Re: [U-Boot] [PATCH] serial: ns16550: fix different reg size access

2011-03-31 Thread Lei Wen
Hi Wolfgang,

On Fri, Apr 1, 2011 at 1:35 PM, Wolfgang Denk  wrote:
> Dear Lei Wen,
>
> In message  you 
> wrote:
>>
>> > Can you please explain on what board, and with which tool chain, you
>> > see any problems?
>>
>> I test on Marvell pxa955 (MG1) board, with android 4.4.0 toolchain.
>> The pxa955's ns16550 register's IER has nine bits. The 8th bit is HSE, which
>> means the high speed mode. It seems something wrong there, if access the ier
>> by byte, the 8th bit would be 1 at the beginning, and would be cleared
>> by the following
>> set value in the ns16550 driver, which cause problem on that board,
>> for the baudrate
>> would be dysfunction.
>
> This makes no sense to me. I have never seen any 9 bit registers in
> any processor I ever encountered in real life.

I don't mean that register is 9bit...
I means that register, IER, is 32bit long, but 9-31th bit is reserved, and
0th to 8th bit is used... Maybe I don't say clearly...
So byte access would only cover 0-7th bit, while 8th bit is not covered.


> Also, in this case the serial controller is probably not NS16550
> compatible, because AFAICT the NS16550 uses only 8 bit wide
> registers.

This is may be additional feature added. For another part except this
one bit is all compatible with ns16550.

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


Re: [U-Boot] [PATCH] serial: ns16550: fix different reg size access

2011-03-31 Thread Wolfgang Denk
Dear Lei Wen,

In message  you 
wrote:
> 
> > Can you please explain on what board, and with which tool chain, you
> > see any problems?
>
> I test on Marvell pxa955 (MG1) board, with android 4.4.0 toolchain.
> The pxa955's ns16550 register's IER has nine bits. The 8th bit is HSE, which
> means the high speed mode. It seems something wrong there, if access the ier
> by byte, the 8th bit would be 1 at the beginning, and would be cleared
> by the following
> set value in the ns16550 driver, which cause problem on that board,
> for the baudrate
> would be dysfunction.

This makes no sense to me. I have never seen any 9 bit registers in
any processor I ever encountered in real life.

Registers are typically 8, 16, 32 or 64 bit.

If your register holds 9 data bits, then it is most probably a 16 or
32 bit wide register.

Also, in this case the serial controller is probably not NS16550
compatible, because AFAICT the NS16550 uses only 8 bit wide
registers.


Further, it is not clear to me why there is a Mervell specific version
of the NS16550 driver (board/Marvell/common/ns16550.*).

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
Time is an illusion perpetrated by the manufacturers of space.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] serial: ns16550: fix different reg size access

2011-03-31 Thread Lei Wen
Hi Wolfgang,

On Thu, Mar 31, 2011 at 11:58 PM, Wolfgang Denk  wrote:
> Dear Lei Wen,
>
> In message <1301586774-25447-1-git-send-email-lei...@marvell.com> you wrote:
>> Some hardware would dysfunctional if only access the register by
>> byte. This patch is tend to recover original access the responding
>> register according to CONFIG_SYS_NS16550_REG_SIZE.
>
> Can you please explain on what board, and with which tool chain, you
> see any problems?

I test on Marvell pxa955 (MG1) board, with android 4.4.0 toolchain.
The pxa955's ns16550 register's IER has nine bits. The 8th bit is HSE, which
means the high speed mode. It seems something wrong there, if access the ier
by byte, the 8th bit would be 1 at the beginning, and would be cleared
by the following
set value in the ns16550 driver, which cause problem on that board,
for the baudrate
would be dysfunction.
If access the ier by int type, then the 8bit would be cleared, and
uart behavior normal.

>
>> +- CONFIG_SYS_NS16550_MAX_REG_SIZE:
>> +             Define the ns16550 max register size,
>> +             if the CONFIG_SYS_NS16550_REG_SIZE is smaller than this value,
>> +             use padding to fill those gap.
>
> This makes no sense to me.  A register is always one specific size,
> so the term "MAX_REG_SIZE" is bogus.

I introduce this CONFIG is for I found when
CONFIG_SYS_NS16550_REG_SIZE is 1 or -1,
there would be no prepad in the structure. And this means the register
size is char only?

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


Re: [U-Boot] how does Linux call the function from u-boot?

2011-03-31 Thread Wolfgang Denk
Dear "sywang",

In message  you wrote:
> 
> In my scenario, I want to write the panic info into the flash, but the panic

If the system panics, you must not assume that there is any working
code left that is capable of writing to flash memory.

> is caused by interrupt routine, I cannot access the flash, so I think that
> if the flash-write function from u-boot can be called, the issue should be
> resolved. 

I told you before that there is no U-Boot code available anywhere once
Linux started execution.

You may look into the shared log buffer feature - if Linux dumps it's
log messages into it's log buffer, this information can be picked up
by U-Boot from there, and even passed on to the next booting Linux
kernel.

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


Re: [U-Boot] Saving environment question

2011-03-31 Thread Wolfgang Denk
Dear Charles Krinke,

In message  you 
wrote:
>
> up_data = (end_addr + 1 - ((long)flash_addr + CONFIG_ENV_SIZE));
> debug("2 Data to save 0x%lx  end:%lx new:%lx\n", up_data, end_addr,
> flash_addr);
> if (up_data) {
> if ((saved_data = malloc(up_data)) == NULL) {
> printf("Unable to save the rest of sector (%ld)\n",
> up_data);
> goto done;
> }
> 
> At the debug statement, up_data = 0x1E000, end_addr = 0xFE07 and
> flash_addr = 0xFE06. The end_addr and flash_addr seem reasonable to me
> as the flash in 128Kb sectors in the MPC8323ERDB so the first few sectors
> are:

Hmm...

up_data = (end_addr + 1 - ((long)flash_addr + CONFIG_ENV_SIZE));

so

CONFIG_ENV_SIZE = up_data + flash_addr - end_addr - 1
= 0x1E000 + 0xFE06 - 0xFE07 - 1
= -8192

The values you give here make no sense to me, as CONFIG_ENV_SIZE is
supposed to be a positive number.


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 something is different, it's either better or worse,  and  usually
both.- Larry Wall
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] DSN: failed (Returned mail: see transcript for details)

2011-03-31 Thread Mailbot for etexusa . com

This is a Delivery Status Notification (DSN).

I was unable to deliver your message to
aardee...@rediffmail.com.

I said 
  (end of message)

And they gave me the error;
  552 suspicious virus code detected in executables attached, message not 
accepted (#5.3.4)

 
Reporting-MTA: dns; etexusa.com
Final-Recipient: RFC822; aardeelon@rediffmail.com
Action: failed
Status: 5.0.0
Received: from lists.denx.de ([122.178.150.71]) by etexusa.com for ; Thu, 31 Mar 2011 21:16:39 -0700
From: u-boot@lists.denx.de
To: aardee...@rediffmail.com
Subject: Returned mail: see transcript for details
Date: Fri, 1 Apr 2011 09:46:07 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=_NextPart_000_0009_21A0B6E1.A2767546"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.

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


Re: [U-Boot] mpq101 board broken

2011-03-31 Thread Andy Fleming
I ran into this, too, but it went away when I updated my compiler. It
looks like the beginning was set a little too close to the end?

On Thu, Mar 31, 2011 at 9:55 AM, Wolfgang Denk  wrote:
> Dear Alex,
>
> the mpq101 board support is broken in recent versions of U-Boot:
>
> Configuring for mpq101 board...
> ppc_85xxDP-ld: u-boot: section .ppcenv lma 0xfffc overlaps previous 
> sections
>
> Can you please have a look?
>
> 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 must follow the people.  Am I not their leader? - Benjamin Disraeli
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] how does Linux call the function from u-boot?

2011-03-31 Thread sywang

Thanks for your reply very much. 

In my scenario, I want to write the panic info into the flash, but the panic
is caused by interrupt routine, I cannot access the flash, so I think that
if the flash-write function from u-boot can be called, the issue should be
resolved. 

Any other comments? 


Thanks!
Shuyou 

-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de] 
Sent: 2011年3月31日 18:01
To: sywang
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] how does Linux call the function from u-boot?

Dear "sywang",

In message  you wrote:
> 
> how does Linux call the function from u-boot?

Simply: it does not.

When Linux starts running, U-Boot is gone and dead; nothing of it
survives the boot of Linux except for the parameters passed to the
Linux kernel.

Linux has no idea which boot loader has been used to start it, nor
can Linux call any functions from the boot loader.

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
Punishment becomes ineffective after a certain point. Men become  in-
sensitive.
-- Eneg, "Patterns of Force", stardate 2534.7

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


[U-Boot] Saving environment question

2011-03-31 Thread Charles Krinke
I have an MPC8323ERDB that I am trying to update from an older version of
u-boot to 2010.12 and am having trouble saving the environment with
"saveenv". I turn on the debug in env_flash.c and can see the failure is at
line 271 near the beginning of the saveenv() routine where we are trying to
mallic(up_data).

up_data = (end_addr + 1 - ((long)flash_addr + CONFIG_ENV_SIZE));
debug("2 Data to save 0x%lx  end:%lx new:%lx\n", up_data, end_addr,
flash_addr);
if (up_data) {
if ((saved_data = malloc(up_data)) == NULL) {
printf("Unable to save the rest of sector (%ld)\n",
up_data);
goto done;
}

At the debug statement, up_data = 0x1E000, end_addr = 0xFE07 and
flash_addr = 0xFE06. The end_addr and flash_addr seem reasonable to me
as the flash in 128Kb sectors in the MPC8323ERDB so the first few sectors
are:

FE00 - FE01
FE02 - FE03
FE04 - FE05
*FE06 - FE07*

The malloc itself appears to be failing and this puzzles me.

Would anyone be willing to point out the location of the "naievety hole" I
have fallen into with this little sub-project??
-- 
Charles Krinke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] u-boot fails to build for powerpc with gcc 4.5.1

2011-03-31 Thread Kumar Gala

On Mar 31, 2011, at 5:27 PM, Darren Hart wrote:

> The u-boot recipe in Poky (OE core) fails to build u-boot for powerpc.
> I've tested the following versions:
> 
> v2010.09
> v2010.12
> v2011.03
> 
> All versions fail with:
> $ make ARCH=powerpc
> CROSS_COMPILE=/opt/poky/1.0/sysroots/x86_64-pokysdk-linux/usr/bin/ppc603e-poky-linux/powerpc-poky-linux-
> MPC8315ERDB_config
> awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg >
> .boards.depend
> Generating include/autoconf.mk
> cc1: error: Do not use -Os option if --enable-target-optspace is not set.
> Generating include/autoconf.mk.dep
> cc1: error: Do not use -Os option if --enable-target-optspace is not set.
> Configuring for MPC8315ERDB board...
> 
> I got past this with:
> diff --git a/config.mk b/config.mk
> index eb95093..374b262 100644
> --- a/config.mk
> +++ b/config.mk
> @@ -151,7 +151,7 @@ ARFLAGS = crv
> endif
> RELFLAGS= $(PLATFORM_RELFLAGS)
> DBGFLAGS= -g # -DDEBUG
> -OPTFLAGS= -Os #-fomit-frame-pointer
> +OPTFLAGS= #-Os #-fomit-frame-pointer
> ifndef LDSCRIPT
> #LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds.debug
> ifeq ($(CONFIG_NAND_U_BOOT),y)
> 
> 
> 
> v2010.09 fails with:
> crc32.c:85:1: error: initializer element is not constant crc32.c:85:1: error: 
> (near initialization for 'crc_table[0]') 
> This appears to be fixed in later versions.
> 
> 
> v2010.12 and v2011.03 fail with:
> ehci-hcd.c:59:3: error: initializer element is not constant
> 
> Full build logs are available in the bug report here:
> http://bugzilla.pokylinux.org/show_bug.cgi?id=943

This is interesting, we've been using a Code Sourcey based 4.5.1 (hard to tell 
exactly what it is)

gcc version 4.5.1 (Sourcery G++ Lite 2010.09-55) 

and it builds just fine.

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


[U-Boot] u-boot fails to build for powerpc with gcc 4.5.1

2011-03-31 Thread Darren Hart
The u-boot recipe in Poky (OE core) fails to build u-boot for powerpc.
I've tested the following versions:

v2010.09
v2010.12
v2011.03

All versions fail with:
$ make ARCH=powerpc
CROSS_COMPILE=/opt/poky/1.0/sysroots/x86_64-pokysdk-linux/usr/bin/ppc603e-poky-linux/powerpc-poky-linux-
MPC8315ERDB_config
awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg >
.boards.depend
Generating include/autoconf.mk
cc1: error: Do not use -Os option if --enable-target-optspace is not set.
Generating include/autoconf.mk.dep
cc1: error: Do not use -Os option if --enable-target-optspace is not set.
Configuring for MPC8315ERDB board...

I got past this with:
diff --git a/config.mk b/config.mk
index eb95093..374b262 100644
--- a/config.mk
+++ b/config.mk
@@ -151,7 +151,7 @@ ARFLAGS = crv
 endif
 RELFLAGS= $(PLATFORM_RELFLAGS)
 DBGFLAGS= -g # -DDEBUG
-OPTFLAGS= -Os #-fomit-frame-pointer
+OPTFLAGS= #-Os #-fomit-frame-pointer
 ifndef LDSCRIPT
 #LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds.debug
 ifeq ($(CONFIG_NAND_U_BOOT),y)



v2010.09 fails with:
crc32.c:85:1: error: initializer element is not constant crc32.c:85:1: error: 
(near initialization for 'crc_table[0]') 
This appears to be fixed in later versions.


v2010.12 and v2011.03 fail with:
ehci-hcd.c:59:3: error: initializer element is not constant

Full build logs are available in the bug report here:
http://bugzilla.pokylinux.org/show_bug.cgi?id=943

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] Fix build issues cause by LDFLAGS_FINAL changes

2011-03-31 Thread Wolfgang Denk
Dear Scott Wood,

In message <20110331212629.ga17...@schlenkerla.am.freescale.net> you wrote:
> From: Wolfgang Denk 
> 
> Commit 6dc1ece "Introduce a new linker flag LDFLAGS_FINAL" modified a
> number of Makefiles in a way that broke out-of-tree builds.  The
> problem was that $(nandobj) was used before it got defined.
> 
> Fix this.
> 
> Signed-off-by: Wolfgang Denk 
> Signed-off-by: Scott Wood 
> ---
> v2: Added da8xxevm, mx31pdk, p1_p2_rdb, tx25, smdk6400
> 
> Applied to u-boot-nand-flash
> 
>  nand_spl/board/amcc/acadia/Makefile   |6 +++---
>  nand_spl/board/amcc/bamboo/Makefile   |6 +++---
>  nand_spl/board/amcc/canyonlands/Makefile  |6 +++---
>  nand_spl/board/amcc/kilauea/Makefile  |6 +++---
>  nand_spl/board/amcc/sequoia/Makefile  |6 +++---
>  nand_spl/board/davinci/da8xxevm/Makefile  |6 +++---
>  nand_spl/board/freescale/mpc8313erdb/Makefile |6 +++---
>  nand_spl/board/freescale/mpc8315erdb/Makefile |6 +++---
>  nand_spl/board/freescale/mpc8536ds/Makefile   |6 +++---
>  nand_spl/board/freescale/mpc8569mds/Makefile  |6 +++---
>  nand_spl/board/freescale/mpc8572ds/Makefile   |6 +++---
>  nand_spl/board/freescale/mx31pdk/Makefile |6 +++---
>  nand_spl/board/freescale/p1_p2_rdb/Makefile   |6 +++---
>  nand_spl/board/karo/tx25/Makefile |6 +++---
>  nand_spl/board/samsung/smdk6400/Makefile  |6 +++---
>  nand_spl/board/sheldon/simpc8313/Makefile |6 +++---
>  16 files changed, 48 insertions(+), 48 deletions(-)

Applied to master, 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
"(The  Chief  Programmer)  personally  defines  the  functional   and
performance  specifications, designs the program, codes it, tests it,
and writes its documentation... He  needs  great  talent,  ten  years
experience  and  considerable  systems  and  applications  knowledge,
whether in applied mathematics, business data handling, or whatever."
- Fred P. Brooks, _The Mythical Man Month_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Build issues with a number of 83xx boards

2011-03-31 Thread Wolfgang Denk
Dear Scott Wood,

In message <20110331112109.12162...@schlenkerla.am.freescale.net> you wrote:
>
> I don't see the above error with top-of-tree:
> 
> $ CROSS_COMPILE=~/ppc-tc-4.5/bin/powerpc-linux-gnu- ./MAKEALL 
> MPC8313ERDB_NAND_33
> Configuring for MPC8313ERDB_NAND_33 - Board: MPC8313ERDB, Options: 
> SYS_33MHZ,NAND_U_BOOT
>textdata bss dec hex filename
>  250372   27944   42056  320372   4e374 ./u-boot

No, you don't see it, because you're not building out of tree.

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 quarrel is quickly settled when deserted by one party; there is  no
battle unless there be two.  - Seneca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] Fix build issues cause by LDFLAGS_FINAL changes

2011-03-31 Thread Scott Wood
From: Wolfgang Denk 

Commit 6dc1ece "Introduce a new linker flag LDFLAGS_FINAL" modified a
number of Makefiles in a way that broke out-of-tree builds.  The
problem was that $(nandobj) was used before it got defined.

Fix this.

Signed-off-by: Wolfgang Denk 
Signed-off-by: Scott Wood 
---
v2: Added da8xxevm, mx31pdk, p1_p2_rdb, tx25, smdk6400

Applied to u-boot-nand-flash

 nand_spl/board/amcc/acadia/Makefile   |6 +++---
 nand_spl/board/amcc/bamboo/Makefile   |6 +++---
 nand_spl/board/amcc/canyonlands/Makefile  |6 +++---
 nand_spl/board/amcc/kilauea/Makefile  |6 +++---
 nand_spl/board/amcc/sequoia/Makefile  |6 +++---
 nand_spl/board/davinci/da8xxevm/Makefile  |6 +++---
 nand_spl/board/freescale/mpc8313erdb/Makefile |6 +++---
 nand_spl/board/freescale/mpc8315erdb/Makefile |6 +++---
 nand_spl/board/freescale/mpc8536ds/Makefile   |6 +++---
 nand_spl/board/freescale/mpc8569mds/Makefile  |6 +++---
 nand_spl/board/freescale/mpc8572ds/Makefile   |6 +++---
 nand_spl/board/freescale/mx31pdk/Makefile |6 +++---
 nand_spl/board/freescale/p1_p2_rdb/Makefile   |6 +++---
 nand_spl/board/karo/tx25/Makefile |6 +++---
 nand_spl/board/samsung/smdk6400/Makefile  |6 +++---
 nand_spl/board/sheldon/simpc8313/Makefile |6 +++---
 16 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/nand_spl/board/amcc/acadia/Makefile 
b/nand_spl/board/amcc/acadia/Makefile
index f4323d5..84cb8ab 100644
--- a/nand_spl/board/amcc/acadia/Makefile
+++ b/nand_spl/board/amcc/acadia/Makefile
@@ -24,6 +24,8 @@
 include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
+nandobj:= $(OBJTREE)/nand_spl/
+
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
 LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
   $(LDFLAGS_FINAL)
@@ -36,9 +38,7 @@ COBJS = gpio.o nand_boot.o nand_ecc.o memory.o ndfc.o pll.o
 SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
 __OBJS := $(SOBJS) $(COBJS)
-LNDIR  := $(OBJTREE)/nand_spl/board/$(BOARDDIR)
-
-nandobj:= $(OBJTREE)/nand_spl/
+LNDIR  := $(nandobj)board/$(BOARDDIR)
 
 ALL= $(nandobj)u-boot-spl $(nandobj)u-boot-spl.bin 
$(nandobj)u-boot-spl-16k.bin \
$(nandobj)System.map
diff --git a/nand_spl/board/amcc/bamboo/Makefile 
b/nand_spl/board/amcc/bamboo/Makefile
index 15af860..6430219 100644
--- a/nand_spl/board/amcc/bamboo/Makefile
+++ b/nand_spl/board/amcc/bamboo/Makefile
@@ -24,6 +24,8 @@
 include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
+nandobj:= $(OBJTREE)/nand_spl/
+
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
 LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
   $(LDFLAGS_FINAL)
@@ -36,9 +38,7 @@ COBJS = nand_boot.o nand_ecc.o ndfc.o sdram.o
 SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
 __OBJS := $(SOBJS) $(COBJS)
-LNDIR  := $(OBJTREE)/nand_spl/board/$(BOARDDIR)
-
-nandobj:= $(OBJTREE)/nand_spl/
+LNDIR  := $(nandobj)board/$(BOARDDIR)
 
 ALL= $(nandobj)u-boot-spl $(nandobj)u-boot-spl.bin 
$(nandobj)u-boot-spl-16k.bin
 
diff --git a/nand_spl/board/amcc/canyonlands/Makefile 
b/nand_spl/board/amcc/canyonlands/Makefile
index 62c77d8..509a46e 100644
--- a/nand_spl/board/amcc/canyonlands/Makefile
+++ b/nand_spl/board/amcc/canyonlands/Makefile
@@ -24,6 +24,8 @@
 include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
+nandobj:= $(OBJTREE)/nand_spl/
+
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
 LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
   $(LDFLAGS_FINAL)
@@ -41,9 +43,7 @@ COBJS += ndfc.o
 SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
 __OBJS := $(SOBJS) $(COBJS)
-LNDIR  := $(OBJTREE)/nand_spl/board/$(BOARDDIR)
-
-nandobj:= $(OBJTREE)/nand_spl/
+LNDIR  := $(nandobj)board/$(BOARDDIR)
 
 ALL= $(nandobj)u-boot-spl $(nandobj)u-boot-spl.bin 
$(nandobj)u-boot-spl-16k.bin
 
diff --git a/nand_spl/board/amcc/kilauea/Makefile 
b/nand_spl/board/amcc/kilauea/Makefile
index 1053ce3..104b7e2 100644
--- a/nand_spl/board/amcc/kilauea/Makefile
+++ b/nand_spl/board/amcc/kilauea/Makefile
@@ -24,6 +24,8 @@
 include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
+nandobj:= $(OBJTREE)/nand_spl/
+
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
 LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
   $(LDFLAGS_FINAL)
@@ -36,9 +38,7 @@ COBJS = 44x_spd_ddr2.o nand_boot.o nand_ecc.o ndfc.o
 SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
 __OBJS := $(SOBJS) $(COBJS)
-LNDIR  := $(

Re: [U-Boot] [PATCH] ehci-pci: Add PCI EHCI controller

2011-03-31 Thread Remy Bohmer
Hi,

2011/3/31 Trübenbach, Ralf :
> This patch adds support for the PI7C9X442SL PCIe EHCI host controller
> from Pericom.
>
> Tested at P4080DS eval board from Freescale.
>
> Signed-off-by: Ralf Trübenbach 
> Cc: Remy Bohmer 
> ---
>

Applied to u-boot-usb.

Thanks.

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


Re: [U-Boot] [PATCH] Fix build issues cause by LDFLAGS_FINAL changes

2011-03-31 Thread Scott Wood
On Thu, 31 Mar 2011 16:52:31 +0200
Wolfgang Denk  wrote:

> Commit 6dc1ece "Introduce a new linker flag LDFLAGS_FINAL" modified a
> number of Makefiles in a way that broke out-of-tree builds.  The
> problem was that $(nandobj) was used before it got defined.
> 
> Fix this.
> 
> Signed-off-by: Wolfgang Denk 
> ---
>  nand_spl/board/amcc/acadia/Makefile   |6 +++---
>  nand_spl/board/amcc/bamboo/Makefile   |6 +++---
>  nand_spl/board/amcc/canyonlands/Makefile  |6 +++---
>  nand_spl/board/amcc/kilauea/Makefile  |6 +++---
>  nand_spl/board/amcc/sequoia/Makefile  |6 +++---
>  nand_spl/board/freescale/mpc8313erdb/Makefile |6 +++---
>  nand_spl/board/freescale/mpc8315erdb/Makefile |6 +++---
>  nand_spl/board/freescale/mpc8536ds/Makefile   |6 +++---
>  nand_spl/board/freescale/mpc8569mds/Makefile  |6 +++---
>  nand_spl/board/freescale/mpc8572ds/Makefile   |6 +++---
>  nand_spl/board/sheldon/simpc8313/Makefile |6 +++---
>  11 files changed, 33 insertions(+), 33 deletions(-)

Also needed in da8xxevm, tx25, smdk6400, and mx31pdk.

Should also be done in p1_p2_rdb for consistency (it doesn't use nandobj in
LDFLAGS, but neither do the ohter 85xx that got updated).

-Scott

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


Re: [U-Boot] Build issues with a number of 83xx boards

2011-03-31 Thread Scott Wood
On Thu, 31 Mar 2011 11:51:30 -0500
Kim Phillips  wrote:

> On Thu, 31 Mar 2011 11:21:09 -0500
> Scott Wood  wrote:
> 
> > On Thu, 31 Mar 2011 17:40:17 +0200
> > Wolfgang Denk  wrote:
> > > In message <20110331103141.80162901.kim.phill...@freescale.com> you wrote:
> > > > Scott, please push this commit upstream to fix out of source tree
> > > > NAND builds.
> > > 
> > > See my previous mail with a fix.
> > > 
> > > Why put such fiuxes into a NEXT branch when we're trying to get a
> > > release ot?
> > > 
> > > That's ... 
> > 
> > The patch Kim quoted, which is in my next branch, is unrelated to the above
> > error.  It is a cleanup patch.
> 
> it prepends the build directory $(obj) to the nand_spl target.

The build directory was always prepended to the nand_spl target.
That patch just moves where the target was defined.

The problem is with $(nandobj) in the nand_spl makefiles.

> But now
> WD has posted another patch (that seems more invasive than the one I
> quoted).

It's solving a different problem, and it's the right fix -- it's better to
avoid depending on deferred evaluation if we can do so reasonably.

> > I don't see the above error with top-of-tree:
> > 
> > $ CROSS_COMPILE=~/ppc-tc-4.5/bin/powerpc-linux-gnu- ./MAKEALL 
> > MPC8313ERDB_NAND_33
> 
> try BUILD_DIR=/tmp/hah ./MAKEALL MPC8313ERDB_NAND_33

Right, I saw afterward that it was an out-of-tree build.  I see the same
thing in my next branch, once I rebase onto Wolfgang's current master which
has the LDFLAGS_FINAL patch.

"Fix NAND_SPL and ONENAND_IPL in Makefile" has nothing to do with this.

-Scott

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


Re: [U-Boot] Build issues with a number of 83xx boards

2011-03-31 Thread Kim Phillips
On Thu, 31 Mar 2011 11:21:09 -0500
Scott Wood  wrote:

> On Thu, 31 Mar 2011 17:40:17 +0200
> Wolfgang Denk  wrote:
> > In message <20110331103141.80162901.kim.phill...@freescale.com> you wrote:
> > > Scott, please push this commit upstream to fix out of source tree
> > > NAND builds.
> > 
> > See my previous mail with a fix.
> > 
> > Why put such fiuxes into a NEXT branch when we're trying to get a
> > release ot?
> > 
> > That's ... 
> 
> The patch Kim quoted, which is in my next branch, is unrelated to the above
> error.  It is a cleanup patch.

it prepends the build directory $(obj) to the nand_spl target.  But now
WD has posted another patch (that seems more invasive than the one I
quoted).

> I don't see the above error with top-of-tree:
> 
> $ CROSS_COMPILE=~/ppc-tc-4.5/bin/powerpc-linux-gnu- ./MAKEALL 
> MPC8313ERDB_NAND_33

try BUILD_DIR=/tmp/hah ./MAKEALL MPC8313ERDB_NAND_33

Kim

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


[U-Boot] [PATCH] ehci-pci: Add PCI EHCI controller

2011-03-31 Thread Trübenbach , Ralf
This patch adds support for the PI7C9X442SL PCIe EHCI host controller 
from Pericom.

Tested at P4080DS eval board from Freescale.

Signed-off-by: Ralf Trübenbach 
Cc: Remy Bohmer  
---

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index cff3438..2b68f7b 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -28,7 +28,8 @@
 #ifdef CONFIG_PCI_EHCI_DEVICE
 static struct pci_device_id ehci_pci_ids[] = {
/* Please add supported PCI EHCI controller ids here */
-   {0x1033, 0x00E0},
+   {0x1033, 0x00E0},   /* NEC */
+   {0x12D8, 0x400F},   /* Pericom */
{0, 0}
 };
 #endif


--
Best Regards/Mit freundlichen Gruessen
Ralf Trübenbach

Ralf Trübenbach, Software Design
MEN Mikro Elektronik GmbH
Neuwieder Straße 5-7
90411 Nürnberg, Germany
Phone +49-911-99 33 5-0
Fax +49-911-99 33 5-910
ralf.truebenb...@men.de
www.men.de
MEN Mikro Elektronik GmbH - Manfred Schmitz (CTO), Udo Fuchs (CFO)
Handelsregister/Trade Register AG Nürnberg HRB 5540

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


Re: [U-Boot] data alignment problem with redundant env

2011-03-31 Thread Andre Schwarz
Wolfgang,
>>> Which board would that be?  I don't see this on any board I tested.
>> it is mvblm7 (=MPC8343) and a new MPC8377 based one waiting for
>> the merge window to open.
>>
>>
>> I'm using a gcc-4.3.3 from OpenEmbedded/Angstrom ... if this matters at all.
> Can you please try and use anothe rtool chain, say good ole ELDK 4.2
> for a test?
yes, of course.
But I can make some tests on real hardware not before monday.

This is what I can say after compiling with both toolchains.

1. redundant env

CROSS_COMPILE=ppc_6xx- ARCH=powerpc sh MAKEALL mvblm7
text   databssdechexfilename
  233298  21940  66960 322198  4ea96./u-boot

CROSS_COMPILE=powerpc-angstrom-linux-  ARCH=powerpc sh MAKEALL mvblm7
text   databssdechexfilename
  233758  21948  66956 322662  4ec66./u-boot


2. without redundant env

swa@swa-m460:~/u-boot$ CROSS_COMPILE=ppc_6xx- ARCH=powerpc sh MAKEALL mvblm7
text   databssdechexfilename
  232494  21912  66960 321366  4e756./u-boot

swa@swa-m460:~/u-boot$ CROSS_COMPILE=powerpc-angstrom-linux-  
ARCH=powerpc sh MAKEALL mvblm7
text   databssdechexfilename
  232954  21920  66956 321830  4e926./u-boot


size of final u-boot binary differs by 8 bytes ... sounds promising ;-)

Will run both versions asap.


Regards,
André

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Fix build issues cause by LDFLAGS_FINAL changes

2011-03-31 Thread Haiying Wang
On Thu, 2011-03-31 at 17:37 +0200, Wolfgang Denk wrote:

> > $(nandobj) was defined in those Makefiles in that way before applying
> > LDFLAGS_FINAL patch. Why could the out-of-tree builds passed before
> > applying LDFLAG_FINAL patch?
> 
> Have a look at the changes introduced by your commit, and you will
> see.  The problem is a bit buried in the changes of "=" into ":=" and
> "$(PLATFORM_LDFLAGS)" into "$(LDFLAGS) $(LDFLAGS_FINAL)" in lines like
> these:
> 
> -LDFLAGS= -Bstatic -T $(nandobj)u-boot.lds -Ttext 
> $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
> +LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) 
> \
> +  $(LDFLAGS_FINAL)

Oh,yes, I got it now. ":=" will expand the variables immediately and "="
will delay the expansion until the new variable is referenced, which can
explain the $(nandobj)worked before this patch. 

> 
> [It is a bit strange to append to LDFLAGS line that.]
The reason I used ":=" was because I added "LDFLAGS_FINAL += -Bstatic
$(LDFLAGS)" in my first version of this patch, but it seems that it is
not necessary to do so after I remove $(LDFLAGS) for LDFLAGS_FINAL.

Thanks for pointing it out.

Haiying


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


Re: [U-Boot] Build issues with a number of 83xx boards

2011-03-31 Thread Scott Wood
On Thu, 31 Mar 2011 17:40:17 +0200
Wolfgang Denk  wrote:

> Dear Kim Phillips,
> 
> In message <20110331103141.80162901.kim.phill...@freescale.com> you wrote:
> > On Thu, 31 Mar 2011 11:19:15 +0200
> > Wolfgang Denk  wrote:
> > 
> > > Dear Kim & Kumar,
> > > 
> > > are you aware that a number of 83xx boards don't build any more?
> > > I see errors like these:
> > > 
> > > Configuring for MPC8313ERDB_NAND_33 - Board: MPC8313ERDB, Options: 
> > > SYS_33MHZ,NAND_U_BOOT
> > > ppc_6xx-ld: cannot open linker script file u-boot.lds: No such file or
> > > directory
> > > make[1]: *** [/work/wd/tmp-ppc/nand_spl/u-boot-spl] Error 1
> > 
> > this isn't 83xx-specific; the nand_spl target was source tree build
> > dependent.  Scott already has a fix in his next branch:
> > 
> > http://git.denx.de/?p=u-boot/u-boot-nand-flash.git;a=commit;h=f13a375e5875acbfec298e9967d2f234f027ab16
> > 
> > Scott, please push this commit upstream to fix out of source tree
> > NAND builds.
> 
> See my previous mail with a fix.
> 
> 
> Why put such fiuxes into a NEXT branch when we're trying to get a
> release ot?
> 
> That's ... 

The patch Kim quoted, which is in my next branch, is unrelated to the above
error.  It is a cleanup patch.

I don't see the above error with top-of-tree:

$ CROSS_COMPILE=~/ppc-tc-4.5/bin/powerpc-linux-gnu- ./MAKEALL 
MPC8313ERDB_NAND_33
Configuring for MPC8313ERDB_NAND_33 - Board: MPC8313ERDB, Options: 
SYS_33MHZ,NAND_U_BOOT
   textdata bss dec hex filename
 250372   27944   42056  320372   4e374 ./u-boot

- SUMMARY 
Boards compiled: 1
--

$ git describe HEAD
v2011.03-rc2-6-gb12fee0

-Scott

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


Re: [U-Boot] [PATCH v3 01/23] powerpc, mpc83xx: add missing functions to mpc83xx.h

2011-03-31 Thread Kim Phillips
On Thu, 31 Mar 2011 07:38:18 +0200
Heiko Schocher  wrote:

> Hello Kim,
> 
> Kim Phillips wrote:
> > On Mon, 21 Mar 2011 08:01:57 +0100
> > Heiko Schocher  wrote:
> > 
> >> Signed-off-by: Heiko Schocher 
> >> cc: Kim Phillips 
> >> cc: Holger Brunck 
> >> cc: Wolfgang Denk 
> >> cc: Detlev Zundel 
> >> cc: Valentin Longchamp 
> >> ---
> > 
> > Hi Heiko, sorry for the late review, but I must admit it doesn't help
> > the reviewer at all when later patches in a patchseries modify things
> > added by earlier patches in the same patchseries!
> 
> Sorry for that, I know, it is a big patchset ...

it's just that it could have been shortened to all the refactoring
parts first, then the adding of all the new boards.

> >>  include/mpc83xx.h |6 ++
> >>  1 files changed, 6 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/include/mpc83xx.h b/include/mpc83xx.h
> >> index ea137c7..e1b0929 100644
> >> --- a/include/mpc83xx.h
> >> +++ b/include/mpc83xx.h
> >> @@ -1274,6 +1274,12 @@ struct pci_region;
> >>  void mpc83xx_pci_init(int num_buses, struct pci_region **reg);
> >>  void mpc83xx_pcislave_unlock(int bus);
> >>  void mpc83xx_pcie_init(int num_buses, struct pci_region **reg);
> >> +
> >> +void disable_addr_trans(void);
> >> +void enable_addr_trans(void);
> >> +#if defined(CONFIG_DDR_ECC) && !defined(CONFIG_ECC_INIT_VIA_DDRCONTROLLER)
> >> +void ddr_enable_ecc(unsigned int dram_size);
> >> +#endif
> > 
> > I don't believe these prototypes belong in mpc83xx.h - they're really
> > not 83xx-specific - e.g., 74xx and 85xx have identical names for
> > functions that have the same...function.
> > 
> > Looking around I think the best place for them would be the 'start.S'
> > section of include/common.h.  Feel free to protect with 83xx ifdefs;
> > others can add their platforms as necessary.
> 
> Hmm.. I thought of this too, but that will result in adding ifdefs.

in common.h?  there already is a ifdef 83xx in the start.S section of
that file - at line 447

wrt ddr_enable_ecc, modern 85xx #include , but I'm
not sure how well 83xx will receive that.  If it doesn't, I wouldn't
have a problem with taking the entire chunk as-is and putting it into
the aforementioned 83xx-protected part of common.h.

> (and special this file has a lot of ifdefs, so I wanted to prevent
>  another ifdef mess...). But I can of course move it to
> include/common.h if thats the preferred place ... ?

please.

Thanks,

Kim

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


Re: [U-Boot] data alignment problem with redundant env

2011-03-31 Thread Wolfgang Denk
Dear Andre Schwarz,

In message <4d94a250@matrix-vision.de> you wrote:
>
> > Which board would that be?  I don't see this on any board I tested.
> it is mvblm7 (=MPC8343) and a new MPC8377 based one waiting for
> the merge window to open.
> 
> 
> I'm using a gcc-4.3.3 from OpenEmbedded/Angstrom ... if this matters at all.

Can you please try and use anothe rtool chain, say good ole ELDK 4.2
for a test?

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
Behind every great man, there is a woman -- urging him on.
-- Harry Mudd, "I, Mudd", stardate 4513.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] serial: ns16550: fix different reg size access

2011-03-31 Thread Wolfgang Denk
Dear Lei Wen,

In message <1301586774-25447-1-git-send-email-lei...@marvell.com> you wrote:
> Some hardware would dysfunctional if only access the register by
> byte. This patch is tend to recover original access the responding
> register according to CONFIG_SYS_NS16550_REG_SIZE.

Can you please explain on what board, and with which tool chain, you
see any problems?

> +- CONFIG_SYS_NS16550_MAX_REG_SIZE:
> + Define the ns16550 max register size,
> + if the CONFIG_SYS_NS16550_REG_SIZE is smaller than this value,
> + use padding to fill those gap.

This makes no sense to me.  A register is always one specific size,
so the term "MAX_REG_SIZE" is bogus.

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
Landru! Guide us!
-- A Beta 3-oid, "The Return of the Archons", stardate 3157.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] serial: ns16550: fix different reg size access

2011-03-31 Thread Lei Wen
Some hardware would dysfunctional if only access the register by
byte. This patch is tend to recover original access the responding
register according to CONFIG_SYS_NS16550_REG_SIZE.

Signed-off-by: Lei Wen 
---
 README   |5 
 drivers/serial/ns16550.c |7 --
 include/ns16550.h|   51 +
 3 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/README b/README
index 21cd71b..45bc7dd 100644
--- a/README
+++ b/README
@@ -2660,6 +2660,11 @@ use the "saveenv" command to store a valid environment.
space for already greatly restricted images, including but not
limited to NAND_SPL configurations.
 
+- CONFIG_SYS_NS16550_MAX_REG_SIZE:
+   Define the ns16550 max register size,
+   if the CONFIG_SYS_NS16550_REG_SIZE is smaller than this value,
+   use padding to fill those gap.
+
 Low Level (hardware related) configuration options:
 ---
 
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 8eeb48f..4956c7f 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -16,13 +16,6 @@
 #define UART_FCRVAL (UART_FCR_FIFO_EN |\
 UART_FCR_RXSR |\
 UART_FCR_TXSR) /* Clear & enable FIFOs */
-#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
-#define serial_out(x,y)outb(x,(ulong)y)
-#define serial_in(y)   inb((ulong)y)
-#else
-#define serial_out(x,y) writeb(x,y)
-#define serial_in(y)   readb(y)
-#endif
 
 #ifndef CONFIG_SYS_NS16550_IER
 #define CONFIG_SYS_NS16550_IER  0x00
diff --git a/include/ns16550.h b/include/ns16550.h
index 9ea81e9..a51b6e6 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -20,17 +20,50 @@
  * Note that the following macro magic uses the fact that the compiler
  * will not allocate storage for arrays of size 0
  */
-
-#if !defined(CONFIG_SYS_NS16550_REG_SIZE) || (CONFIG_SYS_NS16550_REG_SIZE == 0)
+#if (CONFIG_SYS_NS16550_REG_SIZE == 4) || (CONFIG_SYS_NS16550_REG_SIZE == -4)
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+#define serial_out(x, y)   outl(x, y)
+#define serial_in(y)   inl(y)
+#else
+#define serial_out(x, y)   writel(x, y)
+#define serial_in(y)   readl(y)
+#endif
+#define UART_REG_TYPE  unsigned int
+#elif (CONFIG_SYS_NS16550_REG_SIZE == 2) || (CONFIG_SYS_NS16550_REG_SIZE == -2)
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+#define serial_out(x, y)   outw(x, y)
+#define serial_in(y)   inw(y)
+#else
+#define serial_out(x, y)   writew(x, y)
+#define serial_in(y)   readw(y)
+#endif
+#define UART_REG_TYPE  unsigned short
+#elif (CONFIG_SYS_NS16550_REG_SIZE == 1) || (CONFIG_SYS_NS16550_REG_SIZE == -1)
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+#define serial_out(x, y)   outb(x, y)
+#define serial_in(y)   inb(y)
+#else
+#define serial_out(x, y)   writeb(x, y)
+#define serial_in(y)   readb(y)
+#endif
+#define UART_REG_TYPE  unsigned char
+#else
 #error "Please define NS16550 registers size."
-#elif (CONFIG_SYS_NS16550_REG_SIZE > 0)
-#define UART_REG(x)   \
-   unsigned char prepad_##x[CONFIG_SYS_NS16550_REG_SIZE - 1]; \
-   unsigned char x;
-#elif (CONFIG_SYS_NS16550_REG_SIZE < 0)
+#endif
+
+#ifndef CONFIG_SYS_NS16550_MAX_REG_SIZE
+#define CONFIG_SYS_NS16550_MAX_REG_SIZE 4
+#endif
+#if (CONFIG_SYS_NS16550_REG_SIZE > 0)
+#define UART_REG(x)\
+   unsigned char prepad_##x[CONFIG_SYS_NS16550_MAX_REG_SIZE\
+   - CONFIG_SYS_NS16550_REG_SIZE]; \
+   UART_REG_TYPE x;
+#else
 #define UART_REG(x)\
-   unsigned char x;\
-   unsigned char postpad_##x[-CONFIG_SYS_NS16550_REG_SIZE - 1];
+   UART_REG_TYPE x;\
+   unsigned char prepad_##x[CONFIG_SYS_NS16550_MAX_REG_SIZE\
+   + CONFIG_SYS_NS16550_REG_SIZE];
 #endif
 
 struct NS16550 {
-- 
1.7.0.4

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


Re: [U-Boot] data alignment problem with redundant env

2011-03-31 Thread Andre Schwarz
Wolfgang,
> Dear Andre Schwarz,
>
> In message<4d949e22.5090...@matrix-vision.de>  you wrote:
>> moving to latest U-Boot introduces some issues with the environment.
> Which board would that be?  I don't see this on any board I tested.
it is mvblm7 (=MPC8343) and a new MPC8377 based one waiting for
the merge window to open.


I'm using a gcc-4.3.3 from OpenEmbedded/Angstrom ... if this matters at all.


Regards,
André

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Build issues with a number of 83xx boards

2011-03-31 Thread Wolfgang Denk
Dear Kim Phillips,

In message <20110331103141.80162901.kim.phill...@freescale.com> you wrote:
> On Thu, 31 Mar 2011 11:19:15 +0200
> Wolfgang Denk  wrote:
> 
> > Dear Kim & Kumar,
> > 
> > are you aware that a number of 83xx boards don't build any more?
> > I see errors like these:
> > 
> > Configuring for MPC8313ERDB_NAND_33 - Board: MPC8313ERDB, Options: 
> > SYS_33MHZ,NAND_U_BOOT
> > ppc_6xx-ld: cannot open linker script file u-boot.lds: No such file or
> > directory
> > make[1]: *** [/work/wd/tmp-ppc/nand_spl/u-boot-spl] Error 1
> 
> this isn't 83xx-specific; the nand_spl target was source tree build
> dependent.  Scott already has a fix in his next branch:
> 
> http://git.denx.de/?p=u-boot/u-boot-nand-flash.git;a=commit;h=f13a375e5875acbfec298e9967d2f234f027ab16
> 
> Scott, please push this commit upstream to fix out of source tree
> NAND builds.

See my previous mail with a fix.


Why put such fiuxes into a NEXT branch when we're trying to get a
release ot?

That's ... 

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
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] data alignment problem with redundant env

2011-03-31 Thread Wolfgang Denk
Dear Andre Schwarz,

In message <4d949e22.5090...@matrix-vision.de> you wrote:
> 
> moving to latest U-Boot introduces some issues with the environment.

Which board would that be?  I don't see this on any board I tested.

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 existence of god implies a violation of causality.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Fix build issues cause by LDFLAGS_FINAL changes

2011-03-31 Thread Wolfgang Denk
Dear Haiying Wang,

In message <1301583985.1991.4.camel@haiying-laptop> you wrote:
>
> What is "out-of-tree builds"? Why did LDFLAGS_FINAL patch break it? the

out-of-tree building means that you store all build results in some
other directory, outside of the source tree. See item 3 under Notes at
http://www.denx.de/wiki/U-Boot/Patches

Your patch broke it because it referenced $(nandobj) before defining
it - aslong as the build directory and the source directory are the
same, this makes no difference.  But for out-of-tree builds...

> $(nandobj) was defined in those Makefiles in that way before applying
> LDFLAGS_FINAL patch. Why could the out-of-tree builds passed before
> applying LDFLAG_FINAL patch?

Have a look at the changes introduced by your commit, and you will
see.  The problem is a bit buried in the changes of "=" into ":=" and
"$(PLATFORM_LDFLAGS)" into "$(LDFLAGS) $(LDFLAGS_FINAL)" in lines like
these:

-LDFLAGS= -Bstatic -T $(nandobj)u-boot.lds -Ttext 
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
+  $(LDFLAGS_FINAL)


[It is a bit strange to append to LDFLAGS line that.]

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 say you are lying. But if everything you say is a lie,  then  you
are  telling  the truth. You cannot tell the truth because everything
you say is a lie. You lie, you tell the truth ... but you cannot, for
you lie.
-- Norman the android, "I, Mudd", stardate 4513.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Build issues with a number of 83xx boards

2011-03-31 Thread Kim Phillips
On Thu, 31 Mar 2011 11:19:15 +0200
Wolfgang Denk  wrote:

> Dear Kim & Kumar,
> 
> are you aware that a number of 83xx boards don't build any more?
> I see errors like these:
> 
> Configuring for MPC8313ERDB_NAND_33 - Board: MPC8313ERDB, Options: 
> SYS_33MHZ,NAND_U_BOOT
> ppc_6xx-ld: cannot open linker script file u-boot.lds: No such file or
> directory
> make[1]: *** [/work/wd/tmp-ppc/nand_spl/u-boot-spl] Error 1

this isn't 83xx-specific; the nand_spl target was source tree build
dependent.  Scott already has a fix in his next branch:

http://git.denx.de/?p=u-boot/u-boot-nand-flash.git;a=commit;h=f13a375e5875acbfec298e9967d2f234f027ab16

Scott, please push this commit upstream to fix out of source tree
NAND builds.

Kim

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


[U-Boot] data alignment problem with redundant env

2011-03-31 Thread Andre Schwarz
Hi,

moving to latest U-Boot introduces some issues with the environment.

Setup:
- PowerPC based boards (52xx / 83xx)
- Environments are in flash with redundancy

Dumping flash the environments with dd and using hexdump shows :

  - crc32 - flags Data (first entry beginning with 'a').
000: b0ea 7858 0100  64...
010: ...

Regarding to include/environment.h data is "unsigned char" as well as 
data[].
To me it looks like 2-byte wide flags (or 16-bit alignment of data) is 
wrong.

Although env modification within u-boot only is safe it breakother
tools modifying the environment within e.g. Linux.


This happened somewhere between v2010.9 and current master.
Back then U-Boot env data started on byte 5.

Do we need an attribute(packed) on the env struct ?

Any help is welcome.


Regards,
André

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] PERSONAL ASSISTANT NEEDED URGENTLY

2011-03-31 Thread Mrs.Michelle & Richard Moore
Hi,
 My name is Mrs Michelle wife to Mr Richard Jones Moore,I came across your 
resume on Career Network saying you need employment.I\'ll need your services as 
a personal assistant for my business within the

. We just moved in to town  a couple of days ago before embarking on a trip 
sponsored by my husband\'s company. Presently we\'re on vacation on board on an 
European line cruiser sponsored by my husband\'s company and we\'ll be back 
soon before the end of this month or at the very beginning of next month. I am 
a fashion designer, i design and make French wedding gowns, and I have numerous 
customers around the country.I work from home and i also supply stores with my 
products.I deal mainly in whole sales. I wish i had my website up already so 
that you can view some of my work but that\'s one of the reason why i need a 
P.A who will plan with me so that we can set everything up.

Sandra is our only child and  daughter and she plays a very important role in 
our family, ever since she was born,the family has never remained the same for 
good. There \'re just the 4 (myself,my husband,my daughter and my husband\'s 
mom) of us in the house hopefully you will be the fifth person.I have an offer 
for you to be my personal assistant and to help with business related issues 
and advice, also to to take care of my business for me whenever am not around 
in person. You can send in your updated resume references in your next email. I 
want to let you know that we\'re having much fun out here, we would have love 
to call you but the network on board is really poor because of the high tides 
for this particular period of the year.But we would call you as soon as we get 
a clearer reception. My daughter has been a little ill and she has been in the 
Intensive care Unit on board for the past two  days, But I thank God she\'s is 
getting on fine and this will prompt us in coming
  ho
me as soon as we get to shores.

I and my husband want to put things in place so you can start immediately we 
arrive from our vacation.We would like to have a brief interview with 
you,answer the following questions.

1)How many years of work experience do you have ?
2) Do you smoke ?
3)Do you do drugs ?
4) What area are you located presently ?
5)Do you have any disability ?

.  .Below is our Offer and 
Requirements.
You\'ll be paid 400.00 weekly If you choose to receive your salaries monthly 
thats 1600 and its okay with us.
1) You must be able to speak English Language..
2)Is your partners in support of this position for you.
3)You must have any references and achievements ?
4)Ever been convicted ?? Doesn\'t matter to me as long as you have realize your 
past mistakes and now a changed person.

I await your prompt response and as soon as i get your response, I will write 
back to let you know if you have the job or not.

Regards.
Mrs.Michelle & Richard Moore


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


Re: [U-Boot] [PATCH] Fix build issues cause by LDFLAGS_FINAL changes

2011-03-31 Thread Haiying Wang
Dear Wolfgang,
On Thu, 2011-03-31 at 16:52 +0200, Wolfgang Denk wrote:
> Commit 6dc1ece "Introduce a new linker flag LDFLAGS_FINAL" modified a
> number of Makefiles in a way that broke out-of-tree builds.  The
> problem was that $(nandobj) was used before it got defined.
What is "out-of-tree builds"? Why did LDFLAGS_FINAL patch break it? the
$(nandobj) was defined in those Makefiles in that way before applying
LDFLAGS_FINAL patch. Why could the out-of-tree builds passed before
applying LDFLAG_FINAL patch?

Thanks.

Haiying



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


[U-Boot] mpq101 board broken

2011-03-31 Thread Wolfgang Denk
Dear Alex,

the mpq101 board support is broken in recent versions of U-Boot:

Configuring for mpq101 board...
ppc_85xxDP-ld: u-boot: section .ppcenv lma 0xfffc overlaps previous sections

Can you please have a look?

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 must follow the people.  Am I not their leader? - Benjamin Disraeli
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] Fix build issues cause by LDFLAGS_FINAL changes

2011-03-31 Thread Wolfgang Denk
Commit 6dc1ece "Introduce a new linker flag LDFLAGS_FINAL" modified a
number of Makefiles in a way that broke out-of-tree builds.  The
problem was that $(nandobj) was used before it got defined.

Fix this.

Signed-off-by: Wolfgang Denk 
---
 nand_spl/board/amcc/acadia/Makefile   |6 +++---
 nand_spl/board/amcc/bamboo/Makefile   |6 +++---
 nand_spl/board/amcc/canyonlands/Makefile  |6 +++---
 nand_spl/board/amcc/kilauea/Makefile  |6 +++---
 nand_spl/board/amcc/sequoia/Makefile  |6 +++---
 nand_spl/board/freescale/mpc8313erdb/Makefile |6 +++---
 nand_spl/board/freescale/mpc8315erdb/Makefile |6 +++---
 nand_spl/board/freescale/mpc8536ds/Makefile   |6 +++---
 nand_spl/board/freescale/mpc8569mds/Makefile  |6 +++---
 nand_spl/board/freescale/mpc8572ds/Makefile   |6 +++---
 nand_spl/board/sheldon/simpc8313/Makefile |6 +++---
 11 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/nand_spl/board/amcc/acadia/Makefile 
b/nand_spl/board/amcc/acadia/Makefile
index f4323d5..84cb8ab 100644
--- a/nand_spl/board/amcc/acadia/Makefile
+++ b/nand_spl/board/amcc/acadia/Makefile
@@ -24,6 +24,8 @@
 include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
+nandobj:= $(OBJTREE)/nand_spl/
+
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
 LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
   $(LDFLAGS_FINAL)
@@ -36,9 +38,7 @@ COBJS = gpio.o nand_boot.o nand_ecc.o memory.o ndfc.o pll.o
 SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
 __OBJS := $(SOBJS) $(COBJS)
-LNDIR  := $(OBJTREE)/nand_spl/board/$(BOARDDIR)
-
-nandobj:= $(OBJTREE)/nand_spl/
+LNDIR  := $(nandobj)board/$(BOARDDIR)
 
 ALL= $(nandobj)u-boot-spl $(nandobj)u-boot-spl.bin 
$(nandobj)u-boot-spl-16k.bin \
$(nandobj)System.map
diff --git a/nand_spl/board/amcc/bamboo/Makefile 
b/nand_spl/board/amcc/bamboo/Makefile
index 15af860..6430219 100644
--- a/nand_spl/board/amcc/bamboo/Makefile
+++ b/nand_spl/board/amcc/bamboo/Makefile
@@ -24,6 +24,8 @@
 include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
+nandobj:= $(OBJTREE)/nand_spl/
+
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
 LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
   $(LDFLAGS_FINAL)
@@ -36,9 +38,7 @@ COBJS = nand_boot.o nand_ecc.o ndfc.o sdram.o
 SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
 __OBJS := $(SOBJS) $(COBJS)
-LNDIR  := $(OBJTREE)/nand_spl/board/$(BOARDDIR)
-
-nandobj:= $(OBJTREE)/nand_spl/
+LNDIR  := $(nandobj)board/$(BOARDDIR)
 
 ALL= $(nandobj)u-boot-spl $(nandobj)u-boot-spl.bin 
$(nandobj)u-boot-spl-16k.bin
 
diff --git a/nand_spl/board/amcc/canyonlands/Makefile 
b/nand_spl/board/amcc/canyonlands/Makefile
index 62c77d8..509a46e 100644
--- a/nand_spl/board/amcc/canyonlands/Makefile
+++ b/nand_spl/board/amcc/canyonlands/Makefile
@@ -24,6 +24,8 @@
 include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
+nandobj:= $(OBJTREE)/nand_spl/
+
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
 LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
   $(LDFLAGS_FINAL)
@@ -41,9 +43,7 @@ COBJS += ndfc.o
 SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
 __OBJS := $(SOBJS) $(COBJS)
-LNDIR  := $(OBJTREE)/nand_spl/board/$(BOARDDIR)
-
-nandobj:= $(OBJTREE)/nand_spl/
+LNDIR  := $(nandobj)board/$(BOARDDIR)
 
 ALL= $(nandobj)u-boot-spl $(nandobj)u-boot-spl.bin 
$(nandobj)u-boot-spl-16k.bin
 
diff --git a/nand_spl/board/amcc/kilauea/Makefile 
b/nand_spl/board/amcc/kilauea/Makefile
index 1053ce3..104b7e2 100644
--- a/nand_spl/board/amcc/kilauea/Makefile
+++ b/nand_spl/board/amcc/kilauea/Makefile
@@ -24,6 +24,8 @@
 include $(TOPDIR)/config.mk
 include $(TOPDIR)/nand_spl/board/$(BOARDDIR)/config.mk
 
+nandobj:= $(OBJTREE)/nand_spl/
+
 LDSCRIPT= $(TOPDIR)/nand_spl/board/$(BOARDDIR)/u-boot.lds
 LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS) \
   $(LDFLAGS_FINAL)
@@ -36,9 +38,7 @@ COBJS = 44x_spd_ddr2.o nand_boot.o nand_ecc.o ndfc.o
 SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
 __OBJS := $(SOBJS) $(COBJS)
-LNDIR  := $(OBJTREE)/nand_spl/board/$(BOARDDIR)
-
-nandobj:= $(OBJTREE)/nand_spl/
+LNDIR  := $(nandobj)board/$(BOARDDIR)
 
 ALL= $(nandobj)u-boot-spl $(nandobj)u-boot-spl.bin 
$(nandobj)u-boot-spl-16k.bin
 
diff --git a/nand_spl/board/amcc/sequoia/Makefile 
b/nand_spl/board/amcc/sequoia/Makefile
index 9516b5c..54e8a12 100644
--- a/nand_spl/board/amcc/sequoia/Makefile
+++ b/nand_spl/board/amcc/sequoia/Makefile
@@ -24,6 +24,8 @@
 include 

Re: [U-Boot] [PATCH 2/7] tsec: arrange the code to avoid useless function declaration

2011-03-31 Thread Fleming Andy-AFLEMING
Ah, I didnt see it was already in next

On Mar 31, 2011, at 3:13, "Kumar Gala"  wrote:

> 
> On Mar 29, 2011, at 2:30 PM, Andy Fleming wrote:
> 
>> From: Mingkai Hu 
>> 
>> Signed-off-by: Mingkai Hu 
>> Acked-by: Andy Fleming 
>> Signed-off-by: Kumar Gala 
>> ---
>> drivers/net/tsec.c |  857 
>> +---
>> 1 files changed, 416 insertions(+), 441 deletions(-)
> 
> I'm concerned this differs from the version in 85xx 'next'
> 
> - k

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


[U-Boot] [PATCH v2] ftsmc020: enhanced features and unnested structures

2011-03-31 Thread Macpaul Lin
1. Enhance ftsmc020 according to datasheets.
2. Fix relocation related declaration.

Signed-off-by: Macpaul Lin 
---
Changes for v2:
  - Remove assembly register offsets for support lowlevel_init.S.
  - The nested structure of register offsets has been rewrote.
  - Fix relocation related declaration.

Note:
  This patch should be applied after patch
  "[U-Boot,v2,4/4] ftsmc020: move ftsmc020 static mem controller to 
driver/mtd"
  (/patch/87862/) is applied.

 drivers/mtd/ftsmc020.c |7 +++
 include/faraday/ftsmc020.h |   19 +--
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/ftsmc020.c b/drivers/mtd/ftsmc020.c
index b027685..ddeb3a4 100644
--- a/drivers/mtd/ftsmc020.c
+++ b/drivers/mtd/ftsmc020.c
@@ -27,12 +27,10 @@ struct ftsmc020_config {
unsigned inttiming;
 };
 
-static struct ftsmc020_config config[] = CONFIG_SYS_FTSMC020_CONFIGS;
-
-static struct ftsmc020 *smc = (struct ftsmc020 *)CONFIG_FTSMC020_BASE;
-
 static void ftsmc020_setup_bank(unsigned int bank, struct ftsmc020_config *cfg)
 {
+   struct ftsmc020 *smc = (struct ftsmc020 *)CONFIG_FTSMC020_BASE;
+
if (bank > 3) {
printf("bank # %u invalid\n", bank);
return;
@@ -44,6 +42,7 @@ static void ftsmc020_setup_bank(unsigned int bank, struct 
ftsmc020_config *cfg)
 
 void ftsmc020_init(void)
 {
+   struct ftsmc020_config config[] = CONFIG_SYS_FTSMC020_CONFIGS;
int i;
 
for (i = 0; i < ARRAY_SIZE(config); i++)
diff --git a/include/faraday/ftsmc020.h b/include/faraday/ftsmc020.h
index 95d9500..59c6f8e 100644
--- a/include/faraday/ftsmc020.h
+++ b/include/faraday/ftsmc020.h
@@ -25,13 +25,15 @@
 
 #ifndef __ASSEMBLY__
 
+struct ftsmc020_bank {
+   unsigned intcr;
+   unsigned inttpr;
+};
+
 struct ftsmc020 {
-   struct {
-   unsigned intcr; /* 0x00, 0x08, 0x10, 0x18 */
-   unsigned inttpr;/* 0x04, 0x0c, 0x14, 0x1c */
-   } bank[4];
-   unsigned intpad[8]; /* 0x20 - 0x3c */
-   unsigned intssr;/* 0x40 */
+   struct ftsmc020_bank bank[4];   /* 0x00 - 0x1c */
+   unsigned intpad[8]; /* 0x20 - 0x3c */
+   unsigned intssr;/* 0x40 */
 };
 
 void ftsmc020_init(void);
@@ -46,6 +48,10 @@ void ftsmc020_init(void);
 
 #define FTSMC020_BANK_WPROT(1 << 11)
 
+#define FTSMC020_BANK_TYPE1(1 << 10)
+#define FTSMC020_BANK_TYPE2(1 << 9)
+#define FTSMC020_BANK_TYPE3(1 << 8)
+
 #define FTSMC020_BANK_SIZE_32K (0xb << 4)
 #define FTSMC020_BANK_SIZE_64K (0xc << 4)
 #define FTSMC020_BANK_SIZE_128K(0xd << 4)
@@ -57,6 +63,7 @@ void ftsmc020_init(void);
 #define FTSMC020_BANK_SIZE_8M  (0x3 << 4)
 #define FTSMC020_BANK_SIZE_16M (0x4 << 4)
 #define FTSMC020_BANK_SIZE_32M (0x5 << 4)
+#define FTSMC020_BANK_SIZE_64M (0x6 << 4)
 
 #define FTSMC020_BANK_MBW_8(0x0 << 0)
 #define FTSMC020_BANK_MBW_16   (0x1 << 0)
-- 
1.7.3.5

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


Re: [U-Boot] [PATCH v2] ftsmc020: enhanced features and unnested structures

2011-03-31 Thread Wolfgang Denk
Dear "Macpaul Lin",

In message <1301570307-13852-1-git-send-email-macp...@andestech.com> you wrote:
> 1. Enhance ftsmc020 according to datasheets.
> 2. Fix relocation related declaration.
> 
> Signed-off-by: Macpaul Lin 
...
> CONFIDENTIALITY NOTICE:
> 
> This e-mail (and its attachments) may contain confidential and legally 
> privileged information or information protected from disclosure. If you 
...

Message ignored as instructed.

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
Due to lack of disk space, this fortune database has been discontinued.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] ftsmc020: enhanced features and unnested structures

2011-03-31 Thread Macpaul Lin
1. Enhance ftsmc020 according to datasheets.
2. Fix relocation related declaration.

Signed-off-by: Macpaul Lin 
---
Changes for v2:
  - Remove assembly register offsets for support lowlevel_init.S.
  - The nested structure of register offsets has been rewrote.
  - Fix relocation related declaration.

Note:
  This patch should be applied after patch
  "[U-Boot,v2,4/4] ftsmc020: move ftsmc020 static mem controller to
driver/mtd"
  (/patch/87862/) is applied.

 drivers/mtd/ftsmc020.c |7 +++
 include/faraday/ftsmc020.h |   19 +--
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/ftsmc020.c b/drivers/mtd/ftsmc020.c
index b027685..ddeb3a4 100644
--- a/drivers/mtd/ftsmc020.c
+++ b/drivers/mtd/ftsmc020.c
@@ -27,12 +27,10 @@ struct ftsmc020_config {
unsigned inttiming;
 };

-static struct ftsmc020_config config[] = CONFIG_SYS_FTSMC020_CONFIGS;
-
-static struct ftsmc020 *smc = (struct ftsmc020 *)CONFIG_FTSMC020_BASE;
-
 static void ftsmc020_setup_bank(unsigned int bank, struct ftsmc020_config 
*cfg)
 {
+   struct ftsmc020 *smc = (struct ftsmc020 *)CONFIG_FTSMC020_BASE;
+
if (bank > 3) {
printf("bank # %u invalid\n", bank);
return;
@@ -44,6 +42,7 @@ static void ftsmc020_setup_bank(unsigned int bank, 
struct ftsmc020_config *cfg)

 void ftsmc020_init(void)
 {
+   struct ftsmc020_config config[] = CONFIG_SYS_FTSMC020_CONFIGS;
int i;

for (i = 0; i < ARRAY_SIZE(config); i++)
diff --git a/include/faraday/ftsmc020.h b/include/faraday/ftsmc020.h
index 95d9500..59c6f8e 100644
--- a/include/faraday/ftsmc020.h
+++ b/include/faraday/ftsmc020.h
@@ -25,13 +25,15 @@

 #ifndef __ASSEMBLY__

+struct ftsmc020_bank {
+   unsigned intcr;
+   unsigned inttpr;
+};
+
 struct ftsmc020 {
-   struct {
-   unsigned intcr; /* 0x00, 0x08, 0x10, 0x18 */
-   unsigned inttpr;/* 0x04, 0x0c, 0x14, 0x1c */
-   } bank[4];
-   unsigned intpad[8]; /* 0x20 - 0x3c */
-   unsigned intssr;/* 0x40 */
+   struct ftsmc020_bank bank[4];   /* 0x00 - 0x1c */
+   unsigned intpad[8]; /* 0x20 - 0x3c */
+   unsigned intssr;/* 0x40 */
 };

 void ftsmc020_init(void);
@@ -46,6 +48,10 @@ void ftsmc020_init(void);

 #define FTSMC020_BANK_WPROT(1 << 11)

+#define FTSMC020_BANK_TYPE1(1 << 10)
+#define FTSMC020_BANK_TYPE2(1 << 9)
+#define FTSMC020_BANK_TYPE3(1 << 8)
+
 #define FTSMC020_BANK_SIZE_32K (0xb << 4)
 #define FTSMC020_BANK_SIZE_64K (0xc << 4)
 #define FTSMC020_BANK_SIZE_128K(0xd << 4)
@@ -57,6 +63,7 @@ void ftsmc020_init(void);
 #define FTSMC020_BANK_SIZE_8M  (0x3 << 4)
 #define FTSMC020_BANK_SIZE_16M (0x4 << 4)
 #define FTSMC020_BANK_SIZE_32M (0x5 << 4)
+#define FTSMC020_BANK_SIZE_64M (0x6 << 4)

 #define FTSMC020_BANK_MBW_8(0x0 << 0)
 #define FTSMC020_BANK_MBW_16   (0x1 << 0)
-- 
1.7.3.5



CONFIDENTIALITY NOTICE:

This e-mail (and its attachments) may contain confidential and legally 
privileged information or information protected from disclosure. If you 
are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution, or use of the information contained 
herein is strictly prohibited. In this case, please immediately notify the 
sender by return e-mail, delete the message (and any accompanying 
documents) and destroy all printed hard copies. Thank you for your 
cooperation.

Copyright ANDES TECHNOLOGY CORPORATION - All Rights Reserved.

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


Re: [U-Boot] Build issues with a number of 83xx boards

2011-03-31 Thread Wolfgang Denk
Hi all,

In message <20110331091915.d9b19edf...@gemini.denx.de> I wrote:
> 
> are you aware that a number of 83xx boards don't build any more?
> I see errors like these:
> 
> Configuring for MPC8313ERDB_NAND_33 - Board: MPC8313ERDB, Options: 
> SYS_33MHZ,NAND_U_BOOT
> ppc_6xx-ld: cannot open linker script file u-boot.lds: No such file or
> directory
> make[1]: *** [/work/wd/tmp-ppc/nand_spl/u-boot-spl] Error 1

The culprit is this commit:

6dc1eceb9c5f42216f1ba0e0ef538015b0aa10bc is the first bad
commit
commit 6dc1eceb9c5f42216f1ba0e0ef538015b0aa10bc
Author: Haiying Wang 
Date:   Tue Feb 22 16:38:05 2011 -0500

Introduce a new linker flag LDFLAGS_FINAL

It appears this has never been tested with out-of-tree builds!



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
"When anyone says `theoretically,' they really mean `not really.'"
- David Parnas
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] how does Linux call the function from u-boot?

2011-03-31 Thread Wolfgang Denk
Dear "sywang",

In message  you wrote:
> 
> how does Linux call the function from u-boot?

Simply: it does not.

When Linux starts running, U-Boot is gone and dead; nothing of it
survives the boot of Linux except for the parameters passed to the
Linux kernel.

Linux has no idea which boot loader has been used to start it, nor
can Linux call any functions from the boot loader.

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
Punishment becomes ineffective after a certain point. Men become  in-
sensitive.
-- Eneg, "Patterns of Force", stardate 2534.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] how does Linux call the function from u-boot?

2011-03-31 Thread sywang



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


[U-Boot] Build issues with a number of 83xx boards

2011-03-31 Thread Wolfgang Denk
Dear Kim & Kumar,

are you aware that a number of 83xx boards don't build any more?
I see errors like these:

Configuring for MPC8313ERDB_NAND_33 - Board: MPC8313ERDB, Options: 
SYS_33MHZ,NAND_U_BOOT
ppc_6xx-ld: cannot open linker script file u-boot.lds: No such file or
directory
make[1]: *** [/work/wd/tmp-ppc/nand_spl/u-boot-spl] Error 1


Best regards,

Wolfgang Denk

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


[U-Boot] [PATCH 1/2] ARMV7: Adding support for Samsung SMDKV310 Board

2011-03-31 Thread Chander Kashyap
SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much
similar to S5PC210.

Signed-off-by: Chander Kashyap 
Signed-off-by: Tushar Behera 
---
 board/samsung/smdkv310/Makefile|   46 +++
 board/samsung/smdkv310/config.mk   |1 +
 board/samsung/smdkv310/lowlevel_init.S |  549 +++
 board/samsung/smdkv310/mem_setup.S |  632 
 board/samsung/smdkv310/smdkv310.c  |  138 +++
 boards.cfg |1 +
 include/configs/smdkv310.h |  199 ++
 7 files changed, 1566 insertions(+), 0 deletions(-)
 create mode 100644 board/samsung/smdkv310/Makefile
 create mode 100644 board/samsung/smdkv310/config.mk
 create mode 100644 board/samsung/smdkv310/lowlevel_init.S
 create mode 100644 board/samsung/smdkv310/mem_setup.S
 create mode 100644 board/samsung/smdkv310/smdkv310.c
 create mode 100644 include/configs/smdkv310.h

diff --git a/board/samsung/smdkv310/Makefile b/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..8e9b703
--- /dev/null
+++ b/board/samsung/smdkv310/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2011 Samsung Electronics
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+SOBJS  := mem_setup.o
+SOBJS  += lowlevel_init.o
+COBJS  += smdkv310.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+all:$(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/smdkv310/config.mk b/board/samsung/smdkv310/config.mk
new file mode 100644
index 000..19b9e2f
--- /dev/null
+++ b/board/samsung/smdkv310/config.mk
@@ -0,0 +1 @@
+CONFIG_SYS_TEXT_BASE = 0x43e0
diff --git a/board/samsung/smdkv310/lowlevel_init.S 
b/board/samsung/smdkv310/lowlevel_init.S
new file mode 100644
index 000..ead12b2
--- /dev/null
+++ b/board/samsung/smdkv310/lowlevel_init.S
@@ -0,0 +1,549 @@
+/*
+ * Lowlevel setup for SMDKV310 board based on S5PC210
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+#define MEM_DLLl_ON
+
+
+_TEXT_BASE:
+   .word   CONFIG_SYS_TEXT_BASE
+
+   .globl lowlevel_init
+lowlevel_init:
+   push{lr}
+
+
+   /* r5 has always zero */
+   mov r5, #0
+
+   ldr r7, =S5PC210_GPIO_PART1_BASE
+   ldr r6, =S5PC210_GPIO_PART2_BASE
+
+   /* check reset status  */
+   ldr r0, =(S5PC210_POWER_BASE + 0x81C)   @ INFORM7
+ldr r1, [r0]
+
+   /* AFTR wakeup reset */
+   ldr r2, =S5P_CHECK_DIDLE
+   cmp r1, r2
+   beq exit_wakeup
+
+   /* Sleep wakeup reset */
+   ldr r2, =S5P_CHECK_SLEEP
+   cmp r1, r2
+   beq wakeup_reset
+
+   /* when we already run in ram, we don't need to relocate U-Boot.
+* and actually, memory controller must be configured before U-Boot
+* is running in ram.
+*/
+   ldr r0, =0x00ff /* r0 <- M

[U-Boot] [PATCH 2/2] ARMV7: MMC SPL Boot support for SMDKV310 board

2011-03-31 Thread Chander Kashyap
Added MMC SPL boot support for SMDKV310. This framework design is
based on nand_spl support.

Signed-off-by: Chander Kashyap 
---
 Makefile|   11 ++-
 spl/board/samsung/smdkv310/Makefile |  104 +++
 spl/board/samsung/smdkv310/mmc_boot.c   |   82 ++
 spl/board/samsung/smdkv310/tools/mkv310_image.c |  103 ++
 spl/board/samsung/smdkv310/u-boot.lds   |   86 +++
 5 files changed, 385 insertions(+), 1 deletions(-)
 create mode 100644 spl/board/samsung/smdkv310/Makefile
 create mode 100644 spl/board/samsung/smdkv310/mmc_boot.c
 create mode 100644 spl/board/samsung/smdkv310/tools/mkv310_image.c
 create mode 100644 spl/board/samsung/smdkv310/u-boot.lds

diff --git a/Makefile b/Makefile
index c42432b..0fe8286 100644
--- a/Makefile
+++ b/Makefile
@@ -299,6 +299,10 @@ U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
 ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
 endif

+ifeq ($(CONFIG_MMC_U_BOOT),y)
+MMC_SPL = spl
+V310_MMC_SPL_BIN = $(obj)spl/v310_mmc_spl.bin
+endif
 __OBJS := $(subst $(obj),,$(OBJS))
 __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD))

@@ -321,7 +325,7 @@ BOARD_SIZE_CHECK =
 endif

 # Always append ALL so that arch config.mk's can add custom ones
-ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_NAND) 
$(U_BOOT_ONENAND)
+ALL += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map $(U_BOOT_NAND) 
$(U_BOOT_ONENAND) $(V310_MMC_SPL_BIN)

 all:   $(ALL)

@@ -414,6 +418,11 @@ $(ONENAND_IPL):$(TIMESTAMP_FILE) $(VERSION_FILE) 
$(obj)include/autoconf.mk
 $(U_BOOT_ONENAND): $(ONENAND_IPL) $(obj)u-boot.bin
cat $(ONENAND_BIN) $(obj)u-boot.bin > $(obj)u-boot-onenand.bin

+$(MMC_SPL):$(TIMESTAMP_FILE) $(VERSION_FILE) depend
+   $(MAKE) -C $(MMC_SPL)/board/$(BOARDDIR) all
+
+$(V310_MMC_SPL_BIN):   $(MMC_SPL)
+
 $(VERSION_FILE):
@( printf '#define U_BOOT_VERSION "U-Boot %s%s"\n' 
"$(U_BOOT_VERSION)" \
 '$(shell $(TOPDIR)/tools/setlocalversion $(TOPDIR))' ) > $@.tmp
diff --git a/spl/board/samsung/smdkv310/Makefile 
b/spl/board/samsung/smdkv310/Makefile
new file mode 100644
index 000..42ef926
--- /dev/null
+++ b/spl/board/samsung/smdkv310/Makefile
@@ -0,0 +1,104 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, s...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, 
+#
+# (C) Copyright 2011
+# Chander Kashyap, Samsung Electronics, 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+CONFIG_MMC_SPL = y
+
+include $(TOPDIR)/config.mk
+include $(TOPDIR)/board/$(BOARDDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS= -Bstatic -T $(mmcobj)u-boot.lds -Ttext 
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_MMC_SPL
+
+SOBJS  = start.o mem_setup.o lowlevel_init.o
+COBJS  = mmc_boot.o
+
+SRCS   := $(addprefix $(obj),$(SOBJS:.o=.S) $(COBJS:.o=.c))
+OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR  := $(OBJTREE)/spl/board/$(BOARDDIR)
+
+mmcobj := $(OBJTREE)/spl/
+
+
+MKBIN_V310_MMC_SPL_BIN = mkv310_mmc_spl_bin
+MMC_SPL_BIN = v310_mmc_spl.bin
+
+ALL = $(mmcobj)u-boot-spl $(mmcobj)u-boot-spl.bin $(mmcobj)$(MMC_SPL_BIN)
+
+all:$(obj).depend $(ALL)
+
+$(mmcobj)$(MMC_SPL_BIN):  $(mmcobj)u-boot-spl.bin 
tools/$(MKBIN_V310_MMC_SPL_BIN)
+   ./tools/$(MKBIN_V310_MMC_SPL_BIN) $(mmcobj)u-boot-spl.bin 
$(mmcobj)$(MMC_SPL_BIN)
+
+tools/$(MKBIN_V310_MMC_SPL_BIN): tools/mkv310_image.c
+   $(HOSTCC) tools/mkv310_image.c -o tools/$(MKBIN_V310_MMC_SPL_BIN)
+
+$(mmcobj)u-boot-spl.bin:   $(mmcobj)u-boot-spl
+   $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@
+
+$(mmcobj)u-boot-spl:   $(OBJS) $(mmcobj)u-boot.lds
+   cd $(LNDIR) && $(LD) $(LDFLAGS) $(__OBJS) \
+   -Map $(mmcobj)u-boot-spl.map \
+   -o $(mmcobj)u-boot-spl
+
+$(mmcobj)u-boot.lds: $(LDSCRIPT)
+   $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - <$^ >$@
+
+# create symbolic links for common files
+
+# from cpu directory
+$(obj)start.S:
+   @rm -f $@
+   @ln -s $(TOPD

[U-Boot] [PATCH 0/2] SMDKV310 Board support

2011-03-31 Thread Chander Kashyap
Hi,
This patchset adds support for a new board SMDKV310, based on S5PV310 SOC.
This SOC is very similar to S5PC210 SOC, hence we are re-using this SOC code.

Chander Kashyap (2):
  ARMV7: Adding support for Samsung SMDKV310 Board
  ARMV7: MMC SPL Boot support for SMDKV310 board

 Makefile|   11 +-
 board/samsung/smdkv310/Makefile |   46 ++
 board/samsung/smdkv310/config.mk|1 +
 board/samsung/smdkv310/lowlevel_init.S  |  549 
 board/samsung/smdkv310/mem_setup.S  |  632 +++
 board/samsung/smdkv310/smdkv310.c   |  138 +
 boards.cfg  |1 +
 include/configs/smdkv310.h  |  199 +++
 spl/board/samsung/smdkv310/Makefile |  104 
 spl/board/samsung/smdkv310/mmc_boot.c   |   82 +++
 spl/board/samsung/smdkv310/tools/mkv310_image.c |  103 
 spl/board/samsung/smdkv310/u-boot.lds   |   86 +++
 12 files changed, 1951 insertions(+), 1 deletions(-)
 create mode 100644 board/samsung/smdkv310/Makefile
 create mode 100644 board/samsung/smdkv310/config.mk
 create mode 100644 board/samsung/smdkv310/lowlevel_init.S
 create mode 100644 board/samsung/smdkv310/mem_setup.S
 create mode 100644 board/samsung/smdkv310/smdkv310.c
 create mode 100644 include/configs/smdkv310.h
 create mode 100644 spl/board/samsung/smdkv310/Makefile
 create mode 100644 spl/board/samsung/smdkv310/mmc_boot.c
 create mode 100644 spl/board/samsung/smdkv310/tools/mkv310_image.c
 create mode 100644 spl/board/samsung/smdkv310/u-boot.lds

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


Re: [U-Boot] [PATCH] ftsmc020: enhance for features and asm support.

2011-03-31 Thread Wolfgang Denk
Dear Macpaul Lin,

Please keep the mailing list on Cc: (re-added)

In message  you 
wrote:
> 
> > I repeat again: I consider this manual unrolling of the nested structs
> > a Bad Thing.  You should have separate offsets for each of the nested
> > structs.
> 
> The above code is really a rework for a nested structs.
> The origin code looks like,
>  Moreover, the structure of ftsmc020 was nested like
>  struct ftsmc020 {
>  struct {
>  unsigned intcr; /* 0x00, 0x08, 0x10, 0x18 */
>  unsigned inttpr;/* 0x04, 0x0c, 0x14, 0x1c */
>  } bank[4];
>  unsigned intpad[8]; /* 0x20 - 0x3c */
>  unsigned intssr;/* 0x40 */
>  }
> 
> After rewrote it becomes
>  struct ftsmc020 {
>  unsigned int bank0_cr;
>  unsigned int bank0_tpr;
>  unsigned int bank1_cr;
>  unsigned int bank1_tpr;
>  unsigned int bank2_cr;
>  unsigned int bank2_tpr;
>  unsigned int bank3_cr;
>  unsigned int bank3_tpr;
>  unsigned int pad[8];
>  unsigned int ssr;
>  }
> 
> Did I misunderstand what you exactly meant?

Yes, indeed. Unnesting means to move the inner struct declaration
outside, like that:

struct ftsmc020_bank {
unsigned intcr;
unsigned inttpr;
};

struct ftsmc020 {
struct ftsmc020_bank bank[4];
unsigned intpad[8];
unsigned intssr;
};

> > Again: if you need larger numbers of such entries you are doing
> > something fundamentally wrong.  Reconsider your coding style.  What
> > exactly enforces you to use assembly?

> This is because writing assembly code (lowlevel_init) is really a
> necessity for setting the timing
> and power outpur correctly to these registers (SMC, SDMC, PMU).

What exactly prevents you from writing the very same code in C?

> It is required to give a correct setting to PMU and SMC to make the
> onboard DRAM works correctly
> before the code is loaded from ROM to DRAM and then set up stack for C
> environemnt.

We take care to provide global data and an initial stack very, very
early in the initialization sequence.  You canuse C code long before
you can access the system RAM.

> Hence assembly code to setting SMC and PMU in lowlevel_init is a necessity

I seriously doubt that.  Just because many boards are writen that way
does not mean that's how it must be done - actualy many just copied
existing bad examples without thinking.

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 man on tops walks a lonely street;  the  "chain"  of  command  is
often a noose.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v7 1/4] mpc8xxx: DDR2/DDR3: Clean up DIMM-type switch statements

2011-03-31 Thread Kumar Gala

On Mar 28, 2011, at 10:35 AM, Kyle Moffett wrote:

> The numeric constants in the switch statements are replaced by #defines
> added to the common ddr_spd.h header.  This dramatically improves the
> readability of the switch statments.
> 
> In addition, a few of the longer lines were cleaned up, and the DDR2
> type for an SO-RDIMM module was added to the DDR2 switch statement.
> 
> Signed-off-by: Kyle Moffett 
> Cc: Andy Fleming 
> Cc: Kumar Gala 
> Cc: Kim Phillips 
> 
> --
> Changelog:
> v2: Moved the constants to include/ddr_spd.h and also fixed DDR3
> v4: Fixed up excessively long lines
> v6: Rebased onto the 'next' branch of git://git.denx.de/u-boot-mpc85xx.git
> 
> arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c |   23 +++-
> arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |   43 ++
> common/ddr_spd.c|2 +-
> include/ddr_spd.h   |   28 ++-
> 4 files changed, 53 insertions(+), 43 deletions(-)

applied to 85xx next

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


[U-Boot] [PATCH 2/2] p4080ds: remove rev1-specific code for the SERDES8 erratum

2011-03-31 Thread Kumar Gala
From: Timur Tabi 

Remove the SERDES8 erratum work-around code that only applied to P4080 rev1,
which is not supported by this version of U-Boot.

Signed-off-by: Timur Tabi 
Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |  106 +++--
 1 files changed, 47 insertions(+), 59 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c 
b/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
index 7fc00d8..f58d6d6 100644
--- a/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
@@ -109,10 +109,13 @@ int serdes_lane_enabled(int lane)
return 0;
 
 #ifdef CONFIG_SYS_P4080_ERRATUM_SERDES8
-   if (!IS_SVR_REV(get_svr(), 1, 0))
-   if (bank > 0)
-   return !(srds_lpd_b[bank] &
-   (8 >> (lane - (6 + 4 * bank;
+   /*
+* For banks two and three, use the srds_lpd_b[] array instead of the
+* RCW, because this array contains the real values of SRDS_LPD_B2 and
+* SRDS_LPD_B3.
+*/
+   if (bank > 0)
+   return !(srds_lpd_b[bank] & (8 >> (lane - (6 + 4 * bank;
 #endif
 
return !(in_be32(&gur->rcwsr[word]) & (0x8000 >> bit));
@@ -303,15 +306,19 @@ void fsl_serdes_init(void)
}
 
 #ifdef CONFIG_SYS_P4080_ERRATUM_SERDES8
-   if (!IS_SVR_REV(get_svr(), 1, 0))
-   for (bank = 1; bank < ARRAY_SIZE(srds_lpd_b); bank++) {
-   sprintf(srds_lpd_opt, "fsl_srds_lpd_b%u", bank + 1);
-   srds_lpd_arg = hwconfig_subarg_f("serdes", srds_lpd_opt,
-  &arglen, buf);
-   if (srds_lpd_arg)
-   srds_lpd_b[bank] = simple_strtoul(srds_lpd_arg,
- NULL, 0);
-   }
+   /*
+* Store the values of the fsl_srds_lpd_b2 and fsl_srds_lpd_b3
+* hwconfig options into the srds_lpd_b[] array.  See README.p4080ds
+* for a description of these options.
+*/
+   for (bank = 1; bank < ARRAY_SIZE(srds_lpd_b); bank++) {
+   sprintf(srds_lpd_opt, "fsl_srds_lpd_b%u", bank + 1);
+   srds_lpd_arg =
+   hwconfig_subarg_f("serdes", srds_lpd_opt, &arglen, buf);
+   if (srds_lpd_arg)
+   srds_lpd_b[bank] =
+   simple_strtoul(srds_lpd_arg, NULL, 0) & 0xf;
+   }
 #endif
 
/* Look for banks with all lanes disabled, and power down the bank. */
@@ -324,32 +331,12 @@ void fsl_serdes_init(void)
}
 
 #ifdef CONFIG_SYS_P4080_ERRATUM_SERDES8
-   if (IS_SVR_REV(get_svr(), 1, 0)) {
-   /* At least one bank must be disabled due to SERDES8.  If
-* no bank is found to be disabled based on lane
-* disables, disable bank 3 because we can't turn off its
-* lanes in the RCW without disabling MDIO due to erratum
-* GEN8.
-*
-* This means that if you are relying on bank 3 being
-* disabled to avoid SERDES8, in some cases you cannot
-* also disable all lanes of another bank, or else bank
-* 3 won't be disabled, leaving you with a configuration
-* that isn't valid according to SERDES8 (e.g. if banks
-* 2 and 3 have the same clock, and bank 1 is disabled
-* instead of 3).
-*/
-   for (bank = 0; bank < SRDS_MAX_BANK; bank++) {
-   if (!have_bank[bank])
-   break;
-   }
-
-   if (bank == SRDS_MAX_BANK)
-   have_bank[FSL_SRDS_BANK_3] = 0;
-   } else {
-   if (have_bank[FSL_SRDS_BANK_2])
-   have_bank[FSL_SRDS_BANK_3] = 1;
-   }
+   /*
+* Bank two uses the clock from bank three, so if bank two is enabled,
+* then bank three must also be enabled.
+*/
+   if (have_bank[FSL_SRDS_BANK_2])
+   have_bank[FSL_SRDS_BANK_3] = 1;
 #endif
 
for (bank = 0; bank < SRDS_MAX_BANK; bank++) {
@@ -455,19 +442,16 @@ void fsl_serdes_init(void)
bank = idx;
 
 #ifdef CONFIG_SYS_P4080_ERRATUM_SERDES8
-   if (!IS_SVR_REV(get_svr(), 1, 0)) {
-   /*
-* Change bank init order to 0, 2, 1, so that the
-* third bank's PLL is established before we
-* start the second bank which shares the third
-* bank's PLL.
-*/
+   /*
+* Change bank init order to 0, 2, 1, so that the third bank's
+* PLL is established before we start the second bank.  The
+* secon

[U-Boot] [PATCH 1/2] p4080ds: add README.p4080ds which documents the "serdes" hwconfig option

2011-03-31 Thread Kumar Gala
From: Timur Tabi 

Add documentation for the "serdes" hwconfig option, which is used to specify
the status of SerDes banks two and three for the SERDES8 erratum work-around.

Signed-off-by: Timur Tabi 
Signed-off-by: Kumar Gala 
---
 doc/README.p4080ds |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)
 create mode 100644 doc/README.p4080ds

diff --git a/doc/README.p4080ds b/doc/README.p4080ds
new file mode 100644
index 000..3ed59a8
--- /dev/null
+++ b/doc/README.p4080ds
@@ -0,0 +1,32 @@
+Overview
+
+The P4080DS is a Freescale reference board that hosts the eight-core P4080 SOC.
+
+SerDes hwconfig configuration
+-
+The P4080 RCW includes three sets of bits the specify which SerDes lanes
+should be powered down: SRDS_LPD_B1 (for bank one), SRDS_LPD_B2 (for bank two),
+and SRDS_LPD_B3 (for bank three).  Each of these contains four bits, one for
+each lane in the bank.  SerDes Erratum SERDES8 requires that SRDS_LPD_B2 and
+SRDS_LPD_B3 be set to 0b.  This forces banks two and three to be powered
+down at reset.
+
+To re-enable these banks in U-Boot, two hwconfig are available:
+"fsl_srds_lpd_b2" and "fsl_srds_lpd_b3".  The value passed via fsl_srds_lpd_b2
+is written into SRDS_LPD_B2, and the value passed via fsl_srds_lpd_b3 is into
+SRDS_LPD_B3.  Each bit represents one of each bank, and a value of '1'
+indicates that the lane should be powered down.
+
+For example, to indicate that both SerDes banks 2 and 3 are powered down, add
+the following to hwconfig:
+
+   serdes:fsl_srds_lpd_b2=0xf,fsl_srds_lpd_b3=0xf
+
+The "0xf" is a mask that corresponds to the 4 lanes A-D. The most significant
+bit corresponds to lane A.  To indicate that just lane A of bank 3 is to be
+powered down, use:
+
+   serdes:fsl_srds_lpd_b3=8
+
+These options should be specified only if U-Boot does not automatically power
+on the correct lanes.
-- 
1.7.3.4

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


[U-Boot] [PATCH] powerpc/8xxx: Fix typo for address hashing message

2011-03-31 Thread Kumar Gala
Signed-off-by: Kumar Gala 
---
 arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c 
b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
index ee7ef0f..02d069c 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
@@ -1305,7 +1305,7 @@ static void set_ddr_eor(fsl_ddr_cfg_regs_t *ddr, const 
memctl_options_t *popts)
 {
if (popts->addr_hash) {
ddr->ddr_eor = 0x4000;  /* address hash enable */
-   puts("Addess hashing enabled.\n");
+   puts("Address hashing enabled.\n");
}
 }
 
-- 
1.7.3.4

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


[U-Boot] [PATCH V6 5/5] I2C: add i2c support for Armada100 platform

2011-03-31 Thread Lei Wen
Add i2c support to aspenite board with Armada100 soc.

Signed-off-by: Lei Wen 
---
Changelog:
V2:
NO CHANGE

V3:
clean code style issue

V4:
V5:
NO CHANGE

V6:
Move the CONFIG_CMD_I2C define place

 arch/arm/cpu/arm926ejs/armada100/cpu.c|   16 +++
 arch/arm/include/asm/arch-armada100/mfp.h |   40 -
 board/Marvell/aspenite/aspenite.c |5 +++
 include/configs/aspenite.h|   14 ++
 4 files changed, 57 insertions(+), 18 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c 
b/arch/arm/cpu/arm926ejs/armada100/cpu.c
index 62aa175..c21938e 100644
--- a/arch/arm/cpu/arm926ejs/armada100/cpu.c
+++ b/arch/arm/cpu/arm926ejs/armada100/cpu.c
@@ -62,6 +62,16 @@ int arch_cpu_init(void)
/* Enable GPIO clock */
writel(APBC_APBCLK, &apb1clkres->gpio);
 
+#ifdef CONFIG_I2C_MV
+   /* Enable general I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi0);
+   writel(APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi0);
+
+   /* Enable power I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi1);
+   writel(APBC_FNCLK | APBC_APBCLK, &apb1clkres->twsi1);
+#endif
+
/*
 * Enable Functional and APB clock at 14.7456MHz
 * for configured UART console
@@ -90,3 +100,9 @@ int print_cpuinfo(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_I2C_MV
+void i2c_clk_enable(void)
+{
+}
+#endif
diff --git a/arch/arm/include/asm/arch-armada100/mfp.h 
b/arch/arm/include/asm/arch-armada100/mfp.h
index d21a79f..73783a7 100644
--- a/arch/arm/include/asm/arch-armada100/mfp.h
+++ b/arch/arm/include/asm/arch-armada100/mfp.h
@@ -37,28 +37,32 @@
  * offset, pull,pF, drv,dF, edge,eF ,afn,aF
  */
 /* UART1 */
-#define MFP107_UART1_TXD   MFP_REG(0x01ac) | MFP_AF1 | MFP_DRIVE_FAST
-#define MFP107_UART1_RXD   MFP_REG(0x01ac) | MFP_AF2 | MFP_DRIVE_FAST
-#define MFP108_UART1_RXD   MFP_REG(0x01b0) | MFP_AF1 | MFP_DRIVE_FAST
-#define MFP108_UART1_TXD   MFP_REG(0x01b0) | MFP_AF2 | MFP_DRIVE_FAST
-#define MFP109_UART1_CTS   MFP_REG(0x01b4) | MFP_AF1 | MFP_DRIVE_MEDIUM
-#define MFP109_UART1_RTS   MFP_REG(0x01b4) | MFP_AF2 | MFP_DRIVE_MEDIUM
-#define MFP110_UART1_RTS   MFP_REG(0x01b8) | MFP_AF1 | MFP_DRIVE_MEDIUM
-#define MFP110_UART1_CTS   MFP_REG(0x01b8) | MFP_AF2 | MFP_DRIVE_MEDIUM
-#define MFP111_UART1_RIMFP_REG(0x01bc) | MFP_AF1 | 
MFP_DRIVE_MEDIUM
-#define MFP111_UART1_DSR   MFP_REG(0x01bc) | MFP_AF2 | MFP_DRIVE_MEDIUM
-#define MFP112_UART1_DTR   MFP_REG(0x01c0) | MFP_AF1 | MFP_DRIVE_MEDIUM
-#define MFP112_UART1_DCD   MFP_REG(0x01c0) | MFP_AF2 | MFP_DRIVE_MEDIUM
+#define MFP107_UART1_TXD   (MFP_REG(0x01ac) | MFP_AF1 | MFP_DRIVE_FAST)
+#define MFP107_UART1_RXD   (MFP_REG(0x01ac) | MFP_AF2 | MFP_DRIVE_FAST)
+#define MFP108_UART1_RXD   (MFP_REG(0x01b0) | MFP_AF1 | MFP_DRIVE_FAST)
+#define MFP108_UART1_TXD   (MFP_REG(0x01b0) | MFP_AF2 | MFP_DRIVE_FAST)
+#define MFP109_UART1_CTS   (MFP_REG(0x01b4) | MFP_AF1 | MFP_DRIVE_MEDIUM)
+#define MFP109_UART1_RTS   (MFP_REG(0x01b4) | MFP_AF2 | MFP_DRIVE_MEDIUM)
+#define MFP110_UART1_RTS   (MFP_REG(0x01b8) | MFP_AF1 | MFP_DRIVE_MEDIUM)
+#define MFP110_UART1_CTS   (MFP_REG(0x01b8) | MFP_AF2 | MFP_DRIVE_MEDIUM)
+#define MFP111_UART1_RI(MFP_REG(0x01bc) | MFP_AF1 | 
MFP_DRIVE_MEDIUM)
+#define MFP111_UART1_DSR   (MFP_REG(0x01bc) | MFP_AF2 | MFP_DRIVE_MEDIUM)
+#define MFP112_UART1_DTR   (MFP_REG(0x01c0) | MFP_AF1 | MFP_DRIVE_MEDIUM)
+#define MFP112_UART1_DCD   (MFP_REG(0x01c0) | MFP_AF2 | MFP_DRIVE_MEDIUM)
 
 /* UART2 */
-#define MFP47_UART2_RXDMFP_REG(0x0028) | MFP_AF6 | 
MFP_DRIVE_MEDIUM
-#define MFP48_UART2_TXDMFP_REG(0x002c) | MFP_AF6 | 
MFP_DRIVE_MEDIUM
-#define MFP88_UART2_RXDMFP_REG(0x0160) | MFP_AF2 | 
MFP_DRIVE_MEDIUM
-#define MFP89_UART2_TXDMFP_REG(0x0164) | MFP_AF2 | 
MFP_DRIVE_MEDIUM
+#define MFP47_UART2_RXD(MFP_REG(0x0028) | MFP_AF6 | 
MFP_DRIVE_MEDIUM)
+#define MFP48_UART2_TXD(MFP_REG(0x002c) | MFP_AF6 | 
MFP_DRIVE_MEDIUM)
+#define MFP88_UART2_RXD(MFP_REG(0x0160) | MFP_AF2 | 
MFP_DRIVE_MEDIUM)
+#define MFP89_UART2_TXD(MFP_REG(0x0164) | MFP_AF2 | 
MFP_DRIVE_MEDIUM)
 
 /* UART3 */
-#define MFPO8_UART3_RXDMFP_REG(0x06c) | MFP_AF2 | 
MFP_DRIVE_MEDIUM
-#define MFPO9_UART3_TXDMFP_REG(0x070) | MFP_AF2 | 
MFP_DRIVE_MEDIUM
+#define MFPO8_UART3_RXD(MFP_REG(0x06c) | MFP_AF2 | 
MFP_DRIVE_MEDIUM)
+#define MFPO9_UART3_TXD(MFP_REG(0x070) | MFP_AF2 | 
MFP_DRIVE_MEDIUM)
+
+/* I2c */
+#define MFP105_CI2C_SDA(MFP_REG(0x1a4) | MFP_AF1 | 
MFP_DRIVE_MEDIUM)
+#define MFP106_CI2C_SCL(MFP_REG(0x1a8) | MFP_AF1 | 
MFP_DRIVE_MEDIUM)
 
 /* More macros can be defined here... */
 
diff --git

[U-Boot] [PATCH V6 4/5] I2C: mv_i2c: add multi bus support

2011-03-31 Thread Lei Wen
Add the ability to support multiple i2c bus for mv_i2c

Signed-off-by: Lei Wen 
---
Changelog:
V2:
NO CHANGE

V3:
clean code style issue

V4:
V5:
V6:
NO CHANGE

 drivers/i2c/mv_i2c.c |   36 +++-
 1 files changed, 35 insertions(+), 1 deletions(-)

diff --git a/drivers/i2c/mv_i2c.c b/drivers/i2c/mv_i2c.c
index 3f145de..3a3f7d7 100644
--- a/drivers/i2c/mv_i2c.c
+++ b/drivers/i2c/mv_i2c.c
@@ -66,7 +66,35 @@ struct pxa_i2c {
u32 isar;
 };
 
-static struct pxa_i2c *base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
+static struct pxa_i2c *base;
+#ifdef CONFIG_I2C_MULTI_BUS
+static u32 i2c_regs[CONFIG_PXA_I2C_NUM] = CONFIG_PXA_I2C_REG;
+static unsigned int bus_initialized[CONFIG_PXA_I2C_NUM];
+static unsigned int current_bus;
+
+int i2c_set_bus_num(unsigned int bus)
+{
+   if ((bus < 0) || (bus >= CONFIG_PXA_I2C_NUM)) {
+   printf("Bad bus: %d\n", bus);
+   return -1;
+   }
+
+   base = (struct pxa_i2c *)i2c_regs[bus];
+   current_bus = bus;
+
+   if (!bus_initialized[current_bus]) {
+   i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+   bus_initialized[current_bus] = 1;
+   }
+
+   return 0;
+}
+
+unsigned int i2c_get_bus_num(void)
+{
+   return current_bus;
+}
+#endif
 
 /*
  * i2c_pxa_reset: - reset the host controller
@@ -235,6 +263,12 @@ i2c_transfer_finish:
 /*  */
 void i2c_init(int speed, int slaveaddr)
 {
+#ifdef CONFIG_I2C_MULTI_BUS
+   base = (struct pxa_i2c *)i2c_regs[current_bus];
+#else
+   base = (struct pxa_i2c *)CONFIG_PXA_I2C_REG;
+#endif
+
 #ifdef CONFIG_SYS_I2C_INIT_BOARD
u32 icr;
/* call board specific i2c bus reset routine before accessing the   */
-- 
1.7.0.4

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


[U-Boot] [PATCH V6 1/5] pxa: move i2c driver to the common place

2011-03-31 Thread Lei Wen
For better sharing with other platform other than pxa's,
it is more convenient to put the driver to the common place.

Signed-off-by: Lei Wen 
---
Changelog:
v2: rename previous pxa_i2c to mvi2c.

V3: change previous name from pxa_i2c to mv_i2c
clean code style issue exist in original code

V4:
V5:
V6:
NO CHANGE

 arch/arm/cpu/pxa/Makefile |1 -
 arch/arm/cpu/pxa/i2c.c|  469 -
 drivers/i2c/Makefile  |1 +
 drivers/i2c/mv_i2c.c  |  452 +++
 include/configs/innokom.h |1 +
 include/configs/xm250.h   |1 +
 6 files changed, 455 insertions(+), 470 deletions(-)
 delete mode 100644 arch/arm/cpu/pxa/i2c.c
 create mode 100644 drivers/i2c/mv_i2c.c

diff --git a/arch/arm/cpu/pxa/Makefile b/arch/arm/cpu/pxa/Makefile
index 49a6ed3..e8b59a3 100644
--- a/arch/arm/cpu/pxa/Makefile
+++ b/arch/arm/cpu/pxa/Makefile
@@ -28,7 +28,6 @@ LIB   = $(obj)lib$(CPU).o
 START  = start.o
 
 COBJS  += cpu.o
-COBJS  += i2c.o
 COBJS  += pxafb.o
 COBJS  += timer.o
 COBJS  += usb.o
diff --git a/arch/arm/cpu/pxa/i2c.c b/arch/arm/cpu/pxa/i2c.c
deleted file mode 100644
index 7aa49ae..000
--- a/arch/arm/cpu/pxa/i2c.c
+++ /dev/null
@@ -1,469 +0,0 @@
-/*
- * (C) Copyright 2000
- * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arse...@tin.it
- *
- * (C) Copyright 2000 Sysgo Real-Time Solutions, GmbH 
- * Marius Groeger 
- *
- * (C) Copyright 2003 Pengutronix e.K.
- * Robert Schwebel 
- *
- * 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
- *
- * Back ported to the 8xx platform (from the 8260 platform) by
- * murray.jen...@cmst.csiro.au, 27-Jan-01.
- */
-
-/* FIXME: this file is PXA255 specific! What about other XScales? */
-
-#include 
-#include 
-
-#ifdef CONFIG_HARD_I2C
-
-/*
- * - CONFIG_SYS_I2C_SPEED
- * - I2C_PXA_SLAVE_ADDR
- */
-
-#include 
-#include 
-#include 
-
-/*#define  DEBUG_I2C   1   /###* activate local debugging output  
*/
-#define I2C_PXA_SLAVE_ADDR 0x1 /* slave pxa unit address   */
-
-#if (CONFIG_SYS_I2C_SPEED == 40)
-#define I2C_ICR_INIT   (ICR_FM | ICR_BEIE | ICR_IRFIE | ICR_ITEIE | ICR_GCD | 
ICR_SCLE)
-#else
-#define I2C_ICR_INIT   (ICR_BEIE | ICR_IRFIE | ICR_ITEIE | ICR_GCD | ICR_SCLE)
-#endif
-
-#define I2C_ISR_INIT   0x7FF
-
-#ifdef DEBUG_I2C
-#define PRINTD(x) printf x
-#else
-#define PRINTD(x)
-#endif
-
-
-/* Shall the current transfer have a start/stop condition? */
-#define I2C_COND_NORMAL0
-#define I2C_COND_START 1
-#define I2C_COND_STOP  2
-
-/* Shall the current transfer be ack/nacked or being waited for it? */
-#define I2C_ACKNAK_WAITACK 1
-#define I2C_ACKNAK_SENDACK 2
-#define I2C_ACKNAK_SENDNAK 4
-
-/* Specify who shall transfer the data (master or slave) */
-#define I2C_READ   0
-#define I2C_WRITE  1
-
-/* All transfers are described by this data structure */
-struct i2c_msg {
-   u8 condition;
-   u8 acknack;
-   u8 direction;
-   u8 data;
-};
-
-
-/**
- * i2c_pxa_reset: - reset the host controller
- *
- */
-
-static void i2c_reset( void )
-{
-   writel(readl(ICR) & ~ICR_IUE, ICR); /* disable unit */
-   writel(readl(ICR) | ICR_UR, ICR);   /* reset the unit */
-   udelay(100);
-   writel(readl(ICR) & ~ICR_IUE, ICR); /* disable unit */
-#ifdef CONFIG_CPU_MONAHANS
-   /* | CKENB_1_PWM1 | CKENB_0_PWM0); */
-   writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
-#else /* CONFIG_CPU_MONAHANS */
-   /* set the global I2C clock on */
-   writel(readl(CKEN) | CKEN14_I2C, CKEN);
-#endif
-   writel(I2C_PXA_SLAVE_ADDR, ISAR);   /* set our slave address */
-   writel(I2C_ICR_INIT, ICR);  /* set control reg values */
-   writel(I2C_ISR_INIT, ISR);  /* set clear interrupt bits */
-   writel(readl(ICR) | ICR_IUE, ICR);  /* enable unit */
-   udelay(100);
-}
-
-
-/**
- * i2c_isr_set_cleared: - wait until certain bits of the I2C status register
- *   are set and cleared
- *
- * @return: 1 in case of success, 0 means timeout (no match within 10 ms).
- */
-static int i2c_isr_set_cleared( unsigned long set_mask, unsigned long 
c

[U-Boot] [PATCH V6 3/5] I2C: add i2c support for Pantheon platform

2011-03-31 Thread Lei Wen
Add i2c support to dkb board with pantheon soc.

Signed-off-by: Lei Wen 
---
Changelog:
V2:
NO CHANGE

V3:
clean code sytle issue
Add i2c clock enable code include in I2C configure define block

V4:
make i2c definition included in the ifdef

V5:
NO CHANGE

V6:
Move the CONFIG_CMD_I2C define place

 arch/arm/cpu/arm926ejs/pantheon/cpu.c|   12 
 arch/arm/include/asm/arch-pantheon/cpu.h |4 +++-
 arch/arm/include/asm/arch-pantheon/mfp.h |6 --
 board/Marvell/dkb/dkb.c  |4 
 include/configs/dkb.h|   13 +
 5 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c 
b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
index 9ddc77c..8b2eafa 100644
--- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
+++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
@@ -59,6 +59,12 @@ int arch_cpu_init(void)
/* Enable GPIO clock */
writel(APBC_APBCLK, &apbclkres->gpio);
 
+#ifdef CONFIG_I2C_MV
+   /* Enable I2C clock */
+   writel(APBC_RST | APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
+   writel(APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
+#endif
+
icache_enable();
 
return 0;
@@ -76,3 +82,9 @@ int print_cpuinfo(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_I2C_MV
+void i2c_clk_enable(void)
+{
+}
+#endif
diff --git a/arch/arm/include/asm/arch-pantheon/cpu.h 
b/arch/arm/include/asm/arch-pantheon/cpu.h
index 30f4393..60955c5 100644
--- a/arch/arm/include/asm/arch-pantheon/cpu.h
+++ b/arch/arm/include/asm/arch-pantheon/cpu.h
@@ -50,7 +50,9 @@ struct panthapb_registers {
u32 uart0;  /*0x000*/
u32 uart1;  /*0x004*/
u32 gpio;   /*0x008*/
-   u8 pad0[0x034 - 0x08 - 4];
+   u8 pad0[0x02c - 0x08 - 4];
+   u32 twsi;   /*0x02c*/
+   u8 pad1[0x034 - 0x2c - 4];
u32 timers; /*0x034*/
 };
 
diff --git a/arch/arm/include/asm/arch-pantheon/mfp.h 
b/arch/arm/include/asm/arch-pantheon/mfp.h
index fb291cf..e939196 100644
--- a/arch/arm/include/asm/arch-pantheon/mfp.h
+++ b/arch/arm/include/asm/arch-pantheon/mfp.h
@@ -32,8 +32,10 @@
  * offset, pull,pF, drv,dF, edge,eF ,afn,aF
  */
 /* UART2 */
-#define MFP47_UART2_RXDMFP_REG(0x198) | MFP_AF6 | 
MFP_DRIVE_MEDIUM
-#define MFP48_UART2_TXDMFP_REG(0x19c) | MFP_AF6 | 
MFP_DRIVE_MEDIUM
+#define MFP47_UART2_RXD(MFP_REG(0x198) | MFP_AF6 | 
MFP_DRIVE_MEDIUM)
+#define MFP48_UART2_TXD(MFP_REG(0x19c) | MFP_AF6 | 
MFP_DRIVE_MEDIUM)
+#define MFP53_CI2C_SCL (MFP_REG(0x1b0) | MFP_AF2 | MFP_DRIVE_MEDIUM)
+#define MFP54_CI2C_SDA (MFP_REG(0x1b4) | MFP_AF2 | MFP_DRIVE_MEDIUM)
 
 /* More macros can be defined here... */
 
diff --git a/board/Marvell/dkb/dkb.c b/board/Marvell/dkb/dkb.c
index 72a2d2a..00f73e7 100644
--- a/board/Marvell/dkb/dkb.c
+++ b/board/Marvell/dkb/dkb.c
@@ -36,6 +36,10 @@ int board_early_init_f(void)
MFP47_UART2_RXD,
MFP48_UART2_TXD,
 
+   /* I2C */
+   MFP53_CI2C_SCL,
+   MFP54_CI2C_SDA,
+
MFP_EOC /*End of configureation*/
};
/* configure MFP's */
diff --git a/include/configs/dkb.h b/include/configs/dkb.h
index 638af5e..c893a9d 100644
--- a/include/configs/dkb.h
+++ b/include/configs/dkb.h
@@ -47,6 +47,7 @@
 #define CONFIG_SYS_NO_FLASH/* Declare no flash (NOR/SPI) */
 #include 
 #define CONFIG_CMD_AUTOSCRIPT
+#define CONFIG_CMD_I2C
 #undef CONFIG_CMD_NET
 #undef CONFIG_CMD_NFS
 /*
@@ -56,6 +57,18 @@
 #include "mv-common.h"
 
 #undef CONFIG_ARCH_MISC_INIT
+
+/*
+ * I2C definition
+ */
+#ifdef CONFIG_CMD_I2C
+#define CONFIG_I2C_MV  1
+#define CONFIG_PXA_I2C_REG 0xd4011000
+#define CONFIG_HARD_I2C1
+#define CONFIG_SYS_I2C_SPEED   0
+#define CONFIG_SYS_I2C_SLAVE   0xfe
+#endif
+
 /*
  * Environment variables configurations
  */
-- 
1.7.0.4

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


[U-Boot] [PATCH V6 2/5] mv_i2c: use structure to replace the direclty define

2011-03-31 Thread Lei Wen
Add i2c_clk_enable in the cpu specific code, since previous platform it,
while new platform don't need. In the pantheon and armada100 platform,
this function is defined as NULL one.

Signed-off-by: Lei Wen 
---
Changelog:
V2:
NO CHANGE

V3:
clean code sytle issue

V4:
V5:
V6:
NO CHANGE

 arch/arm/cpu/pxa/cpu.c   |   11 +++
 arch/arm/include/asm/arch-pxa/pxa-regs.h |   56 -
 board/innokom/innokom.c  |9 +--
 drivers/i2c/mv_i2c.c |  131 ++
 drivers/i2c/mv_i2c.h |   83 +++
 include/configs/innokom.h|1 +
 include/configs/xm250.h  |1 +
 7 files changed, 159 insertions(+), 133 deletions(-)
 create mode 100644 drivers/i2c/mv_i2c.h

diff --git a/arch/arm/cpu/pxa/cpu.c b/arch/arm/cpu/pxa/cpu.c
index 7d49cbb..24b59e7 100644
--- a/arch/arm/cpu/pxa/cpu.c
+++ b/arch/arm/cpu/pxa/cpu.c
@@ -318,3 +318,14 @@ int arch_cpu_init(void)
pxa_clock_setup();
return 0;
 }
+
+void i2c_clk_enable(void)
+{
+#ifdef CONFIG_CPU_MONAHANS
+   /* | CKENB_1_PWM1 | CKENB_0_PWM0); */
+   writel(readl(CKENB) | (CKENB_4_I2C), CKENB);
+#else /* CONFIG_CPU_MONAHANS */
+   /* set the global I2C clock on */
+   writel(readl(CKEN) | CKEN14_I2C, CKEN);
+#endif
+}
diff --git a/arch/arm/include/asm/arch-pxa/pxa-regs.h 
b/arch/arm/include/asm/arch-pxa/pxa-regs.h
index 65a387f..109fdc0 100644
--- a/arch/arm/include/asm/arch-pxa/pxa-regs.h
+++ b/arch/arm/include/asm/arch-pxa/pxa-regs.h
@@ -456,62 +456,6 @@ typedef void   (*ExcpHndlr) (void) ;
IrSR_XMITIR_IR_MODE)
 
 /*
- * I2C registers
- */
-#define IBMR   0x40301680  /* I2C Bus Monitor Register - IBMR */
-#define IDBR   0x40301688  /* I2C Data Buffer Register - IDBR */
-#define ICR0x40301690  /* I2C Control Register - ICR */
-#define ISR0x40301698  /* I2C Status Register - ISR */
-#define ISAR   0x403016A0  /* I2C Slave Address Register - ISAR */
-
-#ifdef CONFIG_CPU_MONAHANS
-#define PWRIBMR0x40f500C0  /* Power I2C Bus Monitor 
Register-IBMR */
-#define PWRIDBR0x40f500C4  /* Power I2C Data Buffer 
Register-IDBR */
-#define PWRICR 0x40f500C8  /* Power I2C Control Register - ICR */
-#define PWRISR 0x40f500CC  /* Power I2C Status Register - ISR */
-#define PWRISAR0x40f500D0  /* Power I2C Slave Address 
Register-ISAR */
-#else
-#define PWRIBMR0x40f00180  /* Power I2C Bus Monitor 
Register-IBMR */
-#define PWRIDBR0x40f00188  /* Power I2C Data Buffer 
Register-IDBR */
-#define PWRICR 0x40f00190  /* Power I2C Control Register - ICR */
-#define PWRISR 0x40f00198  /* Power I2C Status Register - ISR */
-#define PWRISAR0x40f001A0  /* Power I2C Slave Address 
Register-ISAR */
-#endif
-
-/* - Control register bits  */
-
-#define ICR_START  0x1 /* start bit */
-#define ICR_STOP   0x2 /* stop bit */
-#define ICR_ACKNAK 0x4 /* send ACK(0) or NAK(1) */
-#define ICR_TB 0x8 /* transfer byte bit */
-#define ICR_MA 0x10/* master abort */
-#define ICR_SCLE   0x20/* master clock enable, mona SCLEA */
-#define ICR_IUE0x40/* unit enable */
-#define ICR_GCD0x80/* general call disable */
-#define ICR_ITEIE  0x100   /* enable tx interrupts */
-#define ICR_IRFIE  0x200   /* enable rx interrupts, mona: DRFIE */
-#define ICR_BEIE   0x400   /* enable bus error ints */
-#define ICR_SSDIE  0x800   /* slave STOP detected int enable */
-#define ICR_ALDIE  0x1000  /* enable arbitration interrupt */
-#define ICR_SADIE  0x2000  /* slave address detected int enable */
-#define ICR_UR 0x4000  /* unit reset */
-#define ICR_FM 0x8000  /* Fast Mode */
-
-/* - Status register bits - */
-
-#define ISR_RWM0x1 /* read/write mode */
-#define ISR_ACKNAK 0x2 /* ack/nak status */
-#define ISR_UB 0x4 /* unit busy */
-#define ISR_IBB0x8 /* bus busy */
-#define ISR_SSD0x10/* slave stop detected */
-#define ISR_ALD0x20/* arbitration loss detected */
-#define ISR_ITE0x40/* tx buffer empty */
-#define ISR_IRF0x80/* rx buffer full */
-#define ISR_GCAD   0x100   /* general call address detected */
-#define ISR_SAD0x200   /* slave address detected */
-#define ISR_BED0x400   /* bus error no ACK/NAK */
-
-/*
  * Serial Audio Controller
  */
 /* FIXME the audio d

[U-Boot] [PATCH V6 0/5] add i2c support to pantheon and aramada100

2011-03-31 Thread Lei Wen
V2:
rename the previous pxa_i2c to mvi2c, since this driver would be shared
by many other Marvell platforms.

V3:
Clean the code sytle issue

V4:
add and* and or* to make set bit operation generic
Also make i2c definition included in the ifdef

V5:
Fix code style issue of the first patch
 
V6:
Seperate the and* and or* patch out of the patch set
Move CONFIG_CMD_I2C define place

Lei Wen (5):
  pxa: move i2c driver to the common place
  mv_i2c: use structure to replace the direclty define
  I2C: add i2c support for Pantheon platform
  I2C: mv_i2c: add multi bus support
  I2C: add i2c support for Armada100 platform

 arch/arm/cpu/arm926ejs/armada100/cpu.c|   16 +
 arch/arm/cpu/arm926ejs/pantheon/cpu.c |   12 +
 arch/arm/cpu/pxa/Makefile |1 -
 arch/arm/cpu/pxa/cpu.c|   11 +
 arch/arm/cpu/pxa/i2c.c|  469 
 arch/arm/include/asm/arch-armada100/mfp.h |   40 ++-
 arch/arm/include/asm/arch-pantheon/cpu.h  |4 +-
 arch/arm/include/asm/arch-pantheon/mfp.h  |6 +-
 arch/arm/include/asm/arch-pxa/pxa-regs.h  |   56 
 board/Marvell/aspenite/aspenite.c |5 +
 board/Marvell/dkb/dkb.c   |4 +
 board/innokom/innokom.c   |9 +-
 drivers/i2c/Makefile  |1 +
 drivers/i2c/mv_i2c.c  |  479 +
 drivers/i2c/mv_i2c.h  |   83 +
 include/configs/aspenite.h|   14 +
 include/configs/dkb.h |   13 +
 include/configs/innokom.h |2 +
 include/configs/xm250.h   |2 +
 19 files changed, 672 insertions(+), 555 deletions(-)
 delete mode 100644 arch/arm/cpu/pxa/i2c.c
 create mode 100644 drivers/i2c/mv_i2c.c
 create mode 100644 drivers/i2c/mv_i2c.h

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


Re: [U-Boot] [PATCH v6 1/4] mpc8xxx: DDR2/DDR3: Clean up DIMM-type switch statements

2011-03-31 Thread Kumar Gala

On Mar 15, 2011, at 12:04 PM, Kyle Moffett wrote:

> The numeric constants in the switch statements are replaced by #defines
> added to the common ddr_spd.h header.  This dramatically improves the
> readability of the switch statments.
> 
> In addition, a few of the longer lines were cleaned up, and the DDR2
> type for an SO-RDIMM module was added to the DDR2 switch statement.
> 
> Signed-off-by: Kyle Moffett 
> Cc: Andy Fleming 
> Cc: Kumar Gala 
> Cc: Kim Phillips 
> 
> ---
> Changelog:
> v2: Moved the constants to include/ddr_spd.h and also fixed DDR3
> v3: No changes
> v4: Fixed up excessively long lines
> v5: No changes
> v6: Rebased onto the 'next' branch of git://git.denx.de/u-boot-mpc85xx.git
> 
> arch/powerpc/cpu/mpc8xxx/ddr/ddr2_dimm_params.c |   23 +++-
> arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |   43 ++
> common/ddr_spd.c|2 +-
> include/ddr_spd.h   |   28 ++-
> 4 files changed, 53 insertions(+), 43 deletions(-)

applied to 85xx next

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


Re: [U-Boot] [PATCH v3] fsl_ddr: Don't use full 64-bit divides on 32-bit PowerPC

2011-03-31 Thread Kumar Gala

On Mar 15, 2011, at 10:23 AM, Kyle Moffett wrote:

> The current FreeScale MPC-8xxx DDR SPD interpreter is using full 64-bit
> integer divide operations to convert between nanoseconds and DDR clock
> cycles given arbitrary DDR clock frequencies.
> 
> Since all of the inputs to this are 32-bit (nanoseconds, clock cycles,
> and DDR frequencies), we can easily restructure the computation to use
> the "do_div()" function to perform 64-bit/32-bit divide operations.
> 
> On 64-bit this change is basically a no-op, because do_div is
> implemented as a literal 64-bit divide operation and the instruction
> scheduling works out almost the same.
> 
> On 32-bit PowerPC a fully accurate 64/64 divide (__udivdi3 in libgcc) is
> over 1.1kB of code and thousands of heavily dependent cycles to compute,
> all of which is linked from libgcc.  Another 1.2kB of code comes in for
> the function __umoddi3.
> 
> It should be noted that nothing else in U-Boot or the Linux kernel seems
> to require a full 64-bit divide on my 32-bit PowerPC.
> 
> Build-and-boot-tested on the HWW-1U-1A board using DDR2 SPD detection.
> 
> Signed-off-by: Kyle Moffett 
> Acked-by: York Sun 
> Cc: Andy Fleming 
> Cc: Kumar Gala 
> 
> --
> Changelog:
> v2: Resubmitted separately from the other HWW-1U-1A patches
> v3: Rebased on the 'next' branch of git://git.denx.de/u-boot-mpc85xx.git
> 
> arch/powerpc/cpu/mpc8xxx/ddr/util.c |   56 +--
> 1 files changed, 40 insertions(+), 16 deletions(-)

applied to 85xx next

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


Re: [U-Boot] [PATCH] ftsmc020: enhance for features and asm support.

2011-03-31 Thread Wolfgang Denk
Dear Macpaul Lin,

In message  you 
wrote:
> 
> There are lots of register offset is widely been used both in
> lowlevel_init and C environment.

Yes, there is a lot os mess that piled up over the years.  It will
take time to clean this up.

> If there is a code wrote as writel(0x1,  AT91_ASM_SMC_SETUP0);
> originally must be rewrote as
> writel(0x1,  AT91_SMC_BASE + AT91_ASM_SMC_SETUP0);

No, this should be rewritten to acces a C struct instead.
These offesets must ONLY be used in assembler files, but NOT in any C
code.

> I meant, should we make a script that could auto generate asm-offset
> like a translation from
> struct ftsmc020 {
> unsigned bank0_cr;
> unsigned bank0_tpr;
> ...
> }
> into
> #define FTSMC020_BANK0_CR 0x00;
> or
> #define FTSMC020_BANK0_TPR (4);

No.  It makes no sense to provide offset fefinitions for allexisting
struct entries.  Onle those are needed that are actually being used in
assembler code, and this should be only a handful.

If you find yourself using more of them, you should stop and ask
yourself why you are not writing this code in C.

> without manually reworte the structure in the way as
> OFFSET(FTSMC020_BANK0_CR, ftsmc020, bank0_cr);
> and create a new specific header file for make-asm-offset?

I repeat again: I consider this manual unrolling of the nested structs
a Bad Thing.  You should have separate offsets for each of the nested
structs.

> You are right, the comments of FTSMC020_BANK0_TPR (4) is really bad
> for human reading.

Actually not. They explain exactly what's going on there.

> However, when people implementing lowlevel_init or other assembly
> files, they still need such kind of reference
> to write *.S files before the asm-offset has been generated by make.

First of all, people should stop writing assembly code when they
could use C instead.  The remaining (small!) parts of aseembler code
will need only a small number of offset definitions.  These should be
easy to handle.

Again: if you need larger numbers of such entries you are doing
something fundamentally wrong.  Reconsider your coding style.  What
exactly enforces you to use assembly?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Real computer scientists don't comment their  code.  The  identifiers
are so long they can't afford the disk space.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] powerpc/85xx: Fix setting of LIODN prop in PCIe nodes on P3041/P5020

2011-03-31 Thread Kumar Gala

On Mar 15, 2011, at 1:14 PM, Kumar Gala wrote:

> From: Laurentiu TUDOR 
> 
> We utilize the compatible string to find the node to add fsl,liodn
> property to.  However P3041 & P5020 don't have "fsl,p4080-pcie"
> compatible for their PCIe controllers as they aren't backwards compatible.
> 
> Allow the macro's to specify the PCIe compatible to use to allow SoC
> uniqueness.  On P3041 & P5020 we utilize "fsl,qoriq-pcie-v2.2" for the
> PCIe controllers.
> 
> Signed-off-by: Laurentiu TUDOR 
> Signed-off-by: Kumar Gala 
> ---
> arch/powerpc/cpu/mpc85xx/p3041_ids.c |   10 +-
> arch/powerpc/cpu/mpc85xx/p4080_ids.c |8 
> arch/powerpc/cpu/mpc85xx/p5020_ids.c |   10 +-
> arch/powerpc/include/asm/fsl_liodn.h |4 ++--
> 4 files changed, 16 insertions(+), 16 deletions(-)

applied to 85xx next

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


Re: [U-Boot] [PATCH 2/7] tsec: arrange the code to avoid useless function declaration

2011-03-31 Thread Kumar Gala

On Mar 29, 2011, at 2:30 PM, Andy Fleming wrote:

> From: Mingkai Hu 
> 
> Signed-off-by: Mingkai Hu 
> Acked-by: Andy Fleming 
> Signed-off-by: Kumar Gala 
> ---
> drivers/net/tsec.c |  857 +---
> 1 files changed, 416 insertions(+), 441 deletions(-)

I'm concerned this differs from the version in 85xx 'next'

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


Re: [U-Boot] [PATCH] ftsmc020: enhance for features and asm support.

2011-03-31 Thread Macpaul Lin
Hi Wolfgang

2011/3/31 Wolfgang Denk :
> Dear Macpaul Lin,
>
> We should probably split architecture and/or board specific additions
> like these into separate files in the respectice architecture / board
> directories.  Eventually we add make targets for these, then; for now
> it's probably sufficient to add some #include to lib/asm-offsets.c
>
> Otherwise lib/asm-offsets.c will quickly become an unreadable mess.
>
> Otherwise this looks OK with me.

There are lots of register offset is widely been used both in
lowlevel_init and C environment.
If we really want assembly offset of these registers is generated from
structures,
lots of includes files with OFFSET() marco to generate asm-offsets
will be required.
For example:
in "arch/arm/include/asm/arch-at91/at91sam9_smc.h", there exist the
similar problem as ftsmc020.

#ifdef __ASSEMBLY__

#ifndef AT91_SMC_BASE
#define AT91_SMC_BASE   AT91_SMC0_BASE
#endif

#define AT91_ASM_SMC_SETUP0 AT91_SMC_BASE
#define AT91_ASM_SMC_PULSE0 (AT91_SMC_BASE + 0x04)
#define AT91_ASM_SMC_CYCLE0 (AT91_SMC_BASE + 0x08)
#define AT91_ASM_SMC_MODE0  (AT91_SMC_BASE + 0x0C)

#else

typedef struct  at91_cs {
u32 setup;  /* 0x00 SMC Setup Register */
u32 pulse;  /* 0x04 SMC Pulse Register */
u32 cycle;  /* 0x08 SMC Cycle Register */
u32 mode;   /* 0x0C SMC Mode Register */
} at91_cs_t;

typedef struct  at91_smc {
at91_cs_t   cs[8];
} at91_smc_t;

#endif /*  __ASSEMBLY__ */

Thus we may need to write some code like OFFSET(AT91_ASM_SMC_SETUP0,
at91_cs, setup);
some where in the included file then generate the code like.
#define AT91_ASM_SMC_SETUP0 (0) /* offsetof(struct at91_cs, setup) */

Even like this, we cannot directly use AT91_ASM_SMC_SETUP0 like the
code above in lowlevel_init.c.
If there is a code wrote as writel(0x1,  AT91_ASM_SMC_SETUP0);
originally must be rewrote as
writel(0x1,  AT91_SMC_BASE + AT91_ASM_SMC_SETUP0);

Hence we really need some scalable rework for the both a split
arch/board make-asm-offset directories.

I'm not sure if my thought of this scenario correct?

> Keep in mind that I dislike this manual unrolling of the nested
> structs. It may work in your code, but it is ugly and doesn't scale.
> Also, it does not allow any kind of looping over the entries which
> might be needed here and there.  I strongly recommend to get rid of
> these nested declarations.

Ok, since the original structure was commit by other people, I'm still
trying to rewrite the original C code.

>> #define FTSMC020_PAD4 (48) /* offsetof(struct ftsmc020, pad[4]) */
>> #define FTSMC020_PAD5 (52) /* offsetof(struct ftsmc020, pad[5]) */
>> #define FTSMC020_PAD6 (56) /* offsetof(struct ftsmc020, pad[6]) */
>> #define FTSMC020_PAD7 (60) /* offsetof(struct ftsmc020, pad[7]) */
>> #define FTSMC020_SSR (64) /* offsetof(struct ftsmc020, ssr) */
>>
>> However, this looks weird. It doesn't look like the other automated
>> generated code.
>
> What exactly looks weird?  And what "other automated generated code"
> do you mean?

I meant, should we make a script that could auto generate asm-offset
like a translation from
struct ftsmc020 {
unsigned bank0_cr;
unsigned bank0_tpr;
...
}
into
#define FTSMC020_BANK0_CR 0x00;
or
#define FTSMC020_BANK0_TPR (4);

without manually reworte the structure in the way as
OFFSET(FTSMC020_BANK0_CR, ftsmc020, bank0_cr);
and create a new specific header file for make-asm-offset?

>> Could I move the generated code into ftsmc020.h?
>
> No - what for?  This is automatically generated code, that gets used
> somewhere. No human eye is supposed to have to read it.

You are right, the comments of FTSMC020_BANK0_TPR (4) is really bad
for human reading.
However, when people implementing lowlevel_init or other assembly
files, they still need such kind of reference
to write *.S files before the asm-offset has been generated by make.

Thanks.

-- 
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 1/7] tsec: use IO accessories to access the register

2011-03-31 Thread Kumar Gala

On Mar 29, 2011, at 2:30 PM, Andy Fleming wrote:

> From: Mingkai Hu 
> 
> Signed-off-by: Mingkai Hu 
> Acked-by: Andy Fleming 
> Signed-off-by: Kumar Gala 
> ---
> drivers/net/tsec.c |  234 ++-
> include/tsec.h |8 +-
> 2 files changed, 123 insertions(+), 119 deletions(-)

This is already in 85xx next

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


Re: [U-Boot] [PATCH] [MPC837x v2] Make it work again with USB.

2011-03-31 Thread Andre Schwarz
Kim,

> On Mon, 28 Feb 2011 17:18:38 +0100
> Andre Schwarz  wrote:
>
>> sorry to bother you again, but I again stumbled over the discussed USB
>> init issue :
> nack, 837x has a usb controller at IMMR+0x23000.
 yes - but offset 0x00-0xff is explicitly reserved regarding to the manual.
 Don't know whether it is a "should not" or "must not be touched".

 All I can see is a CPU hang with arbiter event register reporting a 
 timeout on
 0xe0023000.


 Check to see whether there is an invalid USB clock setting in the SCCR?
 All clocks are turned on except SEC and 2nd TSEC.

 After all USB is running fine with this patch, i.e. there can hardly be a
 missing clock.


 Please re-think you NAK.
>>> afaik, 834x and 837x don't have any special USB settings in common, so,
>>> this patch, at least in it's current form, is not on.
>>>
>>> 0xe0023500 should be the address of the config register being accessed
>>> here; please check the code isn't accessing 0xe0023000, as you mention
>>> above.
>> ok - this was some kind of misunderstanding.
>> ehci regs are based at immr + 0x23000 with the "config" pointing to
>> offset 0x500 inside ehci.
>> This looks sane to me.
> ok, as long as it's confirmed.
>
>>> If that's correct, try something like the following so we can determine
>>> what setting the USB controller didn't agree with:
>>>
>>> diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c 
>>> b/arch/powerpc/cpu/mpc83xx/cpu_init.c
>>> index 7a1cae7..cbc4157 100644
>>> --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
>>> +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
>>> @@ -332,7 +332,7 @@ void cpu_init_f (volatile immap_t * im)
>>> struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
>>>
>>> /* Configure interface. */
>>> -   setbits_be32(&ehci->control, REFSEL_16MHZ | UTMI_PHY_EN);
>> MPC837x has only 2 working bits inside the control register :
>>
>> Bit29: USB_EN ->  should be set to 1 before USB can be used.
>> Bit31: ULPI_INT_EN ->  enables an ULPI wake-up irq.
>>
>> Both "REFSEL_16MHZ" and "UTMI_PHY_EN" are completely out of scope for
>> MPC837x.
> that's why I'm suggesting we confirm that touching the REFSEL_16MHZ and
> UTMI_PHY_EN bits aren't sending the 837x controller into oblivion - did
> you test the patch?

yes - writing those bits or not makes no difference ...

>>> +   setbits_be32(&ehci->control, 0);
>>>
>>> /* Wait for clock to stabilize */
>> This loop never returns on MPC837x because "PHY_CLK_VALID" isn't valid.
> right, we need to narrow down the reason for this.
>
... it is this loop that *can not* return since 
ehci->control[PHY_CLK_VALID] is always 0 on 837x.
This can be seen by having a look at the reference manual (Rev. 1 page 
20-46 / Chapter 20.3.2.28).

>>> do {temp = __raw_readl(&ehci->control);
>>>   udelay(1000);
>>>   } while (!(temp&   PHY_CLK_VALID));
>>>
>> I still wonder how there can be a single working MPC837x board with
>> CONFIG_USB_EHCI_FSL set.
>>
>> Some pending patches on your side ?
>> What kind of patch might get an ACK from your side ?
> nothing that suggests 834x and 837x have any special USB settings in
> common - because it's not true and therefore misleading.

I never ever said that 834x and 837x have anything in common regarding USB.
All I say is that they both must not run into this loop.

If you see any problems or'ing 837x into the #ifndef I suggest you come 
up with a positive
#ifdef being valid for only those chips that need it. Honestly I don't 
know which SoC's will need it.

All I want is to skip this loop on 837x.


Regards,
André


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH V5 4/6] I2C: add i2c support for Pantheon platform

2011-03-31 Thread Lei Wen
Hi Prafulla,

On Thu, Mar 31, 2011 at 2:56 AM, Prafulla Wadaskar  wrote:
>
>
>> -Original Message-
>> From: Lei Wen [mailto:adrian.w...@gmail.com]
>> Sent: Wednesday, March 30, 2011 7:36 PM
>> To: Prafulla Wadaskar
>> Cc: Lei Wen; Heiko Schocher; Wolfgang Denk; u-boot@lists.denx.de; Marek
>> Vasut; Ashish Karkare; Prabhanjan Sarnaik; Yu Tang
>> Subject: Re: [PATCH V5 4/6] I2C: add i2c support for Pantheon platform
>>
>> Hi Prafulla,
>>
>> On Tue, Mar 29, 2011 at 9:07 PM, Prafulla Wadaskar
>>  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Lei Wen [mailto:lei...@marvell.com]
>> >> Sent: Monday, March 28, 2011 12:24 PM
>> >> To: Heiko Schocher; Prafulla Wadaskar; Wolfgang Denk; u-
>> >> b...@lists.denx.de; Marek Vasut; Ashish Karkare; Prabhanjan Sarnaik;
>> Yu
>> >> Tang; adrian.w...@gmail.com
>> >> Subject: [PATCH V5 4/6] I2C: add i2c support for Pantheon platform
>> >>
>> >> Add i2c support to dkb board with pantheon soc.
>> >>
>> >> Signed-off-by: Lei Wen 
>> >> ---
>> >> Changelog:
>> >> V2:
>> >> NO CHANGE
>> >>
>> >> V3:
>> >> clean code sytle issue
>> >> Add i2c clock enable code include in I2C configure define block
>> >>
>> >> V4:
>> >> make i2c definition included in the ifdef
>> >>
>> >> V5:
>> >> NO CHANGE
>> >>
>> >>  arch/arm/cpu/arm926ejs/pantheon/cpu.c    |   12 
>> >>  arch/arm/include/asm/arch-pantheon/cpu.h |    4 +++-
>> >>  arch/arm/include/asm/arch-pantheon/mfp.h |    6 --
>> >>  board/Marvell/dkb/dkb.c                  |    4 
>> >>  include/configs/dkb.h                    |   13 +
>> >>  5 files changed, 36 insertions(+), 3 deletions(-)
>> >>
>> > ...snip...
>> >
>> >> diff --git a/include/configs/dkb.h b/include/configs/dkb.h
>> >> index 638af5e..599c8b8 100644
>> >> --- a/include/configs/dkb.h
>> >> +++ b/include/configs/dkb.h
>> >> @@ -56,6 +56,19 @@
>> >>  #include "mv-common.h"
>> >>
>> >>  #undef CONFIG_ARCH_MISC_INIT
>> >> +
>> >> +/*
>> >> + * I2C definition
>> >> + */
>> >> +#define CONFIG_CMD_I2C
>> >
>> > This command definition should be moved up (below #include
>> 
>>
>> I'm ok to put this define to the config_cmd_default.h, but this mean
>> many other platform need
>> which didn't not need the i2c but include the ,
>> need to undef the i2c now.
>> Does that worth the change?
>
> I don't mean here to put it in to the config_cmd_default.h
> I means put it below #include  line where other 
> commands are defined/undefed.
>

Understand...
Patch to come...

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


Re: [U-Boot] Please pull u-boot-mpc85xx.git (updated)

2011-03-31 Thread Wolfgang Denk
Dear Kumar Gala,

In message  you 
wrote:
> [ Pull in one other HW / SoC related fix in for v2011.03 ]
> 
> The following changes since commit cb815e5ff979e36d68df130a810d34de4bf93289:
> 
>   Prepare v (2011-03-27 21:50:07 +0200)
> 
> are available in the git repository at:
>   git://git.denx.de/u-boot-mpc85xx.git master
> 
> Jiang Yutang (1):
>   powerpc/85xx: Enable various errata on P1022/P1013 SoCs
> 
> Prabhakar Kushwaha (1):
>   powerpc/85xx: Handle PCIe initialization requires for P1021 class SoCs
> 
>  arch/powerpc/cpu/mpc85xx/p1021_serdes.c   |   49 
> -
>  arch/powerpc/include/asm/config_mpc85xx.h |   10 ++
>  drivers/pci/fsl_pci_init.c|7 
>  include/configs/P1022DS.h |1 +
>  include/pci.h |1 +
>  5 files changed, 67 insertions(+), 1 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You're dead, Jim.
-- McCoy, "The Tholian Web", stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Please pull u-boot-cfi-flash/master

2011-03-31 Thread Wolfgang Denk
Dear Stefan Roese,

In message <201103281934.20704...@denx.de> you wrote:
> Hi Wolfgang,
> 
> please pull this CFI fix:
> 
> The following changes since commit cb815e5ff979e36d68df130a810d34de4bf93289:
> 
>   Prepare v (2011-03-27 21:50:07 +0200)
> 
> are available in the git repository at:
>   git://www.denx.de/git/u-boot-cfi-flash.git master
> 
> Martin Krause (1):
>   cfi_flash: fix bug with flash banks with different sector numbers
> 
>  drivers/mtd/cfi_flash.c |5 +
>  1 files changed, 5 insertions(+), 0 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
Another war ... must it always be so?  How many comrades have we lost
in this way? ...  Obedience.  Duty.  Death, and more death ...
-- Romulan Commander, "Balance of Terror", stardate 1709.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot