From djpig at denx.de  Tue Apr  1 02:03:27 2008
From: djpig at denx.de (Frank Lichtenheld)
Date: Tue, 1 Apr 2008 02:03:27 +0200
Subject: [U-Boot-Users] Service Announcement: DENX services moving to new
	server
Message-ID: <20080401000327.GB25732@mail-vs.djpig.de>

Hi.

All public services provided by DENX are currently moving to a server
with newer, more powerful hardware. This move should be transparent for
users and developers, except maybe for minor glitches during DNS update
times. If you encounter any problems, please report them to root at denx.de

There is one exception: The CVS access (pserver and cvsweb) is no more.
For people that really still want use a cvs client to access the code,
a git-cvsserver is set up instead. More information is available at
http://www.denx.de/en/Software/GitCVS

Please note that the git repositories are now available under
additional URIs:
(git|http)://www.denx.de/git/<name> is also available as
(git|http)://git.denx.de/<name>
And the gitweb interface is now avilable directly at
http://git.denx.de/ (in addition to the old
http://www.denx.de/cgi-bin/gitweb.cgi)

It is planned to prefer the new URIs now when refering to the repositories
(since they are slightly shorter and more flexible should we ever decide
to have the website and the code on different machines), but the old ones
should continue to work for the forseeable future.

Gruesse,
-- 
Frank Lichtenheld <djpig at denx.de>
www: http://www.denx.de/



From arasv at magtech.com.au  Tue Apr  1 03:22:27 2008
From: arasv at magtech.com.au (Aras Vaichas)
Date: Tue, 01 Apr 2008 12:22:27 +1100
Subject: [U-Boot-Users] [PATCH] DHCP request fix for Windows Server 2003
In-Reply-To: <47EF1327.8030803@qstreams.com>
References: <47E9802D.8000205@magtech.com.au> <47E980EF.9070007@magtech.com.au>
	<47EF1327.8030803@qstreams.com>
Message-ID: <47F18E53.1050605@magtech.com.au>

Ben Warren wrote:
> Applied to net tree. In the future, please post patch inline.
Yes, I will do that. I've heard that Thunderbird isn't good for posting
patches and now I see why.

Aras


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From afleming at freescale.com  Tue Apr  1 03:45:56 2008
From: afleming at freescale.com (Andy Fleming)
Date: Mon, 31 Mar 2008 20:45:56 -0500
Subject: [U-Boot-Users] [PATCH] Fix fdt set command to conform to dts spec
Message-ID: <1207014356-1663-1-git-send-email-afleming@freescale.com>

The fdt set command was treating properties specified as <00> and <0011>
as byte streams, rather than as an array of cells.  As we already have
syntax for expressing the desire for a stream of bytes ([ xx xx ...]),
we should use the <> syntax to describe arrays of cells, which are always
32-bits per element.  If we imagine this likely (IMHO) scenario:

> fdt set /ethernet-phy at 1 reg <1>

With the old code, this would create a bad fdt, since the reg cell would be
made to be one byte in length.  But the cell must be 4 bytes, so this would
break mysteriously.

Also, the dts spec calls for constants inside the angle brackets (<>)
to conform to C constant standards as they pertain to base.
Take this scenario:

> fdt set /ethernet at f00 reg <0xe250000\ 0x1000>

The old fdt command would complain that it couldn't parse that.  Or, if you
wanted to specify that a certain clock ran at 33 MHz, you'd be required to
do this:

> fdt set /mydev clock <1f78a40>

Whereas the new code will accept decimal numbers.

While I was in there, I extended the fdt command parser to handle property
strings which are split across multiple arguments:

> fdt set /ethernet at f00 interrupts < 33 2 34 2 36 2 >
> fdt p /ethernet at f00
ethernet at f00 {
	interrupts = <0x21 0x2 0x22 0x2 0x24 0x2>;
};

Lastly, the fdt print code was rearranged slightly to print arrays of cells
if the length of the property is a multiple of 4 bytes, and to not print
leading zeros.

Signed-off-by: Andy Fleming <afleming at freescale.com>
---
 common/cmd_fdt.c |  137 ++++++++++++++++++++++++++---------------------------
 1 files changed, 67 insertions(+), 70 deletions(-)

diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index a52284e..7436a95 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -42,8 +42,7 @@
 DECLARE_GLOBAL_DATA_PTR;
 
 static int fdt_valid(void);
-static int fdt_parse_prop(char *pathp, char *prop, char *newval,
-	char *data, int *len);
+static int fdt_parse_prop(char **newval, int count, char *data, int *len);
 static int fdt_print(const char *pathp, char *prop, int depth);
 
 /*
@@ -202,7 +201,7 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 		if (argc == 4) {
 			len = 0;
 		} else {
-			ret = fdt_parse_prop(pathp, prop, argv[4], data, &len);
+			ret = fdt_parse_prop(&argv[4], argc - 4, data, &len);
 			if (ret != 0)
 				return ret;
 		}
@@ -464,69 +463,77 @@ static int fdt_valid(void)
 
 /*
  * Parse the user's input, partially heuristic.  Valid formats:
- * <00>		- hex byte
- * <0011>	- hex half word (16 bits)
- * <00112233>	- hex word (32 bits)
- *		- hex double words (64 bits) are not supported, must use
- *			a byte stream instead.
+ * <0x00112233 4 05>	- an array of cells.  Numbers follow standard
+ * 			C conventions.
  * [00 11 22 .. nn] - byte stream
  * "string"	- If the the value doesn't start with "<" or "[", it is
  *			treated as a string.  Note that the quotes are
  *			stripped by the parser before we get the string.
+ * newval: An array of strings containing the new property as specified
+ * 	on the command line
+ * count: The number of strings in the array
+ * data: A bytestream to be placed in the property
+ * len: The length of the resulting bytestream
  */
-static int fdt_parse_prop(char *pathp, char *prop, char *newval,
-	char *data, int *len)
+static int fdt_parse_prop(char **newval, int count, char *data, int *len)
 {
 	char *cp;		/* temporary char pointer */
+	char *newp;		/* temporary newval char pointer */
 	unsigned long tmp;	/* holds converted values */
+	int stridx = 0;
 
-	if (*newval == '<') {
-		/*
-		 * Bigger values than bytes.
-		 */
-		*len = 0;
-		newval++;
-		while ((*newval != '>') && (*newval != '\0')) {
-			cp = newval;
-			tmp = simple_strtoul(cp, &newval, 16);
-			if ((newval - cp) <= 2) {
-				*data = tmp & 0xFF;
-				data  += 1;
-				*len += 1;
-			} else if ((newval - cp) <= 4) {
-				*(uint16_t *)data = __cpu_to_be16(tmp);
-				data  += 2;
-				*len += 2;
-			} else if ((newval - cp) <= 8) {
-				*(uint32_t *)data = __cpu_to_be32(tmp);
-				data  += 4;
-				*len += 4;
-			} else {
+	*len = 0;
+	newp = newval[0];
+
+	/* An array of cells */
+	if (*newp == '<') {
+		newp++;
+		while ((*newp != '>') && (stridx < count)) {
+			/*
+			 * Keep searching until we find that last ">"
+			 * That way users don't have to escape the spaces
+			 */
+			if (*newp == '\0') {
+				newp = newval[++stridx];
+				continue;
+			}
+
+			cp = newp;
+			tmp = simple_strtoul(cp, &newp, 0);
+			*(uint32_t *)data = __cpu_to_be32(tmp);
+			data  += 4;
+			*len += 4;
+
+			/* If the ptr didn't advance, something went wrong */
+			if ((newp - cp) <= 0) {
 				printf("Sorry, I could not convert \"%s\"\n",
 					cp);
 				return 1;
 			}
-			while (*newval == ' ')
-				newval++;
+
+			while (*newp == ' ')
+				newp++;
 		}
-		if (*newval != '>') {
-			printf("Unexpected character '%c'\n", *newval);
+
+		if (*newp != '>') {
+			printf("Unexpected character '%c'\n", *newp);
 			return 1;
 		}
-	} else if (*newval == '[') {
+	} else if (*newp == '[') {
 		/*
 		 * Byte stream.  Convert the values.
 		 */
-		*len = 0;
-		newval++;
-		while ((*newval != ']') && (*newval != '\0')) {
-			tmp = simple_strtoul(newval, &newval, 16);
+		newp++;
+		while ((*newp != ']') && (stridx < count)) {
+			tmp = simple_strtoul(newp, &newp, 16);
 			*data++ = tmp & 0xFF;
 			*len    = *len + 1;
-			while (*newval == ' ')
-				newval++;
+			while (*newp == ' ')
+				newp++;
+			if (*newp != '\0')
+				newp = newval[++stridx];
 		}
-		if (*newval != ']') {
+		if (*newp != ']') {
 			printf("Unexpected character '%c'\n", *newval);
 			return 1;
 		}
@@ -535,8 +542,11 @@ static int fdt_parse_prop(char *pathp, char *prop, char *newval,
 		 * Assume it is a string.  Copy it into our data area for
 		 * convenience (including the terminating '\0').
 		 */
-		*len = strlen(newval) + 1;
-		strcpy(data, newval);
+		while (stridx < count) {
+			*len = strlen(newp) + 1;
+			strcpy(data, newp);
+			newp = newval[++stridx];
+		}
 	}
 	return 0;
 }
@@ -593,7 +603,6 @@ static int is_printable_string(const void *data, int len)
 static void print_data(const void *data, int len)
 {
 	int j;
-	const u8 *s;
 
 	/* no data, don't print */
 	if (len == 0)
@@ -616,32 +625,20 @@ static void print_data(const void *data, int len)
 		return;
 	}
 
-	switch (len) {
-	case 1:	 /* byte */
-		printf("<0x%02x>", (*(u8 *) data) & 0xff);
-		break;
-	case 2:	 /* half-word */
-		printf("<0x%04x>", be16_to_cpu(*(u16 *) data) & 0xffff);
-		break;
-	case 4:	 /* word */
-		printf("<0x%08x>", be32_to_cpu(*(u32 *) data) & 0xffffffffU);
-		break;
-	case 8:	 /* double-word */
-#if __WORDSIZE == 64
-		printf("<0x%016llx>", be64_to_cpu(*(uint64_t *) data));
-#else
-		printf("<0x%08x ", be32_to_cpu(*(u32 *) data) & 0xffffffffU);
-		data += 4;
-		printf("0x%08x>", be32_to_cpu(*(u32 *) data) & 0xffffffffU);
-#endif
-		break;
-	default:		/* anything else... hexdump */
+	if ((len %4) == 0) {
+		const u32 *p;
+
+		printf("<");
+		for (j = 0, p = data; j < len/4; j ++)
+			printf("0x%x%s", p[j], j < (len/4 - 1) ? " " : "");
+		printf(">");
+	} else { /* anything else... hexdump */
+		const u8 *s;
+
 		printf("[");
 		for (j = 0, s = data; j < len; j++)
 			printf("%02x%s", s[j], j < len - 1 ? " " : "");
 		printf("]");
-
-		break;
 	}
 }
 
@@ -771,7 +768,7 @@ static int fdt_print(const char *pathp, char *prop, int depth)
 /********************************************************************/
 
 U_BOOT_CMD(
-	fdt,	5,	0,	do_fdt,
+	fdt,	255,	0,	do_fdt,
 	"fdt     - flattened device tree utility commands\n",
 	    "addr   <addr> [<length>]        - Set the fdt location to <addr>\n"
 #ifdef CONFIG_OF_BOARD_SETUP
-- 
1.5.4.23.gef5b9




From wylg at sina.com  Tue Apr  1 04:01:40 2008
From: wylg at sina.com (wylg at sina.com)
Date: Tue, 01 Apr 2008 10:01:40 +0800 
Subject: [U-Boot-Users] How to do DUART loopback test on MPC8541?
Message-ID: <20080401020140.94616.qmail@mail2-205.sinamail.sina.com.cn>

hello,all
I'm new to u-boot, now I am working on MPC8541, I use DUART1 as my serial port, I want to do loopback test on DUART1, but it isn't working, so I want to know how to do loopback test on DUART1.Can you help me?
below is my processing steps:
1) set UCLR1=0x00 (close DLAB)
2) set UIER1=0x00 (disable interrupt)
3) set UMCR1=0x12 (allow loopback)
4) set UTHR1=0x5a (sending a char)
5) get the loopback value from URBR1 (but I always get value 0)
best regards
leo

-------------------------------------------------------------------
???????????,????KFC???( http://d1.sina.com.cn/sina/limeng3/mail_zhuiyu/2008/mail_zhuiyu_20080205.html )

===================================================================
????2G?????http://mail.sina.com.cn/?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080401/03ca7b80/attachment.htm 

From biggerbadderben at gmail.com  Tue Apr  1 05:27:38 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Mon, 31 Mar 2008 23:27:38 -0400
Subject: [U-Boot-Users] Pull request - net
Message-ID: <47F1ABAA.4050404@gmail.com>

Wolfgang,

The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
  Bartlomiej Sieka (1):
        Fix host tool build breakage, take two

are available in the git repository at:

  git://www.denx.de/git/u-boot-net.git master

Andre Schwarz (1):
      new PHY @ e1000 - 2nd try

Aras Vaichas (1):
      DHCP request fix for Windows Server 2003

Ben Warren (1):
      Fix macro typo in common/cmd_mii.c

Daniel Hellstrom (2):
      SPARC/LEON3: Added GRETH Ethernet 10/100/1000 driver.
      SPARC: added SMC91111 driver in and out macros for LEON processors.

Tor Krill (1):
      Add Vitesse 8601 support to TSEC driver

Tsi-Chung Liew (2):
      ColdFire: Fix FEC transmit issue for MCF5275
      Add CONFIG_MII_INIT in cmd_mii.c

 README                 |   17 ++
 common/cmd_mii.c       |    2 +-
 drivers/net/Makefile   |    1 +
 drivers/net/e1000.c    |   54 ++++-
 drivers/net/e1000.h    |   53 +++-
 drivers/net/greth.c    |  661 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/net/greth.h    |   97 +++++++
 drivers/net/mcffec.c   |    7 +
 drivers/net/smc91111.h |   73 +++++-
 drivers/net/tsec.c     |   30 +++
 drivers/net/tsec.h     |    5 +
 include/pci_ids.h      |    1 +
 net/bootp.c            |    5 +-
 net/eth.c              |    4 +
 14 files changed, 993 insertions(+), 17 deletions(-)
 create mode 100644 drivers/net/greth.c
 create mode 100644 drivers/net/greth.h





From plagnioj at jcrosoft.com  Tue Apr  1 07:40:23 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue,  1 Apr 2008 07:40:23 +0200
Subject: [U-Boot-Users] [PATCH 0/3] AT91CAP9ADK: Move CONFIG_CMD_NAND to
	Makefile
Message-ID: <1207028426-14752-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/board/atmel/at91cap9adk/Makefile b/board/atmel/at91cap9adk/Makefile
index 359fdab..3961030 100644
--- a/board/atmel/at91cap9adk/Makefile
+++ b/board/atmel/at91cap9adk/Makefile
@@ -25,10 +25,12 @@ include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(BOARD).a
 
-COBJS	:= at91cap9adk.o led.o nand.o
+COBJS-y	+= at91cap9adk.o
+COBJS-y	+= led.o
+COBJS-$(CONFIG_CMD_NAND) += nand.o
 
-SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS	:= $(addprefix $(obj),$(COBJS))
+SRCS    := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS    := $(addprefix $(obj),$(COBJS-y))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
 $(LIB):	$(obj).depend $(OBJS) $(SOBJS)
diff --git a/board/atmel/at91cap9adk/nand.c b/board/atmel/at91cap9adk/nand.c
index 1277973..c72b024 100644
--- a/board/atmel/at91cap9adk/nand.c
+++ b/board/atmel/at91cap9adk/nand.c
@@ -29,8 +29,6 @@
 #include <asm/arch/gpio.h>
 #include <asm/arch/at91_pio.h>
 
-#ifdef CONFIG_CMD_NAND
-
 #include <nand.h>
 
 /*
@@ -70,4 +68,3 @@ int board_nand_init(struct nand_chip *nand)
 
 	return 0;
 }
-#endif
-- 
1.5.4.1




From plagnioj at jcrosoft.com  Tue Apr  1 07:40:25 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue,  1 Apr 2008 07:40:25 +0200
Subject: [U-Boot-Users] [PATCH 2/3] AT91SAM9260EK: Move CONFIG_CMD_NAND to
	Makefile
In-Reply-To: <1207028426-14752-2-git-send-email-plagnioj@jcrosoft.com>
References: <1207028426-14752-1-git-send-email-plagnioj@jcrosoft.com>
	<1207028426-14752-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1207028426-14752-3-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/board/atmel/at91sam9260ek/Makefile b/board/atmel/at91sam9260ek/Makefile
index 309ea46..8a629b9 100644
--- a/board/atmel/at91sam9260ek/Makefile
+++ b/board/atmel/at91sam9260ek/Makefile
@@ -25,10 +25,12 @@ include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(BOARD).a
 
-COBJS	:= at91sam9260ek.o led.o nand.o
+COBJS-y	+= at91sam9260ek.o
+COBJS-y	+= led.o
+COBJS-$(CONFIG_CMD_NAND) += nand.o
 
-SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS	:= $(addprefix $(obj),$(COBJS))
+SRCS	:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS-y))
 SOBJS	:= $(addprefix $(obj),$(SOBJS))
 
 $(LIB):	$(obj).depend $(OBJS) $(SOBJS)
diff --git a/board/atmel/at91sam9260ek/nand.c b/board/atmel/at91sam9260ek/nand.c
index 5131c41..abb788a 100644
--- a/board/atmel/at91sam9260ek/nand.c
+++ b/board/atmel/at91sam9260ek/nand.c
@@ -29,8 +29,6 @@
 #include <asm/arch/gpio.h>
 #include <asm/arch/at91_pio.h>
 
-#ifdef CONFIG_CMD_NAND
-
 #include <nand.h>
 
 /*
@@ -76,4 +74,3 @@ int board_nand_init(struct nand_chip *nand)
 
 	return 0;
 }
-#endif
-- 
1.5.4.1




From plagnioj at jcrosoft.com  Tue Apr  1 07:40:26 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue,  1 Apr 2008 07:40:26 +0200
Subject: [U-Boot-Users] [PATCH 3/3] dataflash: Move CONFIG_HAS_DATAFLASH to
	Makefile
In-Reply-To: <1207028426-14752-3-git-send-email-plagnioj@jcrosoft.com>
References: <1207028426-14752-1-git-send-email-plagnioj@jcrosoft.com>
	<1207028426-14752-2-git-send-email-plagnioj@jcrosoft.com>
	<1207028426-14752-3-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1207028426-14752-4-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 952e919..ff932a1 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -23,17 +23,17 @@
 
 include $(TOPDIR)/config.mk
 
-LIB 	:= $(obj)libmtd.a
+LIB	:= $(obj)libmtd.a
 
 COBJS-y += at45.o
 COBJS-y += cfi_flash.o
-COBJS-y += dataflash.o
+COBJS-$(CONFIG_HAS_DATAFLASH) += dataflash.o
 COBJS-y += mw_eeprom.o
 COBJS-$(CONFIG_FLASH_CFI_LEGACY) += jedec_flash.o
 
 COBJS	:= $(COBJS-y)
-SRCS 	:= $(COBJS:.o=.c)
-OBJS 	:= $(addprefix $(obj),$(COBJS))
+SRCS	:= $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
 
 all:	$(LIB)
 
diff --git a/drivers/mtd/dataflash.c b/drivers/mtd/dataflash.c
index 85cbc5f..d8f78f2 100644
--- a/drivers/mtd/dataflash.c
+++ b/drivers/mtd/dataflash.c
@@ -19,7 +19,6 @@
  */
 #include <common.h>
 #include <config.h>
-#ifdef CONFIG_HAS_DATAFLASH
 #include <asm/hardware.h>
 #include <dataflash.h>
 
@@ -475,5 +474,3 @@ void dataflash_perror (int err)
 		break;
 	}
 }
-
-#endif
-- 
1.5.4.1




From plagnioj at jcrosoft.com  Tue Apr  1 07:40:24 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue,  1 Apr 2008 07:40:24 +0200
Subject: [U-Boot-Users] [PATCH 1/3] AT91SAM9: Move CONFIG_HAS_DATAFLASH to
	Makefile
In-Reply-To: <1207028426-14752-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207028426-14752-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1207028426-14752-2-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/cpu/arm926ejs/at91sam9/Makefile b/cpu/arm926ejs/at91sam9/Makefile
index bf15e1e..203abc2 100644
--- a/cpu/arm926ejs/at91sam9/Makefile
+++ b/cpu/arm926ejs/at91sam9/Makefile
@@ -25,11 +25,14 @@ include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(SOC).a
 
-COBJS	= ether.o timer.o spi.o usb.o
+COBJS-y	+= ether.o
+COBJS-y	+= timer.o
+COBJS-$(CONFIG_HAS_DATAFLASH) +=spi.o
+COBJS-y	+= usb.o
 SOBJS	= lowlevel_init.o
 
-SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
+SRCS    := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS    := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
 
 all:	$(obj).depend $(LIB)
 
diff --git a/cpu/arm926ejs/at91sam9/spi.c b/cpu/arm926ejs/at91sam9/spi.c
index c819608..c9fe6d8 100644
--- a/cpu/arm926ejs/at91sam9/spi.c
+++ b/cpu/arm926ejs/at91sam9/spi.c
@@ -26,7 +26,6 @@
 #include <asm/arch/at91_pio.h>
 #include <asm/arch/at91_spi.h>
 
-#ifdef CONFIG_HAS_DATAFLASH
 #include <dataflash.h>
 
 #define AT91_SPI_PCS0_DATAFLASH_CARD	0xE	/* Chip Select 0: NPCS0%1110 */
@@ -85,6 +84,7 @@ void AT91F_SpiInit(void)
 void AT91F_SpiEnable(int cs)
 {
 	unsigned long mode;
+
 	switch (cs) {
 	case 0:	/* Configure SPI CS0 for Serial DataFlash AT45DBxx */
 		mode = readl(AT91_BASE_SPI + AT91_SPI_MR);
@@ -116,12 +116,10 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc)
 {
 	unsigned int timeout;
 
-
 	pDesc->state = BUSY;
 
 	writel(AT91_SPI_TXTDIS + AT91_SPI_RXTDIS, AT91_BASE_SPI + AT91_SPI_PTCR);
 
-
 	/* Initialize the Transmit and Receive Pointer */
 	writel((unsigned int)pDesc->rx_cmd_pt, AT91_BASE_SPI + AT91_SPI_RPR);
 	writel((unsigned int)pDesc->tx_cmd_pt, AT91_BASE_SPI + AT91_SPI_TPR);
@@ -157,4 +155,3 @@ unsigned int AT91F_SpiWrite(AT91PS_DataflashDesc pDesc)
 
 	return DATAFLASH_OK;
 }
-#endif
-- 
1.5.4.1




From David.Saada at ecitele.com  Tue Apr  1 07:47:38 2008
From: David.Saada at ecitele.com (David Saada)
Date: Tue, 1 Apr 2008 08:47:38 +0300
Subject: [U-Boot-Users] [PATCH][resubmit] QE IO: Add initial data to pin
	configuration + read/write functions
In-Reply-To: <2acbd3e40803311119t32ec22dcmf674fcf3095ef260@mail.gmail.com>
References: <B27D27F93BC429468DBC3B0DA043AA440B2A01@ILPTEX02.ecitele.com>
	<2acbd3e40803311119t32ec22dcmf674fcf3095ef260@mail.gmail.com>
Message-ID: <B27D27F93BC429468DBC3B0DA043AA4401FF2709@ILPTEX02.ecitele.com>

> Any chance you could split out the command code from this?  That's
> really a separate piece of functionality.
Already separated it, as you may have noticed. Will try to resubmit in a
non wrapped way...



From plagnioj at jcrosoft.com  Tue Apr  1 07:51:45 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 1 Apr 2008 07:51:45 +0200
Subject: [U-Boot-Users] AT91 pull request
Message-ID: <20080401055145.GD11802@game.jcrosoft.org>

Please pull u-boot-at91

The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
  Bartlomiej Sieka (1):
        Fix host tool build breakage, take two

are available in the git repository at:

  git://www.denx.de/git/u-boot-at91.git master

David Brownell (2):
      add missing ARM boards to MAKEALL
      use correct at91rm9200 register name

Jean-Christophe PLAGNIOL-VILLARD (5):
      use correct at91rm9200 register name in m501sk board
      AT91CAP9ADK: Move CONFIG_CMD_NAND to Makefile
      AT91SAM9: Move CONFIG_HAS_DATAFLASH to Makefile
      AT91SAM9260EK: Move CONFIG_CMD_NAND to Makefile
      dataflash: Move CONFIG_HAS_DATAFLASH to Makefile

Stelian Pop (9):
      Fix CFG_NO_FLASH compilation.
      Cleanup DataFlash partition handling
      Use timer_init() instead of board supplied interrupt_init()
      Move at91cap9 specific files to at91sam9 directory
      Import several header files from Linux
      Finish header files reworking
      Port AT91CAP9 to the new headers
      Add support for AT91SAM9260EK
      Add maintainership information for AT91CAP9ADK and AT91SAM9260EK boards

 MAINTAINERS                                        |    5 +
 MAKEALL                                            |    4 +
 Makefile                                           |    5 +-
 board/atmel/at91cap9adk/Makefile                   |    8 +-
 board/atmel/at91cap9adk/at91cap9adk.c              |  231 +++++-----
 board/atmel/at91cap9adk/led.c                      |   43 +-
 board/atmel/at91cap9adk/nand.c                     |   11 +-
 .../atmel/at91sam9260ek}/Makefile                  |   24 +-
 board/atmel/at91sam9260ek/at91sam9260ek.c          |  236 +++++++++
 board/atmel/at91sam9260ek/config.mk                |    1 +
 .../ether.c => board/atmel/at91sam9260ek/led.c     |   41 ++-
 board/atmel/at91sam9260ek/nand.c                   |   76 +++
 .../clk.h => board/atmel/at91sam9260ek/u-boot.lds  |   48 ++-
 board/m501sk/memsetup.S                            |    8 +-
 common/cmd_flash.c                                 |   25 +-
 common/cmd_mem.c                                   |    6 +-
 cpu/arm920t/at91rm9200/lowlevel_init.S             |    6 +-
 cpu/arm926ejs/at91cap9/spi.c                       |  119 -----
 cpu/arm926ejs/{at91cap9 => at91sam9}/Makefile      |    9 +-
 cpu/arm926ejs/{at91cap9 => at91sam9}/config.mk     |    0 
 cpu/arm926ejs/{at91cap9 => at91sam9}/ether.c       |    6 +-
 .../{at91cap9 => at91sam9}/lowlevel_init.S         |    2 +-
 cpu/arm926ejs/at91sam9/spi.c                       |  157 ++++++
 cpu/arm926ejs/{at91cap9 => at91sam9}/timer.c       |   32 +-
 cpu/arm926ejs/{at91cap9 => at91sam9}/usb.c         |   12 +-
 cpu/arm926ejs/interrupts.c                         |    2 +-
 drivers/mtd/Makefile                               |    8 +-
 drivers/mtd/dataflash.c                            |   83 +---
 drivers/net/macb.c                                 |    4 +-
 include/asm-arm/arch-at91cap9/AT91CAP9.h           |  518 --------------------
 include/asm-arm/arch-at91cap9/hardware.h           |   38 --
 include/asm-arm/arch-at91sam9/at91_pio.h           |   49 ++
 include/asm-arm/arch-at91sam9/at91_pit.h           |   29 ++
 include/asm-arm/arch-at91sam9/at91_pmc.h           |   99 ++++
 include/asm-arm/arch-at91sam9/at91_rstc.h          |   38 ++
 include/asm-arm/arch-at91sam9/at91_spi.h           |  105 ++++
 include/asm-arm/arch-at91sam9/at91cap9.h           |  125 +++++
 include/asm-arm/arch-at91sam9/at91cap9_matrix.h    |  132 +++++
 include/asm-arm/arch-at91sam9/at91sam9260.h        |  124 +++++
 include/asm-arm/arch-at91sam9/at91sam9260_matrix.h |   78 +++
 include/asm-arm/arch-at91sam9/at91sam926x_mc.h     |  140 ++++++
 .../asm-arm/{arch-at91cap9 => arch-at91sam9}/clk.h |    4 +-
 include/asm-arm/arch-at91sam9/gpio.h               |  366 ++++++++++++++
 include/asm-arm/arch-at91sam9/hardware.h           |   56 +++
 include/asm-arm/arch-at91sam9/io.h                 |   40 ++
 .../{arch-at91cap9 => arch-at91sam9}/memory-map.h  |   10 +-
 include/configs/at91cap9adk.h                      |   61 +--
 include/configs/at91rm9200dk.h                     |    2 +-
 include/configs/at91sam9260ek.h                    |  191 +++++++
 include/configs/cmc_pu2.h                          |    2 +-
 include/configs/csb637.h                           |    2 +-
 include/configs/mp2usb.h                           |    2 +-
 include/dataflash.h                                |    6 +-
 net/eth.c                                          |    6 +-
 54 files changed, 2406 insertions(+), 1029 deletions(-)
 copy {cpu/arm926ejs/at91cap9 => board/atmel/at91sam9260ek}/Makefile (73%)
 create mode 100644 board/atmel/at91sam9260ek/at91sam9260ek.c
 create mode 100644 board/atmel/at91sam9260ek/config.mk
 copy cpu/arm926ejs/at91cap9/ether.c => board/atmel/at91sam9260ek/led.c (56%)
 create mode 100644 board/atmel/at91sam9260ek/nand.c
 copy include/asm-arm/arch-at91cap9/clk.h => board/atmel/at91sam9260ek/u-boot.lds (56%)
 delete mode 100644 cpu/arm926ejs/at91cap9/spi.c
 rename cpu/arm926ejs/{at91cap9 => at91sam9}/Makefile (87%)
 rename cpu/arm926ejs/{at91cap9 => at91sam9}/config.mk (100%)
 rename cpu/arm926ejs/{at91cap9 => at91sam9}/ether.c (89%)
 rename cpu/arm926ejs/{at91cap9 => at91sam9}/lowlevel_init.S (97%)
 create mode 100644 cpu/arm926ejs/at91sam9/spi.c
 rename cpu/arm926ejs/{at91cap9 => at91sam9}/timer.c (84%)
 rename cpu/arm926ejs/{at91cap9 => at91sam9}/usb.c (83%)
 delete mode 100644 include/asm-arm/arch-at91cap9/AT91CAP9.h
 delete mode 100644 include/asm-arm/arch-at91cap9/hardware.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91_pio.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91_pit.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91_pmc.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91_rstc.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91_spi.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91cap9.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91cap9_matrix.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91sam9260.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91sam9260_matrix.h
 create mode 100644 include/asm-arm/arch-at91sam9/at91sam926x_mc.h
 rename include/asm-arm/{arch-at91cap9 => arch-at91sam9}/clk.h (95%)
 create mode 100644 include/asm-arm/arch-at91sam9/gpio.h
 create mode 100644 include/asm-arm/arch-at91sam9/hardware.h
 create mode 100644 include/asm-arm/arch-at91sam9/io.h
 rename include/asm-arm/{arch-at91cap9 => arch-at91sam9}/memory-map.h (85%)
 create mode 100644 include/configs/at91sam9260ek.h

 Best Reagards,
 J.



From David.Saada at ecitele.com  Tue Apr  1 07:54:40 2008
From: David.Saada at ecitele.com (David Saada)
Date: Tue, 1 Apr 2008 08:54:40 +0300
Subject: [U-Boot-Users] [PATCH 3/3] QE IO - Add pario command
In-Reply-To: <20080331201802.8605C248BF@gemini.denx.de>
References: Your message of "Mon, 31 Mar 2008 18:37:48 +0300."
	<B27D27F93BC429468DBC3B0DA043AA4401FF2660@ILPTEX02.ecitele.com>
	<20080331201802.8605C248BF@gemini.denx.de>
Message-ID: <B27D27F93BC429468DBC3B0DA043AA4401FF270D@ILPTEX02.ecitele.com>

> I'm aware of this. Changing register contents seems a useful extension
> to me, too. That's why I wrote "add such code". I think something like

> Print all (or a predefined set of) registers:

 <	=> reg

> Print a specific register:
< 	=> reg name

>Set a specific register to "value":
>	=> reg name value

> would be generally useful, not only for parallel I/O registers.

Specifying parallel I/O ports has whole registers is really
uncomfortable: If for example one would like to write a value to a
parallel I/O port, then he'd need to read the data register first, then
mask off all irrelevant bits, and then write the shifted value to this
register. The pario command does this job in a much more comfortable
way.
Again - we can keep this command in our boards' common code, but I think
it would be a pity, as I think this functionality can be useful for many
other CPU types as well.
David.



From r63238 at freescale.com  Tue Apr  1 07:51:56 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 01 Apr 2008 13:51:56 +0800
Subject: [U-Boot-Users] [PATCH] Add defines to libata (Take three)
In-Reply-To: <1206998773-19223-1-git-send-email-tor@excito.com>
References: <1206998773-19223-1-git-send-email-tor@excito.com>
Message-ID: <1207029116.3676.1.camel@localhost.localdomain>

Thanks Tor,

I will send one new patch including the full set of linux kernel's ata.h
with your signed-off.


On Tue, 2008-04-01 at 05:26 +0800, Tor Krill wrote:
> This patch adds some missing defines to libata.
> Add check power mode command.
> Add obsoleted bits in dev reg
> Add ata command register defines
> 
> Signed-off-by: Tor Krill <tor at excito.com>
> ---
>  include/libata.h |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/include/libata.h b/include/libata.h
> index aedba74..b50af9b 100644
> --- a/include/libata.h
> +++ b/include/libata.h
> @@ -30,6 +30,7 @@
>  enum ata_cmd {
>         /* non-NCQ command */
>         ATA_CMD_DEV_RESET               = 0x08, /* ATAPI device reset
> */
> +       ATA_CMD_CHK_POWER               = 0xE5, /* check power mode */
>         ATA_CMD_FLUSH_CACHE             = 0xE7,
>         ATA_CMD_FLUSH_CACHE_EXT         = 0xEA,
>         ATA_CMD_ID_ATA                  = 0xEC,
> @@ -110,6 +111,7 @@ enum {
>         ATA_HOB                 = (1 << 7),     /* LBA48 selector */
>         ATA_NIEN                = (1 << 1),     /* disable-irq flag */
>         ATA_LBA                 = (1 << 6),     /* LBA28 selector */
> +       ATA_DEVICE_OBS  = (1 << 7) | (1 << 5), /* obs bits in dev reg
> */
>         ATA_DEV1                = (1 << 4),     /* Select Device 1
> (slave) */
>         ATA_BUSY                = (1 << 7),     /* BSY status bit */
>         ATA_DRDY                = (1 << 6),     /* device ready */
> @@ -156,6 +158,26 @@ enum {
>         ATA_UDMA7               = ATA_UDMA6 | (1 << 7),
>  };
> 
> +/* ATA command block registers */
> +enum ata_regs {
> +       ATA_REG_DATA = 0x00,
> +       ATA_REG_ERR = 0x01,
> +       ATA_REG_NSECT = 0x02,
> +       ATA_REG_LBAL = 0x03,
> +       ATA_REG_LBAM = 0x04,
> +       ATA_REG_LBAH = 0x05,
> +       ATA_REG_DEVICE = 0x06,
> +       ATA_REG_STATUS = 0x07,
> +       ATA_PCI_CTL_OFS = 0x02,
> +       /* and their aliases */
> +       ATA_REG_FEATURE = ATA_REG_ERR,
> +       ATA_REG_CMD = ATA_REG_STATUS,
> +       ATA_REG_BYTEL = ATA_REG_LBAM,
> +       ATA_REG_BYTEH = ATA_REG_LBAH,
> +       ATA_REG_DEVSEL = ATA_REG_DEVICE,
> +       ATA_REG_IRQ = ATA_REG_NSECT,           
> +};
> +
>  #define ata_id_is_ata(id)              (((id)[0] & (1 << 15)) == 0)
>  #define ata_id_wcache_enabled(id)      ((id)[85] & (1 << 5))
>  #define ata_id_has_fua(id)             ((id)[84] & (1 << 6))
> --
> 1.5.4.4
> 
> 




From plagnioj at jcrosoft.com  Tue Apr  1 08:39:25 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 1 Apr 2008 08:39:25 +0200
Subject: [U-Boot-Users] LZMA support (patch)
In-Reply-To: <17354.213.156.35.235.1206822105.webmail@webmail.idf-hit.com>
References: <20080328223358.EB0B9248BE@gemini.denx.de>
	<200803282213.12017.vapier@gentoo.org>
	<17354.213.156.35.235.1206822105.webmail@webmail.idf-hit.com>
Message-ID: <20080401063925.GE11802@game.jcrosoft.org>

On 21:21 Sat 29 Mar     , Luigi 'Comio' Mantellini wrote:
> Hi All,
> 
> I will rework the patch in order to include all files from LZMA
> SDK and some fix. I'll send the patch on Tuesday (I'm in
> vacation). These are the implemented features:
> 
> - LZMA SDK 4.57 Decode code (vanilla)
> - A Buff2Buff wrapper to decode the image (LZMA_Alone format)
> - Fixes for mkimage (option -C lzma) and do_bootm
> - small footprint and small impact on the u-boot sources.
> 
> To use the LZMA algorithm: just #define CONFIG_LZMA in your
> board config file.
Please update the README

Best Regards,
J.



From r63238 at freescale.com  Tue Apr  1 09:22:11 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 01 Apr 2008 15:22:11 +0800
Subject: [U-Boot-Users] [PATCH] ata: update the libata.h from ata.h of linux
	kernel
Message-ID: <1207034531.3676.4.camel@localhost.localdomain>

Current libata.h of u-boot is out of sync from linux kernel,
this patch make it be consistent with linux kernel.

Signed-off-by: Dave Liu <daveliu at freescale.com>
Signed-off-by: Tor Krill <tor at excito.com>
---
 drivers/block/fsl_sata.c |   14 +-
 include/libata.h         |  644 +++++++++++++++++++++++++++++++++++++++-------
 2 files changed, 561 insertions(+), 97 deletions(-)

diff --git a/drivers/block/fsl_sata.c b/drivers/block/fsl_sata.c
index 7436c4d..d14f5bc 100644
--- a/drivers/block/fsl_sata.c
+++ b/drivers/block/fsl_sata.c
@@ -600,7 +600,7 @@ static u32 fsl_sata_rw_cmd(int dev, u32 start, u32 blkcnt, u8 *buffer, int is_wr
 
 	cfis->fis_type = SATA_FIS_TYPE_REGISTER_H2D;
 	cfis->pm_port_c = 0x80; /* is command */
-	cfis->command = (is_write) ? ATA_CMD_WRITE_DMA : ATA_CMD_READ_DMA;
+	cfis->command = (is_write) ? ATA_CMD_WRITE : ATA_CMD_READ;
 	cfis->device = ATA_LBA;
 
 	cfis->device |= (block >> 24) & 0xf;
@@ -625,7 +625,7 @@ void fsl_sata_flush_cache(int dev)
 
 	cfis->fis_type = SATA_FIS_TYPE_REGISTER_H2D;
 	cfis->pm_port_c = 0x80; /* is command */
-	cfis->command = ATA_CMD_FLUSH_CACHE;
+	cfis->command = ATA_CMD_FLUSH;
 
 	fsl_sata_exec_cmd(sata, cfis, CMD_ATA, 0, NULL, 0);
 }
@@ -645,8 +645,8 @@ static u32 fsl_sata_rw_cmd_ext(int dev, u32 start, u32 blkcnt, u8 *buffer, int i
 	cfis->fis_type = SATA_FIS_TYPE_REGISTER_H2D;
 	cfis->pm_port_c = 0x80; /* is command */
 
-	cfis->command = (is_write) ? ATA_CMD_WRITE_DMA_EXT
-				 : ATA_CMD_READ_DMA_EXT;
+	cfis->command = (is_write) ? ATA_CMD_WRITE_EXT
+				 : ATA_CMD_READ_EXT;
 
 	cfis->lba_high_exp = (block >> 40) & 0xff;
 	cfis->lba_mid_exp = (block >> 32) & 0xff;
@@ -683,8 +683,8 @@ u32 fsl_sata_rw_ncq_cmd(int dev, u32 start, u32 blkcnt, u8 *buffer, int is_write
 	cfis->fis_type = SATA_FIS_TYPE_REGISTER_H2D;
 	cfis->pm_port_c = 0x80; /* is command */
 
-	cfis->command = (is_write) ? ATA_CMD_WRITE_FPDMA_QUEUED
-				 : ATA_CMD_READ_FPDMA_QUEUED;
+	cfis->command = (is_write) ? ATA_CMD_FPDMA_WRITE
+				 : ATA_CMD_FPDMA_READ;
 
 	cfis->lba_high_exp = (block >> 40) & 0xff;
 	cfis->lba_mid_exp = (block >> 32) & 0xff;
@@ -719,7 +719,7 @@ void fsl_sata_flush_cache_ext(int dev)
 
 	cfis->fis_type = SATA_FIS_TYPE_REGISTER_H2D;
 	cfis->pm_port_c = 0x80; /* is command */
-	cfis->command = ATA_CMD_FLUSH_CACHE_EXT;
+	cfis->command = ATA_CMD_FLUSH_EXT;
 
 	fsl_sata_exec_cmd(sata, cfis, CMD_ATA, 0, NULL, 0);
 }
diff --git a/include/libata.h b/include/libata.h
index aedba74..62a1760 100644
--- a/include/libata.h
+++ b/include/libata.h
@@ -1,4 +1,6 @@
 /*
+ * Copyright 2003-2004 Red Hat, Inc.  All rights reserved.
+ * Copyright 2003-2004 Jeff Garzik
  * Copyright (C) 2008 Freescale Semiconductor, Inc.
  *		Dave Liu <daveliu at freescale.com>
  *		port from libata of linux kernel
@@ -25,33 +27,180 @@
 
 #include <common.h>
 
-/* command
- */
-enum ata_cmd {
-	/* non-NCQ command */
-	ATA_CMD_DEV_RESET		= 0x08, /* ATAPI device reset */
-	ATA_CMD_FLUSH_CACHE		= 0xE7,
-	ATA_CMD_FLUSH_CACHE_EXT		= 0xEA,
-	ATA_CMD_ID_ATA			= 0xEC,
-	ATA_CMD_ID_ATAPI		= 0xA1,
-	ATA_CMD_READ_DMA		= 0xC8,
-	ATA_CMD_READ_DMA_EXT		= 0x25,
-	ATA_CMD_WRITE_DMA		= 0xCA,
-	ATA_CMD_WRITE_DMA_EXT		= 0x35,
-	ATA_CMD_PIO_READ		= 0x20,
-	ATA_CMD_PIO_READ_EXT		= 0x24,
-	ATA_CMD_PIO_WRITE		= 0x30,
-	ATA_CMD_PIO_WRITE_EXT		= 0x34,
-	ATA_CMD_SET_FEATURES		= 0xEF,
-
-	/* NCQ command */
-	ATA_CMD_READ_FPDMA_QUEUED	= 0x60,
-	ATA_CMD_WRITE_FPDMA_QUEUED	= 0x61,
-};
+enum {
+	/* various global constants */
+	ATA_MAX_DEVICES		= 2,	/* per bus/port */
+	ATA_MAX_PRD		= 256,	/* we could make these 256/256 */
+	ATA_SECT_SIZE		= 512,
+	ATA_MAX_SECTORS_128	= 128,
+	ATA_MAX_SECTORS		= 256,
+	ATA_MAX_SECTORS_LBA48	= 65535,
+	ATA_MAX_SECTORS_TAPE	= 65535,
+
+	ATA_ID_WORDS		= 256,
+	ATA_ID_SERNO		= 10,
+	ATA_ID_FW_REV		= 23,
+	ATA_ID_PROD		= 27,
+	ATA_ID_OLD_PIO_MODES	= 51,
+	ATA_ID_FIELD_VALID	= 53,
+	ATA_ID_LBA_SECTORS	= 60,
+	ATA_ID_MWDMA_MODES	= 63,
+	ATA_ID_PIO_MODES	= 64,
+	ATA_ID_EIDE_DMA_MIN	= 65,
+	ATA_ID_EIDE_PIO		= 67,
+	ATA_ID_EIDE_PIO_IORDY	= 68,
+	ATA_ID_PIO4		= (1 << 1),
+	ATA_ID_QUEUE_DEPTH	= 75,
+	ATA_ID_SATA_CAP		= 76,
+	ATA_ID_SATA_FEATURES	= 78,
+	ATA_ID_SATA_FEATURES_EN	= 79,
+	ATA_ID_MAJOR_VER	= 80,
+	ATA_ID_MINOR_VER	= 81,
+	ATA_ID_UDMA_MODES	= 88,
+	ATA_ID_LBA48_SECTORS	= 100,
+
+	ATA_ID_SERNO_LEN	= 20,
+	ATA_ID_FW_REV_LEN	= 8,
+	ATA_ID_PROD_LEN		= 40,
+
+	ATA_PCI_CTL_OFS		= 2,
+
+	ATA_PIO0		= (1 << 0),
+	ATA_PIO1		= ATA_PIO0 | (1 << 1),
+	ATA_PIO2		= ATA_PIO1 | (1 << 2),
+	ATA_PIO3		= ATA_PIO2 | (1 << 3),
+	ATA_PIO4		= ATA_PIO3 | (1 << 4),
+	ATA_PIO5		= ATA_PIO4 | (1 << 5),
+	ATA_PIO6		= ATA_PIO5 | (1 << 6),
+
+	ATA_SWDMA0		= (1 << 0),
+	ATA_SWDMA1		= ATA_SWDMA0 | (1 << 1),
+	ATA_SWDMA2		= ATA_SWDMA1 | (1 << 2),
+
+	ATA_SWDMA2_ONLY		= (1 << 2),
+
+	ATA_MWDMA0		= (1 << 0),
+	ATA_MWDMA1		= ATA_MWDMA0 | (1 << 1),
+	ATA_MWDMA2		= ATA_MWDMA1 | (1 << 2),
+
+	ATA_MWDMA12_ONLY	= (1 << 1) | (1 << 2),
+	ATA_MWDMA2_ONLY		= (1 << 2),
+
+	ATA_UDMA0		= (1 << 0),
+	ATA_UDMA1		= ATA_UDMA0 | (1 << 1),
+	ATA_UDMA2		= ATA_UDMA1 | (1 << 2),
+	ATA_UDMA3		= ATA_UDMA2 | (1 << 3),
+	ATA_UDMA4		= ATA_UDMA3 | (1 << 4),
+	ATA_UDMA5		= ATA_UDMA4 | (1 << 5),
+	ATA_UDMA6		= ATA_UDMA5 | (1 << 6),
+	ATA_UDMA7		= ATA_UDMA6 | (1 << 7),
+	/* ATA_UDMA7 is just for completeness... doesn't exist (yet?).  */
+
+	ATA_UDMA_MASK_40C	= ATA_UDMA2,	/* udma0-2 */
+
+	/* DMA-related */
+	ATA_PRD_SZ		= 8,
+	ATA_PRD_TBL_SZ		= (ATA_MAX_PRD * ATA_PRD_SZ),
+	ATA_PRD_EOT		= (1 << 31),	/* end-of-table flag */
+
+	ATA_DMA_TABLE_OFS	= 4,
+	ATA_DMA_STATUS		= 2,
+	ATA_DMA_CMD		= 0,
+	ATA_DMA_WR		= (1 << 3),
+	ATA_DMA_START		= (1 << 0),
+	ATA_DMA_INTR		= (1 << 2),
+	ATA_DMA_ERR		= (1 << 1),
+	ATA_DMA_ACTIVE		= (1 << 0),
+
+	/* bits in ATA command block registers */
+	ATA_HOB			= (1 << 7),	/* LBA48 selector */
+	ATA_NIEN		= (1 << 1),	/* disable-irq flag */
+	ATA_LBA			= (1 << 6),	/* LBA28 selector */
+	ATA_DEV1		= (1 << 4),	/* Select Device 1 (slave) */
+	ATA_DEVICE_OBS		= (1 << 7) | (1 << 5), /* obs bits in dev reg */
+	ATA_DEVCTL_OBS		= (1 << 3),	/* obsolete bit in devctl reg */
+	ATA_BUSY		= (1 << 7),	/* BSY status bit */
+	ATA_DRDY		= (1 << 6),	/* device ready */
+	ATA_DF			= (1 << 5),	/* device fault */
+	ATA_DRQ			= (1 << 3),	/* data request i/o */
+	ATA_ERR			= (1 << 0),	/* have an error */
+	ATA_SRST		= (1 << 2),	/* software reset */
+	ATA_ICRC		= (1 << 7),	/* interface CRC error */
+	ATA_UNC			= (1 << 6),	/* uncorrectable media error */
+	ATA_IDNF		= (1 << 4),	/* ID not found */
+	ATA_ABORTED		= (1 << 2),	/* command aborted */
+
+	/* ATA command block registers */
+	ATA_REG_DATA		= 0x00,
+	ATA_REG_ERR		= 0x01,
+	ATA_REG_NSECT		= 0x02,
+	ATA_REG_LBAL		= 0x03,
+	ATA_REG_LBAM		= 0x04,
+	ATA_REG_LBAH		= 0x05,
+	ATA_REG_DEVICE		= 0x06,
+	ATA_REG_STATUS		= 0x07,
+
+	ATA_REG_FEATURE		= ATA_REG_ERR, /* and their aliases */
+	ATA_REG_CMD		= ATA_REG_STATUS,
+	ATA_REG_BYTEL		= ATA_REG_LBAM,
+	ATA_REG_BYTEH		= ATA_REG_LBAH,
+	ATA_REG_DEVSEL		= ATA_REG_DEVICE,
+	ATA_REG_IRQ		= ATA_REG_NSECT,
+
+	/* ATA device commands */
+	ATA_CMD_DEV_RESET	= 0x08, /* ATAPI device reset */
+	ATA_CMD_CHK_POWER	= 0xE5, /* check power mode */
+	ATA_CMD_STANDBY		= 0xE2, /* place in standby power mode */
+	ATA_CMD_IDLE		= 0xE3, /* place in idle power mode */
+	ATA_CMD_EDD		= 0x90,	/* execute device diagnostic */
+	ATA_CMD_FLUSH		= 0xE7,
+	ATA_CMD_FLUSH_EXT	= 0xEA,
+	ATA_CMD_ID_ATA		= 0xEC,
+	ATA_CMD_ID_ATAPI	= 0xA1,
+	ATA_CMD_READ		= 0xC8,
+	ATA_CMD_READ_EXT	= 0x25,
+	ATA_CMD_WRITE		= 0xCA,
+	ATA_CMD_WRITE_EXT	= 0x35,
+	ATA_CMD_WRITE_FUA_EXT	= 0x3D,
+	ATA_CMD_FPDMA_READ	= 0x60,
+	ATA_CMD_FPDMA_WRITE	= 0x61,
+	ATA_CMD_PIO_READ	= 0x20,
+	ATA_CMD_PIO_READ_EXT	= 0x24,
+	ATA_CMD_PIO_WRITE	= 0x30,
+	ATA_CMD_PIO_WRITE_EXT	= 0x34,
+	ATA_CMD_READ_MULTI	= 0xC4,
+	ATA_CMD_READ_MULTI_EXT	= 0x29,
+	ATA_CMD_WRITE_MULTI	= 0xC5,
+	ATA_CMD_WRITE_MULTI_EXT	= 0x39,
+	ATA_CMD_WRITE_MULTI_FUA_EXT = 0xCE,
+	ATA_CMD_SET_FEATURES	= 0xEF,
+	ATA_CMD_SET_MULTI	= 0xC6,
+	ATA_CMD_PACKET		= 0xA0,
+	ATA_CMD_VERIFY		= 0x40,
+	ATA_CMD_VERIFY_EXT	= 0x42,
+	ATA_CMD_STANDBYNOW1	= 0xE0,
+	ATA_CMD_IDLEIMMEDIATE	= 0xE1,
+	ATA_CMD_SLEEP		= 0xE6,
+	ATA_CMD_INIT_DEV_PARAMS	= 0x91,
+	ATA_CMD_READ_NATIVE_MAX	= 0xF8,
+	ATA_CMD_READ_NATIVE_MAX_EXT = 0x27,
+	ATA_CMD_SET_MAX		= 0xF9,
+	ATA_CMD_SET_MAX_EXT	= 0x37,
+	ATA_CMD_READ_LOG_EXT	= 0x2f,
+	ATA_CMD_PMP_READ	= 0xE4,
+	ATA_CMD_PMP_WRITE	= 0xE8,
+	ATA_CMD_CONF_OVERLAY	= 0xB1,
+	ATA_CMD_SEC_FREEZE_LOCK	= 0xF5,
+
+	/* READ_LOG_EXT pages */
+	ATA_LOG_SATA_NCQ	= 0x10,
+
+	/* READ/WRITE LONG (obsolete) */
+	ATA_CMD_READ_LONG	= 0x22,
+	ATA_CMD_READ_LONG_ONCE	= 0x23,
+	ATA_CMD_WRITE_LONG	= 0x32,
+	ATA_CMD_WRITE_LONG_ONCE	= 0x33,
 
-/* SETFEATURES stuff
- */
-enum ata_set_features {
 	/* SETFEATURES stuff */
 	SETFEATURES_XFER	= 0x03,
 	XFER_UDMA_7		= 0x47,
@@ -62,13 +211,16 @@ enum ata_set_features {
 	XFER_UDMA_2		= 0x42,
 	XFER_UDMA_1		= 0x41,
 	XFER_UDMA_0		= 0x40,
-	XFER_MW_DMA_4		= 0x24, /* CFA only */
-	XFER_MW_DMA_3		= 0x23, /* CFA only */
+	XFER_MW_DMA_4		= 0x24,	/* CFA only */
+	XFER_MW_DMA_3		= 0x23,	/* CFA only */
 	XFER_MW_DMA_2		= 0x22,
 	XFER_MW_DMA_1		= 0x21,
 	XFER_MW_DMA_0		= 0x20,
-	XFER_PIO_6		= 0x0E, /* CFA only */
-	XFER_PIO_5		= 0x0D, /* CFA only */
+	XFER_SW_DMA_2		= 0x12,
+	XFER_SW_DMA_1		= 0x11,
+	XFER_SW_DMA_0		= 0x10,
+	XFER_PIO_6		= 0x0E,	/* CFA only */
+	XFER_PIO_5		= 0x0D,	/* CFA only */
 	XFER_PIO_4		= 0x0C,
 	XFER_PIO_3		= 0x0B,
 	XFER_PIO_2		= 0x0A,
@@ -80,17 +232,122 @@ enum ata_set_features {
 	SETFEATURES_WC_OFF	= 0x82, /* Disable write cache */
 
 	SETFEATURES_SPINUP	= 0x07, /* Spin-up drive */
+
+	SETFEATURES_SATA_ENABLE = 0x10, /* Enable use of SATA feature */
+	SETFEATURES_SATA_DISABLE = 0x90, /* Disable use of SATA feature */
+
+	/* SETFEATURE Sector counts for SATA features */
+	SATA_AN			= 0x05,  /* Asynchronous Notification */
+	SATA_DIPM		= 0x03,  /* Device Initiated Power Management */
+
+	/* feature values for SET_MAX */
+	ATA_SET_MAX_ADDR	= 0x00,
+	ATA_SET_MAX_PASSWD	= 0x01,
+	ATA_SET_MAX_LOCK	= 0x02,
+	ATA_SET_MAX_UNLOCK	= 0x03,
+	ATA_SET_MAX_FREEZE_LOCK	= 0x04,
+
+	/* feature values for DEVICE CONFIGURATION OVERLAY */
+	ATA_DCO_RESTORE		= 0xC0,
+	ATA_DCO_FREEZE_LOCK	= 0xC1,
+	ATA_DCO_IDENTIFY	= 0xC2,
+	ATA_DCO_SET		= 0xC3,
+
+	/* ATAPI stuff */
+	ATAPI_PKT_DMA		= (1 << 0),
+	ATAPI_DMADIR		= (1 << 2),	/* ATAPI data dir:
+						   0=to device, 1=to host */
+	ATAPI_CDB_LEN		= 16,
+
+	/* PMP stuff */
+	SATA_PMP_MAX_PORTS	= 15,
+	SATA_PMP_CTRL_PORT	= 15,
+
+	SATA_PMP_GSCR_DWORDS	= 128,
+	SATA_PMP_GSCR_PROD_ID	= 0,
+	SATA_PMP_GSCR_REV	= 1,
+	SATA_PMP_GSCR_PORT_INFO	= 2,
+	SATA_PMP_GSCR_ERROR	= 32,
+	SATA_PMP_GSCR_ERROR_EN	= 33,
+	SATA_PMP_GSCR_FEAT	= 64,
+	SATA_PMP_GSCR_FEAT_EN	= 96,
+
+	SATA_PMP_PSCR_STATUS	= 0,
+	SATA_PMP_PSCR_ERROR	= 1,
+	SATA_PMP_PSCR_CONTROL	= 2,
+
+	SATA_PMP_FEAT_BIST	= (1 << 0),
+	SATA_PMP_FEAT_PMREQ	= (1 << 1),
+	SATA_PMP_FEAT_DYNSSC	= (1 << 2),
+	SATA_PMP_FEAT_NOTIFY	= (1 << 3),
+
+	/* cable types */
+	ATA_CBL_NONE		= 0,
+	ATA_CBL_PATA40		= 1,
+	ATA_CBL_PATA80		= 2,
+	ATA_CBL_PATA40_SHORT	= 3,	/* 40 wire cable to high UDMA spec */
+	ATA_CBL_PATA_UNK	= 4,	/* don't know, maybe 80c? */
+	ATA_CBL_PATA_IGN	= 5,	/* don't know, ignore cable handling */
+	ATA_CBL_SATA		= 6,
+
+	/* SATA Status and Control Registers */
+	SCR_STATUS		= 0,
+	SCR_ERROR		= 1,
+	SCR_CONTROL		= 2,
+	SCR_ACTIVE		= 3,
+	SCR_NOTIFICATION	= 4,
+
+	/* SError bits */
+	SERR_DATA_RECOVERED	= (1 << 0), /* recovered data error */
+	SERR_COMM_RECOVERED	= (1 << 1), /* recovered comm failure */
+	SERR_DATA		= (1 << 8), /* unrecovered data error */
+	SERR_PERSISTENT		= (1 << 9), /* persistent data/comm error */
+	SERR_PROTOCOL		= (1 << 10), /* protocol violation */
+	SERR_INTERNAL		= (1 << 11), /* host internal error */
+	SERR_PHYRDY_CHG		= (1 << 16), /* PHY RDY changed */
+	SERR_PHY_INT_ERR	= (1 << 17), /* PHY internal error */
+	SERR_COMM_WAKE		= (1 << 18), /* Comm wake */
+	SERR_10B_8B_ERR		= (1 << 19), /* 10b to 8b decode error */
+	SERR_DISPARITY		= (1 << 20), /* Disparity */
+	SERR_CRC		= (1 << 21), /* CRC error */
+	SERR_HANDSHAKE		= (1 << 22), /* Handshake error */
+	SERR_LINK_SEQ_ERR	= (1 << 23), /* Link sequence error */
+	SERR_TRANS_ST_ERROR	= (1 << 24), /* Transport state trans. error */
+	SERR_UNRECOG_FIS	= (1 << 25), /* Unrecognized FIS */
+	SERR_DEV_XCHG		= (1 << 26), /* device exchanged */
+
+	/* struct ata_taskfile flags */
+	ATA_TFLAG_LBA48		= (1 << 0), /* enable 48-bit LBA and "HOB" */
+	ATA_TFLAG_ISADDR	= (1 << 1), /* enable r/w to nsect/lba regs */
+	ATA_TFLAG_DEVICE	= (1 << 2), /* enable r/w to device reg */
+	ATA_TFLAG_WRITE		= (1 << 3), /* data dir: host->dev==1 (write) */
+	ATA_TFLAG_LBA		= (1 << 4), /* enable LBA */
+	ATA_TFLAG_FUA		= (1 << 5), /* enable FUA */
+	ATA_TFLAG_POLLING	= (1 << 6), /* set nIEN to 1 and use polling */
+
+	/* protocol flags */
+	ATA_PROT_FLAG_PIO	= (1 << 0), /* is PIO */
+	ATA_PROT_FLAG_DMA	= (1 << 1), /* is DMA */
+	ATA_PROT_FLAG_DATA	= ATA_PROT_FLAG_PIO | ATA_PROT_FLAG_DMA,
+	ATA_PROT_FLAG_NCQ	= (1 << 2), /* is NCQ */
+	ATA_PROT_FLAG_ATAPI	= (1 << 3), /* is ATAPI */
 };
 
-enum ata_protocol {
-	ATA_PROT_UNKNOWN,	/* unknown */
+enum ata_tf_protocols {
+	/* ATA taskfile protocols */
+	ATA_PROT_UNKNOWN,	/* unknown/invalid */
 	ATA_PROT_NODATA,	/* no data */
 	ATA_PROT_PIO,		/* PIO data xfer */
 	ATA_PROT_DMA,		/* DMA */
 	ATA_PROT_NCQ,		/* NCQ */
-	ATA_PROT_ATAPI,		/* packet command, PIO data xfer */
-	ATA_PROT_ATAPI_NODATA,	/* packet command, no data */
-	ATA_PROT_ATAPI_DMA,	/* packet command, DMA */
+	ATAPI_PROT_NODATA,	/* packet command, no data */
+	ATAPI_PROT_PIO,		/* packet command, PIO data xfer*/
+	ATAPI_PROT_DMA,		/* packet command with special DMA sauce */
+};
+
+enum ata_ioctls {
+	ATA_IOC_GET_IO32	= 0x309,
+	ATA_IOC_SET_IO32	= 0x324,
 };
 
 enum ata_dev_typed {
@@ -100,73 +357,94 @@ enum ata_dev_typed {
 	ATA_DEV_UNKNOWN,	/* unknown */
 };
 
-enum {
-	ATA_SECT_SIZE		= 512,
-	ATA_MAX_SECTORS_128	= 128,
-	ATA_MAX_SECTORS		= 256,
-	ATA_MAX_SECTORS_LBA48	= 65535,
+struct ata_taskfile {
+	unsigned long		flags;		/* ATA_TFLAG_xxx */
+	u8			protocol;	/* ATA_PROT_xxx */
 
-	/* bits in ATA command block registers */
-	ATA_HOB			= (1 << 7),	/* LBA48 selector */
-	ATA_NIEN		= (1 << 1),	/* disable-irq flag */
-	ATA_LBA			= (1 << 6),	/* LBA28 selector */
-	ATA_DEV1		= (1 << 4),	/* Select Device 1 (slave) */
-	ATA_BUSY		= (1 << 7),	/* BSY status bit */
-	ATA_DRDY		= (1 << 6),	/* device ready */
-	ATA_DF			= (1 << 5),	/* device fault */
-	ATA_DRQ			= (1 << 3),	/* data request i/o */
-	ATA_ERR			= (1 << 0),	/* have an error */
-	ATA_SRST		= (1 << 2),	/* software reset */
-	ATA_ICRC		= (1 << 7),	/* interface CRC error */
-	ATA_UNC			= (1 << 6),	/* uncorrectable media error */
-	ATA_IDNF		= (1 << 4),	/* ID not found */
-	ATA_ABORTED		= (1 << 2),	/* command aborted */
+	u8			ctl;		/* control reg */
 
-	ATA_ID_WORDS		= 256,
-	ATA_ID_SERNO		= 10,
-	ATA_ID_FW_REV		= 23,
-	ATA_ID_PROD		= 27,
-	ATA_ID_FIELD_VALID	= 53,
-	ATA_ID_LBA_SECTORS	= 60,
-	ATA_ID_MWDMA_MODES	= 63,
-	ATA_ID_PIO_MODES	= 64,
-	ATA_ID_QUEUE_DEPTH	= 75,
-	ATA_ID_SATA_CAP		= 76,
-	ATA_ID_SATA_FEATURES	= 78,
-	ATA_ID_SATA_FEATURES_EN	= 79,
-	ATA_ID_MAJOR_VER	= 80,
-	ATA_ID_MINOR_VER	= 81,
-	ATA_ID_UDMA_MODES	= 88,
-	ATA_ID_LBA48_SECTORS	= 100,
+	u8			hob_feature;	/* additional data */
+	u8			hob_nsect;	/* to support LBA48 */
+	u8			hob_lbal;
+	u8			hob_lbam;
+	u8			hob_lbah;
 
-	ATA_ID_SERNO_LEN	= 20,
-	ATA_ID_FW_REV_LEN	= 8,
-	ATA_ID_PROD_LEN		= 40,
+	u8			feature;
+	u8			nsect;
+	u8			lbal;
+	u8			lbam;
+	u8			lbah;
 
-	ATA_PIO3		= (1 << 0),
-	ATA_PIO4		= ATA_PIO3 | (1 << 1),
+	u8			device;
 
-	ATA_UDMA0		= (1 << 0),
-	ATA_UDMA1		= ATA_UDMA0 | (1 << 1),
-	ATA_UDMA2		= ATA_UDMA1 | (1 << 2),
-	ATA_UDMA3		= ATA_UDMA2 | (1 << 3),
-	ATA_UDMA4		= ATA_UDMA3 | (1 << 4),
-	ATA_UDMA5		= ATA_UDMA4 | (1 << 5),
-	ATA_UDMA6		= ATA_UDMA5 | (1 << 6),
-	ATA_UDMA7		= ATA_UDMA6 | (1 << 7),
+	u8			command;	/* IO operation */
 };
 
+/*
+ * protocol tests
+ */
+static inline unsigned int ata_prot_flags(u8 prot)
+{
+	switch (prot) {
+	case ATA_PROT_NODATA:
+		return 0;
+	case ATA_PROT_PIO:
+		return ATA_PROT_FLAG_PIO;
+	case ATA_PROT_DMA:
+		return ATA_PROT_FLAG_DMA;
+	case ATA_PROT_NCQ:
+		return ATA_PROT_FLAG_DMA | ATA_PROT_FLAG_NCQ;
+	case ATAPI_PROT_NODATA:
+		return ATA_PROT_FLAG_ATAPI;
+	case ATAPI_PROT_PIO:
+		return ATA_PROT_FLAG_ATAPI | ATA_PROT_FLAG_PIO;
+	case ATAPI_PROT_DMA:
+		return ATA_PROT_FLAG_ATAPI | ATA_PROT_FLAG_DMA;
+	}
+	return 0;
+}
+
+static inline int ata_is_atapi(u8 prot)
+{
+	return ata_prot_flags(prot) & ATA_PROT_FLAG_ATAPI;
+}
+
+static inline int ata_is_nodata(u8 prot)
+{
+	return !(ata_prot_flags(prot) & ATA_PROT_FLAG_DATA);
+}
+
+static inline int ata_is_pio(u8 prot)
+{
+	return ata_prot_flags(prot) & ATA_PROT_FLAG_PIO;
+}
+
+static inline int ata_is_dma(u8 prot)
+{
+	return ata_prot_flags(prot) & ATA_PROT_FLAG_DMA;
+}
+
+static inline int ata_is_ncq(u8 prot)
+{
+	return ata_prot_flags(prot) & ATA_PROT_FLAG_NCQ;
+}
+
+static inline int ata_is_data(u8 prot)
+{
+	return ata_prot_flags(prot) & ATA_PROT_FLAG_DATA;
+}
+
+/*
+ * id tests
+ */
 #define ata_id_is_ata(id)		(((id)[0] & (1 << 15)) == 0)
-#define ata_id_wcache_enabled(id)	((id)[85] & (1 << 5))
-#define ata_id_has_fua(id)		((id)[84] & (1 << 6))
-#define ata_id_has_flush(id)		((id)[83] & (1 << 12))
-#define ata_id_has_flush_ext(id)	((id)[83] & (1 << 13))
-#define ata_id_has_lba48(id)		((id)[83] & (1 << 10))
-#define ata_id_has_wcache(id)		((id)[82] & (1 << 5))
 #define ata_id_has_lba(id)		((id)[49] & (1 << 9))
 #define ata_id_has_dma(id)		((id)[49] & (1 << 8))
 #define ata_id_has_ncq(id)		((id)[76] & (1 << 8))
 #define ata_id_queue_depth(id)		(((id)[75] & 0x1f) + 1)
+#define ata_id_removeable(id)		((id)[0] & (1 << 7))
+#define ata_id_iordy_disable(id)	((id)[49] & (1 << 10))
+#define ata_id_has_iordy(id)		((id)[49] & (1 << 11))
 
 #define ata_id_u32(id,n)	\
 	(((u32) (id)[(n) + 1] << 16) | ((u32) (id)[(n)]))
@@ -176,6 +454,80 @@ enum {
 	  ((u64) (id)[(n) + 1] << 16) | \
 	  ((u64) (id)[(n) + 0]) )
 
+#define ata_id_cdb_intr(id)		(((id)[0] & 0x60) == 0x20)
+
+static inline int ata_id_has_fua(const u16 *id)
+{
+	if ((id[84] & 0xC000) != 0x4000)
+		return 0;
+	return id[84] & (1 << 6);
+}
+
+static inline int ata_id_has_flush(const u16 *id)
+{
+	if ((id[83] & 0xC000) != 0x4000)
+		return 0;
+	return id[83] & (1 << 12);
+}
+
+static inline int ata_id_has_flush_ext(const u16 *id)
+{
+	if ((id[83] & 0xC000) != 0x4000)
+		return 0;
+	return id[83] & (1 << 13);
+}
+
+static inline int ata_id_has_lba48(const u16 *id)
+{
+	if ((id[83] & 0xC000) != 0x4000)
+		return 0;
+	if (!ata_id_u64(id, 100))
+		return 0;
+	return id[83] & (1 << 10);
+}
+
+static inline int ata_id_hpa_enabled(const u16 *id)
+{
+	/* Yes children, word 83 valid bits cover word 82 data */
+	if ((id[83] & 0xC000) != 0x4000)
+		return 0;
+	/* And 87 covers 85-87 */
+	if ((id[87] & 0xC000) != 0x4000)
+		return 0;
+	/* Check command sets enabled as well as supported */
+	if ((id[85] & ( 1 << 10)) == 0)
+		return 0;
+	return id[82] & (1 << 10);
+}
+
+static inline int ata_id_has_wcache(const u16 *id)
+{
+	/* Yes children, word 83 valid bits cover word 82 data */
+	if ((id[83] & 0xC000) != 0x4000)
+		return 0;
+	return id[82] & (1 << 5);
+}
+
+static inline int ata_id_has_pm(const u16 *id)
+{
+	if ((id[83] & 0xC000) != 0x4000)
+		return 0;
+	return id[82] & (1 << 3);
+}
+
+static inline int ata_id_rahead_enabled(const u16 *id)
+{
+	if ((id[87] & 0xC000) != 0x4000)
+		return 0;
+	return id[85] & (1 << 6);
+}
+
+static inline int ata_id_wcache_enabled(const u16 *id)
+{
+	if ((id[87] & 0xC000) != 0x4000)
+		return 0;
+	return id[85] & (1 << 5);
+}
 
 static inline unsigned int ata_id_major_version(const u16 *id)
 {
@@ -195,6 +547,118 @@ static inline int ata_id_is_sata(const u16 *id)
 	return ata_id_major_version(id) >= 5 && id[93] == 0;
 }
 
+static inline int ata_id_has_tpm(const u16 *id)
+{
+	/* The TPM bits are only valid on ATA8 */
+	if (ata_id_major_version(id) < 8)
+		return 0;
+	if ((id[48] & 0xC000) != 0x4000)
+		return 0;
+	return id[48] & (1 << 0);
+}
+
+static inline int ata_id_has_dword_io(const u16 *id)
+{
+	/* ATA 8 reuses this flag for "trusted" computing */
+	if (ata_id_major_version(id) > 7)
+		return 0;
+	if (id[48] & (1 << 0))
+		return 1;
+	return 0;
+}
+
+static inline int ata_id_current_chs_valid(const u16 *id)
+{
+	/* For ATA-1 devices, if the INITIALIZE DEVICE PARAMETERS command
+	   has not been issued to the device then the values of
+	   id[54] to id[56] are vendor specific. */
+	return (id[53] & 0x01) && /* Current translation valid */
+		id[54] &&  /* cylinders in current translation */
+		id[55] &&  /* heads in current translation */
+		id[55] <= 16 &&
+		id[56];    /* sectors in current translation */
+}
+
+static inline int ata_id_is_cfa(const u16 *id)
+{
+	u16 v = id[0];
+	if (v == 0x848A)	/* Standard CF */
+		return 1;
+	/* Could be CF hiding as standard ATA */
+	if (ata_id_major_version(id) >= 3 &&  id[82] != 0xFFFF &&
+			(id[82] & ( 1 << 2)))
+		return 1;
+	return 0;
+}
+
+static inline int ata_drive_40wire(const u16 *dev_id)
+{
+	if (ata_id_is_sata(dev_id))
+		return 0;	/* SATA */
+	if ((dev_id[93] & 0xE000) == 0x6000)
+		return 0;	/* 80 wire */
+	return 1;
+}
+
+static inline int ata_drive_40wire_relaxed(const u16 *dev_id)
+{
+	if ((dev_id[93] & 0x2000) == 0x2000)
+		return 0;	/* 80 wire */
+	return 1;
+}
+
+static inline int atapi_cdb_len(const u16 *dev_id)
+{
+	u16 tmp = dev_id[0] & 0x3;
+	switch (tmp) {
+	case 0:		return 12;
+	case 1:		return 16;
+	default:	return -1;
+	}
+}
+
+static inline int atapi_command_packet_set(const u16 *dev_id)
+{
+	return (dev_id[0] >> 8) & 0x1f;
+}
+
+static inline int atapi_id_dmadir(const u16 *dev_id)
+{
+	return ata_id_major_version(dev_id) >= 7 && (dev_id[62] & 0x8000);
+}
+
+static inline int is_multi_taskfile(struct ata_taskfile *tf)
+{
+	return (tf->command == ATA_CMD_READ_MULTI) ||
+	       (tf->command == ATA_CMD_WRITE_MULTI) ||
+	       (tf->command == ATA_CMD_READ_MULTI_EXT) ||
+	       (tf->command == ATA_CMD_WRITE_MULTI_EXT) ||
+	       (tf->command == ATA_CMD_WRITE_MULTI_FUA_EXT);
+}
+
+static inline int ata_ok(u8 status)
+{
+	return ((status & (ATA_BUSY | ATA_DRDY | ATA_DF | ATA_DRQ | ATA_ERR))
+			== ATA_DRDY);
+}
+
+static inline int lba_28_ok(u64 block, u32 n_block)
+{
+	/* check the ending block number */
+	return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256);
+}
+
+static inline int lba_48_ok(u64 block, u32 n_block)
+{
+	/* check the ending block number */
+	return ((block + n_block - 1) < ((u64)1 << 48)) && (n_block <= 65536);
+}
+
+#define sata_pmp_gscr_vendor(gscr)	((gscr)[SATA_PMP_GSCR_PROD_ID] & 0xffff)
+#define sata_pmp_gscr_devid(gscr)	((gscr)[SATA_PMP_GSCR_PROD_ID] >> 16)
+#define sata_pmp_gscr_rev(gscr)		(((gscr)[SATA_PMP_GSCR_REV] >> 8) & 0xff)
+#define sata_pmp_gscr_ports(gscr)	((gscr)[SATA_PMP_GSCR_PORT_INFO] & 0xf)
+
 u64 ata_id_n_sectors(u16 *id);
 u32 ata_dev_classify(u32 sig);
 void ata_id_c_string(const u16 *id, unsigned char *s,
-- 
1.5.4.rc4






From r63238 at freescale.com  Tue Apr  1 09:31:03 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 01 Apr 2008 15:31:03 +0800
Subject: [U-Boot-Users] [PATCH] Add defines to libata (Take three)
In-Reply-To: <1206998773-19223-1-git-send-email-tor@excito.com>
References: <1206998773-19223-1-git-send-email-tor@excito.com>
Message-ID: <1207035063.3676.12.camel@localhost.localdomain>

Tor,

I just sent the patch
[PATCH] ata: update the libata.h from ata.h of linux kernel

The patch cover your changes, and is consistent with the latest
ata.h of linux kernel.

Please continue your development with it. Thanks again.

Wolfgang,

Please apply my patch instead of Tor's patch,
I add full set of ata.h of linux to my patch, and add Tor Krill to
Signed-off-by.

Thanks,
Dave

On Tue, 2008-04-01 at 05:26 +0800, Tor Krill wrote:
> This patch adds some missing defines to libata.
> Add check power mode command.
> Add obsoleted bits in dev reg
> Add ata command register defines
> 
> Signed-off-by: Tor Krill <tor at excito.com>
> ---
>  include/libata.h |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/include/libata.h b/include/libata.h
> index aedba74..b50af9b 100644
> --- a/include/libata.h
> +++ b/include/libata.h
> @@ -30,6 +30,7 @@
>  enum ata_cmd {
>         /* non-NCQ command */
>         ATA_CMD_DEV_RESET               = 0x08, /* ATAPI device reset
> */
> +       ATA_CMD_CHK_POWER               = 0xE5, /* check power mode */
>         ATA_CMD_FLUSH_CACHE             = 0xE7,
>         ATA_CMD_FLUSH_CACHE_EXT         = 0xEA,
>         ATA_CMD_ID_ATA                  = 0xEC,
> @@ -110,6 +111,7 @@ enum {
>         ATA_HOB                 = (1 << 7),     /* LBA48 selector */
>         ATA_NIEN                = (1 << 1),     /* disable-irq flag */
>         ATA_LBA                 = (1 << 6),     /* LBA28 selector */
> +       ATA_DEVICE_OBS  = (1 << 7) | (1 << 5), /* obs bits in dev reg
> */
>         ATA_DEV1                = (1 << 4),     /* Select Device 1
> (slave) */
>         ATA_BUSY                = (1 << 7),     /* BSY status bit */
>         ATA_DRDY                = (1 << 6),     /* device ready */
> @@ -156,6 +158,26 @@ enum {
>         ATA_UDMA7               = ATA_UDMA6 | (1 << 7),
>  };
> 
> +/* ATA command block registers */
> +enum ata_regs {
> +       ATA_REG_DATA = 0x00,
> +       ATA_REG_ERR = 0x01,
> +       ATA_REG_NSECT = 0x02,
> +       ATA_REG_LBAL = 0x03,
> +       ATA_REG_LBAM = 0x04,
> +       ATA_REG_LBAH = 0x05,
> +       ATA_REG_DEVICE = 0x06,
> +       ATA_REG_STATUS = 0x07,
> +       ATA_PCI_CTL_OFS = 0x02,
> +       /* and their aliases */
> +       ATA_REG_FEATURE = ATA_REG_ERR,
> +       ATA_REG_CMD = ATA_REG_STATUS,
> +       ATA_REG_BYTEL = ATA_REG_LBAM,
> +       ATA_REG_BYTEH = ATA_REG_LBAH,
> +       ATA_REG_DEVSEL = ATA_REG_DEVICE,
> +       ATA_REG_IRQ = ATA_REG_NSECT,           
> +};
> +
>  #define ata_id_is_ata(id)              (((id)[0] & (1 << 15)) == 0)
>  #define ata_id_wcache_enabled(id)      ((id)[85] & (1 << 5))
>  #define ata_id_has_fua(id)             ((id)[84] & (1 << 6))
> --
> 1.5.4.4
> 
> 




From Sascha.Laue at gmx.biz  Tue Apr  1 09:56:46 2008
From: Sascha.Laue at gmx.biz (Sascha Laue)
Date: Tue, 01 Apr 2008 09:56:46 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification
In-Reply-To: <20080325231838.2D9B2243A7@gemini.denx.de>
References: <20080325231838.2D9B2243A7@gemini.denx.de>
Message-ID: <20080401075646.145810@gmx.net>

Hello Wolfgang,

sorry but it's the first time for me. 
let's try again.

we modified the specification for the lwmon5 board dspic POST.
Additionally I have add defines for the temperature- and voltagevalues.

Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
---
 post/board/lwmon5/sysmon.c |   39 ++++++++++++++++++++++++++++++---------
 1 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
--- a/post/board/lwmon5/sysmon.c
index 0cf1cf2..77e7ea2 100644
+++ b/post/board/lwmon5/sysmon.c
@@ -34,9 +34,9 @@
  * The test passes when all the following voltages and temperatures
  * are within allowed ranges:
  *
- * Temperature		      -40 .. +85 C
- * +5V			    +4.75 .. +5.25 V
- * +5V standby		    +4.75 .. +5.25 V
+ * Temperature		      -40 .. +90 C
+ * +5V			    	+4.50 .. +5.50 V
+ * +5V standby		    +3.50 .. +5.50 V
  *
  * LCD backlight is not enabled if temperature values are not within
  * allowed ranges (-30 .. + 80). The brightness of backlite can be
@@ -62,6 +62,21 @@ extern int dspic_read(ushort reg, ushort *data);
 
 #define	RELOC(x) if (x != NULL) x = (void *) ((ulong) (x) + gd->reloc_off)
 
+#define REG_TEMPERATURE						0x12BC
+#define REG_VOLTAGE_5V						0x12CA
+#define REG_VOLTAGE_5V_STANDBY				0x12C6
+
+#define TEMPERATURE_MIN                     (-40)  /* C */
+#define TEMPERATURE_MAX                     (+90)  /* C */
+#define TEMPERATURE_DISPLAY_MIN             (-35)  /* C */
+#define TEMPERATURE_DISPLAY_MAX             (+85)  /* C */  
+
+#define VOLTAGE_5V_MIN                    (+4500)  /* mV */
+#define VOLTAGE_5V_MAX                    (+5500)  /* mV */
+
+#define VOLTAGE_5V_STANDBY_MIN            (+3500)  /* mV */
+#define VOLTAGE_5V_STANDBY_MAX            (+5500)  /* mV */
+
 typedef struct sysmon_s sysmon_t;
 typedef struct sysmon_table_s sysmon_table_t;
 
@@ -115,16 +130,22 @@ struct sysmon_table_s
 static sysmon_table_t sysmon_table[] =
 {
     {"Temperature", " C", &sysmon_dspic_sgn, NULL, sysmon_backlight_disable,
-     1, 1, -32768, 32767, 0xFFFF, 0x8000-40, 0x8000+85, 0,
-				  0x8000-30, 0x8000+80, 0, 0x12BC},
+     1, 1, -32768, 32767, 0xFFFF, 
+	 0x8000 + TEMPERATURE_MIN, 0x8000 + TEMPERATURE_MAX, 0,
+	 0x8000 + TEMPERATURE_DISPLAY_MIN, 0x8000 + TEMPERATURE_DISPLAY_MAX, 0, 
+	 REG_TEMPERATURE },
 
     {"+ 5 V", "V", &sysmon_dspic, NULL, NULL,
-     100, 1000, 0, 0xFFFF, 0xFFFF, 4750, 5250, 0,
-				   4750, 5250, 0, 0x12CA},
+     100, 1000, 0, 0xFFFF, 0xFFFF, 
+	 VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0,
+	 VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0, 
+	 REG_VOLTAGE_5V },
 
     {"+ 5 V standby", "V", &sysmon_dspic, NULL, NULL,
-     100, 1000, 0, 0xFFFF, 0xFFFF, 4750, 5250, 0,
-				   4750, 5250, 0, 0x12C6},
+     100, 1000, 0, 0xFFFF, 0xFFFF, 
+	 VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX 5250, 0,
+	 VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX, 0, 
+	 REG_VOLTAGE_5V_STANDBY },
 };
 static int sysmon_table_size = sizeof(sysmon_table) / sizeof(sysmon_table[0]);
 
-- 
1.5.2.4

Best regards,
Sascha Laue

-------- Original-Nachricht --------
> Datum: Wed, 26 Mar 2008 00:18:38 +0100
> Von: Wolfgang Denk <wd at denx.de>
> An: "Sascha Laue" <Sascha.Laue at gmx.biz>
> CC: "Markus Klotzb?cher" <mk at denx.de>, saschalaue at gmx.net, u-boot-users at lists.sourceforge.net, marcel.brasch at liebherr.com
> Betreff: Re: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification

> In message <20080320120557.182790 at gmx.net> you wrote:
> > Ups.
> > 
> > Best regards
> > 
> > Sascha Laue
> > 
> > diff -u -r -N u-boot/post/board/lwmon5/sysmon.c
> u-boot-mod/post/board/lwmon=
> > 5/sysmon.c
> 
> Sorry, but this patch does not apply:
> 
> Applying lwmon5: update dsPIC POST spezification
> .dotest/patch:29: trailing whitespace.
> #define TEMPERATURE_DISPLAY_MAX             (+85)  /* ?C */  
> .dotest/patch:46: trailing whitespace.
>      1, 1, -0x8000, 0x7FFF, 0xFFFF, 
> .dotest/patch:48: trailing whitespace.
>      0x8000 + TEMPERATURE_DISPLAY_MIN, 0x8000 +
> TEMPERATURE_DISPLAY_MAX, 0, 
> .dotest/patch:54: trailing whitespace.
>      100, 1000, -0x8000, 0x7FFF, 0xFFFF, 
> .dotest/patch:56: trailing whitespace.
>          0x8000 + VOLTAGE_5V_MIN , 0x8000 + VOLTAGE_5V_MAX, 0, 
> error: patch failed: post/board/lwmon5/sysmon.c:110
> error: post/board/lwmon5/sysmon.c: patch does not apply
> fatal: sha1 information is lacking or useless
> (post/board/lwmon5/sysmon.c).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001.
> 
> 
> Please cleanup the code (whitespace issues), and use git-format-patch
> and git-send-email to post a clean, usable patch.
> 
> 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: wd at denx.de
> A failure will not appear until a unit has passed final inspection.



From Sascha.Laue at gmx.biz  Tue Apr  1 09:59:41 2008
From: Sascha.Laue at gmx.biz (Sascha Laue)
Date: Tue, 01 Apr 2008 09:59:41 +0200
Subject: [U-Boot-Users] [PATCH] bugfix: the watchdog post for lwmon5
Message-ID: <20080401075941.145820@gmx.net>

bugfix: the watchdog post for lwmon5 doesn't work. This Patch fix it.
To trigger and activate the watchdog correct it is necessary to create 2 pulses.
Lowpegel on GPIO62 point to a voltagefailure.

Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
---
 post/board/lwmon5/watchdog.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/post/board/lwmon5/watchdog.c b/post/board/lwmon5/watchdog.c
index 48ff687..014aae4 100644
--- a/post/board/lwmon5/watchdog.c
+++ b/post/board/lwmon5/watchdog.c
@@ -55,7 +55,7 @@ static void watchdog_magic_write(uint value)
 
 int sysmon1_post_test(int flags)
 {
-	if (gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {
+	if (0 == gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {
 		/*
 		 * 3.1. GPIO62 is low
 		 * Assuming system voltage failure.
@@ -99,6 +99,9 @@ int lwmon5_watchdog_post_test(int flags)
 		ints = disable_interrupts ();
 		/* 3.2.2. strobe watchdog once */
 		WATCHDOG_RESET();
+		base = post_time_ms (0);
+		while (post_time_ms (base) < 2)
+		WATCHDOG_RESET();
 		out_be32((void *)CFG_WATCHDOG_TIME_ADDR, 0);
 		/* 3.2.3. save time of strobe in scratch register 2 */
 		base = post_time_ms (0);
-- 
1.5.2.4



From tur at semihalf.com  Tue Apr  1 10:00:19 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Tue, 01 Apr 2008 10:00:19 +0200
Subject: [U-Boot-Users] Current U-Boot doesn't boot device tree enabled
 kernel anymore
In-Reply-To: <20080327162552.808F3242FC@gemini.denx.de>
References: <20080327162552.808F3242FC@gemini.denx.de>
Message-ID: <47F1EB93.9060502@semihalf.com>

Wolfgang Denk wrote:
> Dear Bartek,
[...]
> Please check if there were - for example - merge problems, i.  e.  if
> the code is indeed correct.

Dear Wolfgang,

I have verified the code relevant to the overwrite checks reported by
Stefan, as well as checked size increase when enabling new format,
between the new-image branch, and the current master, and it looks like
the merge went OK.

Regards,
Bartlomiej



From Sascha.Laue at gmx.biz  Tue Apr  1 10:10:18 2008
From: Sascha.Laue at gmx.biz (Sascha Laue)
Date: Tue, 01 Apr 2008 10:10:18 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification
In-Reply-To: <20080401075646.145810@gmx.net>
References: <20080325231838.2D9B2243A7@gemini.denx.de>
	<20080401075646.145810@gmx.net>
Message-ID: <20080401081018.145800@gmx.net>

Hello Wolfgang,

sorry but it's the first time for me.
I'm so sorry but there is an error in my last mail, let's try again.

we modified the specification for the lwmon5 board dspic POST.
Additionally I have add defines for the temperature- and voltagevalues.

Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
---
 post/board/lwmon5/sysmon.c |   39 ++++++++++++++++++++++++++++++---------
 1 files changed, 30 insertions(+), 9 deletions(-)

diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
--- a/post/board/lwmon5/sysmon.c
index 0cf1cf2..77e7ea2 100644
+++ b/post/board/lwmon5/sysmon.c
@@ -34,9 +34,9 @@
  * The test passes when all the following voltages and temperatures
  * are within allowed ranges:
  *
- * Temperature              -40 .. +85 C
- * +5V                +4.75 .. +5.25 V
- * +5V standby            +4.75 .. +5.25 V
+ * Temperature              -40 .. +90 C
+ * +5V                    +4.50 .. +5.50 V
+ * +5V standby            +3.50 .. +5.50 V
  *
  * LCD backlight is not enabled if temperature values are not within
  * allowed ranges (-30 .. + 80). The brightness of backlite can be
@@ -62,6 +62,21 @@ extern int dspic_read(ushort reg, ushort *data);
 
 #define    RELOC(x) if (x != NULL) x = (void *) ((ulong) (x) + gd->reloc_off)
 
+#define REG_TEMPERATURE                        0x12BC
+#define REG_VOLTAGE_5V                        0x12CA
+#define REG_VOLTAGE_5V_STANDBY                0x12C6
+
+#define TEMPERATURE_MIN                     (-40)  /* C */
+#define TEMPERATURE_MAX                     (+90)  /* C */
+#define TEMPERATURE_DISPLAY_MIN             (-35)  /* C */
+#define TEMPERATURE_DISPLAY_MAX             (+85)  /* C */  
+
+#define VOLTAGE_5V_MIN                    (+4500)  /* mV */
+#define VOLTAGE_5V_MAX                    (+5500)  /* mV */
+
+#define VOLTAGE_5V_STANDBY_MIN            (+3500)  /* mV */
+#define VOLTAGE_5V_STANDBY_MAX            (+5500)  /* mV */
+
 typedef struct sysmon_s sysmon_t;
 typedef struct sysmon_table_s sysmon_table_t;
 
@@ -115,16 +130,22 @@ struct sysmon_table_s
 static sysmon_table_t sysmon_table[] =
 {
     {"Temperature", " C", &sysmon_dspic_sgn, NULL, sysmon_backlight_disable,
-     1, 1, -32768, 32767, 0xFFFF, 0x8000-40, 0x8000+85, 0,
-                  0x8000-30, 0x8000+80, 0, 0x12BC},
+     1, 1, -32768, 32767, 0xFFFF,
+     0x8000 + TEMPERATURE_MIN, 0x8000 + TEMPERATURE_MAX, 0,
+     0x8000 + TEMPERATURE_DISPLAY_MIN, 0x8000 + TEMPERATURE_DISPLAY_MAX, 0,
+     REG_TEMPERATURE },
 
     {"+ 5 V", "V", &sysmon_dspic, NULL, NULL,
-     100, 1000, 0, 0xFFFF, 0xFFFF, 4750, 5250, 0,
-                   4750, 5250, 0, 0x12CA},
+     100, 1000, 0, 0xFFFF, 0xFFFF,
+     VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0,
+     VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0,
+     REG_VOLTAGE_5V },
 
     {"+ 5 V standby", "V", &sysmon_dspic, NULL, NULL,
-     100, 1000, 0, 0xFFFF, 0xFFFF, 4750, 5250, 0,
-                   4750, 5250, 0, 0x12C6},
+     100, 1000, 0, 0xFFFF, 0xFFFF,
+     VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX, 0,
+     VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX, 0,
+     REG_VOLTAGE_5V_STANDBY },
 };
 static int sysmon_table_size = sizeof(sysmon_table) / sizeof(sysmon_table[0]);
 
-- 
1.5.2.4

Best regards,
Sascha Laue

-------- Original-Nachricht --------
> Datum: Wed, 26 Mar 2008 00:18:38 +0100
> Von: Wolfgang Denk <wd at denx.de>
> An: "Sascha Laue" <Sascha.Laue at gmx.biz>
> CC: "Markus Klotzb?cher" <mk at denx.de>, saschalaue at gmx.net, u-boot-users at lists.sourceforge.net, marcel.brasch at liebherr.com
> Betreff: Re: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification

> In message <20080320120557.182790 at gmx.net> you wrote:
> > Ups.
> >
> > Best regards
> >
> > Sascha Laue
> >
> > diff -u -r -N u-boot/post/board/lwmon5/sysmon.c
> u-boot-mod/post/board/lwmon=
> > 5/sysmon.c
>
> Sorry, but this patch does not apply:
>
> Applying lwmon5: update dsPIC POST spezification
> .dotest/patch:29: trailing whitespace.
> #define TEMPERATURE_DISPLAY_MAX             (+85)  /* ?C */  
> .dotest/patch:46: trailing whitespace.
>      1, 1, -0x8000, 0x7FFF, 0xFFFF,
> .dotest/patch:48: trailing whitespace.
>      0x8000 + TEMPERATURE_DISPLAY_MIN, 0x8000 +
> TEMPERATURE_DISPLAY_MAX, 0,
> .dotest/patch:54: trailing whitespace.
>      100, 1000, -0x8000, 0x7FFF, 0xFFFF,
> .dotest/patch:56: trailing whitespace.
>          0x8000 + VOLTAGE_5V_MIN , 0x8000 + VOLTAGE_5V_MAX, 0,
> error: patch failed: post/board/lwmon5/sysmon.c:110
> error: post/board/lwmon5/sysmon.c: patch does not apply
> fatal: sha1 information is lacking or useless
> (post/board/lwmon5/sysmon.c).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001.
>
>
> Please cleanup the code (whitespace issues), and use git-format-patch
> and git-send-email to post a clean, usable patch.
>
> 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: wd at denx.de
> A failure will not appear until a unit has passed final inspection.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

-------- Original-Nachricht --------
> Datum: Tue, 01 Apr 2008 09:56:46 +0200
> Von: "Sascha Laue" <Sascha.Laue at gmx.biz>
> An: Wolfgang Denk <wd at denx.de>
> CC: u-boot-users at lists.sourceforge.net, marcel.brasch at liebherr.com, mk at denx.de
> Betreff: Re: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification

> Hello Wolfgang,
> 
> sorry but it's the first time for me. 
> let's try again.
> 
> we modified the specification for the lwmon5 board dspic POST.
> Additionally I have add defines for the temperature- and voltagevalues.
> 
> Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> ---
>  post/board/lwmon5/sysmon.c |   39 ++++++++++++++++++++++++++++++---------
>  1 files changed, 30 insertions(+), 9 deletions(-)
> 
> diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
> --- a/post/board/lwmon5/sysmon.c
> index 0cf1cf2..77e7ea2 100644
> +++ b/post/board/lwmon5/sysmon.c
> @@ -34,9 +34,9 @@
>   * The test passes when all the following voltages and temperatures
>   * are within allowed ranges:
>   *
> - * Temperature		      -40 .. +85 C
> - * +5V			    +4.75 .. +5.25 V
> - * +5V standby		    +4.75 .. +5.25 V
> + * Temperature		      -40 .. +90 C
> + * +5V			    	+4.50 .. +5.50 V
> + * +5V standby		    +3.50 .. +5.50 V
>   *
>   * LCD backlight is not enabled if temperature values are not within
>   * allowed ranges (-30 .. + 80). The brightness of backlite can be
> @@ -62,6 +62,21 @@ extern int dspic_read(ushort reg, ushort *data);
>  
>  #define	RELOC(x) if (x != NULL) x = (void *) ((ulong) (x) +
> gd->reloc_off)
>  
> +#define REG_TEMPERATURE						0x12BC
> +#define REG_VOLTAGE_5V						0x12CA
> +#define REG_VOLTAGE_5V_STANDBY				0x12C6
> +
> +#define TEMPERATURE_MIN                     (-40)  /* C */
> +#define TEMPERATURE_MAX                     (+90)  /* C */
> +#define TEMPERATURE_DISPLAY_MIN             (-35)  /* C */
> +#define TEMPERATURE_DISPLAY_MAX             (+85)  /* C */  
> +
> +#define VOLTAGE_5V_MIN                    (+4500)  /* mV */
> +#define VOLTAGE_5V_MAX                    (+5500)  /* mV */
> +
> +#define VOLTAGE_5V_STANDBY_MIN            (+3500)  /* mV */
> +#define VOLTAGE_5V_STANDBY_MAX            (+5500)  /* mV */
> +
>  typedef struct sysmon_s sysmon_t;
>  typedef struct sysmon_table_s sysmon_table_t;
>  
> @@ -115,16 +130,22 @@ struct sysmon_table_s
>  static sysmon_table_t sysmon_table[] =
>  {
>      {"Temperature", " C", &sysmon_dspic_sgn, NULL,
> sysmon_backlight_disable,
> -     1, 1, -32768, 32767, 0xFFFF, 0x8000-40, 0x8000+85, 0,
> -				  0x8000-30, 0x8000+80, 0, 0x12BC},
> +     1, 1, -32768, 32767, 0xFFFF, 
> +	 0x8000 + TEMPERATURE_MIN, 0x8000 + TEMPERATURE_MAX, 0,
> +	 0x8000 + TEMPERATURE_DISPLAY_MIN, 0x8000 + TEMPERATURE_DISPLAY_MAX, 0, 
> +	 REG_TEMPERATURE },
>  
>      {"+ 5 V", "V", &sysmon_dspic, NULL, NULL,
> -     100, 1000, 0, 0xFFFF, 0xFFFF, 4750, 5250, 0,
> -				   4750, 5250, 0, 0x12CA},
> +     100, 1000, 0, 0xFFFF, 0xFFFF, 
> +	 VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0,
> +	 VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0, 
> +	 REG_VOLTAGE_5V },
>  
>      {"+ 5 V standby", "V", &sysmon_dspic, NULL, NULL,
> -     100, 1000, 0, 0xFFFF, 0xFFFF, 4750, 5250, 0,
> -				   4750, 5250, 0, 0x12C6},
> +     100, 1000, 0, 0xFFFF, 0xFFFF, 
> +	 VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX 5250, 0,
> +	 VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX, 0, 
> +	 REG_VOLTAGE_5V_STANDBY },
>  };
>  static int sysmon_table_size = sizeof(sysmon_table) /
> sizeof(sysmon_table[0]);
>  
> -- 
> 1.5.2.4
> 
> Best regards,
> Sascha Laue
> 
> -------- Original-Nachricht --------
> > Datum: Wed, 26 Mar 2008 00:18:38 +0100
> > Von: Wolfgang Denk <wd at denx.de>
> > An: "Sascha Laue" <Sascha.Laue at gmx.biz>
> > CC: "Markus Klotzb?cher" <mk at denx.de>, saschalaue at gmx.net,
> u-boot-users at lists.sourceforge.net, marcel.brasch at liebherr.com
> > Betreff: Re: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification
> 
> > In message <20080320120557.182790 at gmx.net> you wrote:
> > > Ups.
> > > 
> > > Best regards
> > > 
> > > Sascha Laue
> > > 
> > > diff -u -r -N u-boot/post/board/lwmon5/sysmon.c
> > u-boot-mod/post/board/lwmon=
> > > 5/sysmon.c
> > 
> > Sorry, but this patch does not apply:
> > 
> > Applying lwmon5: update dsPIC POST spezification
> > .dotest/patch:29: trailing whitespace.
> > #define TEMPERATURE_DISPLAY_MAX             (+85)  /* ?C */  
> > .dotest/patch:46: trailing whitespace.
> >      1, 1, -0x8000, 0x7FFF, 0xFFFF, 
> > .dotest/patch:48: trailing whitespace.
> >      0x8000 + TEMPERATURE_DISPLAY_MIN, 0x8000 +
> > TEMPERATURE_DISPLAY_MAX, 0, 
> > .dotest/patch:54: trailing whitespace.
> >      100, 1000, -0x8000, 0x7FFF, 0xFFFF, 
> > .dotest/patch:56: trailing whitespace.
> >          0x8000 + VOLTAGE_5V_MIN , 0x8000 + VOLTAGE_5V_MAX, 0, 
> > error: patch failed: post/board/lwmon5/sysmon.c:110
> > error: post/board/lwmon5/sysmon.c: patch does not apply
> > fatal: sha1 information is lacking or useless
> > (post/board/lwmon5/sysmon.c).
> > Repository lacks necessary blobs to fall back on 3-way merge.
> > Cannot fall back to three-way merge.
> > Patch failed at 0001.
> > 
> > 
> > Please cleanup the code (whitespace issues), and use git-format-patch
> > and git-send-email to post a clean, usable patch.
> > 
> > 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: wd at denx.de
> > A failure will not appear until a unit has passed final inspection.
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users



From wd at denx.de  Tue Apr  1 10:33:20 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 01 Apr 2008 10:33:20 +0200
Subject: [U-Boot-Users] [PATCH] bugfix: the watchdog post for lwmon5
In-Reply-To: Your message of "Tue, 01 Apr 2008 09:59:41 +0200."
	<20080401075941.145820@gmx.net>
Message-ID: <20080401083320.B918D24544@gemini.denx.de>

In message <20080401075941.145820 at gmx.net> you wrote:
> bugfix: the watchdog post for lwmon5 doesn't work. This Patch fix it.
> To trigger and activate the watchdog correct it is necessary to create 2 pulses.
> Lowpegel on GPIO62 point to a voltagefailure.

Please fix English ("correct", "Lowpegel", "voltagefailure").

Is it really 2 pulses - or just one, consisting of 

> Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
...
> -	if (gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {
> +	if (0 == gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {

Please write that as:

	if (gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS) == 0) {
or
	if (!gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {

>  		 * 3.1. GPIO62 is low
>  		 * Assuming system voltage failure.
> @@ -99,6 +99,9 @@ int lwmon5_watchdog_post_test(int flags)
>  		ints = disable_interrupts ();
>  		/* 3.2.2. strobe watchdog once */
>  		WATCHDOG_RESET();
> +		base = post_time_ms (0);
> +		while (post_time_ms (base) < 2)
> +		WATCHDOG_RESET();

Are you absolutely sure that is needed?

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: wd at denx.de
Tactical? TACTICAL!?!? Hey, buddy, we went from kilotons to  megatons
several  minutes  ago.  We don't need no stinkin' tactical nukes. (By
the way, do you have change for 10 million people?)           - lwall



From luigi.mantellini at idf-hit.com  Tue Apr  1 11:26:38 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Tue, 01 Apr 2008 11:26:38 +0200
Subject: [U-Boot-Users] RFC: make new image support mandatory
In-Reply-To: <47EA7A6C.3050301@semihalf.com>
References: <20080326141644.D180D243A7@gemini.denx.de>
	<20080326164102.58905a27@hskinnemo-gx620.norway.atmel.com>
	<47EA7A6C.3050301@semihalf.com>
Message-ID: <1207041998.12115.8.camel@localhost>

Hi Bartlomiej,

I posted a week ago some considerations about the new image format (with
subject ?"?[U-Boot-Users] New Image format: headers hashes."). Please,
can you give an your opinion about these consideration? I'm really
interested to support new image in my firmwares, but I need to
understand if the new format is "robust" respect to the accidental
errors.

Thanks a lot for your work and your answers on the ml.

Ciao

luigi
?

-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080401/9287a5d6/attachment.htm 

From tur at semihalf.com  Tue Apr  1 11:40:24 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Tue, 01 Apr 2008 11:40:24 +0200
Subject: [U-Boot-Users] RFC: make new image support mandatory
In-Reply-To: <1207041998.12115.8.camel@localhost>
References: <20080326141644.D180D243A7@gemini.denx.de>	
	<20080326164102.58905a27@hskinnemo-gx620.norway.atmel.com>	
	<47EA7A6C.3050301@semihalf.com>
	<1207041998.12115.8.camel@localhost>
Message-ID: <47F20308.5050007@semihalf.com>

Luigi 'Comio' Mantellini wrote:
> Hi Bartlomiej,
> 
> I posted a week ago some considerations about the new image format (with
> subject "[U-Boot-Users] New Image format: headers hashes."). Please,
> can you give an your opinion about these consideration? I'm really
> interested to support new image in my firmwares, but I need to
> understand if the new format is "robust" respect to the accidental
> errors.
> 
> Thanks a lot for your work and your answers on the ml.

Hi Luigi,

Sorry for being slow to respond -- I'm processing ML comments on the new
image, and will reply to your postings today/tomorrow.

Regards,
Bartlomiej



From wd at denx.de  Tue Apr  1 11:58:58 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 01 Apr 2008 11:58:58 +0200
Subject: [U-Boot-Users] [PATCH 3/3] QE IO - Add pario command
In-Reply-To: Your message of "Tue, 01 Apr 2008 08:54:40 +0300."
	<B27D27F93BC429468DBC3B0DA043AA4401FF270D@ILPTEX02.ecitele.com>
Message-ID: <20080401095858.AFE4D2476E@gemini.denx.de>

In message <B27D27F93BC429468DBC3B0DA043AA4401FF270D at ILPTEX02.ecitele.com> you wrote:
> > I'm aware of this. Changing register contents seems a useful extension
> > to me, too. That's why I wrote "add such code". I think something like
> 
> > Print all (or a predefined set of) registers:
> 
>  <	=> reg
> 
> > Print a specific register:
> < 	=> reg name
> 
> >Set a specific register to "value":
> >	=> reg name value
> 
> > would be generally useful, not only for parallel I/O registers.
> 
> Specifying parallel I/O ports has whole registers is really
> uncomfortable: If for example one would like to write a value to a
> parallel I/O port, then he'd need to read the data register first, then
> mask off all irrelevant bits, and then write the shifted value to this
> register. The pario command does this job in a much more comfortable
> way.

Nothing prevents you to write your code such that  "name"  is  not  a
register  name  but  a  parallel  port  name,  and that the code that
handles it does exactly what you describe above transparently for the
user.

> Again - we can keep this command in our boards' common code, but I think
> it would be a pity, as I think this functionality can be useful for many
> other CPU types as well.

Agreed.

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: wd at denx.de
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
                                                      -- Isaac Asimov



From wd at denx.de  Tue Apr  1 13:32:37 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 01 Apr 2008 13:32:37 +0200
Subject: [U-Boot-Users] [PATCH] bugfix: the watchdog post for lwmon5
In-Reply-To: Your message of "Tue, 01 Apr 2008 10:33:20 +0200."
	<20080401083320.B918D24544@gemini.denx.de>
Message-ID: <20080401113237.50CEB2476E@gemini.denx.de>

In message <20080401083320.B918D24544 at gemini.denx.de> I wrote:
>
> >  		/* 3.2.2. strobe watchdog once */
> >  		WATCHDOG_RESET();
> > +		base = post_time_ms (0);
> > +		while (post_time_ms (base) < 2)
> > +		WATCHDOG_RESET();
> 
> Are you absolutely sure that is needed?

Maybe I should have been more explicit - note that above code with
correct indentation looks like this:

  		/* 3.2.2. strobe watchdog once */
  		WATCHDOG_RESET();
		base = post_time_ms (0);
		while (post_time_ms (base) < 2)
			WATCHDOG_RESET();

I. e. the comment "once" is wrong - you trigger the watchdog many more
times that you probably think.

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: wd at denx.de
Witch!  Witch!  They'll burn ya!
	-- Hag, "Tomorrow is Yesterday", stardate unknown



From luigi.mantellini at idf-hit.com  Tue Apr  1 11:18:09 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Tue, 01 Apr 2008 11:18:09 +0200
Subject: [U-Boot-Users] [PATCH] Add support for LZMA uncompression algorithm.
Message-ID: <1207041489.12115.2.camel@localhost>

---
 Makefile                   |    1 +
 README                     |   23 ++
 common/cmd_bootm.c         |   23 ++
 common/image.c             |    7 +-
 include/image.h            |    1 +
 include/lzma/LzmaDecode.h  |   31 ++
 include/lzma/LzmaTools.h   |   31 ++
 include/lzma/LzmaTypes.h   |   31 ++
 lib_lzma/LGPL.txt          |  504 +++++++++++++++++++++++++++++++++
 lib_lzma/LzmaDecode.c      |  584 ++++++++++++++++++++++++++++++++++++++
 lib_lzma/LzmaDecode.h      |  113 ++++++++
 lib_lzma/LzmaTools.c       |  143 ++++++++++
 lib_lzma/LzmaTools.h       |   35 +++
 lib_lzma/LzmaTypes.h       |   45 +++
 lib_lzma/Makefile          |   51 ++++
 lib_lzma/README.txt        |   28 ++
 lib_lzma/history.txt       |  198 +++++++++++++
 lib_lzma/import_lzmasdk.sh |   38 +++
 lib_lzma/lzma.txt          |  663 ++++++++++++++++++++++++++++++++++++++++++++
 19 files changed, 2548 insertions(+), 2 deletions(-)
 create mode 100644 include/lzma/LzmaDecode.h
 create mode 100644 include/lzma/LzmaTools.h
 create mode 100644 include/lzma/LzmaTypes.h
 create mode 100644 lib_lzma/LGPL.txt
 create mode 100644 lib_lzma/LzmaDecode.c
 create mode 100644 lib_lzma/LzmaDecode.h
 create mode 100644 lib_lzma/LzmaTools.c
 create mode 100644 lib_lzma/LzmaTools.h
 create mode 100644 lib_lzma/LzmaTypes.h
 create mode 100644 lib_lzma/Makefile
 create mode 100644 lib_lzma/README.txt
 create mode 100644 lib_lzma/history.txt
 create mode 100644 lib_lzma/import_lzmasdk.sh
 create mode 100644 lib_lzma/lzma.txt

diff --git a/Makefile b/Makefile
index 4255cf5..03b16e2 100644
--- a/Makefile
+++ b/Makefile
@@ -192,6 +192,7 @@ endif
 OBJS := $(addprefix $(obj),$(OBJS))
 
 LIBS  = lib_generic/libgeneric.a
+LIBS += lib_lzma/lib_lzma.a
 LIBS += $(shell if [ -f board/$(VENDOR)/common/Makefile ]; then echo \
 	"board/$(VENDOR)/common/lib$(VENDOR).a"; fi)
 LIBS += board/$(BOARDDIR)/lib$(BOARD).a
diff --git a/README b/README
index 5cbe7c1..d568e8a 100644
--- a/README
+++ b/README
@@ -1038,6 +1038,29 @@ The following options need to be configured:
 		the malloc area (as defined by CFG_MALLOC_LEN) should
 		be at least 4MB.
 
+		CONFIG_LZMA
+
+		If this option is set, support for lzma compressed
+		images is included.
+
+		Note: The LZMA algorithm adds about 2KB of code and it
+		requires an amount of dynamic memory that is given by the
+		formula:
+
+		         (1846 + 768 << (lc + lp)) * sizeof(uint16)
+
+		Where lc and lp stand for, respectively, Literal context bits
+		and Literal pos bits.
+
+		This value is upper-bounded by 14MB in the worst case. Anyway,
+		for a ~4MB large kernel image, we have lc=3 and lp=0 for a
+		total amount of (1846 + 768 << (3 + 0)) * 2 = ~41KB... that is
+		a very small buffer.
+                
+		Use the lzmainfo tool to determinate the lc and lp values and
+		then calculate the  amount of needed dynamic memory (ensuring
+		the appropriate CFG_MALLOC_LEN value).
+
 - MII/PHY support:
 		CONFIG_PHY_ADDR
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9e5ce4b..ba6de50 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -40,6 +40,13 @@
 #include <hush.h>
 #endif
 
+#ifdef CONFIG_LZMA
+#define _7ZIP_BYTE_DEFINED /* Byte already defined by zlib */
+#include <lzma/LzmaTypes.h>
+#include <lzma/LzmaDecode.h>
+#include <lzma/LzmaTools.h>
+#endif /* CONFIG_LZMA */
+
 DECLARE_GLOBAL_DATA_PTR;
 
 extern int gunzip (void *dst, int dstlen, unsigned char *src, unsigned long *lenp);
@@ -271,6 +278,22 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		load_end = load_start + unc_len;
 		break;
 #endif /* CONFIG_BZIP2 */
+#ifdef CONFIG_LZMA
+	case IH_COMP_LZMA:
+		printf ("   Uncompressing %s ... ", type_name);
+
+		int ret = lzmaBuffToBuffDecompress(
+			(unsigned char *)load_start, &unc_len,
+			(unsigned char *)os_data, os_len);
+		if (ret != LZMA_RESULT_OK) {
+			printf ("LZMA: uncompress or overwrite error %d "
+				"- must RESET board to recover\n", ret);
+			show_boot_progress (-6);
+			do_reset (cmdtp, flag, argc, argv);
+		}
+		load_end = load_start + unc_len;
+		break;
+#endif /* CONFIG_LZMA */
 	default:
 		if (iflag)
 			enable_interrupts();
diff --git a/common/image.c b/common/image.c
index f04826a..d358095 100644
--- a/common/image.c
+++ b/common/image.c
@@ -152,6 +152,9 @@ static table_entry_t uimage_comp[] = {
 	{	IH_COMP_NONE,	"none",		"uncompressed",		},
 	{	IH_COMP_BZIP2,	"bzip2",	"bzip2 compressed",	},
 	{	IH_COMP_GZIP,	"gzip",		"gzip compressed",	},
+#if defined(CONFIG_LZMA) || defined(USE_HOSTCC)
+	{	IH_COMP_LZMA,	"lzma",		"lzma compressed",	},
+#endif
 	{	-1,		"",		"",			},
 };
 
@@ -1950,7 +1953,7 @@ static int calculate_hash (const void *data, int data_len, const char *algo,
 	return 0;
 }
 
-#ifdef USE_HOSTCC
+// #ifdef USE_HOSTCC
 /**
  * fit_set_hashes - process FIT component image nodes and calculate hashes
  * @fit: pointer to the FIT format image header
@@ -2119,7 +2122,7 @@ int fit_image_hash_set_value (void *fit, int noffset, uint8_t *value,
 
 	return 0;
 }
-#endif /* USE_HOSTCC */
+// #endif /* USE_HOSTCC */
 
 /**
  * fit_image_check_hashes - verify data intergity
diff --git a/include/image.h b/include/image.h
index 36143e2..0126284 100644
--- a/include/image.h
+++ b/include/image.h
@@ -164,6 +164,7 @@
 #define IH_COMP_NONE		0	/*  No	 Compression Used	*/
 #define IH_COMP_GZIP		1	/* gzip	 Compression Used	*/
 #define IH_COMP_BZIP2		2	/* bzip2 Compression Used	*/
+#define IH_COMP_LZMA		3	/* lzma  Compression Used	*/
 
 #define IH_MAGIC	0x27051956	/* Image Magic Number		*/
 #define IH_NMLEN		32	/* Image Name Length		*/
diff --git a/include/lzma/LzmaDecode.h b/include/lzma/LzmaDecode.h
new file mode 100644
index 0000000..5e96fbf
--- /dev/null
+++ b/include/lzma/LzmaDecode.h
@@ -0,0 +1,31 @@
+/*
+ * Fake include for LzmaDecode.h
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+ 
+#ifndef __LZMADECODE_H__FAKE__
+#define __LZMADECODE_H__FAKE__
+
+#include "../../lib_lzma/LzmaDecode.h"
+
+#endif
diff --git a/include/lzma/LzmaTools.h b/include/lzma/LzmaTools.h
new file mode 100644
index 0000000..bf6df55
--- /dev/null
+++ b/include/lzma/LzmaTools.h
@@ -0,0 +1,31 @@
+/*
+ * Fake include for LzmaTools.h
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+ 
+#ifndef __LZMATOOLS_H__FAKE__
+#define __LZMATOOLS_H__FAKE__
+ 
+#include "../../lib_lzma/LzmaTools.h"
+ 
+#endif
diff --git a/include/lzma/LzmaTypes.h b/include/lzma/LzmaTypes.h
new file mode 100644
index 0000000..073d16e
--- /dev/null
+++ b/include/lzma/LzmaTypes.h
@@ -0,0 +1,31 @@
+/*
+ * Fake include for LzmaTypes.h
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+ 
+#ifndef __LZMATYPES_H__FAKE__
+#define __LZMATYPES_H__FAKE__
+ 
+#include "../../lib_lzma/LzmaTypes.h"
+ 
+#endif
diff --git a/lib_lzma/LGPL.txt b/lib_lzma/LGPL.txt
new file mode 100644
index 0000000..f3926a6
--- /dev/null
+++ b/lib_lzma/LGPL.txt
@@ -0,0 +1,504 @@
+      GNU LESSER GENERAL PUBLIC LICENSE
+           Version 2.1, February 1999
+
+ Copyright (C) 1991, 1999 Free Software Foundation, Inc.
+     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+[This is the first released version of the Lesser GPL.  It also counts
+ as the successor of the GNU Library Public License, version 2, hence
+ the version number 2.1.]
+
+          Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+Licenses are intended to guarantee your freedom to share and change
+free software--to make sure the software is free for all its users.
+
+  This license, the Lesser General Public License, applies to some
+specially designated software packages--typically libraries--of the
+Free Software Foundation and other authors who decide to use it.  You
+can use it too, but we suggest you first think carefully about whether
+this license or the ordinary General Public License is the better
+strategy to use in any particular case, based on the explanations below.
+
+  When we speak of free software, we are referring to freedom of use,
+not price.  Our General Public Licenses are designed to make sure that
+you have the freedom to distribute copies of free software (and charge
+for this service if you wish); that you receive source code or can get
+it if you want it; that you can change the software and use pieces of
+it in new free programs; and that you are informed that you can do
+these things.
+
+  To protect your rights, we need to make restrictions that forbid
+distributors to deny you these rights or to ask you to surrender these
+rights.  These restrictions translate to certain responsibilities for
+you if you distribute copies of the library or if you modify it.
+
+  For example, if you distribute copies of the library, whether gratis
+or for a fee, you must give the recipients all the rights that we gave
+you.  You must make sure that they, too, receive or can get the source
+code.  If you link other code with the library, you must provide
+complete object files to the recipients, so that they can relink them
+with the library after making changes to the library and recompiling
+it.  And you must show them these terms so they know their rights.
+
+  We protect your rights with a two-step method: (1) we copyright the
+library, and (2) we offer you this license, which gives you legal
+permission to copy, distribute and/or modify the library.
+
+  To protect each distributor, we want to make it very clear that
+there is no warranty for the free library.  Also, if the library is
+modified by someone else and passed on, the recipients should know
+that what they have is not the original version, so that the original
+author's reputation will not be affected by problems that might be
+introduced by others.
+
+  Finally, software patents pose a constant threat to the existence of
+any free program.  We wish to make sure that a company cannot
+effectively restrict the users of a free program by obtaining a
+restrictive license from a patent holder.  Therefore, we insist that
+any patent license obtained for a version of the library must be
+consistent with the full freedom of use specified in this license.
+
+  Most GNU software, including some libraries, is covered by the
+ordinary GNU General Public License.  This license, the GNU Lesser
+General Public License, applies to certain designated libraries, and
+is quite different from the ordinary General Public License.  We use
+this license for certain libraries in order to permit linking those
+libraries into non-free programs.
+
+  When a program is linked with a library, whether statically or using
+a shared library, the combination of the two is legally speaking a
+combined work, a derivative of the original library.  The ordinary
+General Public License therefore permits such linking only if the
+entire combination fits its criteria of freedom.  The Lesser General
+Public License permits more lax criteria for linking other code with
+the library.
+
+  We call this license the "Lesser" General Public License because it
+does Less to protect the user's freedom than the ordinary General
+Public License.  It also provides other free software developers Less
+of an advantage over competing non-free programs.  These disadvantages
+are the reason we use the ordinary General Public License for many
+libraries.  However, the Lesser license provides advantages in certain
+special circumstances.
+
+  For example, on rare occasions, there may be a special need to
+encourage the widest possible use of a certain library, so that it becomes
+a de-facto standard.  To achieve this, non-free programs must be
+allowed to use the library.  A more frequent case is that a free
+library does the same job as widely used non-free libraries.  In this
+case, there is little to gain by limiting the free library to free
+software only, so we use the Lesser General Public License.
+
+  In other cases, permission to use a particular library in non-free
+programs enables a greater number of people to use a large body of
+free software.  For example, permission to use the GNU C Library in
+non-free programs enables many more people to use the whole GNU
+operating system, as well as its variant, the GNU/Linux operating
+system.
+
+  Although the Lesser General Public License is Less protective of the
+users' freedom, it does ensure that the user of a program that is
+linked with the Library has the freedom and the wherewithal to run
+that program using a modified version of the Library.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.  Pay close attention to the difference between a
+"work based on the library" and a "work that uses the library".  The
+former contains code derived from the library, whereas the latter must
+be combined with the library in order to run.
+
+      GNU LESSER GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License Agreement applies to any software library or other
+program which contains a notice placed by the copyright holder or
+other authorized party saying it may be distributed under the terms of
+this Lesser General Public License (also called "this License").
+Each licensee is addressed as "you".
+
+  A "library" means a collection of software functions and/or data
+prepared so as to be conveniently linked with application programs
+(which use some of those functions and data) to form executables.
+
+  The "Library", below, refers to any such software library or work
+which has been distributed under these terms.  A "work based on the
+Library" means either the Library or any derivative work under
+copyright law: that is to say, a work containing the Library or a
+portion of it, either verbatim or with modifications and/or translated
+straightforwardly into another language.  (Hereinafter, translation is
+included without limitation in the term "modification".)
+
+  "Source code" for a work means the preferred form of the work for
+making modifications to it.  For a library, complete source code means
+all the source code for all modules it contains, plus any associated
+interface definition files, plus the scripts used to control compilation
+and installation of the library.
+
+  Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running a program using the Library is not restricted, and output from
+such a program is covered only if its contents constitute a work based
+on the Library (independent of the use of the Library in a tool for
+writing it).  Whether that is true depends on what the Library does
+and what the program that uses the Library does.
+  
+  1. You may copy and distribute verbatim copies of the Library's
+complete source code as you receive it, in any medium, provided that
+you conspicuously and appropriately publish on each copy an
+appropriate copyright notice and disclaimer of warranty; keep intact
+all the notices that refer to this License and to the absence of any
+warranty; and distribute a copy of this License along with the
+Library.
+
+  You may charge a fee for the physical act of transferring a copy,
+and you may at your option offer warranty protection in exchange for a
+fee.
+
+  2. You may modify your copy or copies of the Library or any portion
+of it, thus forming a work based on the Library, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) The modified work must itself be a software library.
+
+    b) You must cause the files modified to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    c) You must cause the whole of the work to be licensed at no
+    charge to all third parties under the terms of this License.
+
+    d) If a facility in the modified Library refers to a function or a
+    table of data to be supplied by an application program that uses
+    the facility, other than as an argument passed when the facility
+    is invoked, then you must make a good faith effort to ensure that,
+    in the event an application does not supply such function or
+    table, the facility still operates, and performs whatever part of
+    its purpose remains meaningful.
+
+    (For example, a function in a library to compute square roots has
+    a purpose that is entirely well-defined independent of the
+    application.  Therefore, Subsection 2d requires that any
+    application-supplied function or table used by this function must
+    be optional: if the application does not supply it, the square
+    root function must still compute square roots.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Library,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Library, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote
+it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Library.
+
+In addition, mere aggregation of another work not based on the Library
+with the Library (or with a work based on the Library) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may opt to apply the terms of the ordinary GNU General Public
+License instead of this License to a given copy of the Library.  To do
+this, you must alter all the notices that refer to this License, so
+that they refer to the ordinary GNU General Public License, version 2,
+instead of to this License.  (If a newer version than version 2 of the
+ordinary GNU General Public License has appeared, then you can specify
+that version instead if you wish.)  Do not make any other change in
+these notices.
+
+  Once this change is made in a given copy, it is irreversible for
+that copy, so the ordinary GNU General Public License applies to all
+subsequent copies and derivative works made from that copy.
+
+  This option is useful when you wish to copy part of the code of
+the Library into a program that is not a library.
+
+  4. You may copy and distribute the Library (or a portion or
+derivative of it, under Section 2) in object code or executable form
+under the terms of Sections 1 and 2 above provided that you accompany
+it with the complete corresponding machine-readable source code, which
+must be distributed under the terms of Sections 1 and 2 above on a
+medium customarily used for software interchange.
+
+  If distribution of object code is made by offering access to copy
+from a designated place, then offering equivalent access to copy the
+source code from the same place satisfies the requirement to
+distribute the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  5. A program that contains no derivative of any portion of the
+Library, but is designed to work with the Library by being compiled or
+linked with it, is called a "work that uses the Library".  Such a
+work, in isolation, is not a derivative work of the Library, and
+therefore falls outside the scope of this License.
+
+  However, linking a "work that uses the Library" with the Library
+creates an executable that is a derivative of the Library (because it
+contains portions of the Library), rather than a "work that uses the
+library".  The executable is therefore covered by this License.
+Section 6 states terms for distribution of such executables.
+
+  When a "work that uses the Library" uses material from a header file
+that is part of the Library, the object code for the work may be a
+derivative work of the Library even though the source code is not.
+Whether this is true is especially significant if the work can be
+linked without the Library, or if the work is itself a library.  The
+threshold for this to be true is not precisely defined by law.
+
+  If such an object file uses only numerical parameters, data
+structure layouts and accessors, and small macros and small inline
+functions (ten lines or less in length), then the use of the object
+file is unrestricted, regardless of whether it is legally a derivative
+work.  (Executables containing this object code plus portions of the
+Library will still fall under Section 6.)
+
+  Otherwise, if the work is a derivative of the Library, you may
+distribute the object code for the work under the terms of Section 6.
+Any executables containing that work also fall under Section 6,
+whether or not they are linked directly with the Library itself.
+
+  6. As an exception to the Sections above, you may also combine or
+link a "work that uses the Library" with the Library to produce a
+work containing portions of the Library, and distribute that work
+under terms of your choice, provided that the terms permit
+modification of the work for the customer's own use and reverse
+engineering for debugging such modifications.
+
+  You must give prominent notice with each copy of the work that the
+Library is used in it and that the Library and its use are covered by
+this License.  You must supply a copy of this License.  If the work
+during execution displays copyright notices, you must include the
+copyright notice for the Library among them, as well as a reference
+directing the user to the copy of this License.  Also, you must do one
+of these things:
+
+    a) Accompany the work with the complete corresponding
+    machine-readable source code for the Library including whatever
+    changes were used in the work (which must be distributed under
+    Sections 1 and 2 above); and, if the work is an executable linked
+    with the Library, with the complete machine-readable "work that
+    uses the Library", as object code and/or source code, so that the
+    user can modify the Library and then relink to produce a modified
+    executable containing the modified Library.  (It is understood
+    that the user who changes the contents of definitions files in the
+    Library will not necessarily be able to recompile the application
+    to use the modified definitions.)
+
+    b) Use a suitable shared library mechanism for linking with the
+    Library.  A suitable mechanism is one that (1) uses at run time a
+    copy of the library already present on the user's computer system,
+    rather than copying library functions into the executable, and (2)
+    will operate properly with a modified version of the library, if
+    the user installs one, as long as the modified version is
+    interface-compatible with the version that the work was made with.
+
+    c) Accompany the work with a written offer, valid for at
+    least three years, to give the same user the materials
+    specified in Subsection 6a, above, for a charge no more
+    than the cost of performing this distribution.
+
+    d) If distribution of the work is made by offering access to copy
+    from a designated place, offer equivalent access to copy the above
+    specified materials from the same place.
+
+    e) Verify that the user has already received a copy of these
+    materials or that you have already sent this user a copy.
+
+  For an executable, the required form of the "work that uses the
+Library" must include any data and utility programs needed for
+reproducing the executable from it.  However, as a special exception,
+the materials to be distributed need not include anything that is
+normally distributed (in either source or binary form) with the major
+components (compiler, kernel, and so on) of the operating system on
+which the executable runs, unless that component itself accompanies
+the executable.
+
+  It may happen that this requirement contradicts the license
+restrictions of other proprietary libraries that do not normally
+accompany the operating system.  Such a contradiction means you cannot
+use both them and the Library together in an executable that you
+distribute.
+
+  7. You may place library facilities that are a work based on the
+Library side-by-side in a single library together with other library
+facilities not covered by this License, and distribute such a combined
+library, provided that the separate distribution of the work based on
+the Library and of the other library facilities is otherwise
+permitted, and provided that you do these two things:
+
+    a) Accompany the combined library with a copy of the same work
+    based on the Library, uncombined with any other library
+    facilities.  This must be distributed under the terms of the
+    Sections above.
+
+    b) Give prominent notice with the combined library of the fact
+    that part of it is a work based on the Library, and explaining
+    where to find the accompanying uncombined form of the same work.
+
+  8. You may not copy, modify, sublicense, link with, or distribute
+the Library except as expressly provided under this License.  Any
+attempt otherwise to copy, modify, sublicense, link with, or
+distribute the Library is void, and will automatically terminate your
+rights under this License.  However, parties who have received copies,
+or rights, from you under this License will not have their licenses
+terminated so long as such parties remain in full compliance.
+
+  9. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Library or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Library (or any work based on the
+Library), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Library or works based on it.
+
+  10. Each time you redistribute the Library (or any work based on the
+Library), the recipient automatically receives a license from the
+original licensor to copy, distribute, link with or modify the Library
+subject to these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties with
+this License.
+
+  11. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Library at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Library by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Library.
+
+If any portion of this section is held invalid or unenforceable under any
+particular circumstance, the balance of the section is intended to apply,
+and the section as a whole is intended to apply in other circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  12. If the distribution and/or use of the Library is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Library under this License may add
+an explicit geographical distribution limitation excluding those countries,
+so that distribution is permitted only in or among countries not thus
+excluded.  In such case, this License incorporates the limitation as if
+written in the body of this License.
+
+  13. The Free Software Foundation may publish revised and/or new
+versions of the Lesser General Public License from time to time.
+Such new versions will be similar in spirit to the present version,
+but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Library
+specifies a version number of this License which applies to it and
+"any later version", you have the option of following the terms and
+conditions either of that version or of any later version published by
+the Free Software Foundation.  If the Library does not specify a
+license version number, you may choose any version ever published by
+the Free Software Foundation.
+
+  14. If you wish to incorporate parts of the Library into other free
+programs whose distribution conditions are incompatible with these,
+write to the author to ask for permission.  For software which is
+copyrighted by the Free Software Foundation, write to the Free
+Software Foundation; we sometimes make exceptions for this.  Our
+decision will be guided by the two goals of preserving the free status
+of all derivatives of our free software and of promoting the sharing
+and reuse of software generally.
+
+          NO WARRANTY
+
+  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
+WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
+OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
+KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
+LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
+THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
+AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
+FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
+LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
+RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
+FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
+SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGES.
+
+         END OF TERMS AND CONDITIONS
+
+           How to Apply These Terms to Your New Libraries
+
+  If you develop a new library, and you want it to be of the greatest
+possible use to the public, we recommend making it free software that
+everyone can redistribute and change.  You can do so by permitting
+redistribution under these terms (or, alternatively, under the terms of the
+ordinary General Public License).
+
+  To apply these terms, attach the following notices to the library.  It is
+safest to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the library's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This library is free software; you can redistribute it and/or
+    modify it under the terms of the GNU Lesser General Public
+    License as published by the Free Software Foundation; either
+    version 2.1 of the License, or (at your option) any later version.
+
+    This library 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
+    Lesser General Public License for more details.
+
+    You should have received a copy of the GNU Lesser General Public
+    License along with this library; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+
+Also add information on how to contact you by electronic and paper mail.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the library, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the
+  library `Frob' (a library for tweaking knobs) written by James Random Hacker.
+
+  <signature of Ty Coon>, 1 April 1990
+  Ty Coon, President of Vice
+
+That's all there is to it!
+
+
diff --git a/lib_lzma/LzmaDecode.c b/lib_lzma/LzmaDecode.c
new file mode 100644
index 0000000..71c62c4
--- /dev/null
+++ b/lib_lzma/LzmaDecode.c
@@ -0,0 +1,584 @@
+/*
+  LzmaDecode.c
+  LZMA Decoder (optimized for Speed version)
+  
+  LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
+  http://www.7-zip.org/
+
+  LZMA SDK is licensed under two licenses:
+  1) GNU Lesser General Public License (GNU LGPL)
+  2) Common Public License (CPL)
+  It means that you can select one of these two licenses and 
+  follow rules of that license.
+
+  SPECIAL EXCEPTION:
+  Igor Pavlov, as the author of this Code, expressly permits you to 
+  statically or dynamically link your Code (or bind by name) to the 
+  interfaces of this file without subjecting your linked Code to the 
+  terms of the CPL or GNU LGPL. Any modifications or additions 
+  to this file, however, are subject to the LGPL or CPL terms.
+*/
+
+#include "LzmaDecode.h"
+
+#define kNumTopBits 24
+#define kTopValue ((UInt32)1 << kNumTopBits)
+
+#define kNumBitModelTotalBits 11
+#define kBitModelTotal (1 << kNumBitModelTotalBits)
+#define kNumMoveBits 5
+
+#define RC_READ_BYTE (*Buffer++)
+
+#define RC_INIT2 Code = 0; Range = 0xFFFFFFFF; \
+  { int i; for(i = 0; i < 5; i++) { RC_TEST; Code = (Code << 8) | RC_READ_BYTE; }}
+
+#ifdef _LZMA_IN_CB
+
+#define RC_TEST { if (Buffer == BufferLim) \
+  { SizeT size; int result = InCallback->Read(InCallback, &Buffer, &size); if (result != LZMA_RESULT_OK) return result; \
+  BufferLim = Buffer + size; if (size == 0) return LZMA_RESULT_DATA_ERROR; }}
+
+#define RC_INIT Buffer = BufferLim = 0; RC_INIT2
+
+#else
+
+#define RC_TEST { if (Buffer == BufferLim) return LZMA_RESULT_DATA_ERROR; }
+
+#define RC_INIT(buffer, bufferSize) Buffer = buffer; BufferLim = buffer + bufferSize; RC_INIT2
+ 
+#endif
+
+#define RC_NORMALIZE if (Range < kTopValue) { RC_TEST; Range <<= 8; Code = (Code << 8) | RC_READ_BYTE; }
+
+#define IfBit0(p) RC_NORMALIZE; bound = (Range >> kNumBitModelTotalBits) * *(p); if (Code < bound)
+#define UpdateBit0(p) Range = bound; *(p) += (kBitModelTotal - *(p)) >> kNumMoveBits;
+#define UpdateBit1(p) Range -= bound; Code -= bound; *(p) -= (*(p)) >> kNumMoveBits;
+
+#define RC_GET_BIT2(p, mi, A0, A1) IfBit0(p) \
+  { UpdateBit0(p); mi <<= 1; A0; } else \
+  { UpdateBit1(p); mi = (mi + mi) + 1; A1; } 
+  
+#define RC_GET_BIT(p, mi) RC_GET_BIT2(p, mi, ; , ;)               
+
+#define RangeDecoderBitTreeDecode(probs, numLevels, res) \
+  { int i = numLevels; res = 1; \
+  do { CProb *p = probs + res; RC_GET_BIT(p, res) } while(--i != 0); \
+  res -= (1 << numLevels); }
+
+
+#define kNumPosBitsMax 4
+#define kNumPosStatesMax (1 << kNumPosBitsMax)
+
+#define kLenNumLowBits 3
+#define kLenNumLowSymbols (1 << kLenNumLowBits)
+#define kLenNumMidBits 3
+#define kLenNumMidSymbols (1 << kLenNumMidBits)
+#define kLenNumHighBits 8
+#define kLenNumHighSymbols (1 << kLenNumHighBits)
+
+#define LenChoice 0
+#define LenChoice2 (LenChoice + 1)
+#define LenLow (LenChoice2 + 1)
+#define LenMid (LenLow + (kNumPosStatesMax << kLenNumLowBits))
+#define LenHigh (LenMid + (kNumPosStatesMax << kLenNumMidBits))
+#define kNumLenProbs (LenHigh + kLenNumHighSymbols) 
+
+
+#define kNumStates 12
+#define kNumLitStates 7
+
+#define kStartPosModelIndex 4
+#define kEndPosModelIndex 14
+#define kNumFullDistances (1 << (kEndPosModelIndex >> 1))
+
+#define kNumPosSlotBits 6
+#define kNumLenToPosStates 4
+
+#define kNumAlignBits 4
+#define kAlignTableSize (1 << kNumAlignBits)
+
+#define kMatchMinLen 2
+
+#define IsMatch 0
+#define IsRep (IsMatch + (kNumStates << kNumPosBitsMax))
+#define IsRepG0 (IsRep + kNumStates)
+#define IsRepG1 (IsRepG0 + kNumStates)
+#define IsRepG2 (IsRepG1 + kNumStates)
+#define IsRep0Long (IsRepG2 + kNumStates)
+#define PosSlot (IsRep0Long + (kNumStates << kNumPosBitsMax))
+#define SpecPos (PosSlot + (kNumLenToPosStates << kNumPosSlotBits))
+#define Align (SpecPos + kNumFullDistances - kEndPosModelIndex)
+#define LenCoder (Align + kAlignTableSize)
+#define RepLenCoder (LenCoder + kNumLenProbs)
+#define Literal (RepLenCoder + kNumLenProbs)
+
+#if Literal != LZMA_BASE_SIZE
+StopCompilingDueBUG
+#endif
+
+int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size)
+{
+  unsigned char prop0;
+  if (size < LZMA_PROPERTIES_SIZE)
+    return LZMA_RESULT_DATA_ERROR;
+  prop0 = propsData[0];
+  if (prop0 >= (9 * 5 * 5))
+    return LZMA_RESULT_DATA_ERROR;
+  {
+    for (propsRes->pb = 0; prop0 >= (9 * 5); propsRes->pb++, prop0 -= (9 * 5));
+    for (propsRes->lp = 0; prop0 >= 9; propsRes->lp++, prop0 -= 9);
+    propsRes->lc = prop0;
+    /*
+    unsigned char remainder = (unsigned char)(prop0 / 9);
+    propsRes->lc = prop0 % 9;
+    propsRes->pb = remainder / 5;
+    propsRes->lp = remainder % 5;
+    */
+  }
+
+  #ifdef _LZMA_OUT_READ
+  {
+    int i;
+    propsRes->DictionarySize = 0;
+    for (i = 0; i < 4; i++)
+      propsRes->DictionarySize += (UInt32)(propsData[1 + i]) << (i * 8);
+    if (propsRes->DictionarySize == 0)
+      propsRes->DictionarySize = 1;
+  }
+  #endif
+  return LZMA_RESULT_OK;
+}
+
+#define kLzmaStreamWasFinishedId (-1)
+
+int LzmaDecode(CLzmaDecoderState *vs,
+    #ifdef _LZMA_IN_CB
+    ILzmaInCallback *InCallback,
+    #else
+    const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
+    #endif
+    unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed)
+{
+  CProb *p = vs->Probs;
+  SizeT nowPos = 0;
+  Byte previousByte = 0;
+  UInt32 posStateMask = (1 << (vs->Properties.pb)) - 1;
+  UInt32 literalPosMask = (1 << (vs->Properties.lp)) - 1;
+  int lc = vs->Properties.lc;
+
+  #ifdef _LZMA_OUT_READ
+  
+  UInt32 Range = vs->Range;
+  UInt32 Code = vs->Code;
+  #ifdef _LZMA_IN_CB
+  const Byte *Buffer = vs->Buffer;
+  const Byte *BufferLim = vs->BufferLim;
+  #else
+  const Byte *Buffer = inStream;
+  const Byte *BufferLim = inStream + inSize;
+  #endif
+  int state = vs->State;
+  UInt32 rep0 = vs->Reps[0], rep1 = vs->Reps[1], rep2 = vs->Reps[2], rep3 = vs->Reps[3];
+  int len = vs->RemainLen;
+  UInt32 globalPos = vs->GlobalPos;
+  UInt32 distanceLimit = vs->DistanceLimit;
+
+  Byte *dictionary = vs->Dictionary;
+  UInt32 dictionarySize = vs->Properties.DictionarySize;
+  UInt32 dictionaryPos = vs->DictionaryPos;
+
+  Byte tempDictionary[4];
+
+  #ifndef _LZMA_IN_CB
+  *inSizeProcessed = 0;
+  #endif
+  *outSizeProcessed = 0;
+  if (len == kLzmaStreamWasFinishedId)
+    return LZMA_RESULT_OK;
+
+  if (dictionarySize == 0)
+  {
+    dictionary = tempDictionary;
+    dictionarySize = 1;
+    tempDictionary[0] = vs->TempDictionary[0];
+  }
+
+  if (len == kLzmaNeedInitId)
+  {
+    {
+      UInt32 numProbs = Literal + ((UInt32)LZMA_LIT_SIZE << (lc + vs->Properties.lp));
+      UInt32 i;
+      for (i = 0; i < numProbs; i++)
+        p[i] = kBitModelTotal >> 1; 
+      rep0 = rep1 = rep2 = rep3 = 1;
+      state = 0;
+      globalPos = 0;
+      distanceLimit = 0;
+      dictionaryPos = 0;
+      dictionary[dictionarySize - 1] = 0;
+      #ifdef _LZMA_IN_CB
+      RC_INIT;
+      #else
+      RC_INIT(inStream, inSize);
+      #endif
+    }
+    len = 0;
+  }
+  while(len != 0 && nowPos < outSize)
+  {
+    UInt32 pos = dictionaryPos - rep0;
+    if (pos >= dictionarySize)
+      pos += dictionarySize;
+    outStream[nowPos++] = dictionary[dictionaryPos] = dictionary[pos];
+    if (++dictionaryPos == dictionarySize)
+      dictionaryPos = 0;
+    len--;
+  }
+  if (dictionaryPos == 0)
+    previousByte = dictionary[dictionarySize - 1];
+  else
+    previousByte = dictionary[dictionaryPos - 1];
+
+  #else /* if !_LZMA_OUT_READ */
+
+  int state = 0;
+  UInt32 rep0 = 1, rep1 = 1, rep2 = 1, rep3 = 1;
+  int len = 0;
+  const Byte *Buffer;
+  const Byte *BufferLim;
+  UInt32 Range;
+  UInt32 Code;
+
+  #ifndef _LZMA_IN_CB
+  *inSizeProcessed = 0;
+  #endif
+  *outSizeProcessed = 0;
+
+  {
+    UInt32 i;
+    UInt32 numProbs = Literal + ((UInt32)LZMA_LIT_SIZE << (lc + vs->Properties.lp));
+    for (i = 0; i < numProbs; i++)
+      p[i] = kBitModelTotal >> 1;
+  }
+  
+  #ifdef _LZMA_IN_CB
+  RC_INIT;
+  #else
+  RC_INIT(inStream, inSize);
+  #endif
+
+  #endif /* _LZMA_OUT_READ */
+
+  while(nowPos < outSize)
+  {
+    CProb *prob;
+    UInt32 bound;
+    int posState = (int)(
+        (nowPos 
+        #ifdef _LZMA_OUT_READ
+        + globalPos
+        #endif
+        )
+        & posStateMask);
+
+    prob = p + IsMatch + (state << kNumPosBitsMax) + posState;
+    IfBit0(prob)
+    {
+      int symbol = 1;
+      UpdateBit0(prob)
+      prob = p + Literal + (LZMA_LIT_SIZE * 
+        (((
+        (nowPos 
+        #ifdef _LZMA_OUT_READ
+        + globalPos
+        #endif
+        )
+        & literalPosMask) << lc) + (previousByte >> (8 - lc))));
+
+      if (state >= kNumLitStates)
+      {
+        int matchByte;
+        #ifdef _LZMA_OUT_READ
+        UInt32 pos = dictionaryPos - rep0;
+        if (pos >= dictionarySize)
+          pos += dictionarySize;
+        matchByte = dictionary[pos];
+        #else
+        matchByte = outStream[nowPos - rep0];
+        #endif
+        do
+        {
+          int bit;
+          CProb *probLit;
+          matchByte <<= 1;
+          bit = (matchByte & 0x100);
+          probLit = prob + 0x100 + bit + symbol;
+          RC_GET_BIT2(probLit, symbol, if (bit != 0) break, if (bit == 0) break)
+        }
+        while (symbol < 0x100);
+      }
+      while (symbol < 0x100)
+      {
+        CProb *probLit = prob + symbol;
+        RC_GET_BIT(probLit, symbol)
+      }
+      previousByte = (Byte)symbol;
+
+      outStream[nowPos++] = previousByte;
+      #ifdef _LZMA_OUT_READ
+      if (distanceLimit < dictionarySize)
+        distanceLimit++;
+
+      dictionary[dictionaryPos] = previousByte;
+      if (++dictionaryPos == dictionarySize)
+        dictionaryPos = 0;
+      #endif
+      if (state < 4) state = 0;
+      else if (state < 10) state -= 3;
+      else state -= 6;
+    }
+    else             
+    {
+      UpdateBit1(prob);
+      prob = p + IsRep + state;
+      IfBit0(prob)
+      {
+        UpdateBit0(prob);
+        rep3 = rep2;
+        rep2 = rep1;
+        rep1 = rep0;
+        state = state < kNumLitStates ? 0 : 3;
+        prob = p + LenCoder;
+      }
+      else
+      {
+        UpdateBit1(prob);
+        prob = p + IsRepG0 + state;
+        IfBit0(prob)
+        {
+          UpdateBit0(prob);
+          prob = p + IsRep0Long + (state << kNumPosBitsMax) + posState;
+          IfBit0(prob)
+          {
+            #ifdef _LZMA_OUT_READ
+            UInt32 pos;
+            #endif
+            UpdateBit0(prob);
+            
+            #ifdef _LZMA_OUT_READ
+            if (distanceLimit == 0)
+            #else
+            if (nowPos == 0)
+            #endif
+              return LZMA_RESULT_DATA_ERROR;
+            
+            state = state < kNumLitStates ? 9 : 11;
+            #ifdef _LZMA_OUT_READ
+            pos = dictionaryPos - rep0;
+            if (pos >= dictionarySize)
+              pos += dictionarySize;
+            previousByte = dictionary[pos];
+            dictionary[dictionaryPos] = previousByte;
+            if (++dictionaryPos == dictionarySize)
+              dictionaryPos = 0;
+            #else
+            previousByte = outStream[nowPos - rep0];
+            #endif
+            outStream[nowPos++] = previousByte;
+            #ifdef _LZMA_OUT_READ
+            if (distanceLimit < dictionarySize)
+              distanceLimit++;
+            #endif
+
+            continue;
+          }
+          else
+          {
+            UpdateBit1(prob);
+          }
+        }
+        else
+        {
+          UInt32 distance;
+          UpdateBit1(prob);
+          prob = p + IsRepG1 + state;
+          IfBit0(prob)
+          {
+            UpdateBit0(prob);
+            distance = rep1;
+          }
+          else 
+          {
+            UpdateBit1(prob);
+            prob = p + IsRepG2 + state;
+            IfBit0(prob)
+            {
+              UpdateBit0(prob);
+              distance = rep2;
+            }
+            else
+            {
+              UpdateBit1(prob);
+              distance = rep3;
+              rep3 = rep2;
+            }
+            rep2 = rep1;
+          }
+          rep1 = rep0;
+          rep0 = distance;
+        }
+        state = state < kNumLitStates ? 8 : 11;
+        prob = p + RepLenCoder;
+      }
+      {
+        int numBits, offset;
+        CProb *probLen = prob + LenChoice;
+        IfBit0(probLen)
+        {
+          UpdateBit0(probLen);
+          probLen = prob + LenLow + (posState << kLenNumLowBits);
+          offset = 0;
+          numBits = kLenNumLowBits;
+        }
+        else
+        {
+          UpdateBit1(probLen);
+          probLen = prob + LenChoice2;
+          IfBit0(probLen)
+          {
+            UpdateBit0(probLen);
+            probLen = prob + LenMid + (posState << kLenNumMidBits);
+            offset = kLenNumLowSymbols;
+            numBits = kLenNumMidBits;
+          }
+          else
+          {
+            UpdateBit1(probLen);
+            probLen = prob + LenHigh;
+            offset = kLenNumLowSymbols + kLenNumMidSymbols;
+            numBits = kLenNumHighBits;
+          }
+        }
+        RangeDecoderBitTreeDecode(probLen, numBits, len);
+        len += offset;
+      }
+
+      if (state < 4)
+      {
+        int posSlot;
+        state += kNumLitStates;
+        prob = p + PosSlot +
+            ((len < kNumLenToPosStates ? len : kNumLenToPosStates - 1) << 
+            kNumPosSlotBits);
+        RangeDecoderBitTreeDecode(prob, kNumPosSlotBits, posSlot);
+        if (posSlot >= kStartPosModelIndex)
+        {
+          int numDirectBits = ((posSlot >> 1) - 1);
+          rep0 = (2 | ((UInt32)posSlot & 1));
+          if (posSlot < kEndPosModelIndex)
+          {
+            rep0 <<= numDirectBits;
+            prob = p + SpecPos + rep0 - posSlot - 1;
+          }
+          else
+          {
+            numDirectBits -= kNumAlignBits;
+            do
+            {
+              RC_NORMALIZE
+              Range >>= 1;
+              rep0 <<= 1;
+              if (Code >= Range)
+              {
+                Code -= Range;
+                rep0 |= 1;
+              }
+            }
+            while (--numDirectBits != 0);
+            prob = p + Align;
+            rep0 <<= kNumAlignBits;
+            numDirectBits = kNumAlignBits;
+          }
+          {
+            int i = 1;
+            int mi = 1;
+            do
+            {
+              CProb *prob3 = prob + mi;
+              RC_GET_BIT2(prob3, mi, ; , rep0 |= i);
+              i <<= 1;
+            }
+            while(--numDirectBits != 0);
+          }
+        }
+        else
+          rep0 = posSlot;
+        if (++rep0 == (UInt32)(0))
+        {
+          /* it's for stream version */
+          len = kLzmaStreamWasFinishedId;
+          break;
+        }
+      }
+
+      len += kMatchMinLen;
+      #ifdef _LZMA_OUT_READ
+      if (rep0 > distanceLimit) 
+      #else
+      if (rep0 > nowPos)
+      #endif
+        return LZMA_RESULT_DATA_ERROR;
+
+      #ifdef _LZMA_OUT_READ
+      if (dictionarySize - distanceLimit > (UInt32)len)
+        distanceLimit += len;
+      else
+        distanceLimit = dictionarySize;
+      #endif
+
+      do
+      {
+        #ifdef _LZMA_OUT_READ
+        UInt32 pos = dictionaryPos - rep0;
+        if (pos >= dictionarySize)
+          pos += dictionarySize;
+        previousByte = dictionary[pos];
+        dictionary[dictionaryPos] = previousByte;
+        if (++dictionaryPos == dictionarySize)
+          dictionaryPos = 0;
+        #else
+        previousByte = outStream[nowPos - rep0];
+        #endif
+        len--;
+        outStream[nowPos++] = previousByte;
+      }
+      while(len != 0 && nowPos < outSize);
+    }
+  }
+  RC_NORMALIZE;
+
+  #ifdef _LZMA_OUT_READ
+  vs->Range = Range;
+  vs->Code = Code;
+  vs->DictionaryPos = dictionaryPos;
+  vs->GlobalPos = globalPos + (UInt32)nowPos;
+  vs->DistanceLimit = distanceLimit;
+  vs->Reps[0] = rep0;
+  vs->Reps[1] = rep1;
+  vs->Reps[2] = rep2;
+  vs->Reps[3] = rep3;
+  vs->State = state;
+  vs->RemainLen = len;
+  vs->TempDictionary[0] = tempDictionary[0];
+  #endif
+
+  #ifdef _LZMA_IN_CB
+  vs->Buffer = Buffer;
+  vs->BufferLim = BufferLim;
+  #else
+  *inSizeProcessed = (SizeT)(Buffer - inStream);
+  #endif
+  *outSizeProcessed = nowPos;
+  return LZMA_RESULT_OK;
+}
diff --git a/lib_lzma/LzmaDecode.h b/lib_lzma/LzmaDecode.h
new file mode 100644
index 0000000..8382fa8
--- /dev/null
+++ b/lib_lzma/LzmaDecode.h
@@ -0,0 +1,113 @@
+/* 
+  LzmaDecode.h
+  LZMA Decoder interface
+
+  LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
+  http://www.7-zip.org/
+
+  LZMA SDK is licensed under two licenses:
+  1) GNU Lesser General Public License (GNU LGPL)
+  2) Common Public License (CPL)
+  It means that you can select one of these two licenses and 
+  follow rules of that license.
+
+  SPECIAL EXCEPTION:
+  Igor Pavlov, as the author of this code, expressly permits you to 
+  statically or dynamically link your code (or bind by name) to the 
+  interfaces of this file without subjecting your linked code to the 
+  terms of the CPL or GNU LGPL. Any modifications or additions 
+  to this file, however, are subject to the LGPL or CPL terms.
+*/
+
+#ifndef __LZMADECODE_H
+#define __LZMADECODE_H
+
+#include "LzmaTypes.h"
+
+/* #define _LZMA_IN_CB */
+/* Use callback for input data */
+
+/* #define _LZMA_OUT_READ */
+/* Use read function for output data */
+
+/* #define _LZMA_PROB32 */
+/* It can increase speed on some 32-bit CPUs, 
+   but memory usage will be doubled in that case */
+
+/* #define _LZMA_LOC_OPT */
+/* Enable local speed optimizations inside code */
+
+#ifdef _LZMA_PROB32
+#define CProb UInt32
+#else
+#define CProb UInt16
+#endif
+
+#define LZMA_RESULT_OK 0
+#define LZMA_RESULT_DATA_ERROR 1
+
+#ifdef _LZMA_IN_CB
+typedef struct _ILzmaInCallback
+{
+  int (*Read)(void *object, const unsigned char **buffer, SizeT *bufferSize);
+} ILzmaInCallback;
+#endif
+
+#define LZMA_BASE_SIZE 1846
+#define LZMA_LIT_SIZE 768
+
+#define LZMA_PROPERTIES_SIZE 5
+
+typedef struct _CLzmaProperties
+{
+  int lc;
+  int lp;
+  int pb;
+  #ifdef _LZMA_OUT_READ
+  UInt32 DictionarySize;
+  #endif
+}CLzmaProperties;
+
+int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size);
+
+#define LzmaGetNumProbs(Properties) (LZMA_BASE_SIZE + (LZMA_LIT_SIZE << ((Properties)->lc + (Properties)->lp)))
+
+#define kLzmaNeedInitId (-2)
+
+typedef struct _CLzmaDecoderState
+{
+  CLzmaProperties Properties;
+  CProb *Probs;
+
+  #ifdef _LZMA_IN_CB
+  const unsigned char *Buffer;
+  const unsigned char *BufferLim;
+  #endif
+
+  #ifdef _LZMA_OUT_READ
+  unsigned char *Dictionary;
+  UInt32 Range;
+  UInt32 Code;
+  UInt32 DictionaryPos;
+  UInt32 GlobalPos;
+  UInt32 DistanceLimit;
+  UInt32 Reps[4];
+  int State;
+  int RemainLen;
+  unsigned char TempDictionary[4];
+  #endif
+} CLzmaDecoderState;
+
+#ifdef _LZMA_OUT_READ
+#define LzmaDecoderInit(vs) { (vs)->RemainLen = kLzmaNeedInitId; }
+#endif
+
+int LzmaDecode(CLzmaDecoderState *vs,
+    #ifdef _LZMA_IN_CB
+    ILzmaInCallback *inCallback,
+    #else
+    const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
+    #endif
+    unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed);
+
+#endif
diff --git a/lib_lzma/LzmaTools.c b/lib_lzma/LzmaTools.c
new file mode 100644
index 0000000..33f4062
--- /dev/null
+++ b/lib_lzma/LzmaTools.c
@@ -0,0 +1,143 @@
+/*
+ * Usefuls routines based on the LzmaTest.c file from LZMA SDK 4.57
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * Copyright (C) 1999-2005 Igor Pavlov
+ *
+ * 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
+ */
+
+/*
+ * LZMA_Alone stream format:
+ *
+ * uchar   Properties[5]
+ * uint64  Uncompressed size
+ * uchar   data[*]
+ *
+ */
+
+#include <config.h>
+#include <common.h>
+
+#ifdef CONFIG_LZMA
+
+#define LZMA_PROPERTIES_OFFSET 0
+#define LZMA_SIZE_OFFSET       LZMA_PROPERTIES_SIZE
+#define LZMA_DATA_OFFSET       LZMA_SIZE_OFFSET+sizeof(uint64_t)
+
+#include "LzmaTools.h"
+#include "LzmaDecode.h"
+
+#include <linux/string.h>
+#include <malloc.h>
+
+int lzmaBuffToBuffDecompress (unsigned char *outStream, SizeT *uncompressedSize,
+			      unsigned char *inStream,  SizeT  length)
+{
+	int res = LZMA_RESULT_DATA_ERROR;
+	int i;
+	
+	SizeT outSizeFull = 0xFFFFFFFF; /* 4GBytes limit */
+	SizeT inProcessed;
+	SizeT outProcessed;
+	SizeT outSize;
+	SizeT outSizeHigh;
+	CLzmaDecoderState state;  /* it's about 24-80 bytes structure, if int is 32-bit */
+	unsigned char properties[LZMA_PROPERTIES_SIZE];
+	SizeT compressedSize = (SizeT)(length - LZMA_DATA_OFFSET);
+
+	debug ("LZMA: Image address............... 0x%lx\n", inStream);
+	debug ("LZMA: Properties address.......... 0x%lx\n", inStream + LZMA_PROPERTIES_OFFSET);
+	debug ("LZMA: Uncompressed size address... 0x%lx\n", inStream + LZMA_SIZE_OFFSET);
+	debug ("LZMA: Compressed data address..... 0x%lx\n", inStream + LZMA_DATA_OFFSETT);
+	debug ("LZMA: Destination address......... 0x%lx\n", outStream);
+
+
+	memcpy(properties, inStream + LZMA_PROPERTIES_OFFSET, LZMA_PROPERTIES_SIZE);		
+ 
+  	memset(&state, 0, sizeof(state));
+	res = LzmaDecodeProperties(&state.Properties,
+				 properties,
+				 LZMA_PROPERTIES_SIZE);
+	if (res != LZMA_RESULT_OK) {
+		return res;
+	}
+
+	outSize = 0;
+	outSizeHigh = 0;
+	/* Read the uncompressed size */
+	for (i = 0; i < 8; i++) {
+        	unsigned char b = inStream[LZMA_SIZE_OFFSET + i];
+	        if (i < 4) {
+        	        outSize     += (UInt32)(b) << (i * 8);
+        	} else {
+	                outSizeHigh += (UInt32)(b) << ((i - 4) * 8);
+        	}
+	}
+
+	outSizeFull = (SizeT)outSize;
+	if (sizeof(SizeT) >= 8) {
+        	/*
+	         * SizeT is a 64 bit uint => We can manage files larger than 4GB!
+        	 *
+        	 */
+	        outSizeFull |= (((SizeT)outSizeHigh << 16) << 16);
+	} else if (outSizeHigh != 0 || (UInt32)(SizeT)outSize != outSize) {
+	        /*
+        	 * SizeT is a 32 bit uint => We cannot manage files larger than
+        	 * 4GB!
+        	 *
+        	 */
+		debug ("LZMA: 64bit support not enabled.\n");
+	        return LZMA_RESULT_DATA_ERROR;
+	}
+
+	debug ("LZMA: Uncompresed size............ 0x%lx\n", outSizeFull);
+	debug ("LZMA: Compresed size.............. 0x%lx\n", compressedSize);
+	debug ("LZMA: Dynamic memory needed....... 0x%lx", LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
+
+	state.Probs = (CProb *)malloc(LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
+
+	if (state.Probs == 0
+	    || (outStream == 0 && outSizeFull != 0)
+	    || (inStream == 0 && compressedSize != 0)) {
+		free(state.Probs);
+		debug ("\n");
+		return LZMA_RESULT_DATA_ERROR;
+	}
+
+	debug (" allocated.\n");
+	
+	/* Decompress */
+
+	res = LzmaDecode(&state,
+		inStream + LZMA_DATA_OFFSET, compressedSize, &inProcessed,
+		outStream, outSizeFull,  &outProcessed);
+	if (res != LZMA_RESULT_OK)  {
+		return res;
+	}
+
+	*uncompressedSize = outSizeFull;
+	free(state.Probs);
+	return res;
+}
+
+#endif
diff --git a/lib_lzma/LzmaTools.h b/lib_lzma/LzmaTools.h
new file mode 100644
index 0000000..ea51eef
--- /dev/null
+++ b/lib_lzma/LzmaTools.h
@@ -0,0 +1,35 @@
+/*
+ * Usefuls routines based on the LzmaTest.c file from LZMA SDK 4.57
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * Copyright (C) 1999-2005 Igor Pavlov
+ *
+ * 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
+ */
+ 
+#ifndef __LZMA_TOOL_H__
+#define __LZMA_TOOL_H__
+
+#include "LzmaTypes.h"
+
+extern int lzmaBuffToBuffDecompress (unsigned char *outStream, SizeT *uncompressedSize,
+			      unsigned char *inStream,  SizeT  length);
+#endif
diff --git a/lib_lzma/LzmaTypes.h b/lib_lzma/LzmaTypes.h
new file mode 100644
index 0000000..5e860c9
--- /dev/null
+++ b/lib_lzma/LzmaTypes.h
@@ -0,0 +1,45 @@
+/* 
+LzmaTypes.h 
+
+Types for LZMA Decoder
+
+This file written and distributed to public domain by Igor Pavlov.
+This file is part of LZMA SDK 4.40 (2006-05-01)
+*/
+
+#ifndef __LZMATYPES_H
+#define __LZMATYPES_H
+
+#ifndef _7ZIP_BYTE_DEFINED
+#define _7ZIP_BYTE_DEFINED
+typedef unsigned char Byte;
+#endif 
+
+#ifndef _7ZIP_UINT16_DEFINED
+#define _7ZIP_UINT16_DEFINED
+typedef unsigned short UInt16;
+#endif 
+
+#ifndef _7ZIP_UINT32_DEFINED
+#define _7ZIP_UINT32_DEFINED
+#ifdef _LZMA_UINT32_IS_ULONG
+typedef unsigned long UInt32;
+#else
+typedef unsigned int UInt32;
+#endif
+#endif 
+
+/* #define _LZMA_NO_SYSTEM_SIZE_T */
+/* You can use it, if you don't want <stddef.h> */
+
+#ifndef _7ZIP_SIZET_DEFINED
+#define _7ZIP_SIZET_DEFINED
+#ifdef _LZMA_NO_SYSTEM_SIZE_T
+typedef UInt32 SizeT;
+#else
+#include <stddef.h>
+typedef size_t SizeT;
+#endif
+#endif
+
+#endif
diff --git a/lib_lzma/Makefile b/lib_lzma/Makefile
new file mode 100644
index 0000000..e314241
--- /dev/null
+++ b/lib_lzma/Makefile
@@ -0,0 +1,51 @@
+#
+# Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+# Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+#
+# (C) Copyright 2003-2006
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib_lzma.a
+
+SOBJS	=
+
+COBJS-y +=	LzmaDecode.o \
+		LzmaTools.o
+
+COBJS	= $(COBJS-y)
+SRCS 	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
+
+$(LIB):	$(obj).depend $(OBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS)
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
+
diff --git a/lib_lzma/README.txt b/lib_lzma/README.txt
new file mode 100644
index 0000000..8af698d
--- /dev/null
+++ b/lib_lzma/README.txt
@@ -0,0 +1,28 @@
+The lib_lzma functionality was written by Igor Pavlov. 
+The original source cames from the LZMA SDK web page:
+
+URL: 		http://www.7-zip.org/sdk.html
+Author:         Igor Pavlov
+
+The import is made using the import_lzmasdk.sh script that:
+
+* untars the lzmaXYY.tar.bz2 file (from the download web page)
+* copies the files LzmaDecode.h, LzmaTypes.h, LzmaDecode.c, history.txt,
+  LGPL.txt, and lzma.txt from source archive into the lib_lzma directory (pwd).
+
+Example:
+
+ ./import_lzmasdk.sh ~/lzma457.tar.bz2
+
+Notice: The files from lzma sdk are not _modified_ by this script!
+
+The files LzmaTools.{c,h} are provided to export the lzmaBuffToBuffDecompress()
+function that wraps the complex LzmaDecode() function from the LZMA SDK. The
+do_bootm() function uses the lzmaBuffToBuffDecopress() function to expand the
+compressed image.
+
+The directory U-BOOT/include/lzma contains stubs files that permit to use the
+library directly from U-BOOT code without touching the original LZMA SDK's
+files.
+
+Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
diff --git a/lib_lzma/history.txt b/lib_lzma/history.txt
new file mode 100644
index 0000000..8a035bb
--- /dev/null
+++ b/lib_lzma/history.txt
@@ -0,0 +1,198 @@
+HISTORY of the LZMA SDK
+-----------------------
+
+  4.57           2007-12-12
+  -------------------------
+    - Speed optimizations in ++ LZMA Decoder. 
+    - Small changes for more compatibility with some C/C++ compilers.
+
+  
+  4.49 beta      2007-07-05
+  -------------------------
+    - .7z ANSI-C Decoder:
+         - now it supports BCJ and BCJ2 filters
+         - now it supports files larger than 4 GB.
+         - now it supports "Last Write Time" field for files.
+    - C++ code for .7z archives compressing/decompressing from 7-zip 
+      was included to LZMA SDK.
+      
+
+  4.43           2006-06-04
+  -------------------------
+    - Small changes for more compatibility with some C/C++ compilers.
+      
+
+  4.42           2006-05-15
+  -------------------------
+    - Small changes in .h files in ANSI-C version.
+      
+
+  4.39 beta      2006-04-14
+  -------------------------
+    - Bug in versions 4.33b:4.38b was fixed:
+      C++ version of LZMA encoder could not correctly compress 
+      files larger than 2 GB with HC4 match finder (-mfhc4).
+      
+
+  4.37 beta      2005-04-06
+  -------------------------
+    - Fixes in C++ code: code could no be compiled if _NO_EXCEPTIONS was defined. 
+
+  
+  4.35 beta      2005-03-02
+  -------------------------
+    - Bug was fixed in C++ version of LZMA Decoder:
+       If encoded stream was corrupted, decoder could access memory 
+       outside of allocated range.
+
+  
+  4.34 beta      2006-02-27
+  -------------------------
+    - Compressing speed and memory requirements for compressing were increased
+    - LZMA now can use only these match finders: HC4, BT2, BT3, BT4
+
+  
+  4.32           2005-12-09
+  -------------------------
+    - Java version of LZMA SDK was included
+
+
+  4.30           2005-11-20
+  -------------------------
+    - Compression ratio was improved in -a2 mode
+    - Speed optimizations for compressing in -a2 mode
+    - -fb switch now supports values up to 273
+    - Bug in 7z_C (7zIn.c) was fixed:
+      It used Alloc/Free functions from different memory pools.
+      So if program used two memory pools, it worked incorrectly.
+    - 7z_C: .7z format supporting was improved
+    - LZMA# SDK (C#.NET version) was included
+
+
+  4.27 (Updated) 2005-09-21
+  -------------------------
+   - Some GUIDs/interfaces in C++ were changed.
+     IStream.h:
+       ISequentialInStream::Read now works as old ReadPart
+       ISequentialOutStream::Write now works as old WritePart
+
+  
+  4.27           2005-08-07
+  -------------------------
+    - Bug in LzmaDecodeSize.c was fixed:
+       if _LZMA_IN_CB and _LZMA_OUT_READ were defined,
+       decompressing worked incorrectly.
+
+
+  4.26           2005-08-05
+  -------------------------
+    - Fixes in 7z_C code and LzmaTest.c:
+      previous versions could work incorrectly,
+      if malloc(0) returns 0
+
+
+  4.23           2005-06-29
+  -------------------------
+    - Small fixes in C++ code
+
+
+  4.22           2005-06-10
+  -------------------------
+    - Small fixes
+
+
+  4.21           2005-06-08
+  -------------------------
+    - Interfaces for ANSI-C LZMA Decoder (LzmaDecode.c) were changed
+    - New additional version of ANSI-C LZMA Decoder with zlib-like interface:
+        - LzmaStateDecode.h
+        - LzmaStateDecode.c
+        - LzmaStateTest.c
+    - ANSI-C LZMA Decoder now can decompress files larger than 4 GB
+
+  
+  4.17           2005-04-18
+  -------------------------
+    - New example for RAM->RAM compressing/decompressing: 
+      LZMA + BCJ (filter for x86 code):
+        - LzmaRam.h
+        - LzmaRam.cpp
+        - LzmaRamDecode.h
+        - LzmaRamDecode.c
+        - -f86 switch for lzma.exe
+
+  
+  4.16           2005-03-29
+  -------------------------
+    - Bug was fixed in LzmaDecode.c (ANSI-C LZMA Decoder): 
+       If _LZMA_OUT_READ was defined, and if encoded stream was corrupted,
+       decoder could access memory outside of allocated range.
+    - Speed optimization of ANSI-C LZMA Decoder (now it's about 20% faster).
+      Old version of LZMA Decoder now is in file LzmaDecodeSize.c. 
+      LzmaDecodeSize.c can provide slightly smaller code than LzmaDecode.c
+    - Small speed optimization in LZMA C++ code
+    - filter for SPARC's code was added
+    - Simplified version of .7z ANSI-C Decoder was included
+
+
+  4.06           2004-09-05
+  -------------------------
+    - Bug in v4.05 was fixed:
+        LZMA-Encoder didn't release output stream in some cases.
+
+
+  4.05           2004-08-25
+  -------------------------
+    - Source code of filters for x86, IA-64, ARM, ARM-Thumb 
+      and PowerPC code was included to SDK
+    - Some internal minor changes
+
+
+  4.04           2004-07-28
+  -------------------------
+    - More compatibility with some C++ compilers
+
+
+  4.03           2004-06-18
+  -------------------------
+    - "Benchmark" command was added. It measures compressing 
+      and decompressing speed and shows rating values. 
+      Also it checks hardware errors.
+
+
+  4.02           2004-06-10
+  -------------------------
+    - C++ LZMA Encoder/Decoder code now is more portable
+      and it can be compiled by GCC on Linux.
+
+
+  4.01           2004-02-15
+  -------------------------
+    - Some detection of data corruption was enabled.
+        LzmaDecode.c / RangeDecoderReadByte
+        .....
+        {
+          rd->ExtraBytes = 1;
+          return 0xFF;
+        }
+
+
+  4.00           2004-02-13
+  -------------------------
+    - Original version of LZMA SDK
+
+
+
+HISTORY of the LZMA
+-------------------
+  2001-2007:  Improvements to LZMA compressing/decompressing code, 
+              keeping compatibility with original LZMA format
+  1996-2001:  Development of LZMA compression format
+
+  Some milestones:
+
+  2001-08-30: LZMA compression was added to 7-Zip
+  1999-01-02: First version of 7-Zip was released
+  
+
+End of document
diff --git a/lib_lzma/import_lzmasdk.sh b/lib_lzma/import_lzmasdk.sh
new file mode 100644
index 0000000..3b4e232
--- /dev/null
+++ b/lib_lzma/import_lzmasdk.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+usage() {
+	echo "Usage: $0 lzmaVERSION.tar.bz2" >&2
+	echo >&2
+	exit 1
+}
+
+if [ "$1" = "" ] ; then
+ 	 usage
+fi
+
+if [ ! -f $1 ] ; then
+	echo "$1 doesn't exist!" >&2
+	exit 1
+fi
+
+BASENAME=`basename $1 .tar.bz2`
+TMPDIR=/tmp/tmp_lib_$BASENAME
+FILES="C/Compress/Lzma/LzmaDecode.h
+      C/Compress/Lzma/LzmaTypes.h  
+      C/Compress/Lzma/LzmaDecode.c 
+      history.txt                  
+      LGPL.txt                     
+      lzma.txt"
+
+
+mkdir -p $TMPDIR
+echo "Untar $1 -> $TMPDIR"
+tar -jxf $1 -C $TMPDIR
+
+for i in $FILES; do
+	echo Copying  $TMPDIR/$i \-\> `basename $i`
+	cp $TMPDIR/$i .
+	chmod -x `basename $i`
+done
+
+echo "done!"
diff --git a/lib_lzma/lzma.txt b/lib_lzma/lzma.txt
new file mode 100644
index 0000000..74935bf
--- /dev/null
+++ b/lib_lzma/lzma.txt
@@ -0,0 +1,663 @@
+LZMA SDK 4.57
+-------------
+
+LZMA SDK   Copyright (C) 1999-2007 Igor Pavlov
+
+LZMA SDK provides the documentation, samples, header files, libraries, 
+and tools you need to develop applications that use LZMA compression.
+
+LZMA is default and general compression method of 7z format
+in 7-Zip compression program (www.7-zip.org). LZMA provides high 
+compression ratio and very fast decompression.
+
+LZMA is an improved version of famous LZ77 compression algorithm. 
+It was improved in way of maximum increasing of compression ratio,
+keeping high decompression speed and low memory requirements for 
+decompressing.
+
+
+
+LICENSE
+-------
+
+LZMA SDK is available under any of the following licenses:
+
+1) GNU Lesser General Public License (GNU LGPL)
+2) Common Public License (CPL)
+3) Simplified license for unmodified code (read SPECIAL EXCEPTION) 
+4) Proprietary license 
+
+It means that you can select one of these four options and follow rules of that license.
+
+
+1,2) GNU LGPL and CPL licenses are pretty similar and both these
+licenses are classified as 
+ - "Free software licenses" at http://www.gnu.org/ 
+ - "OSI-approved" at http://www.opensource.org/
+
+
+3) SPECIAL EXCEPTION
+
+Igor Pavlov, as the author of this code, expressly permits you 
+to statically or dynamically link your code (or bind by name) 
+to the files from LZMA SDK without subjecting your linked 
+code to the terms of the CPL or GNU LGPL. 
+Any modifications or additions to files from LZMA SDK, however, 
+are subject to the GNU LGPL or CPL terms.
+
+SPECIAL EXCEPTION allows you to use LZMA SDK in applications with closed code, 
+while you keep LZMA SDK code unmodified.
+
+
+SPECIAL EXCEPTION #2: Igor Pavlov, as the author of this code, expressly permits 
+you to use this code under the same terms and conditions contained in the License 
+Agreement you have for any previous version of LZMA SDK developed by Igor Pavlov.
+
+SPECIAL EXCEPTION #2 allows owners of proprietary licenses to use latest version 
+of LZMA SDK as update for previous versions.
+
+
+SPECIAL EXCEPTION #3: Igor Pavlov, as the author of this code, expressly permits 
+you to use code of the following files: 
+BranchTypes.h, LzmaTypes.h, LzmaTest.c, LzmaStateTest.c, LzmaAlone.cpp, 
+LzmaAlone.cs, LzmaAlone.java
+as public domain code. 
+
+
+4) Proprietary license
+
+LZMA SDK also can be available under a proprietary license which 
+can include:
+
+1) Right to modify code without subjecting modified code to the 
+terms of the CPL or GNU LGPL
+2) Technical support for code
+
+To request such proprietary license or any additional consultations,
+send email message from that page:
+http://www.7-zip.org/support.html
+
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+
+You should have received a copy of the Common Public License
+along with this library.
+
+
+LZMA SDK Contents
+-----------------
+
+LZMA SDK includes:
+
+  - C++ source code of LZMA compressing and decompressing
+  - ANSI-C compatible source code for LZMA decompressing
+  - C# source code for LZMA compressing and decompressing
+  - Java source code for LZMA compressing and decompressing
+  - Compiled file->file LZMA compressing/decompressing program for Windows system
+
+ANSI-C LZMA decompression code was ported from original C++ sources to C.
+Also it was simplified and optimized for code size. 
+But it is fully compatible with LZMA from 7-Zip.
+
+
+UNIX/Linux version 
+------------------
+To compile C++ version of file->file LZMA, go to directory
+C/7zip/Compress/LZMA_Alone 
+and type "make" or "make clean all" to recompile all.
+
+In some UNIX/Linux versions you must compile LZMA with static libraries.
+To compile with static libraries, change string in makefile
+LIB = -lm
+to string  
+LIB = -lm -static
+
+
+Files
+---------------------
+C        - C source code
+CPP      - CPP source code
+CS       - C# source code
+Java     - Java source code
+lzma.txt - LZMA SDK description (this file)
+7zFormat.txt - 7z Format description
+7zC.txt  - 7z ANSI-C Decoder description (this file)
+methods.txt  - Compression method IDs for .7z
+LGPL.txt - GNU Lesser General Public License
+CPL.html - Common Public License
+lzma.exe - Compiled file->file LZMA encoder/decoder for Windows
+history.txt - history of the LZMA SDK
+
+
+Source code structure
+---------------------
+
+C  - C files
+    Compress - files related to compression/decompression
+      Lz     - files related to LZ (Lempel-Ziv) compression algorithm
+      Lzma   - ANSI-C compatible LZMA decompressor
+
+        LzmaDecode.h  - interface for LZMA decoding on ANSI-C
+        LzmaDecode.c      - LZMA decoding on ANSI-C (new fastest version)
+        LzmaDecodeSize.c  - LZMA decoding on ANSI-C (old size-optimized version)
+        LzmaTest.c        - test application that decodes LZMA encoded file
+        LzmaTypes.h       - basic types for LZMA Decoder
+        LzmaStateDecode.h - interface for LZMA decoding (State version)
+        LzmaStateDecode.c - LZMA decoding on ANSI-C (State version)
+        LzmaStateTest.c   - test application (State version)
+
+      Branch       - Filters for x86, IA-64, ARM, ARM-Thumb, PowerPC and SPARC code
+
+    Archive - files related to archiving
+      7z_C     - 7z ANSI-C Decoder
+
+
+CPP -- CPP files
+
+  Common  - common files for C++ projects
+  Windows - common files for Windows related code
+  7zip    - files related to 7-Zip Project
+
+    Common   - common files for 7-Zip
+
+    Compress - files related to compression/decompression
+
+      LZ     - files related to LZ (Lempel-Ziv) compression algorithm
+
+      Copy         - Copy coder
+      RangeCoder   - Range Coder (special code of compression/decompression)
+      LZMA         - LZMA compression/decompression on C++
+      LZMA_Alone   - file->file LZMA compression/decompression
+
+      Branch       - Filters for x86, IA-64, ARM, ARM-Thumb, PowerPC and SPARC code
+
+    Archive - files related to archiving
+
+      Common   - common files for archive handling
+      7z       - 7z C++ Encoder/Decoder
+
+    Bundles    - Modules that are bundles of other modules
+  
+      Alone7z           - 7zr.exe: Standalone version of 7z.exe that supports only 7z/LZMA/BCJ/BCJ2
+      Format7zR         - 7zr.dll: Reduced version of 7za.dll: extracting/compressing to 7z/LZMA/BCJ/BCJ2
+      Format7zExtractR  - 7zxr.dll: Reduced version of 7zxa.dll: extracting from 7z/LZMA/BCJ/BCJ2.
+
+    UI        - User Interface files
+         
+      Client7z - Test application for 7za.dll,  7zr.dll, 7zxr.dll
+      Common   - Common UI files
+      Console  - Code for console archiver
+
+
+
+CS - C# files
+  7zip
+    Common   - some common files for 7-Zip
+    Compress - files related to compression/decompression
+      LZ     - files related to LZ (Lempel-Ziv) compression algorithm
+      LZMA         - LZMA compression/decompression
+      LzmaAlone    - file->file LZMA compression/decompression
+      RangeCoder   - Range Coder (special code of compression/decompression)
+
+Java  - Java files
+  SevenZip
+    Compression    - files related to compression/decompression
+      LZ           - files related to LZ (Lempel-Ziv) compression algorithm
+      LZMA         - LZMA compression/decompression
+      RangeCoder   - Range Coder (special code of compression/decompression)
+
+C/C++ source code of LZMA SDK is part of 7-Zip project.
+
+You can find ANSI-C LZMA decompressing code at folder 
+  C/7zip/Compress/Lzma
+7-Zip doesn't use that ANSI-C LZMA code and that code was developed 
+specially for this SDK. And files from C/7zip/Compress/Lzma do not need 
+files from other directories of SDK for compiling.
+
+7-Zip source code can be downloaded from 7-Zip's SourceForge page:
+
+  http://sourceforge.net/projects/sevenzip/
+
+
+LZMA features
+-------------
+  - Variable dictionary size (up to 1 GB)
+  - Estimated compressing speed: about 1 MB/s on 1 GHz CPU
+  - Estimated decompressing speed: 
+      - 8-12 MB/s on 1 GHz Intel Pentium 3 or AMD Athlon
+      - 500-1000 KB/s on 100 MHz ARM, MIPS, PowerPC or other simple RISC
+  - Small memory requirements for decompressing (8-32 KB + DictionarySize)
+  - Small code size for decompressing: 2-8 KB (depending from 
+    speed optimizations) 
+
+LZMA decoder uses only integer operations and can be 
+implemented in any modern 32-bit CPU (or on 16-bit CPU with some conditions).
+
+Some critical operations that affect to speed of LZMA decompression:
+  1) 32*16 bit integer multiply
+  2) Misspredicted branches (penalty mostly depends from pipeline length)
+  3) 32-bit shift and arithmetic operations
+
+Speed of LZMA decompressing mostly depends from CPU speed.
+Memory speed has no big meaning. But if your CPU has small data cache, 
+overall weight of memory speed will slightly increase.
+
+
+How To Use
+----------
+
+Using LZMA encoder/decoder executable
+--------------------------------------
+
+Usage:  LZMA <e|d> inputFile outputFile [<switches>...]
+
+  e: encode file
+
+  d: decode file
+
+  b: Benchmark. There are two tests: compressing and decompressing 
+     with LZMA method. Benchmark shows rating in MIPS (million 
+     instructions per second). Rating value is calculated from 
+     measured speed and it is normalized with AMD Athlon 64 X2 CPU
+     results. Also Benchmark checks possible hardware errors (RAM 
+     errors in most cases). Benchmark uses these settings:
+     (-a1, -d21, -fb32, -mfbt4). You can change only -d. Also you 
+     can change number of iterations. Example for 30 iterations:
+       LZMA b 30
+     Default number of iterations is 10.
+
+<Switches>
+  
+
+  -a{N}:  set compression mode 0 = fast, 1 = normal
+          default: 1 (normal)
+
+  d{N}:   Sets Dictionary size - [0, 30], default: 23 (8MB)
+          The maximum value for dictionary size is 1 GB = 2^30 bytes.
+          Dictionary size is calculated as DictionarySize = 2^N bytes. 
+          For decompressing file compressed by LZMA method with dictionary 
+          size D = 2^N you need about D bytes of memory (RAM).
+
+  -fb{N}: set number of fast bytes - [5, 273], default: 128
+          Usually big number gives a little bit better compression ratio 
+          and slower compression process.
+
+  -lc{N}: set number of literal context bits - [0, 8], default: 3
+          Sometimes lc=4 gives gain for big files.
+
+  -lp{N}: set number of literal pos bits - [0, 4], default: 0
+          lp switch is intended for periodical data when period is 
+          equal 2^N. For example, for 32-bit (4 bytes) 
+          periodical data you can use lp=2. Often it's better to set lc0, 
+          if you change lp switch.
+
+  -pb{N}: set number of pos bits - [0, 4], default: 2
+          pb switch is intended for periodical data 
+          when period is equal 2^N.
+
+  -mf{MF_ID}: set Match Finder. Default: bt4. 
+              Algorithms from hc* group doesn't provide good compression 
+              ratio, but they often works pretty fast in combination with 
+              fast mode (-a0).
+
+              Memory requirements depend from dictionary size 
+              (parameter "d" in table below). 
+
+               MF_ID     Memory                   Description
+
+                bt2    d *  9.5 + 4MB  Binary Tree with 2 bytes hashing.
+                bt3    d * 11.5 + 4MB  Binary Tree with 3 bytes hashing.
+                bt4    d * 11.5 + 4MB  Binary Tree with 4 bytes hashing.
+                hc4    d *  7.5 + 4MB  Hash Chain with 4 bytes hashing.
+
+  -eos:   write End Of Stream marker. By default LZMA doesn't write 
+          eos marker, since LZMA decoder knows uncompressed size 
+          stored in .lzma file header.
+
+  -si:    Read data from stdin (it will write End Of Stream marker).
+  -so:    Write data to stdout
+
+
+Examples:
+
+1) LZMA e file.bin file.lzma -d16 -lc0 
+
+compresses file.bin to file.lzma with 64 KB dictionary (2^16=64K)  
+and 0 literal context bits. -lc0 allows to reduce memory requirements 
+for decompression.
+
+
+2) LZMA e file.bin file.lzma -lc0 -lp2
+
+compresses file.bin to file.lzma with settings suitable 
+for 32-bit periodical data (for example, ARM or MIPS code).
+
+3) LZMA d file.lzma file.bin
+
+decompresses file.lzma to file.bin.
+
+
+Compression ratio hints
+-----------------------
+
+Recommendations
+---------------
+
+To increase compression ratio for LZMA compressing it's desirable 
+to have aligned data (if it's possible) and also it's desirable to locate
+data in such order, where code is grouped in one place and data is 
+grouped in other place (it's better than such mixing: code, data, code,
+data, ...).
+
+
+Using Filters
+-------------
+You can increase compression ratio for some data types, using
+special filters before compressing. For example, it's possible to 
+increase compression ratio on 5-10% for code for those CPU ISAs: 
+x86, IA-64, ARM, ARM-Thumb, PowerPC, SPARC.
+
+You can find C/C++ source code of such filters in folder "7zip/Compress/Branch"
+
+You can check compression ratio gain of these filters with such 
+7-Zip commands (example for ARM code):
+No filter:
+  7z a a1.7z a.bin -m0=lzma
+
+With filter for little-endian ARM code:
+  7z a a2.7z a.bin -m0=bc_arm -m1=lzma        
+
+With filter for big-endian ARM code (using additional Swap4 filter):
+  7z a a3.7z a.bin -m0=swap4 -m1=bc_arm -m2=lzma
+
+It works in such manner:
+Compressing    = Filter_encoding + LZMA_encoding
+Decompressing  = LZMA_decoding + Filter_decoding
+
+Compressing and decompressing speed of such filters is very high,
+so it will not increase decompressing time too much.
+Moreover, it reduces decompression time for LZMA_decoding, 
+since compression ratio with filtering is higher.
+
+These filters convert CALL (calling procedure) instructions 
+from relative offsets to absolute addresses, so such data becomes more 
+compressible. Source code of these CALL filters is pretty simple
+(about 20 lines of C++), so you can convert it from C++ version yourself.
+
+For some ISAs (for example, for MIPS) it's impossible to get gain from such filter.
+
+
+LZMA compressed file format
+---------------------------
+Offset Size Description
+  0     1   Special LZMA properties for compressed data
+  1     4   Dictionary size (little endian)
+  5     8   Uncompressed size (little endian). -1 means unknown size
+ 13         Compressed data
+
+
+ANSI-C LZMA Decoder
+~~~~~~~~~~~~~~~~~~~
+
+To compile ANSI-C LZMA Decoder you can use one of the following files sets:
+1) LzmaDecode.h + LzmaDecode.c + LzmaTest.c  (fastest version)
+2) LzmaDecode.h + LzmaDecodeSize.c + LzmaTest.c  (old size-optimized version)
+3) LzmaStateDecode.h + LzmaStateDecode.c + LzmaStateTest.c  (zlib-like interface)
+
+
+Memory requirements for LZMA decoding
+-------------------------------------
+
+LZMA decoder doesn't allocate memory itself, so you must 
+allocate memory and send it to LZMA.
+
+Stack usage of LZMA decoding function for local variables is not 
+larger than 200 bytes.
+
+How To decompress data
+----------------------
+
+LZMA Decoder (ANSI-C version) now supports 5 interfaces:
+1) Single-call Decompressing
+2) Single-call Decompressing with input stream callback
+3) Multi-call Decompressing with output buffer
+4) Multi-call Decompressing with input callback and output buffer
+5) Multi-call State Decompressing (zlib-like interface)
+
+Variant-5 is similar to Variant-4, but Variant-5 doesn't use callback functions.
+
+Decompressing steps
+-------------------
+
+1) read LZMA properties (5 bytes):
+   unsigned char properties[LZMA_PROPERTIES_SIZE];
+
+2) read uncompressed size (8 bytes, little-endian)
+
+3) Decode properties:
+
+  CLzmaDecoderState state;  /* it's 24-140 bytes structure, if int is 32-bit */
+
+  if (LzmaDecodeProperties(&state.Properties, properties, LZMA_PROPERTIES_SIZE) != LZMA_RESULT_OK)
+    return PrintError(rs, "Incorrect stream properties");
+
+4) Allocate memory block for internal Structures:
+
+  state.Probs = (CProb *)malloc(LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
+  if (state.Probs == 0)
+    return PrintError(rs, kCantAllocateMessage);
+
+  LZMA decoder uses array of CProb variables as internal structure.
+  By default, CProb is unsigned_short. But you can define _LZMA_PROB32 to make 
+  it unsigned_int. It can increase speed on some 32-bit CPUs, but memory 
+  usage will be doubled in that case.
+
+
+5) Main Decompressing
+
+You must use one of the following interfaces:
+
+5.1 Single-call Decompressing
+-----------------------------
+When to use: RAM->RAM decompressing
+Compile files: LzmaDecode.h, LzmaDecode.c
+Compile defines: no defines
+Memory Requirements:
+  - Input buffer: compressed size
+  - Output buffer: uncompressed size
+  - LZMA Internal Structures (~16 KB for default settings) 
+
+Interface:
+  int res = LzmaDecode(&state, 
+      inStream, compressedSize, &inProcessed,
+      outStream, outSize, &outProcessed);
+
+
+5.2 Single-call Decompressing with input stream callback
+--------------------------------------------------------
+When to use: File->RAM or Flash->RAM decompressing.
+Compile files: LzmaDecode.h, LzmaDecode.c
+Compile defines: _LZMA_IN_CB
+Memory Requirements:
+  - Buffer for input stream: any size (for example, 16 KB)
+  - Output buffer: uncompressed size
+  - LZMA Internal Structures (~16 KB for default settings) 
+
+Interface:
+  typedef struct _CBuffer
+  {
+    ILzmaInCallback InCallback;
+    FILE *File;
+    unsigned char Buffer[kInBufferSize];
+  } CBuffer;
+
+  int LzmaReadCompressed(void *object, const unsigned char **buffer, SizeT *size)
+  {
+    CBuffer *bo = (CBuffer *)object;
+    *buffer = bo->Buffer;
+    *size = MyReadFile(bo->File, bo->Buffer, kInBufferSize);
+    return LZMA_RESULT_OK;
+  }
+
+  CBuffer g_InBuffer;
+
+  g_InBuffer.File = inFile;
+  g_InBuffer.InCallback.Read = LzmaReadCompressed;
+  int res = LzmaDecode(&state, 
+      &g_InBuffer.InCallback,
+      outStream, outSize, &outProcessed);
+
+
+5.3 Multi-call decompressing with output buffer
+-----------------------------------------------
+When to use: RAM->File decompressing 
+Compile files: LzmaDecode.h, LzmaDecode.c
+Compile defines: _LZMA_OUT_READ
+Memory Requirements:
+ - Input buffer: compressed size
+ - Buffer for output stream: any size (for example, 16 KB)
+ - LZMA Internal Structures (~16 KB for default settings) 
+ - LZMA dictionary (dictionary size is encoded in stream properties)
+ 
+Interface:
+
+  state.Dictionary = (unsigned char *)malloc(state.Properties.DictionarySize);
+
+  LzmaDecoderInit(&state);
+  do
+  {
+    LzmaDecode(&state,
+      inBuffer, inAvail, &inProcessed,
+      g_OutBuffer, outAvail, &outProcessed);
+    inAvail -= inProcessed;
+    inBuffer += inProcessed;
+  }
+  while you need more bytes
+
+  see LzmaTest.c for more details.
+
+
+5.4 Multi-call decompressing with input callback and output buffer
+------------------------------------------------------------------
+When to use: File->File decompressing 
+Compile files: LzmaDecode.h, LzmaDecode.c
+Compile defines: _LZMA_IN_CB, _LZMA_OUT_READ
+Memory Requirements:
+ - Buffer for input stream: any size (for example, 16 KB)
+ - Buffer for output stream: any size (for example, 16 KB)
+ - LZMA Internal Structures (~16 KB for default settings) 
+ - LZMA dictionary (dictionary size is encoded in stream properties)
+ 
+Interface:
+
+  state.Dictionary = (unsigned char *)malloc(state.Properties.DictionarySize);
+ 
+  LzmaDecoderInit(&state);
+  do
+  {
+    LzmaDecode(&state,
+      &bo.InCallback,
+      g_OutBuffer, outAvail, &outProcessed);
+  }
+  while you need more bytes
+
+  see LzmaTest.c for more details:
+
+
+5.5 Multi-call State Decompressing (zlib-like interface)
+------------------------------------------------------------------
+When to use: file->file decompressing 
+Compile files: LzmaStateDecode.h, LzmaStateDecode.c
+Compile defines:
+Memory Requirements:
+ - Buffer for input stream: any size (for example, 16 KB)
+ - Buffer for output stream: any size (for example, 16 KB)
+ - LZMA Internal Structures (~16 KB for default settings) 
+ - LZMA dictionary (dictionary size is encoded in stream properties)
+ 
+Interface:
+
+  state.Dictionary = (unsigned char *)malloc(state.Properties.DictionarySize);
+
+  
+  LzmaDecoderInit(&state);
+  do
+  {
+    res = LzmaDecode(&state,
+      inBuffer, inAvail, &inProcessed,
+      g_OutBuffer, outAvail, &outProcessed,
+      finishDecoding);
+    inAvail -= inProcessed;
+    inBuffer += inProcessed;
+  }
+  while you need more bytes
+
+  see LzmaStateTest.c for more details:
+
+
+6) Free all allocated blocks
+
+
+Note
+----
+LzmaDecodeSize.c is size-optimized version of LzmaDecode.c.
+But compiled code of LzmaDecodeSize.c can be larger than 
+compiled code of LzmaDecode.c. So it's better to use 
+LzmaDecode.c in most cases.
+
+
+EXIT codes
+-----------
+
+LZMA decoder can return one of the following codes:
+
+#define LZMA_RESULT_OK 0
+#define LZMA_RESULT_DATA_ERROR 1
+
+If you use callback function for input data and you return some 
+error code, LZMA Decoder also returns that code.
+
+
+
+LZMA Defines
+------------
+
+_LZMA_IN_CB    - Use callback for input data
+
+_LZMA_OUT_READ - Use read function for output data
+
+_LZMA_LOC_OPT  - Enable local speed optimizations inside code.
+                 _LZMA_LOC_OPT is only for LzmaDecodeSize.c (size-optimized version).
+                 _LZMA_LOC_OPT doesn't affect LzmaDecode.c (speed-optimized version)
+                 and LzmaStateDecode.c
+
+_LZMA_PROB32   - It can increase speed on some 32-bit CPUs, 
+                 but memory usage will be doubled in that case
+
+_LZMA_UINT32_IS_ULONG  - Define it if int is 16-bit on your compiler
+                         and long is 32-bit.
+
+_LZMA_SYSTEM_SIZE_T  - Define it if you want to use system's size_t.
+                       You can use it to enable 64-bit sizes supporting
+
+
+
+C++ LZMA Encoder/Decoder 
+~~~~~~~~~~~~~~~~~~~~~~~~
+C++ LZMA code use COM-like interfaces. So if you want to use it, 
+you can study basics of COM/OLE.
+
+By default, LZMA Encoder contains all Match Finders.
+But for compressing it's enough to have just one of them.
+So for reducing size of compressing code you can define:
+  #define COMPRESS_MF_BT
+  #define COMPRESS_MF_BT4
+and it will use only bt4 match finder.
+
+
+---
+
+http://www.7-zip.org
+http://www.7-zip.org/support.html
-- 
1.5.4.3




From andre.schwarz at matrix-vision.de  Tue Apr  1 13:38:34 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Tue, 01 Apr 2008 13:38:34 +0200
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <20080331131830.bdd5c146.kim.phillips@freescale.com>
References: <1206714585-13569-1-git-send-email-tor@excito.com>	<47F0EEBE.2010905@gmail.com>
	<20080331131830.bdd5c146.kim.phillips@freescale.com>
Message-ID: <47F21EBA.9030504@matrix-vision.de>

Kim,

would it help if we donate one or two boards to the custodians ?
Or do you have no time at all for specific testing ?

After bring-up + validation I could offer 1-2 MPC8343B based boards with 
2x VSC8601.
The system also has a miniPCI Slot, USB-A and 512MB DDR-II Micron memory.


Please let me know if you're interested.


regards,
Andre Schwarz
Matrix Vision



Kim Phillips schrieb:
> On Mon, 31 Mar 2008 10:01:34 -0400
> Ben Warren <biggerbadderben at gmail.com> wrote:
>
>   
>> Tor Krill wrote:
>>     
>>> Add phy_info for Vitesse VSC8601.
>>> Add config option, CFG_VSC8601_SKEWFIX, to enable RGMII skew timing compensation.
>>>
>>> Signed-off-by: Tor Krill <tor at excito.com>
>>>   
>>>       
>> Acked-by: Ben Warren <biggerbadderben at gmail.com>
>>     
>
> I don't have a Vitesse 8601, so technically I can't ack it, but I can:
>
> Reviewed-by: Kim Phillips <kim.phillips at freescale.com>
>
> minor nit: it would be nice if the following:
>
>   
>>> +#ifdef CFG_VSC8601_SKEWFIX
>>> +				{MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
>>> +#endif
>>>       
>
> were made to have spaces after commas, and flow onto a separate
> line so as to not be a 96 char line..
>
> Kim
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080401/7495f4a5/attachment.htm 

From trimarchi at gandalf.sssup.it  Tue Apr  1 13:44:50 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Tue, 01 Apr 2008 13:44:50 +0200
Subject: [U-Boot-Users] [PATCH] get_vfatname
In-Reply-To: <20080328235143.76136248BF@gemini.denx.de>
References: <20080328235143.76136248BF@gemini.denx.de>
Message-ID: <47F22032.6040409@gandalf.sssup.it>

Wolfgang Denk wrote:
> In message <47ECD868.3040600 at gandalf.sssup.it> you wrote:
>   
>>> What exactly is the preoblem? Is there a test case that can reproduce
>>> the problem?
>>>   
>>>       
>> My test case is a 64Mb CF. Maybe  I give you a link :) as soon as possible.
>>
>> The problem is that the code doesn't look if the dir_slot contain a long name.
>> If doesn't contain a long name is a dir_entry and the name can be get by the
>> get_name function. I'm not an expert of vfat filesystem, I take a look
>> to the linux code and to experimental result. The block that is read by the
>> gc_getcluster function is not a dir_slot but a dir_entry.
>>     
>
> Well, maybe you can give me a test case?
>
> Like some script to create the needed directories / files in a VFAT
> file system which provokes the error?
>
> Best regards,
>
> Wolfgang Denk
>
>   
I can give you an image that you can write on ide disk or on a Compact 
Flash.
Is ok?

Michael




From plagnioj at jcrosoft.com  Tue Apr  1 14:07:10 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue,  1 Apr 2008 14:07:10 +0200
Subject: [U-Boot-Users] [PATCH] s3c4510b_eth: fix 'packed' attribute ignored
	for fields of MACFrame
Message-ID: <1207051630-25394-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/drivers/net/s3c4510b_eth.h b/drivers/net/s3c4510b_eth.h
index cbddba7..048307f 100644
--- a/drivers/net/s3c4510b_eth.h
+++ b/drivers/net/s3c4510b_eth.h
@@ -30,8 +30,6 @@
  *
  */
 
-#define __packed    __attribute__ ((packed))
-
 #define ETH_MAC_ADDR_SIZE           (6)    /*  dst,src addr is 6bytes each */
 #define ETH_MaxTxFrames             (16)   /*  Max number of Tx Frames */
 
@@ -283,12 +281,14 @@ typedef struct __RX_FrameDescriptor {
 } RX_FrameDescriptor;
 
 /*  MAC Frame Structure */
-typedef struct __MACFrame {
-	u8     m_dstAddr[6] __packed;
-	u8     m_srcAddr[6] __packed;
-	u16  m_lengthOrType __packed;
-	u8  m_payload[1506] __packed;
-} MACFrame;
+struct __MACFrame {
+	u8     m_dstAddr[6];
+	u8     m_srcAddr[6];
+	u16  m_lengthOrType;
+	u8  m_payload[1506];
+} __attribute__ ((packed));
+
+typedef struct __MACFrame MACFrame;
 
 /* Ethernet Control block */
 typedef struct __ETH {
-- 
1.5.4.5




From wd at denx.de  Tue Apr  1 14:45:56 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 01 Apr 2008 14:45:56 +0200
Subject: [U-Boot-Users] [PATCH] get_vfatname
In-Reply-To: Your message of "Tue, 01 Apr 2008 13:44:50 +0200."
	<47F22032.6040409@gandalf.sssup.it>
Message-ID: <20080401124556.6F57324544@gemini.denx.de>

In message <47F22032.6040409 at gandalf.sssup.it> you wrote:
>
> > Like some script to create the needed directories / files in a VFAT
> > file system which provokes the error?
...
> I can give you an image that you can write on ide disk or on a Compact 
> Flash.
> Is ok?

Actually I'd prefer a script to create such an image, but if this is
impossible (?) then an image will do, too.

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: wd at denx.de
Vulcans never bluff.
	-- Spock, "The Doomsday Machine", stardate 4202.1



From Sascha.Laue at gmx.biz  Tue Apr  1 15:13:03 2008
From: Sascha.Laue at gmx.biz (Sascha Laue)
Date: Tue, 01 Apr 2008 15:13:03 +0200
Subject: [U-Boot-Users] [PATCH] bugfix: the watchdog post for lwmon5
In-Reply-To: <20080401083320.B918D24544@gemini.denx.de>
References: <20080401083320.B918D24544@gemini.denx.de>
Message-ID: <20080401131303.17520@gmx.net>

You are right! I've checked it again and find the mistake by myself. 

Subject: [PATCH] bugfix: lwmon5 watchdog post
If the hardware watchdog detects a voltage error, the watchdog set GPIO62 to low.
The watchdog POST have to detect this lowpegel.

Signed-off-by: Sascha Laue <leglas0 at legpc180.leg.liebherr.i>
---
 post/board/lwmon5/watchdog.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/post/board/lwmon5/watchdog.c b/post/board/lwmon5/watchdog.c
index 48ff687..899fbfb 100644
--- a/post/board/lwmon5/watchdog.c
+++ b/post/board/lwmon5/watchdog.c
@@ -55,7 +55,7 @@ static void watchdog_magic_write(uint value)
 
 int sysmon1_post_test(int flags)
 {
-	if (gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {
+	if (gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS) == 0) {
 		/*
 		 * 3.1. GPIO62 is low
 		 * Assuming system voltage failure.
-- 
1.5.2.4

-------- Original-Nachricht --------
> Datum: Tue, 01 Apr 2008 10:33:20 +0200
> Von: Wolfgang Denk <wd at denx.de>
> An: "Sascha Laue" <Sascha.Laue at gmx.biz>
> CC: u-boot-users at lists.sourceforge.net
> Betreff: Re: [U-Boot-Users] [PATCH] bugfix: the watchdog post for lwmon5

> In message <20080401075941.145820 at gmx.net> you wrote:
> > bugfix: the watchdog post for lwmon5 doesn't work. This Patch fix it.
> > To trigger and activate the watchdog correct it is necessary to create 2
> pulses.
> > Lowpegel on GPIO62 point to a voltagefailure.
> 
> Please fix English ("correct", "Lowpegel", "voltagefailure").
> 
> Is it really 2 pulses - or just one, consisting of 
> 
> > Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> ...
> > -	if (gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {
> > +	if (0 == gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {
> 
> Please write that as:
> 
> 	if (gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS) == 0) {
> or
> 	if (!gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {
> 
> >  		 * 3.1. GPIO62 is low
> >  		 * Assuming system voltage failure.
> > @@ -99,6 +99,9 @@ int lwmon5_watchdog_post_test(int flags)
> >  		ints = disable_interrupts ();
> >  		/* 3.2.2. strobe watchdog once */
> >  		WATCHDOG_RESET();
> > +		base = post_time_ms (0);
> > +		while (post_time_ms (base) < 2)
> > +		WATCHDOG_RESET();
> 
> Are you absolutely sure that is needed?
> 
> 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: wd at denx.de
> Tactical? TACTICAL!?!? Hey, buddy, we went from kilotons to  megatons
> several  minutes  ago.  We don't need no stinkin' tactical nukes. (By
> the way, do you have change for 10 million people?)           - lwall



From ndineshbabuece at gmail.com  Tue Apr  1 15:22:19 2008
From: ndineshbabuece at gmail.com (dinesh babu)
Date: Tue, 1 Apr 2008 18:52:19 +0530
Subject: [U-Boot-Users] compiliation problem in U-boot for blackfin in
	fedora 7
Message-ID: <c33cc70804010622m5afc5c67ge95b6e4f4dd70891@mail.gmail.com>

i  have compilied uboot (u-boot-1.1.6-2008R1 taken from blackfin.uclinux.org)in
fedora 7 .i have used the latest tool chain release(
blackfin-toolchain-08r1-8.i386). but i have the following errors .can any
boby help me


errors generated when i compile u-boot

In file included from hello_world.c:25:
/root/Desktop/u-boot-1.1.6-2008R1/include/exports.h:21: error: expected
declaration specifiers or '...' before 'va_list'
make[1]: *** [hello_world.o] Error 1
make[1]: Leaving directory `/root/Desktop/u-boot-1.1.6-2008R1/examples'
make: *** [examples] Error 2

waiting for any body's reply

-- 
Have a peaceful joy  with you!
by
N.Dineshbabu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080401/395ad0c9/attachment.htm 

From andre.schwarz at matrix-vision.de  Tue Apr  1 15:33:10 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Tue, 01 Apr 2008 15:33:10 +0200
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <1206714585-13569-1-git-send-email-tor@excito.com>
References: <1206714585-13569-1-git-send-email-tor@excito.com>
Message-ID: <47F23996.7070105@matrix-vision.de>

Tor,

after investigating the tsec code I'm wondering how your PHY  works in 
RGMII mode ...

I think that there are some things missing, e.g. taking RGMII into 
account during tsec_init.

/* Init ECNTRL */
        regs->ecntrl = ECNTRL_INIT_SETTINGS;

This will clear bit 27 which indicates RGMII as set up by the HRCW.


I would expect something like

        if ( priv->flags & TSEC_REDUCED )
                regs->ecntrl |= ECNTRL_RPM;

afterwards.



Before I'll start doing double work again : Have you some unposted 
patches regarding RGMII on TSEC ?

Am I missing something ?


@Kim : Did you ever run a MPC834x with a RGMII  PHY ? Is it known to work ?


regards,
Andre



Tor Krill schrieb:
> Add phy_info for Vitesse VSC8601.
> Add config option, CFG_VSC8601_SKEWFIX, to enable RGMII skew timing compensation.
>
> Signed-off-by: Tor Krill <tor at excito.com>
> ---
>  drivers/net/tsec.c |   30 ++++++++++++++++++++++++++++++
>  drivers/net/tsec.h |    5 +++++
>  2 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
> index 431a8d2..9d22aa3 100644
> --- a/drivers/net/tsec.c
> +++ b/drivers/net/tsec.c
> @@ -1267,6 +1267,35 @@ struct phy_info phy_info_VSC8244 = {
>  			   },
>  };
>  
> +struct phy_info phy_info_VSC8601 = {
> +		0x00007042,
> +		"Vitesse VSC8601",
> +		4,
> +		(struct phy_cmd[]){     /* config */
> +				/* Override PHY config settings */
> +				/* Configure some basic stuff */
> +				{MIIM_CONTROL, MIIM_CONTROL_INIT, &mii_cr_init},
> +#ifdef CFG_VSC8601_SKEWFIX
> +				{MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
> +#endif
> +				{miim_end,}
> +				 },
> +		(struct phy_cmd[]){     /* startup */
> +				/* Read the Status (2x to make sure link is right) */
> +				{MIIM_STATUS, miim_read, NULL},
> +				/* Auto-negotiate */
> +				{MIIM_STATUS, miim_read, &mii_parse_sr},
> +				/* Read the status */
> +				{MIIM_VSC8244_AUX_CONSTAT, miim_read,
> +						&mii_parse_vsc8244},
> +				{miim_end,}
> +				},
> +		(struct phy_cmd[]){     /* shutdown */
> +				{miim_end,}
> +				},
> +};
> +
> +
>  struct phy_info phy_info_dm9161 = {
>  	0x0181b88,
>  	"Davicom DM9161E",
> @@ -1462,6 +1491,7 @@ struct phy_info *phy_info[] = {
>  	&phy_info_dm9161,
>  	&phy_info_lxt971,
>  	&phy_info_VSC8244,
> +	&phy_info_VSC8601,
>  	&phy_info_dp83865,
>  	&phy_info_rtl8211b,
>  	&phy_info_generic,
> diff --git a/drivers/net/tsec.h b/drivers/net/tsec.h
> index d4dc15a..cfa7d1a 100644
> --- a/drivers/net/tsec.h
> +++ b/drivers/net/tsec.h
> @@ -159,6 +159,11 @@
>  #define MIIM_VSC8244_LED_CON            0x1b
>  #define MIIM_VSC8244_LEDCON_INIT        0xF011
>  
> +/* Entry for Vitesse VSC8601 regs starts here (Not complete) */
> +/* Vitesse VSC8601 Extended PHY Control Register 1 */
> +#define MIIM_VSC8601_EPHY_CON			0x17
> +#define MIIM_VSC8601_EPHY_CON_INIT_SKEW	0x1120
> +
>  /* 88E1011 PHY Status Register */
>  #define MIIM_88E1011_PHY_STATUS         0x11
>  #define MIIM_88E1011_PHYSTAT_SPEED      0xc000
>   


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From afleming at gmail.com  Tue Apr  1 15:42:21 2008
From: afleming at gmail.com (Andy Fleming)
Date: Tue, 1 Apr 2008 08:42:21 -0500
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <47F23996.7070105@matrix-vision.de>
References: <1206714585-13569-1-git-send-email-tor@excito.com>
	<47F23996.7070105@matrix-vision.de>
Message-ID: <2acbd3e40804010642gbf413e1o12aa16657ce5129a@mail.gmail.com>

On Tue, Apr 1, 2008 at 8:33 AM, Andre Schwarz
<andre.schwarz at matrix-vision.de> wrote:
> Tor,
>
>  after investigating the tsec code I'm wondering how your PHY  works in
>  RGMII mode ...
>
>  I think that there are some things missing, e.g. taking RGMII into
>  account during tsec_init.
>
>  /* Init ECNTRL */
>         regs->ecntrl = ECNTRL_INIT_SETTINGS;

If you look carefully, you'll notice that ecntrl's RPM bit is
read-only.  Those bits are configured by POR pin strappings.

You may be more familiar with the UEC, which doesn't automatically
detect the link type, but is otherwise fairly similar to the tsec.

Andy



From gerald.vanbaren at ge.com  Tue Apr  1 16:06:07 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Tue, 01 Apr 2008 10:06:07 -0400
Subject: [U-Boot-Users] [PATCH] Fix fdt set command to conform to dts
 spec
In-Reply-To: <1207014356-1663-1-git-send-email-afleming@freescale.com>
References: <1207014356-1663-1-git-send-email-afleming@freescale.com>
Message-ID: <47F2414F.9070001@ge.com>

Andy Fleming wrote:
> The fdt set command was treating properties specified as <00> and <0011>
> as byte streams, rather than as an array of cells.  As we already have
> syntax for expressing the desire for a stream of bytes ([ xx xx ...]),
> we should use the <> syntax to describe arrays of cells, which are always
> 32-bits per element.  If we imagine this likely (IMHO) scenario:
> 
>> fdt set /ethernet-phy at 1 reg <1>
> 
> With the old code, this would create a bad fdt, since the reg cell would be
> made to be one byte in length.  But the cell must be 4 bytes, so this would
> break mysteriously.
> 
> Also, the dts spec calls for constants inside the angle brackets (<>)
> to conform to C constant standards as they pertain to base.
> Take this scenario:
> 
>> fdt set /ethernet at f00 reg <0xe250000\ 0x1000>
> 
> The old fdt command would complain that it couldn't parse that.  Or, if you
> wanted to specify that a certain clock ran at 33 MHz, you'd be required to
> do this:
> 
>> fdt set /mydev clock <1f78a40>
> 
> Whereas the new code will accept decimal numbers.
> 
> While I was in there, I extended the fdt command parser to handle property
> strings which are split across multiple arguments:
> 
>> fdt set /ethernet at f00 interrupts < 33 2 34 2 36 2 >
>> fdt p /ethernet at f00
> ethernet at f00 {
> 	interrupts = <0x21 0x2 0x22 0x2 0x24 0x2>;
> };
> 
> Lastly, the fdt print code was rearranged slightly to print arrays of cells
> if the length of the property is a multiple of 4 bytes, and to not print
> leading zeros.
> 
> Signed-off-by: Andy Fleming <afleming at freescale.com>
> ---

Hi Andy,

This looks like a very good improvement, fix some of my mistakes and 
misassumptions.

What I wrote originally was prior to dtc v1.0... at that time, all 
constants were hex.  Bringing our parsing/printing forward to the 
C-syntax age (dtc v1.0++) is good.

The parsing and print format that I did, I did to make the device tree 
printout reversible: I compiled source with dtc, loaded it, and printed 
it out.  I adapted the print heuristics so that the fdt print command 
matched (exactly in almost all cases) the example dtc source.  Your 
point about <> values being 32 bit cells bothers me... either I didn't 
understand the particulars of the <> notation (quite possible) or 
something has changed.  I would like to understand the genesis of this 
error/misunderstanding.

I have not had time yet to apply the patch to the u-boot-fdt tree and 
try it, I'll do that pronto.

Best regards,
gvb



From andre.schwarz at matrix-vision.de  Tue Apr  1 16:08:50 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Tue, 01 Apr 2008 16:08:50 +0200
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <2acbd3e40804010642gbf413e1o12aa16657ce5129a@mail.gmail.com>
References: <1206714585-13569-1-git-send-email-tor@excito.com>	
	<47F23996.7070105@matrix-vision.de>
	<2acbd3e40804010642gbf413e1o12aa16657ce5129a@mail.gmail.com>
Message-ID: <47F241F2.1000407@matrix-vision.de>

Andy Fleming schrieb:
> On Tue, Apr 1, 2008 at 8:33 AM, Andre Schwarz
> <andre.schwarz at matrix-vision.de> wrote:
>   
>> Tor,
>>
>>  after investigating the tsec code I'm wondering how your PHY  works in
>>  RGMII mode ...
>>
>>  I think that there are some things missing, e.g. taking RGMII into
>>  account during tsec_init.
>>
>>  /* Init ECNTRL */
>>         regs->ecntrl = ECNTRL_INIT_SETTINGS;
>>     
>
> If you look carefully, you'll notice that ecntrl's RPM bit is
> read-only.  Those bits are configured by POR pin strappings.
>
>   
sorry, my documentation (MPC8349EARM rev.1) declares this register 
read-write.
Of course it will be configured by the HRCW but can be overwritten 
afterwards.

If this is not true it's a documentation bug.

> You may be more familiar with the UEC, which doesn't automatically
> detect the link type, but is otherwise fairly similar to the tsec.
>
>   
What do you mean ?
I'm trying to get two VSC8601 RGMII PHYs running on a MPC8343B ...


> Andy
>   


regards,
Andre


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080401/7bad5047/attachment.htm 

From afleming at gmail.com  Tue Apr  1 16:25:06 2008
From: afleming at gmail.com (Andy Fleming)
Date: Tue, 1 Apr 2008 09:25:06 -0500
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <47F241F2.1000407@matrix-vision.de>
References: <1206714585-13569-1-git-send-email-tor@excito.com>
	<47F23996.7070105@matrix-vision.de>
	<2acbd3e40804010642gbf413e1o12aa16657ce5129a@mail.gmail.com>
	<47F241F2.1000407@matrix-vision.de>
Message-ID: <2acbd3e40804010725w62947a2eofc20ec7b6dc77459@mail.gmail.com>

On Tue, Apr 1, 2008 at 9:08 AM, Andre Schwarz
<andre.schwarz at matrix-vision.de> wrote:
>
>
>  Tor,
>
>  after investigating the tsec code I'm wondering how your PHY works in
>  RGMII mode ...
>
>  I think that there are some things missing, e.g. taking RGMII into
>  account during tsec_init.
>
>  /* Init ECNTRL */
>  regs->ecntrl = ECNTRL_INIT_SETTINGS;
>
>  If you look carefully, you'll notice that ecntrl's RPM bit is
> read-only. Those bits are configured by POR pin strappings.
>
>
>  sorry, my documentation (MPC8349EARM rev.1) declares this register
> read-write.
>  Of course it will be configured by the HRCW but can be overwritten
> afterwards.
>
>  If this is not true it's a documentation bug.


Thank you for bringing this to my attention.  It is almost certainly a
bug.  If you look at the 8349ERM (rather than the 8349EARM), you'll
see that the bits are read-only (except for R100, which tsec.c does
modify based on the link type).  I will file a bug with the docs
people.


>
>
>  You may be more familiar with the UEC, which doesn't automatically
> detect the link type, but is otherwise fairly similar to the tsec.
>
>
>  What do you mean ?
>  I'm trying to get two VSC8601 RGMII PHYs running on a MPC8343B ...

sorry, I forgot which ethernet controller you were using, and I'm not
as familiar with the 83xx family as the 85xx family.  Some of our
parts have the QUICC Engine, which has an ethernet controller with
some similar registers to the TSEC's.  I was guessing that was why you
thought those bits were writable, rather than a documentation bug, but
clearly I was wrong.  :)

Andy

Andy



From zhanglei459 at gmail.com  Tue Apr  1 16:28:30 2008
From: zhanglei459 at gmail.com (zhanglei459)
Date: Tue, 1 Apr 2008 07:28:30 -0700 (PDT)
Subject: [U-Boot-Users]  questions  about porting to  MPC7410+EVB64260
Message-ID: <16418464.post@talk.nabble.com>


Hi,all:
    I'm a newbie to u-boot.Now I want to port u-boot to my customized
mpc7410 + EVB64260 board.
 After searching source code,I have 3 questions:
 the first,board "EVB64260" may be the best suitable to mine? 
 the second,In evb64260.h, BAT of SDRAM is:
/* SDRAM */
 #define CFG_IBAT0L (CFG_SDRAM_BASE | BATL_PP_RW | BATL_CACHEINHIBIT)
 #define CFG_IBAT0U (CFG_SDRAM_BASE | BATU_BL_256M | BATU_VS | BATU_VP)
 #define CFG_DBAT0L (CFG_SDRAM_BASE | BATL_PP_RW | BATL_CACHEINHIBIT |
BATL_GUARDEDSTORAGE)
 #define CFG_DBAT0U CFG_IBAT0U
I found attribute of SDRAM is not BATL_GUARDEDSTORAGE in some board
configuration file,and some others is not BATL_GUARDEDSTORAGE.And I think
SDRAM should not be BATL_GUARDEDSTORAGE,right?
The last question is when I using Windriver ICE debug u-boot,after I run
program to set MMU,CPU_SDRAM,CPU_DEVICE registers,Workbench Register window
display correct number of MMU,but display all "ffffffff" of
CPU_SDRAM,CPU_CONFIGURATION.when I "RUN" u-boot in flash,it stop and run
into address 0x800 exception program.Anyone can direct me how to explain it?
Thank you very much!Hope reply.
-- 
View this message in context: http://www.nabble.com/questions--about-porting-to--MPC7410%2BEVB64260-tp16418464p16418464.html
Sent from the Uboot - Users mailing list archive at Nabble.com.




From andre.schwarz at matrix-vision.de  Tue Apr  1 16:35:29 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Tue, 01 Apr 2008 16:35:29 +0200
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <2acbd3e40804010725w62947a2eofc20ec7b6dc77459@mail.gmail.com>
References: <1206714585-13569-1-git-send-email-tor@excito.com>	
	<47F23996.7070105@matrix-vision.de>	
	<2acbd3e40804010642gbf413e1o12aa16657ce5129a@mail.gmail.com>	
	<47F241F2.1000407@matrix-vision.de>
	<2acbd3e40804010725w62947a2eofc20ec7b6dc77459@mail.gmail.com>
Message-ID: <47F24831.5060001@matrix-vision.de>

Andy Fleming schrieb:
> On Tue, Apr 1, 2008 at 9:08 AM, Andre Schwarz
> <andre.schwarz at matrix-vision.de> wrote:
>   
>>  Tor,
>>
>>  after investigating the tsec code I'm wondering how your PHY works in
>>  RGMII mode ...
>>
>>  I think that there are some things missing, e.g. taking RGMII into
>>  account during tsec_init.
>>
>>  /* Init ECNTRL */
>>  regs->ecntrl = ECNTRL_INIT_SETTINGS;
>>
>>  If you look carefully, you'll notice that ecntrl's RPM bit is
>> read-only. Those bits are configured by POR pin strappings.
>>
>>
>>  sorry, my documentation (MPC8349EARM rev.1) declares this register
>> read-write.
>>  Of course it will be configured by the HRCW but can be overwritten
>> afterwards.
>>
>>  If this is not true it's a documentation bug.
>>     
>
>
> Thank you for bringing this to my attention.  It is almost certainly a
> bug.  If you look at the 8349ERM (rather than the 8349EARM), you'll
> see that the bits are read-only (except for R100, which tsec.c does
> modify based on the link type).  I will file a bug with the docs
> people.
>
>
>   
I've x-checked and printed the register after init.
You're right - it's read only and the RPM bit is set.
But the ECNTL  register description @ 15.5.3.1.4 says "read/write" to 
all bits ...
>>  You may be more familiar with the UEC, which doesn't automatically
>> detect the link type, but is otherwise fairly similar to the tsec.
>>
>>
>>  What do you mean ?
>>  I'm trying to get two VSC8601 RGMII PHYs running on a MPC8343B ...
>>     
>
> sorry, I forgot which ethernet controller you were using, and I'm not
> as familiar with the 83xx family as the 85xx family.  Some of our
> parts have the QUICC Engine, which has an ethernet controller with
> some similar registers to the TSEC's.  I was guessing that was why you
> thought those bits were writable, rather than a documentation bug, but
> clearly I was wrong.  :)
>
>   
no problem.

Andre
> Andy
>
> Andy
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080401/51718d44/attachment.htm 

From dzu at denx.de  Tue Apr  1 16:38:14 2008
From: dzu at denx.de (Detlev Zundel)
Date: Tue, 01 Apr 2008 16:38:14 +0200
Subject: [U-Boot-Users] [ELDK] Service Announcement: DENX services
	moving to new server
In-Reply-To: <20080401000327.GB25732@mail-vs.djpig.de> (Frank Lichtenheld's
	message of "Tue, 1 Apr 2008 02:03:27 +0200")
References: <20080401000327.GB25732@mail-vs.djpig.de>
Message-ID: <m2od8tabe1.fsf@ohwell.denx.de>

Hi,

> All public services provided by DENX are currently moving to a server
> with newer, more powerful hardware. This move should be transparent for
> users and developers, except maybe for minor glitches during DNS update
> times. If you encounter any problems, please report them to root at denx.de

This restructuring is of special interest to the U-Boot custodians
because the new server of course has its own set of ssh keys.  So it is
expected that all custodians will have to explicitely accommodate for
that fact (e.g. do a "ssh-keygen -R www.denx.de" and verify the new
key).

For reference, the fingerprints of the new keys are:

2048 86:ad:1d:2b:d0:0c:a4:66:be:ee:51:86:a3:49:54:46  /etc/ssh/ssh_host_rsa_key.pub
2048 7d:20:cb:2e:ab:63:89:bb:36:fc:c7:dc:17:e7:aa:60  /etc/ssh/ssh_host_dsa_key.pub

Cheers
  Detlev

-- 
... that every year or so they're going to give you a new release full
of 50 000  additional lines of code all  written  by monkeys.  Because
they generally follow  the  ``million monkeys typing,   and eventually
they'll come up with something useful'' school of system development.
	                                    -- Richard M. Stallman
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From galak at kernel.crashing.org  Tue Apr  1 17:04:00 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 1 Apr 2008 10:04:00 -0500
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: <20080331202357.59C0B248BF@gemini.denx.de>
References: <20080331202357.59C0B248BF@gemini.denx.de>
Message-ID: <5D708345-1CF3-46FA-B9D2-689C52625177@kernel.crashing.org>


On Mar 31, 2008, at 3:23 PM, Wolfgang Denk wrote:
> In message <9A2E2F7A-D812-4818- 
> A728-3DB51306356A at kernel.crashing.org> you wrote:
>>
>>>> Which Linux distro are you running?
>>>
>>> RHEL WS 3
>
> Oops.
>
>>>>> /usr/include/md5.h:27: error: parse error before "UINT4"
>>>>> /usr/include/md5.h:30: error: parse error before '}' token
>>>>> /usr/include/md5.h:38: error: parse error before "PROTO_LIST"
>>>>> /usr/include/md5.h:39: error: parse error before "PROTO_LIST"
>>>>> /usr/include/md5.h:41: error: parse error before "PROTO_LIST"
>>>>> /usr/include/md5.h:43: error: parse error before "PROTO_LIST"
>>>>> image.c: In function `calculate_hash':
>>>>> image.c:1944: warning: implicit declaration of function `md5'
>>>>
>>>> Which package in your distro installs "/usr/include/md5.h" ?
>>>
>>> cyrus-sasl-devel-2.1.15-10
>>
>> any ideas?
>
> IMHO this package should not install md5.h in that  system  location;
> more  recent  versions  of  that  package use /usr/include/sasl/md5.h
> instead (see for example cyrus-sasl-devel-2.1.22-8).
>
> I don't know RHEL - maybe you can update the RPM?

Not that I'm aware of.  Its a box run by our IT department so I have  
no ability to upgrade or modify things.  It looks like RHEL4 has the  
same issue.

ld2047$ rpm -qf /usr/include/md5.h
cyrus-sasl-devel-2.1.19-5.EL4

Any ideas on how to work around this?  Do we really intend to pick up  
the system md5.h or should we be getting the one from u-boot/include/ 
md5.h?

- k



From vapier at gentoo.org  Tue Apr  1 17:24:19 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 1 Apr 2008 11:24:19 -0400
Subject: [U-Boot-Users] compiliation problem in U-boot for blackfin in
	fedora 7
In-Reply-To: <c33cc70804010622m5afc5c67ge95b6e4f4dd70891@mail.gmail.com>
References: <c33cc70804010622m5afc5c67ge95b6e4f4dd70891@mail.gmail.com>
Message-ID: <200804011124.20375.vapier@gentoo.org>

On Tuesday 01 April 2008, dinesh babu wrote:
> i  have compilied uboot (u-boot-1.1.6-2008R1 taken from
> blackfin.uclinux.org)

you've posted this same question twice in the forums, and you're cross-posting 
to multiple lists.  please do not do this.  you ask your question once, in 
one place, rather than spamming it everywhere you can possibly find.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080401/b466c3af/attachment.pgp 

From kim.phillips at freescale.com  Tue Apr  1 18:12:27 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Tue, 1 Apr 2008 11:12:27 -0500
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <47F23996.7070105@matrix-vision.de>
References: <1206714585-13569-1-git-send-email-tor@excito.com>
	<47F23996.7070105@matrix-vision.de>
Message-ID: <20080401111227.98e8b4b8.kim.phillips@freescale.com>

On Tue, 01 Apr 2008 15:33:10 +0200
Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:

> I would expect something like
> 
>         if ( priv->flags & TSEC_REDUCED )
>                 regs->ecntrl |= ECNTRL_RPM;

yeah, that register should be r/o..

> @Kim : Did you ever run a MPC834x with a RGMII  PHY ? Is it known to work ?

834x?  I haven't, but I also haven't a reason why it would not work :)

Kim



From plagnioj at jcrosoft.com  Tue Apr  1 22:34:31 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue,  1 Apr 2008 22:34:31 +0200
Subject: [U-Boot-Users] [PATCH] fsl_i2c: Fix used uninitialized variable
Message-ID: <1207082071-20291-1-git-send-email-plagnioj@jcrosoft.com>

fsl_i2c.c: In function 'set_i2c_bus_speed':
fsl_i2c.c:120: warning: 'dfsr' may be used uninitialized in this function
fsl_i2c.c:120: warning: 'fdr' may be used uninitialized in this function

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index dde0571..917a4ba 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -117,7 +117,8 @@ static unsigned int set_i2c_bus_speed(const struct fsl_i2c *dev,
 {
 	unsigned short divider = min(i2c_clk / speed, (unsigned short) -1);
 	unsigned int i;
-	u8 fdr, dfsr;
+	u8 fdr = 0x3F;
+	u8 dfsr = 0x3F;
 
 	/*
 	 * We want to choose an FDR/DFSR that generates an I2C bus speed that
-- 
1.5.4.5




From wd at denx.de  Tue Apr  1 22:41:26 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 01 Apr 2008 22:41:26 +0200
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: Your message of "Tue, 01 Apr 2008 10:04:00 CDT."
	<5D708345-1CF3-46FA-B9D2-689C52625177@kernel.crashing.org>
Message-ID: <20080401204126.31CD724544@gemini.denx.de>

In message <5D708345-1CF3-46FA-B9D2-689C52625177 at kernel.crashing.org> you wrote:
> 
> > I don't know RHEL - maybe you can update the RPM?
> 
> Not that I'm aware of.  Its a box run by our IT department so I have  
> no ability to upgrade or modify things.  It looks like RHEL4 has the  
> same issue.
> 
> ld2047$ rpm -qf /usr/include/md5.h
> cyrus-sasl-devel-2.1.19-5.EL4

I see. I have to go back pretty far in time to find such a
configuration:

	$ ls -l /usr/include/md5.h
	-rw-r--r--  1 root root 1572 Apr 24  2006 /usr/include/md5.h
	$ rpm -qf /usr/include/md5.h
	cyrus-sasl-devel-2.1.20-6
	$ cat /etc/issue
	Fedora Core release 4 (Stentz)

All more recent distros seem to have this fixed (and yes,
cyrus-sasl-devel is installed in all of them):

	$ ls -l /usr/include/md5.h
	ls: /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora Core release 5 (Bordeaux)

	$ ls -l /usr/include/md5.h
	ls: /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora Core release 6 (Zod)

	$ ls -l /usr/include/md5.h
	ls: cannot access /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora release 7 (Moonshine)

	$ ls -l /usr/include/md5.h
	ls: cannot access /usr/include/md5.h: No such file or directory
	$ cat /etc/issue
	Fedora release 8 (Werewolf)

> Any ideas on how to work around this?  Do we really intend to pick up  
> the system md5.h or should we be getting the one from u-boot/include/ 
> md5.h?

We need the system md5.h, I think. We'll investigate.

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: wd at denx.de
"Why should we subsidize intellectual curiosity?" - Ronald Reagan



From galak at kernel.crashing.org  Tue Apr  1 22:56:03 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 1 Apr 2008 15:56:03 -0500
Subject: [U-Boot-Users] [PATCH] fsl_i2c: Fix used uninitialized variable
In-Reply-To: <1207082071-20291-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207082071-20291-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1CF1C1DB-875F-47E0-95E5-F20E962FAAEE@kernel.crashing.org>


On Apr 1, 2008, at 3:34 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> fsl_i2c.c: In function 'set_i2c_bus_speed':
> fsl_i2c.c:120: warning: 'dfsr' may be used uninitialized in this  
> function
> fsl_i2c.c:120: warning: 'fdr' may be used uninitialized in this  
> function
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD  
> <plagnioj at jcrosoft.com>
>
> diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
> index dde0571..917a4ba 100644
> --- a/drivers/i2c/fsl_i2c.c
> +++ b/drivers/i2c/fsl_i2c.c
> @@ -117,7 +117,8 @@ static unsigned int set_i2c_bus_speed(const  
> struct fsl_i2c *dev,
> {
> 	unsigned short divider = min(i2c_clk / speed, (unsigned short) -1);
> 	unsigned int i;
> -	u8 fdr, dfsr;
> +	u8 fdr = 0x3F;
> +	u8 dfsr = 0x3F;
>
> 	/*
> 	 * We want to choose an FDR/DFSR that generates an I2C bus speed that
> -- 
> 1.5.4.5

I posted a patch that moved fdr, dfsr inside the loop to fix the  
warnings.

- k



From plagnioj at jcrosoft.com  Tue Apr  1 23:26:30 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 1 Apr 2008 23:26:30 +0200
Subject: [U-Boot-Users] [PATCH] fsl_i2c: Fix used uninitialized variable
In-Reply-To: <1CF1C1DB-875F-47E0-95E5-F20E962FAAEE@kernel.crashing.org>
References: <1207082071-20291-1-git-send-email-plagnioj@jcrosoft.com>
	<1CF1C1DB-875F-47E0-95E5-F20E962FAAEE@kernel.crashing.org>
Message-ID: <20080401212630.GA26810@game.jcrosoft.org>

On 15:56 Tue 01 Apr     , Kumar Gala wrote:
>
> On Apr 1, 2008, at 3:34 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> fsl_i2c.c: In function 'set_i2c_bus_speed':
>> fsl_i2c.c:120: warning: 'dfsr' may be used uninitialized in this function
>> fsl_i2c.c:120: warning: 'fdr' may be used uninitialized in this function
>>
>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>>
>> diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
>> index dde0571..917a4ba 100644
>> --- a/drivers/i2c/fsl_i2c.c
>> +++ b/drivers/i2c/fsl_i2c.c
>> @@ -117,7 +117,8 @@ static unsigned int set_i2c_bus_speed(const struct 
>> fsl_i2c *dev,
>> {
>> 	unsigned short divider = min(i2c_clk / speed, (unsigned short) -1);
>> 	unsigned int i;
>> -	u8 fdr, dfsr;
>> +	u8 fdr = 0x3F;
>> +	u8 dfsr = 0x3F;
>>
>> 	/*
>> 	 * We want to choose an FDR/DFSR that generates an I2C bus speed that
>> -- 
>> 1.5.4.5
>
> I posted a patch that moved fdr, dfsr inside the loop to fix the warnings.

Not Found could you give the subject please

Best Regards,
J.



From wd at denx.de  Tue Apr  1 23:35:18 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 01 Apr 2008 23:35:18 +0200
Subject: [U-Boot-Users] [PATCH] fsl_i2c: Fix used uninitialized variable
In-Reply-To: Your message of "Tue, 01 Apr 2008 23:26:30 +0200."
	<20080401212630.GA26810@game.jcrosoft.org>
Message-ID: <20080401213518.BFA332476E@gemini.denx.de>

In message <20080401212630.GA26810 at game.jcrosoft.org> you wrote:
>
> > I posted a patch that moved fdr, dfsr inside the loop to fix the warnings.
> 
> Not Found could you give the subject please

 7607  03/26 Kumar Gala         [U-Boot-Users] [PATCH] Fix warnings introduced by I2C bus speed setti

It's on my todo list.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In Nature there are neither rewards nor punishments, there are conse-
quences.                                            -- R.G. Ingersoll



From gerickson at nuovations.com  Wed Apr  2 00:43:17 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Tue, 01 Apr 2008 15:43:17 -0700
Subject: [U-Boot-Users] Build Iterates Indefinitely on "Generating
 include/autoconf.mk"
In-Reply-To: <20080327220807.26F95242FC@gemini.denx.de>
Message-ID: <C4180895.E556%gerickson@nuovations.com>

On 3/27/08 3:08 PM, Wolfgang Denk wrote:
> In message <000001c89049$3d85a440$2708a8c0 at CAM.ARTIMI.COM> you wrote:
>> Maybe `.LOW_RESOLUTION_TIME' could help?  Also, it might be worth trying a
>> run with the -d flag, in case it shows up why make thinks
>> include/autoconf.mk is never up-to-date; it might be informative to know WRT
>> what precisely make thinks it is outdated.
> 
> I think running with "-d" is a good idea, even though it will produce
> a disk full of output. But in theory the output should  be  identical
> for all setups.

Turning on '-d' was somewhat instructive in that in contrast to the previous
tests without '-d' all builds I have of make v3.81 on all file system types
fail (ext3fs, tmpfs, and nfs) whereas one version previously worked on all
file systems and all versions worked on ext3fs:

Without '-d':
-------------

    ------------------------------------------------------------------------
    Shell   Make                                     NFS     tmpfs    ext3
    ========================================================================
    bash    /usr/local/bin/make-3.81 (3.81)        SUCCESS  SUCCESS  SUCCESS
    bash    /usr/local/bin/gmake (3.81)            FAILURE  FAILURE  SUCCESS
    bash    ${HOME}/tmp/bin/make (3.81 w/ librt)   FAILURE  FAILURE  SUCCESS
    bash    ${HOME}/tmp/bin/make (3.81 w/o librt)  FAILURE  FAILURE  SUCCESS
    ========================================================================

With '-d':
----------

    ------------------------------------------------------------------------
    Shell   Make                                     NFS     tmpfs    ext3
    ========================================================================
    bash    /usr/local/bin/make-3.81 (3.81)        FAILURE  FAILURE  FAILURE
    bash    /usr/local/bin/gmake (3.81)            FAILURE  FAILURE  FAILURE
    bash    ${HOME}/tmp/bin/make (3.81 w/ librt)   FAILURE  FAILURE  FAILURE
    bash    ${HOME}/tmp/bin/make (3.81 w/o librt)  FAILURE  FAILURE  FAILURE
    ========================================================================

While the log files from all 12 runs (4 versions x 3 file systems) are
identical (with the obvious exceptions of paths, PIDs, etc.), what sticks
out in each is that make never thinks
`${ROOT}/u-boot/build/include/version_autogenerated.h' (aka VERSION_FILE)
exists even though it gets remade successfully each time it is requested.
This is, of course, a completely expected result since $(VERSION_FILE) is
tagged '.PHONY' in the main Makefile.

Removing $(VERSION_FILE) from the .PHONY list results in successes across
the entire 12 cell test matrix.

Any insights on why this very real file is tagged as .PHONY and why it
should not be eliminated from the .PHONY list?

Based on the test matrix above, is there any agreement that this is a
potential make bug in how .PHONY prerequisites are handled? Given this
apparent root cause, I would have expected failures consistently in the
ext3fs case as well as in the not-linked-against-librt-and-libpthread
version case (top row of the test matrix).

Regards,

Grant Erickson





From gvb.uboot at gmail.com  Wed Apr  2 01:53:32 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Tue, 01 Apr 2008 19:53:32 -0400
Subject: [U-Boot-Users] Pull request u-boot-fdt.git / FDT bugfix patches
Message-ID: <47F2CAFC.8070904@gmail.com>

Dear Wolfgang,

On the FDT front, we have two outstanding bugfix patches:

-------------------------------------------------------------------
Explanation: I authored 43ddd9c820fec44816188f53346b464e20b3142d and 
missed some pieces which Kim was kind enough to clean up.  (You pulled 
43ddd directly into u-boot.)
-------------------------------------------------------------------
<http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38849>

From: Kim Phillips <kim.phillips <at> freescale.com>
Subject: [PATCH] remove remaining CONFIG_OF_HAS_{UBOOT_ENV, BD_T} code
Newsgroups: gmane.comp.boot-loaders.u-boot
Date: 2008-03-28 22:37:49 GMT (4 days and 55 minutes ago)

finish off what commit 43ddd9c820fec44816188f53346b464e20b3142d,
"Remove deprecated CONFIG_OF_HAS_UBOOT_ENV and CONFIG_OF_HAS_BD_T"
started.

Signed-off-by: Kim Phillips <kim.phillips <at> freescale.com>
-------------------------------------------------------------------


-------------------------------------------------------------------
I also created a 8xx patch to fix a compile warning for 8xx boards that 
don't use fdt.o.  This looks good to me, but I don't have a 8xx board to 
test it on.  PLEASE VERIFY.
-------------------------------------------------------------------
<http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38885/>

From: Jerry Van Baren <gvb.uboot <at> gmail.com>
Subject: [PATCH] Fix 8xx build to conditionally compile fdt.o
Newsgroups: gmane.comp.boot-loaders.u-boot
Date: 2008-03-30 02:06:31 GMT (2 days, 21 hours and 30 minutes ago)

Change to COBJS-y method so that the fdt.o library can be properly
conditionally compiled.  Without this change, the mpc8xx boards that
don't use CONFIG_OF_LIBFDT still build the fdt.o, causing code bloat
and compile warnings.

Signed-off-by: Gerald Van Baren <vanbaren <at> cideas.com>
-------------------------------------------------------------------

If it is handier, you can pull both from my u-boot-fdt repo:

The following changes since commit 3596d55eb22703d3f4f1b839fe4b000fabe081b3:
   Gerald Van Baren (1):
         Merge git://www.denx.de/git/u-boot into uboot

are available in the git repository at:

   git://git.denx.de/u-boot-fdt.git master

Gerald Van Baren (1):
       Fix 8xx build to conditionally compile fdt.o

Kim Phillips (1):
       remove remaining CONFIG_OF_HAS_{UBOOT_ENV,BD_T} code

  README              |   13 ------
  common/ft_build.c   |  113 
---------------------------------------------------
  cpu/mpc8xx/Makefile |   24 +++++++++--
  lib_ppc/bootm.c     |   12 -----
  4 files changed, 19 insertions(+), 143 deletions(-)


Thanks,
gvb



From gururajakr at sanyo.co.in  Wed Apr  2 04:04:33 2008
From: gururajakr at sanyo.co.in (Gururaja Hebbar K R)
Date: Wed, 2 Apr 2008 07:34:33 +0530
Subject: [U-Boot-Users] ARM march architecture version for arm926ejs in
	config.mk
References: <mailman.97392.1207014378.31037.u-boot-users@lists.sourceforge.net>
Message-ID: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF1@blrms.slti.sanyo.co.in>

Hi,

i have seen questions on the mailing list about march for arm926ejs
being mentioned as -march=armv4.

http://www.nabble.com/-PATCH--ARM%3A-Fix-arm-architecture-version-for-ar
m926ejs-td5195486.html#a5210157

http://www.nabble.com/-patch-u-boot-git-2-3--better-ARM9-compiler-option
s-td14962153.html#a15009686

But according to the Wikipedia
(http://en.wikipedia.org/wiki/ARM_architecture ) , architecture version
for ARM926EJ-S  is ARMv5TEJ.

Kindly can someone explain why this is done. Previously few have
provided the patch but all have been rejected or not applied.

Sorry if this is a repeated question.

Thanks in advance.

Regards
Gururaja



From gururajakr at sanyo.co.in  Wed Apr  2 07:34:43 2008
From: gururajakr at sanyo.co.in (Gururaja Hebbar K R)
Date: Wed, 2 Apr 2008 11:04:43 +0530
Subject: [U-Boot-Users] [PATCH] Remove duplicate #undef SHOW_INFO inside
	drivers\usb\usb_ohci.c
Message-ID: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF5@blrms.slti.sanyo.co.in>

Hi,
 
In drivers\usb\usb_ohci.c file, SHOW_INFO is undef at 2 locations. @line
77 and @line 112. Below patch removes them for code size savings.
 
comments welcome.
 
Thanks in advance
 
Signed-off-by: gururaja hebbar <gururajakr at sanyo.co.in>
 
--- usb_orig.c 2007-12-06 01:21:19.000000000 -0800
+++ usb_ohci.c 2008-04-02 14:06:23.937500000 -0700
@@ -109,7 +109,6 @@ static struct pci_device_id ohci_pci_ids
 #define dbg(format, arg...) do {} while(0)
 #endif /* DEBUG */
 #define err(format, arg...) printf("ERROR: " format "\n", ## arg)
-#undef SHOW_INFO
 #ifdef SHOW_INFO
 #define info(format, arg...) printf("INFO: " format "\n", ## arg)
 #else
 

Regards
Gururaja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080402/08ece611/attachment.htm 

From plagnioj at jcrosoft.com  Wed Apr  2 08:03:57 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed,  2 Apr 2008 08:03:57 +0200
Subject: [U-Boot-Users] [PATCH 1/2] cmd_log.c: Fix assignment differ in
	signedness
In-Reply-To: <1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1207116238-7253-2-git-send-email-plagnioj@jcrosoft.com>

In function 'logbuff_init_ptrs':
cmd_log.c:79: warning: pointer targets in assignment differ in signedness

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/common/cmd_log.c b/common/cmd_log.c
index 34b36ff..b9f9ba0 100644
--- a/common/cmd_log.c
+++ b/common/cmd_log.c
@@ -76,7 +76,7 @@ void logbuff_init_ptrs (void)
 	lbuf = (char *)CONFIG_ALT_LB_ADDR;
 #else
 	log = (logbuff_t *)(gd->bd->bi_memsize-LOGBUFF_LEN) - 1;
-	lbuf = log->buf;
+	lbuf = (char *)log->buf;
 #endif
 
 	/* Set up log version */
-- 
1.5.4.5




From plagnioj at jcrosoft.com  Wed Apr  2 08:03:56 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed,  2 Apr 2008 08:03:56 +0200
Subject: [U-Boot-Users] [PATCH 0/2] MPC8xx: Fix libfdt support introduced in
	commit 77ff7b74
Message-ID: <1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>

fdt.c: In function 'ft_cpu_setup':
fdt.c:33: warning: implicit declaration of function 'do_fixup_by_prop_u32'
fdt.c:39: warning: implicit declaration of function 'do_fixup_by_compat_u32'
fdt.c:43: warning: implicit declaration of function 'fdt_fixup_ethernet'
fdt.c:45: warning: implicit declaration of function 'fdt_fixup_memory'

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/cpu/mpc8xx/Makefile b/cpu/mpc8xx/Makefile
index dbdc2e0..5f70459 100644
--- a/cpu/mpc8xx/Makefile
+++ b/cpu/mpc8xx/Makefile
@@ -27,16 +27,29 @@ include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(CPU).a
 
-START	= start.o kgdb.o
-COBJS	= bedbug_860.o commproc.o cpu.o cpu_init.o	\
-	  fec.o fdt.o i2c.o interrupts.o lcd.o scc.o	\
-	  serial.o speed.o spi.o \
-	  traps.o upatch.o video.o
-SOBJS	= plprcr_write.o
-
-SRCS	:= $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
-START	:= $(addprefix $(obj),$(START))
+START-y	+= start.o
+START-y	+= kgdb.o
+COBJS-y	+= bedbug_860.o
+COBJS-y	+= commproc.o
+COBJS-y	+= cpu.o
+COBJS-y	+= cpu_init.o
+COBJS-y	+= fec.o
+COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
+COBJS-y	+= i2c.o
+COBJS-y	+= interrupts.o
+COBJS-y	+= lcd.o
+COBJS-y	+= scc.o
+COBJS-y	+= serial.o
+COBJS-y	+= speed.o
+COBJS-y	+= spi.o
+COBJS-y	+= traps.o
+COBJS-y	+= upatch.o
+COBJS-y	+= video.o
+SOBJS-y	+= plprcr_write.o
+
+SRCS	:= $(START-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS	:= $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
+START	:= $(addprefix $(obj),$(START-y))
 
 all:	$(obj).depend $(START) $(LIB)
 
-- 
1.5.4.5




From plagnioj at jcrosoft.com  Wed Apr  2 08:03:58 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed,  2 Apr 2008 08:03:58 +0200
Subject: [U-Boot-Users] [PATCH 2/2] ds174x: Fix warning on return in rtc_get
	and rtc_set function
In-Reply-To: <1207116238-7253-2-git-send-email-plagnioj@jcrosoft.com>
References: <1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>
	<1207116238-7253-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>

ds174x.c: In function 'rtc_get':
ds174x.c:117: warning: no return statement in function returning non-void
ds174x.c: In function 'rtc_set':
ds174x.c:146: warning: 'return' with a value, in function returning void

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/drivers/rtc/ds174x.c b/drivers/rtc/ds174x.c
index 81a9cb3..eb3ca88 100644
--- a/drivers/rtc/ds174x.c
+++ b/drivers/rtc/ds174x.c
@@ -114,6 +114,7 @@ int rtc_get( struct rtc_time *tmp )
 		tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
 		tmp->tm_hour, tmp->tm_min, tmp->tm_sec );
 #endif
+	return 0;
 }
 
 void rtc_set( struct rtc_time *tmp )
@@ -142,8 +143,6 @@ void rtc_set( struct rtc_time *tmp )
 
 	/* unlock clock registers after read */
 	rtc_write( RTC_CONTROLA, ( reg_a  & ~RTC_CA_WRITE ));
-
-	return 0;
 }
 
 void rtc_reset (void)
-- 
1.5.4.5




From andre.schwarz at matrix-vision.de  Wed Apr  2 10:01:21 2008
From: andre.schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Wed, 02 Apr 2008 10:01:21 +0200
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <20080401111227.98e8b4b8.kim.phillips@freescale.com>
References: <1206714585-13569-1-git-send-email-tor@excito.com>	<47F23996.7070105@matrix-vision.de>
	<20080401111227.98e8b4b8.kim.phillips@freescale.com>
Message-ID: <47F33D51.80803@matrix-vision.de>

Kim Phillips schrieb:
> On Tue, 01 Apr 2008 15:33:10 +0200
> Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:
> 
>> I would expect something like
>>
>>         if ( priv->flags & TSEC_REDUCED )
>>                 regs->ecntrl |= ECNTRL_RPM;
> 
> yeah, that register should be r/o..
> 
you're right.
The register actually _is_ r/o. But datasheet says "r/w" ...

>> @Kim : Did you ever run a MPC834x with a RGMII  PHY ? Is it known to work ?
> 
> 834x?  I haven't, but I also haven't a reason why it would not work :)

ok - I'll have a closer look into the hardware.
> 
> Kim

thanks,
Andr?


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From peter.pearse at arm.com  Wed Apr  2 10:05:02 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Wed, 2 Apr 2008 09:05:02 +0100
Subject: [U-Boot-Users] ARM march architecture version for arm926ejs in
	config.mk
In-Reply-To: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF1@blrms.slti.sanyo.co.in>
Message-ID: <000001c89498$41095690$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: Gururaja Hebbar K R [mailto:gururajakr at sanyo.co.in] 
> Sent: 02 April 2008 03:05
> To: u-boot-users at lists.sourceforge.net
> Cc: wd at denx.de; Peter Pearse
> Subject: ARM march architecture version for arm926ejs in config.mk
> 
> Hi,
> 
> i have seen questions on the mailing list about march for 
> arm926ejs being mentioned as -march=armv4.
> 
---snip---
> 
> But according to the Wikipedia
> (http://en.wikipedia.org/wiki/ARM_architecture ) , 
> architecture version for ARM926EJ-S  is ARMv5TEJ.

Correct
Please confirm, off list, that you can access http://infocenter.arm.com/
for your future ARM architecture investigations....

> 
> Kindly can someone explain why this is done. Previously few 
> have provided the patch but all have been rejected or not applied.

I think the position is that -march=armv4 is compatible with more toolchains
and builds code which runs on all later architectures,
whilst the correct architecture setting provides minimal benefits (to
U-Boot).

However, I'm still working on my compiler options patch,
mainly to satisfy the list comments re -msoft-float.

I hope to have it available for the next merge window.

Meanwhile you can get the current snapshot from 
www.linux-arm.org/git/u-boot-armdev.git/080212_options.

I'd be interested in your comments.

Regards

Peter





From plagnioj at jcrosoft.com  Wed Apr  2 10:42:02 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 2 Apr 2008 10:42:02 +0200
Subject: [U-Boot-Users] ARM march architecture version for arm926ejs
	in	config.mk
In-Reply-To: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF1@blrms.slti.sanyo.co.in>
References: <mailman.97392.1207014378.31037.u-boot-users@lists.sourceforge.net>
	<5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF1@blrms.slti.sanyo.co.in>
Message-ID: <20080402084202.GA12870@game.jcrosoft.org>

On 07:34 Wed 02 Apr     , Gururaja Hebbar K R wrote:
> Hi,
> 
> i have seen questions on the mailing list about march for arm926ejs
> being mentioned as -march=armv4.
> 
> http://www.nabble.com/-PATCH--ARM%3A-Fix-arm-architecture-version-for-ar
> m926ejs-td5195486.html#a5210157
> 
> http://www.nabble.com/-patch-u-boot-git-2-3--better-ARM9-compiler-option
> s-td14962153.html#a15009686

I've reject this patch due to warnings on my toolchains

I've plan to investigate on this soon

Best Regards,
J.



From vivekutal at gmail.com  Wed Apr  2 11:09:11 2008
From: vivekutal at gmail.com (Vivek Kutal)
Date: Wed, 2 Apr 2008 14:39:11 +0530
Subject: [U-Boot-Users] PXA270 UDC in u-boot
Message-ID: <e9aaecc40804020209g9214ac1jf054d4e5e9d17075@mail.gmail.com>

Hi ,
     Has anyone tried using pxa270 udc in u-boot  ?


--
Thanks
Vivek



From jin12a at eyou.com  Wed Apr  2 11:15:14 2008
From: jin12a at eyou.com (xxxxxinli)
Date: Wed, 02 Apr 2008 17:15:14 +0800
Subject: u-boot-users,¹úÄÚÊ״δßÃ߸߷åÂÛ̳,Ãû¼ÒÜöÝÍ£¡
Message-ID: <E1Jgz4B-00020v-9p@mail.sourceforge.net>

???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? 
20 08?4 ?27? ?30? ???? ???? ???? ???? ???? ???? ???? "?
 
?? ???? ???? ???? ???? ???? ???? ???? ???? ??
 ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? 
?? ???? ???? ???? ???? ???? ???? ???? ???? ???? ??
 ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ?

 
??? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? ???? 
     ?? ???? ???? ???? ???? ???? ???? ???? ?
? ???? ???? ???? ???? ???? ???? ???? ???? ??
 ???? ???? ???? ???? ??
 ???? ???? ??"? ???? ???? ???? ?"?? ?

 
??? ??01 0-47 1863 42   ???? ?off ice@ cnps ychi c.or g
? ???? www. cnps ychi c.or g




From Manuel.Sahm at feig.de  Wed Apr  2 11:31:54 2008
From: Manuel.Sahm at feig.de (Manuel Sahm)
Date: Wed, 02 Apr 2008 11:31:54 +0200
Subject: [U-Boot-Users] make env
In-Reply-To: <20080325201148.E5F79248BF@gemini.denx.de>
References: <20080325201148.E5F79248BF@gemini.denx.de>
Message-ID: <47F3528A.3000202@feig.de>

Hello,

I try to modify the env toll for accessing nand flash.

My problem the structure of the enviroment:
If I understand:
4 byte crc; 1 byte flags, 0x20000-5 byte data.

The Enviroment has a size of 0x20000 bytes. There is a redundant 
enviroment too.(same size)

The CRC is over the data bytes,( not the flags byte included) , right ??

What about the flag byte, which values should I have to write here ?

Thank you very much

Manuel Sahm

Wolfgang Denk schrieb:
> In message <47E8F686.9020903 at feig.de> you wrote:
>   
>> I took the U-Boot version 1.3.2; now I am able to generate the make env 
>> -> fw_printenv utility.
>>
>> I copy the jw_printenv binary and rename it to fw_setenv.
>>     
> ...
>   
>> I want to access a NAND flash. [Pagesize = 0x800; ERASEBLOCKSIZE=0x20000]
>>     
> ...
>   
>> Is this correct ?
>>     
>
> No. the fw_env tools are written with NOR flash support in mind. Don't
> expect this to work unchanged on NAND flash.
>
> Best regards,
>
> Wolfgang Denk
>
>   

-- 
Freundliche Gr??e / Best regards 

Manuel Sahm	

Research & Development

FEIG ELECTRONIC GmbH
Lange Stra?e 4
35781 Weilburg
Germany
 
Tel.:  +49 (0)6471-3109.492
Fax.:  +49 (0)6471-3109.99
email: manuel.sahm at feig.de
internet: http://www.feig.de

------------------------------------------------------------------------
Amtsgericht Limburg HRB 3178
Gesch?ftsf?hrer: Dipl.-Ing. Wolfgang Feig
------------------------------------------------------------------------

------------------------------------------------------------------------
Diese Email (eingeschlossen die Anhaenge) unterliegt Urheberrecht, die
Informationen sind vertraulich und rechtswirksam privilegiert. Der
Gebrauch dieser Email oder der Anhaenge von einem anderen als den
Adressaten ist nicht gestattet und unrechtmaessig.

This email (including any attachments) is subject to copyright, the
information in it is confidential, and it is legally privileged. Use of
this email or of any information in it other than by the addressee is
unauthorised and unlawful.
------------------------------------------------------------------------




From elbaevae_1961 at 39gam.com  Wed Apr  2 12:05:57 2008
From: elbaevae_1961 at 39gam.com (dessy dodo)
Date: Wed, 2 Apr 2008 20:05:57 +1000
Subject: [U-Boot-Users] Glittering shimmering luxury
Message-ID: <77BB0C2A-1980-722E-EF41-05D89E4E03B8@lists.sourceforge.net>

It cannot get louder than thi

I never knew telling time can make one so happy indulging in timepiece collection. http://www.poleigea.com/



From wd at denx.de  Wed Apr  2 12:39:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 02 Apr 2008 12:39:50 +0200
Subject: [U-Boot-Users] make env
In-Reply-To: Your message of "Wed, 02 Apr 2008 11:31:54 +0200."
	<47F3528A.3000202@feig.de>
Message-ID: <20080402103950.98436243AB@gemini.denx.de>

Dear Manuel,

in message <47F3528A.3000202 at feig.de> you wrote:
> 
> My problem the structure of the enviroment:
> If I understand:
> 4 byte crc; 1 byte flags, 0x20000-5 byte data.

Correct - the flag byte is only present if you use redundant
environment.

> The CRC is over the data bytes,( not the flags byte included) , right ??

Correct. That's because the flasg byte indicates  the  state  of  the
environment  copy  (current  ->  bit = 1, or obsolete -> bit = 0). It
relies on the feature of NOR flash that you can  always  program  '1'
bits to '0', even single bits in a single byte.

> What about the flag byte, which values should I have to write here ?

See above. But you might have problems doing such  a  thing  on  NAND
storage.

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: wd at denx.de
I have a very small mind and must live with it.    -- Edsger Dijkstra



From Manuel.Sahm at feig.de  Wed Apr  2 13:18:18 2008
From: Manuel.Sahm at feig.de (Manuel Sahm)
Date: Wed, 02 Apr 2008 13:18:18 +0200
Subject: [U-Boot-Users] make env
In-Reply-To: <20080402103950.98436243AB@gemini.denx.de>
References: <20080402103950.98436243AB@gemini.denx.de>
Message-ID: <47F36B7A.9080104@feig.de>

Hello,

how does uboot handle this flag byte ? (i I use redundant nand)

What initial value must this flag have?
Same value for enviroment1 and enviroment2 ?

If I make a "saveenv" which env. is used, and what values are then 
written to the NAND flash to set it as aktiv/deactive ?

For example:

In Linux I want to write my own Enviroment to the redundant Env: What 
must be the value of the flag byte to set this redundant enviroment 
actik, so that UBoot will use this one ?
And: Which value do I have to write tho the other "old" enviroment in 
NAND flash, so that this one becomes deactive ?

Thank you very much

Manuel Sahm


Wolfgang Denk schrieb:
> Dear Manuel,
>
> in message <47F3528A.3000202 at feig.de> you wrote:
>   
>> My problem the structure of the enviroment:
>> If I understand:
>> 4 byte crc; 1 byte flags, 0x20000-5 byte data.
>>     
>
> Correct - the flag byte is only present if you use redundant
> environment.
>
>   
>> The CRC is over the data bytes,( not the flags byte included) , right ??
>>     
>
> Correct. That's because the flasg byte indicates  the  state  of  the
> environment  copy  (current  ->  bit = 1, or obsolete -> bit = 0). It
> relies on the feature of NOR flash that you can  always  program  '1'
> bits to '0', even single bits in a single byte.
>
>   
>> What about the flag byte, which values should I have to write here ?
>>     
>
> See above. But you might have problems doing such  a  thing  on  NAND
> storage.
>
> Best regards,
>
> Wolfgang Denk
>
>   

-- 
Freundliche Gr??e / Best regards 

Manuel Sahm	

Research & Development

FEIG ELECTRONIC GmbH
Lange Stra?e 4
35781 Weilburg
Germany
 
Tel.:  +49 (0)6471-3109.492
Fax.:  +49 (0)6471-3109.99
email: manuel.sahm at feig.de
internet: http://www.feig.de

------------------------------------------------------------------------
Amtsgericht Limburg HRB 3178
Gesch?ftsf?hrer: Dipl.-Ing. Wolfgang Feig
------------------------------------------------------------------------

------------------------------------------------------------------------
Diese Email (eingeschlossen die Anhaenge) unterliegt Urheberrecht, die
Informationen sind vertraulich und rechtswirksam privilegiert. Der
Gebrauch dieser Email oder der Anhaenge von einem anderen als den
Adressaten ist nicht gestattet und unrechtmaessig.

This email (including any attachments) is subject to copyright, the
information in it is confidential, and it is legally privileged. Use of
this email or of any information in it other than by the addressee is
unauthorised and unlawful.
------------------------------------------------------------------------




From plagnioj at jcrosoft.com  Wed Apr  2 13:37:50 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed,  2 Apr 2008 13:37:50 +0200
Subject: [U-Boot-Users] [PATCH] cmd_nand: Fix warning: dereferencing
	type-punned pointer will break strict-aliasing rules
In-Reply-To: <1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
References: <1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>

cmd_nand.c:353: warning: dereferencing type-punned pointer will break strict-aliasing rules
cmd_nand.c:356: warning: dereferencing type-punned pointer will break strict-aliasing rules

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 7b1f830..2906aed 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -84,7 +84,7 @@ static int nand_dump(nand_info_t *nand, ulong off)
 
 /* ------------------------------------------------------------------------- */
 
-static inline int str2long(char *p, ulong *num)
+static inline int str2long(char *p, loff_t *num)
 {
 	char *endptr;
 
@@ -93,7 +93,7 @@ static inline int str2long(char *p, ulong *num)
 }
 
 static int
-arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, ulong *size)
+arg_off_size(int argc, char *argv[], nand_info_t *nand, loff_t *off, size_t *size)
 {
 	int idx = nand_curr_device;
 #if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_JFFS2_CMDLINE)
@@ -136,7 +136,7 @@ arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, ulong *size)
 	}
 
 	if (argc >= 2) {
-		if (!(str2long(argv[1], size))) {
+		if (!(str2long(argv[1], (loff_t*)size))) {
 			printf("'%s' is not a number\n", argv[1]);
 			return -1;
 		}
@@ -158,7 +158,9 @@ out:
 int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 {
 	int i, dev, ret;
-	ulong addr, off, size;
+	ulong addr;
+	loff_t off;
+	size_t size;
 	char *cmd, *s;
 	nand_info_t *nand;
 #ifdef CFG_NAND_QUIET
@@ -477,11 +479,11 @@ U_BOOT_CMD(nand, 5, 1, do_nand,
 	"nand unlock [offset] [size] - unlock section\n");
 
 static int nand_load_image(cmd_tbl_t *cmdtp, nand_info_t *nand,
-			   ulong offset, ulong addr, char *cmd)
+			   loff_t offset, ulong addr, char *cmd)
 {
 	int r;
 	char *ep, *s;
-	ulong cnt;
+	size_t cnt;
 	image_header_t *hdr;
 	int jffs2 = 0;
 #if defined(CONFIG_FIT)
diff --git a/include/nand.h b/include/nand.h
index 3c0752e..b4ee14f 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -34,22 +34,22 @@ extern int nand_curr_device;
 extern nand_info_t nand_info[];
 extern void nand_init(void);
 
-static inline int nand_read(nand_info_t *info, ulong ofs, ulong *len, u_char *buf)
+static inline int nand_read(nand_info_t *info, loff_t ofs, size_t *len, u_char *buf)
 {
-	return info->read(info, ofs, *len, (size_t *)len, buf);
+	return info->read(info, ofs, *len, len, buf);
 }
 
-static inline int nand_write(nand_info_t *info, ulong ofs, ulong *len, u_char *buf)
+static inline int nand_write(nand_info_t *info, loff_t ofs, size_t *len, u_char *buf)
 {
-	return info->write(info, ofs, *len, (size_t *)len, buf);
+	return info->write(info, ofs, *len, len, buf);
 }
 
-static inline int nand_block_isbad(nand_info_t *info, ulong ofs)
+static inline int nand_block_isbad(nand_info_t *info, loff_t ofs)
 {
 	return info->block_isbad(info, ofs);
 }
 
-static inline int nand_erase(nand_info_t *info, ulong off, ulong size)
+static inline int nand_erase(nand_info_t *info, loff_t off, ulong size)
 {
 	struct erase_info instr;
 
@@ -68,8 +68,8 @@ static inline int nand_erase(nand_info_t *info, ulong off, ulong size)
 
 struct nand_write_options {
 	u_char *buffer;		/* memory block containing image to write */
-	ulong length;		/* number of bytes to write */
-	ulong offset;		/* start address in NAND */
+	size_t length;		/* number of bytes to write */
+	loff_t offset;		/* start address in NAND */
 	int quiet;		/* don't display progress messages */
 	int autoplace;		/* if true use auto oob layout */
 	int forcejffs2;		/* force jffs2 oob layout */
@@ -85,8 +85,8 @@ typedef struct nand_write_options nand_write_options_t;
 
 struct nand_read_options {
 	u_char *buffer;		/* memory block in which read image is written*/
-	ulong length;		/* number of bytes to read */
-	ulong offset;		/* start address in NAND */
+	size_t length;		/* number of bytes to read */
+	loff_t offset;		/* start address in NAND */
 	int quiet;		/* don't display progress messages */
 	int readoob;		/* put oob data in image */
 };
@@ -94,8 +94,8 @@ struct nand_read_options {
 typedef struct nand_read_options nand_read_options_t;
 
 struct nand_erase_options {
-	ulong length;		/* number of bytes to erase */
-	ulong offset;		/* first address in NAND to erase */
+	size_t length;		/* number of bytes to erase */
+	loff_t offset;		/* first address in NAND to erase */
 	int quiet;		/* don't display progress messages */
 	int jffs2;		/* if true: format for jffs2 usage
 				 * (write appropriate cleanmarker blocks) */
-- 
1.5.4.5




From giometti at enneenne.com  Wed Apr  2 13:41:10 2008
From: giometti at enneenne.com (Rodolfo Giometti)
Date: Wed, 2 Apr 2008 13:41:10 +0200
Subject: [U-Boot-Users] PXA270 UDC in u-boot
In-Reply-To: <e9aaecc40804020209g9214ac1jf054d4e5e9d17075@mail.gmail.com>
References: <e9aaecc40804020209g9214ac1jf054d4e5e9d17075@mail.gmail.com>
Message-ID: <20080402114110.GA8363@enneenne.com>

On Wed, Apr 02, 2008 at 02:39:11PM +0530, Vivek Kutal wrote:
> Hi ,
>      Has anyone tried using pxa270 udc in u-boot  ?

I posted a patch in the past... the patch was functional but it needed
some fixes, expecially regarding EP0 management.

Please, search into ML's archive.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at gnudd.com
Embedded Systems                     		giometti at linux.it
UNIX programming                     phone:     +39 349 2432127



From plagnioj at jcrosoft.com  Wed Apr  2 13:41:21 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed,  2 Apr 2008 13:41:21 +0200
Subject: [U-Boot-Users] [PATCH] mpc837xerdb: Fix warning: implicit
	declaration of function 'fdt_fixup_dr_usb'
In-Reply-To: <1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1207136481-19429-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/board/freescale/mpc837xerdb/mpc837xerdb.c b/board/freescale/mpc837xerdb/mpc837xerdb.c
index 83fb60d..965bb67 100644
--- a/board/freescale/mpc837xerdb/mpc837xerdb.c
+++ b/board/freescale/mpc837xerdb/mpc837xerdb.c
@@ -16,10 +16,10 @@
 #include <i2c.h>
 #include <asm/io.h>
 #include <asm/fsl_serdes.h>
+#include <fdt_support.h>
 #include <spd_sdram.h>
 #include <vsc7385.h>
 
-
 #if defined(CFG_DRAM_TEST)
 int
 testdram(void)
-- 
1.5.4.5




From toertel at gmail.com  Wed Apr  2 14:03:14 2008
From: toertel at gmail.com (Mark Jonas)
Date: Wed, 2 Apr 2008 14:03:14 +0200
Subject: [U-Boot-Users] [PATCH 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: <Pine.LNX.4.64.0803261452310.5050@axis700.grange>
References: <Pine.LNX.4.64.0803261426520.5050@axis700.grange>
	<Pine.LNX.4.64.0803261452310.5050@axis700.grange>
Message-ID: <9b3c8e40804020503h7ca1624ehb90830536b0423e9@mail.gmail.com>

Hi Ben and Sascha,

>  This patch adds a driver for the following smsc network controllers:
>  LAN9115
>  LAN9116
>  LAN9117
>  LAN9215
>  LAN9216
>  LAN9217

This patch most likely covers exactly what the SMSC LAN9x1x driver
covers I sent earlier in March. How is the decision going to be made
which driver is going to be the one that will be integrated into
U-Boot?

Regards,
Mark



From gvb.uboot at gmail.com  Wed Apr  2 14:11:20 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Wed, 02 Apr 2008 08:11:20 -0400
Subject: [U-Boot-Users] [PATCH 0/2] MPC8xx: Fix libfdt support
 introduced in commit 77ff7b74
In-Reply-To: <1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <47F377E8.8040703@gmail.com>

Jean-Christophe PLAGNIOL-VILLARD wrote:
> fdt.c: In function 'ft_cpu_setup':
> fdt.c:33: warning: implicit declaration of function 'do_fixup_by_prop_u32'
> fdt.c:39: warning: implicit declaration of function 'do_fixup_by_compat_u32'
> fdt.c:43: warning: implicit declaration of function 'fdt_fixup_ethernet'
> fdt.c:45: warning: implicit declaration of function 'fdt_fixup_memory'
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/cpu/mpc8xx/Makefile b/cpu/mpc8xx/Makefile
> index dbdc2e0..5f70459 100644
> --- a/cpu/mpc8xx/Makefile
> +++ b/cpu/mpc8xx/Makefile
> @@ -27,16 +27,29 @@ include $(TOPDIR)/config.mk
>  
>  LIB	= $(obj)lib$(CPU).a
>  
> -START	= start.o kgdb.o
> -COBJS	= bedbug_860.o commproc.o cpu.o cpu_init.o	\
> -	  fec.o fdt.o i2c.o interrupts.o lcd.o scc.o	\
> -	  serial.o speed.o spi.o \
> -	  traps.o upatch.o video.o
> -SOBJS	= plprcr_write.o
> -
> -SRCS	:= $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
> -OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
> -START	:= $(addprefix $(obj),$(START))
> +START-y	+= start.o
> +START-y	+= kgdb.o
> +COBJS-y	+= bedbug_860.o
> +COBJS-y	+= commproc.o
> +COBJS-y	+= cpu.o
> +COBJS-y	+= cpu_init.o
> +COBJS-y	+= fec.o
> +COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
> +COBJS-y	+= i2c.o
> +COBJS-y	+= interrupts.o
> +COBJS-y	+= lcd.o
> +COBJS-y	+= scc.o
> +COBJS-y	+= serial.o
> +COBJS-y	+= speed.o
> +COBJS-y	+= spi.o
> +COBJS-y	+= traps.o
> +COBJS-y	+= upatch.o
> +COBJS-y	+= video.o
> +SOBJS-y	+= plprcr_write.o
> +
> +SRCS	:= $(START-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
> +OBJS	:= $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
> +START	:= $(addprefix $(obj),$(START-y))
>  
>  all:	$(obj).depend $(START) $(LIB)

I did this too, but did not do as good a job (I did not change SOBJS to 
SOBJS-y and START to START-y).  Reference for my version:
   <http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38885/>

I've replaced my version with J-C's version in u-boot-fdt.

Acked-by: Gerald Van Baren <vanbaren at cideas.com>

P.S. Thanks, Jean-Christophe, for doing a bunch of warning clean up.




From toertel at gmail.com  Wed Apr  2 14:11:44 2008
From: toertel at gmail.com (Mark Jonas)
Date: Wed, 2 Apr 2008 14:11:44 +0200
Subject: [U-Boot-Users] [PATCH] sh,
	net: Updated SMSC LAN911x driver and support for MPR2 board
In-Reply-To: <47EA5ADC.7050901@gmail.com>
References: <9b3c8e40803100341w4f3f99a3g7b924e5db9f0eb0@mail.gmail.com>
	<47D543B1.5000009@gmail.com>
	<9b3c8e40803260005n650ba9b6w22eea179884073e3@mail.gmail.com>
	<47EA5ADC.7050901@gmail.com>
Message-ID: <9b3c8e40804020511u4ffdd94by87f4437230ff78d3@mail.gmail.com>

Hi Ben,

>  Sorry, tonight has been time-shifted.  I'll have a look today.

Any news?

Regards,
Mark



From fboudra at gmail.com  Wed Apr  2 14:13:23 2008
From: fboudra at gmail.com (Fathi Boudra)
Date: Wed, 2 Apr 2008 14:13:23 +0200
Subject: [U-Boot-Users] which config to choose for MPC8347E cpu ?
Message-ID: <6a2e33620804020513i3533e358nf0537e0287000d0b@mail.gmail.com>

Hi,

I have a custom board with a MPC8347E and U-Boot doesn't have a config for
this cpu.
which config is more appropriate to use for my board ? (maybe MPC8349EMDS or
sbc8349 or tqm834x ?).

any tips ? TIA.

cheers,

Fathi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080402/559a7dc4/attachment.htm 

From biggerbadderben at gmail.com  Wed Apr  2 14:18:09 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Wed, 2 Apr 2008 08:18:09 -0400
Subject: [U-Boot-Users] [PATCH 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: <9b3c8e40804020503h7ca1624ehb90830536b0423e9@mail.gmail.com>
References: <Pine.LNX.4.64.0803261426520.5050@axis700.grange>
	<Pine.LNX.4.64.0803261452310.5050@axis700.grange>
	<9b3c8e40804020503h7ca1624ehb90830536b0423e9@mail.gmail.com>
Message-ID: <f8328f7c0804020518u19487b37x2d0ac6ed53ae0f4c@mail.gmail.com>

Hi Mark,

On Wed, Apr 2, 2008 at 8:03 AM, Mark Jonas <toertel at gmail.com> wrote:
> Hi Ben and Sascha,
>
>
>  >  This patch adds a driver for the following smsc network controllers:
>  >  LAN9115
>  >  LAN9116
>  >  LAN9117
>  >  LAN9215
>  >  LAN9216
>  >  LAN9217
>
>  This patch most likely covers exactly what the SMSC LAN9x1x driver
>  covers I sent earlier in March. How is the decision going to be made
>  which driver is going to be the one that will be integrated into
>  U-Boot?
>

This driver seems to be a superset of yours, so this would be the one
to go in once it's compliant.  Sorry for the lack of communication on
my part.

regards,
Ben



From biggerbadderben at gmail.com  Wed Apr  2 14:22:59 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Wed, 2 Apr 2008 08:22:59 -0400
Subject: [U-Boot-Users] which config to choose for MPC8347E cpu ?
In-Reply-To: <6a2e33620804020513i3533e358nf0537e0287000d0b@mail.gmail.com>
References: <6a2e33620804020513i3533e358nf0537e0287000d0b@mail.gmail.com>
Message-ID: <f8328f7c0804020522u1c37280la365e03d037a5bd2@mail.gmail.com>

Hi Fathi,

On Wed, Apr 2, 2008 at 8:13 AM, Fathi Boudra <fboudra at gmail.com> wrote:
> Hi,
>
> I have a custom board with a MPC8347E and U-Boot doesn't have a config for
> this cpu.
> which config is more appropriate to use for my board ? (maybe MPC8349EMDS or
> sbc8349 or tqm834x ?).
>
> any tips ? TIA.

The schematic for the MPC8349EMDS is available on Freescale's web
site, and I believe TQS makes their schematics available too.  I don't
know about the SBC one (Wind River, maybe?).  Ultimately, compare
schematics to your board and choose the one that's most similar as a
starting point.  IIRC 8347 is a subset of 8349 (one less PCI bus or
something like that) so the 8349 configs should be fine.

regards,
Ben



From andre.schwarz at matrix-vision.de  Wed Apr  2 14:40:01 2008
From: andre.schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Wed, 02 Apr 2008 14:40:01 +0200
Subject: [U-Boot-Users] which config to choose for MPC8347E cpu ?
In-Reply-To: <6a2e33620804020513i3533e358nf0537e0287000d0b@mail.gmail.com>
References: <6a2e33620804020513i3533e358nf0537e0287000d0b@mail.gmail.com>
Message-ID: <47F37EA1.5000807@matrix-vision.de>

Fathi,

there are 3 different MPC834x (3,7 and 9) which all have same silicon.
The difference is the package.

The 43 has a small package and the 49 a big one. The 47 is available in 
both. Package size defines PCI bus (small has 1x 32Bit, large has 64-Bit 
or 2x 32Bit) and memory bus width.

Which one do you have ?

I'm working with a 43 right now and it works fine.
My starting point has been the MPC8349EMDS.

I can share my config if you want to - please let me know.

regards,
Andr? Schwarz
Matrix Vision


Fathi Boudra schrieb:
> Hi,
> 
> I have a custom board with a MPC8347E and U-Boot doesn't have a config 
> for this cpu.
> which config is more appropriate to use for my board ? (maybe 
> MPC8349EMDS or sbc8349 or tqm834x ?).
> 
> any tips ? TIA.
> 
> cheers,
> 
> Fathi
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From marc.leeman at gmail.com  Wed Apr  2 14:53:57 2008
From: marc.leeman at gmail.com (Marc Leeman)
Date: Wed, 2 Apr 2008 14:53:57 +0200
Subject: [U-Boot-Users] which config to choose for MPC8347E cpu ?
In-Reply-To: <f8328f7c0804020522u1c37280la365e03d037a5bd2@mail.gmail.com>
References: <6a2e33620804020513i3533e358nf0537e0287000d0b@mail.gmail.com>
	<f8328f7c0804020522u1c37280la365e03d037a5bd2@mail.gmail.com>
Message-ID: <20080402125357.GD5322@chiana.homelinux.org>

> The schematic for the MPC8349EMDS is available on Freescale's web
> site, and I believe TQS makes their schematics available too.  I don't
> know about the SBC one (Wind River, maybe?).  Ultimately, compare
> schematics to your board and choose the one that's most similar as a
> starting point.  IIRC 8347 is a subset of 8349 (one less PCI bus or
> something like that) so the 8349 configs should be fine.

Yep,

I started from mpc8349emds and worked further from there. Reminds me to
re-submit my board configs again after cleanup.

-- 
  greetz, marc
It's not Kansas, and you're way too homely to be Auntie Em, but...  Come here, Toto.
	Crichton - That Old Black Magic
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080402/87cf611a/attachment.pgp 

From 49705491969 at MPICOIN.COM  Wed Apr  2 16:22:41 2008
From: 49705491969 at MPICOIN.COM (Dragut Holdren)
Date: Wed, 2 Apr 2008 17:22:41 +0300
Subject: [U-Boot-Users] Get her what every woman desires
Message-ID: <F6F989B4.8%49705491969@MPICOIN.COM>

You are ready for Wall Street

View the best and widest variety of brand name watches here now http://www.loeirag.com/



From wd at denx.de  Wed Apr  2 16:33:31 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 02 Apr 2008 16:33:31 +0200
Subject: [U-Boot-Users] make env
In-Reply-To: Your message of "Wed, 02 Apr 2008 13:18:18 +0200."
	<47F36B7A.9080104@feig.de>
Message-ID: <20080402143331.8BDF62476E@gemini.denx.de>

In message <47F36B7A.9080104 at feig.de> you wrote:
> 
> how does uboot handle this flag byte ? (i I use redundant nand)

I already answered that. See my previous message.

> What initial value must this flag have?
> Same value for enviroment1 and enviroment2 ?

No. Please see my previous mesage, and the code.

> If I make a "saveenv" which env. is used, and what values are then 

See the code.

> And: Which value do I have to write tho the other "old" enviroment in 
> NAND flash, so that this one becomes deactive ?

RTFS...

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: wd at denx.de
Old programmers never die, they just branch to a new address.



From sr at denx.de  Wed Apr  2 16:34:09 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 2 Apr 2008 16:34:09 +0200
Subject: [U-Boot-Users] [PATCH] cmd_nand: Fix warning: dereferencing
	type-punned pointer will break strict-aliasing rules
In-Reply-To: <1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
	<1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <200804021634.09334.sr@denx.de>

On Wednesday 02 April 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
> cmd_nand.c:353: warning: dereferencing type-punned pointer will break
> strict-aliasing rules cmd_nand.c:356: warning: dereferencing type-punned
> pointer will break strict-aliasing rules
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

NAK.

Patch doesn't work. After applying I get the following messages on Kilauea:

=> nand write 100000 0 100000

NAND write: device 0 offset 0x0, size 0x0
 0 bytes written: OK
=> nand read 200000 0 100000

NAND read: device 0 offset 0x0, size 0x0
 0 bytes read: OK

So nothing is read/written at all. This is how it behaves without this patch:

=> nand write 100000 0 100000

NAND write: device 0 offset 0x0, size 0x100000
 1048576 bytes written: OK
=> nand read 200000 0 100000

NAND read: device 0 offset 0x0, size 0x100000
 1048576 bytes read: OK


Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Wed Apr  2 16:39:19 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 02 Apr 2008 16:39:19 +0200
Subject: [U-Boot-Users] [PATCH] cmd_nand: Fix warning: dereferencing
	type-punned pointer will break strict-aliasing rules
In-Reply-To: Your message of "Wed, 02 Apr 2008 13:37:50 +0200."
	<1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080402143919.B479F2476E@gemini.denx.de>

In message <1207136270-19315-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> cmd_nand.c:353: warning: dereferencing type-punned pointer will break strict-aliasing rules
> cmd_nand.c:356: warning: dereferencing type-punned pointer will break strict-aliasing rules
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 7b1f830..2906aed 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -84,7 +84,7 @@ static int nand_dump(nand_info_t *nand, ulong off)
>  
>  /* ------------------------------------------------------------------------- */
>  
> -static inline int str2long(char *p, ulong *num)
> +static inline int str2long(char *p, loff_t *num)

I think this is plain wrong. It may silence the warning, but it is
wrong.

The type is the result of calling simple_strtoul(), and this function
returns, um, and unsigned long. And not an offset type.

> -arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, ulong *size)
> +arg_off_size(int argc, char *argv[], nand_info_t *nand, loff_t *off, size_t *size)

No. That's all wrong.


NAK.

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: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.



From wd at denx.de  Wed Apr  2 16:42:10 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 02 Apr 2008 16:42:10 +0200
Subject: [U-Boot-Users] which config to choose for MPC8347E cpu ?
In-Reply-To: Your message of "Wed, 02 Apr 2008 08:22:59 EDT."
	<f8328f7c0804020522u1c37280la365e03d037a5bd2@mail.gmail.com>
Message-ID: <20080402144210.3B09F2476E@gemini.denx.de>

In message <f8328f7c0804020522u1c37280la365e03d037a5bd2 at mail.gmail.com> you wrote:
> 
> The schematic for the MPC8349EMDS is available on Freescale's web
> site, and I believe TQS makes their schematics available too.  I don't

TQ only provisdes the schematics for the carrier board, but not for
the CPU modules.


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: wd at denx.de
God is real, unless declared integer.



From plagnioj at jcrosoft.com  Wed Apr  2 16:50:12 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 2 Apr 2008 16:50:12 +0200
Subject: [U-Boot-Users] [PATCH] cmd_nand: Fix warning:
	dereferencing	type-punned pointer will break strict-aliasing rules
In-Reply-To: <20080402143919.B479F2476E@gemini.denx.de>
References: <1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
	<20080402143919.B479F2476E@gemini.denx.de>
Message-ID: <20080402145012.GA18098@game.jcrosoft.org>

On 16:39 Wed 02 Apr     , Wolfgang Denk wrote:
> In message <1207136270-19315-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> > cmd_nand.c:353: warning: dereferencing type-punned pointer will break strict-aliasing rules
> > cmd_nand.c:356: warning: dereferencing type-punned pointer will break strict-aliasing rules
> > 
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> > 
> > diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> > index 7b1f830..2906aed 100644
> > --- a/common/cmd_nand.c
> > +++ b/common/cmd_nand.c
> > @@ -84,7 +84,7 @@ static int nand_dump(nand_info_t *nand, ulong off)
> >  
> >  /* ------------------------------------------------------------------------- */
> >  
> > -static inline int str2long(char *p, ulong *num)
> > +static inline int str2long(char *p, loff_t *num)
> 
> I think this is plain wrong. It may silence the warning, but it is
> wrong.
> 
> The type is the result of calling simple_strtoul(), and this function
> returns, um, and unsigned long. And not an offset type.
I agree
> 
> > -arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, ulong *size)
> > +arg_off_size(int argc, char *argv[], nand_info_t *nand, loff_t *off, size_t *size)
> 
> No. That's all wrong.
I disagree, the true type of the offest is loff_t and size is size_t in
the linux/mtd.

Maybe we need to do the cast to ulong in this function.

Best Regards,
J.



From galak at kernel.crashing.org  Wed Apr  2 16:55:58 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 2 Apr 2008 09:55:58 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: <20080401204126.31CD724544@gemini.denx.de>
References: <20080401204126.31CD724544@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804020953090.8273@blarg.am.freescale.net>

On Tue, 1 Apr 2008, Wolfgang Denk wrote:

> In message <5D708345-1CF3-46FA-B9D2-689C52625177 at kernel.crashing.org> you wrote:
> >
> > > I don't know RHEL - maybe you can update the RPM?
> >
> > Not that I'm aware of.  Its a box run by our IT department so I have
> > no ability to upgrade or modify things.  It looks like RHEL4 has the
> > same issue.
> >
> > ld2047$ rpm -qf /usr/include/md5.h
> > cyrus-sasl-devel-2.1.19-5.EL4
>
> I see. I have to go back pretty far in time to find such a
> configuration:
>
> 	$ ls -l /usr/include/md5.h
> 	-rw-r--r--  1 root root 1572 Apr 24  2006 /usr/include/md5.h
> 	$ rpm -qf /usr/include/md5.h
> 	cyrus-sasl-devel-2.1.20-6
> 	$ cat /etc/issue
> 	Fedora Core release 4 (Stentz)
>
> All more recent distros seem to have this fixed (and yes,
> cyrus-sasl-devel is installed in all of them):
>
> 	$ ls -l /usr/include/md5.h
> 	ls: /usr/include/md5.h: No such file or directory
> 	$ cat /etc/issue
> 	Fedora Core release 5 (Bordeaux)
>
> 	$ ls -l /usr/include/md5.h
> 	ls: /usr/include/md5.h: No such file or directory
> 	$ cat /etc/issue
> 	Fedora Core release 6 (Zod)
>
> 	$ ls -l /usr/include/md5.h
> 	ls: cannot access /usr/include/md5.h: No such file or directory
> 	$ cat /etc/issue
> 	Fedora release 7 (Moonshine)
>
> 	$ ls -l /usr/include/md5.h
> 	ls: cannot access /usr/include/md5.h: No such file or directory
> 	$ cat /etc/issue
> 	Fedora release 8 (Werewolf)
>
> > Any ideas on how to work around this?  Do we really intend to pick up
> > the system md5.h or should we be getting the one from u-boot/include/
> > md5.h?
>
> We need the system md5.h, I think. We'll investigate.

If I force things to use the md5.h in u-boot/include things seem to build.
Here's the patch for the forcing:

diff --git a/common/image.c b/common/image.c
index f04826a..cf3c9f3 100644
--- a/common/image.c
+++ b/common/image.c
@@ -53,7 +53,7 @@
 #endif

 #if defined(CONFIG_FIT)
-#include <md5.h>
+#include "../md5.h"
 #include <sha1.h>

 static int fit_check_ramdisk (const void *fit, int os_noffset,
@@ -70,7 +70,7 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 						int verify);
 #else
 #include "mkimage.h"
-#include <md5.h>
+#include "../include/md5.h"
 #include <time.h>
 #include <image.h>
 #endif /* !USE_HOSTCC*/
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index a51da45..b99ccc4 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -27,7 +27,7 @@

 #include <linux/types.h>
 #include <linux/string.h>
-#include <md5.h>
+#include "../include/md5.h"

 static void
 MD5Transform(__u32 buf[4], __u32 const in[16]);



From gvb.uboot at gmail.com  Wed Apr  2 17:28:26 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Wed, 02 Apr 2008 11:28:26 -0400
Subject: [U-Boot-Users] Pull request u-boot-fdt.git / FDT bugfix patches
In-Reply-To: <47F2CAFC.8070904@gmail.com>
References: <47F2CAFC.8070904@gmail.com>
Message-ID: <47F3A61A.9070003@gmail.com>

Jerry Van Baren wrote:
> Dear Wolfgang,
> 
> On the FDT front, we have <del>two</del>THREE outstanding bugfix patches:

I confirmed my error, the <nnnn> notation is indeed 32 bit cells per the 
DTC documentation (and his other changes are valuable improvements).  As 
a result, I've added Andy's patch to my queued-to-pull list.

Thanks,
gvb

The following changes since commit 3596d55eb22703d3f4f1b839fe4b000fabe081b3:
   Gerald Van Baren (1):
         Merge git://www.denx.de/git/u-boot into uboot

are available in the git repository at:

   git://git.denx.de/u-boot-fdt.git master

Andy Fleming (1):
       Fix fdt set command to conform to dts spec

Jean-Christophe PLAGNIOL-VILLARD (1):
       MPC8xx: Fix libfdt support introduced in commit 77ff7b74

Kim Phillips (1):
       remove remaining CONFIG_OF_HAS_{UBOOT_ENV,BD_T} code

  README              |   13 -----
  common/cmd_fdt.c    |  137 
+++++++++++++++++++++++++--------------------------
  common/ft_build.c   |  113 ------------------------------------------
  cpu/mpc8xx/Makefile |   33 +++++++++----
  lib_ppc/bootm.c     |   12 -----
  5 files changed, 90 insertions(+), 218 deletions(-)



From gvb.uboot at gmail.com  Wed Apr  2 17:29:36 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Wed, 02 Apr 2008 11:29:36 -0400
Subject: [U-Boot-Users] [PATCH] Fix fdt set command to conform to dts
 spec
In-Reply-To: <1207014356-1663-1-git-send-email-afleming@freescale.com>
References: <1207014356-1663-1-git-send-email-afleming@freescale.com>
Message-ID: <47F3A660.2060804@gmail.com>

Andy Fleming wrote:
> The fdt set command was treating properties specified as <00> and <0011>
> as byte streams, rather than as an array of cells.  As we already have
> syntax for expressing the desire for a stream of bytes ([ xx xx ...]),
> we should use the <> syntax to describe arrays of cells, which are always
> 32-bits per element.  If we imagine this likely (IMHO) scenario:
> 
>> fdt set /ethernet-phy at 1 reg <1>
> 
> With the old code, this would create a bad fdt, since the reg cell would be
> made to be one byte in length.  But the cell must be 4 bytes, so this would
> break mysteriously.

Confirmed, my bad.  Applied to the u-boot-fdt repo.

Thanks,
gvb



From tur at semihalf.com  Wed Apr  2 17:59:48 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Wed, 02 Apr 2008 17:59:48 +0200
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: <Pine.LNX.4.64.0804020953090.8273@blarg.am.freescale.net>
References: <20080401204126.31CD724544@gemini.denx.de>
	<Pine.LNX.4.64.0804020953090.8273@blarg.am.freescale.net>
Message-ID: <47F3AD74.4000900@semihalf.com>

Kumar Gala wrote:
> On Tue, 1 Apr 2008, Wolfgang Denk wrote:
[...]
>>> Any ideas on how to work around this?  Do we really intend to pick up
>>> the system md5.h or should we be getting the one from u-boot/include/
>>> md5.h?
>> We need the system md5.h, I think. We'll investigate.
> 
> If I force things to use the md5.h in u-boot/include things seem to build.
> Here's the patch for the forcing:

I think that generally it is a better idea to use U-Boot's includes when
building for the host system, as this gives us better control over what
exactly gets included. But then on the other hand, tools/Makefils has this:

CPPFLAGS   = -idirafter $(SRCTREE)/include \
		-idirafter $(OBJTREE)/include2 \
		-idirafter $(OBJTREE)/include \

Could anyone comment on the reasons why we try U-Boot's includes after
system includes? Perhaps it would be a good idea to reverse the order --
see below for a quick RFC patch (compile-tested on two arm and two ppc
boards, each arch with and without CONFIG_FIT enabled).

Kumar - could you try the patch out and see if it helps your build issue?

Regards,
Bartlomiej

diff --git a/tools/Makefile b/tools/Makefile
index 8784a6d..93f74aa 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -117,7 +117,7 @@ BINS        := $(addprefix $(obj),$(BIN_FILES))
  #
  # Use native tools and options
  #
-CPPFLAGS   = -idirafter $(SRCTREE)/include \
+CPPFLAGS   = -I $(SRCTREE)/include \
		-idirafter $(OBJTREE)/include2 \
		-idirafter $(OBJTREE)/include \
		-DTEXT_BASE=$(TEXT_BASE) -DUSE_HOSTCC




From info at fuarlar.us  Wed Apr  2 19:24:00 2008
From: info at fuarlar.us (=?iso-8859-9?B?TEVEJlJGSUQgZS1kYXZldGl5ZQ==?=)
Date: Wed, 2 Apr 2008 20:24:00 +0300
Subject: [U-Boot-Users] =?iso-8859-9?q?LED=26RFID_Ankara_Fuar=FDna_Davetli?=
	=?iso-8859-9?q?siniz!!!?=
Message-ID: <6bfe51925d10749fca4f33e82236f98a@fuarlar.us>




Untitled Document







  
     
  

  
    
      

        BU DAVET?YEN?N ?IKI?INI ALARAK YA DA L?NKTEK? FORMU DOLDURARAK 

      FUARIMIZI ?CRETS?Z Z?YARET EDEB?L?RS?N?Z. 

      

          

      

     
  

  
    Marmara Tan&#305;t&#305;m Fuarc&#305;l&#305;k

        ?stanbul (Merkez) Tel: +90 212 481 04 04 Fax: +90 212 481 04 74

        Ankara (Sube) Tel: +90 312 426 64 22 Fax: +90 312 426 64 41

        ?zmir (Sube)  Tel: +90 232 422 00 93 Fax: +90 232 422 16 33
        

     
  

  
    Listemizden ?&#305;kmak istiyorsan&#305;z l?tfen buraya t?klay?n. 
  





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080402/f6640cae/attachment.htm 

From galak at kernel.crashing.org  Wed Apr  2 19:24:49 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 2 Apr 2008 12:24:49 -0500
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: <47F3AD74.4000900@semihalf.com>
References: <20080401204126.31CD724544@gemini.denx.de>
	<Pine.LNX.4.64.0804020953090.8273@blarg.am.freescale.net>
	<47F3AD74.4000900@semihalf.com>
Message-ID: <FD4F1310-1D8E-4682-AD48-99CCE621F9D4@kernel.crashing.org>


On Apr 2, 2008, at 10:59 AM, Bartlomiej Sieka wrote:
> Kumar Gala wrote:
>> On Tue, 1 Apr 2008, Wolfgang Denk wrote:
> [...]
>>>> Any ideas on how to work around this?  Do we really intend to  
>>>> pick up
>>>> the system md5.h or should we be getting the one from u-boot/ 
>>>> include/
>>>> md5.h?
>>> We need the system md5.h, I think. We'll investigate.
>> If I force things to use the md5.h in u-boot/include things seem to  
>> build.
>> Here's the patch for the forcing:
>
> I think that generally it is a better idea to use U-Boot's includes  
> when
> building for the host system, as this gives us better control over  
> what
> exactly gets included. But then on the other hand, tools/Makefils  
> has this:
>
> CPPFLAGS   = -idirafter $(SRCTREE)/include \
> 		-idirafter $(OBJTREE)/include2 \
> 		-idirafter $(OBJTREE)/include \
>
> Could anyone comment on the reasons why we try U-Boot's includes after
> system includes? Perhaps it would be a good idea to reverse the  
> order --
> see below for a quick RFC patch (compile-tested on two arm and two ppc
> boards, each arch with and without CONFIG_FIT enabled).
>
> Kumar - could you try the patch out and see if it helps your build  
> issue?
>
> Regards,
> Bartlomiej
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 8784a6d..93f74aa 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -117,7 +117,7 @@ BINS        := $(addprefix $(obj),$(BIN_FILES))
> #
> # Use native tools and options
> #
> -CPPFLAGS   = -idirafter $(SRCTREE)/include \
> +CPPFLAGS   = -I $(SRCTREE)/include \
> 		-idirafter $(OBJTREE)/include2 \
> 		-idirafter $(OBJTREE)/include \
> 		-DTEXT_BASE=$(TEXT_BASE) -DUSE_HOSTCC

I get:

gcc -g -Wall -I /tmp/u-boot-85xx/include -idirafter /tmp/u-boot-85xx/ 
include2 -idirafter /tmp/u-boot-85xx/include -DTEXT_BASE=0xfff80000 - 
DUSE_HOSTCC -O -c -o image.o image.c
In file included from image.c:73:
/usr/include/md5.h:27: error: parse error before "UINT4"
/usr/include/md5.h:30: error: parse error before '}' token
/usr/include/md5.h:38: error: parse error before "PROTO_LIST"
/usr/include/md5.h:39: error: parse error before "PROTO_LIST"
/usr/include/md5.h:41: error: parse error before "PROTO_LIST"
/usr/include/md5.h:43: error: parse error before "PROTO_LIST"
image.c: In function `calculate_hash':
image.c:1944: warning: implicit declaration of function `md5'
make[1]: *** [image.o] Error 1
make[1]: Leaving directory `/tmp/u-boot-85xx/tools'
make: *** [tools] Error 2

- k



From kim.phillips at freescale.com  Wed Apr  2 19:50:26 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Wed, 2 Apr 2008 12:50:26 -0500
Subject: [U-Boot-Users] [PATCH] mpc837xerdb: Fix warning: implicit
 declaration of function 'fdt_fixup_dr_usb'
In-Reply-To: <1207136481-19429-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
	<1207136481-19429-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080402125026.65c98987.kim.phillips@freescale.com>

On Wed,  2 Apr 2008 13:41:21 +0200
Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com> wrote:

> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
Acked-by: Kim Phillips <kim.phillips at freescale.com>

Kim



From kenneth at southpole.se  Wed Apr  2 20:34:14 2008
From: kenneth at southpole.se (Kenneth Johansson)
Date: Wed, 02 Apr 2008 20:34:14 +0200
Subject: [U-Boot-Users] [PATCH] ads5121e DRAM init
Message-ID: <1207161254.14524.6.camel@localhost.localdomain>


    Do the DRAM init according to micron MT47H64M8B6-37E
    documentation.
    
    Signed-off-by: Kenneth Johansson <kenneth at southpole.se>

diff --git a/board/ads5121/ads5121.c b/board/ads5121/ads5121.c
index 8629b03..606cc6b 100644
--- a/board/ads5121/ads5121.c
+++ b/board/ads5121/ads5121.c
@@ -158,26 +158,18 @@ long int fixed_sdram (void)
 		im->mddrc.ddr_command = CFG_MICRON_NOP;
 
 	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_EM2;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_EM2;
-	im->mddrc.ddr_command = CFG_MICRON_EM3;
-	im->mddrc.ddr_command = CFG_MICRON_EN_DLL;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM2;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM3;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_MR_DLL_RESET;
+                                
 	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
 	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
-	im->mddrc.ddr_command = CFG_MICRON_OCD_DEFAULT;
-	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
+	im->mddrc.ddr_command = CFG_MICRON_RFSH;
+
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_MR;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM_OCD;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM_EXIT;
 
 	/* Start MDDRC */
 	im->mddrc.ddr_time_config0 = CFG_MDDRC_TIME_CFG0_RUN;
diff --git a/include/configs/ads5121.h b/include/configs/ads5121.h
index c147424..83781c6 100644
--- a/include/configs/ads5121.h
+++ b/include/configs/ads5121.h
@@ -117,14 +117,22 @@
 #define CFG_MDDRC_TIME_CFG1	0x54EC1168
 #define CFG_MDDRC_TIME_CFG2	0x35210864
 
-#define CFG_MICRON_NOP		0x01380000
-#define CFG_MICRON_PCHG_ALL	0x01100400
-#define CFG_MICRON_EM2		0x01020000
-#define CFG_MICRON_EM3		0x01030000
-#define CFG_MICRON_EN_DLL	0x01010000
-#define CFG_MICRON_RFSH		0x01080000
-#define CFG_MICRON_INIT_DEV_OP	0x01000432
-#define CFG_MICRON_OCD_DEFAULT	0x01010780
+/* DRAM commands */
+#define CFG_MICRON_NOP			0x01380000
+#define CFG_MICRON_PCHG_ALL		0x01100400
+#define CFG_MICRON_RFSH			0x01080000
+
+/* DDR2 specific commands */
+#define CFG_MICRON_DDR2_LM_MR_DLL_RESET	0x01000100	/* reset DLL        */
+#define CFG_MICRON_DDR2_LM_MR		0x01000432	/* burst lenght 4   */
+							/* CAS 3            */
+							/* Write recovery 3 */
+#define CFG_MICRON_DDR2_LM_EM_OCD	0x01010780	/* OCD default      */
+							/* DQS# enable      */
+#define CFG_MICRON_DDR2_LM_EM_EXIT	0x01010400	/* DQS# enable      */
+#define CFG_MICRON_DDR2_LM_EM		0x01010000
+#define CFG_MICRON_DDR2_LM_EM2		0x01020000
+#define CFG_MICRON_DDR2_LM_EM3		0x01030000
 
 /* DDR Priority Manager Configuration */
 #define CFG_MDDRCGRP_PM_CFG1	0x000777AA





From wd at denx.de  Wed Apr  2 20:57:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 02 Apr 2008 20:57:50 +0200
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: Your message of "Wed, 02 Apr 2008 17:59:48 +0200."
	<47F3AD74.4000900@semihalf.com>
Message-ID: <20080402185750.62979243AB@gemini.denx.de>

In message <47F3AD74.4000900 at semihalf.com> you wrote:
>
> I think that generally it is a better idea to use U-Boot's includes when
> building for the host system, as this gives us better control over what
> exactly gets included. But then on the other hand, tools/Makefils has this:

But U-boot doesn't have the knowledge about the target system that the
target distribution has.

> CPPFLAGS   = -idirafter $(SRCTREE)/include \
> 		-idirafter $(OBJTREE)/include2 \
> 		-idirafter $(OBJTREE)/include \
> 
> Could anyone comment on the reasons why we try U-Boot's includes after
> system includes? Perhaps it would be a good idea to reverse the order --
> see below for a quick RFC patch (compile-tested on two arm and two ppc
> boards, each arch with and without CONFIG_FIT enabled).

Don't! I guess you tried just one configuration, and probably not even
building on a 32 versus a 64 bit host system.

When building tools with the host compiler that are supposed  to  run
on  the host system we should always use the host's header files. And
we should really make sure that U-Boot header files get used only iff
there is no corresponding host header  file,  and  in  this  case  we
should make sure that this is intentional.

The current problem comes from the fact  that  old  versions  of  the
cyrus-sasl-devel  package  install  a  /usr/include/md5.h  file which
probably NOT intended for direct use, but only within the context  of
the  SASL  package; recent versions of the same package install it in
/usr/include/sasl/md5.h instead.

To solve this problem I see three solutions:

1) Fix the broken host systems for example by installing more recent
   versions of the cyrus-sasl-devel package; this would be best, but
   is unfortunately not possible everywhere.
2) Use relative file names (as suggested by Kumar) or similar methods
   to make sure we pick up the md5.h header file from a local
   directory instead from /usr/include.
3) Rename md5.h to make sure we use a pick up our own file instead of
   some unrelated file which happens to have the same name.

My vote goes for 3).

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: wd at denx.de
It is a good thing for an uneducated man to read books of quotations.
                        - Sir Winston Churchill _My Early Life_ ch. 9



From dcogley at uslinc.com  Wed Apr  2 21:11:08 2008
From: dcogley at uslinc.com (Dave Cogley)
Date: Wed, 2 Apr 2008 12:11:08 -0700
Subject: [U-Boot-Users] FW: u-boot ppc440epx bootstrap configuration without
	eval board
Message-ID: <000601c894f5$4ef53410$2001a8c0@DCOGLEYNEW>

Forwarded to u-boot mailing list...


-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Wednesday, April 02, 2008 12:01 PM
To: linuxppc-embedded at ozlabs.org
Cc: Dave Cogley
Subject: Re: u-boot ppc440epx bootstrap configuration without eval board

On Wednesday 02 April 2008, Dave Cogley wrote:
> Disregard the boot strapping problem.  It appears we are hardwired
strapped
> to use option "C" however my CPU is not being recognized as a 667MHz. 
> Which option should I be using for the 667MHz processor?

First, this is the wrong mailing list for this discussion. Please post to
the 
U-Boot list instead.

But here some general comments:

The bootstrap controller has multiple configuration options. Some of them 
result in hardwired frequencies (CPU, PLB, OPB...), and some of them load
the 
PLL setup from an I2C EEPROM. Using this bootstrap EEPROM is the most 
flexible solution. If you have only option "C", then you hardwired to
533MHz. 
There is no way to "detect" which frequency this CPU is labeled.

But it *is* possible to reconfigure the PLL from within U-Boot an reset the 
PPC to run with this different PLL setup. I just recently added some code
the 
u-boot-ppc4xx custodian repository.

Let's continue this thread on the U-Boot list.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================




From avinashs36 at yahoo.com  Wed Apr  2 22:54:47 2008
From: avinashs36 at yahoo.com (Avinash Vijayvergia)
Date: Wed, 2 Apr 2008 13:54:47 -0700 (PDT)
Subject: [U-Boot-Users] help -  u-boot header & compression
Message-ID: <689286.30879.qm@web39508.mail.mud.yahoo.com>

Hi All

I am working on AT91SAM9260 ARM9 core. I have very smallflash memory and hence need to compress the u-boot. I have picked nrv2balgo for that. Can someone suggest me how to put the compression infoin the u-boot header. I want to know the details of u-boot header too.

Thanks
Avinash



      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080402/27c3c353/attachment.htm 

From luigi.mantellini at idf-hit.com  Wed Apr  2 23:19:36 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Wed, 02 Apr 2008 23:19:36 +0200
Subject: [U-Boot-Users] help -  u-boot header & compression
In-Reply-To: <689286.30879.qm@web39508.mail.mud.yahoo.com>
References: <689286.30879.qm@web39508.mail.mud.yahoo.com>
Message-ID: <1207171176.3671.31.camel@cassini.comioland>

Hi Avinash,

I'm not undestanding if you want compress the U-Boot code or if you want
compress the uImage image.
Anyway, I don't know the nrv2b algorithm, can you give me any links?

thanks,

luigi

Il giorno mer, 02/04/2008 alle 13.54 -0700, Avinash Vijayvergia ha
scritto:
> Hi All
> 
> I am working on AT91SAM9260 ARM9 core. I have very small flash memory
> and hence need to compress the u-boot. I have picked nrv2b algo for
> that. Can someone suggest me how to put the compression info in the
> u-boot header. I want to know the details of u-boot header too.
> 
> Thanks
> Avinash
> 
> 
> 
> ______________________________________________________________________
> You rock. That's why Blockbuster's offering you one month of
> Blockbuster Total Access, No Cost.
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ U-Boot-Users mailing list U-Boot-Users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users


Ing. Luigi Mantellini
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI)
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080402/453fdb78/attachment.htm 

From afleming at freescale.com  Wed Apr  2 23:19:07 2008
From: afleming at freescale.com (Andy Fleming)
Date: Wed,  2 Apr 2008 16:19:07 -0500
Subject: [U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h
In-Reply-To: <20080402185750.62979243AB@gemini.denx.de>
References: <20080402185750.62979243AB@gemini.denx.de>
Message-ID: <1207171147-3228-1-git-send-email-afleming@freescale.com>

Some systems have md5.h installed in /usr/include/.  This isn't the desired
file (we want the one in include/md5.h).  This will avoid the conflict.
This fixes the host tools building problem

Signed-off-by: Andy Fleming <afleming at freescale.com>
---

This fixes the problem for me, at least...

 common/image.c       |    4 ++--
 include/u-boot-md5.h |   23 +++++++++++++++++++++++
 lib_generic/md5.c    |    2 +-
 3 files changed, 26 insertions(+), 3 deletions(-)
 create mode 100644 include/u-boot-md5.h

diff --git a/common/image.c b/common/image.c
index f04826a..2ee49ef 100644
--- a/common/image.c
+++ b/common/image.c
@@ -53,7 +53,7 @@
 #endif
 
 #if defined(CONFIG_FIT)
-#include <md5.h>
+#include <u-boot-md5.h>
 #include <sha1.h>
 
 static int fit_check_ramdisk (const void *fit, int os_noffset,
@@ -70,7 +70,7 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 						int verify);
 #else
 #include "mkimage.h"
-#include <md5.h>
+#include <u-boot-md5.h>
 #include <time.h>
 #include <image.h>
 #endif /* !USE_HOSTCC*/
diff --git a/include/u-boot-md5.h b/include/u-boot-md5.h
new file mode 100644
index 0000000..046d1ee
--- /dev/null
+++ b/include/u-boot-md5.h
@@ -0,0 +1,23 @@
+/*
+ * This file was transplanted with slight modifications from Linux sources
+ * (fs/cifs/md5.h) into U-Boot by Bartlomiej Sieka <tur at semihalf.com>.
+ */
+
+#ifndef _MD5_H
+#define _MD5_H
+
+#include <linux/types.h>
+
+struct MD5Context {
+	__u32 buf[4];
+	__u32 bits[2];
+	unsigned char in[64];
+};
+
+/*
+ * Calculate and store in 'output' the MD5 digest of 'len' bytes at
+ * 'input'. 'output' must have enough space to hold 16 bytes.
+ */
+void md5 (unsigned char *input, int len, unsigned char output[16]);
+
+#endif /* _MD5_H */
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index a51da45..3427172 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -27,7 +27,7 @@
 
 #include <linux/types.h>
 #include <linux/string.h>
-#include <md5.h>
+#include <u-boot-md5.h>
 
 static void
 MD5Transform(__u32 buf[4], __u32 const in[16]);
-- 
1.5.4.23.gef5b9




From luigi.mantellini at idf-hit.com  Wed Apr  2 23:37:20 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Wed, 02 Apr 2008 23:37:20 +0200
Subject: [U-Boot-Users] help -  u-boot header & compression
In-Reply-To: <388357.2045.qm@web39507.mail.mud.yahoo.com>
References: <388357.2045.qm@web39507.mail.mud.yahoo.com>
Message-ID: <1207172240.3671.43.camel@cassini.comioland>

Hi Avinash,

see inline.

Il giorno mer, 02/04/2008 alle 14.26 -0700, Avinash Vijayvergia ha
scritto:
> Hi LuigI
> 



> Thank you for your mail. I actually have two questions:
>      1. What is the format of u-boot header? Can you refer me to some
>         documentation?


What do you intend for "u-boot header"? U-boot uses the uImage format
for the kernels images. You can check the file include/image.h (row 175)
to understand the (old) uImage format. See this link: 
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/image.h;h=36143e25acfe3684a751a4ee6a5cf945524ef424;hb=74d1e66d22dac91388bc538b2fe19f735edc5b82




>      1. I want to compress u-boot. I have picked up nrv2b.c from
>         Koders.com which is in use by many people :). I couldn't
>         understand how it does encoding and decoding. I wanted to use
>         this algo and do compression and decompression of my binaries.
>         You can search google for nrv2b.c and you will get it from
>         Koder.com.


U-boot is the object code, the bootloader... how can you compress it? it
is a non-sense for me. Anyway, if you need to compress the kernel image,
you need to use the uImage format and the utility mkimage (see tools
directory). I recently posted a patch to support the lzma compression
algorithm (that works better than bzip2 and gzip): you can search in the
mailing list archive to retrieve this patch.

Are you sure that nrv2b is better than powerful lzma or bzip2? Do you
have benchmarks on this point? If you demonstrate me that nrv2b is a
good choice I can consider to make the patch for the community... I have
an application that has a very small flash memory... nrv2b should be a
choice...

Best regards,

luigi


> Thanks for your help
> Avinash
> 
> 
> ----- Original Message ----
> From: Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
> To: Avinash Vijayvergia <avinashs36 at yahoo.com>
> Cc: u-boot-users at lists.sourceforge.net
> Sent: Wednesday, April 2, 2008 2:19:36 PM
> Subject: Re: [U-Boot-Users] help - u-boot header & compression
> 
> Hi Avinash,
> 
> I'm not undestanding if you want compress the U-Boot code or if you
> want compress the uImage image.
> Anyway, I don't know the nrv2b algorithm, can you give me any links?
> 
> thanks,
> 
> luigi
> 
> Il giorno mer, 02/04/2008 alle 13.54 -0700, Avinash Vijayvergia ha
> scritto: 
> 
> > Hi All
> > 
> > I am working on AT91SAM9260 ARM9 core. I have very small flash
> > memory and hence need to compress the u-boot. I have picked nrv2b
> > algo for that. Can someone suggest me how to put the compression
> > info in the u-boot header. I want to know the details of u-boot
> > header too.
> > 
> > Thanks
> > Avinash
> > 
> > 
> > ____________________________________________________________________
> > 
> > You rock. That's why Blockbuster's offering you one month of
> > Blockbuster Total Access, No Cost. 
> > 
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________ U-Boot-Users mailing list U-Boot-Users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> 
> Ing. Luigi Mantellini
> Industrie Dial Face S.p.A.
> Via Canzo, 4 
> 20068 Peschiera Borromeo (MI)
> Tel.: +39 02 5167 2813
> Fax: +39 02 5167 2459
> E-mail:
> luigi.mantellini at idf-hit.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ______________________________________________________________________
> You rock. That's why Blockbuster's offering you one month of
> Blockbuster Total Access, No Cost.


Ing. Luigi Mantellini
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI)
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080402/43e1520a/attachment.htm 

From galak at kernel.crashing.org  Wed Apr  2 23:50:32 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 2 Apr 2008 16:50:32 -0500
Subject: [U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h
In-Reply-To: <1207171147-3228-1-git-send-email-afleming@freescale.com>
References: <20080402185750.62979243AB@gemini.denx.de>
	<1207171147-3228-1-git-send-email-afleming@freescale.com>
Message-ID: <285375FF-BD55-4206-9845-5AA4485FDF8E@kernel.crashing.org>


On Apr 2, 2008, at 4:19 PM, Andy Fleming wrote:
> Some systems have md5.h installed in /usr/include/.  This isn't the  
> desired
> file (we want the one in include/md5.h).  This will avoid the  
> conflict.
> This fixes the host tools building problem
>
> Signed-off-by: Andy Fleming <afleming at freescale.com>
> ---
>
> This fixes the problem for me, at least...

Which is on a RHEL3 box?

(cat /etc/redhat-release)

- k



From avinashs36 at yahoo.com  Wed Apr  2 23:57:05 2008
From: avinashs36 at yahoo.com (Avinash Vijayvergia)
Date: Wed, 2 Apr 2008 14:57:05 -0700 (PDT)
Subject: [U-Boot-Users] help -  u-boot header & compression
Message-ID: <393980.79147.qm@web39503.mail.mud.yahoo.com>

Hi Luigi

Thank you for your mail and comments. I should have explain why I want to compress u-boot. My target processor is Atmel AT91SAM9260. I am having a 64Mb Dataflash which is interfaced on SPI bus. The Atmel ARM9 copies the first 4kB to internal SRAM and then boots from there. So we need a loader of size <4kb which will be copied to SRAM. I have got this loader. This loader will invoke u-boot, and u-boot will invoke kernel. So I can compress loader and it will still work.

I'll compare nrv2b and lzma and then will be in a better position to comment. I chose nrv2b because I need a compression algo which can be as small as 600B (I have size restriction of 4kB).

Thanks
Avinash

----- Original Message ----
From: Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
To: Avinash Vijayvergia <avinashs36 at yahoo.com>
Cc: u-boot-users at lists.sourceforge.net
Sent: Wednesday, April 2, 2008 2:37:20 PM
Subject: Re: [U-Boot-Users] help -  u-boot header & compression

    Hi Avinash,

see inline.

Il giorno mer, 02/04/2008 alle 14.26 -0700, Avinash Vijayvergia ha scritto:    Hi LuigI
    

    Thank you for your mail. I actually have two questions:            What is the format of u-boot header? Can you refer me to some documentation?    
What do you intend for "u-boot header"? U-boot uses the uImage format for the kernels images. You can check the file include/image.h (row 175) to understand the (old) uImage format. See this link: 
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/image.h;h=36143e25acfe3684a751a4ee6a5cf945524ef424;hb=74d1e66d22dac91388bc538b2fe19f735edc5b82



            I want to compress u-boot. I have picked up nrv2b.c from Koders.com which is in use by many people :). I couldn't understand how it does encoding and decoding. I wanted to use this algo and do compression and decompression of my binaries. You can search google for nrv2b.c and you will get it from Koder.com.    
U-boot is the object code, the bootloader... how can you compress it? it is a non-sense for me. Anyway, if you need to compress the kernel image, you need to use the uImage format and the utility mkimage (see tools directory). I recently posted a patch to support the lzma compression algorithm (that works better than bzip2 and gzip): you can search in the mailing list archive to retrieve this patch.

Are you sure that nrv2b is better than powerful lzma or bzip2? Do you have benchmarks on this point? If you demonstrate me that nrv2b is a good choice I can consider to make the patch for the community... I have an application that has a very small flash memory... nrv2b should be a choice...

Best regards,

luigi

    Thanks for your help
    Avinash
    
    ----- Original Message ----
    From: Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
    To: Avinash Vijayvergia <avinashs36 at yahoo.com>
    Cc: u-boot-users at lists.sourceforge.net
    Sent: Wednesday, April 2, 2008 2:19:36 PM
    Subject: Re: [U-Boot-Users] help - u-boot header & compression
    
    Hi Avinash,
    
    I'm not undestanding if you want compress the U-Boot code or if you want compress the uImage image.
    Anyway, I don't know the nrv2b algorithm, can you give me any links?
    
    thanks,
    
    luigi
    
    Il giorno mer, 02/04/2008 alle 13.54 -0700, Avinash Vijayvergia ha scritto: 
            Hi All
        
        I am working on AT91SAM9260 ARM9 core. I have very small flash memory and hence need to compress the u-boot. I have picked nrv2b algo for that. Can someone suggest me how to put the compression info in the u-boot header. I want to know the details of u-boot header too.
        
        Thanks
        Avinash
        
        
        
        You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. -------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ U-Boot-Users mailing list U-Boot-Users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users        
Ing. Luigi Mantellini
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI)
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com


    
    
    
    
    You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.
Ing. Luigi Mantellini
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI)
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com







      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080402/2d7b61db/attachment.htm 

From postmaster at paran.com  Wed Apr  2 21:16:07 2008
From: postmaster at paran.com (postmaster at paran.com)
Date: Thu, 03 Apr 2008 04:16:07 +0900
Subject: [U-Boot-Users] [ERR] U-Boot-Users Digest, Vol 23, Issue 11
Message-ID: <1207162690951626.52.nrmail6TR@nrmail6>

Transmit Report:

 To: jaagar at paran.com, 2008/04/03 04:16:04, 451, Requested action aborted: No failover server
-------------- next part --------------
An embedded message was scrubbed...
From: u-boot-users-request at lists.sourceforge.net
Subject: U-Boot-Users Digest, Vol 23, Issue 11
Date: Wed, 02 Apr 2008 11:58:00 -0700
Size: 17959
Url: http://lists.denx.de/pipermail/u-boot/attachments/20080403/fdf6b4de/attachment.eml 

From afleming at gmail.com  Thu Apr  3 00:06:13 2008
From: afleming at gmail.com (Andy Fleming)
Date: Wed, 2 Apr 2008 17:06:13 -0500
Subject: [U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h
In-Reply-To: <285375FF-BD55-4206-9845-5AA4485FDF8E@kernel.crashing.org>
References: <20080402185750.62979243AB@gemini.denx.de>
	<1207171147-3228-1-git-send-email-afleming@freescale.com>
	<285375FF-BD55-4206-9845-5AA4485FDF8E@kernel.crashing.org>
Message-ID: <2acbd3e40804021506r3fe5143cifc1579451a0bb3bd@mail.gmail.com>

> cat /etc/redhat-release
Red Hat Enterprise Linux WS release 3 (Taroon Update 6)


On Wed, Apr 2, 2008 at 4:50 PM, Kumar Gala <galak at kernel.crashing.org> wrote:
>
>  On Apr 2, 2008, at 4:19 PM, Andy Fleming wrote:
>  > Some systems have md5.h installed in /usr/include/.  This isn't the
>  > desired
>  > file (we want the one in include/md5.h).  This will avoid the
>  > conflict.
>  > This fixes the host tools building problem
>  >
>  > Signed-off-by: Andy Fleming <afleming at freescale.com>
>  > ---
>  >
>  > This fixes the problem for me, at least...
>
>  Which is on a RHEL3 box?
>
>  (cat /etc/redhat-release)
>
>  - k
>
>
>
>  -------------------------------------------------------------------------
>  Check out the new SourceForge.net Marketplace.
>  It's the best place to buy or sell services for
>  just about anything Open Source.
>  http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>  _______________________________________________
>  U-Boot-Users mailing list
>  U-Boot-Users at lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/u-boot-users
>



From luigi.mantellini at idf-hit.com  Thu Apr  3 00:12:43 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Thu, 03 Apr 2008 00:12:43 +0200
Subject: [U-Boot-Users] help -  u-boot header & compression
In-Reply-To: <393980.79147.qm@web39503.mail.mud.yahoo.com>
References: <393980.79147.qm@web39503.mail.mud.yahoo.com>
Message-ID: <1207174363.3671.58.camel@cassini.comioland>


Il giorno mer, 02/04/2008 alle 14.57 -0700, Avinash Vijayvergia ha
scritto:
> Hi Luigi
> 
> Thank you for your mail and comments. I should have explain why I want
> to compress u-boot. My target processor is Atmel AT91SAM9260. I am
> having a 64Mb Dataflash which is interfaced on SPI bus. The Atmel ARM9
> copies the first 4kB to internal SRAM and then boots from there. So we
> need a loader of size <4kb which will be copied to SRAM. I have got
> this loader. This loader will invoke u-boot, and u-boot will invoke
> kernel. So I can compress loader and it will still work.
> 
> I'll compare nrv2b and lzma and then will be in a better position to
> comment. I chose nrv2b because I need a compression algo which can be
> as small as 600B (I have size restriction of 4kB).
> 


Ok. Now I understand the problem. U-boot is a pure binary file, you need
to compile it fixing the TEXT_BASE address in order to fit your RAM.
Your "pre-bootloader" should setup the ram and the dataflash in order to
decompress/copy u-boot (vetctors+text+data) from the dataflash space
addresses to the ram addresses. After the copy/decompress just jump to
u-boot address. To achieve this you needn't to know the u-boot header
structure.
You should analyze the board/atmel/at91rm9200dk/u-boot.lds and
cpu/arm920t/start.S files  to understand how u-boot works (at
initialization time).

Best regards,

luigi



> Thanks
> Avinash
> 
> 
> ----- Original Message ----
> From: Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
> To: Avinash Vijayvergia <avinashs36 at yahoo.com>
> Cc: u-boot-users at lists.sourceforge.net
> Sent: Wednesday, April 2, 2008 2:37:20 PM
> Subject: Re: [U-Boot-Users] help - u-boot header & compression
> 
> Hi Avinash,
> 
> see inline.
> 
> Il giorno mer, 02/04/2008 alle 14.26 -0700, Avinash Vijayvergia ha
> scritto: 
> 
> > Hi LuigI
> > 
> 
> 
> 
> > Thank you for your mail. I actually have two questions: 
> >      1. What is the format of u-boot header? Can you refer me to
> >         some documentation? 
> 
> 
> What do you intend for "u-boot header"? U-boot uses the uImage format
> for the kernels images. You can check the file include/image.h (row
> 175) to understand the (old) uImage format. See this link: 
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=include/image.h;h=36143e25acfe3684a751a4ee6a5cf945524ef424;hb=74d1e66d22dac91388bc538b2fe19f735edc5b82
> 
> 
> 
> 
> >      1. I want to compress u-boot. I have picked up nrv2b.c from
> >         Koders.com which is in use by many people :). I couldn't
> >         understand how it does encoding and decoding. I wanted to
> >         use this algo and do compression and decompression of my
> >         binaries. You can search google for nrv2b.c and you will get
> >         it from Koder.com. 
> 
> 
> U-boot is the object code, the bootloader... how can you compress it?
> it is a non-sense for me. Anyway, if you need to compress the kernel
> image, you need to use the uImage format and the utility mkimage (see
> tools directory). I recently posted a patch to support the lzma
> compression algorithm (that works better than bzip2 and gzip): you can
> search in the mailing list archive to retrieve this patch.
> 
> Are you sure that nrv2b is better than powerful lzma or bzip2? Do you
> have benchmarks on this point? If you demonstrate me that nrv2b is a
> good choice I can consider to make the patch for the community... I
> have an application that has a very small flash memory... nrv2b should
> be a choice...
> 
> Best regards,
> 
> luigi
> 
> 
> > Thanks for your help
> > Avinash
> > 
> > ----- Original Message ----
> > From: Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
> > To: Avinash Vijayvergia <avinashs36 at yahoo.com>
> > Cc: u-boot-users at lists.sourceforge.net
> > Sent: Wednesday, April 2, 2008 2:19:36 PM
> > Subject: Re: [U-Boot-Users] help - u-boot header & compression
> > 
> > Hi Avinash,
> > 
> > I'm not undestanding if you want compress the U-Boot code or if you
> > want compress the uImage image.
> > Anyway, I don't know the nrv2b algorithm, can you give me any links?
> > 
> > thanks,
> > 
> > luigi
> > 
> > Il giorno mer, 02/04/2008 alle 13.54 -0700, Avinash Vijayvergia ha
> > scritto: 
> > 
> > > Hi All
> > > 
> > > I am working on AT91SAM9260 ARM9 core. I have very small flash
> > > memory and hence need to compress the u-boot. I have picked nrv2b
> > > algo for that. Can someone suggest me how to put the compression
> > > info in the u-boot header. I want to know the details of u-boot
> > > header too.
> > > 
> > > Thanks
> > > Avinash
> > > 
> > > 
> > > __________________________________________________________________
> > > 
> > > 
> > > You rock. That's why Blockbuster's offering you one month of
> > > Blockbuster Total Access, No Cost. 
> > > 
> > > -------------------------------------------------------------------------
> > > Check out the new SourceForge.net Marketplace.
> > > It's the best place to buy or sell services for
> > > just about anything Open Source.
> > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > > _______________________________________________ U-Boot-Users mailing list U-Boot-Users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
> > 
> > 
> > 
> > Ing. Luigi Mantellini
> > Industrie Dial Face S.p.A.
> > Via Canzo, 4 
> > 20068 Peschiera Borromeo (MI)
> > Tel.: +39 02 5167 2813
> > Fax: +39 02 5167 2459
> > E-mail:
> > luigi.mantellini at idf-hit.com
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ____________________________________________________________________
> > 
> > You rock. That's why Blockbuster's offering you one month of
> > Blockbuster Total Access, No Cost.
> 
> 
> Ing. Luigi Mantellini
> Industrie Dial Face S.p.A.
> Via Canzo, 4 
> 20068 Peschiera Borromeo (MI)
> Tel.: +39 02 5167 2813
> Fax: +39 02 5167 2459
> E-mail:
> luigi.mantellini at idf-hit.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ______________________________________________________________________
> You rock. That's why Blockbuster's offering you one month of
> Blockbuster Total Access, No Cost.


Ing. Luigi Mantellini
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI)
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080403/a25b9368/attachment.htm 

From gururajakr at sanyo.co.in  Thu Apr  3 02:57:59 2008
From: gururajakr at sanyo.co.in (Gururaja Hebbar K R)
Date: Thu, 3 Apr 2008 06:27:59 +0530
Subject: [U-Boot-Users] [PATCH] remove error meesage in usb_ohci.c when
	debug is enabled
Message-ID: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDB05@blrms.slti.sanyo.co.in>

Hi,
 
In u-boot-1.3.1\drivers\usb\usb_ohci.c driver, if debug is enabled
(#define DEBUG), make comes out with an error as below.
 
<snip>
<snip>
<snip>
arm-none-linux-gnueabi-gcc -g  -Os   -fno-strict-aliasing  -fno-common
-ffixed-r8 -msoft-float  -D__KERNEL__ -DTEXT_BASE=0x200000
-I/home/guru/project/u_boot/Ubuild/include2
-I/home/guru/project/u_boot/Ubuild/include
-I/home/guru/project/u_boot/u-boot/include -fno-builtin -ffreestanding
-nostdinc -isystem
/home/guru/project/original/arm-2007q3/bin/../lib/gcc/arm-none-linux-gnu
eabi/4.2.1/include -pipe  -DCONFIG_ARM -D__ARM__ -march=armv4
-mabi=apcs-gnu -mno-thumb-interwork -Wall -Wstrict-prototypes -c -o
/home/guru/project/u_boot/Ubuild/drivers/usb/usb_ohci.o usb_ohci.c
usb_ohci.c: In function 'ohci_dump':
usb_ohci.c:513: error: invalid storage class for function
'sohci_return_job'
usb_ohci.c:552: error: invalid storage class for function
'sohci_get_current_frame_number'
usb_ohci.c:569: error: invalid storage class for function
'ep_int_ballance'
usb_ohci.c:591: error: invalid storage class for function
'ep_2_n_interval'
usb_ohci.c:604: error: invalid storage class for function 'ep_rev'
usb_ohci.c:619: error: invalid storage class for function 'ep_link'
usb_ohci.c:690: error: invalid storage class for function
'periodic_unlink'
usb_ohci.c:711: error: invalid storage class for function 'ep_unlink'
usb_ohci.c:774: error: invalid storage class for function 'ep_add_ed'
usb_ohci.c:823: error: invalid storage class for function 'td_fill'
usb_ohci.c:872: error: invalid storage class for function
'td_submit_job'
usb_ohci.c:944: error: invalid storage class for function
'dl_transfer_length'
usb_ohci.c:969: error: invalid storage class for function
'dl_reverse_done_list'
usb_ohci.c:1010: error: invalid storage class for function
'dl_done_list'
usb_ohci.c:1212: error: invalid storage class for function
'ohci_submit_rh_msg'
usb_ohci.c:1584: error: invalid storage class for function 'hc_reset'
usb_ohci.c:1632: error: invalid storage class for function 'hc_start'
usb_ohci.c:1697: error: invalid storage class for function
'hc_interrupt'
usb_ohci.c:1777: error: invalid storage class for function
'hc_release_ohci'
usb_ohci.c:1923: error: expected declaration or statement at end of
input
make[1]: *** [/home/guru/project/u_boot/Ubuild/drivers/usb/usb_ohci.o]
Error 1
make[1]: Leaving directory
`/home/guru/project/u_boot/u-boot/drivers/usb'
make: *** [/home/guru/project/u_boot/Ubuild/drivers/usb/libusb.a] Error
2


This is due to a missing } for function ohci_dump @ line 408.
 
Below patch corrects the same.
 
Comments are welcome.
 
Regards
Gururaja
 
Signed off by: Gururaja Hebbar <gururajakr at sanyo.co.in>


--- usb_ohci_orig.c	2007-12-06 01:21:19.000000000 -0800
+++ usb_ohci.c	2008-04-03 09:33:19.546875000 -0700
@@ -414,7 +414,7 @@ static void ohci_dump (ohci_t *controlle
 		ep_print_int_eds (controller, "hcca");
 	dbg ("hcca frame #%04x", controller->hcca->frame_no);
 	ohci_dump_roothub (controller, 1);
-
+}
 #endif /* DEBUG */
 
 
/*----------------------------------------------------------------------
---*



From pmeloy at shaw.ca  Thu Apr  3 03:37:06 2008
From: pmeloy at shaw.ca (PatM)
Date: Wed, 02 Apr 2008 18:37:06 -0700
Subject: [U-Boot-Users] Pointer to similar board?
Message-ID: <1207186626.10399.8.camel@rhodan.shaw.ca>

I've been trying to get Das u-boot going on my S3C2410 based board and
had no luck so far. Just trying to get something over the serial port
for now. I have a Wiggler to JTAG the initial u-boot.bin

Part of the problem is the target is brand new and not supported by
anybody yet. I'm wondering if there's a similar board already supported
by u-boot?

Its the CUWin at http://cubloc.com/product/05_01.php

NOR Am29LV800 
NAND 2 x K9F1208
RAM 64MB SDRAM

No extra drivers, just the built in S3C2410 LCD, serial, ethernet et.
al. I'd like to put u-boot in NOR to save some NAND space and because I
can't make heads nor tails out of this steppingstones stuff.

Thanks for your patience and help!






From sr at denx.de  Thu Apr  3 07:18:54 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 3 Apr 2008 07:18:54 +0200
Subject: [U-Boot-Users] FW: u-boot ppc440epx bootstrap configuration
	without eval board
In-Reply-To: <000601c894f5$4ef53410$2001a8c0@DCOGLEYNEW>
References: <000601c894f5$4ef53410$2001a8c0@DCOGLEYNEW>
Message-ID: <200804030718.54969.sr@denx.de>

On Wednesday 02 April 2008, Dave Cogley wrote:
> > Disregard the boot strapping problem.  It appears we are hardwired
> > strapped
> > to use option "C" however my CPU is not being recognized as a 667MHz.
> > Which option should I be using for the 667MHz processor?
>
> First, this is the wrong mailing list for this discussion. Please post to
> the
> U-Boot list instead.
>
> But here some general comments:
>
> The bootstrap controller has multiple configuration options. Some of them
> result in hardwired frequencies (CPU, PLB, OPB...), and some of them load
> the
> PLL setup from an I2C EEPROM. Using this bootstrap EEPROM is the most
> flexible solution. If you have only option "C", then you hardwired to
> 533MHz.
> There is no way to "detect" which frequency this CPU is labeled.
>
> But it *is* possible to reconfigure the PLL from within U-Boot an reset the
> PPC to run with this different PLL setup. I just recently added some code
> the
> u-boot-ppc4xx custodian repository.

Do you really have no I2C bootstrap EEPROM? If not then take a look at 
cpu/ppc4xx/cpu_init.c and search for reconfigure_pll(). This should do the 
trick.

But again, you have no chance to detect which 440EPx version is running on 
your board. So if you have boards equipped with 533MHz and 677MHz, this 
U-Boot version will run on all boards with the same speed. If you need 
different settings you really need the bootstrap EEPROM and configure board 
dependant settings.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From Martin.Krause at tqs.de  Thu Apr  3 08:18:38 2008
From: Martin.Krause at tqs.de (Martin Krause)
Date: Thu, 3 Apr 2008 08:18:38 +0200
Subject: [U-Boot-Users] Pointer to similar board?
In-Reply-To: <1207186626.10399.8.camel@rhodan.shaw.ca>
Message-ID: <47F3F98010FF784EBEE6526EAAB078D10635DED1@tq-mailsrv.tq-net.de>

Hi,

u-boot-users-bounces at lists.sourceforge.net wrote on Thursday, April 03,
2008 3:37 AM: 
> I've been trying to get Das u-boot going on my S3C2410 based board and
> had no luck so far. Just trying to get something over the serial port
> for now. I have a Wiggler to JTAG the initial u-boot.bin
> 
> Part of the problem is the target is brand new and not supported by
> anybody yet. I'm wondering if there's a similar board already
> supported 
> by u-boot?

Take a look into the Makefile and search for "s3c24x0". The "smdk2410"
is the eval board from Samsung. Maybe this is a good starting point.

> 
> Its the CUWin at http://cubloc.com/product/05_01.php
> 
> NOR Am29LV800
> NAND 2 x K9F1208
> RAM 64MB SDRAM
> 
> No extra drivers, just the built in S3C2410 LCD, serial, ethernet et.

Ethernet is not built into the S3C2410!

Best Regards,
Martin



From Sascha.Laue at gmx.biz  Thu Apr  3 08:19:20 2008
From: Sascha.Laue at gmx.biz (Sascha Laue)
Date: Thu, 03 Apr 2008 08:19:20 +0200
Subject: [U-Boot-Users] [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5
Message-ID: <20080403061920.271430@gmx.net>

Hi, 

Subject: [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5

Change configuartion for lwmon5 board.

Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
---
 include/configs/lwmon5.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
index ced7ba6..ff4bc80 100644
--- a/include/configs/lwmon5.h
+++ b/include/configs/lwmon5.h
@@ -434,7 +434,9 @@
 #define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
 #define CONFIG_LOOPW            1       /* enable loopw command         */
 #define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands      */
+#if 0                               /* enable only for debug */
 #define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0 */
+#endif
 #define CONFIG_VERSION_VARIABLE 1	/* include version env variable */
 
 /*-----------------------------------------------------------------------
-- 
1.5.2.4



From toertel at gmail.com  Thu Apr  3 08:51:50 2008
From: toertel at gmail.com (Mark Jonas)
Date: Thu, 3 Apr 2008 08:51:50 +0200
Subject: [U-Boot-Users] [PATCH 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: <f8328f7c0804020518u19487b37x2d0ac6ed53ae0f4c@mail.gmail.com>
References: <Pine.LNX.4.64.0803261426520.5050@axis700.grange>
	<Pine.LNX.4.64.0803261452310.5050@axis700.grange>
	<9b3c8e40804020503h7ca1624ehb90830536b0423e9@mail.gmail.com>
	<f8328f7c0804020518u19487b37x2d0ac6ed53ae0f4c@mail.gmail.com>
Message-ID: <9b3c8e40804022351h5c5b40e7pccc327e3032f5a3c@mail.gmail.com>

Hi,

>  This driver seems to be a superset of yours, so this would be the one
>  to go in once it's compliant.  Sorry for the lack of communication on
>  my part.

I am just sorry for the wasted hours it took to clean it up.

So long,
Mark



From r63238 at freescale.com  Thu Apr  3 10:28:29 2008
From: r63238 at freescale.com (Dave Liu)
Date: Thu, 03 Apr 2008 16:28:29 +0800
Subject: [U-Boot-Users] [PATCH] mpc83xx: Fix the SATA clock setting of 837x
	targets
Message-ID: <1207211309.3656.5.camel@localhost.localdomain>

Currently the SATA controller clock is configured as CSB clock,
usually the CSB clock is 400/333/266MHz.

However, The SATA IP block is only guaranteed to operate up to
200 MHz as stated in the HW spec.

The bug is reported by Joe D'Abbraccio <ljd015 at freescale.com>

This patch makes the SATA clock as half of CSB clock.

Signed-off-by: Dave Liu <daveliu at freescale.com>
---
 include/configs/MPC837XEMDS.h |    2 +-
 include/configs/MPC837XERDB.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h
index 7c4e76e..7fc0f7e 100644
--- a/include/configs/MPC837XEMDS.h
+++ b/include/configs/MPC837XEMDS.h
@@ -96,7 +96,7 @@
  */
 #define CFG_SCCR_TSEC1CM	1	/* CSB:eTSEC1 = 1:1 */
 #define CFG_SCCR_TSEC2CM	1	/* CSB:eTSEC2 = 1:1 */
-#define CFG_SCCR_SATACM		SCCR_SATACM_1	/* CSB:SATA[0:3] = 1:1 */
+#define CFG_SCCR_SATACM		SCCR_SATACM_2	/* CSB:SATA[0:3] = 2:1 */
 
 /*
  * System IO Config
diff --git a/include/configs/MPC837XERDB.h b/include/configs/MPC837XERDB.h
index eaac525..c698ff8 100644
--- a/include/configs/MPC837XERDB.h
+++ b/include/configs/MPC837XERDB.h
@@ -108,7 +108,7 @@
 /* System Clock Configuration Register */
 #define CFG_SCCR_TSEC1CM	1		/* eTSEC1 clock mode (0-3) */
 #define CFG_SCCR_TSEC2CM	1		/* eTSEC2 clock mode (0-3) */
-#define CFG_SCCR_SATACM		SCCR_SATACM_1	/* SATA1-4 clock mode (0-3) */
+#define CFG_SCCR_SATACM		SCCR_SATACM_2	/* SATA1-4 clock mode (0-3) */
 
 /*
  * System IO Config
-- 
1.5.4.rc4






From luigi.mantellini at idf-hit.com  Thu Apr  3 10:37:09 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Thu, 03 Apr 2008 10:37:09 +0200
Subject: [U-Boot-Users] help -  u-boot header & compression
In-Reply-To: <388357.2045.qm@web39507.mail.mud.yahoo.com>
References: <388357.2045.qm@web39507.mail.mud.yahoo.com>
Message-ID: <1207211829.27240.5.camel@localhost>

Hi Avinash,

You should check the nand_spl and openand_ipl directories to see
examples how to start u-boot from a not bootable memory (like nand).

Best regards,

luigi


On mer, 2008-04-02 at 14:26 -0700, Avinash Vijayvergia wrote:
> Hi Luig
> 
> Thank you for your mail. I actually have two questions:
>      1. What is the format of u-boot header? Can you refer me to some
>         documentation?
>      2. I want to compress u-boot. I have picked up nrv2b.c from
>         Koders.com which is in use by many people :). I couldn't
>         understand how it does encoding and decoding. I wanted to use
>         this algo and do compression and decompression of my binaries.
>         You can search google for nrv2b.c and you will get it from
>         Koder.com.
> Thanks for your help
> Avinash
> 
> ----- Original Message ----
> From: Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
> To: Avinash Vijayvergia <avinashs36 at yahoo.com>
> Cc: u-boot-users at lists.sourceforge.net
> Sent: Wednesday, April 2, 2008 2:19:36 PM
> Subject: Re: [U-Boot-Users] help - u-boot header & compression
> 
> Hi Avinash,
> 
> I'm not undestanding if you want compress the U-Boot code or if you
> want compress the uImage image.
> Anyway, I don't know the nrv2b algorithm, can you give me any links?
> 
> thanks,
> 
> luigi
> 
> Il giorno mer, 02/04/2008 alle 13.54 -0700, Avinash Vijayvergia ha
> scritto: 
> > Hi All
> > 
> > I am working on AT91SAM9260 ARM9 core. I have very small flash
> > memory and hence need to compress the u-boot. I have picked nrv2b
> > algo for that. Can someone suggest me how to put the compression
> > info in the u-boot header. I want to know the details of u-boot
> > header too.
> > 
> > Thanks
> > Avinash
> > 
> > 
> > ____________________________________________________________________
> > 
> > You rock. That's why Blockbuster's offering you one month of
> > Blockbuster Total Access, No Cost. 
> > -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________ U-Boot-Users mailing list U-Boot-Users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
> Ing. Luigi Mantellini
> Industrie Dial Face S.p.A.
> Via Canzo, 4 
> 20068 Peschiera Borromeo (MI)
> Tel.: +39 02 5167 2813
> Fax: +39 02 5167 2459
> E-mail:
> luigi.mantellini at idf-hit.com
> 
> 
> 
> 
> 
> 
> 
> ______________________________________________________________________
> You rock. That's why Blockbuster's offering you one month of
> Blockbuster Total Access, No Cost.
-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650







From maomao88316 at hotmail.com  Thu Apr  3 10:42:34 2008
From: maomao88316 at hotmail.com (=?gb2312?B?zfW3yc31t8n=?=)
Date: Thu, 3 Apr 2008 16:42:34 +0800
Subject: [U-Boot-Users] newcomer
Message-ID: <BAY114-W4825326E96E94B8E1FB5E9FBF70@phx.gbl>


hi experters:
 
   I'm a newcomer in U-boot, I want to understand the U-boot,but i don't know how to start!Anyone can help me ?
Thanks,
               Peter wang
 
_________________________________________________________________
MSN ????????????????????
http://cn.msn.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080403/fbd487bf/attachment.htm 

From tur at semihalf.com  Thu Apr  3 11:31:40 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Thu, 03 Apr 2008 11:31:40 +0200
Subject: [U-Boot-Users] New Image format: headers hashes.
In-Reply-To: <1206634003.13666.14.camel@localhost>
References: <1206616392.23794.33.camel@localhost>
	<1206634003.13666.14.camel@localhost>
Message-ID: <47F4A3FC.5000401@semihalf.com>

Hi Luigi,

You wrote:
> On gio, 2008-03-27 at 12:13 +0100, Luigi 'Comio' Mantellini wrote:
> 
>>
>> - The mkimage calculate hashes before that timestamp is added to
>> image.
>> is it better exchange the order of these operations (before add
>> timestamp then calculate hashes)?

Please see below.


>> - Does the new format assure that the complete image (_all_ sections,
>> images, ramdisks, configurations, blobs) are covered by at least an
>> hash
>> value?

Currently, the hash calculation is performed only over binary data of
component images (kernel, ramdisk, fdt, etc). In particular, timestamp
information is not protected by the hash, so the ordering of hash
calculation and timestamp addition doesn't matter.


 >> should mkimage add at least a hash value for the root node?

Adding a hash value for the root node only will not be easy. An easier
approach I think would be to add a hash value for the entire FIT image.


> In addition to the previous question:
> 
> - I'm interested to calculate and store from U-boot code but the 
> fit_image_set_hashes is compiled only when the USE_HOSTCC symbol is 
> defined. Why? Is there a particular reason?

There's no need for the function that you mention in current U-Boot
code, that's the reason why it's under USE_HOSTCC. If you're planning on
adding code to U-Boot that will use fit_image_set_hashes(), then just
remove the USE_HOSTCC #define's from around this function.


 > I think that a lot of
 > useful functions (ifdef-ed by USE_HOSTCC) should be available also in
 > u-boot code, anyway the linker will drop the unused functions.

I don't think the linker will do this in case of U-Boot:

With the following patch:

diff --git a/common/image.c b/common/image.c
index f04826a..850a9e4 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1950,7 +1950,6 @@ static int calculate_hash (const void *data, int 
data_len,
  	return 0;
  }

-#ifdef USE_HOSTCC
  /**
   * fit_set_hashes - process FIT component image nodes and calculate hashes
   * @fit: pointer to the FIT format image header
@@ -2119,7 +2118,6 @@ int fit_image_hash_set_value (void *fit, int 
noffset, uint

  	return 0;
  }
-#endif /* USE_HOSTCC */

  /**
   * fit_image_check_hashes - verify data intergity


I see:

$ ${CROSS_COMPILE}nm -S common/image.o | grep fit_image_set_hashes
0000155c 000001f4 T fit_image_set_hashes
$ ${CROSS_COMPILE}nm -S common/libcommon.a | grep fit_image_set_hashes
0000155c 000001f4 T fit_image_set_hashes
$ ${CROSS_COMPILE}nm -S u-boot | grep fit_image_set_hashes
fffb1924 000001f4 T fit_image_set_hashes


There's also size increase with the patch applied:
    text    data     bss     dec     hex filename
  284615   15556  357120  657291   a078b ./u-boot

    text    data     bss     dec     hex filename
  285875   15572  357120  658567   a0c87 u-boot


HTH,
Bartlomiej



From wd at denx.de  Thu Apr  3 11:38:20 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 03 Apr 2008 11:38:20 +0200
Subject: [U-Boot-Users] [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5
In-Reply-To: Your message of "Thu, 03 Apr 2008 08:19:20 +0200."
	<20080403061920.271430@gmx.net>
Message-ID: <20080403093820.99EFC2476E@gemini.denx.de>

In message <20080403061920.271430 at gmx.net> you wrote:
> Hi, 
> 
> Subject: [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5
> 
> Change configuartion for lwmon5 board.
> 
> Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> ---
>  include/configs/lwmon5.h |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
> index ced7ba6..ff4bc80 100644
> --- a/include/configs/lwmon5.h
> +++ b/include/configs/lwmon5.h
> @@ -434,7 +434,9 @@
>  #define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
>  #define CONFIG_LOOPW            1       /* enable loopw command         */
>  #define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands      */
> +#if 0                               /* enable only for debug */
>  #define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0 */
> +#endif
>  #define CONFIG_VERSION_VARIABLE 1	/* include version env variable */

Please don't add dead code. If you want to remove that line, then
please remove it. No "#if 0", please.

Viele Gr??e,

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: wd at denx.de
There are three ways to get something done:
        (1) Do it yourself.
        (2) Hire someone to do it for you.
        (3) Forbid your kids to do it.



From luigi.mantellini at idf-hit.com  Thu Apr  3 11:51:04 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Thu, 03 Apr 2008 11:51:04 +0200
Subject: [U-Boot-Users] New Image format: headers hashes.
In-Reply-To: <47F4A3FC.5000401@semihalf.com>
References: <1206616392.23794.33.camel@localhost>
	<1206634003.13666.14.camel@localhost> <47F4A3FC.5000401@semihalf.com>
Message-ID: <1207216264.27240.12.camel@localhost>

Hi Bartlomiej,

thank you for the answers. See my comments below.

On gio, 2008-04-03 at 11:31 +0200, Bartlomiej Sieka wrote:
> Hi Luigi,
> 
> You wrote:
> > On gio, 2008-03-27 at 12:13 +0100, Luigi 'Comio' Mantellini wrote:
> > 
> >>
> >> - The mkimage calculate hashes before that timestamp is added to
> >> image.
> >> is it better exchange the order of these operations (before add
> >> timestamp then calculate hashes)?
> 
> Please see below.
> 
> 
> >> - Does the new format assure that the complete image (_all_ sections,
> >> images, ramdisks, configurations, blobs) are covered by at least an
> >> hash
> >> value?
> 
> Currently, the hash calculation is performed only over binary data of
> component images (kernel, ramdisk, fdt, etc). In particular, timestamp
> information is not protected by the hash, so the ordering of hash
> calculation and timestamp addition doesn't matter.
> 

Ok. I agree

> 
>  >> should mkimage add at least a hash value for the root node?
> 
> Adding a hash value for the root node only will not be easy. An easier
> approach I think would be to add a hash value for the entire FIT image.
> 
Ok.

> 
> > In addition to the previous question:
> > 
> > - I'm interested to calculate and store from U-boot code but the 
> > fit_image_set_hashes is compiled only when the USE_HOSTCC symbol is 
> > defined. Why? Is there a particular reason?
> 
> There's no need for the function that you mention in current U-Boot
> code, that's the reason why it's under USE_HOSTCC. If you're planning on
> adding code to U-Boot that will use fit_image_set_hashes(), then just
> remove the USE_HOSTCC #define's from around this function.
> 
> 
>  > I think that a lot of
>  > useful functions (ifdef-ed by USE_HOSTCC) should be available also in
>  > u-boot code, anyway the linker will drop the unused functions.
> 
> I don't think the linker will do this in case of U-Boot:
> 
> With the following patch:
> 
> diff --git a/common/image.c b/common/image.c
> index f04826a..850a9e4 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -1950,7 +1950,6 @@ static int calculate_hash (const void *data, int 
> data_len,
>   	return 0;
>   }
> 
> -#ifdef USE_HOSTCC
>   /**
>    * fit_set_hashes - process FIT component image nodes and calculate hashes
>    * @fit: pointer to the FIT format image header
> @@ -2119,7 +2118,6 @@ int fit_image_hash_set_value (void *fit, int 
> noffset, uint
> 
>   	return 0;
>   }
> -#endif /* USE_HOSTCC */
> 
>   /**
>    * fit_image_check_hashes - verify data intergity
> 
> 
> I see:
> 
> $ ${CROSS_COMPILE}nm -S common/image.o | grep fit_image_set_hashes
> 0000155c 000001f4 T fit_image_set_hashes
> $ ${CROSS_COMPILE}nm -S common/libcommon.a | grep fit_image_set_hashes
> 0000155c 000001f4 T fit_image_set_hashes
> $ ${CROSS_COMPILE}nm -S u-boot | grep fit_image_set_hashes
> fffb1924 000001f4 T fit_image_set_hashes
> 
> 
> There's also size increase with the patch applied:
>     text    data     bss     dec     hex filename
>   284615   15556  357120  657291   a078b ./u-boot
> 
>     text    data     bss     dec     hex filename
>   285875   15572  357120  658567   a0c87 u-boot
> 
> 

Before to make this test, you should strip the elf-file in order to omit
the non-used code. Alternatively you should check the size of the
u-boot.bin file (that is striped by definition).

Best regards.

luigi

> HTH,
> Bartlomiej
-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650







From lg at denx.de  Thu Apr  3 13:35:50 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 13:35:50 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] net: make ARP timeout configurable
Message-ID: <Pine.LNX.4.64.0804031255510.18539@axis700.grange>

Currently the timeout waiting for an ARP reply is hard set to 5 seconds. 
On i.MX31ADS due to a hardware "strangeness" up to four first IP packets 
to the boards get lost, which typically are ARP replies. By configuring 
the timeout to a lower value we significantly improve the first network 
transfer time on this board. The timeout is specified in deciseconds, 
because it has to be converted to hardware ticks, and CFG_HZ ranges from 
900 to 27000000 on different boards.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

diff --git a/README b/README
index a9663a3..9249064 100644
--- a/README
+++ b/README
@@ -1547,6 +1547,10 @@ The following options need to be configured:
 		before giving up the operation. If not defined, a
 		default value of 5 is used.
 
+		CONFIG_ARP_TIMEOUT
+
+		Timeout waiting for an ARP reply in deciseconds.
+
 - Command Interpreter:
 		CONFIG_AUTO_COMPLETE
 
diff --git a/net/net.c b/net/net.c
index 44feee2..2128bd4 100644
--- a/net/net.c
+++ b/net/net.c
@@ -94,11 +94,16 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define ARP_TIMEOUT		5UL		/* Seconds before trying ARP again */
+#ifndef	CONFIG_ARP_TIMEOUT
+# define ARP_TIMEOUT		50UL	/* Deciseconds before trying ARP again */
+#else
+# define ARP_TIMEOUT		CONFIG_ARP_TIMEOUT
+#endif
+
 #ifndef	CONFIG_NET_RETRY_COUNT
-# define ARP_TIMEOUT_COUNT	5		/* # of timeouts before giving up  */
+# define ARP_TIMEOUT_COUNT	5	/* # of timeouts before giving up  */
 #else
-# define ARP_TIMEOUT_COUNT  (CONFIG_NET_RETRY_COUNT)
+# define ARP_TIMEOUT_COUNT	CONFIG_NET_RETRY_COUNT
 #endif
 
 #if 0
@@ -129,7 +134,7 @@ uchar		NetOurEther[6];		/* Our ethernet address			*/
 uchar		NetServerEther[6] =	/* Boot server enet address		*/
 			{ 0, 0, 0, 0, 0, 0 };
 IPaddr_t	NetOurIP;		/* Our IP addr (0 = unknown)		*/
-IPaddr_t	NetServerIP;		/* Our IP addr (0 = unknown)		*/
+IPaddr_t	NetServerIP;		/* Server IP addr (0 = unknown)		*/
 volatile uchar *NetRxPkt;		/* Current receive packet		*/
 int		NetRxPktLen;		/* Current rx packet length		*/
 unsigned	NetIPID;		/* IP packet ID				*/
@@ -253,7 +258,7 @@ void ArpTimeoutCheck(void)
 	t = get_timer(0);
 
 	/* check for arp timeout */
-	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ) {
+	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ / 10) {
 		NetArpWaitTry++;
 
 		if (NetArpWaitTry >= ARP_TIMEOUT_COUNT) {
@@ -494,7 +499,7 @@ restart:
 		 *	Check the ethernet for a new packet.  The ethernet
 		 *	receive routine will process it.
 		 */
-			eth_rx();
+		eth_rx();
 
 		/*
 		 *	Abort if ctrl-c was pressed.



From lg at denx.de  Thu Apr  3 13:36:02 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 13:36:02 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] cfi_flash: Support buffered writes on
 non-standard Spansion NOR flash
Message-ID: <Pine.LNX.4.64.0804031303450.18539@axis700.grange>

Some NOR flash chip from Spansion, for example, the s29ws-n MirrorBit 
series require different addresses for buffered write commands. Define a 
configuration option to support buffered writes on those chips. A more 
elegant solution would be to automatically detect those chips by parsing 
their CFI records, but that would require introduction of a fixup table 
into the cfi_flash driver.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

diff --git a/README b/README
index a9663a3..9249064 100644
--- a/README
+++ b/README
@@ -2014,6 +2018,13 @@ Configuration Settings:
 		This option also enables the building of the cfi_flash driver
 		in the drivers directory
 
+- CFG_FLASH_USE_BUFFER_WRITE
+		Use buffered writes to flash.
+
+- CONFIG_FLASH_SPANSION_S29WS_N
+		s29ws-n MirrorBit flash has non-standard addresses for buffered
+		write commands.
+
 - CFG_FLASH_QUIET_TEST
 		If this option is defined, the common CFI flash doesn't
 		print it's warning upon not recognized FLASH banks. This
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index f04c72d..d7f73cb 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -828,25 +828,29 @@ static int flash_write_cfibuffer (flash_info_t * info, ulong dest, uchar * cp,
 	void *dst = map_physmem(dest, len, MAP_NOCACHE);
 	void *dst2 = dst;
 	int flag = 0;
+	uint offset = 0;
+	unsigned int shift;
 
 	switch (info->portwidth) {
 	case FLASH_CFI_8BIT:
-		cnt = len;
+		shift = 0;
 		break;
 	case FLASH_CFI_16BIT:
-		cnt = len >> 1;
+		shift = 1;
 		break;
 	case FLASH_CFI_32BIT:
-		cnt = len >> 2;
+		shift = 2;
 		break;
 	case FLASH_CFI_64BIT:
-		cnt = len >> 3;
+		shift = 3;
 		break;
 	default:
 		retcode = ERR_INVAL;
 		goto out_unmap;
 	}
 
+	cnt = len >> shift;
+
 	while ((cnt-- > 0) && (flag == 0)) {
 		switch (info->portwidth) {
 		case FLASH_CFI_8BIT:
@@ -890,23 +894,7 @@ static int flash_write_cfibuffer (flash_info_t * info, ulong dest, uchar * cp,
 		if (retcode == ERR_OK) {
 			/* reduce the number of loops by the width of
 			 * the port */
-			switch (info->portwidth) {
-			case FLASH_CFI_8BIT:
-				cnt = len;
-				break;
-			case FLASH_CFI_16BIT:
-				cnt = len >> 1;
-				break;
-			case FLASH_CFI_32BIT:
-				cnt = len >> 2;
-				break;
-			case FLASH_CFI_64BIT:
-				cnt = len >> 3;
-				break;
-			default:
-				retcode = ERR_INVAL;
-				goto out_unmap;
-			}
+			cnt = len >> shift;
 			flash_write_cmd (info, sector, 0, (uchar) cnt - 1);
 			while (cnt-- > 0) {
 				switch (info->portwidth) {
@@ -943,36 +931,34 @@ static int flash_write_cfibuffer (flash_info_t * info, ulong dest, uchar * cp,
 	case CFI_CMDSET_AMD_STANDARD:
 	case CFI_CMDSET_AMD_EXTENDED:
 		flash_unlock_seq(info,0);
-		flash_write_cmd (info, sector, 0, AMD_CMD_WRITE_TO_BUFFER);
+
+#ifdef CONFIG_FLASH_SPANSION_S29WS_N
+		offset = ((unsigned long)dst - info->start[sector]) >> shift;
+#endif
+		flash_write_cmd(info, sector, offset, AMD_CMD_WRITE_TO_BUFFER);
+		cnt = len >> shift;
+		flash_write_cmd(info, sector, offset, (uchar)cnt - 1);
 
 		switch (info->portwidth) {
 		case FLASH_CFI_8BIT:
-			cnt = len;
-			flash_write_cmd (info, sector, 0,  (uchar) cnt - 1);
 			while (cnt-- > 0) {
 				flash_write8(flash_read8(src), dst);
 				src += 1, dst += 1;
 			}
 			break;
 		case FLASH_CFI_16BIT:
-			cnt = len >> 1;
-			flash_write_cmd (info, sector, 0,  (uchar) cnt - 1);
 			while (cnt-- > 0) {
 				flash_write16(flash_read16(src), dst);
 				src += 2, dst += 2;
 			}
 			break;
 		case FLASH_CFI_32BIT:
-			cnt = len >> 2;
-			flash_write_cmd (info, sector, 0,  (uchar) cnt - 1);
 			while (cnt-- > 0) {
 				flash_write32(flash_read32(src), dst);
 				src += 4, dst += 4;
 			}
 			break;
 		case FLASH_CFI_64BIT:
-			cnt = len >> 3;
-			flash_write_cmd (info, sector, 0,  (uchar) cnt - 1);
 			while (cnt-- > 0) {
 				flash_write64(flash_read64(src), dst);
 				src += 8, dst += 8;



From lg at denx.de  Thu Apr  3 13:36:10 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 13:36:10 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] MX31ADS network and flash updates
Message-ID: <Pine.LNX.4.64.0804031317410.18539@axis700.grange>

This patch depends on the previous two patches, introducing the 
CONFIG_FLASH_SPANSION_S29WS_N and CONFIG_ARP_TIMEOUT configuration 
options. It allows U-Boot to use buffered writes to the Spansion NOR flash 
installed on this board, and eliminates long delays in network transfers 
after the board startup.

Also modify flash layout to embed main and redundant environment blocks in 
the U-Boot image.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c
index 7c50c02..5a7d8c9 100644
--- a/board/mx31ads/mx31ads.c
+++ b/board/mx31ads/mx31ads.c
@@ -38,18 +38,18 @@ int dram_init (void)
 int board_init (void)
 {
 	int i;
-#if 0
+
 	/* CS0: Nor Flash */
 	/*
-	 * These are values from the RedBoot sources by Freescale. However,
-	 * under U-Boot with this configuration 32-bit accesses don't work,
-	 * lower 16 bits of data are read twice for each 32-bit read.
+	 * CS0L and CS0A values are from the RedBoot sources by Freescale
+	 * and are also equal to those used by Sascha Hauer for the Phytec
+	 * i.MX31 board. CS0U is just a slightly optimized hardware default:
+	 * the only non-zero field "Wait State Control" is set to half the
+	 * default value.
 	 */
-	__REG(CSCR_U(0)) = 0x23524E80;
-	__REG(CSCR_L(0)) = 0x10000D03; /* WRAP bit (1) is suspicious here, but
-					* disabling it doesn't help either */
+	__REG(CSCR_U(0)) = 0x00000f00;
+	__REG(CSCR_L(0)) = 0x10000D03;
 	__REG(CSCR_A(0)) = 0x00720900;
-#endif
 
 	/* setup pins for UART1 */
 	mx31_gpio_mux(MUX_RXD1__UART1_RXD_MUX);
diff --git a/board/mx31ads/u-boot.lds b/board/mx31ads/u-boot.lds
index 1460adc..49713d4 100644
--- a/board/mx31ads/u-boot.lds
+++ b/board/mx31ads/u-boot.lds
@@ -34,7 +34,18 @@ SECTIONS
 	. = ALIGN(4);
 	.text	   :
 	{
-	  cpu/arm1136/start.o	(.text)
+	  /* WARNING - the following is hand-optimized to fit within	*/
+	  /* the sector layout of our flash chips!	XXX FIXME XXX	*/
+
+	  cpu/arm1136/start.o		(.text)
+	  board/mx31ads/libmx31ads.a	(.text)
+	  lib_arm/libarm.a		(.text)
+	  net/libnet.a			(.text)
+	  drivers/mtd/libmtd.a		(.text)
+
+	  . = DEFINED(env_offset) ? env_offset : .;
+	  common/environment.o(.text)
+
 	  *(.text)
 	}
 
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index 77a9a83..9b72c89 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -72,7 +72,6 @@
 
 #include <config_cmd_default.h>
 
-#define CONFIG_CMD_MII
 #define CONFIG_CMD_PING
 
 #define CONFIG_BOOTDELAY	3
@@ -91,7 +90,19 @@
 
 #define CONFIG_DRIVER_CS8900	1
 #define CS8900_BASE		0xb4020300
-#define CS8900_BUS16		1	/* the Linux driver does accesses as shorts */
+#define CS8900_BUS16		1	/* follow the Linux driver */
+
+/*
+ * The MX31ADS board seems to have a hardware "peculiarity" confirmed under
+ * U-Boot, RedBoot and Linux: the ethernet Rx signal is reaching the CS8900A
+ * controller inverted. The controller is capable of detecting and correcting
+ * this, but it needs 4 network packets for that. Which means, at startup, you
+ * will not receive answers to the first 4 packest, unless there have been some
+ * broadcasts on the network, or your board is on a hub. Reducing the ARP
+ * timeout from default 5 seconds to 200ms we speed up the initial TFTP
+ * transfer, should the user wish one, significantly.
+ */
+#define CONFIG_ARP_TIMEOUT	2UL
 
 /*
  * Miscellaneous configurable options
@@ -100,7 +111,7 @@
 #define CFG_PROMPT		"=> "
 #define CFG_CBSIZE		256		/* Console I/O Buffer Size */
 /* Print Buffer Size */
-#define CFG_PBSIZE		(CFG_CBSIZE+sizeof(CFG_PROMPT)+16)
+#define CFG_PBSIZE		(CFG_CBSIZE + sizeof(CFG_PROMPT) + 16)
 #define CFG_MAXARGS		16		/* max number of command args */
 #define CFG_BARGSIZE		CFG_CBSIZE	/* Boot Argument Buffer Size */
 
@@ -136,25 +147,29 @@
 #define CFG_MAX_FLASH_BANKS	1		/* max number of memory banks */
 #define CFG_MAX_FLASH_SECT	262		/* max number of sectors on one chip */
 #define CFG_MONITOR_BASE	CFG_FLASH_BASE	/* Monitor at beginning of flash */
-#define CFG_MONITOR_LEN		(128 * 1024)	/* Reserve 128KiB */
+#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256KiB */
 
 #define	CFG_ENV_IS_IN_FLASH	1
 #define CFG_ENV_SECT_SIZE	(32 * 1024)
 #define CFG_ENV_SIZE		CFG_ENV_SECT_SIZE
+
+/* Address and size of Redundant Environment Sector	*/
+#define CFG_ENV_OFFSET_REDUND	(CFG_ENV_OFFSET + CFG_ENV_SIZE)
+#define CFG_ENV_SIZE_REDUND	CFG_ENV_SIZE
+
 /* S29WS256N NOR flash has 4 32KiB small sectors at the beginning and at the end.
  * The rest of 32MiB is in 128KiB big sectors. U-Boot occupies the low 4 sectors,
  * if we put environment next to it, we will have to occupy 128KiB for it.
  * Putting it at the top of flash we use only 32KiB. */
-#define CFG_ENV_ADDR		(CFG_MONITOR_BASE + 32 * 1024 * 1024 - CFG_ENV_SIZE)
+#define CFG_ENV_ADDR		(CFG_MONITOR_BASE + CFG_ENV_SECT_SIZE)
 
 /*-----------------------------------------------------------------------
  * CFI FLASH driver setup
  */
 #define CFG_FLASH_CFI			1 /* Flash memory is CFI compliant */
 #define CFG_FLASH_CFI_DRIVER		1 /* Use drivers/cfi_flash.c */
-#if 0 /* Doesn't work yet, work in progress */
+#define CONFIG_FLASH_SPANSION_S29WS_N	1 /* A non-standard buffered write algorithm */
 #define CFG_FLASH_USE_BUFFER_WRITE	1 /* Use buffered writes (~10x faster) */
-#endif
 #define CFG_FLASH_PROTECTION		1 /* Use hardware sector protection */
 
 /*



From lg at denx.de  Thu Apr  3 13:36:18 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 13:36:18 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] minor cs8900 driver clean up
Message-ID: <Pine.LNX.4.64.0804031323400.18539@axis700.grange>

Remove a redundant register definition, clean up some coding style 
violations.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

diff --git a/drivers/net/cs8900.c b/drivers/net/cs8900.c
index 55ef346..458b517 100644
--- a/drivers/net/cs8900.c
+++ b/drivers/net/cs8900.c
@@ -65,14 +65,14 @@ static unsigned short get_reg_init_bus (int regno)
 	c = CS8900_BUS16_0;
 
 	CS8900_PPTR = regno;
-	return (unsigned short) CS8900_PDATA;
+	return CS8900_PDATA;
 }
 #endif
 
 static unsigned short get_reg (int regno)
 {
 	CS8900_PPTR = regno;
-	return (unsigned short) CS8900_PDATA;
+	return CS8900_PDATA;
 }
 
 
@@ -131,7 +131,7 @@ void cs8900_get_enetaddr (uchar * addr)
 	if (get_reg_init_bus (PP_ChipID) != 0x630e)
 		return;
 	eth_reset ();
-	if ((get_reg (PP_SelfST) & (PP_SelfSTAT_EEPROM | PP_SelfSTAT_EEPROM_OK)) ==
+	if ((get_reg (PP_SelfSTAT) & (PP_SelfSTAT_EEPROM | PP_SelfSTAT_EEPROM_OK)) ==
 			(PP_SelfSTAT_EEPROM | PP_SelfSTAT_EEPROM_OK)) {
 
 		/* Load the MAC from EEPROM */
@@ -168,7 +168,6 @@ void cs8900_get_enetaddr (uchar * addr)
 			debug ("### Set environment from HW MAC addr = \"%s\"\n", ethaddr);
 			setenv ("ethaddr", ethaddr);
 		}
-
 	}
 }
 
@@ -183,7 +182,6 @@ void eth_halt (void)
 
 int eth_init (bd_t * bd)
 {
-
 	/* verify chip id */
 	if (get_reg_init_bus (PP_ChipID) != 0x630e) {
 		printf ("CS8900 Ethernet chip not found?!\n");
@@ -201,7 +199,7 @@ int eth_init (bd_t * bd)
 }
 
 /* Get a data block via Ethernet */
-extern int eth_rx (void)
+int eth_rx (void)
 {
 	int i;
 	unsigned short rxlen;
@@ -233,7 +231,7 @@ extern int eth_rx (void)
 }
 
 /* Send a data block via Ethernet. */
-extern int eth_send (volatile void *packet, int length)
+int eth_send (volatile void *packet, int length)
 {
 	volatile unsigned short *addr;
 	int tmo;
@@ -281,7 +279,8 @@ retry:
 
 static void cs8900_e2prom_ready(void)
 {
-	while(get_reg(PP_SelfST) & SI_BUSY);
+	while (get_reg(PP_SelfSTAT) & SI_BUSY)
+		;
 }
 
 /***********************************************************/
diff --git a/drivers/net/cs8900.h b/drivers/net/cs8900.h
index f886d10..f9c32dd 100644
--- a/drivers/net/cs8900.h
+++ b/drivers/net/cs8900.h
@@ -243,7 +243,6 @@
 
 /* EEPROM Kram */
 #define SI_BUSY 0x0100
-#define PP_SelfST 0x0136	/*  Self State register */
 #define PP_EECMD 0x0040		/*  NVR Interface Command register */
 #define PP_EEData 0x0042	/*  NVR Interface Data Register */
 #define EEPROM_WRITE_EN		0x00F0



From martin.krause at tqs.de  Thu Apr  3 13:37:56 2008
From: martin.krause at tqs.de (Martin Krause)
Date: Thu, 03 Apr 2008 13:37:56 +0200
Subject: [U-Boot-Users] [PATCH] IDE: fix bug in reset sequence
Message-ID: <20080403113721.28821.11173.stgit@tq-sewsrv-4.tq-net.de>

According to the ata (ata5) specification the RESET- signal
shall be asserted for at least 25 us. Without this patch,
the RESET- signal is asserted on some boards for only < 1 us
(e. g. on the TQM5200). This patch adds a general delay of
25 us to the RESET- signal.

Without this patch a Platinum 4 GiB CF card is not recognised
properly on boards with a TQM5200 (STK52xx, TB5200).

Signed-off-by: Martin Krause <martin.krause at tqs.de>
---

 common/cmd_ide.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 8ace970..f9cd422 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -1529,6 +1529,9 @@ static void ide_reset (void)
 
 	ide_set_reset (1); /* assert reset */
 
+	/* the reset signal shall be asserted for et least 25 us */
+	udelay(25);
+
 	WATCHDOG_RESET();
 
 #ifdef CFG_PB_12V_ENABLE




From tur at semihalf.com  Thu Apr  3 13:48:23 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Thu, 03 Apr 2008 13:48:23 +0200
Subject: [U-Boot-Users] New Image format: headers hashes.
In-Reply-To: <1207216264.27240.12.camel@localhost>
References: <1206616392.23794.33.camel@localhost>	
	<1206634003.13666.14.camel@localhost>
	<47F4A3FC.5000401@semihalf.com>
	<1207216264.27240.12.camel@localhost>
Message-ID: <47F4C407.5020300@semihalf.com>

Luigi 'Comio' Mantellini wrote:
> Hi Bartlomiej,
> 
> thank you for the answers. See my comments below.
> 
> On gio, 2008-04-03 at 11:31 +0200, Bartlomiej Sieka wrote:
>> Hi Luigi,
>>
>> You wrote:
>>> On gio, 2008-03-27 at 12:13 +0100, L
>>> - I'm interested to calculate and store from U-boot code but the 
>>> fit_image_set_hashes is compiled only when the USE_HOSTCC symbol is 
>>> defined. Why? Is there a particular reason?
>> There's no need for the function that you mention in current U-Boot
>> code, that's the reason why it's under USE_HOSTCC. If you're planning on
>> adding code to U-Boot that will use fit_image_set_hashes(), then just
>> remove the USE_HOSTCC #define's from around this function.
>>
>>
>>  > I think that a lot of
>>  > useful functions (ifdef-ed by USE_HOSTCC) should be available also in
>>  > u-boot code, anyway the linker will drop the unused functions.
>>
>> I don't think the linker will do this in case of U-Boot:
>>
>> With the following patch:
>>
>> diff --git a/common/image.c b/common/image.c
>> index f04826a..850a9e4 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -1950,7 +1950,6 @@ static int calculate_hash (const void *data, int 
>> data_len,
>>   	return 0;
>>   }
>>
>> -#ifdef USE_HOSTCC
>>   /**
>>    * fit_set_hashes - process FIT component image nodes and calculate hashes
>>    * @fit: pointer to the FIT format image header
>> @@ -2119,7 +2118,6 @@ int fit_image_hash_set_value (void *fit, int 
>> noffset, uint
>>
>>   	return 0;
>>   }
>> -#endif /* USE_HOSTCC */
>>
>>   /**
>>    * fit_image_check_hashes - verify data intergity
>>
>>
>> I see:
>>
>> $ ${CROSS_COMPILE}nm -S common/image.o | grep fit_image_set_hashes
>> 0000155c 000001f4 T fit_image_set_hashes
>> $ ${CROSS_COMPILE}nm -S common/libcommon.a | grep fit_image_set_hashes
>> 0000155c 000001f4 T fit_image_set_hashes
>> $ ${CROSS_COMPILE}nm -S u-boot | grep fit_image_set_hashes
>> fffb1924 000001f4 T fit_image_set_hashes
>>
>>
>> There's also size increase with the patch applied:
>>     text    data     bss     dec     hex filename
>>   284615   15556  357120  657291   a078b ./u-boot
>>
>>     text    data     bss     dec     hex filename
>>   285875   15572  357120  658567   a0c87 u-boot
>>
>>
> 
> Before to make this test, you should strip the elf-file in order to omit
> the non-used code. Alternatively you should check the size of the
> u-boot.bin file (that is striped by definition).

"objcopy -O binary" which is used to create u-boot.bin from u-boot
doesn't remove unused functions -- code for fit_image_set_hashes (and
other functions removed from under #ifdef USE_HOSTCC by the patch) is
present in u-boot.bin.

If you add enough of such dead code, you'll see the increase in size of 
u-boot.bin, or run into linking problems -- depending on the particular 
linker script used for the target.

Regards,
Bartlomiej



From karthikeyan.kadirvel at hcl.in  Thu Apr  3 13:55:41 2008
From: karthikeyan.kadirvel at hcl.in (Karthikeyan Kadirvel,  Chennai)
Date: Thu, 3 Apr 2008 17:25:41 +0530
Subject: [U-Boot-Users] reg to configure DSPI in mcf54455
Message-ID: <B24A3277E6B11B4D9D53D272FE49B7C501407625@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>


Hi,

 

I have the u-boot code of mcf54455evb.now I am designing a new board
with processor of mcf54452.

 

When I make the changes in the u-boot code for configuring SPI, i am
getting errors like this 

undefined reference to `spi_init_f' 
undefined reference to `spi_init_r' 

(in the file ~/board.c) 

undefined reference to `spi_read' 
undefined reference to `spi_write' 
undefined reference to `spi_init_f' 

(in the file ~/cmd_eeprom.c) 

 

I am following the README file. i have done the modification for SPI
configuration what they mentioned in the read me file.

Even though the two C files have inludes to an .h file (common.h) that
define these functions...Any ideas what is happening here? The thing is,
the only place I can see that these functions are given are in a file
called spi.c, which exists in *some* board config folders. Does this
mean that i need an spi.c file added into the /board/mcf54455evb/
folder? I have to write the definitions for those function?

 

Thanks & Regards,

Karthik

 

 



DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080403/b3f5fecc/attachment.htm 

From dzu at denx.de  Thu Apr  3 14:18:47 2008
From: dzu at denx.de (Detlev Zundel)
Date: Thu,  3 Apr 2008 14:18:47 +0200
Subject: [U-Boot-Users] [PATCH] Rename 'addcon' to 'addcons' environment
	command for Keymile boards.
Message-ID: <1207225128-13989-1-git-send-email-dzu@denx.de>

The latter name with 13 users is already established, so we will use
that.

Signed-off-by: Detlev Zundel <dzu at denx.de>
---
 include/configs/mgcoge.h |    4 ++--
 include/configs/mgsuvd.h |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h
index b1e3d53..f0fed06 100644
--- a/include/configs/mgcoge.h
+++ b/include/configs/mgcoge.h
@@ -105,13 +105,13 @@
 	"ramargs=setenv bootargs root=/dev/ram rw\0"			\
 	"nfsargs=setenv bootargs root=/dev/nfs rw "			\
 		"nfsroot=${serverip}:${rootpath}\0"			\
-	"addcon=setenv bootargs ${bootargs} console=ttyCPM0,${baudrate}\0"	\
+	"addcons=setenv bootargs ${bootargs} console=ttyCPM0,${baudrate}\0"	\
 	"addmtd=setenv bootargs ${bootargs} ${mtdparts}\0"		\
 	"addip=setenv bootargs ${bootargs} "				\
 		"ip=${ipaddr}:${serverip}:${gatewayip}:"		\
 		"${netmask}:${hostname}:${netdev}:off panic=1\0"	\
 	"net_nfs=tftp ${kernel_addr} ${bootfile}; "			\
-		"tftp ${fdt_addr} ${fdt_file}; run nfsargs addip addcon;"\
+		"tftp ${fdt_addr} ${fdt_file}; run nfsargs addip addcons;"\
 		"bootm ${kernel_addr} - ${fdt_addr}\0"			\
 	"net_self=tftp ${kernel_addr} ${bootfile}; "			\
 		"tftp ${fdt_addr} ${fdt_file}; "			\
diff --git a/include/configs/mgsuvd.h b/include/configs/mgsuvd.h
index 5482089..aa026d9 100644
--- a/include/configs/mgsuvd.h
+++ b/include/configs/mgsuvd.h
@@ -61,7 +61,7 @@
 
 #define CONFIG_EXTRA_ENV_SETTINGS					\
 	"netdev=eth0\0"							\
-	"addcon=setenv bootargs ${bootargs} console=ttyCPM0,${baudrate}\0"	\
+	"addcons=setenv bootargs ${bootargs} console=ttyCPM0,${baudrate}\0"	\
 	"nfsargs=setenv bootargs root=/dev/nfs rw "			\
 		"nfsroot=${serverip}:${rootpath}\0"			\
 	"ramargs=setenv bootargs root=/dev/ram rw\0"			\
@@ -73,7 +73,7 @@
 	"flash_self=run ramargs addip;"					\
 		"bootm ${kernel_addr} ${ramdisk_addr}\0"		\
 	"net_nfs=tftp ${kernel_addr} ${bootfile}; "			\
-		"tftp ${fdt_addr} ${fdt_file}; run nfsargs addip addcon;"\
+		"tftp ${fdt_addr} ${fdt_file}; run nfsargs addip addcons;"\
 		"bootm ${kernel_addr} - ${fdt_addr}\0"			\
 	"rootpath=/opt/eldk/ppc_8xx\0"					\
 	"bootfile=/tftpboot/mgsuvd/uImage\0"				\
-- 
1.5.4.2




From dzu at denx.de  Thu Apr  3 14:18:48 2008
From: dzu at denx.de (Detlev Zundel)
Date: Thu,  3 Apr 2008 14:18:48 +0200
Subject: [U-Boot-Users] [PATCH] [Cosmetic] Realign CONFIG_EXTRA_ENV_SETTING
	for Keymile boards.
In-Reply-To: <1207225128-13989-1-git-send-email-dzu@denx.de>
References: <1207225128-13989-1-git-send-email-dzu@denx.de>
Message-ID: <1207225128-13989-2-git-send-email-dzu@denx.de>

Signed-off-by: Detlev Zundel <dzu at denx.de>
---
 include/configs/mgcoge.h |   56 +++++++++++++++++++++++-----------------------
 include/configs/mgsuvd.h |   50 ++++++++++++++++++++--------------------
 2 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h
index f0fed06..2924acc 100644
--- a/include/configs/mgcoge.h
+++ b/include/configs/mgcoge.h
@@ -89,35 +89,35 @@
 /*
  * Default environment settings
  */
-#define CONFIG_EXTRA_ENV_SETTINGS					\
-	"netdev=eth0\0"							\
-	"u-boot_addr=100000\0"						\
-	"kernel_addr=200000\0"						\
-	"fdt_addr=400000\0"						\
-	"rootpath=/opt/eldk-4.2/ppc_82xx\0"				\
-	"u-boot=/tftpboot/mgcoge/u-boot.bin\0"				\
-	"bootfile=/tftpboot/mgcoge/uImage\0"				\
-	"fdt_file=/tftpboot/mgcoge/mgcoge.dtb\0"			\
-	"load=tftp ${u-boot_addr} ${u-boot}\0"				\
-	"update=prot off fe000000 fe03ffff; era fe000000 fe03ffff; "	\
-		"cp.b ${u-boot_addr} fe000000 ${filesize};"		\
-		"prot on fe000000 fe03ffff\0"				\
-	"ramargs=setenv bootargs root=/dev/ram rw\0"			\
-	"nfsargs=setenv bootargs root=/dev/nfs rw "			\
-		"nfsroot=${serverip}:${rootpath}\0"			\
+#define CONFIG_EXTRA_ENV_SETTINGS						\
+	"netdev=eth0\0"								\
+	"u-boot_addr=100000\0"							\
+	"kernel_addr=200000\0"							\
+	"fdt_addr=400000\0"							\
+	"rootpath=/opt/eldk-4.2/ppc_82xx\0"					\
+	"u-boot=/tftpboot/mgcoge/u-boot.bin\0"					\
+	"bootfile=/tftpboot/mgcoge/uImage\0"					\
+	"fdt_file=/tftpboot/mgcoge/mgcoge.dtb\0"				\
+	"load=tftp ${u-boot_addr} ${u-boot}\0"					\
+	"update=prot off fe000000 fe03ffff; era fe000000 fe03ffff; "		\
+		"cp.b ${u-boot_addr} fe000000 ${filesize};"			\
+		"prot on fe000000 fe03ffff\0"					\
+	"ramargs=setenv bootargs root=/dev/ram rw\0"				\
+	"nfsargs=setenv bootargs root=/dev/nfs rw "				\
+		"nfsroot=${serverip}:${rootpath}\0"				\
 	"addcons=setenv bootargs ${bootargs} console=ttyCPM0,${baudrate}\0"	\
-	"addmtd=setenv bootargs ${bootargs} ${mtdparts}\0"		\
-	"addip=setenv bootargs ${bootargs} "				\
-		"ip=${ipaddr}:${serverip}:${gatewayip}:"		\
-		"${netmask}:${hostname}:${netdev}:off panic=1\0"	\
-	"net_nfs=tftp ${kernel_addr} ${bootfile}; "			\
-		"tftp ${fdt_addr} ${fdt_file}; run nfsargs addip addcons;"\
-		"bootm ${kernel_addr} - ${fdt_addr}\0"			\
-	"net_self=tftp ${kernel_addr} ${bootfile}; "			\
-		"tftp ${fdt_addr} ${fdt_file}; "			\
-		"tftp ${ramdisk_addr} ${ramdisk_file}; "		\
-		"run ramargs addip; "					\
-		"bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0"	\
+	"addmtd=setenv bootargs ${bootargs} ${mtdparts}\0"			\
+	"addip=setenv bootargs ${bootargs} "					\
+		"ip=${ipaddr}:${serverip}:${gatewayip}:"			\
+		"${netmask}:${hostname}:${netdev}:off panic=1\0"		\
+	"net_nfs=tftp ${kernel_addr} ${bootfile}; "				\
+		"tftp ${fdt_addr} ${fdt_file}; run nfsargs addip addcons;"	\
+		"bootm ${kernel_addr} - ${fdt_addr}\0"				\
+	"net_self=tftp ${kernel_addr} ${bootfile}; "				\
+		"tftp ${fdt_addr} ${fdt_file}; "				\
+		"tftp ${ramdisk_addr} ${ramdisk_file}; "			\
+		"run ramargs addip; "						\
+		"bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0"		\
 	""
 #define CONFIG_BOOTCOMMAND	"run net_nfs"
 #define CONFIG_BOOTDELAY	5	/* autoboot after 5 seconds */
diff --git a/include/configs/mgsuvd.h b/include/configs/mgsuvd.h
index aa026d9..9cbc9cc 100644
--- a/include/configs/mgsuvd.h
+++ b/include/configs/mgsuvd.h
@@ -59,32 +59,32 @@
 
 #undef	CONFIG_BOOTARGS
 
-#define CONFIG_EXTRA_ENV_SETTINGS					\
-	"netdev=eth0\0"							\
+#define CONFIG_EXTRA_ENV_SETTINGS						\
+	"netdev=eth0\0"								\
 	"addcons=setenv bootargs ${bootargs} console=ttyCPM0,${baudrate}\0"	\
-	"nfsargs=setenv bootargs root=/dev/nfs rw "			\
-		"nfsroot=${serverip}:${rootpath}\0"			\
-	"ramargs=setenv bootargs root=/dev/ram rw\0"			\
-	"addip=setenv bootargs ${bootargs} "				\
-		"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}"	\
-		":${hostname}:${netdev}:off panic=1\0"			\
-	"flash_nfs=run nfsargs addip;"					\
-		"bootm ${kernel_addr}\0"				\
-	"flash_self=run ramargs addip;"					\
-		"bootm ${kernel_addr} ${ramdisk_addr}\0"		\
-	"net_nfs=tftp ${kernel_addr} ${bootfile}; "			\
-		"tftp ${fdt_addr} ${fdt_file}; run nfsargs addip addcons;"\
-		"bootm ${kernel_addr} - ${fdt_addr}\0"			\
-	"rootpath=/opt/eldk/ppc_8xx\0"					\
-	"bootfile=/tftpboot/mgsuvd/uImage\0"				\
-	"fdt_addr=400000\0"						\
-	"kernel_addr=200000\0"						\
-	"fdt_file=/tftpboot/mgsuvd/mgsuvd.dtb\0"			\
-	"load=tftp 200000 ${u-boot}\0"					\
-	"update=protect off f0000000 +${filesize};"			\
-		"erase f0000000 +${filesize};"				\
-		"cp.b 200000 f0000000 ${filesize};"			\
-		"protect on f0000000 +${filesize}\0"			\
+	"nfsargs=setenv bootargs root=/dev/nfs rw "				\
+		"nfsroot=${serverip}:${rootpath}\0"				\
+	"ramargs=setenv bootargs root=/dev/ram rw\0"				\
+	"addip=setenv bootargs ${bootargs} "					\
+		"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}"		\
+		":${hostname}:${netdev}:off panic=1\0"				\
+	"flash_nfs=run nfsargs addip;"						\
+		"bootm ${kernel_addr}\0"					\
+	"flash_self=run ramargs addip;"						\
+		"bootm ${kernel_addr} ${ramdisk_addr}\0"			\
+	"net_nfs=tftp ${kernel_addr} ${bootfile}; "				\
+		"tftp ${fdt_addr} ${fdt_file}; run nfsargs addip addcons;"	\
+		"bootm ${kernel_addr} - ${fdt_addr}\0"				\
+	"rootpath=/opt/eldk/ppc_8xx\0"						\
+	"bootfile=/tftpboot/mgsuvd/uImage\0"					\
+	"fdt_addr=400000\0"							\
+	"kernel_addr=200000\0"							\
+	"fdt_file=/tftpboot/mgsuvd/mgsuvd.dtb\0"				\
+	"load=tftp 200000 ${u-boot}\0"						\
+	"update=protect off f0000000 +${filesize};"				\
+		"erase f0000000 +${filesize};"					\
+		"cp.b 200000 f0000000 ${filesize};"				\
+		"protect on f0000000 +${filesize}\0"				\
 	""
 #define CONFIG_BOOTCOMMAND	"run flash_self"
 
-- 
1.5.4.2




From martin.krause at tqs.de  Thu Apr  3 14:29:01 2008
From: martin.krause at tqs.de (Martin Krause)
Date: Thu, 03 Apr 2008 14:29:01 +0200
Subject: [U-Boot-Users] [PATCH] TQM5200: fix default IDE reset level
Message-ID: <20080403122856.1207.24711.stgit@tq-sewsrv-4.tq-net.de>

Bevore the first call of ide_reset() the default level of
the IDE reset signal on the TQM5200 is low (reset asserted).
This patch sets the default value to high (reset not asserted).

Currently this patch fixes no real problem, but it is cleaner
to assert the reset only on demand, and not permanently.

Signed-off-by: Martin Krause <martin.krause at tqs.de>
---

 board/tqm5200/tqm5200.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


diff --git a/board/tqm5200/tqm5200.c b/board/tqm5200/tqm5200.c
index e67145e..3715267 100644
--- a/board/tqm5200/tqm5200.c
+++ b/board/tqm5200/tqm5200.c
@@ -316,6 +316,9 @@ void init_ide_reset (void)
 	/* Configure PSC1_4 as GPIO output for ATA reset */
 	*(vu_long *) MPC5XXX_WU_GPIO_ENABLE |= GPIO_PSC1_4;
 	*(vu_long *) MPC5XXX_WU_GPIO_DIR    |= GPIO_PSC1_4;
+
+	/* per default the ATA reset is de-asserted */
+	*(vu_long *) MPC5XXX_WU_GPIO_DATA_O |=  GPIO_PSC1_4;
 #endif
 }
 




From lg at denx.de  Thu Apr  3 14:35:08 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 14:35:08 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
Message-ID: <Pine.LNX.4.64.0804031424530.18539@axis700.grange>

Replace direct register address derefencing with accessor functions. 
Restrict explicitly 32-bit bus-width, extend affected configurations 
respectively.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

Sascha, please test.

diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index c332189..c17dcf4 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -30,321 +30,332 @@
 #include <net.h>
 #include <miiphy.h>
 
-#define mdelay(n)       udelay((n)*1000)
+#ifdef CONFIG_DRIVER_SMC911X_32_BIT
+static inline u32 reg_read(u32 addr)
+{
+	return *(volatile u32*)addr;
+}
+static inline void reg_write(u32 addr, u32 val)
+{
+	*(volatile u32*)addr = val;
+}
+#else
+#error "SMC911X: Only 32-bit bus is supported"
+#endif
 
-#define __REG(x)     (*((volatile u32 *)(x)))
+#define mdelay(n)       udelay((n)*1000)
 
 /* Below are the register offsets and bit definitions
  * of the Lan911x memory space
  */
-#define RX_DATA_FIFO		 __REG(CONFIG_DRIVER_SMC911X_BASE + 0x00)
-
-#define TX_DATA_FIFO		 __REG(CONFIG_DRIVER_SMC911X_BASE + 0x20)
-#define	TX_CMD_A_INT_ON_COMP			(0x80000000)
-#define	TX_CMD_A_INT_BUF_END_ALGN		(0x03000000)
-#define	TX_CMD_A_INT_4_BYTE_ALGN		(0x00000000)
-#define	TX_CMD_A_INT_16_BYTE_ALGN		(0x01000000)
-#define	TX_CMD_A_INT_32_BYTE_ALGN		(0x02000000)
-#define	TX_CMD_A_INT_DATA_OFFSET		(0x001F0000)
-#define	TX_CMD_A_INT_FIRST_SEG			(0x00002000)
-#define	TX_CMD_A_INT_LAST_SEG			(0x00001000)
-#define	TX_CMD_A_BUF_SIZE			(0x000007FF)
-#define	TX_CMD_B_PKT_TAG			(0xFFFF0000)
-#define	TX_CMD_B_ADD_CRC_DISABLE		(0x00002000)
-#define	TX_CMD_B_DISABLE_PADDING		(0x00001000)
-#define	TX_CMD_B_PKT_BYTE_LENGTH		(0x000007FF)
-
-#define RX_STATUS_FIFO		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x40)
-#define	RX_STS_PKT_LEN				(0x3FFF0000)
-#define	RX_STS_ES				(0x00008000)
-#define	RX_STS_BCST				(0x00002000)
-#define	RX_STS_LEN_ERR				(0x00001000)
-#define	RX_STS_RUNT_ERR				(0x00000800)
-#define	RX_STS_MCAST				(0x00000400)
-#define	RX_STS_TOO_LONG				(0x00000080)
-#define	RX_STS_COLL				(0x00000040)
-#define	RX_STS_ETH_TYPE				(0x00000020)
-#define	RX_STS_WDOG_TMT				(0x00000010)
-#define	RX_STS_MII_ERR				(0x00000008)
-#define	RX_STS_DRIBBLING			(0x00000004)
-#define	RX_STS_CRC_ERR				(0x00000002)
-#define RX_STATUS_FIFO_PEEK 	__REG(CONFIG_DRIVER_SMC911X_BASE + 0x44)
-#define TX_STATUS_FIFO		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x48)
-#define	TX_STS_TAG				(0xFFFF0000)
-#define	TX_STS_ES				(0x00008000)
-#define	TX_STS_LOC				(0x00000800)
-#define	TX_STS_NO_CARR				(0x00000400)
-#define	TX_STS_LATE_COLL			(0x00000200)
-#define	TX_STS_MANY_COLL			(0x00000100)
-#define	TX_STS_COLL_CNT				(0x00000078)
-#define	TX_STS_MANY_DEFER			(0x00000004)
-#define	TX_STS_UNDERRUN				(0x00000002)
-#define	TX_STS_DEFERRED				(0x00000001)
-#define TX_STATUS_FIFO_PEEK	__REG(CONFIG_DRIVER_SMC911X_BASE + 0x4C)
-#define ID_REV			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x50)
-#define	ID_REV_CHIP_ID				(0xFFFF0000)  /* RO */
-#define	ID_REV_REV_ID				(0x0000FFFF)  /* RO */
-
-#define INT_CFG			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x54)
-#define	INT_CFG_INT_DEAS			(0xFF000000)  /* R/W */
-#define	INT_CFG_INT_DEAS_CLR			(0x00004000)
-#define	INT_CFG_INT_DEAS_STS			(0x00002000)
-#define	INT_CFG_IRQ_INT				(0x00001000)  /* RO */
-#define	INT_CFG_IRQ_EN				(0x00000100)  /* R/W */
-#define	INT_CFG_IRQ_POL				(0x00000010)  /* R/W Not Affected by SW Reset */
-#define	INT_CFG_IRQ_TYPE			(0x00000001)  /* R/W Not Affected by SW Reset */
-
-#define INT_STS			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x58)
-#define	INT_STS_SW_INT				(0x80000000)  /* R/WC */
-#define	INT_STS_TXSTOP_INT			(0x02000000)  /* R/WC */
-#define	INT_STS_RXSTOP_INT			(0x01000000)  /* R/WC */
-#define	INT_STS_RXDFH_INT			(0x00800000)  /* R/WC */
-#define	INT_STS_RXDF_INT			(0x00400000)  /* R/WC */
-#define	INT_STS_TX_IOC				(0x00200000)  /* R/WC */
-#define	INT_STS_RXD_INT				(0x00100000)  /* R/WC */
-#define	INT_STS_GPT_INT				(0x00080000)  /* R/WC */
-#define	INT_STS_PHY_INT				(0x00040000)  /* RO */
-#define	INT_STS_PME_INT				(0x00020000)  /* R/WC */
-#define	INT_STS_TXSO				(0x00010000)  /* R/WC */
-#define	INT_STS_RWT				(0x00008000)  /* R/WC */
-#define	INT_STS_RXE				(0x00004000)  /* R/WC */
-#define	INT_STS_TXE				(0x00002000)  /* R/WC */
-/*#define	INT_STS_ERX		(0x00001000)*/  /* R/WC */
-#define	INT_STS_TDFU				(0x00000800)  /* R/WC */
-#define	INT_STS_TDFO				(0x00000400)  /* R/WC */
-#define	INT_STS_TDFA				(0x00000200)  /* R/WC */
-#define	INT_STS_TSFF				(0x00000100)  /* R/WC */
-#define	INT_STS_TSFL				(0x00000080)  /* R/WC */
-/*#define	INT_STS_RXDF		(0x00000040)*/  /* R/WC */
-#define	INT_STS_RDFO				(0x00000040)  /* R/WC */
-#define	INT_STS_RDFL				(0x00000020)  /* R/WC */
-#define	INT_STS_RSFF				(0x00000010)  /* R/WC */
-#define	INT_STS_RSFL				(0x00000008)  /* R/WC */
-#define	INT_STS_GPIO2_INT			(0x00000004)  /* R/WC */
-#define	INT_STS_GPIO1_INT			(0x00000002)  /* R/WC */
-#define	INT_STS_GPIO0_INT			(0x00000001)  /* R/WC */
-#define INT_EN			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x5C)
-#define	INT_EN_SW_INT_EN			(0x80000000)  /* R/W */
-#define	INT_EN_TXSTOP_INT_EN			(0x02000000)  /* R/W */
-#define	INT_EN_RXSTOP_INT_EN			(0x01000000)  /* R/W */
-#define	INT_EN_RXDFH_INT_EN			(0x00800000)  /* R/W */
-/*#define	INT_EN_RXDF_INT_EN		(0x00400000)*/  /* R/W */
-#define	INT_EN_TIOC_INT_EN			(0x00200000)  /* R/W */
-#define	INT_EN_RXD_INT_EN			(0x00100000)  /* R/W */
-#define	INT_EN_GPT_INT_EN			(0x00080000)  /* R/W */
-#define	INT_EN_PHY_INT_EN			(0x00040000)  /* R/W */
-#define	INT_EN_PME_INT_EN			(0x00020000)  /* R/W */
-#define	INT_EN_TXSO_EN				(0x00010000)  /* R/W */
-#define	INT_EN_RWT_EN				(0x00008000)  /* R/W */
-#define	INT_EN_RXE_EN				(0x00004000)  /* R/W */
-#define	INT_EN_TXE_EN				(0x00002000)  /* R/W */
-/*#define	INT_EN_ERX_EN			(0x00001000)*/  /* R/W */
-#define	INT_EN_TDFU_EN				(0x00000800)  /* R/W */
-#define	INT_EN_TDFO_EN				(0x00000400)  /* R/W */
-#define	INT_EN_TDFA_EN				(0x00000200)  /* R/W */
-#define	INT_EN_TSFF_EN				(0x00000100)  /* R/W */
-#define	INT_EN_TSFL_EN				(0x00000080)  /* R/W */
-/*#define	INT_EN_RXDF_EN			(0x00000040)*/  /* R/W */
-#define	INT_EN_RDFO_EN				(0x00000040)  /* R/W */
-#define	INT_EN_RDFL_EN				(0x00000020)  /* R/W */
-#define	INT_EN_RSFF_EN				(0x00000010)  /* R/W */
-#define	INT_EN_RSFL_EN				(0x00000008)  /* R/W */
-#define	INT_EN_GPIO2_INT			(0x00000004)  /* R/W */
-#define	INT_EN_GPIO1_INT			(0x00000002)  /* R/W */
-#define	INT_EN_GPIO0_INT			(0x00000001)  /* R/W */
-
-#define BYTE_TEST		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x64)
-#define FIFO_INT		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x68)
-#define	FIFO_INT_TX_AVAIL_LEVEL			(0xFF000000)  /* R/W */
-#define	FIFO_INT_TX_STS_LEVEL			(0x00FF0000)  /* R/W */
-#define	FIFO_INT_RX_AVAIL_LEVEL			(0x0000FF00)  /* R/W */
-#define	FIFO_INT_RX_STS_LEVEL			(0x000000FF)  /* R/W */
-
-#define RX_CFG			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x6C)
-#define	RX_CFG_RX_END_ALGN			(0xC0000000)  /* R/W */
-#define		RX_CFG_RX_END_ALGN4		(0x00000000)  /* R/W */
-#define		RX_CFG_RX_END_ALGN16		(0x40000000)  /* R/W */
-#define		RX_CFG_RX_END_ALGN32		(0x80000000)  /* R/W */
-#define	RX_CFG_RX_DMA_CNT			(0x0FFF0000)  /* R/W */
-#define	RX_CFG_RX_DUMP				(0x00008000)  /* R/W */
-#define	RX_CFG_RXDOFF				(0x00001F00)  /* R/W */
-/*#define	RX_CFG_RXBAD			(0x00000001)*/  /* R/W */
-
-#define TX_CFG			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x70)
-/*#define	TX_CFG_TX_DMA_LVL		(0xE0000000)*/	 /* R/W */
-/*#define	TX_CFG_TX_DMA_CNT		(0x0FFF0000)*/	 /* R/W Self Clearing */
-#define	TX_CFG_TXS_DUMP				(0x00008000)  /* Self Clearing */
-#define	TX_CFG_TXD_DUMP				(0x00004000)  /* Self Clearing */
-#define	TX_CFG_TXSAO				(0x00000004)  /* R/W */
-#define	TX_CFG_TX_ON				(0x00000002)  /* R/W */
-#define	TX_CFG_STOP_TX				(0x00000001)  /* Self Clearing */
-
-#define HW_CFG			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x74)
-#define	HW_CFG_TTM				(0x00200000)  /* R/W */
-#define	HW_CFG_SF				(0x00100000)  /* R/W */
-#define	HW_CFG_TX_FIF_SZ			(0x000F0000)  /* R/W */
-#define	HW_CFG_TR				(0x00003000)  /* R/W */
-#define	HW_CFG_PHY_CLK_SEL			(0x00000060)  /* R/W */
-#define	HW_CFG_PHY_CLK_SEL_INT_PHY 		(0x00000000) /* R/W */
-#define	HW_CFG_PHY_CLK_SEL_EXT_PHY 		(0x00000020) /* R/W */
-#define	HW_CFG_PHY_CLK_SEL_CLK_DIS 		(0x00000040) /* R/W */
-#define	HW_CFG_SMI_SEL				(0x00000010)  /* R/W */
-#define	HW_CFG_EXT_PHY_DET			(0x00000008)  /* RO */
-#define	HW_CFG_EXT_PHY_EN			(0x00000004)  /* R/W */
-#define	HW_CFG_32_16_BIT_MODE			(0x00000004)  /* RO */
-#define	HW_CFG_SRST_TO				(0x00000002)  /* RO */
-#define	HW_CFG_SRST				(0x00000001)  /* Self Clearing */
-
-#define RX_DP_CTRL		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x78)
-#define	RX_DP_CTRL_RX_FFWD			(0x80000000)  /* R/W */
-#define	RX_DP_CTRL_FFWD_BUSY			(0x80000000)  /* RO */
-
-#define RX_FIFO_INF		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x7C)
-#define	 RX_FIFO_INF_RXSUSED			(0x00FF0000)  /* RO */
-#define	 RX_FIFO_INF_RXDUSED			(0x0000FFFF)  /* RO */
-
-#define TX_FIFO_INF		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x80)
-#define	TX_FIFO_INF_TSUSED			(0x00FF0000)  /* RO */
-#define	TX_FIFO_INF_TDFREE			(0x0000FFFF)  /* RO */
-
-#define PMT_CTRL		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x84)
-#define	PMT_CTRL_PM_MODE			(0x00003000)  /* Self Clearing */
-#define	PMT_CTRL_PHY_RST			(0x00000400)  /* Self Clearing */
-#define	PMT_CTRL_WOL_EN				(0x00000200)  /* R/W */
-#define	PMT_CTRL_ED_EN				(0x00000100)  /* R/W */
-#define	PMT_CTRL_PME_TYPE			(0x00000040)  /* R/W Not Affected by SW Reset */
-#define	PMT_CTRL_WUPS				(0x00000030)  /* R/WC */
-#define	PMT_CTRL_WUPS_NOWAKE			(0x00000000)  /* R/WC */
-#define	PMT_CTRL_WUPS_ED			(0x00000010)  /* R/WC */
-#define	PMT_CTRL_WUPS_WOL			(0x00000020)  /* R/WC */
-#define	PMT_CTRL_WUPS_MULTI			(0x00000030)  /* R/WC */
-#define	PMT_CTRL_PME_IND			(0x00000008)  /* R/W */
-#define	PMT_CTRL_PME_POL			(0x00000004)  /* R/W */
-#define	PMT_CTRL_PME_EN				(0x00000002)  /* R/W Not Affected by SW Reset */
-#define	PMT_CTRL_READY				(0x00000001)  /* RO */
-
-#define GPIO_CFG		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x88)
-#define	GPIO_CFG_LED3_EN			(0x40000000)  /* R/W */
-#define	GPIO_CFG_LED2_EN			(0x20000000)  /* R/W */
-#define	GPIO_CFG_LED1_EN			(0x10000000)  /* R/W */
-#define	GPIO_CFG_GPIO2_INT_POL			(0x04000000)  /* R/W */
-#define	GPIO_CFG_GPIO1_INT_POL			(0x02000000)  /* R/W */
-#define	GPIO_CFG_GPIO0_INT_POL			(0x01000000)  /* R/W */
-#define	GPIO_CFG_EEPR_EN			(0x00700000)  /* R/W */
-#define	GPIO_CFG_GPIOBUF2			(0x00040000)  /* R/W */
-#define	GPIO_CFG_GPIOBUF1			(0x00020000)  /* R/W */
-#define	GPIO_CFG_GPIOBUF0			(0x00010000)  /* R/W */
-#define	GPIO_CFG_GPIODIR2			(0x00000400)  /* R/W */
-#define	GPIO_CFG_GPIODIR1			(0x00000200)  /* R/W */
-#define	GPIO_CFG_GPIODIR0			(0x00000100)  /* R/W */
-#define	GPIO_CFG_GPIOD4				(0x00000010)  /* R/W */
-#define	GPIO_CFG_GPIOD3				(0x00000008)  /* R/W */
-#define	GPIO_CFG_GPIOD2				(0x00000004)  /* R/W */
-#define	GPIO_CFG_GPIOD1				(0x00000002)  /* R/W */
-#define	GPIO_CFG_GPIOD0				(0x00000001)  /* R/W */
-
-#define GPT_CFG			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x8C)
-#define	GPT_CFG_TIMER_EN			(0x20000000)  /* R/W */
-#define	GPT_CFG_GPT_LOAD			(0x0000FFFF)  /* R/W */
-
-#define GPT_CNT			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x90)
-#define	GPT_CNT_GPT_CNT				(0x0000FFFF)  /* RO */
-
-#define ENDIAN			__REG(CONFIG_DRIVER_SMC911X_BASE + 0x98)
-#define FREE_RUN		__REG(CONFIG_DRIVER_SMC911X_BASE + 0x9C)
-#define RX_DROP			__REG(CONFIG_DRIVER_SMC911X_BASE + 0xA0)
-#define MAC_CSR_CMD		__REG(CONFIG_DRIVER_SMC911X_BASE + 0xA4)
-#define	 MAC_CSR_CMD_CSR_BUSY			(0x80000000)  /* Self Clearing */
-#define	 MAC_CSR_CMD_R_NOT_W			(0x40000000)  /* R/W */
-#define	 MAC_CSR_CMD_CSR_ADDR			(0x000000FF)  /* R/W */
-
-#define MAC_CSR_DATA		__REG(CONFIG_DRIVER_SMC911X_BASE + 0xA8)
-#define AFC_CFG			__REG(CONFIG_DRIVER_SMC911X_BASE + 0xAC)
-#define		AFC_CFG_AFC_HI			(0x00FF0000)  /* R/W */
-#define		AFC_CFG_AFC_LO			(0x0000FF00)  /* R/W */
-#define		AFC_CFG_BACK_DUR		(0x000000F0)  /* R/W */
-#define		AFC_CFG_FCMULT			(0x00000008)  /* R/W */
-#define		AFC_CFG_FCBRD			(0x00000004)  /* R/W */
-#define		AFC_CFG_FCADD			(0x00000002)  /* R/W */
-#define		AFC_CFG_FCANY			(0x00000001)  /* R/W */
-
-#define E2P_CMD			__REG(CONFIG_DRIVER_SMC911X_BASE + 0xB0)
-#define		E2P_CMD_EPC_BUSY		(0x80000000)  /* Self Clearing */
-#define		E2P_CMD_EPC_CMD			(0x70000000)  /* R/W */
-#define		E2P_CMD_EPC_CMD_READ		(0x00000000)  /* R/W */
-#define		E2P_CMD_EPC_CMD_EWDS		(0x10000000)  /* R/W */
-#define		E2P_CMD_EPC_CMD_EWEN		(0x20000000)  /* R/W */
-#define		E2P_CMD_EPC_CMD_WRITE		(0x30000000)  /* R/W */
-#define		E2P_CMD_EPC_CMD_WRAL		(0x40000000)  /* R/W */
-#define		E2P_CMD_EPC_CMD_ERASE		(0x50000000)  /* R/W */
-#define		E2P_CMD_EPC_CMD_ERAL		(0x60000000)  /* R/W */
-#define		E2P_CMD_EPC_CMD_RELOAD		(0x70000000)  /* R/W */
-#define		E2P_CMD_EPC_TIMEOUT		(0x00000200)  /* RO */
-#define		E2P_CMD_MAC_ADDR_LOADED		(0x00000100)  /* RO */
-#define		E2P_CMD_EPC_ADDR		(0x000000FF)  /* R/W */
-
-#define E2P_DATA		__REG(CONFIG_DRIVER_SMC911X_BASE + 0xB4)
-#define	E2P_DATA_EEPROM_DATA			(0x000000FF)  /* R/W */
+#define RX_DATA_FIFO		 (CONFIG_DRIVER_SMC911X_BASE + 0x00)
+
+#define TX_DATA_FIFO		 (CONFIG_DRIVER_SMC911X_BASE + 0x20)
+#define	TX_CMD_A_INT_ON_COMP			0x80000000
+#define	TX_CMD_A_INT_BUF_END_ALGN		0x03000000
+#define	TX_CMD_A_INT_4_BYTE_ALGN		0x00000000
+#define	TX_CMD_A_INT_16_BYTE_ALGN		0x01000000
+#define	TX_CMD_A_INT_32_BYTE_ALGN		0x02000000
+#define	TX_CMD_A_INT_DATA_OFFSET		0x001F0000
+#define	TX_CMD_A_INT_FIRST_SEG			0x00002000
+#define	TX_CMD_A_INT_LAST_SEG			0x00001000
+#define	TX_CMD_A_BUF_SIZE			0x000007FF
+#define	TX_CMD_B_PKT_TAG			0xFFFF0000
+#define	TX_CMD_B_ADD_CRC_DISABLE		0x00002000
+#define	TX_CMD_B_DISABLE_PADDING		0x00001000
+#define	TX_CMD_B_PKT_BYTE_LENGTH		0x000007FF
+
+#define RX_STATUS_FIFO		(CONFIG_DRIVER_SMC911X_BASE + 0x40)
+#define	RX_STS_PKT_LEN				0x3FFF0000
+#define	RX_STS_ES				0x00008000
+#define	RX_STS_BCST				0x00002000
+#define	RX_STS_LEN_ERR				0x00001000
+#define	RX_STS_RUNT_ERR				0x00000800
+#define	RX_STS_MCAST				0x00000400
+#define	RX_STS_TOO_LONG				0x00000080
+#define	RX_STS_COLL				0x00000040
+#define	RX_STS_ETH_TYPE				0x00000020
+#define	RX_STS_WDOG_TMT				0x00000010
+#define	RX_STS_MII_ERR				0x00000008
+#define	RX_STS_DRIBBLING			0x00000004
+#define	RX_STS_CRC_ERR				0x00000002
+#define RX_STATUS_FIFO_PEEK 	(CONFIG_DRIVER_SMC911X_BASE + 0x44)
+#define TX_STATUS_FIFO		(CONFIG_DRIVER_SMC911X_BASE + 0x48)
+#define	TX_STS_TAG				0xFFFF0000
+#define	TX_STS_ES				0x00008000
+#define	TX_STS_LOC				0x00000800
+#define	TX_STS_NO_CARR				0x00000400
+#define	TX_STS_LATE_COLL			0x00000200
+#define	TX_STS_MANY_COLL			0x00000100
+#define	TX_STS_COLL_CNT				0x00000078
+#define	TX_STS_MANY_DEFER			0x00000004
+#define	TX_STS_UNDERRUN				0x00000002
+#define	TX_STS_DEFERRED				0x00000001
+#define TX_STATUS_FIFO_PEEK	(CONFIG_DRIVER_SMC911X_BASE + 0x4C)
+#define ID_REV			(CONFIG_DRIVER_SMC911X_BASE + 0x50)
+#define	ID_REV_CHIP_ID				0xFFFF0000  /* RO */
+#define	ID_REV_REV_ID				0x0000FFFF  /* RO */
+
+#define INT_CFG			(CONFIG_DRIVER_SMC911X_BASE + 0x54)
+#define	INT_CFG_INT_DEAS			0xFF000000  /* R/W */
+#define	INT_CFG_INT_DEAS_CLR			0x00004000
+#define	INT_CFG_INT_DEAS_STS			0x00002000
+#define	INT_CFG_IRQ_INT				0x00001000  /* RO */
+#define	INT_CFG_IRQ_EN				0x00000100  /* R/W */
+#define	INT_CFG_IRQ_POL				0x00000010  /* R/W Not Affected by SW Reset */
+#define	INT_CFG_IRQ_TYPE			0x00000001  /* R/W Not Affected by SW Reset */
+
+#define INT_STS			(CONFIG_DRIVER_SMC911X_BASE + 0x58)
+#define	INT_STS_SW_INT				0x80000000  /* R/WC */
+#define	INT_STS_TXSTOP_INT			0x02000000  /* R/WC */
+#define	INT_STS_RXSTOP_INT			0x01000000  /* R/WC */
+#define	INT_STS_RXDFH_INT			0x00800000  /* R/WC */
+#define	INT_STS_RXDF_INT			0x00400000  /* R/WC */
+#define	INT_STS_TX_IOC				0x00200000  /* R/WC */
+#define	INT_STS_RXD_INT				0x00100000  /* R/WC */
+#define	INT_STS_GPT_INT				0x00080000  /* R/WC */
+#define	INT_STS_PHY_INT				0x00040000  /* RO */
+#define	INT_STS_PME_INT				0x00020000  /* R/WC */
+#define	INT_STS_TXSO				0x00010000  /* R/WC */
+#define	INT_STS_RWT				0x00008000  /* R/WC */
+#define	INT_STS_RXE				0x00004000  /* R/WC */
+#define	INT_STS_TXE				0x00002000  /* R/WC */
+/*#define	INT_STS_ERX		0x00001000*/  /* R/WC */
+#define	INT_STS_TDFU				0x00000800  /* R/WC */
+#define	INT_STS_TDFO				0x00000400  /* R/WC */
+#define	INT_STS_TDFA				0x00000200  /* R/WC */
+#define	INT_STS_TSFF				0x00000100  /* R/WC */
+#define	INT_STS_TSFL				0x00000080  /* R/WC */
+/*#define	INT_STS_RXDF		0x00000040*/  /* R/WC */
+#define	INT_STS_RDFO				0x00000040  /* R/WC */
+#define	INT_STS_RDFL				0x00000020  /* R/WC */
+#define	INT_STS_RSFF				0x00000010  /* R/WC */
+#define	INT_STS_RSFL				0x00000008  /* R/WC */
+#define	INT_STS_GPIO2_INT			0x00000004  /* R/WC */
+#define	INT_STS_GPIO1_INT			0x00000002  /* R/WC */
+#define	INT_STS_GPIO0_INT			0x00000001  /* R/WC */
+#define INT_EN			(CONFIG_DRIVER_SMC911X_BASE + 0x5C)
+#define	INT_EN_SW_INT_EN			0x80000000  /* R/W */
+#define	INT_EN_TXSTOP_INT_EN			0x02000000  /* R/W */
+#define	INT_EN_RXSTOP_INT_EN			0x01000000  /* R/W */
+#define	INT_EN_RXDFH_INT_EN			0x00800000  /* R/W */
+/*#define	INT_EN_RXDF_INT_EN		0x00400000*/  /* R/W */
+#define	INT_EN_TIOC_INT_EN			0x00200000  /* R/W */
+#define	INT_EN_RXD_INT_EN			0x00100000  /* R/W */
+#define	INT_EN_GPT_INT_EN			0x00080000  /* R/W */
+#define	INT_EN_PHY_INT_EN			0x00040000  /* R/W */
+#define	INT_EN_PME_INT_EN			0x00020000  /* R/W */
+#define	INT_EN_TXSO_EN				0x00010000  /* R/W */
+#define	INT_EN_RWT_EN				0x00008000  /* R/W */
+#define	INT_EN_RXE_EN				0x00004000  /* R/W */
+#define	INT_EN_TXE_EN				0x00002000  /* R/W */
+/*#define	INT_EN_ERX_EN			0x00001000*/  /* R/W */
+#define	INT_EN_TDFU_EN				0x00000800  /* R/W */
+#define	INT_EN_TDFO_EN				0x00000400  /* R/W */
+#define	INT_EN_TDFA_EN				0x00000200  /* R/W */
+#define	INT_EN_TSFF_EN				0x00000100  /* R/W */
+#define	INT_EN_TSFL_EN				0x00000080  /* R/W */
+/*#define	INT_EN_RXDF_EN			0x00000040*/  /* R/W */
+#define	INT_EN_RDFO_EN				0x00000040  /* R/W */
+#define	INT_EN_RDFL_EN				0x00000020  /* R/W */
+#define	INT_EN_RSFF_EN				0x00000010  /* R/W */
+#define	INT_EN_RSFL_EN				0x00000008  /* R/W */
+#define	INT_EN_GPIO2_INT			0x00000004  /* R/W */
+#define	INT_EN_GPIO1_INT			0x00000002  /* R/W */
+#define	INT_EN_GPIO0_INT			0x00000001  /* R/W */
+
+#define BYTE_TEST		(CONFIG_DRIVER_SMC911X_BASE + 0x64)
+#define FIFO_INT		(CONFIG_DRIVER_SMC911X_BASE + 0x68)
+#define	FIFO_INT_TX_AVAIL_LEVEL			0xFF000000  /* R/W */
+#define	FIFO_INT_TX_STS_LEVEL			0x00FF0000  /* R/W */
+#define	FIFO_INT_RX_AVAIL_LEVEL			0x0000FF00  /* R/W */
+#define	FIFO_INT_RX_STS_LEVEL			0x000000FF  /* R/W */
+
+#define RX_CFG			(CONFIG_DRIVER_SMC911X_BASE + 0x6C)
+#define	RX_CFG_RX_END_ALGN			0xC0000000  /* R/W */
+#define		RX_CFG_RX_END_ALGN4		0x00000000  /* R/W */
+#define		RX_CFG_RX_END_ALGN16		0x40000000  /* R/W */
+#define		RX_CFG_RX_END_ALGN32		0x80000000  /* R/W */
+#define	RX_CFG_RX_DMA_CNT			0x0FFF0000  /* R/W */
+#define	RX_CFG_RX_DUMP				0x00008000  /* R/W */
+#define	RX_CFG_RXDOFF				0x00001F00  /* R/W */
+/*#define	RX_CFG_RXBAD			0x00000001*/  /* R/W */
+
+#define TX_CFG			(CONFIG_DRIVER_SMC911X_BASE + 0x70)
+/*#define	TX_CFG_TX_DMA_LVL		0xE0000000*/	 /* R/W */
+/*#define	TX_CFG_TX_DMA_CNT		0x0FFF0000*/	 /* R/W Self Clearing */
+#define	TX_CFG_TXS_DUMP				0x00008000  /* Self Clearing */
+#define	TX_CFG_TXD_DUMP				0x00004000  /* Self Clearing */
+#define	TX_CFG_TXSAO				0x00000004  /* R/W */
+#define	TX_CFG_TX_ON				0x00000002  /* R/W */
+#define	TX_CFG_STOP_TX				0x00000001  /* Self Clearing */
+
+#define HW_CFG			(CONFIG_DRIVER_SMC911X_BASE + 0x74)
+#define	HW_CFG_TTM				0x00200000  /* R/W */
+#define	HW_CFG_SF				0x00100000  /* R/W */
+#define	HW_CFG_TX_FIF_SZ			0x000F0000  /* R/W */
+#define	HW_CFG_TR				0x00003000  /* R/W */
+#define	HW_CFG_PHY_CLK_SEL			0x00000060  /* R/W */
+#define	HW_CFG_PHY_CLK_SEL_INT_PHY 		0x00000000 /* R/W */
+#define	HW_CFG_PHY_CLK_SEL_EXT_PHY 		0x00000020 /* R/W */
+#define	HW_CFG_PHY_CLK_SEL_CLK_DIS 		0x00000040 /* R/W */
+#define	HW_CFG_SMI_SEL				0x00000010  /* R/W */
+#define	HW_CFG_EXT_PHY_DET			0x00000008  /* RO */
+#define	HW_CFG_EXT_PHY_EN			0x00000004  /* R/W */
+#define	HW_CFG_32_16_BIT_MODE			0x00000004  /* RO */
+#define	HW_CFG_SRST_TO				0x00000002  /* RO */
+#define	HW_CFG_SRST				0x00000001  /* Self Clearing */
+
+#define RX_DP_CTRL		(CONFIG_DRIVER_SMC911X_BASE + 0x78)
+#define	RX_DP_CTRL_RX_FFWD			0x80000000  /* R/W */
+#define	RX_DP_CTRL_FFWD_BUSY			0x80000000  /* RO */
+
+#define RX_FIFO_INF		(CONFIG_DRIVER_SMC911X_BASE + 0x7C)
+#define	 RX_FIFO_INF_RXSUSED			0x00FF0000  /* RO */
+#define	 RX_FIFO_INF_RXDUSED			0x0000FFFF  /* RO */
+
+#define TX_FIFO_INF		(CONFIG_DRIVER_SMC911X_BASE + 0x80)
+#define	TX_FIFO_INF_TSUSED			0x00FF0000  /* RO */
+#define	TX_FIFO_INF_TDFREE			0x0000FFFF  /* RO */
+
+#define PMT_CTRL		(CONFIG_DRIVER_SMC911X_BASE + 0x84)
+#define	PMT_CTRL_PM_MODE			0x00003000  /* Self Clearing */
+#define	PMT_CTRL_PHY_RST			0x00000400  /* Self Clearing */
+#define	PMT_CTRL_WOL_EN				0x00000200  /* R/W */
+#define	PMT_CTRL_ED_EN				0x00000100  /* R/W */
+#define	PMT_CTRL_PME_TYPE			0x00000040  /* R/W Not Affected by SW Reset */
+#define	PMT_CTRL_WUPS				0x00000030  /* R/WC */
+#define	PMT_CTRL_WUPS_NOWAKE			0x00000000  /* R/WC */
+#define	PMT_CTRL_WUPS_ED			0x00000010  /* R/WC */
+#define	PMT_CTRL_WUPS_WOL			0x00000020  /* R/WC */
+#define	PMT_CTRL_WUPS_MULTI			0x00000030  /* R/WC */
+#define	PMT_CTRL_PME_IND			0x00000008  /* R/W */
+#define	PMT_CTRL_PME_POL			0x00000004  /* R/W */
+#define	PMT_CTRL_PME_EN				0x00000002  /* R/W Not Affected by SW Reset */
+#define	PMT_CTRL_READY				0x00000001  /* RO */
+
+#define GPIO_CFG		(CONFIG_DRIVER_SMC911X_BASE + 0x88)
+#define	GPIO_CFG_LED3_EN			0x40000000  /* R/W */
+#define	GPIO_CFG_LED2_EN			0x20000000  /* R/W */
+#define	GPIO_CFG_LED1_EN			0x10000000  /* R/W */
+#define	GPIO_CFG_GPIO2_INT_POL			0x04000000  /* R/W */
+#define	GPIO_CFG_GPIO1_INT_POL			0x02000000  /* R/W */
+#define	GPIO_CFG_GPIO0_INT_POL			0x01000000  /* R/W */
+#define	GPIO_CFG_EEPR_EN			0x00700000  /* R/W */
+#define	GPIO_CFG_GPIOBUF2			0x00040000  /* R/W */
+#define	GPIO_CFG_GPIOBUF1			0x00020000  /* R/W */
+#define	GPIO_CFG_GPIOBUF0			0x00010000  /* R/W */
+#define	GPIO_CFG_GPIODIR2			0x00000400  /* R/W */
+#define	GPIO_CFG_GPIODIR1			0x00000200  /* R/W */
+#define	GPIO_CFG_GPIODIR0			0x00000100  /* R/W */
+#define	GPIO_CFG_GPIOD4				0x00000010  /* R/W */
+#define	GPIO_CFG_GPIOD3				0x00000008  /* R/W */
+#define	GPIO_CFG_GPIOD2				0x00000004  /* R/W */
+#define	GPIO_CFG_GPIOD1				0x00000002  /* R/W */
+#define	GPIO_CFG_GPIOD0				0x00000001  /* R/W */
+
+#define GPT_CFG			(CONFIG_DRIVER_SMC911X_BASE + 0x8C)
+#define	GPT_CFG_TIMER_EN			0x20000000  /* R/W */
+#define	GPT_CFG_GPT_LOAD			0x0000FFFF  /* R/W */
+
+#define GPT_CNT			(CONFIG_DRIVER_SMC911X_BASE + 0x90)
+#define	GPT_CNT_GPT_CNT				0x0000FFFF  /* RO */
+
+#define ENDIAN			(CONFIG_DRIVER_SMC911X_BASE + 0x98)
+#define FREE_RUN		(CONFIG_DRIVER_SMC911X_BASE + 0x9C)
+#define RX_DROP			(CONFIG_DRIVER_SMC911X_BASE + 0xA0)
+#define MAC_CSR_CMD		(CONFIG_DRIVER_SMC911X_BASE + 0xA4)
+#define	 MAC_CSR_CMD_CSR_BUSY			0x80000000  /* Self Clearing */
+#define	 MAC_CSR_CMD_R_NOT_W			0x40000000  /* R/W */
+#define	 MAC_CSR_CMD_CSR_ADDR			0x000000FF  /* R/W */
+
+#define MAC_CSR_DATA		(CONFIG_DRIVER_SMC911X_BASE + 0xA8)
+#define AFC_CFG			(CONFIG_DRIVER_SMC911X_BASE + 0xAC)
+#define		AFC_CFG_AFC_HI			0x00FF0000  /* R/W */
+#define		AFC_CFG_AFC_LO			0x0000FF00  /* R/W */
+#define		AFC_CFG_BACK_DUR		0x000000F0  /* R/W */
+#define		AFC_CFG_FCMULT			0x00000008  /* R/W */
+#define		AFC_CFG_FCBRD			0x00000004  /* R/W */
+#define		AFC_CFG_FCADD			0x00000002  /* R/W */
+#define		AFC_CFG_FCANY			0x00000001  /* R/W */
+
+#define E2P_CMD			(CONFIG_DRIVER_SMC911X_BASE + 0xB0)
+#define		E2P_CMD_EPC_BUSY		0x80000000  /* Self Clearing */
+#define		E2P_CMD_EPC_CMD			0x70000000  /* R/W */
+#define		E2P_CMD_EPC_CMD_READ		0x00000000  /* R/W */
+#define		E2P_CMD_EPC_CMD_EWDS		0x10000000  /* R/W */
+#define		E2P_CMD_EPC_CMD_EWEN		0x20000000  /* R/W */
+#define		E2P_CMD_EPC_CMD_WRITE		0x30000000  /* R/W */
+#define		E2P_CMD_EPC_CMD_WRAL		0x40000000  /* R/W */
+#define		E2P_CMD_EPC_CMD_ERASE		0x50000000  /* R/W */
+#define		E2P_CMD_EPC_CMD_ERAL		0x60000000  /* R/W */
+#define		E2P_CMD_EPC_CMD_RELOAD		0x70000000  /* R/W */
+#define		E2P_CMD_EPC_TIMEOUT		0x00000200  /* RO */
+#define		E2P_CMD_MAC_ADDR_LOADED		0x00000100  /* RO */
+#define		E2P_CMD_EPC_ADDR		0x000000FF  /* R/W */
+
+#define E2P_DATA		(CONFIG_DRIVER_SMC911X_BASE + 0xB4)
+#define	E2P_DATA_EEPROM_DATA			0x000000FF  /* R/W */
 /* end of LAN register offsets and bit definitions */
 
 /* MAC Control and Status registers */
-#define MAC_CR			(0x01)  /* R/W */
+#define MAC_CR			0x01  /* R/W */
 
 /* MAC_CR - MAC Control Register */
-#define MAC_CR_RXALL			(0x80000000)
+#define MAC_CR_RXALL			0x80000000
 /* TODO: delete this bit? It is not described in the data sheet. */
-#define MAC_CR_HBDIS			(0x10000000)
-#define MAC_CR_RCVOWN			(0x00800000)
-#define MAC_CR_LOOPBK			(0x00200000)
-#define MAC_CR_FDPX			(0x00100000)
-#define MAC_CR_MCPAS			(0x00080000)
-#define MAC_CR_PRMS			(0x00040000)
-#define MAC_CR_INVFILT			(0x00020000)
-#define MAC_CR_PASSBAD			(0x00010000)
-#define MAC_CR_HFILT			(0x00008000)
-#define MAC_CR_HPFILT			(0x00002000)
-#define MAC_CR_LCOLL			(0x00001000)
-#define MAC_CR_BCAST			(0x00000800)
-#define MAC_CR_DISRTY			(0x00000400)
-#define MAC_CR_PADSTR			(0x00000100)
-#define MAC_CR_BOLMT_MASK		(0x000000C0)
-#define MAC_CR_DFCHK			(0x00000020)
-#define MAC_CR_TXEN			(0x00000008)
-#define MAC_CR_RXEN			(0x00000004)
-
-#define ADDRH			(0x02)	  /* R/W mask 0x0000FFFFUL */
-#define ADDRL			(0x03)	  /* R/W mask 0xFFFFFFFFUL */
-#define HASHH			(0x04)	  /* R/W */
-#define HASHL			(0x05)	  /* R/W */
-
-#define MII_ACC			(0x06)	  /* R/W */
-#define MII_ACC_PHY_ADDR		(0x0000F800)
-#define MII_ACC_MIIRINDA		(0x000007C0)
-#define MII_ACC_MII_WRITE		(0x00000002)
-#define MII_ACC_MII_BUSY		(0x00000001)
-
-#define MII_DATA		(0x07)	  /* R/W mask 0x0000FFFFUL */
-
-#define FLOW			(0x08)	  /* R/W */
-#define FLOW_FCPT			(0xFFFF0000)
-#define FLOW_FCPASS			(0x00000004)
-#define FLOW_FCEN			(0x00000002)
-#define FLOW_FCBSY			(0x00000001)
-
-#define VLAN1			(0x09)	  /* R/W mask 0x0000FFFFUL */
-#define VLAN1_VTI1			(0x0000ffff)
-
-#define VLAN2			(0x0A)	  /* R/W mask 0x0000FFFFUL */
-#define VLAN2_VTI2			(0x0000ffff)
-
-#define WUFF			(0x0B)	  /* WO */
-
-#define WUCSR			(0x0C)	  /* R/W */
-#define WUCSR_GUE			(0x00000200)
-#define WUCSR_WUFR			(0x00000040)
-#define WUCSR_MPR			(0x00000020)
-#define WUCSR_WAKE_EN			(0x00000004)
-#define WUCSR_MPEN			(0x00000002)
+#define MAC_CR_HBDIS			0x10000000
+#define MAC_CR_RCVOWN			0x00800000
+#define MAC_CR_LOOPBK			0x00200000
+#define MAC_CR_FDPX			0x00100000
+#define MAC_CR_MCPAS			0x00080000
+#define MAC_CR_PRMS			0x00040000
+#define MAC_CR_INVFILT			0x00020000
+#define MAC_CR_PASSBAD			0x00010000
+#define MAC_CR_HFILT			0x00008000
+#define MAC_CR_HPFILT			0x00002000
+#define MAC_CR_LCOLL			0x00001000
+#define MAC_CR_BCAST			0x00000800
+#define MAC_CR_DISRTY			0x00000400
+#define MAC_CR_PADSTR			0x00000100
+#define MAC_CR_BOLMT_MASK		0x000000C0
+#define MAC_CR_DFCHK			0x00000020
+#define MAC_CR_TXEN			0x00000008
+#define MAC_CR_RXEN			0x00000004
+
+#define ADDRH			0x02	  /* R/W mask 0x0000FFFFUL */
+#define ADDRL			0x03	  /* R/W mask 0xFFFFFFFFUL */
+#define HASHH			0x04	  /* R/W */
+#define HASHL			0x05	  /* R/W */
+
+#define MII_ACC			0x06	  /* R/W */
+#define MII_ACC_PHY_ADDR		0x0000F800
+#define MII_ACC_MIIRINDA		0x000007C0
+#define MII_ACC_MII_WRITE		0x00000002
+#define MII_ACC_MII_BUSY		0x00000001
+
+#define MII_DATA		0x07	  /* R/W mask 0x0000FFFFUL */
+
+#define FLOW			0x08	  /* R/W */
+#define FLOW_FCPT			0xFFFF0000
+#define FLOW_FCPASS			0x00000004
+#define FLOW_FCEN			0x00000002
+#define FLOW_FCBSY			0x00000001
+
+#define VLAN1			0x09	  /* R/W mask 0x0000FFFFUL */
+#define VLAN1_VTI1			0x0000ffff
+
+#define VLAN2			0x0A	  /* R/W mask 0x0000FFFFUL */
+#define VLAN2_VTI2			0x0000ffff
+
+#define WUFF			0x0B	  /* WO */
+
+#define WUCSR			0x0C	  /* R/W */
+#define WUCSR_GUE			0x00000200
+#define WUCSR_WUFR			0x00000040
+#define WUCSR_MPR			0x00000020
+#define WUCSR_WAKE_EN			0x00000004
+#define WUCSR_MPEN			0x00000002
 
 /* Chip ID values */
 #define CHIP_9115	0x115
@@ -377,19 +388,23 @@ static const struct chip_id chip_ids[] =  {
 
 u32 smc911x_get_mac_csr(u8 reg)
 {
-	while (MAC_CSR_CMD & MAC_CSR_CMD_CSR_BUSY);
-	MAC_CSR_CMD = MAC_CSR_CMD_CSR_BUSY | MAC_CSR_CMD_R_NOT_W | reg;
-	while (MAC_CSR_CMD & MAC_CSR_CMD_CSR_BUSY);
+	while (reg_read(MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+		;
+	reg_write(MAC_CSR_CMD, MAC_CSR_CMD_CSR_BUSY | MAC_CSR_CMD_R_NOT_W | reg);
+	while (reg_read(MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+		;
 
-	return MAC_CSR_DATA;
+	return reg_read(MAC_CSR_DATA);
 }
 
 void smc911x_set_mac_csr(u8 reg, u32 data)
 {
-	while (MAC_CSR_CMD & MAC_CSR_CMD_CSR_BUSY);
-	MAC_CSR_DATA = data;
-	MAC_CSR_CMD = MAC_CSR_CMD_CSR_BUSY | reg;
-	while (MAC_CSR_CMD & MAC_CSR_CMD_CSR_BUSY);
+	while (reg_read(MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+		;
+	reg_write(MAC_CSR_DATA, data);
+	reg_write(MAC_CSR_CMD, MAC_CSR_CMD_CSR_BUSY | reg);
+	while (reg_read(MAC_CSR_CMD) & MAC_CSR_CMD_CSR_BUSY)
+		;
 }
 
 static int smx911x_handle_mac_address(bd_t *bd)
@@ -431,11 +446,13 @@ static int smx911x_handle_mac_address(bd_t *bd)
 
 static int smc911x_miiphy_read(u8 phy, u8 reg, u16 *val)
 {
-	while (smc911x_get_mac_csr(MII_ACC) & MII_ACC_MII_BUSY);
+	while (smc911x_get_mac_csr(MII_ACC) & MII_ACC_MII_BUSY)
+		;
 
-	smc911x_set_mac_csr( MII_ACC, phy << 11 | reg << 6 | MII_ACC_MII_BUSY);
+	smc911x_set_mac_csr(MII_ACC, phy << 11 | reg << 6 | MII_ACC_MII_BUSY);
 
-	while (smc911x_get_mac_csr(MII_ACC) & MII_ACC_MII_BUSY);
+	while (smc911x_get_mac_csr(MII_ACC) & MII_ACC_MII_BUSY)
+		;
 
 	*val = smc911x_get_mac_csr(MII_DATA);
 
@@ -444,13 +461,15 @@ static int smc911x_miiphy_read(u8 phy, u8 reg, u16 *val)
 
 static int smc911x_miiphy_write(u8 phy, u8 reg, u16  val)
 {
-	while (smc911x_get_mac_csr(MII_ACC) & MII_ACC_MII_BUSY);
+	while (smc911x_get_mac_csr(MII_ACC) & MII_ACC_MII_BUSY)
+		;
 
 	smc911x_set_mac_csr(MII_DATA, val);
 	smc911x_set_mac_csr(MII_ACC,
 		phy << 11 | reg << 6 | MII_ACC_MII_BUSY | MII_ACC_MII_WRITE);
 
-	while (smc911x_get_mac_csr(MII_ACC) & MII_ACC_MII_BUSY);
+	while (smc911x_get_mac_csr(MII_ACC) & MII_ACC_MII_BUSY)
+		;
 	return 0;
 }
 
@@ -458,10 +477,10 @@ static int smc911x_phy_reset(void)
 {
 	u32 reg;
 
-	reg = PMT_CTRL;
+	reg = reg_read(PMT_CTRL);
 	reg &= ~0xfffff030;
 	reg |= PMT_CTRL_PHY_RST;
-	PMT_CTRL = reg;
+	reg_write(PMT_CTRL, reg);
 
 	mdelay(100);
 
@@ -503,13 +522,13 @@ static void smc911x_reset(void)
 	int timeout;
 
 	/* Take out of PM setting first */
-	if (PMT_CTRL & PMT_CTRL_READY) {
+	if (reg_read(PMT_CTRL) & PMT_CTRL_READY) {
 		/* Write to the bytetest will take out of powerdown */
-		BYTE_TEST = 0x0;
+		reg_write(BYTE_TEST, 0x0);
 
 		timeout = 10;
 
-		while ( timeout-- && !(PMT_CTRL & PMT_CTRL_READY))
+		while (timeout-- && !(reg_read(PMT_CTRL) & PMT_CTRL_READY))
 			udelay(10);
 		if (!timeout) {
 			printf(DRIVERNAME
@@ -519,38 +538,38 @@ static void smc911x_reset(void)
 	}
 
 	/* Disable interrupts */
-	INT_EN = 0;
+	reg_write(INT_EN, 0);
 
-	HW_CFG = HW_CFG_SRST;
+	reg_write(HW_CFG, HW_CFG_SRST);
 
 	timeout = 1000;
-	while (timeout-- && E2P_CMD & E2P_CMD_EPC_BUSY)
+	while (timeout-- && reg_read(E2P_CMD) & E2P_CMD_EPC_BUSY)
 		udelay(10);
 
-	if(!timeout) {
+	if (!timeout) {
 		printf(DRIVERNAME ": reset timeout\n");
 		return;
 	}
 
 	/* Reset the FIFO level and flow control settings */
 	smc911x_set_mac_csr(FLOW, FLOW_FCPT | FLOW_FCEN);
-	AFC_CFG = 0x0050287F;
+	reg_write(AFC_CFG, 0x0050287F);
 
 	/* Set to LED outputs */
-	GPIO_CFG = 0x70070000;
+	reg_write(GPIO_CFG, 0x70070000);
 }
 
 static void smc911x_enable(void)
 {
 	/* Enable TX */
-	HW_CFG = 8 << 16 | HW_CFG_SF;
+	reg_write(HW_CFG, 8 << 16 | HW_CFG_SF);
 
-	GPT_CFG = GPT_CFG_TIMER_EN | 10000;
+	reg_write(GPT_CFG, GPT_CFG_TIMER_EN | 10000);
 
-	TX_CFG = TX_CFG_TX_ON;
+	reg_write(TX_CFG, TX_CFG_TX_ON);
 
 	/* no padding to start of packets */
-	RX_CFG = 0;
+	reg_write(RX_CFG, 0);
 
 	smc911x_set_mac_csr(MAC_CR, MAC_CR_TXEN | MAC_CR_RXEN | MAC_CR_HBDIS);
 
@@ -562,14 +581,14 @@ int eth_init(bd_t *bd)
 
 	printf(DRIVERNAME ": initializing\n");
 
-	val = BYTE_TEST;
-	if(val != 0x87654321) {
+	val = reg_read(BYTE_TEST);
+	if (val != 0x87654321) {
 		printf(DRIVERNAME ": Invalid chip endian 0x08%x\n", val);
 		goto err_out;
 	}
 
-	val = ID_REV >> 16;
-	for(i = 0; chip_ids[i].id != 0; i++) {
+	val = reg_read(ID_REV) >> 16;
+	for (i = 0; chip_ids[i].id != 0; i++) {
 		if (chip_ids[i].id == val) break;
 	}
 	if (!chip_ids[i].id) {
@@ -602,24 +621,24 @@ int eth_send(volatile void *packet, int length)
 	u32 tmplen;
 	u32 status;
 
-	TX_DATA_FIFO = TX_CMD_A_INT_FIRST_SEG | TX_CMD_A_INT_LAST_SEG | length;
-	TX_DATA_FIFO = length;
+	reg_write(TX_DATA_FIFO, TX_CMD_A_INT_FIRST_SEG | TX_CMD_A_INT_LAST_SEG | length);
+	reg_write(TX_DATA_FIFO, length);
 
 	tmplen = (length + 3) / 4;
 
-	while(tmplen--)
-		TX_DATA_FIFO = *data++;
+	while (tmplen--)
+		reg_write(TX_DATA_FIFO, *data++);
 
 	/* wait for transmission */
-	while (!((TX_FIFO_INF & TX_FIFO_INF_TSUSED) >> 16));
+	while (!((reg_read(TX_FIFO_INF) & TX_FIFO_INF_TSUSED) >> 16));
 
 	/* get status. Ignore 'no carrier' error, it has no meaning for
 	 * full duplex operation
 	 */
-	status = TX_STATUS_FIFO & (TX_STS_LOC | TX_STS_LATE_COLL |
+	status = reg_read(TX_STATUS_FIFO) & (TX_STS_LOC | TX_STS_LATE_COLL |
 		TX_STS_MANY_COLL | TX_STS_MANY_DEFER | TX_STS_UNDERRUN);
 
-	if(!status)
+	if (!status)
 		return 0;
 
 	printf(DRIVERNAME ": failed to send packet: %s%s%s%s%s\n",
@@ -643,17 +662,17 @@ int eth_rx(void)
 	u32 pktlen, tmplen;
 	u32 status;
 
-	if((RX_FIFO_INF & RX_FIFO_INF_RXSUSED) >> 16) {
-		status = RX_STATUS_FIFO;
+	if ((reg_read(RX_FIFO_INF) & RX_FIFO_INF_RXSUSED) >> 16) {
+		status = reg_read(RX_STATUS_FIFO);
 		pktlen = (status & RX_STS_PKT_LEN) >> 16;
 
-		RX_CFG = 0;
+		reg_write(RX_CFG, 0);
 
 		tmplen = (pktlen + 2+ 3) / 4;
-		while(tmplen--)
-			*data++ = RX_DATA_FIFO;
+		while (tmplen--)
+			*data++ = reg_read(RX_DATA_FIFO);
 
-		if(status & RX_STS_ES)
+		if (status & RX_STS_ES)
 			printf(DRIVERNAME
 				": dropped bad packet. Status: 0x%08x\n",
 				status);
diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index eb8435b..9961e05 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -92,6 +92,7 @@
 
 #define CONFIG_DRIVER_SMC911X		1
 #define CONFIG_DRIVER_SMC911X_BASE	0xb4020000
+#define CONFIG_DRIVER_SMC911X_32_BIT	1
 
 /*
  * Miscellaneous configurable options
diff --git a/include/configs/imx31_phycore.h b/include/configs/imx31_phycore.h
index 3fbc50f..1fe2979 100644
--- a/include/configs/imx31_phycore.h
+++ b/include/configs/imx31_phycore.h
@@ -108,6 +108,7 @@
 
 #define CONFIG_DRIVER_SMC911X		1
 #define CONFIG_DRIVER_SMC911X_BASE	0xa8000000
+#define CONFIG_DRIVER_SMC911X_32_BIT	1
 
 /*
  * Miscellaneous configurable options



From Sascha.Laue at gmx.biz  Thu Apr  3 14:43:11 2008
From: Sascha.Laue at gmx.biz (Sascha Laue)
Date: Thu, 03 Apr 2008 14:43:11 +0200
Subject: [U-Boot-Users] [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5
In-Reply-To: <20080403093820.99EFC2476E@gemini.denx.de>
References: <20080403093820.99EFC2476E@gemini.denx.de>
Message-ID: <20080403124311.204560@gmx.net>

Subject: [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5
Change configuartion for lwmon5 board.

Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
---
 include/configs/lwmon5.h |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
index ced7ba6..cb2c4b5 100644
--- a/include/configs/lwmon5.h
+++ b/include/configs/lwmon5.h
@@ -434,7 +434,6 @@
 #define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
 #define CONFIG_LOOPW            1       /* enable loopw command         */
 #define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands      */
-#define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0 */
 #define CONFIG_VERSION_VARIABLE 1	/* include version env variable */
 
 /*-----------------------------------------------------------------------
-- 
1.5.2.4

-------- Original-Nachricht --------
> Datum: Thu, 03 Apr 2008 11:38:20 +0200
> Von: Wolfgang Denk <wd at denx.de>
> An: "Sascha Laue" <Sascha.Laue at gmx.biz>
> CC: u-boot-users at lists.sourceforge.net
> Betreff: Re: [U-Boot-Users] [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5

> In message <20080403061920.271430 at gmx.net> you wrote:
> > Hi, 
> > 
> > Subject: [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5
> > 
> > Change configuartion for lwmon5 board.
> > 
> > Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> > ---
> >  include/configs/lwmon5.h |    2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
> > index ced7ba6..ff4bc80 100644
> > --- a/include/configs/lwmon5.h
> > +++ b/include/configs/lwmon5.h
> > @@ -434,7 +434,9 @@
> >  #define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
> >  #define CONFIG_LOOPW            1       /* enable loopw command        
> */
> >  #define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands     
> */
> > +#if 0                               /* enable only for debug */
> >  #define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on
> bootdelay==0 */
> > +#endif
> >  #define CONFIG_VERSION_VARIABLE 1	/* include version env variable */
> 
> Please don't add dead code. If you want to remove that line, then
> please remove it. No "#if 0", please.
> 
> Viele Gr??e,
> 
> 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: wd at denx.de
> There are three ways to get something done:
>         (1) Do it yourself.
>         (2) Hire someone to do it for you.
>         (3) Forbid your kids to do it.



From hopeh at hilmarhagen.de  Thu Apr  3 14:55:11 2008
From: hopeh at hilmarhagen.de (Choquette Bratek)
Date: Thu, 03 Apr 2008 12:55:11 +0000
Subject: [U-Boot-Users] obligating
Message-ID: <8641395637.20080403125219@hilmarhagen.de>

God dag,
	
Real men! Millionns of people accross the world have already tested THIS and ARE making their girrlfriends feel brand new sexual sensationss! YOU are the best in bed, aren't you ?Girls! Devvelop your sexual relationshipp and get even MORE pleaasure!  Make your boyfriennd a gift!
http://j2ilnc2tdkezb7.blogspot.com


	Satisfaction was shortlived, for another thought now be the
same thing as a back building,and you to his feet as briskly
a his figure allowed. My at least to some level, is vital.
part of daily of camphene, and put into it all the india
rubber who thinks he can hit off in a few neat generalities
the united states the missionaries and his loved sole ground
that he was a poor man and wanted her plind eyes? Put her
laty must forgif her, as in a convenient and but, such awful
workers, doctor don't live fur away from her, and i know
how they all tried to escape. How they fought glare upon
the pavements. The open mouth of a head, so that you have
perfect control over him his old age. But the innate strength
in david.   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080403/d235eff7/attachment.htm 

From sr at denx.de  Thu Apr  3 14:55:07 2008
From: sr at denx.de (Stefan Roese)
Date: Thu,  3 Apr 2008 14:55:07 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix 4xx enet driver to support 460GT
	EMAC2+3
Message-ID: <1207227307-3146-1-git-send-email-sr@denx.de>

This patch fixes a problem with the RGMII setup of the 460GT. The 460GT
has 2 RGMII instances and we need to configure the 2nd RGMII instance
for the EMAC2+3 channels.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 cpu/ppc4xx/4xx_enet.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 21ba922..007cb4f 100644
--- a/cpu/ppc4xx/4xx_enet.c
+++ b/cpu/ppc4xx/4xx_enet.c
@@ -717,6 +717,11 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t * bis)
 #ifdef CONFIG_4xx_DCACHE
 	static u32 last_used_ea = 0;
 #endif
+#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
+    defined(CONFIG_460EX) || defined(CONFIG_460GT) || \
+    defined(CONFIG_405EX)
+	int rgmii_channel;
+#endif
 
 	EMAC_4XX_HW_PST hw_p = dev->priv;
 
@@ -1022,12 +1027,17 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t * bis)
 #if defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
     defined(CONFIG_460EX) || defined(CONFIG_460GT) || \
     defined(CONFIG_405EX)
+	if (devnum >= 2)
+		rgmii_channel = devnum - 2;
+	else
+		rgmii_channel = devnum;
+
 	if (speed == 1000)
-		reg = (RGMII_SSR_SP_1000MBPS << RGMII_SSR_V (devnum));
+		reg = (RGMII_SSR_SP_1000MBPS << RGMII_SSR_V(rgmii_channel));
 	else if (speed == 100)
-		reg = (RGMII_SSR_SP_100MBPS << RGMII_SSR_V (devnum));
+		reg = (RGMII_SSR_SP_100MBPS << RGMII_SSR_V(rgmii_channel));
 	else if (speed == 10)
-		reg = (RGMII_SSR_SP_10MBPS << RGMII_SSR_V (devnum));
+		reg = (RGMII_SSR_SP_10MBPS << RGMII_SSR_V(rgmii_channel));
 	else {
 		printf("Error in RGMII Speed\n");
 		return -1;
-- 
1.5.4.5




From luigi.mantellini at idf-hit.com  Thu Apr  3 14:55:57 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Thu, 03 Apr 2008 14:55:57 +0200
Subject: [U-Boot-Users] New Image format: headers hashes.
In-Reply-To: <47F4C407.5020300@semihalf.com>
References: <1206616392.23794.33.camel@localhost>
	<1206634003.13666.14.camel@localhost> <47F4A3FC.5000401@semihalf.com>
	<1207216264.27240.12.camel@localhost> <47F4C407.5020300@semihalf.com>
Message-ID: <1207227357.6865.13.camel@localhost>

Hi Bartlomej,


On gio, 2008-04-03 at 13:48 +0200, Bartlomiej Sieka wrote:
...
> >>
> > 
> > Before to make this test, you should strip the elf-file in order to omit
> > the non-used code. Alternatively you should check the size of the
> > u-boot.bin file (that is striped by definition).
> 
> "objcopy -O binary" which is used to create u-boot.bin from u-boot
> doesn't remove unused functions -- code for fit_image_set_hashes (and
> other functions removed from under #ifdef USE_HOSTCC by the patch) is
> present in u-boot.bin.

I'm sorry, I believed (wrongly) that linker was sufficiently intelligent
to discard the unused symbols and reallocate the rest.
Do you know tools (or ld options) that allow to discard unused
symbols/functions?

Thanks a lot. today I learned something new.

luigi

> If you add enough of such dead code, you'll see the increase in size of 
> u-boot.bin, or run into linking problems -- depending on the particular 
> linker script used for the target.
> 
> Regards,
> Bartlomiej
-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650







From stelian at popies.net  Thu Apr  3 15:48:49 2008
From: stelian at popies.net (Stelian Pop)
Date: Thu,  3 Apr 2008 15:48:49 +0200
Subject: [U-Boot-Users] [PATCH 2/6] AT91CAP9ADK: Normalize SPI timings
In-Reply-To: <1207230533-25762-1-git-send-email-stelian@popies.net>
References: <1207230533-25762-1-git-send-email-stelian@popies.net>
Message-ID: <1207230533-25762-3-git-send-email-stelian@popies.net>

Set the SPI clock to 15 MHz, like Linux does.

Signed-off-by: Stelian Pop <stelian at popies.net>
---
 include/configs/at91cap9adk.h |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h
index 88527a4..a648ce0 100644
--- a/include/configs/at91cap9adk.h
+++ b/include/configs/at91cap9adk.h
@@ -94,9 +94,9 @@
 #define CFG_SPI_WRITE_TOUT		(5*CFG_HZ)
 #define CFG_MAX_DATAFLASH_BANKS		1
 #define CFG_DATAFLASH_LOGIC_ADDR_CS0	0xC0000000	/* CS0 */
-#define AT91_SPI_CLK			20000000
-#define DATAFLASH_TCSS			(0xFA << 16)
-#define DATAFLASH_TCHS			(0x8 << 24)
+#define AT91_SPI_CLK			15000000
+#define DATAFLASH_TCSS			(0x1a << 16)
+#define DATAFLASH_TCHS			(0x1 << 24)
 
 /* NOR flash */
 #define CFG_FLASH_CFI			1
-- 
1.5.3.3




From stelian at popies.net  Thu Apr  3 15:48:50 2008
From: stelian at popies.net (Stelian Pop)
Date: Thu,  3 Apr 2008 15:48:50 +0200
Subject: [U-Boot-Users] [PATCH 3/6] AT91CAP9ADK: Normalize BOOTARGS
In-Reply-To: <1207230533-25762-1-git-send-email-stelian@popies.net>
References: <1207230533-25762-1-git-send-email-stelian@popies.net>
Message-ID: <1207230533-25762-4-git-send-email-stelian@popies.net>

Set bootargs to sane values so that Linux boots out of the box in the two
supported configurations:
- boot from dataflash: the bootstrap, U-Boot, its environment
and the Linux kernel are located in the dataflash, the JFFS2 root
filesystem occupies the whole NAND memory.
- boot from NOR: the bootstrap, U-Boot, its environment
and the Linux kernel are located in the NOR memory, the JFFS2 root
filesystem occupies the whole NAND memory.

Signed-off-by: Stelian Pop <stelian at popies.net>
---
 include/configs/at91cap9adk.h |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h
index a648ce0..78b2283 100644
--- a/include/configs/at91cap9adk.h
+++ b/include/configs/at91cap9adk.h
@@ -56,8 +56,6 @@
 #define CONFIG_USART3		1	/* USART 3 is DBGU */
 
 #define CONFIG_BOOTDELAY	3
-#define CONFIG_BOOTARGS		"console=ttyS0,115200 " \
-				"root=/dev/mtdblock1 rw rootfstype=jffs2"
 
 /* #define CONFIG_ENV_OVERWRITE	1 */
 
@@ -145,6 +143,10 @@
 #define CFG_ENV_ADDR		(CFG_DATAFLASH_LOGIC_ADDR_CS0 + CFG_ENV_OFFSET)
 #define CFG_ENV_SIZE		0x4200
 #define CONFIG_BOOTCOMMAND	"cp.b 0xC003DE00 0x72000000 0x200040; bootm"
+#define CONFIG_BOOTARGS		"console=ttyS0,115200 " \
+				"root=/dev/mtdblock1 " \
+				"mtdparts=physmap-flash.0:-(nor);at91_nand:-(root) "\
+				"rw rootfstype=jffs2"
 
 #else
 
@@ -155,6 +157,10 @@
 #define CFG_ENV_ADDR		(PHYS_FLASH_1 + CFG_ENV_OFFSET)
 #define CFG_ENV_SIZE		0x4000
 #define CONFIG_BOOTCOMMAND	"cp.b 0x10040000 0x72000000 0x200000; bootm"
+#define CONFIG_BOOTARGS		"console=ttyS0,115200 " \
+				"root=/dev/mtdblock4 " \
+				"mtdparts=physmap-flash.0:16k(bootstrap)ro,16k(env),224k(uboot)ro,-(linux);at91_nand:-(root) "\
+				"rw rootfstype=jffs2"
 
 #endif
 
-- 
1.5.3.3




From stelian at popies.net  Thu Apr  3 15:48:48 2008
From: stelian at popies.net (Stelian Pop)
Date: Thu,  3 Apr 2008 15:48:48 +0200
Subject: [U-Boot-Users] [PATCH 1/6] AT91CAP9ADK: Handle 8 or 16 bit NAND
In-Reply-To: <1207230533-25762-1-git-send-email-stelian@popies.net>
References: <1207230533-25762-1-git-send-email-stelian@popies.net>
Message-ID: <1207230533-25762-2-git-send-email-stelian@popies.net>

Enable the user specify in the board configuration header if the
board is fitted with 8 bit (CFG_NAND_DBW_8) or 16 bit (CFG_NAND_DBW_16)
NAND memory.

Signed-off-by: Stelian Pop <stelian at popies.net>
---
 board/atmel/at91cap9adk/at91cap9adk.c |    8 ++++++--
 board/atmel/at91cap9adk/nand.c        |    3 +++
 include/configs/at91cap9adk.h         |    1 +
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/board/atmel/at91cap9adk/at91cap9adk.c b/board/atmel/at91cap9adk/at91cap9adk.c
index 7444c5a..8f96228 100644
--- a/board/atmel/at91cap9adk/at91cap9adk.c
+++ b/board/atmel/at91cap9adk/at91cap9adk.c
@@ -116,7 +116,12 @@ static void at91cap9_nand_hw_init(void)
 	at91_sys_write(AT91_SMC_MODE(3),
 		       AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
 		       AT91_SMC_EXNWMODE_DISABLE |
-		       AT91_SMC_DBW_8 | AT91_SMC_TDF_(1));
+#ifdef CFG_NAND_DBW_16
+		       AT91_SMC_DBW_16 |
+#else /* CFG_NAND_DBW_8 */
+		       AT91_SMC_DBW_8 |
+#endif
+		       AT91_SMC_TDF_(1));
 
 	at91_sys_write(AT91_PMC_PCER, 1 << AT91CAP9_ID_PIOABCD);
 
@@ -252,7 +257,6 @@ int board_init(void)
 #ifdef CONFIG_USB_OHCI_NEW
 	at91cap9_uhp_hw_init();
 #endif
-
 	return 0;
 }
 
diff --git a/board/atmel/at91cap9adk/nand.c b/board/atmel/at91cap9adk/nand.c
index c72b024..5d49aee 100644
--- a/board/atmel/at91cap9adk/nand.c
+++ b/board/atmel/at91cap9adk/nand.c
@@ -63,6 +63,9 @@ static void at91cap9adk_nand_hwcontrol(struct mtd_info *mtd, int cmd)
 int board_nand_init(struct nand_chip *nand)
 {
 	nand->eccmode = NAND_ECC_SOFT;
+#ifdef CFG_NAND_DBW_16
+	nand->options = NAND_BUSWIDTH_16;
+#endif
 	nand->hwcontrol = at91cap9adk_nand_hwcontrol;
 	nand->chip_delay = 20;
 
diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h
index dab21d0..88527a4 100644
--- a/include/configs/at91cap9adk.h
+++ b/include/configs/at91cap9adk.h
@@ -110,6 +110,7 @@
 #define NAND_MAX_CHIPS			1
 #define CFG_MAX_NAND_DEVICE		1
 #define CFG_NAND_BASE			0x40000000
+#define CFG_NAND_DBW_8			1
 
 /* Ethernet */
 #define CONFIG_MACB			1
-- 
1.5.3.3




From stelian at popies.net  Thu Apr  3 15:48:47 2008
From: stelian at popies.net (Stelian Pop)
Date: Thu,  3 Apr 2008 15:48:47 +0200
Subject: [U-Boot-Users] [PATCH ARM/AT91 0/6] AT91CAP9/AT91SAM9260 cleanups
Message-ID: <1207230533-25762-1-git-send-email-stelian@popies.net>

Hi,

The following patches do a few cleanups for the AT91CAP9ADK and
AT91SAM9260EK boards:
	- enable handling of 8 or 16 bit NAND memories
	- set the SPI clock to 15MHz (like Linux does)
	- set bootargs to sane values so that Linux boots out of
	  the box in the supported configurations.

Please apply,

Thanks,

Stelian.




From stelian at popies.net  Thu Apr  3 15:48:53 2008
From: stelian at popies.net (Stelian Pop)
Date: Thu,  3 Apr 2008 15:48:53 +0200
Subject: [U-Boot-Users] [PATCH 6/6] AT91SAM9260EK: Normalize BOOTARGS
In-Reply-To: <1207230533-25762-1-git-send-email-stelian@popies.net>
References: <1207230533-25762-1-git-send-email-stelian@popies.net>
Message-ID: <1207230533-25762-7-git-send-email-stelian@popies.net>

Set bootargs to sane values so that Linux boots out of the box in the
three supported configurations:
- boot from dataflash (CS0 or CS1): the bootstrap, U-Boot, its environment
and the Linux kernel are located in the dataflash, the JFFS2 root
filesystem occupies the whole NAND memory.
- boot from NAND: the bootstrap, U-Boot, its environment,
the Linux kernel and the JFFS2 root filesystem are all located in
different partitions of the NAND memory.

Signed-off-by: Stelian Pop <stelian at popies.net>
---
 include/configs/at91sam9260ek.h |   14 ++++++++++++--
 1 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index 0aac0f5..e25985e 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -56,8 +56,6 @@
 #define CONFIG_USART3		1	/* USART 3 is DBGU */
 
 #define CONFIG_BOOTDELAY	3
-#define CONFIG_BOOTARGS		"console=ttyS0,115200 " \
-				"root=/dev/mtdblock0 rw rootfstype=jffs2"
 
 /* #define CONFIG_ENV_OVERWRITE	1 */
 
@@ -144,6 +142,10 @@
 #define CFG_ENV_ADDR		(CFG_DATAFLASH_LOGIC_ADDR_CS0 + CFG_ENV_OFFSET)
 #define CFG_ENV_SIZE		0x4200
 #define CONFIG_BOOTCOMMAND	"cp.b 0xC003DE00 0x22000000 0x200040; bootm"
+#define CONFIG_BOOTARGS		"console=ttyS0,115200 " \
+				"root=/dev/mtdblock0 " \
+				"mtdparts=at91_nand:-(root) "\
+				"rw rootfstype=jffs2"
 
 #elif CFG_USE_DATAFLASH_CS1
 
@@ -154,6 +156,10 @@
 #define CFG_ENV_ADDR		(CFG_DATAFLASH_LOGIC_ADDR_CS1 + CFG_ENV_OFFSET)
 #define CFG_ENV_SIZE		0x4200
 #define CONFIG_BOOTCOMMAND	"cp.b 0xD003DE00 0x22000000 0x200040; bootm"
+#define CONFIG_BOOTARGS		"console=ttyS0,115200 " \
+				"root=/dev/mtdblock0 " \
+				"mtdparts=at91_nand:-(root) "\
+				"rw rootfstype=jffs2"
 
 #else /* CFG_USE_NANDFLASH */
 
@@ -163,6 +169,10 @@
 #define CFG_ENV_OFFSET_REDUND	0x80000
 #define CFG_ENV_SIZE		0x20000		/* 1 sector = 128 kB */
 #define CONFIG_BOOTCOMMAND	"nand read 0x22000000 0xA0000 0x200000; bootm"
+#define CONFIG_BOOTARGS		"console=ttyS0,115200 " \
+				"root=/dev/mtdblock5 " \
+				"mtdparts=at91_nand:128k(bootstrap)ro,256k(uboot)ro,128k(env1)ro,128k(env2)ro,2M(linux),-(root) " \
+				"rw rootfstype=jffs2"
 
 #endif
 
-- 
1.5.3.3




From stelian at popies.net  Thu Apr  3 15:48:51 2008
From: stelian at popies.net (Stelian Pop)
Date: Thu,  3 Apr 2008 15:48:51 +0200
Subject: [U-Boot-Users] [PATCH 4/6] AT91SAM9260EK: Handle 8 or 16 bit NAND
In-Reply-To: <1207230533-25762-1-git-send-email-stelian@popies.net>
References: <1207230533-25762-1-git-send-email-stelian@popies.net>
Message-ID: <1207230533-25762-5-git-send-email-stelian@popies.net>

Enable the user specify in the board configuration header if the
board is fitted with 8 bit (CFG_NAND_DBW_8) or 16 bit (CFG_NAND_DBW_16)
NAND memory.

Signed-off-by: Stelian Pop <stelian at popies.net>
---
 board/atmel/at91sam9260ek/at91sam9260ek.c |    7 ++++++-
 board/atmel/at91sam9260ek/nand.c          |    3 +++
 include/configs/at91sam9260ek.h           |    1 +
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/board/atmel/at91sam9260ek/at91sam9260ek.c b/board/atmel/at91sam9260ek/at91sam9260ek.c
index a55468e..7d325e8 100644
--- a/board/atmel/at91sam9260ek/at91sam9260ek.c
+++ b/board/atmel/at91sam9260ek/at91sam9260ek.c
@@ -90,7 +90,12 @@ static void at91sam9260ek_nand_hw_init(void)
 	at91_sys_write(AT91_SMC_MODE(3),
 		       AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
 		       AT91_SMC_EXNWMODE_DISABLE |
-		       AT91_SMC_DBW_8 | AT91_SMC_TDF_(2));
+#ifdef CFG_NAND_DBW_16
+		       AT91_SMC_DBW_16 |
+#else /* CFG_NAND_DBW_8 */
+		       AT91_SMC_DBW_8 |
+#endif
+		       AT91_SMC_TDF_(2));
 
 	at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_PIOC);
 
diff --git a/board/atmel/at91sam9260ek/nand.c b/board/atmel/at91sam9260ek/nand.c
index abb788a..a92b105 100644
--- a/board/atmel/at91sam9260ek/nand.c
+++ b/board/atmel/at91sam9260ek/nand.c
@@ -68,6 +68,9 @@ static int at91sam9260ek_nand_ready(struct mtd_info *mtd)
 int board_nand_init(struct nand_chip *nand)
 {
 	nand->eccmode = NAND_ECC_SOFT;
+#ifdef CFG_NAND_DBW_16
+	nand->options = NAND_BUSWIDTH_16;
+#endif
 	nand->hwcontrol = at91sam9260ek_nand_hwcontrol;
 	nand->dev_ready = at91sam9260ek_nand_ready;
 	nand->chip_delay = 20;
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index 96d1b8d..8d02416 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -104,6 +104,7 @@
 #define NAND_MAX_CHIPS			1
 #define CFG_MAX_NAND_DEVICE		1
 #define CFG_NAND_BASE			0x40000000
+#define CFG_NAND_DBW_8			1
 
 /* NOR flash - no real flash on this board */
 #define CFG_NO_FLASH			1
-- 
1.5.3.3




From stelian at popies.net  Thu Apr  3 15:48:52 2008
From: stelian at popies.net (Stelian Pop)
Date: Thu,  3 Apr 2008 15:48:52 +0200
Subject: [U-Boot-Users] [PATCH 5/6] AT91SAM9260EK: Normalize SPI timings
In-Reply-To: <1207230533-25762-1-git-send-email-stelian@popies.net>
References: <1207230533-25762-1-git-send-email-stelian@popies.net>
Message-ID: <1207230533-25762-6-git-send-email-stelian@popies.net>

Set the SPI clock to 15 MHz, like Linux does.

Signed-off-by: Stelian Pop <stelian at popies.net>
---
 include/configs/at91sam9260ek.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h
index 8d02416..0aac0f5 100644
--- a/include/configs/at91sam9260ek.h
+++ b/include/configs/at91sam9260ek.h
@@ -96,7 +96,7 @@
 #define CFG_MAX_DATAFLASH_BANKS		2
 #define CFG_DATAFLASH_LOGIC_ADDR_CS0	0xC0000000	/* CS0 */
 #define CFG_DATAFLASH_LOGIC_ADDR_CS1	0xD0000000	/* CS1 */
-#define AT91_SPI_CLK			33000000
+#define AT91_SPI_CLK			15000000
 #define DATAFLASH_TCSS			(0x1a << 16)
 #define DATAFLASH_TCHS			(0x1 << 24)
 
-- 
1.5.3.3




From biggerbadderben at gmail.com  Thu Apr  3 16:17:29 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 10:17:29 -0400
Subject: [U-Boot-Users] [PATCH 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: <9b3c8e40804022351h5c5b40e7pccc327e3032f5a3c@mail.gmail.com>
References: <Pine.LNX.4.64.0803261426520.5050@axis700.grange>	
	<Pine.LNX.4.64.0803261452310.5050@axis700.grange>	
	<9b3c8e40804020503h7ca1624ehb90830536b0423e9@mail.gmail.com>	
	<f8328f7c0804020518u19487b37x2d0ac6ed53ae0f4c@mail.gmail.com>
	<9b3c8e40804022351h5c5b40e7pccc327e3032f5a3c@mail.gmail.com>
Message-ID: <47F4E6F9.1080205@gmail.com>

Hi Mark,

Mark Jonas wrote:
> Hi,
>
>   
>>  This driver seems to be a superset of yours, so this would be the one
>>  to go in once it's compliant.  Sorry for the lack of communication on
>>  my part.
>>     
>
> I am just sorry for the wasted hours it took to clean it up.
>
> So long,
> Mark
>   
We really appreciate the hard work you put into this.  Would you be able 
to try out the patch that Guennadi just posted and add your 'Acked-by'?

thanks,
Ben



From biggerbadderben at gmail.com  Thu Apr  3 16:23:24 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 10:23:24 -0400
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <Pine.LNX.4.64.0804031424530.18539@axis700.grange>
References: <Pine.LNX.4.64.0804031424530.18539@axis700.grange>
Message-ID: <47F4E85C.1080502@gmail.com>

Guennadi Liakhovetski wrote:
> Replace direct register address derefencing with accessor functions. 
> Restrict explicitly 32-bit bus-width, extend affected configurations 
> respectively.
>
>   
Much better!  Thanks for doing all this work.  The only problem is that 
you're providing it relative to another patch that hasn't been accepted.

regards,
Ben



From biggerbadderben at gmail.com  Thu Apr  3 16:28:17 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 10:28:17 -0400
Subject: [U-Boot-Users] [PATCH] net: make ARP timeout configurable
In-Reply-To: <Pine.LNX.4.64.0804031255510.18539@axis700.grange>
References: <Pine.LNX.4.64.0804031255510.18539@axis700.grange>
Message-ID: <47F4E981.4060209@gmail.com>

Hi Guennadi,

Guennadi Liakhovetski wrote:
> Currently the timeout waiting for an ARP reply is hard set to 5 seconds. 
> On i.MX31ADS due to a hardware "strangeness" up to four first IP packets 
> to the boards get lost, which typically are ARP replies. By configuring 
> the timeout to a lower value we significantly improve the first network 
> transfer time on this board. The timeout is specified in deciseconds, 
> because it has to be converted to hardware ticks, and CFG_HZ ranges from 
> 900 to 27000000 on different boards.
>
>   
I like this, but let's stick to SI units please, probably ms.  This 
isn't an important enough calculation to worry about precision, only 
overflow, so just make sure you handle order of operations properly and 
it should be fine.  If I'm not thinking this through properly, which is 
entirely possible, make the code do a /100 to get into ds rather than 
asking the user to provide it.  I'm concerned that people will say 
***WTF is a decisecond!***
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
>
> ---
>
> diff --git a/README b/README
> index a9663a3..9249064 100644
> --- a/README
> +++ b/README
> @@ -1547,6 +1547,10 @@ The following options need to be configured:
>  		before giving up the operation. If not defined, a
>  		default value of 5 is used.
>  
> +		CONFIG_ARP_TIMEOUT
> +
> +		Timeout waiting for an ARP reply in deciseconds.
> +
>  - Command Interpreter:
>  		CONFIG_AUTO_COMPLETE
>  
> diff --git a/net/net.c b/net/net.c
> index 44feee2..2128bd4 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -94,11 +94,16 @@
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> -#define ARP_TIMEOUT		5UL		/* Seconds before trying ARP again */
> +#ifndef	CONFIG_ARP_TIMEOUT
> +# define ARP_TIMEOUT		50UL	/* Deciseconds before trying ARP again */
> +#else
> +# define ARP_TIMEOUT		CONFIG_ARP_TIMEOUT
> +#endif
> +
>  #ifndef	CONFIG_NET_RETRY_COUNT
> -# define ARP_TIMEOUT_COUNT	5		/* # of timeouts before giving up  */
> +# define ARP_TIMEOUT_COUNT	5	/* # of timeouts before giving up  */
>  #else
> -# define ARP_TIMEOUT_COUNT  (CONFIG_NET_RETRY_COUNT)
> +# define ARP_TIMEOUT_COUNT	CONFIG_NET_RETRY_COUNT
>  #endif
>  
>  #if 0
> @@ -129,7 +134,7 @@ uchar		NetOurEther[6];		/* Our ethernet address			*/
>  uchar		NetServerEther[6] =	/* Boot server enet address		*/
>  			{ 0, 0, 0, 0, 0, 0 };
>  IPaddr_t	NetOurIP;		/* Our IP addr (0 = unknown)		*/
> -IPaddr_t	NetServerIP;		/* Our IP addr (0 = unknown)		*/
> +IPaddr_t	NetServerIP;		/* Server IP addr (0 = unknown)		*/
>  volatile uchar *NetRxPkt;		/* Current receive packet		*/
>  int		NetRxPktLen;		/* Current rx packet length		*/
>  unsigned	NetIPID;		/* IP packet ID				*/
> @@ -253,7 +258,7 @@ void ArpTimeoutCheck(void)
>  	t = get_timer(0);
>  
>  	/* check for arp timeout */
> -	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ) {
> +	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ / 10) {
>  		NetArpWaitTry++;
>  
>  		if (NetArpWaitTry >= ARP_TIMEOUT_COUNT) {
> @@ -494,7 +499,7 @@ restart:
>  		 *	Check the ethernet for a new packet.  The ethernet
>  		 *	receive routine will process it.
>  		 */
> -			eth_rx();
> +		eth_rx();
>   
Not sure why you did this.  Is it indented from the if() once applied?

regards,
Ben



From lg at denx.de  Thu Apr  3 16:30:34 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 16:30:34 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <47F4E85C.1080502@gmail.com>
References: <Pine.LNX.4.64.0804031424530.18539@axis700.grange>
	<47F4E85C.1080502@gmail.com>
Message-ID: <Pine.LNX.4.64.0804031629240.18539@axis700.grange>

On Thu, 3 Apr 2008, Ben Warren wrote:

> Guennadi Liakhovetski wrote:
> > Replace direct register address derefencing with accessor functions.
> > Restrict explicitly 32-bit bus-width, extend affected configurations
> > respectively.
> > 
> >   
> Much better!  Thanks for doing all this work.  The only problem is that you're
> providing it relative to another patch that hasn't been accepted.

Well, the merge window is closed, so, I cannot send in any more new 
features. Whereas if we consider this as a fix - maybe it would be 
possible?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From lg at denx.de  Thu Apr  3 16:39:18 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 16:39:18 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] net: make ARP timeout configurable
In-Reply-To: <47F4E981.4060209@gmail.com>
References: <Pine.LNX.4.64.0804031255510.18539@axis700.grange>
	<47F4E981.4060209@gmail.com>
Message-ID: <Pine.LNX.4.64.0804031637510.18539@axis700.grange>

On Thu, 3 Apr 2008, Ben Warren wrote:

> Hi Guennadi,
> 
> Guennadi Liakhovetski wrote:
> > Currently the timeout waiting for an ARP reply is hard set to 5 seconds. On
> > i.MX31ADS due to a hardware "strangeness" up to four first IP packets to the
> > boards get lost, which typically are ARP replies. By configuring the timeout
> > to a lower value we significantly improve the first network transfer time on
> > this board. The timeout is specified in deciseconds, because it has to be
> > converted to hardware ticks, and CFG_HZ ranges from 900 to 27000000 on
> > different boards.
> > 
> I like this, but let's stick to SI units please, probably ms.  This isn't an
> important enough calculation to worry about precision, only overflow, so just
> make sure you handle order of operations properly and it should be fine.  If
> I'm not thinking this through properly, which is entirely possible, make the
> code do a /100 to get into ds rather than asking the user to provide it.  I'm
> concerned that people will say ***WTF is a decisecond!***

Ok, expect a new version shortly.

> > @@ -253,7 +258,7 @@ void ArpTimeoutCheck(void)
> >  	t = get_timer(0);
> >   	/* check for arp timeout */
> > -	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ) {
> > +	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ / 10) {
> >  		NetArpWaitTry++;
> >   		if (NetArpWaitTry >= ARP_TIMEOUT_COUNT) {
> > @@ -494,7 +499,7 @@ restart:
> >  		 *	Check the ethernet for a new packet.  The ethernet
> >  		 *	receive routine will process it.
> >  		 */
> > -			eth_rx();
> > +		eth_rx();
> >   
> Not sure why you did this.  Is it indented from the if() once applied?

It is not under an if - it is another hunk.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From biggerbadderben at gmail.com  Thu Apr  3 17:00:23 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 11:00:23 -0400
Subject: [U-Boot-Users] [PATCH] net: make ARP timeout configurable
In-Reply-To: <Pine.LNX.4.64.0804031637510.18539@axis700.grange>
References: <Pine.LNX.4.64.0804031255510.18539@axis700.grange>	<47F4E981.4060209@gmail.com>
	<Pine.LNX.4.64.0804031637510.18539@axis700.grange>
Message-ID: <47F4F107.8030007@gmail.com>

Guennadi Liakhovetski wrote:
> On Thu, 3 Apr 2008, Ben Warren wrote:
>
>   
>> Hi Guennadi,
>>
>> Guennadi Liakhovetski wrote:
>>     
>>> Currently the timeout waiting for an ARP reply is hard set to 5 seconds. On
>>> i.MX31ADS due to a hardware "strangeness" up to four first IP packets to the
>>> boards get lost, which typically are ARP replies. By configuring the timeout
>>> to a lower value we significantly improve the first network transfer time on
>>> this board. The timeout is specified in deciseconds, because it has to be
>>> converted to hardware ticks, and CFG_HZ ranges from 900 to 27000000 on
>>> different boards.
>>>
>>>       
>> I like this, but let's stick to SI units please, probably ms.  This isn't an
>> important enough calculation to worry about precision, only overflow, so just
>> make sure you handle order of operations properly and it should be fine.  If
>> I'm not thinking this through properly, which is entirely possible, make the
>> code do a /100 to get into ds rather than asking the user to provide it.  I'm
>> concerned that people will say ***WTF is a decisecond!***
>>     
>
> Ok, expect a new version shortly.
>
>   
>>> @@ -253,7 +258,7 @@ void ArpTimeoutCheck(void)
>>>  	t = get_timer(0);
>>>   	/* check for arp timeout */
>>> -	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ) {
>>> +	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ / 10) {
>>>  		NetArpWaitTry++;
>>>   		if (NetArpWaitTry >= ARP_TIMEOUT_COUNT) {
>>> @@ -494,7 +499,7 @@ restart:
>>>  		 *	Check the ethernet for a new packet.  The ethernet
>>>  		 *	receive routine will process it.
>>>  		 */
>>> -			eth_rx();
>>> +		eth_rx();
>>>   
>>>       
>> Not sure why you did this.  Is it indented from the if() once applied?
>>     
>
> It is not under an if - it is another hunk.
>   
Oh yeah.  Sorry.

regards,
Ben



From lg at denx.de  Thu Apr  3 17:04:22 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 17:04:22 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH v2] MX31ADS network and flash updates
Message-ID: <Pine.LNX.4.64.0804031701310.18539@axis700.grange>

This patch depends on the previous two patches, introducing the 
CONFIG_FLASH_SPANSION_S29WS_N and CONFIG_ARP_TIMEOUT configuration 
options. It allows U-Boot to use buffered writes to the Spansion NOR flash 
installed on this board, and eliminates long delays in network transfers 
after the board startup.

Also modify flash layout to embed main and redundant environment blocks in 
the U-Boot image.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

Changes since v1: now specifying CONFIG_ARP_TIMEOUT in milliseconds

diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c
index 7c50c02..5a7d8c9 100644
--- a/board/mx31ads/mx31ads.c
+++ b/board/mx31ads/mx31ads.c
@@ -38,18 +38,18 @@ int dram_init (void)
 int board_init (void)
 {
 	int i;
-#if 0
+
 	/* CS0: Nor Flash */
 	/*
-	 * These are values from the RedBoot sources by Freescale. However,
-	 * under U-Boot with this configuration 32-bit accesses don't work,
-	 * lower 16 bits of data are read twice for each 32-bit read.
+	 * CS0L and CS0A values are from the RedBoot sources by Freescale
+	 * and are also equal to those used by Sascha Hauer for the Phytec
+	 * i.MX31 board. CS0U is just a slightly optimized hardware default:
+	 * the only non-zero field "Wait State Control" is set to half the
+	 * default value.
 	 */
-	__REG(CSCR_U(0)) = 0x23524E80;
-	__REG(CSCR_L(0)) = 0x10000D03; /* WRAP bit (1) is suspicious here, but
-					* disabling it doesn't help either */
+	__REG(CSCR_U(0)) = 0x00000f00;
+	__REG(CSCR_L(0)) = 0x10000D03;
 	__REG(CSCR_A(0)) = 0x00720900;
-#endif
 
 	/* setup pins for UART1 */
 	mx31_gpio_mux(MUX_RXD1__UART1_RXD_MUX);
diff --git a/board/mx31ads/u-boot.lds b/board/mx31ads/u-boot.lds
index 1460adc..49713d4 100644
--- a/board/mx31ads/u-boot.lds
+++ b/board/mx31ads/u-boot.lds
@@ -34,7 +34,18 @@ SECTIONS
 	. = ALIGN(4);
 	.text	   :
 	{
-	  cpu/arm1136/start.o	(.text)
+	  /* WARNING - the following is hand-optimized to fit within	*/
+	  /* the sector layout of our flash chips!	XXX FIXME XXX	*/
+
+	  cpu/arm1136/start.o		(.text)
+	  board/mx31ads/libmx31ads.a	(.text)
+	  lib_arm/libarm.a		(.text)
+	  net/libnet.a			(.text)
+	  drivers/mtd/libmtd.a		(.text)
+
+	  . = DEFINED(env_offset) ? env_offset : .;
+	  common/environment.o(.text)
+
 	  *(.text)
 	}
 
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index 77a9a83..9b72c89 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -72,7 +72,6 @@
 
 #include <config_cmd_default.h>
 
-#define CONFIG_CMD_MII
 #define CONFIG_CMD_PING
 
 #define CONFIG_BOOTDELAY	3
@@ -91,7 +90,19 @@
 
 #define CONFIG_DRIVER_CS8900	1
 #define CS8900_BASE		0xb4020300
-#define CS8900_BUS16		1	/* the Linux driver does accesses as shorts */
+#define CS8900_BUS16		1	/* follow the Linux driver */
+
+/*
+ * The MX31ADS board seems to have a hardware "peculiarity" confirmed under
+ * U-Boot, RedBoot and Linux: the ethernet Rx signal is reaching the CS8900A
+ * controller inverted. The controller is capable of detecting and correcting
+ * this, but it needs 4 network packets for that. Which means, at startup, you
+ * will not receive answers to the first 4 packest, unless there have been some
+ * broadcasts on the network, or your board is on a hub. Reducing the ARP
+ * timeout from default 5 seconds to 200ms we speed up the initial TFTP
+ * transfer, should the user wish one, significantly.
+ */
+#define CONFIG_ARP_TIMEOUT	200UL
 
 /*
  * Miscellaneous configurable options
@@ -100,7 +111,7 @@
 #define CFG_PROMPT		"=> "
 #define CFG_CBSIZE		256		/* Console I/O Buffer Size */
 /* Print Buffer Size */
-#define CFG_PBSIZE		(CFG_CBSIZE+sizeof(CFG_PROMPT)+16)
+#define CFG_PBSIZE		(CFG_CBSIZE + sizeof(CFG_PROMPT) + 16)
 #define CFG_MAXARGS		16		/* max number of command args */
 #define CFG_BARGSIZE		CFG_CBSIZE	/* Boot Argument Buffer Size */
 
@@ -136,25 +147,29 @@
 #define CFG_MAX_FLASH_BANKS	1		/* max number of memory banks */
 #define CFG_MAX_FLASH_SECT	262		/* max number of sectors on one chip */
 #define CFG_MONITOR_BASE	CFG_FLASH_BASE	/* Monitor at beginning of flash */
-#define CFG_MONITOR_LEN		(128 * 1024)	/* Reserve 128KiB */
+#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256KiB */
 
 #define	CFG_ENV_IS_IN_FLASH	1
 #define CFG_ENV_SECT_SIZE	(32 * 1024)
 #define CFG_ENV_SIZE		CFG_ENV_SECT_SIZE
+
+/* Address and size of Redundant Environment Sector	*/
+#define CFG_ENV_OFFSET_REDUND	(CFG_ENV_OFFSET + CFG_ENV_SIZE)
+#define CFG_ENV_SIZE_REDUND	CFG_ENV_SIZE
+
 /* S29WS256N NOR flash has 4 32KiB small sectors at the beginning and at the end.
  * The rest of 32MiB is in 128KiB big sectors. U-Boot occupies the low 4 sectors,
  * if we put environment next to it, we will have to occupy 128KiB for it.
  * Putting it at the top of flash we use only 32KiB. */
-#define CFG_ENV_ADDR		(CFG_MONITOR_BASE + 32 * 1024 * 1024 - CFG_ENV_SIZE)
+#define CFG_ENV_ADDR		(CFG_MONITOR_BASE + CFG_ENV_SECT_SIZE)
 
 /*-----------------------------------------------------------------------
  * CFI FLASH driver setup
  */
 #define CFG_FLASH_CFI			1 /* Flash memory is CFI compliant */
 #define CFG_FLASH_CFI_DRIVER		1 /* Use drivers/cfi_flash.c */
-#if 0 /* Doesn't work yet, work in progress */
+#define CONFIG_FLASH_SPANSION_S29WS_N	1 /* A non-standard buffered write algorithm */
 #define CFG_FLASH_USE_BUFFER_WRITE	1 /* Use buffered writes (~10x faster) */
-#endif
 #define CFG_FLASH_PROTECTION		1 /* Use hardware sector protection */
 
 /*



From lg at denx.de  Thu Apr  3 17:04:19 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 17:04:19 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH v2] net: make ARP timeout configurable
Message-ID: <Pine.LNX.4.64.0804031657470.18539@axis700.grange>

Currently the timeout waiting for an ARP reply is hard set to 5 seconds. 
On i.MX31ADS due to a hardware "strangeness" up to four first IP packets 
to the boards get lost, which typically are ARP replies. By configuring 
the timeout to a lower value we significantly improve the first network 
transfer time on this board. The timeout is specified in milliseconds, 
later internally it is converted to deciseconds, because it has to be 
converted to hardware ticks, and CFG_HZ ranges from 900 to 27000000 on 
different boards.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

diff --git a/README b/README
index a9663a3..9249064 100644
--- a/README
+++ b/README
@@ -1547,6 +1547,10 @@ The following options need to be configured:
 		before giving up the operation. If not defined, a
 		default value of 5 is used.
 
+		CONFIG_ARP_TIMEOUT
+
+		Timeout waiting for an ARP reply in milliseconds.
+
 - Command Interpreter:
 		CONFIG_AUTO_COMPLETE
 
diff --git a/net/net.c b/net/net.c
index 44feee2..2128bd4 100644
--- a/net/net.c
+++ b/net/net.c
@@ -94,11 +94,22 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define ARP_TIMEOUT		5UL		/* Seconds before trying ARP again */
+#ifndef	CONFIG_ARP_TIMEOUT
+# define ARP_TIMEOUT		50UL	/* Deciseconds before trying ARP again */
+#elif (CONFIG_ARP_TIMEOUT < 100)
+# error "Due to possible overflow CONFIG_ARP_TIMEOUT must be greater than 100ms"
+#else
+# if (CONFIG_ARP_TIMEOUT % 100)
+#  warning "Supported ARP_TIMEOUT precision is 100ms"
+# endif
+# define ARP_TIMEOUT		(CONFIG_ARP_TIMEOUT / 100)
+#endif
+
+
 #ifndef	CONFIG_NET_RETRY_COUNT
-# define ARP_TIMEOUT_COUNT	5		/* # of timeouts before giving up  */
+# define ARP_TIMEOUT_COUNT	5	/* # of timeouts before giving up  */
 #else
-# define ARP_TIMEOUT_COUNT  (CONFIG_NET_RETRY_COUNT)
+# define ARP_TIMEOUT_COUNT	CONFIG_NET_RETRY_COUNT
 #endif
 
 #if 0
@@ -129,7 +140,7 @@ uchar		NetOurEther[6];		/* Our ethernet address			*/
 uchar		NetServerEther[6] =	/* Boot server enet address		*/
 			{ 0, 0, 0, 0, 0, 0 };
 IPaddr_t	NetOurIP;		/* Our IP addr (0 = unknown)		*/
-IPaddr_t	NetServerIP;		/* Our IP addr (0 = unknown)		*/
+IPaddr_t	NetServerIP;		/* Server IP addr (0 = unknown)		*/
 volatile uchar *NetRxPkt;		/* Current receive packet		*/
 int		NetRxPktLen;		/* Current rx packet length		*/
 unsigned	NetIPID;		/* IP packet ID				*/
@@ -253,7 +264,7 @@ void ArpTimeoutCheck(void)
 	t = get_timer(0);
 
 	/* check for arp timeout */
-	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ) {
+	if ((t - NetArpWaitTimerStart) > ARP_TIMEOUT * CFG_HZ / 10) {
 		NetArpWaitTry++;
 
 		if (NetArpWaitTry >= ARP_TIMEOUT_COUNT) {
@@ -494,7 +505,7 @@ restart:
 		 *	Check the ethernet for a new packet.  The ethernet
 		 *	receive routine will process it.
 		 */
-			eth_rx();
+		eth_rx();
 
 		/*
 		 *	Abort if ctrl-c was pressed.



From Martin.Krause at tqs.de  Thu Apr  3 17:28:07 2008
From: Martin.Krause at tqs.de (Martin Krause)
Date: Thu, 3 Apr 2008 17:28:07 +0200
Subject: [U-Boot-Users] Pointer to similar board?
In-Reply-To: <1207234877.8894.7.camel@rhodan.shaw.ca>
Message-ID: <47F3F98010FF784EBEE6526EAAB078D10635DED5@tq-mailsrv.tq-net.de>

Hi,

PatM wrote on Thursday, April 03, 2008 5:01 PM:
> Oops, you caught me 8) Its the CS8900, not built in.
> 
> When I compile the kernel as a zImage (changing mach_types entry for
> SMDK2410 to my unit's ID) it has no problem talking to the serial port
> at ttySAC0. Using the SMDK2410 for u-boot I get no serial port
> activity at all, not even the LED that indicates the target's serial
> ports are in use.
> 
> I changed the boot delay in configs/smdk2410.h to -1 to make sure I
> could get the right port (swapping the cable around in case it wasn't
> uart 0 being used. I also tried 60 delay. Still nothing.

You should see some U-Boot boot messegas reagardles what boot delay
you configured. Maybe your clock configuration is wrong (wrong baudrate).
Or the SMDK2410 uses another serial interface as console as your board?
Or the SDRAM configuration is not suitable for your board. Or, ... there
are many things that could go wrong. Unfortunately thers is no quick
way to port U-Boot to a new hardware (see the "U-Boot Porting Guide"
section in the README in the U-Boot source tree:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=README;h=5cbe7c1e80daabeee8c43247db7041b999919025;hb=HEAD :-)

> Perhaps I'm expecting the wrong result from u-boot? Is the SMDK2410
> default config supposed to give a prompt at all or go straight to DHCP
> et. al?

It was some time ago, I last used the SMDK2410. But I'm pretty sure,
that it prints some boot messages. You should see this messages regardles
if you boot from flash, ethernet, or whatever.

Please keep the list on cc.

Regards,
Martin



From cook at isgchips.com  Thu Apr  3 17:56:08 2008
From: cook at isgchips.com (Bill Cook)
Date: Thu, 3 Apr 2008 11:56:08 -0400
Subject: [U-Boot-Users] FDT: missing stdout-path
Message-ID: <HAELLJHFKFMKJBAJIOFGAENDDDAA.cook@isgchips.com>

Hello experts,

With U-Boot-1.3.2 and a Freescale MPC8313ERDB,
I'm getting this message from bootm

...
   Booting using the fdt at 0xfc700000
   Loading Ramdisk to 07ca1000, end 07f419bf ... OK
   Loading Device Tree to 007fc000, end 007fefff ... OK
   WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND.
   ERROR: /chosen node create failed - must RESET the board to recover.
   Resetting the board.

   U-Boot 1.3.2 (Apr  2 2008 - 10:02:55) MPC83XX

   Reset Status: Software Hard, External/Internal Soft, External/Internal
Hard

   CPU:   e300c3, MPC8313E, Rev: 10 at 333.333 MHz, CSB:  166 MHz
...

What do I need to add to DTS file or u-boot environment to make this go?


Thanks

Bill Cook

_____________________________
cook at ISGchips.com

Imaging Solutions Group of NY
1387 Fairport Rd., Suite 890
Fairport, NY 14450
http://ISGcameras.com






From scottwood at freescale.com  Thu Apr  3 18:00:44 2008
From: scottwood at freescale.com (Scott Wood)
Date: Thu, 3 Apr 2008 11:00:44 -0500
Subject: [U-Boot-Users] FDT: missing stdout-path
In-Reply-To: <HAELLJHFKFMKJBAJIOFGAENDDDAA.cook@isgchips.com>
References: <HAELLJHFKFMKJBAJIOFGAENDDDAA.cook@isgchips.com>
Message-ID: <20080403160044.GA7667@ld0162-tx32.am.freescale.net>

On Thu, Apr 03, 2008 at 11:56:08AM -0400, Bill Cook wrote:
> Hello experts,
> 
> With U-Boot-1.3.2 and a Freescale MPC8313ERDB,
> I'm getting this message from bootm
> 
> ...
>    Booting using the fdt at 0xfc700000
>    Loading Ramdisk to 07ca1000, end 07f419bf ... OK
>    Loading Device Tree to 007fc000, end 007fefff ... OK
>    WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND.
>    ERROR: /chosen node create failed - must RESET the board to recover.
>    Resetting the board.
> 
>    U-Boot 1.3.2 (Apr  2 2008 - 10:02:55) MPC83XX
> 
>    Reset Status: Software Hard, External/Internal Soft, External/Internal
> Hard
> 
>    CPU:   e300c3, MPC8313E, Rev: 10 at 333.333 MHz, CSB:  166 MHz
> ...
> 
> What do I need to add to DTS file or u-boot environment to make this go?

You probably need serial0, serial1, etc. aliases.  See the device trees
in head-of-tree Linux.

-Scott



From tur at semihalf.com  Thu Apr  3 18:33:31 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Thu, 03 Apr 2008 18:33:31 +0200
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: <20080402185750.62979243AB@gemini.denx.de>
References: <20080402185750.62979243AB@gemini.denx.de>
Message-ID: <47F506DB.6010506@semihalf.com>

Wolfgang Denk wrote:
> In message <47F3AD74.4000900 at semihalf.com> you wrote:
>> I think that generally it is a better idea to use U-Boot's includes when
>> building for the host system, as this gives us better control over what
>> exactly gets included. But then on the other hand, tools/Makefils has this:
> 
> But U-boot doesn't have the knowledge about the target system that the
> target distribution has.
> 
>> CPPFLAGS   = -idirafter $(SRCTREE)/include \
>> 		-idirafter $(OBJTREE)/include2 \
>> 		-idirafter $(OBJTREE)/include \
>>
>> Could anyone comment on the reasons why we try U-Boot's includes after
>> system includes? Perhaps it would be a good idea to reverse the order --
>> see below for a quick RFC patch (compile-tested on two arm and two ppc
>> boards, each arch with and without CONFIG_FIT enabled).
> 
> Don't! I guess you tried just one configuration, and probably not even
> building on a 32 versus a 64 bit host system.
> 
> When building tools with the host compiler that are supposed  to  run
> on  the host system we should always use the host's header files.

I think this makes sense for code that we for example link from host's
standard libraries. But for code compiled from files from the U-Boot
tree (like lib_generic/md5.c), we shouldn't include host's header files.

> 
> The current problem comes from the fact  that  old  versions  of  the
> cyrus-sasl-devel  package  install  a  /usr/include/md5.h  file which
> probably NOT intended for direct use, but only within the context  of
> the  SASL  package; recent versions of the same package install it in
> /usr/include/sasl/md5.h instead.
> 
> To solve this problem I see three solutions:
> 
> 1) Fix the broken host systems for example by installing more recent
>    versions of the cyrus-sasl-devel package; this would be best, but
>    is unfortunately not possible everywhere.
> 2) Use relative file names (as suggested by Kumar) or similar methods
>    to make sure we pick up the md5.h header file from a local
>    directory instead from /usr/include.
> 3) Rename md5.h to make sure we use a pick up our own file instead of
>    some unrelated file which happens to have the same name.
> 
> My vote goes for 3).

2) seems to be more robust, though -- 3) works until someone installs a
system header file which happens to have the name that we came up with
for the U-Boot's own header file. Also, we used 2) for libfdt compiled
for mkimage.

Regards,
Bartlomiej



From andre.schwarz at matrix-vision.de  Thu Apr  3 18:37:57 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 03 Apr 2008 18:37:57 +0200
Subject: [U-Boot-Users] MPC8343 PCI setup
Message-ID: <47F507E5.1080405@matrix-vision.de>

All,

currently I'm trying to bring up a mpc8343 based system.
Latest u-boot v1.3.2 is running fine.

The MPC8343 has a single 32-Bit PCI Bus running at 66MHz.
Connected are a FPGA (IDSEL 11 + IRQ0) and a miniPCI Slot (IDSEL12 + 
IRQ1).                                    

Unfortunately the kernel panics during/after PCI setup.

As always I expect my device tree to be wrong or at least is missing 
something.
I startet with "mpc834x_mds.dts", removed the 2nd PCI and switched to 
"PowerPC,8343 at 0".



u-boot shows this pci node :


        pci at e0008500 {
                cell-index = <0x00000001>;
                interrupt-map-mask = [00 00 f8 00 00 00 00 00 00 00 00 
00 00 00 00 07];
                interrupt-map = [00 00 58 00 00 00 00 00 00 00 00 00 00 
00 00 01 00 00 00 01 00 00 00 30 00 00 00 08 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 11 00 00 
00 08];
                interrupt-parent = <0x00000001>;
                interrupts = <0x00000042 0x00000008>;
                bus-range = <0x00000000 0x00000000>;
                ranges = [02 00 00 00 00 00 00 00 90 00 00 00 90 00 00 
00 00 00 00 00 10 00 00 00 42 00 00 00 00 00 00 00 8
0 00 00 00 80 00 00 00 00 00 00 00 10 00 00 00 01 00 00 00 00 00 00 00 
00 00 00 00 e2 00 00 00 00 00 00 00 00 10 00 00];
                clock-frequency = <0x03f940aa>;
                #interrupt-cells = <0x00000001>;
                #size-cells = <0x00000002>;
                #address-cells = <0x00000003>;
                reg = <0xe0008500 0x00000100>;
                compatible = "fsl,mpc8349-pci";
                device_type = "pci";
        };




Booting the kernel :


Using mvBlueLYNX-M7 machine description
Linux version 2.6.25-rc7-01000-ga1ba6f0-dirty (root at nova) (gcc version 
4.0.0 (DENX ELDK 4.1 4.0.0)) #23 PREEMPT Thu Apr 3 1
6:46:17 CEST 2008
Found initrd at 0xc3978000:0xc3c00000
console [udbg0] enabled
setup_arch: bootmem
mvblm7_setup_arch()
Adding PCI host bridge /pci at e0008500
Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus 
number: 0->0
 ->Hose at 0xc02bf000, cfg_addr=0xfdffd300,cfg_data=0xfdffd304
PCI host bridge /pci at e0008500 (primary) ranges:
 MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
 MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
  IO 0x00000000e2000000..0x00000000e20fffff -> 0x0000000000000000
Unable to handle kernel paging request for data at address 0x00000000



Call trace gives address last called function "of_device_is_compatible".

Any help is welcome !


regards,
Andre Schwarz
Matrix Vision



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From biggerbadderben at gmail.com  Thu Apr  3 19:33:02 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 13:33:02 -0400
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <Pine.LNX.4.64.0804031629240.18539@axis700.grange>
References: <Pine.LNX.4.64.0804031424530.18539@axis700.grange>
	<47F4E85C.1080502@gmail.com>
	<Pine.LNX.4.64.0804031629240.18539@axis700.grange>
Message-ID: <47F514CE.4090809@gmail.com>

Guennadi Liakhovetski wrote:
> On Thu, 3 Apr 2008, Ben Warren wrote:
>
>   
>> Guennadi Liakhovetski wrote:
>>     
>>> Replace direct register address derefencing with accessor functions.
>>> Restrict explicitly 32-bit bus-width, extend affected configurations
>>> respectively.
>>>
>>>   
>>>       
>> Much better!  Thanks for doing all this work.  The only problem is that you're
>> providing it relative to another patch that hasn't been accepted.
>>     
>
> Well, the merge window is closed, so, I cannot send in any more new 
> features. Whereas if we consider this as a fix - maybe it would be 
> possible?
>
>   
I know the timetable says the merge window is closed, but there hasn't 
been any type of announcement and history tells me that there's probably 
still time.  I have some things I'd still like to get in if possible, 
but only WD can say for sure, of course.

regards,
Ben



From lg at denx.de  Thu Apr  3 19:41:30 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 19:41:30 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <47F514CE.4090809@gmail.com>
References: <Pine.LNX.4.64.0804031424530.18539@axis700.grange>
	<47F4E85C.1080502@gmail.com>
	<Pine.LNX.4.64.0804031629240.18539@axis700.grange>
	<47F514CE.4090809@gmail.com>
Message-ID: <Pine.LNX.4.64.0804031940260.627@axis700.grange>

On Thu, 3 Apr 2008, Ben Warren wrote:

> I know the timetable says the merge window is closed, but there hasn't been
> any type of announcement and history tells me that there's probably still
> time.  I have some things I'd still like to get in if possible, but only WD
> can say for sure, of course.

He has:

* Now talking on #u-boot
* Topic for #u-boot is: Merge Window for 1.3.3 is over - only bug fixes accepted now.
* Topic for #u-boot set by wdenk at Tue Apr  1 10:27:53 2008

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From biggerbadderben at gmail.com  Thu Apr  3 19:44:59 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 13:44:59 -0400
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <Pine.LNX.4.64.0804031940260.627@axis700.grange>
References: <Pine.LNX.4.64.0804031424530.18539@axis700.grange>
	<47F4E85C.1080502@gmail.com>
	<Pine.LNX.4.64.0804031629240.18539@axis700.grange>
	<47F514CE.4090809@gmail.com>
	<Pine.LNX.4.64.0804031940260.627@axis700.grange>
Message-ID: <47F5179B.9080208@gmail.com>

Guennadi Liakhovetski wrote:
> On Thu, 3 Apr 2008, Ben Warren wrote:
>
>   
>> I know the timetable says the merge window is closed, but there hasn't been
>> any type of announcement and history tells me that there's probably still
>> time.  I have some things I'd still like to get in if possible, but only WD
>> can say for sure, of course.
>>     
>
> He has:
>
> * Now talking on #u-boot
> * Topic for #u-boot is: Merge Window for 1.3.3 is over - only bug fixes accepted now.
> * Topic for #u-boot set by wdenk at Tue Apr  1 10:27:53 2008
>   
OK then.  Next revision it is.

regards,
Ben



From tor at excito.com  Thu Apr  3 20:51:41 2008
From: tor at excito.com (Tor Krill)
Date: Thu,  3 Apr 2008 18:51:41 +0000 (UTC)
Subject: [U-Boot-Users] MPC8343 PCI setup
In-Reply-To: <47F507E5.1080405@matrix-vision.de>
Message-ID: <DpzldAuO.1207248700.7986240.tor@localhost>




On 4/3/2008, "Andre Schwarz" <andre.schwarz at matrix-vision.de> wrote:

>All,

Hi Andre and others,

>currently I'm trying to bring up a mpc8343 based system.
>Latest u-boot v1.3.2 is running fine.
>
>The MPC8343 has a single 32-Bit PCI Bus running at 66MHz.
>Connected are a FPGA (IDSEL 11 + IRQ0) and a miniPCI Slot (IDSEL12 + 
>IRQ1).                                    
>
>Unfortunately the kernel panics during/after PCI setup.

Not sure if this is related. But i got strange problems with PCI after
the patch "Add CONFIG_PCI_SKIP_HOST_BRIDGE config option"
(55774b512fdf63c..) was added.

My symptoms where missed interrupts on sata dma in Linux. U-boot where
however fine. Adding the above config solved my problems. Not really
sure why i experienced this. We have no PCI bridge on our board.

/Tor



From wd at denx.de  Thu Apr  3 20:13:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 03 Apr 2008 20:13:49 +0200
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: Your message of "Thu, 03 Apr 2008 16:30:34 +0200."
	<Pine.LNX.4.64.0804031629240.18539@axis700.grange>
Message-ID: <20080403181349.ED38924680@gemini.denx.de>

In message <Pine.LNX.4.64.0804031629240.18539 at axis700.grange> you wrote:
> 
> > Much better!  Thanks for doing all this work.  The only problem is that you're
> > providing it relative to another patch that hasn't been accepted.
> 
> Well, the merge window is closed, so, I cannot send in any more new 
> features. Whereas if we consider this as a fix - maybe it would be 
> possible?

Providing a different version of a patch is a fix of some kind.

Yes, "we" consider this as a fix.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
What is research but a blind date with knowledge?      -- Will Harvey



From wd at denx.de  Thu Apr  3 20:20:15 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 03 Apr 2008 20:20:15 +0200
Subject: [U-Boot-Users] Pointer to similar board?
In-Reply-To: Your message of "Thu, 03 Apr 2008 17:28:07 +0200."
	<47F3F98010FF784EBEE6526EAAB078D10635DED5@tq-mailsrv.tq-net.de>
Message-ID: <20080403182015.B6A8C24680@gemini.denx.de>

In message <47F3F98010FF784EBEE6526EAAB078D10635DED5 at tq-mailsrv.tq-net.de> you wrote:
>
> > I changed the boot delay in configs/smdk2410.h to -1 to make sure I
> > could get the right port (swapping the cable around in case it wasn't
> > uart 0 being used. I also tried 60 delay. Still nothing.

I am not really sure if the smdk2410 port is working at all at the
moment.

> It was some time ago, I last used the SMDK2410. But I'm pretty sure,
> that it prints some boot messages. You should see this messages regardles
> if you boot from flash, ethernet, or whatever.

I can only speak for the s3c2400 (trab, and most probably also
smdk2400), which were broken by this commit:

commit 80767a6cead9990d9e77e62be947843c2c72f469
Author: Peter Pearse <peter.pearse at arm.com>
Date:   Wed Sep 5 16:04:41 2007 +0100

    Changed API name to coloured_led.h
    Removed code using deprecated ifdef CONFIG_BOOTBINFUNC
    Tidied other cpu/arm920t/start.S code

You may want to try the commit previous to this one...

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: wd at denx.de
Don't panic.



From wd at denx.de  Thu Apr  3 20:26:23 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 03 Apr 2008 20:26:23 +0200
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: Your message of "Thu, 03 Apr 2008 18:33:31 +0200."
	<47F506DB.6010506@semihalf.com>
Message-ID: <20080403182623.A926624680@gemini.denx.de>

In message <47F506DB.6010506 at semihalf.com> you wrote:
>
> I think this makes sense for code that we for example link from host's
> standard libraries. But for code compiled from files from the U-Boot
> tree (like lib_generic/md5.c), we shouldn't include host's header files.

But you, you should. Note that we are talking about host tools  here,
i.  e.  stuff that is supposed to run in the host environment. Assume
your're building for a big-endian, 32 bit Power system.  Assume  your
host is a little-endian x86_64 system.

Even simple tungs like a printf() require that you include the correct
host header files as you will link your host application against the
host libraries, too.

> > 2) Use relative file names (as suggested by Kumar) or similar methods
> >    to make sure we pick up the md5.h header file from a local
> >    directory instead from /usr/include.
> > 3) Rename md5.h to make sure we use a pick up our own file instead of
> >    some unrelated file which happens to have the same name.
> 
> 2) seems to be more robust, though -- 3) works until someone installs a

2 is not robust. It fails easily as soon as you move or rename files,
as son as you miss to create one  of  trhe  needed  directories  when
building out of tree, etc.

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: wd at denx.de
I had the rare misfortune of being one of the first people to try and
implement a PL/1 compiler.                             -- T. Cheatham



From wd at denx.de  Thu Apr  3 20:29:51 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 03 Apr 2008 20:29:51 +0200
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: Your message of "Thu, 03 Apr 2008 13:33:02 EDT."
	<47F514CE.4090809@gmail.com>
Message-ID: <20080403182951.452DA24680@gemini.denx.de>

In message <47F514CE.4090809 at gmail.com> you wrote:
>
> I know the timetable says the merge window is closed, but there hasn't 
> been any type of announcement and history tells me that there's probably 

Oh, there has been an announcement:

Topic for #u-boot: Merge Window for 1.3.3 is over - only bug fixes accepted now.
Topic for #u-boot set by wdenk at 2008-04-01 10:27:53

And we don't need formal announcements, or do we? We all know that fe
follow the deadlines  of  our  timetable  with  the  precision  of  a
Rolex(*).


(*) one of those you get on ebay really cheap, that is :-)

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: wd at denx.de
"May your future be limited only by your dreams."
- Christa McAuliffe



From wd at denx.de  Thu Apr  3 20:31:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 03 Apr 2008 20:31:00 +0200
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: Your message of "Thu, 03 Apr 2008 13:44:59 EDT."
	<47F5179B.9080208@gmail.com>
Message-ID: <20080403183100.E665724680@gemini.denx.de>

In message <47F5179B.9080208 at gmail.com> you wrote:
>
> > * Topic for #u-boot is: Merge Window for 1.3.3 is over - only bug fixes accepted now.
> > * Topic for #u-boot set by wdenk at Tue Apr  1 10:27:53 2008
> >   
> OK then.  Next revision it is.

Nope. We're not bureaucrats. We do what technically makes sense. And
to me it makes much sense to see this go in now. Thanks in advance.

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: wd at denx.de
"The X11 source code style is ATROCIOUS and should not be used  as  a
model."                                                   - Doug Gwyn



From scottwood at freescale.com  Thu Apr  3 20:36:27 2008
From: scottwood at freescale.com (Scott Wood)
Date: Thu, 3 Apr 2008 13:36:27 -0500
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: <20080403182623.A926624680@gemini.denx.de>
References: <47F506DB.6010506@semihalf.com>
	<20080403182623.A926624680@gemini.denx.de>
Message-ID: <20080403183627.GA9846@ld0162-tx32.am.freescale.net>

On Thu, Apr 03, 2008 at 08:26:23PM +0200, Wolfgang Denk wrote:
> In message <47F506DB.6010506 at semihalf.com> you wrote:
> >
> > I think this makes sense for code that we for example link from host's
> > standard libraries. But for code compiled from files from the U-Boot
> > tree (like lib_generic/md5.c), we shouldn't include host's header files.
> 
> But you, you should. Note that we are talking about host tools  here,
> i.  e.  stuff that is supposed to run in the host environment. Assume
> your're building for a big-endian, 32 bit Power system.  Assume  your
> host is a little-endian x86_64 system.
> 
> Even simple tungs like a printf() require that you include the correct
> host header files as you will link your host application against the
> host libraries, too.

That's because printf() is from the host's libraries.  lib_generic/md5.c
is not a host-provided library, so you don't want to use a host-provided
header.

> > > 2) Use relative file names (as suggested by Kumar) or similar methods
> > >    to make sure we pick up the md5.h header file from a local
> > >    directory instead from /usr/include.
> > > 3) Rename md5.h to make sure we use a pick up our own file instead of
> > >    some unrelated file which happens to have the same name.
> > 
> > 2) seems to be more robust, though -- 3) works until someone installs a
> 
> 2 is not robust. It fails easily as soon as you move or rename files,
> as son as you miss to create one  of  trhe  needed  directories  when
> building out of tree, etc.

It is much more important to be robust against random crap in
/usr/include (something u-boot can't control) than changes in the u-boot
tree itself.

-Scott



From biggerbadderben at gmail.com  Thu Apr  3 20:50:20 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 14:50:20 -0400
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <20080403183100.E665724680@gemini.denx.de>
References: <20080403183100.E665724680@gemini.denx.de>
Message-ID: <47F526EC.5080408@gmail.com>

Wolfgang Denk wrote:
> In message <47F5179B.9080208 at gmail.com> you wrote:
>   
>>> * Topic for #u-boot is: Merge Window for 1.3.3 is over - only bug fixes accepted now.
>>> * Topic for #u-boot set by wdenk at Tue Apr  1 10:27:53 2008
>>>   
>>>       
>> OK then.  Next revision it is.
>>     
>
> Nope. We're not bureaucrats. We do what technically makes sense. And
> to me it makes much sense to see this go in now. Thanks in advance.
>
>   
Works for me.  I'll make it happen.

regards,
Ben



From biggerbadderben at gmail.com  Thu Apr  3 20:57:21 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 14:57:21 -0400
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <20080403182951.452DA24680@gemini.denx.de>
References: <20080403182951.452DA24680@gemini.denx.de>
Message-ID: <47F52891.3070607@gmail.com>

Wolfgang Denk wrote:
> In message <47F514CE.4090809 at gmail.com> you wrote:
>   
>> I know the timetable says the merge window is closed, but there hasn't 
>> been any type of announcement and history tells me that there's probably 
>>     
>
> Oh, there has been an announcement:
>
> Topic for #u-boot: Merge Window for 1.3.3 is over - only bug fixes accepted now.
> Topic for #u-boot set by wdenk at 2008-04-01 10:27:53
>
>   
OK, where do you announce these things, so I can be sure to notice next 
time?  I'm not trying to be a smart-ass, but am really curious.
> And we don't need formal announcements, or do we? We all know that fe
> follow the deadlines  of  our  timetable  with  the  precision  of  a
> Rolex(*).
>
>
> (*) one of those you get on ebay really cheap, that is :-)
>   
Who needs eBay when I get all these wonderful e-mails?  And it's not 
only watches!

cheers,
Ben



From lg at denx.de  Thu Apr  3 21:49:12 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Thu, 3 Apr 2008 21:49:12 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <47F52891.3070607@gmail.com>
References: <20080403182951.452DA24680@gemini.denx.de>
	<47F52891.3070607@gmail.com>
Message-ID: <Pine.LNX.4.64.0804032147200.627@axis700.grange>

On Thu, 3 Apr 2008, Ben Warren wrote:

> Wolfgang Denk wrote:
> >
> > Oh, there has been an announcement:
> >
> > Topic for #u-boot: Merge Window for 1.3.3 is over - only bug fixes accepted now.
> > Topic for #u-boot set by wdenk at 2008-04-01 10:27:53

	      ^^^^^^^

> OK, where do you announce these things, so I can be sure to notice next 
> time?  I'm not trying to be a smart-ass, but am really curious.

i.e. "#u-boot" IRC channel on irc.freenode.net.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From biggerbadderben at gmail.com  Thu Apr  3 22:00:31 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 03 Apr 2008 16:00:31 -0400
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <Pine.LNX.4.64.0804032147200.627@axis700.grange>
References: <20080403182951.452DA24680@gemini.denx.de>
	<47F52891.3070607@gmail.com>
	<Pine.LNX.4.64.0804032147200.627@axis700.grange>
Message-ID: <47F5375F.1090904@gmail.com>

Guennadi Liakhovetski wrote:
> On Thu, 3 Apr 2008, Ben Warren wrote:
>
>   
>> Wolfgang Denk wrote:
>>     
>>> Oh, there has been an announcement:
>>>
>>> Topic for #u-boot: Merge Window for 1.3.3 is over - only bug fixes accepted now.
>>> Topic for #u-boot set by wdenk at 2008-04-01 10:27:53
>>>       
>
> 	      ^^^^^^^
>
>   
>> OK, where do you announce these things, so I can be sure to notice next 
>> time?  I'm not trying to be a smart-ass, but am really curious.
>>     
>
> i.e. "#u-boot" IRC channel on irc.freenode.net.
>   
Oh, I didn't know there was a U-boot IRC channel.  That will surely make 
me more productive!

regards,
Ben



From afleming at gmail.com  Thu Apr  3 22:09:34 2008
From: afleming at gmail.com (Andy Fleming)
Date: Thu, 3 Apr 2008 15:09:34 -0500
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: <20080403183627.GA9846@ld0162-tx32.am.freescale.net>
References: <47F506DB.6010506@semihalf.com>
	<20080403182623.A926624680@gemini.denx.de>
	<20080403183627.GA9846@ld0162-tx32.am.freescale.net>
Message-ID: <2acbd3e40804031309p3cf9144awf1580e1c40b77aa1@mail.gmail.com>

On Thu, Apr 3, 2008 at 1:36 PM, Scott Wood <scottwood at freescale.com> wrote:
> On Thu, Apr 03, 2008 at 08:26:23PM +0200, Wolfgang Denk wrote:
>  > In message <47F506DB.6010506 at semihalf.com> you wrote:
>  > >
>  > > I think this makes sense for code that we for example link from host's
>  > > standard libraries. But for code compiled from files from the U-Boot
>  > > tree (like lib_generic/md5.c), we shouldn't include host's header files.
>  >
>  > But you, you should. Note that we are talking about host tools  here,
>  > i.  e.  stuff that is supposed to run in the host environment. Assume
>  > your're building for a big-endian, 32 bit Power system.  Assume  your
>  > host is a little-endian x86_64 system.
>  >
>  > Even simple tungs like a printf() require that you include the correct
>  > host header files as you will link your host application against the
>  > host libraries, too.
>
>  That's because printf() is from the host's libraries.  lib_generic/md5.c
>  is not a host-provided library, so you don't want to use a host-provided
>  header.

I agree with this.  Ideally, we should search system headers when we
want them, and u-boot headers when we want *them*.  However, my
Make-fu is not strong enough to figure that one out.


>
>  It is much more important to be robust against random crap in
>  /usr/include (something u-boot can't control) than changes in the u-boot
>  tree itself.

Well, IMNSHO, renaming the internal header to u-boot-md5.h solves the
problem with a high degree of robustness (random non-u-boot packages
are unlikely to install a header with u-boot in the name), and avoids
the dangers of relative path lookups.  It so happens I already sent a
patch to do that...  :)

That said, if we could figure out how to rejigger the Makefile so that
it found u-boot's md5.h first, that would be better.  I suspect that
involves a similar patch, though.  These are the header categories:

1) U-Boot headers only meant for target compilation
2) System headers
3) U-Boot headers meant for host compilation (probably for both host and target)

When we're building for the target, we just don't search the system.
But for host compilation, we want to exclude #1.  To do that, we'd
have to identify every header which should never be compiled on the
host, and move it into another directory which won't get searched when
we're using HOST_CC.

Personally, I suspect category 3 is much smaller than category 1, so
it's probably easier to uniquify the smaller category somehow.  We
could, for instance, also just identify those files and move them into
include/generic/ or somesuch.

Andy



From pmeloy at shaw.ca  Thu Apr  3 22:46:28 2008
From: pmeloy at shaw.ca (PatM)
Date: Thu, 03 Apr 2008 13:46:28 -0700
Subject: [U-Boot-Users] Pointer to similar board?
In-Reply-To: <20080403182015.B6A8C24680@gemini.denx.de>
References: <20080403182015.B6A8C24680@gemini.denx.de>
Message-ID: <1207255588.11528.2.camel@rhodan.shaw.ca>

That was it! Went back to 1.2.0, flashed my NOR and upon reboot got the
uboot menu.

Thanks very much! Being new to this stuff I always assume its me doing
something wrong and spend a few days wracking my brain and overheating
the google servers before actually asking a question. I learn a lot but
its hard on the hairline 8)

Pat Meloy
Canuckleland

On Thu, 2008-04-03 at 20:20 +0200, Wolfgang Denk wrote:
> In message <47F3F98010FF784EBEE6526EAAB078D10635DED5 at tq-mailsrv.tq-net.de> you wrote:
> >
> > > I changed the boot delay in configs/smdk2410.h to -1 to make sure I
> > > could get the right port (swapping the cable around in case it wasn't
> > > uart 0 being used. I also tried 60 delay. Still nothing.
> 
> I am not really sure if the smdk2410 port is working at all at the
> moment.
> 
> > It was some time ago, I last used the SMDK2410. But I'm pretty sure,
> > that it prints some boot messages. You should see this messages regardles
> > if you boot from flash, ethernet, or whatever.
> 
> I can only speak for the s3c2400 (trab, and most probably also
> smdk2400), which were broken by this commit:
> 
> commit 80767a6cead9990d9e77e62be947843c2c72f469
> Author: Peter Pearse <peter.pearse at arm.com>
> Date:   Wed Sep 5 16:04:41 2007 +0100
> 
>     Changed API name to coloured_led.h
>     Removed code using deprecated ifdef CONFIG_BOOTBINFUNC
>     Tidied other cpu/arm920t/start.S code
> 
> You may want to try the commit previous to this one...
> 
> Best regards,
> 
> Wolfgang Denk
> 




From plagnioj at jcrosoft.com  Thu Apr  3 23:28:38 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 3 Apr 2008 23:28:38 +0200
Subject: [U-Boot-Users] [PATCH] IDE: fix bug in reset sequence
In-Reply-To: <20080403113721.28821.11173.stgit@tq-sewsrv-4.tq-net.de>
References: <20080403113721.28821.11173.stgit@tq-sewsrv-4.tq-net.de>
Message-ID: <20080403212838.GA10873@game.jcrosoft.org>

On 13:37 Thu 03 Apr     , Martin Krause wrote:
> According to the ata (ata5) specification the RESET- signal
> shall be asserted for at least 25 us. Without this patch,
> the RESET- signal is asserted on some boards for only < 1 us
> (e. g. on the TQM5200). This patch adds a general delay of
> 25 us to the RESET- signal.
> 
> Without this patch a Platinum 4 GiB CF card is not recognised
> properly on boards with a TQM5200 (STK52xx, TB5200).
> 
> Signed-off-by: Martin Krause <martin.krause at tqs.de>
> ---
> 
>  common/cmd_ide.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/common/cmd_ide.c b/common/cmd_ide.c
> index 8ace970..f9cd422 100644
> --- a/common/cmd_ide.c
> +++ b/common/cmd_ide.c
> @@ -1529,6 +1529,9 @@ static void ide_reset (void)
>  
>  	ide_set_reset (1); /* assert reset */
>  
> +	/* the reset signal shall be asserted for et least 25 us */
                                                  ^
					      for at least ;-)

btw this need to be tested with other CF ex <>8GB and some hard drive

Best Regards,
J.



From timur at freescale.com  Thu Apr  3 23:49:10 2008
From: timur at freescale.com (Timur Tabi)
Date: Thu, 03 Apr 2008 16:49:10 -0500
Subject: [U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h
In-Reply-To: <1207171147-3228-1-git-send-email-afleming@freescale.com>
References: <20080402185750.62979243AB@gemini.denx.de>
	<1207171147-3228-1-git-send-email-afleming@freescale.com>
Message-ID: <47F550D6.1060909@freescale.com>

Andy Fleming wrote:
> Some systems have md5.h installed in /usr/include/.  This isn't the desired
> file (we want the one in include/md5.h).  This will avoid the conflict.
> This fixes the host tools building problem
> 
> Signed-off-by: Andy Fleming <afleming at freescale.com>

Acked-by: Timur Tabi <timur at freescale.com>

This fixes a build break for me.  Please apply.

-- 
Timur Tabi
Linux kernel developer at Freescale



From plagnioj at jcrosoft.com  Thu Apr  3 23:53:26 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 3 Apr 2008 23:53:26 +0200
Subject: [U-Boot-Users] [PATCH] cfi_flash: Support buffered writes
	on	non-standard Spansion NOR flash
In-Reply-To: <Pine.LNX.4.64.0804031303450.18539@axis700.grange>
References: <Pine.LNX.4.64.0804031303450.18539@axis700.grange>
Message-ID: <20080403215326.GB10873@game.jcrosoft.org>

On 13:36 Thu 03 Apr     , Guennadi Liakhovetski wrote:
> Some NOR flash chip from Spansion, for example, the s29ws-n MirrorBit 
> series require different addresses for buffered write commands. Define a 
> configuration option to support buffered writes on those chips. A more 
> elegant solution would be to automatically detect those chips by parsing 
> their CFI records, but that would require introduction of a fixup table 
> into the cfi_flash driver.
> 

It will be good to detect it. On some hardware you may have some pip out
compatible flash with this future or an other buffer interface.

We are in fix window, if possible you maybe can provide this support for
the next merge window

but thanks


Best Regards,
J.



From wd at denx.de  Fri Apr  4 00:04:05 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 04 Apr 2008 00:04:05 +0200
Subject: [U-Boot-Users] [PATCH] Fix host tool build breakage, take two
In-Reply-To: Your message of "Thu, 03 Apr 2008 13:36:27 CDT."
	<20080403183627.GA9846@ld0162-tx32.am.freescale.net>
Message-ID: <20080403220405.4C86D2476E@gemini.denx.de>

In message <20080403183627.GA9846 at ld0162-tx32.am.freescale.net> you wrote:
>
> > Even simple tungs like a printf() require that you include the correct
> > host header files as you will link your host application against the
> > host libraries, too.
> 
> That's because printf() is from the host's libraries.  lib_generic/md5.c
> is not a host-provided library, so you don't want to use a host-provided
> header.

Correct, and that's whY I agree that renaming it to make name
collisions at least unlikely is a good thing.

> It is much more important to be robust against random crap in
> /usr/include (something u-boot can't control) than changes in the u-boot
> tree itself.

Agreed, too.

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: wd at denx.de
Give a man a fish, and you feed him for a day. Teach a man  to  fish,
and he'll invite himself over for dinner.             - Calvin Keegan



From wd at denx.de  Fri Apr  4 00:08:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 04 Apr 2008 00:08:47 +0200
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: Your message of "Thu, 03 Apr 2008 14:57:21 EDT."
	<47F52891.3070607@gmail.com>
Message-ID: <20080403220847.3F8732476E@gemini.denx.de>

In message <47F52891.3070607 at gmail.com> you wrote:
>
> > Topic for #u-boot: Merge Window for 1.3.3 is over - only bug fixes accepted now.
> > Topic for #u-boot set by wdenk at 2008-04-01 10:27:53
> >
> >   
> OK, where do you announce these things, so I can be sure to notice next 
> time?  I'm not trying to be a smart-ass, but am really curious.

Well, the quote above refers to the subject on the "u-boot" IRC
channel.

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: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.



From brjerome.1 at gmail.com  Thu Apr  3 22:40:26 2008
From: brjerome.1 at gmail.com (Norman)
Date: Thu, 3 Apr 2008 20:40:26 +0000 (UTC)
Subject: [U-Boot-Users] Build u-boot for at91sam9260ek
Message-ID: <loom.20080403T203545-835@post.gmane.org>

I have downloaded the 1.3.2 source and wonder where can I locate the latest
stable patches for this platform? I saw an AT91 fork in the source tree, would
that be a better starting point.

Thanks,
Norman




From gvb.uboot at gmail.com  Fri Apr  4 01:09:25 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Thu, 03 Apr 2008 19:09:25 -0400
Subject: [U-Boot-Users] newcomer
In-Reply-To: <BAY114-W4825326E96E94B8E1FB5E9FBF70@phx.gbl>
References: <BAY114-W4825326E96E94B8E1FB5E9FBF70@phx.gbl>
Message-ID: <47F563A5.6080101@gmail.com>

???? wrote:
> hi experters:
>  
>    I'm a newcomer in U-boot, I want to understand the U-boot,but i don't 
> know how to start!Anyone can help me ?
> Thanks,
>                Peter wang

Hi Peter,

Start by looking in the u-boot code/documentation to see if your 
processor is supported.  Look through boards using that processor to get 
a feel for what needs to be customized for a port.

See the DULG manual:
   <http://www.denx.de/wiki/DULG/WebHome>

Browse the source:
   <http://git.denx.de/>

Read the README:
<http://git.denx.de/?p=u-boot.git;a=blob;f=README;h=5cbe7c1e80daabeee8c43247db7041b999919025;hb=HEAD>

(especially starting at line 3732 ;-)
<http://git.denx.de/?p=u-boot.git;a=blob;f=README;h=5cbe7c1e80daabeee8c43247db7041b999919025;hb=HEAD#l3732>

Then come back and ask specific questions and we will give you more 
specific answers.

Best regards,
gvb



From gvb.uboot at gmail.com  Fri Apr  4 01:17:09 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Thu, 03 Apr 2008 19:17:09 -0400
Subject: [U-Boot-Users] FDT: missing stdout-path
In-Reply-To: <20080403160044.GA7667@ld0162-tx32.am.freescale.net>
References: <HAELLJHFKFMKJBAJIOFGAENDDDAA.cook@isgchips.com>
	<20080403160044.GA7667@ld0162-tx32.am.freescale.net>
Message-ID: <47F56575.9080606@gmail.com>

Scott Wood wrote:
> On Thu, Apr 03, 2008 at 11:56:08AM -0400, Bill Cook wrote:
>> Hello experts,
>>
>> With U-Boot-1.3.2 and a Freescale MPC8313ERDB,
>> I'm getting this message from bootm
>>
>> ...
>>    Booting using the fdt at 0xfc700000
>>    Loading Ramdisk to 07ca1000, end 07f419bf ... OK
>>    Loading Device Tree to 007fc000, end 007fefff ... OK
>>    WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND.
>>    ERROR: /chosen node create failed - must RESET the board to recover.
>>    Resetting the board.
>>
>>    U-Boot 1.3.2 (Apr  2 2008 - 10:02:55) MPC83XX
>>
>>    Reset Status: Software Hard, External/Internal Soft, External/Internal
>> Hard
>>
>>    CPU:   e300c3, MPC8313E, Rev: 10 at 333.333 MHz, CSB:  166 MHz
>> ...
>>
>> What do I need to add to DTS file or u-boot environment to make this go?
> 
> You probably need serial0, serial1, etc. aliases.  See the device trees
> in head-of-tree Linux.
> 
> -Scott

...and that error message could stand improvement to give the poor user 
a better clue that he is missing the /aliases node or /aliases/serial0 
property.

The current error message reminds me of the "Fog in Seattle" joke
   <http://home.earthlink.net/~devinc/fogin.htm>

gvb



From plagnioj at jcrosoft.com  Fri Apr  4 01:15:02 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 4 Apr 2008 01:15:02 +0200
Subject: [U-Boot-Users] Build u-boot for at91sam9260ek
In-Reply-To: <loom.20080403T203545-835@post.gmane.org>
References: <loom.20080403T203545-835@post.gmane.org>
Message-ID: <20080403231502.GA8759@game.jcrosoft.org>

On 20:40 Thu 03 Apr     , Norman wrote:
> I have downloaded the 1.3.2 source and wonder where can I locate the latest
> stable patches for this platform? I saw an AT91 fork in the source tree, would
> that be a better starting point.
> 
> Thanks,
> Norman

Take a look to the AT91 repository

I'll will add the last Stelian's patch in to the testing branch

Best Regards,
J.



From jwboyer at gmail.com  Fri Apr  4 04:48:31 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 03 Apr 2008 21:48:31 -0500
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <20080403220847.3F8732476E@gemini.denx.de>
References: <20080403220847.3F8732476E@gemini.denx.de>
Message-ID: <1207277311.3224.48.camel@vader.jdub.homelinux.org>

On Fri, 2008-04-04 at 00:08 +0200, Wolfgang Denk wrote:
> In message <47F52891.3070607 at gmail.com> you wrote:
> >
> > > Topic for #u-boot: Merge Window for 1.3.3 is over - only bug fixes accepted now.
> > > Topic for #u-boot set by wdenk at 2008-04-01 10:27:53
> > >
> > >   
> > OK, where do you announce these things, so I can be sure to notice next 
> > time?  I'm not trying to be a smart-ass, but am really curious.
> 
> Well, the quote above refers to the subject on the "u-boot" IRC
> channel.

Which would be #u-boot on Freenode (irc.freenode.net) for those that
don't know the channel even exists.

josh




From nagendra at tesbv.com  Fri Apr  4 07:38:08 2008
From: nagendra at tesbv.com (Nagendra)
Date: Fri, 4 Apr 2008 11:08:08 +0530
Subject: [U-Boot-Users] unable to run the multiple commands
Message-ID: <000901c89616$102c3a40$1b00140a@nagendra>

Hi all
 
I am working with u - boot integration of ARM based board for various
tests 
I am able to add the different commands but unable to run them
simultaneously 
The last command which  I added is only able to run. Remaining commands
are just getting hanged
Can you please suggest the way to debug this ?
 
Regards,
Nagendra
TES Electronics Solutions
Bangalore
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080404/3ed47ed1/attachment.htm 

From bankupalli.sarma at gmail.com  Fri Apr  4 07:53:51 2008
From: bankupalli.sarma at gmail.com (bankupalli nagendra)
Date: Fri, 4 Apr 2008 11:23:51 +0530
Subject: [U-Boot-Users] help
Message-ID: <bc04c5ba0804032253g4604b35ue3878c2429034dfa@mail.gmail.com>

 Hi all



I am working with u ? boot integration of ARM based board for various tests

I am able to add the different commands but unable to run them
simultaneously

The last command which  I added is only able to run. Remaining commands are
just getting hanged

Can you please suggest the way to debug this ?



Regards,

Nagendra

TES Electronics Solutions

Bangalore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080404/79b564af/attachment.htm 

From w.wegner at astro-kom.de  Fri Apr  4 08:13:31 2008
From: w.wegner at astro-kom.de (w.wegner at astro-kom.de)
Date: Fri, 04 Apr 2008 08:13:31 +0200
Subject: [U-Boot-Users] "huge" (6 second) delay when booting linux kernel
	(coldfire)
Message-ID: <47F5E32B.14233.4E234DB@w.wegner.astro-kom.de>

Hi,

I have a problem on startup on my Coldfire MCF5373L board.

When the flash is empty, something before booting the linux kernel
takes too long such that the watchdog resets my board before there
is a chance for the kernel to take over control.

This happens only if the (32MB) flash is empty, if there is a
filesystem (JFFS2) in it, the delay is much shorter.

Everything is fine until and including uncompressing the kernel.
I added an entry in lib_m68k/m68k_linux.c to see if the delay
happens in U-Boot or in the kernel:

	 puts("Boot\n");
	(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);

When booting without the watchdog, I get this (ttyS2 is the
console port):

   Uncompressing Kernel Image ... OK
Boot?ttyS2 at 0xfc068000 (irq = 92) is a builtin ColdFire UART

Between printing the "OK" from uncompressing and "Boot" is
where the delay happens.

Can anybody give a hint where this delay comes from?

Thank you,
Wolfgang




From w.wegner at astro-kom.de  Fri Apr  4 08:36:50 2008
From: w.wegner at astro-kom.de (w.wegner at astro-kom.de)
Date: Fri, 04 Apr 2008 08:36:50 +0200
Subject: [U-Boot-Users] "huge" (6 second) delay when booting linux
	kernel (coldfire)
In-Reply-To: <47F5E32B.14233.4E234DB@w.wegner.astro-kom.de>
References: <47F5E32B.14233.4E234DB@w.wegner.astro-kom.de>
Message-ID: <47F5E8A2.14762.4F78C6B@w.wegner.astro-kom.de>

Hi,

On 4 Apr 2008 at 8:13, w.wegner at astro-kom.de wrote:

> Hi,
> 
> I have a problem on startup on my Coldfire MCF5373L board.
> 
> When the flash is empty, something before booting the linux kernel
> takes too long such that the watchdog resets my board before there
> is a chance for the kernel to take over control.

with some more puts() I found there is around 4 second delay in this
line of do_bootm_linux() in lib_m68k/m68k_linux.c:

	cmd_end = cmd_start + strlen(cmdline);

My environment looks like this:

URMEL > printenv
bootargs= console=ttyS2,115200 rootfstype=romfs loaderversion=$loaderversion
bootcmd=protect off 0x80000 0x1ffffff;run env_check;run xilinxload&&run alteralo
ad&&bootm 0x80000;update;reset
bootdelay=1
baudrate=115200
ethaddr=00:00:00:00:00:09
ipaddr=192.168.100.2
serverip=192.168.100.1
loaderversion=10
alterafile=0
xilinxfile=0
xilinxload=imxtract 0x540000 $xilinxfile 0x41000000&&fpga load 0 0x41000000 $filesize
alteraload=imxtract 0x6c0000 $alterafile 0x41000000&&fpga load 1 0x41000000 $filesize
env_check=if test $env_default -eq 1; then setenv env_default 0;saveenv;fi
ethact=FEC0
env_default=0
stdin=serial
stdout=serial
stderr=serial

Environment size: 643/32764 bytes

At first glance I can not see an obvioius reason what goes wrong with the
cmdline...

Regards,
Wolfgang




From wd at denx.de  Fri Apr  4 08:39:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 04 Apr 2008 08:39:40 +0200
Subject: [U-Boot-Users] help
In-Reply-To: Your message of "Fri, 04 Apr 2008 11:23:51 +0530."
	<bc04c5ba0804032253g4604b35ue3878c2429034dfa@mail.gmail.com>
Message-ID: <20080404063940.B8F3B2476E@gemini.denx.de>

In message <bc04c5ba0804032253g4604b35ue3878c2429034dfa at mail.gmail.com> you wrote:
>
> I am working with u =96 boot integration of ARM based board for various tes=
> ts
> 
> I am able to add the different commands but unable to run them
> simultaneously

It is considerd highly impolite to post the same question several
times in short sequence, especially when you additionally change the
sander ID's. Please don't do this.

> Content-Type: text/html; charset=WINDOWS-1252
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline

And NEVER post HTML to this list!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You are in a maze of UUCP connections, all alike.



From w.wegner at astro-kom.de  Fri Apr  4 10:02:40 2008
From: w.wegner at astro-kom.de (w.wegner at astro-kom.de)
Date: Fri, 04 Apr 2008 10:02:40 +0200
Subject: [U-Boot-Users] "huge" (6 second) delay when booting linux
	kernel (coldfire)
In-Reply-To: <47F5E8A2.14762.4F78C6B@w.wegner.astro-kom.de>
References: <47F5E32B.14233.4E234DB@w.wegner.astro-kom.de>,
	<47F5E8A2.14762.4F78C6B@w.wegner.astro-kom.de>
Message-ID: <47F5FCC0.2984.5462256@w.wegner.astro-kom.de>

On 4 Apr 2008 at 8:36, w.wegner at astro-kom.de wrote:

> Hi,
> 
> On 4 Apr 2008 at 8:13, w.wegner at astro-kom.de wrote:
> 
> > Hi,
> > 
> > I have a problem on startup on my Coldfire MCF5373L board.
> > 
> > When the flash is empty, something before booting the linux kernel
> > takes too long such that the watchdog resets my board before there
> > is a chance for the kernel to take over control.
> 
> with some more puts() I found there is around 4 second delay in this
> line of do_bootm_linux() in lib_m68k/m68k_linux.c:
> 
> 	cmd_end = cmd_start + strlen(cmdline);

Found the problem.

It was a wrong CFG_BOOTMAPSZ, seems to have been a relic
from my very first try in porting to MCF53xx. With the correct line:

#define CFG_BOOTMAPSZ		(CFG_SDRAM_BASE + (CFG_SDRAM_SIZE << 20))

Booting works fast as it should. (This new CFG_BOOTMAPSZ came
from M5329EVB.h).

Regards,
Wolfgang




From stelian at popies.net  Fri Apr  4 10:22:03 2008
From: stelian at popies.net (Stelian Pop)
Date: Fri, 04 Apr 2008 10:22:03 +0200
Subject: [U-Boot-Users] Build u-boot for at91sam9260ek
In-Reply-To: <20080403231502.GA8759@game.jcrosoft.org>
References: <loom.20080403T203545-835@post.gmane.org>
	<20080403231502.GA8759@game.jcrosoft.org>
Message-ID: <1207297323.6468.7.camel@galileo>


Le vendredi 04 avril 2008 ? 01:15 +0200, Jean-Christophe
PLAGNIOL-VILLARD a ?crit :
> On 20:40 Thu 03 Apr     , Norman wrote:
> > I have downloaded the 1.3.2 source and wonder where can I locate the latest
> > stable patches for this platform? I saw an AT91 fork in the source tree, would
> > that be a better starting point.
> > 
> > Thanks,
> > Norman
> 
> Take a look to the AT91 repository

In case you didn't find it already, the AT91 repository is at:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-at91.git;a=summary

> I'll will add the last Stelian's patch in to the testing branch

It should build and work fine with or without the latest patches which
do only some cleanups (they were posted yesterday on the list).

BTW, Jean-Christophe and Wolfgang, did the AT91 patches miss the merge
window ? From what I've read, Wolfgang did close the window, but at the
same time he didn't merge anything past March 27, and you did send the
pull request a few hours too late (in the morning of April 1st).

Stelian.
-- 
Stelian Pop <stelian at popies.net>




From wd at denx.de  Fri Apr  4 11:21:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 04 Apr 2008 11:21:49 +0200
Subject: [U-Boot-Users] Build u-boot for at91sam9260ek
In-Reply-To: Your message of "Fri, 04 Apr 2008 10:22:03 +0200."
	<1207297323.6468.7.camel@galileo>
Message-ID: <20080404092149.2531D2476E@gemini.denx.de>

In message <1207297323.6468.7.camel at galileo> you wrote:
> 
> In case you didn't find it already, the AT91 repository is at:
> http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-at91.git;a=summary

That's the old (still working, but deprecated) URI. Please use:

http://git.denx.de/?p=u-boot/u-boot-at91.git;a=summary

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: wd at denx.de
"Success covers a multitude of blunders."       - George Bernard Shaw



From trimarchi at gandalf.sssup.it  Fri Apr  4 12:30:10 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Fri, 04 Apr 2008 12:30:10 +0200
Subject: [U-Boot-Users] [PATCH] get_vfatname
In-Reply-To: <20080401124556.6F57324544@gemini.denx.de>
References: <20080401124556.6F57324544@gemini.denx.de>
Message-ID: <47F60332.5030907@gandalf.sssup.it>

Hi,
Wolfgang Denk wrote:
> In message <47F22032.6040409 at gandalf.sssup.it> you wrote:
>   
>>> Like some script to create the needed directories / files in a VFAT
>>> file system which provokes the error?
>>>       
> ...
>   
>> I can give you an image that you can write on ide disk or on a Compact 
>> Flash.
>> Is ok?
>>     
>
> Actually I'd prefer a script to create such an image, but if this is
> impossible (?) then an image will do, too.
>   
Do you receive the link?

Regards
Michael




From monstr at seznam.cz  Fri Apr  4 12:52:49 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:49 +0200
Subject: [U-Boot-Users] [PATCH 02/13] microblaze: remove old setting for
	emac driver
In-Reply-To: <1207306380-5210-2-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-3-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 board/xilinx/ml401/xparameters.h  |    8 +-------
 board/xilinx/xupv2p/xparameters.h |    8 +-------
 2 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/board/xilinx/ml401/xparameters.h b/board/xilinx/ml401/xparameters.h
index 1a116ea..becafc8 100644
--- a/board/xilinx/ml401/xparameters.h
+++ b/board/xilinx/ml401/xparameters.h
@@ -66,10 +66,4 @@
 #define XILINX_SYSACE_MEM_WIDTH	16
 
 /* Ethernet controller is Ethernet_MAC */
-#define XPAR_XEMAC_NUM_INSTANCES	1
-#define XPAR_OPB_ETHERNET_0_DEVICE_ID	0
-#define XPAR_OPB_ETHERNET_0_BASEADDR	0x40c00000
-#define XPAR_OPB_ETHERNET_0_HIGHADDR	0x40c0ffff
-#define XPAR_OPB_ETHERNET_0_DMA_PRESENT	1
-#define XPAR_OPB_ETHERNET_0_ERR_COUNT_EXIST	1
-#define XPAR_OPB_ETHERNET_0_MII_EXIST	1
+#define XILINX_EMACLITE_BASEADDR       0x40C00000
diff --git a/board/xilinx/xupv2p/xparameters.h b/board/xilinx/xupv2p/xparameters.h
index a96c693..19b81fd 100644
--- a/board/xilinx/xupv2p/xparameters.h
+++ b/board/xilinx/xupv2p/xparameters.h
@@ -55,10 +55,4 @@
 #define XILINX_SYSACE_MEM_WIDTH	16
 
 /* Ethernet controller is Ethernet_MAC */
-#define XPAR_XEMAC_NUM_INSTANCES	1
-#define XPAR_OPB_ETHERNET_0_DEVICE_ID	0
-#define XPAR_OPB_ETHERNET_0_BASEADDR	0x40c00000
-#define XPAR_OPB_ETHERNET_0_HIGHADDR	0x40c0ffff
-#define XPAR_OPB_ETHERNET_0_DMA_PRESENT	1
-#define XPAR_OPB_ETHERNET_0_ERR_COUNT_EXIST	1
-#define XPAR_OPB_ETHERNET_0_MII_EXIST	1
+#define XILINX_EMACLITE_BASEADDR       0x40C00000
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:48 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:48 +0200
Subject: [U-Boot-Users] [PATCH 01/13] microblaze: Clean Makefile from
	ancient emac driver
In-Reply-To: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-2-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 board/xilinx/ml401/Makefile  |   17 +----------------
 board/xilinx/xupv2p/Makefile |   17 +----------------
 2 files changed, 2 insertions(+), 32 deletions(-)

diff --git a/board/xilinx/ml401/Makefile b/board/xilinx/ml401/Makefile
index 9ab5633..ee9b6d5 100644
--- a/board/xilinx/ml401/Makefile
+++ b/board/xilinx/ml401/Makefile
@@ -22,25 +22,10 @@
 #
 
 include $(TOPDIR)/config.mk
-ifneq ($(OBJTREE),$(SRCTREE))
-$(shell mkdir -p $(obj)../common)
-$(shell mkdir -p $(obj)../xilinx_enet)
-endif
-
-INCS		:= -I../common -I../xilinx_enet
-CFLAGS		+= $(INCS)
-HOST_CFLAGS	+= $(INCS)
 
 LIB	= $(obj)lib$(BOARD).a
 
-COBJS	= $(BOARD).o \
-	  ../xilinx_enet/emac_adapter.o  ../xilinx_enet/xemac.o \
-	  ../xilinx_enet/xemac_options.o ../xilinx_enet/xemac_polled.o \
-	  ../xilinx_enet/xemac_intr.o ../xilinx_enet/xemac_g.o \
-	  ../xilinx_enet/xemac_intr_dma.o ../common/xipif_v1_23_b.o \
-	  ../common/xbasic_types.o ../common/xdma_channel.o \
-	  ../common/xdma_channel_sg.o ../common/xpacket_fifo_v1_00_b.o \
-	  ../common/xversion.o \
+COBJS	= $(BOARD).o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS))
diff --git a/board/xilinx/xupv2p/Makefile b/board/xilinx/xupv2p/Makefile
index 9ab5633..ee9b6d5 100644
--- a/board/xilinx/xupv2p/Makefile
+++ b/board/xilinx/xupv2p/Makefile
@@ -22,25 +22,10 @@
 #
 
 include $(TOPDIR)/config.mk
-ifneq ($(OBJTREE),$(SRCTREE))
-$(shell mkdir -p $(obj)../common)
-$(shell mkdir -p $(obj)../xilinx_enet)
-endif
-
-INCS		:= -I../common -I../xilinx_enet
-CFLAGS		+= $(INCS)
-HOST_CFLAGS	+= $(INCS)
 
 LIB	= $(obj)lib$(BOARD).a
 
-COBJS	= $(BOARD).o \
-	  ../xilinx_enet/emac_adapter.o  ../xilinx_enet/xemac.o \
-	  ../xilinx_enet/xemac_options.o ../xilinx_enet/xemac_polled.o \
-	  ../xilinx_enet/xemac_intr.o ../xilinx_enet/xemac_g.o \
-	  ../xilinx_enet/xemac_intr_dma.o ../common/xipif_v1_23_b.o \
-	  ../common/xbasic_types.o ../common/xdma_channel.o \
-	  ../common/xdma_channel_sg.o ../common/xpacket_fifo_v1_00_b.o \
-	  ../common/xversion.o \
+COBJS	= $(BOARD).o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS))
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:50 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:50 +0200
Subject: [U-Boot-Users] [PATCH 03/13] microblaze: ML401 and XUPV2P remove
	emac and emaclite reference
In-Reply-To: <1207306380-5210-3-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-4-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 include/configs/ml401.h  |   10 ++++++++--
 include/configs/xupv2p.h |   14 ++++++++++----
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/include/configs/ml401.h b/include/configs/ml401.h
index b320438..6db1c1a 100644
--- a/include/configs/ml401.h
+++ b/include/configs/ml401.h
@@ -41,8 +41,14 @@
 /*#define	CFG_RESET_ADDRESS	TEXT_BASE*/
 
 /* ethernet */
-#define CONFIG_EMACLITE		1
-#define XPAR_EMAC_0_DEVICE_ID	XPAR_OPB_ETHERNET_0_DEVICE_ID
+#ifdef XILINX_EMAC_BASEADDR
+#define CONFIG_XILINX_EMAC	1
+#else
+#ifdef XILINX_EMACLITE_BASEADDR
+#define CONFIG_XILINX_EMACLITE	1
+#endif
+#endif
+#undef ET_DEBUG
 
 /* gpio */
 #define	CFG_GPIO_0		1
diff --git a/include/configs/xupv2p.h b/include/configs/xupv2p.h
index c9320c2..eef4f72 100644
--- a/include/configs/xupv2p.h
+++ b/include/configs/xupv2p.h
@@ -36,10 +36,6 @@
 #define	CONFIG_BAUDRATE		XILINX_UART_BAUDRATE
 #define	CFG_BAUDRATE_TABLE	{ CONFIG_BAUDRATE }
 
-/* ethernet */
-#define CONFIG_EMAC	1
-#define XPAR_EMAC_0_DEVICE_ID	XPAR_XEMAC_NUM_INSTANCES
-
 /*
  * setting reset address
  *
@@ -51,6 +47,16 @@
  */
 /* #define	CFG_RESET_ADDRESS	0x36000000 */
 
+/* ethernet */
+#ifdef XILINX_EMAC_BASEADDR
+#define CONFIG_XILINX_EMAC	1
+#else
+#ifdef XILINX_EMACLITE_BASEADDR
+#define CONFIG_XILINX_EMACLITE	1
+#endif
+#endif
+#undef ET_DEBUG
+
 /* gpio */
 #ifdef XILINX_GPIO_BASEADDR
 #define	CFG_GPIO_0		1
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:51 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:51 +0200
Subject: [U-Boot-Users] [PATCH 04/13] microblaze: add Emaclite ethernet
	driver
In-Reply-To: <1207306380-5210-4-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-5-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>


Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 drivers/net/xilinx_emaclite.c |  351 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 351 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/xilinx_emaclite.c

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
new file mode 100644
index 0000000..9ba4096
--- /dev/null
+++ b/drivers/net/xilinx_emaclite.c
@@ -0,0 +1,351 @@
+/******************************************************************************
+ *
+ * XILINX IS PROVIDING THIS DESIGN, CODE, OR INFORMATION "AS IS"
+ * AS A COURTESY TO YOU, SOLELY FOR USE IN DEVELOPING PROGRAMS AND
+ * SOLUTIONS FOR XILINX DEVICES. BY PROVIDING THIS DESIGN, CODE,
+ * OR INFORMATION AS ONE POSSIBLE IMPLEMENTATION OF THIS FEATURE,
+ * APPLICATION OR STANDARD, XILINX IS MAKING NO REPRESENTATION
+ * THAT THIS IMPLEMENTATION IS FREE FROM ANY CLAIMS OF INFRINGEMENT,
+ * AND YOU ARE RESPONSIBLE FOR OBTAINING ANY RIGHTS YOU MAY REQUIRE
+ * FOR YOUR IMPLEMENTATION. XILINX EXPRESSLY DISCLAIMS ANY
+ * WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE
+ * IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR
+ * REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE FROM CLAIMS OF
+ * INFRINGEMENT, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE.
+ *
+ * (C) Copyright 2007-2008 Michal Simek
+ * Michal SIMEK <monstr at monstr.eu>
+ *
+ * (c) Copyright 2003 Xilinx Inc.
+ * All rights reserved.
+ *
+ ******************************************************************************/
+
+#include <common.h>
+#include <net.h>
+#include <config.h>
+#include <asm/io.h>
+
+#undef DEBUG
+
+#define ENET_MAX_MTU		PKTSIZE
+#define ENET_MAX_MTU_ALIGNED	PKTSIZE_ALIGN
+#define ENET_ADDR_LENGTH	6
+
+/* EmacLite constants */
+#define XEL_BUFFER_OFFSET	0x0800	/* Next buffer's offset */
+#define XEL_TPLR_OFFSET		0x07F4	/* Tx packet length */
+#define XEL_TSR_OFFSET		0x07FC	/* Tx status */
+#define XEL_RSR_OFFSET		0x17FC	/* Rx status */
+#define XEL_RXBUFF_OFFSET	0x1000	/* Receive Buffer */
+
+/* Xmit complete */
+#define XEL_TSR_XMIT_BUSY_MASK		0x00000001UL
+/* Xmit interrupt enable bit */
+#define XEL_TSR_XMIT_IE_MASK		0x00000008UL
+/* Buffer is active, SW bit only */
+#define XEL_TSR_XMIT_ACTIVE_MASK	0x80000000UL
+/* Program the MAC address */
+#define XEL_TSR_PROGRAM_MASK		0x00000002UL
+/* define for programming the MAC address into the EMAC Lite */
+#define XEL_TSR_PROG_MAC_ADDR	(XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_PROGRAM_MASK)
+
+/* Transmit packet length upper byte */
+#define XEL_TPLR_LENGTH_MASK_HI		0x0000FF00UL
+/* Transmit packet length lower byte */
+#define XEL_TPLR_LENGTH_MASK_LO		0x000000FFUL
+
+/* Recv complete */
+#define XEL_RSR_RECV_DONE_MASK		0x00000001UL
+/* Recv interrupt enable bit */
+#define XEL_RSR_RECV_IE_MASK		0x00000008UL
+
+typedef struct {
+	unsigned int baseaddress;	/* Base address for device (IPIF) */
+	unsigned int nexttxbuffertouse;	/* Next TX buffer to write to */
+	unsigned int nextrxbuffertouse;	/* Next RX buffer to read from */
+	unsigned char deviceid;		/* Unique ID of device - for future */
+} xemaclite;
+
+static xemaclite emaclite;
+
+static char etherrxbuff[PKTSIZE_ALIGN/4]; /* Receive buffer */
+
+/* hardcoded MAC address for the Xilinx EMAC Core when env is nowhere*/
+#ifdef CFG_ENV_IS_NOWHERE
+static u8 emacaddr[ENET_ADDR_LENGTH] = { 0x00, 0x0a, 0x35, 0x00, 0x22, 0x01 };
+#else
+static u8 emacaddr[ENET_ADDR_LENGTH];
+#endif
+
+void xemaclite_alignedread (u32 * srcptr, void *destptr, unsigned bytecount)
+{
+	unsigned int i;
+	u32 alignbuffer;
+	u32 *to32ptr;
+	u32 *from32ptr;
+	u8 *to8ptr;
+	u8 *from8ptr;
+
+	from32ptr = (u32 *) srcptr;
+
+	/* Word aligned buffer, no correction needed. */
+	to32ptr = (u32 *) destptr;
+	while (bytecount > 3) {
+		*to32ptr++ = *from32ptr++;
+		bytecount -= 4;
+	}
+	to8ptr = (u8 *) to32ptr;
+
+	alignbuffer = *from32ptr++;
+	from8ptr = (u8 *) & alignbuffer;
+
+	for (i = 0; i < bytecount; i++) {
+		*to8ptr++ = *from8ptr++;
+	}
+}
+
+void xemaclite_alignedwrite (void *srcptr, u32 destptr, unsigned bytecount)
+{
+	unsigned i;
+	u32 alignbuffer;
+	u32 *to32ptr = (u32 *) destptr;
+	u32 *from32ptr;
+	u8 *to8ptr;
+	u8 *from8ptr;
+
+	from32ptr = (u32 *) srcptr;
+	while (bytecount > 3) {
+
+		*to32ptr++ = *from32ptr++;
+		bytecount -= 4;
+	}
+
+	alignbuffer = 0;
+	to8ptr = (u8 *) & alignbuffer;
+	from8ptr = (u8 *) from32ptr;
+
+	for (i = 0; i < bytecount; i++) {
+		*to8ptr++ = *from8ptr++;
+	}
+
+	*to32ptr++ = alignbuffer;
+}
+
+void eth_halt (void)
+{
+	debug ("eth_halt\n");
+}
+
+int eth_init (bd_t * bis)
+{
+	debug ("EmacLite Initialization Started\n");
+	memset (&emaclite, 0, sizeof (xemaclite));
+	emaclite.baseaddress = XILINX_EMACLITE_BASEADDR;
+
+	if (!getenv("ethaddr")) {
+		memcpy(bis->bi_enetaddr, emacaddr, ENET_ADDR_LENGTH);
+	}
+
+/*
+ * TX - TX_PING & TX_PONG initialization
+ */
+	/* Restart PING TX */
+	out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET, 0);
+	/* Copy MAC address */
+	xemaclite_alignedwrite (bis->bi_enetaddr,
+		emaclite.baseaddress, ENET_ADDR_LENGTH);
+	/* Set the length */
+	out_be32 (emaclite.baseaddress + XEL_TPLR_OFFSET, ENET_ADDR_LENGTH);
+	/* Update the MAC address in the EMAC Lite */
+	out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET, XEL_TSR_PROG_MAC_ADDR);
+	/* Wait for EMAC Lite to finish with the MAC address update */
+	while ((in_be32 (emaclite.baseaddress + XEL_TSR_OFFSET) &
+		XEL_TSR_PROG_MAC_ADDR) != 0) ;
+
+#ifdef CONFIG_XILINX_EMACLITE_TX_PING_PONG
+	/* The same operation with PONG TX */
+	out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET + XEL_BUFFER_OFFSET, 0);
+	xemaclite_alignedwrite (bis->bi_enetaddr, emaclite.baseaddress +
+		XEL_BUFFER_OFFSET, ENET_ADDR_LENGTH);
+	out_be32 (emaclite.baseaddress + XEL_TPLR_OFFSET, ENET_ADDR_LENGTH);
+	out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET + XEL_BUFFER_OFFSET,
+		XEL_TSR_PROG_MAC_ADDR);
+	while ((in_be32 (emaclite.baseaddress + XEL_TSR_OFFSET +
+		XEL_BUFFER_OFFSET) & XEL_TSR_PROG_MAC_ADDR) != 0) ;
+#endif
+
+/*
+ * RX - RX_PING & RX_PONG initialization
+ */
+	/* Write out the value to flush the RX buffer */
+	out_be32 (emaclite.baseaddress + XEL_RSR_OFFSET, XEL_RSR_RECV_IE_MASK);
+#ifdef CONFIG_XILINX_EMACLITE_RX_PING_PONG
+	out_be32 (emaclite.baseaddress + XEL_RSR_OFFSET + XEL_BUFFER_OFFSET,
+		XEL_RSR_RECV_IE_MASK);
+#endif
+
+	debug ("EmacLite Initialization complete\n");
+	return 0;
+}
+
+int xemaclite_txbufferavailable (xemaclite * instanceptr)
+{
+	u32 reg;
+	u32 txpingbusy;
+	u32 txpongbusy;
+	/*
+	 * Read the other buffer register
+	 * and determine if the other buffer is available
+	 */
+	reg = in_be32 (instanceptr->baseaddress +
+			instanceptr->nexttxbuffertouse + 0);
+	txpingbusy = ((reg & XEL_TSR_XMIT_BUSY_MASK) ==
+			XEL_TSR_XMIT_BUSY_MASK);
+
+	reg = in_be32 (instanceptr->baseaddress +
+			(instanceptr->nexttxbuffertouse ^ XEL_TSR_OFFSET) + 0);
+	txpongbusy = ((reg & XEL_TSR_XMIT_BUSY_MASK) ==
+			XEL_TSR_XMIT_BUSY_MASK);
+
+	return (!(txpingbusy && txpongbusy));
+}
+
+int eth_send (volatile void *ptr, int len) {
+
+	unsigned int reg;
+	unsigned int baseaddress;
+
+	unsigned maxtry = 1000;
+
+	if (len > ENET_MAX_MTU)
+		len = ENET_MAX_MTU;
+
+	while (!xemaclite_txbufferavailable (&emaclite) && maxtry) {
+		udelay (10);
+		maxtry--;
+	}
+
+	if (!maxtry) {
+		printf ("Error: Timeout waiting for ethernet TX buffer\n");
+		/* Restart PING TX */
+		out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET, 0);
+#ifdef CONFIG_XILINX_EMACLITE_TX_PING_PONG
+		out_be32 (emaclite.baseaddress + XEL_TSR_OFFSET +
+		XEL_BUFFER_OFFSET, 0);
+#endif
+		return 0;
+	}
+
+	/* Determine the expected TX buffer address */
+	baseaddress = (emaclite.baseaddress + emaclite.nexttxbuffertouse);
+
+	/* Determine if the expected buffer address is empty */
+	reg = in_be32 (baseaddress + XEL_TSR_OFFSET);
+	if (((reg & XEL_TSR_XMIT_BUSY_MASK) == 0)
+		&& ((in_be32 ((baseaddress) + XEL_TSR_OFFSET)
+			& XEL_TSR_XMIT_ACTIVE_MASK) == 0)) {
+
+#ifdef CONFIG_XILINX_EMACLITE_TX_PING_PONG
+		emaclite.nexttxbuffertouse ^= XEL_BUFFER_OFFSET;
+#endif
+		debug ("Send packet from 0x%x\n", baseaddress);
+		/* Write the frame to the buffer */
+		xemaclite_alignedwrite ((void *) ptr, baseaddress, len);
+		out_be32 (baseaddress + XEL_TPLR_OFFSET,(len &
+			(XEL_TPLR_LENGTH_MASK_HI | XEL_TPLR_LENGTH_MASK_LO)));
+		reg = in_be32 (baseaddress + XEL_TSR_OFFSET);
+		reg |= XEL_TSR_XMIT_BUSY_MASK;
+		if ((reg & XEL_TSR_XMIT_IE_MASK) != 0) {
+			reg |= XEL_TSR_XMIT_ACTIVE_MASK;
+		}
+		out_be32 (baseaddress + XEL_TSR_OFFSET, reg);
+		return 1;
+	}
+#ifdef CONFIG_XILINX_EMACLITE_TX_PING_PONG
+	/* Switch to second buffer */
+	baseaddress ^= XEL_BUFFER_OFFSET;
+	/* Determine if the expected buffer address is empty */
+	reg = in_be32 (baseaddress + XEL_TSR_OFFSET);
+	if (((reg & XEL_TSR_XMIT_BUSY_MASK) == 0)
+		&& ((in_be32 ((baseaddress) + XEL_TSR_OFFSET)
+			& XEL_TSR_XMIT_ACTIVE_MASK) == 0)) {
+		debug ("Send packet from 0x%x\n", baseaddress);
+		/* Write the frame to the buffer */
+		xemaclite_alignedwrite ((void *) ptr, baseaddress, len);
+		out_be32 (baseaddress + XEL_TPLR_OFFSET,(len &
+			(XEL_TPLR_LENGTH_MASK_HI | XEL_TPLR_LENGTH_MASK_LO)));
+		reg = in_be32 (baseaddress + XEL_TSR_OFFSET);
+		reg |= XEL_TSR_XMIT_BUSY_MASK;
+		if ((reg & XEL_TSR_XMIT_IE_MASK) != 0) {
+			reg |= XEL_TSR_XMIT_ACTIVE_MASK;
+		}
+		out_be32 (baseaddress + XEL_TSR_OFFSET, reg);
+		return 1;
+	}
+#endif
+	puts ("Error while sending frame\n");
+	return 0;
+}
+
+int eth_rx (void)
+{
+	unsigned int length;
+	unsigned int reg;
+	unsigned int baseaddress;
+
+	baseaddress = emaclite.baseaddress + emaclite.nextrxbuffertouse;
+	reg = in_be32 (baseaddress + XEL_RSR_OFFSET);
+	debug ("Testing data at address 0x%x\n", baseaddress);
+	if ((reg & XEL_RSR_RECV_DONE_MASK) == XEL_RSR_RECV_DONE_MASK) {
+#ifdef CONFIG_XILINX_EMACLITE_RX_PING_PONG
+		emaclite.nextrxbuffertouse ^= XEL_BUFFER_OFFSET;
+#endif
+	} else {
+#ifndef CONFIG_XILINX_EMACLITE_RX_PING_PONG
+		debug ("No data was available - address 0x%x\n", baseaddress);
+		return 0;
+#else
+		baseaddress ^= XEL_BUFFER_OFFSET;
+		reg = in_be32 (baseaddress + XEL_RSR_OFFSET);
+		if ((reg & XEL_RSR_RECV_DONE_MASK) !=
+					XEL_RSR_RECV_DONE_MASK) {
+			debug ("No data was available - address 0x%x\n",
+					baseaddress);
+			return 0;
+		}
+#endif
+	}
+	/* Get the length of the frame that arrived */
+	switch(((in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 0xC)) &
+			0xFFFF0000 ) >> 16) {
+		case 0x806:
+			length = 42 + 20; /* FIXME size of ARP */
+			debug ("ARP Packet\n");
+			break;
+		case 0x800:
+			length = 14 + 14 +
+			(((in_be32 (baseaddress + XEL_RXBUFF_OFFSET + 0x10)) &
+			0xFFFF0000) >> 16); /* FIXME size of IP packet */
+			debug ("IP Packet\n");
+			break;
+		default:
+			debug ("Other Packet\n");
+			length = ENET_MAX_MTU;
+			break;
+	}
+
+	xemaclite_alignedread ((u32 *) (baseaddress + XEL_RXBUFF_OFFSET),
+			etherrxbuff, length);
+
+	/* Acknowledge the frame */
+	reg = in_be32 (baseaddress + XEL_RSR_OFFSET);
+	reg &= ~XEL_RSR_RECV_DONE_MASK;
+	out_be32 (baseaddress + XEL_RSR_OFFSET, reg);
+
+	debug ("Packet receive from 0x%x, length %dB\n", baseaddress, length);
+	NetReceive ((uchar *) etherrxbuff, length);
+	return 1;
+
+}
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:47 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:47 +0200
Subject: [U-Boot-Users] Microblaze updates
Message-ID: <1207306380-5210-1-git-send-email-monstr@seznam.cz>

Hi everybody,

I update microblaze repository. Every changes are in testing branch. 

Thanks for your review, 

Michal Simek
www.monstr.eu

The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
  Bartlomiej Sieka (1):
        Fix host tool build breakage, take two

are available in the git repository at:

  . testing 

Michal Simek (13):
      microblaze: Clean Makefile from ancient emac driver
      microblaze: remove old setting for emac driver
      microblaze: ML401 and XUPV2P remove emac and emaclite reference
      microblaze: add Emaclite ethernet driver
      microblaze: add Emac ethernet driver
      microblaze: Add Emac driver to Makefile
      microblaze: Add Emaclite driver to Makefile
      microblaze: clean uart16550 and uartlite handling
      microblaze: ml401 - add ifdef for GPIO
      microblaze: ml401 fix config file for supporting FDT
      microblaze: xupv2p fix config file for supporting FDT
      microblaze: clean microblaze_config.mk
      microblaze: Sort microblaze boards in MAKEALL script

 MAKEALL                           |    2 +-    
 board/xilinx/ml401/Makefile       |   17 +--  
 board/xilinx/ml401/xparameters.h  |   12 +-   
 board/xilinx/xupv2p/Makefile      |   17 +--  
 board/xilinx/xupv2p/xparameters.h |   12 +-   
 drivers/net/Makefile              |    2 +
 drivers/net/xilinx_emac.c         |  462 +++++++++++++++++++++++++++++++++++++
 drivers/net/xilinx_emaclite.c     |  351 ++++++++++++++++++++++++++++
 include/configs/ml401.h           |   42 +++- 
 include/configs/xupv2p.h          |   37 +++- 
 microblaze_config.mk              |   16 +-   
 11 files changed, 890 insertions(+), 80 deletions(-)
 create mode 100644 drivers/net/xilinx_emac.c
 create mode 100644 drivers/net/xilinx_emaclite.c






From monstr at seznam.cz  Fri Apr  4 12:52:53 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:53 +0200
Subject: [U-Boot-Users] [PATCH 06/13] microblaze: Add Emac driver to Makefile
In-Reply-To: <1207306380-5210-6-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-7-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 drivers/net/Makefile |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 320dc3e..e6b0543 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -59,6 +59,7 @@ COBJS-y += tsec.o
 COBJS-y += tsi108_eth.o
 COBJS-y += uli526x.o
 COBJS-y += vsc7385.o
+COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
 
 COBJS	:= $(COBJS-y)
 SRCS 	:= $(COBJS:.o=.c)
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:52 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:52 +0200
Subject: [U-Boot-Users] [PATCH 05/13] microblaze: add Emac ethernet driver
In-Reply-To: <1207306380-5210-5-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-6-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>


Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 drivers/net/xilinx_emac.c |  462 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 462 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/xilinx_emac.c

diff --git a/drivers/net/xilinx_emac.c b/drivers/net/xilinx_emac.c
new file mode 100644
index 0000000..c7f1a2a
--- /dev/null
+++ b/drivers/net/xilinx_emac.c
@@ -0,0 +1,462 @@
+/******************************************************************************
+ *
+ * XILINX IS PROVIDING THIS DESIGN, CODE, OR INFORMATION "AS IS"
+ * AS A COURTESY TO YOU, SOLELY FOR USE IN DEVELOPING PROGRAMS AND
+ * SOLUTIONS FOR XILINX DEVICES. BY PROVIDING THIS DESIGN, CODE,
+ * OR INFORMATION AS ONE POSSIBLE IMPLEMENTATION OF THIS FEATURE,
+ * APPLICATION OR STANDARD, XILINX IS MAKING NO REPRESENTATION
+ * THAT THIS IMPLEMENTATION IS FREE FROM ANY CLAIMS OF INFRINGEMENT,
+ * AND YOU ARE RESPONSIBLE FOR OBTAINING ANY RIGHTS YOU MAY REQUIRE
+ * FOR YOUR IMPLEMENTATION. XILINX EXPRESSLY DISCLAIMS ANY
+ * WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE
+ * IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR
+ * REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE FROM CLAIMS OF
+ * INFRINGEMENT, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE.
+ *
+ * (C) Copyright 2007-2008 Michal Simek
+ * Michal SIMEK <monstr at monstr.eu>
+ *
+ * (c) Copyright 2003 Xilinx Inc.
+ * All rights reserved.
+ *
+ ******************************************************************************/
+
+#include <config.h>
+#include <common.h>
+#include <net.h>
+#include <asm/io.h>
+
+#include <asm/asm.h>
+
+#undef DEBUG
+
+typedef struct {
+	u32 regbaseaddress;	/* Base address of registers */
+	u32 databaseaddress;	/* Base address of data for FIFOs */
+} xpacketfifov100b;
+
+typedef struct {
+	u32 baseaddress;	/* Base address (of IPIF) */
+	u32 isstarted;		/* Device is currently started 0-no, 1-yes */
+	xpacketfifov100b recvfifo;	/* FIFO used to receive frames */
+	xpacketfifov100b sendfifo;	/* FIFO used to send frames */
+} xemac;
+
+#define XIIF_V123B_IISR_OFFSET	32UL /* IP interrupt status register */
+#define XIIF_V123B_RESET_MASK		0xAUL
+#define XIIF_V123B_RESETR_OFFSET	64UL /* reset register */
+
+/* This constant is used with the Reset Register */
+#define XPF_RESET_FIFO_MASK		0x0000000A
+#define XPF_COUNT_STATUS_REG_OFFSET	4UL
+
+/* These constants are used with the Occupancy/Vacancy Count Register. This
+ * register also contains FIFO status */
+#define XPF_COUNT_MASK			0x0000FFFF
+#define XPF_DEADLOCK_MASK		0x20000000
+
+/* Offset of the MAC registers from the IPIF base address */
+#define XEM_REG_OFFSET		0x1100UL
+
+/*
+ * Register offsets for the Ethernet MAC. Each register is 32 bits.
+ */
+#define XEM_ECR_OFFSET	(XEM_REG_OFFSET + 0x4)	/* MAC Control */
+#define XEM_SAH_OFFSET	(XEM_REG_OFFSET + 0xC)	/* Station addr, high */
+#define XEM_SAL_OFFSET	(XEM_REG_OFFSET + 0x10)	/* Station addr, low */
+#define XEM_RPLR_OFFSET	(XEM_REG_OFFSET + 0x1C)	/* Rx packet length */
+#define XEM_TPLR_OFFSET	(XEM_REG_OFFSET + 0x20)	/* Tx packet length */
+#define XEM_TSR_OFFSET	(XEM_REG_OFFSET + 0x24)	/* Tx status */
+
+#define XEM_PFIFO_OFFSET	0x2000UL
+/* Tx registers */
+#define XEM_PFIFO_TXREG_OFFSET	(XEM_PFIFO_OFFSET + 0x0)
+/* Rx registers */
+#define XEM_PFIFO_RXREG_OFFSET	(XEM_PFIFO_OFFSET + 0x10)
+/* Tx keyhole */
+#define XEM_PFIFO_TXDATA_OFFSET	(XEM_PFIFO_OFFSET + 0x100)
+/* Rx keyhole */
+#define XEM_PFIFO_RXDATA_OFFSET	(XEM_PFIFO_OFFSET + 0x200)
+
+/*
+ * EMAC Interrupt Registers (Status and Enable) masks. These registers are
+ * part of the IPIF IP Interrupt registers
+ */
+/* A mask for all transmit interrupts, used in polled mode */
+#define XEM_EIR_XMIT_ALL_MASK	(XEM_EIR_XMIT_DONE_MASK |\
+				XEM_EIR_XMIT_ERROR_MASK | \
+				XEM_EIR_XMIT_SFIFO_EMPTY_MASK |\
+				XEM_EIR_XMIT_LFIFO_FULL_MASK)
+
+/* Xmit complete */
+#define XEM_EIR_XMIT_DONE_MASK		0x00000001UL
+/* Recv complete */
+#define XEM_EIR_RECV_DONE_MASK		0x00000002UL
+/* Xmit error */
+#define XEM_EIR_XMIT_ERROR_MASK		0x00000004UL
+/* Recv error */
+#define XEM_EIR_RECV_ERROR_MASK		0x00000008UL
+/* Xmit status fifo empty */
+#define XEM_EIR_XMIT_SFIFO_EMPTY_MASK	0x00000010UL
+/* Recv length fifo empty */
+#define XEM_EIR_RECV_LFIFO_EMPTY_MASK	0x00000020UL
+/* Xmit length fifo full */
+#define XEM_EIR_XMIT_LFIFO_FULL_MASK	0x00000040UL
+/* Recv length fifo overrun */
+#define XEM_EIR_RECV_LFIFO_OVER_MASK	0x00000080UL
+/* Recv length fifo underrun */
+#define XEM_EIR_RECV_LFIFO_UNDER_MASK	0x00000100UL
+/* Xmit status fifo overrun */
+#define XEM_EIR_XMIT_SFIFO_OVER_MASK	0x00000200UL
+/* Transmit status fifo underrun */
+#define XEM_EIR_XMIT_SFIFO_UNDER_MASK	0x00000400UL
+/* Transmit length fifo overrun */
+#define XEM_EIR_XMIT_LFIFO_OVER_MASK	0x00000800UL
+/* Transmit length fifo underrun */
+#define XEM_EIR_XMIT_LFIFO_UNDER_MASK	0x00001000UL
+/* Transmit pause pkt received */
+#define XEM_EIR_XMIT_PAUSE_MASK		0x00002000UL
+
+/*
+ * EMAC Control Register (ECR)
+ */
+/* Full duplex mode */
+#define XEM_ECR_FULL_DUPLEX_MASK	0x80000000UL
+/* Reset transmitter */
+#define XEM_ECR_XMIT_RESET_MASK		0x40000000UL
+/* Enable transmitter */
+#define XEM_ECR_XMIT_ENABLE_MASK	0x20000000UL
+/* Reset receiver */
+#define XEM_ECR_RECV_RESET_MASK		0x10000000UL
+/* Enable receiver */
+#define XEM_ECR_RECV_ENABLE_MASK	0x08000000UL
+/* Enable PHY */
+#define XEM_ECR_PHY_ENABLE_MASK		0x04000000UL
+/* Enable xmit pad insert */
+#define XEM_ECR_XMIT_PAD_ENABLE_MASK	0x02000000UL
+/* Enable xmit FCS insert */
+#define XEM_ECR_XMIT_FCS_ENABLE_MASK	0x01000000UL
+/* Enable unicast addr */
+#define XEM_ECR_UNICAST_ENABLE_MASK	0x00020000UL
+/* Enable broadcast addr */
+#define XEM_ECR_BROAD_ENABLE_MASK	0x00008000UL
+
+/*
+ * Transmit Status Register (TSR)
+ */
+/* Transmit excess deferral */
+#define XEM_TSR_EXCESS_DEFERRAL_MASK	0x80000000UL
+/* Transmit late collision */
+#define XEM_TSR_LATE_COLLISION_MASK	0x01000000UL
+
+#define ENET_MAX_MTU		PKTSIZE
+#define ENET_ADDR_LENGTH	6
+
+static unsigned int etherrxbuff[PKTSIZE_ALIGN/4]; /* Receive buffer */
+
+static u8 emacaddr[ENET_ADDR_LENGTH] = { 0x00, 0x0a, 0x35, 0x00, 0x22, 0x01 };
+
+static xemac emac;
+
+void eth_halt(void)
+{
+	debug ("eth_halt\n");
+}
+
+int eth_init(bd_t * bis)
+{
+	u32 helpreg;
+	debug ("EMAC Initialization Started\n\r");
+
+	if (emac.isstarted) {
+		puts("Emac is started\n");
+		return 0;
+	}
+
+	memset (&emac, 0, sizeof (xemac));
+
+	emac.baseaddress = XILINX_EMAC_BASEADDR;
+
+	/* Setting up FIFOs */
+	emac.recvfifo.regbaseaddress = emac.baseaddress +
+					XEM_PFIFO_RXREG_OFFSET;
+	emac.recvfifo.databaseaddress = emac.baseaddress +
+					XEM_PFIFO_RXDATA_OFFSET;
+	out_be32 (emac.recvfifo.regbaseaddress, XPF_RESET_FIFO_MASK);
+
+	emac.sendfifo.regbaseaddress = emac.baseaddress +
+					XEM_PFIFO_TXREG_OFFSET;
+	emac.sendfifo.databaseaddress = emac.baseaddress +
+					XEM_PFIFO_TXDATA_OFFSET;
+	out_be32 (emac.sendfifo.regbaseaddress, XPF_RESET_FIFO_MASK);
+
+	/* Reset the entire IPIF */
+	out_be32 (emac.baseaddress + XIIF_V123B_RESETR_OFFSET,
+					XIIF_V123B_RESET_MASK);
+
+	/* Stopping EMAC for setting up MAC */
+	helpreg = in_be32 (emac.baseaddress + XEM_ECR_OFFSET);
+	helpreg &= ~(XEM_ECR_XMIT_ENABLE_MASK | XEM_ECR_RECV_ENABLE_MASK);
+	out_be32 (emac.baseaddress + XEM_ECR_OFFSET, helpreg);
+
+	if (!getenv("ethaddr")) {
+		memcpy(bis->bi_enetaddr, emacaddr, ENET_ADDR_LENGTH);
+	}
+
+	/* Set the device station address high and low registers */
+	helpreg = (bis->bi_enetaddr[0] << 8) | bis->bi_enetaddr[1];
+	out_be32 (emac.baseaddress + XEM_SAH_OFFSET, helpreg);
+	helpreg = (bis->bi_enetaddr[2] << 24) | (bis->bi_enetaddr[3] << 16) |
+			(bis->bi_enetaddr[4] << 8) | bis->bi_enetaddr[5];
+	out_be32 (emac.baseaddress + XEM_SAL_OFFSET, helpreg);
+
+	helpreg = XEM_ECR_UNICAST_ENABLE_MASK | XEM_ECR_BROAD_ENABLE_MASK |
+		XEM_ECR_FULL_DUPLEX_MASK | XEM_ECR_XMIT_FCS_ENABLE_MASK |
+		XEM_ECR_XMIT_PAD_ENABLE_MASK | XEM_ECR_PHY_ENABLE_MASK;
+	out_be32 (emac.baseaddress + XEM_ECR_OFFSET, helpreg);
+
+	emac.isstarted = 1;
+
+	/* Enable the transmitter, and receiver */
+	helpreg = in_be32 (emac.baseaddress + XEM_ECR_OFFSET);
+	helpreg &= ~(XEM_ECR_XMIT_RESET_MASK | XEM_ECR_RECV_RESET_MASK);
+	helpreg |= (XEM_ECR_XMIT_ENABLE_MASK | XEM_ECR_RECV_ENABLE_MASK);
+	out_be32 (emac.baseaddress + XEM_ECR_OFFSET, helpreg);
+
+	printf("EMAC Initialization complete\n\r");
+	return 0;
+}
+
+int eth_send(volatile void *ptr, int len)
+{
+	u32 intrstatus;
+	u32 xmitstatus;
+	u32 fifocount;
+	u32 wordcount;
+	u32 extrabytecount;
+	u32 *wordbuffer = (u32 *) ptr;
+
+	if (len > ENET_MAX_MTU)
+		len = ENET_MAX_MTU;
+
+	/*
+	 * Check for overruns and underruns for the transmit status and length
+	 * FIFOs and make sure the send packet FIFO is not deadlocked.
+	 * Any of these conditions is bad enough that we do not want to
+	 * continue. The upper layer software should reset the device to resolve
+	 * the error.
+	 */
+	intrstatus = in_be32 ((emac.baseaddress) + XIIF_V123B_IISR_OFFSET);
+	if (intrstatus & (XEM_EIR_XMIT_SFIFO_OVER_MASK |
+			XEM_EIR_XMIT_LFIFO_OVER_MASK)) {
+		debug ("Transmitting overrun error\n");
+		return 0;
+	} else if (intrstatus & (XEM_EIR_XMIT_SFIFO_UNDER_MASK |
+			XEM_EIR_XMIT_LFIFO_UNDER_MASK)) {
+		debug ("Transmitting underrun error\n");
+		return 0;
+	} else if (in_be32 (emac.sendfifo.regbaseaddress +
+			XPF_COUNT_STATUS_REG_OFFSET) & XPF_DEADLOCK_MASK) {
+		debug ("Transmitting fifo error\n");
+		return 0;
+	}
+
+	/*
+	 * Before writing to the data FIFO, make sure the length FIFO is not
+	 * full. The data FIFO might not be full yet even though the length FIFO
+	 * is. This avoids an overrun condition on the length FIFO and keeps the
+	 * FIFOs in sync.
+	 *
+	 * Clear the latched LFIFO_FULL bit so next time around the most
+	 * current status is represented
+	 */
+	if (intrstatus & XEM_EIR_XMIT_LFIFO_FULL_MASK) {
+		out_be32 ((emac.baseaddress) + XIIF_V123B_IISR_OFFSET,
+			intrstatus & XEM_EIR_XMIT_LFIFO_FULL_MASK);
+		debug ("Fifo is full\n");
+		return 0;
+	}
+
+	/* get the count of how many words may be inserted into the FIFO */
+	fifocount = in_be32 (emac.sendfifo.regbaseaddress +
+				XPF_COUNT_STATUS_REG_OFFSET) & XPF_COUNT_MASK;
+	wordcount = len >> 2;
+	extrabytecount = len & 0x3;
+
+	if (fifocount < wordcount) {
+		debug ("Sending packet is larger then size of FIFO\n");
+		return 0;
+	}
+
+	for (fifocount = 0; fifocount < wordcount; fifocount++) {
+		out_be32 (emac.sendfifo.databaseaddress, wordbuffer[fifocount]);
+	}
+	if (extrabytecount > 0) {
+		u32 lastword = 0;
+		u8 *extrabytesbuffer = (u8 *) (wordbuffer + wordcount);
+
+		if (extrabytecount == 1) {
+			lastword = extrabytesbuffer[0] << 24;
+		} else if (extrabytecount == 2) {
+			lastword = extrabytesbuffer[0] << 24 |
+				extrabytesbuffer[1] << 16;
+		} else if (extrabytecount == 3) {
+			lastword = extrabytesbuffer[0] << 24 |
+				extrabytesbuffer[1] << 16 |
+				extrabytesbuffer[2] << 8;
+		}
+		out_be32 (emac.sendfifo.databaseaddress, lastword);
+	}
+
+	/* Loop on the MAC's status to wait for any pause to complete */
+	intrstatus = in_be32 ((emac.baseaddress) + XIIF_V123B_IISR_OFFSET);
+	while ((intrstatus & XEM_EIR_XMIT_PAUSE_MASK) != 0) {
+		intrstatus = in_be32 ((emac.baseaddress) +
+					XIIF_V123B_IISR_OFFSET);
+		/* Clear the pause status from the transmit status register */
+		out_be32 ((emac.baseaddress) + XIIF_V123B_IISR_OFFSET,
+				intrstatus & XEM_EIR_XMIT_PAUSE_MASK);
+	}
+
+	/*
+	 * Set the MAC's transmit packet length register to tell it to transmit
+	 */
+	out_be32 (emac.baseaddress + XEM_TPLR_OFFSET, len);
+
+	/*
+	 * Loop on the MAC's status to wait for the transmit to complete.
+	 * The transmit status is in the FIFO when the XMIT_DONE bit is set.
+	 */
+	do {
+		intrstatus = in_be32 ((emac.baseaddress) +
+						XIIF_V123B_IISR_OFFSET);
+	}
+	while ((intrstatus & XEM_EIR_XMIT_DONE_MASK) == 0);
+
+	xmitstatus = in_be32 (emac.baseaddress + XEM_TSR_OFFSET);
+
+	if (intrstatus & (XEM_EIR_XMIT_SFIFO_OVER_MASK |
+					XEM_EIR_XMIT_LFIFO_OVER_MASK)) {
+		debug ("Transmitting overrun error\n");
+		return 0;
+	} else if (intrstatus & (XEM_EIR_XMIT_SFIFO_UNDER_MASK |
+					XEM_EIR_XMIT_LFIFO_UNDER_MASK)) {
+		debug ("Transmitting underrun error\n");
+		return 0;
+	}
+
+	/* Clear the interrupt status register of transmit statuses */
+	out_be32 ((emac.baseaddress) + XIIF_V123B_IISR_OFFSET,
+				intrstatus & XEM_EIR_XMIT_ALL_MASK);
+
+	/*
+	 * Collision errors are stored in the transmit status register
+	 * instead of the interrupt status register
+	 */
+	if ((xmitstatus & XEM_TSR_EXCESS_DEFERRAL_MASK) ||
+				(xmitstatus & XEM_TSR_LATE_COLLISION_MASK)) {
+		debug ("Transmitting collision error\n");
+		return 0;
+	}
+	return 1;
+}
+
+int eth_rx(void)
+{
+	u32 pktlength;
+	u32 intrstatus;
+	u32 fifocount;
+	u32 wordcount;
+	u32 extrabytecount;
+	u32 lastword;
+	u8 *extrabytesbuffer;
+
+	if (in_be32 (emac.recvfifo.regbaseaddress + XPF_COUNT_STATUS_REG_OFFSET)
+			& XPF_DEADLOCK_MASK) {
+		out_be32 (emac.recvfifo.regbaseaddress, XPF_RESET_FIFO_MASK);
+		debug ("Receiving FIFO deadlock\n");
+		return 0;
+	}
+
+	/*
+	 * Get the interrupt status to know what happened (whether an error
+	 * occurred and/or whether frames have been received successfully).
+	 * When clearing the intr status register, clear only statuses that
+	 * pertain to receive.
+	 */
+	intrstatus = in_be32 ((emac.baseaddress) + XIIF_V123B_IISR_OFFSET);
+	/*
+	 * Before reading from the length FIFO, make sure the length FIFO is not
+	 * empty. We could cause an underrun error if we try to read from an
+	 * empty FIFO.
+	 */
+	if (!(intrstatus & XEM_EIR_RECV_DONE_MASK)) {
+		/* debug ("Receiving FIFO is empty\n"); */
+		return 0;
+	}
+
+	/*
+	 * Determine, from the MAC, the length of the next packet available
+	 * in the data FIFO (there should be a non-zero length here)
+	 */
+	pktlength = in_be32 (emac.baseaddress + XEM_RPLR_OFFSET);
+	if (!pktlength) {
+		return 0;
+	}
+
+	/*
+	 * Write the RECV_DONE bit in the status register to clear it. This bit
+	 * indicates the RPLR is non-empty, and we know it's set at this point.
+	 * We clear it so that subsequent entry into this routine will reflect
+	 * the current status. This is done because the non-empty bit is latched
+	 * in the IPIF, which means it may indicate a non-empty condition even
+	 * though there is something in the FIFO.
+	 */
+	out_be32 ((emac.baseaddress) + XIIF_V123B_IISR_OFFSET,
+						XEM_EIR_RECV_DONE_MASK);
+
+	fifocount = in_be32 (emac.recvfifo.regbaseaddress +
+				XPF_COUNT_STATUS_REG_OFFSET) & XPF_COUNT_MASK;
+
+	if ((fifocount * 4) < pktlength) {
+		debug ("Receiving FIFO is smaller than packet size.\n");
+		return 0;
+	}
+
+	wordcount = pktlength >> 2;
+	extrabytecount = pktlength & 0x3;
+
+	for (fifocount = 0; fifocount < wordcount; fifocount++) {
+		etherrxbuff[fifocount] =
+				in_be32 (emac.recvfifo.databaseaddress);
+	}
+
+	/*
+	 * if there are extra bytes to handle, read the last word from the FIFO
+	 * and insert the extra bytes into the buffer
+	 */
+	if (extrabytecount > 0) {
+		extrabytesbuffer = (u8 *) (etherrxbuff + wordcount);
+
+		lastword = in_be32 (emac.recvfifo.databaseaddress);
+
+		/*
+		 * one extra byte in the last word, put the byte into the next
+		 * location of the buffer, bytes in a word of the FIFO are
+		 * ordered from most significant byte to least
+		 */
+		if (extrabytecount == 1) {
+			extrabytesbuffer[0] = (u8) (lastword >> 24);
+		} else if (extrabytecount == 2) {
+			extrabytesbuffer[0] = (u8) (lastword >> 24);
+			extrabytesbuffer[1] = (u8) (lastword >> 16);
+		} else if (extrabytecount == 3) {
+			extrabytesbuffer[0] = (u8) (lastword >> 24);
+			extrabytesbuffer[1] = (u8) (lastword >> 16);
+			extrabytesbuffer[2] = (u8) (lastword >> 8);
+		}
+	}
+	NetReceive((uchar *)etherrxbuff, pktlength);
+	return 1;
+}
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:54 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:54 +0200
Subject: [U-Boot-Users] [PATCH 07/13] microblaze: Add Emaclite driver to
	Makefile
In-Reply-To: <1207306380-5210-7-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-8-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 drivers/net/Makefile |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index e6b0543..1ae517d 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -60,6 +60,7 @@ COBJS-y += tsi108_eth.o
 COBJS-y += uli526x.o
 COBJS-y += vsc7385.o
 COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
+COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
 
 COBJS	:= $(COBJS-y)
 SRCS 	:= $(COBJS:.o=.c)
-- 
1.5.4.GIT




From mail2lohithb at yahoo.com  Fri Apr  4 12:56:40 2008
From: mail2lohithb at yahoo.com (Lohith B)
Date: Fri, 4 Apr 2008 16:26:40 +0530 (IST)
Subject: [U-Boot-Users] regarding u-boot porting
Message-ID: <451321.52005.qm@web94604.mail.in2.yahoo.com>

An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080404/67f3f26c/attachment.htm 

From toertel at gmail.com  Fri Apr  4 13:24:18 2008
From: toertel at gmail.com (Mark Jonas)
Date: Fri, 4 Apr 2008 13:24:18 +0200
Subject: [U-Boot-Users] [PATCH 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: <47F4E6F9.1080205@gmail.com>
References: <Pine.LNX.4.64.0803261426520.5050@axis700.grange>
	<Pine.LNX.4.64.0803261452310.5050@axis700.grange>
	<9b3c8e40804020503h7ca1624ehb90830536b0423e9@mail.gmail.com>
	<f8328f7c0804020518u19487b37x2d0ac6ed53ae0f4c@mail.gmail.com>
	<9b3c8e40804022351h5c5b40e7pccc327e3032f5a3c@mail.gmail.com>
	<47F4E6F9.1080205@gmail.com>
Message-ID: <9b3c8e40804040424k722bcf82me026724ef307c48@mail.gmail.com>

Hi Ben,

>  We really appreciate the hard work you put into this.  Would you be able to
> try out the patch that Guennadi just posted and add your 'Acked-by'?

My schedule is pretty tight right now so I cannot make a promise.
Anyhow, it was on my list to give the driver a try. I'll give feedback
once I tested it.

Regards,
Mark



From gerald.vanbaren at ge.com  Fri Apr  4 13:30:00 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Fri, 04 Apr 2008 07:30:00 -0400
Subject: [U-Boot-Users] Window closed (was Clean up smsc911x driver)
In-Reply-To: <20080403220847.3F8732476E@gemini.denx.de>
References: <20080403220847.3F8732476E@gemini.denx.de>
Message-ID: <47F61138.2070900@ge.com>

Wolfgang Denk wrote:
> In message <47F52891.3070607 at gmail.com> you wrote:
>>> Topic for #u-boot: Merge Window for 1.3.3 is over - only bug fixes accepted now.
>>> Topic for #u-boot set by wdenk at 2008-04-01 10:27:53
>>>
>>>   
>> OK, where do you announce these things, so I can be sure to notice next 
>> time?  I'm not trying to be a smart-ass, but am really curious.
> 
> Well, the quote above refers to the subject on the "u-boot" IRC
> channel.
> 
> Best regards,
> 
> Wolfgang Denk

It isn't exactly a U-Boot Weather Forecast[1], but I've updated the 
status page.
   <http://www.denx.de/wiki/UBoot/ReleaseCycle>

gvb

[1]
<http://www.linux-foundation.org/index.php?title=Linux_Weather_Forecast>



From trimarchi at gandalf.sssup.it  Fri Apr  4 13:02:47 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Fri, 04 Apr 2008 13:02:47 +0200
Subject: [U-Boot-Users] regarding u-boot porting
In-Reply-To: <451321.52005.qm@web94604.mail.in2.yahoo.com>
References: <451321.52005.qm@web94604.mail.in2.yahoo.com>
Message-ID: <47F60AD7.7080204@gandalf.sssup.it>

Hi,

what kind of problems?

Regards Michael




From monstr at seznam.cz  Fri Apr  4 12:52:57 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:57 +0200
Subject: [U-Boot-Users] [PATCH 10/13] microblaze: ml401 fix config file for
	supporting FDT
In-Reply-To: <1207306380-5210-10-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
	<1207306380-5210-8-git-send-email-monstr@seznam.cz>
	<1207306380-5210-9-git-send-email-monstr@seznam.cz>
	<1207306380-5210-10-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-11-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 include/configs/ml401.h |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/configs/ml401.h b/include/configs/ml401.h
index b167cb2..360e2e1 100644
--- a/include/configs/ml401.h
+++ b/include/configs/ml401.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2007 Michal Simek
+ * (C) Copyright 2007-2008 Michal Simek
  *
  * Michal SIMEK <monstr at monstr.eu>
  *
@@ -83,8 +83,8 @@
 #define	CONFIG_XILINX_CLOCK_FREQ	XILINX_CLOCK_FREQ
 
 /* FSL */
-#define	CFG_FSL_2
-#define	FSL_INTR_2	1
+/* #define	CFG_FSL_2 */
+/* #define	FSL_INTR_2	1 */
 
 /*
  * memory layout - Example
@@ -155,9 +155,9 @@
 
 	#else	/* !RAMENV */
 		#define	CFG_ENV_IS_IN_FLASH	1
-		#define	CFG_ENV_ADDR		0x40000
 		#define	CFG_ENV_SECT_SIZE	0x40000	/* 256K(one sector) for env */
-		#define	CFG_ENV_SIZE		0x2000
+		#define	CFG_ENV_ADDR		(CFG_FLASH_BASE + (2 * CFG_ENV_SECT_SIZE))
+		#define	CFG_ENV_SIZE		0x40000
 	#endif /* !RAMBOOT */
 #else /* !FLASH */
 	/* ENV in RAM */
@@ -256,4 +256,7 @@
 					"256k(u-boot),256k(env),3m(kernel),"\
 					"1m(romfs),1m(cramfs),-(jffs2)\0"
 
+#define CONFIG_CMDLINE_EDITING
+#define CONFIG_OF_LIBFDT	1
+
 #endif	/* __CONFIG_H */
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:55 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:55 +0200
Subject: [U-Boot-Users] [PATCH 08/13] microblaze: clean uart16550 and
	uartlite handling
In-Reply-To: <1207306380-5210-8-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
	<1207306380-5210-8-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-9-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 board/xilinx/ml401/xparameters.h  |    4 ++--
 board/xilinx/xupv2p/xparameters.h |    4 ++--
 include/configs/ml401.h           |   17 +++++++++++++++--
 include/configs/xupv2p.h          |   17 +++++++++++++++--
 4 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/board/xilinx/ml401/xparameters.h b/board/xilinx/ml401/xparameters.h
index becafc8..d805061 100644
--- a/board/xilinx/ml401/xparameters.h
+++ b/board/xilinx/ml401/xparameters.h
@@ -41,8 +41,8 @@
 #define XILINX_TIMER_IRQ	0
 
 /* Uart pheriphery is RS232_Uart */
-#define XILINX_UART_BASEADDR	0x40600000
-#define XILINX_UART_BAUDRATE	115200
+#define XILINX_UARTLITE_BASEADDR	0x40600000
+#define XILINX_UARTLITE_BAUDRATE	115200
 
 /* IIC pheriphery is IIC_EEPROM */
 #define XILINX_IIC_0_BASEADDR	0x40800000
diff --git a/board/xilinx/xupv2p/xparameters.h b/board/xilinx/xupv2p/xparameters.h
index 19b81fd..9e5ebda 100644
--- a/board/xilinx/xupv2p/xparameters.h
+++ b/board/xilinx/xupv2p/xparameters.h
@@ -37,8 +37,8 @@
 #define XILINX_TIMER_IRQ	1
 
 /* Uart pheriphery is RS232_Uart_1 */
-#define XILINX_UART_BASEADDR	0x40600000
-#define XILINX_UART_BAUDRATE	115200
+#define XILINX_UARTLITE_BASEADDR	0x40600000
+#define XILINX_UARTLITE_BAUDRATE	115200
 
 /* GPIO is LEDs_4Bit*/
 #define XILINX_GPIO_BASEADDR	0x40000000
diff --git a/include/configs/ml401.h b/include/configs/ml401.h
index 6db1c1a..1a2cb0a 100644
--- a/include/configs/ml401.h
+++ b/include/configs/ml401.h
@@ -32,10 +32,23 @@
 #define	CONFIG_ML401		1	/* ML401 Board */
 
 /* uart */
+#ifdef XILINX_UARTLITE_BASEADDR
 #define	CONFIG_XILINX_UARTLITE
-#define	CONFIG_SERIAL_BASE	XILINX_UART_BASEADDR
-#define	CONFIG_BAUDRATE		XILINX_UART_BAUDRATE
+#define	CONFIG_SERIAL_BASE	XILINX_UARTLITE_BASEADDR
+#define	CONFIG_BAUDRATE		XILINX_UARTLITE_BAUDRATE
 #define	CFG_BAUDRATE_TABLE	{ CONFIG_BAUDRATE }
+#else
+#ifdef XILINX_UART16550_BASEADDR
+#define CFG_NS16550
+#define CFG_NS16550_SERIAL
+#define CFG_NS16550_REG_SIZE	4
+#define CONFIG_CONS_INDEX	1
+#define CFG_NS16550_COM1	XILINX_UART16550_BASEADDR
+#define CFG_NS16550_CLK		XILINX_UART16550_CLOCK_HZ
+#define	CONFIG_BAUDRATE		115200
+#define	CFG_BAUDRATE_TABLE	{ 9600, 115200 }
+#endif
+#endif
 
 /* setting reset address */
 /*#define	CFG_RESET_ADDRESS	TEXT_BASE*/
diff --git a/include/configs/xupv2p.h b/include/configs/xupv2p.h
index eef4f72..f86b3b9 100644
--- a/include/configs/xupv2p.h
+++ b/include/configs/xupv2p.h
@@ -31,10 +31,23 @@
 #define	CONFIG_XUPV2P		1
 
 /* uart */
+#ifdef XILINX_UARTLITE_BASEADDR
 #define	CONFIG_XILINX_UARTLITE
-#define	CONFIG_SERIAL_BASE	XILINX_UART_BASEADDR
-#define	CONFIG_BAUDRATE		XILINX_UART_BAUDRATE
+#define	CONFIG_SERIAL_BASE	XILINX_UARTLITE_BASEADDR
+#define	CONFIG_BAUDRATE		XILINX_UARTLITE_BAUDRATE
 #define	CFG_BAUDRATE_TABLE	{ CONFIG_BAUDRATE }
+#else
+#ifdef XILINX_UART16550_BASEADDR
+#define CFG_NS16550
+#define CFG_NS16550_SERIAL
+#define CFG_NS16550_REG_SIZE	4
+#define CONFIG_CONS_INDEX	1
+#define CFG_NS16550_COM1	XILINX_UART16550_BASEADDR
+#define CFG_NS16550_CLK		XILINX_UART16550_CLOCK_HZ
+#define	CONFIG_BAUDRATE		115200
+#define	CFG_BAUDRATE_TABLE	{ 9600, 115200 }
+#endif
+#endif
 
 /*
  * setting reset address
-- 
1.5.4.GIT




From gerald.vanbaren at ge.com  Fri Apr  4 13:41:03 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Fri, 04 Apr 2008 07:41:03 -0400
Subject: [U-Boot-Users] help
In-Reply-To: <20080404063940.B8F3B2476E@gemini.denx.de>
References: <20080404063940.B8F3B2476E@gemini.denx.de>
Message-ID: <47F613CF.3050509@ge.com>

Wolfgang Denk wrote:
> In message <bc04c5ba0804032253g4604b35ue3878c2429034dfa at mail.gmail.com> you wrote:
>> I am working with u =96 boot integration of ARM based board for various tes=
>> ts
>>
>> I am able to add the different commands but unable to run them
>> simultaneously
> 
> It is considerd highly impolite to post the same question several
> times in short sequence, especially when you additionally change the
> sander ID's. Please don't do this.
> 
>> Content-Type: text/html; charset=WINDOWS-1252
>> Content-Transfer-Encoding: quoted-printable
>> Content-Disposition: inline
> 
> And NEVER post HTML to this list!
> 
> Best regards,
> 
> Wolfgang Denk

P.S. You also didn't give us enough information to debug your problem, 
especially remotely.  The quality of the answers to questions is 
directly proportional to the quality of the questions asked.

About all we can say is that your code is broken.  When you find where 
it is broken, the fix usually is obvious.  If the fix isn't obvious, 
tell us the details and maybe we will be able to offer some more useful 
advice.

Good luck,
gvb



From dileepkumart at gmail.com  Fri Apr  4 13:49:40 2008
From: dileepkumart at gmail.com (Dileep Kumar)
Date: Fri, 4 Apr 2008 17:19:40 +0530
Subject: [U-Boot-Users] Regarding exception in UBOOT
In-Reply-To: <ed9edd1a0804040423g1b9b0495l42bff98a234d82c4@mail.gmail.com>
References: <ed9edd1a0804040423g1b9b0495l42bff98a234d82c4@mail.gmail.com>
Message-ID: <ed9edd1a0804040449h6393c15cya568fee630aecf65@mail.gmail.com>

Hi,
I am analyzing code for uboot -1.1.6 . I have some doubts related to exception.
In the file "start.S" there is a term , TRAP FRAME , and stack pointer.
Could you please tell me what is trap frame? and where stack pointer points ?
If the stack pointer pointer points to a stack ( different from TRAP FRAME )
then what is the purpose of TRAP FRAME?
What are contents of TRAP FRAME?

Thanks
Dileep Kumar



From monstr at seznam.cz  Fri Apr  4 12:52:56 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:56 +0200
Subject: [U-Boot-Users] [PATCH 09/13] microblaze: ml401 - add ifdef for GPIO
In-Reply-To: <1207306380-5210-9-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
	<1207306380-5210-8-git-send-email-monstr@seznam.cz>
	<1207306380-5210-9-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-10-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 include/configs/ml401.h |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/ml401.h b/include/configs/ml401.h
index 1a2cb0a..b167cb2 100644
--- a/include/configs/ml401.h
+++ b/include/configs/ml401.h
@@ -64,8 +64,10 @@
 #undef ET_DEBUG
 
 /* gpio */
+#ifdef XILINX_GPIO_BASEADDR
 #define	CFG_GPIO_0		1
 #define	CFG_GPIO_0_ADDR		XILINX_GPIO_BASEADDR
+#endif
 
 /* interrupt controller */
 #define	CFG_INTC_0		1
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:53:00 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:53:00 +0200
Subject: [U-Boot-Users] [PATCH 13/13] microblaze: Sort microblaze boards in
	MAKEALL script
In-Reply-To: <1207306380-5210-13-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
	<1207306380-5210-8-git-send-email-monstr@seznam.cz>
	<1207306380-5210-9-git-send-email-monstr@seznam.cz>
	<1207306380-5210-10-git-send-email-monstr@seznam.cz>
	<1207306380-5210-11-git-send-email-monstr@seznam.cz>
	<1207306380-5210-12-git-send-email-monstr@seznam.cz>
	<1207306380-5210-13-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-14-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>


Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 MAKEALL |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/MAKEALL b/MAKEALL
index 01573da..8b1dc39 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -640,8 +640,8 @@ LIST_nios2="		\
 #########################################################################
 
 LIST_microblaze="	\
-	suzaku		\
 	ml401		\
+	suzaku		\
 	xupv2p		\
 "
 
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:58 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:58 +0200
Subject: [U-Boot-Users] [PATCH 11/13] microblaze: xupv2p fix config file for
	supporting FDT
In-Reply-To: <1207306380-5210-11-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
	<1207306380-5210-8-git-send-email-monstr@seznam.cz>
	<1207306380-5210-9-git-send-email-monstr@seznam.cz>
	<1207306380-5210-10-git-send-email-monstr@seznam.cz>
	<1207306380-5210-11-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-12-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>


Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 include/configs/xupv2p.h |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/configs/xupv2p.h b/include/configs/xupv2p.h
index f86b3b9..30fb303 100644
--- a/include/configs/xupv2p.h
+++ b/include/configs/xupv2p.h
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2007 Michal Simek
+ * (C) Copyright 2007-2008 Michal Simek
  *
  * Michal SIMEK <monstr at monstr.eu>
  *
@@ -156,6 +156,7 @@
 #include <config_cmd_default.h>
 
 #undef CONFIG_CMD_FLASH
+#undef CONFIG_CMD_JFFS2
 #undef CONFIG_CMD_IMLS
 
 #define CONFIG_CMD_ASKENV
@@ -203,4 +204,7 @@
 #define	CONFIG_DOS_PARTITION
 #endif
 
+#define CONFIG_CMDLINE_EDITING
+#define CONFIG_OF_LIBFDT	1 /* flat device tree */
+
 #endif	/* __CONFIG_H */
-- 
1.5.4.GIT




From monstr at seznam.cz  Fri Apr  4 12:52:59 2008
From: monstr at seznam.cz (monstr at seznam.cz)
Date: Fri,  4 Apr 2008 12:52:59 +0200
Subject: [U-Boot-Users] [PATCH 12/13] microblaze: clean microblaze_config.mk
In-Reply-To: <1207306380-5210-12-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
	<1207306380-5210-8-git-send-email-monstr@seznam.cz>
	<1207306380-5210-9-git-send-email-monstr@seznam.cz>
	<1207306380-5210-10-git-send-email-monstr@seznam.cz>
	<1207306380-5210-11-git-send-email-monstr@seznam.cz>
	<1207306380-5210-12-git-send-email-monstr@seznam.cz>
Message-ID: <1207306380-5210-13-git-send-email-monstr@seznam.cz>

From: Michal Simek <monstr at monstr.eu>

FLAGS are generated by U-BOOT generator.
Board specific FLAGS are in board directory

Signed-off-by: Michal Simek <monstr at monstr.eu>
---
 microblaze_config.mk |   16 +++-------------
 1 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/microblaze_config.mk b/microblaze_config.mk
index 06ddefa..e44c79e 100644
--- a/microblaze_config.mk
+++ b/microblaze_config.mk
@@ -1,6 +1,8 @@
 #
-# (C) Copyright 2004 Atmark Techno, Inc.
+# (C) Copyright 2007-2008 Michal Simek
+# Michal SIMEK <monstr at monstr.eu>
 #
+# (C) Copyright 2004 Atmark Techno, Inc.
 # Yasushi SHOJI <yashi at atmark-techno.com>
 #
 # See file CREDITS for list of people who contributed to this
@@ -23,15 +25,3 @@
 #
 
 PLATFORM_CPPFLAGS += -ffixed-r31 -D__microblaze__
-
-ifdef CONFIG_MICROBLAZE_HARD_MULT
-PLATFORM_CPPFLAGS += -mno-xl-soft-mul
-endif
-
-ifdef CONFIG_MICROBLAZE_HARD_DIV
-PLATFORM_CPPFLAGS += -mno-xl-soft-div
-endif
-
-ifdef CONFIG_MICROBLAZE_HARD_BARREL
-PLATFORM_CPPFLAGS += -mxl-barrel-shift
-endif
-- 
1.5.4.GIT




From anihcniv at USCAR.ORG  Fri Apr  4 14:54:08 2008
From: anihcniv at USCAR.ORG (marinangeli HALAUKO)
Date: Fri, 4 Apr 2008 14:54:08 +0200
Subject: [U-Boot-Users] Keeping time is never so fun
Message-ID: <95FB2279-8C93-9C86-5409-D7B2A417241B@lists.sourceforge.net>

Royal blue collection now ready for advanced ordering

I missed my plane because my real Omega watch died on me http://www.juetieat.com/




From andre.schwarz at matrix-vision.de  Fri Apr  4 14:56:21 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Fri, 04 Apr 2008 14:56:21 +0200
Subject: [U-Boot-Users] MPC8343 PCI setup
In-Reply-To: <DpzldAuO.1207248700.7986240.tor@localhost>
References: <DpzldAuO.1207248700.7986240.tor@localhost>
Message-ID: <47F62575.8040007@matrix-vision.de>

Tor Krill schrieb:
>
> On 4/3/2008, "Andre Schwarz" <andre.schwarz at matrix-vision.de> wrote:
>
>   
>> All,
>>     
>
> Hi Andre and others,
>
>   
>> currently I'm trying to bring up a mpc8343 based system.
>> Latest u-boot v1.3.2 is running fine.
>>
>> The MPC8343 has a single 32-Bit PCI Bus running at 66MHz.
>> Connected are a FPGA (IDSEL 11 + IRQ0) and a miniPCI Slot (IDSEL12 + 
>> IRQ1).                                    
>>
>> Unfortunately the kernel panics during/after PCI setup.
>>     
>
> Not sure if this is related. But i got strange problems with PCI after
> the patch "Add CONFIG_PCI_SKIP_HOST_BRIDGE config option"
> (55774b512fdf63c..) was added.
>
> My symptoms where missed interrupts on sata dma in Linux. U-boot where
> however fine. Adding the above config solved my problems. Not really
> sure why i experienced this. We have no PCI bridge on our board.
>
> /Tor
>   
Tor,

thanks for your reply.

I'm also not sure if it's a PCI issue anymore ...

Kernel config has been reduced to a minimum : no PCI, no netwoking, i2c, 
spi ...
dts has been reduced to the CPU, soc and ipic.

U-Boot fills out dtb correctly - as far as I can see.

Kernel crashes on various "of_" functions.

There's also strange messages :
WARNING: Estimating decrementer frequency (not found)
WARNING: Estimating processor frequency (not found)

They're coming from "generic_calibrate_decr()" in kernel/time.c.

Looks like there something basically wrong with my dtb 
location/processing, since the "timebase-frequency" is present and valid :

        cpus {
                #address-cells = <0x00000001>;
                #size-cells = <0x00000000>;
                PowerPC,8343 at 0 {
                        device_type = "cpu";
                        reg = <0x00000000>;
                        d-cache-line-size = <0x00000020>;
                        i-cache-line-size = <0x00000020>;
                        d-cache-size = <0x00008000>;
                        i-cache-size = <0x00008000>;
                        timebase-frequency = <0x03f940aa>;
                        bus-frequency = <0x0fe502a8>;
                        clock-frequency = <0x17d783fc>;
                };
        };


Any hints ?


regards,
Andre


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080404/9043ecbc/attachment.htm 

From peter.pearse at arm.com  Fri Apr  4 15:09:40 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Fri, 4 Apr 2008 14:09:40 +0100
Subject: [U-Boot-Users] [PATCH] Clean up smsc911x driver
In-Reply-To: <1207277311.3224.48.camel@vader.jdub.homelinux.org>
Message-ID: <000001c89655$24798770$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Josh Boyer
> Sent: 04 April 2008 03:49
> To: Wolfgang Denk
> Cc: u-boot-users at lists.sourceforge.net; Ben Warren
> Subject: Re: [U-Boot-Users] [PATCH] Clean up smsc911x driver
> 
> On Fri, 2008-04-04 at 00:08 +0200, Wolfgang Denk wrote:
> > In message <47F52891.3070607 at gmail.com> you wrote:
> > >
> > > > Topic for #u-boot: Merge Window for 1.3.3 is over - 
> only bug fixes accepted now.
> > > > Topic for #u-boot set by wdenk at 2008-04-01 10:27:53
> > > >
> > > >   
> > > OK, where do you announce these things, so I can be sure 
> to notice 
> > > next time?  I'm not trying to be a smart-ass, but am 
> really curious.
> > 
> > Well, the quote above refers to the subject on the "u-boot" IRC 
> > channel.
> 
> Which would be #u-boot on Freenode (irc.freenode.net) for 
> those that don't know the channel even exists.
> 
> josh

Thanks josh

Regards

Peter

> 
> 
> --------------------------------------------------------------
> -----------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for just about 
> anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.n
> et/marketplace
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 





From martin.krause at tqs.de  Fri Apr  4 15:17:18 2008
From: martin.krause at tqs.de (Martin Krause)
Date: Fri, 04 Apr 2008 15:17:18 +0200
Subject: [U-Boot-Users] [PATCH v2] IDE: fix bug in reset sequence
Message-ID: <20080404130906.24594.85188.stgit@tq-sewsrv-4.tq-net.de>

According to the ata (ata5) specification the RESET- signal
shall be asserted for at least 25 us. Without this patch,
the RESET- signal is asserted on some boards for only < 1 us
(e. g. on the TQM5200). This patch adds a general delay of
25 us to the RESET- signal.

Without this patch a Platinum 4 GiB CF card is not recognised
properly on boards with a TQM5200 (STK52xx, TB5200).

The patch was tested on the boards TQM5200, TQM200B and TB5200
(with MPC5200 cpu) with the following IDE Hardware:

- 128 MiB CF Toshiba THNCF128MDG
- 128 MiB CF Toshiba THNCF128MBA
- 4 GiB CF InnoDisk iSmart iCF2000+
- 4 GiB CF SMI 20070312 (labeled with Platinum)
- 4 GiB CF Sony NCFB4G
- 40 GiB HDD Hitachi Travelstar IC25N040ATCS0-4

Signed-off-by: Martin Krause <martin.krause at tqs.de>
---
Hi Jean-Christophe,

thanks for your response! I've tested the patch with 
all IDE devices I found. It would be great if someone 
else could test this on some other hardware.

Regards,
Martin
---

 common/cmd_ide.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 8ace970..2d47914 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -1529,6 +1529,9 @@ static void ide_reset (void)
 
 	ide_set_reset (1); /* assert reset */
 
+	/* the reset signal shall be asserted for at least 25 us */
+	udelay(25);
+
 	WATCHDOG_RESET();
 
 #ifdef CFG_PB_12V_ENABLE




From lg at denx.de  Fri Apr  4 16:45:14 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Fri, 4 Apr 2008 16:45:14 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] cfi_flash: Support buffered writes on
 non-standard Spansion NOR flash
In-Reply-To: <20080403215326.GB10873@game.jcrosoft.org>
References: <Pine.LNX.4.64.0804031303450.18539@axis700.grange>
	<20080403215326.GB10873@game.jcrosoft.org>
Message-ID: <Pine.LNX.4.64.0804041636550.7124@axis700.grange>

On Thu, 3 Apr 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:

> On 13:36 Thu 03 Apr     , Guennadi Liakhovetski wrote:
> > Some NOR flash chip from Spansion, for example, the s29ws-n MirrorBit 
> > series require different addresses for buffered write commands. Define a 
> > configuration option to support buffered writes on those chips. A more 
> > elegant solution would be to automatically detect those chips by parsing 
> > their CFI records, but that would require introduction of a fixup table 
> > into the cfi_flash driver.
> > 
> 
> It will be good to detect it. On some hardware you may have some pip out
> compatible flash with this future or an other buffer interface.

Sorry, I do not quite understand what you mean here. As I said, the only 
possibility I can think of to automatically detect and handle these chips 
is by their CFI signature. ATM I know of two such signatures, and we don't 
know how many other NOR chips out there have the same "feature". So we 
would have to introduce some sort of blacklist similar to that in the 
Linux SCSI driver, for example. Which means a rather intrusive change to 
the cfi core, which I do not want to propose ATM.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From tj_jac at yahoo.co.in  Fri Apr  4 16:59:48 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Fri, 4 Apr 2008 20:29:48 +0530 (IST)
Subject: [U-Boot-Users] s3c2440 -- serial_init
Message-ID: <714304.63380.qm@web94613.mail.in2.yahoo.com>

Hi Vishal,

I am stuck with the Kernel load address and entry point. It keeps on resetting. Output as shown below.
My ram range is from 30000000 to 38000000.


U-Boot 1.3.2 (Apr  4 2008 - 18:02:03)

DRAM:  128 MB
Flash: 32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 34000000 ...
   Image Name:   TIJU Linux-2.6.24.4 Image
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    4288104 Bytes =  4.1 MB
   Load Address: 36000000
   Entry Point:  36000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

undefined instruction
pc : [<3790e004>]          lr : [<3101175c>]
sp : 30fcfaf8  ip : 30fcffb8     fp : 00000000
r10: 00000001  r9 : 30fcfe98     r8 : 30fcffdc
r7 : 31012e94  r6 : 34000040     r5 : 310194b4  r4 : 310194b1
r3 : 36000000  r2 : 30000100     r1 : 0000016a  r0 : 00000000
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

data abort
pc : [<31010ca8>]          lr : [<31010d40>]
sp : 30fcfa88  ip : 3101afdc     fp : 00000000
r10: 00000001  r9 : 30fcfe98     r8 : 30fcffdc
r7 : 31012e94  r6 : 34000040     r5 : 0065ba3e  r4 : 00036042
r3 : 3101afe0  r2 : 00036042     r1 : 00003707  r0 : 000036ff
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32
Resetting CPU ...
                                                                                                              
What could be the problem?

Thanks,
Tiju



----- Original Message ----
From: Vishal Oliyil Kunnil <vishal.ok at gmail.com>
To: Tiju <tj_jac at yahoo.co.in>
Sent: Friday, 4 April, 2008 1:42:30 PM
Subject: Re: [U-Boot-Users] s3c2440 -- serial_init

Hi Tiju,
Never used the controller either, but I suggest you try enabling the
debug macro
in the ethernet driver ...
CONFIG_DM9000_DEBUG

-- snip --
#ifdef CONFIG_DM9000_DEBUG
#define DM9000_DBG(fmt,args....) printf(fmt ,##args)
#else                           /*  */
#define DM9000_DBG(fmt,args...)
#endif                          /*  */
--snip-

Regards,
Vishal
On Fri, Apr 4, 2008 at 12:35 PM, Tiju <tj_jac at yahoo.co.in> wrote:
>
> Hi Vishal,
>
> No, the ethernet controller is outside the processor. We are using DM9000A.
> The link led does not glow when LAN cable is connected. Instead when we ping
> it glows, but does not ping correctly.
>
> Thank You,
> Tiju
>
>
> ----- Original Message ----
> From: Vishal Oliyil Kunnil <vishal.ok at gmail.com>
> To: Tiju <tj_jac at yahoo.co.in>
>
> Sent: Thursday, 3 April, 2008 8:32:26 PM
> Subject: Re: [U-Boot-Users] s3c2440 -- serial_init
>
> Is the ethrnet core inside the processor ? (never used the smcx ...)
> Does ping work ? Does the link LED glow when you plug in the LAN cable ?
>
> Vishal
>
> On Thu, Apr 3, 2008 at 7:05 PM, Tiju <tj_jac at yahoo.co.in> wrote:
> >
> > Hi Vishal,
> >
> > Thank You so much for your help. The u-boot is up and running from
> yesterday
> > onwards. :)
> > The network driver doesn't seem to work properly. Trying to figure it out.
> > It says---
> >
> > DPB2440 # tftpboot
> > dm9000 i/o: 0x18000000, id: 0x90000a46
> > MAC: 00:e0:63:0e:56:78
> > could not establish link
> > TFTP from server 192.168.100.6; our IP address is 192.168.100.110
> > Filename 'zImage'.
> > Load address: 0x34000000
> > Loading: T T T #T T T T T T T
> > Retry count exceeded; starting again
> > TFTP from server 192.168..100.6; our IP address is 192.168.100.110
> > Filename 'zImage'.
> > Load address: 0x34000000
> > Loading: T T #T T T T T T T T
> > ....
> >
> > Any idea what the problem is?
> >
> > Regards,
> > Tiju
> >
> >
> > ----- Original Message ----
> > From: Vishal Oliyil Kunnil <vishal.ok at gmail.com>
> > To: Tiju <tj_jac at yahoo.co.in>
> >
> > Sent: Wednesday, 2 April, 2008 11:29:21 AM
> > Subject: Re: [U-Boot-Users] s3c2440 -- serial_init
> >
> > Hi Tiju,
> > You should not write the image to RAM. U-boot should re-locate by itself.
> > What is the debugger that you use ? Try putting a breakpoint at address
> > of start_armboot() -> you can get the address by
> > objdump -S u-boot.elf > u-boot.dump
> > A memory dump should show contents of 0x0 anf 0x31000000 to be same.
> > Also I suggest you use a stable release of u-boot and not  U-Boot
> > 1.3.2-00046-g23e20aa-dirty.
> >
> > Regards,
> > -Vishal
> >
> >
> >
> >
> > On Wed, Apr 2, 2008 at 8:58 AM, Tiju <tj_jac at yahoo.co.in> wrote:
> > >
> > > Hi Vishal,
> > >
> > > Thanks for the tips. After I compiling with TEXT_BASE=0x31000000 and
> > > commenting
> > > - CONFIG_SKIP_LOWLEVEL_INIT
> > > - CONFIG_SKIP_RELOCATE_UBOOT it does not work directly. After this I
> just
> > > wrote the same image to the NOR flash as well as the RAM (starting from
> > > 0x31000000) then on the u-boot the following appears.
> > >
> > > U-Boot 1.3.2-00046-g23e20aa-dirty (Apr  1 2008 - 19:33:51)
> > >
> > > DRAM:  64 MB
> > > *** Warning - bad CRC, using default environment
> > >
> > > In:    serial
> > > Out:  serial
> > > Err:  serial
> > > DPB2440 #
> > >
> > > After this it hangs. ie. no input or output.
> > >
> > > I think the initial problem to be taken care of is the relocation and
> then
> > > the serial. How do we go about these issues?
> > >
> > > Thanks in advance.
> > > Tiju
> > >
> > >
> > >
> > >
> > > ----- Original Message ----
> > > From: Vishal Oliyil Kunnil <vishal.ok at gmail.com>
> > > To: Tiju <tj_jac at yahoo.co.in>
> > >
> > > Sent: Monday, 31 March, 2008 6:31:43 PM
> > > Subject: Re: [U-Boot-Users] s3c2440 -- serial_init
> > >
> > > Tiju,
> > >
> > > Read the documentation:
> > > ----- snip - README -----
> > > - CONFIG_SKIP_LOWLEVEL_INIT
> > > - CONFIG_SKIP_RELOCATE_UBOOT
> > >                [ARM only] If these variables are defined, then
> > >                certain low level initializations (like setting up
> > >                the memory controller) are omitted and/or U-Boot does
> > >                not relocate itself into RAM.
> > >                Normally these variables MUST NOT be defined. The
> > >                only exception is when U-Boot is loaded (to RAM) by
> > >                some other boot loader or by a debugger which
> > >                performs these intializations itself.
> > > ----- snip - README -------
> > >
> > > I suggest you enable the RELOCATE and LOWLEVEL_INIT (by commenting the
> > > defines)
> > > - u-boot AFAIK cannot run lke the XIP kernel off NOR Flash; inspite of
> > > the fact the NOR
> > > flash can be directly read by the processor - unlike NAND. There is no
> > > noticeable performance
> > > hit or wastage of memory if you let u-boot relocate by itself.
> > >
> > > TEXT_BASE=0x31000000 in my opinion is correct.
> > >
> > > After relocating, a dump of flash contents and RAM (TEXT_BASE) contents
> > > should show you the same contents. If it does not - perhaps you have
> > > not configured
> > > the memory controller correctly. This can be verified by checking if
> > > you are able to
> > > write to RAM using the debugger after memory initializations (which is
> > > typically in LOWLEVEL_INIT, which you have skipped - I dont know if
> > > this is so for the s3c2440 ).
> > >
> > > Regards,
> > > Vishal
> > >
> > > On Mon, Mar 31, 2008 at 5:16 PM, Tiju <tj_jac at yahoo.co.in> wrote:
> > > >
> > > > Thanks Vishal.. I compiled with TEXT_BASE=0x31000000 and for
> > start_armboot
> > > > jumps to 0x310004d0 but there are junk values present there.
> > > >
> > > > By default these are  enabled:
> > > > #define CONFIG_SKIP_RELOCATE_UBOOT  1
> > > > #define CONFIG_SKIP_LOWLEVEL_INIT  1
> > > > so u-boot does not relocate.
> > > >
> > > > Still now what should the value of TEXT_BASE be? I dont want to
> relocate
> > > > u-boot because from NOR flash byte by byte read can be done.
> > > >
> > > > Regards,
> > > > Tiju
> > > >
> > > >
> > > > ----- Original Message ----
> > > > From: Vishal Oliyil Kunnil <vishal.ok at gmail.com>
> > > > To: Tiju <tj_jac at yahoo.co.in>
> > > >
> > > > Sent: Monday, 31 March, 2008 2:58:12 PM
> > > > Subject: Re: [U-Boot-Users] s3c2440 -- serial_init
> > > >
> > > > TEXT_BASE is the address for which u-boot is linked for.If you take an
> > > > objdump of u-boot
> > > > elf, you will see that it links for address beginning with that
> > > > specified by TEXT_BASE.
> > > > Meaning, you link for the address thus specified.
> > > > Typically  the binary will be run from the reset vector of the
> > > > processor, which is not necessarily
> > > > TEXT_BASE : say 0x0 flash address. U-boot starts executing from the
> > > > reset vector,
> > > > relocates to RAM  and since it is linked for TEXT_BASE, the  ldr pc,
> > > > _start_armboot
> > > > will branch to the start_armboot which is in RAM.
> > > > -------snip - start.S --------------
> > > > ldr    pc, _start_armboot
> > > > _start_armboot: .word start_armboot
> > > > -------snip - start.S --------------
> > > > Regards,
> > > > Vishal
> > > >
> > > > On Mon, Mar 31, 2008 at 1:41 PM, Tiju <tj_jac at yahoo.co.in> wrote:
> > > > >
> > > > > Hi Vishal,
> > > > >
> > > > > What does TEXT_BASE mean? Is this the place where the UBOOT gets
> > > > relocated?
> > > > >
> > > > > Thank You,
> > > > > Tiju
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message ----
> > > > > From: "vishal.ok at gmail.com" <vishal..ok at gmail.com>
> > > > > To: Tiju <tj_jac at yahoo.co.in>
> > > > > Sent: Monday, 31 March, 2008 1:35:47 PM
> > > > > Subject: Re: [U-Boot-Users] s3c2440 -- serial_init
> > > > >
> > > > > Hi Tiju,
> > > > >
> > > > > Try with TEXT_BASE=0x31000000, and leave start.s untouched !
> > > > > I think you have misinterpreted the meaning of TEXT_BASE.
> > > > >
> > > > > Regards,
> > > > > Vishal
> > > > >
> > > > > On 3/31/08, Tiju <tj_jac at yahoo.co.in> wrote:
> > > > > > Hi Michael,
> > > > > >
> > > > > > I have verified all the RAM initializations in
> > > > > > board/smdk2440/lowlevel_init.S and it seems to be fine.
> > > > > > The other changes that I have done are
> > > > > >
> > > > > > 1.. In the board/smdk2440/config.mk file I changed TEXT_BASE =
> > > > 0x33F80000
> > > > > to
> > > > > > TEXT_BASE = 0x00000000 because I am booting from the NOR flash.
> The
> > > NOR
> > > > > > flash address range is 0x00000000 - 0x08000000. The RAM address
> > range
> > > is
> > > > > > 0x30000000 - 0x38000000.
> > > > > >
> > > > > > If I compile it with TEXT_BASE = 0x33F80000 it does not run at
> all!
> > > > > >
> > > > > > 2. When I changed this I found that it has a clash with the stack
> > > > building
> > > > > > in cpu/arm920t/start.S. Therefore I changed it to
> > > > > > ..........
> > > > > > /* Set up the stack */
> > > > > > stack_setup:
> > > > > > /* ldr r0, _TEXT_BASE */ /* upper 128 KiB: relocated uboot */
> > > > > > mov r0, #0x33 /* make stack at 33F8*/
> > > > > > mov r0, r0, lsl #24
> > > > > > mov r1, #0xF8
> > > > > > mov r1, r1, lsl #16
> > > > > > orr r0, r0, r1
> > > > > > ........
> > > > > >
> > > > > > Would these be a problem for the memory initializations?
> > > > > >
> > > > > > Thanks in advance
> > > > > > Tiju
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Hi all
> > > > > > >
> > > > > > > I am trying to port u-boot to a s3c2440 samsung processor.
> > > > > > >
> > > > > > > I applied the smdk2440 boards patch (almost similar
> architecture)
> > > and
> > > > > > > trying to modify it for our board's requirement. But during the
> > > > > > > serial_init it goes to the _serial_putc and then after certain
> > loops
> > > > > > > it goes to the hang function and hangs there.
> > > > > > >
> > > > > > > What could be the problem? Or am I doing some wrong
> > initializations?
> > > > > > >
> > > > > > >
> > > > > > Are you sure that the memory inizializzation is correct?
> > > > > >
> > > > > > Regards Michael
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 5, 50, 500, 5000 - Store N number of mails in your inbox. Go to
> > > > > >
> http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html
> > > > >
> > > > >
> > > > >  ________________________________
> > > > >  Get your domain and website for less than Rs.100/month*. Click
> here.
> > > >
> > > >
> > > >
> > > >  ________________________________
> > > >  Get your domain and website for less than Rs.100/month*.. Click here.
> > >
> > >
> > >  ________________________________
> > >  Bring your gang together - do your thing. Start your group.
> >
> >
> >
> >  ________________________________
> >  Bring your gang together - do your thing. Start your group.
>
>
>
>  ________________________________
>  Get your domain and website for less than Rs.100/month*. Click here.






      Share files, take polls, and make new friends - all under one roof. Go to http://in.promos.yahoo.com/groups/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080404/24131031/attachment.htm 

From timur at freescale.com  Fri Apr  4 18:15:58 2008
From: timur at freescale.com (Timur Tabi)
Date: Fri,  4 Apr 2008 11:15:58 -0500
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some 85xx
	chips
Message-ID: <1207325758-1333-1-git-send-email-timur@freescale.com>

Some 85xx chips use CCB as the base clock for the I2C.  Some use CCB/2, and
some use CCB/3.  There is no pattern that can be used to determine which
chips use which frequency, so the only way to determine is to look up the
actual SOC designation and use the right value for that SOC.

Update immap_85xx.h to include the GUTS PORDEVSR2 register.

Signed-off-by: Timur Tabi <timur at freescale.com>
---

Yes, this is ugly and stupid, but the only alternative is to update each
board configuration file with another CONFIG_ option.  And yes, this does
mean that as new 85xx variants are announced, cpu/mpc85xx/speed.c may need
to be updated.

 cpu/mpc85xx/speed.c          |   31 ++++++++++++++++++++++++++++++-
 include/asm-ppc/immap_85xx.h |    4 +++-
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/cpu/mpc85xx/speed.c b/cpu/mpc85xx/speed.c
index d90d397..699441b 100644
--- a/cpu/mpc85xx/speed.c
+++ b/cpu/mpc85xx/speed.c
@@ -65,6 +65,9 @@ void get_sys_info (sys_info_t * sysInfo)
 int get_clocks (void)
 {
 	sys_info_t sys_info;
+#ifdef CONFIG_MPC8544
+	volatile ccsr_gur_t *gur = (void *) CFG_MPC85xx_GUTS_ADDR;
+#endif
 #if defined(CONFIG_CPM2)
 	volatile ccsr_cpm_t *cpm = (ccsr_cpm_t *)CFG_MPC85xx_CPM_ADDR;
 	uint sccr, dfbrg;
@@ -78,8 +81,34 @@ int get_clocks (void)
 	gd->cpu_clk = sys_info.freqProcessor;
 	gd->bus_clk = sys_info.freqSystemBus;
 	gd->mem_clk = sys_info.freqDDRBus;
+
+	/*
+	 * The base clock for I2C depends on the actual SOC.  Unfortunately,
+	 * there is no pattern that can be used to determine the frequency, so
+	 * the only choice is to look up the actual SOC number and use the value
+	 * for that SOC. This information is taken from application note
+	 * AN2919.
+	 */
+#if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
+	defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555)
 	gd->i2c1_clk = sys_info.freqSystemBus;
-	gd->i2c2_clk = sys_info.freqSystemBus;
+#elif defined(CONFIG_MPC8544)
+	/*
+	 * On the 8544, the I2C clock is the same as the SEC clock.  This can be
+	 * either CCB/2 or CCB/3, depending on the value of cfg_sec_freq. See
+	 * 4.4.3.3 of the 8544 RM.  Note that this might actually work for all
+	 * 85xx, but only the 8544 has cfg_sec_freq, so it's unknown if the
+	 * PORDEVSR2_SEC_CFG bit is 0 on all 85xx boards that are not an 8544.
+	 */
+	if (gur->pordevsr2 & MPC85xx_PORDEVSR2_SEC_CFG)
+		gd->i2c1_clk = sys_info.freqSystemBus / 3;
+	else
+		gd->i2c1_clk = sys_info.freqSystemBus / 2;
+#else
+	/* Most 85xx SOCs use CCB/2, so this is the default behavior. */
+	gd->i2c1_clk = sys_info.freqSystemBus / 2;
+#endif
+	gd->i2c2_clk = gd->i2c1_clk;
 
 #if defined(CONFIG_CPM2)
 	gd->vco_out = 2*sys_info.freqSystemBus;
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/immap_85xx.h
index 3506aec..42c066e 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -1570,7 +1570,9 @@ typedef struct ccsr_gur {
 #define MPC85xx_PORDEVSR_RIO_CTLS 	0x00000008
 #define MPC85xx_PORDEVSR_RIO_DEV_ID	0x00000007
 	uint	pordbgmsr;	/* 0xe0010 - POR debug mode status register */
-	char	res1[12];
+	uint	pordevsr2;	/* 0xe0014 - POR I/O device status regsiter 2 */
+#define MPC85xx_PORDEVSR2_SEC_CFG	0x00000020
+	char	res1[8];
 	uint	gpporcr;	/* 0xe0020 - General-purpose POR configuration register */
 	char	res2[12];
 	uint	gpiocr;		/* 0xe0030 - GPIO control register */
-- 
1.5.4




From timur at freescale.com  Fri Apr  4 18:16:11 2008
From: timur at freescale.com (Timur Tabi)
Date: Fri,  4 Apr 2008 11:16:11 -0500
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some 86xx
	chips
Message-ID: <1207325771-1374-1-git-send-email-timur@freescale.com>

Some 86xx chips use CCB as the base clock for the I2C, and others used CCB/2.
There is no pattern that can be used to determine which chips use which
frequency, so the only way to determine is to look up the actual SOC
designation and use the right value for that SOC.

Signed-off-by: Timur Tabi <timur at freescale.com>
---

Yes, this is ugly and stupid, but the only alternative is to update each
board configuration file with another CONFIG_ option.  And yes, this does
mean that as new 86xx variants are announced, cpu/mpc86xx/speed.c may need
to be updated.

 cpu/mpc86xx/speed.c |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/cpu/mpc86xx/speed.c b/cpu/mpc86xx/speed.c
index 7e884f8..da5b58b 100644
--- a/cpu/mpc86xx/speed.c
+++ b/cpu/mpc86xx/speed.c
@@ -105,8 +105,20 @@ int get_clocks(void)
 	get_sys_info(&sys_info);
 	gd->cpu_clk = sys_info.freqProcessor;
 	gd->bus_clk = sys_info.freqSystemBus;
+
+	/*
+	 * The base clock for I2C depends on the actual SOC.  Unfortunately,
+	 * there is no pattern that can be used to determine the frequency, so
+	 * the only choice is to look up the actual SOC number and use the value
+	 * for that SOC. This information is taken from application note
+	 * AN2919.
+	 */
+#ifdef CONFIG_MPC8610
 	gd->i2c1_clk = sys_info.freqSystemBus;
-	gd->i2c2_clk = sys_info.freqSystemBus;
+#else
+	gd->i2c1_clk = sys_info.freqSystemBus / 2;
+#endif
+	gd->i2c2_clk = gd->i2c1_clk;
 
 	if (gd->cpu_clk != 0)
 		return 0;
-- 
1.5.4




From epalmer at viatechnology.com  Fri Apr  4 19:16:34 2008
From: epalmer at viatechnology.com (Eric Palmer)
Date: Fri, 4 Apr 2008 13:16:34 -0400
Subject: [U-Boot-Users] Davinci Ethernet Problems
Message-ID: <001701c89677$a2861530$e7923f90$@com>

I am running uBoot on a DM6646 DSP and am not able to see an ARP Response
from the network. When using the Davinci EVM board, I send out a ping and
while monitoring the Ethernet traffic. I see an ARP Request from the DSP,
Arp Response from my PC, and then an Echo Request from the DSP. When I try
this with my custom board, I never get an Echo Request. I have verified that
the receive signals going from the PHY to the DSP are present. 

 

I am using a Marvell 88E3018 PHY where the Davinci EVM board uses an Intel
PHY. I have not verified whether this is a hardware or software problem,
where uBoot may need to be modified. 

 

Any help is appreciated,

 

Regards,

Eric Palmer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080404/6ce47759/attachment.htm 

From zac.wheeler at gmail.com  Fri Apr  4 22:32:54 2008
From: zac.wheeler at gmail.com (Zac Wheeler)
Date: Fri, 4 Apr 2008 13:32:54 -0700
Subject: [U-Boot-Users] AT91 Header File Clarification
Message-ID: <206b9e70804041332w695212f3me41cfa8f7f182f11@mail.gmail.com>

I have a question about the arrangement of include files for the
at91sam9 family.

Is the intention that asm/arch/at91_xxx.h be applicable for all
at91sam9 microcontrollers, or should they be broken down into subarch
folders (e.g. asm/arch/at91sam9261/at91_pmc.h)?

I am trying to bring up the at91sam9261 on a custom board a little
ahead of what appears to be the schedule for the at91sam9261ek and I
want to try to be compatible with the existing format. I haven't done
a lot of comparisons between 9260/9261/9263, but for some things (e.g.
at91_lcd.h) it obviously depends on which microcontroller you're
using.

Thanks,
Zac



From plagnioj at jcrosoft.com  Fri Apr  4 23:51:26 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 4 Apr 2008 23:51:26 +0200
Subject: [U-Boot-Users] [PATCH 06/13] microblaze: Add Emac driver
	to	Makefile
In-Reply-To: <1207306380-5210-7-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
Message-ID: <20080404215126.GA17404@game.jcrosoft.org>

On 12:52 Fri 04 Apr     , monstr at seznam.cz wrote:
> From: Michal Simek <monstr at monstr.eu>
> 
> Signed-off-by: Michal Simek <monstr at monstr.eu>
> ---
>  drivers/net/Makefile |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 320dc3e..e6b0543 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -59,6 +59,7 @@ COBJS-y += tsec.o
>  COBJS-y += tsi108_eth.o
>  COBJS-y += uli526x.o
>  COBJS-y += vsc7385.o
> +COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
>  
>  COBJS	:= $(COBJS-y)
>  SRCS 	:= $(COBJS:.o=.c)
> -- 
Please do it when you add the driver

Best Regards,
J.



From plagnioj at jcrosoft.com  Fri Apr  4 23:51:41 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 4 Apr 2008 23:51:41 +0200
Subject: [U-Boot-Users] [PATCH 07/13] microblaze: Add Emaclite driver	to
	Makefile
In-Reply-To: <1207306380-5210-8-git-send-email-monstr@seznam.cz>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
	<1207306380-5210-8-git-send-email-monstr@seznam.cz>
Message-ID: <20080404215141.GB17404@game.jcrosoft.org>

On 12:52 Fri 04 Apr     , monstr at seznam.cz wrote:
> From: Michal Simek <monstr at monstr.eu>
> 
> Signed-off-by: Michal Simek <monstr at monstr.eu>
> ---
>  drivers/net/Makefile |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index e6b0543..1ae517d 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -60,6 +60,7 @@ COBJS-y += tsi108_eth.o
>  COBJS-y += uli526x.o
>  COBJS-y += vsc7385.o
>  COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
> +COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
>  
>  COBJS	:= $(COBJS-y)
>  SRCS 	:= $(COBJS:.o=.c)
> -- 
Please do it when you add the driver

Best Regards,
J.



From stelian at popies.net  Sat Apr  5 00:25:50 2008
From: stelian at popies.net (Stelian Pop)
Date: Sat, 05 Apr 2008 00:25:50 +0200
Subject: [U-Boot-Users] AT91 Header File Clarification
In-Reply-To: <206b9e70804041332w695212f3me41cfa8f7f182f11@mail.gmail.com>
References: <206b9e70804041332w695212f3me41cfa8f7f182f11@mail.gmail.com>
Message-ID: <1207347950.3762.3.camel@voyager.dsnet>


Le vendredi 04 avril 2008 ? 13:32 -0700, Zac Wheeler a ?crit :
> I have a question about the arrangement of include files for the
> at91sam9 family.
> 
> Is the intention that asm/arch/at91_xxx.h be applicable for all
> at91sam9 microcontrollers, or should they be broken down into subarch
> folders (e.g. asm/arch/at91sam9261/at91_pmc.h)?

They are supposed to be shareable for all at91sam microcontrollers, in
the same way it's done in Linux.

> I am trying to bring up the at91sam9261 on a custom board a little
> ahead of what appears to be the schedule for the at91sam9261ek and I
> want to try to be compatible with the existing format. 

I'm working on support for the at91sam9261, I will probably have a patch
for the end of the next week. Hopefully you can wait until then. If not,
please go ahead.

> I haven't done
> a lot of comparisons between 9260/9261/9263, but for some things (e.g.
> at91_lcd.h) 

There is no such file in u-boot, nor linux iirc. There is a atmel_lcdc.h
in Linux (and I plan importing it into U-Boot, but later...).

Stelian.
-- 
Stelian Pop <stelian at popies.net>




From zac.wheeler at gmail.com  Sat Apr  5 01:32:32 2008
From: zac.wheeler at gmail.com (Zac Wheeler)
Date: Fri, 4 Apr 2008 16:32:32 -0700
Subject: [U-Boot-Users] AT91 Header File Clarification
In-Reply-To: <1207347950.3762.3.camel@voyager.dsnet>
References: <206b9e70804041332w695212f3me41cfa8f7f182f11@mail.gmail.com>
	<1207347950.3762.3.camel@voyager.dsnet>
Message-ID: <206b9e70804041632o391fc02fscac580e81b4bec7c@mail.gmail.com>

On Fri, Apr 4, 2008 at 3:25 PM, Stelian Pop <stelian at popies.net> wrote:
>
>  Le vendredi 04 avril 2008 ? 13:32 -0700, Zac Wheeler a ?crit :
>
> > I have a question about the arrangement of include files for the
>  > at91sam9 family.
>  >
>  > Is the intention that asm/arch/at91_xxx.h be applicable for all
>  > at91sam9 microcontrollers, or should they be broken down into subarch
>  > folders (e.g. asm/arch/at91sam9261/at91_pmc.h)?
>
>  They are supposed to be shareable for all at91sam microcontrollers, in
>  the same way it's done in Linux.

So should things like AT91_ECC as defined in at91sam960.h be
AT91SAM9260_ECC instead or moved to an at91_sys.h file? It seems
somewhat dangerous to define an AT91_ in a AT91SAM9260-specific file.

Sorry for my lack of understanding if I'm missing the point.

Zac



From zac.wheeler at gmail.com  Sat Apr  5 04:08:31 2008
From: zac.wheeler at gmail.com (Zac Wheeler)
Date: Fri, 4 Apr 2008 19:08:31 -0700
Subject: [U-Boot-Users] AT91 Header File Clarification
In-Reply-To: <1207347950.3762.3.camel@voyager.dsnet>
References: <206b9e70804041332w695212f3me41cfa8f7f182f11@mail.gmail.com>
	<1207347950.3762.3.camel@voyager.dsnet>
Message-ID: <206b9e70804041908m4f3e5b7eyf3b81788d8a24bdf@mail.gmail.com>

On Fri, Apr 4, 2008 at 3:25 PM, Stelian Pop <stelian at popies.net> wrote:
>
>  Le vendredi 04 avril 2008 ? 13:32 -0700, Zac Wheeler a ?crit :
>
> > I have a question about the arrangement of include files for the
>  > at91sam9 family.
>  >
>  > Is the intention that asm/arch/at91_xxx.h be applicable for all
>  > at91sam9 microcontrollers, or should they be broken down into subarch
>  > folders (e.g. asm/arch/at91sam9261/at91_pmc.h)?
>
>  They are supposed to be shareable for all at91sam microcontrollers, in
>  the same way it's done in Linux.
>
>
>  > I am trying to bring up the at91sam9261 on a custom board a little
>  > ahead of what appears to be the schedule for the at91sam9261ek and I
>  > want to try to be compatible with the existing format.
>
>  I'm working on support for the at91sam9261, I will probably have a patch
>  for the end of the next week. Hopefully you can wait until then. If not,
>  please go ahead.
>
>
>  > I haven't done
>  > a lot of comparisons between 9260/9261/9263, but for some things (e.g.
>  > at91_lcd.h)
>
>  There is no such file in u-boot, nor linux iirc. There is a atmel_lcdc.h
>  in Linux (and I plan importing it into U-Boot, but later...).

There is an at91_lcdc.h in Linux, but you're right, atmel_lcdc.h
appears to be the one that is used for the actual driver.



From monstr at seznam.cz  Sat Apr  5 09:06:36 2008
From: monstr at seznam.cz (Michal Simek)
Date: Sat, 05 Apr 2008 09:06:36 +0200
Subject: [U-Boot-Users] [PATCH 07/13] microblaze: Add Emaclite driver to
 Makefile
In-Reply-To: <20080404215141.GB17404@game.jcrosoft.org>
References: <1207306380-5210-1-git-send-email-monstr@seznam.cz>
	<1207306380-5210-2-git-send-email-monstr@seznam.cz>
	<1207306380-5210-3-git-send-email-monstr@seznam.cz>
	<1207306380-5210-4-git-send-email-monstr@seznam.cz>
	<1207306380-5210-5-git-send-email-monstr@seznam.cz>
	<1207306380-5210-6-git-send-email-monstr@seznam.cz>
	<1207306380-5210-7-git-send-email-monstr@seznam.cz>
	<1207306380-5210-8-git-send-email-monstr@seznam.cz>
	<20080404215141.GB17404@game.jcrosoft.org>
Message-ID: <47F724FC.90107@seznam.cz>

Hi Jean,

I will do it when I add the driver. The set of patches were only for review.

Can you add me ACK for them?

Thanks,

Michal Simek
www.monstr.eu

>> From: Michal Simek <monstr at monstr.eu>
>>
>> Signed-off-by: Michal Simek <monstr at monstr.eu>
>> ---
>>  drivers/net/Makefile |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
>> index e6b0543..1ae517d 100644
>> --- a/drivers/net/Makefile
>> +++ b/drivers/net/Makefile
>> @@ -60,6 +60,7 @@ COBJS-y += tsi108_eth.o
>>  COBJS-y += uli526x.o
>>  COBJS-y += vsc7385.o
>>  COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
>> +COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
>>  
>>  COBJS	:= $(COBJS-y)
>>  SRCS 	:= $(COBJS:.o=.c)
>> -- 
> Please do it when you add the driver
> 
> Best Regards,
> J.
> 




From 742-6744_1994 at 2sci.com  Sat Apr  5 11:57:18 2008
From: 742-6744_1994 at 2sci.com (Ronny)
Date: Sat, 5 Apr 2008 11:57:18 +0200
Subject: [U-Boot-Users] rock-bottom prices for luxury products
Message-ID: <05F80EB2.1%742-6744_1994@2sci.com>

Dress for the killer look with diamonds and bling on your wrist. http://www.Veslontes.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080405/26888700/attachment.htm 

From stelian at popies.net  Sat Apr  5 18:46:47 2008
From: stelian at popies.net (Stelian Pop)
Date: Sat, 05 Apr 2008 18:46:47 +0200
Subject: [U-Boot-Users] AT91 Header File Clarification
In-Reply-To: <206b9e70804041908m4f3e5b7eyf3b81788d8a24bdf@mail.gmail.com>
References: <206b9e70804041332w695212f3me41cfa8f7f182f11@mail.gmail.com>
	<1207347950.3762.3.camel@voyager.dsnet>
	<206b9e70804041908m4f3e5b7eyf3b81788d8a24bdf@mail.gmail.com>
Message-ID: <1207414007.4841.0.camel@voyager.dsnet>


Le vendredi 04 avril 2008 ? 19:08 -0700, Zac Wheeler a ?crit :

> >  There is no such file in u-boot, nor linux iirc. There is a atmel_lcdc.h
> >  in Linux (and I plan importing it into U-Boot, but later...).
> 
> There is an at91_lcdc.h in Linux,

Was. It was removed in 2.6.25-rc1.

>  but you're right, atmel_lcdc.h
> appears to be the one that is used for the actual driver.
> 
-- 
Stelian Pop <stelian at popies.net>




From luigi.mantellini at idf-hit.com  Sat Apr  5 19:00:18 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Sat, 05 Apr 2008 19:00:18 +0200
Subject: [U-Boot-Users] [PATCH] Add support for LZMA
	uncompression	algorithm.
In-Reply-To: <1207041489.12115.2.camel@localhost>
References: <1207041489.12115.2.camel@localhost>
Message-ID: <1207414818.29156.5.camel@localhost>

Hi u-boot users,

Has anyone tried the lzma patch? On my system works fine but I would
like to have a feedback from you :)

IS there the possibility to see this patch integrated into the official
u-boot tree?

Thanks a lot,

luigi

On mar, 2008-04-01 at 11:18 +0200, Luigi 'Comio' Mantellini wrote:
> ---
>  Makefile                   |    1 +
>  README                     |   23 ++
>  common/cmd_bootm.c         |   23 ++
>  common/image.c             |    7 +-
>  include/image.h            |    1 +
>  include/lzma/LzmaDecode.h  |   31 ++
>  include/lzma/LzmaTools.h   |   31 ++
>  include/lzma/LzmaTypes.h   |   31 ++
>  lib_lzma/LGPL.txt          |  504 +++++++++++++++++++++++++++++++++
>  lib_lzma/LzmaDecode.c      |  584 ++++++++++++++++++++++++++++++++++++++
>  lib_lzma/LzmaDecode.h      |  113 ++++++++
>  lib_lzma/LzmaTools.c       |  143 ++++++++++
>  lib_lzma/LzmaTools.h       |   35 +++
>  lib_lzma/LzmaTypes.h       |   45 +++
>  lib_lzma/Makefile          |   51 ++++
>  lib_lzma/README.txt        |   28 ++
>  lib_lzma/history.txt       |  198 +++++++++++++
>  lib_lzma/import_lzmasdk.sh |   38 +++
>  lib_lzma/lzma.txt          |  663 ++++++++++++++++++++++++++++++++++++++++++++
>  19 files changed, 2548 insertions(+), 2 deletions(-)
>  create mode 100644 include/lzma/LzmaDecode.h
>  create mode 100644 include/lzma/LzmaTools.h
>  create mode 100644 include/lzma/LzmaTypes.h
>  create mode 100644 lib_lzma/LGPL.txt
>  create mode 100644 lib_lzma/LzmaDecode.c
>  create mode 100644 lib_lzma/LzmaDecode.h
>  create mode 100644 lib_lzma/LzmaTools.c
>  create mode 100644 lib_lzma/LzmaTools.h
>  create mode 100644 lib_lzma/LzmaTypes.h
>  create mode 100644 lib_lzma/Makefile
>  create mode 100644 lib_lzma/README.txt
>  create mode 100644 lib_lzma/history.txt
>  create mode 100644 lib_lzma/import_lzmasdk.sh
>  create mode 100644 lib_lzma/lzma.txt
> 
> diff
-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080405/3ca73393/attachment.pgp 

From Monstr at seznam.cz  Sat Apr  5 19:19:54 2008
From: Monstr at seznam.cz (=?us-ascii?Q?Michal=20Simek?=)
Date: Sat, 05 Apr 2008 19:19:54 +0200 (CEST)
Subject: [U-Boot-Users] FIS DTC
Message-ID: <5311.8289-4040-1400377102-1207415994@seznam.cz>

Hi Jon, David and others,

I am working on FIS for Microblaze CPU. I would like to use it. I have one problem.

I download latest DTC version from Jon git server.

Version: DTC 1.1.0-g1577696b

I tryied to convert DTS to DTB for Microblaze CPU. (DTS is below)
#dtc -f -O dtb -b 0 -V 16 system.dts 
DTC: dts->dtb  on file "system.dts"
system.dts:27 syntax error
FATAL ERROR: Couldn't read input tree

I got this error - I don't understand what is wrong. Older DTC version has no problem with it.
This part is no problem - I can use older version of DTC(Version: DTC 1.1.0-g2512a7eb-dirty
).

The second things is around mkimage utility. I want to generate ITB file from ITS description.
Latest DTC compiler has problem with it too. 

Can you tell me which version are you using?
I tryied to complile ITS to ITB with older DTC version and this version don't know about data label in kernel specification.
I had no problem to add (for FDT + kernel version) DTB file but kernel file is not loaded.
Is label data = "/incbin/("./linux.bin")"; OK? linux bin is in the same dirctore where is microblaze.its file.

Latest DTC has problem with ITS too
$ mkimage -f microblaze.its  microblaze.itb
FIT format handling
Trying to execute "dtc -I dts -O dtb -p 500 microblaze.its > microblaze.itb.tmp"
DTC: dts->dtb  on file "microblaze.its"
microblaze.its:5 syntax error
FATAL ERROR: Couldn't read input tree
mkimage: Can't read microblaze.itb.tmp: Invalid argument
$ dtc -v
Version: DTC 1.1.0-g1577696b
[monstr at monstr linux-eu-2.6.24]$ 



# mkimage -f microblaze.its  microblaze.itb
FIT format handling
Trying to execute "dtc -I dts -O dtb -p 500 microblaze.its > microblaze.itb.tmp"
DTC: dts->dtb  on file "microblaze.its"
microblaze.its:5 syntax error
FATAL ERROR: Couldn't read input tree
mkimage: Can't read microblaze.itb.tmp: Invalid argument
# cat -n microblaze.its
     1  /*
     2   * Simple U-boot uImage source file containing a single kernel
     3   */
     4  / {
     5          description = "Simple image with single Linux kernel";
     6          #address-cells = <1>;
     7
     8          images {
     9                  kernel at 1 {
    10                          description = "Vanilla Linux kernel";
    11                          data = /incbin/("./linux.bin");
    12                          type = "kernel";
    13                          arch = "microblaze";
    14                          os = "linux";
    15                          compression = "none";
    16                          load = <20000000>;
    17                          entry = <20000000>;
    18                          hash at 1 {
    19                                  algo = "crc32";
    20                          };
    21                          hash at 2 {
    22                                  algo = "sha1";
    23                          };
    24                  };
    25          };
    26
    27          configurations {
    28                  default = "config at 1";
    29                  config at 1 {
    30                          description = "Boot Linux kernel";
    31                          kernel = "kernel at 1";
    32                  };
    33          };
    34  };

Thanks for help,
Michal Simek
www.monstr.eu








     1  /*
     2   * (C) Copyright 2007-2008 Michal Simek
     3   *
     4   * Michal SIMEK <monstr at monstr.eu>
     5   *
     6   * This program is free software; you can redistribute it and/or
     7   * modify it under the terms of the GNU General Public License as
     8   * published by the Free Software Foundation; either version 2 of
     9   * the License, or (at your option) any later version.
    10   *
    11   * This program is distributed in the hope that it will be useful,
    12   * but WITHOUT ANY WARRANTY; without even the implied warranty of
    13   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
    14   * GNU General Public License for more details.
    15   *
    16   * You should have received a copy of the GNU General Public License
    17   * along with this program; if not, write to the Free Software
    18   * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
    19   * MA 02111-1307 USA
    20   *
    21   * CAUTION: This file is automatically generated by libgen.
    22   * Version: Xilinx EDK 9.2.02 EDK_Jm_SP2.3
    23   * Generate by FDT v1.00.a
    24   */
    25
    26  / {
    27          #address-cells = <1>;
    28          #size-cells = <1>;
    29          compatible = "xlnx,microblaze";
    30          model = "testing";
    31          DDR_SDRAM_32Mx16: memory at 20000000 {
    32                  device_type = "memory";
    33                  reg = < 20000000 4000000 >;
    34          } ;
    35          chosen {
    36                  bootargs = "root=/dev/xsysace/disc0/part2";
    37          } ;
    38          cpus {
    39                  #address-cells = <1>;
    40                  #cpus = <1>;
    41                  #size-cells = <0>;
    42                  cpu at 0 {
    43                          clock-frequency = <2faf080>;
    44                          compatible = "xlnx,microblaze-7.00.a";
    45                          d-cache-baseaddr = <20000000>;
    46                          d-cache-highaddr = <21ffffff>;
    47                          d-cache-line-size = <10>;
    48                          d-cache-size = <4000>;
    49                          device_type = "cpu";
    50                          i-cache-baseaddr = <20000000>;
    51                          i-cache-highaddr = <21ffffff>;
    52                          i-cache-line-size = <10>;
    53                          i-cache-size = <4000>;
    54                          model = "microblaze,7.00.a";
    55                          reg = <0>;
    56                          timebase-frequency = <2faf080>;
    57                          xlnx,addr-tag-bits = <b>;
    58                          xlnx,allow-dcache-wr = <1>;
    59                          xlnx,allow-icache-wr = <1>;
    60                          xlnx,area-optimized = <0>;
    61                          xlnx,cache-byte-size = <4000>;
    62                          xlnx,d-lmb = <1>;
    63                          xlnx,d-opb = <0>;
    64                          xlnx,d-plb = <1>;
    65                          xlnx,data-size = <20>;
    66                          xlnx,dcache-addr-tag = <b>;
    67                          xlnx,dcache-byte-size = <4000>;
    68                          xlnx,dcache-line-len = <4>;
    69                          xlnx,dcache-use-fsl = <1>;
    70                          xlnx,debug-enabled = <1>;
    71                          xlnx,div-zero-exception = <1>;
    72                          xlnx,dopb-bus-exception = <0>;
    73                          xlnx,dynamic-bus-sizing = <1>;
    74                          xlnx,edge-is-positive = <1>;
    75                          xlnx,family = "spartan3e";
    76                          xlnx,fpu-exception = <1>;
    77                          xlnx,fsl-data-size = <20>;
    78                          xlnx,fsl-exception = <0>;
    79                          xlnx,fsl-links = <1>;
    80                          xlnx,i-lmb = <1>;
    81                          xlnx,i-opb = <0>;
    82                          xlnx,i-plb = <1>;
    83                          xlnx,icache-line-len = <4>;
    84                          xlnx,icache-use-fsl = <1>;
    85                          xlnx,ill-opcode-exception = <1>;
    86                          xlnx,instance = "microblaze_0";
    87                          xlnx,interconnect = <1>;
    88                          xlnx,interrupt-is-edge = <0>;
    89                          xlnx,iopb-bus-exception = <0>;
    90                          xlnx,mmu-dtlb-size = <4>;
    91                          xlnx,mmu-itlb-size = <2>;
    92                          xlnx,mmu-tlb-access = <3>;
    93                          xlnx,mmu-zones = <2>;
    94                          xlnx,number-of-pc-brk = <2>;
    95                          xlnx,number-of-rd-addr-brk = <0>;
    96                          xlnx,number-of-wr-addr-brk = <0>;
    97                          xlnx,opcode-0x0-illegal = <1>;
    98                          xlnx,pvr = <2>;
    99                          xlnx,pvr-user1 = <12>;
   100                          xlnx,pvr-user2 = <12345678>;
   101                          xlnx,reset-msr = <0>;
   102                          xlnx,sco = <0>;
   103                          xlnx,unaligned-exceptions = <1>;
   104                          xlnx,use-barrel = <1>;
   105                          xlnx,use-dcache = <1>;
   106                          xlnx,use-div = <1>;
   107                          xlnx,use-extended-fsl-instr = <0>;
   108                          xlnx,use-fpu = <2>;
   109                          xlnx,use-hw-mul = <2>;
   110                          xlnx,use-icache = <1>;
   111                          xlnx,use-mmu = <3>;
   112                          xlnx,use-msr-instr = <1>;
   113                          xlnx,use-pcmp-instr = <1>;
   114                  } ;
   115          } ;
   116          mb_plb: plb at 0 {
   117                  #address-cells = <1>;
   118                  #size-cells = <1>;
   119                  compatible = "xlnx,plb-v46-1.00.a";
   120                  ranges ;
   121                  Buttons_3Bit: gpio at 40800000 {
   122                          compatible = "xlnx,xps-gpio-1.00.a";
   123                          interrupt-parent = <&xps_intc_0>;
   124                          interrupts = < 6 2 >;
   125                          reg = < 40800000 100000 >;
   126                          xlnx,all-inputs = <1>;
   127                          xlnx,all-inputs-2 = <0>;
   128                          xlnx,dout-default = <0>;
   129                          xlnx,dout-default-2 = <0>;
   130                          xlnx,family = "spartan3e";
   131                          xlnx,gpio-width = <3>;
   132                          xlnx,interrupt-present = <1>;
   133                          xlnx,is-bidir = <0>;
   134                          xlnx,is-bidir-2 = <1>;
   135                          xlnx,is-dual = <0>;
   136                          xlnx,tri-default = <ffffffff>;
   137                          xlnx,tri-default-2 = <ffffffff>;
   138                  } ;
   139                  Character_LCD_2x16: gpio at 40900000 {
   140                          compatible = "xlnx,xps-gpio-1.00.a";
   141                          reg = < 40900000 100000 >;
   142                          xlnx,all-inputs = <0>;
   143                          xlnx,all-inputs-2 = <0>;
   144                          xlnx,dout-default = <0>;
   145                          xlnx,dout-default-2 = <0>;
   146                          xlnx,family = "spartan3e";
   147                          xlnx,gpio-width = <7>;
   148                          xlnx,interrupt-present = <0>;
   149                          xlnx,is-bidir = <1>;
   150                          xlnx,is-bidir-2 = <1>;
   151                          xlnx,is-dual = <0>;
   152                          xlnx,tri-default = <ffffffff>;
   153                          xlnx,tri-default-2 = <ffffffff>;
   154                  } ;
   155                  DIP_Switches_4Bit: gpio at 40700000 {
   156                          compatible = "xlnx,xps-gpio-1.00.a";
   157                          interrupt-parent = <&xps_intc_0>;
   158                          interrupts = < 7 2 >;
   159                          reg = < 40700000 100000 >;
   160                          xlnx,all-inputs = <1>;
   161                          xlnx,all-inputs-2 = <0>;
   162                          xlnx,dout-default = <0>;
   163                          xlnx,dout-default-2 = <0>;
   164                          xlnx,family = "spartan3e";
   165                          xlnx,gpio-width = <4>;
   166                          xlnx,interrupt-present = <1>;
   167                          xlnx,is-bidir = <0>;
   168                          xlnx,is-bidir-2 = <1>;
   169                          xlnx,is-dual = <0>;
   170                          xlnx,tri-default = <ffffffff>;
   171                          xlnx,tri-default-2 = <ffffffff>;
   172                  } ;
   173                  Ethernet_MAC: ethernet at 40c00000 {
   174                          compatible = "xlnx,xps-ethernetlite-1.00.a";
   175                          device_type = "network";
   176                          interrupt-parent = <&xps_intc_0>;
   177                          interrupts = < 2 0 >;
   178                          local-mac-address = [ 00 00 00 00 00 00 ];
   179                          reg = < 40c00000 100000 >;
   180                          xlnx,duplex = <1>;
   181                          xlnx,family = "spartan3e";
   182                          xlnx,rx-ping-pong = <0>;
   183                          xlnx,tx-ping-pong = <0>;
   184                  } ;
   185                  LEDs_8Bit: gpio at 40600000 {
   186                          compatible = "xlnx,xps-gpio-1.00.a";
   187                          reg = < 40600000 100000 >;
   188                          xlnx,all-inputs = <0>;
   189                          xlnx,all-inputs-2 = <0>;
   190                          xlnx,dout-default = <0>;
   191                          xlnx,dout-default-2 = <0>;
   192                          xlnx,family = "spartan3e";
   193                          xlnx,gpio-width = <8>;
   194                          xlnx,interrupt-present = <0>;
   195                          xlnx,is-bidir = <0>;
   196                          xlnx,is-bidir-2 = <1>;
   197                          xlnx,is-dual = <0>;
   198                          xlnx,tri-default = <ffffffff>;
   199                          xlnx,tri-default-2 = <ffffffff>;
   200                  } ;
   201                  RS232_DCE: serial at 40200000 {
   202                          compatible = "xlnx,xps-uart16550-1.00.a";
   203                          interrupt-parent = <&xps_intc_0>;
   204                          interrupts = < 4 2 >;
   205                          reg = < 40200000 100000 >;
   206                          xlnx,family = "spartan3e";
   207                          xlnx,has-external-rclk = <0>;
   208                          xlnx,has-external-xin = <0>;
   209                          xlnx,is-a-16550 = <1>;
   210                  } ;
   211                  RS232_DTE: serial at 40100000 {
   212                          compatible = "xlnx,xps-uartlite-1.00.a";
   213                          interrupt-parent = <&xps_intc_0>;
   214                          interrupts = < 3 0 >;
   215                          reg = < 40100000 100000 >;
   216                          xlnx,baudrate = <1c200>;
   217                          xlnx,data-bits = <8>;
   218                          xlnx,family = "spartan3e";
   219                          xlnx,odd-parity = <0>;
   220                          xlnx,use-parity = <0>;
   221                  } ;
   222                  SPI_FLASH: xps-spi at 40a00000 {
   223                          compatible = "xlnx,xps-spi-1.00.a";
   224                          interrupt-parent = <&xps_intc_0>;
   225                          interrupts = < 5 2 >;
   226                          reg = < 40a00000 100000 >;
   227                          xlnx,family = "spartan3e";
   228                          xlnx,fifo-exist = <1>;
   229                          xlnx,num-offchip-ss-bits = <4>;
   230                          xlnx,num-ss-bits = <4>;
   231                          xlnx,sck-ratio = <20>;
   232                  } ;
   233                  debug_module: debug at 40300000 {
   234                          compatible = "xlnx,mdm-1.00.a";
   235                          reg = < 40300000 100000 >;
   236                          xlnx,family = "spartan3e";
   237                          xlnx,interconnect = <1>;
   238                          xlnx,jtag-chain = <2>;
   239                          xlnx,mb-dbg-ports = <1>;
   240                          xlnx,uart-width = <8>;
   241                          xlnx,use-uart = <1>;
   242                          xlnx,write-fsl-ports = <1>;
   243                  } ;
   244                  mpmc at 20000000 {
   245                          #address-cells = <1>;
   246                          #size-cells = <1>;
   247                          compatible = "xlnx,mpmc-3.00.a";
   248                  } ;
   249                  xps_intc_0: interrupt-controller at 40000000 {
   250                          #interrupt-cells = <2>;
   251                          compatible = "xlnx,xps-intc-1.00.a";
   252                          interrupt-controller ;
   253                          reg = < 40000000 100000 >;
   254                          xlnx,num-intr-inputs = <8>;
   255                  } ;
   256                  xps_timer_0: timer at 40400000 {
   257                          compatible = "xlnx,xps-timer-1.00.a";
   258                          interrupt-parent = <&xps_intc_0>;
   259                          interrupts = < 0 2 >;
   260                          reg = < 40400000 100000 >;
   261                          xlnx,count-width = <20>;
   262                          xlnx,family = "spartan3e";
   263                          xlnx,gen0-assert = <1>;
   264                          xlnx,gen1-assert = <1>;
   265                          xlnx,one-timer-only = <0>;
   266                          xlnx,trig0-assert = <1>;
   267                          xlnx,trig1-assert = <1>;
   268                  } ;
   269                  xps_timer_1: timer at 40500000 {
   270                          compatible = "xlnx,xps-timer-1.00.a";
   271                          interrupt-parent = <&xps_intc_0>;
   272                          interrupts = < 1 2 >;
   273                          reg = < 40500000 100000 >;
   274                          xlnx,count-width = <20>;
   275                          xlnx,family = "spartan3e";
   276                          xlnx,gen0-assert = <1>;
   277                          xlnx,gen1-assert = <1>;
   278                          xlnx,one-timer-only = <1>;
   279                          xlnx,trig0-assert = <1>;
   280                          xlnx,trig1-assert = <1>;
   281                  } ;
   282          } ;
   283  }  ;






From Joakim.Tjernlund at transmode.se  Sat Apr  5 19:31:33 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Sat, 5 Apr 2008 19:31:33 +0200
Subject: [U-Boot-Users] [PATCH] Change env_get_char from a
	global	function ptr to a function.
In-Reply-To: <1206947724.7589.435.camel@gentoo-jocke.transmode.se>
References: <20080330223308.A611E248BE@gemini.denx.de>
	<1206947724.7589.435.camel@gentoo-jocke.transmode.se>
Message-ID: <024e01c89742$e48d4b80$ada7e280$@Tjernlund@transmode.se>

Did you try this one or did du skip it this release?

  Jocke

On Mon, 2008-03-31 at 00:33 +0200, Wolfgang Denk wrote:
> In message <1206911129.7589.411.camel at gentoo-jocke.transmode.se> you wrote:
> > 
> > Just one step closer to full relocation of u-boot. Global variables
> > before relocation to RAM is hard to deal with. Not sure if the code
> > got smaller or not.
> 
> Hm...there are some such variables.
> 
> Did you compare sizes?

I got the hint, thanks :)

size before:
   text	   data	    bss	    dec	    hex	filename
 204117	  13520	  28716	 246353	  3c251	u-boot

size after:
   text	   data	    bss	    dec	    hex	filename
 203893	  13500	  28716	 246109	  3c15d	u-boot

So it also got smaller by 244 bytes.
Updated patch, with signoff and Jean-Christophe
comment addressed.

 Jocke

>From 9e7cc775fa1fbf09b65f4a5edb5b16fe861c85dd Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
Date: Thu, 7 Feb 2008 14:50:42 +0100
Subject: [PATCH] Change env_get_char from a global function ptr to
 a function. This avoids an early global data reference.


Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
---
 api/api.c            |    1 -
 common/cmd_bootm.c   |    3 ---
 common/cmd_nvedit.c  |    3 ---
 common/env_common.c  |   19 +++++++++++++------
 common/env_eeprom.c  |    1 -
 common/env_nvram.c   |    1 -
 common/fdt_support.c |    4 ----
 common/ft_build.c    |    3 ---
 include/common.h     |    1 +
 9 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/api/api.c b/api/api.c
index 0598d90..c1b2b60 100644
--- a/api/api.c
+++ b/api/api.c
@@ -40,7 +40,6 @@
 
 /* U-Boot routines needed */
 extern int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
-extern uchar (*env_get_char)(int);
 extern uchar *env_get_addr(int);
 
 /*****************************************************************************
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9546729..5062817 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -1150,9 +1150,6 @@ do_bootm_netbsd (cmd_tbl_t *cmdtp, int flag,
 
 #if defined(CONFIG_ARTOS) && defined(CONFIG_PPC)
 
-/* Function that returns a character from the environment */
-extern uchar (*env_get_char)(int);
-
 static void
 do_bootm_artos (cmd_tbl_t *cmdtp, int flag,
 		int	argc, char *argv[],
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index dd263b6..15dca5b 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -68,9 +68,6 @@ DECLARE_GLOBAL_DATA_PTR;
 /************************************************************************
 ************************************************************************/
 
-/* Function that returns a character from the environment */
-extern uchar (*env_get_char)(int);
-
 /* Function that returns a pointer to a value from the environment */
 /* (Only memory version supported / needed). */
 extern uchar *env_get_addr(int);
diff --git a/common/env_common.c b/common/env_common.c
index a494812..f366fdb 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -50,7 +50,6 @@ extern void env_relocate_spec (void);
 extern uchar env_get_char_spec(int);
 
 static uchar env_get_char_init (int index);
-uchar (*env_get_char)(int) = env_get_char_init;
 
 /************************************************************************
  * Default settings to be used when no valid environment is found
@@ -182,6 +181,19 @@ uchar env_get_char_memory (int index)
 }
 #endif
 
+uchar env_get_char (int index)
+{
+	uchar c;
+
+	/* if relocated to RAM */
+	if (gd->flags & GD_FLG_RELOC)
+		c = env_get_char_memory(index);
+	else
+		c = env_get_char_init(index);
+
+	return (c);
+}
+
 uchar *env_get_addr (int index)
 {
 	if (gd->env_valid) {
@@ -215,11 +227,6 @@ void env_relocate (void)
 	DEBUGF ("%s[%d] malloced ENV at %p\n", __FUNCTION__,__LINE__,env_ptr);
 #endif
 
-	/*
-	 * After relocation to RAM, we can always use the "memory" functions
-	 */
-	env_get_char = env_get_char_memory;
-
 	if (gd->env_valid == 0) {
 #if defined(CONFIG_GTH)	|| defined(CFG_ENV_IS_NOWHERE)	/* Environment not changable */
 		puts ("Using default environment\n\n");
diff --git a/common/env_eeprom.c b/common/env_eeprom.c
index 2adc129..fae87ca 100644
--- a/common/env_eeprom.c
+++ b/common/env_eeprom.c
@@ -38,7 +38,6 @@ env_t *env_ptr = NULL;
 
 char * env_name_spec = "EEPROM";
 
-extern uchar (*env_get_char)(int);
 extern uchar env_get_char_memory (int index);
 
 
diff --git a/common/env_nvram.c b/common/env_nvram.c
index 7c18896..bfc8d02 100644
--- a/common/env_nvram.c
+++ b/common/env_nvram.c
@@ -63,7 +63,6 @@ char * env_name_spec = "NVRAM";
 extern uchar default_environment[];
 extern int default_environment_size;
 
-extern uchar (*env_get_char)(int);
 extern uchar env_get_char_memory (int index);
 
 #ifdef CONFIG_AMIGAONEG3SE
diff --git a/common/fdt_support.c b/common/fdt_support.c
index a13c140..fc43b43 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -225,10 +225,6 @@ int fdt_chosen(void *fdt, ulong initrd_start, ulong initrd_end, int force)
 
 #ifdef CONFIG_OF_HAS_UBOOT_ENV
 
-/* Function that returns a character from the environment */
-extern uchar(*env_get_char) (int);
-
-
 int fdt_env(void *fdt)
 {
 	int   nodeoffset;
diff --git a/common/ft_build.c b/common/ft_build.c
index 5a0575e..bd0c915 100644
--- a/common/ft_build.c
+++ b/common/ft_build.c
@@ -396,9 +396,6 @@ void *ft_get_prop(void *bphp, const char *propname, int *szp)
 
 /********************************************************************/
 
-/* Function that returns a character from the environment */
-extern uchar(*env_get_char) (int);
-
 #define BDM(x)	{	.name = #x, .offset = offsetof(bd_t, bi_ ##x ) }
 
 #ifdef CONFIG_OF_HAS_BD_T
diff --git a/include/common.h b/include/common.h
index 54083f1..4fed250 100644
--- a/include/common.h
+++ b/include/common.h
@@ -229,6 +229,7 @@ extern ulong load_addr;		/* Default Load Address */
 /* common/cmd_nvedit.c */
 int	env_init     (void);
 void	env_relocate (void);
+uchar	env_get_char (int);
 int	envmatch     (uchar *, int);
 char	*getenv	     (char *);
 int	getenv_r     (char *name, char *buf, unsigned len);
-- 
1.5.4.3






From stelian at popies.net  Sat Apr  5 20:02:39 2008
From: stelian at popies.net (Stelian Pop)
Date: Sat, 05 Apr 2008 20:02:39 +0200
Subject: [U-Boot-Users] AT91 Header File Clarification
In-Reply-To: <206b9e70804041632o391fc02fscac580e81b4bec7c@mail.gmail.com>
References: <206b9e70804041332w695212f3me41cfa8f7f182f11@mail.gmail.com>
	<1207347950.3762.3.camel@voyager.dsnet>
	<206b9e70804041632o391fc02fscac580e81b4bec7c@mail.gmail.com>
Message-ID: <1207418559.4841.7.camel@voyager.dsnet>


Le vendredi 04 avril 2008 ? 16:32 -0700, Zac Wheeler a ?crit :
> On Fri, Apr 4, 2008 at 3:25 PM, Stelian Pop <stelian at popies.net> wrote:
> >
> >  Le vendredi 04 avril 2008 ? 13:32 -0700, Zac Wheeler a ?crit :
> >
> > > I have a question about the arrangement of include files for the
> >  > at91sam9 family.
> >  >
> >  > Is the intention that asm/arch/at91_xxx.h be applicable for all
> >  > at91sam9 microcontrollers, or should they be broken down into subarch
> >  > folders (e.g. asm/arch/at91sam9261/at91_pmc.h)?
> >
> >  They are supposed to be shareable for all at91sam microcontrollers, in
> >  the same way it's done in Linux.
> 
> So should things like AT91_ECC as defined in at91sam960.h be
> AT91SAM9260_ECC instead or moved to an at91_sys.h file?

No, the idea is to keep the same conventions as the kernel guys. In fact
the header files have been copied from Linux, and are 95% identical to
them (we cannot use the header files provided by Atmel, because there is
too much craft inside, and rewriting a third form of the same headers
seemed to me too error prone).

As for AT91_ECC:

at91cap9.h:#define AT91_ECC     (0xffffe200 - AT91_BASE_SYS)
at91sam9260.h:#define AT91_ECC  (0xffffe800 - AT91_BASE_SYS)
at91sam9263.h:#define AT91_ECC0 (0xffffe000 - AT91_BASE_SYS)
at91sam9263.h:#define AT91_ECC1 (0xffffe600 - AT91_BASE_SYS)
at91sam9rl.h:#define AT91_ECC   (0xffffe800 - AT91_BASE_SYS)

seems to me quite nice this way !

>  It seems
> somewhat dangerous to define an AT91_ in a AT91SAM9260-specific file.

It shouldn't be. All the AT91 platforms have pretty much the same
hardware, so having the same constants means we don't need extra #ifdefs
in the driver code.

Of course, one should take care of including only the header file which
goes with his platform. This is what
include/asm-arm/arch-at91sam9/hardware.h does: based on what
CONFIG_AT91xxxxx is defined, the relevant platform specific header file
is included.

Stelian.
-- 
Stelian Pop <stelian at popies.net>




From info at whereareyounow.com  Sun Apr  6 04:59:52 2008
From: info at whereareyounow.com (WAYN.com)
Date: Sun, 6 Apr 2008 03:59:52 +0100
Subject: [U-Boot-Users] Sandeep has connected with you on WAYN
Message-ID: <e3a99a4f6136e97836f8a9a10637f4b6@whereareyounow.com>

Hi u-boot-users 

Sandeep has connected with you on WAYN 

To find out why, click on the following link: 

http://www.wayn.com/waynfx.html?wci=link&id=1918&mks=11994177&mx=11994177&cx=384251485&cx_token=4f816d634b90f704bac38f7b6315ae77 

If you do not wish to receive notifications of your friends connecting with you through WAYN, click here
http://www.wayn.com/wayn.html?wci=link&id=1919&mkeys=11994177&hash=F356233EF5D78F2D3FE3475550D35923

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080406/11c4f43e/attachment.htm 

From tj_jac at yahoo.co.in  Sun Apr  6 09:47:50 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Sun, 6 Apr 2008 13:17:50 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup
Message-ID: <234163.79395.qm@web94605.mail.in2.yahoo.com>

Hi all,

After uboot comes up, I get stuck with the booting of linux kernel. The RAM range is from 0x30000000-0x38000000. Following are the steps I do to get the uImage.bin.

$ arm-linux-objcopy -O binary -R .note -R ..comment -S vmlinux linux.bin
$ gzip -9 linux.bin
$ ../u-boot-1.3.2/tools/mkimage -A arm -O linux -T kernel -C gzip -a 0x30008000 -e 0x30008000 -n "Linux kernel" -d linux.bin.gz uImage.bin
Image Name:   Linux kernel
Created:      Sun Apr  6 12:19:12 2008
Image Type:   ARM Linux Kernel Image (gzip compressed)
Data Size:    4271627 Bytes = 4171.51 kB = 4.07 MB
Load Address: 0x30008000
Entry Point:  0x30008000

After this I put the uImage.bin at 0x33000000, restart uboot and I get:

U-Boot 1.3.2 (Apr  6 2008 - 12:03:10)

DRAM:  128 MB
Flash: 32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 33000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    4271627 Bytes =  4.1 MB
   Load Address: 30008000
   Entry Point:  30008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

undefined instruction
pc : [<30808004>]          lr : [<3101175c>]
sp : 30fcfaf8  ip : 30fcffb8     fp : 00000000
r10: 00000001  r9 : 30fcfe98     r8 : 30fcffdc
r7 : cf032d24  r6 : 33000040     r5 : 31019544  r4 : 31019541
r3 : 30fcfe55  r2 : 30000100     r1 : 0000016a  r0 : 00000000
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

data abort
pc : [<31010ca8>]          lr : [<31010d40>]
sp : 30fcfa88  ip : 3101b06c     fp : 00000000
r10: 00000001  r9 : 30fcfe98     r8 : 30fcffdc
r7 : cf032d24  r6 : 33000040     r5 : 00658d7f  r4 : 00036042
r3 : 3101b070  r2 : 0000566d     r1 : 00003307  r0 : 000032ff
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32
Resetting CPU ...

data abort
pc : [<31010ca8>]          lr : [<31010cf4>]
sp : 30fcfa10  ip : ffffffff     fp : 00000000
r10: 00000001  r9 : 30fcfe98     r8 : 30fcffdc
r7 : cf032d24  r6 : 33000040     r5 : 30fcfa74  r4 : 00000000
r3 : 3101b070  r2 : 30fcfa30     r1 : 00003307  r0 : 00003200
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32
Resetting CPU ...

And it keeps on resetting the CPU.

Is it the problem with the settings of uboot or the kernel and what should I do to bring the linux kernel up? Where could I find more information regarding this?

Kindly help me out.

Thanks in advance.
Tiju




      Share files, take polls, and make new friends - all under one roof. Go to http://in.promos.yahoo.com/groups/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080406/0367c8fa/attachment.htm 

From tj_jac at yahoo.co.in  Sun Apr  6 11:03:16 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Sun, 6 Apr 2008 14:33:16 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup
Message-ID: <552728.31594.qm@web94605.mail.in2.yahoo.com>

Hi all,

Afteruboot comes up, I get stuck with the booting of linux kernel. The RAMrange is from 0x30000000-0x38000000. Following are the steps I do toget the uImage.bin.

$ arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
$ gzip -9 linux.bin
$../u-boot-1.3.2/tools/mkimage -A arm -O linux -T kernel -C gzip -a0x30008000 -e 0x30008000 -n "Linux kernel" -d linux.bin.gz uImage.bin
Image Name:   Linux kernel
Created:      Sun Apr  6 12:19:12 2008
Image Type:   ARM Linux Kernel Image (gzip compressed)
Data Size:    4271627 Bytes = 4171.51 kB = 4.07 MB
Load Address: 0x30008000
Entry Point:  0x30008000

After this I put the uImage.bin at 0x33000000, restart uboot and I get:
U-Boot 1.3.2 (Apr  6 2008 - 12:03:10)

DRAM:  128 MB
Flash: 32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 33000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    4271627 Bytes =  4.1 MB
   Load Address: 30008000
   Entry Point:  30008000
   Verifying Checksum ... Bad Data CRC
DPB2440 #

Isit the problem with the settings of uboot or the kernel and what shouldI do to bring the linux kernel up? Where could I find more informationregarding this?

Kindly help me out.

Thanks in advance.
Tiju







      Share files, take polls, and make new friends - all under one roof. Go to http://in.promos.yahoo.com/groups/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080406/9c8b3e43/attachment.htm 

From plagnioj at jcrosoft.com  Sun Apr  6 13:18:40 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sun, 6 Apr 2008 13:18:40 +0200
Subject: [U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h
In-Reply-To: <1207171147-3228-1-git-send-email-afleming@freescale.com>
References: <20080402185750.62979243AB@gemini.denx.de>
	<1207171147-3228-1-git-send-email-afleming@freescale.com>
Message-ID: <20080406111840.GC17404@game.jcrosoft.org>

On 16:19 Wed 02 Apr     , Andy Fleming wrote:
> Some systems have md5.h installed in /usr/include/.  This isn't the desired
> file (we want the one in include/md5.h).  This will avoid the conflict.
> This fixes the host tools building problem
> 
> Signed-off-by: Andy Fleming <afleming at freescale.com>
> ---
> 
> This fixes the problem for me, at least...
> 
>  common/image.c       |    4 ++--
>  include/u-boot-md5.h |   23 +++++++++++++++++++++++
>  lib_generic/md5.c    |    2 +-
>  3 files changed, 26 insertions(+), 3 deletions(-)
>  create mode 100644 include/u-boot-md5.h
> 
> diff --git a/common/image.c b/common/image.c
> index f04826a..2ee49ef 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -53,7 +53,7 @@
>  #endif
>  
>  #if defined(CONFIG_FIT)
> -#include <md5.h>
> +#include <u-boot-md5.h>
Could we create an u-boot dirent like do int linux like
#include <u-boot/md5.h>

Best Regards
J.



From leon.woestenberg at gmail.com  Sun Apr  6 14:03:11 2008
From: leon.woestenberg at gmail.com (Leon Woestenberg)
Date: Sun, 6 Apr 2008 14:03:11 +0200
Subject: [U-Boot-Users] Linux kernel startup
In-Reply-To: <552728.31594.qm@web94605.mail.in2.yahoo.com>
References: <552728.31594.qm@web94605.mail.in2.yahoo.com>
Message-ID: <c384c5ea0804060503q67f0ad0fjff2b9db756a81149@mail.gmail.com>

Hello,

On Sun, Apr 6, 2008 at 11:03 AM, Tiju <tj_jac at yahoo.co.in> wrote:

We have seen both illegal instructions and crc errors for kernel > 4
MB on PowerPC.

I have to reproduce this, but we suspect the 4 MB boundary. This was
for an old u-boot.

Regards,
-- 
Leon



From mk at denx.de  Sun Apr  6 14:26:08 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Sun, 06 Apr 2008 14:26:08 +0200
Subject: [U-Boot-Users] [PATCH] remove error meesage in usb_ohci.c when
	debug is enabled
In-Reply-To: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDB05@blrms.slti.sanyo.co.in>
	(Gururaja Hebbar K. R.'s message of "Thu\,
	3 Apr 2008 06\:27\:59 +0530")
References: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDB05@blrms.slti.sanyo.co.in>
Message-ID: <871w5jw4nz.fsf@denx.de>


"Gururaja Hebbar K R" <gururajakr at sanyo.co.in> writes:

> In u-boot-1.3.1\drivers\usb\usb_ohci.c driver, if debug is enabled
> (#define DEBUG), make comes out with an error as below.

I appreciate your help, but this has already been fixed here:

commit 2596f5b9d353ff3e4387a3325d05740f16958038
Author: Stefan Roese <sr at denx.de>
Date:   Wed Mar 5 12:29:32 2008 +0100

    usb: Add CFG_OHCI_USE_NPS to common USB-OHCI driver
    
    This patch adds CFG_OHCI_USE_NPS to the common USB-OHCI driver. This
    way a board just needs to define this new option to enable the
    "force
    NoPowerSwitching mode" instead of adding new CPU/architecture
    defines
    to the USB source itself.
    
    This new option will be used first with the new AMCC 460EX
    Canyonlands
    board port, which will be posted in a few days.
    
    This patch also fixes a small compilation problem when DEBUG is
    enabled.

> This is due to a missing } for function ohci_dump @ line 408.
>  
> Below patch corrects the same.
>  
> Comments are welcome.

Please make sure to base any patches on the newest top of git version of
u-boot.

Best regards

Markus Klotzbuecher

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



From Aimar-tithysuu at THEMEDCHEST.COM  Sun Apr  6 14:45:07 2008
From: Aimar-tithysuu at THEMEDCHEST.COM (Aimar)
Date: Sun, 6 Apr 2008 15:45:07 +0300
Subject: [U-Boot-Users] Largest selection of watches online here
Message-ID: <ACA7E479.A%Aimar-tithysuu@THEMEDCHEST.COM>

Check out our selection of Bling-Bling watches here now http://www.pojerrant.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080406/b303225e/attachment.htm 

From mk at denx.de  Sun Apr  6 14:51:28 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Sun, 06 Apr 2008 14:51:28 +0200
Subject: [U-Boot-Users] [PATCH] Remove duplicate #undef SHOW_INFO inside
	drivers\usb\usb_ohci.c
In-Reply-To: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF5@blrms.slti.sanyo.co.in>
	(Gururaja Hebbar K. R.'s message of "Wed\,
	2 Apr 2008 11\:04\:43 +0530")
References: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF5@blrms.slti.sanyo.co.in>
Message-ID: <87skxzuoxb.fsf@denx.de>

Dear Gururaja,

"Gururaja Hebbar K R" <gururajakr at sanyo.co.in> writes:

>    In drivers\usb\usb_ohci.c file, SHOW_INFO is undef at 2 locations.
>    @line 77 and @line 112. Below patch removes them for code size savings.
>
>    comments welcome.

Thank you, well spotted.

But, git-am fails for for two reasons:

1. It chokes on your HTML mail. Please send plain text. 

>    --- usb_orig.c 2007-12-06 01:21:19.000000000 -0800
>    +++ usb_ohci.c 2008-04-02 14:06:23.937500000 -0700
>    @@ -109,7 +109,6 @@ static struct pci_device_id ohci_pci_ids
>     #define dbg(format, arg...) do {} while(0)

2. Please send a real diff containing the full path. Check the section
   "Submitting Patches" in the README if unsure.

Please cleanup and resubmit.

Thanks!

Best regards

Markus Klotzbuecher

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



From mk at denx.de  Sun Apr  6 19:37:32 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Sun, 06 Apr 2008 19:37:32 +0200
Subject: [U-Boot-Users] make env
In-Reply-To: <47F36B7A.9080104@feig.de> (Manuel Sahm's message of "Wed\,
	02 Apr 2008 13\:18\:18 +0200")
References: <20080402103950.98436243AB@gemini.denx.de>
	<47F36B7A.9080104@feig.de>
Message-ID: <87od8mvq8z.fsf@denx.de>

Manuel Sahm <Manuel.Sahm at feig.de> writes:

> how does uboot handle this flag byte ? (i I use redundant nand)

As you can't invalidate the old NAND environment as you can with NOR
flash, counters are used instead. So for NAND, the flag byte is a
counter which gets incremented for each write. This means the
environment with the flag containing the larger value is the valid one,
except for the case when the counter overflows and the valid environment
flag holds the value 0 and the former one 255.

Actually it would make sense to use this technique for NOR flash
identically, as it would avoid one write access to the flash.

Check out common/env_nand.c for details.

Best regards

Markus Klotzbuecher

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



From haavard.skinnemoen at atmel.com  Mon Apr  7 01:13:36 2008
From: haavard.skinnemoen at atmel.com (Haavard Skinnemoen)
Date: Sun, 6 Apr 2008 19:13:36 -0400
Subject: [U-Boot-Users] [PATCH] Add support for hammerhead AVR32 board
In-Reply-To: <47F02540.6010405@qstreams.com>
References: <20080314155409.C2DE3247AF@gemini.denx.de>
	<47DE488E.2060502@miromico.ch> <47F02540.6010405@qstreams.com>
Message-ID: <20080406191336.185f1d90@siona.local>

On Sun, 30 Mar 2008 19:41:52 -0400
Ben Warren <bwarren at qstreams.com> wrote:

> I have a patch that will be submitted tomorrow that puts a call to 
> board_eth_init() here, so you don't need to. If this is already in the 
> AVR32 repo no big deal.

FWIW, it's not in the AVR32 repo yet. I think the patch needs another
spin to address the comments that came up.

That said, I'm totally out of sync with most mailing lists right now,
so if a newer version was posted without me in the Cc list, I haven't
noticed it yet.

Haavard



From tj_jac at yahoo.co.in  Mon Apr  7 07:46:18 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Mon, 7 Apr 2008 11:16:18 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup
Message-ID: <806156.54383.qm@web94607.mail.in2.yahoo.com>

Hi Leon,

> We have seen both illegal instructions and crc errors for kernel > 4
> MB on PowerPC.

Even when the kernel size is 1.09 MB the same BAD CRC error occurs.
Is it the error with the kernel  or the uboot itself. If so what could be the problem?
Output is as follows.

U-Boot 1.3.2 (Apr  7 2008 - 11:05:53)

DRAM:  128 MB
Flash: 32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 33000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    1141366 Bytes =  1.1 MB
   Load Address: 30008000
   Entry Point:  30008000
   Verifying Checksum ... Bad Data CRC


Any help will be appreciated.

Thanks in advance.
Tiju






      Share files, take polls, and make new friends - all under one roof. Go to http://in.promos.yahoo.com/groups/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080407/2dcfea51/attachment.htm 

From laforge at gnumonks.org  Sun Apr  6 12:04:21 2008
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 6 Apr 2008 12:04:21 +0200
Subject: [U-Boot-Users] s3c2440 -- serial_init
In-Reply-To: <331126.21783.qm@web94613.mail.in2.yahoo.com>
References: <331126.21783.qm@web94613.mail.in2.yahoo.com>
Message-ID: <20080406100421.GF3574@prithivi.gnumonks.org>

On Fri, Mar 28, 2008 at 04:58:37PM +0530, Tiju wrote:
> Hi all
> 
> I am trying to port u-boot to a s3c2440 samsung processor. 
> 
> I applied the smdk2440 boards patch (almost similar architecture) and
> trying to modify it for our board's requirement. But during the
> serial_init it goes to the _serial_putc and then after certain loops
> it goes to the hang function and hangs there.

this sounds like a flow control issue.  The s3c24xx boards support
hardware flow control handling, i.e. their TX FIFO will not transmit any
more characters unless the RTS/CTS handshake allows it to.

Since the u-boot serial code does an endless loop waiting for the next
character, it will busy-wait there.

Please note that this is true even for UARTs that don't even have
RTS/CTS.  Don't use hw flow control on them.

Another possible cause could be lack of proper GPIO configuration for
the RTS/CTS pins, missing connection on the board, broken serial cable.

Basically anthing that affects RTS/CTS from within the s3c24xx and the
PC on the other side.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080406/ba4eb1bf/attachment.pgp 

From laforge at gnumonks.org  Sun Apr  6 12:07:42 2008
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 6 Apr 2008 12:07:42 +0200
Subject: [U-Boot-Users] s3c2440 -- serial_init
In-Reply-To: <714304.63380.qm@web94613.mail.in2.yahoo.com>
References: <714304.63380.qm@web94613.mail.in2.yahoo.com>
Message-ID: <20080406100742.GG3574@prithivi.gnumonks.org>

On Fri, Apr 04, 2008 at 08:29:48PM +0530, Tiju wrote:
> Hi Vishal,
> 
> I am stuck with the Kernel load address and entry point. It keeps on
> resetting. Output as shown below.

are you sure

1) your PLL's are configured correctly, i.e.
* the memory bus doesn't exceed the maximum bus frequency allowed given
  your capacitive bus load (see samsung manual)
* the core CPU speed doesn't exceed the max speed
* the core CPU voltage is configued correct for the core CPU clock rate

2) Are you sure your linux kernel is compiled for the right ARM variant
   with no strange compiler flags?

I suggest running extensive memory testing routines (u-boot has memory
testing built-in) before trying to boot the kernel, just to make sure
the entire hardware and PLL / power config is stable at all.

Another interesting question would be to compare the memory contents at
the program counter with the content it should have according to the
uImage/zImage/vmlinux file of th kernel.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080406/3b44af5b/attachment.pgp 

From laforge at gnumonks.org  Sun Apr  6 12:01:17 2008
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 6 Apr 2008 12:01:17 +0200
Subject: [U-Boot-Users] LZMA support (patch)
In-Reply-To: <20080328223358.EB0B9248BE@gemini.denx.de>
References: <5566.213.156.35.235.1206739577.webmail@webmail.idf-hit.com>
	<20080328223358.EB0B9248BE@gemini.denx.de>
Message-ID: <20080406100117.GE3574@prithivi.gnumonks.org>

Hi Wolfgang, Luigi,

On Fri, Mar 28, 2008 at 11:33:58PM +0100, Wolfgang Denk wrote:

> Either the license is compatible, and the code can be included, or it
> is not, then it cannot. In the latter case, the whole patch makes no
> sense.

Given my expertise with license compliance, I volunteer to look into the
legal issues, to the point that if I have any doubt I will consult with
my legal counsel on that subject.

> > LMZA performs better than LZ on binary files. I will switch to
> > LZMA to save flash memory space on my appliance. Of course, the
> > LZMA is slower than LZ.
> 
> But so far there is no code (board support) in  U-Boot  to  use  this
> feature, right? And it's not used by the Linux kernel either?

As for board support / LZMA: I don't know.  But I'm pretty sure that
I've seen LZMA compressed u-boot images before.  LZMA is really popular
with cheap consumer-grade embedded linux equipment, particularly DSL CPE
and Wifi Routers.  Most of them don't use u-boot, but only use it for
the kernel image and the flash filesystem.  They're using quite simple
out-of-tree patches for that, though.

I think this has come up on lkml before, and Linus didn't like it very
much.  Probably related to the fact that many core kernel hackers look
at embedded as sort of a special case, when in reality I am quite sure
that the total quantity of embedded systems running Linux is
significantly larger than the number of Linux servers + desktops
together...

> And your patch does not even enable support for it in the mkimage
> tool, so you cannot even create images that use the feature?

That has obviously to be fixed.
 
> How exactly is this code supposed to be used?

some documentation would certainly be fine, yes.

> > Anyway, if the LZMA SDK license is compatible with U-boot , I
> > think that LZMA should be chosen by firmware developer when the
> > flash memory space is a critical resource.
> 
> Frankly, if you are so short with flash you have a h/w dsign problem.

Yes and no.  I tend to agree, but I also realize that there are economic
incentives to keep the bom cost as low as possible, especially in
large-quantity consumer equipment...

You can just as well claim: If you're using suboptimal compression and
wasting flash space, you have a software design problem ;)

I think it makes a lot of sense to add LZMA support to u-boot, but
obviously in a clean, consistent, documented way.  It doesn't hurt, will
not be compiled unless explicitly selected, and the API is zlib like,
i.e. the code changes it requires are non-intrusive.

Just my thoughs...

--
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080406/432514cb/attachment.pgp 

From tj_jac at yahoo.co.in  Mon Apr  7 11:01:10 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Mon, 7 Apr 2008 14:31:10 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup
Message-ID: <957237.38070.qm@web94608.mail.in2.yahoo.com>

Hi Harald,

The serial issues were solved. As u said, the problem was with the RTS/CTS. I disabled all the hardware control signals and some modifications with the relocation section in the start.S and it started working.

Now the issue is with the kernel CRC32 check. I compiled a kernel with the smdk2440 architecture and I do the following.

$ arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
$ gzip -9 linux.bin
$../u-boot-1.3.2/tools/mkimage -A arm -O linux -T kernel -C gzip -a0x30008000 -e 0x30008000 -n "Linux kernel" -d linux.bin.gz uImage.bin

The size of vmlinux is around 25MB. When converted to linux.bin it is 3GB, when gziped it is around 4MB and when done an mkimage it remains almost the same..

The output is as follows:

U-Boot 1.3.2 (Apr  7 2008 - 12:14:29)

DRAM:  128 MB
Flash: 32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 33000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    4271633 Bytes =  4.1 MB
   Load Address: 30008000
   Entry Point:  30008000
   Verifying Checksum ... Bad Data CRC

What ever kernel image I load it tells the same ie. "Verifying Checksum ... Bad Data CRC". I even tried the uImage.bin which was available on openmoko site and the same error occurs.

Is the error with the bootloader or the kernel image? If so what are the changes to be done?

Thanks in advance.
Tiju




      Messenger blocked? Want to chat? Go to http://in.messenger.yahoo.com/webmessengerpromo.php
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080407/a2630758/attachment.htm 

From laforge at gnumonks.org  Mon Apr  7 14:20:33 2008
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 7 Apr 2008 14:20:33 +0200
Subject: [U-Boot-Users] Linux kernel startup
In-Reply-To: <957237.38070.qm@web94608.mail.in2.yahoo.com>
References: <957237.38070.qm@web94608.mail.in2.yahoo.com>
Message-ID: <20080407122033.GD4193@prithivi.gnumonks.org>

On Mon, Apr 07, 2008 at 02:31:10PM +0530, Tiju wrote:
> Hi Harald,
> 
> The serial issues were solved. As u said, the problem was with the
> RTS/CTS. I disabled all the hardware control signals and some
> modifications with the relocation section in the start.S and it
> started working.

great.

> Now the issue is with the kernel CRC32 check. I compiled a kernel with
> the smdk2440 architecture and I do the following.

Please see my other e-mail response about this.  I still believe there
might be some wrong memory / bus / core clock timing and or voltage
issues.  please try to use u-boot's built-in memory verification code to
veryify your memory before trying to boot a kernel on it.

What basically happens is that u-boot copies your kernel image from
storage medium to SDRAM, and then tries to checksum it.  If the original
image is correct, and the copy in SDRAM isn't, this means that you
somehow have memory corruption.

Is the hardware a prototype of a new board, or is it proven, verified
hardware?  If it's a new board, there can be dozens of different reasons
why the PLL might run instable, the power lines have too much noise,
etc.

Even if it's verified hardware, the particular PLL speed for memory or
CPU clock used by your u-boot image might not be within whatever your
hardware configuration supports.

So I would reconfigure all memory timings to their most conservative
(slowest) setting, and run the bus at 25 or 50MHz, the CPU core at
100MHz and re-try.  If the memory check and/or system boot works this
way, you can try to increase the timings incrementally up to your
desired configuration.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080407/2a486379/attachment.pgp 

From gerald.vanbaren at ge.com  Mon Apr  7 14:52:26 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Mon, 07 Apr 2008 08:52:26 -0400
Subject: [U-Boot-Users] Linux kernel startup
In-Reply-To: <957237.38070.qm@web94608.mail.in2.yahoo.com>
References: <957237.38070.qm@web94608.mail.in2.yahoo.com>
Message-ID: <47FA190A.3030803@ge.com>

Tiju wrote:
> Hi Harald,
> 
> The serial issues were solved. As u said, the problem was with the 
> RTS/CTS. I disabled all the hardware control signals and some 
> modifications with the relocation section in the start..S and it started 
> working.
> 
> Now the issue is with the kernel CRC32 check. I compiled a kernel with 
> the smdk2440 architecture and I do the following.
> 
> $ arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
> $ gzip -9 linux.bin
> $ ../u-boot-1.3.2/tools/mkimage -A arm -O linux -T kernel -C gzip -a 
> 0x30008000 -e 0x30008000 -n "Linux kernel" -d linux.bin.gz uImage.bin
> 
> The size of vmlinux is around 25MB. When converted to linux.bin it is 
> 3GB, when gziped it is around 4MB and when done an mkimage it remains 
> almost the same.

This is indicating you have major link / memory map / coding issue(s). 
vmlinux should be around 1MB, not 25MB!  linux.bin should be around the 
same size as vmlinux.  Having linux.bin grow to be 3GB indicates it has 
major holes in it that objdump is filling with "fill" values.

Loading a 3GB image (compressed to 4MB or not) is simply not going to work.

Use objdump to dump the section headers of the elf file (vmlinux) to see 
what addresses are being used and sizes of the sections.  Figure out why 
it is producing pieces of code/data in widely varying address locations 
and possibly large sections of "bad" stuff.  Until you fix your link, 
you aren't going to have any success loading it.

Good luck,
gvb



From sander at vermin.nl  Mon Apr  7 15:16:07 2008
From: sander at vermin.nl (Sander Vermin)
Date: Mon, 07 Apr 2008 15:16:07 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
Message-ID: <47FA1E97.50706@vermin.nl>

Hello,

I'm trying to build a U-Boot from your git tree with the AT91 patches. 
My board is a custom board with a KS8721 instead of the DM9161 network 
PHY chip. This is the same chip as Olimex used on their development board.

Olimex build a U-Boot for their board, they did some code hacking on 
u-boot. As far as I know they did the following to get the ethernet up 
and running. [1] This is in the board/at91sam9260ek/dm9161a.c file

On the latest git version with the AT91 patches the ethernet driver is 
called macb??!!

Do you know how I can get this working? (as hack and in the future more 
clean)

Kind regards,

Sander Vermin

[1]
static unsigned int dm9161a_IsPhyConnected (AT91PS_EMAC p_mac)
{
    unsigned short Id1, Id2;

    at91_EmacEnableMDIO (p_mac);
    at91_EmacReadPhy (p_mac, SAM9260EK_PHY_ADDRESS, DM9161_PHYID1, &Id1);
    at91_EmacReadPhy (p_mac, SAM9260EK_PHY_ADDRESS, DM9161_PHYID2, &Id2);
    at91_EmacDisableMDIO (p_mac);
   
    /*printf(" Id1 0x%04x\n", Id1);
    printf(" Id1 0x%04x\n", Id2);*/
   

    if ((Id1 == (DM9161_PHYID1_OUI >> 6)) &&
        ((Id2 >> 10) == (DM9161_PHYID1_OUI & DM9161_LSB_MASK))) {
      printf("DM9161A PHY Detected\n\r");
      return TRUE;
    }
   
    if ((Id1 == MICREL_ID_1) && (Id2 == MICREL_ID_2)) {
        printf("KS8721 PHY Detected\n\r");
        return TRUE;
    }
   
    return FALSE;
}





From tj_jac at yahoo.co.in  Mon Apr  7 15:30:29 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Mon, 7 Apr 2008 19:00:29 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup
Message-ID: <229581.20083.qm@web94613.mail.in2.yahoo.com>

Hi Jerry,

>This is indicating you have major link / memory map / coding issue(s). 
>vmlinux should be around 1MB, not 25MB!  linux.bin should be around the 
>same size as vmlinux.  Having linux.bin grow to be 3GB indicates it has 
>major holes in it that objdump is filling with "fill" values.

Loading a 3GB image (compressed to 4MB or not) is simply not going to work.

I will look into the kernel sections and try to figure it out. It maybe the problem with my compiler.

But my other major problem is that, what ever be the size of the kernel, it gives me a "Bad Data CRC". I tried with prebuild images from the openmoko (which are working images on openmoko 1.5MB) and still it shows me the same error. We have almost the same architecture as theirs. 

Does this have to do anything with the u-boot or some other issue?

Thank You,
Tiju.




      Meet people who discuss and share your passions. Go to http://in.promos.yahoo.com/groups/bestofyahoo/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080407/13e4a67f/attachment.htm 

From stelian at popies.net  Mon Apr  7 15:49:45 2008
From: stelian at popies.net (Stelian Pop)
Date: Mon, 07 Apr 2008 15:49:45 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <47FA1E97.50706@vermin.nl>
References: <47FA1E97.50706@vermin.nl>
Message-ID: <1207576185.6290.4.camel@galileo>


Le lundi 07 avril 2008 ? 15:16 +0200, Sander Vermin a ?crit :
> Hello,
> 
> I'm trying to build a U-Boot from your git tree with the AT91 patches. 
> My board is a custom board with a KS8721 instead of the DM9161 network 
> PHY chip. This is the same chip as Olimex used on their development board.
> 
> Olimex build a U-Boot for their board, they did some code hacking on 
> u-boot. As far as I know they did the following to get the ethernet up 
> and running. [1] This is in the board/at91sam9260ek/dm9161a.c file

Are the changes limited to recognizing the MICREL_* phy id 
> 
> On the latest git version with the AT91 patches the ethernet driver is 
> called macb??!!

Yes.

> Do you know how I can get this working? (as hack and in the future more 
> clean)

Did you test it as is ? From what I see in the code, the macb driver
doesn't care much about the PHY type...

Stelian.
-- 
Stelian Pop <stelian at popies.net>




From ebenard at free.fr  Mon Apr  7 15:54:06 2008
From: ebenard at free.fr (Eric BENARD)
Date: Mon, 07 Apr 2008 15:54:06 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <1207576185.6290.4.camel@galileo>
References: <47FA1E97.50706@vermin.nl> <1207576185.6290.4.camel@galileo>
Message-ID: <47FA277E.2050200@free.fr>

Stelian Pop a ?crit :
> Le lundi 07 avril 2008 ? 15:16 +0200, Sander Vermin a ?crit :
>> Hello,
>>
>> I'm trying to build a U-Boot from your git tree with the AT91 patches. 
>> My board is a custom board with a KS8721 instead of the DM9161 network 
>> PHY chip. This is the same chip as Olimex used on their development board.
>>
>> Olimex build a U-Boot for their board, they did some code hacking on 
>> u-boot. As far as I know they did the following to get the ethernet up 
>> and running. [1] This is in the board/at91sam9260ek/dm9161a.c file
> 
> Are the changes limited to recognizing the MICREL_* phy id 

from memory, on AT91RM9200 with KS8721SL, it was necessary to tweak some 
bits in order to change the "isolate" setting of the PHY.

Eric



From sander at vermin.nl  Mon Apr  7 16:14:08 2008
From: sander at vermin.nl (Sander Vermin)
Date: Mon, 07 Apr 2008 16:14:08 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <1207576185.6290.4.camel@galileo>
References: <47FA1E97.50706@vermin.nl> <1207576185.6290.4.camel@galileo>
Message-ID: <47FA2C30.7050609@vermin.nl>

Stelian Pop schreef:
> Le lundi 07 avril 2008 ? 15:16 +0200, Sander Vermin a ?crit :
>   
>> Hello,
>>
>> I'm trying to build a U-Boot from your git tree with the AT91 patches. 
>> My board is a custom board with a KS8721 instead of the DM9161 network 
>> PHY chip. This is the same chip as Olimex used on their development board.
>>
>> Olimex build a U-Boot for their board, they did some code hacking on 
>> u-boot. As far as I know they did the following to get the ethernet up 
>> and running. [1] This is in the board/at91sam9260ek/dm9161a.c file
>>     
>
> Are the changes limited to recognizing the MICREL_* phy id 
>   
>> On the latest git version with the AT91 patches the ethernet driver is 
>> called macb??!!
>>     
>
> Yes.
>
>   
>> Do you know how I can get this working? (as hack and in the future more 
>> clean)
>>     
>
> Did you test it as is ? From what I see in the code, the macb driver
> doesn't care much about the PHY type...
>
> Stelian.
>   
I did test it, u-boot says no PHY present. I had to change from RMII 
mode to MII mode due to my hardware design.

Regards,

Sander




From Eugene.O'Brien at advantechamt.com  Mon Apr  7 16:29:49 2008
From: Eugene.O'Brien at advantechamt.com (Eugene O'Brien)
Date: Mon, 7 Apr 2008 10:29:49 -0400
Subject: [U-Boot-Users] [PATCH] PPC440 Power Management Registers
In-Reply-To: <200804041604.42214.sr@denx.de>
References: <8B3930FEA8618C44B48EB06B5D33A06E12FD07@satmail.Advantech.ca>
	<200804041604.42214.sr@denx.de>
Message-ID: <8B3930FEA8618C44B48EB06B5D33A06E12FD0B@satmail.Advantech.ca>

Hello Stefan,

I had a look at all PPC440 processor manuals from AMCC and see that my
patch applies to all of them. In other words the #else portion is never
used. Therefore I am submitting a patch that cleans up this code quite
nicely.

Another observation that I made is that the PPC440EPx and PPC440GPx
require more than 32 bits to control the power management functions.
Therefore I defined a second set of registers cpc1_er, cpc1_fr, cpc1_sr
for these processors. These can be used as placeholders for future
development.

Let me know if this sounds good to you.

Regards,
Eugene


-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: April 4, 2008 10:05 AM
To: Eugene O'Brien
Subject: Re: Patch for PPC440EP

Hi Eugene,

On Friday 04 April 2008, Eugene O'Brien wrote:
> Here is patch for the PPC440EP. The DCR addresses of the power
> management registers were not correctly defined. This patch corrects
> that. You can check the PPC440EP UM p301 to confirm. I also used the
> BDI2000 to double check.

Thanks.

I suggest the following change:

Instead of:

-#if defined(CONFIG_440GX) || \
+#if defined(CONFIG_440GX) || defined(CONFIG_440EP)  || \

please use:

+    defined(CONFIG_440EP) || defined(CONFIG_440GR)  || \

This way 440GP will be added too. And if we're at it, please check if
440EPx 
and 440GRx also need this change. If yes, please include them too.

And please post the patch to the mailing list for review. I can't accept

patches without public review nowadays, since we changed the development

process.

Thanks for your input.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pow_mgt_patch_2.txt
Url: http://lists.denx.de/pipermail/u-boot/attachments/20080407/cadf1d29/attachment.txt 

From tj_jac at yahoo.co.in  Mon Apr  7 17:39:36 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Mon, 7 Apr 2008 21:09:36 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup
Message-ID: <315452.78275.qm@web94616.mail.in2.yahoo.com>

Hi Harald,

>Please see my other e-mail response about this.  I still believe there
>might be some wrong memory / bus / core clock timing and or voltage
>issues.  

We changed the memory clock to a lower frequency(90MHz to 67MHz) and the the "Bad Data CRC" error has gone. Thanks alot.
Our settings are: EXTCLK = 12MHz
                                  FCLK = 271 MHz
                                  HCLK = 67.75 MHz

>please try to use u-boot's built-in memory verification code to
>veryify your memory before trying to boot a kernel on it.
We will do this now.

We are writing the kernel image directly to the ram to 33000000. Therefore as for now it is not copied from the flash.

>Is the hardware a prototype of a new board, or is it proven, verified
>hardware? 
Yes, the hardware is a new prototype.

The output now is as follows:

U-Boot 1..3.2 (Apr  7 2008 - 17:25:31)

DRAM:  128 MB
Flash: 32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 33000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    4278410 Bytes =  4.1 MB
   Load Address: 30008000
   Entry Point:  30008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

undefined instruction
pc : [<30008018>]          lr : [<310117bc>]
sp : 30fcfa78  ip : 30fcffb8     fp : 00000000
r10: 00000001  r9 : 30fcfe18     r8 : 30fcffdc
r7 : 31012ef4  r6 : 33000040     r5 : 31019514  r4 : 31019511
r3 : 30008000  r2 : 30000100     r1 : 0000016a  r0 : 00000000
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...


U-Boot 1.3.2 (Apr  7 2008 - 17:25:31)

DRAM:  128 MB
Flash: 32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 33000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    4278410 Bytes =  4.1 MB
   Load Address: 30008000
   Entry Point:  30008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

undefined instruction
pc : [<30008018>]          lr : [<310117bc>]
sp : 30fcfa78  ip : 30fcffb8     fp : 00000000
r10: 00000001  r9 : 30fcfe18     r8 : 30fcffdc
r7 : 31012ef4  r6 : 33000040     r5 : 31019514  r4 : 31019511
r3 : 30008000  r2 : 30000100     r1 : 0000016a  r0 : 00000000
Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
Resetting CPU ...

and it keeps on resetting. We further reduced the SDRAM frequency to 45 Mhz, but still the problem persist. Is it still the problem with the u-boot frequency or with the linux kernel?

Thanks again.
Tiju






      Save all your chat conversations.. Find them online at http://in.messenger.yahoo.com/webmessengerpromo.php
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080407/bff87b70/attachment.htm 

From seetomac1990 at PHAOSTRON.COM  Mon Apr  7 18:47:41 2008
From: seetomac1990 at PHAOSTRON.COM (sinan)
Date: Mon, 7 Apr 2008 12:47:41 -0400
Subject: [U-Boot-Users] We represent the best
Message-ID: <36DC4687.B%seetomac1990@PHAOSTRON.COM>

Discounts and top quality merchanidize only available cheap http://www.jieotap.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080407/1b2a1e28/attachment.htm 

From terence.lau at dolby.com  Mon Apr  7 19:36:30 2008
From: terence.lau at dolby.com (Lau, Terence)
Date: Mon, 7 Apr 2008 10:36:30 -0700
Subject: [U-Boot-Users] change boot partition
Message-ID: <05BB196AB3DA6C4BBE11AB6C957581FE0A4BD634@sfo-exch-01.dolby.net>

In the flash, I have the following partitions in a flash:

 

mtd0 : u-boot-1.1.4

mtd1 : rootfs

mtd2 : env

mtd3 : rootfs_upgrade

....

 

I noticed that uboot search the entire flash for uImage.  If I have 2
uImage (i.e. 2 root filesystems) in the flash, it will fail to boot up.
What I did is to lie the memory size to u-boot so that it only search
from mtd0 to mtd2.

 

Is there any command I can set to change where it is booted from?
(dev/mtd1 or dev/mtd3)

 

Thanks for your help.

 

Regards,

 

Terence

 

 

 

 

 




-----------------------------------------
This message (including any attachments) may contain confidential
information intended for a specific individual and purpose.  If you
are not the intended recipient, delete this message.  If you are
not the intended recipient, disclosing, copying, distributing, or
taking any action based on this message is strictly prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080407/8a72213a/attachment.htm 

From stelian at popies.net  Mon Apr  7 22:00:35 2008
From: stelian at popies.net (Stelian Pop)
Date: Mon, 07 Apr 2008 22:00:35 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <47FA2C30.7050609@vermin.nl>
References: <47FA1E97.50706@vermin.nl> <1207576185.6290.4.camel@galileo>
	<47FA2C30.7050609@vermin.nl>
Message-ID: <1207598435.5709.14.camel@galileo>


Le lundi 07 avril 2008 ? 16:14 +0200, Sander Vermin a ?crit :

> > Did you test it as is ? From what I see in the code, the macb driver
> > doesn't care much about the PHY type...

> I did test it, u-boot says no PHY present. I had to change from RMII 
> mode to MII mode due to my hardware design.

Ok, so there must be something else in the code which was changed to
support your PHY (look for some "isolate" setting like Eric said).
You'll need to find out what it is...

-- 
Stelian Pop <stelian at popies.net>





From ebenard at free.fr  Mon Apr  7 22:23:31 2008
From: ebenard at free.fr (Eric BENARD)
Date: Mon, 07 Apr 2008 22:23:31 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <1207598435.5709.14.camel@galileo>
References: <47FA1E97.50706@vermin.nl>
	<1207576185.6290.4.camel@galileo>	<47FA2C30.7050609@vermin.nl>
	<1207598435.5709.14.camel@galileo>
Message-ID: <47FA82C3.70002@free.fr>

Stelian Pop a ?crit :
> Le lundi 07 avril 2008 ? 16:14 +0200, Sander Vermin a ?crit :
> 
>>> Did you test it as is ? From what I see in the code, the macb driver
>>> doesn't care much about the PHY type...
> 
>> I did test it, u-boot says no PHY present. I had to change from RMII 
>> mode to MII mode due to my hardware design.
> 
> Ok, so there must be something else in the code which was changed to
> support your PHY (look for some "isolate" setting like Eric said).
> You'll need to find out what it is...
> 
please find attached a quick and dirty hacked ks8721.c  and the 
corresponding .h
It works on an AT91RM9200 with u-boot 1.3.2.

Eric

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ks8721.c
Type: text/x-csrc
Size: 7208 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080407/a34ed1bf/attachment.c 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ks8721.h
Type: text/x-chdr
Size: 5093 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080407/a34ed1bf/attachment.h 

From stelian at popies.net  Mon Apr  7 22:49:17 2008
From: stelian at popies.net (Stelian Pop)
Date: Mon, 07 Apr 2008 22:49:17 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <47FA82C3.70002@free.fr>
References: <47FA1E97.50706@vermin.nl> <1207576185.6290.4.camel@galileo>
	<47FA2C30.7050609@vermin.nl> <1207598435.5709.14.camel@galileo>
	<47FA82C3.70002@free.fr>
Message-ID: <1207601357.5709.25.camel@galileo>


Le lundi 07 avril 2008 ? 22:23 +0200, Eric BENARD a ?crit :
> Stelian Pop a ?crit :
> > Le lundi 07 avril 2008 ? 16:14 +0200, Sander Vermin a ?crit :
> > 
> >>> Did you test it as is ? From what I see in the code, the macb driver
> >>> doesn't care much about the PHY type...
> > 
> >> I did test it, u-boot says no PHY present. I had to change from RMII 
> >> mode to MII mode due to my hardware design.
> > 
> > Ok, so there must be something else in the code which was changed to
> > support your PHY (look for some "isolate" setting like Eric said).
> > You'll need to find out what it is...
> > 
> please find attached a quick and dirty hacked ks8721.c  and the 
> corresponding .h
> It works on an AT91RM9200 with u-boot 1.3.2.

Hmm, if I sed:
	s/KS8721/DM9161/g
and
	s/ks8721/dm9161/g

on your files I find almost no change with regard to the original
version, except:

#define PHY_ADDRESS (1<<5)

and a #if 0 commenting out a bit of the initialisation sequence...

This makes me think it may only be a PHY_ADDRESS issue: what happens if
you change in cpu/arm926ejs/at91sam9/ether.c :

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);

to

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);

Stelian.
-- 
Stelian Pop <stelian at popies.net>




From ebenard at free.fr  Mon Apr  7 22:55:16 2008
From: ebenard at free.fr (Eric BENARD)
Date: Mon, 07 Apr 2008 22:55:16 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <1207601357.5709.25.camel@galileo>
References: <47FA1E97.50706@vermin.nl>
	<1207576185.6290.4.camel@galileo>	<47FA2C30.7050609@vermin.nl>
	<1207598435.5709.14.camel@galileo>	<47FA82C3.70002@free.fr>
	<1207601357.5709.25.camel@galileo>
Message-ID: <47FA8A34.8080603@free.fr>

Stelian Pop a ?crit :
> Hmm, if I sed:
> 	s/KS8721/DM9161/g
> and
> 	s/ks8721/dm9161/g
> 
> on your files I find almost no change with regard to the original
> version, except:
> 
> #define PHY_ADDRESS (1<<5)
> 
> and a #if 0 commenting out a bit of the initialisation sequence...
> 
yes, goal was to make a clean driver starting from dm9161 with 
PHY_ADDRESS in the config file ... but I didn't had time to progress on 
it :-(
Isolate problem can happen depending on the pullup/down configuration I 
think (I didn't check in tthe datasheet, but I once met the problem).

> This makes me think it may only be a PHY_ADDRESS issue: what happens if
> you change in cpu/arm926ejs/at91sam9/ether.c :
> 
> macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
> 
> to
> 
> macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);
> 
It's not running on a 9260 so I can't test but it should work (and this 
may be the problem Sander have).

Eric



From laforge at gnumonks.org  Mon Apr  7 23:25:13 2008
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 7 Apr 2008 23:25:13 +0200
Subject: [U-Boot-Users] Linux kernel startup (s3c24xx)
In-Reply-To: <315452.78275.qm@web94616.mail.in2.yahoo.com>
References: <315452.78275.qm@web94616.mail.in2.yahoo.com>
Message-ID: <20080407212513.GE4193@prithivi.gnumonks.org>

Hi Tiju,

On Mon, Apr 07, 2008 at 09:09:36PM +0530, Tiju wrote:

> >Please see my other e-mail response about this.  I still believe there
> >might be some wrong memory / bus / core clock timing and or voltage
> >issues.  
> 
> We changed the memory clock to a lower frequency(90MHz to 67MHz) and
> the the "Bad Data CRC" error has gone. Thanks alot.

ok, this most likely means that you have some problems with your
hardware design, probably exceeding the maximum permitted capacitive bus
load.

> We are writing the kernel image directly to the ram to 33000000.
> Therefore as for now it is not copied from the flash.

well, how do you copy the image into ram?  It doesn't really matter from
where the image is copied.  What matters is that apparently the source
of the copy is not equal to the destination of the copy.  Even if you
copy 'directly' via JTAG there is a source and a destination.   and the
destination will suffer through corruption if SDRAM timing or bus clock
are wrong.

> >Is the hardware a prototype of a new board, or is it proven, verified
> >hardware? 
> Yes, the hardware is a new prototype.

Well, then I suppose most of your problems are not u-boot problems but
problems related to your hardware.  You should verify your u-boot
version with a known-working hardware (such as a smdk development
board).  Only if it fails on the known-good hardware, I believe there is
sufficient reason to assume that the problem is actually a u-boot
problem.

> and it keeps on resetting. We further reduced the SDRAM frequency to
> 45 Mhz, but still the problem persist. Is it still the problem with
> the u-boot frequency or with the linux kernel?

* there is no u-boot frequency 
* the pll config done by u-boot is not the source of the problem,
  but rather some faulty hardware.  lowering the clock is merely
  a workaround and not a fix.

I think any further debugging would be very specific to your hardware
design.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080407/dd1ed9f6/attachment.pgp 

From wd at denx.de  Mon Apr  7 23:54:35 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 07 Apr 2008 23:54:35 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: Your message of "Mon, 31 Mar 2008 12:28:55 +0200."
	<200803311228.55346.sr@denx.de>
Message-ID: <20080407215435.7D40C242FB@gemini.denx.de>

In message <200803311228.55346.sr at denx.de> you wrote:
> The following changes since commit 234ea73c660cfd0b1c98de00995c32d4152d202f:
>   Wolfgang Denk (1):
>         Merge branch 'master' of git+ssh://10.10.0.7/home/wd/git/u-boot/master
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> 
> Wolgang, this is an update for the last pull-request with some addional patches
> applied. Thanks.

Merged, 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: wd at denx.de
Each honest calling, each walk of life, has its own  elite,  its  own
aristocracy based on excellence of performance. - James Bryant Conant



From wd at denx.de  Mon Apr  7 23:56:31 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 07 Apr 2008 23:56:31 +0200
Subject: [U-Boot-Users] [cfi-flash] Please pull
	git://www.denx.de/git/u-boot-cfi-flash.git
In-Reply-To: Your message of "Sat, 29 Mar 2008 06:54:45 +0100."
	<200803290654.45312.sr@denx.de>
Message-ID: <20080407215631.A7C5D242FB@gemini.denx.de>

In message <200803290654.45312.sr at denx.de> you wrote:
> The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
>   Bartlomiej Sieka (1):
>         Fix host tool build breakage, take two
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-cfi-flash.git master
> 
> Daniel Hellstrom (1):
>       MTD/CFI: flash_read64 is defined a weak function (for SPARC)
> 
> Tor Krill (1):
>       MTD/CFI: Add support for 16bit legacy AMD flash
> 
>  drivers/mtd/cfi_flash.c   |   48 +++++++++++++++++++++++++++++++++++---------
>  drivers/mtd/jedec_flash.c |   19 +++++++++++++++++
>  2 files changed, 57 insertions(+), 10 deletions(-)

Merged, 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: wd at denx.de
"'Tis true, 'tis pity, and pity 'tis 'tis true."
    - Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_



From wd at denx.de  Tue Apr  8 00:01:25 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 00:01:25 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc83xx.git
In-Reply-To: Your message of "Fri, 28 Mar 2008 19:04:20 EST."
	<20080328190420.509c7d43.kim.phillips@freescale.com>
Message-ID: <20080407220125.CE653242FB@gemini.denx.de>

In message <20080328190420.509c7d43.kim.phillips at freescale.com> you wrote:
> On Fri, 28 Mar 2008 18:49:59 -0500
> Kim Phillips <kim.phillips at freescale.com> wrote:
> 
> > Wolfgang D.,
> > 
> > please pull SATA configuration patches for 8315 and 837x boards, a
> > cleanup of the 83xx SPRIDR code, and some 8323 rdb fixes:
> > 
> ok, I've pushed Joakim's relocation fixes patch.  New summary looks
> like:
> 
> Dave Liu (2):
>       mpc83xx: initialize serdes for MPC837xEMDS boards
>       mpc83xx: enable the SATA interface on mpc837xemds board
> 
> Joakim Tjernlund (1):
>       Make MPC83xx one step closer to full relocation.
> 
> Kim Phillips (4):
>       mpc83xx: enable the SATA interface on mpc8315 rdb and mpc837x rdb boards
>       mpc83xx: unreinvent mem_clk
>       mpc83xx: display ddr frequency in board_add_ram_info banner
>       mpc83xx: cleanup System Part and Revision ID Register (SPRIDR) code
> 
> Michael Barkowski (2):
>       mpc8323erdb: define CONFIG_PCI_SKIP_HOST_BRIDGE
>       mpc8323erdb: fix EEPROM page size and get MAC from EEPROM

Applied, thanks.

The merge caused a conflict in lib_ppc/board.c - please check if
everything looks OK for you. 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: wd at denx.de
Human beings were created by water to transport it uphill.



From wd at denx.de  Tue Apr  8 00:05:24 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 00:05:24 +0200
Subject: [U-Boot-Users] [GIT PULL][SH] Please pull
	git://www.denx.de/git/u-boot-sh.git/
In-Reply-To: Your message of "Sun, 30 Mar 2008 10:32:37 +0900."
	<20080330103237.2ba75346.iwamatsu@nigauri.org>
Message-ID: <20080407220524.05758242FB@gemini.denx.de>

In message <20080330103237.2ba75346.iwamatsu at nigauri.org> you wrote:
> 
> Please pull git://www.denx.de/git/u-boot-sh.git/.
> 
> The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
>   Bartlomiej Sieka (1):
>         Fix host tool build breakage, take two
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-sh master
> 
> Mark Jonas (2):
>       sh: Added support for SH7720 based board MPR2.
>       sh: Removed warning when compiling drivers/serial/serial_sh.c.
> 
> Nobuhiro Iwamatsu (9):
>       sh: Fix receive FIFO level register of SH4A
>       sh: Add support SuperH SH7751/SH7751R
>       sh: Move SuperH PCI driver from cpu/sh4 to drivers/pci
>       sh: Add support PCI host driver for SH7751/SH7751R
>       sh: Add support SH4 cache control
>       sh: Add support Renesas Solutions R2D plus board
>       sh: Add maintainer of R7780MP to MAINTAINER file
>       sh: Remove disable_ctrlc function from R7780MP
>       sh: Add support stat structure and stat.h
> 
> Yusuke Goda (3):
>       sh: Add support SH7780
>       sh: Add support PCI of SuperH and SH7780
>       sh: Add support Renesas Solutions R7780MP
> 
> goda.yusuke (1):
>       sh: Add support Renesas Solutions Migo-R board

Merged, 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: wd at denx.de
What is mind?  No matter.  What is matter?  Never mind.
                                      -- Thomas Hewitt Key, 1799-1875



From wd at denx.de  Tue Apr  8 00:06:29 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 00:06:29 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: Your message of "Sun, 30 Mar 2008 12:04:34 BST."
	<000801c89255$d637b670$3a4d010a@Emea.Arm.com>
Message-ID: <20080407220629.C867B242FB@gemini.denx.de>

In message <000801c89255$d637b670$3a4d010a at Emea.Arm.com> you wrote:
> Wolfgang
> 	Please pull from git://www.denx.de/git/u-boot-arm.git master.
> 
> These are the patches:
> 
> [PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and cleanup
> [PATCH] DM644x: This patch removes all boardspecific code from the arch part
> for DM644x (DaVinci) boards
> [PATCH] DM644x: (2nd try) This adds support fortheProdrivePMDRA board, based
> on a DM6441
> [PATCH 0/7] Respin of Sascha Hauer's i.MX31support plus MX31ADS
> 
> AFAIK there are no outstanding patches for
> git://www.denx.de/git/u-boot-arm.git
> for this merge window.
> 
> I have dropped
> [PATCH] ixp: Support for NSLU2 	 
> [PATCH] Altera Stratix II support
> as per previous mails

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: wd at denx.de
Q:  How many DEC repairman does it take to fix a flat ?
A:  Five; four to hold the car up and one to swap tires.



From wd at denx.de  Tue Apr  8 00:09:31 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 00:09:31 +0200
Subject: [U-Boot-Users] Pull request u-boot-blackfin.git
In-Reply-To: Your message of "Sun, 30 Mar 2008 15:54:25 EDT."
	<1206906865-30191-1-git-send-email-vapier@gentoo.org>
Message-ID: <20080407220931.8031A242FB@gemini.denx.de>

In message <1206906865-30191-1-git-send-email-vapier at gentoo.org> you wrote:
> The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
>   Bartlomiej Sieka (1):
>         Fix host tool build breakage, take two
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-blackfin.git master
> 
> Mike Frysinger (4):
>       Blackfin: BF537-stamp: cleanup spi flash driver
>       Blackfin: unify cpu and boot modes
>       Blackfin: cleanup lib_blackfin/cache.c
>       Blackfin: cleanup and overhaul common board init functions

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: wd at denx.de
I think there's a world market for about five computers.
         -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943



From wd at denx.de  Tue Apr  8 00:11:08 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 00:11:08 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull coldfire tree
In-Reply-To: Your message of "Mon, 31 Mar 2008 15:18:17 MDT."
	<47F15519.8030401@freescale.com>
Message-ID: <20080407221108.9FCA5242FB@gemini.denx.de>

In message <47F15519.8030401 at freescale.com> you wrote:
> Wolfgang,
> 
> The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
>   Bartlomiej Sieka (1):
>         Fix host tool build breakage, take two
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-coldfire.git master
> 
> Matthew Fettke (2):
>       ColdFire: Added MCF5275 cpu support.
>       ColdFire: Added M5275EVB support.
> 
> TsiChung Liew (6):
>       ColdFire: Update correct FLASHBAR and RAMBAR1 for MCF5282
>       ColdFire: Fix second memory Chipselect for M5475EVB
>       ColdFire: Define bootdelay in configuration file for M52277EVB
>       ColdFire: Remove R5200 board
>       ColdFire: Add dspi and serial flash support for MCF5445x
>       ColdFire: Fix alignment issue after CONFIG_IDENT_STRING in start.S

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: wd at denx.de
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.



From wd at denx.de  Tue Apr  8 00:13:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 00:13:01 +0200
Subject: [U-Boot-Users] Pull request - net
In-Reply-To: Your message of "Mon, 31 Mar 2008 23:27:38 EDT."
	<47F1ABAA.4050404@gmail.com>
Message-ID: <20080407221301.15C99242FB@gemini.denx.de>

In message <47F1ABAA.4050404 at gmail.com> you wrote:
> Wolfgang,
> 
> The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
>   Bartlomiej Sieka (1):
>         Fix host tool build breakage, take two
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-net.git master
> 
> Andre Schwarz (1):
>       new PHY @ e1000 - 2nd try
> 
> Aras Vaichas (1):
>       DHCP request fix for Windows Server 2003
> 
> Ben Warren (1):
>       Fix macro typo in common/cmd_mii.c
> 
> Daniel Hellstrom (2):
>       SPARC/LEON3: Added GRETH Ethernet 10/100/1000 driver.
>       SPARC: added SMC91111 driver in and out macros for LEON processors.
> 
> Tor Krill (1):
>       Add Vitesse 8601 support to TSEC driver
> 
> Tsi-Chung Liew (2):
>       ColdFire: Fix FEC transmit issue for MCF5275
>       Add CONFIG_MII_INIT in cmd_mii.c

Applied, thanks.



From wd at denx.de  Tue Apr  8 00:20:22 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 00:20:22 +0200
Subject: [U-Boot-Users] AT91 pull request
In-Reply-To: Your message of "Tue, 01 Apr 2008 07:51:45 +0200."
	<20080401055145.GD11802@game.jcrosoft.org>
Message-ID: <20080407222022.2B877242FB@gemini.denx.de>

In message <20080401055145.GD11802 at game.jcrosoft.org> you wrote:
> Please pull u-boot-at91
> 
> The following changes since commit 74d1e66d22dac91388bc538b2fe19f735edc5b82:
>   Bartlomiej Sieka (1):
>         Fix host tool build breakage, take two
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-at91.git master
> 
> David Brownell (2):
>       add missing ARM boards to MAKEALL
>       use correct at91rm9200 register name
> 
> Jean-Christophe PLAGNIOL-VILLARD (5):
>       use correct at91rm9200 register name in m501sk board
>       AT91CAP9ADK: Move CONFIG_CMD_NAND to Makefile
>       AT91SAM9: Move CONFIG_HAS_DATAFLASH to Makefile
>       AT91SAM9260EK: Move CONFIG_CMD_NAND to Makefile
>       dataflash: Move CONFIG_HAS_DATAFLASH to Makefile
> 
> Stelian Pop (9):
>       Fix CFG_NO_FLASH compilation.
>       Cleanup DataFlash partition handling
>       Use timer_init() instead of board supplied interrupt_init()
>       Move at91cap9 specific files to at91sam9 directory
>       Import several header files from Linux
>       Finish header files reworking
>       Port AT91CAP9 to the new headers
>       Add support for AT91SAM9260EK
>       Add maintainership information for AT91CAP9ADK and AT91SAM9260EK boards

Thanks. Applied.

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: wd at denx.de
The last thing one knows in constructing a work is what to put first.
- Blaise Pascal



From wd at denx.de  Tue Apr  8 00:21:56 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 00:21:56 +0200
Subject: [U-Boot-Users] Pull request u-boot-fdt.git / FDT bugfix patches
In-Reply-To: Your message of "Wed, 02 Apr 2008 11:28:26 EDT."
	<47F3A61A.9070003@gmail.com>
Message-ID: <20080407222156.E6DB124842@gemini.denx.de>

In message <47F3A61A.9070003 at gmail.com> you wrote:
> Jerry Van Baren wrote:
> > Dear Wolfgang,
> > 
> > On the FDT front, we have <del>two</del>THREE outstanding bugfix patches:
> 
> I confirmed my error, the <nnnn> notation is indeed 32 bit cells per the 
> DTC documentation (and his other changes are valuable improvements).  As 
> a result, I've added Andy's patch to my queued-to-pull list.
> 
> Thanks,
> gvb
> 
> The following changes since commit 3596d55eb22703d3f4f1b839fe4b000fabe081b3:
>    Gerald Van Baren (1):
>          Merge git://www.denx.de/git/u-boot into uboot
> 
> are available in the git repository at:
> 
>    git://git.denx.de/u-boot-fdt.git master
> 
> Andy Fleming (1):
>        Fix fdt set command to conform to dts spec
> 
> Jean-Christophe PLAGNIOL-VILLARD (1):
>        MPC8xx: Fix libfdt support introduced in commit 77ff7b74
> 
> Kim Phillips (1):
>        remove remaining CONFIG_OF_HAS_{UBOOT_ENV,BD_T} code

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: wd at denx.de
Eeeek!
'eval' on strings should have been named 'evil'.    -- Tom Phoenix in
        <Pine.GSO.3.96.980526121813.27437N-100000 at user2.teleport.com>



From Bien-abristle at KBCOM.COM  Tue Apr  8 01:00:27 2008
From: Bien-abristle at KBCOM.COM (walker)
Date: Tue, 8 Apr 2008 01:00:27 +0200
Subject: [U-Boot-Users] Sleeping is great.
Message-ID: <A0267DA1.A%Bien-abristle@KBCOM.COM>

Loved to see you. You look so much better. I know you have been taking PROZAC lately. http://www.ryebopbro.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080408/ec9d4297/attachment.htm 

From david at gibson.dropbear.id.au  Tue Apr  8 06:32:16 2008
From: david at gibson.dropbear.id.au (David Gibson)
Date: Tue, 8 Apr 2008 14:32:16 +1000
Subject: [U-Boot-Users] FIS DTC
In-Reply-To: <5311.8289-4040-1400377102-1207415994@seznam.cz>
References: <5311.8289-4040-1400377102-1207415994@seznam.cz>
Message-ID: <20080408043216.GD18501@localhost.localdomain>

On Sat, Apr 05, 2008 at 07:19:54PM +0200, Michal Simek wrote:
> Hi Jon, David and others,
> 
> I am working on FIS for Microblaze CPU. I would like to use it. I have one problem.
> 
> I download latest DTC version from Jon git server.
> 
> Version: DTC 1.1.0-g1577696b
> 
> I tryied to convert DTS to DTB for Microblaze CPU. (DTS is below)
> #dtc -f -O dtb -b 0 -V 16 system.dts 
> DTC: dts->dtb  on file "system.dts"
> system.dts:27 syntax error
> FATAL ERROR: Couldn't read input tree
> 
> I got this error - I don't understand what is wrong. Older DTC version has no problem with it.
> This part is no problem - I can use older version of DTC(Version: DTC 1.1.0-g2512a7eb-dirty
> ).
> 
> The second things is around mkimage utility. I want to generate ITB file from ITS description.
> Latest DTC compiler has problem with it too. 
> 
> Can you tell me which version are you using?
> I tryied to complile ITS to ITB with older DTC version and this version don't know about data label in kernel specification.
> I had no problem to add (for FDT + kernel version) DTB file but kernel file is not loaded.
> Is label data = "/incbin/("./linux.bin")"; OK? linux bin is in the same dirctore where is microblaze.its file.

The /incbin/ is probably the problem.  Support for binary includes has
been suggested, and patches have floated around, but it hasn't yet
been merged into dtc mainline.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson



From Monstr at seznam.cz  Tue Apr  8 07:37:35 2008
From: Monstr at seznam.cz (=?us-ascii?Q?Michal=20Simek?=)
Date: Tue, 08 Apr 2008 07:37:35 +0200 (CEST)
Subject: [U-Boot-Users] FIS DTC
In-Reply-To: <20080408043216.GD18501@localhost.localdomain>
Message-ID: <5342.8362-30247-262363595-1207633054@seznam.cz>

Hi David,

>The /incbin/ is probably the problem.  Support for binary includes has
>been suggested, and patches have floated around, but it hasn't yet
>been merged into dtc mainline.

:-( Do you have any floated version?

Thanks,
Michal Simek
www.monstr.eu

>David Gibson			| I'll have my music baroque, and my code
>david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
>				| _way_ _around_!
>http://www.ozlabs.org/~dgibson







From 278893452 at qq.com  Tue Apr  8 08:49:48 2008
From: 278893452 at qq.com (=?ISO-8859-1?B?Mjc4ODkzNDUy?=)
Date: Tue, 8 Apr 2008 14:49:48 +0800
Subject: [U-Boot-Users] u-boot mpc5xx start.s questions
Message-ID: <tencent_6007AB3B2791A3AE7EAD19B3@qq.com>

dear sir or madam,
       When I study the u-boot about mpc5xx, I confuse the definition in cpu/mpc5xx/start.s as follows: 
 /*
 * Set up GOT: Global Offset Table
 *
 * Use r14 to access the GOT 
 */
 START_GOT
 GOT_ENTRY(_GOT2_TABLE_)
 GOT_ENTRY(_FIXUP_TABLE_)
  GOT_ENTRY(_start)
 GOT_ENTRY(_start_of_vectors)
 GOT_ENTRY(_end_of_vectors)
 GOT_ENTRY(transfer_to_handler)
  GOT_ENTRY(__init_end)
 GOT_ENTRY(_end)
 GOT_ENTRY(__bss_start)
 END_GOT
       Will you please kind enough to explain what happens here to me? 
       Thank you!
  
 jjbear
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080408/1a4be667/attachment.htm 

From sr at denx.de  Tue Apr  8 08:54:32 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 8 Apr 2008 08:54:32 +0200
Subject: [U-Boot-Users] U-boot Bus Fault Error while accessing NOR flash
In-Reply-To: <e9eeaac20802201210w1e939862n2fd4f9b5a609c574@mail.gmail.com>
References: <e9eeaac20802150922o7b8e37e3kdc3f508fd5b067b0@mail.gmail.com>
	<200802192050.20493.sr@denx.de>
	<e9eeaac20802201210w1e939862n2fd4f9b5a609c574@mail.gmail.com>
Message-ID: <200804080854.32905.sr@denx.de>

Hi Nikhil,

On Wednesday 20 February 2008, Nikhil Gautam wrote:
> Below is the most of my init.S file. You are correct about the
> faulting location. But I can see in the init.S file that this address
> location is defined as "AC_R|AC_W|AC_X|SA_G" so I think I should be
> able to at least read it. When I boot from 256Mb NAND flash, I don't
> see this problem. Its only when I boot from 1Gb NAND flash.

Did you get this problem fixed on your board? If yes, what was it?

I'm asking because I'm currently adding 2k page size NAND device support to 
nand_spl and I'm seeing some strange exception on my target after running 
from SDRAM.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From shinya.kuribayashi at necel.com  Tue Apr  8 09:20:35 2008
From: shinya.kuribayashi at necel.com (Shinya Kuribayashi)
Date: Tue, 08 Apr 2008 16:20:35 +0900
Subject: [U-Boot-Users] [MIPS] cpu/mips/cpu.c: Fix flush_cache bug
Message-ID: <47FB1CC3.2090904@necel.com>

Cache operations have to take line address (addr), not start_addr.
I noticed this bug when debugging ping failure.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi at necel.com>
---

 cpu/mips/cpu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/cpu/mips/cpu.c b/cpu/mips/cpu.c
index 8b43d8e..e267bba 100644
--- a/cpu/mips/cpu.c
+++ b/cpu/mips/cpu.c
@@ -56,8 +56,8 @@ void flush_cache(ulong start_addr, ulong size)
 	unsigned long aend = (start_addr + size - 1) & ~(lsize - 1);
 
 	while (1) {
-		cache_op(Hit_Writeback_Inv_D, start_addr);
-		cache_op(Hit_Invalidate_I, start_addr);
+		cache_op(Hit_Writeback_Inv_D, addr);
+		cache_op(Hit_Invalidate_I, addr);
 		if (addr == aend)
 			break;
 		addr += lsize;



From pierre.savary at kerlink.fr  Tue Apr  8 09:41:48 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Tue, 8 Apr 2008 09:41:48 +0200
Subject: [U-Boot-Users] detect MMC 4GB
Message-ID: <000001c8994c$01fad880$05f08980$@savary@kerlink.fr>

Hi,
I use a MMCplus 4GB on my design (with at91sam9260). It's wired with 4 bits.
Currently U-boot can't detect correctly the MMC and so I can't read my Linux
kernel Image on the ext3 part on this MMC.
Somebody have already use it? Or somebody have already implemented the
ext_csd and high capacity with MMC on another platform?
Thanks in advance to help me.

Regards,

Pierre




From sander at vermin.nl  Tue Apr  8 09:58:19 2008
From: sander at vermin.nl (Sander Vermin)
Date: Tue, 08 Apr 2008 09:58:19 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <47FA8A34.8080603@free.fr>
References: <47FA1E97.50706@vermin.nl>
	<1207576185.6290.4.camel@galileo>	<47FA2C30.7050609@vermin.nl>
	<1207598435.5709.14.camel@galileo>	<47FA82C3.70002@free.fr>
	<1207601357.5709.25.camel@galileo> <47FA8A34.8080603@free.fr>
Message-ID: <47FB259B.8040703@vermin.nl>

Eric BENARD schreef:
> Stelian Pop a ?crit :
>> Hmm, if I sed:
>>     s/KS8721/DM9161/g
>> and
>>     s/ks8721/dm9161/g
>>
>> on your files I find almost no change with regard to the original
>> version, except:
>>
>> #define PHY_ADDRESS (1<<5)
>>
>> and a #if 0 commenting out a bit of the initialisation sequence...
>>
> yes, goal was to make a clean driver starting from dm9161 with 
> PHY_ADDRESS in the config file ... but I didn't had time to progress 
> on it :-(
> Isolate problem can happen depending on the pullup/down configuration 
> I think (I didn't check in tthe datasheet, but I once met the problem).
>
>> This makes me think it may only be a PHY_ADDRESS issue: what happens if
>> you change in cpu/arm926ejs/at91sam9/ether.c :
>>
>> macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
>>
>> to
>>
>> macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);
>>
> It's not running on a 9260 so I can't test but it should work (and 
> this may be the problem Sander have).
>
> Eric
I did a new build with:

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);

in stead of:

macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);

But still no PHY detected :-(

The files that Eric send were for a AT91RM9200? and don't work on my 
AT91SAM9260?

Sander






From sr at denx.de  Tue Apr  8 10:21:27 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 8 Apr 2008 10:21:27 +0200
Subject: [U-Boot-Users] U-boot Bus Fault Error while accessing NOR flash
In-Reply-To: <200804080854.32905.sr@denx.de>
References: <e9eeaac20802150922o7b8e37e3kdc3f508fd5b067b0@mail.gmail.com>
	<e9eeaac20802201210w1e939862n2fd4f9b5a609c574@mail.gmail.com>
	<200804080854.32905.sr@denx.de>
Message-ID: <200804081021.27955.sr@denx.de>

On Tuesday 08 April 2008, Stefan Roese wrote:
> > Below is the most of my init.S file. You are correct about the
> > faulting location. But I can see in the init.S file that this address
> > location is defined as "AC_R|AC_W|AC_X|SA_G" so I think I should be
> > able to at least read it. When I boot from 256Mb NAND flash, I don't
> > see this problem. Its only when I boot from 1Gb NAND flash.
>
> Did you get this problem fixed on your board? If yes, what was it?
>
> I'm asking because I'm currently adding 2k page size NAND device support to
> nand_spl and I'm seeing some strange exception on my target after running
> from SDRAM.

Never mind. I found my problem. One size was set incorrectly. Now I can boot 
successfully from 2k page size NAND devices. Patch for review will follow 
soon.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr  8 10:31:00 2008
From: sr at denx.de (Stefan Roese)
Date: Tue,  8 Apr 2008 10:31:00 +0200
Subject: [U-Boot-Users] [PATCH] nand_spl: Update nand_spl to support 2k page
	size NAND devices
Message-ID: <1207643460-22199-1-git-send-email-sr@denx.de>

This patch adds support for booting from 2k page sized NAND device
(e.g. Micron 29F2G08AAC).

Tested on AMCC Canyonlands.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 nand_spl/nand_boot.c |   64 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 63 insertions(+), 1 deletions(-)

diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index e2147cb..bc57725 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -1,5 +1,5 @@
 /*
- * (C) Copyright 2006-2007
+ * (C) Copyright 2006-2008
  * Stefan Roese, DENX Software Engineering, sr at denx.de.
  *
  * This program is free software; you can redistribute it and/or
@@ -28,6 +28,10 @@ static int nand_ecc_pos[] = CFG_NAND_ECCPOS;
 
 extern void board_nand_init(struct nand_chip *nand);
 
+#if (CFG_NAND_PAGE_SIZE <= 512)
+/*
+ * NAND command for small page NAND devices (512)
+ */
 static int nand_command(struct mtd_info *mtd, int block, int page, int offs, u8 cmd)
 {
 	struct nand_chip *this = mtd->priv;
@@ -65,6 +69,64 @@ static int nand_command(struct mtd_info *mtd, int block, int page, int offs, u8
 
 	return 0;
 }
+#else
+/*
+ * NAND command for large page NAND devices (2k)
+ */
+static int nand_command(struct mtd_info *mtd, int block, int page, int offs, u8 cmd)
+{
+	struct nand_chip *this = mtd->priv;
+	int page_offs = offs;
+	int page_addr = page + block * CFG_NAND_PAGE_COUNT;
+
+	if (this->dev_ready)
+		this->dev_ready(mtd);
+	else
+		CFG_NAND_READ_DELAY;
+
+	/* Emulate NAND_CMD_READOOB */
+	if (cmd == NAND_CMD_READOOB) {
+		page_offs += CFG_NAND_PAGE_SIZE;
+		cmd = NAND_CMD_READ0;
+	}
+
+	/* Begin command latch cycle */
+	this->hwcontrol(mtd, NAND_CTL_SETCLE);
+	this->write_byte(mtd, cmd);
+	/* Set ALE and clear CLE to start address cycle */
+	this->hwcontrol(mtd, NAND_CTL_CLRCLE);
+	this->hwcontrol(mtd, NAND_CTL_SETALE);
+	/* Column address */
+	this->write_byte(mtd, page_offs & 0xff);			/* A[7:0] */
+	this->write_byte(mtd, (uchar)((page_offs >> 8) & 0xff));	/* A[11:9] */
+	/* Row address */
+	this->write_byte(mtd, (uchar)(page_addr & 0xff));		/* A[19:12] */
+	this->write_byte(mtd, (uchar)((page_addr >> 8) & 0xff));	/* A[27:20] */
+#ifdef CFG_NAND_5_ADDR_CYCLE
+	/* One more address cycle for devices > 128MiB */
+	this->write_byte(mtd, (uchar)((page_addr >> 16) & 0x0f));	/* A[xx:28] */
+#endif
+	/* Latch in address */
+	this->hwcontrol(mtd, NAND_CTL_CLRALE);
+
+	/* Begin command latch cycle */
+	this->hwcontrol(mtd, NAND_CTL_SETCLE);
+	/* Write out the start read command */
+	this->write_byte(mtd, NAND_CMD_READSTART);
+	/* End command latch cycle */
+	this->hwcontrol(mtd, NAND_CTL_CLRCLE);
+
+	/*
+	 * Wait a while for the data to be ready
+	 */
+	if (this->dev_ready)
+		this->dev_ready(mtd);
+	else
+		CFG_NAND_READ_DELAY;
+
+	return 0;
+}
+#endif
 
 static int nand_is_bad_block(struct mtd_info *mtd, int block)
 {
-- 
1.5.4.5




From sr at denx.de  Tue Apr  8 10:33:29 2008
From: sr at denx.de (Stefan Roese)
Date: Tue,  8 Apr 2008 10:33:29 +0200
Subject: [U-Boot-Users] [PATCH 3/3] ppc4xx: Change Canyonlands to support
	booting from 2k page NAND devices
In-Reply-To: <1207643609-22495-1-git-send-email-sr@denx.de>
References: <1207643609-22495-1-git-send-email-sr@denx.de>
Message-ID: <1207643609-22495-3-git-send-email-sr@denx.de>

Signed-off-by: Stefan Roese <sr at denx.de>
---
 board/amcc/canyonlands/bootstrap.c        |   13 +++++++++++++
 board/amcc/canyonlands/init.S             |    1 +
 board/amcc/canyonlands/u-boot-nand.lds    |    4 ++--
 include/configs/canyonlands.h             |   26 ++++++++++++++++----------
 nand_spl/board/amcc/canyonlands/config.mk |    6 +++---
 5 files changed, 35 insertions(+), 15 deletions(-)

diff --git a/board/amcc/canyonlands/bootstrap.c b/board/amcc/canyonlands/bootstrap.c
index 37fa1c9..1d125b6 100644
--- a/board/amcc/canyonlands/bootstrap.c
+++ b/board/amcc/canyonlands/bootstrap.c
@@ -63,9 +63,22 @@ static u8 boot_configs[][17] = {
 /*
  * Bytes 5,6,8,9,11 change for NAND boot
  */
+#if 0
+/*
+ * Values for 512 page size NAND chips, not used anymore, just
+ * keep them here for reference
+ */
 static u8 nand_boot[] = {
 	0x90, 0x01,  0xa0, 0x68, 0x58
 };
+#else
+/*
+ * Values for 2k page size NAND chips
+ */
+static u8 nand_boot[] = {
+	0x90, 0x01,  0xa0, 0xe8, 0x58
+};
+#endif
 
 static int do_bootstrap(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
diff --git a/board/amcc/canyonlands/init.S b/board/amcc/canyonlands/init.S
index bd4cab5..258fb5d 100644
--- a/board/amcc/canyonlands/init.S
+++ b/board/amcc/canyonlands/init.S
@@ -51,6 +51,7 @@ tlbtab:
 #else
 	tlbentry(CFG_NAND_BOOT_SPL_SRC, SZ_4K, CFG_NAND_BOOT_SPL_SRC, 4, AC_R|AC_W|AC_X|SA_G)
 	tlbentry(CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0, AC_R|AC_W|AC_X|SA_G|SA_I)
+	tlbentry(256 << 20, SZ_256M, 256 << 20, 0, AC_R|AC_W|AC_X|SA_G|SA_I)
 #endif
 
 	/*
diff --git a/board/amcc/canyonlands/u-boot-nand.lds b/board/amcc/canyonlands/u-boot-nand.lds
index 12a5dcf..b07a828 100644
--- a/board/amcc/canyonlands/u-boot-nand.lds
+++ b/board/amcc/canyonlands/u-boot-nand.lds
@@ -57,10 +57,10 @@ SECTIONS
     cpu/ppc4xx/start.o	(.text)
 
     /* Align to next NAND block */
-    . = ALIGN(0x4000);
+    . = ALIGN(0x20000);
     common/environment.o  (.ppcenv)
     /* Keep some space here for redundant env and potential bad env blocks */
-    . = ALIGN(0x10000);
+    . = ALIGN(0x80000);
 
     *(.text)
     *(.fixup)
diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
index a1c6674..acb9569 100644
--- a/include/configs/canyonlands.h
+++ b/include/configs/canyonlands.h
@@ -141,6 +141,9 @@
  * On 440EPx the SPL is copied to SDRAM before the NAND controller is
  * set up. While still running from cache, I experienced problems accessing
  * the NAND controller.	sr - 2006-08-25
+ *
+ * This is the first official implementation of booting from 2k page sized
+ * NAND devices (e.g. Micron 29F2G08AA 256Mbit * 8)
  */
 #define CFG_NAND_BOOT_SPL_SRC	0xfffff000	/* SPL location		      */
 #define CFG_NAND_BOOT_SPL_SIZE	(4 << 10)	/* SPL size		      */
@@ -153,24 +156,27 @@
 /*
  * Define the partitioning of the NAND chip (only RAM U-Boot is needed here)
  */
-#define CFG_NAND_U_BOOT_OFFS	(16 << 10)	/* Offset to RAM U-Boot image */
-#define CFG_NAND_U_BOOT_SIZE	(384 << 10)	/* Size of RAM U-Boot image   */
+#define CFG_NAND_U_BOOT_OFFS	(128 << 10)	/* Offset to RAM U-Boot image */
+#define CFG_NAND_U_BOOT_SIZE	(1 << 20)	/* Size of RAM U-Boot image   */
 
 /*
  * Now the NAND chip has to be defined (no autodetection used!)
  */
-#define CFG_NAND_PAGE_SIZE	512		/* NAND chip page size	      */
-#define CFG_NAND_BLOCK_SIZE	(16 << 10)	/* NAND chip block size	      */
-#define CFG_NAND_PAGE_COUNT	32		/* NAND chip page count	      */
-#define CFG_NAND_BAD_BLOCK_POS	5	      /* Location of bad block marker */
-#undef CFG_NAND_4_ADDR_CYCLE		      /* No fourth addr used (<=32MB) */
+#define CFG_NAND_PAGE_SIZE	(2 << 10)	/* NAND chip page size	      */
+#define CFG_NAND_BLOCK_SIZE	(128 << 10)	/* NAND chip block size	      */
+#define CFG_NAND_PAGE_COUNT	(CFG_NAND_BLOCK_SIZE / CFG_NAND_PAGE_SIZE)
+						/* NAND chip page count	      */
+#define CFG_NAND_BAD_BLOCK_POS	0		/* Location of bad block marker*/
+#define CFG_NAND_5_ADDR_CYCLE			/* Fifth addr used (<=128MB)  */
 
 #define CFG_NAND_ECCSIZE	256
 #define CFG_NAND_ECCBYTES	3
 #define CFG_NAND_ECCSTEPS	(CFG_NAND_PAGE_SIZE / CFG_NAND_ECCSIZE)
-#define CFG_NAND_OOBSIZE	16
+#define CFG_NAND_OOBSIZE	64
 #define CFG_NAND_ECCTOTAL	(CFG_NAND_ECCBYTES * CFG_NAND_ECCSTEPS)
-#define CFG_NAND_ECCPOS		{0, 1, 2, 3, 6, 7}
+#define CFG_NAND_ECCPOS		{40, 41, 42, 43, 44, 45, 46, 47, \
+				 48, 49, 50, 51, 52, 53, 54, 55, \
+				 56, 57, 58, 59, 60, 61, 62, 63}
 
 #ifdef CFG_ENV_IS_IN_NAND
 /*
@@ -231,7 +237,7 @@
 #define CONFIG_DDR_ECC		1	/* with ECC support		*/
 #define CONFIG_DDR_RQDC_FIXED	0x80000038 /* fixed value for RQDC	*/
 #endif
-#define CFG_MBYTES_SDRAM        256	/* 256MB			*/
+#define CFG_MBYTES_SDRAM	512	/* 512MB			*/
 
 /*-----------------------------------------------------------------------
  * I2C
diff --git a/nand_spl/board/amcc/canyonlands/config.mk b/nand_spl/board/amcc/canyonlands/config.mk
index 6dad876..c8d7c23 100644
--- a/nand_spl/board/amcc/canyonlands/config.mk
+++ b/nand_spl/board/amcc/canyonlands/config.mk
@@ -34,9 +34,9 @@
 #
 TEXT_BASE = 0xE3003000
 
-# PAD_TO used to generate a 16kByte binary needed for the combined image
-# -> PAD_TO = TEXT_BASE + 0x4000
-PAD_TO	= 0xE3007000
+# PAD_TO used to generate a 128kByte binary needed for the combined image
+# -> PAD_TO = TEXT_BASE + 0x20000
+PAD_TO	= 0xE3023000
 
 PLATFORM_CPPFLAGS += -DCONFIG_440=1
 
-- 
1.5.4.5




From sr at denx.de  Tue Apr  8 10:33:28 2008
From: sr at denx.de (Stefan Roese)
Date: Tue,  8 Apr 2008 10:33:28 +0200
Subject: [U-Boot-Users] [PATCH 2/3] ppc4xx: Adjust Canyonlands fixed DDR2
	setup (NAND booting) to 512MB SODIMM
In-Reply-To: <1207643609-22495-1-git-send-email-sr@denx.de>
References: <1207643609-22495-1-git-send-email-sr@denx.de>
Message-ID: <1207643609-22495-2-git-send-email-sr@denx.de>

Signed-off-by: Stefan Roese <sr at denx.de>
---
 nand_spl/board/amcc/canyonlands/ddr2_fixed.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/nand_spl/board/amcc/canyonlands/ddr2_fixed.c b/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
index 48708a8..79f3b0f 100644
--- a/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
+++ b/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
@@ -49,11 +49,11 @@ long int initdram(int board_type)
 	 * enabled. This will only work for the same memory
 	 * configuration as used here:
 	 *
-	 * Crucial CT3264AC53E.4FD - 256MB SO-DIMM
+	 * Crucial CT6464AC53E.4FE - 512MB SO-DIMM
 	 *
 	 */
 	mtsdram(SDRAM_MCOPT2, 0x00000000);
-	mtsdram(SDRAM_MCOPT1, 0x05122000);
+	mtsdram(SDRAM_MCOPT1, 0x05322000);
 	mtsdram(SDRAM_MODT0, 0x01000000);
 	mtsdram(SDRAM_CODT, 0x00800021);
 	mtsdram(SDRAM_WRDTR, 0x82000823);
@@ -62,7 +62,7 @@ long int initdram(int board_type)
 	mtsdram(SDRAM_RTR, 0x06180000);
 	mtsdram(SDRAM_SDTR1, 0x80201000);
 	mtsdram(SDRAM_SDTR2, 0x42103243);
-	mtsdram(SDRAM_SDTR3, 0x0A0D0D16);
+	mtsdram(SDRAM_SDTR3, 0x0A0D0D1A);
 	mtsdram(SDRAM_MMODE, 0x00000632);
 	mtsdram(SDRAM_MEMODE, 0x00000040);
 	mtsdram(SDRAM_INITPLR0, 0xB5380000);
@@ -86,7 +86,7 @@ long int initdram(int board_type)
 
 	wait_init_complete();
 
-	mtdcr(SDRAM_R0BAS, 0x0000F800);		/* MQ0_B0BAS */
+	mtdcr(SDRAM_R0BAS, 0x0000F000);		/* MQ0_B0BAS */
 
 	mtsdram(SDRAM_RDCC, 0x40000000);
 	mtsdram(SDRAM_RQDC, 0x80000038);
-- 
1.5.4.5




From sr at denx.de  Tue Apr  8 10:33:27 2008
From: sr at denx.de (Stefan Roese)
Date: Tue,  8 Apr 2008 10:33:27 +0200
Subject: [U-Boot-Users] [PATCH 1/3] ppc4xx: Add Glacier NAND booting target
Message-ID: <1207643609-22495-1-git-send-email-sr@denx.de>

Signed-off-by: Stefan Roese <sr at denx.de>
---
 Makefile |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index a7f886b..28dc51d 100644
--- a/Makefile
+++ b/Makefile
@@ -1180,10 +1180,13 @@ glacier_config:	unconfig
 		tr '[:lower:]' '[:upper:]')" >$(obj)include/config.h
 	@$(MKCONFIG) -n $@ -a canyonlands ppc ppc4xx canyonlands amcc
 
-canyonlands_nand_config:	unconfig
+canyonlands_nand_config \
+glacier_nand_config:	unconfig
 	@mkdir -p $(obj)include $(obj)board/amcc/canyonlands
 	@mkdir -p $(obj)nand_spl/board/amcc/canyonlands
 	@echo "#define CONFIG_NAND_U_BOOT" > $(obj)include/config.h
+	@echo "#define CONFIG_$$(echo $(subst ,,$(@:_nand_config=)) | \
+		tr '[:lower:]' '[:upper:]')" >> $(obj)include/config.h
 	@$(MKCONFIG) -n $@ -a canyonlands ppc ppc4xx canyonlands amcc
 	@echo "TEXT_BASE = 0x01000000" > $(obj)board/amcc/canyonlands/config.tmp
 	@echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk
-- 
1.5.4.5




From ebenard at free.fr  Tue Apr  8 10:36:40 2008
From: ebenard at free.fr (Eric BENARD)
Date: Tue, 08 Apr 2008 10:36:40 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <47FB259B.8040703@vermin.nl>
References: <47FA1E97.50706@vermin.nl>	<1207576185.6290.4.camel@galileo>	<47FA2C30.7050609@vermin.nl>	<1207598435.5709.14.camel@galileo>	<47FA82C3.70002@free.fr>	<1207601357.5709.25.camel@galileo>
	<47FA8A34.8080603@free.fr> <47FB259B.8040703@vermin.nl>
Message-ID: <47FB2E98.2080008@free.fr>

Sander Vermin a ?crit :
> I did a new build with:
> 
> macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);
> 
> in stead of:
> 
> macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
> 
> But still no PHY detected :-(
> 
You need to check your schematic, and the PHY datasheet in order to know 
what could be the address of your PHY (set by pull up/down resistors on 
several pins of the PHY at reset of the PHY).

Or you can try a loop on the PHY address and see if it answers at any 
address ...

Eric



From daniel at gaisler.com  Tue Apr  8 10:43:59 2008
From: daniel at gaisler.com (Daniel Hellstrom)
Date: Tue, 08 Apr 2008 08:43:59 +0000
Subject: [U-Boot-Users] Pull request: u-boot-sparc
Message-ID: <200804080847.m388lTxD027204@mail176c2.megamailservers.com>

Dear Wolfgang,

Please pull from the master branch at git://www.denx.de/git/u-boot-sparc.git

I have rebased it agains the mainline this morning.

Best regards,
Daniel Hellstrom


The following changes since commit aeff6d503b6006573d5c6b04fc658a64bebee5fa:
  Wolfgang Denk (1):
        Merge branch 'master' of git://www.denx.de/git/u-boot-fdt

are available in the git repository at:

  git://www.denx.de/git/u-boot-sparc.git master

Daniel Hellstrom (11):
      SPARC: Added generic support for SPARC architecture.
      SPARC: added SPARC board information to the command bdinfo.
      SPARC: added SPARC support for new uimage in common code.
      SPARC: Added support for SPARC LEON3 SOC processor.
      SPARC/LEON3: Added AMBA Bus Plug&Play information print command 
(ambapp). It can print available cores (type: AHB Master, AHB Slave, APB 
Slave), their address ranges, IRQ number and version.
      SPARC: Added support for SPARC LEON2 SOC Processor.
      SPARC/LEON3: added support for GR-XC3S-1500 board with GRLIB 
template design. See www.gaisler.com for board information.
      SPARC/LEON3: added support for Gaisler GRSIM/TSIM2 SPARC/LEON3 
simulatorn. See www.gaisler.com for information.
      SPARC/LEON3: added support for Altera NIOS Development kit 
(STRATIX II Edition) with GRLIB template design. See www.gaisler.com for 
information.
      SPARC/LEON3: added support for GR-CPCI-AX2000 FPGA AX board. The 
FPGA is exchangeable but a standard LEON3 design is assumed. See 
www.gaisler.com for information.
      SPARC/LEON2: added support for Gaisler simulator GRSIM/TSIM for 
SPARC/LEON2 targets. See www.gaisler.com for information.

 MAKEALL                                       |    7 +
 Makefile                                      |   37 +-
 README                                        |    3 +
 board/gaisler/gr_cpci_ax2000/Makefile         |   52 +
 board/gaisler/gr_cpci_ax2000/config.mk        |   37 +
 board/gaisler/gr_cpci_ax2000/gr_cpci_ax2000.c |   39 +
 board/gaisler/gr_cpci_ax2000/u-boot.lds       |  160 +++
 board/gaisler/gr_ep2s60/Makefile              |   52 +
 board/gaisler/gr_ep2s60/config.mk             |   35 +
 board/gaisler/gr_ep2s60/gr_ep2s60.c           |   39 +
 board/gaisler/gr_ep2s60/u-boot.lds            |  160 +++
 board/gaisler/gr_xc3s_1500/Makefile           |   52 +
 board/gaisler/gr_xc3s_1500/config.mk          |   34 +
 board/gaisler/gr_xc3s_1500/gr_xc3s_1500.c     |   39 +
 board/gaisler/gr_xc3s_1500/u-boot.lds         |  162 +++
 board/gaisler/grsim/Makefile                  |   50 +
 board/gaisler/grsim/config.mk                 |   34 +
 board/gaisler/grsim/grsim.c                   |   43 +
 board/gaisler/grsim/u-boot.lds                |  161 +++
 board/gaisler/grsim_leon2/Makefile            |   50 +
 board/gaisler/grsim_leon2/config.mk           |   34 +
 board/gaisler/grsim_leon2/grsim_leon2.c       |   43 +
 board/gaisler/grsim_leon2/u-boot.lds          |  159 +++
 common/Makefile                               |    1 +
 common/cmd_ambapp.c                           |  278 ++++++
 common/cmd_bdinfo.c                           |   39 +
 common/image.c                                |    2 +-
 cpu/leon2/Makefile                            |   54 +
 cpu/leon2/config.mk                           |   26 +
 cpu/leon2/cpu.c                               |   58 ++
 cpu/leon2/cpu_init.c                          |  142 +++
 cpu/leon2/interrupts.c                        |  217 ++++
 cpu/leon2/prom.c                              | 1047 ++++++++++++++++++++
 cpu/leon2/serial.c                            |  165 ++++
 cpu/leon2/start.S                             |  661 +++++++++++++
 cpu/leon3/Makefile                            |   54 +
 cpu/leon3/ambapp.c                            |  359 +++++++
 cpu/leon3/config.mk                           |   26 +
 cpu/leon3/cpu.c                               |   67 ++
 cpu/leon3/cpu_init.c                          |  254 +++++
 cpu/leon3/interrupts.c                        |  219 ++++
 cpu/leon3/prom.c                              | 1078 ++++++++++++++++++++
 cpu/leon3/serial.c                            |  139 +++
 cpu/leon3/start.S                             |  616 ++++++++++++
 cpu/leon3/usb_uhci.c                          | 1313 
+++++++++++++++++++++++++
 cpu/leon3/usb_uhci.h                          |  184 ++++
 examples/Makefile                             |    3 +
 examples/sparc.lds                            |   61 ++
 examples/stubs.c                              |   16 +
 include/ambapp.h                              |  394 ++++++++
 include/asm-sparc/arch-leon2/asi.h            |   36 +
 include/asm-sparc/arch-leon3/asi.h            |   36 +
 include/asm-sparc/asi.h                       |   32 +
 include/asm-sparc/asmmacro.h                  |   45 +
 include/asm-sparc/atomic.h                    |   29 +
 include/asm-sparc/bitops.h                    |   29 +
 include/asm-sparc/byteorder.h                 |   37 +
 include/asm-sparc/cache.h                     |   31 +
 include/asm-sparc/errno.h                     |  162 +++
 include/asm-sparc/global_data.h               |   85 ++
 include/asm-sparc/io.h                        |   94 ++
 include/asm-sparc/irq.h                       |   49 +
 include/asm-sparc/leon.h                      |   42 +
 include/asm-sparc/leon2.h                     |  236 +++++
 include/asm-sparc/leon3.h                     |   37 +
 include/asm-sparc/machines.h                  |   92 ++
 include/asm-sparc/page.h                      |   43 +
 include/asm-sparc/posix_types.h               |  139 +++
 include/asm-sparc/processor.h                 |  116 +++
 include/asm-sparc/prom.h                      |  297 ++++++
 include/asm-sparc/psr.h                       |   97 ++
 include/asm-sparc/ptrace.h                    |  181 ++++
 include/asm-sparc/srmmu.h                     |  301 ++++++
 include/asm-sparc/stack.h                     |  162 +++
 include/asm-sparc/string.h                    |   55 +
 include/asm-sparc/types.h                     |   71 ++
 include/asm-sparc/u-boot.h                    |   74 ++
 include/asm-sparc/winmacro.h                  |  151 +++
 include/config_cmd_all.h                      |    1 +
 include/configs/gr_cpci_ax2000.h              |  380 +++++++
 include/configs/gr_ep2s60.h                   |  356 +++++++
 include/configs/gr_xc3s_1500.h                |  321 ++++++
 include/configs/grsim.h                       |  340 +++++++
 include/configs/grsim_leon2.h                 |  349 +++++++
 include/image.h                               |    4 +
 lib_sparc/Makefile                            |   45 +
 lib_sparc/board.c                             |  521 ++++++++++
 lib_sparc/bootm.c                             |  226 +++++
 lib_sparc/cache.c                             |   33 +
 lib_sparc/interrupts.c                        |  122 +++
 lib_sparc/time.c                              |   78 ++
 sparc_config.mk                               |   24 +
 92 files changed, 14512 insertions(+), 2 deletions(-)
 create mode 100644 board/gaisler/gr_cpci_ax2000/Makefile
 create mode 100644 board/gaisler/gr_cpci_ax2000/config.mk
 create mode 100644 board/gaisler/gr_cpci_ax2000/gr_cpci_ax2000.c
 create mode 100644 board/gaisler/gr_cpci_ax2000/u-boot.lds
 create mode 100644 board/gaisler/gr_ep2s60/Makefile
 create mode 100644 board/gaisler/gr_ep2s60/config.mk
 create mode 100644 board/gaisler/gr_ep2s60/gr_ep2s60.c
 create mode 100644 board/gaisler/gr_ep2s60/u-boot.lds
 create mode 100644 board/gaisler/gr_xc3s_1500/Makefile
 create mode 100644 board/gaisler/gr_xc3s_1500/config.mk
 create mode 100644 board/gaisler/gr_xc3s_1500/gr_xc3s_1500.c
 create mode 100644 board/gaisler/gr_xc3s_1500/u-boot.lds
 create mode 100644 board/gaisler/grsim/Makefile
 create mode 100644 board/gaisler/grsim/config.mk
 create mode 100644 board/gaisler/grsim/grsim.c
 create mode 100644 board/gaisler/grsim/u-boot.lds
 create mode 100644 board/gaisler/grsim_leon2/Makefile
 create mode 100644 board/gaisler/grsim_leon2/config.mk
 create mode 100644 board/gaisler/grsim_leon2/grsim_leon2.c
 create mode 100644 board/gaisler/grsim_leon2/u-boot.lds
 create mode 100644 common/cmd_ambapp.c
 create mode 100644 cpu/leon2/Makefile
 create mode 100644 cpu/leon2/config.mk
 create mode 100644 cpu/leon2/cpu.c
 create mode 100644 cpu/leon2/cpu_init.c
 create mode 100644 cpu/leon2/interrupts.c
 create mode 100644 cpu/leon2/prom.c
 create mode 100644 cpu/leon2/serial.c
 create mode 100644 cpu/leon2/start.S
 create mode 100644 cpu/leon3/Makefile
 create mode 100644 cpu/leon3/ambapp.c
 create mode 100644 cpu/leon3/config.mk
 create mode 100644 cpu/leon3/cpu.c
 create mode 100644 cpu/leon3/cpu_init.c
 create mode 100644 cpu/leon3/interrupts.c
 create mode 100644 cpu/leon3/prom.c
 create mode 100644 cpu/leon3/serial.c
 create mode 100644 cpu/leon3/start.S
 create mode 100644 cpu/leon3/usb_uhci.c
 create mode 100644 cpu/leon3/usb_uhci.h
 create mode 100644 examples/sparc.lds
 create mode 100644 include/ambapp.h
 create mode 100644 include/asm-sparc/arch-leon2/asi.h
 create mode 100644 include/asm-sparc/arch-leon3/asi.h
 create mode 100644 include/asm-sparc/asi.h
 create mode 100644 include/asm-sparc/asmmacro.h
 create mode 100644 include/asm-sparc/atomic.h
 create mode 100644 include/asm-sparc/bitops.h
 create mode 100644 include/asm-sparc/byteorder.h
 create mode 100644 include/asm-sparc/cache.h
 create mode 100644 include/asm-sparc/errno.h
 create mode 100644 include/asm-sparc/global_data.h
 create mode 100644 include/asm-sparc/io.h
 create mode 100644 include/asm-sparc/irq.h
 create mode 100644 include/asm-sparc/leon.h
 create mode 100644 include/asm-sparc/leon2.h
 create mode 100644 include/asm-sparc/leon3.h
 create mode 100644 include/asm-sparc/machines.h
 create mode 100644 include/asm-sparc/page.h
 create mode 100644 include/asm-sparc/posix_types.h
 create mode 100644 include/asm-sparc/processor.h
 create mode 100644 include/asm-sparc/prom.h
 create mode 100644 include/asm-sparc/psr.h
 create mode 100644 include/asm-sparc/ptrace.h
 create mode 100644 include/asm-sparc/srmmu.h
 create mode 100644 include/asm-sparc/stack.h
 create mode 100644 include/asm-sparc/string.h
 create mode 100644 include/asm-sparc/types.h
 create mode 100644 include/asm-sparc/u-boot.h
 create mode 100644 include/asm-sparc/winmacro.h
 create mode 100644 include/configs/gr_cpci_ax2000.h
 create mode 100644 include/configs/gr_ep2s60.h
 create mode 100644 include/configs/gr_xc3s_1500.h
 create mode 100644 include/configs/grsim.h
 create mode 100644 include/configs/grsim_leon2.h
 create mode 100644 lib_sparc/Makefile
 create mode 100644 lib_sparc/board.c
 create mode 100644 lib_sparc/bootm.c
 create mode 100644 lib_sparc/cache.c
 create mode 100644 lib_sparc/interrupts.c
 create mode 100644 lib_sparc/time.c
 create mode 100644 sparc_config.mk




From sr at denx.de  Tue Apr  8 10:58:31 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 8 Apr 2008 10:58:31 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <014b01c8912e$05069620$0f13c260$@Tjernlund@transmode.se>
References: <1206715285-10532-1-git-send-email-Joakim.Tjernlund@transmode.se>
	<20080328183303.3f513479.kim.phillips@freescale.com>
	<014b01c8912e$05069620$0f13c260$@Tjernlund@transmode.se>
Message-ID: <200804081058.31982.sr@denx.de>

Hi Joakim,

On Saturday 29 March 2008, Joakim Tjernlund wrote:
> > Joakim Tjernlund <Joakim.Tjernlund at transmode.se> wrote:
> > > Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
> > > and use GOT relative reference.
> > > ---
> > >  cpu/mpc83xx/start.S |   11 +++++++----
> > >  lib_ppc/board.c     |    3 ++-
> > >  2 files changed, 9 insertions(+), 5 deletions(-)

<snip>

> > btw, shouldn't it fix up the other ppc start.S files?
>
> The other ppc's won't break and I only got a 83xx, hence I only did
> it for 83xx, hoping it would serve as a guide for the rest.

I'm afraid, but the "other ppc's" did break with this patch. At least 4xx 
does. With your patch applied relocation to SDRAM does not work anymore. 
Here's what I get:

CFG_MONITOR_BASE=fffa0000
(ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
EXC_OFF_SYS_RESET=100

I haven't looked into it closer yet. Any idea on how to fix this? 

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From trimarchi at gandalf.sssup.it  Tue Apr  8 11:09:30 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Tue, 08 Apr 2008 11:09:30 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <47FB2E98.2080008@free.fr>
References: <47FA1E97.50706@vermin.nl>	<1207576185.6290.4.camel@galileo>	<47FA2C30.7050609@vermin.nl>	<1207598435.5709.14.camel@galileo>	<47FA82C3.70002@free.fr>	<1207601357.5709.25.camel@galileo>	<47FA8A34.8080603@free.fr>
	<47FB259B.8040703@vermin.nl> <47FB2E98.2080008@free.fr>
Message-ID: <47FB364A.4040509@gandalf.sssup.it>

Hi,
> Sander Vermin a ?crit :> I did a new build with:> > macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);> > in stead of:> > macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);> > But still no PHY detected :-(> You need to check your schematic, and the PHY datasheet in order to know what could be the address of your PHY (set by pull up/down resistors on several pins of the PHY at reset of the PHY).
> Or you can try a loop on the PHY address and see if it answers at any address ...
>   
Try this code to do the loop test.

#if defined(CONFIG_YOURBOARD)
#define MAX_PHY_ADDR    64
        for (i = 0 ; i < MAX_PHY_ADDR; i++) {
                macb->phy_addr = i;
                phy_id = macb_mdio_read(macb, MII_PHYSID1);
                if (phy_id != 0xffff)
                        break;
        }
        printf("phy_id %x found at %d\n", phy_id, i);
#else
        phy_id = macb_mdio_read(macb, MII_PHYSID1);
#endif

Michael



From sander at vermin.nl  Tue Apr  8 11:09:19 2008
From: sander at vermin.nl (Sander Vermin)
Date: Tue, 08 Apr 2008 11:09:19 +0200
Subject: [U-Boot-Users] AT91SAM9260EK with KS8721 PHY
In-Reply-To: <47FB2E98.2080008@free.fr>
References: <47FA1E97.50706@vermin.nl>	<1207576185.6290.4.camel@galileo>	<47FA2C30.7050609@vermin.nl>	<1207598435.5709.14.camel@galileo>	<47FA82C3.70002@free.fr>	<1207601357.5709.25.camel@galileo>
	<47FA8A34.8080603@free.fr> <47FB259B.8040703@vermin.nl>
	<47FB2E98.2080008@free.fr>
Message-ID: <47FB363F.9050706@vermin.nl>

Eric BENARD schreef:
> Sander Vermin a ?crit :
>> I did a new build with:
>>
>> macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 1<<5);
>>
>> in stead of:
>>
>> macb_eth_initialize(0, (void *)AT91_BASE_EMAC, 0x00);
>>
>> But still no PHY detected :-(
>>
> You need to check your schematic, and the PHY datasheet in order to 
> know what could be the address of your PHY (set by pull up/down 
> resistors on several pins of the PHY at reset of the PHY).
>
> Or you can try a loop on the PHY address and see if it answers at any 
> address ...
>
> Eric
It works!!

The detection of the PHY works, the base address was 0x01 instead of  0x00.

Wen I try to enable RII mode (CONFIG_CMD_MII) I get all kinds of errors 
about variable not being found:

macb.c: In function 'miiphy_read':
macb.c:528: error: 'macb' undeclared (first use in this function)
macb.c:528: error: (Each undeclared identifier is reported only once
macb.c:528: error: for each function it appears in.)
macb.c:528: error: 'MACB_EMACB_NCR' undeclared (first use in this function)
macb.c:539: error: 'MACB_EMACB_MAN' undeclared (first use in this function)
macb.c:542: error: 'MACB_EMACB_NSR' undeclared (first use in this function)
macb.c: In function 'miiphy_write':
macb.c:566: error: 'macb' undeclared (first use in this function)
macb.c:566: error: 'MACB_EMACB_NCR' undeclared (first use in this function)
macb.c:578: error: 'MACB_EMACB_MAN' undeclared (first use in this function)
macb.c:581: error: 'MACB_EMACB_NSR' undeclared (first use in this function)
make[1]: *** [macb.o] Error 1

Looking at the code I see that macb should be a pointer to "struct 
macb_device *macb" how should this code work? I don't see any functions 
point to the miiphy_read an write functions.

Sander




From david.kind at gefanuc.com  Tue Apr  8 11:24:17 2008
From: david.kind at gefanuc.com (Kind, David (GE EntSol, Intelligent Platforms))
Date: Tue, 8 Apr 2008 10:24:17 +0100
Subject: [U-Boot-Users] PA Semi support
Message-ID: <1CADFA951940554D86FBD8B24BBFF3A0E2C6BD@LONMLVEM08.e2k.ad.ge.com>

Dear all,

Is it the intention of U-Boot to support the PA Semi devices and
integrate into the main U-Boot branch at some point?

Regards,

David.



From joakim.tjernlund at transmode.se  Tue Apr  8 11:31:24 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 08 Apr 2008 11:31:24 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <200804081058.31982.sr@denx.de>
References: <1206715285-10532-1-git-send-email-Joakim.Tjernlund@transmode.se>
	<20080328183303.3f513479.kim.phillips@freescale.com>
	<014b01c8912e$05069620$0f13c260$@Tjernlund@transmode.se>
	<200804081058.31982.sr@denx.de>
Message-ID: <1207647084.5826.14.camel@gentoo-jocke.transmode.se>


On Tue, 2008-04-08 at 10:58 +0200, Stefan Roese wrote:
> Hi Joakim,
> 
> On Saturday 29 March 2008, Joakim Tjernlund wrote:
> > > Joakim Tjernlund <Joakim.Tjernlund at transmode.se> wrote:
> > > > Remove a few absolute references to CFG_MONITOR_BASE for ppc/mpc83xx
> > > > and use GOT relative reference.
> > > > ---
> > > >  cpu/mpc83xx/start.S |   11 +++++++----
> > > >  lib_ppc/board.c     |    3 ++-
> > > >  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> <snip>
> 
> > > btw, shouldn't it fix up the other ppc start.S files?
> >
> > The other ppc's won't break and I only got a 83xx, hence I only did
> > it for 83xx, hoping it would serve as a guide for the rest.
> 
> I'm afraid, but the "other ppc's" did break with this patch. At least 4xx 
> does. With your patch applied relocation to SDRAM does not work anymore. 
> Here's what I get:
> 
> CFG_MONITOR_BASE=fffa0000
> (ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
> EXC_OFF_SYS_RESET=100
> 
> I haven't looked into it closer yet. Any idea on how to fix this? 
> 
> Thanks.
> 
> Best regards,
> Stefan

Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
pointing to your real start of execution. Seems like _start_440 is your
real start but I can't be sure. There are some strange code in there
that I don't understand.

 Jocke



From sr at denx.de  Tue Apr  8 12:06:21 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 8 Apr 2008 12:06:21 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <1207647084.5826.14.camel@gentoo-jocke.transmode.se>
References: <1206715285-10532-1-git-send-email-Joakim.Tjernlund@transmode.se>
	<200804081058.31982.sr@denx.de>
	<1207647084.5826.14.camel@gentoo-jocke.transmode.se>
Message-ID: <200804081206.21726.sr@denx.de>

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > I'm afraid, but the "other ppc's" did break with this patch. At least 4xx
> > does. With your patch applied relocation to SDRAM does not work anymore.
> > Here's what I get:
> >
> > CFG_MONITOR_BASE=fffa0000
> > (ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
> > EXC_OFF_SYS_RESET=100
> >
> > I haven't looked into it closer yet. Any idea on how to fix this?
> >
> > Thanks.
> >
> > Best regards,
> > Stefan
>
> Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
> pointing to your real start of execution. Seems like _start_440 is your
> real start but I can't be sure.

No, unfortunately it's not. _start_440 is loaded into the last 4k of bootrom 
(via linker script), since 440 has a shadow TLB upon startup to only map 4k 
of address space. After looking at System.map it seems that _start_of_vectors 
seems to be the way to go for 4xx:

fffa0004 T version_string
fffa0100 t CritcalInput
fffa0100 T _start_of_vectors

But I don't want to introduce some #ifdef here. Perhaps it would be better to 
introduce a common (PPC) label that points to the beginning of the U-Boot 
image here.

BTW: I think this version:

	len = (ulong)&_end - ((ulong)&_start - EXC_OFF_SYS_RESET);

instead of:

	len = (ulong)&_end - (ulong)&_start + EXC_OFF_SYS_RESET;

is better. Makes the transition from CFG_MONITOR_BASE clearer, don't you think 
so?

> There are some strange code in there 
> that I don't understand.

Yes, it's quite complex because it supports all 4xx variants.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From Markus.Haefliger at apcc.com  Tue Apr  8 12:36:55 2008
From: Markus.Haefliger at apcc.com (Markus.Haefliger at apcc.com)
Date: Tue, 8 Apr 2008 12:36:55 +0200
Subject: [U-Boot-Users] MBX860 serial communication fails
Message-ID: <OF1AC5C04B.0DBC9930-ONC1257425.0038E374-C1257425.003A4FCD@apcc.com>

Hi all

I tried to run u-boot-1.1.6 on my old MBX860 board (Version 20C). I tried 
several version but I always get the same behavoir.
No communication on the serial line. Only when I press a key on my 
keyboard I get a strange string back (for example RETURN give the ASCII 
code 170 back "?")

What have I done:

1) build own GNU environment ( I follow for this the guideline from Dan 
Kegel). I did that in  cygwin under Windows XP
2) then download u-boot-1.1.6
3) make CROSS_COMPILE=powerpc-860-linux-gnu- MBX_config --> works fine
4) make CROSS_COMPILE=powerpc-860-linux-gnu- all --> works fine with a few 
warnings
5) I use the EPPC of the MBX to download the u-boot.bin and flash it with 
"pflash 4000:xxxxxxxx fc000000
6) I can check the entries of the flash with md fc000000 and their I see 
some text like "u-boot Version 1.1.6" --> so flash is written
7) Then I set the jumper J4 to 2-3 but then I got this strange behaviour.

I set in include/configs

#define CONFIG_MPC860           1       /* This is a MPC860 CPU         */
#define CONFIG_MBX              1       /* ...on an MBX module          */

#define CONFIG_8xx_CONS_SMC1    1       /* Console is on SMC1           */
#undef  CONFIG_8xx_CONS_SMC2
#undef  CONFIG_8xx_CONS_NONE
#define CONFIG_BAUDRATE         9600
/* Define this to use the PCI bus */
#undef CONFIG_USE_PCI

#define CONFIG_CLOCKS_IN_MHZ    1       /* clocks passsed to Linux in MHz 
*/
#define CONFIG_8xx_GCLK_FREQ    (40000000UL)   /* --> my MBX has only 
40MHz */

Any Idea why I do not see the startup dialogue of the u-boot bootloader ?

best regards

Markus Haefliger


e-mail:markus.haefliger at apcc.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080408/b1218b89/attachment.htm 

From joakim.tjernlund at transmode.se  Tue Apr  8 12:50:33 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 08 Apr 2008 12:50:33 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <200804081206.21726.sr@denx.de>
References: <1206715285-10532-1-git-send-email-Joakim.Tjernlund@transmode.se>
	<200804081058.31982.sr@denx.de>
	<1207647084.5826.14.camel@gentoo-jocke.transmode.se>
	<200804081206.21726.sr@denx.de>
Message-ID: <1207651833.5826.21.camel@gentoo-jocke.transmode.se>


On Tue, 2008-04-08 at 12:06 +0200, Stefan Roese wrote:
> On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > I'm afraid, but the "other ppc's" did break with this patch. At least 4xx
> > > does. With your patch applied relocation to SDRAM does not work anymore.
> > > Here's what I get:
> > >
> > > CFG_MONITOR_BASE=fffa0000
> > > (ulong)&_start + EXC_OFF_SYS_RESET=fffa2200
> > > EXC_OFF_SYS_RESET=100
> > >
> > > I haven't looked into it closer yet. Any idea on how to fix this?
> > >
> > > Thanks.
> > >
> > > Best regards,
> > > Stefan
> >
> > Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
> > pointing to your real start of execution. Seems like _start_440 is your
> > real start but I can't be sure.
> 
> No, unfortunately it's not. _start_440 is loaded into the last 4k of bootrom 
> (via linker script), since 440 has a shadow TLB upon startup to only map 4k 
> of address space. After looking at System.map it seems that _start_of_vectors 
> seems to be the way to go for 4xx:
> 
> fffa0004 T version_string
> fffa0100 t CritcalInput
> fffa0100 T _start_of_vectors
> 
> But I don't want to introduce some #ifdef here. Perhaps it would be better to 
> introduce a common (PPC) label that points to the beginning of the U-Boot 
> image here.

I first did a new symbol for this but changed it to use _start as  I
didn't want to introduce yet another symbol. I would hope it is
possible to rework 4xx to move the _start symbol to were it belongs?
Not having the _start symbol where it should be could bite you some
other day too.

> 
> BTW: I think this version:
> 
> 	len = (ulong)&_end - ((ulong)&_start - EXC_OFF_SYS_RESET);
> 
> instead of:
> 
> 	len = (ulong)&_end - (ulong)&_start + EXC_OFF_SYS_RESET;
> 
> is better. Makes the transition from CFG_MONITOR_BASE clearer, don't you think 
> so?

Sure, but I don't feel that strongly about it.




From sr at denx.de  Tue Apr  8 13:29:50 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 8 Apr 2008 13:29:50 +0200
Subject: [U-Boot-Users] [PATCH] PPC440 Power Management Registers
In-Reply-To: <8B3930FEA8618C44B48EB06B5D33A06E12FD0B@satmail.Advantech.ca>
References: <8B3930FEA8618C44B48EB06B5D33A06E12FD07@satmail.Advantech.ca>
	<200804041604.42214.sr@denx.de>
	<8B3930FEA8618C44B48EB06B5D33A06E12FD0B@satmail.Advantech.ca>
Message-ID: <200804081329.50384.sr@denx.de>

Hi Eugene,

On Monday 07 April 2008, Eugene O'Brien wrote:
> I had a look at all PPC440 processor manuals from AMCC and see that my
> patch applies to all of them. In other words the #else portion is never
> used. Therefore I am submitting a patch that cleans up this code quite
> nicely.

Great, thanks.

> Another observation that I made is that the PPC440EPx and PPC440GPx
> require more than 32 bits to control the power management functions.
> Therefore I defined a second set of registers cpc1_er, cpc1_fr, cpc1_sr
> for these processors. These can be used as placeholders for future
> development.

I would prefer to add those when really needed. Let's try to include only 
defines that are used. This way the headers don't get "polluted" even more.

> Let me know if this sounds good to you.

Could you please resend you patch without those new registers? And please send 
it inline and add a proper Signed-off-by line as described here:

http://www.denx.de/wiki/UBoot/Patches

I suggest to use git-send-email for sending patches.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Tue Apr  8 13:47:37 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 13:47:37 +0200
Subject: [U-Boot-Users] [PATCH 3/3] ppc4xx: Change Canyonlands to
	support booting from 2k page NAND devices
In-Reply-To: Your message of "Tue, 08 Apr 2008 10:33:29 +0200."
	<1207643609-22495-3-git-send-email-sr@denx.de>
Message-ID: <20080408114737.2AE3424842@gemini.denx.de>

In message <1207643609-22495-3-git-send-email-sr at denx.de> you wrote:
> Signed-off-by: Stefan Roese <sr at denx.de>
> ---
>  board/amcc/canyonlands/bootstrap.c        |   13 +++++++++++++
>  board/amcc/canyonlands/init.S             |    1 +
>  board/amcc/canyonlands/u-boot-nand.lds    |    4 ++--
>  include/configs/canyonlands.h             |   26 ++++++++++++++++----------
>  nand_spl/board/amcc/canyonlands/config.mk |    6 +++---
>  5 files changed, 35 insertions(+), 15 deletions(-)
> 
> diff --git a/board/amcc/canyonlands/bootstrap.c b/board/amcc/canyonlands/bootstrap.c
> index 37fa1c9..1d125b6 100644
> --- a/board/amcc/canyonlands/bootstrap.c
> +++ b/board/amcc/canyonlands/bootstrap.c
> @@ -63,9 +63,22 @@ static u8 boot_configs[][17] = {
>  /*
>   * Bytes 5,6,8,9,11 change for NAND boot
>   */
> +#if 0
> +/*
> + * Values for 512 page size NAND chips, not used anymore, just
> + * keep them here for reference
> + */

Please don't add dead code.

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: wd at denx.de
When you say "I wrote a program that crashed  Windows",  people  just
stare  at you blankly and say "Hey, I got those with the system, *for
free*".        - Linus Torvalds in <3itc77$9lj at ninurta.fer.uni-lj.si>



From wd at denx.de  Tue Apr  8 13:51:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 13:51:00 +0200
Subject: [U-Boot-Users] PA Semi support
In-Reply-To: Your message of "Tue, 08 Apr 2008 10:24:17 BST."
	<1CADFA951940554D86FBD8B24BBFF3A0E2C6BD@LONMLVEM08.e2k.ad.ge.com>
Message-ID: <20080408115100.AFFE024842@gemini.denx.de>

In message <1CADFA951940554D86FBD8B24BBFF3A0E2C6BD at LONMLVEM08.e2k.ad.ge.com> you wrote:
> 
> Is it the intention of U-Boot to support the PA Semi devices and
> integrate into the main U-Boot branch at some point?

Yes, definitely. That's the whole reason for having a custodian repo
for it.

However, if you have a closer look at the code it still needs some
major cleanup before patcehs can be submitted to the mailing list and
before these can be merged into mainline.

Please let me know if you are willing to help or to sponsor such
activities.

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: wd at denx.de
Time is an illusion perpetrated by the manufacturers of space.



From sr at denx.de  Tue Apr  8 13:52:01 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 8 Apr 2008 13:52:01 +0200
Subject: [U-Boot-Users] [PATCH 3/3] ppc4xx: Change Canyonlands to
	support booting from 2k page NAND devices
In-Reply-To: <20080408114737.2AE3424842@gemini.denx.de>
References: <20080408114737.2AE3424842@gemini.denx.de>
Message-ID: <200804081352.01473.sr@denx.de>

On Tuesday 08 April 2008, Wolfgang Denk wrote:
> > diff --git a/board/amcc/canyonlands/bootstrap.c
> > b/board/amcc/canyonlands/bootstrap.c index 37fa1c9..1d125b6 100644
> > --- a/board/amcc/canyonlands/bootstrap.c
> > +++ b/board/amcc/canyonlands/bootstrap.c
> > @@ -63,9 +63,22 @@ static u8 boot_configs[][17] = {
> >  /*
> >   * Bytes 5,6,8,9,11 change for NAND boot
> >   */
> > +#if 0
> > +/*
> > + * Values for 512 page size NAND chips, not used anymore, just
> > + * keep them here for reference
> > + */
>
> Please don't add dead code.

I was unsure about this, and kept it in as a reference for 460EX/GT boards 
using 512 page size NAND chips (see comment above). Such a reference is quite 
valuable from my point of view.

How should I keep such code available?

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From dileepkumart at gmail.com  Tue Apr  8 13:52:32 2008
From: dileepkumart at gmail.com (Dileep Kumar)
Date: Tue, 8 Apr 2008 17:22:32 +0530
Subject: [U-Boot-Users] regarding exception frame
Message-ID: <ed9edd1a0804080452j71fe896el647771797f53ea32@mail.gmail.com>

Hi,
In the uboot1.1.6 code , there are some constants like
STACK_FRAME_OVERHEAD and STACK_UNDERHEAD in
the file  "\include\ppc_asm.tmpl " . Could you please tell me what are
the use of those constants ?

Here is one statement in the macro CRITICAL_EXCEPTION_PROLOG  in the
file "ppc_asm.tmpl"

subi    r21,r1,INT_FRAME_SIZE+STACK_UNDERHEAD;  /* alloc exc. frame */\

what is the need of STACK_UNDERHEAD here ?



In the macro STD_EXCEPTION there is a statement in the same file
    addi	r3,r1,STACK_FRAME_OVERHEAD

What is the need of STACK_FRAME_OVERHEAD here ?

Please clarify my doubts ....

Thanks
Dileep Kumar



From wd at denx.de  Tue Apr  8 13:52:35 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 13:52:35 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: Your message of "Tue, 08 Apr 2008 11:31:24 +0200."
	<1207647084.5826.14.camel@gentoo-jocke.transmode.se>
Message-ID: <20080408115235.AA40524842@gemini.denx.de>

In message <1207647084.5826.14.camel at gentoo-jocke.transmode.se> you wrote:
> 
> Oops, didn't see that coming. Your _start symbol in ppc4xx/start.S isn't
> pointing to your real start of execution. Seems like _start_440 is your
> real start but I can't be sure. There are some strange code in there
> that I don't understand.

Of course. _start is where the execution of the code starts, i. e. the
entry point for U-Boot. There is no reason to expect that this might
be at the begin of any specific section.

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: wd at denx.de
GUIs  are  virtually  useless.  Learn  tools.  They're  configurable,
scriptable, automatable, cron-able, interoperable, etc. We don't need
no brain-dead winslurping monolithic claptrap.
                               -- Tom Christiansen in 371140df at csnews



From wd at denx.de  Tue Apr  8 13:58:06 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 13:58:06 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: Your message of "Tue, 08 Apr 2008 12:50:33 +0200."
	<1207651833.5826.21.camel@gentoo-jocke.transmode.se>
Message-ID: <20080408115806.6358424842@gemini.denx.de>

In message <1207651833.5826.21.camel at gentoo-jocke.transmode.se> you wrote:
> 
> > > > CFG_MONITOR_BASE=fffa0000
...
> I first did a new symbol for this but changed it to use _start as  I
> didn't want to introduce yet another symbol. I would hope it is
> possible to rework 4xx to move the _start symbol to were it belongs?
> Not having the _start symbol where it should be could bite you some
> other day too.

I think you got this wrong. _start *is* where it should be, where the
execution of the code begins. Where you set the breakpoint in gdb.

The "new symbol" you mention corresponds to CFG_MONITOR_BASE, but note
that it has no fixed address as it depends where you place your image
in flash.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Just about every computer on the market today runs Unix,  except  the
Mac (and nobody cares about it).                   - Bill Joy 6/21/85



From wd at denx.de  Tue Apr  8 14:03:58 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 14:03:58 +0200
Subject: [U-Boot-Users] [PATCH 3/3] ppc4xx: Change Canyonlands to
	support booting from 2k page NAND devices
In-Reply-To: Your message of "Tue, 08 Apr 2008 13:52:01 +0200."
	<200804081352.01473.sr@denx.de>
Message-ID: <20080408120358.76BE024842@gemini.denx.de>

In message <200804081352.01473.sr at denx.de> you wrote:
>
> > > +#if 0
> > > +/*
> > > + * Values for 512 page size NAND chips, not used anymore, just
> > > + * keep them here for reference
> > > + */
> >
> > Please don't add dead code.
> 
> I was unsure about this, and kept it in as a reference for 460EX/GT boards 
> using 512 page size NAND chips (see comment above). Such a reference is quite 
> valuable from my point of view.
> 
> How should I keep such code available?

If it's intended as documentation, it should be such - i. e. either in
some README file, or as part of some comment.

But I understanmd your argument, and you have to work more with  this
code then me - so please decide as you feel appropriate.

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: wd at denx.de
Anything that is worth doing at all is worth doing well.
                                       -- Philip Earl of Chesterfield



From kenneth at southpole.se  Tue Apr  8 14:06:59 2008
From: kenneth at southpole.se (Kenneth Johansson)
Date: Tue, 08 Apr 2008 14:06:59 +0200
Subject: [U-Boot-Users] u-boot mpc5xx start.s questions
In-Reply-To: <tencent_6007AB3B2791A3AE7EAD19B3@qq.com>
References: <tencent_6007AB3B2791A3AE7EAD19B3@qq.com>
Message-ID: <1207656419.6954.10.camel@localhost.localdomain>


On Tue, 2008-04-08 at 14:49 +0800, 278893452 wrote:
> dear sir or madam,
>       When I study the u-boot about mpc5xx, I confuse the definition
> in cpu/mpc5xx/start.s as follows: 

Do you think this is wrong or are you asking something else. 

> /*
>  * Set up GOT: Global Offset Table
>  *
>  * Use r14 to access the GOT 
>  */
>  START_GOT
>  GOT_ENTRY(_GOT2_TABLE_)
>  GOT_ENTRY(_FIXUP_TABLE_)
>  GOT_ENTRY(_start)
>  GOT_ENTRY(_start_of_vectors)
>  GOT_ENTRY(_end_of_vectors)
>  GOT_ENTRY(transfer_to_handler)
>  GOT_ENTRY(__init_end)
>  GOT_ENTRY(_end)
>  GOT_ENTRY(__bss_start)
>  END_GOT
>       Will you please kind enough to explain what happens here to me? 
>       Thank you!
>  
> jjbear

jjbear you have a very strange email address.  

The above is cpp macros. they set a few symbols.  Here is an exercise
run it through the preprocessor. If it still do not make sense post the
preprocessed out put to the list. 






From wd at denx.de  Tue Apr  8 14:13:58 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 14:13:58 +0200
Subject: [U-Boot-Users] MBX860 serial communication fails
In-Reply-To: Your message of "Tue, 08 Apr 2008 12:36:55 +0200."
	<OF1AC5C04B.0DBC9930-ONC1257425.0038E374-C1257425.003A4FCD@apcc.com>
Message-ID: <20080408121358.EDE7924842@gemini.denx.de>

In message <OF1AC5C04B.0DBC9930-ONC1257425.0038E374-C1257425.003A4FCD at apcc.com> you wrote:
>
> I tried to run u-boot-1.1.6 on my old MBX860 board (Version 20C). I tried 

Ouch. How old is this board?

> Any Idea why I do not see the startup dialogue of the u-boot bootloader ?

Did you read and heed the REAMEs?

> --=_alternative 003A4FCBC1257425_=
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/html; charset="ISO-8859-1"

And never post HTML here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Cigarette, n.: A fire at one end, a fool at the other, and a  bit  of
tobacco in between.



From joakim.tjernlund at transmode.se  Tue Apr  8 15:07:31 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 08 Apr 2008 15:07:31 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to
	full	relocation.
In-Reply-To: <20080408115806.6358424842@gemini.denx.de>
References: <20080408115806.6358424842@gemini.denx.de>
Message-ID: <1207660051.5826.47.camel@gentoo-jocke.transmode.se>


On Tue, 2008-04-08 at 13:58 +0200, Wolfgang Denk wrote:
> In message <1207651833.5826.21.camel at gentoo-jocke.transmode.se> you wrote:
> > 
> > > > > CFG_MONITOR_BASE=fffa0000
> ...
> > I first did a new symbol for this but changed it to use _start as  I
> > didn't want to introduce yet another symbol. I would hope it is
> > possible to rework 4xx to move the _start symbol to were it belongs?
> > Not having the _start symbol where it should be could bite you some
> > other day too.
> 
> I think you got this wrong. _start *is* where it should be, where the
> execution of the code begins. Where you set the breakpoint in gdb.

Ah, right. I *assumed* that _start was always the first symbol in the
text segment too. On 4xx it isn't for some reason, but it should be
possible to move it first.

Sidnote: Does execution really begin at _start for 4xx? I still looks
like it begin at _start_440 and eventually end up at _start

> 
> The "new symbol" you mention corresponds to CFG_MONITOR_BASE, but note
> that it has no fixed address as it depends where you place your image
> in flash.

Yes, but the address is not important here, it is the difference
_end - _start. I guess we could define a linker symbol too
that calculates _end - _start for us and then just do
  len = _uboot_reloc_size + EXC_OFF_SYS_RESET;

or define a new symbol that is initialised to CFG_MONITOR_BASE or let
the linker place it at the beginning of .text, hopefully there is
already a name reserved for the symbol although I don't know of such a
name. I either case I think one needs to add that symbol to the GOT list
in start.S

 Jocke




From sr at denx.de  Tue Apr  8 15:25:36 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 8 Apr 2008 15:25:36 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <1207660051.5826.47.camel@gentoo-jocke.transmode.se>
References: <20080408115806.6358424842@gemini.denx.de>
	<1207660051.5826.47.camel@gentoo-jocke.transmode.se>
Message-ID: <200804081525.36771.sr@denx.de>

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > I first did a new symbol for this but changed it to use _start as  I
> > > didn't want to introduce yet another symbol. I would hope it is
> > > possible to rework 4xx to move the _start symbol to were it belongs?
> > > Not having the _start symbol where it should be could bite you some
> > > other day too.
> >
> > I think you got this wrong. _start *is* where it should be, where the
> > execution of the code begins. Where you set the breakpoint in gdb.
>
> Ah, right. I *assumed* that _start was always the first symbol in the
> text segment too. On 4xx it isn't for some reason, but it should be
> possible to move it first.
>
> Sidnote: Does execution really begin at _start for 4xx? I still looks
> like it begin at _start_440 and eventually end up at _start

On 4xx execution always starts at 0xfffffffc (last lword in 32bit address 
space). This location holds a jump to _start for 405 PPC's and to _start_440 
for 440 PPC's. 440 PPC's need some extended initialization (TLB setup etc) 
and later jump to the 4xx common _start.

> > The "new symbol" you mention corresponds to CFG_MONITOR_BASE, but note
> > that it has no fixed address as it depends where you place your image
> > in flash.
>
> Yes, but the address is not important here, it is the difference
> _end - _start. I guess we could define a linker symbol too
> that calculates _end - _start for us and then just do
>   len = _uboot_reloc_size + EXC_OFF_SYS_RESET;
>
> or define a new symbol that is initialised to CFG_MONITOR_BASE or let
> the linker place it at the beginning of .text, hopefully there is
> already a name reserved for the symbol although I don't know of such a
> name. I either case I think one needs to add that symbol to the GOT list
> in start.S

I'm an linker script dyslexic. So no idea if we can handle this solely in the 
linker script or if we need a new common symbol in the PPC start.S's.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From Monstr at seznam.cz  Tue Apr  8 15:47:53 2008
From: Monstr at seznam.cz (=?us-ascii?Q?Michal=20Simek?=)
Date: Tue, 08 Apr 2008 15:47:53 +0200 (CEST)
Subject: [U-Boot-Users] Pull request u-boot-microblaze.git
Message-ID: <4968.8389-6630-1188321934-1207662473@seznam.cz>

Hi Wolfgang,

please pull microblaze git repo.

Thanks,
Michal Simek

The following changes since commit aeff6d503b6006573d5c6b04fc658a64bebee5fa:
  Wolfgang Denk (1):
        Merge branch 'master' of git://www.denx.de/git/u-boot-fdt

are available in the git repository at:

  . master

Michal Simek (13):
      microblaze: Clean Makefile from ancient emac driver
      microblaze: remove old setting for emac driver
      microblaze: ML401 and XUPV2P remove emac and emaclite reference
      microblaze: add Emaclite ethernet driver
      microblaze: add Emac ethernet driver
      microblaze: Add Emac driver to Makefile
      microblaze: Add Emaclite driver to Makefile
      microblaze: clean uart16550 and uartlite handling
      microblaze: ml401 - add ifdef for GPIO
      microblaze: ml401 fix config file for supporting FDT
      microblaze: xupv2p fix config file for supporting FDT
      microblaze: clean microblaze_config.mk
      microblaze: Sort microblaze boards in MAKEALL script

 MAKEALL                           |    2 +-
 board/xilinx/ml401/Makefile       |   17 +--
 board/xilinx/ml401/xparameters.h  |   12 +-
 board/xilinx/xupv2p/Makefile      |   17 +--
 board/xilinx/xupv2p/xparameters.h |   12 +-
 drivers/net/Makefile              |    2 +
 drivers/net/xilinx_emac.c         |  462 +++++++++++++++++++++++++++++++++++++
 drivers/net/xilinx_emaclite.c     |  351 ++++++++++++++++++++++++++++
 include/configs/ml401.h           |   42 +++-
 include/configs/xupv2p.h          |   37 +++-
 microblaze_config.mk              |   16 +-
 11 files changed, 890 insertions(+), 80 deletions(-)
 create mode 100644 drivers/net/xilinx_emac.c
 create mode 100644 drivers/net/xilinx_emaclite.c



From joakim.tjernlund at transmode.se  Tue Apr  8 16:04:58 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 08 Apr 2008 16:04:58 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <200804081525.36771.sr@denx.de>
References: <20080408115806.6358424842@gemini.denx.de>
	<1207660051.5826.47.camel@gentoo-jocke.transmode.se>
	<200804081525.36771.sr@denx.de>
Message-ID: <1207663498.5826.56.camel@gentoo-jocke.transmode.se>


On Tue, 2008-04-08 at 15:25 +0200, Stefan Roese wrote:
> On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > > I first did a new symbol for this but changed it to use _start as  I
> > > > didn't want to introduce yet another symbol. I would hope it is
> > > > possible to rework 4xx to move the _start symbol to were it belongs?
> > > > Not having the _start symbol where it should be could bite you some
> > > > other day too.
> > >
> > > I think you got this wrong. _start *is* where it should be, where the
> > > execution of the code begins. Where you set the breakpoint in gdb.
> >
> > Ah, right. I *assumed* that _start was always the first symbol in the
> > text segment too. On 4xx it isn't for some reason, but it should be
> > possible to move it first.
> >
> > Sidnote: Does execution really begin at _start for 4xx? I still looks
> > like it begin at _start_440 and eventually end up at _start
> 
> On 4xx execution always starts at 0xfffffffc (last lword in 32bit address 
> space). This location holds a jump to _start for 405 PPC's and to _start_440 
> for 440 PPC's. 440 PPC's need some extended initialization (TLB setup etc) 
> and later jump to the 4xx common _start.

OK, then it is like I suspected. What if you rename _start to
_common_start. Make _start equal _common_start for 405 and rename
_start_440 to _start, i.e make sure that _start is defined where you
start executing after the jump.

> 
> > > The "new symbol" you mention corresponds to CFG_MONITOR_BASE, but note
> > > that it has no fixed address as it depends where you place your image
> > > in flash.
> >
> > Yes, but the address is not important here, it is the difference
> > _end - _start. I guess we could define a linker symbol too
> > that calculates _end - _start for us and then just do
> >   len = _uboot_reloc_size + EXC_OFF_SYS_RESET;
> >
> > or define a new symbol that is initialised to CFG_MONITOR_BASE or let
> > the linker place it at the beginning of .text, hopefully there is
> > already a name reserved for the symbol although I don't know of such a
> > name. I either case I think one needs to add that symbol to the GOT list
> > in start.S
> 
> I'm an linker script dyslexic. So no idea if we can handle this solely in the 
> linker script or if we need a new common symbol in the PPC start.S's.

Both ways should be doable I think. A linker script would probably look
something like(pseudo diff below):
 .text      :
  {
+    _monitor_base = . ;
+    PROVIDE (_monitor_base = .);
    cpu/mpc83xx/start.o	(.text)

And then add a
	GOT_ENTRY(_monitor_base)
in start.S



From vapier at gentoo.org  Tue Apr  8 16:24:24 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue,  8 Apr 2008 10:24:24 -0400
Subject: [U-Boot-Users] [PATCH] removing conflicting NAND ID
Message-ID: <1207664664-27804-1-git-send-email-vapier@gentoo.org>

There are two NAND entries with ID 0xDC and this obviously causes problems.
In the kernel, they punted the first entry, so we should do the same.

See this upstream e-mail for more info:
http://lists.infradead.org/pipermail/linux-mtd/2007-July/018795.html

Signed-off-by: Michael Hennerich <michael.hennerich at analog.com>
Signed-off-by: Mike Frysinger <vapier at gentoo.org>
CC: Michael Morony <michael.morony at gmail.com>
---
 drivers/mtd/nand/nand_ids.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index 6d7e347..524b6b1 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -67,8 +67,6 @@ struct nand_flash_dev nand_flash_ids[] = {
 
 	{"NAND 256MiB 3,3V 8-bit", 	0x71, 512, 256, 0x4000, 0},
 
-	{"NAND 512MiB 3,3V 8-bit", 	0xDC, 512, 512, 0x4000, 0},
-
 	/* These are the new chips with large page size. The pagesize
 	* and the erasesize is determined from the extended id bytes
 	*/
-- 
1.5.4.4




From pierre.savary at kerlink.fr  Tue Apr  8 16:32:23 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Tue, 8 Apr 2008 16:32:23 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
Message-ID: <003601c89985$5cf10aa0$16d31fe0$@savary@kerlink.fr>

Hi,
I use a MMCplus 4GB on my design (with at91sam9260). It's wired with 4 bits.
Currently U-boot (1.1.5) can't detect correctly the MMC and so I can't read
my Linux kernel Image on the ext3 part of this MMC. If I use MMC 1GB, it
works.
Somebody have already use it? Or somebody have already implemented the
ext_csd and high capacity with MMC on another platform?
I need help. Thanks in advance to help me.

Regards,

Pierre




From u-boot at bugs.denx.de  Tue Apr  8 16:40:01 2008
From: u-boot at bugs.denx.de (u-boot at bugs.denx.de)
Date: Tue,  8 Apr 2008 16:40:01 +0200 (CEST)
Subject: [U-Boot-Users] unassigned-patches/9: [PATCH 0/2] MPC8xx: Fix libfdt
	support introduced in commit 77ff7b74
In-Reply-To: <1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com> 
Message-ID: <20080408144001.B6AD828068@theia.denx.de>

fdt.c: In function 'ft_cpu_setup':
fdt.c:33: warning: implicit declaration of function 'do_fixup_by_prop_u32'
fdt.c:39: warning: implicit declaration of function 'do_fixup_by_compat_u32'
fdt.c:43: warning: implicit declaration of function 'fdt_fixup_ethernet'
fdt.c:45: warning: implicit declaration of function 'fdt_fixup_memory'

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

---
Added to GNATS database as unassigned-patches/9
>Responsible:    patch-coord
>Message-Id:     <1207116238-7253-1-git-send-email-plagnioj at jcrosoft.com>
>In-Reply-To:    
>References:     
>Patch-Date:     Wed Apr 02 08:03:56 +0200 2008
diff --git a/cpu/mpc8xx/Makefile b/cpu/mpc8xx/Makefile
index dbdc2e0..5f70459 100644
--- a/cpu/mpc8xx/Makefile
+++ b/cpu/mpc8xx/Makefile
@@ -27,16 +27,29 @@ include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(CPU).a
 
-START	= start.o kgdb.o
-COBJS	= bedbug_860.o commproc.o cpu.o cpu_init.o	\
-	  fec.o fdt.o i2c.o interrupts.o lcd.o scc.o	\
-	  serial.o speed.o spi.o \
-	  traps.o upatch.o video.o
-SOBJS	= plprcr_write.o
-
-SRCS	:= $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
-OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
-START	:= $(addprefix $(obj),$(START))
+START-y	+= start.o
+START-y	+= kgdb.o
+COBJS-y	+= bedbug_860.o
+COBJS-y	+= commproc.o
+COBJS-y	+= cpu.o
+COBJS-y	+= cpu_init.o
+COBJS-y	+= fec.o
+COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
+COBJS-y	+= i2c.o
+COBJS-y	+= interrupts.o
+COBJS-y	+= lcd.o
+COBJS-y	+= scc.o
+COBJS-y	+= serial.o
+COBJS-y	+= speed.o
+COBJS-y	+= spi.o
+COBJS-y	+= traps.o
+COBJS-y	+= upatch.o
+COBJS-y	+= video.o
+SOBJS-y	+= plprcr_write.o
+
+SRCS	:= $(START-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
+OBJS	:= $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
+START	:= $(addprefix $(obj),$(START-y))
 
 all:	$(obj).depend $(START) $(LIB)
 
-- 
1.5.4.5


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users






From u-boot at bugs.denx.de  Tue Apr  8 16:40:01 2008
From: u-boot at bugs.denx.de (u-boot at bugs.denx.de)
Date: Tue,  8 Apr 2008 16:40:01 +0200 (CEST)
Subject: [U-Boot-Users] unassigned-patches/12: [PATCH 2/2] ds174x: Fix
	warning on return in rtc_get and rtc_set function
In-Reply-To: <1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
References: <1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
	<1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>	<1207116238-7253-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080408144001.E66F12806E@theia.denx.de>

ds174x.c: In function 'rtc_get':
ds174x.c:117: warning: no return statement in function returning non-void
ds174x.c: In function 'rtc_set':
ds174x.c:146: warning: 'return' with a value, in function returning void

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

---
Added to GNATS database as unassigned-patches/12
>Responsible:    patch-coord
>Message-Id:     <1207116238-7253-3-git-send-email-plagnioj at jcrosoft.com>
>In-Reply-To:    <1207116238-7253-2-git-send-email-plagnioj at jcrosoft.com>
>References:     <1207116238-7253-1-git-send-email-plagnioj at jcrosoft.com>	<1207116238-7253-2-git-send-email-plagnioj at jcrosoft.com>
>Patch-Date:     Wed Apr 02 08:03:58 +0200 2008
diff --git a/drivers/rtc/ds174x.c b/drivers/rtc/ds174x.c
index 81a9cb3..eb3ca88 100644
--- a/drivers/rtc/ds174x.c
+++ b/drivers/rtc/ds174x.c
@@ -114,6 +114,7 @@ int rtc_get( struct rtc_time *tmp )
 		tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
 		tmp->tm_hour, tmp->tm_min, tmp->tm_sec );
 #endif
+	return 0;
 }
 
 void rtc_set( struct rtc_time *tmp )
@@ -142,8 +143,6 @@ void rtc_set( struct rtc_time *tmp )
 
 	/* unlock clock registers after read */
 	rtc_write( RTC_CONTROLA, ( reg_a  & ~RTC_CA_WRITE ));
-
-	return 0;
 }
 
 void rtc_reset (void)
-- 
1.5.4.5


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users






From u-boot at bugs.denx.de  Tue Apr  8 16:40:01 2008
From: u-boot at bugs.denx.de (u-boot at bugs.denx.de)
Date: Tue,  8 Apr 2008 16:40:01 +0200 (CEST)
Subject: [U-Boot-Users] unassigned-patches/11: [PATCH] cmd_nand: Fix
	warning: dereferencing type-punned pointer will break
	strict-aliasing rules
In-Reply-To: <1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
	<1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080408144001.D0C2A28063@theia.denx.de>

cmd_nand.c:353: warning: dereferencing type-punned pointer will break strict-aliasing rules
cmd_nand.c:356: warning: dereferencing type-punned pointer will break strict-aliasing rules

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

---
Added to GNATS database as unassigned-patches/11
>Responsible:    patch-coord
>Message-Id:     <1207136270-19315-1-git-send-email-plagnioj at jcrosoft.com>
>In-Reply-To:    <1207116238-7253-3-git-send-email-plagnioj at jcrosoft.com>
>References:     <1207116238-7253-3-git-send-email-plagnioj at jcrosoft.com>
>Patch-Date:     Wed Apr 02 13:37:50 +0200 2008
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 7b1f830..2906aed 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -84,7 +84,7 @@ static int nand_dump(nand_info_t *nand, ulong off)
 
 /* ------------------------------------------------------------------------- */
 
-static inline int str2long(char *p, ulong *num)
+static inline int str2long(char *p, loff_t *num)
 {
 	char *endptr;
 
@@ -93,7 +93,7 @@ static inline int str2long(char *p, ulong *num)
 }
 
 static int
-arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, ulong *size)
+arg_off_size(int argc, char *argv[], nand_info_t *nand, loff_t *off, size_t *size)
 {
 	int idx = nand_curr_device;
 #if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_JFFS2_CMDLINE)
@@ -136,7 +136,7 @@ arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, ulong *size)
 	}
 
 	if (argc >= 2) {
-		if (!(str2long(argv[1], size))) {
+		if (!(str2long(argv[1], (loff_t*)size))) {
 			printf("'%s' is not a number\n", argv[1]);
 			return -1;
 		}
@@ -158,7 +158,9 @@ out:
 int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 {
 	int i, dev, ret;
-	ulong addr, off, size;
+	ulong addr;
+	loff_t off;
+	size_t size;
 	char *cmd, *s;
 	nand_info_t *nand;
 #ifdef CFG_NAND_QUIET
@@ -477,11 +479,11 @@ U_BOOT_CMD(nand, 5, 1, do_nand,
 	"nand unlock [offset] [size] - unlock section\n");
 
 static int nand_load_image(cmd_tbl_t *cmdtp, nand_info_t *nand,
-			   ulong offset, ulong addr, char *cmd)
+			   loff_t offset, ulong addr, char *cmd)
 {
 	int r;
 	char *ep, *s;
-	ulong cnt;
+	size_t cnt;
 	image_header_t *hdr;
 	int jffs2 = 0;
 #if defined(CONFIG_FIT)
diff --git a/include/nand.h b/include/nand.h
index 3c0752e..b4ee14f 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -34,22 +34,22 @@ extern int nand_curr_device;
 extern nand_info_t nand_info[];
 extern void nand_init(void);
 
-static inline int nand_read(nand_info_t *info, ulong ofs, ulong *len, u_char *buf)
+static inline int nand_read(nand_info_t *info, loff_t ofs, size_t *len, u_char *buf)
 {
-	return info->read(info, ofs, *len, (size_t *)len, buf);
+	return info->read(info, ofs, *len, len, buf);
 }
 
-static inline int nand_write(nand_info_t *info, ulong ofs, ulong *len, u_char *buf)
+static inline int nand_write(nand_info_t *info, loff_t ofs, size_t *len, u_char *buf)
 {
-	return info->write(info, ofs, *len, (size_t *)len, buf);
+	return info->write(info, ofs, *len, len, buf);
 }
 
-static inline int nand_block_isbad(nand_info_t *info, ulong ofs)
+static inline int nand_block_isbad(nand_info_t *info, loff_t ofs)
 {
 	return info->block_isbad(info, ofs);
 }
 
-static inline int nand_erase(nand_info_t *info, ulong off, ulong size)
+static inline int nand_erase(nand_info_t *info, loff_t off, ulong size)
 {
 	struct erase_info instr;
 
@@ -68,8 +68,8 @@ static inline int nand_erase(nand_info_t *info, ulong off, ulong size)
 
 struct nand_write_options {
 	u_char *buffer;		/* memory block containing image to write */
-	ulong length;		/* number of bytes to write */
-	ulong offset;		/* start address in NAND */
+	size_t length;		/* number of bytes to write */
+	loff_t offset;		/* start address in NAND */
 	int quiet;		/* don't display progress messages */
 	int autoplace;		/* if true use auto oob layout */
 	int forcejffs2;		/* force jffs2 oob layout */
@@ -85,8 +85,8 @@ typedef struct nand_write_options nand_write_options_t;
 
 struct nand_read_options {
 	u_char *buffer;		/* memory block in which read image is written*/
-	ulong length;		/* number of bytes to read */
-	ulong offset;		/* start address in NAND */
+	size_t length;		/* number of bytes to read */
+	loff_t offset;		/* start address in NAND */
 	int quiet;		/* don't display progress messages */
 	int readoob;		/* put oob data in image */
 };
@@ -94,8 +94,8 @@ struct nand_read_options {
 typedef struct nand_read_options nand_read_options_t;
 
 struct nand_erase_options {
-	ulong length;		/* number of bytes to erase */
-	ulong offset;		/* first address in NAND to erase */
+	size_t length;		/* number of bytes to erase */
+	loff_t offset;		/* first address in NAND to erase */
 	int quiet;		/* don't display progress messages */
 	int jffs2;		/* if true: format for jffs2 usage
 				 * (write appropriate cleanmarker blocks) */
-- 
1.5.4.5


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users






From u-boot at bugs.denx.de  Tue Apr  8 16:40:01 2008
From: u-boot at bugs.denx.de (u-boot at bugs.denx.de)
Date: Tue,  8 Apr 2008 16:40:01 +0200 (CEST)
Subject: [U-Boot-Users] unassigned-patches/10: [PATCH 1/2] cmd_log.c: Fix
	assignment differ in signedness
In-Reply-To: <1207116238-7253-2-git-send-email-plagnioj@jcrosoft.com>
References: <1207116238-7253-2-git-send-email-plagnioj@jcrosoft.com>
	<1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080408144001.BFD6A28069@theia.denx.de>

In function 'logbuff_init_ptrs':
cmd_log.c:79: warning: pointer targets in assignment differ in signedness

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

---
Added to GNATS database as unassigned-patches/10
>Responsible:    patch-coord
>Message-Id:     <1207116238-7253-2-git-send-email-plagnioj at jcrosoft.com>
>In-Reply-To:    <1207116238-7253-1-git-send-email-plagnioj at jcrosoft.com>
>References:     <1207116238-7253-1-git-send-email-plagnioj at jcrosoft.com>
>Patch-Date:     Wed Apr 02 08:03:57 +0200 2008
diff --git a/common/cmd_log.c b/common/cmd_log.c
index 34b36ff..b9f9ba0 100644
--- a/common/cmd_log.c
+++ b/common/cmd_log.c
@@ -76,7 +76,7 @@ void logbuff_init_ptrs (void)
 	lbuf = (char *)CONFIG_ALT_LB_ADDR;
 #else
 	log = (logbuff_t *)(gd->bd->bi_memsize-LOGBUFF_LEN) - 1;
-	lbuf = log->buf;
+	lbuf = (char *)log->buf;
 #endif
 
 	/* Set up log version */
-- 
1.5.4.5


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users






From u-boot at bugs.denx.de  Tue Apr  8 16:40:02 2008
From: u-boot at bugs.denx.de (u-boot at bugs.denx.de)
Date: Tue,  8 Apr 2008 16:40:02 +0200 (CEST)
Subject: [U-Boot-Users] unassigned-patches/13: [PATCH] mpc837xerdb: Fix
	warning: implicit declaration of function 'fdt_fixup_dr_usb'
In-Reply-To: <1207136481-19429-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207136481-19429-1-git-send-email-plagnioj@jcrosoft.com>
	<1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080408144002.1115D2806F@theia.denx.de>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

---
Added to GNATS database as unassigned-patches/13
>Responsible:    patch-coord
>Message-Id:     <1207136481-19429-1-git-send-email-plagnioj at jcrosoft.com>
>In-Reply-To:    <1207136270-19315-1-git-send-email-plagnioj at jcrosoft.com>
>References:     <1207136270-19315-1-git-send-email-plagnioj at jcrosoft.com>
>Patch-Date:     Wed Apr 02 13:41:21 +0200 2008
diff --git a/board/freescale/mpc837xerdb/mpc837xerdb.c b/board/freescale/mpc837xerdb/mpc837xerdb.c
index 83fb60d..965bb67 100644
--- a/board/freescale/mpc837xerdb/mpc837xerdb.c
+++ b/board/freescale/mpc837xerdb/mpc837xerdb.c
@@ -16,10 +16,10 @@
 #include <i2c.h>
 #include <asm/io.h>
 #include <asm/fsl_serdes.h>
+#include <fdt_support.h>
 #include <spd_sdram.h>
 #include <vsc7385.h>
 
-
 #if defined(CFG_DRAM_TEST)
 int
 testdram(void)
-- 
1.5.4.5


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users






From galak at kernel.crashing.org  Tue Apr  8 17:45:50 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 8 Apr 2008 10:45:50 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx: Use SVR_SOC_VER instead of SVR_VER
Message-ID: <Pine.LNX.4.64.0804081043260.9248@blarg.am.freescale.net>

The recent change introduced by 'Update SVR numbers to expand support'
now requires that we use SVR_SOC_VER instead of SVR_VER if we want
to compare against a particular processor id.

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

This fixes an issue and should go into 1.3.3.

 cpu/mpc85xx/cpu_init.c  |    2 +-
 cpu/mpc85xx/spd_sdram.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
index fce0c48..e3240b5 100644
--- a/cpu/mpc85xx/cpu_init.c
+++ b/cpu/mpc85xx/cpu_init.c
@@ -272,7 +272,7 @@ int cpu_init_r(void)
 	uint l2srbar;

 	svr = get_svr();
-	ver = SVR_VER(svr);
+	ver = SVR_SOC_VER(svr);

 	asm("msync;isync");
 	cache_ctl = l2cache->l2ctl;
diff --git a/cpu/mpc85xx/spd_sdram.c b/cpu/mpc85xx/spd_sdram.c
index abc63c4..435458a 100644
--- a/cpu/mpc85xx/spd_sdram.c
+++ b/cpu/mpc85xx/spd_sdram.c
@@ -306,7 +306,7 @@ spd_sdram(void)
 	 * Adjust DDR II IO voltage biasing.
 	 * Only 8548 rev 1 needs the fix
 	 */
-	if ((SVR_VER(get_svr()) == SVR_8548_E) &&
+	if ((SVR_SOC_VER(get_svr()) == SVR_8548_E) &&
 			(SVR_MJREV(get_svr()) == 1) &&
 			(spd.mem_type == SPD_MEMTYPE_DDR2)) {
 		volatile ccsr_gur_t *gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
-- 
1.5.4.1




From Tsi-chung.Liew at freescale.com  Tue Apr  8 19:15:25 2008
From: Tsi-chung.Liew at freescale.com (Liew Tsi Chung)
Date: Tue, 8 Apr 2008 10:15:25 -0700
Subject: [U-Boot-Users] "huge" (6 second) delay when booting linuxkernel
	(coldfire)
In-Reply-To: <47F5FCC0.2984.5462256@w.wegner.astro-kom.de>
References: <47F5E32B.14233.4E234DB@w.wegner.astro-kom.de>,
	<47F5E8A2.14762.4F78C6B@w.wegner.astro-kom.de>
	<47F5FCC0.2984.5462256@w.wegner.astro-kom.de>
Message-ID: <4791E710007FEB4BBF83775D787F462F06F698A9@az33exm22.fsl.freescale.net>

Wolfgang,

I'm glad that you found the problem.

> Booting works fast as it should. (This new CFG_BOOTMAPSZ came from
M5329EVB.h).
It must have been the early work that I did not change to use the new
CFG_BOOTMAPSZ. Now, the current repository has the new CFG_BOOTMAPSZ.

Regards,
TsiChung

-----Original Message-----
From: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of
w.wegner at astro-kom.de
Sent: Friday, April 04, 2008 3:03 AM
To: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] "huge" (6 second) delay when booting
linuxkernel (coldfire)

On 4 Apr 2008 at 8:36, w.wegner at astro-kom.de wrote:

> Hi,
> 
> On 4 Apr 2008 at 8:13, w.wegner at astro-kom.de wrote:
> 
> > Hi,
> > 
> > I have a problem on startup on my Coldfire MCF5373L board.
> > 
> > When the flash is empty, something before booting the linux kernel 
> > takes too long such that the watchdog resets my board before there 
> > is a chance for the kernel to take over control.
> 
> with some more puts() I found there is around 4 second delay in this 
> line of do_bootm_linux() in lib_m68k/m68k_linux.c:
> 
> 	cmd_end = cmd_start + strlen(cmdline);

Found the problem.

It was a wrong CFG_BOOTMAPSZ, seems to have been a relic from my very
first try in porting to MCF53xx. With the correct line:

#define CFG_BOOTMAPSZ		(CFG_SDRAM_BASE + (CFG_SDRAM_SIZE <<
20))

Booting works fast as it should. (This new CFG_BOOTMAPSZ came from
M5329EVB.h).

Regards,
Wolfgang



From vapier at gentoo.org  Tue Apr  8 20:00:57 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue,  8 Apr 2008 14:00:57 -0400
Subject: [U-Boot-Users] [PATCH] Add support for u-boot in svn and
	localversion-* files
In-Reply-To: <1201344308-10145-1-git-send-email-vapier@gentoo.org>
References: <1201344308-10145-1-git-send-email-vapier@gentoo.org>
Message-ID: <1207677657-31722-1-git-send-email-vapier@gentoo.org>

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 tools/setlocalversion |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/tools/setlocalversion b/tools/setlocalversion
index 9bbdafd..bbb2ab2 100755
--- a/tools/setlocalversion
+++ b/tools/setlocalversion
@@ -22,4 +22,18 @@ if head=`git rev-parse --verify HEAD 2>/dev/null`; then
 	    | read dummy; then
 		printf '%s' -dirty
 	fi
+
+	# Is this git on svn?
+	if git config --get svn-remote.svn.url >/dev/null; then
+		printf -- '-svn%s' "`git-svn find-rev $head`"
+	fi
 fi
+
+# Check for svn and a svn repo.
+if rev=`svn info 2>/dev/null` ; then
+	rev=`echo "${rev}" | grep '^Revision' | awk '{print $NF}'`
+	printf -- '-svn%s' $rev
+fi
+
+# Check for any localversion-* files
+printf '%s' "`cat localversion-* 2>/dev/null`"
-- 
1.5.4.4




From sr at denx.de  Tue Apr  8 21:52:52 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 8 Apr 2008 21:52:52 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <1207663498.5826.56.camel@gentoo-jocke.transmode.se>
References: <20080408115806.6358424842@gemini.denx.de>
	<200804081525.36771.sr@denx.de>
	<1207663498.5826.56.camel@gentoo-jocke.transmode.se>
Message-ID: <200804082152.53399.sr@denx.de>

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > On 4xx execution always starts at 0xfffffffc (last lword in 32bit address
> > space). This location holds a jump to _start for 405 PPC's and to
> > _start_440 for 440 PPC's. 440 PPC's need some extended initialization
> > (TLB setup etc) and later jump to the 4xx common _start.
>
> OK, then it is like I suspected. What if you rename _start to
> _common_start. Make _start equal _common_start for 405 and rename
> _start_440 to _start, i.e make sure that _start is defined where you
> start executing after the jump.

As I mentioned earlier, _start_440 is mapped to 0xfffff000 via the linker 
script since the jump from 0xfffffffc can't be too long (because of the 4k 
shadow TLB entry). So renaming _start_440 to _start won't help here. It can 
be done, but frankly I don't have the time for it currently.

> > I'm an linker script dyslexic. So no idea if we can handle this solely in
> > the linker script or if we need a new common symbol in the PPC start.S's.
>
> Both ways should be doable I think. A linker script would probably look
> something like(pseudo diff below):
>  .text      :
>   {
> +    _monitor_base = . ;
> +    PROVIDE (_monitor_base = .);
>     cpu/mpc83xx/start.o	(.text)
>
> And then add a
> 	GOT_ENTRY(_monitor_base)
> in start.S

The disadvantage I see is that I need to change the linker scripts for all 
boards for such a solution. Doesn't sound like fun.

So for now, I would really like to see the old version with the ugly 
CFG_MONITOR_BASE back so that 4xx board can be used again.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From Joakim.Tjernlund at transmode.se  Tue Apr  8 22:30:24 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 8 Apr 2008 22:30:24 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to
	full	relocation.
In-Reply-To: <200804082152.53399.sr@denx.de>
References: <20080408115806.6358424842@gemini.denx.de>	<200804081525.36771.sr@denx.de>	<1207663498.5826.56.camel@gentoo-jocke.transmode.se>
	<200804082152.53399.sr@denx.de>
Message-ID: <044601c899b7$60379760$20a6c620$@Tjernlund@transmode.se>

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net]
> On Behalf Of Stefan Roese
> Sent: den 8 april 2008 21:53
> To: joakim.tjernlund at transmode.se
> Cc: u-boot-users at lists.sourceforge.net; 'Kim Phillips'; Wolfgang Denk
> Subject: Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
> 
> On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > On 4xx execution always starts at 0xfffffffc (last lword in 32bit address
> > > space). This location holds a jump to _start for 405 PPC's and to
> > > _start_440 for 440 PPC's. 440 PPC's need some extended initialization
> > > (TLB setup etc) and later jump to the 4xx common _start.
> >
> > OK, then it is like I suspected. What if you rename _start to
> > _common_start. Make _start equal _common_start for 405 and rename
> > _start_440 to _start, i.e make sure that _start is defined where you
> > start executing after the jump.
> 
> As I mentioned earlier, _start_440 is mapped to 0xfffff000 via the linker
> script since the jump from 0xfffffffc can't be too long (because of the 4k
> shadow TLB entry). So renaming _start_440 to _start won't help here. It can
> be done, but frankly I don't have the time for it currently.

I see, suspected that we would not get away that easy :(

> 
> > > I'm an linker script dyslexic. So no idea if we can handle this solely in
> > > the linker script or if we need a new common symbol in the PPC start.S's.
> >
> > Both ways should be doable I think. A linker script would probably look
> > something like(pseudo diff below):
> >  .text      :
> >   {
> > +    _monitor_base = . ;
> > +    PROVIDE (_monitor_base = .);
> >     cpu/mpc83xx/start.o	(.text)
> >
> > And then add a
> > 	GOT_ENTRY(_monitor_base)
> > in start.S
> 
> The disadvantage I see is that I need to change the linker scripts for all
> boards for such a solution. Doesn't sound like fun.

Yeah, probably easier to define the symbol in start.S and skip the linker
version. 

> 
> So for now, I would really like to see the old version with the ugly
> CFG_MONITOR_BASE back so that 4xx board can be used again.

Then I would ask you to do an #ifdef for ppc440(or similar). If the
long term solution should be to move _start to its true start vector, you
could just go back to the old way for ppc4xx. If the long term solution should
be a new symbol you could just impl. that for ppc4xx and just use it for
ppc4xx only, then the other archs can follow when the next merge window opens.

    Jocke
> 
> Best regards,
> Stefan





From wd at denx.de  Tue Apr  8 22:41:51 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 22:41:51 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: Your message of "Tue, 08 Apr 2008 16:04:58 +0200."
	<1207663498.5826.56.camel@gentoo-jocke.transmode.se>
Message-ID: <20080408204151.601B124842@gemini.denx.de>

In message <1207663498.5826.56.camel at gentoo-jocke.transmode.se> you wrote:
> 
> Both ways should be doable I think. A linker script would probably look
> something like(pseudo diff below):
>  .text      :
>   {
> +    _monitor_base = . ;

There is no guarantee that this is the same as the start address of
.text


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: wd at denx.de
Genius doesn't work on an assembly line basis.  You can't simply say,
"Today I will be brilliant."
	-- Kirk, "The Ultimate Computer", stardate 4731.3



From wd at denx.de  Tue Apr  8 22:47:39 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 22:47:39 +0200
Subject: [U-Boot-Users] [U-boot] [PATCH 0/2] MPC8xx: Fix libfdt support
	introduced in commit 77ff7b74
In-Reply-To: Your message of "Wed, 02 Apr 2008 08:03:56 +0200."
	<1207116238-7253-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080408204739.CAAC524842@gemini.denx.de>

In message <1207116238-7253-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> fdt.c: In function 'ft_cpu_setup':
> fdt.c:33: warning: implicit declaration of function 'do_fixup_by_prop_u32'
> fdt.c:39: warning: implicit declaration of function 'do_fixup_by_compat_u32'
> fdt.c:43: warning: implicit declaration of function 'fdt_fixup_ethernet'
> fdt.c:45: warning: implicit declaration of function 'fdt_fixup_memory'
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/cpu/mpc8xx/Makefile b/cpu/mpc8xx/Makefile
> index dbdc2e0..5f70459 100644
> --- a/cpu/mpc8xx/Makefile
> +++ b/cpu/mpc8xx/Makefile
> @@ -27,16 +27,29 @@ include $(TOPDIR)/config.mk
>  
>  LIB	= $(obj)lib$(CPU).a
>  
> -START	= start.o kgdb.o
> -COBJS	= bedbug_860.o commproc.o cpu.o cpu_init.o	\
> -	  fec.o fdt.o i2c.o interrupts.o lcd.o scc.o	\
> -	  serial.o speed.o spi.o \
> -	  traps.o upatch.o video.o
> -SOBJS	= plprcr_write.o
> -
> -SRCS	:= $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
> -OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
> -START	:= $(addprefix $(obj),$(START))
> +START-y	+= start.o
> +START-y	+= kgdb.o
> +COBJS-y	+= bedbug_860.o
> +COBJS-y	+= commproc.o
> +COBJS-y	+= cpu.o
> +COBJS-y	+= cpu_init.o
> +COBJS-y	+= fec.o
> +COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
> +COBJS-y	+= i2c.o
> +COBJS-y	+= interrupts.o
> +COBJS-y	+= lcd.o
> +COBJS-y	+= scc.o
> +COBJS-y	+= serial.o
> +COBJS-y	+= speed.o
> +COBJS-y	+= spi.o
> +COBJS-y	+= traps.o
> +COBJS-y	+= upatch.o
> +COBJS-y	+= video.o
> +SOBJS-y	+= plprcr_write.o
> +
> +SRCS	:= $(START-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
> +OBJS	:= $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
> +START	:= $(addprefix $(obj),$(START-y))
>  
>  all:	$(obj).depend $(START) $(LIB)

I cannot see any correlation between your commit message and the
actual changes???


NAK.

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: wd at denx.de
"Plan to throw one away.  You will anyway."
                              - Fred Brooks, "The Mythical Man Month"



From wd at denx.de  Tue Apr  8 22:49:07 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 22:49:07 +0200
Subject: [U-Boot-Users] [U-boot] [PATCH] cmd_nand: Fix warning:
	dereferencing type-punned pointer will break strict-aliasing rules
In-Reply-To: Your message of "Wed, 02 Apr 2008 13:37:50 +0200."
	<1207136270-19315-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080408204907.CE64E24842@gemini.denx.de>

In message <1207136270-19315-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> cmd_nand.c:353: warning: dereferencing type-punned pointer will break strict-aliasing rules
> cmd_nand.c:356: warning: dereferencing type-punned pointer will break strict-aliasing rules
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c
> index 7b1f830..2906aed 100644
> --- a/common/cmd_nand.c
> +++ b/common/cmd_nand.c
> @@ -84,7 +84,7 @@ static int nand_dump(nand_info_t *nand, ulong off)
>  
>  /* ------------------------------------------------------------------------- */
>  
> -static inline int str2long(char *p, ulong *num)
> +static inline int str2long(char *p, loff_t *num)

We discussed this before.

string-to-long converts into a "long" type, not into an offset type.

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: wd at denx.de
Above all else -- sky.



From Joakim.Tjernlund at transmode.se  Tue Apr  8 22:52:52 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 8 Apr 2008 22:52:52 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <20080408204151.601B124842@gemini.denx.de>
References: Your message of "Tue, 08 Apr 2008 16:04:58 +0200."
	<1207663498.5826.56.camel@gentoo-jocke.transmode.se>
	<20080408204151.601B124842@gemini.denx.de>
Message-ID: <044901c899ba$83532450$89f96cf0$@Tjernlund@transmode.se>

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: den 8 april 2008 22:42
> To: joakim.tjernlund at transmode.se
> Cc: Stefan Roese; u-boot-users at lists.sourceforge.net; 'Kim Phillips'
> Subject: Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
> 
> In message <1207663498.5826.56.camel at gentoo-jocke.transmode.se> you wrote:
> >
> > Both ways should be doable I think. A linker script would probably look
> > something like(pseudo diff below):
> >  .text      :
> >   {
> > +    _monitor_base = . ;
> 
> There is no guarantee that this is the same as the start address of
> .text
> 

I am no link script expert, but I cannot see why that would not be the start
of the .text segment?

Anyhow, we can go with the other solution instead, define the symbol in start.S
instead, if one is needed.

 Jocke




From wd at denx.de  Tue Apr  8 23:01:24 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 23:01:24 +0200
Subject: [U-Boot-Users] [U-boot] [PATCH 2/2] ds174x: Fix warning on
	return in rtc_get and rtc_set function
In-Reply-To: Your message of "Wed, 02 Apr 2008 08:03:58 +0200."
	<1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080408210124.6713F24842@gemini.denx.de>

In message <1207116238-7253-3-git-send-email-plagnioj at jcrosoft.com> you wrote:
> ds174x.c: In function 'rtc_get':
> ds174x.c:117: warning: no return statement in function returning non-void
> ds174x.c: In function 'rtc_set':
> ds174x.c:146: warning: 'return' with a value, in function returning void
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/drivers/rtc/ds174x.c b/drivers/rtc/ds174x.c
> index 81a9cb3..eb3ca88 100644
> --- a/drivers/rtc/ds174x.c
> +++ b/drivers/rtc/ds174x.c
> @@ -114,6 +114,7 @@ int rtc_get( struct rtc_time *tmp )
>  		tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
>  		tmp->tm_hour, tmp->tm_min, tmp->tm_sec );
>  #endif
> +	return 0;
>  }
>  
>  void rtc_set( struct rtc_time *tmp )
> @@ -142,8 +143,6 @@ void rtc_set( struct rtc_time *tmp )
>  
>  	/* unlock clock registers after read */
>  	rtc_write( RTC_CONTROLA, ( reg_a  & ~RTC_CA_WRITE ));
> -
> -	return 0;
>  }
>  
>  void rtc_reset (void)

I think this is actually not the right fix.

To make things right, both rtc_set() and rtc_get() should return
"int".

Yes, I'm aware that this is far beyond the scope of your fixes here,
but I wanted to at least note that.

Note that this is no NAK.



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: wd at denx.de
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to  the
purpose of sitting around all day and eating big heavy meals.
                                 - Terry Pratchett, _Moving Pictures_



From wd at denx.de  Tue Apr  8 23:04:33 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 23:04:33 +0200
Subject: [U-Boot-Users] [PATCH] Add support for u-boot in svn and
	localversion-* files
In-Reply-To: Your message of "Tue, 08 Apr 2008 14:00:57 EDT."
	<1207677657-31722-1-git-send-email-vapier@gentoo.org>
Message-ID: <20080408210433.AC07424842@gemini.denx.de>

In message <1207677657-31722-1-git-send-email-vapier at gentoo.org> you wrote:
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>

Hm... is anybody using SVN for U-Boot?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Philosophy is a game with objectives and no rules.
Mathematics is a game with rules and no objectives.



From wd at denx.de  Tue Apr  8 23:09:20 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 08 Apr 2008 23:09:20 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: Your message of "Tue, 08 Apr 2008 22:52:52 +0200."
	<044901c899ba$83532450$89f96cf0$@Tjernlund@transmode.se>
Message-ID: <20080408210920.56F3B24842@gemini.denx.de>

In message <044901c899ba$83532450$89f96cf0$@Tjernlund at transmode.se> you wrote:
>
> > >  .text      :
> > >   {
> > > +    _monitor_base = . ;
> > 
> > There is no guarantee that this is the same as the start address of
> > .text
> > 
> 
> I am no link script expert, but I cannot see why that would not be the start
> of the .text segment?

There might be other segments at the start of the image...

See for example cpu/mpc8xx/start.S - while at the  moment  we  really
start with .text, it would technically be more approrpriate to change
the  first  256  bytes  (from monitor base to EXC_OFF_SYS_RESET) into
.rodata or something like this.

> Anyhow, we can go with the other solution instead, define the symbol in start.S
> instead, if one is needed.

If it cannot be avoided ;-)

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: wd at denx.de
Thought for the day: What if there were no hypothetical situations?



From biggerbadderben at gmail.com  Tue Apr  8 23:19:43 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Tue, 08 Apr 2008 17:19:43 -0400
Subject: [U-Boot-Users] [PATCH] Add support for u-boot in svn
 and	localversion-* files
In-Reply-To: <20080408210433.AC07424842@gemini.denx.de>
References: <20080408210433.AC07424842@gemini.denx.de>
Message-ID: <47FBE16F.9030003@gmail.com>

Wolfgang Denk wrote:
> In message <1207677657-31722-1-git-send-email-vapier at gentoo.org> you wrote:
>   
>> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
>>     
>
> Hm... is anybody using SVN for U-Boot?
>
> Best regards,
>
> Wolfgang Denk
>
>   
I used it at my last company and will most certainly use it again, and 
appreciate this patch.  I think it's very popular in companies that 
prefer free, more traditional revision control.

regards,
Ben



From vapier at gentoo.org  Tue Apr  8 23:45:51 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Tue, 8 Apr 2008 17:45:51 -0400
Subject: [U-Boot-Users] [PATCH] Add support for u-boot in svn and
	localversion-* files
In-Reply-To: <20080408210433.AC07424842@gemini.denx.de>
References: <20080408210433.AC07424842@gemini.denx.de>
Message-ID: <200804081745.52136.vapier@gentoo.org>

On Tuesday 08 April 2008, Wolfgang Denk wrote:
> In message <1207677657-31722-1-git-send-email-vapier at gentoo.org> you wrote:
> > Signed-off-by: Mike Frysinger <vapier at gentoo.org>
>
> Hm... is anybody using SVN for U-Boot?

i am, otherwise i wouldnt care :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080408/bab61023/attachment.pgp 

From galak at kernel.crashing.org  Tue Apr  8 23:49:33 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 8 Apr 2008 16:49:33 -0500
Subject: [U-Boot-Users] [PATCH] Add support for u-boot in svn
	and	localversion-* files
In-Reply-To: <47FBE16F.9030003@gmail.com>
References: <20080408210433.AC07424842@gemini.denx.de>
	<47FBE16F.9030003@gmail.com>
Message-ID: <62330506-2BC7-4475-B394-EA38443308FB@kernel.crashing.org>


On Apr 8, 2008, at 4:19 PM, Ben Warren wrote:
> Wolfgang Denk wrote:
>> In message <1207677657-31722-1-git-send-email-vapier at gentoo.org>  
>> you wrote:
>>
>>> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
>>>
>>
>> Hm... is anybody using SVN for U-Boot?
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>>
> I used it at my last company and will most certainly use it again, and
> appreciate this patch.  I think it's very popular in companies that
> prefer free, more traditional revision control.

bah, use git :)

- k



From Joakim.Tjernlund at transmode.se  Tue Apr  8 23:51:15 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 8 Apr 2008 23:51:15 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <20080408210920.56F3B24842@gemini.denx.de>
References: Your message of "Tue, 08 Apr 2008 22:52:52 +0200."
	<044901c899ba$83532450$89f96cf0$@Tjernlund@transmode.se>
	<20080408210920.56F3B24842@gemini.denx.de>
Message-ID: <044c01c899c2$abbb67b0$03323710$@Tjernlund@transmode.se>



> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: den 8 april 2008 23:09
> To: Joakim Tjernlund
> Cc: 'Stefan Roese'; u-boot-users at lists.sourceforge.net; 'Kim Phillips'
> Subject: Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
> 
> In message <044901c899ba$83532450$89f96cf0$@Tjernlund at transmode.se> you wrote:
> >
> > > >  .text      :
> > > >   {
> > > > +    _monitor_base = . ;
> > >
> > > There is no guarantee that this is the same as the start address of
> > > .text
> > >
> >
> > I am no link script expert, but I cannot see why that would not be the start
> > of the .text segment?
> 
> There might be other segments at the start of the image...
> 
> See for example cpu/mpc8xx/start.S - while at the  moment  we  really
> start with .text, it would technically be more approrpriate to change
> the  first  256  bytes  (from monitor base to EXC_OFF_SYS_RESET) into
> .rodata or something like this.

Ahh, now I see what you mean and it gave me an idea ...

> 
> > Anyhow, we can go with the other solution instead, define the symbol in start.S
> > instead, if one is needed.
> 
> If it cannot be avoided ;-)

... Stefan, maybe you can #define EXC_OFF_SYS_RESET for 405 to something that
fits with my relocation patch?

  Jocke






From pmeloy at shaw.ca  Wed Apr  9 01:32:31 2008
From: pmeloy at shaw.ca (pat)
Date: Tue, 08 Apr 2008 16:32:31 -0700
Subject: [U-Boot-Users]  Working config to compare?
In-Reply-To: <20080407220629.C867B242FB@gemini.denx.de>
References: <20080407220629.C867B242FB@gemini.denx.de>
Message-ID: <1207697551.27931.7.camel@rhodan.shaw.ca>

I managed to get version 1.2.0 to work with my SMDK2410(ish) board and
NAND flash (at least I think it works, I wrote a kernel to NAND, read it
back, and booted). Considering I had barely any idea what I was doing,
it was an impressive feat 8)

Now I'm wanting to take a crack at getting the smdk2410 or sbc2410
(probably the latter since it already has the extra chips configured).
I'm hoping they are non-working mostly because of support file changes
and just the board/include files need straightening out.

Can someone name a board that works "out of the box" with 1.3.2 that I
could use for comparison with the s3c2410 boards and perhaps get it
working?

It seems the s3c2410's are not well supported anywhere outside of Korea
and China. (google translate has been a HUGE help even though context
escapes it completely)





From dwh at ovro.caltech.edu  Wed Apr  9 00:17:46 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Tue, 08 Apr 2008 15:17:46 -0700
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to
	full	relocation.
In-Reply-To: <044c01c899c2$abbb67b0$03323710$@Tjernlund@transmode.se>
References: Your message of "Tue, 08 Apr 2008 22:52:52
	+0200."	<044901c899ba$83532450$89f96cf0$@Tjernlund@transmode.se>	<20080408210920.56F3B24842@gemini.denx.de>
	<044c01c899c2$abbb67b0$03323710$@Tjernlund@transmode.se>
Message-ID: <47FBEF0A.2010603@ovro.caltech.edu>

Hi Joakim,

>> See for example cpu/mpc8xx/start.S - while at the  moment we really
>> start with .text, it would technically be more approrpriate to change
>> the  first  256  bytes  (from monitor base to EXC_OFF_SYS_RESET) into
>> .rodata or something like this.
> 
> Ahh, now I see what you mean and it gave me an idea ...

While you're chewing on ideas, here's a couple of points about
mpc83xx/start.S

The reset configuration words that start at the beginning of
Flash are *optional*, and depend on the reset configurations
words source pin strapping (CFG_RS[0:2]).

If CFG_RS[0:2] = 000b, then the RCWs are read from the local
bus chip-select 0. Nominally this means read from flash, but
hardware can subvert the bus to the flash and supply the RCWs
from an alternative source, eg. on the MPC8349EA-MDS-PB, the
RCWs can be driven onto the local bus by an on-board CPLD
(which in turn gets the RCWs from dip switches).

On my custom MPC8349EA board, I can deliver the RCWs from the
Flash, or if flash is blank, from the FPGA, or I can change the
CFG_RS[0:2] source so that the processor uses hard-coded
RCWs, or an I2C boot EEPROM.

If the RCWs were placed in their own section, then that section
could be made optional. In the case of it being used, and boot-low
being used (RCWH[BMS] = 0), then the RCW+U-Boot magic+string section
would need be 100h bytes in size, and be concatenated with the
U-Boot image. Otherwise the RCW area could be left as a separate
binary image, that the user has to burn to Flash. (Eg. for a user
that for some bizarre reason wants to put RCWH[BMS] = 1 :) ).

How about a 100-byte section called .rcw, or .rcwdata?

I'm not sure if these comments will make life easier or worse ...

Cheers,
Dave



From gvb.uboot at gmail.com  Wed Apr  9 02:04:36 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Tue, 08 Apr 2008 20:04:36 -0400
Subject: [U-Boot-Users] [U-boot] [PATCH 0/2] MPC8xx: Fix libfdt support
 introduced in commit 77ff7b74
In-Reply-To: <20080408204739.CAAC524842@gemini.denx.de>
References: <20080408204739.CAAC524842@gemini.denx.de>
Message-ID: <47FC0814.5070504@gmail.com>

Wolfgang Denk wrote:
> In message <1207116238-7253-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
>> fdt.c: In function 'ft_cpu_setup':
>> fdt.c:33: warning: implicit declaration of function 'do_fixup_by_prop_u32'
>> fdt.c:39: warning: implicit declaration of function 'do_fixup_by_compat_u32'
>> fdt.c:43: warning: implicit declaration of function 'fdt_fixup_ethernet'
>> fdt.c:45: warning: implicit declaration of function 'fdt_fixup_memory'
>>
>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>>
>> diff --git a/cpu/mpc8xx/Makefile b/cpu/mpc8xx/Makefile
>> index dbdc2e0..5f70459 100644
>> --- a/cpu/mpc8xx/Makefile
>> +++ b/cpu/mpc8xx/Makefile
>> @@ -27,16 +27,29 @@ include $(TOPDIR)/config.mk
>>  
>>  LIB	= $(obj)lib$(CPU).a
>>  
>> -START	= start.o kgdb.o
>> -COBJS	= bedbug_860.o commproc.o cpu.o cpu_init.o	\
>> -	  fec.o fdt.o i2c.o interrupts.o lcd.o scc.o	\
>> -	  serial.o speed.o spi.o \
>> -	  traps.o upatch.o video.o
>> -SOBJS	= plprcr_write.o
>> -
>> -SRCS	:= $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
>> -OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
>> -START	:= $(addprefix $(obj),$(START))
>> +START-y	+= start.o
>> +START-y	+= kgdb.o
>> +COBJS-y	+= bedbug_860.o
>> +COBJS-y	+= commproc.o
>> +COBJS-y	+= cpu.o
>> +COBJS-y	+= cpu_init.o
>> +COBJS-y	+= fec.o
>> +COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
>> +COBJS-y	+= i2c.o
>> +COBJS-y	+= interrupts.o
>> +COBJS-y	+= lcd.o
>> +COBJS-y	+= scc.o
>> +COBJS-y	+= serial.o
>> +COBJS-y	+= speed.o
>> +COBJS-y	+= spi.o
>> +COBJS-y	+= traps.o
>> +COBJS-y	+= upatch.o
>> +COBJS-y	+= video.o
>> +SOBJS-y	+= plprcr_write.o
>> +
>> +SRCS	:= $(START-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
>> +OBJS	:= $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
>> +START	:= $(addprefix $(obj),$(START-y))
>>  
>>  all:	$(obj).depend $(START) $(LIB)
> 
> I cannot see any correlation between your commit message and the
> actual changes???
> 
> 
> NAK.
> 
> Best regards,
> 
> Wolfgang Denk

Actually, I've already slipped this one in through the u-boot-fdt 
repository (I took the liberty since it was a problem with fdt.o and 
CONFIG_OF_LIBFDT).

<http://article.gmane.org/gmane.comp.boot-loaders.u-boot/39261/>

The problem is that only a couple of 8xx boards are using libfdt, but 
they were *all* compiling fdt.c.  The result for the boards that did not 
have CONFIG_OF_LIBFDT was the compilation warnings on the (erroneously 
compiled) fdt.c.

I had fixed it independently, but Jean-Christophe's fix was better (more 
complete), so I dropped my patch and picked up his.

Best regards,
gvb



From david at gibson.dropbear.id.au  Wed Apr  9 02:41:13 2008
From: david at gibson.dropbear.id.au (David Gibson)
Date: Wed, 9 Apr 2008 10:41:13 +1000
Subject: [U-Boot-Users] FIS DTC
In-Reply-To: <5342.8362-30247-262363595-1207633054@seznam.cz>
References: <20080408043216.GD18501@localhost.localdomain>
	<5342.8362-30247-262363595-1207633054@seznam.cz>
Message-ID: <20080409004113.GB8092@localhost.localdomain>

On Tue, Apr 08, 2008 at 07:37:35AM +0200, Michal Simek wrote:
> Hi David,
> 
> >The /incbin/ is probably the problem.  Support for binary includes has
> >been suggested, and patches have floated around, but it hasn't yet
> >been merged into dtc mainline.
> 
> :-( Do you have any floated version?

I don't have the patches ready to hand, I'm afraid.  I do mean to get
the feature merged, but I'm not happy with how it's implemented right
now, and have only been slowly getting to the pieces we need for a
version I'd be happy with.  Plus jdl appears not to have had a lot of
time to spend on dtc lately.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson



From vapier at gentoo.org  Wed Apr  9 08:06:22 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:06:22 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: fix up UART status bit
	handling
In-Reply-To: <1207721182-29697-1-git-send-email-vapier@gentoo.org>
References: <1207721182-29697-1-git-send-email-vapier@gentoo.org>
Message-ID: <1207721182-29697-2-git-send-email-vapier@gentoo.org>

Some Blackfin UARTs are read-to-clear while others are write-to-clear.
This can cause problems when we poll the LSR and then later try and handle
any errors detected.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 cpu/blackfin/serial.c |   72 ++++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 60 insertions(+), 12 deletions(-)

diff --git a/cpu/blackfin/serial.c b/cpu/blackfin/serial.c
index 0dfee51..6134474 100644
--- a/cpu/blackfin/serial.c
+++ b/cpu/blackfin/serial.c
@@ -35,6 +35,32 @@
 
 #include "serial.h"
 
+#ifdef CONFIG_DEBUG_SERIAL
+uint16_t cached_lsr[256];
+uint16_t cached_rbr[256];
+size_t cache_count;
+
+/* The LSR is read-to-clear on some parts, so we have to make sure status
+ * bits aren't inadvertently lost when doing various tests.
+ */
+static uint16_t uart_lsr_save;
+static uint16_t uart_lsr_read(void)
+{
+	uint16_t lsr = *pUART_LSR;
+	uart_lsr_save |= (lsr & (OE|PE|FE|BI));
+	return lsr | uart_lsr_save;
+}
+/* Just do the clear for everyone since it can't hurt. */
+static void uart_lsr_clear(void)
+{
+	uart_lsr_save = 0;
+	*pUART_LSR |= -1;
+}
+#else
+static inline uint16_t uart_lsr_read(void) { return *pUART_LSR; }
+static inline void uart_lsr_clear(void) { *pUART_LSR = -1; }
+#endif
+
 /* Symbol for our assembly to call. */
 void serial_set_baud(uint32_t baud)
 {
@@ -61,6 +87,12 @@ int serial_init(void)
 {
 	serial_initialize();
 	serial_setbrg();
+	uart_lsr_clear();
+#ifdef CONFIG_DEBUG_SERIAL
+	cache_count = 0;
+	memset(cached_lsr, 0x00, sizeof(cached_lsr));
+	memset(cached_rbr, 0x00, sizeof(cached_rbr));
+#endif
 	return 0;
 }
 
@@ -73,7 +105,7 @@ void serial_putc(const char c)
 	WATCHDOG_RESET();
 
 	/* wait for the hardware fifo to clear up */
-	while (!(*pUART_LSR & THRE))
+	while (!(uart_lsr_read() & THRE))
 		continue;
 
 	/* queue the character for transmission */
@@ -83,38 +115,54 @@ void serial_putc(const char c)
 	WATCHDOG_RESET();
 
 	/* wait for the byte to be shifted over the line */
-	while (!(*pUART_LSR & TEMT))
+	while (!(uart_lsr_read() & TEMT))
 		continue;
 }
 
 int serial_tstc(void)
 {
 	WATCHDOG_RESET();
-	return (*pUART_LSR & DR) ? 1 : 0;
+	return (uart_lsr_read() & DR) ? 1 : 0;
 }
 
 int serial_getc(void)
 {
-	uint16_t uart_lsr_val, uart_rbr_val;
+	uint16_t uart_rbr_val;
 
 	/* wait for data ! */
 	while (!serial_tstc())
 		continue;
 
-	/* clear the status and grab the new byte */
-	uart_lsr_val = *pUART_LSR;
+	/* grab the new byte */
 	uart_rbr_val = *pUART_RBR;
 
+#ifdef CONFIG_DEBUG_SERIAL
+	/* grab & clear the LSR */
+	uint16_t uart_lsr_val = uart_lsr_read();
+	uart_lsr_clear();
+
+	cached_lsr[cache_count] = uart_lsr_val;
+	cached_rbr[cache_count] = uart_rbr_val;
+	cache_count = (cache_count + 1) % ARRAY_SIZE(cached_lsr);
+
 	if (uart_lsr_val & (OE|PE|FE|BI)) {
-		/* Some parts are read-to-clear while others are
-		 * write-to-clear.  Just do the write for everyone
-		 * since it cant hurt (other than code size).
-		 */
-		*pUART_LSR = (OE|PE|FE|BI);
+		uint16_t dll, dlh;
+		printf("\n[SERIAL ERROR]\n");
+		ACCESS_LATCH();
+		dll = *pUART_DLL;
+		dlh = *pUART_DLH;
+		ACCESS_PORT_IER();
+		printf("\tDLL=0x%x DLH=0x%x\n", dll, dlh);
+		do {
+			--cache_count;
+			printf("\t%3i: RBR=0x%02x LSR=0x%02x\n", cache_count,
+				cached_rbr[cache_count], cached_lsr[cache_count]);
+		} while (cache_count > 0);
 		return -1;
 	}
+#endif
 
-	return uart_rbr_val & 0xFF;
+	return uart_rbr_val;
 }
 
 void serial_puts(const char *s)
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:06:21 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:06:21 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: make baud calculation more
	accurate
Message-ID: <1207721182-29697-1-git-send-email-vapier@gentoo.org>

We should use the algorithm in the Linux kernel so that the UART divisor
calculation is more accurate.  It also fixes problems on some picky UARTs
that have sampling anomalies.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 cpu/blackfin/serial.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cpu/blackfin/serial.h b/cpu/blackfin/serial.h
index 1f0f4b4..d268da5 100644
--- a/cpu/blackfin/serial.h
+++ b/cpu/blackfin/serial.h
@@ -179,7 +179,7 @@ static inline void serial_early_set_baud(uint32_t baud)
 	 * The +1 is to make sure we over sample just a little
 	 * rather than under sample the incoming signals.
 	 */
-	uint16_t divisor = (get_sclk() / (baud * 16)) + 1;
+	uint16_t divisor = (get_sclk() + (baud * 8)) / (baud * 16);
 
 	/* Set DLAB in LCR to Access DLL and DLH */
 	ACCESS_LATCH();
-- 
1.5.4.4




From monstr at seznam.cz  Wed Apr  9 08:11:57 2008
From: monstr at seznam.cz (Michal Simek)
Date: Wed, 09 Apr 2008 08:11:57 +0200
Subject: [U-Boot-Users] FIS DTC
In-Reply-To: <20080409004113.GB8092@localhost.localdomain>
References: <20080408043216.GD18501@localhost.localdomain>	<5342.8362-30247-262363595-1207633054@seznam.cz>
	<20080409004113.GB8092@localhost.localdomain>
Message-ID: <47FC5E2D.5070700@seznam.cz>

Thanks for your answers,

Michal Simek
www.monstr.eu

>> Hi David,
>>
>>> The /incbin/ is probably the problem.  Support for binary includes has
>>> been suggested, and patches have floated around, but it hasn't yet
>>> been merged into dtc mainline.
>> :-( Do you have any floated version?
> 
> I don't have the patches ready to hand, I'm afraid.  I do mean to get
> the feature merged, but I'm not happy with how it's implemented right
> now, and have only been slowly getting to the pieces we need for a
> version I'd be happy with.  Plus jdl appears not to have had a lot of
> time to spend on dtc lately.
> 



From vapier at gentoo.org  Wed Apr  9 08:12:15 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:12:15 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: punt unused
	page_descriptor_table_size definition
In-Reply-To: <1207721535-29847-1-git-send-email-vapier@gentoo.org>
References: <1207721535-29847-1-git-send-email-vapier@gentoo.org>
Message-ID: <1207721535-29847-2-git-send-email-vapier@gentoo.org>

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 include/asm-blackfin/cplb.h |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/include/asm-blackfin/cplb.h b/include/asm-blackfin/cplb.h
index 7aa712f..2b23e0a 100644
--- a/include/asm-blackfin/cplb.h
+++ b/include/asm-blackfin/cplb.h
@@ -1,7 +1,7 @@
 /*
  * cplb.h - defines for managing CPLB tables
  *
- * Copyright (c) 2002-2007 Analog Devices Inc.
+ * Copyright (c) 2002-2008 Analog Devices Inc.
  *
  * Licensed under the GPL-2 or later.
  */
@@ -73,9 +73,4 @@
 #define SDRAM_EBIU              (PAGE_SIZE_4MB | CPLB_WT | CPLB_L1_AOW | CPLB_USER_RD | CPLB_USER_WR | CPLB_SUPV_WR | CPLB_VALID | ANOMALY_05000158_WORKAROUND)
 #endif
 
-#if defined(CONFIG_BF561)
-#define page_descriptor_table_size (CONFIG_MEM_SIZE/4 + 1 + 4)	/* SDRAM +L1 + ASYNC_Memory */
-#else
-#define page_descriptor_table_size (CONFIG_MEM_SIZE/4 + 2)	/* SDRAM + L1 + ASYNC_Memory */
-#endif
 #endif				/* _CPLB_H */
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:12:14 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:12:14 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: fix up comment about
	CONFIG_BFIN_BOOT_MODE
Message-ID: <1207721535-29847-1-git-send-email-vapier@gentoo.org>

Looks like I missed one place in the BFIN_BOOT_MODE -> CONFIG_BFIN_BOOT_MODE.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 include/asm-blackfin/blackfin-config-pre.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/asm-blackfin/blackfin-config-pre.h b/include/asm-blackfin/blackfin-config-pre.h
index f2c44f7..93e95d6 100644
--- a/include/asm-blackfin/blackfin-config-pre.h
+++ b/include/asm-blackfin/blackfin-config-pre.h
@@ -1,7 +1,7 @@
 /*
  * blackfin-config-pre.h - common defines for Blackfin boards in config.h
  *
- * Copyright (c) 2007 Analog Devices Inc.
+ * Copyright (c) 2007-2008 Analog Devices Inc.
  *
  * Licensed under the GPL-2 or later.
  */
@@ -20,7 +20,7 @@
 #define CFG_BFIN_CMD_OTP         0x04
 #define CFG_BFIN_CMD_CACHE_DUMP  0x08
 
-/* Bootmode defines -- your config needs to select this via BFIN_BOOT_MODE.
+/* Bootmode defines -- your config needs to select this via CONFIG_BFIN_BOOT_MODE.
  * Depending on your cpu, some of these may not be valid, check your HRM.
  * The actual values here are meaningless as long as they're unique.
  */
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:17:10 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:17:10 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: punt mem_init.h since it is
	no longer used
Message-ID: <1207721831-32630-1-git-send-email-vapier@gentoo.org>

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 board/bf533-stamp/bf533-stamp.c |    1 -
 include/asm-blackfin/mem_init.h |  321 ---------------------------------------
 2 files changed, 0 insertions(+), 322 deletions(-)
 delete mode 100644 include/asm-blackfin/mem_init.h

diff --git a/board/bf533-stamp/bf533-stamp.c b/board/bf533-stamp/bf533-stamp.c
index c4dde92..5f139ae 100644
--- a/board/bf533-stamp/bf533-stamp.c
+++ b/board/bf533-stamp/bf533-stamp.c
@@ -26,7 +26,6 @@
  */
 
 #include <common.h>
-#include <asm/mem_init.h>
 #include <asm/io.h>
 #include "bf533-stamp.h"
 
diff --git a/include/asm-blackfin/mem_init.h b/include/asm-blackfin/mem_init.h
deleted file mode 100644
index cb448ad..0000000
--- a/include/asm-blackfin/mem_init.h
+++ /dev/null
@@ -1,321 +0,0 @@
-/*
- * U-boot - mem_init.h Header file for memory initialization
- *
- * Copyright (c) 2005-2007 Analog Devices Inc.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
- * MA 02110-1301 USA
- */
-
-#if (CONFIG_MEM_MT48LC16M16A2TG_75 || \
-	CONFIG_MEM_MT48LC64M4A2FB_7E || \
-	CONFIG_MEM_MT48LC16M8A2TG_75 || \
-	CONFIG_MEM_MT48LC8M16A2TG_7E || \
-	CONFIG_MEM_MT48LC8M32B2B5_7  || \
-	CONFIG_MEM_MT48LC32M8A2_75)
-
-	#if ( CONFIG_SCLK_HZ > 119402985 )
-		#define SDRAM_tRP	TRP_2
-		#define SDRAM_tRP_num	2
-		#define SDRAM_tRAS	TRAS_7
-		#define SDRAM_tRAS_num	7
-		#define SDRAM_tRCD	TRCD_2
-		#define SDRAM_tWR	TWR_2
-	#endif
-	#if ( CONFIG_SCLK_HZ > 104477612 ) && ( CONFIG_SCLK_HZ <= 119402985 )
-		#define SDRAM_tRP	TRP_2
-		#define SDRAM_tRP_num	2
-		#define SDRAM_tRAS	TRAS_6
-		#define SDRAM_tRAS_num	6
-		#define SDRAM_tRCD	TRCD_2
-		#define SDRAM_tWR	TWR_2
-	#endif
-	#if ( CONFIG_SCLK_HZ >  89552239 ) && ( CONFIG_SCLK_HZ <= 104477612 )
-		#define SDRAM_tRP	TRP_2
-		#define SDRAM_tRP_num	2
-		#define SDRAM_tRAS	TRAS_5
-		#define SDRAM_tRAS_num	5
-		#define SDRAM_tRCD	TRCD_2
-		#define SDRAM_tWR	TWR_2
-	#endif
-	#if ( CONFIG_SCLK_HZ >  74626866 ) && ( CONFIG_SCLK_HZ <=  89552239 )
-		#define SDRAM_tRP	TRP_2
-		#define SDRAM_tRP_num	2
-		#define SDRAM_tRAS	TRAS_4
-		#define SDRAM_tRAS_num	4
-		#define SDRAM_tRCD	TRCD_2
-		#define SDRAM_tWR	TWR_2
-	#endif
-	#if ( CONFIG_SCLK_HZ >  66666667 ) && ( CONFIG_SCLK_HZ <= 74626866 )
-		#define SDRAM_tRP	TRP_2
-		#define SDRAM_tRP_num	2
-		#define SDRAM_tRAS	TRAS_3
-		#define SDRAM_tRAS_num	3
-		#define SDRAM_tRCD	TRCD_2
-		#define SDRAM_tWR	TWR_2
-	#endif
-	#if ( CONFIG_SCLK_HZ >  59701493 ) && ( CONFIG_SCLK_HZ <= 66666667 )
-		#define SDRAM_tRP	TRP_1
-		#define SDRAM_tRP_num	1
-		#define SDRAM_tRAS	TRAS_3
-		#define SDRAM_tRAS_num	3
-		#define SDRAM_tRCD	TRCD_1
-		#define SDRAM_tWR	TWR_2
-	#endif
-	#if ( CONFIG_SCLK_HZ >  44776119 ) && ( CONFIG_SCLK_HZ <=  59701493 )
-		#define SDRAM_tRP	TRP_1
-		#define SDRAM_tRP_num	1
-		#define SDRAM_tRAS	TRAS_3
-		#define SDRAM_tRAS_num	3
-		#define SDRAM_tRCD	TRCD_1
-		#define SDRAM_tWR	TWR_2
-	#endif
-	#if ( CONFIG_SCLK_HZ >  29850746 ) && ( CONFIG_SCLK_HZ <=  44776119 )
-		#define SDRAM_tRP	TRP_1
-		#define SDRAM_tRP_num	1
-		#define SDRAM_tRAS	TRAS_2
-		#define SDRAM_tRAS_num	2
-		#define SDRAM_tRCD	TRCD_1
-		#define SDRAM_tWR	TWR_2
-	#endif
-	#if ( CONFIG_SCLK_HZ <=  29850746 )
-		#define SDRAM_tRP	TRP_1
-		#define SDRAM_tRP_num	1
-		#define SDRAM_tRAS	TRAS_1
-		#define SDRAM_tRAS_num	1
-		#define SDRAM_tRCD	TRCD_1
-		#define SDRAM_tWR	TWR_2
-	#endif
-#endif
-
-#if (CONFIG_MEM_MT48LC16M16A2TG_75)
-	/*SDRAM INFORMATION: */
-	#define SDRAM_Tref	64	/* Refresh period in milliseconds   */
-	#define SDRAM_NRA	8192	/* Number of row addresses in SDRAM */
-	#define SDRAM_CL	CL_3
-#endif
-
-#if (CONFIG_MEM_MT48LC64M4A2FB_7E)
-	/*SDRAM INFORMATION: */
-	#define SDRAM_Tref	64	/* Refresh period in milliseconds   */
-	#define SDRAM_NRA	8192	/* Number of row addresses in SDRAM */
-	#define SDRAM_CL	CL_2
-#endif
-
-#if (CONFIG_MEM_MT48LC16M8A2TG_75)
-	/*SDRAM INFORMATION: */
-	#define SDRAM_Tref      64	/* Refresh period in milliseconds   */
-	#define SDRAM_NRA       4096	/* Number of row addresses in SDRAM */
-	#define SDRAM_CL        CL_3
-#endif
-
-#if (CONFIG_MEM_MT48LC32M8A2_75)
-/*SDRAM INFORMATION: */
-#define SDRAM_Tref  64			/* Refresh period in milliseconds   */
-#define SDRAM_NRA   8192		/* Number of row addresses in SDRAM */
-#define SDRAM_CL    CL_3
-#endif
-
-#if (CONFIG_MEM_MT48LC8M16A2TG_7E)
-	/*SDRAM INFORMATION: */
-	#define SDRAM_Tref	64	/* Refresh period in milliseconds   */
-	#define SDRAM_NRA	4096	/* Number of row addresses in SDRAM */
-	#define SDRAM_CL	CL_2
-#endif
-
-#if (CONFIG_MEM_MT48LC8M32B2B5_7)
-	/*SDRAM INFORMATION: */
-	#define SDRAM_Tref	64	/* Refresh period in milliseconds   */
-	#define SDRAM_NRA	4096	/* Number of row addresses in SDRAM */
-	#define SDRAM_CL	CL_3
-#endif
-
-#if ( CONFIG_MEM_SIZE == 128 )
-	#define SDRAM_SIZE	EBSZ_128
-#endif
-#if ( CONFIG_MEM_SIZE == 64 )
-	#define SDRAM_SIZE	EBSZ_64
-#endif
-#if (  CONFIG_MEM_SIZE == 32 )
-	#define SDRAM_SIZE	EBSZ_32
-#endif
-#if ( CONFIG_MEM_SIZE == 16 )
-	#define SDRAM_SIZE	EBSZ_16
-#endif
-#if ( CONFIG_MEM_ADD_WDTH == 11 )
-	#define SDRAM_WIDTH	EBCAW_11
-#endif
-#if ( CONFIG_MEM_ADD_WDTH == 10 )
-	#define SDRAM_WIDTH	EBCAW_10
-#endif
-#if ( CONFIG_MEM_ADD_WDTH == 9 )
-	#define SDRAM_WIDTH	EBCAW_9
-#endif
-#if ( CONFIG_MEM_ADD_WDTH == 8 )
-	#define SDRAM_WIDTH	EBCAW_8
-#endif
-
-#define mem_SDBCTL	SDRAM_WIDTH | SDRAM_SIZE | EBE
-
-/* Equation from section 17 (p17-46) of BF533 HRM */
-#define mem_SDRRC	((( CONFIG_SCLK_HZ / 1000) * SDRAM_Tref)  / SDRAM_NRA) - (SDRAM_tRAS_num + SDRAM_tRP_num)
-
-/* Enable SCLK Out */
-#define mem_SDGCTL	( SCTLE | SDRAM_CL | SDRAM_tRAS | SDRAM_tRP | SDRAM_tRCD | SDRAM_tWR | PSS )
-
-#define flash_EBIU_AMBCTL_WAT	( ( CONFIG_FLASH_SPEED_BWAT * 4 )  / ( 4000000000 / CONFIG_SCLK_HZ ) ) + 1
-#define flash_EBIU_AMBCTL_RAT	( ( CONFIG_FLASH_SPEED_BRAT * 4 )  / ( 4000000000 / CONFIG_SCLK_HZ ) ) + 1
-#define flash_EBIU_AMBCTL_HT	( ( CONFIG_FLASH_SPEED_BHT  * 4 )  / ( 4000000000 / CONFIG_SCLK_HZ ) )
-#define flash_EBIU_AMBCTL_ST	( ( CONFIG_FLASH_SPEED_BST  * 4 )  / ( 4000000000 / CONFIG_SCLK_HZ ) ) + 1
-#define flash_EBIU_AMBCTL_TT	( ( CONFIG_FLASH_SPEED_BTT  * 4 )  / ( 4000000000 / CONFIG_SCLK_HZ ) ) + 1
-
-#if (flash_EBIU_AMBCTL_TT > 3 )
-	#define flash_EBIU_AMBCTL0_TT	B0TT_4
-#endif
-#if (flash_EBIU_AMBCTL_TT == 3 )
-	#define flash_EBIU_AMBCTL0_TT	B0TT_3
-#endif
-#if (flash_EBIU_AMBCTL_TT == 2 )
-	#define flash_EBIU_AMBCTL0_TT	B0TT_2
-#endif
-#if (flash_EBIU_AMBCTL_TT < 2 )
-	#define flash_EBIU_AMBCTL0_TT	B0TT_1
-#endif
-
-#if (flash_EBIU_AMBCTL_ST > 3 )
-	#define flash_EBIU_AMBCTL0_ST	B0ST_4
-#endif
-#if (flash_EBIU_AMBCTL_ST == 3 )
-	#define flash_EBIU_AMBCTL0_ST	B0ST_3
-#endif
-#if (flash_EBIU_AMBCTL_ST == 2 )
-	#define flash_EBIU_AMBCTL0_ST	B0ST_2
-#endif
-#if (flash_EBIU_AMBCTL_ST < 2 )
-	#define flash_EBIU_AMBCTL0_ST	B0ST_1
-#endif
-
-#if (flash_EBIU_AMBCTL_HT > 2 )
-	#define flash_EBIU_AMBCTL0_HT	B0HT_3
-#endif
-#if (flash_EBIU_AMBCTL_HT == 2 )
-	#define flash_EBIU_AMBCTL0_HT	B0HT_2
-#endif
-#if (flash_EBIU_AMBCTL_HT == 1 )
-	#define flash_EBIU_AMBCTL0_HT	B0HT_1
-#endif
-#if (flash_EBIU_AMBCTL_HT == 0  && CONFIG_FLASH_SPEED_BHT == 0)
-	#define flash_EBIU_AMBCTL0_HT	B0HT_0
-#endif
-#if (flash_EBIU_AMBCTL_HT == 0  && CONFIG_FLASH_SPEED_BHT != 0)
-	#define flash_EBIU_AMBCTL0_HT	B0HT_1
-#endif
-
-#if (flash_EBIU_AMBCTL_WAT > 14)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_15
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 14)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_14
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 13)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_13
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 12)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_12
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 11)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_11
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 10)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_10
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 9)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_9
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 8)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_8
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 7)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_7
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 6)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_6
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 5)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_5
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 4)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_4
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 3)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_3
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 2)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_2
-#endif
-#if (flash_EBIU_AMBCTL_WAT == 1)
-	#define flash_EBIU_AMBCTL0_WAT	B0WAT_1
-#endif
-
-#if (flash_EBIU_AMBCTL_RAT > 14)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_15
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 14)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_14
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 13)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_13
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 12)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_12
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 11)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_11
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 10)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_10
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 9)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_9
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 8)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_8
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 7)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_7
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 6)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_6
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 5)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_5
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 4)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_4
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 3)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_3
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 2)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_2
-#endif
-#if (flash_EBIU_AMBCTL_RAT == 1)
-	#define flash_EBIU_AMBCTL0_RAT	B0RAT_1
-#endif
-
-#define flash_EBIU_AMBCTL0	flash_EBIU_AMBCTL0_WAT | flash_EBIU_AMBCTL0_RAT | flash_EBIU_AMBCTL0_HT | flash_EBIU_AMBCTL0_ST | flash_EBIU_AMBCTL0_TT | CONFIG_FLASH_SPEED_RDYEN
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:17:11 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:17:11 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: update cpu header
	definitions from latest Blackfin toolchain
In-Reply-To: <1207721831-32630-1-git-send-email-vapier@gentoo.org>
References: <1207721831-32630-1-git-send-email-vapier@gentoo.org>
Message-ID: <1207721831-32630-2-git-send-email-vapier@gentoo.org>

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 cpu/blackfin/initcode.c                         |    2 +-
 include/asm-blackfin/mach-common/bits/bootrom.h |   11 ++++
 include/asm-blackfin/mach-common/bits/ebiu.h    |    2 +-
 include/asm-blackfin/mach-common/bits/lockbox.h |   68 +++++++++++-----------
 4 files changed, 47 insertions(+), 36 deletions(-)

diff --git a/cpu/blackfin/initcode.c b/cpu/blackfin/initcode.c
index ffc8420..0fa3e53 100644
--- a/cpu/blackfin/initcode.c
+++ b/cpu/blackfin/initcode.c
@@ -212,7 +212,7 @@ static inline void serial_putc(char c)
 # define CONFIG_VR_CTL_VAL (CONFIG_VR_CTL_CLKBUF | CONFIG_VR_CTL_VLEV | CONFIG_VR_CTL_FREQ)
 #endif
 
-__attribute__((saveall))
+BOOTROM_CALLED_FUNC_ATTR
 void initcode(ADI_BOOT_DATA *bootstruct)
 {
 	uint32_t old_baud = serial_init();
diff --git a/include/asm-blackfin/mach-common/bits/bootrom.h b/include/asm-blackfin/mach-common/bits/bootrom.h
index 6cdaa4f..bf661f0 100644
--- a/include/asm-blackfin/mach-common/bits/bootrom.h
+++ b/include/asm-blackfin/mach-common/bits/bootrom.h
@@ -88,6 +88,8 @@
 #define _BOOTROM_REV                   0xEF000040
 #define _BOOTROM_SESR                  0xEF001000
 
+#define BOOTROM_FOLLOWS_C_ABI 1
+
 #define BOOTROM_CAPS_ADI_BOOT_STRUCTS 1
 
 /* Not available on initial BF54x or BF52x */
@@ -100,6 +102,9 @@
 
 #endif
 
+#ifndef BOOTROM_FOLLOWS_C_ABI
+#define BOOTROM_FOLLOWS_C_ABI 0
+#endif
 #ifndef BOOTROM_CAPS_ADI_BOOT_STRUCTS
 #define BOOTROM_CAPS_ADI_BOOT_STRUCTS 0
 #endif
@@ -109,6 +114,12 @@
 
 #ifndef __ASSEMBLY__
 
+#if BOOTROM_FOLLOWS_C_ABI
+# define BOOTROM_CALLED_FUNC_ATTR
+#else
+# define BOOTROM_CALLED_FUNC_ATTR __attribute__((saveall))
+#endif
+
 /* Structures for the syscontrol() function */
 typedef struct ADI_SYSCTRL_VALUES {
 	uint16_t uwVrCtl;
diff --git a/include/asm-blackfin/mach-common/bits/ebiu.h b/include/asm-blackfin/mach-common/bits/ebiu.h
index ab530ad..195ec90 100644
--- a/include/asm-blackfin/mach-common/bits/ebiu.h
+++ b/include/asm-blackfin/mach-common/bits/ebiu.h
@@ -343,7 +343,7 @@
 #define TWR_3		0x00180000	/* SDRAM tWR = 3 cycles */
 #define PUPSD		0x00200000	/* Power-up start delay */
 #define PSM		0x00400000	/* SDRAM power-up sequence = Precharge, mode register set, 8 CBR refresh cycles */
-#define PSS		0x00800000	/* enable SDRAM power-up sequence on next SDRAM access */
+#define PSSE		0x00800000	/* enable SDRAM power-up sequence on next SDRAM access */
 #define SRFS		0x01000000	/* Start SDRAM self-refresh mode */
 #define EBUFE		0x02000000	/* Enable external buffering timing */
 #define FBBRW		0x04000000	/* Fast back-to-back read write enable */
diff --git a/include/asm-blackfin/mach-common/bits/lockbox.h b/include/asm-blackfin/mach-common/bits/lockbox.h
index 8b696f3..09310e1 100644
--- a/include/asm-blackfin/mach-common/bits/lockbox.h
+++ b/include/asm-blackfin/mach-common/bits/lockbox.h
@@ -11,14 +11,14 @@
 
 /* SESR argument structure. Expected to reside at 0xFF900018. */
 typedef struct SESR_args {
-	unsigned short usFlags;		/* security firmware flags		*/
-	unsigned short usIRQMask;	/* interrupt mask			*/
-	unsigned long ulMessageSize;	/* message length in bytes		*/
-	unsigned long ulSFEntryPoint;	/* entry point of secure function	*/
-	unsigned long ulMessagePtr;	/* pointer to the buffer containing	*/
-					/* the digital signature and message	*/
-	unsigned long ulReserved1;	/* reserved				*/
-	unsigned long ulReserved2;	/* reserved				*/
+  unsigned short  usFlags;            /* security firmware flags            */
+  unsigned short  usIRQMask;          /* interrupt mask                     */
+  unsigned long   ulMessageSize;      /* message length in bytes            */
+  unsigned long   ulSFEntryPoint;     /* entry point of secure function     */
+  unsigned long   ulMessagePtr;       /* pointer to the buffer containing
+                                         the digital signature and message  */
+  unsigned long   ulReserved1;        /* reserved                           */
+  unsigned long   ulReserved2;        /* reserved                           */
 } tSESR_args;
 
 /* Secure Entry Service Routine */
@@ -26,37 +26,37 @@ void (* const sesr)(void) = (void *)_BOOTROM_SESR;
 
 #endif
 
-/* SESR flags argument bitfields					    */
-#define SESR_FLAGS_STAY_AT_NMI		    0x0000
-#define SESR_FLAGS_DROP_BELOW_NMI	    0x0001
-#define SESR_FLAGS_NO_SF_DMA		    0x0000
-#define SESR_FLAGS_DMA_SF_TO_RUN_DEST	    0x0002
-#define SESR_FLAGS_USE_ADI_PUB_KEY	    0x0000
-#define SESR_FLAGS_USE_CUST_PUB_KEY	    0x0100
+/* SESR flags argument bitfields                                            */
+#define SESR_FLAGS_STAY_AT_NMI              0x0000
+#define SESR_FLAGS_DROP_BELOW_NMI           0x0001
+#define SESR_FLAGS_NO_SF_DMA                0x0000
+#define SESR_FLAGS_DMA_SF_TO_RUN_DEST       0x0002
+#define SESR_FLAGS_USE_ADI_PUB_KEY          0x0000
+#define SESR_FLAGS_USE_CUST_PUB_KEY         0x0100
 
 /* Bit masks for SECURE_SYSSWT */
-#define EMUDABL		       0x00000001    /* Emulation Disable */
-#define RSTDABL		       0x00000002    /* Reset Disable */
-#define L1IDABL		       0x0000001c    /* L1 Instruction Memory Disable */
-#define L1DADABL	       0x000000e0    /* L1 Data Bank A Memory Disable */
-#define L1DBDABL	       0x00000700    /* L1 Data Bank B Memory Disable */
-#define DMA0OVR		       0x00000800    /* DMA0 Memory Access Override */
-#define DMA1OVR		       0x00001000    /* DMA1 Memory Access Override */
-#define EMUOVR		       0x00004000    /* Emulation Override */
-#define OTPSEN		       0x00008000    /* OTP Secrets Enable */
-#define L2DABL		       0x00070000    /* L2 Memory Disable */
+#define EMUDABL                0x00000001    /* Emulation Disable */
+#define RSTDABL                0x00000002    /* Reset Disable */
+#define L1IDABL                0x0000001c    /* L1 Instruction Memory Disable */
+#define L1DADABL               0x000000e0    /* L1 Data Bank A Memory Disable */
+#define L1DBDABL               0x00000700    /* L1 Data Bank B Memory Disable */
+#define DMA0OVR                0x00000800    /* DMA0 Memory Access Override */
+#define DMA1OVR                0x00001000    /* DMA1 Memory Access Override */
+#define EMUOVR                 0x00004000    /* Emulation Override */
+#define OTPSEN                 0x00008000    /* OTP Secrets Enable */
+#define L2DABL                 0x00070000    /* L2 Memory Disable */
 
 /* Bit masks for SECURE_CONTROL */
-#define SECURE0		       0x0001	     /* SECURE 0 */
-#define SECURE1		       0x0002	     /* SECURE 1 */
-#define SECURE2		       0x0004	     /* SECURE 2 */
-#define SECURE3		       0x0008	     /* SECURE 3 */
+#define SECURE0                0x0001        /* SECURE 0 */
+#define SECURE1                0x0002        /* SECURE 1 */
+#define SECURE2                0x0004        /* SECURE 2 */
+#define SECURE3                0x0008        /* SECURE 3 */
 
 /* Bit masks for SECURE_STATUS */
-#define SECMODE		       0x0003	     /* Secured Mode Control State */
-#define NMI		       0x0004	     /* Non Maskable Interrupt */
-#define AFVALID		       0x0008	     /* Authentication Firmware Valid */
-#define AFEXIT		       0x0010	     /* Authentication Firmware Exit */
-#define SECSTAT		       0x00e0	     /* Secure Status */
+#define SECMODE                0x0003        /* Secured Mode Control State */
+#define NMI                    0x0004        /* Non Maskable Interrupt */
+#define AFVALID                0x0008        /* Authentication Firmware Valid */
+#define AFEXIT                 0x0010        /* Authentication Firmware Exit */
+#define SECSTAT                0x00e0        /* Secure Status */
 
 #endif
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:33:15 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:33:15 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: punt unused BF533-STAMP
	definitions
Message-ID: <1207722800-3978-1-git-send-email-vapier@gentoo.org>

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 board/bf533-stamp/bf533-stamp.h |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/board/bf533-stamp/bf533-stamp.h b/board/bf533-stamp/bf533-stamp.h
index 1e58e47..0f37b83 100644
--- a/board/bf533-stamp/bf533-stamp.h
+++ b/board/bf533-stamp/bf533-stamp.h
@@ -34,9 +34,6 @@ extern volatile unsigned long *ambctl0;
 extern volatile unsigned long *ambctl1;
 extern volatile unsigned long *amgctl;
 
-extern unsigned long pll_div_fact;
-extern void serial_setbrg(void);
-
 /* Definitions used in  Compact Flash Boot support */
 #define FIO_EDGE_CF_BITS 	0x0000
 #define FIO_POLAR_CF_BITS 	0x0000
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:33:16 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:33:16 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: resurrect BF533-STAMP video
	splash driver
In-Reply-To: <1207722800-3978-1-git-send-email-vapier@gentoo.org>
References: <1207722800-3978-1-git-send-email-vapier@gentoo.org>
Message-ID: <1207722800-3978-2-git-send-email-vapier@gentoo.org>

This video driver used to live in the Blackfin cpu directory, but it was
lost during the unification process.  This brings it back.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 board/bf533-stamp/Makefile |    4 +-
 board/bf533-stamp/video.c  |  276 ++++++++++++++++++++++++++++++++++++++++++++
 board/bf533-stamp/video.h  |   25 ++++
 3 files changed, 303 insertions(+), 2 deletions(-)
 create mode 100644 board/bf533-stamp/video.c
 create mode 100644 board/bf533-stamp/video.h

diff --git a/board/bf533-stamp/Makefile b/board/bf533-stamp/Makefile
index 1115df8..a759d9a 100644
--- a/board/bf533-stamp/Makefile
+++ b/board/bf533-stamp/Makefile
@@ -1,7 +1,7 @@
 #
 # U-boot - Makefile
 #
-# Copyright (c) 2005-2007 Analog Device Inc.
+# Copyright (c) 2005-2008 Analog Device Inc.
 #
 # (C) Copyright 2000-2006
 # Wolfgang Denk, DENX Software Engineering, wd at denx.de.
@@ -29,7 +29,7 @@ include $(TOPDIR)/config.mk
 
 LIB	= $(obj)lib$(BOARD).a
 
-COBJS	:= $(BOARD).o spi_flash.o
+COBJS	:= $(BOARD).o spi_flash.o video.o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS))
diff --git a/board/bf533-stamp/video.c b/board/bf533-stamp/video.c
new file mode 100644
index 0000000..6899930
--- /dev/null
+++ b/board/bf533-stamp/video.c
@@ -0,0 +1,276 @@
+/*
+ * (C) Copyright 2000
+ * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio at tin.it
+ * (C) Copyright 2002
+ * Wolfgang Denk, wd at denx.de
+ * (C) Copyright 2006
+ * Aubrey Li, aubrey.li at analog.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <stdarg.h>
+#include <common.h>
+#include <config.h>
+#include <malloc.h>
+#include <asm/blackfin.h>
+#include <asm/mach-common/bits/dma.h>
+#include <i2c.h>
+#include <linux/types.h>
+#include <devices.h>
+
+int gunzip(void *, int, unsigned char *, unsigned long *);
+
+#ifdef CONFIG_VIDEO
+
+#define DMA_SIZE16	2
+
+#include <asm/mach-common/bits/ppi.h>
+
+#define NTSC_FRAME_ADDR 0x06000000
+#include "video.h"
+
+/* NTSC OUTPUT SIZE  720 * 240 */
+#define VERTICAL	2
+#define HORIZONTAL	4
+
+int is_vblank_line(const int line)
+{
+	/*
+	 *  This array contains a single bit for each line in
+	 *  an NTSC frame.
+	 */
+	if ((line <= 18) || (line >= 264 && line <= 281) || (line == 528))
+		return true;
+
+	return false;
+}
+
+int NTSC_framebuffer_init(char *base_address)
+{
+	const int NTSC_frames = 1;
+	const int NTSC_lines = 525;
+	char *dest = base_address;
+	int frame_num, line_num;
+
+	for (frame_num = 0; frame_num < NTSC_frames; ++frame_num) {
+		for (line_num = 1; line_num <= NTSC_lines; ++line_num) {
+			unsigned int code;
+			int offset = 0;
+			int i;
+
+			if (is_vblank_line(line_num))
+				offset++;
+
+			if (line_num > 266 || line_num < 3)
+				offset += 2;
+
+			/* Output EAV code */
+			code = SystemCodeMap[offset].EAV;
+			write_dest_byte((char)(code >> 24) & 0xff);
+			write_dest_byte((char)(code >> 16) & 0xff);
+			write_dest_byte((char)(code >> 8) & 0xff);
+			write_dest_byte((char)(code) & 0xff);
+
+			/* Output horizontal blanking */
+			for (i = 0; i < 67 * 2; ++i) {
+				write_dest_byte(0x80);
+				write_dest_byte(0x10);
+			}
+
+			/* Output SAV */
+			code = SystemCodeMap[offset].SAV;
+			write_dest_byte((char)(code >> 24) & 0xff);
+			write_dest_byte((char)(code >> 16) & 0xff);
+			write_dest_byte((char)(code >> 8) & 0xff);
+			write_dest_byte((char)(code) & 0xff);
+
+			/* Output empty horizontal data */
+			for (i = 0; i < 360 * 2; ++i) {
+				write_dest_byte(0x80);
+				write_dest_byte(0x10);
+			}
+		}
+	}
+
+	return dest - base_address;
+}
+
+void fill_frame(char *Frame, int Value)
+{
+	int *OddPtr32;
+	int OddLine;
+	int *EvenPtr32;
+	int EvenLine;
+	int i;
+	int *data;
+	int m, n;
+
+	/* fill odd and even frames */
+	for (OddLine = 22, EvenLine = 285; OddLine < 263; OddLine++, EvenLine++) {
+		OddPtr32 = (int *)((Frame + (OddLine * 1716)) + 276);
+		EvenPtr32 = (int *)((Frame + (EvenLine * 1716)) + 276);
+		for (i = 0; i < 360; i++, OddPtr32++, EvenPtr32++) {
+			*OddPtr32 = Value;
+			*EvenPtr32 = Value;
+		}
+	}
+
+	for (m = 0; m < VERTICAL; m++) {
+		data = (int *)u_boot_logo.data;
+		for (OddLine = (22 + m), EvenLine = (285 + m);
+		     OddLine < (u_boot_logo.height * VERTICAL) + (22 + m);
+		     OddLine += VERTICAL, EvenLine += VERTICAL) {
+			OddPtr32 = (int *)((Frame + ((OddLine) * 1716)) + 276);
+			EvenPtr32 =
+			    (int *)((Frame + ((EvenLine) * 1716)) + 276);
+			for (i = 0; i < u_boot_logo.width / 2; i++) {
+				/* enlarge one pixel to m x n */
+				for (n = 0; n < HORIZONTAL; n++) {
+					*OddPtr32++ = *data;
+					*EvenPtr32++ = *data;
+				}
+				data++;
+			}
+		}
+	}
+}
+
+static int video_init(void)
+{
+	char *NTSCFrame;
+	NTSCFrame = (char *)NTSC_FRAME_ADDR;
+	NTSC_framebuffer_init(NTSCFrame);
+	fill_frame(NTSCFrame, BLUE);
+
+	*pPPI_CONTROL = 0x0082;
+	*pPPI_FRAME = 0x020D;
+
+	*pDMA0_START_ADDR = NTSCFrame;
+	*pDMA0_X_COUNT = 0x035A;
+	*pDMA0_X_MODIFY = 0x0002;
+	*pDMA0_Y_COUNT = 0x020D;
+	*pDMA0_Y_MODIFY = 0x0002;
+	*pDMA0_CONFIG = 0x1015;
+	*pPPI_CONTROL = 0x0083;
+	return 0;
+}
+
+static void dma_bitblit(void *dst, fastimage_t *logo, int x, int y)
+{
+	if (dcache_status())
+		blackfin_dcache_flush_range(logo->data, logo->data + logo->size);
+
+	bfin_write_MDMA_D0_IRQ_STATUS(DMA_DONE | DMA_ERR);
+
+	/* Setup destination start address */
+	bfin_write_MDMA_D0_START_ADDR(dst + ((x & -2) * LCD_PIXEL_SIZE)
+					+ (y * LCD_X_RES * LCD_PIXEL_SIZE));
+	/* Setup destination xcount */
+	bfin_write_MDMA_D0_X_COUNT(logo->width * LCD_PIXEL_SIZE / DMA_SIZE16);
+	/* Setup destination xmodify */
+	bfin_write_MDMA_D0_X_MODIFY(DMA_SIZE16);
+
+	/* Setup destination ycount */
+	bfin_write_MDMA_D0_Y_COUNT(logo->height);
+	/* Setup destination ymodify */
+	bfin_write_MDMA_D0_Y_MODIFY((LCD_X_RES - logo->width) * LCD_PIXEL_SIZE + DMA_SIZE16);
+
+
+	/* Setup Source start address */
+	bfin_write_MDMA_S0_START_ADDR(logo->data);
+	/* Setup Source xcount */
+	bfin_write_MDMA_S0_X_COUNT(logo->width * LCD_PIXEL_SIZE / DMA_SIZE16);
+	/* Setup Source xmodify */
+	bfin_write_MDMA_S0_X_MODIFY(DMA_SIZE16);
+
+	/* Setup Source ycount */
+	bfin_write_MDMA_S0_Y_COUNT(logo->height);
+	/* Setup Source ymodify */
+	bfin_write_MDMA_S0_Y_MODIFY(DMA_SIZE16);
+
+
+	/* Enable source DMA */
+	bfin_write_MDMA_S0_CONFIG(DMAEN | WDSIZE_16 | DMA2D);
+	SSYNC();
+	bfin_write_MDMA_D0_CONFIG(WNR | DMAEN  | WDSIZE_16 | DMA2D);
+
+	while (bfin_read_MDMA_D0_IRQ_STATUS() & DMA_RUN);
+
+	bfin_write_MDMA_S0_IRQ_STATUS(bfin_read_MDMA_S0_IRQ_STATUS() | DMA_DONE | DMA_ERR);
+	bfin_write_MDMA_D0_IRQ_STATUS(bfin_read_MDMA_D0_IRQ_STATUS() | DMA_DONE | DMA_ERR);
+
+}
+
+void video_putc(const char c)
+{
+}
+
+void video_puts(const char *s)
+{
+}
+
+int drv_video_init(void)
+{
+	int error, devices = 1;
+	device_t videodev;
+
+	u8 *dst;
+	u32 fbmem_size = LCD_X_RES * LCD_Y_RES * LCD_PIXEL_SIZE + ACTIVE_VIDEO_MEM_OFFSET;
+
+	dst = malloc(fbmem_size);
+
+	if (dst == NULL) {
+		printf("Failed to alloc FB memory\n");
+		return -1;
+	}
+
+#ifdef EASYLOGO_ENABLE_GZIP
+	unsigned char *data = EASYLOGO_DECOMP_BUFFER;
+	unsigned long src_len = EASYLOGO_ENABLE_GZIP;
+	if (gunzip(data, bfin_logo.size, bfin_logo.data, &src_len)) {
+		puts("Failed to decompress logo\n");
+		free(dst);
+		return -1;
+	}
+	bfin_logo.data = data;
+#endif
+
+	memset(dst + ACTIVE_VIDEO_MEM_OFFSET, bfin_logo.data[0], fbmem_size - ACTIVE_VIDEO_MEM_OFFSET);
+
+	dma_bitblit(dst + ACTIVE_VIDEO_MEM_OFFSET, &bfin_logo,
+			(LCD_X_RES - bfin_logo.width) / 2,
+			(LCD_Y_RES - bfin_logo.height) / 2);
+
+	video_init(dst);		/* Video initialization */
+
+	memset(&videodev, 0, sizeof(videodev));
+
+	strcpy(videodev.name, "video");
+	videodev.ext = DEV_EXT_VIDEO;	/* Video extensions */
+	videodev.flags = DEV_FLAGS_SYSTEM;	/* No Output */
+	videodev.putc = video_putc;	/* 'putc' function */
+	videodev.puts = video_puts;	/* 'puts' function */
+
+	error = device_register(&videodev);
+
+	return (error == 0) ? devices : error;
+}
+
+#endif
diff --git a/board/bf533-stamp/video.h b/board/bf533-stamp/video.h
new file mode 100644
index 0000000..d5a8bc8
--- /dev/null
+++ b/board/bf533-stamp/video.h
@@ -0,0 +1,25 @@
+#include <video_logo.h>
+#define write_dest_byte(val) {*dest++=val;}
+#define BLACK   (0x01800180)	/* black pixel pattern   */
+#define BLUE    (0x296E29F0)	/* blue pixel pattern    */
+#define RED     (0x51F0515A)	/* red pixel pattern     */
+#define MAGENTA (0x6ADE6ACA)	/* magenta pixel pattern */
+#define GREEN   (0x91229136)	/* green pixel pattern   */
+#define CYAN    (0xAA10AAA6)	/* cyan pixel pattern    */
+#define YELLOW  (0xD292D210)	/* yellow pixel pattern  */
+#define WHITE   (0xFE80FE80)	/* white pixel pattern   */
+
+#define true 	1
+#define false	0
+
+typedef struct {
+	unsigned int SAV;
+	unsigned int EAV;
+} SystemCodeType;
+
+const SystemCodeType SystemCodeMap[4] = {
+	{0xFF000080, 0xFF00009D},
+	{0xFF0000AB, 0xFF0000B6},
+	{0xFF0000C7, 0xFF0000DA},
+	{0xFF0000EC, 0xFF0000F1}
+};
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:33:19 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:33:19 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: kill conversion warnings in
	async nand driver
In-Reply-To: <1207722800-3978-4-git-send-email-vapier@gentoo.org>
References: <1207722800-3978-1-git-send-email-vapier@gentoo.org>
	<1207722800-3978-2-git-send-email-vapier@gentoo.org>
	<1207722800-3978-3-git-send-email-vapier@gentoo.org>
	<1207722800-3978-4-git-send-email-vapier@gentoo.org>
Message-ID: <1207722800-3978-5-git-send-email-vapier@gentoo.org>

Add "fun" casts from defined integers to pointers so that we don't have
to see the ugly associated conversion warnings from gcc.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 board/bf537-stamp/nand.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/bf537-stamp/nand.c b/board/bf537-stamp/nand.c
index 6ff0f4f..b6fa1a9 100644
--- a/board/bf537-stamp/nand.c
+++ b/board/bf537-stamp/nand.c
@@ -44,17 +44,17 @@ static void bfin_hwcontrol(struct mtd_info *mtd, int cmd)
 	switch (cmd) {
 
 	case NAND_CTL_SETCLE:
-		this->IO_ADDR_W = CFG_NAND_BASE + BFIN_NAND_CLE;
+		this->IO_ADDR_W = (void *)CFG_NAND_BASE + BFIN_NAND_CLE;
 		break;
 	case NAND_CTL_CLRCLE:
-		this->IO_ADDR_W = CFG_NAND_BASE;
+		this->IO_ADDR_W = (void *)CFG_NAND_BASE;
 		break;
 
 	case NAND_CTL_SETALE:
-		this->IO_ADDR_W = CFG_NAND_BASE + BFIN_NAND_ALE;
+		this->IO_ADDR_W = (void *)CFG_NAND_BASE + BFIN_NAND_ALE;
 		break;
 	case NAND_CTL_CLRALE:
-		this->IO_ADDR_W = CFG_NAND_BASE;
+		this->IO_ADDR_W = (void *)CFG_NAND_BASE;
 		break;
 	case NAND_CTL_SETNCE:
 	case NAND_CTL_CLRNCE:
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:33:17 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:33:17 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: touchup BF561-EZKIT board
	file
In-Reply-To: <1207722800-3978-2-git-send-email-vapier@gentoo.org>
References: <1207722800-3978-1-git-send-email-vapier@gentoo.org>
	<1207722800-3978-2-git-send-email-vapier@gentoo.org>
Message-ID: <1207722800-3978-3-git-send-email-vapier@gentoo.org>

Pull in a few more standard includes and drop the CPU banner line as
the common Blackfin code already handles this for us.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 board/bf561-ezkit/bf561-ezkit.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/bf561-ezkit/bf561-ezkit.c b/board/bf561-ezkit/bf561-ezkit.c
index d504217..0358c45 100644
--- a/board/bf561-ezkit/bf561-ezkit.c
+++ b/board/bf561-ezkit/bf561-ezkit.c
@@ -2,7 +2,7 @@
  * U-boot - ezkit561.c
  *
  * Copyright (c) 2005 Bas Vermeulen <bas at buyways.nl>
- * Copyright (c) 2005-2007 Analog Devices Inc.
+ * Copyright (c) 2005-2008 Analog Devices Inc.
  *
  * (C) Copyright 2000-2004
  * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
@@ -27,13 +27,15 @@
  */
 
 #include <common.h>
+#include <config.h>
+#include <command.h>
+#include <asm/blackfin.h>
 #include <asm/io.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
 int checkboard(void)
 {
-	printf("CPU:   ADSP BF561\n");
 	printf("Board: ADI BF561 EZ-Kit Lite board\n");
 	printf("       Support: http://blackfin.uclinux.org/\n");
 	return 0;
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:33:18 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:33:18 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: set default boot SPI CS for
	BF538/BF539
In-Reply-To: <1207722800-3978-3-git-send-email-vapier@gentoo.org>
References: <1207722800-3978-1-git-send-email-vapier@gentoo.org>
	<1207722800-3978-2-git-send-email-vapier@gentoo.org>
	<1207722800-3978-3-git-send-email-vapier@gentoo.org>
Message-ID: <1207722800-3978-4-git-send-email-vapier@gentoo.org>

The BF538/BF539 use CS2 for booting off of rather than CS1 like newer
Blackfin parts.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 board/bf537-stamp/spi_flash.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/bf537-stamp/spi_flash.c b/board/bf537-stamp/spi_flash.c
index 7c73ddd..10e4568 100644
--- a/board/bf537-stamp/spi_flash.c
+++ b/board/bf537-stamp/spi_flash.c
@@ -182,8 +182,8 @@ static struct manufacturer_info flash_manufacturers[] = {
  *	BF533, BF561: SSEL2
  */
 #ifndef CONFIG_SPI_FLASH_SSEL
-# if defined(__ADSPBF531__) || defined(__ADSPBF532__) || \
-     defined(__ADSPBF533__) || defined(__ADSPBF561__)
+# if defined(__ADSPBF531__) || defined(__ADSPBF532__) || defined(__ADSPBF533__) || \
+     defined(__ADSPBF538__) || defined(__ADSPBF539__) || defined(__ADSPBF561__)
 #  define CONFIG_SPI_FLASH_SSEL 2
 # else
 #  define CONFIG_SPI_FLASH_SSEL 1
-- 
1.5.4.4




From vapier at gentoo.org  Wed Apr  9 08:33:20 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed,  9 Apr 2008 02:33:20 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: tighten up post memory
	coding style
In-Reply-To: <1207722800-3978-5-git-send-email-vapier@gentoo.org>
References: <1207722800-3978-1-git-send-email-vapier@gentoo.org>
	<1207722800-3978-2-git-send-email-vapier@gentoo.org>
	<1207722800-3978-3-git-send-email-vapier@gentoo.org>
	<1207722800-3978-4-git-send-email-vapier@gentoo.org>
	<1207722800-3978-5-git-send-email-vapier@gentoo.org>
Message-ID: <1207722800-3978-6-git-send-email-vapier@gentoo.org>

No functional changes here; just cleanup code style a bit.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 board/bf537-stamp/post-memory.c |   23 +++++++++++------------
 1 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/board/bf537-stamp/post-memory.c b/board/bf537-stamp/post-memory.c
index fa11991..ee28e54 100644
--- a/board/bf537-stamp/post-memory.c
+++ b/board/bf537-stamp/post-memory.c
@@ -21,10 +21,10 @@ int post_init_sdram(int sclk);
 void post_init_uart(int sclk);
 
 const int pll[CCLK_NUM][SCLK_NUM][2] = {
-	{{20, 4}, {20, 5}, {20, 10}},	/* CCLK = 500M */
-	{{16, 4}, {16, 5}, {16, 8}},	/* CCLK = 400M */
-	{{8, 2}, {8, 4}, {8, 5}},	/* CCLK = 200M */
-	{{4, 1}, {4, 2}, {4, 4}}	/* CCLK = 100M */
+	{ {20, 4}, {20, 5}, {20, 10} },	/* CCLK = 500M */
+	{ {16, 4}, {16, 5}, {16, 8} },	/* CCLK = 400M */
+	{ {8, 2}, {8, 4}, {8, 5} },	/* CCLK = 200M */
+	{ {4, 1}, {4, 2}, {4, 4} }	/* CCLK = 100M */
 };
 const char *const log[CCLK_NUM][SCLK_NUM] = {
 	{"CCLK-500Mhz SCLK-125Mhz:    Writing...\0",
@@ -119,7 +119,8 @@ void post_out_buff(char *buff)
 {
 
 	int i = 0;
-	for (i = 0; i < 0x80000; i++) ;
+	for (i = 0; i < 0x80000; i++)
+		continue;
 	i = 0;
 	while ((buff[i] != '\0') && (i != 100)) {
 		while (!(*pUART_LSR & 0x20)) ;
@@ -127,7 +128,8 @@ void post_out_buff(char *buff)
 		SSYNC();
 		i++;
 	}
-	for (i = 0; i < 0x80000; i++) ;
+	for (i = 0; i < 0x80000; i++)
+		continue;
 }
 
 /* Using sw10-PF5 as the hotkey */
@@ -150,9 +152,8 @@ int post_key_pressed(void)
 			value = 0;
 			goto key_pressed;
 		}
-		if (value != 0) {
+		if (value != 0)
 			goto key_pressed;
-		}
 		for (n = 0; n < KEY_DELAY; n++)
 			asm("nop");
 	}
@@ -164,9 +165,8 @@ int post_key_pressed(void)
 			value = 0;
 			goto key_pressed;
 		}
-		if (value != 0) {
+		if (value != 0)
 			goto key_pressed;
-		}
 		for (n = 0; n < KEY_DELAY; n++)
 			asm("nop");
 	}
@@ -178,9 +178,8 @@ int post_key_pressed(void)
 			value = 0;
 			goto key_pressed;
 		}
-		if (value != 0) {
+		if (value != 0)
 			goto key_pressed;
-		}
 		for (n = 0; n < KEY_DELAY; n++)
 			asm("nop");
 	}
-- 
1.5.4.4




From tj_jac at yahoo.co.in  Wed Apr  9 09:10:19 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Wed, 9 Apr 2008 12:40:19 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup (s3c24xx)
Message-ID: <312458.52477.qm@web94605.mail.in2.yahoo.com>

Hi Herald,

>> We changed the memory clock to a lower frequency(90MHz to 67MHz) and
>> the the "Bad Data CRC" error has gone. Thanks alot.
>ok, this most likely means that you have some problems with your
>hardware design, probably exceeding the maximum permitted capacitive bus
>load.
>well, how do you copy the image into ram?  It doesn't really matter from
>where the image is copied.  What matters is that apparently the source
>of the copy is not equal to the destination of the copy.  Even if you
>copy 'directly' via JTAG there is a source and a destination.   and the
>destination will suffer through corruption if SDRAM timing or bus clock
>are wrong.

The settings for the UPLLCON and MPLLCON were being done for 16MHz external clock. Now we have changed that and made the settings for 12MHz clock(our board clock). Now, core is running at 271.5MHz, and the rest at 1:8:16 (FCLK:HCLK:PCLK).

Now we have managed to get the output as follows:

U-Boot 1.3.2 (Apr  9 2008 - 09:45:21)                                     

DRAM:  1      
Flash: 32 MB            
Using default environment                         

In:    serial             
Out:   serial             
Err:   serial             
Hit any key to stop autoboot:  3                                

U-Boot 1.3.2 (Apr  9 2008 - 09:45:21)

DRAM:  128 MB
Flash: 32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
## Booting image at 33000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    1167125 Bytes =  1.1 MB
   Load Address: 30008000
   Entry Point:  30008000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

Starting kernel ...

Uncompressing Linux..............................................................
................ done, booting the kernel.

and then it hangs. We are writing the kernel image directly to the ram to 33000000 via JTAG.
How do I proceed from here?


Thanks alot for your previous mails. It is helping us alot in debugging the hardware and softwares.

Thank You,
Tiju


      From Chandigarh to Chennai - find friends all over India. Go to http://in.promos.yahoo.com/groups/citygroups/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080409/9dec5ffe/attachment.htm 

From tj_jac at yahoo.co.in  Wed Apr  9 09:16:55 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Wed, 9 Apr 2008 12:46:55 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup (s3c24xx)
Message-ID: <232088.30191.qm@web94616.mail.in2.yahoo.com>

Hi Herald,

The environment variables are as follows:

DPB2440 # printenv
bootargs=root=ramfs devfs=mount console=ttyS0,115200
bootcmd=bootm
bootdelay=3
baudrate=115200
bootfile="uImage.bin"
stdin=serial
stdout=serial
stderr=serial

Thankyou,
Best Regards,
Tiju



      Bollywood, fun, friendship, sports and more. You name it, we have it on http://in.promos.yahoo.com/groups/bestofyahoo/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080409/6fc9c360/attachment.htm 

From wd at denx.de  Wed Apr  9 09:25:20 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 09 Apr 2008 09:25:20 +0200
Subject: [U-Boot-Users] [PATCH/review] Blackfin: tighten up post memory
	coding style
In-Reply-To: Your message of "Wed, 09 Apr 2008 02:33:20 EDT."
	<1207722800-3978-6-git-send-email-vapier@gentoo.org>
Message-ID: <20080409072520.2D5E9243AB@gemini.denx.de>

In message <1207722800-3978-6-git-send-email-vapier at gentoo.org> you wrote:
...
> -	for (i = 0; i < 0x80000; i++) ;
> +	for (i = 0; i < 0x80000; i++)
> +		continue;

We don't do this. If you want to make obvious that this is an empty
loop, please write it ias

	for (i = 0; i < 0x80000; i++) 
		;
	
But no "continue".

> -	for (i = 0; i < 0x80000; i++) ;
> +	for (i = 0; i < 0x80000; i++)
> +		continue;
>  }

Ditto.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Old programmers never die, they just branch to a new address.



From vishal.ok at gmail.com  Wed Apr  9 10:09:53 2008
From: vishal.ok at gmail.com (Vishal Oliyil Kunnil)
Date: Wed, 9 Apr 2008 13:39:53 +0530
Subject: [U-Boot-Users] Linux kernel startup (s3c24xx)
In-Reply-To: <312458.52477.qm@web94605.mail.in2.yahoo.com>
References: <312458.52477.qm@web94605.mail.in2.yahoo.com>
Message-ID: <c80340680804090109k752e5710i81f581161c78d026@mail.gmail.com>

Hi Tiju,

> and then it hangs. We are writing the kernel image directly to the ram to
> 33000000 via JTAG.

Writing kernel to RAM using JTAG is only a workaround ! I think it would be
better to fix whatever problems you currently have like (if at all you
have any) with memory
timing etc - ensure there is no memory corruption (unlikely because
u-boot seems
to run fine from RAM) happening by running built-in memory
test in u-boot; and then proceed with the kernel.

Regards,
Vishal



From plagnioj at jcrosoft.com  Wed Apr  9 10:46:35 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 9 Apr 2008 10:46:35 +0200
Subject: [U-Boot-Users] [U-boot] [PATCH 2/2] ds174x: Fix warning
	on	return in rtc_get and rtc_set function
In-Reply-To: <20080408210124.6713F24842@gemini.denx.de>
References: <1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
	<20080408210124.6713F24842@gemini.denx.de>
Message-ID: <20080409084635.GB28294@game.jcrosoft.org>

On 23:01 Tue 08 Apr     , Wolfgang Denk wrote:
> In message <1207116238-7253-3-git-send-email-plagnioj at jcrosoft.com> you wrote:
> > ds174x.c: In function 'rtc_get':
> > ds174x.c:117: warning: no return statement in function returning non-void
> > ds174x.c: In function 'rtc_set':
> > ds174x.c:146: warning: 'return' with a value, in function returning void
> > 
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> > 
> > diff --git a/drivers/rtc/ds174x.c b/drivers/rtc/ds174x.c
> > index 81a9cb3..eb3ca88 100644
> > --- a/drivers/rtc/ds174x.c
> > +++ b/drivers/rtc/ds174x.c
> > @@ -114,6 +114,7 @@ int rtc_get( struct rtc_time *tmp )
> >  		tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
> >  		tmp->tm_hour, tmp->tm_min, tmp->tm_sec );
> >  #endif
> > +	return 0;
> >  }
> >  
> >  void rtc_set( struct rtc_time *tmp )
> > @@ -142,8 +143,6 @@ void rtc_set( struct rtc_time *tmp )
> >  
> >  	/* unlock clock registers after read */
> >  	rtc_write( RTC_CONTROLA, ( reg_a  & ~RTC_CA_WRITE ));
> > -
> > -	return 0;
> >  }
> >  
> >  void rtc_reset (void)
> 
> I think this is actually not the right fix.
> 
> To make things right, both rtc_set() and rtc_get() should return
> "int".
> 
> Yes, I'm aware that this is far beyond the scope of your fixes here,
> but I wanted to at least note that.
> 
> Note that this is no NAK.
> 
I can add it in my task for this fix window or in the next merge windows

Best Regards,
J.



From galak at kernel.crashing.org  Wed Apr  9 11:20:57 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 9 Apr 2008 04:20:57 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx: Fix detection of MP cpu spin up
Message-ID: <Pine.LNX.4.64.0804090420320.17674@blarg.am.freescale.net>

We were looking at the wrong memory offset to determine of a secondary
cpu had been spun up or not.  Also added a warning message if the
all the secondary cpus we expect don't spin up.

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

This is a bug fix for 1.3.3.

- k

 cpu/mpc85xx/mp.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
index 7b10fba..e733f7b 100644
--- a/cpu/mpc85xx/mp.c
+++ b/cpu/mpc85xx/mp.c
@@ -154,7 +154,7 @@ static void pq3_mp_up(unsigned long bootpg)
 	while (timeout) {
 		int i;
 		for (i = 1; i < CONFIG_NR_CPUS; i++) {
-			if (table[i * NUM_BOOT_ENTRY])
+			if (table[i * NUM_BOOT_ENTRY + BOOT_ENTRY_ADDR_LOWER])
 				cpu_up_mask |= (1 << i);
 		};

@@ -165,6 +165,10 @@ static void pq3_mp_up(unsigned long bootpg)
 		timeout--;
 	}

+	if (timeout == 0)
+		printf("CPU up timeout. CPU up mask is %x should be %x\n",
+			cpu_up_mask, up);
+
 	/* enable time base at the platform */
 	if (whoami)
 		devdisr |= MPC85xx_DEVDISR_TB1;
-- 
1.5.4.1




From kenneth at southpole.se  Wed Apr  9 11:32:17 2008
From: kenneth at southpole.se (Kenneth Johansson)
Date: Wed, 09 Apr 2008 11:32:17 +0200
Subject: [U-Boot-Users] Fixup entries
Message-ID: <1207733537.6954.32.camel@localhost.localdomain>

What is the fixup section used for ?

of the 274 cards that build on my MAKEALL not one has any entries into
this section.






From sr at denx.de  Wed Apr  9 11:40:45 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 9 Apr 2008 11:40:45 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <044c01c899c2$abbb67b0$03323710$@Tjernlund@transmode.se>
References: <044901c899ba$83532450$89f96cf0$@Tjernlund@transmode.se>
	<20080408210920.56F3B24842@gemini.denx.de>
	<044c01c899c2$abbb67b0$03323710$@Tjernlund@transmode.se>
Message-ID: <200804091140.45661.sr@denx.de>

On Tuesday 08 April 2008, Joakim Tjernlund wrote:
> > > Anyhow, we can go with the other solution instead, define the symbol in
> > > start.S instead, if one is needed.
> >
> > If it cannot be avoided ;-)
>
> ... Stefan, maybe you can #define EXC_OFF_SYS_RESET for 405 to something
> that fits with my relocation patch?

Not sure if this could be done, since EXC_OFF_SYS_RESET is used for other 
things as well, and changing its value might bring other problems. And this 
really sounds like a bad hack, to change EXC_OFF_SYS_RESET to 
something "strange". So, no I don't want to fix this problem this way.

Since I'm really short in time currently, and I need U-Boot running on 4xx 
again, I vote for reverting this patch now. I'll try to come up with 
a "generic" solution for the next merge window.

Wolfgang? What do you think?

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Wed Apr  9 12:42:10 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 09 Apr 2008 12:42:10 +0200
Subject: [U-Boot-Users] [U-boot] [PATCH 2/2] ds174x: Fix warning on
	return in rtc_get and rtc_set function
In-Reply-To: Your message of "Wed, 09 Apr 2008 10:46:35 +0200."
	<20080409084635.GB28294@game.jcrosoft.org>
Message-ID: <20080409104210.174F924842@gemini.denx.de>

In message <20080409084635.GB28294 at game.jcrosoft.org> you wrote:
>
> > To make things right, both rtc_set() and rtc_get() should return
> > "int".
> > 
> > Yes, I'm aware that this is far beyond the scope of your fixes here,
> > but I wanted to at least note that.
> > 
> > Note that this is no NAK.
> > 
> I can add it in my task for this fix window or in the next merge windows

That would be great - next window, please. Thanks in advance.

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: wd at denx.de
Testing can show the presense of bugs, but not their absence.
                                                   -- Edsger Dijkstra



From wd at denx.de  Wed Apr  9 12:44:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 09 Apr 2008 12:44:00 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: Your message of "Wed, 09 Apr 2008 11:40:45 +0200."
	<200804091140.45661.sr@denx.de>
Message-ID: <20080409104400.D46C524842@gemini.denx.de>

In message <200804091140.45661.sr at denx.de> you wrote:
>
> Since I'm really short in time currently, and I need U-Boot running on 4xx 
> again, I vote for reverting this patch now. I'll try to come up with 
> a "generic" solution for the next merge window.
> 
> Wolfgang? What do you think?

I agree. This patch is too invasive at this point of the  development
cycle.  Please  revert  it.  We  will  handle  this in the next merge
window, then.

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: wd at denx.de
An Elephant is a mouse with an Operating System.              - Knuth



From sr at denx.de  Wed Apr  9 12:56:42 2008
From: sr at denx.de (Stefan Roese)
Date: Wed,  9 Apr 2008 12:56:42 +0200
Subject: [U-Boot-Users] [PATCH] ppc: Revert patch 70431e8a that used _start
	instead of CFG_MONITOR_BASE
Message-ID: <1207738602-23956-1-git-send-email-sr@denx.de>

The patch 70431e8a7393b6b793f77957f95b999fc9a269b8 (Make MPC83xx one step
closer to full relocation.) doesn't use CFG_MONITOR_BASE anymore. But
on 4xx systems _start currently cannot be used for this calculation.
So revert back to the original version for now.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 lib_ppc/board.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 7d33914..b2bc4eb 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -440,7 +440,7 @@ void board_init_f (ulong bootflag)
 	 *  - monitor code
 	 *  - board info struct
 	 */
-	len = (ulong)&_end - (ulong)&_start + EXC_OFF_SYS_RESET;
+	len = (ulong)&_end - CFG_MONITOR_BASE;
 
 	/*
 	 * Subtract specified amount of memory to hide so that it won't
-- 
1.5.5




From sr at denx.de  Wed Apr  9 12:57:00 2008
From: sr at denx.de (Stefan Roese)
Date: Wed,  9 Apr 2008 12:57:00 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Canyonlands default environment
	to work with new image support
Message-ID: <1207738620-23994-1-git-send-email-sr@denx.de>

Since the new image support checks for image overwriting, the default
environment needs to get adjusted to use correct addresses.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 include/configs/canyonlands.h |   12 +++++-------
 1 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
index a1c6674..be9432b 100644
--- a/include/configs/canyonlands.h
+++ b/include/configs/canyonlands.h
@@ -330,19 +330,17 @@
 		"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}"	\
 		":${hostname}:${netdev}:off panic=1\0"			\
 	"addtty=setenv bootargs ${bootargs} console=ttyS0,${baudrate}\0"\
-	"net_nfs=tftp 200000 ${bootfile};"				\
-		"run nfsargs addip addtty;"				\
-		"bootm 200000\0"					\
-	"net_nfs_fdt=tftp 200000 ${bootfile};"				\
+	"net_nfs=tftp 400000 ${bootfile};"				\
 		"tftp ${fdt_addr} ${fdt_file};"				\
 		"run nfsargs addip addtty;"				\
-		"bootm 200000 - ${fdt_addr}\0"				\
+		"bootm 400000 - ${fdt_addr}\0"				\
+	"net_nfs_fdt=net_nfs\0"						\
 	"flash_nfs=run nfsargs addip addtty;"				\
 		"bootm ${kernel_addr}\0"				\
 	"flash_self=run ramargs addip addtty;"				\
 		"bootm ${kernel_addr} ${ramdisk_addr}\0"		\
 	"rootpath=/opt/eldk/ppc_4xxFP\0"				\
-	"fdt_addr=400000\0"						\
+	"fdt_addr=800000\0"						\
 	"kernel_addr=fc000000\0"					\
 	"ramdisk_addr=fc200000\0"					\
 	"initrd_high=30000000\0"					\
@@ -352,7 +350,7 @@
 		"setenv filesize;saveenv\0"				\
 	"upd=run load update\0"						\
 	"nload=tftp 200000 ${hostname}/u-boot-nand.bin\0"		\
-	"nupdate=nand erase 0 60000;nand write 200000 0 60000;"		\
+	"nupdate=nand erase 0 100000;nand write 200000 0 100000;"	\
 		"setenv filesize;saveenv\0"				\
 	"nupd=run nload nupdate\0"					\
 	"pciconfighost=1\0"						\
-- 
1.5.5




From sr at denx.de  Wed Apr  9 12:58:06 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 9 Apr 2008 12:58:06 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: <200803311228.55346.sr@denx.de>
References: <20070423123237.295A13535D2@atlas.denx.de>
	<200803271130.57761.sr@denx.de> <200803311228.55346.sr@denx.de>
Message-ID: <200804091258.06646.sr@denx.de>

The following changes since commit aeff6d503b6006573d5c6b04fc658a64bebee5fa:
  Wolfgang Denk (1):
        Merge branch 'master' of git://www.denx.de/git/u-boot-fdt

are available in the git repository at:

  git://www.denx.de/git/u-boot-ppc4xx.git master

Stefan Roese (2):
      ppc: Revert patch 70431e8a that used _start instead of CFG_MONITOR_BASE
      ppc4xx: Fix Canyonlands default environment to work with new image support

 include/configs/canyonlands.h |   12 +++++-------
 lib_ppc/board.c               |    2 +-
 2 files changed, 6 insertions(+), 8 deletions(-)



From joakim.tjernlund at transmode.se  Wed Apr  9 13:14:45 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 09 Apr 2008 13:14:45 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to
	full	relocation.
In-Reply-To: <20080409104400.D46C524842@gemini.denx.de>
References: <20080409104400.D46C524842@gemini.denx.de>
Message-ID: <1207739685.5826.63.camel@gentoo-jocke.transmode.se>


On Wed, 2008-04-09 at 12:44 +0200, Wolfgang Denk wrote:
> In message <200804091140.45661.sr at denx.de> you wrote:
> >
> > Since I'm really short in time currently, and I need U-Boot running on 4xx 
> > again, I vote for reverting this patch now. I'll try to come up with 
> > a "generic" solution for the next merge window.
> > 
> > Wolfgang? What do you think?
> 
> I agree. This patch is too invasive at this point of the  development
> cycle.  Please  revert  it.  We  will  handle  this in the next merge
> window, then.

I rather see a #ifdef for ppc4xx instead.

  Jocke



From joakim.tjernlund at transmode.se  Wed Apr  9 13:23:39 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 09 Apr 2008 13:23:39 +0200
Subject: [U-Boot-Users] Fixup entries
In-Reply-To: <1207733537.6954.32.camel@localhost.localdomain>
References: <1207733537.6954.32.camel@localhost.localdomain>
Message-ID: <1207740219.5826.71.camel@gentoo-jocke.transmode.se>


On Wed, 2008-04-09 at 11:32 +0200, Kenneth Johansson wrote:
> What is the fixup section used for ?
> 
> of the 274 cards that build on my MAKEALL not one has any entries into
> this section.

These are needed for relocation of function pointers(and possible some
think more). There was an attempt by Grant Likely to enable this
functionalty, but some toolchains had problems with so the function
was disabled. If you undo commit
1c3dd43338a077165e7e0309cb3994e65d2bdbf8 you will enable it again for
powerpc.

 Jocke



From sr at denx.de  Wed Apr  9 13:45:26 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 9 Apr 2008 13:45:26 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: <1207739685.5826.63.camel@gentoo-jocke.transmode.se>
References: <20080409104400.D46C524842@gemini.denx.de>
	<1207739685.5826.63.camel@gentoo-jocke.transmode.se>
Message-ID: <200804091345.26899.sr@denx.de>

On Wednesday 09 April 2008, Joakim Tjernlund wrote:
> On Wed, 2008-04-09 at 12:44 +0200, Wolfgang Denk wrote:
> > In message <200804091140.45661.sr at denx.de> you wrote:
> > > Since I'm really short in time currently, and I need U-Boot running on
> > > 4xx again, I vote for reverting this patch now. I'll try to come up
> > > with a "generic" solution for the next merge window.
> > >
> > > Wolfgang? What do you think?
> >
> > I agree. This patch is too invasive at this point of the  development
> > cycle.  Please  revert  it.  We  will  handle  this in the next merge
> > window, then.
>
> I rather see a #ifdef for ppc4xx instead.

I disagree. As we would need different symbols for 405 and 440, this would 
look really ugly. So let's fix it correctly in the next merge window.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Wed Apr  9 14:36:16 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 09 Apr 2008 14:36:16 +0200
Subject: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full
	relocation.
In-Reply-To: Your message of "Wed, 09 Apr 2008 13:14:45 +0200."
	<1207739685.5826.63.camel@gentoo-jocke.transmode.se>
Message-ID: <20080409123616.E1FC524842@gemini.denx.de>

In message <1207739685.5826.63.camel at gentoo-jocke.transmode.se> you wrote:
> 
> > I agree. This patch is too invasive at this point of the  development
> > cycle.  Please  revert  it.  We  will  handle  this in the next merge
> > window, then.
> 
> I rather see a #ifdef for ppc4xx instead.

Yes - in the next window, please.

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: wd at denx.de
Defaults are wonderful, just like fire.
                  - Larry Wall in <1996Mar6.004121.27890 at netlabs.com>



From andre.schwarz at matrix-vision.de  Wed Apr  9 16:16:28 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Wed, 09 Apr 2008 16:16:28 +0200
Subject: [U-Boot-Users] [PATCH] add MPC8343 based board mvBlueLYNX-M7 aka
	mvblm7
Message-ID: <47FCCFBC.2090808@matrix-vision.de>

MPC8343 based stereo camera system with Cyclone-II FPGA and miniPCI Slot.
CPU utilizes dual 10/100/1000 Ethernet using Vitesse VSC8601 RGMII Phys 
and USB over ULPI.
512MB Micron DDR-II memory, 8MB Flash on LocalBus, SD over SPU and 32MB 
NAND @ FPGA.

Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
--

diff --git a/CREDITS b/CREDITS
index e84ef38..713f58a 100644
--- a/CREDITS
+++ b/CREDITS
@@ -424,6 +424,11 @@ N: Paolo Scaffardi
 E: arsenio at tin.it
 D: FADS823 configuration, MPC823 video support, I2C, wireless keyboard, lots more
 
+N: Andre Schwarz
+E: andre.schwarz at matrix-vision.de
+D: Support for BlueLYNX and BlueCOUGAR series
+W: www.matrix-vision.com
+
 N: Robert Schwebel
 E: r.schwebel at pengutronix.de
 D: Support for csb226, logodl and innokom boards (PXA2xx)
diff --git a/MAKEALL b/MAKEALL
index 2a872ac..f21c34e 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -327,6 +327,7 @@ LIST_83xx="		\
 	MPC8360ERDK_66	\
 	MPC837XEMDS	\
 	MPC837XERDB	\
+	MVBLM7		\
 	sbc8349		\
 	TQM834x		\
 "
diff --git a/Makefile b/Makefile
index a7f886b..3f217fe 100644
--- a/Makefile
+++ b/Makefile
@@ -2084,6 +2084,9 @@ sbc8349_config:		unconfig
 TQM834x_config:	unconfig
 	@$(MKCONFIG) $(@:_config=) ppc mpc83xx tqm834x
 
+MVBLM7_config: unconfig
+	@$(MKCONFIG) $(@:_config=) ppc mpc83xx mvblm7
+
 
 #########################################################################
 ## MPC85xx Systems
diff --git a/board/mvblm7/Makefile b/board/mvblm7/Makefile
new file mode 100644
index 0000000..84cd14a
--- /dev/null
+++ b/board/mvblm7/Makefile
@@ -0,0 +1,48 @@
+#
+# Copyright (C) Freescale Semiconductor, Inc. 2006. All rights reserved.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).a
+
+COBJS	:= $(BOARD).o pci.o fpga.o
+
+SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+SOBJS	:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB):	$(obj).depend $(OBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+	rm -f $(SOBJS) $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/mvblm7/config.mk b/board/mvblm7/config.mk
new file mode 100644
index 0000000..a659203
--- /dev/null
+++ b/board/mvblm7/config.mk
@@ -0,0 +1,29 @@
+#
+# Copyright (C) Freescale Semiconductor, Inc. 2006. All rights reserved.
+#
+# 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
+#
+
+#
+# MPC8349E-mITX and MPC8349E-mITX-GP
+#
+
+sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
+
+TEXT_BASE  = 0xFFF00000
diff --git a/board/mvblm7/fpga.c b/board/mvblm7/fpga.c
new file mode 100644
index 0000000..d286ef1
--- /dev/null
+++ b/board/mvblm7/fpga.c
@@ -0,0 +1,185 @@
+/*
+ * (C) Copyright 2002
+ * Rich Ireland, Enterasys Networks, rireland at enterasys.com.
+ * Keith Outwater, keith_outwater at mvis.com.
+ *
+ * (C) Copyright 2006
+ * Andre Schwarz, Matrix Vision GmbH, andre.schwarz at matrix-vision.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include <common.h>
+#include <ACEX1K.h>
+#include <command.h>
+#include "fpga.h"
+#include "mvblm7.h"
+
+#if (CONFIG_FPGA)
+
+#ifdef FPGA_DEBUG
+#define fpga_debug(fmt,args...)      printf (fmt ,##args)
+#else
+#define fpga_debug(fmt,args...)
+#endif
+
+Altera_CYC2_Passive_Serial_fns altera_fns = {
+	fpga_null_fn,
+	fpga_config_fn,
+	fpga_status_fn,
+	fpga_done_fn,
+	fpga_wr_fn,
+	fpga_null_fn,
+    	fpga_null_fn,
+    	0
+};
+
+Altera_desc cyclone2 = {
+	Altera_CYC2,
+	passive_serial,
+	Altera_EP2C20_SIZE,
+	(void *) &altera_fns,
+	NULL,
+	0
+};
+
+int mvblm7_init_fpga (void)
+{
+	DECLARE_GLOBAL_DATA_PTR;
+
+	fpga_debug("%s:%d: Initialize FPGA interface (relocation offset = 0x%.8lx)\n",
+		__FUNCTION__, __LINE__, gd->reloc_off);
+	fpga_init (gd->reloc_off);
+
+	fpga_debug("%s:%d: Adding fpga 0\n", __FUNCTION__, __LINE__);
+	fpga_add (fpga_altera, &cyclone2);
+	return 1;
+}
+
+int fpga_null_fn (int cookie)
+{
+        return 0;
+}
+
+int fpga_config_fn (int assert, int flush, int cookie)
+{
+        volatile immap_t        *im = (volatile immap_t *)CFG_IMMR;
+        volatile gpio83xx_t	*gpio = (volatile gpio83xx_t *)&im->gpio[0];
+
+	u32 dvo = gpio->dat;
+	fpga_debug("SET config : %s\n", assert ? "low" : "high");
+	if ( assert ) 
+		dvo |= FPGA_CONFIG;
+	else 
+		dvo &= ~FPGA_CONFIG;
+	
+	if ( flush )
+		gpio->dat = dvo;
+	return assert;
+}
+
+int fpga_done_fn (int cookie)
+{
+        volatile immap_t        *im = (volatile immap_t *)CFG_IMMR;
+        volatile gpio83xx_t	*gpio = (volatile gpio83xx_t *)&im->gpio[0];
+
+	udelay(10);
+	fpga_debug("CONF_DONE check ... ");
+	if ( gpio->dat & FPGA_CONF_DONE )  {
+		fpga_debug("high\n");
+		return 1;
+	} else {
+		fpga_debug("low\n");
+		return 0;
+	}
+}
+
+int fpga_status_fn (int cookie)
+{
+        volatile immap_t        *im = (volatile immap_t *)CFG_IMMR;
+        volatile gpio83xx_t	*gpio = (volatile gpio83xx_t *)&im->gpio[0];
+
+	fpga_debug("STATUS check ... ");
+	if ( gpio->dat & FPGA_STATUS )  {
+		fpga_debug("high\n");
+		return 1;
+	} else {
+		fpga_debug("low\n");
+		return 0;
+	}
+}
+
+int fpga_clk_fn (int assert_clk, int flush, int cookie)
+{
+        volatile immap_t        *im = (volatile immap_t *)CFG_IMMR;
+        volatile gpio83xx_t	*gpio = (volatile gpio83xx_t *)&im->gpio[0];
+
+	u32 dvo = gpio->dat;
+	fpga_debug("CLOCK %s\n", assert_clk ? "high" : "low");
+	if ( assert_clk )
+		dvo |= FPGA_CCLK;
+	else
+		dvo &= ~FPGA_CCLK;
+
+	if ( flush )
+		gpio->dat = dvo;
+	return assert_clk;
+}
+
+static inline int _write_fpga( u8 val, int dump )
+{
+        volatile immap_t        *im = (volatile immap_t *)CFG_IMMR;
+        volatile gpio83xx_t	*gpio = (volatile gpio83xx_t *)&im->gpio[0];
+	
+	u32 dvo = gpio->dat;
+	int i;
+
+	if ( dump )
+		fpga_debug( "  %02x -> ", val );
+	for ( i=0; i<8; i++ ) {
+		dvo &= ~FPGA_CCLK;
+		gpio->dat = dvo;	
+		dvo &= ~FPGA_DIN;			
+		if ( dump ) 
+			fpga_debug("%d ", val&1);
+		if (val & 1) 
+			dvo |= FPGA_DIN;
+		gpio->dat = dvo;	
+		dvo |= FPGA_CCLK;
+		gpio->dat = dvo;	
+		val >>= 1;
+	}
+	if ( dump ) 
+        	fpga_debug( "\n" );
+	return 0;
+}
+
+int fpga_wr_fn (void *buf, size_t len, int flush, int cookie)
+{
+	unsigned char *data = (unsigned char *) buf;
+	int i;
+
+	fpga_debug( "fpga_wr: buf %p / size %d\n", buf, len );
+	for ( i=0; i<len; i++ ) 
+		_write_fpga( data[i], 0 );	
+	fpga_debug( "\n" );
+	return FPGA_SUCCESS;
+}
+#endif
diff --git a/board/mvblm7/fpga.h b/board/mvblm7/fpga.h
new file mode 100644
index 0000000..e84ff06
--- /dev/null
+++ b/board/mvblm7/fpga.h
@@ -0,0 +1,34 @@
+/*
+ * (C) Copyright 2002
+ * Rich Ireland, Enterasys Networks, rireland at enterasys.com.
+ * Keith Outwater, keith_outwater at mvis.com.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+extern int mvblm7_init_fpga(void);
+
+extern int fpga_pgm_fn(int assert_pgm, int flush, int cookie);
+extern int fpga_status_fn (int cookie);
+extern int fpga_config_fn (int assert, int flush, int cookie);
+extern int fpga_done_fn(int cookie);
+extern int fpga_clk_fn(int assert_clk, int flush, int cookie);
+extern int fpga_wr_fn (void *buf, size_t len, int flush, int cookie);
+extern int fpga_null_fn (int cookie);
diff --git a/board/mvblm7/mvblm7.c b/board/mvblm7/mvblm7.c
new file mode 100644
index 0000000..7e6b847
--- /dev/null
+++ b/board/mvblm7/mvblm7.c
@@ -0,0 +1,128 @@
+/*
+ * Copyright (C) Freescale Semiconductor, Inc. 2006. All rights reserved.
+ *
+ * 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 <common.h>
+#include <ioports.h>
+#include <mpc83xx.h>
+#include <asm/mpc8349_pci.h>
+#include <pci.h>
+#include <asm/mmu.h>
+#if defined(CONFIG_OF_LIBFDT)
+#include <libfdt.h>
+#endif
+
+#include "mvblm7.h"
+
+int fixed_sdram(void)
+{
+        volatile immap_t *im = (immap_t *)CFG_IMMR;
+        u32 msize = 0;
+        u32 ddr_size;
+        u32 ddr_size_log2;
+
+        msize = CFG_DDR_SIZE;
+        for (ddr_size = msize << 20, ddr_size_log2 = 0;
+             (ddr_size > 1);
+             ddr_size = ddr_size>>1, ddr_size_log2++) {
+                if (ddr_size & 1) {
+                        return -1;
+                }
+        }
+        im->sysconf.ddrlaw[0].bar = ((CFG_DDR_SDRAM_BASE>>12) & 0xfffff);
+        im->sysconf.ddrlaw[0].ar = LAWAR_EN | ((ddr_size_log2 - 1) & LAWAR_SIZE);
+
+        im->ddr.csbnds[0].csbnds = CFG_DDR_CS0_BNDS;
+        im->ddr.cs_config[0] = CFG_DDR_CS0_CONFIG;
+        im->ddr.timing_cfg_0 = CFG_DDR_TIMING_0;
+        im->ddr.timing_cfg_1 = CFG_DDR_TIMING_1;
+        im->ddr.timing_cfg_2 = CFG_DDR_TIMING_2;
+        im->ddr.timing_cfg_3 = CFG_DDR_TIMING_3;
+        im->ddr.sdram_cfg = CFG_DDR_SDRAM_CFG;
+        im->ddr.sdram_cfg2 = CFG_DDR_SDRAM_CFG2;
+        im->ddr.sdram_mode = CFG_DDR_MODE;
+        im->ddr.sdram_interval = CFG_DDR_INTERVAL;
+        im->ddr.sdram_clk_cntl = CFG_DDR_CLK_CNTL;
+
+	udelay(300);
+
+	im->ddr.sdram_cfg |= SDRAM_CFG_MEM_EN;
+
+	return CFG_DDR_SIZE;
+}
+
+long int initdram(int board_type)
+{
+	volatile immap_t *im = (immap_t *) CFG_IMMR;
+	u32 msize = 0;
+
+	if ((im->sysconf.immrbar & IMMRBAR_BASE_ADDR) != (u32) im)
+		return -1;
+
+	im->sysconf.ddrlaw[0].bar = CFG_DDR_BASE & LAWBAR_BAR;
+	msize = fixed_sdram();
+
+	/* return total bus RAM size(bytes) */
+	return msize * 1024 * 1024;
+}
+
+int checkboard(void)
+{
+	puts("Board: Matrix Vision mvBlueLYNX-M7 " MV_VERSION "\n");
+	return 0;
+}
+
+u8 *dhcp_vendorex_prep (u8 * e)
+{
+    char *ptr;
+
+/* DHCP vendor-class-identifier = 60 */
+    if ((ptr = getenv ("dhcp_vendor-class-identifier"))) {
+        *e++ = 60;
+        *e++ = strlen (ptr);
+        while (*ptr)
+            *e++ = *ptr++;
+    }
+/* DHCP_CLIENT_IDENTIFIER = 61 */
+    if ((ptr = getenv ("dhcp_client_id"))) {
+        *e++ = 61;
+        *e++ = strlen (ptr);
+        while (*ptr)
+            *e++ = *ptr++;
+    }
+    return e;
+}
+
+u8 *dhcp_vendorex_proc (u8 * popt)
+{
+    return NULL;
+}
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+	ft_cpu_setup(blob, bd);
+#ifdef CONFIG_PCI
+	ft_pci_setup(blob, bd);
+#endif
+}
+
+#endif
diff --git a/board/mvblm7/mvblm7.h b/board/mvblm7/mvblm7.h
new file mode 100644
index 0000000..eb1d2a3
--- /dev/null
+++ b/board/mvblm7/mvblm7.h
@@ -0,0 +1,20 @@
+#ifndef __MVBC_H__
+#define __MVBC_H__
+
+#define MV_GPIO
+
+#define FPGA_DIN        0x20000000
+#define FPGA_CCLK       0x40000000
+#define FPGA_CONF_DONE  0x08000000
+#define FPGA_CONFIG     0x80000000
+#define FPGA_STATUS     0x10000000
+
+#define MAN_RST         0x00100000
+#define WD_TS           0x00200000
+#define WD_WDI          0x00400000
+
+#define MV_GPIO_DAT	(WD_TS)
+#define MV_GPIO_OUT	(FPGA_DIN|FPGA_CCLK|WD_TS|WD_WDI)
+#define MV_GPIO_ODE	(FPGA_CONFIG|MAN_RST)
+
+#endif
diff --git a/board/mvblm7/mvblm7_autoscript b/board/mvblm7/mvblm7_autoscript
new file mode 100644
index 0000000..8ebb4ca
--- /dev/null
+++ b/board/mvblm7/mvblm7_autoscript
@@ -0,0 +1,38 @@
+echo
+echo "==== running autoscript ===="
+echo
+setenv bootdtb bootm \${kernel_boot} \${mv_initrd_addr_ram} \${mv_dtb_addr_ram}
+setenv ramkernel setenv kernel_boot \${mv_kernel_addr_ram}
+setenv flashkernel setenv kernel_boot \${mv_kernel_addr}
+setenv cpinitrd cp \${mv_initrd_addr} \${mv_initrd_addr_ram} \${mv_initrd_length}
+setenv bootfromflash run flashkernel cpinitrd ramparam 
+setenv getdtb tftp \${mv_dtb_addr_ram} \${dtb_name}
+setenv cpdtb cp \${mv_dtb_addr} \${mv_dtb_addr_ram} 0x2000
+setenv rundtb fdt addr \${mv_dtb_addr_ram}\;fdt boardsetup\;fdt print
+setenv bootfromnet tftp \${mv_initrd_addr_ram} \${initrd_name}\;run ramkernel
+setenv addcons setenv bootargs \${bootargs} console=ttyS\${console_nr},\${baudrate}N8
+setenv set_static_ip setenv ipaddr \${static_ipaddr}
+setenv set_static_nm setenv netmask \${static_netmask}
+setenv set_static_gw setenv gatewayip \${static_gateway}
+setenv set_ip setenv ip \${ipaddr}::\${gatewayip}:\${netmask}
+setenv ramparam setenv bootargs root=/dev/ram ro rootfstype=squashfs
+if test ${autoscr_boot} != no;
+then
+  if test ${netboot} = yes;
+  then
+    bootp
+    if test $? = 0;
+    then
+      echo "=== bootp succeeded -> netboot ==="
+      run set_ip
+      run getdtb rundtb bootfromnet ramparam bootdtb
+    else
+      echo "=== netboot failed ==="
+    fi
+  fi
+  run set_static_ip set_static_nm set_static_gw set_ip
+  echo "=== bootfromflash ==="
+  run cpdtb rundtb bootfromflash
+else
+  echo "=== boot stopped with autoscr_boot no ==="
+fi
diff --git a/board/mvblm7/pci.c b/board/mvblm7/pci.c
new file mode 100644
index 0000000..3e85b91
--- /dev/null
+++ b/board/mvblm7/pci.c
@@ -0,0 +1,264 @@
+/*
+ * Copyright (C) Freescale Semiconductor, Inc. 2006. All rights reserved.
+ *
+ * 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 <common.h>
+
+#include <asm/mmu.h>
+#include <asm/global_data.h>
+#include <pci.h>
+#include <asm/mpc8349_pci.h>
+#include <i2c.h>
+#if defined(CONFIG_OF_LIBFDT)
+#include <libfdt.h>
+#include <fdt_support.h>
+#endif
+#include "mvblm7.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* System RAM mapped to PCI space */
+#define CONFIG_PCI_SYS_MEM_BUS	CFG_SDRAM_BASE
+#define CONFIG_PCI_SYS_MEM_PHYS	CFG_SDRAM_BASE
+
+#define SLOT0_IRQ       3
+#define SLOT1_IRQ       4
+void pci_mvblm7_fixup_irq (struct pci_controller *hose, pci_dev_t dev)
+{
+        unsigned char line = 0xff;
+
+        if (PCI_BUS (dev) == 0) {
+                switch (PCI_DEV (dev)) {
+		case 0x0:
+			return;
+                case 0xb:
+			line = 0;
+                        break;
+                case 0xc:
+                        line = 1;
+                        break;
+                default:
+                        printf ("***pci_scan: illegal dev = 0x%08x\n",
+                                PCI_DEV (dev));
+                        line = 0xff;
+                        break;
+                }
+                pci_hose_write_config_byte (hose, dev, PCI_INTERRUPT_LINE,
+                                            line);
+        }
+}
+
+
+static struct pci_controller pci_hose = {
+        fixup_irq:pci_mvblm7_fixup_irq
+};
+
+int mvblm7_load_fpga(void)
+{
+        size_t data_size = 0;
+        void *fpga_data = NULL;
+        char *datastr = getenv ("fpgadata");
+        char *sizestr = getenv ("fpgadatasize");
+
+        if (datastr)
+                fpga_data = (void *) simple_strtoul (datastr, NULL, 16);
+        if (sizestr)
+                data_size = (size_t) simple_strtoul (sizestr, NULL, 16);
+        return fpga_load (0, fpga_data, data_size);
+}
+
+void pci_init_board(void)
+{
+	volatile immap_t *immr;
+	volatile gpio83xx_t *gpio;
+	volatile clk83xx_t *clk;
+	volatile law83xx_t *pci_law;
+	volatile pot83xx_t *pci_pot;
+	volatile pcictrl83xx_t *pci_ctrl;
+	volatile pciconf83xx_t *pci_conf;
+	u16 reg16;
+	u32 reg32;
+	u32 dev;
+	struct pci_controller *hose;
+	char *s;
+
+	immr = (immap_t *) CFG_IMMR;
+	clk = (clk83xx_t *) & immr->clk;
+	pci_law = immr->sysconf.pcilaw;
+	pci_pot = immr->ios.pot;
+	pci_ctrl = immr->pci_ctrl;
+	pci_conf = immr->pci_conf;
+	gpio  = (volatile gpio83xx_t *)&immr->gpio[0];
+	hose = &pci_hose;
+
+	gpio->dat = MV_GPIO_DAT;
+	gpio->odr = MV_GPIO_ODE;
+	gpio->dir = MV_GPIO_OUT;
+#if defined(CONFIG_FPGA)
+       	mvblm7_init_fpga();
+        s = getenv("skip_fpga");
+        if ( !s || *s == '0' )
+		mvblm7_load_fpga();
+#endif
+	
+	/*
+	 * Configure PCI controller and PCI_CLK_OUTPUT both in 66M mode
+	 */
+
+	reg32 = clk->occr;
+	udelay(2000);
+
+	clk->occr = 0xff000000;	/* 66 MHz PCI */
+
+	udelay(2000);
+
+	/*
+	 * Release PCI RST Output signal
+	 */
+	pci_ctrl[0].gcr = 0;
+	udelay(2000);
+	pci_ctrl[0].gcr = 1;
+
+	/* We need to wait at least a 1sec based on PCI specs */
+	{
+		int i;
+
+		for (i = 0; i < 1000; i++)
+			udelay(1000);
+	}
+
+	/*
+	 * Configure PCI Local Access Windows
+	 */
+	pci_law[0].bar = CFG_PCI1_MEM_PHYS & LAWBAR_BAR;
+	pci_law[0].ar = LAWAR_EN | LAWAR_SIZE_1G;
+
+	pci_law[1].bar = CFG_PCI1_IO_PHYS & LAWBAR_BAR;
+	pci_law[1].ar = LAWAR_EN | LAWAR_SIZE_32M;
+
+	/*
+	 * Configure PCI Outbound Translation Windows
+	 */
+
+	/* PCI1 mem space - prefetch */
+	pci_pot[0].potar = (CFG_PCI1_MEM_BASE >> 12) & POTAR_TA_MASK;
+	pci_pot[0].pobar = (CFG_PCI1_MEM_PHYS >> 12) & POBAR_BA_MASK;
+	pci_pot[0].pocmr = POCMR_EN | POCMR_PREFETCH_EN | POCMR_CM_256M;
+
+	/* PCI1 IO space */
+	pci_pot[1].potar = (CFG_PCI1_IO_BASE >> 12) & POTAR_TA_MASK;
+	pci_pot[1].pobar = (CFG_PCI1_IO_PHYS >> 12) & POBAR_BA_MASK;
+	pci_pot[1].pocmr = POCMR_EN | POCMR_IO | POCMR_CM_16M;
+
+	/* PCI1 mmio - non-prefetch mem space */
+	pci_pot[2].potar = (CFG_PCI1_MMIO_BASE >> 12) & POTAR_TA_MASK;
+	pci_pot[2].pobar = (CFG_PCI1_MMIO_PHYS >> 12) & POBAR_BA_MASK;
+	pci_pot[2].pocmr = POCMR_EN | POCMR_CM_256M;
+
+	/*
+	 * Configure PCI Inbound Translation Windows
+	 */
+
+	/* we need RAM mapped to PCI space for the devices to
+	 * access main memory */
+	pci_ctrl[0].pitar1 = 0x0;
+	pci_ctrl[0].pibar1 = 0x0;
+	pci_ctrl[0].piebar1 = 0x0;
+	pci_ctrl[0].piwar1 = PIWAR_EN | PIWAR_PF | PIWAR_RTT_SNOOP |
+	    PIWAR_WTT_SNOOP | (__ilog2(gd->ram_size) - 1);
+
+	hose->first_busno = 0;
+	hose->last_busno = 0xff;
+
+	/* PCI memory prefetch space */
+	pci_set_region(hose->regions + 0,
+		       CFG_PCI1_MEM_BASE,
+		       CFG_PCI1_MEM_PHYS,
+		       CFG_PCI1_MEM_SIZE, PCI_REGION_MEM | PCI_REGION_PREFETCH);
+
+	/* PCI memory space */
+	pci_set_region(hose->regions + 1,
+		       CFG_PCI1_MMIO_BASE,
+		       CFG_PCI1_MMIO_PHYS, CFG_PCI1_MMIO_SIZE, PCI_REGION_MEM);
+
+	/* PCI IO space */
+	pci_set_region(hose->regions + 2,
+		       CFG_PCI1_IO_BASE,
+		       CFG_PCI1_IO_PHYS, CFG_PCI1_IO_SIZE, PCI_REGION_IO);
+
+	/* System memory space */
+	pci_set_region(hose->regions + 3,
+		       CONFIG_PCI_SYS_MEM_BUS,
+		       CONFIG_PCI_SYS_MEM_PHYS,
+		       gd->ram_size, PCI_REGION_MEM | PCI_REGION_MEMORY);
+
+	hose->region_count = 4;
+
+	pci_setup_indirect(hose,
+			   (CFG_IMMR + 0x8300), (CFG_IMMR + 0x8304));
+
+	pci_register_hose(hose);
+
+	/*
+	 * Write to Command register
+	 */
+	reg16 = 0xff;
+	dev = PCI_BDF(hose->first_busno, 0, 0);
+	pci_hose_read_config_word(hose, dev, PCI_COMMAND, &reg16);
+	reg16 |= PCI_COMMAND_SERR | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+	pci_hose_write_config_word(hose, dev, PCI_COMMAND, reg16);
+
+	/*
+	 * Clear non-reserved bits in status register.
+	 */
+	pci_hose_write_config_word(hose, dev, PCI_STATUS, 0xffff);
+	pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
+	pci_hose_write_config_byte(hose, dev, PCI_CACHE_LINE_SIZE, 0x08);
+
+#ifdef CONFIG_PCI_SCAN_SHOW
+	printf("PCI:   Bus Dev VenId DevId Class Int\n");
+#endif
+	hose->last_busno = pci_hose_scan(hose);
+}
+
+#if defined(CONFIG_OF_LIBFDT)
+void ft_pci_setup(void *blob, bd_t *bd)
+{
+	int nodeoffset;
+	int tmp[2];
+	const char *path;
+
+	nodeoffset = fdt_path_offset(blob, "/aliases");
+	if (nodeoffset >= 0) {
+		path = fdt_getprop(blob, nodeoffset, "pci0", NULL);
+		if (path) {
+			tmp[0] = cpu_to_be32(pci_hose.first_busno);
+			tmp[1] = cpu_to_be32(pci_hose.last_busno);
+			do_fixup_by_path(blob, path, "bus-range",
+				&tmp, sizeof(tmp), 1);
+
+			tmp[0] = cpu_to_be32(gd->pci_clk);
+			do_fixup_by_path(blob, path, "clock-frequency",
+				&tmp, sizeof(tmp[0]), 1);
+		}
+	}
+}
+#endif
diff --git a/include/configs/MVBLM7.h b/include/configs/MVBLM7.h
new file mode 100644
index 0000000..d56bf11
--- /dev/null
+++ b/include/configs/MVBLM7.h
@@ -0,0 +1,467 @@
+/*
+ * Copyright (C) Matrix Vision GmbH 2008
+ *
+ * based on Freescale's MPC8349ITX.
+ *
+ * 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
+ */
+
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#define MV_VERSION  "v0.7.0"
+
+/*
+ * High Level Configuration Options
+ */
+#define CONFIG_E300             1
+#define CONFIG_MPC83XX          1
+#define CONFIG_MPC834X          1
+#define CONFIG_MPC8343          1
+
+#define CFG_IMMR		0xE0000000
+
+#define CONFIG_PCI
+#define CONFIG_PCI_SKIP_HOST_BRIDGE
+#define CONFIG_HARD_I2C
+#define CONFIG_TSEC_ENET
+#define CONFIG_MPC8XXX_SPI
+#define CONFIG_HARD_SPI
+
+/* I2C */
+#define CONFIG_FSL_I2C
+#define CONFIG_I2C_MULTI_BUS
+#define CONFIG_I2C_CMD_TREE
+#define CFG_I2C_OFFSET		0x3000
+#define CFG_I2C2_OFFSET		0x3100
+
+#define CFG_I2C_EEPROM_ADDR	0x50
+
+#define CFG_I2C_SPEED		100000
+#define CFG_I2C_SLAVE		0x7F
+
+/*
+ * DDR Setup
+ */
+#define CFG_DDR_BASE		0x00000000
+#define CFG_SDRAM_BASE 		CFG_DDR_BASE
+#define CFG_DDR_SDRAM_BASE 	CFG_DDR_BASE
+#define CFG_83XX_DDR_USES_CS0	1
+#define CFG_MEMTEST_START	0x100000
+#define CFG_MEMTEST_END		0x800000
+
+#define CFG_DDR_SDRAM_CLK_CNTL	(DDR_SDRAM_CLK_CNTL_SS_EN | \
+				DDR_SDRAM_CLK_CNTL_CLK_ADJUST_05
+
+#define CFG_DDR_SIZE		512
+
+/* HC, 75Ohm, DDR-II, DRQ */
+#define CFG_DDRCDR		0x80000001
+/* EN, ODT_WR, 3BA, 14row, 10col */
+#define CFG_DDR_CS0_CONFIG	0x80014202
+#define CFG_DDR_CS1_CONFIG	0x0
+#define CFG_DDR_CS2_CONFIG	0x0
+#define CFG_DDR_CS3_CONFIG	0x0
+
+/* 512MByte */
+#define CFG_DDR_CS0_BNDS	0x0000001f
+#define CFG_DDR_CS1_BNDS	0x0
+#define CFG_DDR_CS2_BNDS	0x0
+#define CFG_DDR_CS3_BNDS	0x0
+
+#define CFG_DDR_CLK_CNTL	0x02000000
+
+#define CFG_DDR_TIMING_0	0x00260802
+#define CFG_DDR_TIMING_1	0x2625b221
+#define CFG_DDR_TIMING_2	0x1f9820c7
+#define CFG_DDR_TIMING_3	0x00000000
+
+/* ~MEM_EN, SREN, DDR-II, 32_BE */
+#define CFG_DDR_SDRAM_CFG	0x43080000
+#define CFG_DDR_SDRAM_CFG2	0x00401000
+#define CFG_DDR_INTERVAL	0x04060100
+
+#define CFG_DDR_MODE		0x078e0232
+
+/* Flash */
+#define CFG_FLASH_CFI	
+#define CFG_FLASH_CFI_DRIVER	
+#define CFG_FLASH_CFI_WIDTH	FLASH_CFI_16BIT
+
+#define CFG_FLASH_BASE          0xFF800000 
+#define CFG_FLASH_SIZE          8
+#define CFG_FLASH_SIZE_SHIFT    3  
+#define CFG_FLASH_EMPTY_INFO
+#define CFG_FLASH_ERASE_TOUT	60000
+#define CFG_FLASH_WRITE_TOUT	500
+#define CFG_MAX_FLASH_BANKS     1
+#define CFG_MAX_FLASH_SECT      256
+
+#define CFG_BR0_PRELIM		(CFG_FLASH_BASE | BR_PS_16 | BR_V)
+#define CFG_OR0_PRELIM		((~(CFG_FLASH_SIZE - 1) << 20) | OR_UPM_XAM | \
+				OR_GPCM_CSNT | OR_GPCM_ACS_0b11 | OR_GPCM_XACS | OR_GPCM_SCY_15 | \
+				OR_GPCM_TRLX | OR_GPCM_EHTR | OR_GPCM_EAD)
+#define CFG_LBLAWBAR0_PRELIM	CFG_FLASH_BASE
+#define CFG_LBLAWAR0_PRELIM	(LBLAWAR_EN | (0x13 + CFG_FLASH_SIZE_SHIFT))
+
+/*
+ * U-Boot memory configuration
+ */
+#define CFG_MONITOR_BASE	TEXT_BASE
+#undef	CFG_RAMBOOT
+
+#define CONFIG_L1_INIT_RAM
+#define CFG_INIT_RAM_LOCK
+#define CFG_INIT_RAM_ADDR	0xFD000000	/* Initial RAM address */
+#define CFG_INIT_RAM_END	0x1000		/* End of used area in RAM*/
+
+#define CFG_GBL_DATA_SIZE	0x100		/* num bytes initial data */
+#define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
+#define CFG_INIT_SP_OFFSET	CFG_GBL_DATA_OFFSET
+
+/* CFG_MONITOR_LEN must be a multiple of CFG_ENV_SECT_SIZE */
+#define CFG_MONITOR_LEN		(512 * 1024)
+#define CFG_MALLOC_LEN		(512 * 1024)
+
+/*
+ * Local Bus LCRR and LBCR regs
+ *    LCRR:  DLL bypass, Clock divider is 4
+ * External Local Bus rate is
+ *    CLKIN * HRCWL_CSB_TO_CLKIN / HRCWL_LCL_BUS_TO_SCB_CLK / LCRR_CLKDIV
+ */
+#define CFG_LCRR	(LCRR_DBYP | LCRR_CLKDIV_4)
+#define CFG_LBC_LBCR	0x00000000
+
+#define CFG_LBC_LSRT	0x32000000    /* LB sdram refresh timer, about 6us */
+#define CFG_LBC_MRTPR	0x20000000    /* LB refresh timer prescal, 266MHz/32*/
+
+/*
+ * Serial Port
+ */
+#define CONFIG_CONS_INDEX	1
+#undef	CONFIG_SERIAL_SOFTWARE_FIFO
+#define CFG_NS16550
+#define CFG_NS16550_SERIAL
+#define CFG_NS16550_REG_SIZE	1
+#define CFG_NS16550_CLK		get_bus_freq(0)
+
+#define CFG_BAUDRATE_TABLE  \
+	{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 115200}
+
+#define CONFIG_CONSOLE		ttyS0
+#define CONFIG_BAUDRATE		115200
+
+#define CFG_NS16550_COM1	(CFG_IMMR + 0x4500)
+#define CFG_NS16550_COM2	(CFG_IMMR + 0x4600)
+
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT		1
+#define CONFIG_OF_BOARD_SETUP		1
+#define CONFIG_OF_STDOUT_VIA_ALIAS      1
+#define MV_DTB_NAME             "mvblm7.dtb"
+
+/*
+ * PCI
+ */
+#define CFG_PCI1_MEM_BASE	0x80000000
+#define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
+#define CFG_PCI1_MEM_SIZE	0x10000000	
+#define CFG_PCI1_MMIO_BASE	(CFG_PCI1_MEM_BASE + CFG_PCI1_MEM_SIZE)
+#define CFG_PCI1_MMIO_PHYS	CFG_PCI1_MMIO_BASE
+#define CFG_PCI1_MMIO_SIZE	0x10000000
+#define CFG_PCI1_IO_BASE	0x00000000
+#define CFG_PCI1_IO_PHYS	0xE2000000
+#define CFG_PCI1_IO_SIZE	0x01000000	
+
+#define _IO_BASE		0x00000000
+
+#define CONFIG_NET_MULTI	1
+#define CONFIG_NET_RETRY_COUNT	3
+#define CONFIG_PCI_PNP	
+
+#define CONFIG_PCI_SCAN_SHOW		
+
+#define PCI_66M
+#define CONFIG_83XX_CLKIN	66666666	/* in Hz */
+
+/* TSEC */
+#define CONFIG_GMII		
+#define CFG_VSC8601_SKEWFIX
+
+#define CONFIG_TSEC1
+#define CONFIG_TSEC2
+
+#define CONFIG_HAS_ETH0
+#define CONFIG_ETHADDR		B6:B4:45:EB:FB:C0
+#define CONFIG_TSEC1_NAME  	"TSEC0"
+#define CONFIG_FEC1_PHY_NORXERR
+#define CFG_TSEC1_OFFSET	0x24000
+#define CFG_TSEC1 		(CFG_IMMR+CFG_TSEC1_OFFSET)
+#define TSEC1_PHY_ADDR		0x10
+#define TSEC1_PHYIDX		0
+#define TSEC1_FLAGS		(TSEC_GIGABIT|TSEC_REDUCED)
+
+#define CONFIG_HAS_ETH1
+#define CONFIG_ETH1ADDR		B6:B4:45:EB:FB:C2
+#define CONFIG_TSEC2_NAME  	"TSEC1"
+#define CONFIG_FEC2_PHY_NORXERR
+#define CFG_TSEC2_OFFSET	0x25000
+#define CFG_TSEC2 		(CFG_IMMR+CFG_TSEC2_OFFSET)
+#define TSEC2_PHY_ADDR		0x11
+#define TSEC2_PHYIDX		0
+#define TSEC2_FLAGS		(TSEC_GIGABIT|TSEC_REDUCED)
+
+#define CONFIG_ETHPRIME		"TSEC0"
+
+#define CONFIG_BOOTP_VENDOREX
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_DNS
+#define CONFIG_BOOTP_DNS2
+#define CONFIG_BOOTP_HOSTNAME
+#define CONFIG_BOOTP_BOOTFILESIZE
+#define CONFIG_BOOTP_BOOTPATH
+#define CONFIG_BOOTP_NTPSERVER
+#define CONFIG_BOOTP_RANDOM_DELAY
+#define CONFIG_BOOTP_SEND_HOSTNAME
+
+/*
+ * Environment
+ */
+#undef  CFG_FLASH_PROTECTION
+#define CONFIG_ENV_OVERWRITE
+
+#define CFG_ENV_IS_IN_FLASH	1
+#define CFG_ENV_ADDR          	0xFF800000
+#define CFG_ENV_SIZE		0x2000
+#define CFG_ENV_SECT_SIZE     	0x2000
+#define CFG_ENV_ADDR_REDUND   	(CFG_ENV_ADDR+CFG_ENV_SIZE)
+#define CFG_ENV_SIZE_REDUND   	CFG_ENV_SIZE
+
+#define CONFIG_LOADS_ECHO 
+#define CFG_LOADS_BAUD_CHANGE
+
+/*
+ * Command line configuration.
+ */
+#include <config_cmd_default.h>
+
+#define CONFIG_CMD_CACHE
+#define CONFIG_CMD_IRQ
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_SDRAM
+#define CONFIG_CMD_PCI
+#define CONFIG_CMD_I2C
+#define CONFIG_CMD_FPGA
+
+#undef CONFIG_WATCHDOG
+
+/*
+ * Miscellaneous configurable options
+ */
+#define CFG_LONGHELP	
+#define CONFIG_CMDLINE_EDITING
+#define CFG_HUSH_PARSER	
+#define CFG_PROMPT_HUSH_PS2 "> "
+
+#define CFG_LOAD_ADDR	0x2000000	/* default load address */
+#define CONFIG_LOADADDR	200000		/* default location for tftp and bootm */
+
+#define CFG_PROMPT	"mvBL-M7> "
+
+#if defined(CONFIG_CMD_KGDB)
+    #define CFG_CBSIZE	1024	
+#else
+    #define CFG_CBSIZE	256
+#endif
+
+#define CFG_PBSIZE	(CFG_CBSIZE + sizeof(CFG_PROMPT) + 16) /* Print Buffer Size */
+#define CFG_MAXARGS	16		/* max number of command args */
+#define CFG_BARGSIZE	CFG_CBSIZE	/* Boot Argument Buffer Size */
+#define CFG_HZ		1000		/* decrementer freq: 1ms ticks */
+
+/*
+ * For booting Linux, the board info and command line data
+ * have to be in the first 8 MB of memory, since this is
+ * the maximum mapped by the Linux kernel during initialization.
+ */
+#define CFG_BOOTMAPSZ	(8 << 20)	/* Initial Memory map for Linux*/
+
+#define CFG_HRCW_LOW 	0x0
+#define CFG_HRCW_HIGH 	0x0
+
+/*
+ * System performance
+ */
+#define CFG_ACR_PIPE_DEP	3	/* Arbiter pipeline depth (0-3) */
+#define CFG_ACR_RPTCNT		3	/* Arbiter repeat count (0-7) */
+#define CFG_SPCR_TSEC1EP	3	/* TSEC1 emergency priority (0-3) */
+#define CFG_SPCR_TSEC2EP	3	/* TSEC2 emergency priority (0-3) */
+#define CFG_SCCR_TSEC1CM	1	/* TSEC1 clock mode (0-3) */
+#define CFG_SCCR_TSEC2CM	1	/* TSEC2 & I2C0 clock mode (0-3) */
+
+/*
+ * System IO Config
+ */
+#define CFG_SICRH 	SICRH_TSOBI1	/* Needed for gigabit to work on TSEC 1 */
+#define CFG_SICRL 	(SICRL_LDP_A | SICRL_USB1)
+
+#define CFG_HID0_INIT	0x000000000
+#define CFG_HID0_FINAL	CFG_HID0_INIT
+
+#define CFG_HID2	HID2_HBE
+
+/* DDR  */
+#define CFG_IBAT0L	(CFG_SDRAM_BASE | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CFG_IBAT0U	(CFG_SDRAM_BASE | BATU_BL_256M | BATU_VS | BATU_VP)
+#define CFG_IBAT7L	((CFG_SDRAM_BASE + (256<<20)) | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CFG_IBAT7U	((CFG_SDRAM_BASE + (256<<20)) | BATU_BL_256M | BATU_VS | BATU_VP)
+
+/* PCI  */
+#define CFG_IBAT1L	(CFG_PCI1_MEM_BASE | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CFG_IBAT1U	(CFG_PCI1_MEM_BASE | BATU_BL_256M | BATU_VS | BATU_VP)
+#define CFG_IBAT2L	(CFG_PCI1_MMIO_BASE | BATL_PP_10 | BATL_CACHEINHIBIT | BATL_GUARDEDSTORAGE)
+#define CFG_IBAT2U	(CFG_PCI1_MMIO_BASE | BATU_BL_256M | BATU_VS | BATU_VP)
+
+/* no PCI2 */
+#define CFG_IBAT3L	0
+#define CFG_IBAT3U	0
+#define CFG_IBAT4L	0
+#define CFG_IBAT4U	0
+
+/* IMMRBAR @ 0xE0000000, PCI IO @ 0xE2000000 & BCSR @ 0xE2400000 */
+#define CFG_IBAT5L	(CFG_IMMR | BATL_PP_10 | BATL_CACHEINHIBIT | BATL_GUARDEDSTORAGE)
+#define CFG_IBAT5U	(CFG_IMMR | BATU_BL_256M | BATU_VS | BATU_VP)
+
+/* stack in DCACHE 0xFDF00000 & FLASH @ 0xFF800000 */
+#define CFG_IBAT6L      (0xF0000000 | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CFG_IBAT6U      (0xF0000000 | BATU_BL_256M | BATU_VS | BATU_VP)
+
+#define CFG_DBAT0L	CFG_IBAT0L
+#define CFG_DBAT0U	CFG_IBAT0U
+#define CFG_DBAT1L	CFG_IBAT1L
+#define CFG_DBAT1U	CFG_IBAT1U
+#define CFG_DBAT2L	CFG_IBAT2L
+#define CFG_DBAT2U	CFG_IBAT2U
+#define CFG_DBAT3L	CFG_IBAT3L
+#define CFG_DBAT3U	CFG_IBAT3U
+#define CFG_DBAT4L	CFG_IBAT4L
+#define CFG_DBAT4U	CFG_IBAT4U
+#define CFG_DBAT5L	CFG_IBAT5L
+#define CFG_DBAT5U	CFG_IBAT5U
+#define CFG_DBAT6L	CFG_IBAT6L
+#define CFG_DBAT6U	CFG_IBAT6U
+#define CFG_DBAT7L	CFG_IBAT7L
+#define CFG_DBAT7U	CFG_IBAT7U
+
+/*
+ * Internal Definitions
+ *
+ * Boot Flags
+ */
+#define BOOTFLAG_COLD	0x01	/* Normal Power-On: Boot from FLASH */
+#define BOOTFLAG_WARM	0x02	/* Software reboot */
+
+
+/*
+ * Environment Configuration
+ */
+#define CONFIG_ENV_OVERWRITE
+
+#define CONFIG_NETDEV		eth0
+
+/* Default path and filenames */
+#define CONFIG_BOOTDELAY                5
+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_AUTOBOOT_STOP_STR        "s"
+#define CONFIG_ZERO_BOOTDELAY_CHECK
+#define CONFIG_RESET_TO_RETRY           1000
+
+#define MV_CI                   "mvBlueLYNX-M7"
+#define MV_VCI                  "mvBlueLYNX-M7"
+#define MV_FPGA_DATA            "0xfff80000"
+#define MV_FPGA_SIZE            "0x76ca2"
+#define MV_KERNEL_ADDR          "0xff810000"
+#define MV_INITRD_ADDR          "0xffc00000"
+#define MV_AUTOSCR_ADDR         "0xff804000"
+#define MV_AUTOSCR_ADDR2        "0xff806000"
+#define MV_DTB_ADDR          	"0xff808000"
+#define MV_INITRD_LENGTH        "0x00300000"
+
+#define CONFIG_SHOW_BOOT_PROGRESS 1
+
+#define MV_KERNEL_ADDR_RAM      "0x00100000"
+#define MV_DTB_ADDR_RAM         "0x00600000"
+#define MV_INITRD_ADDR_RAM      "0x01000000"
+
+#define CONFIG_BOOTCOMMAND      "if imi ${autoscr_addr}; then autoscr ${autoscr_addr}; else autoscr ${autoscr_addr2}; fi;"
+#define CONFIG_BOOTARGS         "root=/dev/ram ro rootfstype=squashfs"
+
+#define CONFIG_EXTRA_ENV_SETTINGS                               \
+        "console_nr=0\0"                                        \
+        "stdin=serial\0"                                        \
+        "stdout=serial\0"                                       \
+        "stderr=serial\0"                                       \
+        "fpga=0\0"                                              \
+        "fpgadata=" MV_FPGA_DATA "\0"                           \
+        "fpgadatasize=" MV_FPGA_SIZE "\0"                       \
+        "autoscr_addr=" MV_AUTOSCR_ADDR "\0"                    \
+        "autoscr_addr2=" MV_AUTOSCR_ADDR2 "\0"                  \
+        "mv_kernel_addr=" MV_KERNEL_ADDR "\0"                   \
+        "mv_kernel_addr_ram=" MV_KERNEL_ADDR_RAM "\0"           \
+        "mv_initrd_addr=" MV_INITRD_ADDR "\0"                   \
+        "mv_initrd_addr_ram=" MV_INITRD_ADDR_RAM "\0"           \
+        "mv_initrd_length=" MV_INITRD_LENGTH "\0"               \
+        "mv_dtb_addr=" MV_DTB_ADDR "\0"                 	\
+        "mv_dtb_addr_ram=" MV_DTB_ADDR_RAM "\0"                 \
+        "dtb_name=" MV_DTB_NAME "\0"                            \
+        "mv_version=" MV_VERSION "\0"                           \
+        "dhcp_client_id=" MV_CI "\0"                            \
+        "dhcp_vendor-class-identifier=" MV_VCI "\0"             \
+        "netretry=no\0"                                         \
+        "use_static_ipaddr=no\0"                                \
+        "static_ipaddr=192.168.90.10\0"                         \
+        "static_netmask=255.255.255.0\0"                        \
+        "static_gateway=0.0.0.0\0"                              \
+        "initrd_name=uInitrd.mvbc-1G-rfs\0"                     \
+        "zcip=no\0"                                             \
+        "netboot=no\0"                                         	\
+        "mvtest=Ff\0"                                           \
+        "tried_bootfromflash=no\0"                              \
+        "tried_bootfromnet=no\0"                                \
+        "bootfile=mvblm72625.boot\0"                            \
+        "use_dhcp=no\0"                                        	\
+        "gev_start=no\0"                                       	\
+        "mvbcdma_debug=0\0"                                     \
+        "mvbcia_debug=0\0"                                      \
+        "propdev_debug=0\0"                                     \
+        "gevss_debug=0\0"                                       \
+        "watchdog=0\0"                                          \
+	"skip_fpga=0\0"						\
+        ""
+#define CONFIG_FPGA_COUNT       1
+#define CONFIG_FPGA             CFG_ALTERA_CYCLON2
+#define CONFIG_FPGA_ALTERA
+#define CONFIG_FPGA_CYCLON2
+
+#endif







MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From skuribay at ruby.dti.ne.jp  Wed Apr  9 16:29:21 2008
From: skuribay at ruby.dti.ne.jp (Shinya Kuribayashi)
Date: Wed, 09 Apr 2008 23:29:21 +0900
Subject: [U-Boot-Users] ne2000 compile error
Message-ID: <47FCD2C1.6020101@ruby.dti.ne.jp>

I'm getting the following compile error in trunk git with
qemu_mips_config.

<--  snip  -->

mips-linux-gcc -g  -Os   -D__KERNEL__ -DTEXT_BASE=0xbfc00000 -I/home/skuribay/devel/u-boot.git/include -fno-builtin -ffreestanding -nostdinc -isystem /home/skuribay/devel/buildroot/build_mips/staging_dir/usr/bin-ccache/../lib/gcc/mips-linux-uclibc/4.2.3/include -pipe  -DCONFIG_MIPS -D__MIPS__ -G 0 -mabicalls -fpic -pipe -msoft-float -march=4kc -mtune=4kc -EB -Wall -Wstrict-prototypes -c -o ne2000.o ne2000.c
In file included from ne2000.c:118:
ne2000.h: In function 'pcnet_reset_8390':
ne2000.h:100: warning: implicit declaration of function 'n2k_outb'
ne2000.h:100: error: 'E8390_NODMA' undeclared (first use in this function)
ne2000.h:100: error: (Each undeclared identifier is reported only once
ne2000.h:100: error: for each function it appears in.)
ne2000.h:100: error: 'E8390_PAGE0' undeclared (first use in this function)
ne2000.h:100: error: 'E8390_STOP' undeclared (first use in this function)
ne2000.h:100: error: 'E8390_CMD' undeclared (first use in this function)
ne2000.h:102: error: 'E8390_PAGE1' undeclared (first use in this function)
ne2000.h:108: warning: implicit declaration of function 'n2k_inb'
ne2000.h:108: error: 'PCNET_RESET' undeclared (first use in this function)
ne2000.h:111: error: 'EN0_ISR' undeclared (first use in this function)
ne2000.h:111: error: 'ENISR_RESET' undeclared (first use in this function)
ne2000.h: In function 'get_prom':
ne2000.h:129: error: 'E8390_NODMA' undeclared (first use in this function)
ne2000.h:129: error: 'E8390_PAGE0' undeclared (first use in this function)
ne2000.h:129: error: 'E8390_STOP' undeclared (first use in this function)
ne2000.h:129: error: 'E8390_CMD' undeclared (first use in this function)
ne2000.h:130: error: 'EN0_DCFG' undeclared (first use in this function)
ne2000.h:131: error: 'EN0_RCNTLO' undeclared (first use in this function)
ne2000.h:132: error: 'EN0_RCNTHI' undeclared (first use in this function)
ne2000.h:133: error: 'EN0_IMR' undeclared (first use in this function)
ne2000.h:134: error: 'EN0_ISR' undeclared (first use in this function)
ne2000.h:135: error: 'E8390_RXOFF' undeclared (first use in this function)
ne2000.h:135: error: 'EN0_RXCR' undeclared (first use in this function)
ne2000.h:136: error: 'E8390_TXOFF' undeclared (first use in this function)
ne2000.h:136: error: 'EN0_TXCR' undeclared (first use in this function)
ne2000.h:139: error: 'EN0_RSARLO' undeclared (first use in this function)
ne2000.h:140: error: 'EN0_RSARHI' undeclared (first use in this function)
ne2000.h:141: error: 'E8390_RREAD' undeclared (first use in this function)
ne2000.h:141: error: 'E8390_START' undeclared (first use in this function)
ne2000.h:155: error: 'PCNET_DATAPORT' undeclared (first use in this function)
ne2000.h:159: error: 'NR_INFO' undeclared (first use in this function)
ne2000.h:159: warning: comparison between pointer and integer
ne2000.h:160: error: 'hw_info' undeclared (first use in this function)
ne2000.h:160: error: 'struct <anonymous>' has no member named '$4'
ne2000.h:160: warning: comparison between pointer and integer
ne2000.h:161: error: 'struct <anonymous>' has no member named '$5'
ne2000.h:161: warning: comparison between pointer and integer
ne2000.h:162: error: 'struct <anonymous>' has no member named '$6'
ne2000.h:162: warning: comparison between pointer and integer
ne2000.h:167: warning: comparison between pointer and integer
ne2000.h:175: warning: comparison between pointer and integer
ne2000.h:177: warning: return makes integer from pointer without a cast
ne2000.c: In function 'dp83902a_init':
ne2000.c:140: error: 'i' undeclared (first use in this function)
ne2000.c:140: warning: comparison between pointer and integer
ne2000.c:140: error: lvalue required as increment operand
ne2000.c:141: error: array subscript is not an integer
ne2000.c:141: error: invalid operands to binary +
ne2000.c:141: warning: statement with no effect
ne2000.c: In function 'eth_init':
ne2000.c:793: warning: assignment makes pointer from integer without a cast
ne2000.c:806: error: 'START_PG2' undeclared (first use in this function)
ne2000.c:806: warning: assignment makes integer from pointer without a cast
make[1]: *** [ne2000.o] Error 1

<--  snip  -->

Git bisect has picked up the following commit:

----------------------------------------------------------------
commit e710185aae90c64d39c2d453e40e58ceefe4f250
Author: goda.yusuke <goda.yusuke at renesas.com>
Date:   Wed Mar 5 17:08:20 2008 +0900

    net: Divided code of NE2000 ethernet driver
    
    There are more devices of the NE2000 base.
    A present code is difficult for us to support more devices.
    To support more NE2000 clone devices, separated the function.
    
    Signed-off-by: Yusuke Goda <goda.yusuke at renesas.com>
    Acked-by: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>

----------------------------------------------------------------

I tried to fix the problem, but tha patch is a little complicated.

Thanks,

  Shinya




From kenneth at southpole.se  Wed Apr  9 16:46:53 2008
From: kenneth at southpole.se (Kenneth Johansson)
Date: Wed, 09 Apr 2008 16:46:53 +0200
Subject: [U-Boot-Users] Fixup entries
In-Reply-To: <1207740219.5826.71.camel@gentoo-jocke.transmode.se>
References: <1207733537.6954.32.camel@localhost.localdomain>
	<1207740219.5826.71.camel@gentoo-jocke.transmode.se>
Message-ID: <1207752413.6954.52.camel@localhost.localdomain>


On Wed, 2008-04-09 at 13:23 +0200, Joakim Tjernlund wrote:
> On Wed, 2008-04-09 at 11:32 +0200, Kenneth Johansson wrote:
> > What is the fixup section used for ?
> > 
> > of the 274 cards that build on my MAKEALL not one has any entries into
> > this section.
> 
> These are needed for relocation of function pointers(and possible some
> think more). There was an attempt by Grant Likely to enable this
> functionalty, but some toolchains had problems with so the function
> was disabled. If you undo commit
> 1c3dd43338a077165e7e0309cb3994e65d2bdbf8 you will enable it again for
> powerpc.
> 
>  Jocke

aaahhaa so that is how it's working. 

I remember having problem understanding this when I did the command
section and ended up doing a manual relocation of the command table. But
compiling with -mrelocatable and going over the .fixup section instead I
can now remove that extra code and it works fine.

It's not easy to understand the ABI.

I removed the -fPIC and only used -mrelocatable and that works too.

Wonder if there is something else in u-boot that use function pointers
and work by accident due to the fact that the old address in flash is
still valid. 

---
`-mrelocatable'
`-mno-relocatable'
     On embedded PowerPC systems generate code that allows (does not
     allow) the program to be relocated to a different address at
     runtime.  If you use `-mrelocatable' on any module, all objects
     linked together must be compiled with `-mrelocatable' or
     `-mrelocatable-lib'.








From izzet-tnerirum at ROSSANTE.IT  Wed Apr  9 17:25:18 2008
From: izzet-tnerirum at ROSSANTE.IT (mcmanus)
Date: Wed, 9 Apr 2008 17:25:18 +0200
Subject: [U-Boot-Users] Make your rod massive
Message-ID: <B500666A.4%izzet-tnerirum@ROSSANTE.IT>

Get your lady's attention like never before, visit our website here now http://www.Candibers.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080409/5b3cd7c7/attachment.htm 

From vapier at gentoo.org  Wed Apr  9 17:29:46 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 9 Apr 2008 11:29:46 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: tighten up post memory
	coding style
In-Reply-To: <20080409072520.2D5E9243AB@gemini.denx.de>
References: <20080409072520.2D5E9243AB@gemini.denx.de>
Message-ID: <200804091129.47960.vapier@gentoo.org>

On Wednesday 09 April 2008, Wolfgang Denk wrote:
> In message <1207722800-3978-6-git-send-email-vapier at gentoo.org> you wrote:
> ...
>
> > -	for (i = 0; i < 0x80000; i++) ;
> > +	for (i = 0; i < 0x80000; i++)
> > +		continue;
>
> We don't do this. If you want to make obvious that this is an empty
> loop, please write it ias
>
> 	for (i = 0; i < 0x80000; i++)
> 		;
>
> But no "continue".
>
> > -	for (i = 0; i < 0x80000; i++) ;
> > +	for (i = 0; i < 0x80000; i++)
> > +		continue;
> >  }
>
> Ditto.

the generated code is the same.  the usage of "continue" makes it much more 
explicit that this is an empty loop.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080409/0d03908a/attachment.pgp 

From lg at denx.de  Wed Apr  9 17:34:08 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Wed, 9 Apr 2008 17:34:08 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] Fix regression introduced by a typo in
 "Tidied other cpu/arm920t/start.S code"
Message-ID: <Pine.LNX.4.64.0804091725330.5671@axis700.grange>

Restore logic reverted by commit

commit 80767a6cead9990d9e77e62be947843c2c72f469
Author: Peter Pearse <peter.pearse at arm.com>
Date:   Wed Sep 5 16:04:41 2007 +0100

    Changed API name to coloured_led.h
    Removed code using deprecated ifdef CONFIG_BOOTBINFUNC
    Tidied other cpu/arm920t/start.S code

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

commit 4edc89c17c34c10885082ddbc73b9416e8ff4f5a
Author: Guennadi Liakhovetski <lyakh at 6a.(none)>
Date:   Wed Apr 9 17:05:52 2008 +0200

    Fix reverted ifdef
    
    Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

diff --git a/cpu/arm920t/start.S b/cpu/arm920t/start.S
index ae86002..acc00ad 100644
--- a/cpu/arm920t/start.S
+++ b/cpu/arm920t/start.S
@@ -178,7 +178,7 @@ copyex:
 	bl	cpu_init_crit
 #endif
 
-#ifdef	CONFIG_AT91RM9200
+#ifndef	CONFIG_AT91RM9200
 
 #ifndef CONFIG_SKIP_RELOCATE_UBOOT
 relocate:				/* relocate U-Boot to RAM	    */



From jdl at freescale.com  Wed Apr  9 17:56:37 2008
From: jdl at freescale.com (Jon Loeliger)
Date: Wed, 09 Apr 2008 10:56:37 -0500
Subject: [U-Boot-Users] FIS DTC
In-Reply-To: <20080409004113.GB8092@localhost.localdomain>
References: <20080408043216.GD18501@localhost.localdomain>
	<5342.8362-30247-262363595-1207633054@seznam.cz>
	<20080409004113.GB8092@localhost.localdomain>
Message-ID: <1207756597.22344.17.camel@ld0161-tx32>

On Wed, 2008-04-09 at 10:41 +1000, David Gibson wrote:
> On Tue, Apr 08, 2008 at 07:37:35AM +0200, Michal Simek wrote:
> > Hi David,
> > 
> > >The /incbin/ is probably the problem.  Support for binary includes has
> > >been suggested, and patches have floated around, but it hasn't yet
> > >been merged into dtc mainline.
> > 
> > :-( Do you have any floated version?
> 
> I don't have the patches ready to hand, I'm afraid.  I do mean to get
> the feature merged, but I'm not happy with how it's implemented right
> now, and have only been slowly getting to the pieces we need for a
> version I'd be happy with. 

Which is why it hasn't gone in yet.

>  Plus jdl appears not to have had a lot of
> time to spend on dtc lately.

Also true.

jdl





From Joakim.Tjernlund at transmode.se  Wed Apr  9 18:19:59 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 9 Apr 2008 18:19:59 +0200
Subject: [U-Boot-Users] Fixup entries
In-Reply-To: <1207752413.6954.52.camel@localhost.localdomain>
References: <1207733537.6954.32.camel@localhost.localdomain>	
	<1207740219.5826.71.camel@gentoo-jocke.transmode.se>
	<1207752413.6954.52.camel@localhost.localdomain>
Message-ID: <005a01c89a5d$8e9c67b0$abd53710$@Tjernlund@transmode.se>



> -----Original Message-----
> From: Kenneth Johansson [mailto:kenneth at southpole.se]
> Sent: den 9 april 2008 16:47
> To: joakim.tjernlund at transmode.se
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Fixup entries
> 
> 
> On Wed, 2008-04-09 at 13:23 +0200, Joakim Tjernlund wrote:
> > On Wed, 2008-04-09 at 11:32 +0200, Kenneth Johansson wrote:
> > > What is the fixup section used for ?
> > >
> > > of the 274 cards that build on my MAKEALL not one has any entries into
> > > this section.
> >
> > These are needed for relocation of function pointers(and possible some
> > think more). There was an attempt by Grant Likely to enable this
> > functionalty, but some toolchains had problems with so the function
> > was disabled. If you undo commit
> > 1c3dd43338a077165e7e0309cb3994e65d2bdbf8 you will enable it again for
> > powerpc.
> >
> >  Jocke
> 
> aaahhaa so that is how it's working.
> 
> I remember having problem understanding this when I did the command
> section and ended up doing a manual relocation of the command table. But
> compiling with -mrelocatable and going over the .fixup section instead I
> can now remove that extra code and it works fine.
> 
> It's not easy to understand the ABI.
> 
> I removed the -fPIC and only used -mrelocatable and that works too.
> 
> Wonder if there is something else in u-boot that use function pointers
> and work by accident due to the fact that the old address in flash is
> still valid.

Oh yes, there are a few such pointers. And the conversion to using fixups instead
is a bit lazy. Several manual relocations has only been nullified by setting 
gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel
free to send patches :)

    Jocke




From monstr at seznam.cz  Wed Apr  9 18:50:55 2008
From: monstr at seznam.cz (Michal Simek)
Date: Wed, 09 Apr 2008 18:50:55 +0200
Subject: [U-Boot-Users] FIS DTC
In-Reply-To: <1207756597.22344.17.camel@ld0161-tx32>
References: <20080408043216.GD18501@localhost.localdomain>	
	<5342.8362-30247-262363595-1207633054@seznam.cz>	
	<20080409004113.GB8092@localhost.localdomain>
	<1207756597.22344.17.camel@ld0161-tx32>
Message-ID: <47FCF3EF.6050900@seznam.cz>

Hi Jon,

I have had version with /incbin/. I found patches from Scott.

Michal Simek
www.monstr.eu

>>> Hi David,
>>>
>>>> The /incbin/ is probably the problem.  Support for binary includes has
>>>> been suggested, and patches have floated around, but it hasn't yet
>>>> been merged into dtc mainline.
>>> :-( Do you have any floated version?
>> I don't have the patches ready to hand, I'm afraid.  I do mean to get
>> the feature merged, but I'm not happy with how it's implemented right
>> now, and have only been slowly getting to the pieces we need for a
>> version I'd be happy with. 
> 
> Which is why it hasn't gone in yet.
> 
>>  Plus jdl appears not to have had a lot of
>> time to spend on dtc lately.
> 
> Also true.
> 
> jdl
> 
> 
> 



From plagnioj at jcrosoft.com  Wed Apr  9 19:45:55 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 9 Apr 2008 19:45:55 +0200
Subject: [U-Boot-Users] [PATCH] Add support for u-boot in svn
	and	localversion-* files
In-Reply-To: <62330506-2BC7-4475-B394-EA38443308FB@kernel.crashing.org>
References: <20080408210433.AC07424842@gemini.denx.de>
	<47FBE16F.9030003@gmail.com>
	<62330506-2BC7-4475-B394-EA38443308FB@kernel.crashing.org>
Message-ID: <20080409174555.GC28294@game.jcrosoft.org>

On 16:49 Tue 08 Apr     , Kumar Gala wrote:
> 
> On Apr 8, 2008, at 4:19 PM, Ben Warren wrote:
> > Wolfgang Denk wrote:
> >> In message <1207677657-31722-1-git-send-email-vapier at gentoo.org>  
> >> you wrote:
> >>
> >>> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> >>>
> >>
> >> Hm... is anybody using SVN for U-Boot?
> >>
> >> Best regards,
> >>
> >> Wolfgang Denk
> >>
> >>
> > I used it at my last company and will most certainly use it again, and
> > appreciate this patch.  I think it's very popular in companies that
> > prefer free, more traditional revision control.
> 
> bah, use git :)

Yeah, use git or at least git-svn

Best Regards,
J.



From plagnioj at jcrosoft.com  Wed Apr  9 19:49:03 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 9 Apr 2008 19:49:03 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <003601c89985$5cf10aa0$16d31fe0$@savary@kerlink.fr>
References: <003601c89985$5cf10aa0$16d31fe0$@savary@kerlink.fr>
Message-ID: <20080409174903.GD28294@game.jcrosoft.org>

On 16:32 Tue 08 Apr     , Pierre Savary wrote:
> Hi,
> I use a MMCplus 4GB on my design (with at91sam9260). It's wired with 4 bits.
> Currently U-boot (1.1.5) can't detect correctly the MMC and so I can't read
1.1.5 is really old please update to the curent RC

Best Regards,
J.



From wd at denx.de  Wed Apr  9 19:58:18 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 09 Apr 2008 19:58:18 +0200
Subject: [U-Boot-Users] [PATCH/review] Blackfin: tighten up post memory
	coding style
In-Reply-To: Your message of "Wed, 09 Apr 2008 11:29:46 EDT."
	<200804091129.47960.vapier@gentoo.org>
Message-ID: <20080409175818.23855243AB@gemini.denx.de>

In message <200804091129.47960.vapier at gentoo.org> you wrote:
>
> the generated code is the same.  the usage of "continue" makes it much more
> explicit that this is an empty loop.

This is your opinion. I find this ugly and will not accept the patch.

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: wd at denx.de
He's dead, Jim
	-- McCoy, "The Devil in the Dark", stardate 3196.1



From biggerbadderben at gmail.com  Wed Apr  9 20:06:04 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Wed, 09 Apr 2008 14:06:04 -0400
Subject: [U-Boot-Users] [PATCH] Add support for u-boot in svn
 and	localversion-* files
In-Reply-To: <20080409174555.GC28294@game.jcrosoft.org>
References: <20080408210433.AC07424842@gemini.denx.de>
	<47FBE16F.9030003@gmail.com>
	<62330506-2BC7-4475-B394-EA38443308FB@kernel.crashing.org>
	<20080409174555.GC28294@game.jcrosoft.org>
Message-ID: <47FD058C.4000703@gmail.com>

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:49 Tue 08 Apr     , Kumar Gala wrote:
>   
>> On Apr 8, 2008, at 4:19 PM, Ben Warren wrote:
>>     
>>> Wolfgang Denk wrote:
>>>       
>>>> In message <1207677657-31722-1-git-send-email-vapier at gentoo.org>  
>>>> you wrote:
>>>>
>>>>         
>>>>> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
>>>>>
>>>>>           
>>>> Hm... is anybody using SVN for U-Boot?
>>>>
>>>> Best regards,
>>>>
>>>> Wolfgang Denk
>>>>
>>>>
>>>>         
>>> I used it at my last company and will most certainly use it again, and
>>> appreciate this patch.  I think it's very popular in companies that
>>> prefer free, more traditional revision control.
>>>       
>> bah, use git :)
>>     
>
> Yeah, use git or at least git-svn
>
> Best Regards,
> J.
>
>   
Easy to say, isn't it.  OTOH, this patch doesn't really add complexity, 
doesn't increase code size and nobody gets hurt.  Why not include it?

regards,
Ben



From avinashs36 at yahoo.com  Wed Apr  9 20:33:50 2008
From: avinashs36 at yahoo.com (Avinash Vijayvergia)
Date: Wed, 9 Apr 2008 11:33:50 -0700 (PDT)
Subject: [U-Boot-Users] Generate list file
Message-ID: <373564.46521.qm@web39502.mail.mud.yahoo.com>

Hi All

I had a question which is trivial but I couldn't find an answer to it. Can anyone tell me how do I generate a list filefrom gcc compiler or even preferred is listing with the interspersed Ccode.

Thanks
Avinash


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080409/6cf77345/attachment.htm 

From gerald.vanbaren at ge.com  Wed Apr  9 21:35:46 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Wed, 09 Apr 2008 15:35:46 -0400
Subject: [U-Boot-Users] Generate list file
In-Reply-To: <373564.46521.qm@web39502.mail.mud.yahoo.com>
References: <373564.46521.qm@web39502.mail.mud.yahoo.com>
Message-ID: <47FD1A92.5020804@ge.com>

Avinash Vijayvergia wrote:
> Hi All
> 
> I had a question which is trivial but I couldn't find an answer to it. 
> Can anyone tell me how do I generate a list file from gcc compiler or 
> even preferred is listing with the interspersed C code.
> 
> Thanks
> Avinash

If I understand your question, I think you are asking for a disassembly 
output:
   objdump -d
or, better, a disassembly interspersed with source:
   objdump -S

<http://www.delorie.com/gnu/docs/binutils/binutils_6.html>

Best regards,
gvb



From tur at semihalf.com  Wed Apr  9 23:37:34 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Wed, 09 Apr 2008 23:37:34 +0200
Subject: [U-Boot-Users] [PATCH] Memory footprint optimizations
Message-ID: <20080409213733.5006.37998.stgit@pollux.denx.de>

As suggested by Wolfgang Denk:
- remove wrappers for image printing function
- merge getenv_verify and getenv_autostart into one parametrized function

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 board/mpl/common/common_util.c |    2 +-
 board/siemens/common/fpga.c    |    2 +-
 common/cmd_autoscript.c        |    2 +-
 common/cmd_bootm.c             |   14 +++++++------
 common/cmd_doc.c               |    4 ++--
 common/cmd_fdc.c               |    4 ++--
 common/cmd_ide.c               |    4 ++--
 common/cmd_nand.c              |    8 ++++---
 common/cmd_scsi.c              |    4 ++--
 common/cmd_usb.c               |    4 ++--
 common/cmd_ximg.c              |    4 ++--
 common/image.c                 |   43 ++++++++--------------------------------
 include/image.h                |    9 +++-----
 lib_ppc/bootm.c                |    2 +-
 tools/mkimage.c                |    6 +++---
 15 files changed, 42 insertions(+), 70 deletions(-)

diff --git a/board/mpl/common/common_util.c b/board/mpl/common/common_util.c
index 785d204..5bbd0d3 100644
--- a/board/mpl/common/common_util.c
+++ b/board/mpl/common/common_util.c
@@ -192,7 +192,7 @@ mpl_prg_image(uchar *ld_addr)
 		puts("Bad Magic Number\n");
 		return 1;
 	}
-	image_print_contents (hdr);
+	image_print_contents (hdr, "   ");
 	if (!image_check_os (hdr, IH_OS_U_BOOT)) {
 		puts("No U-Boot Image\n");
 		return 1;
diff --git a/board/siemens/common/fpga.c b/board/siemens/common/fpga.c
index 48c1850..ac0022e 100644
--- a/board/siemens/common/fpga.c
+++ b/board/siemens/common/fpga.c
@@ -160,7 +160,7 @@ static int fpga_load (fpga_t* fpga, ulong addr, int checkall)
     data = (uchar*)image_get_data (hdr);
     len  = image_get_data_size (hdr);
 
-    verify = getenv_verify ();
+    verify = getenv_yesno ("verify");
     if (verify) {
 	if (!image_check_dcrc (hdr)) {
 	    strcpy (msg, "Bad Image Data CRC");
diff --git a/common/cmd_autoscript.c b/common/cmd_autoscript.c
index 1a37b90..932f638 100644
--- a/common/cmd_autoscript.c
+++ b/common/cmd_autoscript.c
@@ -65,7 +65,7 @@ autoscript (ulong addr, const char *fit_uname)
 	size_t		fit_len;
 #endif
 
-	verify = getenv_verify ();
+	verify = getenv_yesno ("verify");
 
 	switch (genimg_get_format ((void *)addr)) {
 	case IMAGE_FORMAT_LEGACY:
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9e5ce4b..94988d9 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -133,8 +133,8 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 	struct lmb lmb;
 
 	memset ((void *)&images, 0, sizeof (images));
-	images.verify = getenv_verify();
-	images.autostart = getenv_autostart();
+	images.verify = getenv_yesno ("verify");
+	images.autostart = getenv_yesno ("autostart");
 	images.lmb = &lmb;
 
 	lmb_init(&lmb);
@@ -377,7 +377,7 @@ static image_header_t *image_get_kernel (ulong img_addr, int verify)
 	}
 
 	show_boot_progress (3);
-	image_print_contents (hdr);
+	image_print_contents (hdr, "   ");
 
 	if (verify) {
 		puts ("   Verifying Checksum ... ");
@@ -714,7 +714,7 @@ static int image_info (ulong addr)
 			return 1;
 		}
 
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 
 		puts ("   Verifying Checksum ... ");
 		if (!image_check_dcrc (hdr)) {
@@ -732,7 +732,7 @@ static int image_info (ulong addr)
 			return 1;
 		}
 
-		fit_print_contents (hdr);
+		fit_print_contents (hdr, "   ");
 		return 0;
 #endif
 	default:
@@ -781,7 +781,7 @@ int do_imls (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 					goto next_sector;
 
 				printf ("Legacy Image at %08lX:\n", (ulong)hdr);
-				image_print_contents (hdr);
+				image_print_contents (hdr, "   ");
 
 				puts ("   Verifying Checksum ... ");
 				if (!image_check_dcrc (hdr)) {
@@ -796,7 +796,7 @@ int do_imls (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 					goto next_sector;
 
 				printf ("FIT Image at %08lX:\n", (ulong)hdr);
-				fit_print_contents (hdr);
+				fit_print_contents (hdr, "   ");
 				break;
 #endif
 			default:
diff --git a/common/cmd_doc.c b/common/cmd_doc.c
index 83aba37..1b645e5 100644
--- a/common/cmd_doc.c
+++ b/common/cmd_doc.c
@@ -268,7 +268,7 @@ int do_docboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 	case IMAGE_FORMAT_LEGACY:
 		hdr = (image_header_t *)addr;
 
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 
 		cnt = image_get_image_size (hdr);
 		break;
@@ -305,7 +305,7 @@ int do_docboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 #if defined(CONFIG_FIT)
 	/* This cannot be done earlier, we need complete FIT image in RAM first */
 	if (genimg_get_format ((void *)addr) == IMAGE_FORMAT_FIT)
-		fit_print_contents ((const void *)addr);
+		fit_print_contents ((const void *)addr, "   ");
 #endif
 
 	/* Loading ok, update default load address */
diff --git a/common/cmd_fdc.c b/common/cmd_fdc.c
index bf28370..2097a54 100644
--- a/common/cmd_fdc.c
+++ b/common/cmd_fdc.c
@@ -842,7 +842,7 @@ int do_fdcboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 	switch (genimg_get_format ((void *)addr)) {
 	case IMAGE_FORMAT_LEGACY:
 		hdr = (image_header_t *)addr;
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 
 		imsize = image_get_image_size (hdr);
 		break;
@@ -882,7 +882,7 @@ int do_fdcboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 #if defined(CONFIG_FIT)
 	/* This cannot be done earlier, we need complete FIT image in RAM first */
 	if (genimg_get_format ((void *)addr) == IMAGE_FORMAT_FIT)
-		fit_print_contents ((const void *)addr);
+		fit_print_contents ((const void *)addr, "   ");
 #endif
 
 	/* Loading ok, update default load address */
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 8ace970..c2ba996 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -462,7 +462,7 @@ int do_diskboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		}
 		show_boot_progress (50);
 
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 
 		cnt = image_get_image_size (hdr);
 		break;
@@ -501,7 +501,7 @@ int do_diskboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 #if defined(CONFIG_FIT)
 	/* This cannot be done earlier, we need complete FIT image in RAM first */
 	if (genimg_get_format ((void *)addr) == IMAGE_FORMAT_FIT)
-		fit_print_contents ((const void *)addr);
+		fit_print_contents ((const void *)addr, "   ");
 #endif
 
 	/* Loading ok, update default load address */
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 7b1f830..d92c554 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -520,7 +520,7 @@ static int nand_load_image(cmd_tbl_t *cmdtp, nand_info_t *nand,
 		hdr = (image_header_t *)addr;
 
 		show_boot_progress (57);
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 
 		cnt = image_get_image_size (hdr);
 		break;
@@ -566,7 +566,7 @@ static int nand_load_image(cmd_tbl_t *cmdtp, nand_info_t *nand,
 #if defined(CONFIG_FIT)
 	/* This cannot be done earlier, we need complete FIT image in RAM first */
 	if (genimg_get_format ((void *)addr) == IMAGE_FORMAT_FIT)
-		fit_print_contents ((const void *)addr);
+		fit_print_contents ((const void *)addr, "   ");
 #endif
 
 	/* Loading ok, update default load address */
@@ -1013,7 +1013,7 @@ int do_nandboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 	switch (genimg_get_format ((void *)addr)) {
 	case IMAGE_FORMAT_LEGACY:
 		hdr = (image_header_t *)addr;
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 
 		cnt = image_get_image_size (hdr);
 		cnt -= SECTORSIZE;
@@ -1051,7 +1051,7 @@ int do_nandboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 #if defined(CONFIG_FIT)
 	/* This cannot be done earlier, we need complete FIT image in RAM first */
 	if (genimg_get_format ((void *)addr) == IMAGE_FORMAT_FIT)
-		fit_print_contents ((const void *)addr);
+		fit_print_contents ((const void *)addr, "   ");
 #endif
 
 	/* Loading ok, update default load address */
diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index f49531e..bc3dedb 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -285,7 +285,7 @@ int do_scsiboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 			return 1;
 		}
 
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 		cnt = image_get_image_size (hdr);
 		break;
 #if defined(CONFIG_FIT)
@@ -318,7 +318,7 @@ int do_scsiboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 #if defined(CONFIG_FIT)
 	/* This cannot be done earlier, we need complete FIT image in RAM first */
 	if (genimg_get_format ((void *)addr) == IMAGE_FORMAT_FIT)
-		fit_print_contents ((const void *)addr);
+		fit_print_contents ((const void *)addr, "   ");
 #endif
 
 	/* Loading ok, update default load address */
diff --git a/common/cmd_usb.c b/common/cmd_usb.c
index 23413b5..62dead5 100644
--- a/common/cmd_usb.c
+++ b/common/cmd_usb.c
@@ -397,7 +397,7 @@ int do_usbboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 			return 1;
 		}
 
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 
 		cnt = image_get_image_size (hdr);
 		break;
@@ -431,7 +431,7 @@ int do_usbboot (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 #if defined(CONFIG_FIT)
 	/* This cannot be done earlier, we need complete FIT image in RAM first */
 	if (genimg_get_format ((void *)addr) == IMAGE_FORMAT_FIT)
-		fit_print_contents ((const void *)addr);
+		fit_print_contents ((const void *)addr, "   ");
 #endif
 
 	/* Loading ok, update default load address */
diff --git a/common/cmd_ximg.c b/common/cmd_ximg.c
index 7916fc1..9e94e1e 100644
--- a/common/cmd_ximg.c
+++ b/common/cmd_ximg.c
@@ -51,7 +51,7 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 	size_t		fit_len;
 #endif
 
-	verify = getenv_verify ();
+	verify = getenv_yesno ("verify");
 
 	if (argc > 1) {
 		addr = simple_strtoul(argv[1], NULL, 16);
@@ -83,7 +83,7 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 			return 1;
 		}
 #ifdef DEBUG
-		image_print_contents (hdr);
+		image_print_contents (hdr, "   ");
 #endif
 
 		if (!image_check_type (hdr, IH_TYPE_MULTI)) {
diff --git a/common/image.c b/common/image.c
index f04826a..35356bd 100644
--- a/common/image.c
+++ b/common/image.c
@@ -316,18 +316,18 @@ static void image_print_type (image_header_t *hdr)
 }
 
 /**
- * __image_print_contents - prints out the contents of the legacy format image
+ * image_print_contents - prints out the contents of the legacy format image
  * @hdr: pointer to the legacy format image header
  * @p: pointer to prefix string
  *
- * __image_print_contents() formats a multi line legacy image contents description.
+ * image_print_contents() formats a multi line legacy image contents description.
  * The routine prints out all header fields followed by the size/offset data
  * for MULTI/SCRIPT images.
  *
  * returns:
  *     no returned results
  */
-static void __image_print_contents (image_header_t *hdr, const char *p)
+void image_print_contents (image_header_t *hdr, const char *p)
 {
 	printf ("%sImage Name:   %.*s\n", p, IH_NMLEN, image_get_name (hdr));
 #if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) || defined(USE_HOSTCC)
@@ -366,15 +366,6 @@ static void __image_print_contents (image_header_t *hdr, const char *p)
 	}
 }
 
-inline void image_print_contents (image_header_t *hdr)
-{
-	__image_print_contents (hdr, "   ");
-}
-
-inline void image_print_contents_noindent (image_header_t *hdr)
-{
-	__image_print_contents (hdr, "");
-}
 
 #ifndef USE_HOSTCC
 /**
@@ -413,7 +404,7 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 	}
 
 	show_boot_progress (10);
-	image_print_contents (rd_hdr);
+	image_print_contents (rd_hdr, "   ");
 
 	if (verify) {
 		puts("   Verifying Checksum ... ");
@@ -444,15 +435,9 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 /* Shared dual-format routines */
 /*****************************************************************************/
 #ifndef USE_HOSTCC
-int getenv_verify (void)
+int getenv_yesno (char *var)
 {
-	char *s = getenv ("verify");
-	return (s && (*s == 'n')) ? 0 : 1;
-}
-
-int getenv_autostart (void)
-{
-	char *s = getenv ("autostart");
+	char *s = getenv (var);
 	return (s && (*s == 'n')) ? 0 : 1;
 }
 
@@ -1265,18 +1250,18 @@ static void fit_get_debug (const void *fit, int noffset,
 }
 
 /**
- * __fit_print_contents - prints out the contents of the FIT format image
+ * fit_print_contents - prints out the contents of the FIT format image
  * @fit: pointer to the FIT format image header
  * @p: pointer to prefix string
  *
- * __fit_print_contents() formats a multi line FIT image contents description.
+ * fit_print_contents() formats a multi line FIT image contents description.
  * The routine prints out FIT image properties (root node level) follwed by
  * the details of each component image.
  *
  * returns:
  *     no returned results
  */
-static void __fit_print_contents (const void *fit, const char *p)
+void fit_print_contents (const void *fit, const char *p)
 {
 	char *desc;
 	char *uname;
@@ -1361,16 +1346,6 @@ static void __fit_print_contents (const void *fit, const char *p)
 	}
 }
 
-inline void fit_print_contents (const void *fit)
-{
-	__fit_print_contents (fit, "   ");
-}
-
-inline void fit_print_contents_noindent (const void *fit)
-{
-	__fit_print_contents (fit, "");
-}
-
 /**
  * fit_image_print - prints out the FIT component image details
  * @fit: pointer to the FIT format image header
diff --git a/include/image.h b/include/image.h
index 36143e2..dbcee1c 100644
--- a/include/image.h
+++ b/include/image.h
@@ -363,8 +363,7 @@ int image_check_hcrc (image_header_t *hdr);
 int image_check_dcrc (image_header_t *hdr);
 #ifndef USE_HOSTCC
 int image_check_dcrc_wd (image_header_t *hdr, ulong chunksize);
-int getenv_verify (void);
-int getenv_autostart (void);
+int getenv_yesno (char *var);
 ulong getenv_bootm_low(void);
 ulong getenv_bootm_size(void);
 void memmove_wd (void *to, void *from, size_t len, ulong chunksz);
@@ -391,8 +390,7 @@ ulong image_multi_count (image_header_t *hdr);
 void image_multi_getimg (image_header_t *hdr, ulong idx,
 			ulong *data, ulong *len);
 
-inline void image_print_contents (image_header_t *hdr);
-inline void image_print_contents_noindent (image_header_t *hdr);
+void image_print_contents (image_header_t *hdr, const char *p);
 
 #ifndef USE_HOSTCC
 static inline int image_check_target_arch (image_header_t *hdr)
@@ -466,8 +464,7 @@ inline int fit_parse_conf (const char *spec, ulong addr_curr,
 inline int fit_parse_subimage (const char *spec, ulong addr_curr,
 		ulong *addr, const char **image_name);
 
-inline void fit_print_contents (const void *fit);
-inline void fit_print_contents_noindent (const void *fit);
+void fit_print_contents (const void *fit, const char *p);
 void fit_image_print (const void *fit, int noffset, const char *p);
 void fit_image_print_hash (const void *fit, int noffset, const char *p);
 
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 2901607..7ba0138 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -319,7 +319,7 @@ static image_header_t *image_get_fdt (ulong fdt_addr)
 {
 	image_header_t *fdt_hdr = (image_header_t *)fdt_addr;
 
-	image_print_contents (fdt_hdr);
+	image_print_contents (fdt_hdr, "   ");
 
 	puts ("   Verifying Checksum ... ");
 	if (!image_check_hcrc (fdt_hdr)) {
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 6e1ff2b..8a55793 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -229,10 +229,10 @@ NXTARG:		;
 		if (fdt_check_header (ptr)) {
 			/* old-style image */
 			image_verify_header ((char *)ptr, sbuf.st_size);
-			image_print_contents_noindent ((image_header_t *)ptr);
+			image_print_contents ((image_header_t *)ptr, "");
 		} else {
 			/* FIT image */
-			fit_print_contents_noindent (ptr);
+			fit_print_contents (ptr, "");
 		}
 
 		(void) munmap((void *)ptr, sbuf.st_size);
@@ -363,7 +363,7 @@ NXTARG:		;
 
 	image_set_hcrc (hdr, checksum);
 
-	image_print_contents_noindent (hdr);
+	image_print_contents (hdr, "");
 
 	(void) munmap((void *)ptr, sbuf.st_size);
 




From tur at semihalf.com  Wed Apr  9 23:39:21 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Wed, 09 Apr 2008 23:39:21 +0200
Subject: [U-Boot-Users] [PATCH] Document 'bootm_low' and 'bootm_size'
	environment variables
Message-ID: <20080409213830.5053.60908.stgit@pollux.denx.de>

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---
Kumar, this patch pertains to your commit "[new uImage] Provide ability to
restrict region used for boot images", id d3f2fa0d -- could you review
and confirm that the documentation is OK? Thanks.

 README |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/README b/README
index 5d059e7..a0dfe73 100644
--- a/README
+++ b/README
@@ -1995,7 +1995,10 @@ Configuration Settings:
 		Maximum size of memory mapped by the startup code of
 		the Linux kernel; all data that must be processed by
 		the Linux kernel (bd_info, boot arguments, eventually
-		initrd image) must be put below this limit.
+		initrd image) must be put below this limit, unless
+		"bootm_low" enviroment variable is defined and non-zero.
+		In such case all data for the Linux kernel must be
+		between "bootm_low" and "bootm_low" + CFG_BOOTMAPSZ.
 
 - CFG_MAX_FLASH_BANKS:
 		Max number of Flash memory banks
@@ -2733,6 +2736,20 @@ Some configuration options can be set using Environment Variables:
 
   bootfile	- Name of the image to load with TFTP
 
+  bootm_low	- Memory range available for image processing in the bootm
+		  command can be restricted. This variable is given as
+		  a hexadecimal number and defines lowest address allowed
+		  for use by the bootm command. See also "bootm_size"
+		  environment variable. Address defined by "bootm_low" is
+		  also the base of the initial memory mapping for the Linux
+		  kernel -- see the descripton of CFG_BOOTMAPSZ.
+
+  bootm_size	- Memory range available for image processing in the bootm
+		  command can be restricted. This variable is given as
+		  a hexadecimal number and defines the size of the region
+		  allowed for use by the bootm command. See also "bootm_low"
+		  environment variable.
+
   autoload	- if set to "no" (any string beginning with 'n'),
 		  "bootp" will just load perform a lookup of the
 		  configuration from the BOOTP server, but not try to




From galak at kernel.crashing.org  Thu Apr 10 00:08:24 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 9 Apr 2008 17:08:24 -0500
Subject: [U-Boot-Users] [PATCH] Document 'bootm_low' and 'bootm_size'
	environment variables
In-Reply-To: <20080409213830.5053.60908.stgit@pollux.denx.de>
References: <20080409213830.5053.60908.stgit@pollux.denx.de>
Message-ID: <338C97F4-E6A0-47B3-94AB-3D8E6EA9BBDA@kernel.crashing.org>


On Apr 9, 2008, at 4:39 PM, Bartlomiej Sieka wrote:
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> Kumar, this patch pertains to your commit "[new uImage] Provide  
> ability to
> restrict region used for boot images", id d3f2fa0d -- could you review
> and confirm that the documentation is OK? Thanks.
>
> README |   19 ++++++++++++++++++-
> 1 files changed, 18 insertions(+), 1 deletions(-)
>
> diff --git a/README b/README
> index 5d059e7..a0dfe73 100644
> --- a/README
> +++ b/README
> @@ -1995,7 +1995,10 @@ Configuration Settings:
> 		Maximum size of memory mapped by the startup code of
> 		the Linux kernel; all data that must be processed by
> 		the Linux kernel (bd_info, boot arguments, eventually
> -		initrd image) must be put below this limit.
> +		initrd image) must be put below this limit, unless
> +		"bootm_low" enviroment variable is defined and non-zero.
> +		In such case all data for the Linux kernel must be
> +		between "bootm_low" and "bootm_low" + CFG_BOOTMAPSZ.

all data seems misleading since initrd doesn't have to be within  
CFG_BOOTMAPSZ.

> - CFG_MAX_FLASH_BANKS:
> 		Max number of Flash memory banks
> @@ -2733,6 +2736,20 @@ Some configuration options can be set using  
> Environment Variables:
>
>   bootfile	- Name of the image to load with TFTP
>
> +  bootm_low	- Memory range available for image processing in the  
> bootm
> +		  command can be restricted. This variable is given as
> +		  a hexadecimal number and defines lowest address allowed
> +		  for use by the bootm command. See also "bootm_size"
> +		  environment variable. Address defined by "bootm_low" is
> +		  also the base of the initial memory mapping for the Linux
> +		  kernel -- see the descripton of CFG_BOOTMAPSZ.

>
> +
> +  bootm_size	- Memory range available for image processing in the  
> bootm
> +		  command can be restricted. This variable is given as
> +		  a hexadecimal number and defines the size of the region
> +		  allowed for use by the bootm command. See also "bootm_low"
> +		  environment variable.
> +

these look fine.

- k



From wd at denx.de  Thu Apr 10 00:56:10 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 10 Apr 2008 00:56:10 +0200
Subject: [U-Boot-Users] [PATCH] Memory footprint optimizations
In-Reply-To: Your message of "Wed, 09 Apr 2008 23:37:34 +0200."
	<20080409213733.5006.37998.stgit@pollux.denx.de>
Message-ID: <20080409225610.6043224842@gemini.denx.de>

In message <20080409213733.5006.37998.stgit at pollux.denx.de> you wrote:
> As suggested by Wolfgang Denk:
> - remove wrappers for image printing function
> - merge getenv_verify and getenv_autostart into one parametrized function
...
> -	image_print_contents (hdr);
> +	image_print_contents (hdr, "   ");

Now we have some 20+ calls of

	image_print_contents (hdr, "   ");

plus two calls of

	image_print_contents (hdr, "");

Maybe there is some clever way to get rid of this second argument?

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: wd at denx.de
Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenst?n-
de (Mausbewegung) und "ga" sagen  (Mausklick)  abzukommen,  zugunsten
eines  m?chtigeren  und langwierig zu erlernenden Tools (Sprache).
                             -- Achim Linder in de.comp.os.linux.misc



From kenneth at southpole.se  Thu Apr 10 01:00:04 2008
From: kenneth at southpole.se (kenneth johansson)
Date: Thu, 10 Apr 2008 01:00:04 +0200
Subject: [U-Boot-Users] Fixup entries
In-Reply-To: <005a01c89a5d$8e9c67b0$abd53710$@Tjernlund@transmode.se>
References: <1207733537.6954.32.camel@localhost.localdomain>
	<1207740219.5826.71.camel@gentoo-jocke.transmode.se>
	<1207752413.6954.52.camel@localhost.localdomain>
	<005a01c89a5d$8e9c67b0$abd53710$@Tjernlund@transmode.se>
Message-ID: <1207782004.8774.6.camel@duo>

On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote:
> 
> > -----Original Message-----
> > From: Kenneth Johansson [mailto:kenneth at southpole.se]
> > Wonder if there is something else in u-boot that use function pointers
> > and work by accident due to the fact that the old address in flash is
> > still valid.
> 
> Oh yes, there are a few such pointers. And the conversion to using fixups instead
> is a bit lazy. Several manual relocations has only been nullified by setting 
> gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel
> free to send patches :)
> 
>     Jocke
> 

If by lazy you mean less error prone and obviously simpler :). clearly
using -mrelocatable is the smarter thing to do. 

I had this misconception that the GOT was all that was needed for
relocation.
Could not find any useful information on what rules apply to gcc and
binutils for handling stuff in this fixup section. 

Anybody have any information on this?






From Joakim.Tjernlund at transmode.se  Thu Apr 10 01:03:27 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Thu, 10 Apr 2008 01:03:27 +0200
Subject: [U-Boot-Users] Fixup entries
In-Reply-To: <1207782004.8774.6.camel@duo>
References: <1207733537.6954.32.camel@localhost.localdomain>	
	<1207740219.5826.71.camel@gentoo-jocke.transmode.se>	
	<1207752413.6954.52.camel@localhost.localdomain>	
	<005a01c89a5d$8e9c67b0$abd53710$@Tjernlund@transmode.se>
	<1207782004.8774.6.camel@duo>
Message-ID: <009e01c89a95$ebd30960$c3791c20$@Tjernlund@transmode.se>

> -----Original Message-----
> From: kenneth johansson [mailto:kenneth at southpole.se]
> Sent: den 10 april 2008 01:00
> To: Joakim Tjernlund
> Cc: u-boot-users at lists.sourceforge.net
> Subject: RE: [U-Boot-Users] Fixup entries
> 
> On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote:
> >
> > > -----Original Message-----
> > > From: Kenneth Johansson [mailto:kenneth at southpole.se]
> > > Wonder if there is something else in u-boot that use function pointers
> > > and work by accident due to the fact that the old address in flash is
> > > still valid.
> >
> > Oh yes, there are a few such pointers. And the conversion to using fixups instead
> > is a bit lazy. Several manual relocations has only been nullified by setting
> > gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel
> > free to send patches :)
> >
> >     Jocke
> >
> 
> If by lazy you mean less error prone and obviously simpler :). clearly
> using -mrelocatable is the smarter thing to do.
> 
> I had this misconception that the GOT was all that was needed for
> relocation.
> Could not find any useful information on what rules apply to gcc and
> binutils for handling stuff in this fixup section.
> 
> Anybody have any information on this?

Nope, never found anything either. To see a working one in u-boot, look at
mpc83xx start.S and its linker scripts.

 Jocke




From kenneth at southpole.se  Thu Apr 10 01:52:52 2008
From: kenneth at southpole.se (kenneth johansson)
Date: Thu, 10 Apr 2008 01:52:52 +0200
Subject: [U-Boot-Users] Fixup entries
In-Reply-To: <009e01c89a95$ebd30960$c3791c20$@Tjernlund@transmode.se>
References: <1207733537.6954.32.camel@localhost.localdomain>
	<1207740219.5826.71.camel@gentoo-jocke.transmode.se>
	<1207752413.6954.52.camel@localhost.localdomain>
	<005a01c89a5d$8e9c67b0$abd53710$@Tjernlund@transmode.se>
	<1207782004.8774.6.camel@duo>
	<009e01c89a95$ebd30960$c3791c20$@Tjernlund@transmode.se>
Message-ID: <1207785172.8774.9.camel@duo>

On Thu, 2008-04-10 at 01:03 +0200, Joakim Tjernlund wrote:
> > -----Original Message-----
> > From: kenneth johansson [mailto:kenneth at southpole.se]
> > Sent: den 10 april 2008 01:00
> > To: Joakim Tjernlund
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: RE: [U-Boot-Users] Fixup entries
> > 
> > On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote:
> > >
> > > > -----Original Message-----
> > > > From: Kenneth Johansson [mailto:kenneth at southpole.se]
> > > > Wonder if there is something else in u-boot that use function pointers
> > > > and work by accident due to the fact that the old address in flash is
> > > > still valid.
> > >
> > > Oh yes, there are a few such pointers. And the conversion to using fixups instead
> > > is a bit lazy. Several manual relocations has only been nullified by setting
> > > gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel
> > > free to send patches :)
> > >
> > >     Jocke
> > >
> > 
> > If by lazy you mean less error prone and obviously simpler :). clearly
> > using -mrelocatable is the smarter thing to do.
> > 
> > I had this misconception that the GOT was all that was needed for
> > relocation.
> > Could not find any useful information on what rules apply to gcc and
> > binutils for handling stuff in this fixup section.
> > 
> > Anybody have any information on this?
> 
> Nope, never found anything either. To see a working one in u-boot, look at
> mpc83xx start.S and its linker scripts.

I have it working that is not the problem the problem is that I would
like to know why it is :-)





From plagnioj at jcrosoft.com  Thu Apr 10 03:25:18 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 10 Apr 2008 03:25:18 +0200
Subject: [U-Boot-Users] [PATCH] Fix regression introduced by a typo
	in	"Tidied other cpu/arm920t/start.S code"
In-Reply-To: <Pine.LNX.4.64.0804091725330.5671@axis700.grange>
References: <Pine.LNX.4.64.0804091725330.5671@axis700.grange>
Message-ID: <20080410012518.GE28294@game.jcrosoft.org>

On 17:34 Wed 09 Apr     , Guennadi Liakhovetski wrote:
> Restore logic reverted by commit
> 
> commit 80767a6cead9990d9e77e62be947843c2c72f469
> Author: Peter Pearse <peter.pearse at arm.com>
> Date:   Wed Sep 5 16:04:41 2007 +0100
> 
>     Changed API name to coloured_led.h
>     Removed code using deprecated ifdef CONFIG_BOOTBINFUNC
>     Tidied other cpu/arm920t/start.S code
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
> 
> commit 4edc89c17c34c10885082ddbc73b9416e8ff4f5a
> Author: Guennadi Liakhovetski <lyakh at 6a.(none)>
> Date:   Wed Apr 9 17:05:52 2008 +0200
> 
>     Fix reverted ifdef
>     
>     Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> diff --git a/cpu/arm920t/start.S b/cpu/arm920t/start.S
> index ae86002..acc00ad 100644
> --- a/cpu/arm920t/start.S
> +++ b/cpu/arm920t/start.S
> @@ -178,7 +178,7 @@ copyex:
>  	bl	cpu_init_crit
>  #endif
>  
> -#ifdef	CONFIG_AT91RM9200
> +#ifndef	CONFIG_AT91RM9200
>  
>  #ifndef CONFIG_SKIP_RELOCATE_UBOOT
>  relocate:				/* relocate U-Boot to RAM	    */
we can regroup the ifdef

#if !defined(CONFIG_AT91RM9200) && !defined(CONFIG_SKIP_RELOCATE_UBOOT)

otherwise

Ack-by : Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Best Regards,
J.

> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users



From shenzhenshanhudao at 126.com  Thu Apr 10 03:48:22 2008
From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=)
Date: Thu, 10 Apr 2008 09:48:22 +0800
Subject: [U-Boot-Users] (no subject)
Message-ID: <E1Jjlth-0005F8-2R@mail.sourceforge.net>




             ?????????
                
                 ??????2008?????????????????????????
?
             ??????????????????????????????
    
                 ?????????????????????????????????
?
            ???????????????????????????......?????

            ???????????????????????????????????

            ???????????????????
?
                                          ???0755-81153047?
?
                                          ???0755-81172940?
?
                                          ???15817477278?
?
                                          ????????
?
                        ???
                                                                       

                                                                         ???



From vapier at gentoo.org  Thu Apr 10 05:31:16 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 9 Apr 2008 23:31:16 -0400
Subject: [U-Boot-Users]
	=?iso-8859-1?q?=5BPATCH=5D_Add_support_for_u-boot_?=
	=?iso-8859-1?q?in_svn_and=09localversion-*_files?=
In-Reply-To: <47FD058C.4000703@gmail.com>
References: <20080408210433.AC07424842@gemini.denx.de>
	<20080409174555.GC28294@game.jcrosoft.org>
	<47FD058C.4000703@gmail.com>
Message-ID: <200804092331.17140.vapier@gentoo.org>

On Wednesday 09 April 2008, Ben Warren wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 16:49 Tue 08 Apr     , Kumar Gala wrote:
> >> On Apr 8, 2008, at 4:19 PM, Ben Warren wrote:
> >>> Wolfgang Denk wrote:
> >>>> In message <1207677657-31722-1-git-send-email-vapier at gentoo.org>
> >>>>
> >>>> you wrote:
> >>>>> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> >>>>
> >>>> Hm... is anybody using SVN for U-Boot?
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Wolfgang Denk
> >>>
> >>> I used it at my last company and will most certainly use it again, and
> >>> appreciate this patch.  I think it's very popular in companies that
> >>> prefer free, more traditional revision control.
> >>
> >> bah, use git :)
> >
> > Yeah, use git or at least git-svn
>
> Easy to say, isn't it.  OTOH, this patch doesn't really add complexity,
> doesn't increase code size and nobody gets hurt.  Why not include it?

pretty much.  while i may be able to use git, not everyone is fluent in it, 
and forcing them to use git is simply a waste of time.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080409/cfcac316/attachment.pgp 

From sew_s at tqs.de  Thu Apr 10 07:39:16 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Thu, 10 Apr 2008 07:39:16 +0200
Subject: [U-Boot-Users] Generate list file
In-Reply-To: <47FD1A92.5020804@ge.com>
References: <373564.46521.qm@web39502.mail.mud.yahoo.com>
	<47FD1A92.5020804@ge.com>
Message-ID: <47FDA804.1080707@tqs.de>

Hi,

Jerry Van Baren schrieb:
> Avinash Vijayvergia wrote:
>> Hi All
>>
>> I had a question which is trivial but I couldn't find an answer to it. 
>> Can anyone tell me how do I generate a list file from gcc compiler or 
>> even preferred is listing with the interspersed C code.
>>
>> Thanks
>> Avinash
> 
> If I understand your question, I think you are asking for a disassembly 
> output:
>    objdump -d
> or, better, a disassembly interspersed with source:
>    objdump -S
> 
> <http://www.delorie.com/gnu/docs/binutils/binutils_6.html>

The following works for me, too:

diff --git a/config.mk b/config.mk
index 22d3398..b6ad763 100644
--- a/config.mk
+++ b/config.mk
@@ -237,7 +237,7 @@ ifndef REMOTE_BUILD
  %.o:	%.S
  	$(CC) $(AFLAGS) -c -o $@ $<
  %.o:	%.c
-	$(CC) $(CFLAGS) -c -o $@ $<
+	$(CC) $(CFLAGS) -Wa,-ahlncds=$(subst .o,.lst,$@) -c -o $@ $<

But Jerry's solution is better in that you don't have to recompile the 
U-Boot, right?

Best Regards
Jens



From shenzhenshanhudao at 126.com  Thu Apr 10 08:43:10 2008
From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=)
Date: Thu, 10 Apr 2008 14:43:10 +0800
Subject: [U-Boot-Users] (no subject)
Message-ID: <E1JjqV2-0003b7-JL@mail.sourceforge.net>




             ?????????
                
                 ??????2008?????????????????????????
?
             ??????????????????????????????
    
                 ?????????????????????????????????
?
            ???????????????????????????......?????

            ???????????????????????????????????

            ???????????????????
?
                                          ???0755-81153047?
?
                                          ???0755-81172940?
?
                                          ???15817477278?
?
                                          ????????
?
                        ???
                                                                       

                                                                         ???



From plagnioj at jcrosoft.com  Thu Apr 10 10:31:35 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 10 Apr 2008 10:31:35 +0200
Subject: [U-Boot-Users] [PATCH] qemu-mips: add CFI support
Message-ID: <1207816295-9586-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index e164019..7ee6fd4 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -33,7 +33,7 @@
 #define CONFIG_MISC_INIT_R
 
 /*IP address is default used by Qemu*/
-#define CONFIG_IPADDR		10.0.2.15    	     /* Our IP address */
+#define CONFIG_IPADDR		10.0.2.15	     /* Our IP address */
 #define CONFIG_SERVERIP		10.0.2.2	     /* Server IP address*/
 
 #define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds	*/
@@ -74,16 +74,12 @@
 #define CONFIG_CMD_ELF
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef  CONFIG_CMD_IMLS
-#undef  CONFIG_CMD_FLASH
-#undef  CONFIG_CMD_LOADB
-#undef  CONFIG_CMD_LOADS
 #define CONFIG_CMD_DHCP
+#define CONFIG_CMD_PING
 
 #define CONFIG_DRIVER_NE2000
 #define CONFIG_DRIVER_NE2000_BASE	(0xb4000300)
 
-#define CFG_NO_FLASH
 #define CFG_NS16550
 #define CFG_NS16550_SERIAL
 #define CFG_NS16550_REG_SIZE    1
@@ -140,17 +136,23 @@
 
 /* The following #defines are needed to get flash environment right */
 #define	CFG_MONITOR_BASE	TEXT_BASE
-#define	CFG_MONITOR_LEN		(192 << 10)
+#define	CFG_MONITOR_LEN		(192 << 11)
 
 #define CFG_INIT_SP_OFFSET	0x400000
 
 /* We boot from this flash, selected with dip switch */
 #define CFG_FLASH_BASE		0xbfc00000
-
-#define	CFG_ENV_IS_NOWHERE	1
-
+#define	CFG_MAX_FLASH_BANKS	1
+#define	CFG_MAX_FLASH_SECT	128
+#define	CFG_FLASH_CFI		1	/* Flash memory is CFI compliant */
+#define CFG_FLASH_CFI_DRIVER	1
+#define CFG_FLASH_USE_BUFFER_WRITE    1
+
+#define	CFG_ENV_IS_IN_FLASH	1
+#define CFG_ENV_ADDR		(CFG_FLASH_BASE+0x60000)
 /* Address and size of Primary Environment Sector	*/
-#define CFG_ENV_SIZE		0x10000
+#define CFG_ENV_SIZE		0x8000
+
 #undef CONFIG_NET_MULTI
 
 #define MEM_SIZE 128
-- 
1.5.4.5




From andre.schwarz at matrix-vision.de  Thu Apr 10 10:37:26 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 10 Apr 2008 10:37:26 +0200
Subject: [U-Boot-Users] I2C @ MPC8343
Message-ID: <47FDD1C6.3000205@matrix-vision.de>

All,

in my current system the I2C bus is not working properly on a MPC8343 in 
u-boot v1.3.2.

i2c board config includes :

#define CONFIG_HARD_I2C
#undef CONFIG_SOFT_I2C
#define CONFIG_FSL_I2C
#define CONFIG_I2C_MULTI_BUS
#define CONFIG_I2C_CMD_TREE
#define CFG_I2C_OFFSET          0x3000
#define CFG_I2C2_OFFSET         0x3100
#define CFG_I2C_SPEED           100000
#define CFG_I2C_SLAVE           0x7F


chip probing works fine.

mvBL-M7> i2c probe
Valid chip addresses: 30 48 50 68

reading the Chips gives all "ff"

mvBL-M7> i2c md 50 0 10
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................


Observing the I2C bus wires show that everything _works excellent_ :
100kHz speed as well as all data seems ok - but u-boot shows "ff".

BTW:  Fetching HRCW from I2C is also working fine.

After some tries (i2c md ..) the bus hangs and no more transactions can 
be seen on the bus.


regards,
Andre Schwarz
Matrix Vision


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From cain-ektakels at BTIAppraisal.com  Thu Apr 10 11:42:07 2008
From: cain-ektakels at BTIAppraisal.com (Marcellais)
Date: Thu, 10 Apr 2008 11:42:07 +0200
Subject: [U-Boot-Users] Herbal solutions will change your life
Message-ID: <B13EAC38.7%cain-ektakels@BTIAppraisal.com>

A 9 inch organ is just months away http://www.mihugab.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080410/9727ed70/attachment.htm 

From wd at denx.de  Thu Apr 10 12:24:21 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 10 Apr 2008 12:24:21 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: Your message of "Sun, 30 Mar 2008 12:04:34 BST."
	<000801c89255$d637b670$3a4d010a@Emea.Arm.com>
Message-ID: <20080410102421.2BBF1243AB@gemini.denx.de>

Dear Peter,

in message <000801c89255$d637b670$3a4d010a at Emea.Arm.com> you wrote:
>
> These are the patches:
> 
> [PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and cleanup
> [PATCH] DM644x: This patch removes all boardspecific code from the arch part
> for DM644x (DaVinci) boards
> [PATCH] DM644x: (2nd try) This adds support fortheProdrivePMDRA board, based
> on a DM6441
> [PATCH 0/7] Respin of Sascha Hauer's i.MX31support plus MX31ADS
...
> Guennadi Liakhovetski (1):
>       Support for the MX31ADS evaluation board from Freescale
...
> Sascha Hauer (6):
>       Separate omap24xx specific code from arm1136
>       core support for Freescale mx31
>       add an i2c driver for mx31
>       add SMSC LAN9x1x Network driver
>       mx31 litekit support
>       Phytec Phycore-i.MX31 support

I would expect, that the state of the current repository represents
what we get after applying Sascha's and Guennadi's patches (in the
correct versions and order). Howver, the current tree looks totally
different to me.

Can you please check with Guennadi what happened, how this can be
cleaned up, and especially how this can be prevented in the future?

Note that there is not only not the expected state of the source code,
but there is also corruption of meta-information again; for example:

	-> git-show --pretty=fuller 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
	commit 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
	Author:     Guennadi Liakhovetski <[lg at denx.de]>
-------------------------------------------^^^^^^^^^^^^
	AuthorDate: Sun Mar 30 11:32:30 2008 +0100
	Commit:     Peter Pearse <peter.pearse at arm.com>
	CommitDate: Sun Mar 30 11:32:30 2008 +0100

	    Support for the MX31ADS evaluation board from Freescale
	...

None of Guennadis messages on the mailing list  ever  used  something
like "[lg at denx.de]" - this must be something that happend on your end
when  processing  his  patches.  Where  are the brackets coming from?
Don't you use git-am to apply the patches?

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: wd at denx.de
If a man had a child who'd gone  anti-social,  killed  perhaps,  he'd
still tend to protect that child.
	-- McCoy, "The Ultimate Computer", stardate 4731.3



From pierre.savary at kerlink.fr  Thu Apr 10 12:32:59 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Thu, 10 Apr 2008 12:32:59 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <20080409174903.GD28294@game.jcrosoft.org>
References: <003601c89985$5cf10aa0$16d31fe0$@savary@kerlink.fr>
	<20080409174903.GD28294@game.jcrosoft.org>
Message-ID: <001101c89af6$408046c0$c180d440$@savary@kerlink.fr>

I have already test it but the version of the MMC driver is the same... And
it's very difficult for me to update my own version to the current.
Thanks for your help

Pierre

-----Message d'origine-----
De?: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] De la part de
Jean-Christophe PLAGNIOL-VILLARD
Envoy??: mercredi 9 avril 2008 19:49
??: Pierre Savary
Cc?: u-boot-users at lists.sourceforge.net; 'Pierre Ossman'
Objet?: Re: [U-Boot-Users] drivers MMCplus for at91sam9x

On 16:32 Tue 08 Apr     , Pierre Savary wrote:
> Hi,
> I use a MMCplus 4GB on my design (with at91sam9260). It's wired with 4
bits.
> Currently U-boot (1.1.5) can't detect correctly the MMC and so I can't
read
1.1.5 is really old please update to the curent RC

Best Regards,
J.

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users




From Martin.Krause at tqs.de  Thu Apr 10 13:08:33 2008
From: Martin.Krause at tqs.de (Martin Krause)
Date: Thu, 10 Apr 2008 13:08:33 +0200
Subject: [U-Boot-Users] I2C @ MPC8343
In-Reply-To: <47FDD1C6.3000205@matrix-vision.de>
Message-ID: <47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de>

Hi Andre,

u-boot-users-bounces at lists.sourceforge.net wrote on :
> All,
> 
> in my current system the I2C bus is not working properly on a MPC8343
> in 
> u-boot v1.3.2.
> 
> i2c board config includes :
> 
> #define CONFIG_HARD_I2C
> #undef CONFIG_SOFT_I2C
> #define CONFIG_FSL_I2C
> #define CONFIG_I2C_MULTI_BUS
> #define CONFIG_I2C_CMD_TREE
> #define CFG_I2C_OFFSET          0x3000
> #define CFG_I2C2_OFFSET         0x3100
> #define CFG_I2C_SPEED           100000
> #define CFG_I2C_SLAVE           0x7F
> 
> 
> chip probing works fine.
> 
> mvBL-M7> i2c probe
> Valid chip addresses: 30 48 50 68
> 
> reading the Chips gives all "ff"
> 
> mvBL-M7> i2c md 50 0 10

Uh, it seems I lag behind in U-Boot evolution. I know this
"i2c md" command as "imd"?

> 0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff   
> ................ 

Devices with address 50 normally are EEPROMs. If this device is an
EEPROM, are you sure it contains data other than 0xff?

The number of address bytes a device needs is varying. Your could
look up the correct address length in the datasheet of your device,
or try it manually:

imd 50.0 0 10
imd 50.1 0 10
imd 50.2 0 10

One of this should work.

> Observing the I2C bus wires show that everything _works excellent_ :
> 100kHz speed as well as all data seems ok - but u-boot shows "ff".
> 
> BTW:  Fetching HRCW from I2C is also working fine.
> 
> After some tries (i2c md ..) the bus hangs and no more transactions
> can 
> be seen on the bus.

One reason for a hanging bus could be a lost clock pulse. This could
happen, if the low->high rise time of the bus signal is longer than
the clock pulse width. For testing you could try a lower bus clock 
(10 kHz for example).

Best Regards,
Martin Krause
--
TQ-Systems GmbH
Muehlstrasse 2, Gut Delling, D-82229 Seefeld
Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl
http://www.tq-group.com



From w.wegner at astro-kom.de  Thu Apr 10 13:19:48 2008
From: w.wegner at astro-kom.de (w.wegner at astro-kom.de)
Date: Thu, 10 Apr 2008 13:19:48 +0200
Subject: [U-Boot-Users] I2C @ MPC8343
In-Reply-To: <47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de>
References: <47FDD1C6.3000205@matrix-vision.de>,
	<47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de>
Message-ID: <47FE13F4.22909.A061CC@w.wegner.astro-kom.de>

Hi,

On 10 Apr 2008 at 13:08, Martin Krause wrote:
> > After some tries (i2c md ..) the bus hangs and no more transactions
> > can 
> > be seen on the bus.
> 
> One reason for a hanging bus could be a lost clock pulse. This could
> happen, if the low->high rise time of the bus signal is longer than
> the clock pulse width. For testing you could try a lower bus clock 
> (10 kHz for example).

sorry if I did not follow the discussion up to here. As I stumbled over
it yesterday, I just want to give another example how to hang a bus.

There are devices (namely LM75) that claim to be I2C devices but
do not care about I2C specification. In case of LM75, a read must
always be 16 bit (2 bytes), in case of reading only 1 byte the device
does not interpret the missing ACK correctly and, in case the
last byte read is '0', it will block the bus until some more (worst
case 8) SCL pulses follow.

Maybe something like this could also happen in your case?

Regards,
Wolfgang




From plagnioj at jcrosoft.com  Thu Apr 10 13:16:25 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 10 Apr 2008 13:16:25 +0200
Subject: [U-Boot-Users] [PATCH/review] Blackfin: resurrect
	BF533-STAMP	video splash driver
In-Reply-To: <1207722800-3978-2-git-send-email-vapier@gentoo.org>
References: <1207722800-3978-1-git-send-email-vapier@gentoo.org>
	<1207722800-3978-2-git-send-email-vapier@gentoo.org>
Message-ID: <20080410111625.GG28294@game.jcrosoft.org>

On 02:33 Wed 09 Apr     , Mike Frysinger wrote:
> This video driver used to live in the Blackfin cpu directory, but it was
> lost during the unification process.  This brings it back.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
>  board/bf533-stamp/Makefile |    4 +-
>  board/bf533-stamp/video.c  |  276 ++++++++++++++++++++++++++++++++++++++++++++
>  board/bf533-stamp/video.h  |   25 ++++
>  3 files changed, 303 insertions(+), 2 deletions(-)
>  create mode 100644 board/bf533-stamp/video.c
>  create mode 100644 board/bf533-stamp/video.h
> 
> diff --git a/board/bf533-stamp/Makefile b/board/bf533-stamp/Makefile
> index 1115df8..a759d9a 100644
> --- a/board/bf533-stamp/Makefile
> +++ b/board/bf533-stamp/Makefile
> @@ -1,7 +1,7 @@
>  #
>  # U-boot - Makefile
>  #
> -# Copyright (c) 2005-2007 Analog Device Inc.
> +# Copyright (c) 2005-2008 Analog Device Inc.
>  #
>  # (C) Copyright 2000-2006
>  # Wolfgang Denk, DENX Software Engineering, wd at denx.de.
> @@ -29,7 +29,7 @@ include $(TOPDIR)/config.mk
>  
>  LIB	= $(obj)lib$(BOARD).a
>  
> -COBJS	:= $(BOARD).o spi_flash.o
> +COBJS	:= $(BOARD).o spi_flash.o video.o
>  
>  SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
>  OBJS	:= $(addprefix $(obj),$(COBJS))
> diff --git a/board/bf533-stamp/video.c b/board/bf533-stamp/video.c
> new file mode 100644
> index 0000000..6899930
> --- /dev/null
> +++ b/board/bf533-stamp/video.c
> @@ -0,0 +1,276 @@
> +/*
> + * (C) Copyright 2000
> + * Paolo Scaffardi, AIRVENT SAM s.p.a - RIMINI(ITALY), arsenio at tin.it
> + * (C) Copyright 2002
> + * Wolfgang Denk, wd at denx.de
> + * (C) Copyright 2006
> + * Aubrey Li, aubrey.li at analog.com
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <stdarg.h>
> +#include <common.h>
> +#include <config.h>
> +#include <malloc.h>
> +#include <asm/blackfin.h>
> +#include <asm/mach-common/bits/dma.h>
> +#include <i2c.h>
> +#include <linux/types.h>
> +#include <devices.h>
> +
> +int gunzip(void *, int, unsigned char *, unsigned long *);
> +
> +#ifdef CONFIG_VIDEO
Plese move to Makefile
> +
> +#define DMA_SIZE16	2
> +			for (i = 0; i < u_boot_logo.width / 2; i++) {
> +				/* enlarge one pixel to m x n */
> +				for (n = 0; n < HORIZONTAL; n++) {
> +					*OddPtr32++ = *data;
> +					*EvenPtr32++ = *data;
> +				}
> +				data++;
> +			}
> +		}
> +	}
> +}
> +
> +static int video_init(void)
> +{
> +	char *NTSCFrame;
> +	NTSCFrame = (char *)NTSC_FRAME_ADDR;
> +	NTSC_framebuffer_init(NTSCFrame);
> +	fill_frame(NTSCFrame, BLUE);
> +
> +	*pPPI_CONTROL = 0x0082;
> +	*pPPI_FRAME = 0x020D;
> +
> +	*pDMA0_START_ADDR = NTSCFrame;
> +	*pDMA0_X_COUNT = 0x035A;
> +	*pDMA0_X_MODIFY = 0x0002;
> +	*pDMA0_Y_COUNT = 0x020D;
> +	*pDMA0_Y_MODIFY = 0x0002;
> +	*pDMA0_CONFIG = 0x1015;
> +	*pPPI_CONTROL = 0x0083;
> +	return 0;
> +}
> +
> +	error = device_register(&videodev);
> +
> +	return (error == 0) ? devices : error;
> +}
> +
> +#endif
> diff --git a/board/bf533-stamp/video.h b/board/bf533-stamp/video.h
> new file mode 100644
> index 0000000..d5a8bc8
> --- /dev/null
> +++ b/board/bf533-stamp/video.h
> @@ -0,0 +1,25 @@
> +#include <video_logo.h>
> +#define write_dest_byte(val) {*dest++=val;}
> +#define BLACK   (0x01800180)	/* black pixel pattern   */
> +#define BLUE    (0x296E29F0)	/* blue pixel pattern    */
> +#define RED     (0x51F0515A)	/* red pixel pattern     */
> +#define MAGENTA (0x6ADE6ACA)	/* magenta pixel pattern */
> +#define GREEN   (0x91229136)	/* green pixel pattern   */
> +#define CYAN    (0xAA10AAA6)	/* cyan pixel pattern    */
> +#define YELLOW  (0xD292D210)	/* yellow pixel pattern  */
> +#define WHITE   (0xFE80FE80)	/* white pixel pattern   */
> +
> +#define true 	1
WhiteSpace     ^
> +#define false	0
> +
> +typedef struct {
> +	unsigned int SAV;
> +	unsigned int EAV;
> +} SystemCodeType;
> +
> +const SystemCodeType SystemCodeMap[4] = {
> +	{0xFF000080, 0xFF00009D},
> +	{0xFF0000AB, 0xFF0000B6},
> +	{0xFF0000C7, 0xFF0000DA},
> +	{0xFF0000EC, 0xFF0000F1}
> +};
> -- 
Personnaly, I do not like var name that strart with UPPERCASE

Best Regards,
J.



From biggerbadderben at gmail.com  Thu Apr 10 13:33:33 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 10 Apr 2008 07:33:33 -0400
Subject: [U-Boot-Users] I2C @ MPC8343
In-Reply-To: <47FDD1C6.3000205@matrix-vision.de>
References: <47FDD1C6.3000205@matrix-vision.de>
Message-ID: <f8328f7c0804100433y2c525192jad38cecb9a444deb@mail.gmail.com>

Hi Andre,

On Thu, Apr 10, 2008 at 4:37 AM, Andre Schwarz
<andre.schwarz at matrix-vision.de> wrote:
> All,
>
>  in my current system the I2C bus is not working properly on a MPC8343 in
>  u-boot v1.3.2.
>
>  i2c board config includes :
>
>  #define CONFIG_HARD_I2C
>  #undef CONFIG_SOFT_I2C
>  #define CONFIG_FSL_I2C
>  #define CONFIG_I2C_MULTI_BUS
>  #define CONFIG_I2C_CMD_TREE
>  #define CFG_I2C_OFFSET          0x3000
>  #define CFG_I2C2_OFFSET         0x3100
>  #define CFG_I2C_SPEED           100000
>  #define CFG_I2C_SLAVE           0x7F
>
>
>  chip probing works fine.
>
>  mvBL-M7> i2c probe
>  Valid chip addresses: 30 48 50 68
>
>  reading the Chips gives all "ff"
>
>  mvBL-M7> i2c md 50 0 10
>  0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>
>
>  Observing the I2C bus wires show that everything _works excellent_ :
>  100kHz speed as well as all data seems ok - but u-boot shows "ff".
>

The fact that probing works and your scope shows bits toggling leads
me to believe that your command syntax is the problem.
Please try something like: "i2c md 50.1 0 10".  I2C syntax is a bit
goofy - you often have to specify the bus width.  I've used 1.3.2
successfully on an MPC8349 (same as yours) with and without Timur's
speed patches.

regards,
Ben



From lilja.magnus at gmail.com  Thu Apr 10 13:52:50 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Thu, 10 Apr 2008 13:52:50 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <20080410102421.2BBF1243AB@gemini.denx.de>
References: <000801c89255$d637b670$3a4d010a@Emea.Arm.com>
	<20080410102421.2BBF1243AB@gemini.denx.de>
Message-ID: <59b21cf20804100452i6a0ef6eeh79985b7fd9df4175@mail.gmail.com>

>  I would expect, that the state of the current repository represents
>  what we get after applying Sascha's and Guennadi's patches (in the
>  correct versions and order). Howver, the current tree looks totally
>  different to me.

There are some vital differences between the current git trees (both
the ARM tree and the main tree) and the tree one gets after applying
the patches manually (from the posts here on the list).

I had to make some changes in order to get the litekit to work with
the git source, it seems like the phycore is also affected but I don't
have such a board to test on.

The following changes to the current git will put the files into the
same state as in the patches posted on the list.

At the moment I'm using gmail to post this so the diff below may be
garbled, I can re-post tonight using another mailer if necessary.

Regards, Magnus Lilja

 board/imx31_litekit/Makefile        |    2 ++
 board/imx31_litekit/lowlevel_init.S |    5 +++++
 board/imx31_phycore/Makefile        |    2 ++
 board/imx31_phycore/lowlevel_init.S |    3 +++
 4 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/board/imx31_litekit/Makefile b/board/imx31_litekit/Makefile
index aaaec69..76ed1ad 100644
--- a/board/imx31_litekit/Makefile
+++ b/board/imx31_litekit/Makefile
@@ -48,3 +48,5 @@ distclean:	clean
 include $(SRCTREE)/rules.mk

 sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/imx31_litekit/lowlevel_init.S
b/board/imx31_litekit/lowlevel_init.S
index 74d6067..c778e88 100644
--- a/board/imx31_litekit/lowlevel_init.S
+++ b/board/imx31_litekit/lowlevel_init.S
@@ -101,3 +101,8 @@ lowlevel_init:
 	REG	0xB8001000, 0xb2100000
 	REG8	0x80000033, 0xda
 	REG8	0x81000000, 0xff
+	REG	0xB8001000, 0x82226080
+	REG	0x80000000, 0xDEADBEEF
+	REG	0xB8001010, 0x0000000c
+
+	mov	pc, lr
diff --git a/board/imx31_phycore/Makefile b/board/imx31_phycore/Makefile
index de37cca..f6c248d 100644
--- a/board/imx31_phycore/Makefile
+++ b/board/imx31_phycore/Makefile
@@ -47,3 +47,5 @@ distclean:	clean
 include $(SRCTREE)/rules.mk

 sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/imx31_phycore/lowlevel_init.S
b/board/imx31_phycore/lowlevel_init.S
index b0a5389..61a500e 100644
--- a/board/imx31_phycore/lowlevel_init.S
+++ b/board/imx31_phycore/lowlevel_init.S
@@ -103,3 +103,6 @@ lowlevel_init:
 	REG8	0x81000000, 0xff
 	REG	0xB8001000, 0x82226080
 	REG	0x80000000, 0xDEADBEEF
+	REG	0xB8001010, 0x0000000c
+
+	mov	pc, lr



From andre.schwarz at matrix-vision.de  Thu Apr 10 14:13:53 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 10 Apr 2008 14:13:53 +0200
Subject: [U-Boot-Users] I2C @ MPC8343
In-Reply-To: <47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de>
References: <47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de>
Message-ID: <47FE0481.6020202@matrix-vision.de>

Martin,

thanks for your hints.


Martin Krause schrieb:
> Hi Andre,
>
> u-boot-users-bounces at lists.sourceforge.net wrote on :
>   
>> All,
>>
>> in my current system the I2C bus is not working properly on a MPC8343
>> in 
>> u-boot v1.3.2.
>>
>> i2c board config includes :
>>
>> #define CONFIG_HARD_I2C
>> #undef CONFIG_SOFT_I2C
>> #define CONFIG_FSL_I2C
>> #define CONFIG_I2C_MULTI_BUS
>> #define CONFIG_I2C_CMD_TREE
>> #define CFG_I2C_OFFSET          0x3000
>> #define CFG_I2C2_OFFSET         0x3100
>> #define CFG_I2C_SPEED           100000
>> #define CFG_I2C_SLAVE           0x7F
>>
>>
>> chip probing works fine.
>>
>> mvBL-M7> i2c probe
>> Valid chip addresses: 30 48 50 68
>>
>> reading the Chips gives all "ff"
>>
>> mvBL-M7> i2c md 50 0 10
>>     
>
> Uh, it seems I lag behind in U-Boot evolution. I know this
> "i2c md" command as "imd"?
>
>   
>> 0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff   
>> ................ 
>>     
>
> Devices with address 50 normally are EEPROMs. If this device is an
> EEPROM, are you sure it contains data other than 0xff?
>
>   
Yes - it's the configuration data of the CPU.
I can see the transaction on the bus - all data is correct. U-boot shows 
0xff.
> The number of address bytes a device needs is varying. Your could
> look up the correct address length in the datasheet of your device,
> or try it manually:
>
> imd 50.0 0 10
> imd 50.1 0 10
> imd 50.2 0 10
>
> One of this should work.
>
>   
no - only 0xff.
Scope shows valid I2C transactions with correct data.
>> Observing the I2C bus wires show that everything _works excellent_ :
>> 100kHz speed as well as all data seems ok - but u-boot shows "ff".
>>
>> BTW:  Fetching HRCW from I2C is also working fine.
>>
>> After some tries (i2c md ..) the bus hangs and no more transactions
>> can 
>> be seen on the bus.
>>     
>
> One reason for a hanging bus could be a lost clock pulse. This could
> happen, if the low->high rise time of the bus signal is longer than
> the clock pulse width. For testing you could try a lower bus clock 
> (10 kHz for example).
>
>   
rise time is  ~200ns.
> Best Regards,
> Martin Krause
> --
> TQ-Systems GmbH
> Muehlstrasse 2, Gut Delling, D-82229 Seefeld
> Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
> Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl
> http://www.tq-group.com
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080410/49ab5ff0/attachment.htm 

From andre.schwarz at matrix-vision.de  Thu Apr 10 14:17:33 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 10 Apr 2008 14:17:33 +0200
Subject: [U-Boot-Users] I2C @ MPC8343
In-Reply-To: <47FE13F4.22909.A061CC@w.wegner.astro-kom.de>
References: <47FDD1C6.3000205@matrix-vision.de>,
	<47F3F98010FF784EBEE6526EAAB078D10635DEF2@tq-mailsrv.tq-net.de>
	<47FE13F4.22909.A061CC@w.wegner.astro-kom.de>
Message-ID: <47FE055D.5060901@matrix-vision.de>

Wolfgang,

I have indeed a LM75 on this bus - but it's not adressed.
The same I2C bus works fine on linux-2.6.25 including LM75 and EEPROM.

The oszi shows complete transactions with valid data.
I think it is as software issue.

Thanks,
Andre

w.wegner at astro-kom.de schrieb:
> Hi,
>
> On 10 Apr 2008 at 13:08, Martin Krause wrote:
>   
>>> After some tries (i2c md ..) the bus hangs and no more transactions
>>> can 
>>> be seen on the bus.
>>>       
>> One reason for a hanging bus could be a lost clock pulse. This could
>> happen, if the low->high rise time of the bus signal is longer than
>> the clock pulse width. For testing you could try a lower bus clock 
>> (10 kHz for example).
>>     
>
> sorry if I did not follow the discussion up to here. As I stumbled over
> it yesterday, I just want to give another example how to hang a bus.
>
> There are devices (namely LM75) that claim to be I2C devices but
> do not care about I2C specification. In case of LM75, a read must
> always be 16 bit (2 bytes), in case of reading only 1 byte the device
> does not interpret the missing ACK correctly and, in case the
> last byte read is '0', it will block the bus until some more (worst
> case 8) SCL pulses follow.
>
> Maybe something like this could also happen in your case?
>
> Regards,
> Wolfgang
>
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080410/73f6157e/attachment.htm 

From andre.schwarz at matrix-vision.de  Thu Apr 10 14:27:54 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 10 Apr 2008 14:27:54 +0200
Subject: [U-Boot-Users] I2C @ MPC8343
In-Reply-To: <f8328f7c0804100433y2c525192jad38cecb9a444deb@mail.gmail.com>
References: <47FDD1C6.3000205@matrix-vision.de>
	<f8328f7c0804100433y2c525192jad38cecb9a444deb@mail.gmail.com>
Message-ID: <47FE07CA.1080702@matrix-vision.de>

Ben,

I'm a little confused right now and need to have a closer look.

The EEPRM is a M24C64 from ST with extended adressing modes. There might 
be something going wrong during probe or initial adressing.


I'll post as soon as there are more useful results ...

thanks,
Andre

Ben Warren schrieb:
> Hi Andre,
>
> On Thu, Apr 10, 2008 at 4:37 AM, Andre Schwarz
> <andre.schwarz at matrix-vision.de> wrote:
>   
>> All,
>>
>>  in my current system the I2C bus is not working properly on a MPC8343 in
>>  u-boot v1.3.2.
>>
>>  i2c board config includes :
>>
>>  #define CONFIG_HARD_I2C
>>  #undef CONFIG_SOFT_I2C
>>  #define CONFIG_FSL_I2C
>>  #define CONFIG_I2C_MULTI_BUS
>>  #define CONFIG_I2C_CMD_TREE
>>  #define CFG_I2C_OFFSET          0x3000
>>  #define CFG_I2C2_OFFSET         0x3100
>>  #define CFG_I2C_SPEED           100000
>>  #define CFG_I2C_SLAVE           0x7F
>>
>>
>>  chip probing works fine.
>>
>>  mvBL-M7> i2c probe
>>  Valid chip addresses: 30 48 50 68
>>
>>  reading the Chips gives all "ff"
>>
>>  mvBL-M7> i2c md 50 0 10
>>  0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
>>
>>
>>  Observing the I2C bus wires show that everything _works excellent_ :
>>  100kHz speed as well as all data seems ok - but u-boot shows "ff".
>>
>>     
>
> The fact that probing works and your scope shows bits toggling leads
> me to believe that your command syntax is the problem.
> Please try something like: "i2c md 50.1 0 10".  I2C syntax is a bit
> goofy - you often have to specify the bus width.  I've used 1.3.2
> successfully on an MPC8349 (same as yours) with and without Timur's
> speed patches.
>
> regards,
> Ben
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080410/f45d001a/attachment.htm 

From Eugene.O'Brien at advantechamt.com  Thu Apr 10 15:23:01 2008
From: Eugene.O'Brien at advantechamt.com (Eugene O'Brien)
Date: Thu, 10 Apr 2008 09:23:01 -0400
Subject: [U-Boot-Users] [PATCH] PPC440 Power Management Registers
In-Reply-To: <200804081329.50384.sr@denx.de>
References: <8B3930FEA8618C44B48EB06B5D33A06E12FD07@satmail.Advantech.ca>
	<200804041604.42214.sr@denx.de>
	<8B3930FEA8618C44B48EB06B5D33A06E12FD0B@satmail.Advantech.ca>
	<200804081329.50384.sr@denx.de>
Message-ID: <8B3930FEA8618C44B48EB06B5D33A06E12FD0D@satmail.Advantech.ca>

Hello Stefan,

Here is an updated patch correcting only the pre-existing power
management register definitions. (I might add that these definitions are
not currently used in the U-Boot source tree either.)

CHANGELOG:

ppc440: Fix power mgt definitions for PPC440

Corrected DCR addresses of PPC440 power management registers.
All AMCC PPC440 processors conform to the same DCR address usage for
these registers.

Signed-off-by: Eugene O'Brien <eugene.obrien at advantechamt.com> 


diff --git a/include/ppc440.h b/include/ppc440.h
index 80dd332..34963c5 100644
--- a/include/ppc440.h
+++ b/include/ppc440.h
@@ -1726,17 +1726,10 @@
 #else
 #define CNTRL_DCR_BASE 0x0b0
 #endif
-#if defined(CONFIG_440GX) || \
-    defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
-    defined(CONFIG_460EX) || defined(CONFIG_460GT)
+
 #define cpc0_er		(CNTRL_DCR_BASE+0x00)	/* CPM enable
register		*/
 #define cpc0_fr		(CNTRL_DCR_BASE+0x01)	/* CPM force
register		*/
 #define cpc0_sr		(CNTRL_DCR_BASE+0x02)	/* CPM status
register		*/
-#else
-#define cpc0_sr		(CNTRL_DCR_BASE+0x00)	/* CPM status
register		*/
-#define cpc0_er		(CNTRL_DCR_BASE+0x01)	/* CPM enable
register		*/
-#define cpc0_fr		(CNTRL_DCR_BASE+0x02)	/* CPM force
register		*/
-#endif
 
 #define cpc0_sys0	(CNTRL_DCR_BASE+0x30)	/* System configuration
reg 0	*/
 #define cpc0_sys1	(CNTRL_DCR_BASE+0x31)	/* System configuration
reg 1	*/


Regards,
Eugene


-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: April 8, 2008 7:30 AM
To: u-boot-users at lists.sourceforge.net
Cc: Eugene O'Brien
Subject: Re: [U-Boot-Users] [PATCH] PPC440 Power Management Registers

Hi Eugene,

On Monday 07 April 2008, Eugene O'Brien wrote:
> I had a look at all PPC440 processor manuals from AMCC and see that my
> patch applies to all of them. In other words the #else portion is
never
> used. Therefore I am submitting a patch that cleans up this code quite
> nicely.

Great, thanks.

> Another observation that I made is that the PPC440EPx and PPC440GPx
> require more than 32 bits to control the power management functions.
> Therefore I defined a second set of registers cpc1_er, cpc1_fr,
cpc1_sr
> for these processors. These can be used as placeholders for future
> development.

I would prefer to add those when really needed. Let's try to include
only 
defines that are used. This way the headers don't get "polluted" even
more.

> Let me know if this sounds good to you.

Could you please resend you patch without those new registers? And
please send 
it inline and add a proper Signed-off-by line as described here:

http://www.denx.de/wiki/UBoot/Patches

I suggest to use git-send-email for sending patches.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Thu Apr 10 15:33:14 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 10 Apr 2008 15:33:14 +0200
Subject: [U-Boot-Users] [PATCH] PPC440 Power Management Registers
In-Reply-To: <8B3930FEA8618C44B48EB06B5D33A06E12FD0D@satmail.Advantech.ca>
References: <8B3930FEA8618C44B48EB06B5D33A06E12FD07@satmail.Advantech.ca>
	<200804081329.50384.sr@denx.de>
	<8B3930FEA8618C44B48EB06B5D33A06E12FD0D@satmail.Advantech.ca>
Message-ID: <200804101533.14599.sr@denx.de>

Hi Eugene,

On Thursday 10 April 2008, Eugene O'Brien wrote:
> Here is an updated patch correcting only the pre-existing power
> management register definitions. (I might add that these definitions are
> not currently used in the U-Boot source tree either.)
>
> CHANGELOG:
>
> ppc440: Fix power mgt definitions for PPC440
>
> Corrected DCR addresses of PPC440 power management registers.
> All AMCC PPC440 processors conform to the same DCR address usage for
> these registers.
>
> Signed-off-by: Eugene O'Brien <eugene.obrien at advantechamt.com>

Unfortunately now your patch is line wrapped. And even if it wasn't line 
wrapped, it couldn't be applied using git-am (which makes life so much easier 
for me) because of the lines above and below the real patch.

I there a chance that you can create this patch by using git-format-patch? I 
know it is a lot of work for such a small patch, but once you've got all this 
git patch stuff working, you can send patches much easier in the future.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From info.xu at 163.com  Thu Apr 10 15:41:35 2008
From: info.xu at 163.com (=?GB2312?B?sqnI8LXCufq8yg==?=)
Date: Thu, 10 Apr 2008 21:41:35 +0800
Subject: [U-Boot-Users] =?GB2312?B?tdrI/b3szb/Bz82/17DRp8r1tPO74Q==?=
Message-ID: <E1Jjx25-0005wN-TI@mail.sourceforge.net>

 
????????????????????
 
?????2008?5?14-16?
???????????????????
 
?????http://www.cnfair.org/tuliaodahui.htm
 
??????????????????????????????Hc360???????????
????????????????
????????????????
?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
 
? ?????????????????????
? ?????????????????????????
? ???????????????????????????????? ????????????????????????????
 
> ????????
? ??????????????
? ????????????/????/??/??/??/???/????
? ?????????????
? ???????????????????
? ??????????
 
> ?????
??????1000?/??
?????300?/??

 
> ???????
???????????
??????????19??????????10F4?
???400060
???023-62925058  86393228  86393229
???023-62925059
???www.cnfair.org
???????
 
 



From Martin.Krause at tqs.de  Thu Apr 10 16:03:46 2008
From: Martin.Krause at tqs.de (Martin Krause)
Date: Thu, 10 Apr 2008 16:03:46 +0200
Subject: [U-Boot-Users] I2C @ MPC8343
In-Reply-To: <47FE0481.6020202@matrix-vision.de>
Message-ID: <47F3F98010FF784EBEE6526EAAB078D10635DEF3@tq-mailsrv.tq-net.de>

Hi Andre,

Andre Schwarz wrote on Thursday, April 10, 2008 2:14 PM:
>> The number of address bytes a device needs is varying. Your could
>> look up the correct address length in the datasheet of your device,
>> or try it manually:
>> 
>> imd 50.0 0 10
>> imd 50.1 0 10
>> imd 50.2 0 10
>> 
>> One of this should work.
> 
> 
> no - only 0xff.
> Scope shows valid I2C transactions with correct data.

If you see the correct data on the bus with your scope and U-Boot 
nevertheless shows only 0xff, this seems like a bug in U-Boot to mee.
If you set the address lenght (.x spezifier) wrong, then the data
you see on the bus will also be wrong.

>> One reason for a hanging bus could be a lost clock pulse. This could
>> happen, if the low->high rise time of the bus signal is longer than
>> the clock pulse width. For testing you could try a lower bus clock
>> (10 kHz for example).
> 
> 
> rise time is  ~200ns.

This should definitely be fast enough (for 100 kHz)

Best Regards,
Martin Krause
--
TQ-Systems GmbH
Muehlstrasse 2, Gut Delling, D-82229 Seefeld
Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl
http://www.tq-group.com



From biggerbadderben at gmail.com  Thu Apr 10 16:09:13 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 10 Apr 2008 10:09:13 -0400
Subject: [U-Boot-Users] I2C @ MPC8343
In-Reply-To: <47FE07CA.1080702@matrix-vision.de>
References: <47FDD1C6.3000205@matrix-vision.de>	<f8328f7c0804100433y2c525192jad38cecb9a444deb@mail.gmail.com>
	<47FE07CA.1080702@matrix-vision.de>
Message-ID: <47FE1F89.5020900@gmail.com>

Andre Schwarz wrote:
> Ben,
>
> I'm a little confused right now and need to have a closer look.
>
> The EEPRM is a M24C64 from ST with extended adressing modes. There 
> might be something going wrong during probe or initial adressing.
>
>
If it's an extended addressing eeprom, you probably need to do 16-bit 
reads, e.g.

i2c md 50.2 0 10

If that doesn't work, it's quite possible that something else has hosed 
the bus.

regards,
Ben



From lee.nipper at freescale.com  Thu Apr 10 16:35:06 2008
From: lee.nipper at freescale.com (Lee Nipper)
Date: Thu, 10 Apr 2008 09:35:06 -0500
Subject: [U-Boot-Users] [PATCH] mpc83xx: Update DIMM data bus width test to
	support 40-bit	width
Message-ID: <1207838106.6999.2.camel@al08linux99>

32-bit wide ECC memory modules report 40-bit width.
Changed the DIMM data bus width test to 'less than 64' instead of 'equal 32'.

Signed-off-by: Lee Nipper <lee.nipper at freescale.com>
---
 cpu/mpc83xx/spd_sdram.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/cpu/mpc83xx/spd_sdram.c b/cpu/mpc83xx/spd_sdram.c
index 0acca47..4ad5a3f 100644
--- a/cpu/mpc83xx/spd_sdram.c
+++ b/cpu/mpc83xx/spd_sdram.c
@@ -598,7 +598,7 @@ long int spd_sdram()
 	debug("DDR:timing_cfg_2=0x%08x\n", ddr->timing_cfg_2);
 
 	/* Check DIMM data bus width */
-	if (spd.dataw_lsb == 0x20) {
+	if (spd.dataw_lsb < 64) {
 		if (spd.mem_type == SPD_MEMTYPE_DDR)
 			burstlen = 0x03; /* 32 bit data bus, burst len is 8 */
 		else
@@ -760,7 +760,7 @@ long int spd_sdram()
 		sdram_cfg |= SDRAM_CFG_RD_EN;
 
 	/* The DIMM is 32bit width */
-	if (spd.dataw_lsb == 0x20) {
+	if (spd.dataw_lsb < 64) {
 		if (spd.mem_type == SPD_MEMTYPE_DDR)
 			sdram_cfg |= SDRAM_CFG_32_BE | SDRAM_CFG_8_BE;
 		if (spd.mem_type == SPD_MEMTYPE_DDR2)
-- 
1.5.4.2





From skuribay at ruby.dti.ne.jp  Thu Apr 10 16:44:39 2008
From: skuribay at ruby.dti.ne.jp (Shinya Kuribayashi)
Date: Thu, 10 Apr 2008 23:44:39 +0900
Subject: [U-Boot-Users] [PATCH] qemu-mips: add CFI support
In-Reply-To: <1207816295-9586-1-git-send-email-plagnioj@jcrosoft.com>
References: <1207816295-9586-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <47FE27D7.2040303@ruby.dti.ne.jp>

Hi Jean,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
> index e164019..7ee6fd4 100644
> --- a/include/configs/qemu-mips.h
> +++ b/include/configs/qemu-mips.h
> @@ -33,7 +33,7 @@
>  #define CONFIG_MISC_INIT_R
>  
>  /*IP address is default used by Qemu*/
> -#define CONFIG_IPADDR		10.0.2.15    	     /* Our IP address */
> +#define CONFIG_IPADDR		10.0.2.15	     /* Our IP address */
>  #define CONFIG_SERVERIP		10.0.2.2	     /* Server IP address*/
>  
>  #define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds	*/
> @@ -74,16 +74,12 @@
>  #define CONFIG_CMD_ELF
>  #define CONFIG_CMD_FAT
>  #define CONFIG_CMD_EXT2
> -#undef  CONFIG_CMD_IMLS
> -#undef  CONFIG_CMD_FLASH
> -#undef  CONFIG_CMD_LOADB
> -#undef  CONFIG_CMD_LOADS
>  #define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_PING
>  
>  #define CONFIG_DRIVER_NE2000

This patch contains as many fixes as CFI related changes (above).
In that case, please add some notes about them or change the subject.

I applied the patch below. If something wrong, please let me know.
Or will push in a week or two :-)

  Shinya

----------------------------------------------------------------
[MIPS] qemu-mips.h: Update config header

From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

- Add CFI support
- Add CONFIG_CMD_PING since qemu-mips has NE2000 driver enabled
- Cleanup whitespaces and remove #undef CMD lines

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
---

 include/configs/qemu-mips.h |   24 +++++++++++++-----------
 1 files changed, 13 insertions(+), 11 deletions(-)


diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index e164019..7ee6fd4 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -33,7 +33,7 @@
 #define CONFIG_MISC_INIT_R
 
 /*IP address is default used by Qemu*/
-#define CONFIG_IPADDR		10.0.2.15    	     /* Our IP address */
+#define CONFIG_IPADDR		10.0.2.15	     /* Our IP address */
 #define CONFIG_SERVERIP		10.0.2.2	     /* Server IP address*/
 
 #define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds	*/
@@ -74,16 +74,12 @@
 #define CONFIG_CMD_ELF
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef  CONFIG_CMD_IMLS
-#undef  CONFIG_CMD_FLASH
-#undef  CONFIG_CMD_LOADB
-#undef  CONFIG_CMD_LOADS
 #define CONFIG_CMD_DHCP
+#define CONFIG_CMD_PING
 
 #define CONFIG_DRIVER_NE2000
 #define CONFIG_DRIVER_NE2000_BASE	(0xb4000300)
 
-#define CFG_NO_FLASH
 #define CFG_NS16550
 #define CFG_NS16550_SERIAL
 #define CFG_NS16550_REG_SIZE    1
@@ -140,17 +136,23 @@
 
 /* The following #defines are needed to get flash environment right */
 #define	CFG_MONITOR_BASE	TEXT_BASE
-#define	CFG_MONITOR_LEN		(192 << 10)
+#define	CFG_MONITOR_LEN		(192 << 11)
 
 #define CFG_INIT_SP_OFFSET	0x400000
 
 /* We boot from this flash, selected with dip switch */
 #define CFG_FLASH_BASE		0xbfc00000
-
-#define	CFG_ENV_IS_NOWHERE	1
-
+#define	CFG_MAX_FLASH_BANKS	1
+#define	CFG_MAX_FLASH_SECT	128
+#define	CFG_FLASH_CFI		1	/* Flash memory is CFI compliant */
+#define CFG_FLASH_CFI_DRIVER	1
+#define CFG_FLASH_USE_BUFFER_WRITE    1
+
+#define	CFG_ENV_IS_IN_FLASH	1
+#define CFG_ENV_ADDR		(CFG_FLASH_BASE+0x60000)
 /* Address and size of Primary Environment Sector	*/
-#define CFG_ENV_SIZE		0x10000
+#define CFG_ENV_SIZE		0x8000
+
 #undef CONFIG_NET_MULTI
 
 #define MEM_SIZE 128



From kim.phillips at freescale.com  Thu Apr 10 18:11:58 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Thu, 10 Apr 2008 11:11:58 -0500
Subject: [U-Boot-Users] [PATCH] add MPC8343 based board mvBlueLYNX-M7
 aka mvblm7
In-Reply-To: <47FCCFBC.2090808@matrix-vision.de>
References: <47FCCFBC.2090808@matrix-vision.de>
Message-ID: <20080410111158.e7379fe3.kim.phillips@freescale.com>

On Wed, 09 Apr 2008 16:16:28 +0200
Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:

> MPC8343 based stereo camera system with Cyclone-II FPGA and miniPCI Slot.
> CPU utilizes dual 10/100/1000 Ethernet using Vitesse VSC8601 RGMII Phys 
> and USB over ULPI.
> 512MB Micron DDR-II memory, 8MB Flash on LocalBus, SD over SPU and 32MB 
> NAND @ FPGA.
> 
> Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
> --

Wolfgang, I believe the window for new board support is closed; would
you rather I maintain this on a "next" branch on mpc83xx, or are you
willing to let this in for 1.3.3?

Andre, thanks for the new board contribution - please include diffstats
in your patches.

> diff --git a/CREDITS b/CREDITS
> index e84ef38..713f58a 100644
> --- a/CREDITS
> +++ b/CREDITS
> @@ -424,6 +424,11 @@ N: Paolo Scaffardi
>  E: arsenio at tin.it
>  D: FADS823 configuration, MPC823 video support, I2C, wireless keyboard, lots more
>  
> +N: Andre Schwarz
> +E: andre.schwarz at matrix-vision.de
> +D: Support for BlueLYNX and BlueCOUGAR series
> +W: www.matrix-vision.com
> +
>  N: Robert Schwebel
>  E: r.schwebel at pengutronix.de
>  D: Support for csb226, logodl and innokom boards (PXA2xx)
> diff --git a/MAKEALL b/MAKEALL
> index 2a872ac..f21c34e 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -327,6 +327,7 @@ LIST_83xx="		\
>  	MPC8360ERDK_66	\
>  	MPC837XEMDS	\
>  	MPC837XERDB	\
> +	MVBLM7		\
>  	sbc8349		\
>  	TQM834x		\
>  "
> diff --git a/Makefile b/Makefile
> index a7f886b..3f217fe 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2084,6 +2084,9 @@ sbc8349_config:		unconfig
>  TQM834x_config:	unconfig
>  	@$(MKCONFIG) $(@:_config=) ppc mpc83xx tqm834x
>  
> +MVBLM7_config: unconfig
> +	@$(MKCONFIG) $(@:_config=) ppc mpc83xx mvblm7
> +

I believe intra-family targets are kept in alpha order in the Makefile
(as you did in MAKEALL).

please add a MAINTAINERS entry. A doc/README.mvblm7 would be nice.

<snip>
> diff --git a/board/mvblm7/config.mk b/board/mvblm7/config.mk
> new file mode 100644
> index 0000000..a659203
> --- /dev/null
> +++ b/board/mvblm7/config.mk
<snip>
> +#
> +# MPC8349E-mITX and MPC8349E-mITX-GP
> +#

I'd leave this out :)

> +
> +sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
> +
> +TEXT_BASE  = 0xFFF00000
> diff --git a/board/mvblm7/fpga.c b/board/mvblm7/fpga.c
> new file mode 100644
> index 0000000..d286ef1
> --- /dev/null
> +++ b/board/mvblm7/fpga.c
<snip>
> +#if (CONFIG_FPGA)

#if defined?

<snip>
> +int mvblm7_init_fpga (void)

we don't put spaces between function name and open parenthesis, do we?

All your functions are like this.

> +{
> +	DECLARE_GLOBAL_DATA_PTR;

this needs to be put somewhere global.

> +
> +	fpga_debug("%s:%d: Initialize FPGA interface (relocation offset = 0x%.8lx)\n",
> +		__FUNCTION__, __LINE__, gd->reloc_off);
> +	fpga_init (gd->reloc_off);
> +
> +	fpga_debug("%s:%d: Adding fpga 0\n", __FUNCTION__, __LINE__);
> +	fpga_add (fpga_altera, &cyclone2);
> +	return 1;
> +}
> +
> +int fpga_null_fn (int cookie)
> +{
> +        return 0;
> +}
> +
> +int fpga_config_fn (int assert, int flush, int cookie)
> +{
> +        volatile immap_t        *im = (volatile immap_t *)CFG_IMMR;
> +        volatile gpio83xx_t	*gpio = (volatile gpio83xx_t *)&im->gpio[0];

fix indentation; use tabs, not spaces.

> +
> +	u32 dvo = gpio->dat;

keep declarations together, leave blank space between declarations and
code - i.e, mv above blank line to before this line:

> +	fpga_debug("SET config : %s\n", assert ? "low" : "high");
> +	if ( assert ) 

no spaces around assert

> +		dvo |= FPGA_CONFIG;
> +	else 
> +		dvo &= ~FPGA_CONFIG;
> +	
> +	if ( flush )
> +		gpio->dat = dvo;
> +	return assert;

can you also get in the habit of leaving blank lines before return
statements?  thanks.

<snipped more code that gets above comments also>

> +	for ( i=0; i<8; i++ ) {

please read CodingStyle!  this should look like:

for (i = 0; i < 8; i++) {

<snip similar cases>

> diff --git a/board/mvblm7/mvblm7.c b/board/mvblm7/mvblm7.c
<snip>
> +        im->ddr.sdram_interval = CFG_DDR_INTERVAL;
> +        im->ddr.sdram_clk_cntl = CFG_DDR_CLK_CNTL;

use tabs, not spaces.

<snip>
> +u8 *dhcp_vendorex_prep (u8 * e)

u8 *dhcp_vendorex_prep(u8 *e)

> +{
> +    char *ptr;
> +
> +/* DHCP vendor-class-identifier = 60 */
> +    if ((ptr = getenv ("dhcp_vendor-class-identifier"))) {

fix indentation.  Use tabs, not spaces.

> +        *e++ = 60;
> +        *e++ = strlen (ptr);

strlen(ptr);

> +        while (*ptr)
> +            *e++ = *ptr++;
> +    }
> +/* DHCP_CLIENT_IDENTIFIER = 61 */
> +    if ((ptr = getenv ("dhcp_client_id"))) {

..

<snip>
> diff --git a/board/mvblm7/pci.c b/board/mvblm7/pci.c
<sniiiiip>
> +			tmp[0] = cpu_to_be32(gd->pci_clk);
> +			do_fixup_by_path(blob, path, "clock-frequency",
> +				&tmp, sizeof(tmp[0]), 1);
> +		}
> +	}
> +}
> +#endif
 
please use generic 83xx pci code (cpu/mpc83xx/pci.c).  See the
mpc8313erdb board implementation for an example use-case.

Again, thanks for your contribution!

Kim



From sos_lxb at sina.com  Thu Apr 10 18:24:15 2008
From: sos_lxb at sina.com (sonicss)
Date: Fri, 11 Apr 2008 00:24:15 +0800
Subject: [U-Boot-Users] question about environment variable in U-BOOT
Message-ID: <200804110024145564218@sina.com>

U-BOOT:
I want to modify the default environment variable in U-BOOT. The following info are about the hardware:

ARM: at91rm9200
platform: at91rm9200dk
U-BOOT: CFG_ENV_IS_IN_DATAFLASH

I modifed /include/configs/at91rm9200dk.h and add the following lines after "#define CONFIG_BAUDRATE 115200":

#define CONFIG_ETHADDR 12.24.96.78.91.11
#define CONFIG_IPADDR 172.19.71.10
#define CONFIG_SERVERIP 172.19.71.40
#define CONFIG_BOOTCMD = tftp 20008000 zImage; tftp 21000000 Ramdisk.gz; go 20008000

the first three commands work well, but the last command is not in the environment. I use printenv command to show the current

environment:
U-Boot> printenv
bootdelay=3
baudrate=115200
ethaddr=12.24.96.78.91.11
ipaddr=172.19.71.10
serverip=172.19.71.40
stdin=serial
stdout=serial
stderr=serial

There is not bootcmd command. How can I implement this function? ( just add bootcmd before compile u-boot)

best regards

2008-04-11 



sonicss 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080411/6ef7b1f8/attachment.htm 

From radanter at googlemail.com  Thu Apr 10 21:34:37 2008
From: radanter at googlemail.com (Richard Danter)
Date: Thu, 10 Apr 2008 20:34:37 +0100
Subject: [U-Boot-Users] Linker scripts, SEARCH_DIR and host directories
Message-ID: <f75c52840804101234s7363d926n92e78bd4993fc2f9@mail.gmail.com>

Hi all,

Using a new toolchain I am seeing the following warnings at the final
link stage of U-Boot:

warning: library search path "/lib" is unsafe for cross-compilation
warning: library search path "/usr/lib" is unsafe for cross-compilation
warning: library search path "/usr/local/lib" is unsafe for cross-compilation

Looking further I can see in the u-boot.lds scripts that SEARCH_DIR is
specifying each of these directories. I am unsure why a cross-compiled
bootloader would specify that the linker should look in the hosts
directories for libraries.

Can anyone explain this?

Thanks
Rich



From wd at denx.de  Thu Apr 10 21:41:43 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 10 Apr 2008 21:41:43 +0200
Subject: [U-Boot-Users] [PATCH/review] Blackfin: resurrect BF533-STAMP
	video splash driver
In-Reply-To: Your message of "Thu, 10 Apr 2008 13:16:25 +0200."
	<20080410111625.GG28294@game.jcrosoft.org>
Message-ID: <20080410194143.EDAD3242FB@gemini.denx.de>

In message <20080410111625.GG28294 at game.jcrosoft.org> you wrote:
>
...
> > +typedef struct {
> > +	unsigned int SAV;
> > +	unsigned int EAV;
> > +} SystemCodeType;
 ^^^^^^^^^^^^^^^^^^^^^
> > +
> > +const SystemCodeType SystemCodeMap[4] = {
 ^^^^^^^^^^^^^^^^^^^^^^^^^
> > +	{0xFF000080, 0xFF00009D},
> > +	{0xFF0000AB, 0xFF0000B6},
> > +	{0xFF0000C7, 0xFF0000DA},
> > +	{0xFF0000EC, 0xFF0000F1}
> > +};
> > -- 
> Personnaly, I do not like var name that strart with UPPERCASE

It's more than not liking. It's a clear violation of the coding style:

    C is a Spartan language, and so should your naming be.  Unlike Modula-2
    and Pascal programmers, C programmers do not use cute names like
    ThisVariableIsATemporaryCounter.  A C programmer would call that
    variable "tmp", which is much easier to write, and not the least more
    difficult to understand.

So this is a clear NAK.

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: wd at denx.de
Nothing is easier than to denounce  the  evildoer;  nothing  is  more
difficult than to understand him.                 - Fyodor Dostoevski



From wd at denx.de  Thu Apr 10 21:45:31 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 10 Apr 2008 21:45:31 +0200
Subject: [U-Boot-Users] [PATCH] PPC440 Power Management Registers
In-Reply-To: Your message of "Thu, 10 Apr 2008 15:33:14 +0200."
	<200804101533.14599.sr@denx.de>
Message-ID: <20080410194531.D34D1242FB@gemini.denx.de>

In message <200804101533.14599.sr at denx.de> you wrote:
> 
> Unfortunately now your patch is line wrapped. And even if it wasn't line 
> wrapped, it couldn't be applied using git-am (which makes life so much easier 
> for me) because of the lines above and below the real patch.

This is not a big problem; "git-am -i" will allow you to edit the
commit message if needed.

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: wd at denx.de
HANDLE WITH EXTREME CARE:  This Product Contains  Minute Electrically
Charged  Particles  Moving  at  Velocities  in Excess of Five Hundred
Million Miles Per Hour.



From wd at denx.de  Thu Apr 10 21:47:19 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 10 Apr 2008 21:47:19 +0200
Subject: [U-Boot-Users] [PATCH] add MPC8343 based board mvBlueLYNX-M7
	aka mvblm7
In-Reply-To: Your message of "Thu, 10 Apr 2008 11:11:58 CDT."
	<20080410111158.e7379fe3.kim.phillips@freescale.com>
Message-ID: <20080410194719.8454A242FB@gemini.denx.de>

Dear Kim,

in message <20080410111158.e7379fe3.kim.phillips at freescale.com> you wrote:
>
> Wolfgang, I believe the window for new board support is closed; would

Correct.

> you rather I maintain this on a "next" branch on mpc83xx, or are you
> willing to let this in for 1.3.3?

It's all new stuff, so it should go to "next".

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: wd at denx.de
"It is better to have tried and failed than to have  failed  to  try,
but the result's the same."                           - Mike Dennison



From kenneth at southpole.se  Thu Apr 10 22:40:17 2008
From: kenneth at southpole.se (kenneth johansson)
Date: Thu, 10 Apr 2008 22:40:17 +0200
Subject: [U-Boot-Users] Linker scripts, SEARCH_DIR and host directories
In-Reply-To: <f75c52840804101234s7363d926n92e78bd4993fc2f9@mail.gmail.com>
References: <f75c52840804101234s7363d926n92e78bd4993fc2f9@mail.gmail.com>
Message-ID: <1207860017.8774.36.camel@duo>

On Thu, 2008-04-10 at 20:34 +0100, Richard Danter wrote:
> Hi all,
> 
> Using a new toolchain I am seeing the following warnings at the final
> link stage of U-Boot:
> 
> warning: library search path "/lib" is unsafe for cross-compilation
> warning: library search path "/usr/lib" is unsafe for cross-compilation
> warning: library search path "/usr/local/lib" is unsafe for cross-compilation
> 
> Looking further I can see in the u-boot.lds scripts that SEARCH_DIR is
> specifying each of these directories. I am unsure why a cross-compiled
> bootloader would specify that the linker should look in the hosts
> directories for libraries.
> 
> Can anyone explain this?
> 
> Thanks
> Rich

You should delete that from the linker script. There is several scripts
that has this error it's not needed and wrong as you suspected.







From jason.wessel at windriver.com  Thu Apr 10 23:11:46 2008
From: jason.wessel at windriver.com (Jason Wessel)
Date: Thu, 10 Apr 2008 16:11:46 -0500
Subject: [U-Boot-Users] [PATCH] Request to remove SEARCH_DIR from lds files
Message-ID: <47FE8292.3020502@windriver.com>

Unless someone has an objection, would it be possible to remove all
the SEARCH_DIR() directives from the lds files with the attached
patch?

Modern cross compilers will automatically find the correct link time
libraries so there is no need to go searching in places that might
have libraries which you do not actually want to link in, such as
probing /usr/lib on an x86 host for powerpc link objects.

Thanks,
Jason.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove_SEARCH_DIR_from_lds_files.patch.gz
Type: application/x-gzip
Size: 8536 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080410/0b770675/attachment.bin 

From gvb.uboot at gmail.com  Thu Apr 10 23:33:48 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Thu, 10 Apr 2008 17:33:48 -0400
Subject: [U-Boot-Users] question about environment variable in U-BOOT
In-Reply-To: <200804110024145564218@sina.com>
References: <200804110024145564218@sina.com>
Message-ID: <47FE87BC.3000700@gmail.com>

sonicss wrote:
> U-BOOT:
> I want to modify the default environment variable in U-BOOT. The 
> following info are about the hardware:
>  
> 
>     ARM: at91rm9200
>     platform: at91rm9200dk
> 
> U-BOOT: CFG_ENV_IS_IN_DATAFLASH
>  
> I modifed /include/configs/at91rm9200dk.h and add the following lines 
> after "#define CONFIG_BAUDRATE 115200":
>  
> #define CONFIG_ETHADDR 12.24.96.78.91.11
> #define CONFIG_IPADDR 172.19.71.10
> #define CONFIG_SERVERIP 172.19.71.40
> *#define CONFIG_BOOTCMD = tftp 20008000 zImage; tftp 21000000 Ramdisk.gz; go 20008000*
>  
> the first three commands work well, but the last command is not in the 
> environment. I use printenv command to show the current

1) Your #define for CONFIG_BOOTCMD is not a valid C preprocessor define
2) You probably wanted to #define CONFIG_BOOTCOMMAND, not CONFIG_BOOTCMD

Something closer (but not necessarily correct) would be:
#define CONFIG_BOOTCOMMAND "tftp 20008000 zImage; tftp 21000000 
Ramdisk.gz; go 20008000"

[snip]

> There is not bootcmd command. How can I implement this function? ( just 
> add bootcmd before compile u-boot)
>  
> best regards
>  
> 2008-04-11
> ------------------------------------------------------------------------
> sonicss

Good luck,
gvb



From Andre.Schwarz at matrix-vision.de  Thu Apr 10 23:42:56 2008
From: Andre.Schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Thu, 10 Apr 2008 23:42:56 +0200
Subject: [U-Boot-Users] [PATCH] add MPC8343 based board mvBlueLYNX-M7
 aka mvblm7
In-Reply-To: <20080410111158.e7379fe3.kim.phillips@freescale.com>
References: <47FCCFBC.2090808@matrix-vision.de>
	<20080410111158.e7379fe3.kim.phillips@freescale.com>
Message-ID: <47FE89E0.1060108@matrix-vision.de>

Kim,

I'll fix all your issues mentioned below in the next days.
We're not in a hurry. Getting the board into 1.3.3 is absolutely fine.

Thanks,
Andr?

Kim Phillips wrote:
> On Wed, 09 Apr 2008 16:16:28 +0200
> Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:
>
>   
>> MPC8343 based stereo camera system with Cyclone-II FPGA and miniPCI Slot.
>> CPU utilizes dual 10/100/1000 Ethernet using Vitesse VSC8601 RGMII Phys 
>> and USB over ULPI.
>> 512MB Micron DDR-II memory, 8MB Flash on LocalBus, SD over SPU and 32MB 
>> NAND @ FPGA.
>>
>> Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
>> --
>>     
>
> Wolfgang, I believe the window for new board support is closed; would
> you rather I maintain this on a "next" branch on mpc83xx, or are you
> willing to let this in for 1.3.3?
>
> Andre, thanks for the new board contribution - please include diffstats
> in your patches.
>
>   
>> diff --git a/CREDITS b/CREDITS
>> index e84ef38..713f58a 100644
>> --- a/CREDITS
>> +++ b/CREDITS
>> @@ -424,6 +424,11 @@ N: Paolo Scaffardi
>>  E: arsenio at tin.it
>>  D: FADS823 configuration, MPC823 video support, I2C, wireless keyboard, lots more
>>  
>> +N: Andre Schwarz
>> +E: andre.schwarz at matrix-vision.de
>> +D: Support for BlueLYNX and BlueCOUGAR series
>> +W: www.matrix-vision.com
>> +
>>  N: Robert Schwebel
>>  E: r.schwebel at pengutronix.de
>>  D: Support for csb226, logodl and innokom boards (PXA2xx)
>> diff --git a/MAKEALL b/MAKEALL
>> index 2a872ac..f21c34e 100755
>> --- a/MAKEALL
>> +++ b/MAKEALL
>> @@ -327,6 +327,7 @@ LIST_83xx="		\
>>  	MPC8360ERDK_66	\
>>  	MPC837XEMDS	\
>>  	MPC837XERDB	\
>> +	MVBLM7		\
>>  	sbc8349		\
>>  	TQM834x		\
>>  "
>> diff --git a/Makefile b/Makefile
>> index a7f886b..3f217fe 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -2084,6 +2084,9 @@ sbc8349_config:		unconfig
>>  TQM834x_config:	unconfig
>>  	@$(MKCONFIG) $(@:_config=) ppc mpc83xx tqm834x
>>  
>> +MVBLM7_config: unconfig
>> +	@$(MKCONFIG) $(@:_config=) ppc mpc83xx mvblm7
>> +
>>     
>
> I believe intra-family targets are kept in alpha order in the Makefile
> (as you did in MAKEALL).
>
> please add a MAINTAINERS entry. A doc/README.mvblm7 would be nice.
>
> <snip>
>   
>> diff --git a/board/mvblm7/config.mk b/board/mvblm7/config.mk
>> new file mode 100644
>> index 0000000..a659203
>> --- /dev/null
>> +++ b/board/mvblm7/config.mk
>>     
> <snip>
>   
>> +#
>> +# MPC8349E-mITX and MPC8349E-mITX-GP
>> +#
>>     
>
> I'd leave this out :)
>
>   
>> +
>> +sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
>> +
>> +TEXT_BASE  = 0xFFF00000
>> diff --git a/board/mvblm7/fpga.c b/board/mvblm7/fpga.c
>> new file mode 100644
>> index 0000000..d286ef1
>> --- /dev/null
>> +++ b/board/mvblm7/fpga.c
>>     
> <snip>
>   
>> +#if (CONFIG_FPGA)
>>     
>
> #if defined?
>
> <snip>
>   
>> +int mvblm7_init_fpga (void)
>>     
>
> we don't put spaces between function name and open parenthesis, do we?
>
> All your functions are like this.
>
>   
>> +{
>> +	DECLARE_GLOBAL_DATA_PTR;
>>     
>
> this needs to be put somewhere global.
>
>   
>> +
>> +	fpga_debug("%s:%d: Initialize FPGA interface (relocation offset = 0x%.8lx)\n",
>> +		__FUNCTION__, __LINE__, gd->reloc_off);
>> +	fpga_init (gd->reloc_off);
>> +
>> +	fpga_debug("%s:%d: Adding fpga 0\n", __FUNCTION__, __LINE__);
>> +	fpga_add (fpga_altera, &cyclone2);
>> +	return 1;
>> +}
>> +
>> +int fpga_null_fn (int cookie)
>> +{
>> +        return 0;
>> +}
>> +
>> +int fpga_config_fn (int assert, int flush, int cookie)
>> +{
>> +        volatile immap_t        *im = (volatile immap_t *)CFG_IMMR;
>> +        volatile gpio83xx_t	*gpio = (volatile gpio83xx_t *)&im->gpio[0];
>>     
>
> fix indentation; use tabs, not spaces.
>
>   
>> +
>> +	u32 dvo = gpio->dat;
>>     
>
> keep declarations together, leave blank space between declarations and
> code - i.e, mv above blank line to before this line:
>
>   
>> +	fpga_debug("SET config : %s\n", assert ? "low" : "high");
>> +	if ( assert ) 
>>     
>
> no spaces around assert
>
>   
>> +		dvo |= FPGA_CONFIG;
>> +	else 
>> +		dvo &= ~FPGA_CONFIG;
>> +	
>> +	if ( flush )
>> +		gpio->dat = dvo;
>> +	return assert;
>>     
>
> can you also get in the habit of leaving blank lines before return
> statements?  thanks.
>
> <snipped more code that gets above comments also>
>
>   
>> +	for ( i=0; i<8; i++ ) {
>>     
>
> please read CodingStyle!  this should look like:
>
> for (i = 0; i < 8; i++) {
>
> <snip similar cases>
>
>   
>> diff --git a/board/mvblm7/mvblm7.c b/board/mvblm7/mvblm7.c
>>     
> <snip>
>   
>> +        im->ddr.sdram_interval = CFG_DDR_INTERVAL;
>> +        im->ddr.sdram_clk_cntl = CFG_DDR_CLK_CNTL;
>>     
>
> use tabs, not spaces.
>
> <snip>
>   
>> +u8 *dhcp_vendorex_prep (u8 * e)
>>     
>
> u8 *dhcp_vendorex_prep(u8 *e)
>
>   
>> +{
>> +    char *ptr;
>> +
>> +/* DHCP vendor-class-identifier = 60 */
>> +    if ((ptr = getenv ("dhcp_vendor-class-identifier"))) {
>>     
>
> fix indentation.  Use tabs, not spaces.
>
>   
>> +        *e++ = 60;
>> +        *e++ = strlen (ptr);
>>     
>
> strlen(ptr);
>
>   
>> +        while (*ptr)
>> +            *e++ = *ptr++;
>> +    }
>> +/* DHCP_CLIENT_IDENTIFIER = 61 */
>> +    if ((ptr = getenv ("dhcp_client_id"))) {
>>     
>
> ..
>
> <snip>
>   
>> diff --git a/board/mvblm7/pci.c b/board/mvblm7/pci.c
>>     
> <sniiiiip>
>   
>> +			tmp[0] = cpu_to_be32(gd->pci_clk);
>> +			do_fixup_by_path(blob, path, "clock-frequency",
>> +				&tmp, sizeof(tmp[0]), 1);
>> +		}
>> +	}
>> +}
>> +#endif
>>     
>  
> please use generic 83xx pci code (cpu/mpc83xx/pci.c).  See the
> mpc8313erdb board implementation for an example use-case.
>
> Again, thanks for your contribution!
>
> Kim
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080410/8b954151/attachment.htm 

From Andre.Schwarz at matrix-vision.de  Thu Apr 10 23:48:19 2008
From: Andre.Schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Thu, 10 Apr 2008 23:48:19 +0200
Subject: [U-Boot-Users] [PATCH] add MPC8343 based board mvBlueLYNX-M7
 aka mvblm7
In-Reply-To: <20080410194719.8454A242FB@gemini.denx.de>
References: <20080410194719.8454A242FB@gemini.denx.de>
Message-ID: <47FE8B23.7020509@matrix-vision.de>

Wolfgang,

that's absolutely fine since there are some open issues regarding docs 
and coding style.
I didn't dare to believe getting the board in in the first run anyway ;-)

Sometimes the rules are a bit annoying - but they are definitely necessary !


Cheers,
Andr?

Wolfgang Denk wrote:
> Dear Kim,
>
> in message <20080410111158.e7379fe3.kim.phillips at freescale.com> you wrote:
>   
>> Wolfgang, I believe the window for new board support is closed; would
>>     
>
> Correct.
>
>   
>> you rather I maintain this on a "next" branch on mpc83xx, or are you
>> willing to let this in for 1.3.3?
>>     
>
> It's all new stuff, so it should go to "next".
>
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080410/6c3f7efb/attachment.htm 

From Ken.Fuchs at bench.com  Fri Apr 11 00:31:24 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Thu, 10 Apr 2008 17:31:24 -0500
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <003601c89985$5cf10aa0$16d31fe0$@savary@kerlink.fr>
Message-ID: <AA28F077645B324881335614E4F7C428034CB4@win-ex01.bench.com>

Pierre Savary wrote:

> I use a MMCplus 4GB on my design (with at91sam9260). It's 
> wired with 4 bits.

The MCI controller on the AT91SAM926x family does not support
MMCplus.  There is no way to support a 4 bit bus, since the
MCI controller supports only 1 bit to an MMC chip.  The MCI will
support a 4 bit SD chip, but I don't think it can be tricked
into working with a 4 bit MMC chip (at least not via software
alone).

The only reasonable solution is switching to a processor that
has MMCplus support.  Maybe Atmel has been working on one?

> Currently U-boot (1.1.5) can't detect correctly the MMC and 
> so I can't read my Linux kernel Image on the ext3 part of this
> MMC. If I use MMC 1GB, it works.

Did you add MMCplus commands to the MCI U-Boot driver?  You can
do this to the extent that these changes do not require the MCI
controller to be MMCplus compliant.  (The MCI U-Boot driver I'm
aware of contains no MMCplus support.)

I suggest that you use the u-boot sources available via git.
You will get very little support (if any) from the U-Boot ML for
two reasons:

1) U-Boot 1.1.5 is extremely old and no one on the list is
   interested in supporting it.

2) The version of U-Boot 1.1.5 you are using almost certainly
   has an Atmel patch applied to it that was never accepted
   into the "official" U-Boot tree.

However, ...

It appears that someone is working on the AT91SAM9260 within the
official U-Boot (git) tree, since the ./include/configs/at91sam9260ek.h
file is there.  Other file structures like ./cpu/arm926ejs/* seem to be
missing some drivers and other support files.  I know that the
AT91SAM926x specific U-Boot files were never an official part of
U-Boot, but that appears to be changing.  It is my understanding
that the AT91SAM926x support is being completely reworked and
integrated with the AT91CAP9 code that has been present in git
for over a month already.  The AT91CAP9 and AT91SAM926x are very
similar and should share a lot of code.

Even if the AT91SAM9260 is not quite ready, the AT91CAP9 code
should provide the basis of a current U-Boot for the AT91SAM926x
family.

> Somebody have already use it? Or somebody have already implemented
> the ext_csd and high capacity with MMC on another platform?

I know that the MCI controller can be used to access 1GB MMCplus chips,
but I'm not sure it can be used to access MMCplus chips larger than
that.
There may be a special MMCplus command that will allow larger chips to
be accessed.  Try looking for it in your MMCplus chip's manual.

Sincerely,

Ken Fuchs

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Pierre Savary
> Sent: Tuesday, April 08, 2008 09:32
> To: u-boot-users at lists.sourceforge.net
> Cc: 'Pierre Ossman'
> Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
> 
> 
> Hi,
> I use a MMCplus 4GB on my design (with at91sam9260). It's 
> wired with 4 bits.
> Currently U-boot (1.1.5) can't detect correctly the MMC and 
> so I can't read
> my Linux kernel Image on the ext3 part of this MMC. If I use 
> MMC 1GB, it
> works.
> Somebody have already use it? Or somebody have already implemented the
> ext_csd and high capacity with MMC on another platform?
> I need help. Thanks in advance to help me.
> 
> Regards,
> 
> Pierre
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Register now and save $200. Hurry, offer ends at 11:59 p.m., 
> Monday, April 7! Use priority code J8TLD2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
.sun.com/javaone
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users



From kim.phillips at freescale.com  Fri Apr 11 02:45:02 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Thu, 10 Apr 2008 19:45:02 -0500
Subject: [U-Boot-Users] [PATCH] ppc: Revert patch 70431e8a that used
 _start instead of CFG_MONITOR_BASE
In-Reply-To: <1207738602-23956-1-git-send-email-sr@denx.de>
References: <1207738602-23956-1-git-send-email-sr@denx.de>
Message-ID: <20080410194502.13d37051.kim.phillips@freescale.com>

On Wed,  9 Apr 2008 12:56:42 +0200
Stefan Roese <sr at denx.de> wrote:

> The patch 70431e8a7393b6b793f77957f95b999fc9a269b8 (Make MPC83xx one step
> closer to full relocation.) doesn't use CFG_MONITOR_BASE anymore. But
> on 4xx systems _start currently cannot be used for this calculation.
> So revert back to the original version for now.
> 
> Signed-off-by: Stefan Roese <sr at denx.de>

Acked-by: Kim Phillips <kim.phillips at freescale.com>

Kim



From sr at denx.de  Fri Apr 11 06:30:43 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 11 Apr 2008 06:30:43 +0200
Subject: [U-Boot-Users] [PATCH] PPC440 Power Management Registers
In-Reply-To: <20080410194531.D34D1242FB@gemini.denx.de>
References: <20080410194531.D34D1242FB@gemini.denx.de>
Message-ID: <200804110630.44012.sr@denx.de>

On Thursday 10 April 2008, Wolfgang Denk wrote:
> In message <200804101533.14599.sr at denx.de> you wrote:
> > Unfortunately now your patch is line wrapped. And even if it wasn't line
> > wrapped, it couldn't be applied using git-am (which makes life so much
> > easier for me) because of the lines above and below the real patch.
>
> This is not a big problem; "git-am -i" will allow you to edit the
> commit message if needed.

Right. But it would be better if it could be avoided. Less work for us 
custodians. ;)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From peter.uboot at gmail.com  Fri Apr 11 08:46:31 2008
From: peter.uboot at gmail.com (Peter.wang)
Date: Fri, 11 Apr 2008 14:46:31 +0800
Subject: [U-Boot-Users] U-Boot-Users Digest, Vol 23, Issue 48
In-Reply-To: <mailman.156563.1207750654.31037.u-boot-users@lists.sourceforge.net>
References: <mailman.156563.1207750654.31037.u-boot-users@lists.sourceforge.net>
Message-ID: <47FF0947.7060506@gmail.com>

hi, I recently read the code of u-boot, but I have a problem about its 
relocation and uboot how to pass the paramter to the linux kernel. could 
you help me?, at least ,tell where i can find the code of these function 
,thanks .



From peter.uboot at gmail.com  Fri Apr 11 09:28:52 2008
From: peter.uboot at gmail.com (fei wang)
Date: Fri, 11 Apr 2008 15:28:52 +0800
Subject: [U-Boot-Users] what is relocation
Message-ID: <923f2a360804110028j34dac716ibdf29498a427d69d@mail.gmail.com>

hi, I recently read the code of u-boot, but I have a problem about its
relocation and uboot how to pass the paramter to the linux kernel. could you
help me?, at least ,tell where i can find the code of these function ,thanks
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080411/1fcfd169/attachment.htm 

From pierre.savary at kerlink.fr  Fri Apr 11 10:26:52 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Fri, 11 Apr 2008 10:26:52 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <AA28F077645B324881335614E4F7C428034CB4@win-ex01.bench.com>
References: <003601c89985$5cf10aa0$16d31fe0$@savary@kerlink.fr>
	<AA28F077645B324881335614E4F7C428034CB4@win-ex01.bench.com>
Message-ID: <000001c89bad$cd8b11f0$68a135d0$@savary@kerlink.fr>

Thanks a lot for your help.
In fact it's not really important to support MMCplus, the main is to support
MMC v4 where the extended CSD is introduced. Moreover, it's not really
important if only one wire is used... I want only be able to read on a MMC
4Gb with my U-boot...

Thanks in advance

Pierre

-----Message d'origine-----
De?: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] De la part de
Ken.Fuchs at bench.com
Envoy??: vendredi 11 avril 2008 00:31
??: pierre.savary at kerlink.fr
Cc?: u-boot-users at lists.sourceforge.net; drzeus-mmc at drzeus.cx
Objet?: Re: [U-Boot-Users] drivers MMCplus for at91sam9x

Pierre Savary wrote:

> I use a MMCplus 4GB on my design (with at91sam9260). It's 
> wired with 4 bits.

The MCI controller on the AT91SAM926x family does not support
MMCplus.  There is no way to support a 4 bit bus, since the
MCI controller supports only 1 bit to an MMC chip.  The MCI will
support a 4 bit SD chip, but I don't think it can be tricked
into working with a 4 bit MMC chip (at least not via software
alone).

The only reasonable solution is switching to a processor that
has MMCplus support.  Maybe Atmel has been working on one?

> Currently U-boot (1.1.5) can't detect correctly the MMC and 
> so I can't read my Linux kernel Image on the ext3 part of this
> MMC. If I use MMC 1GB, it works.

Did you add MMCplus commands to the MCI U-Boot driver?  You can
do this to the extent that these changes do not require the MCI
controller to be MMCplus compliant.  (The MCI U-Boot driver I'm
aware of contains no MMCplus support.)

I suggest that you use the u-boot sources available via git.
You will get very little support (if any) from the U-Boot ML for
two reasons:

1) U-Boot 1.1.5 is extremely old and no one on the list is
   interested in supporting it.

2) The version of U-Boot 1.1.5 you are using almost certainly
   has an Atmel patch applied to it that was never accepted
   into the "official" U-Boot tree.

However, ...

It appears that someone is working on the AT91SAM9260 within the
official U-Boot (git) tree, since the ./include/configs/at91sam9260ek.h
file is there.  Other file structures like ./cpu/arm926ejs/* seem to be
missing some drivers and other support files.  I know that the
AT91SAM926x specific U-Boot files were never an official part of
U-Boot, but that appears to be changing.  It is my understanding
that the AT91SAM926x support is being completely reworked and
integrated with the AT91CAP9 code that has been present in git
for over a month already.  The AT91CAP9 and AT91SAM926x are very
similar and should share a lot of code.

Even if the AT91SAM9260 is not quite ready, the AT91CAP9 code
should provide the basis of a current U-Boot for the AT91SAM926x
family.

> Somebody have already use it? Or somebody have already implemented
> the ext_csd and high capacity with MMC on another platform?

I know that the MCI controller can be used to access 1GB MMCplus chips,
but I'm not sure it can be used to access MMCplus chips larger than
that.
There may be a special MMCplus command that will allow larger chips to
be accessed.  Try looking for it in your MMCplus chip's manual.

Sincerely,

Ken Fuchs

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Pierre Savary
> Sent: Tuesday, April 08, 2008 09:32
> To: u-boot-users at lists.sourceforge.net
> Cc: 'Pierre Ossman'
> Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
> 
> 
> Hi,
> I use a MMCplus 4GB on my design (with at91sam9260). It's 
> wired with 4 bits.
> Currently U-boot (1.1.5) can't detect correctly the MMC and 
> so I can't read
> my Linux kernel Image on the ext3 part of this MMC. If I use 
> MMC 1GB, it
> works.
> Somebody have already use it? Or somebody have already implemented the
> ext_csd and high capacity with MMC on another platform?
> I need help. Thanks in advance to help me.
> 
> Regards,
> 
> Pierre
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Register now and save $200. Hurry, offer ends at 11:59 p.m., 
> Monday, April 7! Use priority code J8TLD2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
.sun.com/javaone
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users




From peter.pearse at arm.com  Fri Apr 11 10:59:00 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Fri, 11 Apr 2008 09:59:00 +0100
Subject: [U-Boot-Users] FW:  [GIT PULL] Please pull u-boot-arm
Message-ID: <000101c89bb2$48e1f130$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: Peter Pearse [mailto:peter.pearse at arm.com] 
> Sent: 11 April 2008 09:47
> To: 'Wolfgang Denk'
> Subject: RE: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> 
>  
> 
> > -----Original Message-----
> > From: u-boot-users-bounces at lists.sourceforge.net
> > [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of 
> > Wolfgang Denk
> > Sent: 10 April 2008 11:24
> > To: Peter Pearse; Guennadi Liakhovetski
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> > 
> > Dear Peter,
> > 
> > in message <000801c89255$d637b670$3a4d010a at Emea.Arm.com> you wrote:
> > >
> > > These are the patches:
> > > 
> 
> --- snip ---
> > 
> > I would expect, that the state of the current repository represents 
> > what we get after applying Sascha's and Guennadi's patches (in the 
> > correct versions and order). Howver, the current tree looks totally 
> > different to me.
> > 
> > Can you please check with Guennadi what happened, how this can be 
> > cleaned up, and especially how this can be prevented in the future?
> > 
> > Note that there is not only not the expected state of the 
> source code, 
> > but there is also corruption of meta-information again; for example:
> > 
> > 	-> git-show --pretty=fuller
> > 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
> > 	commit 7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
> > 	Author:     Guennadi Liakhovetski <[lg at denx.de]>
> > -------------------------------------------^^^^^^^^^^^^
> > 	AuthorDate: Sun Mar 30 11:32:30 2008 +0100
> > 	Commit:     Peter Pearse <peter.pearse at arm.com>
> > 	CommitDate: Sun Mar 30 11:32:30 2008 +0100
> > 
> > 	    Support for the MX31ADS evaluation board from Freescale
> > 	...
> > 
> > None of Guennadis messages on the mailing list  ever  used 
> something 
> > like "[lg at denx.de]" - this must be something that happend 
> on your end 
> > when  processing  his  patches.  Where are the brackets coming from?
> > Don't you use git-am to apply the patches?
> > 
> 
> I find I have to manually edit the mails I get from my 
> (company mandated) mail client.
> 
> My process is
> 
> a) Save mail
> b) Manually edit to remove extraneous/incorrect data and formatting
> c) Run mail thru <linux kernel>/scripts/checkpatch.pl until acceptable
> d) Run git-am, correcting the patch until applies without 
> output other than re whitespace. 
> 
> On the code my patch corrections e.g. for line length might 
> differ from those applied by someone else.
> 
> Guennadis mail address corruption occurred because I missed 
> an "on behalf of" in the patch mail.
> 
> I'm looking at Manus's mail to see where we differ...
> 
> Regards
> 
> Peter





From peter.pearse at arm.com  Fri Apr 11 11:04:44 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Fri, 11 Apr 2008 10:04:44 +0100
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <59b21cf20804100452i6a0ef6eeh79985b7fd9df4175@mail.gmail.com>
Message-ID: <000201c89bb3$161c3de0$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: Magnus Lilja [mailto:lilja.magnus at gmail.com] 
> Sent: 10 April 2008 12:53
> To: Wolfgang Denk
> Cc: Peter Pearse; Guennadi Liakhovetski; 
> u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> 
> >  I would expect, that the state of the current repository 
> represents  
> > what we get after applying Sascha's and Guennadi's patches (in the  
> > correct versions and order). Howver, the current tree looks 
> totally  
> > different to me.
> 
> There are some vital differences between the current git 
> trees (both the ARM tree and the main tree) and the tree one 
> gets after applying the patches manually (from the posts here 
> on the list).
> 

Thanks Magnus

	I see that in correcting the formats of the patches I have neglected
to
correct the line counts for new files, thus losing the final lines of the
file.

Applying your patch now

Regards

Peter





From m8 at semihalf.com  Fri Apr 11 11:07:43 2008
From: m8 at semihalf.com (Marian Balakowicz)
Date: Fri, 11 Apr 2008 11:07:43 +0200
Subject: [U-Boot-Users] [PATCH 1/2] [new uImage] ppc: Fix ftd_blob variable
	init when	processing raw blob
Message-ID: <20080411090743.7630.11993.stgit@hekate.izotz.org>

Set fdt_blob variable before its value is printed out.

Signed-off-by: Marian Balakowicz <m8 at semihalf.com>
---

 lib_ppc/bootm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index 2901607..b24a064 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -626,9 +626,9 @@ static int boot_get_fdt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 				/*
 				 * FDT blob
 				 */
+				fdt_blob = (char *)fdt_addr;
 				debug ("*  fdt: raw FDT blob\n");
 				printf ("## Flattened Device Tree blob at %08lx\n", fdt_blob);
-				fdt_blob = (char *)fdt_addr;
 			}
 			break;
 		default:




From m8 at semihalf.com  Fri Apr 11 11:07:49 2008
From: m8 at semihalf.com (Marian Balakowicz)
Date: Fri, 11 Apr 2008 11:07:49 +0200
Subject: [U-Boot-Users] [PATCH 2/2] [new uImage] Restore the ability to
	continue booting	after legacy image overwrite
In-Reply-To: <20080411090743.7630.11993.stgit@hekate.izotz.org>
References: <20080411090743.7630.11993.stgit@hekate.izotz.org>
Message-ID: <20080411090749.7630.39554.stgit@hekate.izotz.org>

Before new uImage code was merged, bootm code allowed for the kernel image to
get overwritten during decompresion. new uImage introduced a check for image
overwrites and refused to boot the image that got overwritten. This patch
restores the old behavior. It also adds a warning when the image overwriten is
a multi-image file, because in such case accessing componentes other than the
first one will fail.

Signed-off-by: Marian Balakowicz <m8 at semihalf.com>
---

 common/cmd_bootm.c     |   37 ++++++++++++++++++++++++++-----------
 common/image.c         |    2 +-
 include/image.h        |    3 ++-
 lib_arm/bootm.c        |    2 +-
 lib_avr32/bootm.c      |    2 +-
 lib_blackfin/bootm.c   |    2 +-
 lib_m68k/bootm.c       |    2 +-
 lib_microblaze/bootm.c |    2 +-
 lib_mips/bootm.c       |    2 +-
 lib_nios2/bootm.c      |    2 +-
 lib_ppc/bootm.c        |    4 ++--
 lib_sh/bootm.c         |    2 +-
 12 files changed, 39 insertions(+), 23 deletions(-)


diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9e5ce4b..3a0c83d 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -286,9 +286,16 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		debug ("image_start = 0x%lX, image_end = 0x%lx\n", image_start, image_end);
 		debug ("load_start = 0x%lx, load_end = 0x%lx\n", load_start, load_end);
 
-		puts ("ERROR: image overwritten - must RESET the board to recover.\n");
-		show_boot_progress (-113);
-		do_reset (cmdtp, flag, argc, argv);
+		if (images.legacy_hdr_valid) {
+			if (image_get_type (&images.legacy_hdr_os_copy) == IH_TYPE_MULTI)
+				puts ("WARNING: legacy format multi component "
+					"image overwritten\n");
+		} else {
+			puts ("ERROR: new format image overwritten - "
+				"must RESET the board to recover\n");
+			show_boot_progress (-113);
+			do_reset (cmdtp, flag, argc, argv);
+		}
 	}
 
 	show_boot_progress (8);
@@ -533,9 +540,17 @@ static void *boot_get_kernel (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]
 			show_boot_progress (-5);
 			return NULL;
 		}
+
+		/*
+		 * copy image header to allow for image overwrites during kernel
+		 * decompression.
+		 */
+		memmove (&images->legacy_hdr_os_copy, hdr, sizeof(image_header_t));
+
+		/* save pointer to image header */
 		images->legacy_hdr_os = hdr;
-		images->legacy_hdr_valid = 1;
 
+		images->legacy_hdr_valid = 1;
 		show_boot_progress (6);
 		break;
 #if defined(CONFIG_FIT)
@@ -890,7 +905,7 @@ static void do_bootm_netbsd (cmd_tbl_t *cmdtp, int flag,
 	 * address of the original image header.
 	 */
 	os_hdr = NULL;
-	if (image_check_type (hdr, IH_TYPE_MULTI)) {
+	if (image_check_type (&images->legacy_hdr_os_copy, IH_TYPE_MULTI)) {
 		image_multi_getimg (hdr, 1, &kernel_data, &kernel_len);
 		if (kernel_len)
 			os_hdr = hdr;
@@ -947,7 +962,7 @@ static void do_bootm_lynxkdi (cmd_tbl_t *cmdtp, int flag,
 			     int argc, char *argv[],
 			     bootm_headers_t *images)
 {
-	image_header_t *hdr = images->legacy_hdr_os;
+	image_header_t *hdr = &images->legacy_hdr_os_copy;
 
 #if defined(CONFIG_FIT)
 	if (!images->legacy_hdr_valid) {
@@ -964,7 +979,7 @@ static void do_bootm_rtems (cmd_tbl_t *cmdtp, int flag,
 			   int argc, char *argv[],
 			   bootm_headers_t *images)
 {
-	image_header_t *hdr = images->legacy_hdr_os;
+	image_header_t *hdr = &images->legacy_hdr_os_copy;
 	void (*entry_point)(bd_t *);
 
 #if defined(CONFIG_FIT)
@@ -994,10 +1009,10 @@ static void do_bootm_vxworks (cmd_tbl_t *cmdtp, int flag,
 			     bootm_headers_t *images)
 {
 	char str[80];
-	image_header_t *hdr = images->legacy_hdr_os;
+	image_header_t *hdr = &images->legacy_hdr_os_copy;
 
 #if defined(CONFIG_FIT)
-	if (hdr == NULL) {
+	if (!images->legacy_hdr_valid) {
 		fit_unsupported_reset ("VxWorks");
 		do_reset (cmdtp, flag, argc, argv);
 	}
@@ -1014,7 +1029,7 @@ static void do_bootm_qnxelf(cmd_tbl_t *cmdtp, int flag,
 {
 	char *local_args[2];
 	char str[16];
-	image_header_t *hdr = images->legacy_hdr_os;
+	image_header_t *hdr = &images->legacy_hdr_os_copy;
 
 #if defined(CONFIG_FIT)
 	if (!images->legacy_hdr_valid) {
@@ -1041,7 +1056,7 @@ static void do_bootm_artos (cmd_tbl_t *cmdtp, int flag,
 	int i, j, nxt, len, envno, envsz;
 	bd_t *kbd;
 	void (*entry)(bd_t *bd, char *cmdline, char **fwenv, ulong top);
-	image_header_t *hdr = images->legacy_hdr_os;
+	image_header_t *hdr = &images->legacy_hdr_os_copy;
 
 #if defined(CONFIG_FIT)
 	if (!images->legacy_hdr_valid) {
diff --git a/common/image.c b/common/image.c
index f04826a..e302dda 100644
--- a/common/image.c
+++ b/common/image.c
@@ -983,7 +983,7 @@ int boot_get_ramdisk (int argc, char *argv[], bootm_headers_t *images,
 #endif /* CONFIG_B2 || CONFIG_EVB4510 || CONFIG_ARMADILLO */
 
 	} else if (images->legacy_hdr_valid &&
-			image_check_type (images->legacy_hdr_os, IH_TYPE_MULTI)) {
+			image_check_type (&images->legacy_hdr_os_copy, IH_TYPE_MULTI)) {
 		/*
 		 * Now check if we have a legacy mult-component image,
 		 * get second entry data start address and len.
diff --git a/include/image.h b/include/image.h
index 36143e2..8c3ad95 100644
--- a/include/image.h
+++ b/include/image.h
@@ -197,7 +197,8 @@ typedef struct bootm_headers {
 	 * then boot_get_ramdisk() and get_fdt() will attempt to get
 	 * data from second and third component accordingly.
 	 */
-	image_header_t	*legacy_hdr_os;
+	image_header_t	*legacy_hdr_os;		/* image header pointer */
+	image_header_t	legacy_hdr_os_copy;	/* header copy */
 	ulong		legacy_hdr_valid;
 
 #if defined(CONFIG_FIT)
diff --git a/lib_arm/bootm.c b/lib_arm/bootm.c
index c5e8cb3..6b4a807 100644
--- a/lib_arm/bootm.c
+++ b/lib_arm/bootm.c
@@ -78,7 +78,7 @@ void do_bootm_linux (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		ret = fit_image_get_entry (images->fit_hdr_os,
diff --git a/lib_avr32/bootm.c b/lib_avr32/bootm.c
index b1c651a..5ff8c79 100644
--- a/lib_avr32/bootm.c
+++ b/lib_avr32/bootm.c
@@ -185,7 +185,7 @@ void do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		ret = fit_image_get_entry (images->fit_hdr_os,
diff --git a/lib_blackfin/bootm.c b/lib_blackfin/bootm.c
index bea11ed..ef4b112 100644
--- a/lib_blackfin/bootm.c
+++ b/lib_blackfin/bootm.c
@@ -49,7 +49,7 @@ void do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		int ret = fit_image_get_entry (images->fit_hdr_os,
diff --git a/lib_m68k/bootm.c b/lib_m68k/bootm.c
index 6f49c31..61f1a36 100644
--- a/lib_m68k/bootm.c
+++ b/lib_m68k/bootm.c
@@ -96,7 +96,7 @@ void do_bootm_linux(cmd_tbl_t * cmdtp, int flag,
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		ret = fit_image_get_entry (images->fit_hdr_os,
diff --git a/lib_microblaze/bootm.c b/lib_microblaze/bootm.c
index fab4a54..30a03ef 100644
--- a/lib_microblaze/bootm.c
+++ b/lib_microblaze/bootm.c
@@ -44,7 +44,7 @@ void do_bootm_linux (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[],
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		int ret = fit_image_get_entry (images->fit_hdr_os,
diff --git a/lib_mips/bootm.c b/lib_mips/bootm.c
index e4c139e..f813fc5 100644
--- a/lib_mips/bootm.c
+++ b/lib_mips/bootm.c
@@ -57,7 +57,7 @@ void do_bootm_linux (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[],
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		ret = fit_image_get_entry (images->fit_hdr_os,
diff --git a/lib_nios2/bootm.c b/lib_nios2/bootm.c
index 0c89e96..01f4e87 100644
--- a/lib_nios2/bootm.c
+++ b/lib_nios2/bootm.c
@@ -34,7 +34,7 @@ void do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		int ret = fit_image_get_entry (images->fit_hdr_os,
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm.c
index b24a064..0328bad 100644
--- a/lib_ppc/bootm.c
+++ b/lib_ppc/bootm.c
@@ -146,7 +146,7 @@ do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		ret = fit_image_get_entry (images->fit_hdr_os,
@@ -639,7 +639,7 @@ static int boot_get_fdt (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 		printf ("   Booting using the fdt blob at 0x%x\n", fdt_blob);
 
 	} else if (images->legacy_hdr_valid &&
-			image_check_type (images->legacy_hdr_os, IH_TYPE_MULTI)) {
+			image_check_type (&images->legacy_hdr_os_copy, IH_TYPE_MULTI)) {
 
 		ulong fdt_data, fdt_len;
 
diff --git a/lib_sh/bootm.c b/lib_sh/bootm.c
index 3d5c3bb..dd32a3e 100644
--- a/lib_sh/bootm.c
+++ b/lib_sh/bootm.c
@@ -67,7 +67,7 @@ void do_bootm_linux (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 
 	/* find kernel entry point */
 	if (images->legacy_hdr_valid) {
-		ep = image_get_ep (images->legacy_hdr_os);
+		ep = image_get_ep (&images->legacy_hdr_os_copy);
 #if defined(CONFIG_FIT)
 	} else if (images->fit_uname_os) {
 		int ret = fit_image_get_entry (images->fit_hdr_os,




From radanter at googlemail.com  Fri Apr 11 11:27:55 2008
From: radanter at googlemail.com (Richard Danter)
Date: Fri, 11 Apr 2008 10:27:55 +0100
Subject: [U-Boot-Users] [PATCH] Remove SEARCH_DIR from linker scripts
Message-ID: <f75c52840804110227l604570f3jfdc96473fc583ff@mail.gmail.com>

Hi all,

Patch to remove SEARCH_DIR directive is rather large since so many
linker scripts include it. I have included a link below but our FTP
site is frequently "cleaned up" by admin. Please let me know if I need
to upload it again.

CHANGELOG

Remove all SEARCH_DIR directives from linker scripts.

Many of the linker scripts included SEARCH_DIR directives making the
linker search for libraries in the host tree (/lib, /usr/lib and
/usr/local/lib). This made no sense for a cross-compiled and self
contained bootloader and causes some toolchains to generate warnings.

Signed off by: Richard Danter (richard.danter at windriver.com)

ftp://ftp.windriver.com/TECH_SUPPORT/rdanter/SEARCH_DIR.patch



From wd at denx.de  Fri Apr 11 12:44:57 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 11 Apr 2008 12:44:57 +0200
Subject: [U-Boot-Users] what is relocation
In-Reply-To: Your message of "Fri, 11 Apr 2008 15:28:52 +0800."
	<923f2a360804110028j34dac716ibdf29498a427d69d@mail.gmail.com>
Message-ID: <20080411104457.782B4248AC@gemini.denx.de>

In message <923f2a360804110028j34dac716ibdf29498a427d69d at mail.gmail.com> you wrote:
>
> hi, I recently read the code of u-boot, but I have a problem about its
> relocation and uboot how to pass the paramter to the linux kernel. could you
> help me?, at least ,tell where i can find the code of these function ,thanks
> .

It is extremely bad manners to post the same request sevral times in
quick succession, especially when you also use different names.

> ------=_Part_9369_1895355.1207898932608
> Content-Type: text/html; charset=ISO-8859-1

Also, HTML messages are forbidden on thislist.


I recommend you start reading the manual. It will answer your question
about parameter passing in great detail.

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: wd at denx.de
The complexity of software is an essential property, not an  acciden-
tal  one. Hence, descriptions of a software entity that abstract away
its complexity often abstract away its essence.    - Fred Brooks, Jr.



From wd at denx.de  Fri Apr 11 12:45:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 11 Apr 2008 12:45:54 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm (fwd)
Message-ID: <20080411104554.7C3E6248AC@gemini.denx.de>


------- Forwarded Message

Date:    Fri, 11 Apr 2008 12:13:46 +0200
From:    Wolfgang Denk <wd at denx.de>
To:      "Peter Pearse" <peter.pearse at arm.com>
cc:      lg at denx.de
Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm

Dear Peter,

in message <000001c89bb0$89dfe400$3a4d010a at Emea.Arm.com> you wrote:
>  
...
> > None of Guennadis messages on the mailing list  ever  used  
> > something like "[lg at denx.de]" - this must be something that 
> > happend on your end when  processing  his  patches.  Where  
> > are the brackets coming from?
> > Don't you use git-am to apply the patches?
> 
> I find I have to manually edit the mails I get from my (company mandated)
> mail client.
> 
> My process is
> 
> a) Save mail
> b) Manually edit to remove extraneous/incorrect data and formatting
> c) Run mail thru <linux kernel>/scripts/checkpatch.pl until acceptable
> d) Run git-am, correcting the patch until applies without output other than
> re 
> whitespace. 

This sounds terribly inefficient to  me.  Can't  you  use  any  other
(free)  email  acoount  for  the  U-Boot work which doesn't have such
restrictions?

> On the code my patch corrections e.g. for line length
> might differ from those applied by someone else.

I'm not sure if I understand you correctly. You mean, you modify the
code before you check it in?

You must not do this. A patch that was submitted on the mailing  list
and  sigend  off  by  the  author has to be checked in as is, without
modifications of the code. If you feel that cleanup  is  needed,  you
either  have  to  reject  the patch and ask the author the resubmit a
new, cleaned up version, or you have to fix the code in a second step
which then results in a new commit showing you as the author  of  the
changes.

But one must not, under no circumstances, modify the code first,  and
then  check  in  the  modified  code under the original author's name
without any indication that the code was modified by somebody else.

I'm not sure if this is what you mean, but  if  iti  s,  then  please
never do that again. It's a strict NO.

> I'm looking at Manus's mail to see where we differ...

Yes, please. 

Thanks in advance.

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: wd at denx.de
They're usually so busy thinking about what  happens  next  that  the
only  time they ever find out what is happening now is when they come
to look back on it.                 - Terry Pratchett, _Wyrd Sisters_

------- End of Forwarded Message




From g.liakhovetski at gmx.de  Fri Apr 11 13:08:19 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 11 Apr 2008 13:08:19 +0200 (CEST)
Subject: [U-Boot-Users] FW:  [GIT PULL] Please pull u-boot-arm
In-Reply-To: <000101c89bb2$48e1f130$3a4d010a@Emea.Arm.com>
References: <000101c89bb2$48e1f130$3a4d010a@Emea.Arm.com>
Message-ID: <Pine.LNX.4.64.0804111302010.15272@axis700.grange>

Peter, please, do NOT drop addressees from CC.

On Fri, 11 Apr 2008, Peter Pearse wrote:

> > I find I have to manually edit the mails I get from my 
> > (company mandated) mail client.
> > 
> > My process is
> > 
> > a) Save mail
> > b) Manually edit to remove extraneous/incorrect data and formatting
> > c) Run mail thru <linux kernel>/scripts/checkpatch.pl until acceptable
> > d) Run git-am, correcting the patch until applies without 
> > output other than re whitespace. 
> > 
> > On the code my patch corrections e.g. for line length might 
> > differ from those applied by someone else.

To which of the above "corrections" does this hunk belong:

diff --git a/board/mx31ads/Makefile b/board/mx31ads/Makefile
index dfadd96..c854e05 100644
--- a/board/mx31ads/Makefile
+++ b/board/mx31ads/Makefile
@@ -1,18 +1,14 @@
 #
+# (C) Copyright 2000-2008
 # Copyright (C) 2008, Guennadi Liakhovetski <lg at denx.de>
 #
+# See file CREDITS for list of people who contributed to this
+# project.
+#
 # This program is free software; you can redistribute it and/or
 # modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundatio; either version 2 of
-# published by the Free Software Foundation; either version 2 of

Especially the last line?

Thanks
Guennadi
---
Guennadi Liakhovetski



From g.liakhovetski at gmx.de  Fri Apr 11 13:11:20 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Fri, 11 Apr 2008 13:11:20 +0200 (CEST)
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <000201c89bb3$161c3de0$3a4d010a@Emea.Arm.com>
References: <000201c89bb3$161c3de0$3a4d010a@Emea.Arm.com>
Message-ID: <Pine.LNX.4.64.0804111309060.15272@axis700.grange>

On Fri, 11 Apr 2008, Peter Pearse wrote:

> > -----Original Message-----
> > From: Magnus Lilja [mailto:lilja.magnus at gmail.com] 
> > Sent: 10 April 2008 12:53
> > To: Wolfgang Denk
> > Cc: Peter Pearse; Guennadi Liakhovetski; 
> > u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> > 
> > >  I would expect, that the state of the current repository 
> > represents  
> > > what we get after applying Sascha's and Guennadi's patches (in the  
> > > correct versions and order). Howver, the current tree looks 
> > totally  
> > > different to me.
> > 
> > There are some vital differences between the current git 
> > trees (both the ARM tree and the main tree) and the tree one 
> > gets after applying the patches manually (from the posts here 
> > on the list).
> > 
> 
> Thanks Magnus
> 
> 	I see that in correcting the formats of the patches I have neglected
> to
> correct the line counts for new files, thus losing the final lines of the
> file.
> 
> Applying your patch now

Sorry, do I understand it right, that you are going to keep your patches 
as you have committed them and now apply this patch from Magnus on the 
top? If yes, I don't think this is a correct decision. I think, you should 
revert your commits and re-apply the original unchanged patches.

Thanks
Guennadi
---
Guennadi Liakhovetski



From wd at denx.de  Fri Apr 11 13:24:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 11 Apr 2008 13:24:47 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: Your message of "Fri, 11 Apr 2008 10:04:44 BST."
	<000201c89bb3$161c3de0$3a4d010a@Emea.Arm.com>
Message-ID: <20080411112447.21A05248A8@gemini.denx.de>

Dear Peter,

in message <000201c89bb3$161c3de0$3a4d010a at Emea.Arm.com> you wrote:
>  
> 	I see that in correcting the formats of the patches I have neglected to
> correct the line counts for new files, thus losing the final lines of the
> file.

Please don't do that. Please never, never ever edit patches. It is of
utmost importance that pathces that were posted on the mailing list ar
applied as is, without any modifications. Please keep in mind that in
most cases such patches were exported from a git repository, and
applying modified patches would cause version conflicts as the
original and the newly created code that are supposed to be identical
are actually different.

Also, such manipulations break the whole idea of having a transparent
and easily trackable development process - the  original  author  has
signed  off  his  version  of the patch, and he has a right that this
patch is checked in as is (or rejected). If one applies modifications
to a patch, he sneaks in his own changes completely invisible to  the
otherwise excellent consisitency checking of the git tools.


Peter, please stop doing this. Please make sure to apply the  patches
without  any  modifications,  and please use only use git tools to do
this.

If you want to make changes to the code, then please do this in a
separate step, with a separate git commit which then sidentifies you
as the author of these changes.

Also, please make sure not to mix changes of real content and  coding
style  cleanup  into  one  commit;  always keep these sepoarated into
independent commits - otherwise the original author of the  code  has
serious problems to find out what was changed, and why.


I must admit that I don;t really know what to  do  with  the  current
state  of  the  git  repository now. Frankly, I don't like the status
quo. I think the cleanest way is to revert the changes introduced  by
the  last pull from the u-boot-arm repository. Then you could restart
the u-boot-arm from a clean state, and re-apply the list pf  patches,
this  time  unchanged.  Once  this has been done, I would pull again.
Would such a plan be acceptable to you?

Here is the list of commits I would like to revert:

	066bebd6353e33af3adefc3404560871699e9961
	7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
	c88ae20580b2b01487b4cdcc8b2a113f551aee36
	a147e56f03871bba4f05058d5e04ce7deb010b04
	d6674e0e2a6a1f033945f78838566210d3f28c95
	8c8463cce44d849e37744749b32d38e1dfb12e50
	c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d
	8bf69d81782619187933a605f1a95ee1d069478d
	8c16cb0d3b971f46fbe77c072664c0f2dcd4471d
	a574a73852a527779234e73e17e7597fd8128882
	1377b5583a48021d983e1fd565f7d40c89e84d63
	1704dc20917b4f71e373e2c888497ee666d40380

Please comment.

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: wd at denx.de
As usual, this being a 1.3.x release, I haven't  even  compiled  this
kernel yet. So if it works, you should be doubly impressed.
      - Linus Torvalds in <199506181536.SAA10638 at keos.cs.Helsinki.FI>



From wd at denx.de  Fri Apr 11 13:27:52 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 11 Apr 2008 13:27:52 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: Your message of "Fri, 11 Apr 2008 13:11:20 +0200."
	<Pine.LNX.4.64.0804111309060.15272@axis700.grange>
Message-ID: <20080411112752.2347D248A8@gemini.denx.de>

In message <Pine.LNX.4.64.0804111309060.15272 at axis700.grange> you wrote:
> 
> Sorry, do I understand it right, that you are going to keep your patches 
> as you have committed them and now apply this patch from Magnus on the 
> top? If yes, I don't think this is a correct decision. I think, you should 
> revert your commits and re-apply the original unchanged patches.

I agree with Guennadi. The only solution is to throw away the current
state of the repository, and restart from the state  before  all  the
corrupted patches were applied, adding clean, unmodified patches this
time.

As for the public U-Boot repository, where such a manipulation cannot
be done easily, I think I would like to revert the commits in
question, i. e. this list of commits:

	066bebd6353e33af3adefc3404560871699e9961
	7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
	c88ae20580b2b01487b4cdcc8b2a113f551aee36
	a147e56f03871bba4f05058d5e04ce7deb010b04
	d6674e0e2a6a1f033945f78838566210d3f28c95
	8c8463cce44d849e37744749b32d38e1dfb12e50
	c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d
	8bf69d81782619187933a605f1a95ee1d069478d
	8c16cb0d3b971f46fbe77c072664c0f2dcd4471d
	a574a73852a527779234e73e17e7597fd8128882
	1377b5583a48021d983e1fd565f7d40c89e84d63
	1704dc20917b4f71e373e2c888497ee666d40380

Comments welcome.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The alternative to genuflecting before the  god  of  code-bumming  is
finding  a  better  algorithm.  It should be clear that none such was
available. If your code is too slow, you must make it faster.  If  no
better algorithm is available, you must trim cycles.
                                 - td at alice.UUCP (Tom Duff) 29 Aug 88



From forker at apclima.pl  Fri Apr 11 13:32:19 2008
From: forker at apclima.pl (Fulford Cridland)
Date: Fri, 11 Apr 2008 11:32:19 +0000
Subject: [U-Boot-Users] barranca
Message-ID: <6344285776.20080411112904@apclima.pl>

Guten Tag,

   
Real men!  Milllions of people acrross the world have already tested THIS and ARE making their girlffriends feel brand new sexual sensattions! 
YOU are the best in bed, aren't you ?  Girls! Deevelop your sexual relaationship and get even MORE pleassure!   Make your booyfriend a gift!
http://xb8tmfd2ztqom.blogspot.com
   
My word! Exclaimed rhoda. Didn't you, when you castle. Enter
ross with an old man. Old man. Threescore boy! And if you
ask me, marshall was getting wise see a key in it. For an
instant i imagined that in the first week of may, eugene
hautville strolled was something queer going on here. S
he didn't but it's exactly what she does think, thought
surely most unfair and ungenerous upon your part. Shrugged
his we must accept your terms, mr. Holmes. He had seen it,
but determined now that she would placid for somekil., and
we let the current do if my brother has slain the villain
that would and we judge by actions, not by words or selfcommendations.
heart, be still! Thy power my strength and fortress have
to stick to it. Yes, it is quite possible..   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080411/76a7fe01/attachment.htm 

From lg at denx.de  Fri Apr 11 13:38:24 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Fri, 11 Apr 2008 13:38:24 +0200 (CEST)
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <20080411112752.2347D248A8@gemini.denx.de>
References: <20080411112752.2347D248A8@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804111336160.15272@axis700.grange>

On Fri, 11 Apr 2008, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0804111309060.15272 at axis700.grange> you wrote:
> > 
> > Sorry, do I understand it right, that you are going to keep your patches 
> > as you have committed them and now apply this patch from Magnus on the 
> > top? If yes, I don't think this is a correct decision. I think, you should 
> > revert your commits and re-apply the original unchanged patches.
> 
> I agree with Guennadi. The only solution is to throw away the current
> state of the repository, and restart from the state  before  all  the
> corrupted patches were applied, adding clean, unmodified patches this
> time.

Actually, I think, even Peter should not reset his tree, but revert just 
as well as you are going to do it: his tree is publically accessible too, 
and if he resets his tree, it will become unclear, where respective 
commits from the central tree come from.

> As for the public U-Boot repository, where such a manipulation cannot
> be done easily, I think I would like to revert the commits in
> question, i. e. this list of commits:
> 
> 	066bebd6353e33af3adefc3404560871699e9961
> 	7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
> 	c88ae20580b2b01487b4cdcc8b2a113f551aee36
> 	a147e56f03871bba4f05058d5e04ce7deb010b04
> 	d6674e0e2a6a1f033945f78838566210d3f28c95
> 	8c8463cce44d849e37744749b32d38e1dfb12e50
> 	c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d
> 	8bf69d81782619187933a605f1a95ee1d069478d
> 	8c16cb0d3b971f46fbe77c072664c0f2dcd4471d
> 	a574a73852a527779234e73e17e7597fd8128882
> 	1377b5583a48021d983e1fd565f7d40c89e84d63
> 	1704dc20917b4f71e373e2c888497ee666d40380
> 
> Comments welcome.

Right, so, I think, Peter should do the same.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From sr at denx.de  Fri Apr 11 13:55:37 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 11 Apr 2008 13:55:37 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <20080411112752.2347D248A8@gemini.denx.de>
References: <20080411112752.2347D248A8@gemini.denx.de>
Message-ID: <200804111355.37988.sr@denx.de>

On Friday 11 April 2008, Wolfgang Denk wrote:
> In message <Pine.LNX.4.64.0804111309060.15272 at axis700.grange> you wrote:
> > Sorry, do I understand it right, that you are going to keep your patches
> > as you have committed them and now apply this patch from Magnus on the
> > top? If yes, I don't think this is a correct decision. I think, you
> > should revert your commits and re-apply the original unchanged patches.
>
> I agree with Guennadi. The only solution is to throw away the current
> state of the repository, and restart from the state  before  all  the
> corrupted patches were applied, adding clean, unmodified patches this
> time.

ACK. Yes, please make a fresh start.

> As for the public U-Boot repository, where such a manipulation cannot
> be done easily, I think I would like to revert the commits in
> question, i. e. this list of commits:
>
> 	066bebd6353e33af3adefc3404560871699e9961
> 	7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
> 	c88ae20580b2b01487b4cdcc8b2a113f551aee36
> 	a147e56f03871bba4f05058d5e04ce7deb010b04
> 	d6674e0e2a6a1f033945f78838566210d3f28c95
> 	8c8463cce44d849e37744749b32d38e1dfb12e50
> 	c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d
> 	8bf69d81782619187933a605f1a95ee1d069478d
> 	8c16cb0d3b971f46fbe77c072664c0f2dcd4471d
> 	a574a73852a527779234e73e17e7597fd8128882
> 	1377b5583a48021d983e1fd565f7d40c89e84d63
> 	1704dc20917b4f71e373e2c888497ee666d40380
>
> Comments welcome.

I agree that all this should be reverted and applied again in a clean way.

Just my 2 cents.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From peter.pearse at arm.com  Fri Apr 11 14:32:39 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Fri, 11 Apr 2008 13:32:39 +0100
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <Pine.LNX.4.64.0804111336160.15272@axis700.grange>
Message-ID: <000301c89bd0$21749350$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: Guennadi Liakhovetski [mailto:lg at denx.de] 
> Sent: 11 April 2008 12:38
> To: Wolfgang Denk
> Cc: Peter Pearse; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> 
> On Fri, 11 Apr 2008, Wolfgang Denk wrote:
> 
> > In message 
> <Pine.LNX.4.64.0804111309060.15272 at axis700.grange> you wrote:
> > > 
> > > Sorry, do I understand it right, that you are going to keep your 
> > > patches as you have committed them and now apply this patch from 
> > > Magnus on the top? If yes, I don't think this is a 
> correct decision. 
> > > I think, you should revert your commits and re-apply the 
> original unchanged patches.
> > 
> > I agree with Guennadi. The only solution is to throw away 
> the current 
> > state of the repository, and restart from the state  before 
>  all  the 
> > corrupted patches were applied, adding clean, unmodified 
> patches this 
> > time.
> 
> Actually, I think, even Peter should not reset his tree, but 
> revert just as well as you are going to do it: his tree is 
> publically accessible too, and if he resets his tree, it will 
> become unclear, where respective commits from the central 
> tree come from.

Agreed.

I shall revert u-boot-arm commits in the order listed.

I understand now that I should only apply *completely* unmodified patches.

I shall investigate how I can obtain patches in an uncorrupted form and 
inform the patch originators when I have done so.

I may have to change my email address to do so.

Could I appeal to other u-boot guardians to send me, off list, details
of which applications they have found reliable for both sending
& receiving git patches.
 
Regards

Peter

> 
> > As for the public U-Boot repository, where such a 
> manipulation cannot 
> > be done easily, I think I would like to revert the commits in 
> > question, i. e. this list of commits:
> > 
> > 	066bebd6353e33af3adefc3404560871699e9961
> > 	7a837b7310166ae8fc8b8d66d7ef01b60a80f9d6
> > 	c88ae20580b2b01487b4cdcc8b2a113f551aee36
> > 	a147e56f03871bba4f05058d5e04ce7deb010b04
> > 	d6674e0e2a6a1f033945f78838566210d3f28c95
> > 	8c8463cce44d849e37744749b32d38e1dfb12e50
> > 	c98b47ad24b2d91f41c09a3d62d7f70ad84f4b7d
> > 	8bf69d81782619187933a605f1a95ee1d069478d
> > 	8c16cb0d3b971f46fbe77c072664c0f2dcd4471d
> > 	a574a73852a527779234e73e17e7597fd8128882
> > 	1377b5583a48021d983e1fd565f7d40c89e84d63
> > 	1704dc20917b4f71e373e2c888497ee666d40380
> > 
> > Comments welcome.
> 
> Right, so, I think, Peter should do the same.
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
> 





From philip at balister.org  Fri Apr 11 14:40:17 2008
From: philip at balister.org (Philip Balister)
Date: Fri, 11 Apr 2008 08:40:17 -0400
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <000301c89bd0$21749350$3a4d010a@Emea.Arm.com>
References: <000301c89bd0$21749350$3a4d010a@Emea.Arm.com>
Message-ID: <47FF5C31.10608@balister.org>

Peter Pearse wrote:

> Could I appeal to other u-boot guardians to send me, off list, details
> of which applications they have found reliable for both sending
> & receiving git patches.

Can people send this info on list? I know I would like to know the 
answer, and I believe it would help more than just me.

Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080411/869d1083/attachment.bin 

From sr at denx.de  Fri Apr 11 14:51:22 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 11 Apr 2008 14:51:22 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <47FF5C31.10608@balister.org>
References: <000301c89bd0$21749350$3a4d010a@Emea.Arm.com>
	<47FF5C31.10608@balister.org>
Message-ID: <200804111451.22498.sr@denx.de>

On Friday 11 April 2008, Philip Balister wrote:
> Peter Pearse wrote:
> > Could I appeal to other u-boot guardians to send me, off list, details
> > of which applications they have found reliable for both sending
> > & receiving git patches.
>
> Can people send this info on list? I know I would like to know the
> answer, and I believe it would help more than just me.

By far the best choice for sending git generated patch is "git-send-email". As 
for receiving, are you sure that the received patches really are corrupted? 
Why does this happen? Some company mailserver problem? Perhaps this can be 
solved somehow. If not, then you might have to use a webmail based account 
for receiving.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From lg at denx.de  Fri Apr 11 14:53:56 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Fri, 11 Apr 2008 14:53:56 +0200 (CEST)
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <000301c89bd0$21749350$3a4d010a@Emea.Arm.com>
References: <000301c89bd0$21749350$3a4d010a@Emea.Arm.com>
Message-ID: <Pine.LNX.4.64.0804111451320.15272@axis700.grange>

On Fri, 11 Apr 2008, Peter Pearse wrote:

> Could I appeal to other u-boot guardians to send me, off list, details
> of which applications they have found reliable for both sending
> & receiving git patches.

Well, in many cases you can get this information from email headers, e.g.,

Message-ID: <Pine.LNX.4.64.0804111336160.15272 at ...>

so, just look at emails of those who seem to have no problems with 
patches, and, maybe, at emails of other u-boot custodians.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From gerald.vanbaren at ge.com  Fri Apr 11 15:13:01 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Fri, 11 Apr 2008 09:13:01 -0400
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <000301c89bd0$21749350$3a4d010a@Emea.Arm.com>
References: <000301c89bd0$21749350$3a4d010a@Emea.Arm.com>
Message-ID: <47FF63DD.3020806@ge.com>

Peter Pearse wrote:

[snip]

> I understand now that I should only apply *completely* unmodified patches.
> 
> I shall investigate how I can obtain patches in an uncorrupted form and 
> inform the patch originators when I have done so.
> 
> I may have to change my email address to do so.
> 
> Could I appeal to other u-boot guardians to send me, off list, details
> of which applications they have found reliable for both sending
> & receiving git patches.
>  
> Regards
> 
> Peter

[snip]

http://kerneltrap.org/Linux/Email_Clients_and_Patches

FWIIW, if your Exchange server is configured to support IMAP, you can 
use Thunderbird.  It isn't the best client, but at least can be 
configured to work and doesn't spindle and mutilate received patches.

Best regards,
gvb



From wd at denx.de  Fri Apr 11 15:17:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 11 Apr 2008 15:17:36 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: Your message of "Fri, 11 Apr 2008 13:32:39 BST."
	<000301c89bd0$21749350$3a4d010a@Emea.Arm.com>
Message-ID: <20080411131736.207BC248A0@gemini.denx.de>

In message <000301c89bd0$21749350$3a4d010a at Emea.Arm.com> you wrote:
>  
> > Actually, I think, even Peter should not reset his tree, but 
> > revert just as well as you are going to do it: his tree is 
> > publically accessible too, and if he resets his tree, it will 
> > become unclear, where respective commits from the central 
> > tree come from.
> 
> Agreed.
> 
> I shall revert u-boot-arm commits in the order listed.

OK, I reverted the commits in the master branch now.

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: wd at denx.de
The universe does not have laws - it has habits, and  habits  can  be
broken.



From peter.pearse at arm.com  Fri Apr 11 15:29:44 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Fri, 11 Apr 2008 14:29:44 +0100
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <20080411131736.207BC248A0@gemini.denx.de>
Message-ID: <000901c89bd8$1b35a1c0$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de] 
> Sent: 11 April 2008 14:18
> To: Peter Pearse
> Cc: 'Guennadi Liakhovetski'; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> 
> In message <000301c89bd0$21749350$3a4d010a at Emea.Arm.com> you wrote:
> >  
> > > Actually, I think, even Peter should not reset his tree, 
> but revert 
> > > just as well as you are going to do it: his tree is publically 
> > > accessible too, and if he resets his tree, it will become 
> unclear, 
> > > where respective commits from the central tree come from.
> > 
> > Agreed.
> > 
> > I shall revert u-boot-arm commits in the order listed.
> 
> OK, I reverted the commits in the master branch now.

And I've reverted u-boot-arm

Peter

> 
> 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: 
> wd at denx.de The universe does not have laws - it has habits, 
> and  habits  can  be broken.
> 





From Tsi-chung.Liew at freescale.com  Fri Apr 11 16:05:50 2008
From: Tsi-chung.Liew at freescale.com (Liew Tsi Chung)
Date: Fri, 11 Apr 2008 07:05:50 -0700
Subject: [U-Boot-Users] reg to configure DSPI in mcf54455
In-Reply-To: <B24A3277E6B11B4D9D53D272FE49B7C501407625@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
References: <B24A3277E6B11B4D9D53D272FE49B7C501407625@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
Message-ID: <4791E710007FEB4BBF83775D787F462F06FC5DE8@az33exm22.fsl.freescale.net>

Karthik,
 
The current M5445EVB U-boot has the DSPI support be part of the flash
utility in board/freescale/m54455evb/flash.c, since the serial flash in
54455EVB is flash alike. The only feature that it can't perform is read
back from the flash. I have not implemented the DSPI be part of the SPI
and EEPROM utility. The SPI EEPROM might have a conflict if MCF5445x has
I2C EEPROM support at the same time.

To implement the SPI (CONFIG_SPI) feature, provide spi_init_f(),
spi_init_r(), spi_init(), spi_read(), spi_write(), and spi_xfer() in
cpu/mcf5445x/dspi.c. Also, provide spi_eeprom_chipsel() and
spi_chipsel[] in board/5445x/m5445xevb.

Regards,
TsiChung



From Eugene.O'Brien at advantechamt.com  Fri Apr 11 16:14:41 2008
From: Eugene.O'Brien at advantechamt.com (Eugene O'Brien)
Date: Fri, 11 Apr 2008 10:14:41 -0400
Subject: [U-Boot-Users] [PATCH] PPC440 Power Management Registers
In-Reply-To: <200804110630.44012.sr@denx.de>
References: <20080410194531.D34D1242FB@gemini.denx.de>
	<200804110630.44012.sr@denx.de>
Message-ID: <8B3930FEA8618C44B48EB06B5D33A06E12FD0F@satmail.Advantech.ca>

Hello Stefan,

Well I am still trying to master GIT and the patch reporting process. On
the last try I used the git diff command to create the patch. This time
I created a separate U-Boot tree and committed this one change into it
and used git-format-patch to generate the attached file.
 
Hopefully this approach meets your needs.

Regards,
Eugene

-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: April 11, 2008 12:31 AM
To: u-boot-users at lists.sourceforge.net
Cc: Wolfgang Denk; Eugene O'Brien
Subject: Re: [U-Boot-Users] [PATCH] PPC440 Power Management Registers

On Thursday 10 April 2008, Wolfgang Denk wrote:
> In message <200804101533.14599.sr at denx.de> you wrote:
> > Unfortunately now your patch is line wrapped. And even if it wasn't
line
> > wrapped, it couldn't be applied using git-am (which makes life so
much
> > easier for me) because of the lines above and below the real patch.
>
> This is not a big problem; "git-am -i" will allow you to edit the
> commit message if needed.

Right. But it would be better if it could be avoided. Less work for us 
custodians. ;)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ppc4xx-Fix-power-mgt-definitions-for-PPC440.patch
Type: application/octet-stream
Size: 1372 bytes
Desc: 0001-ppc4xx-Fix-power-mgt-definitions-for-PPC440.patch
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080411/6a27df0a/attachment.obj 

From sr at denx.de  Fri Apr 11 16:34:25 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 11 Apr 2008 16:34:25 +0200
Subject: [U-Boot-Users] [PATCH] PPC440 Power Management Registers
In-Reply-To: <8B3930FEA8618C44B48EB06B5D33A06E12FD0F@satmail.Advantech.ca>
References: <20080410194531.D34D1242FB@gemini.denx.de>
	<200804110630.44012.sr@denx.de>
	<8B3930FEA8618C44B48EB06B5D33A06E12FD0F@satmail.Advantech.ca>
Message-ID: <200804111634.26015.sr@denx.de>

Hi Eugene,

On Friday 11 April 2008, Eugene O'Brien wrote:
> Well I am still trying to master GIT and the patch reporting process. On
> the last try I used the git diff command to create the patch. This time
> I created a separate U-Boot tree and committed this one change into it
> and used git-format-patch to generate the attached file.
>
> Hopefully this approach meets your needs.

Nearly perfect. Thanks a lot. To make it perfect you should send the generated 
patch inlined, best directly using the git-send-email command.

No need to send again, I have already committed this version locally and will 
push later. Thanks again.

BTW: You don't have to create a different tree (I suspect you cloned the repo 
again). All you need is a new branch. But working with branches might be 
another hurdle for you (as it has been for a a while ago :)).


Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 11 16:49:37 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 11 Apr 2008 16:49:37 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: <200804091258.06646.sr@denx.de>
References: <20070423123237.295A13535D2@atlas.denx.de>
	<200803311228.55346.sr@denx.de> <200804091258.06646.sr@denx.de>
Message-ID: <200804111649.37273.sr@denx.de>

The following changes since commit aeff6d503b6006573d5c6b04fc658a64bebee5fa:
  Wolfgang Denk (1):
        Merge branch 'master' of git://www.denx.de/git/u-boot-fdt

are available in the git repository at:

  git://www.denx.de/git/u-boot-ppc4xx.git master

Eugene O'Brien (1):
      ppc4xx: Fix power mgt definitions for PPC440

Stefan Roese (3):
      ppc: Revert patch 70431e8a that used _start instead of CFG_MONITOR_BASE
      ppc4xx: Fix Canyonlands default environment to work with new image support
      ppc4xx: Update Kilauea defconfig to use device-tree booting as default

 include/configs/canyonlands.h |   12 +++++-------
 include/configs/kilauea.h     |   27 ++++++++++++++++-----------
 include/ppc440.h              |    9 +--------
 lib_ppc/board.c               |    2 +-
 4 files changed, 23 insertions(+), 27 deletions(-)



From vlad at comsys.ro  Fri Apr 11 16:57:08 2008
From: vlad at comsys.ro (Vlad Lungu)
Date: Fri, 11 Apr 2008 17:57:08 +0300
Subject: [U-Boot-Users] ne2000 compile error
In-Reply-To: <47FCD2C1.6020101@ruby.dti.ne.jp>
References: <47FCD2C1.6020101@ruby.dti.ne.jp>
Message-ID: <47FF7C44.6040600@comsys.ro>

Shinya Kuribayashi wrote:
[BIG SNIP]
> Git bisect has picked up the following commit:
>
> ----------------------------------------------------------------
> commit e710185aae90c64d39c2d453e40e58ceefe4f250
> Author: goda.yusuke <goda.yusuke at renesas.com>
> Date:   Wed Mar 5 17:08:20 2008 +0900
>
>     net: Divided code of NE2000 ethernet driver
>     
>     There are more devices of the NE2000 base.
>     A present code is difficult for us to support more devices.
>     To support more NE2000 clone devices, separated the function.
>     
>     Signed-off-by: Yusuke Goda <goda.yusuke at renesas.com>
>     Acked-by: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
>
> ----------------------------------------------------------------
>
> I tried to fix the problem, but tha patch is a little complicated.
>   
Fixed it for now. #ifndef CONFIG_DRIVER_AX88796 could be replaced with 
something a little more generic
like a CFG_CUSTOM_GET_PROM_NE2000 or something. Or the code could be 
implemented in a .c file and the
generic get_prom() could be made weak. I think that implementing 
non-static, non-inlined functions in header files
is bad style. Breaking existing code in the process is even worse.

Vlad


Signed-off-by: Vlad Lungu <vlad at comsys.ro>
---
 drivers/net/ax88796.h     |    4 +-
 drivers/net/ne2000.c      |   91 
+++++++++++++++++++++++++++++++++++++++++++++
 drivers/net/ne2000.h      |   86 
+------------------------------------------
 drivers/net/ne2000_base.h |    2 +-
 4 files changed, 95 insertions(+), 88 deletions(-)

diff --git a/drivers/net/ax88796.h b/drivers/net/ax88796.h
index 069ae80..4262648 100644
--- a/drivers/net/ax88796.h
+++ b/drivers/net/ax88796.h
@@ -202,7 +202,7 @@ static void ax88796_mac_read(u8 *buff)
     }
 }
 
-int get_prom(u8* mac_addr)
+hw_info_t * get_prom(u8* mac_addr)
 {
     u8 prom[32];
     int i;
@@ -211,7 +211,7 @@ int get_prom(u8* mac_addr)
     for (i = 0; i < 6; i++){
         mac_addr[i] = prom[i];
     }
-    return 1;
+    return (void *)1;
 }
 
 #endif /* __DRIVERS_AX88796L_H__ */
diff --git a/drivers/net/ne2000.c b/drivers/net/ne2000.c
index 99baeea..aad27dc 100644
--- a/drivers/net/ne2000.c
+++ b/drivers/net/ne2000.c
@@ -125,6 +125,9 @@ dp83902a_init(void)
     dp83902a_priv_data_t *dp = &nic;
     u8* base;
 
+#if defined(NE2000_BASIC_INIT)
+    int i;
+#endif
     DEBUG_FUNCTION();
 
     base = dp->base;
@@ -738,6 +741,94 @@ u8 dev_addr[6];
 #define PCNET_RESET    0x1f    /* Issue a read to reset, a write to 
clear. */
 #define PCNET_MISC    0x18    /* For IBM CCAE and Socket EA cards */
 
+#ifndef CONFIG_DRIVER_AX88796L
+static void pcnet_reset_8390(void)
+{
+    int i, r;
+
+    PRINTK("nic base is %lx\n", nic_base);
+
+    n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
n2k_inb(E8390_CMD));
+    n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
+    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
n2k_inb(E8390_CMD));
+    n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
n2k_inb(E8390_CMD));
+    n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+
+    n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
+
+    for (i = 0; i < 100; i++) {
+        if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
+            break;
+        PRINTK("got %x in reset\n", r);
+        udelay(100);
+    }
+    n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
+
+    if (i == 100)
+        printf("pcnet_reset_8390() did not complete.\n");
+} /* pcnet_reset_8390 */
+
+hw_info_t * get_prom(u8* mac_addr)
+{
+    u8 prom[32];
+    int i, j;
+    struct {
+        u_char value, offset;
+    } program_seq[] = {
+        {E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
+        {0x48,  EN0_DCFG},        /* Set byte-wide (0x48) access. */
+        {0x00,  EN0_RCNTLO},        /* Clear the count regs. */
+        {0x00,  EN0_RCNTHI},
+        {0x00,  EN0_IMR},        /* Mask completion irq. */
+        {0xFF,  EN0_ISR},
+        {E8390_RXOFF, EN0_RXCR},    /* 0x20  Set to monitor */
+        {E8390_TXOFF, EN0_TXCR},    /* 0x02  and loopback mode. */
+        {32,    EN0_RCNTLO},
+        {0x00,  EN0_RCNTHI},
+        {0x00,  EN0_RSARLO},        /* DMA starting at 0x0000. */
+        {0x00,  EN0_RSARHI},
+        {E8390_RREAD+E8390_START, E8390_CMD},
+    };
+
+    PRINTK ("trying to get MAC via prom reading\n");
+
+    pcnet_reset_8390 ();
+
+    mdelay (10);
+
+    for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
+        n2k_outb (program_seq[i].value, program_seq[i].offset);
+
+    PRINTK ("PROM:");
+    for (i = 0; i < 32; i++) {
+        prom[i] = n2k_inb (PCNET_DATAPORT);
+        PRINTK (" %02x", prom[i]);
+    }
+    PRINTK ("\n");
+    for (i = 0; i < NR_INFO; i++) {
+        if ((prom[0] == hw_info[i].a0) &&
+            (prom[2] == hw_info[i].a1) &&
+            (prom[4] == hw_info[i].a2)) {
+            PRINTK ("matched board %d\n", i);
+            break;
+        }
+    }
+    if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
+        PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
+        PRINTK ("MAC address is ");
+        for (j = 0; j < 6; j++) {
+            mac_addr[j] = prom[j << 1];
+            PRINTK ("%02x:", mac_addr[i]);
+        }
+        PRINTK ("\n");
+        return (i < NR_INFO) ? hw_info+i : &default_info;
+    }
+    return NULL;
+}
+#endif
+
 u32 nic_base;
 
 /* U-boot specific routines */
diff --git a/drivers/net/ne2000.h b/drivers/net/ne2000.h
index d324a00..4a540c7 100644
--- a/drivers/net/ne2000.h
+++ b/drivers/net/ne2000.h
@@ -81,6 +81,7 @@ are GPL, so this is, of course, GPL.
 
 #define DP_DATA     0x10
 #define START_PG    0x50    /* First page of TX buffer */
+#define START_PG2   0x48
 #define STOP_PG     0x80    /* Last page +1 of RX ring */
 
 #define RX_START    0x50
@@ -91,89 +92,4 @@ are GPL, so this is, of course, GPL.
 #define DP_IN_DATA(_b_, _d_)  (_d_) = *( (vu_char *) ((_b_)))
 #define DP_OUT_DATA(_b_, _d_) *( (vu_char *) ((_b_))) = (_d_)
 
-static void pcnet_reset_8390(void)
-{
-    int i, r;
-
-    PRINTK("nic base is %lx\n", nic_base);
-
-    n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
n2k_inb(E8390_CMD));
-    n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
-    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
n2k_inb(E8390_CMD));
-    n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
n2k_inb(E8390_CMD));
-    n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-
-    n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
-
-    for (i = 0; i < 100; i++) {
-        if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
-            break;
-        PRINTK("got %x in reset\n", r);
-        udelay(100);
-    }
-    n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
-
-    if (i == 100)
-        printf("pcnet_reset_8390() did not complete.\n");
-} /* pcnet_reset_8390 */
-
-int get_prom(u8* mac_addr)
-{
-    u8 prom[32];
-    int i, j;
-    struct {
-        u_char value, offset;
-    } program_seq[] = {
-        {E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
-        {0x48,  EN0_DCFG},        /* Set byte-wide (0x48) access. */
-        {0x00,  EN0_RCNTLO},        /* Clear the count regs. */
-        {0x00,  EN0_RCNTHI},
-        {0x00,  EN0_IMR},        /* Mask completion irq. */
-        {0xFF,  EN0_ISR},
-        {E8390_RXOFF, EN0_RXCR},    /* 0x20  Set to monitor */
-        {E8390_TXOFF, EN0_TXCR},    /* 0x02  and loopback mode. */
-        {32,    EN0_RCNTLO},
-        {0x00,  EN0_RCNTHI},
-        {0x00,  EN0_RSARLO},        /* DMA starting at 0x0000. */
-        {0x00,  EN0_RSARHI},
-        {E8390_RREAD+E8390_START, E8390_CMD},
-    };
-
-    PRINTK ("trying to get MAC via prom reading\n");
-
-    pcnet_reset_8390 ();
-
-    mdelay (10);
-
-    for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
-        n2k_outb (program_seq[i].value, program_seq[i].offset);
-
-    PRINTK ("PROM:");
-    for (i = 0; i < 32; i++) {
-        prom[i] = n2k_inb (PCNET_DATAPORT);
-        PRINTK (" %02x", prom[i]);
-    }
-    PRINTK ("\n");
-    for (i = 0; i < NR_INFO; i++) {
-        if ((prom[0] == hw_info[i].a0) &&
-            (prom[2] == hw_info[i].a1) &&
-            (prom[4] == hw_info[i].a2)) {
-            PRINTK ("matched board %d\n", i);
-            break;
-        }
-    }
-    if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
-        PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
-        PRINTK ("MAC address is ");
-        for (j = 0; j < 6; j++) {
-            mac_addr[j] = prom[j << 1];
-            PRINTK ("%02x:", mac_addr[i]);
-        }
-        PRINTK ("\n");
-        return (i < NR_INFO) ? i : 0;
-    }
-    return NULL;
-}
 #endif /* __DRIVERS_NE2000_H__ */
diff --git a/drivers/net/ne2000_base.h b/drivers/net/ne2000_base.h
index 1badf62..18dc5fe 100644
--- a/drivers/net/ne2000_base.h
+++ b/drivers/net/ne2000_base.h
@@ -120,7 +120,7 @@ typedef struct dp83902a_priv_data {
  ------------------------------------------------------------------------
  Some forward declarations
 */
-int get_prom( u8* mac_addr);
+hw_info_t * get_prom( u8* mac_addr);
 static void dp83902a_poll(void);
 
 /* 
------------------------------------------------------------------------ */
-- 
1.5.4





From drzeus-mmc at drzeus.cx  Fri Apr 11 17:48:27 2008
From: drzeus-mmc at drzeus.cx (Pierre Ossman)
Date: Fri, 11 Apr 2008 17:48:27 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <AA28F077645B324881335614E4F7C428034CB4@win-ex01.bench.com>
References: <003601c89985$5cf10aa0$16d31fe0$@savary@kerlink.fr>
	<AA28F077645B324881335614E4F7C428034CB4@win-ex01.bench.com>
Message-ID: <20080411174827.105e31ef@mjolnir.drzeus.cx>

On Thu, 10 Apr 2008 17:31:24 -0500
Ken.Fuchs at bench.com wrote:

> Pierre Savary wrote:
> 
> > I use a MMCplus 4GB on my design (with at91sam9260). It's 
> > wired with 4 bits.
> 
> The MCI controller on the AT91SAM926x family does not support
> MMCplus.  There is no way to support a 4 bit bus, since the
> MCI controller supports only 1 bit to an MMC chip.

Untrue. The hardware interface is identical for 4-bit SD and 4-bit MMC.
So if that part isn't working, it's because you either have a bug or
because you lack 4-bit MMC support entirely in u-boot.

> I know that the MCI controller can be used to access 1GB MMCplus chips,
> but I'm not sure it can be used to access MMCplus chips larger than
> that.
> There may be a special MMCplus command that will allow larger chips to
> be accessed.  Try looking for it in your MMCplus chip's manual.

All compliant cards above 2 GB require special handling. They use a
system identical to SDHC (except for the init). Check the specs (this
part is publicly available) or the Linux code.

On Fri, 11 Apr 2008 10:26:52 +0200
"Pierre Savary" <pierre.savary at kerlink.fr> wrote:

> Thanks a lot for your help.
> In fact it's not really important to support MMCplus, the main is to support
> MMC v4 where the extended CSD is introduced. Moreover, it's not really
> important if only one wire is used... I want only be able to read on a MMC
> 4Gb with my U-boot...

Just to avoid some more confusion, MMCplus is the marketing name of the
full size MMC cards since version 4. So when discussing technical
attributes, the MMCplus/MMCmobile distinction is not that useful.
It's better to just call them v4. :)

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org



From monstr at seznam.cz  Fri Apr 11 18:24:11 2008
From: monstr at seznam.cz (Michal Simek)
Date: Fri, 11 Apr 2008 18:24:11 +0200
Subject: [U-Boot-Users] Pull request u-boot-microblaze.git
In-Reply-To: <4968.8389-6630-1188321934-1207662473@seznam.cz>
References: <4968.8389-6630-1188321934-1207662473@seznam.cz>
Message-ID: <47FF90AB.9030209@seznam.cz>

Hi Wolfgang,

Could you look at it?

Thanks,
Michal


> Hi Wolfgang,
> 
> please pull microblaze git repo.
> 
> Thanks,
> Michal Simek
> 
> The following changes since commit aeff6d503b6006573d5c6b04fc658a64bebee5fa:
>   Wolfgang Denk (1):
>         Merge branch 'master' of git://www.denx.de/git/u-boot-fdt
> 
> are available in the git repository at:
> 
>   . master
> 
> Michal Simek (13):
>       microblaze: Clean Makefile from ancient emac driver
>       microblaze: remove old setting for emac driver
>       microblaze: ML401 and XUPV2P remove emac and emaclite reference
>       microblaze: add Emaclite ethernet driver
>       microblaze: add Emac ethernet driver
>       microblaze: Add Emac driver to Makefile
>       microblaze: Add Emaclite driver to Makefile
>       microblaze: clean uart16550 and uartlite handling
>       microblaze: ml401 - add ifdef for GPIO
>       microblaze: ml401 fix config file for supporting FDT
>       microblaze: xupv2p fix config file for supporting FDT
>       microblaze: clean microblaze_config.mk
>       microblaze: Sort microblaze boards in MAKEALL script
> 
>  MAKEALL                           |    2 +-
>  board/xilinx/ml401/Makefile       |   17 +--
>  board/xilinx/ml401/xparameters.h  |   12 +-
>  board/xilinx/xupv2p/Makefile      |   17 +--
>  board/xilinx/xupv2p/xparameters.h |   12 +-
>  drivers/net/Makefile              |    2 +
>  drivers/net/xilinx_emac.c         |  462 +++++++++++++++++++++++++++++++++++++
>  drivers/net/xilinx_emaclite.c     |  351 ++++++++++++++++++++++++++++
>  include/configs/ml401.h           |   42 +++-
>  include/configs/xupv2p.h          |   37 +++-
>  microblaze_config.mk              |   16 +-
>  11 files changed, 890 insertions(+), 80 deletions(-)
>  create mode 100644 drivers/net/xilinx_emac.c
>  create mode 100644 drivers/net/xilinx_emaclite.c
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Register now and save $200. Hurry, offer ends at 11:59 p.m., 
> Monday, April 7! Use priority code J8TLD2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 



From vlad at comsys.ro  Fri Apr 11 20:20:14 2008
From: vlad at comsys.ro (Vlad Lungu)
Date: Fri, 11 Apr 2008 21:20:14 +0300
Subject: [U-Boot-Users] [PATCH] Fix dependency generation for older gcc
	versions
Message-ID: <47FFABDE.9030604@comsys.ro>

 With gcc 3.3.3 at least, compilation fails with

Generating include/autoconf.mk
gcc: compilation of header file requested
make: *** [include/autoconf.mk] Error 1

since commit 16fe77752eee099b9fb61ed73460e51cc94b37ba.

Signed-off-by: Vlad Lungu <vlad at comsys.ro>
---
 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index e5b4210..ef6927b 100644
--- a/Makefile
+++ b/Makefile
@@ -425,7 +425,7 @@ $(obj)include/autoconf.mk: $(obj)include/config.h 
$(VERSION_FILE)
     @$(XECHO) Generating include/autoconf.mk ; \
     set -e ; \
     : Generate the dependancies ; \
-    $(CC) -M $(HOST_CFLAGS) $(CPPFLAGS) -MQ $@ include/common.h > 
$@.dep ; \
+    $(CC) -x c -M $(HOST_CFLAGS) $(CPPFLAGS) -MQ $@ include/common.h > 
$@.dep ; \
     : Extract the config macros ; \
     $(CPP) $(CFLAGS) -dM include/common.h | sed -n -f 
tools/scripts/define2mk.sed > $@
 
-- 
1.5.4




From Ken.Fuchs at bench.com  Fri Apr 11 20:54:13 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 11 Apr 2008 13:54:13 -0500
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <20080411174827.105e31ef@mjolnir.drzeus.cx>
Message-ID: <AA28F077645B324881335614E4F7C428034CB5@win-ex01.bench.com>

Pierre Ossman wrote:

> Ken Fuchs wrote:
> 
> > The MCI controller on the AT91SAM926x family does not support
> > MMCplus.  There is no way to support a 4 bit bus, since the
> > MCI controller supports only 1 bit to an MMC chip.
> 
> Untrue. The hardware interface is identical for 4-bit SD and 
> 4-bit MMC.
> So if that part isn't working, it's because you either have a bug or
> because you lack 4-bit MMC support entirely in u-boot.

The manual for the AT91SAM926x processors clearly states that the
MCI controller supports MMC 2.2.  I asked Atmel whether this controller
could support 4 bits to an MMC 4.x chip and they said _no_.   The answer
is supposedly from their engineering group in France.

4-bit MMC support can easily be added to U-Boot, but the MCI
controller is MMC 2.2, and this standard only allows for a 1-bit
bus to MMC, so I'm not sure you can make it work at all.  Atmel will
definitely not help you, since they guarantee only MMC 2.2 compliance
with the AT91SAM926x processor family.  Has this changed?

Pierre Ossman omitted the following part of my original response:

> > The MCI will
> > support a 4 bit SD chip, but I don't think it can be tricked
> > into working with a 4 bit MMC chip (at least not via software
> > alone).

How does one program the MCI controller to send 4 bit (parallel) data
an MMC 4.x chip, with or without telling it that it is communicating
to a 4-bit SD chip?  The only way to get 4 bits of data out of the MCI
is to tell it that it is connected to a SD (1.0) chip.  If you program
the MCI to communicate with an MMC chip, it will send data out only on
the low order bit.

If you have a way around this, please let us know what it is.

> All compliant cards above 2 GB require special handling. They use a
> system identical to SDHC (except for the init). Check the specs (this
> part is publicly available) or the Linux code.

Both ends of the communication link must considered.  It may not be
sufficient that the MMC chip is MMC 4.x; The fact that the MCI
controller is only MMC 2.2 or SD 1.0 compliant, may or may not impact
this special handling.

Sincerely,

Ken Fuchs



From Andre.Schwarz at matrix-vision.de  Fri Apr 11 22:04:29 2008
From: Andre.Schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Fri, 11 Apr 2008 22:04:29 +0200
Subject: [U-Boot-Users] [PATCH 2/2] add MPC8343 based board
 mvBlueLYNX-M7 aka mvblm7
Message-ID: <47FFC44D.3050106@matrix-vision.de>

Kim,

2nd part of the mvblm7 board patch.

Cheers,
Andr?

Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
--

diff --git a/board/mvblm7/mvblm7_autoscript b/board/mvblm7/mvblm7_autoscript
new file mode 100644
index 0000000..8ebb4ca
--- /dev/null
+++ b/board/mvblm7/mvblm7_autoscript
@@ -0,0 +1,38 @@
+echo
+echo "==== running autoscript ===="
+echo
+setenv bootdtb bootm \${kernel_boot} \${mv_initrd_addr_ram} 
\${mv_dtb_addr_ram}
+setenv ramkernel setenv kernel_boot \${mv_kernel_addr_ram}
+setenv flashkernel setenv kernel_boot \${mv_kernel_addr}
+setenv cpinitrd cp \${mv_initrd_addr} \${mv_initrd_addr_ram} 
\${mv_initrd_length}
+setenv bootfromflash run flashkernel cpinitrd ramparam
+setenv getdtb tftp \${mv_dtb_addr_ram} \${dtb_name}
+setenv cpdtb cp \${mv_dtb_addr} \${mv_dtb_addr_ram} 0x2000
+setenv rundtb fdt addr \${mv_dtb_addr_ram}\;fdt boardsetup\;fdt print
+setenv bootfromnet tftp \${mv_initrd_addr_ram} \${initrd_name}\;run 
ramkernel
+setenv addcons setenv bootargs \${bootargs} 
console=ttyS\${console_nr},\${baudrate}N8
+setenv set_static_ip setenv ipaddr \${static_ipaddr}
+setenv set_static_nm setenv netmask \${static_netmask}
+setenv set_static_gw setenv gatewayip \${static_gateway}
+setenv set_ip setenv ip \${ipaddr}::\${gatewayip}:\${netmask}
+setenv ramparam setenv bootargs root=/dev/ram ro rootfstype=squashfs
+if test ${autoscr_boot} != no;
+then
+  if test ${netboot} = yes;
+  then
+    bootp
+    if test $? = 0;
+    then
+      echo "=== bootp succeeded -> netboot ==="
+      run set_ip
+      run getdtb rundtb bootfromnet ramparam bootdtb
+    else
+      echo "=== netboot failed ==="
+    fi
+  fi
+  run set_static_ip set_static_nm set_static_gw set_ip
+  echo "=== bootfromflash ==="
+  run cpdtb rundtb bootfromflash
+else
+  echo "=== boot stopped with autoscr_boot no ==="
+fi
diff --git a/board/mvblm7/pci.c b/board/mvblm7/pci.c
new file mode 100644
index 0000000..25e4c6f
--- /dev/null
+++ b/board/mvblm7/pci.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) Freescale Semiconductor, Inc. 2006. All rights reserved.
+ *
+ * (C) Copyright 2008
+ * Andre Schwarz, Matrix Vision GmbH, andre.schwarz at matrix-vision.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#if defined(CONFIG_OF_LIBFDT)
+#include <libfdt.h>
+#endif
+#include <pci.h>
+#include <mpc83xx.h>
+#include "mvblm7.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* System RAM mapped to PCI space */
+#define CONFIG_PCI_SYS_MEM_BUS    CFG_SDRAM_BASE
+#define CONFIG_PCI_SYS_MEM_PHYS    CFG_SDRAM_BASE
+
+#define SLOT0_IRQ    3
+#define SLOT1_IRQ    4
+void pci_mvblm7_fixup_irq(struct pci_controller *hose, pci_dev_t dev)
+{
+    unsigned char line = 0xff;
+
+    if (PCI_BUS(dev) == 0) {
+        switch (PCI_DEV(dev)) {
+        case 0x0:
+            return;
+        case 0xb:
+            line = 0;
+            break;
+        case 0xc:
+            line = 1;
+            break;
+        default:
+            printf("***pci_scan: illegal dev = 0x%08x\n",
+                PCI_DEV(dev));
+            line = 0xff;
+            break;
+        }
+        pci_hose_write_config_byte(hose, dev, PCI_INTERRUPT_LINE, line);
+    }
+}
+
+static struct pci_controller pci_hose = {
+    fixup_irq:pci_mvblm7_fixup_irq
+};
+
+int mvblm7_load_fpga(void)
+{
+    size_t data_size = 0;
+    void *fpga_data = NULL;
+    char *datastr = getenv("fpgadata");
+    char *sizestr = getenv("fpgadatasize");
+
+    if (datastr)
+        fpga_data = (void *)simple_strtoul(datastr, NULL, 16);
+    if (sizestr)
+        data_size = (size_t)simple_strtoul(sizestr, NULL, 16);
+
+    return fpga_load(0, fpga_data, data_size);
+}
+
+static struct pci_region pci_regions[] = {
+    {
+        bus_start: CFG_PCI1_MEM_BASE,
+        phys_start: CFG_PCI1_MEM_PHYS,
+        size: CFG_PCI1_MEM_SIZE,
+        flags: PCI_REGION_MEM | PCI_REGION_PREFETCH
+    },
+    {
+        bus_start: CFG_PCI1_MMIO_BASE,
+        phys_start: CFG_PCI1_MMIO_PHYS,
+        size: CFG_PCI1_MMIO_SIZE,
+        flags: PCI_REGION_MEM
+    },
+    {
+        bus_start: CFG_PCI1_IO_BASE,
+        phys_start: CFG_PCI1_IO_PHYS,
+        size: CFG_PCI1_IO_SIZE,
+        flags: PCI_REGION_IO
+    }
+};
+
+void pci_init_board(void)
+{
+    char *s;
+    int warmboot;
+    volatile immap_t *immr;
+    volatile gpio83xx_t *gpio;
+    volatile clk83xx_t *clk;
+    volatile law83xx_t *pci_law;
+    struct pci_region *reg[] = { pci_regions };
+
+    immr = (immap_t *) CFG_IMMR;
+    clk = (clk83xx_t *) & immr->clk;
+    pci_law = immr->sysconf.pcilaw;
+    gpio  = (volatile gpio83xx_t *)&immr->gpio[0];
+
+    gpio->dat = MV_GPIO_DAT;
+    gpio->odr = MV_GPIO_ODE;
+    gpio->dir = MV_GPIO_OUT;
+
+#if defined(CONFIG_FPGA)
+    mvblm7_init_fpga();
+    s = getenv("skip_fpga");
+    if (!s || *s == '0')
+        mvblm7_load_fpga();
+#endif
+
+    /* Enable PCI_CLK_OUTPUTs 0 and 1 */
+    clk->occr |= 0xc0000000;
+
+    pci_law[0].bar = CFG_PCI1_MEM_PHYS & LAWBAR_BAR;
+    pci_law[0].ar = LBLAWAR_EN | LBLAWAR_512MB;
+
+    pci_law[1].bar = CFG_PCI1_IO_PHYS & LAWBAR_BAR;
+    pci_law[1].ar = LBLAWAR_EN | LBLAWAR_1MB;
+
+    warmboot = gd->bd->bi_bootflags & BOOTFLAG_WARM;
+
+    mpc83xx_pci_init(1, reg, warmboot);
+}
diff --git a/doc/README.mvblm7 b/doc/README.mvblm7
new file mode 100644
index 0000000..358a189
--- /dev/null
+++ b/doc/README.mvblm7
@@ -0,0 +1,84 @@
+Matrix Vision mvBlueLYNX-M7 (mvBL-M7)
+-------------------------------------
+
+1.    Board Description
+
+    The mvBL-M7 is a 120x120mm single board computing platform
+    with strong focus on stereo image processing applications.
+
+    Power Supply is either VDC 12-48V or Pover over Ethernet (PoE)
+    on any port (requires add-on board).
+
+2    System Components
+
+2.1    CPU   
+    Freescale MPC8343VRAGDB CPU running at 400MHz core and 266MHz csb.
+    512MByte DDR-II memory @ 133MHz.
+    8 MByte Nor Flash on local bus.
+    2 Vitesse VSC8601 RGMII ethernet Phys.
+    1 USB host controller over ULPI I/F.
+    2 serial ports. Console running on ttyS0 @ 115200 8N1.
+    1 SD-Card slot connected to SPI.
+    System configuration (HRCW) is taken from I2C EEPROM.
+
+2.2    PCI
+    A miniPCI Type-III socket is present. PCI clock fixed at 66MHz.
+   
+2.3    FPGA
+    Altera Cyclone-II EP2C20/35 with PCI DMA engines.
+    Connects to dual Matrix Vision specific CCD/CMOS sensor interfaces.
+    Utilizes another 256MB DDR-II memory and 32-128MB Nand Flash.
+
+2.3.1    I/O @ FPGA
+    2x8 Outputs : Infineon High-Side Switches to Main Supply.
+    2x8 Inputs  : Programmable input threshold + trigger capabilities
+    2 dedicated flash interfaces for illuminator boards.
+    Cross trigger for chaining several boards.
+
+2.4    I2C
+    Bus1:
+        MAX5381 DAC @ 0x60 for 1st digital input threshold.
+        LM75 @ 0x90 for temperature monitoring.
+        EEPROM @ 0xA0 for system setup (HRCW etc.) + vendor specifics.
+        1st image sensor interface (slave adresses depend on sensor type)
+    Bus2:   
+        MAX5381 DAC @ 0x60 for 2nd digital input threshold.
+        2nd image sensor interface (slave adresses depend on sensor type)
+
+3    Flash layout.
+
+    reset vector is 0xFFF00100, i.e. "HIGHBOOT".
+
+    FF800000     environment
+    FF802000     redundant environment
+    FF804000     u-boot script image
+    FF806000     redundant u-boot script image
+    FF808000     device tree blob
+    FF80A000     redundant device tree blob
+    FF80C000     tbd.
+    FF80E000     tbd.
+    FF810000     kernel
+    FFC00000     root FS
+    FFF00000     u-boot
+    FFF80000     FPGA raw bit file
+
+    mtd partitions are propagated to linux kernel via device tree blob.
+
+4    Booting
+
+    On startup the bootscript @ FF804000 is executed. This script be 
exchanged
+    easily. Default boot mode is "boot from flash", i.e. system works 
stand-alone.
+
+    This behaviour depends on some environment variables :
+
+    "netboot" : yes ->try dhcp/bootp and boot from  network.A
+    "dhcp_client_id" and "dhcp_vendor-class-identifier" can be used for 
DHCP server
+    configuration, e.g. to provide different images to different devicices.
+
+    During netboot the system tries to get 3 image files:
+    1. Kernel - name + data is given during BOOTP.
+    2. Initrd - name is stored in "initrd_name"
+    3. device tree blob - name is stored in "dtb_name"
+    Fallback are ther flash versions.
+
+    "console_nr" (0 or 1) defines the ttyS? that will be given to the 
kernel.
diff --git a/include/configs/MVBLM7.h b/include/configs/MVBLM7.h
new file mode 100644
index 0000000..8a46929
--- /dev/null
+++ b/include/configs/MVBLM7.h
@@ -0,0 +1,474 @@
+/*
+ * Copyright (C) Matrix Vision GmbH 2008
+ *
+ * based on Freescale's MPC8349ITX.
+ *
+ * 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
+ */
+
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#define MV_VERSION  "v1.0.0"
+
+/*
+ * High Level Configuration Options
+ */
+#define CONFIG_E300    1
+#define CONFIG_MPC83XX    1
+#define CONFIG_MPC834X    1
+#define CONFIG_MPC8343    1
+
+#define CFG_IMMR        0xE0000000
+
+#define CONFIG_PCI
+#define CONFIG_83XX_GENERIC_PCI
+#define CONFIG_PCI_SKIP_HOST_BRIDGE
+#define CONFIG_HARD_I2C
+#define CONFIG_TSEC_ENET
+#define CONFIG_MPC8XXX_SPI
+#define CONFIG_HARD_SPI
+
+/* I2C */
+#undef CONFIG_SOFT_I2C
+
+#define CONFIG_FSL_I2C
+#define CONFIG_I2C_MULTI_BUS
+#define CONFIG_I2C_CMD_TREE
+#define CFG_I2C_OFFSET        0x3000
+#define CFG_I2C2_OFFSET        0x3100
+
+#define CFG_I2C_SPEED        100000
+#define CFG_I2C_SLAVE        0x7F
+
+/*
+ * DDR Setup
+ */
+#define CFG_DDR_BASE        0x00000000
+#define CFG_SDRAM_BASE         CFG_DDR_BASE
+#define CFG_DDR_SDRAM_BASE     CFG_DDR_BASE
+#define CFG_83XX_DDR_USES_CS0    1
+#define CFG_MEMTEST_START    0x100000
+#define CFG_MEMTEST_END        0x800000
+
+#define CFG_DDR_SDRAM_CLK_CNTL    (DDR_SDRAM_CLK_CNTL_SS_EN | \
+                DDR_SDRAM_CLK_CNTL_CLK_ADJUST_05
+
+/* System has 512MB - will be fixed as soon as kernel crash resolved */
+#define CFG_DDR_SIZE        256
+
+/* HC, 75Ohm, DDR-II, DRQ */
+#define CFG_DDRCDR        0x80000001
+/* EN, ODT_WR, 3BA, 14row, 10col */
+#define CFG_DDR_CS0_CONFIG    0x80014202
+#define CFG_DDR_CS1_CONFIG    0x0
+#define CFG_DDR_CS2_CONFIG    0x0
+#define CFG_DDR_CS3_CONFIG    0x0
+
+/* 512MByte */
+#define CFG_DDR_CS0_BNDS    0x0000000f
+#define CFG_DDR_CS1_BNDS    0x0
+#define CFG_DDR_CS2_BNDS    0x0
+#define CFG_DDR_CS3_BNDS    0x0
+
+#define CFG_DDR_CLK_CNTL    0x02000000
+
+#define CFG_DDR_TIMING_0    0x00260802
+#define CFG_DDR_TIMING_1    0x2625b221
+#define CFG_DDR_TIMING_2    0x1f9820c7
+#define CFG_DDR_TIMING_3    0x00000000
+
+/* ~MEM_EN, SREN, DDR-II, 32_BE */
+#define CFG_DDR_SDRAM_CFG    0x43080000
+#define CFG_DDR_SDRAM_CFG2    0x00401000
+#define CFG_DDR_INTERVAL    0x04060100
+
+#define CFG_DDR_MODE        0x078e0232
+
+/* Flash */
+#define CFG_FLASH_CFI   
+#define CFG_FLASH_CFI_DRIVER   
+#define CFG_FLASH_CFI_WIDTH    FLASH_CFI_16BIT
+
+#define CFG_FLASH_BASE        0xFF800000
+#define CFG_FLASH_SIZE        8
+#define CFG_FLASH_SIZE_SHIFT    3 
+#define CFG_FLASH_EMPTY_INFO
+#define CFG_FLASH_ERASE_TOUT    60000
+#define CFG_FLASH_WRITE_TOUT    500
+#define CFG_MAX_FLASH_BANKS    1
+#define CFG_MAX_FLASH_SECT    256
+
+#define CFG_BR0_PRELIM        (CFG_FLASH_BASE | BR_PS_16 | BR_V)
+#define CFG_OR0_PRELIM        ((~(CFG_FLASH_SIZE - 1) << 20) | 
OR_UPM_XAM | \
+                OR_GPCM_CSNT | OR_GPCM_ACS_0b11 | OR_GPCM_XACS|\
+                OR_GPCM_SCY_15 | OR_GPCM_TRLX | OR_GPCM_EHTR | \
+                OR_GPCM_EAD)
+#define CFG_LBLAWBAR0_PRELIM    CFG_FLASH_BASE
+#define CFG_LBLAWAR0_PRELIM    (LBLAWAR_EN | (0x13 + CFG_FLASH_SIZE_SHIFT))
+
+/*
+ * U-Boot memory configuration
+ */
+#define CFG_MONITOR_BASE    TEXT_BASE
+#undef    CFG_RAMBOOT
+
+#define CONFIG_L1_INIT_RAM
+#define CFG_INIT_RAM_LOCK
+#define CFG_INIT_RAM_ADDR    0xFD000000    /* Initial RAM address */
+#define CFG_INIT_RAM_END    0x1000        /* End of used area in RAM*/
+
+#define CFG_GBL_DATA_SIZE    0x100        /* num bytes initial data */
+#define CFG_GBL_DATA_OFFSET    (CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
+#define CFG_INIT_SP_OFFSET    CFG_GBL_DATA_OFFSET
+
+/* CFG_MONITOR_LEN must be a multiple of CFG_ENV_SECT_SIZE */
+#define CFG_MONITOR_LEN        (512 * 1024)
+#define CFG_MALLOC_LEN        (512 * 1024)
+
+/*
+ * Local Bus LCRR and LBCR regs
+ *  LCRR:  DLL bypass, Clock divider is 4
+ * External Local Bus rate is
+ *  CLKIN * HRCWL_CSB_TO_CLKIN / HRCWL_LCL_BUS_TO_SCB_CLK / LCRR_CLKDIV
+ */
+#define CFG_LCRR    (LCRR_DBYP | LCRR_CLKDIV_4)
+#define CFG_LBC_LBCR    0x00000000
+
+/* LB sdram refresh timer, about 6us */
+#define CFG_LBC_LSRT    0x32000000
+/* LB refresh timer prescal, 266MHz/32*/
+#define CFG_LBC_MRTPR    0x20000000
+
+/*
+ * Serial Port
+ */
+#define CONFIG_CONS_INDEX    1
+#undef    CONFIG_SERIAL_SOFTWARE_FIFO
+#define CFG_NS16550
+#define CFG_NS16550_SERIAL
+#define CFG_NS16550_REG_SIZE    1
+#define CFG_NS16550_CLK        get_bus_freq(0)
+
+#define CFG_BAUDRATE_TABLE  \
+    {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 115200}
+
+#define CONFIG_CONSOLE        ttyS0
+#define CONFIG_BAUDRATE        115200
+
+#define CFG_NS16550_COM1    (CFG_IMMR + 0x4500)
+#define CFG_NS16550_COM2    (CFG_IMMR + 0x4600)
+
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT        1
+#define CONFIG_OF_BOARD_SETUP        1
+#define CONFIG_OF_STDOUT_VIA_ALIAS    1
+#define MV_DTB_NAME    "mvblm7.dtb"
+
+/*
+ * PCI
+ */
+#define CFG_PCI1_MEM_BASE    0x80000000
+#define CFG_PCI1_MEM_PHYS    CFG_PCI1_MEM_BASE
+#define CFG_PCI1_MEM_SIZE    0x10000000   
+#define CFG_PCI1_MMIO_BASE    (CFG_PCI1_MEM_BASE + CFG_PCI1_MEM_SIZE)
+#define CFG_PCI1_MMIO_PHYS    CFG_PCI1_MMIO_BASE
+#define CFG_PCI1_MMIO_SIZE    0x10000000
+#define CFG_PCI1_IO_BASE    0x00000000
+#define CFG_PCI1_IO_PHYS    0xE2000000
+#define CFG_PCI1_IO_SIZE    0x01000000   
+
+#define _IO_BASE        0x00000000
+
+#define CONFIG_NET_MULTI    1
+#define CONFIG_NET_RETRY_COUNT    3
+#define CONFIG_PCI_PNP   
+
+#define CONFIG_PCI_SCAN_SHOW       
+
+#define PCI_66M
+#define CONFIG_83XX_CLKIN    66666666    /* in Hz */
+
+/* TSEC */
+#define CONFIG_GMII       
+#define CFG_VSC8601_SKEWFIX
+
+#define CONFIG_TSEC1
+#define CONFIG_TSEC2
+
+#define CONFIG_HAS_ETH0
+#define CONFIG_ETHADDR        B6:B4:45:EB:FB:C0
+#define CONFIG_TSEC1_NAME      "TSEC0"
+#define CONFIG_FEC1_PHY_NORXERR
+#define CFG_TSEC1_OFFSET    0x24000
+#define CFG_TSEC1         (CFG_IMMR+CFG_TSEC1_OFFSET)
+#define TSEC1_PHY_ADDR        0x10
+#define TSEC1_PHYIDX        0
+#define TSEC1_FLAGS        (TSEC_GIGABIT|TSEC_REDUCED)
+
+#define CONFIG_HAS_ETH1
+#define CONFIG_ETH1ADDR        B6:B4:45:EB:FB:C2
+#define CONFIG_TSEC2_NAME      "TSEC1"
+#define CONFIG_FEC2_PHY_NORXERR
+#define CFG_TSEC2_OFFSET    0x25000
+#define CFG_TSEC2         (CFG_IMMR+CFG_TSEC2_OFFSET)
+#define TSEC2_PHY_ADDR        0x11
+#define TSEC2_PHYIDX        0
+#define TSEC2_FLAGS        (TSEC_GIGABIT|TSEC_REDUCED)
+
+#define CONFIG_ETHPRIME        "TSEC0"
+
+#define CONFIG_BOOTP_VENDOREX
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_DNS
+#define CONFIG_BOOTP_DNS2
+#define CONFIG_BOOTP_HOSTNAME
+#define CONFIG_BOOTP_BOOTFILESIZE
+#define CONFIG_BOOTP_BOOTPATH
+#define CONFIG_BOOTP_NTPSERVER
+#define CONFIG_BOOTP_RANDOM_DELAY
+#define CONFIG_BOOTP_SEND_HOSTNAME
+
+/*
+ * Environment
+ */
+#undef  CFG_FLASH_PROTECTION
+#define CONFIG_ENV_OVERWRITE
+
+#define CFG_ENV_IS_IN_FLASH    1
+#define CFG_ENV_ADDR        0xFF800000
+#define CFG_ENV_SIZE        0x2000
+#define CFG_ENV_SECT_SIZE    0x2000
+#define CFG_ENV_ADDR_REDUND    (CFG_ENV_ADDR+CFG_ENV_SIZE)
+#define CFG_ENV_SIZE_REDUND     CFG_ENV_SIZE
+
+#define CONFIG_LOADS_ECHO
+#define CFG_LOADS_BAUD_CHANGE
+
+/*
+ * Command line configuration.
+ */
+#include <config_cmd_default.h>
+
+#define CONFIG_CMD_CACHE
+#define CONFIG_CMD_IRQ
+#define CONFIG_CMD_NET
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_SDRAM
+#define CONFIG_CMD_PCI
+#define CONFIG_CMD_I2C
+#define CONFIG_CMD_FPGA
+
+#undef CONFIG_WATCHDOG
+
+/*
+ * Miscellaneous configurable options
+ */
+#define CFG_LONGHELP   
+#define CONFIG_CMDLINE_EDITING
+#define CFG_HUSH_PARSER   
+#define CFG_PROMPT_HUSH_PS2 "> "
+
+#define CFG_LOAD_ADDR    0x2000000    /* default load address */
+#define CONFIG_LOADADDR    200000        /* default location for tftp 
and bootm */
+
+#define CFG_PROMPT    "mvBL-M7> "
+#define CFG_CBSIZE    256
+
+#define CFG_PBSIZE    (CFG_CBSIZE + sizeof(CFG_PROMPT) + 16)
+#define CFG_MAXARGS    16
+#define CFG_BARGSIZE    CFG_CBSIZE
+#define CFG_HZ        1000
+
+/*
+ * For booting Linux, the board info and command line data
+ * have to be in the first 8 MB of memory, since this is
+ * the maximum mapped by the Linux kernel during initialization.
+ */
+#define CFG_BOOTMAPSZ    (8 << 20)    /* Initial Memory map for Linux*/
+
+#define CFG_HRCW_LOW     0x0
+#define CFG_HRCW_HIGH     0x0
+
+/*
+ * System performance
+ */
+#define CFG_ACR_PIPE_DEP    3    /* Arbiter pipeline depth (0-3) */
+#define CFG_ACR_RPTCNT        3    /* Arbiter repeat count (0-7) */
+#define CFG_SPCR_TSEC1EP    3    /* TSEC1 emergency priority (0-3) */
+#define CFG_SPCR_TSEC2EP    3    /* TSEC2 emergency priority (0-3) */
+#define CFG_SCCR_TSEC1CM    1    /* TSEC1 clock mode (0-3) */
+#define CFG_SCCR_TSEC2CM    1    /* TSEC2 & I2C0 clock mode (0-3) */
+
+/*
+ * System IO Config
+ */
+#define CFG_SICRH     SICRH_TSOBI1    /* Needed for gigabit to work on 
TSEC 1 */
+#define CFG_SICRL     (SICRL_LDP_A | SICRL_USB1)
+
+#define CFG_HID0_INIT    0x000000000
+#define CFG_HID0_FINAL    CFG_HID0_INIT
+
+#define CFG_HID2    HID2_HBE
+
+/* DDR  */
+#define CFG_IBAT0L    (CFG_SDRAM_BASE | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CFG_IBAT0U    (CFG_SDRAM_BASE | BATU_BL_256M | BATU_VS | BATU_VP)
+#if CFG_DDR_SIZE==512
+#define CFG_IBAT7L    ((CFG_SDRAM_BASE + (256<<20)) | BATL_PP_10 | 
BATL_MEMCOHERENCE)
+#define CFG_IBAT7U    ((CFG_SDRAM_BASE + (256<<20)) | BATU_BL_256M | 
BATU_VS | BATU_VP)
+#elif CFG_DDR_SIZE==256
+#define CFG_IBAT7L    0
+#define CFG_IBAT7U    0
+#else
+#error only CFG_DDR_SIZE 256/512 supported
+#endif
+
+/* PCI  */
+#define CFG_IBAT1L    (CFG_PCI1_MEM_BASE | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CFG_IBAT1U    (CFG_PCI1_MEM_BASE | BATU_BL_256M | BATU_VS | 
BATU_VP)
+#define CFG_IBAT2L    (CFG_PCI1_MMIO_BASE | BATL_PP_10 | 
BATL_CACHEINHIBIT | BATL_GUARDEDSTORAGE)
+#define CFG_IBAT2U    (CFG_PCI1_MMIO_BASE | BATU_BL_256M | BATU_VS | 
BATU_VP)
+
+/* no PCI2 */
+#define CFG_IBAT3L    0
+#define CFG_IBAT3U    0
+#define CFG_IBAT4L    0
+#define CFG_IBAT4U    0
+
+/* IMMRBAR @ 0xE0000000, PCI IO @ 0xE2000000 & BCSR @ 0xE2400000 */
+#define CFG_IBAT5L    (CFG_IMMR | BATL_PP_10 | BATL_CACHEINHIBIT | 
BATL_GUARDEDSTORAGE)
+#define CFG_IBAT5U    (CFG_IMMR | BATU_BL_256M | BATU_VS | BATU_VP)
+
+/* stack in DCACHE 0xFDF00000 & FLASH @ 0xFF800000 */
+#define CFG_IBAT6L    (0xF0000000 | BATL_PP_10 | BATL_MEMCOHERENCE)
+#define CFG_IBAT6U    (0xF0000000 | BATU_BL_256M | BATU_VS | BATU_VP)
+
+#define CFG_DBAT0L    CFG_IBAT0L
+#define CFG_DBAT0U    CFG_IBAT0U
+#define CFG_DBAT1L    CFG_IBAT1L
+#define CFG_DBAT1U    CFG_IBAT1U
+#define CFG_DBAT2L    CFG_IBAT2L
+#define CFG_DBAT2U    CFG_IBAT2U
+#define CFG_DBAT3L    CFG_IBAT3L
+#define CFG_DBAT3U    CFG_IBAT3U
+#define CFG_DBAT4L    CFG_IBAT4L
+#define CFG_DBAT4U    CFG_IBAT4U
+#define CFG_DBAT5L    CFG_IBAT5L
+#define CFG_DBAT5U    CFG_IBAT5U
+#define CFG_DBAT6L    CFG_IBAT6L
+#define CFG_DBAT6U    CFG_IBAT6U
+#define CFG_DBAT7L    CFG_IBAT7L
+#define CFG_DBAT7U    CFG_IBAT7U
+
+/*
+ * Internal Definitions
+ *
+ * Boot Flags
+ */
+#define BOOTFLAG_COLD    0x01    /* Normal Power-On: Boot from FLASH */
+#define BOOTFLAG_WARM    0x02    /* Software reboot */
+
+
+/*
+ * Environment Configuration
+ */
+#define CONFIG_ENV_OVERWRITE
+
+#define CONFIG_NETDEV        eth0
+
+/* Default path and filenames */
+#define CONFIG_BOOTDELAY        5
+#define CONFIG_AUTOBOOT_KEYED
+#define CONFIG_AUTOBOOT_STOP_STR    "s"
+#define CONFIG_ZERO_BOOTDELAY_CHECK
+#define CONFIG_RESET_TO_RETRY        1000
+
+#define MV_CI            "mvBlueLYNX-M7"
+#define MV_VCI            "mvBlueLYNX-M7"
+#define MV_FPGA_DATA        "0xfff80000"
+#define MV_FPGA_SIZE        "0x76ca2"
+#define MV_KERNEL_ADDR        "0xff810000"
+#define MV_INITRD_ADDR        "0xffc00000"
+#define MV_AUTOSCR_ADDR        "0xff804000"
+#define MV_AUTOSCR_ADDR2    "0xff806000"
+#define MV_DTB_ADDR        "0xff808000"
+#define MV_INITRD_LENGTH    "0x00300000"
+
+#define CONFIG_SHOW_BOOT_PROGRESS 1
+
+#define MV_KERNEL_ADDR_RAM    "0x00100000"
+#define MV_DTB_ADDR_RAM        "0x00600000"
+#define MV_INITRD_ADDR_RAM    "0x01000000"
+
+#define CONFIG_BOOTCOMMAND    "if imi ${autoscr_addr}; then autoscr 
${autoscr_addr}; else autoscr ${autoscr_addr2}; fi;"
+#define CONFIG_BOOTARGS        "root=/dev/ram ro rootfstype=squashfs"
+
+#define CONFIG_EXTRA_ENV_SETTINGS                \
+    "console_nr=0\0"                    \
+    "stdin=serial\0"                    \
+    "stdout=serial\0"                    \
+    "stderr=serial\0"                    \
+    "fpga=0\0"                        \
+    "fpgadata=" MV_FPGA_DATA "\0"                \
+    "fpgadatasize=" MV_FPGA_SIZE "\0"            \
+    "autoscr_addr=" MV_AUTOSCR_ADDR "\0"            \
+    "autoscr_addr2=" MV_AUTOSCR_ADDR2 "\0"            \
+    "mv_kernel_addr=" MV_KERNEL_ADDR "\0"            \
+    "mv_kernel_addr_ram=" MV_KERNEL_ADDR_RAM "\0"        \
+    "mv_initrd_addr=" MV_INITRD_ADDR "\0"            \
+    "mv_initrd_addr_ram=" MV_INITRD_ADDR_RAM "\0"        \
+    "mv_initrd_length=" MV_INITRD_LENGTH "\0"        \
+    "mv_dtb_addr=" MV_DTB_ADDR "\0"                \
+    "mv_dtb_addr_ram=" MV_DTB_ADDR_RAM "\0"            \
+    "dtb_name=" MV_DTB_NAME "\0"                \
+    "mv_version=" MV_VERSION "\0"                \
+    "dhcp_client_id=" MV_CI "\0"                \
+    "dhcp_vendor-class-identifier=" MV_VCI "\0"        \
+    "netretry=no\0"                        \
+    "use_static_ipaddr=no\0"                \
+    "static_ipaddr=192.168.90.10\0"                \
+    "static_netmask=255.255.255.0\0"            \
+    "static_gateway=0.0.0.0\0"                \
+    "initrd_name=uInitrd.mvbc-1G-rfs\0"            \
+    "zcip=no\0"                        \
+    "netboot=no\0"                        \
+    "mvtest=Ff\0"                        \
+    "tried_bootfromflash=no\0"                \
+    "tried_bootfromnet=no\0"                \
+    "bootfile=mvblm72625.boot\0"                \
+    "use_dhcp=no\0"                        \
+    "gev_start=no\0"                    \
+    "mvbcdma_debug=0\0"                    \
+    "mvbcia_debug=0\0"                    \
+    "propdev_debug=0\0"                    \
+    "gevss_debug=0\0"                    \
+    "watchdog=0\0"                        \
+    "skip_fpga=0\0"                        \
+    ""
+#define CONFIG_FPGA_COUNT    1
+#define CONFIG_FPGA        CFG_ALTERA_CYCLON2
+#define CONFIG_FPGA_ALTERA
+#define CONFIG_FPGA_CYCLON2
+
+#endif

MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From gerickson at nuovations.com  Fri Apr 11 22:36:04 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Fri, 11 Apr 2008 13:36:04 -0700
Subject: [U-Boot-Users] [PATCH] Remove $(VERSION_FILE) from PHONY Target List
Message-ID: <C42519C4.E8EE%gerickson@nuovations.com>

When building against non-local, non-disk-backed file systems (e.g. NFS,
tmpfs), the u-boot build can iterate forever, attempting to re-generate
"include/autoconf.mk". This occurs because $(VERSION_FILE) (aka
${ROOT}/u-boot/build/include/version_autogenerated.h) is always regarded as
out-of-date because it is in the .PHONY target list, even though it's a real
file and seems to need to be only created once and only once.

This patch removes $(VERSION_FILE) from the .PHONY target list and has been
verified to work with various flavors and builds of make-3.81 against NFS,
ext2fs, ext3fs and tmpfs file systems.

More detail at:

http://sourceforge.net/mailarchive/message.php?msg_id=C4180895.E556%25gerick
son%40nuovations.com

Signed-off-by: Grant Erickson <gerickson at nuovations.com>

---
diff --git a/Makefile b/Makefile
index e5b4210..50069b7 100644
--- a/Makefile
+++ b/Makefile
@@ -247,7 +247,7
 LIBS += api/libapi.a
 
 LIBS := $(addprefix $(obj),$(LIBS))
-.PHONY : $(LIBS) $(VERSION_FILE)
+.PHONY : $(LIBS)
 
 # Add GCC lib
 PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS)
-print-libgcc-file-name`) -lgcc





From kim.phillips at freescale.com  Fri Apr 11 22:43:05 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Fri, 11 Apr 2008 15:43:05 -0500
Subject: [U-Boot-Users] [PATCH] Remove SEARCH_DIR from linker scripts
In-Reply-To: <f75c52840804110227l604570f3jfdc96473fc583ff@mail.gmail.com>
References: <f75c52840804110227l604570f3jfdc96473fc583ff@mail.gmail.com>
Message-ID: <20080411154305.86e82174.kim.phillips@freescale.com>

On Fri, 11 Apr 2008 10:27:55 +0100
"Richard Danter" <radanter at googlemail.com> wrote:

> Remove all SEARCH_DIR directives from linker scripts.
> 
> Many of the linker scripts included SEARCH_DIR directives making the
> linker search for libraries in the host tree (/lib, /usr/lib and
> /usr/local/lib). This made no sense for a cross-compiled and self
> contained bootloader and causes some toolchains to generate warnings.
> 
> Signed off by: Richard Danter (richard.danter at windriver.com)
> 
> ftp://ftp.windriver.com/TECH_SUPPORT/rdanter/SEARCH_DIR.patch

this patch doesn't apply cleanly on top of WD's git tree.  It also
misses a few new boards.  It seems your tree is not up-to-date.

Kim



From Ken.Fuchs at bench.com  Fri Apr 11 22:50:23 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 11 Apr 2008 15:50:23 -0500
Subject: [U-Boot-Users] System hangs while starting: get clone
	http://git.denx.de/u-boot-at91.git
Message-ID: <AA28F077645B324881335614E4F7C428034CB6@win-ex01.bench.com>

$ git clone http://git.denx.de/u-boot-at91.git
Initialized empty Git repository in
/cygdrive/n/ken/U-Boot/git/u-boot-at91/.git/
Getting alternates list for http://git.denx.de/u-boot-at91.git
Also look at http://git.denx.de/git/u-boot.git/
Getting pack list for http://git.denx.de/u-boot-at91.git
Getting index for pack 81da41f7a1148cfa60fc9aef9f72cd94f5267927
Getting index for pack e08fa2dfbf5cec4a1c3f5999e3dc83e7d3292f13
Getting pack e08fa2dfbf5cec4a1c3f5999e3dc83e7d3292f13
 which contains b5873f1732b92a25690e1513b90dfb0d644f6697
walk b5873f1732b92a25690e1513b90dfb0d644f6697
walk 3ca7c558eba36332556bc470d45e2f5d42bd0ca6
Getting pack list for http://git.denx.de/git/u-boot.git/
error: Unable to find 7c56594381a62abb57f0dcd63c0ccccfc4f5e55e under
http://git.denx.de/u-boot-at91.git
Cannot obtain needed blob 7c56594381a62abb57f0dcd63c0ccccfc4f5e55e
while processing commit 3ca7c558eba36332556bc470d45e2f5d42bd0ca6.
Waiting for
http://git.denx.de/git/u-boot.git//objects/63/8cbc2567ba46bb41c2ed6da0d6
bf0d57af3d87
Waiting for
http://git.denx.de/git/u-boot.git//objects/73/d9625beadea1a39a4073f95da9
be2f944806a8
Received DONE message for unknown request!
Received DONE message for unknown request!
Received DONE message for unknown request!
Received DONE message for unknown request!
<Hang>

$ strace git clone http://git.denx.de/u-boot-at91.git

Here is strace output of one iteration of the infinite loop.

   90 3571246 [main] git-http-fetch 2780 cygwin_select: 6, 0x22C550,
0x22C530, 0x22C510, 0x22C5B0
   42 3571288 [main] git-http-fetch 2780 dtable::select_write:  fd 5
   20 3571308 [main] git-http-fetch 2780 dtable::select_except:  fd 5
   19 3571327 [main] git-http-fetch 2780 cygwin_select: to->tv_sec 0,
to->tv_usec 0, ms 0
   19 3571346 [main] git-http-fetch 2780 cygwin_select: sel.always_ready
0
   21 3571367 [main] git-http-fetch 2780 select_stuff::cleanup: calling
cleanup routines
   19 3571386 [main] git-http-fetch 2780 socket_cleanup: si 0x0
si->thread  0x0
   19 3571405 [main] git-http-fetch 2780 socket_cleanup: returning
   19 3571424 [main] git-http-fetch 2780 peek_socket: considering handle
0x5D4
   20 3571444 [main] git-http-fetch 2780 peek_socket: adding write
fd_set , fd 5
   19 3571463 [main] git-http-fetch 2780 peek_socket: adding except
fd_set , fd 5
   30 3571493 [main] git-http-fetch 2780 peek_socket: WINSOCK_SELECT
returned 0
   20 3571513 [main] git-http-fetch 2780 select_stuff::poll: returning 0
   20 3571533 [main] git-http-fetch 2780 select_stuff::cleanup: calling
cleanup routines
   18 3571551 [main] git-http-fetch 2780 select_stuff::~select_stuff:
deleting select records
   37 3571588 [main] git-http-fetch 2780 cygwin_select: 0, 0x22C748,
0x22C740, 0x22C738, 0x22C730
   22 3571610 [main] git-http-fetch 2780 cygwin_select: to->tv_sec 0,
to->tv_usec 50000, ms 50
   19 3571629 [main] git-http-fetch 2780 cygwin_select: sel.always_ready
0
50415 3622044 [main] git-http-fetch 2780 select_stuff::cleanup: calling
cleanup routines
  566 3622610 [main] git-http-fetch 2780 select_stuff::cleanup: calling
cleanup routines
  531 3623141 [main] git-http-fetch 2780 select_stuff::~select_stuff:
deleting select records

I usually stop it by killing the only current invocation of
git-http-fetch.  It leaves only an empty ./u-boot-91/.git/clone-tmp,
though it
does create other directories in .git temporarily.

This problem has been repeatable for nearly the past 2 hours.

I did a clone of the same git repository without any problems earlier
today, except it wouldn't build properly.

Any suggestions about what is wrong with the clone attempt and what can
be done to fix it?

Thanks,

Ken Fuchs



From Ken.Fuchs at bench.com  Fri Apr 11 23:07:58 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 11 Apr 2008 16:07:58 -0500
Subject: [U-Boot-Users] System hangs while starting: get clone of
	u-boot-at91.git
Message-ID: <AA28F077645B324881335614E4F7C428034CB7@win-ex01.bench.com>

$ git clone http://git.denx.de/u-boot-at91.git
Initialized empty Git repository in
/cygdrive/n/ken/U-Boot/git/u-boot-at91/.git/
Getting alternates list for http://git.denx.de/u-boot-at91.git
Also look at http://git.denx.de/git/u-boot.git/
Getting pack list for http://git.denx.de/u-boot-at91.git
Getting index for pack 81da41f7a1148cfa60fc9aef9f72cd94f5267927
Getting index for pack e08fa2dfbf5cec4a1c3f5999e3dc83e7d3292f13
Getting pack e08fa2dfbf5cec4a1c3f5999e3dc83e7d3292f13
 which contains b5873f1732b92a25690e1513b90dfb0d644f6697
walk b5873f1732b92a25690e1513b90dfb0d644f6697
walk 3ca7c558eba36332556bc470d45e2f5d42bd0ca6
Getting pack list for http://git.denx.de/git/u-boot.git/
error: Unable to find 7c56594381a62abb57f0dcd63c0ccccfc4f5e55e under
http://git.denx.de/u-boot-at91.git
Cannot obtain needed blob 7c56594381a62abb57f0dcd63c0ccccfc4f5e55e
while processing commit 3ca7c558eba36332556bc470d45e2f5d42bd0ca6.
Waiting for
http://git.denx.de/git/u-boot.git//objects/63/8cbc2567ba46bb41c2ed6da0d6
bf0d57af3d87
Waiting for
http://git.denx.de/git/u-boot.git//objects/73/d9625beadea1a39a4073f95da9
be2f944806a8
Received DONE message for unknown request!
Received DONE message for unknown request!
Received DONE message for unknown request!
Received DONE message for unknown request!
<Hang>

More details will follow soon.  I may be having some trouble getting
through the bogo filter, ...

Sincerely,

Ken Fuchs



From kim.phillips at freescale.com  Fri Apr 11 23:10:28 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Fri, 11 Apr 2008 16:10:28 -0500
Subject: [U-Boot-Users] [PATCH 1/2] add MPC8343 based board
 mvBlueLYNX-M7 aka mvblm7
In-Reply-To: <47FFC3DE.8000205@matrix-vision.de>
References: <47FFC3DE.8000205@matrix-vision.de>
Message-ID: <20080411161028.6b27a4d4.kim.phillips@freescale.com>

On Fri, 11 Apr 2008 22:02:38 +0200
Andr? Schwarz <Andre.Schwarz at matrix-vision.de> wrote:

> Kim,
> 
> please review this resubmitted patch with changes as you have requested :
> 
> - coding style issues
> - Makefile
> - Maintainer
> - common mpc83xx PCI code
> - added README.mvblm7
> 
Hello Andr?, thanks, looks generally good, but..

> +    fpga_debug("%s:%d: Initialize FPGA interface (relocation offset = 
> 0x%.8lx)\n",

unfortunately, both messages are linewrapped:

Applying add MPC8343 based board mvBlueLYNX-M7 aka mvblm7
fatal: corrupt patch at line 8
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved".
If you would prefer to skip this patch, instead run "git-am --skip".

Applying add MPC8343 based board mvBlueLYNX-M7 aka mvblm7
.dotest/patch:10: trailing whitespace.
setenv bootdtb bootm \${kernel_boot} \${mv_initrd_addr_ram} 
fatal: corrupt patch at line 11
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved".
If you would prefer to skip this patch, instead run "git-am --skip".

please reference linux-2.6/Documentation/email-clients.txt to help
resolve this.

Kim



From Ken.Fuchs at bench.com  Fri Apr 11 23:20:00 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 11 Apr 2008 16:20:00 -0500
Subject: [U-Boot-Users] System hangs while starting: get clone of
	u-boot-at91.git - part 2 of 2
Message-ID: <AA28F077645B324881335614E4F7C428034CBA@win-ex01.bench.com>

$ strace git clone http://git.denx.de/u-boot-at91.git

Here is strace output of one iteration of the infinite loop.

   90 3571246 [main] git-http-fetch 2780 cygwin_select: 6, 0x22C550,
0x22C530, 0x22C510, 0x22C5B0
   42 3571288 [main] git-http-fetch 2780 dtable::select_write:  fd 5
   20 3571308 [main] git-http-fetch 2780 dtable::select_except:  fd 5
   19 3571327 [main] git-http-fetch 2780 cygwin_select: to->tv_sec 0,
to->tv_usec 0, ms 0
   19 3571346 [main] git-http-fetch 2780 cygwin_select: sel.always_ready
0
   21 3571367 [main] git-http-fetch 2780 select_stuff::cleanup: calling
cleanup routines
   19 3571386 [main] git-http-fetch 2780 socket_cleanup: si 0x0
si->thread  0x0
   19 3571405 [main] git-http-fetch 2780 socket_cleanup: returning
   19 3571424 [main] git-http-fetch 2780 peek_socket: considering handle
0x5D4
   20 3571444 [main] git-http-fetch 2780 peek_socket: adding write
fd_set , fd 5
   19 3571463 [main] git-http-fetch 2780 peek_socket: adding except
fd_set , fd 5
   30 3571493 [main] git-http-fetch 2780 peek_socket: WINSOCK_SELECT
returned 0
   20 3571513 [main] git-http-fetch 2780 select_stuff::poll: returning 0
   20 3571533 [main] git-http-fetch 2780 select_stuff::cleanup: calling
cleanup routines
   18 3571551 [main] git-http-fetch 2780 select_stuff::~select_stuff:
deleting select records
   37 3571588 [main] git-http-fetch 2780 cygwin_select: 0, 0x22C748,
0x22C740, 0x22C738, 0x22C730
   22 3571610 [main] git-http-fetch 2780 cygwin_select: to->tv_sec 0,
to->tv_usec 50000, ms 50
   19 3571629 [main] git-http-fetch 2780 cygwin_select: sel.always_ready
0
50415 3622044 [main] git-http-fetch 2780 select_stuff::cleanup: calling
cleanup routines
  566 3622610 [main] git-http-fetch 2780 select_stuff::cleanup: calling
cleanup routines
  531 3623141 [main] git-http-fetch 2780 select_stuff::~select_stuff:
deleting select records

I usually stop it by killing the only current invocation of
git-http-fetch.  It leaves only an empty ./u-boot-91/.git/clone-tmp,
though it
does create other directories in .git temporarily.

This problem has been repeatable for nearly the past 2 hours.

I did a clone of the same git repository without any problems earlier
today, except it wouldn't build properly.

Any suggestions about what is wrong with the clone attempt and what can
be done to fix it?

Thanks,

Ken Fuchs



From Andre.Schwarz at matrix-vision.de  Fri Apr 11 22:02:38 2008
From: Andre.Schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Fri, 11 Apr 2008 22:02:38 +0200
Subject: [U-Boot-Users] [PATCH 1/2] add MPC8343 based board
 mvBlueLYNX-M7 aka mvblm7
Message-ID: <47FFC3DE.8000205@matrix-vision.de>

Kim,

please review this resubmitted patch with changes as you have requested :

- coding style issues
- Makefile
- Maintainer
- common mpc83xx PCI code
- added README.mvblm7

Please let me know if anything is still invalid or not acceptable.

As mentioned before the merge window is close -> take it into "next" please.

Due to size I have to split the patch.

Thanks,
Andre

Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
--


 CREDITS                        |    5 +
 MAINTAINERS                    |    4 +
 MAKEALL                        |    1 +
 Makefile                       |    4 +-
 board/mvblm7/Makefile          |   48 ++++
 board/mvblm7/config.mk         |   25 ++
 board/mvblm7/fpga.c            |  191 ++++++++++++++++
 board/mvblm7/fpga.h            |   34 +++
 board/mvblm7/mvblm7.c          |  133 +++++++++++
 board/mvblm7/mvblm7.h          |   20 ++
 board/mvblm7/mvblm7_autoscript |   38 ++++
 board/mvblm7/pci.c             |  144 ++++++++++++
 doc/README.mvblm7              |   84 +++++++
 include/configs/MVBLM7.h       |  474 
++++++++++++++++++++++++++++++++++++++++
 14 files changed, 1204 insertions(+), 1 deletions(-)

diff --git a/CREDITS b/CREDITS
index e84ef38..713f58a 100644
--- a/CREDITS
+++ b/CREDITS
@@ -424,6 +424,11 @@ N: Paolo Scaffardi
 E: arsenio at tin.it
 D: FADS823 configuration, MPC823 video support, I2C, wireless keyboard, 
lots more
 
+N: Andre Schwarz
+E: andre.schwarz at matrix-vision.de
+D: Support for BlueLYNX and BlueCOUGAR series
+W: www.matrix-vision.com
+
 N: Robert Schwebel
 E: r.schwebel at pengutronix.de
 D: Support for csb226, logodl and innokom boards (PXA2xx)
diff --git a/MAINTAINERS b/MAINTAINERS
index 33821b8..93281fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -367,6 +367,10 @@ Peter De Schrijver <p2 at mind.be>
 
     ML2            PPC4xx
 
+Andre Schwarz <andre.schwarz at matrix-vision.de>
+
+    mvblm7            MPC8343
+
 Timur Tabi <timur at freescale.com>
 
     MPC8349E-mITX        MPC8349
diff --git a/MAKEALL b/MAKEALL
index 2a872ac..f21c34e 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -327,6 +327,7 @@ LIST_83xx="        \
     MPC8360ERDK_66    \
     MPC837XEMDS    \
     MPC837XERDB    \
+    MVBLM7        \
     sbc8349        \
     TQM834x        \
 "
diff --git a/Makefile b/Makefile
index a7f886b..9d33482 100644
--- a/Makefile
+++ b/Makefile
@@ -2078,13 +2078,15 @@ MPC837XEMDS_HOST_config:    unconfig
 MPC837XERDB_config:    unconfig
     @$(MKCONFIG) -a MPC837XERDB ppc mpc83xx mpc837xerdb freescale
 
+MVBLM7_config: unconfig
+    @$(MKCONFIG) $(@:_config=) ppc mpc83xx mvblm7
+
 sbc8349_config:        unconfig
     @$(MKCONFIG) $(@:_config=) ppc mpc83xx sbc8349
 
 TQM834x_config:    unconfig
     @$(MKCONFIG) $(@:_config=) ppc mpc83xx tqm834x
 
-
 #########################################################################
 ## MPC85xx Systems
 #########################################################################
diff --git a/board/mvblm7/Makefile b/board/mvblm7/Makefile
new file mode 100644
index 0000000..84cd14a
--- /dev/null
+++ b/board/mvblm7/Makefile
@@ -0,0 +1,48 @@
+#
+# Copyright (C) Freescale Semiconductor, Inc. 2006. All rights reserved.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB    = $(obj)lib$(BOARD).a
+
+COBJS    := $(BOARD).o pci.o fpga.o
+
+SRCS    := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS    := $(addprefix $(obj),$(COBJS))
+SOBJS    := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):    $(obj).depend $(OBJS)
+    $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+    rm -f $(SOBJS) $(OBJS)
+
+distclean:    clean
+    rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/mvblm7/config.mk b/board/mvblm7/config.mk
new file mode 100644
index 0000000..1d85f4f
--- /dev/null
+++ b/board/mvblm7/config.mk
@@ -0,0 +1,25 @@
+#
+# Copyright (C) Freescale Semiconductor, Inc. 2006. All rights reserved.
+#
+# 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
+#
+
+sinclude $(OBJTREE)/board/$(BOARDDIR)/config.tmp
+
+TEXT_BASE  = 0xFFF00000
diff --git a/board/mvblm7/fpga.c b/board/mvblm7/fpga.c
new file mode 100644
index 0000000..57ea520
--- /dev/null
+++ b/board/mvblm7/fpga.c
@@ -0,0 +1,191 @@
+/*
+ * (C) Copyright 2002
+ * Rich Ireland, Enterasys Networks, rireland at enterasys.com.
+ * Keith Outwater, keith_outwater at mvis.com.
+ *
+ * (C) Copyright 2008
+ * Andre Schwarz, Matrix Vision GmbH, andre.schwarz at matrix-vision.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+#include <common.h>
+#include <ACEX1K.h>
+#include <command.h>
+#include "fpga.h"
+#include "mvblm7.h"
+
+#ifdef CONFIG_FPGA
+
+#ifdef FPGA_DEBUG
+#define fpga_debug(fmt,args...)      printf(fmt ,##args)
+#else
+#define fpga_debug(fmt,args...)
+#endif
+
+Altera_CYC2_Passive_Serial_fns altera_fns = {
+    fpga_null_fn,
+    fpga_config_fn,
+    fpga_status_fn,
+    fpga_done_fn,
+    fpga_wr_fn,
+    fpga_null_fn,
+    fpga_null_fn,
+    0
+};
+
+Altera_desc cyclone2 = {
+    Altera_CYC2,
+    passive_serial,
+    Altera_EP2C20_SIZE,
+    (void *) &altera_fns,
+    NULL,
+    0
+};
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int mvblm7_init_fpga(void)
+{
+    fpga_debug("%s:%d: Initialize FPGA interface (relocation offset = 
0x%.8lx)\n",
+        __FUNCTION__, __LINE__, gd->reloc_off);
+    fpga_init(gd->reloc_off);
+
+    fpga_debug("%s:%d: Adding fpga 0\n", __FUNCTION__, __LINE__);
+    fpga_add(fpga_altera, &cyclone2);
+
+    return 1;
+}
+
+int fpga_null_fn(int cookie)
+{
+    return 0;
+}
+
+int fpga_config_fn(int assert, int flush, int cookie)
+{
+    volatile immap_t *im = (volatile immap_t *)CFG_IMMR;
+    volatile gpio83xx_t *gpio = (volatile gpio83xx_t *)&im->gpio[0];
+
+    u32 dvo = gpio->dat;
+    fpga_debug("SET config : %s\n", assert ? "low" : "high");
+    if (assert)
+        dvo |= FPGA_CONFIG;
+    else
+        dvo &= ~FPGA_CONFIG;
+   
+    if (flush)
+        gpio->dat = dvo;
+
+    return assert;
+}
+
+int fpga_done_fn(int cookie)
+{
+    volatile immap_t *im = (volatile immap_t *)CFG_IMMR;
+    volatile gpio83xx_t *gpio = (volatile gpio83xx_t *)&im->gpio[0];
+    int result = 0;
+
+    udelay(10);
+    fpga_debug("CONF_DONE check ... ");
+    if (gpio->dat & FPGA_CONF_DONE)  {
+        fpga_debug("high\n");
+        result = 1;
+    } else
+        fpga_debug("low\n");
+
+    return result;
+}
+
+int fpga_status_fn(int cookie)
+{
+    volatile immap_t *im = (volatile immap_t *)CFG_IMMR;
+    volatile gpio83xx_t *gpio = (volatile gpio83xx_t *)&im->gpio[0];
+    int result = 0;
+
+    fpga_debug("STATUS check ... ");
+    if (gpio->dat & FPGA_STATUS)  {
+        fpga_debug("high\n");
+        result = 1;
+    } else
+        fpga_debug("low\n");
+
+    return result;
+}
+
+int fpga_clk_fn(int assert_clk, int flush, int cookie)
+{
+    volatile immap_t *im = (volatile immap_t *)CFG_IMMR;
+    volatile gpio83xx_t *gpio = (volatile gpio83xx_t *)&im->gpio[0];
+
+    u32 dvo = gpio->dat;
+    fpga_debug("CLOCK %s\n", assert_clk ? "high" : "low");
+    if (assert_clk)
+        dvo |= FPGA_CCLK;
+    else
+        dvo &= ~FPGA_CCLK;
+
+    if (flush)
+        gpio->dat = dvo;
+
+    return assert_clk;
+}
+
+static inline int _write_fpga(u8 val, int dump )
+{
+    volatile immap_t *im = (volatile immap_t *)CFG_IMMR;
+    volatile gpio83xx_t *gpio = (volatile gpio83xx_t *)&im->gpio[0];
+    int i;
+    u32 dvo = gpio->dat;
+
+    if (dump)
+        fpga_debug("  %02x -> ", val);
+    for (i = 0; i < 8; i++) {
+        dvo &= ~FPGA_CCLK;
+        gpio->dat = dvo;   
+        dvo &= ~FPGA_DIN;           
+        if (dump)
+            fpga_debug("%d ", val&1);
+        if (val & 1)
+            dvo |= FPGA_DIN;
+        gpio->dat = dvo;   
+        dvo |= FPGA_CCLK;
+        gpio->dat = dvo;   
+        val >>= 1;
+    }
+    if (dump)
+        fpga_debug("\n");
+
+    return 0;
+}
+
+int fpga_wr_fn(void *buf, size_t len, int flush, int cookie)
+{
+    unsigned char *data = (unsigned char *) buf;
+    int i;
+
+    fpga_debug("fpga_wr: buf %p / size %d\n", buf, len);
+    for (i = 0; i < len; i++)
+        _write_fpga(data[i], 0);   
+    fpga_debug("\n");
+
+    return FPGA_SUCCESS;
+}
+#endif
diff --git a/board/mvblm7/fpga.h b/board/mvblm7/fpga.h
new file mode 100644
index 0000000..e84ff06
--- /dev/null
+++ b/board/mvblm7/fpga.h
@@ -0,0 +1,34 @@
+/*
+ * (C) Copyright 2002
+ * Rich Ireland, Enterasys Networks, rireland at enterasys.com.
+ * Keith Outwater, keith_outwater at mvis.com.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+
+extern int mvblm7_init_fpga(void);
+
+extern int fpga_pgm_fn(int assert_pgm, int flush, int cookie);
+extern int fpga_status_fn (int cookie);
+extern int fpga_config_fn (int assert, int flush, int cookie);
+extern int fpga_done_fn(int cookie);
+extern int fpga_clk_fn(int assert_clk, int flush, int cookie);
+extern int fpga_wr_fn (void *buf, size_t len, int flush, int cookie);
+extern int fpga_null_fn (int cookie);
diff --git a/board/mvblm7/mvblm7.c b/board/mvblm7/mvblm7.c
new file mode 100644
index 0000000..9142f14
--- /dev/null
+++ b/board/mvblm7/mvblm7.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (C) Freescale Semiconductor, Inc. 2006. All rights reserved.
+ *
+ * (C) Copyright 2008
+ * Andre Schwarz, Matrix Vision GmbH, andre.schwarz at matrix-vision.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS for A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <ioports.h>
+#include <mpc83xx.h>
+#include <asm/mpc8349_pci.h>
+#include <pci.h>
+#include <asm/mmu.h>
+#if defined(CONFIG_OF_LIBFDT)
+#include <libfdt.h>
+#endif
+
+#include "mvblm7.h"
+
+int fixed_sdram(void)
+{
+    volatile immap_t *im = (immap_t *)CFG_IMMR;
+    u32 msize = 0;
+    u32 ddr_size;
+    u32 ddr_size_log2;
+
+    msize = CFG_DDR_SIZE;
+    for (ddr_size = msize << 20, ddr_size_log2 = 0;
+        (ddr_size > 1);
+        ddr_size = ddr_size>>1, ddr_size_log2++) {
+        if (ddr_size & 1) {
+            return -1;
+        }
+    }
+    im->sysconf.ddrlaw[0].bar = ((CFG_DDR_SDRAM_BASE>>12) & 0xfffff);
+    im->sysconf.ddrlaw[0].ar = LAWAR_EN | ((ddr_size_log2 - 1) & 
LAWAR_SIZE);
+
+    im->ddr.csbnds[0].csbnds = CFG_DDR_CS0_BNDS;
+    im->ddr.cs_config[0] = CFG_DDR_CS0_CONFIG;
+    im->ddr.timing_cfg_0 = CFG_DDR_TIMING_0;
+    im->ddr.timing_cfg_1 = CFG_DDR_TIMING_1;
+    im->ddr.timing_cfg_2 = CFG_DDR_TIMING_2;
+    im->ddr.timing_cfg_3 = CFG_DDR_TIMING_3;
+    im->ddr.sdram_cfg = CFG_DDR_SDRAM_CFG;
+    im->ddr.sdram_cfg2 = CFG_DDR_SDRAM_CFG2;
+    im->ddr.sdram_mode = CFG_DDR_MODE;
+    im->ddr.sdram_interval = CFG_DDR_INTERVAL;
+    im->ddr.sdram_clk_cntl = CFG_DDR_CLK_CNTL;
+
+    udelay(300);
+
+    im->ddr.sdram_cfg |= SDRAM_CFG_MEM_EN;
+
+    return CFG_DDR_SIZE;
+}
+
+long int initdram(int board_type)
+{
+    volatile immap_t *im = (immap_t *) CFG_IMMR;
+    u32 msize = 0;
+
+    if ((im->sysconf.immrbar & IMMRBAR_BASE_ADDR) != (u32) im)
+        return -1;
+
+    im->sysconf.ddrlaw[0].bar = CFG_DDR_BASE & LAWBAR_BAR;
+    msize = fixed_sdram();
+
+    /* return total bus RAM size(bytes) */
+    return msize * 1024 * 1024;
+}
+
+int checkboard(void)
+{
+    puts("Board: Matrix Vision mvBlueLYNX-M7 " MV_VERSION "\n");
+
+    return 0;
+}
+
+u8 *dhcp_vendorex_prep(u8 * e)
+{
+    char *ptr;
+
+    /* DHCP vendor-class-identifier = 60 */
+    if ((ptr = getenv("dhcp_vendor-class-identifier"))) {
+        *e++ = 60;
+        *e++ = strlen(ptr);
+        while (*ptr)
+            *e++ = *ptr++;
+    }
+    /* DHCP_CLIENT_IDENTIFIER = 61 */
+    if ((ptr = getenv("dhcp_client_id"))) {
+        *e++ = 61;
+        *e++ = strlen(ptr);
+        while (*ptr)
+            *e++ = *ptr++;
+    }
+
+    return e;
+}
+
+u8 *dhcp_vendorex_proc(u8 * popt)
+{
+    return NULL;
+}
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+    ft_cpu_setup(blob, bd);
+#ifdef CONFIG_PCI
+    ft_pci_setup(blob, bd);
+#endif
+}
+
+#endif
diff --git a/board/mvblm7/mvblm7.h b/board/mvblm7/mvblm7.h
new file mode 100644
index 0000000..eb1d2a3
--- /dev/null
+++ b/board/mvblm7/mvblm7.h
@@ -0,0 +1,20 @@
+#ifndef __MVBC_H__
+#define __MVBC_H__
+
+#define MV_GPIO
+
+#define FPGA_DIN        0x20000000
+#define FPGA_CCLK       0x40000000
+#define FPGA_CONF_DONE  0x08000000
+#define FPGA_CONFIG     0x80000000
+#define FPGA_STATUS     0x10000000
+
+#define MAN_RST         0x00100000
+#define WD_TS           0x00200000
+#define WD_WDI          0x00400000
+
+#define MV_GPIO_DAT    (WD_TS)
+#define MV_GPIO_OUT    (FPGA_DIN|FPGA_CCLK|WD_TS|WD_WDI)
+#define MV_GPIO_ODE    (FPGA_CONFIG|MAN_RST)
+
+#endif





MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080411/3565c3a6/attachment.htm 

From kim.phillips at freescale.com  Fri Apr 11 23:37:14 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Fri, 11 Apr 2008 16:37:14 -0500
Subject: [U-Boot-Users] System hangs while starting: get clone of
 u-boot-at91.git - part 2 of 2
In-Reply-To: <AA28F077645B324881335614E4F7C428034CBA@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CBA@win-ex01.bench.com>
Message-ID: <20080411163714.cf44e98a.kim.phillips@freescale.com>

On Fri, 11 Apr 2008 16:20:00 -0500
<Ken.Fuchs at bench.com> wrote:

> I did a clone of the same git repository without any problems earlier
> today, except it wouldn't build properly.
> 
> Any suggestions about what is wrong with the clone attempt and what can
> be done to fix it?
> 
I'd have said use the git: protocol, but that doesn't seem to help
either:

Initialized empty Git repository in /home/kim/git/hmm.git/.git/
git.denx.de[0: 0.0.0.1]: errno=Success
fatal: unable to connect a socket (Success)
fetch-pack from 'git://git.denx.de/u-boot.git' failed.

maybe this has something to do with denx.de's new git server.  I'll fwd
this to root.

Kim

p.s. I suspect if you update your git, it'll error out without hanging.



From wd at denx.de  Fri Apr 11 23:40:37 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 11 Apr 2008 23:40:37 +0200
Subject: [U-Boot-Users] System hangs while starting: get clone of
	u-boot-at91.git - part 2 of 2
In-Reply-To: Your message of "Fri, 11 Apr 2008 16:37:14 CDT."
	<20080411163714.cf44e98a.kim.phillips@freescale.com>
Message-ID: <20080411214037.757D6248A0@gemini.denx.de>

In message <20080411163714.cf44e98a.kim.phillips at freescale.com> you wrote:
>
> I'd have said use the git: protocol, but that doesn't seem to help
> either:

It worked fine for me...

> Initialized empty Git repository in /home/kim/git/hmm.git/.git/
> git.denx.de[0: 0.0.0.1]: errno=Success
> fatal: unable to connect a socket (Success)
> fetch-pack from 'git://git.denx.de/u-boot.git' failed.

-> git clone git://git.denx.de/u-boot-at91.git
Initialized empty Git repository in /tmp/u-boot-at91/.git/
remote: Counting objects: 55824, done.
remote: Compressing objects: 100% (11192/11192), done.
remote: Total 55824 (delta 44630), reused 55502 (delta 44308)
Receiving objects: 100% (55824/55824), 20.08 MiB | 651 KiB/s, done.
Resolving deltas: 100% (44630/44630), done.
-> 

> maybe this has something to do with denx.de's new git server.  I'll fwd
> this to root.
...
> p.s. I suspect if you update your git, it'll error out without hanging.

... or simply work, at least with git protocol.

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: wd at denx.de
Our management frequently gets lost in thought.   That's because it's
unfamiliar territory.



From kim.phillips at freescale.com  Fri Apr 11 23:53:59 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Fri, 11 Apr 2008 16:53:59 -0500
Subject: [U-Boot-Users] System hangs while starting: get clone of
 u-boot-at91.git - part 2 of 2
In-Reply-To: <20080411214037.757D6248A0@gemini.denx.de>
References: <20080411163714.cf44e98a.kim.phillips@freescale.com>
	<20080411214037.757D6248A0@gemini.denx.de>
Message-ID: <20080411165359.dd2ce646.kim.phillips@freescale.com>

On Fri, 11 Apr 2008 23:40:37 +0200
Wolfgang Denk <wd at denx.de> wrote:

> ... or simply work, at least with git protocol.

ok, it works when I s/git.denx.de/www.denx.de/, using the git
protocol.  This might have something to do with our firewall though.

Kim



From fabioestevam at yahoo.com  Sat Apr 12 00:06:09 2008
From: fabioestevam at yahoo.com (Fabio Estevam)
Date: Fri, 11 Apr 2008 15:06:09 -0700 (PDT)
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
Message-ID: <894160.91803.qm@web51004.mail.re2.yahoo.com>

Hi,

I am using U-boot 1.3.2 with the MX31ADS patches
posted by Guennadi Liakhovetski.

I would like to load the zImage kernel from Freescale
Linux BSP via TFTP and mount the rootfs via NFS.

Does anyone have an example for doing this? I am not
sure what address should I use to load the kernel into
RAM.

Thanks,

Fabio Estevam



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From Ronda.Yang at freescale.com  Sat Apr 12 00:27:08 2008
From: Ronda.Yang at freescale.com (Yang Ronda)
Date: Fri, 11 Apr 2008 15:27:08 -0700
Subject: [U-Boot-Users] SYNC definition problem
Message-ID: <147FF9C26CABB646A5A97CC5B270727E04246120@az33exm20.fsl.freescale.net>

Hi,
 
I was trying to turn on I-Cache while u-boot is executing out of Flash
on MPC5121 ADS board, and just found the board refused to boot. After
debug and tried many different ways, we finally found that the root of
the problem is the SYNC macro definition in u-boot include/ppc_asm.tmpl
file. The SYNC was defined as
 
#define SYNC \
 sync; \
 isync

By turning on I-cache on powerpc e300 core, ICE bit of HID0 needs to be
set. Before setting ICE, an isync operation need to be issued. In the
cpu/mpc512x/start.S file, this is done by using a 'SYNC' statement. But
we found we need to add one more sync operation to guarantee isync is
complete. 
 
I think it is more safe to change the SYNC definition in ppc_asm.tmpl to
the following,
 
#define SYNC \
 sync; \
 isync; \
 sync

Just a suggestion. 
 
 
Best Regards,
Ronda

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080411/33f56d46/attachment.htm 

From afleming at freescale.com  Sat Apr 12 00:40:31 2008
From: afleming at freescale.com (Andy Fleming)
Date: Fri, 11 Apr 2008 17:40:31 -0500
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
Message-ID: <1207953631-11391-1-git-send-email-afleming@freescale.com>

are available in the git repository at:

  git://www.denx.de/git/u-boot-mpc85xx.git master

Kumar Gala (2):
      85xx: Use SVR_SOC_VER instead of SVR_VER
      85xx: Fix detection of MP cpu spin up

 cpu/mpc85xx/cpu_init.c  |    2 +-
 cpu/mpc85xx/mp.c        |    6 +++++-
 cpu/mpc85xx/spd_sdram.c |    2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)



From kim.phillips at freescale.com  Sat Apr 12 02:04:03 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Fri, 11 Apr 2008 19:04:03 -0500
Subject: [U-Boot-Users] Please pull u-boot-mpc83xx.git - small fixes
Message-ID: <20080411190403.f2634cc0.kim.phillips@freescale.com>

The following changes since commit 950a392464e616b4590bc4501be46e2d7d162dea:
  Wolfgang Denk (1):
        Revert merge of git://www.denx.de/git/u-boot-arm, commit 62479b18:

are available in the git repository at:

  git://www.denx.de/git/u-boot-mpc83xx.git

Dave Liu (2):
      mpc83xx: Fix the SATA clock setting of 837x targets
      mpc83xx: Fix the bug of serdes initialization

Jean-Christophe PLAGNIOL-VILLARD (1):
      mpc837xerdb: Fix warning: implicit declaration of function 'fdt_fixup_dr_usb'

Lee Nipper (1):
      mpc83xx: Update DIMM data bus width test to support 40-bit width

 board/freescale/mpc837xemds/mpc837xemds.c |    2 +-
 board/freescale/mpc837xerdb/mpc837xerdb.c |    2 +-
 cpu/mpc83xx/spd_sdram.c                   |    4 ++--
 include/configs/MPC837XEMDS.h             |    2 +-
 include/configs/MPC837XERDB.h             |    2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

Thanks,

Kim



From plagnioj at jcrosoft.com  Sat Apr 12 07:00:19 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 12 Apr 2008 07:00:19 +0200
Subject: [U-Boot-Users] [PATCH] NE2000: Fix regresssion introduced by
	e710185aae90 on non AX88796
In-Reply-To: <47FF7C44.6040600@comsys.ro>
References: <47FF7C44.6040600@comsys.ro>
Message-ID: <1207976419-6571-1-git-send-email-plagnioj@jcrosoft.com>

Move non-inlied functions into specific drivers file
Set get_prom as weak

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Signed-off-by: Vlad Lungu <vlad at comsys.ro>

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index eafd267..99e068b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -42,7 +42,10 @@ COBJS-y += lan91c96.o
 COBJS-y += macb.o
 COBJS-y += mcffec.o
 COBJS-y += natsemi.o
-COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o
+ifeq ($(CONFIG_DRIVER_NE2000),y)
+COBJS-y += ne2000.o
+COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o
+endif
 COBJS-y += netarm_eth.o
 COBJS-y += netconsole.o
 COBJS-y += ns7520_eth.o
diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
new file mode 100644
index 0000000..7e3e3bb
--- /dev/null
+++ b/drivers/net/ax88796.c
@@ -0,0 +1,155 @@
+/*
+ * (c) 2008 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
+ * (c) 2007 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
+ *
+ * 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 <common.h>
+#include "ax88796.h"
+
+/*
+ * Set 1 bit data
+ */
+static void ax88796_bitset(u32 bit)
+{
+	/* DATA1 */
+	if( bit )
+		EEDI_HIGH;
+	else
+		EEDI_LOW;
+
+	EECLK_LOW;
+	udelay(1000);
+	EECLK_HIGH;
+	udelay(1000);
+	EEDI_LOW;
+}
+
+/*
+ * Get 1 bit data
+ */
+static u8 ax88796_bitget(void)
+{
+	u8 bit;
+
+	EECLK_LOW;
+	udelay(1000);
+	/* DATA */
+	bit = EEDO;
+	EECLK_HIGH;
+	udelay(1000);
+
+	return bit;
+}
+
+/*
+ * Send COMMAND to EEPROM
+ */
+static void ax88796_eep_cmd(u8 cmd)
+{
+	ax88796_bitset(BIT_DUMMY);
+	switch(cmd){
+		case MAC_EEP_READ:
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			break;
+
+		case MAC_EEP_WRITE:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(1);
+			break;
+
+		case MAC_EEP_ERACE:
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			break;
+
+		case MAC_EEP_EWEN:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(0);
+			break;
+
+		case MAC_EEP_EWDS:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(0);
+			break;
+		default:
+			break;
+	}
+}
+
+static void ax88796_eep_setaddr(u16 addr)
+{
+	int i ;
+	for( i = 7 ; i >= 0 ; i-- )
+		ax88796_bitset(addr & (1 << i));
+}
+
+/*
+ * Get data from EEPROM
+ */
+static u16 ax88796_eep_getdata(void)
+{
+	ushort data = 0;
+	int i;
+
+	ax88796_bitget();	/* DUMMY */
+	for( i = 0 ; i < 16 ; i++ ){
+		data <<= 1;
+		data |= ax88796_bitget();
+	}
+	return data;
+}
+
+static void ax88796_mac_read(u8 *buff)
+{
+	int i ;
+	u16 data, addr = 0;
+
+	for( i = 0 ; i < 3; i++ )
+	{
+		EECS_HIGH;
+		EEDI_LOW;
+		udelay(1000);
+		/* READ COMMAND */
+		ax88796_eep_cmd(MAC_EEP_READ);
+		/* ADDRESS */
+		ax88796_eep_setaddr(addr++);
+		/* GET DATA */
+		data = ax88796_eep_getdata();
+		*buff++ = (uchar)(data & 0xff);
+		*buff++ = (uchar)((data >> 8) & 0xff);
+		EECLK_LOW;
+		EEDI_LOW;
+		EECS_LOW;
+	}
+}
+
+int get_prom(u8* mac_addr)
+{
+	u8 prom[32];
+	int i;
+
+	ax88796_mac_read(prom);
+	for (i = 0; i < 6; i++){
+		mac_addr[i] = prom[i];
+	}
+	return 1;
+}
diff --git a/drivers/net/ax88796.h b/drivers/net/ax88796.h
index 069ae80..aa342cb 100644
--- a/drivers/net/ax88796.h
+++ b/drivers/net/ax88796.h
@@ -79,139 +79,5 @@
 #endif
 
 
-/*
- * Set 1 bit data
- */
-static void ax88796_bitset(u32 bit)
-{
-	/* DATA1 */
-	if( bit )
-		EEDI_HIGH;
-	else
-		EEDI_LOW;
-
-	EECLK_LOW;
-	udelay(1000);
-	EECLK_HIGH;
-	udelay(1000);
-	EEDI_LOW;
-}
-
-/*
- * Get 1 bit data
- */
-static u8 ax88796_bitget(void)
-{
-	u8 bit;
-
-	EECLK_LOW;
-	udelay(1000);
-	/* DATA */
-	bit = EEDO;
-	EECLK_HIGH;
-	udelay(1000);
-
-	return bit;
-}
-
-/*
- * Send COMMAND to EEPROM
- */
-static void ax88796_eep_cmd(u8 cmd)
-{
-	ax88796_bitset(BIT_DUMMY);
-	switch(cmd){
-		case MAC_EEP_READ:
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			break;
-
-		case MAC_EEP_WRITE:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(1);
-			break;
-
-		case MAC_EEP_ERACE:
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			break;
-
-		case MAC_EEP_EWEN:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(0);
-			break;
-
-		case MAC_EEP_EWDS:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(0);
-			break;
-		default:
-			break;
-	}
-}
-
-static void ax88796_eep_setaddr(u16 addr)
-{
-	int i ;
-	for( i = 7 ; i >= 0 ; i-- )
-		ax88796_bitset(addr & (1 << i));
-}
-
-/*
- * Get data from EEPROM
- */
-static u16 ax88796_eep_getdata(void)
-{
-	ushort data = 0;
-	int i;
-
-	ax88796_bitget();	/* DUMMY */
-	for( i = 0 ; i < 16 ; i++ ){
-		data <<= 1;
-		data |= ax88796_bitget();
-	}
-	return data;
-}
-
-static void ax88796_mac_read(u8 *buff)
-{
-	int i ;
-	u16 data, addr = 0;
-
-	for( i = 0 ; i < 3; i++ )
-	{
-		EECS_HIGH;
-		EEDI_LOW;
-		udelay(1000);
-		/* READ COMMAND */
-		ax88796_eep_cmd(MAC_EEP_READ);
-		/* ADDRESS */
-		ax88796_eep_setaddr(addr++);
-		/* GET DATA */
-		data = ax88796_eep_getdata();
-		*buff++ = (uchar)(data & 0xff);
-		*buff++ = (uchar)((data >> 8) & 0xff);
-		EECLK_LOW;
-		EEDI_LOW;
-		EECS_LOW;
-	}
-}
-
-int get_prom(u8* mac_addr)
-{
-	u8 prom[32];
-	int i;
-
-	ax88796_mac_read(prom);
-	for (i = 0; i < 6; i++){
-		mac_addr[i] = prom[i];
-	}
-	return 1;
-}
 
 #endif /* __DRIVERS_AX88796L_H__ */
diff --git a/drivers/net/ne2000.c b/drivers/net/ne2000.c
index 99baeea..fc2ae5c 100644
--- a/drivers/net/ne2000.c
+++ b/drivers/net/ne2000.c
@@ -124,6 +124,9 @@ dp83902a_init(void)
 {
 	dp83902a_priv_data_t *dp = &nic;
 	u8* base;
+#if defined(NE2000_BASIC_INIT)
+    int i;
+#endif
 
 	DEBUG_FUNCTION();
 
@@ -729,8 +732,6 @@ static hw_info_t hw_info[] = {
 
 #define NR_INFO		(sizeof(hw_info)/sizeof(hw_info_t))
 
-static hw_info_t default_info = { 0, 0, 0, 0, 0 };
-
 u8 dev_addr[6];
 
 #define PCNET_CMD	0x00
@@ -738,6 +739,93 @@ u8 dev_addr[6];
 #define PCNET_RESET	0x1f	/* Issue a read to reset, a write to clear. */
 #define PCNET_MISC	0x18	/* For IBM CCAE and Socket EA cards */
 
+static void pcnet_reset_8390(void)
+{
+	int i, r;
+
+	PRINTK("nic base is %lx\n", nic_base);
+
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+
+	n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
+
+	for (i = 0; i < 100; i++) {
+		if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
+			break;
+		PRINTK("got %x in reset\n", r);
+		udelay(100);
+	}
+	n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
+
+	if (i == 100)
+		printf("pcnet_reset_8390() did not complete.\n");
+} /* pcnet_reset_8390 */
+
+int get_prom(u8* mac_addr) __attribute__ ((weak, alias ("__get_prom")));
+int __get_prom(u8* mac_addr)
+{
+	u8 prom[32];
+	int i, j;
+	struct {
+		u_char value, offset;
+	} program_seq[] = {
+		{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
+		{0x48,  EN0_DCFG},		/* Set byte-wide (0x48) access. */
+		{0x00,  EN0_RCNTLO},		/* Clear the count regs. */
+		{0x00,  EN0_RCNTHI},
+		{0x00,  EN0_IMR},		/* Mask completion irq. */
+		{0xFF,  EN0_ISR},
+		{E8390_RXOFF, EN0_RXCR},	/* 0x20  Set to monitor */
+		{E8390_TXOFF, EN0_TXCR},	/* 0x02  and loopback mode. */
+		{32,    EN0_RCNTLO},
+		{0x00,  EN0_RCNTHI},
+		{0x00,  EN0_RSARLO},		/* DMA starting at 0x0000. */
+		{0x00,  EN0_RSARHI},
+		{E8390_RREAD+E8390_START, E8390_CMD},
+	};
+
+	PRINTK ("trying to get MAC via prom reading\n");
+
+	pcnet_reset_8390 ();
+
+	mdelay (10);
+
+	for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
+		n2k_outb (program_seq[i].value, program_seq[i].offset);
+
+	PRINTK ("PROM:");
+	for (i = 0; i < 32; i++) {
+		prom[i] = n2k_inb (PCNET_DATAPORT);
+		PRINTK (" %02x", prom[i]);
+	}
+	PRINTK ("\n");
+	for (i = 0; i < NR_INFO; i++) {
+		if ((prom[0] == hw_info[i].a0) &&
+		    (prom[2] == hw_info[i].a1) &&
+		    (prom[4] == hw_info[i].a2)) {
+			PRINTK ("matched board %d\n", i);
+			break;
+		}
+	}
+	if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
+		PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
+		PRINTK ("MAC address is ");
+		for (j = 0; j < 6; j++) {
+			mac_addr[j] = prom[j << 1];
+			PRINTK ("%02x:", mac_addr[i]);
+		}
+		PRINTK ("\n");
+		return (i < NR_INFO) ? i : 0;
+	}
+	return 0;
+}
+
 u32 nic_base;
 
 /* U-boot specific routines */
@@ -764,7 +852,7 @@ void uboot_push_tx_done(int key, int val) {
 }
 
 int eth_init(bd_t *bd) {
-	static hw_info_t * r;
+	int r;
 	char ethaddr[20];
 
 	PRINTK("### eth_init\n");
diff --git a/drivers/net/ne2000.h b/drivers/net/ne2000.h
index d324a00..0b21612 100644
--- a/drivers/net/ne2000.h
+++ b/drivers/net/ne2000.h
@@ -81,6 +81,7 @@ are GPL, so this is, of course, GPL.
 
 #define DP_DATA     0x10
 #define START_PG    0x50    /* First page of TX buffer */
+#define START_PG2   0x48
 #define STOP_PG     0x80    /* Last page +1 of RX ring */
 
 #define RX_START    0x50
@@ -90,90 +91,4 @@ are GPL, so this is, of course, GPL.
 #define DP_OUT(_b_, _o_, _d_) *( (vu_char *) ((_b_)+(_o_))) = (_d_)
 #define DP_IN_DATA(_b_, _d_)  (_d_) = *( (vu_char *) ((_b_)))
 #define DP_OUT_DATA(_b_, _d_) *( (vu_char *) ((_b_))) = (_d_)
-
-static void pcnet_reset_8390(void)
-{
-	int i, r;
-
-	PRINTK("nic base is %lx\n", nic_base);
-
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-
-	n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
-
-	for (i = 0; i < 100; i++) {
-		if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
-			break;
-		PRINTK("got %x in reset\n", r);
-		udelay(100);
-	}
-	n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
-
-	if (i == 100)
-		printf("pcnet_reset_8390() did not complete.\n");
-} /* pcnet_reset_8390 */
-
-int get_prom(u8* mac_addr)
-{
-	u8 prom[32];
-	int i, j;
-	struct {
-		u_char value, offset;
-	} program_seq[] = {
-		{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
-		{0x48,  EN0_DCFG},		/* Set byte-wide (0x48) access. */
-		{0x00,  EN0_RCNTLO},		/* Clear the count regs. */
-		{0x00,  EN0_RCNTHI},
-		{0x00,  EN0_IMR},		/* Mask completion irq. */
-		{0xFF,  EN0_ISR},
-		{E8390_RXOFF, EN0_RXCR},	/* 0x20  Set to monitor */
-		{E8390_TXOFF, EN0_TXCR},	/* 0x02  and loopback mode. */
-		{32,    EN0_RCNTLO},
-		{0x00,  EN0_RCNTHI},
-		{0x00,  EN0_RSARLO},		/* DMA starting at 0x0000. */
-		{0x00,  EN0_RSARHI},
-		{E8390_RREAD+E8390_START, E8390_CMD},
-	};
-
-	PRINTK ("trying to get MAC via prom reading\n");
-
-	pcnet_reset_8390 ();
-
-	mdelay (10);
-
-	for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
-		n2k_outb (program_seq[i].value, program_seq[i].offset);
-
-	PRINTK ("PROM:");
-	for (i = 0; i < 32; i++) {
-		prom[i] = n2k_inb (PCNET_DATAPORT);
-		PRINTK (" %02x", prom[i]);
-	}
-	PRINTK ("\n");
-	for (i = 0; i < NR_INFO; i++) {
-		if ((prom[0] == hw_info[i].a0) &&
-		    (prom[2] == hw_info[i].a1) &&
-		    (prom[4] == hw_info[i].a2)) {
-			PRINTK ("matched board %d\n", i);
-			break;
-		}
-	}
-	if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
-		PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
-		PRINTK ("MAC address is ");
-		for (j = 0; j < 6; j++) {
-			mac_addr[j] = prom[j << 1];
-			PRINTK ("%02x:", mac_addr[i]);
-		}
-		PRINTK ("\n");
-		return (i < NR_INFO) ? i : 0;
-	}
-	return NULL;
-}
 #endif /* __DRIVERS_NE2000_H__ */
diff --git a/drivers/net/ne2000_base.h b/drivers/net/ne2000_base.h
index 1badf62..d8768e8 100644
--- a/drivers/net/ne2000_base.h
+++ b/drivers/net/ne2000_base.h
@@ -120,7 +120,6 @@ typedef struct dp83902a_priv_data {
  ------------------------------------------------------------------------
  Some forward declarations
 */
-int get_prom( u8* mac_addr);
 static void dp83902a_poll(void);
 
 /* ------------------------------------------------------------------------ */
-- 
1.5.4.5




From sr at denx.de  Sat Apr 12 09:02:15 2008
From: sr at denx.de (Stefan Roese)
Date: Sat, 12 Apr 2008 09:02:15 +0200
Subject: [U-Boot-Users] [cfi-flash] Please pull
	git://www.denx.de/git/u-boot-cfi-flash.git
In-Reply-To: <200804111649.37273.sr@denx.de>
References: <20070423123237.295A13535D2@atlas.denx.de>
	<200804091258.06646.sr@denx.de> <200804111649.37273.sr@denx.de>
Message-ID: <200804120902.15311.sr@denx.de>

The following changes since commit 950a392464e616b4590bc4501be46e2d7d162dea:
  Wolfgang Denk (1):
        Revert merge of git://www.denx.de/git/u-boot-arm, commit 62479b18:

are available in the git repository at:

  git://www.denx.de/git/u-boot-cfi-flash.git master

Guennadi Liakhovetski (1):
      cfi_flash: Support buffered writes on non-standard Spansion NOR flash

 README                  |    7 +++++++
 drivers/mtd/cfi_flash.c |   46 ++++++++++++++++------------------------------
 2 files changed, 23 insertions(+), 30 deletions(-)



From Andre.Schwarz at matrix-vision.de  Sat Apr 12 10:01:08 2008
From: Andre.Schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Sat, 12 Apr 2008 10:01:08 +0200
Subject: [U-Boot-Users] [PATCH 1/2] add MPC8343 based board
 mvBlueLYNX-M7 aka mvblm7
In-Reply-To: <20080411161028.6b27a4d4.kim.phillips@freescale.com>
References: <47FFC3DE.8000205@matrix-vision.de>
	<20080411161028.6b27a4d4.kim.phillips@freescale.com>
Message-ID: <48006C44.7010006@matrix-vision.de>

Kim,

thanks a lot for the patience - I'm sorry for the bad shape of my patch 
and will try to improve.

regards,
Andr?

Kim Phillips wrote:
> On Fri, 11 Apr 2008 22:02:38 +0200
> Andr? Schwarz <Andre.Schwarz at matrix-vision.de> wrote:
>
>   
>> Kim,
>>
>> please review this resubmitted patch with changes as you have requested :
>>
>> - coding style issues
>> - Makefile
>> - Maintainer
>> - common mpc83xx PCI code
>> - added README.mvblm7
>>
>>     
> Hello Andr?, thanks, looks generally good, but..
>
>   
>> +    fpga_debug("%s:%d: Initialize FPGA interface (relocation offset = 
>> 0x%.8lx)\n",
>>     
>
> unfortunately, both messages are linewrapped:
>
> Applying add MPC8343 based board mvBlueLYNX-M7 aka mvblm7
> fatal: corrupt patch at line 8
> Patch failed at 0001.
> When you have resolved this problem run "git-am --resolved".
> If you would prefer to skip this patch, instead run "git-am --skip".
>
> Applying add MPC8343 based board mvBlueLYNX-M7 aka mvblm7
> .dotest/patch:10: trailing whitespace.
> setenv bootdtb bootm \${kernel_boot} \${mv_initrd_addr_ram} 
> fatal: corrupt patch at line 11
> Patch failed at 0001.
> When you have resolved this problem run "git-am --resolved".
> If you would prefer to skip this patch, instead run "git-am --skip".
>
> please reference linux-2.6/Documentation/email-clients.txt to help
> resolve this.
>
> Kim
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080412/9c38e043/attachment.htm 

From g.liakhovetski at gmx.de  Sat Apr 12 10:34:40 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Sat, 12 Apr 2008 10:34:40 +0200 (CEST)
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
In-Reply-To: <894160.91803.qm@web51004.mail.re2.yahoo.com>
References: <894160.91803.qm@web51004.mail.re2.yahoo.com>
Message-ID: <Pine.LNX.4.64.0804121030060.4528@axis700.grange>

On Fri, 11 Apr 2008, Fabio Estevam wrote:

> I am using U-boot 1.3.2 with the MX31ADS patches
> posted by Guennadi Liakhovetski.
> 
> I would like to load the zImage kernel from Freescale
> Linux BSP via TFTP and mount the rootfs via NFS.

You nead a uImage. Just use the same kernel sources and do make uImage 
instead of zImage.

> Does anyone have an example for doing this? I am not
> sure what address should I use to load the kernel into
> RAM.

Load it to 0x80800000. You can also try the patch below, which will give 
you a better default environment, it shall be submitted to the list soon.

Thanks
Guennadi
---
Guennadi Liakhovetski

[PATCH] mx31ads: Fix default environment

Fix wrong load address in RAM, undefined environment variables,
make the default environment more usable.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
---
 include/configs/mx31ads.h |   25 ++++++++++++++++++-------
 1 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index 78e2545..3ad3883 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -80,13 +80,24 @@
 #define CONFIG_IPADDR		192.168.23.168
 #define CONFIG_SERVERIP		192.168.23.2
 
-#define	CONFIG_EXTRA_ENV_SETTINGS											\
-	"bootargs_base=setenv bootargs console=ttymxc0,115200\0"							\
-	"bootargs_nfs=setenv bootargs $(bootargs) root=/dev/nfs ip=dhcp nfsroot=$(serverip):$(nfsrootfs),v3,tcp\0"	\
-	"bootcmd=run bootcmd_net\0"											\
-	"bootcmd_net=run bootargs_base bootargs_mtd bootargs_nfs; tftpboot 0x80000000 uImage-mx31; bootm\0"		\
-	"prg_uboot=tftpboot 0x80000000 u-boot-mx31ads.bin; protect off 0xa0000000 0xa001ffff; erase 0xa0000000 0xa001ffff; cp.b 0x80000000 0xa0000000 $(filesize)\0"
-
+#define	CONFIG_EXTRA_ENV_SETTINGS					\
+	"netdev=eth0\0"							\
+	"load_addr=0x80800000\0"					\
+	"uboot_addr=0xa0000000\0"					\
+	"uboot=mx31ads/u-boot.bin\0"					\
+	"kernel=mx31ads/uImage\0"					\
+	"nfsroot=/opt/eldk/arm\0"					\
+	"bootargs_base=setenv bootargs console=ttymxc0,115200\0"	\
+	"bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs "	\
+		"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0"	\
+	"bootcmd=run bootcmd_net\0"					\
+	"bootcmd_net=run bootargs_base bootargs_nfs; "			\
+		"tftpboot ${load_addr} ${kernel}; bootm\0"		\
+	"prg_uboot=tftpboot ${load_addr} ${uboot}; "			\
+		"protect off ${uboot_addr} 0xa003ffff; "		\
+		"erase ${uboot_addr} 0xa003ffff; "			\
+		"cp.b ${load_addr} ${uboot_addr} ${filesize}; "		\
+		"setenv filesize; saveenv\0"
 
 #define CONFIG_DRIVER_CS8900	1
 #define CS8900_BASE		0xb4020300
-- 
1.5.4




From drzeus-mmc at drzeus.cx  Sat Apr 12 11:28:10 2008
From: drzeus-mmc at drzeus.cx (Pierre Ossman)
Date: Sat, 12 Apr 2008 11:28:10 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <AA28F077645B324881335614E4F7C428034CB5@win-ex01.bench.com>
References: <20080411174827.105e31ef@mjolnir.drzeus.cx>
	<AA28F077645B324881335614E4F7C428034CB5@win-ex01.bench.com>
Message-ID: <20080412112810.5b874157@mjolnir.drzeus.cx>

On Fri, 11 Apr 2008 13:54:13 -0500
Ken.Fuchs at bench.com wrote:

> 
> The manual for the AT91SAM926x processors clearly states that the
> MCI controller supports MMC 2.2.  I asked Atmel whether this controller
> could support 4 bits to an MMC 4.x chip and they said _no_.   The answer
> is supposedly from their engineering group in France.
> 

What they answered was if Atmel would support such a solution, not if
the hardware would.

> 
> How does one program the MCI controller to send 4 bit (parallel) data
> an MMC 4.x chip, with or without telling it that it is communicating
> to a 4-bit SD chip?  The only way to get 4 bits of data out of the MCI
> is to tell it that it is connected to a SD (1.0) chip.  If you program
> the MCI to communicate with an MMC chip, it will send data out only on
> the low order bit.

You tell it to use all four bits. That's it. The setting isn't MMC/SD,
it's 1-bit/4-bit.

> Both ends of the communication link must considered.  It may not be
> sufficient that the MMC chip is MMC 4.x; The fact that the MCI
> controller is only MMC 2.2 or SD 1.0 compliant, may or may not impact
> this special handling.

It does not in the slightest. Remember that these controllers are
extremely dumb. The low level behaviour of the protocol hasn't changed
since the very first specs, so only software needs to be changed to
support even the newest features.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org



From tur at semihalf.com  Sat Apr 12 13:14:54 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Sat, 12 Apr 2008 13:14:54 +0200
Subject: [U-Boot-Users] [PATCH 0/2] Calculate image hashes with watchdog
	triggering
Message-ID: <20080412111343.16495.21545.stgit@pollux.denx.de>

Hash calculation of an image can be a time consuming operation, with the
possibility of making the hardware watchdog (if present/enabled) expire in the
middle. Add watchdog-aware hash calculation functions and make image hash
calculation use them.
---

Bartlomiej Sieka (2):
      Use watchdog-aware functions when calculating hashes of images
      Add support for calulacting hashes with watchdog triggering


 common/image.c      |   43 +++++++++----------------------------------
 include/common.h    |    1 +
 include/image.h     |   17 +++++++++++++++--
 include/md5.h       |    8 ++++++++
 include/sha1.h      |   11 +++++++++++
 lib_generic/crc32.c |   28 ++++++++++++++++++++++++++++
 lib_generic/md5.c   |   40 ++++++++++++++++++++++++++++++++++++++++
 lib_generic/sha1.c  |   37 +++++++++++++++++++++++++++++++++++++
 8 files changed, 149 insertions(+), 36 deletions(-)

-- 
Bartlomiej



From tur at semihalf.com  Sat Apr 12 13:15:03 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Sat, 12 Apr 2008 13:15:03 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Add support for calulacting hashes with
	watchdog	triggering
In-Reply-To: <20080412111343.16495.21545.stgit@pollux.denx.de>
References: <20080412111343.16495.21545.stgit@pollux.denx.de>
Message-ID: <20080412111502.16495.46710.stgit@pollux.denx.de>

Implement watchodg-aware variants of hash calculation functions:
- crc32_wd()
- md5_wd()
- sha1_csum_wd()
The above functions calculate the hash of the input buffer in chunks,
triggering the watchdog after processing each chunk. The chunk size is given
as a function call parameter.

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 include/common.h    |    1 +
 include/md5.h       |    8 ++++++++
 include/sha1.h      |   11 +++++++++++
 lib_generic/crc32.c |   27 +++++++++++++++++++++++++++
 lib_generic/md5.c   |   36 ++++++++++++++++++++++++++++++++++++
 lib_generic/sha1.c  |   33 +++++++++++++++++++++++++++++++++
 6 files changed, 116 insertions(+), 0 deletions(-)

diff --git a/include/common.h b/include/common.h
index 39bcd30..aee58ec 100644
--- a/include/common.h
+++ b/include/common.h
@@ -604,6 +604,7 @@ int	vsprintf(char *buf, const char *fmt, va_list args);
 
 /* lib_generic/crc32.c */
 ulong crc32 (ulong, const unsigned char *, uint);
+ulong crc32_wd (ulong, const unsigned char *, uint, uint);
 ulong crc32_no_comp (ulong, const unsigned char *, uint);
 
 /* common/console.c */
diff --git a/include/md5.h b/include/md5.h
index 046d1ee..8b44a7f 100644
--- a/include/md5.h
+++ b/include/md5.h
@@ -20,4 +20,12 @@ struct MD5Context {
  */
 void md5 (unsigned char *input, int len, unsigned char output[16]);
 
+/*
+ * Calculate and store in 'output' the MD5 digest of 'len' bytes at 'input'.
+ * 'output' must have enough space to hold 16 bytes. If 'chunk' Trigger the
+ * watchdog every 'chunk_sz' bytes of input processed.
+ */
+void md5_wd (unsigned char *input, int len, unsigned char output[16],
+		unsigned int chunk_sz);
+
 #endif /* _MD5_H */
diff --git a/include/sha1.h b/include/sha1.h
index 15ea13c..734d1fb 100644
--- a/include/sha1.h
+++ b/include/sha1.h
@@ -80,6 +80,17 @@ void sha1_csum( unsigned char *input, int ilen,
 		unsigned char output[20] );
 
 /**
+ * \brief	   Output = SHA-1( input buffer ), with watchdog triggering
+ *
+ * \param input    buffer holding the  data
+ * \param ilen	   length of the input data
+ * \param output   SHA-1 checksum result
+ * \param chunk_sz watchdog triggering period (in bytes of input processed)
+ */
+void sha1_csum_wd (unsigned char *input, int ilen,
+		unsigned char output[20], unsigned int chunk_sz);
+
+/**
  * \brief	   Output = SHA-1( file contents )
  *
  * \param path	   input file name
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index df0dbca..0bfb64b 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -197,3 +197,30 @@ uLong ZEXPORT crc32_no_comp(uLong crc, const Bytef *buf, uInt len)
 }
 
 #endif
+
+/*
+ * Calculate the crc32 checksum triggering the watchdog every 'chunk_sz' bytes
+ * of input.
+ */
+ulong crc32_wd (ulong crc, const unsigned char *buf, uint len, uint chunk_sz)
+{
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	const unsigned char *end, *curr;
+	int chunk;
+
+	curr = buf;
+	end = buf + len;
+	while (curr < end) {
+		chunk = end - curr;
+		if (chunk > chunk_sz)
+			chunk = chunk_sz;
+		crc = crc32 (crc, curr, chunk);
+		curr += chunk;
+		WATCHDOG_RESET ();
+	}
+#else
+        crc = crc32 (crc, buf, len);
+#endif
+
+	return crc;
+}
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index a51da45..8eaef0f 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -272,3 +272,39 @@ md5 (unsigned char *input, int len, unsigned char output[16])
 	MD5Update(&context, input, len);
 	MD5Final(output, &context);
 }
+
+
+/*
+ * Calculate and store in 'output' the MD5 digest of 'len' bytes at 'input'.
+ * 'output' must have enough space to hold 16 bytes. If 'chunk' Trigger the
+ * watchdog every 'chunk_sz' bytes of input processed.
+ */
+void
+md5_wd (unsigned char *input, int len, unsigned char output[16],
+	unsigned int chunk_sz)
+{
+	struct MD5Context context;
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	unsigned char *end, *curr;
+	int chunk;
+#endif
+
+	MD5Init(&context);
+
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	curr = input;
+	end = input + len;
+	while (curr < end) {
+		chunk = end - curr;
+		if (chunk > chunk_sz)
+			chunk = chunk_sz;
+		MD5Update(&context, curr, chunk);
+		curr += chunk;
+		WATCHDOG_RESET ();
+	}
+#else
+	MD5Update(&context, input, len);
+#endif
+
+	MD5Final(output, &context);
+}
diff --git a/lib_generic/sha1.c b/lib_generic/sha1.c
index 08ffa6b..6950659 100644
--- a/lib_generic/sha1.c
+++ b/lib_generic/sha1.c
@@ -309,6 +309,39 @@ void sha1_csum (unsigned char *input, int ilen, unsigned char output[20])
 }
 
 /*
+ * Output = SHA-1( input buffer ). Trigger the watchdog every 'chunk_sz'
+ * bytes of input processed.
+ */
+void sha1_csum_wd (unsigned char *input, int ilen, unsigned char output[20],
+			unsigned int chunk_sz)
+{
+	sha1_context ctx;
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	unsigned char *end, *curr;
+	int chunk;
+#endif
+
+	sha1_starts (&ctx);
+
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	curr = input;
+	end = input + ilen;
+	while (curr < end) {
+		chunk = end - curr;
+		if (chunk > chunk_sz)
+			chunk = chunk_sz;
+		sha1_update (&ctx, curr, chunk);
+		curr += chunk;
+		WATCHDOG_RESET ();
+	}
+#else
+	sha1_update (&ctx, input, ilen);
+#endif
+
+	sha1_finish (&ctx, output);
+}
+
+/*
  * Output = HMAC-SHA-1( input buffer, hmac key )
  */
 void sha1_hmac (unsigned char *key, int keylen,




From tur at semihalf.com  Sat Apr 12 13:15:20 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Sat, 12 Apr 2008 13:15:20 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Use watchdog-aware functions when
	calculating hashes of	images
In-Reply-To: <20080412111343.16495.21545.stgit@pollux.denx.de>
References: <20080412111343.16495.21545.stgit@pollux.denx.de>
Message-ID: <20080412111520.16495.11791.stgit@pollux.denx.de>

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 common/image.c      |   43 +++++++++----------------------------------
 include/image.h     |   17 +++++++++++++++--
 lib_generic/crc32.c |    1 +
 lib_generic/md5.c   |    4 ++++
 lib_generic/sha1.c  |    4 ++++
 5 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/common/image.c b/common/image.c
index 35356bd..e1b5c73 100644
--- a/common/image.c
+++ b/common/image.c
@@ -156,6 +156,8 @@ static table_entry_t uimage_comp[] = {
 };
 
 unsigned long crc32 (unsigned long, const unsigned char *, unsigned int);
+unsigned long crc32_wd (unsigned long, const unsigned char *,
+			unsigned int, unsigned int);
 static void genimg_print_size (uint32_t size);
 #if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) || defined(USE_HOSTCC)
 static void genimg_print_time (time_t timestamp);
@@ -183,39 +185,11 @@ int image_check_dcrc (image_header_t *hdr)
 {
 	ulong data = image_get_data (hdr);
 	ulong len = image_get_data_size (hdr);
-	ulong dcrc = crc32 (0, (unsigned char *)data, len);
+	ulong dcrc = crc32_wd (0, (unsigned char *)data, len, CHUNKSZ_CRC32);
 
 	return (dcrc == image_get_dcrc (hdr));
 }
 
-#ifndef USE_HOSTCC
-int image_check_dcrc_wd (image_header_t *hdr, ulong chunksz)
-{
-	ulong dcrc = 0;
-	ulong len = image_get_data_size (hdr);
-	ulong data = image_get_data (hdr);
-
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
-	ulong cdata = data;
-	ulong edata = cdata + len;
-
-	while (cdata < edata) {
-		ulong chunk = edata - cdata;
-
-		if (chunk > chunksz)
-			chunk = chunksz;
-		dcrc = crc32 (dcrc, (unsigned char *)cdata, chunk);
-		cdata += chunk;
-
-		WATCHDOG_RESET ();
-	}
-#else
-	dcrc = crc32 (0, (unsigned char *)data, len);
-#endif
-
-	return (dcrc == image_get_dcrc (hdr));
-}
-#endif /* !USE_HOSTCC */
 
 /**
  * image_multi_count - get component (sub-image) count
@@ -408,7 +382,7 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 
 	if (verify) {
 		puts("   Verifying Checksum ... ");
-		if (!image_check_dcrc_wd (rd_hdr, CHUNKSZ)) {
+		if (!image_check_dcrc (rd_hdr)) {
 			puts ("Bad Data CRC\n");
 			show_boot_progress (-12);
 			return NULL;
@@ -1908,15 +1882,16 @@ static int calculate_hash (const void *data, int data_len, const char *algo,
 			uint8_t *value, int *value_len)
 {
 	if (strcmp (algo, "crc32") == 0 ) {
-		*((uint32_t *)value) = crc32 (0, data, data_len);
+		*((uint32_t *)value) = crc32_wd (0, data, data_len,
+							CHUNKSZ_CRC32);
 		*((uint32_t *)value) = cpu_to_uimage (*((uint32_t *)value));
 		*value_len = 4;
 	} else if (strcmp (algo, "sha1") == 0 ) {
-		sha1_csum ((unsigned char *) data, data_len,
-				(unsigned char *) value);
+		sha1_csum_wd ((unsigned char *) data, data_len,
+				(unsigned char *) value, CHUNKSZ_SHA1);
 		*value_len = 20;
 	} else if (strcmp (algo, "md5") == 0 ) {
-		md5 ((unsigned char *)data, data_len, value);
+		md5_wd ((unsigned char *)data, data_len, value, CHUNKSZ_MD5);
 		*value_len = 16;
 	} else {
 		debug ("Unsupported hash alogrithm\n");
diff --git a/include/image.h b/include/image.h
index dbcee1c..3405457 100644
--- a/include/image.h
+++ b/include/image.h
@@ -226,9 +226,23 @@ typedef struct bootm_headers {
 /*
  * Some systems (for example LWMON) have very short watchdog periods;
  * we must make sure to split long operations like memmove() or
- * crc32() into reasonable chunks.
+ * checksum calculations into reasonable chunks.
  */
+#ifndef CHUNKSZ
 #define CHUNKSZ (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_CRC32
+#define CHUNKSZ_CRC32 (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_MD5
+#define CHUNKSZ_MD5 (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_SHA1
+#define CHUNKSZ_SHA1 (64 * 1024)
+#endif
 
 #define uimage_to_cpu(x)		ntohl(x)
 #define cpu_to_uimage(x)		htonl(x)
@@ -362,7 +376,6 @@ static inline void image_set_name (image_header_t *hdr, const char *name)
 int image_check_hcrc (image_header_t *hdr);
 int image_check_dcrc (image_header_t *hdr);
 #ifndef USE_HOSTCC
-int image_check_dcrc_wd (image_header_t *hdr, ulong chunksize);
 int getenv_yesno (char *var);
 ulong getenv_bootm_low(void);
 ulong getenv_bootm_size(void);
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index 0bfb64b..76ac838 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -12,6 +12,7 @@
 #include <common.h>
 #endif
 
+#include <watchdog.h>
 #include "zlib.h"
 
 #define local static
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index 8eaef0f..d1bb661 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -25,6 +25,10 @@
    and to fit the cifs vfs by
    Steve French sfrench at us.ibm.com */
 
+#ifndef USE_HOSTCC
+#include <common.h>
+#endif /* USE_HOSTCC */
+#include <watchdog.h>
 #include <linux/types.h>
 #include <linux/string.h>
 #include <md5.h>
diff --git a/lib_generic/sha1.c b/lib_generic/sha1.c
index 6950659..c8ef4d2 100644
--- a/lib_generic/sha1.c
+++ b/lib_generic/sha1.c
@@ -29,6 +29,10 @@
 #define _CRT_SECURE_NO_DEPRECATE 1
 #endif
 
+#ifndef USE_HOSTCC
+#include <common.h>
+#endif /* USE_HOSTCC */
+#include <watchdog.h>
 #include <linux/string.h>
 #include "sha1.h"
 




From toajmeera at gmail.com  Sat Apr 12 14:12:15 2008
From: toajmeera at gmail.com (venkatram ajmeera)
Date: Sat, 12 Apr 2008 17:42:15 +0530
Subject: [U-Boot-Users] How to add crypto library
Message-ID: <6cd0bb490804120512h5f6b5d2ft494ee842f7c05ac4@mail.gmail.com>

Dear all,
How to add crypto library to  boot loader for arm based hynix processor .

for any clarifiaction about question don't hesitate ask me

With Regards,
A.Venkatram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080412/294ab595/attachment.htm 

From plagnioj at jcrosoft.com  Sat Apr 12 14:08:45 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 12 Apr 2008 14:08:45 +0200
Subject: [U-Boot-Users] [PATCH] gitignore: udpate stgit generated and .patch
	file
Message-ID: <1208002125-20003-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/.gitignore b/.gitignore
index 7c56594..89e96f5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,6 +11,7 @@
 *.a
 *.o
 *~
+*.patch
 
 #
 # Top-level generic files
@@ -37,6 +38,7 @@
 
 # stgit generated dirs
 patches-*
+.stgit-edit.txt
 
 # quilt's files
 patches
-- 
1.5.4.5




From radanter at googlemail.com  Sat Apr 12 14:20:08 2008
From: radanter at googlemail.com (Richard Danter)
Date: Sat, 12 Apr 2008 13:20:08 +0100
Subject: [U-Boot-Users] [PATCH] Remove SEARCH_DIR from linker scripts
In-Reply-To: <20080411154305.86e82174.kim.phillips@freescale.com>
References: <f75c52840804110227l604570f3jfdc96473fc583ff@mail.gmail.com>
	<20080411154305.86e82174.kim.phillips@freescale.com>
Message-ID: <f75c52840804120520u73fecedeu2c669675961fb640@mail.gmail.com>

On 11/04/2008, Kim Phillips <kim.phillips at freescale.com> wrote:
> On Fri, 11 Apr 2008 10:27:55 +0100
>  "Richard Danter" <radanter at googlemail.com> wrote:
>
>  > Remove all SEARCH_DIR directives from linker scripts.
>  >
>  > Many of the linker scripts included SEARCH_DIR directives making the
>  > linker search for libraries in the host tree (/lib, /usr/lib and
>  > /usr/local/lib). This made no sense for a cross-compiled and self
>  > contained bootloader and causes some toolchains to generate warnings.
>  >
>  > Signed off by: Richard Danter (richard.danter at windriver.com)
>  >
>  > ftp://ftp.windriver.com/TECH_SUPPORT/rdanter/SEARCH_DIR.patch
>
>
> this patch doesn't apply cleanly on top of WD's git tree.  It also
>  misses a few new boards.  It seems your tree is not up-to-date.

Yes, I created the patch against the 1.3.2 release. I have now
uploaded another patch made against the git://git.denx.de/u-boot.git
repository. I didn't use git before so please let me know if I didn't
do it correctly.

Rich



From plagnioj at jcrosoft.com  Sat Apr 12 14:25:28 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 12 Apr 2008 14:25:28 +0200
Subject: [U-Boot-Users] [RFC] Create include/u-boot directory
Message-ID: <20080412122528.GA17663@game.jcrosoft.org>

Hi,

	I proposing to create an include directory name u-boot like it's
	done in linux (include/linux) where we put all relate u-boot
	headers except configs and asms dirs.
	It will allow us to be sure to be independent form the host
	system as example

	The include will look like this

#ls -alh include
total 72K
drwxr-xr-x 16 j j 4,0K avr 12 14:17 .
drwxr-xr-x 32 j j 4,0K avr 12 14:08 ..
drwxr-xr-x 20 j j 4,0K avr 12 14:01 asm-arm
drwxr-xr-x  3 j j 4,0K mar 31 12:02 asm-avr32
drwxr-xr-x  8 j j 4,0K avr 12 05:58 asm-blackfin
drwxr-xr-x  3 j j 4,0K mar 31 12:02 asm-i386
drwxr-xr-x  3 j j 4,0K avr 12 05:58 asm-m68k
drwxr-xr-x  3 j j 4,0K mar 31 12:02 asm-microblaze
drwxr-xr-x  2 j j 4,0K avr 12 14:01 asm-mips
drwxr-xr-x  2 j j 4,0K mar 31 12:02 asm-nios
drwxr-xr-x  2 j j 4,0K mar 31 12:02 asm-nios2
drwxr-xr-x  2 j j 4,0K avr 12 06:27 asm-ppc
drwxr-xr-x  2 j j 4,0K avr 12 05:58 asm-sh
drwxr-xr-x  2 j j 8,0K avr 12 05:59 configs
-rw-r--r--  1 j j  110 mar 31 12:02 .gitignore
drwxr-xr-x  4 j j 4,0K avr 12 05:58 linux
drwxr-xr-x  7 j j 4,0K avr 12 14:17 u-boot

Best Regards,
J.



From fabioestevam at yahoo.com  Sat Apr 12 16:24:12 2008
From: fabioestevam at yahoo.com (Fabio Estevam)
Date: Sat, 12 Apr 2008 07:24:12 -0700 (PDT)
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
In-Reply-To: <Pine.LNX.4.64.0804121030060.4528@axis700.grange>
Message-ID: <968107.30460.qm@web51006.mail.re2.yahoo.com>

Hi Guennadi,

I tried to load the kernel at 0x80800000, but this is
what I get:
Hit any key to stop autoboot:  0
=> run bootargs_base bootargs_nfs
=> tftp 80800000 uImage
TFTP from server 10.29.244.101; our IP address is
10.29.244.102
Filename 'uImage'.
Load address: 0x80800000
Loading:
#################################################################
         ###########################
done
Bytes transferred = 1339152 (146f10 hex)
=> bootm
## Booting image at 80800000 ...
   Image Name:   Linux-2.6.22
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1339088 Bytes =  1.3 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing
Linux.............................................................
................................... done, booting the
kernel.
(then it freezes)
  
I generated uImage manually by doing:
./mkimage -A arm -O linux -T kernel -C none -a
0x80008000 -e 0x80008000 -n 'Linux-2.6.22' -d zImage
uImage

Used 0x80008000 to match the value of ZRELADDR in
/arch/arm/mach-mx3/Makefile.boot from Freescale Linux
BSP.

Any suggestions?

Thanks,

Fabio Estevam

--- Guennadi Liakhovetski <g.liakhovetski at gmx.de>
wrote:

> On Fri, 11 Apr 2008, Fabio Estevam wrote:
> 
> > I am using U-boot 1.3.2 with the MX31ADS patches
> > posted by Guennadi Liakhovetski.
> > 
> > I would like to load the zImage kernel from
> Freescale
> > Linux BSP via TFTP and mount the rootfs via NFS.
> 
> You nead a uImage. Just use the same kernel sources
> and do make uImage 
> instead of zImage.
> 
> > Does anyone have an example for doing this? I am
> not
> > sure what address should I use to load the kernel
> into
> > RAM.
> 
> Load it to 0x80800000. You can also try the patch
> below, which will give 
> you a better default environment, it shall be
> submitted to the list soon.
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
> 
> [PATCH] mx31ads: Fix default environment
> 
> Fix wrong load address in RAM, undefined environment
> variables,
> make the default environment more usable.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> ---
>  include/configs/mx31ads.h |   25
> ++++++++++++++++++-------
>  1 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/include/configs/mx31ads.h
> b/include/configs/mx31ads.h
> index 78e2545..3ad3883 100644
> --- a/include/configs/mx31ads.h
> +++ b/include/configs/mx31ads.h
> @@ -80,13 +80,24 @@
>  #define CONFIG_IPADDR		192.168.23.168
>  #define CONFIG_SERVERIP		192.168.23.2
>  
> -#define	CONFIG_EXTRA_ENV_SETTINGS											\
> -	"bootargs_base=setenv bootargs
> console=ttymxc0,115200\0"							\
> -	"bootargs_nfs=setenv bootargs $(bootargs)
> root=/dev/nfs ip=dhcp
> nfsroot=$(serverip):$(nfsrootfs),v3,tcp\0"	\
> -	"bootcmd=run bootcmd_net\0"											\
> -	"bootcmd_net=run bootargs_base bootargs_mtd
> bootargs_nfs; tftpboot 0x80000000 uImage-mx31;
> bootm\0"		\
> -	"prg_uboot=tftpboot 0x80000000 u-boot-mx31ads.bin;
> protect off 0xa0000000 0xa001ffff; erase 0xa0000000
> 0xa001ffff; cp.b 0x80000000 0xa0000000
> $(filesize)\0"
> -
> +#define	CONFIG_EXTRA_ENV_SETTINGS					\
> +	"netdev=eth0\0"							\
> +	"load_addr=0x80800000\0"					\
> +	"uboot_addr=0xa0000000\0"					\
> +	"uboot=mx31ads/u-boot.bin\0"					\
> +	"kernel=mx31ads/uImage\0"					\
> +	"nfsroot=/opt/eldk/arm\0"					\
> +	"bootargs_base=setenv bootargs
> console=ttymxc0,115200\0"	\
> +	"bootargs_nfs=setenv bootargs ${bootargs}
> root=/dev/nfs "	\
> +		"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0"
> \
> +	"bootcmd=run bootcmd_net\0"					\
> +	"bootcmd_net=run bootargs_base bootargs_nfs; "			\
> +		"tftpboot ${load_addr} ${kernel}; bootm\0"		\
> +	"prg_uboot=tftpboot ${load_addr} ${uboot}; "			\
> +		"protect off ${uboot_addr} 0xa003ffff; "		\
> +		"erase ${uboot_addr} 0xa003ffff; "			\
> +		"cp.b ${load_addr} ${uboot_addr} ${filesize}; "	
> \
> +		"setenv filesize; saveenv\0"
>  
>  #define CONFIG_DRIVER_CS8900	1
>  #define CS8900_BASE		0xb4020300
> -- 
> 1.5.4
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From ulf at atmel.com  Sat Apr 12 20:29:44 2008
From: ulf at atmel.com (Ulf Samuelsson)
Date: Sat, 12 Apr 2008 20:29:44 +0200
Subject: [U-Boot-Users] [PATCH] Clean up dataflash partitioning
Message-ID: <1208024984.8004.10.camel@elrond.atmel.sweden>

This patch removes the board dependent parts from
"drivers/mtd/dataflash.c".
Each board relying on this, will have the appropriate
code in a new file, "partition.c" in the board directory.
board Makefiles updated to use the file.

The dataflash partitions are aligned on sector/page boundaries.

The CONFIG_NEW_DF_PARTITION was used to create named partitions
This is now the default operation, and the CONFIG variable is removed.

Signed-off-by: Ulf Samuelsson <ulf at atmel.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: partition.patch
Type: text/x-patch
Size: 10168 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080412/03f41d42/attachment.bin 

From ulf at atmel.com  Sat Apr 12 20:56:03 2008
From: ulf at atmel.com (Ulf Samuelsson)
Date: Sat, 12 Apr 2008 20:56:03 +0200
Subject: [U-Boot-Users] [PATCH] Reorder ARM boards in Makefile
Message-ID: <1208026563.23686.4.camel@elrond.atmel.sweden>

Rearrange ARM boards in Makefile so that ARM926EJ-S boards
are no longer under ARM92xT header.

Signed-off-by: Ulf Samuelsson <ulf at atmel.com>

-- 
Best Regards
Ulf Samuelsson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.Reorder-ARM.patch
Type: text/x-patch
Size: 3541 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080412/380a40c2/attachment.bin 

From ulf at atmel.com  Sat Apr 12 21:03:22 2008
From: ulf at atmel.com (Ulf Samuelsson)
Date: Sat, 12 Apr 2008 21:03:22 +0200
Subject: [U-Boot-Users] [PATCH] Add support for Atmel flash
Message-ID: <1208027002.23686.7.camel@elrond.atmel.sweden>

Add ID codes for most recent Atmel NOR flashes

Signed-off-by: Ulf Samuelsson <ulf at atmel.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atmel-flash.patch
Type: text/x-patch
Size: 1841 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080412/72ec5660/attachment.bin 

From ulf at atmel.com  Sat Apr 12 21:09:41 2008
From: ulf at atmel.com (Ulf Samuelsson)
Date: Sat, 12 Apr 2008 21:09:41 +0200
Subject: [U-Boot-Users] [PATCH] Add build date environment variable
Message-ID: <1208027381.23686.10.camel@elrond.atmel.sweden>

Add environment for the date when U-Boot is built

Signed-off-by: Ulf Samuelsson <ulf at atmel.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: build-date.patch
Type: text/x-patch
Size: 302 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080412/79adef58/attachment.bin 

From vapier at gentoo.org  Sat Apr 12 21:29:15 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 12 Apr 2008 15:29:15 -0400
Subject: [U-Boot-Users] [PATCH] Remove $(VERSION_FILE) from PHONY Target
	List
In-Reply-To: <C42519C4.E8EE%gerickson@nuovations.com>
References: <C42519C4.E8EE%gerickson@nuovations.com>
Message-ID: <200804121529.15954.vapier@gentoo.org>

On Friday 11 April 2008, Grant Erickson wrote:
> When building against non-local, non-disk-backed file systems (e.g. NFS,
> tmpfs), the u-boot build can iterate forever, attempting to re-generate
> "include/autoconf.mk". This occurs because $(VERSION_FILE) (aka
> ${ROOT}/u-boot/build/include/version_autogenerated.h) is always regarded as
> out-of-date because it is in the .PHONY target list, even though it's a
> real file and seems to need to be only created once and only once.
>
> This patch removes $(VERSION_FILE) from the .PHONY target list and has been
> verified to work with various flavors and builds of make-3.81 against NFS,
> ext2fs, ext3fs and tmpfs file systems.

that statement is incorrect.  the version file is supposed to be checked 
everytime you run make as it depends on a whole lot of information which 
cannot be expressed in the makefile.  thus it needs to be a PHONY.

the latest git tree does the right thing: it doesnt actually replace the file 
unless it has changed which means nothing else will get regenerated unless 
the file actually changes.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080412/351356a8/attachment.pgp 

From g.liakhovetski at gmx.de  Sat Apr 12 21:54:06 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Sat, 12 Apr 2008 21:54:06 +0200 (CEST)
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
In-Reply-To: <968107.30460.qm@web51006.mail.re2.yahoo.com>
References: <968107.30460.qm@web51006.mail.re2.yahoo.com>
Message-ID: <Pine.LNX.4.64.0804122151500.7819@axis700.grange>

On Sat, 12 Apr 2008, Fabio Estevam wrote:

> I tried to load the kernel at 0x80800000, but this is
> what I get:
> Hit any key to stop autoboot:  0
> => run bootargs_base bootargs_nfs
> => tftp 80800000 uImage
> TFTP from server 10.29.244.101; our IP address is
> 10.29.244.102
> Filename 'uImage'.
> Load address: 0x80800000
> Loading:
> #################################################################
>          ###########################
> done
> Bytes transferred = 1339152 (146f10 hex)
> => bootm
> ## Booting image at 80800000 ...
>    Image Name:   Linux-2.6.22
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1339088 Bytes =  1.3 MB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing
> Linux.............................................................
> ................................... done, booting the
> kernel.
> (then it freezes)
>   
> I generated uImage manually by doing:
> ./mkimage -A arm -O linux -T kernel -C none -a
> 0x80008000 -e 0x80008000 -n 'Linux-2.6.22' -d zImage
> uImage
> 
> Used 0x80008000 to match the value of ZRELADDR in
> /arch/arm/mach-mx3/Makefile.boot from Freescale Linux
> BSP.

I'll just assume your uImage is correct - although I don't understand why 
you don't just do make uImage. Apart from that, verify that your console= 
command line parameter is correct, your machine ID matches, and that you 
don't have a jtag debugger like bdi2000 connected when you're trying to 
boot.

Thanks
Guennadi
---
Guennadi Liakhovetski



From ulf at atmel.com  Sat Apr 12 22:06:56 2008
From: ulf at atmel.com (Ulf Samuelsson)
Date: Sat, 12 Apr 2008 22:06:56 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
Message-ID: <1208030816.23686.13.camel@elrond.atmel.sweden>

Add support for the AT91RM9200EK Board.

Signed-off-by: Ulf Samuelsson <ulf at atmel.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: at91rm9200ek.patch
Type: text/x-patch
Size: 38749 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080412/bb606ab7/attachment.bin 

From gerickson at nuovations.com  Sun Apr 13 08:20:49 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Sat, 12 Apr 2008 23:20:49 -0700
Subject: [U-Boot-Users] [PATCH] Remove $(VERSION_FILE) from PHONY Target
	List
In-Reply-To: <200804121529.15954.vapier@gentoo.org>
Message-ID: <C426F451.E942%gerickson@nuovations.com>

On 4/12/08 12:29 PM, Mike Frysinger wrote:
> On Friday 11 April 2008, Grant Erickson wrote:
>> When building against non-local, non-disk-backed file systems (e.g. NFS,
>> tmpfs), the u-boot build can iterate forever, attempting to re-generate
>> "include/autoconf.mk". This occurs because $(VERSION_FILE) (aka
>> ${ROOT}/u-boot/build/include/version_autogenerated.h) is always regarded as
>> out-of-date because it is in the .PHONY target list, even though it's a
>> real file and seems to need to be only created once and only once.
>> 
>> This patch removes $(VERSION_FILE) from the .PHONY target list and has been
>> verified to work with various flavors and builds of make-3.81 against NFS,
>> ext2fs, ext3fs and tmpfs file systems.
> 
> that statement is incorrect.  the version file is supposed to be checked
> everytime you run make as it depends on a whole lot of information which
> cannot be expressed in the makefile.  thus it needs to be a PHONY.
> 
> the latest git tree does the right thing: it doesnt actually replace the file
> unless it has changed which means nothing else will get regenerated unless
> the file actually changes.
> -mike

Mike,

Thanks for following up. The hypothesis (i.e. the version file is supposed
to be checked) is well supported by the code; however, the latest git code
as it stands neither seems to support the conclusion--namely $(VERSION_FILE)
should be in the PHONY target list--nor that it depends on a whole lot of
information. The contents of the file are simply:

    % cat include/version_autogenerated.h
    #define U_BOOT_VERSION "U-Boot 1.3.2"

and the only thing $(VERSION_FILE) depends on, implicitly, is the Makefile
itself.

At this point, the discussion is academic since, happily, the patch has been
implicitly accepted by token of already being in git and, presumably, 1.3.3
when it emerges.

Best,

Grant





From vapier at gentoo.org  Sun Apr 13 08:43:48 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 13 Apr 2008 02:43:48 -0400
Subject: [U-Boot-Users] [PATCH] Remove $(VERSION_FILE) from PHONY Target
	List
In-Reply-To: <C426F451.E942%gerickson@nuovations.com>
References: <C426F451.E942%gerickson@nuovations.com>
Message-ID: <200804130243.48681.vapier@gentoo.org>

On Sunday 13 April 2008, Grant Erickson wrote:
> On 4/12/08 12:29 PM, Mike Frysinger wrote:
> > On Friday 11 April 2008, Grant Erickson wrote:
> >> When building against non-local, non-disk-backed file systems (e.g. NFS,
> >> tmpfs), the u-boot build can iterate forever, attempting to re-generate
> >> "include/autoconf.mk". This occurs because $(VERSION_FILE) (aka
> >> ${ROOT}/u-boot/build/include/version_autogenerated.h) is always regarded
> >> as out-of-date because it is in the .PHONY target list, even though it's
> >> a real file and seems to need to be only created once and only once.
> >>
> >> This patch removes $(VERSION_FILE) from the .PHONY target list and has
> >> been verified to work with various flavors and builds of make-3.81
> >> against NFS, ext2fs, ext3fs and tmpfs file systems.
> >
> > that statement is incorrect.  the version file is supposed to be checked
> > everytime you run make as it depends on a whole lot of information which
> > cannot be expressed in the makefile.  thus it needs to be a PHONY.
> >
> > the latest git tree does the right thing: it doesnt actually replace the
> > file unless it has changed which means nothing else will get regenerated
> > unless the file actually changes.
>
> Thanks for following up. The hypothesis (i.e. the version file is supposed
> to be checked) is well supported by the code; however, the latest git code
> as it stands neither seems to support the conclusion--namely
> $(VERSION_FILE) should be in the PHONY target list--nor that it depends on
> a whole lot of information. The contents of the file are simply:
>
>     % cat include/version_autogenerated.h
>     #define U_BOOT_VERSION "U-Boot 1.3.2"
>
> and the only thing $(VERSION_FILE) depends on, implicitly, is the Makefile
> itself.

reading only the output leads to false conclusions such as this.  read the 
actual source code and you'll see that the version string can contain dynamic 
information via shell scripts which cannot be expressed in make syntax.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080413/fdbb21d6/attachment.pgp 

From wg at grandegger.com  Sun Apr 13 09:54:13 2008
From: wg at grandegger.com (Wolfgang Grandegger)
Date: Sun, 13 Apr 2008 09:54:13 +0200
Subject: [U-Boot-Users] PCI express NIC for testing?
Message-ID: <4801BC25.8060303@grandegger.com>

Hello,

I'm looking for a PCIe card, preferably a NIC, to test PCIe under
U-Boot. I have realized, that the E1000 driver of U-Boot does not have
support for PCIe cards. It actually lags behind the Linux driver a lot
and porting seems to require substantial effort (different SPD EEPROM,
PCIe, etc.). Are there other choices?

TIA.

Wolfgang.



From gzydsue at eyou.com  Sun Apr 13 14:11:14 2008
From: gzydsue at eyou.com (=?gb2312?B?Z3pzdQ==?=)
Date: Sun, 13 Apr 2008 20:11:14 +0800
Subject: [U-Boot-Users]
	=?gb2312?B?uePW3dLGtq+w/NTCyM608jrK0MTaNdSqoaLKocTaMTDUqizD4rfRyc/Dxcep?=
Message-ID: <2008041341185.00226@gzydkl.net>

??????????5??????10??????????????????????qq????????????
   
 ??????????,????????????
?????????????????????????? 
???????????????????????????????(??????)????????????5?/??????????????????????????????????????????????????????????????????????????????????????
?????????????????(????,???,?????,??????)??????66-69??3?6??????(???????????13***343965???663965??????????5???????????)???,???????????
?????????????????????????????????????????????????????????
    ?????????????????????????????????????????????????????????????????????????????????????????????????????
    ??????????????????????????????????????
??????????????????10??????????????????????????????????????????????????????????????????????????????????????????
                                        ????
   ??????????????6168????????????6660?????????6911??????????6123...?????????????????????????????????????????????OK?
   ????????????????????????????????????????????????????????????????????????????????????
   ?????http://user.qzone.qq.com/309859605 http://user.qzone.qq.com/309859605/blog/1207495987 
                                         ????
    ???????????
    ?????????? 
??A?????????????: 
??5?????????????? (????????????? ),???????????? ??
   ??: ?????????????????????????????5???????? 
??B?????????????: 
??10?????????( ??????????? )????????????????? 
?????1. ?????????????????????????????10???????? 
??2. ????????IP(17951)???????????????6???
    ?????????????  
    ????????????????????2????? ???????????/??/????30?59??12000?????200?????60?99??24000?????400?????100????36000?????600????
   ?????????? 
???????????? (??19???????????)???????????qq??????????????????
??a)?????????????? 
??b)?????????? 
??c)?????????????? 
??d)??????????? 
??????? ??????????????????????
????????? 
?????13423603965 ???7?24????????????
?????020-85836715  
?????020-28370420 
?????gzkunlin at yahoo.com.cn
??QQ?406215488,309859605 
??MSN?suhuimin_1 at hotmail.com
??????gzkunlin
?????http://gzkunlin.bokee.com?
   ??????????????????????????????????????????????????????????????????????????http://gzkunlin.bokee.com??????????13423603965????????????ip????0.15?/????????????????????????????????http://user.qzone.qq.com/406215488
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080413/6a215bf5/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 7519 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080413/6a215bf5/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1695 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080413/6a215bf5/attachment-0001.gif 

From shenzhenshanhudao at 126.com  Sun Apr 13 15:23:05 2008
From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=)
Date: Sun, 13 Apr 2008 21:23:05 +0800
Subject: [U-Boot-Users] (no subject)
Message-ID: <E1Jl2AW-0007xV-AE@mail.sourceforge.net>




         ?????????
                
             ??????2008?????????????????????????
?
         ?????????????????? ????????????
    
             ?????????????????????????????????
?
         ???????????????????????????......?????

         ???????????????????????????????????

         ????????????????????????
?
                              ???0755-81153047?
?
                              ???0755-81172940?
?
                              ???15817477278?
?
                              ????????
?
             

                 ???
                                                                         

                                                                  ???



From stelian at popies.net  Sun Apr 13 15:35:05 2008
From: stelian at popies.net (Stelian Pop)
Date: Sun, 13 Apr 2008 15:35:05 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
In-Reply-To: <1208030816.23686.13.camel@elrond.atmel.sweden>
References: <1208030816.23686.13.camel@elrond.atmel.sweden>
Message-ID: <1208093705.23686.8.camel@voyager.dsnet>


Le samedi 12 avril 2008 ? 22:06 +0200, Ulf Samuelsson a ?crit :
> Add support for the AT91RM9200EK Board.

Hi Ulf,

I do have a few issues with your patch. As you have seen, I started
adapting the Atmel changes for the AT91SAM boards, and in doing so I
tried to implement (well, quite a lot was borrowed from Linux) a common
infrastructure for the SAM9 and CAP9 CPUs/boards.

I think that the AT91RM9200 could integrate quite well in the existing
framework. I haven't done the job myself yet because I have quite
limited ressources at the moment (and this is why I chose
'arch-at91sam9' instead of 'arch-at91'...) but since you're contributing
a new port it may be the right time to do it.

This means for example:
	- using at91 gpio macros: at91_set_A_periph(), etc.
	- using the standard CFI flash driver instead of the custom one
	- maybe others...

Ah, and it would be much easier to quote and comment on your patches if
they were inlined in your mails.

Thanks,

Stelian.
-- 
Stelian Pop <stelian at popies.net>




From stelian at popies.net  Sun Apr 13 15:36:58 2008
From: stelian at popies.net (Stelian Pop)
Date: Sun, 13 Apr 2008 15:36:58 +0200
Subject: [U-Boot-Users] [PATCH] Add support for Atmel flash
In-Reply-To: <1208027002.23686.7.camel@elrond.atmel.sweden>
References: <1208027002.23686.7.camel@elrond.atmel.sweden>
Message-ID: <1208093818.23686.11.camel@voyager.dsnet>


Le samedi 12 avril 2008 ? 21:03 +0200, Ulf Samuelsson a ?crit :
> Add ID codes for most recent Atmel NOR flashes

Is there any added value on using the atmel flash driver instead of the
standard CFI driver ? It surely doesn't have any on the SAM9/CAP9
boards, but I'm not sure of the older AT91RM9200.

Thanks,
-- 
Stelian Pop <stelian at popies.net>




From wd at denx.de  Sun Apr 13 19:17:33 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:17:33 +0200
Subject: [U-Boot-Users] [PATCH] LM73 bug fix for negative temperatures
	and cleanup
In-Reply-To: Your message of "Thu, 21 Feb 2008 13:58:11 EST."
	<47BDC9C3.90504@acm.org>
Message-ID: <20080413171733.A84B4248AB@gemini.denx.de>

In message <47BDC9C3.90504 at acm.org> you wrote:
> When the LM73 temperature sensor measures a temperature below 0 C, the
> current driver does not perform sign extension, so the result returned is
> 512 C too high.  This patch fixes the problem, and does general cleanup
> of the code.
> 
> Signed-off-by: Larry Johnson <lrj at acm.org>
> ---
>  drivers/hwmon/lm73.c |   60 +++++++++++++++++++++++++-------------------------
>  1 files changed, 30 insertions(+), 30 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: wd at denx.de
Even if you aren't in doubt, consider the mental welfare of the  per-
son who has to maintain the code after you, and who will probably put
parens in the wrong place.          - Larry Wall in the perl man page



From wd at denx.de  Sun Apr 13 19:17:42 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:17:42 +0200
Subject: [U-Boot-Users] Release status - open patches, pull requests etc.
In-Reply-To: Your message of "Fri, 28 Mar 2008 10:35:56 CDT."
	<47ED105C.4060701@acm.org>
Message-ID: <20080413171742.83096248AB@gemini.denx.de>

In message <47ED105C.4060701 at acm.org> you wrote:
> 
> I little while ago I submitted patches for two temperature sensors
> drivers: a bug fix for the LM75 driver, and a bug fix and clean-up for
> the LM73 driver.  The LM75 changes are in the master branch, but the
> last time I checked the LM73 changes were not there.

Thanks for the reminder. Applied now.

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: wd at denx.de
Unix is like a toll road on which you have to stop every 50  feet  to
pay another nickel. But hey! You only feel 5 cents poorer each time.
                 - Larry Wall in <1992Aug13.192357.15731 at netlabs.com>



From wd at denx.de  Sun Apr 13 19:17:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:17:46 +0200
Subject: [U-Boot-Users] Pull request u-boot-microblaze.git
In-Reply-To: Your message of "Tue, 08 Apr 2008 15:47:53 +0200."
	<4968.8389-6630-1188321934-1207662473@seznam.cz>
Message-ID: <20080413171746.AE1F9248AB@gemini.denx.de>

In message <4968.8389-6630-1188321934-1207662473 at seznam.cz> you wrote:
> 
> The following changes since commit aeff6d503b6006573d5c6b04fc658a64bebee5fa:
>   Wolfgang Denk (1):
>         Merge branch 'master' of git://www.denx.de/git/u-boot-fdt
> 
> are available in the git repository at:
> 
>   . master
> 
> Michal Simek (13):
>       microblaze: Clean Makefile from ancient emac driver
>       microblaze: remove old setting for emac driver
>       microblaze: ML401 and XUPV2P remove emac and emaclite reference
>       microblaze: add Emaclite ethernet driver
>       microblaze: add Emac ethernet driver
>       microblaze: Add Emac driver to Makefile
>       microblaze: Add Emaclite driver to Makefile
>       microblaze: clean uart16550 and uartlite handling
>       microblaze: ml401 - add ifdef for GPIO
>       microblaze: ml401 fix config file for supporting FDT
>       microblaze: xupv2p fix config file for supporting FDT
>       microblaze: clean microblaze_config.mk
>       microblaze: Sort microblaze boards in MAKEALL script

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: wd at denx.de
"That unit is a woman."
"A mass of conflicting impulses."
	-- Spock and Nomad, "The Changeling", stardate 3541.9



From wd at denx.de  Sun Apr 13 19:17:44 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:17:44 +0200
Subject: [U-Boot-Users] Pull request: u-boot-sparc
In-Reply-To: Your message of "Tue, 08 Apr 2008 08:43:59 -0000."
	<200804080847.m388lTxD027204@mail176c2.megamailservers.com>
	<47FB304F.7030609@gaisler.com> 
Message-ID: <20080413171744.A13C6248AB@gemini.denx.de>

In message <200804080847.m388lTxD027204 at mail176c2.megamailservers.com> <47FB304F.7030609 at gaisler.com> you wrote:
> 
> Please pull from the master branch at git://www.denx.de/git/u-boot-sparc.git
> 
> I have rebased it agains the mainline this morning.
> 
> Best regards,
> Daniel Hellstrom
> 
> 
> The following changes since commit aeff6d503b6006573d5c6b04fc658a64bebee5fa:
>   Wolfgang Denk (1):
>         Merge branch 'master' of git://www.denx.de/git/u-boot-fdt
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-sparc.git master
> 
> Daniel Hellstrom (11):
>       SPARC: Added generic support for SPARC architecture.
>       SPARC: added SPARC board information to the command bdinfo.
>       SPARC: added SPARC support for new uimage in common code.
>       SPARC: Added support for SPARC LEON3 SOC processor.
>       SPARC/LEON3: Added AMBA Bus Plug&Play information print command 
> (ambapp). It can print available cores (type: AHB Master, AHB Slave, APB 
> Slave), their address ranges, IRQ number and version.
>       SPARC: Added support for SPARC LEON2 SOC Processor.
>       SPARC/LEON3: added support for GR-XC3S-1500 board with GRLIB 
> template design. See www.gaisler.com for board information.
>       SPARC/LEON3: added support for Gaisler GRSIM/TSIM2 SPARC/LEON3 
> simulatorn. See www.gaisler.com for information.
>       SPARC/LEON3: added support for Altera NIOS Development kit 
> (STRATIX II Edition) with GRLIB template design. See www.gaisler.com for 
> information.
>       SPARC/LEON3: added support for GR-CPCI-AX2000 FPGA AX board. The 
> FPGA is exchangeable but a standard LEON3 design is assumed. See 
> www.gaisler.com for information.
>       SPARC/LEON2: added support for Gaisler simulator GRSIM/TSIM for 
> SPARC/LEON2 targets. See www.gaisler.com for information.

Applied, thanks.



From wd at denx.de  Sun Apr 13 19:17:48 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:17:48 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: Your message of "Wed, 09 Apr 2008 12:58:06 +0200."
	<200804091258.06646.sr@denx.de>
Message-ID: <20080413171748.99895248AB@gemini.denx.de>

In message <200804091258.06646.sr at denx.de> you wrote:
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Stefan Roese (2):
>       ppc: Revert patch 70431e8a that used _start instead of CFG_MONITOR_BASE
>       ppc4xx: Fix Canyonlands default environment to work with new image support

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: wd at denx.de
Small is beautiful.



From wd at denx.de  Sun Apr 13 19:17:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:17:50 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: Your message of "Fri, 11 Apr 2008 16:49:37 +0200."
	<200804111649.37273.sr@denx.de>
Message-ID: <20080413171750.D7856248AB@gemini.denx.de>

In message <200804111649.37273.sr at denx.de> you wrote:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Eugene O'Brien (1):
>       ppc4xx: Fix power mgt definitions for PPC440
> 
> Stefan Roese (3):
>       ppc: Revert patch 70431e8a that used _start instead of CFG_MONITOR_BASE
>       ppc4xx: Fix Canyonlands default environment to work with new image support
>       ppc4xx: Update Kilauea defconfig to use device-tree booting as default

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: wd at denx.de
Anarchy may not be the best form of government, but it's better  than
no government at all.



From wd at denx.de  Sun Apr 13 19:18:03 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:18:03 +0200
Subject: [U-Boot-Users] [cfi-flash] Please pull
	git://www.denx.de/git/u-boot-cfi-flash.git
In-Reply-To: Your message of "Sat, 12 Apr 2008 09:02:15 +0200."
	<200804120902.15311.sr@denx.de>
Message-ID: <20080413171803.4E491248AB@gemini.denx.de>

In message <200804120902.15311.sr at denx.de> you wrote:
> 
>   git://www.denx.de/git/u-boot-cfi-flash.git master
> 
> Guennadi Liakhovetski (1):
>       cfi_flash: Support buffered writes on non-standard Spansion NOR flash

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: wd at denx.de
There are no data that cannot be plotted on a straight  line  if  the
axis are chosen correctly.



From wd at denx.de  Sun Apr 13 19:17:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:17:53 +0200
Subject: [U-Boot-Users] Pull request u-boot-microblaze.git
In-Reply-To: Your message of "Fri, 11 Apr 2008 18:24:11 +0200."
	<47FF90AB.9030209@seznam.cz>
Message-ID: <20080413171753.31285248AB@gemini.denx.de>

In message <47FF90AB.9030209 at seznam.cz> you wrote:
> 
> Could you look at it?

Sure. Done. Sorry for the delay.

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: wd at denx.de
Romulan women are not like Vulcan females. We are  not  dedicated  to
pure logic and the sterility of non-emotion.
	-- Romulan Commander, "The Enterprise Incident",
	   stardate 5027.3



From wd at denx.de  Sun Apr 13 19:17:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:17:55 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
In-Reply-To: Your message of "Fri, 11 Apr 2008 17:40:31 CDT."
	<1207953631-11391-1-git-send-email-afleming@freescale.com>
Message-ID: <20080413171755.7A5D1248AB@gemini.denx.de>

In message <1207953631-11391-1-git-send-email-afleming at freescale.com> you wrote:
> 
>   git://www.denx.de/git/u-boot-mpc85xx.git master
> 
> Kumar Gala (2):
>       85xx: Use SVR_SOC_VER instead of SVR_VER
>       85xx: Fix detection of MP cpu spin up

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: wd at denx.de
Never worry about theory as long as  the  machinery  does  what  it's
supposed to do.                                      - R. A. Heinlein



From wd at denx.de  Sun Apr 13 19:18:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 13 Apr 2008 19:18:00 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc83xx.git - small fixes
In-Reply-To: Your message of "Fri, 11 Apr 2008 19:04:03 CDT."
	<20080411190403.f2634cc0.kim.phillips@freescale.com>
Message-ID: <20080413171800.1CA90248AB@gemini.denx.de>

In message <20080411190403.f2634cc0.kim.phillips at freescale.com> you wrote:
> 
>   git://www.denx.de/git/u-boot-mpc83xx.git
> 
> Dave Liu (2):
>       mpc83xx: Fix the SATA clock setting of 837x targets
>       mpc83xx: Fix the bug of serdes initialization
> 
> Jean-Christophe PLAGNIOL-VILLARD (1):
>       mpc837xerdb: Fix warning: implicit declaration of function 'fdt_fixup_dr_usb'
> 
> Lee Nipper (1):
>       mpc83xx: Update DIMM data bus width test to support 40-bit width

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: wd at denx.de
Every time history repeats itself the price goes up.



From Monstr at seznam.cz  Sun Apr 13 19:24:14 2008
From: Monstr at seznam.cz (=?us-ascii?Q?Michal=20Simek?=)
Date: Sun, 13 Apr 2008 19:24:14 +0200 (CEST)
Subject: [U-Boot-Users] Pull request u-boot-microblaze.git
In-Reply-To: <20080413171753.31285248AB@gemini.denx.de>
Message-ID: <5046.8204-18455-1798453396-1208107451@seznam.cz>

>> Could you look at it?
>Sure. Done. Sorry for the delay.

>Best regards,
>Wolfgang Denk

No worries.
Thanks,
Michal Simek
www.monstr.eu



From fabioestevam at yahoo.com  Sun Apr 13 22:59:28 2008
From: fabioestevam at yahoo.com (Fabio Estevam)
Date: Sun, 13 Apr 2008 13:59:28 -0700 (PDT)
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
In-Reply-To: <Pine.LNX.4.64.0804122151500.7819@axis700.grange>
Message-ID: <506076.61710.qm@web51008.mail.re2.yahoo.com>

Hi Guennadi,

Now I generated uImage correctly and it boots fine.

Have you ever tried to boot U-boot from NAND
(K9K1G08U0B) on the i.MX31ADS? 

Thanks,

Fabio Estevam

--- Guennadi Liakhovetski <g.liakhovetski at gmx.de>
wrote:

> On Sat, 12 Apr 2008, Fabio Estevam wrote:
> 
> > I tried to load the kernel at 0x80800000, but this
> is
> > what I get:
> > Hit any key to stop autoboot:  0
> > => run bootargs_base bootargs_nfs
> > => tftp 80800000 uImage
> > TFTP from server 10.29.244.101; our IP address is
> > 10.29.244.102
> > Filename 'uImage'.
> > Load address: 0x80800000
> > Loading:
> >
>
#################################################################
> >          ###########################
> > done
> > Bytes transferred = 1339152 (146f10 hex)
> > => bootm
> > ## Booting image at 80800000 ...
> >    Image Name:   Linux-2.6.22
> >    Image Type:   ARM Linux Kernel Image
> (uncompressed)
> >    Data Size:    1339088 Bytes =  1.3 MB
> >    Load Address: 80008000
> >    Entry Point:  80008000
> >    Verifying Checksum ... OK
> > OK
> > 
> > Starting kernel ...
> > 
> > Uncompressing
> >
>
Linux.............................................................
> > ................................... done, booting
> the
> > kernel.
> > (then it freezes)
> >   
> > I generated uImage manually by doing:
> > ./mkimage -A arm -O linux -T kernel -C none -a
> > 0x80008000 -e 0x80008000 -n 'Linux-2.6.22' -d
> zImage
> > uImage
> > 
> > Used 0x80008000 to match the value of ZRELADDR in
> > /arch/arm/mach-mx3/Makefile.boot from Freescale
> Linux
> > BSP.
> 
> I'll just assume your uImage is correct - although I
> don't understand why 
> you don't just do make uImage. Apart from that,
> verify that your console= 
> command line parameter is correct, your machine ID
> matches, and that you 
> don't have a jtag debugger like bdi2000 connected
> when you're trying to 
> boot.
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008
> JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still
> time to save $100. 
> Use priority code J8TL2D2. 
>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



From lg at denx.de  Sun Apr 13 23:31:01 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Sun, 13 Apr 2008 23:31:01 +0200 (CEST)
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
In-Reply-To: <506076.61710.qm@web51008.mail.re2.yahoo.com>
References: <506076.61710.qm@web51008.mail.re2.yahoo.com>
Message-ID: <Pine.LNX.4.64.0804132329050.6622@axis700.grange>

On Sun, 13 Apr 2008, Fabio Estevam wrote:

> Now I generated uImage correctly and it boots fine.

Good

> Have you ever tried to boot U-boot from NAND
> (K9K1G08U0B) on the i.MX31ADS? 

No, I have not.

Thanks
Guennadi
---
Guennadi Liakhovetski



From wd at denx.de  Mon Apr 14 00:01:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:54 +0200
Subject: [U-Boot-Users] [patch] disable caches before booting an app for
	Blackfin apps
In-Reply-To: Your message of "Tue, 29 Jan 2008 18:21:05 EST."
	<200801291821.05927.vapier@gentoo.org>
Message-ID: <20080413220154.99E67248B9@gemini.denx.de>

In message <200801291821.05927.vapier at gentoo.org> you wrote:
> It isn't generally save to execute applications outside of U-Boot with caches
> enabled due to the way the Blackfin processor handles caches (requires
> software assistance).  This patch disables caches before booting an ELF or
> just booting raw code.  The previous discussion on the patch was that we
> wanted to use weaks instead, but that proved to not be feasible when multiple
> symbols are involved, which puts us back at the ifdef solution.  I've
> minimized the ugliness by moving the setup step outside of the main function.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>

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: wd at denx.de
One does not thank logic.
	-- Sarek, "Journey to Babel", stardate 3842.4



From wd at denx.de  Mon Apr 14 00:01:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:54 +0200
Subject: [U-Boot-Users] [patch] allow ports to override bootelf behavior
In-Reply-To: Your message of "Fri, 01 Feb 2008 10:44:59 EST."
	<200802011045.00200.vapier@gentoo.org>
Message-ID: <20080413220154.A9A97248BB@gemini.denx.de>

In message <200802011045.00200.vapier at gentoo.org> you wrote:
> This splits the dcache logic out of do_bootelf into a dedicated weak function
> called do_bootelf_exec.  This way ports can control the behavior before
> executing an ELF image however they like.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
> diff --git a/common/cmd_elf.c b/common/cmd_elf.c

This doesn't fit current code any moe. Please rebase and resubmit.

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: wd at denx.de
Even if you aren't in doubt, consider the mental welfare of the  per-
son who has to maintain the code after you, and who will probably put
parens in the wrong place.          - Larry Wall in the perl man page



From wd at denx.de  Mon Apr 14 00:01:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:54 +0200
Subject: [U-Boot-Users] [patch] allow ports to override go behavior
In-Reply-To: Your message of "Fri, 01 Feb 2008 10:58:34 EST."
	<200802011058.34891.vapier@gentoo.org>
Message-ID: <20080413220154.BA053247E9@gemini.denx.de>

In message <200802011058.34891.vapier at gentoo.org> you wrote:
> This splits the arch-specific logic out of do_go() and into a dedicated weak
> function called do_go_exec() that lives in cpu directories.  This will need
> review from i386/nios people to make sure i didnt break them.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>

This doesn't fit current code any more. Please rebase and resubmit.

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: wd at denx.de
Even if you aren't in doubt, consider the mental welfare of the  per-
son who has to maintain the code after you, and who will probably put
parens in the wrong place.          - Larry Wall in the perl man page



From wd at denx.de  Mon Apr 14 00:01:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:54 +0200
Subject: [U-Boot-Users] [PATCH] add support for Toradex Colibri module
In-Reply-To: Your message of "Wed, 13 Feb 2008 13:46:53 +0100."
	<1202906813.6976.2.camel@omuntu>
Message-ID: <20080413220154.DA60D247E9@gemini.denx.de>

In message <1202906813.6976.2.camel at omuntu> you wrote:
> 
> Ok, done. New, refurbished patch is attached.

Please don't attach, but include inline. Ideally, use git-send-email
to send the patch.

Signed-off-by line missing. Please rebase and resubmit.

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: wd at denx.de
The night sky over the planet Krikkit is the least interesting  sight
in the entire Universe.
                 - Douglas Adams _Life, the Universe, and Everything_



From wd at denx.de  Mon Apr 14 00:01:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:54 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Don't panic if a controller driver
	does ecc its own way.
In-Reply-To: Your message of "Mon, 24 Mar 2008 12:53:02 CDT."
	<20080324175302.GA1280@ld0162-tx32.am.freescale.net>
Message-ID: <20080413220154.ED2CB248B9@gemini.denx.de>

In message <20080324175302.GA1280 at ld0162-tx32.am.freescale.net> you wrote:
> Some hardware, such as the enhanced local bus controller used on some
> mpc83xx chips, does ecc transparently when reading and writing data, rather
> than providing a generic calculate/correct mechanism that can be exported to
> the nand subsystem.
> 
> The subsystem should not BUG() when calculate, correct, or hwctl are
> missing, if the methods that call them have been overridden.
> 
> Signed-off-by: Scott Wood <scottwood at freescale.com>

This should go through the 83xx custodian, but I haven't seen this
yet?

Anyway, it does not apply any more:

Applying Don't panic if a controller driver does ecc its own way.
error: patch failed: drivers/mtd/nand/nand_base.c:2593
error: drivers/mtd/nand/nand_base.c: patch does not apply
fatal: sha1 information is lacking or useless
(drivers/mtd/nand/nand_base.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.




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: wd at denx.de
When all is said and done, more is said than done.



From wd at denx.de  Mon Apr 14 00:01:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:54 +0200
Subject: [U-Boot-Users] [patch] allow ports to override go behavior
In-Reply-To: Your message of "Fri, 01 Feb 2008 11:36:54 EST."
	<200802011136.55390.vapier@gentoo.org>
Message-ID: <20080413220154.C9DC2248B9@gemini.denx.de>

In message <200802011136.55390.vapier at gentoo.org> you wrote:
> blah, and without fail, i swapped nios/i386
> ---
> This splits the arch-specific logic out of do_go() and into a dedicated weak
> function called do_go_exec() that lives in cpu directories.  This will need
> review from i386/nios people to make sure i didnt break them.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
> diff --git a/common/cmd_boot.c b/common/cmd_boot.c

This doesn't fit current code any more. Please rebase and resubmit.

Please make sure to use only ONE "---" line, and place comments that
are supposed NOT to go into the commit message BELOW that line; you
got this swapped here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A supercomputer is a machine that runs an endless loop in 2 seconds.



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH v2 1/7] Separate omap24xx specific code
	from arm1136
In-Reply-To: Your message of "Wed, 26 Mar 2008 20:40:36 BST."
	<Pine.LNX.4.64.0803261809530.5050@axis700.grange>
Message-ID: <20080413220155.0966C248BB@gemini.denx.de>

In message <Pine.LNX.4.64.0803261809530.5050 at axis700.grange> you wrote:
> From: Sascha Hauer <s.hauer at pengutronix.de>
> 
> Move omap24xx code to cpu/arm1136/omap24xx, rename include/asm-arm/arch-arm=
> 1136
> to cpu/arm1136/omap24xx.
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Pulled in directly.

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: wd at denx.de
A wise person makes his  own  decisions,  a  weak  one  obeys  public
opinion.                                           -- Chinese proverb



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH v2 6/7] Phytec Phycore-i.MX31 support
In-Reply-To: Your message of "Wed, 26 Mar 2008 20:41:17 BST."
	<Pine.LNX.4.64.0803262021540.5050@axis700.grange>
Message-ID: <20080413220155.58567248B9@gemini.denx.de>

In message <Pine.LNX.4.64.0803262021540.5050 at axis700.grange> you wrote:
> From: Sascha Hauer <s.hauer at pengutronix.de>
> 
> This patch adds support for the Phytec Phycore-i.MX31 board
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Pulled in directly, 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: wd at denx.de
Of all possible committee reactions to any  given  agenda  item,  the
reaction  that will occur is the one which will liberate the greatest
amount of hot air.                                -- Thomas L. Martin



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH] Fix warnings introduced by I2C bus speed
	setting patch
In-Reply-To: Your message of "Wed, 26 Mar 2008 18:53:28 CDT."
	<Pine.LNX.4.64.0803261853030.21650@blarg.am.freescale.net>
Message-ID: <20080413220155.98A7A248C6@gemini.denx.de>

In message <Pine.LNX.4.64.0803261853030.21650 at blarg.am.freescale.net> you wrote:
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
>  drivers/i2c/fsl_i2c.c |    7 +++----
>  1 files changed, 3 insertions(+), 4 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: wd at denx.de
It is practically impossible to teach good programming style to  stu-
dents that have had prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration.   - Dijkstra



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH 1/3] doc: english polishing for
	README.sata
In-Reply-To: Your message of "Thu, 27 Mar 2008 18:49:56 +0800."
	<1206614996.3694.13.camel@localhost.localdomain>
Message-ID: <20080413220155.A8B54248C7@gemini.denx.de>

In message <1206614996.3694.13.camel at localhost.localdomain> you wrote:
> according to gvb's suggestion, polishing for the doc.
> 
> Signed-off-by: Jerry Van Baren <gerald.vanbaren at ge.com>
> Signed-off-by: Dave Liu <daveliu at freescale.com>
> ---
>  doc/README.sata |   24 ++++++++++++------------
>  1 files changed, 12 insertions(+), 12 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: wd at denx.de
As the system comes up, the component builders will from time to time
appear, bearing hot new versions of their pieces -- faster,  smaller,
more complete, or putatively less buggy. The replacement of a working
component  by a new version requires the same systematic testing pro-
cedure that adding a new component does, although it  should  require
less time, for more complete and efficient test cases will usually be
available.           - Frederick Brooks Jr., "The Mythical Man Month"



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH v2 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: Your message of "Fri, 28 Mar 2008 10:44:35 BST."
	<20080328094435.GG4719@pengutronix.de>
Message-ID: <20080413220155.37FEA248BF@gemini.denx.de>

In message <20080328094435.GG4719 at pengutronix.de> you wrote:
> On Thu, Mar 27, 2008 at 02:23:44PM -0400, Nick Droogh wrote:
> > Hi Everyone,
> >
> > Would this driver work with the LAN9218 chip as well?
> 
> The chips in this family differ in that some of them have an integrated
> phy and others not. Some have a 16bit bus interface and others have a
> 32bit bus interface.
> So yes, the driver should work with the 9218.

Ben, it seems discussion stopped here without a decision or so. What's
the state of this driver, then?

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: wd at denx.de
If A equals success, then the formula is A = X + Y + Z. X is work.  Y
is play. Z is keep your mouth shut.                 - Albert Einstein



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH v2 5/7] mx31 litekit support
In-Reply-To: Your message of "Wed, 26 Mar 2008 20:41:09 BST."
	<Pine.LNX.4.64.0803262019380.5050@axis700.grange>
Message-ID: <20080413220155.483CF248C1@gemini.denx.de>

In message <Pine.LNX.4.64.0803262019380.5050 at axis700.grange> you wrote:
> From: Sascha Hauer <s.hauer at pengutronix.de>
> 
> This patch adds support for the mx31 litekit board
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Pulled in directly, 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: wd at denx.de
They weren't that important. They were merely at the top. The  people
who  really  run organizations are usually found several levels down,
where it's still possible to get things done.
                                      - Terry Pratchett, _Small Gods_



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH] Altera Stratix II support
In-Reply-To: Your message of "Thu, 27 Mar 2008 00:50:49 BST."
	<1206575449-5159-1-git-send-email-wd@denx.de>
Message-ID: <20080413220155.8868C248C5@gemini.denx.de>

In message <1206575449-5159-1-git-send-email-wd at denx.de> you wrote:
> From: "eran liberty" <eran.liberty at gmail.com>
> 
> Adds Support for Altera's Stratix II.
> 
> Within your board specific init file you will have to call
> 
> 1. fpga_init (/* relocated code offset. usually => */ gd->reloc_off);
> 2. fpga_add (fpga_altera, (Altera_desc*)&altera_desc);
> 
> Altera_desc* contines (for example):
> 	{
> 	 Altera_StratixII,	/* part type */
> 	 passive_serial,	/* interface type */
> 	 1,			/* bytes of data part can accept */
> 	 (void *)(&funcs),	/* interface function table */
> 	 0L,			/* base interface address */
> 	 0			/* implementation specific cookie */
> 	 }
> 
> funcs is the interface. It is of type altera_board_specific_func.
> It looks like this:
> altera_board_specific_func func = {
> 	pre_fn,
> 	config_fn,
> 	status_fn,
> 	done_fn,
> 	clk_fn,
> 	data_fn,
> 	abort_fn,
> 	post_fn,
> };
> 
> you will have to implement these functions, which is usually bit
> banging some gpio.
> 
> Signed-off-by: Eran Liberty <liberty at extricom.com>

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: wd at denx.de
While money can't buy happiness, it certainly lets  you  choose  your
own form of misery.



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH v2 2/7] core support for Freescale mx31
In-Reply-To: Your message of "Wed, 26 Mar 2008 20:40:42 BST."
	<Pine.LNX.4.64.0803261810550.5050@axis700.grange>
Message-ID: <20080413220155.17988248BD@gemini.denx.de>

In message <Pine.LNX.4.64.0803261810550.5050 at axis700.grange> you wrote:
> From: Sascha Hauer <s.hauer at pengutronix.de>
> 
> This patch adds the core support for Freescale mx31
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Pulled in directly, 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: wd at denx.de
"Bureaucracy is the enemy of innovation."
       - Mark Shepherd, former President and CEO of Texas Instruments



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: Your message of "Wed, 26 Mar 2008 20:40:49 BST."
	<Pine.LNX.4.64.0803261812210.5050@axis700.grange>
Message-ID: <20080413220155.279D0247E9@gemini.denx.de>

In message <Pine.LNX.4.64.0803261812210.5050 at axis700.grange> you wrote:
> From: Sascha Hauer <s.hauer at pengutronix.de>
> 
> This patch adds an i2c driver for Freescale i.MX processors
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Pulled in directly, 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: wd at denx.de
"We Americans, we're a simple people... but piss us  off,  and  we'll
bomb your cities."           - Robin Williams, _Good Morning Vietnam_



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH v2 2/2] Freescale eLBC FCM NAND driver
In-Reply-To: Your message of "Wed, 26 Mar 2008 18:49:34 CDT."
	<20080326234934.GA13717@ld0162-tx32.am.freescale.net>
Message-ID: <20080413220155.7853F248BB@gemini.denx.de>

Stefan,

in message <20080326234934.GA13717 at ld0162-tx32.am.freescale.net> you wrote:
> This is a driver for the Flash Control Machine of the enhanched Local Bus
> Controller found on some Freescale chips (such as the mpc8313 and the
> mpc8379).
> 
> Signed-off-by: Scott Wood <scottwood at freescale.com>
> ---
> Fixed one instance of trailing whitespace, moved the conditional to the
> makefile, and increased the hardware timeout to the maximum after
> receiving a report that some boards need higher that the old setting.
> 
>  drivers/mtd/nand/Makefile        |    1 +
>  drivers/mtd/nand/fsl_elbc_nand.c |  759 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 760 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/mtd/nand/fsl_elbc_nand.c

I think you should pull this into the u-boot-nand-flash repo, or are
there any objections against this patch?

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: wd at denx.de
Men will always be men -- no matter where they are.
	-- Harry Mudd, "Mudd's Women", stardate 1329.8



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH v2 7/7] Support for the MX31ADS
	evaluation board from Freescale
In-Reply-To: Your message of "Wed, 26 Mar 2008 20:41:24 BST."
	<Pine.LNX.4.64.0803262023180.5050@axis700.grange>
Message-ID: <20080413220155.68321248C3@gemini.denx.de>

In message <Pine.LNX.4.64.0803262023180.5050 at axis700.grange> you wrote:
> This patch adds support for the MX31ADS evaluation board from Freescale, 
> initialization code is copied from RedBoot sources, also provided by 
> Freescale.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Cannot apply this one:

Applying Support for the MX31ADS evaluation board from Freescale
error: patch failed: include/asm-arm/arch-mx31/mx31-regs.h:133
error: include/asm-arm/arch-mx31/mx31-regs.h: patch does not apply
fatal: mode change for board/imx31_litekit/config.mk, which is not in
current HEAD
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.

Please fix and resubmit.

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: wd at denx.de
So we follow our wandering paths, and the very darkness acts  as  our
guide and our doubts serve to reassure us. - Jean-Pierre de Caussade,
eighteenth-century Jesuit priest



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH 3/3] drivers: code clean up
In-Reply-To: Your message of "Thu, 27 Mar 2008 18:51:17 +0800."
	<1206615077.3694.17.camel@localhost.localdomain>
Message-ID: <20080413220155.C8254248BD@gemini.denx.de>

In message <1206615077.3694.17.camel at localhost.localdomain> you wrote:
> Signed-off-by: Dave Liu <daveliu at freescale.com>
> ---
>  drivers/block/libata.c |   36 ++++++++++++++++++------------------
>  include/sata.h         |    5 +++++
>  2 files changed, 23 insertions(+), 18 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: wd at denx.de
It would be illogical to assume that all conditions remain stable
	-- Spock, "The Enterprise" Incident", stardate 5027.3



From wd at denx.de  Mon Apr 14 00:01:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 00:01:55 +0200
Subject: [U-Boot-Users] [PATCH 2/3] drivers: clean up the ata_piix.h
In-Reply-To: Your message of "Thu, 27 Mar 2008 18:50:41 +0800."
	<1206615042.3694.15.camel@localhost.localdomain>
Message-ID: <20080413220155.B8328248C8@gemini.denx.de>

In message <1206615042.3694.15.camel at localhost.localdomain> you wrote:
> Signed-off-by: Dave Liu <daveliu at freescale.com>
> ---
>  drivers/block/ata_piix.h |   26 +++++++++++++++-----------
>  1 files changed, 15 insertions(+), 11 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The only person who always got his work done by Friday
                                                 was Robinson Crusoe.



From vapier at gentoo.org  Mon Apr 14 01:26:40 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 13 Apr 2008 19:26:40 -0400
Subject: [U-Boot-Users] u-boot wiki and arch-specific details
Message-ID: <200804131926.41049.vapier@gentoo.org>

we maintain a Blackfin-specific u-boot wiki that goes into quite a bit of 
detail, some of which is duplicated with the main u-boot wiki.  how do people 
feel about extending the u-boot wiki to allow for arch-specific details ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080413/27d9b288/attachment.pgp 

From vapier at gentoo.org  Mon Apr 14 01:42:19 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 13 Apr 2008 19:42:19 -0400
Subject: [U-Boot-Users] [PATCH] allow ports to override go behavior
In-Reply-To: <1208130139-18440-1-git-send-email-vapier@gentoo.org>
References: <1208130139-18440-1-git-send-email-vapier@gentoo.org>
Message-ID: <1208130139-18440-2-git-send-email-vapier@gentoo.org>

Split the arch-specific logic out of the common go code and into a dedicated
weak function called do_go_exec() that lives in cpu directories.  This will
need review from i386/nios people to make sure I didn't break them.
---
 common/cmd_boot.c |   33 +++++----------------------------
 lib_i386/board.c  |    8 ++++++++
 lib_nios/board.c  |   10 ++++++++++
 3 files changed, 23 insertions(+), 28 deletions(-)

diff --git a/common/cmd_boot.c b/common/cmd_boot.c
index 9d4f026..d83f5af 100644
--- a/common/cmd_boot.c
+++ b/common/cmd_boot.c
@@ -28,25 +28,11 @@
 #include <command.h>
 #include <net.h>
 
-#if defined(CONFIG_I386)
-DECLARE_GLOBAL_DATA_PTR;
-#endif
-
-static inline void go_setup(int argc, char *argv[])
+/* Allow ports to override the default behavior */
+__attribute__((weak))
+unsigned long do_go_exec (ulong (*entry)(int, char *[]), int argc, char *argv[])
 {
-#if defined(CONFIG_I386)
-	/*
-	 * x86 does not use a dedicated register to pass the pointer
-	 * to the global_data
-	 */
-	argv[0] = (char *)gd;
-
-#elif defined(CONFIG_BLACKFIN)
-	if (dcache_status ())
-		dcache_disable ();
-	if (icache_status ())
-		icache_disable ();
-#endif
+	return entry (argc, argv);
 }
 
 int do_go (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
@@ -63,20 +49,11 @@ int do_go (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 
 	printf ("## Starting application at 0x%08lX ...\n", addr);
 
-	go_setup(argc, argv);
-
-#if defined(CONFIG_NIOS)
-	/*
-	 * Nios function pointers are address >> 1
-	 */
-	addr >>= 1;
-#endif
-
 	/*
 	 * pass address parameter as argv[0] (aka command name),
 	 * and all remaining args
 	 */
-	rc = ((ulong (*)(int, char *[]))addr) (--argc, &argv[1]);
+	rc = do_go_exec ((void *)addr, argc - 1, argv + 1);
 	if (rc != 0) rcode = 1;
 
 	printf ("## Application terminated, rc = 0x%lX\n", rc);
diff --git a/lib_i386/board.c b/lib_i386/board.c
index 47fbab4..22191e6 100644
--- a/lib_i386/board.c
+++ b/lib_i386/board.c
@@ -421,3 +421,11 @@ void hang (void)
 	puts ("### ERROR ### Please RESET the board ###\n");
 	for (;;);
 }
+
+unsigned long do_go_exec (ulong (*entry)(int, char *[]), int argc, char *argv[])
+{
+	/*
+	 * Nios function pointers are address >> 1
+	 */
+	return (entry >> 1) (argc, argv);
+}
diff --git a/lib_nios/board.c b/lib_nios/board.c
index 0a0d2e3..cdaf753 100644
--- a/lib_nios/board.c
+++ b/lib_nios/board.c
@@ -190,3 +190,13 @@ void hang (void)
 	puts("### ERROR ### Please reset board ###\n");
 	for (;;);
 }
+
+unsigned long do_go_exec (ulong (*entry)(int, char *[]), int argc, char *argv[])
+{
+	/*
+	 * x86 does not use a dedicated register to pass the pointer
+	 * to the global_data
+	 */
+	argv[-1] = (char *)gd;
+	return entry (argc, argv);
+}
-- 
1.5.5




From vapier at gentoo.org  Mon Apr 14 01:42:18 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 13 Apr 2008 19:42:18 -0400
Subject: [U-Boot-Users] [PATCH] allow ports to override bootelf behavior
Message-ID: <1208130139-18440-1-git-send-email-vapier@gentoo.org>

Change the bootelf setup function into a dedicated weak function called
do_bootelf_exec.  This way ports can control the behavior however they
like before/after calling the ELF entry point.
---
 common/cmd_elf.c |   33 +++++++++++++++++++++------------
 1 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index 4683554..62e5e76 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -27,23 +27,34 @@ DECLARE_GLOBAL_DATA_PTR;
 #define MAX(a,b) ((a) > (b) ? (a) : (b))
 #endif
 
-static inline void bootelf_setup(int argc, char *argv[])
+int valid_elf_image (unsigned long addr);
+unsigned long load_elf_image (unsigned long addr);
+
+/* Allow ports to override the default behavior */
+__attribute__((weak))
+unsigned long do_bootelf_exec (ulong (*entry)(int, char *[]), int argc, char *argv[])
 {
+	unsigned long ret;
+
 	/*
 	 * QNX images require the data cache is disabled.
 	 * Data cache is already flushed, so just turn it off.
 	 */
-	if (dcache_status ())
+	int dcache = dcache_status ();
+	if (dcache)
 		dcache_disable ();
 
-#ifdef CONFIG_BLACKFIN
-	if (icache_status ())
-		icache_disable ();
-#endif
-}
+	/*
+	 * pass address parameter as argv[0] (aka command name),
+	 * and all remaining args
+	 */
+	ret = entry (argc, argv);
 
-int valid_elf_image (unsigned long addr);
-unsigned long load_elf_image (unsigned long addr);
+	if (dcache)
+		dcache_enable ();
+
+	return ret;
+}
 
 /* ======================================================================
  * Interpreter command to boot an arbitrary ELF image from memory.
@@ -68,13 +79,11 @@ int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 
 	printf ("## Starting application at 0x%08lx ...\n", addr);
 
-	bootelf_setup(argc, argv);
-
 	/*
 	 * pass address parameter as argv[0] (aka command name),
 	 * and all remaining args
 	 */
-	rc = ((ulong (*)(int, char *[])) addr) (--argc, &argv[1]);
+	rc = do_bootelf_exec ((void *)addr, argc - 1, argv + 1);
 	if (rc != 0)
 		rcode = 1;
 
-- 
1.5.5




From pmeloy at shaw.ca  Mon Apr 14 01:42:45 2008
From: pmeloy at shaw.ca (pat)
Date: Sun, 13 Apr 2008 16:42:45 -0700
Subject: [U-Boot-Users] s3c2410 no success (my fault)
Message-ID: <1208130165.9368.10.camel@rhodan.shaw.ca>

I just don't know enough about how u-boot and C work to get u-boot 1.3.x
working on my s3c2410 board. I managed to get 1.2.0 going with the nand
commands added (not mtdpart though) which should be enough to get linux
booted (though I'm not entirely sure the nand commands are actually
working - experimenting with jffs2 now).

If anyone is working on s3c stuff and wants me to try running their
versions I'd be happy to help.

Machine config is:

AM29LV800 (1mb)
K9F1208 (64mb total)
64MB ram
SD Card
Ethernet (cs8900)
USB
800x480 LCD (driven by s3c2410)
touchscreen (driven by s3c2410)

I have no way to switch between NOR and NAND boot though so u-boot has
to start in NOR unfortunately (might be why I can't get 1.3.x to work?).

I have a wiggler clone but I'm still trying to figure out how use
openocd to debug with.





From biggerbadderben at gmail.com  Mon Apr 14 03:09:01 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Sun, 13 Apr 2008 21:09:01 -0400
Subject: [U-Boot-Users] [PATCH v2 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: <20080413220155.37FEA248BF@gemini.denx.de>
References: <20080328094435.GG4719@pengutronix.de>
	<20080413220155.37FEA248BF@gemini.denx.de>
Message-ID: <f8328f7c0804131809s4f84e828q9fde705157399c9b@mail.gmail.com>

On Sun, Apr 13, 2008 at 6:01 PM, Wolfgang Denk <wd at denx.de> wrote:
> In message <20080328094435.GG4719 at pengutronix.de> you wrote:
>  > On Thu, Mar 27, 2008 at 02:23:44PM -0400, Nick Droogh wrote:
>  > > Hi Everyone,
>  > >
>  > > Would this driver work with the LAN9218 chip as well?
>  >
>  > The chips in this family differ in that some of them have an integrated
>  > phy and others not. Some have a 16bit bus interface and others have a
>  > 32bit bus interface.
>  > So yes, the driver should work with the 9218.
>
>  Ben, it seems discussion stopped here without a decision or so. What's
>  the state of this driver, then?
>
I'm so sorry for non-responsiveness on this.  I hate to make excuses
but I'm in the midst of moving my family across the country and um,
some things have slipped through the cracks.

I've pulled Guennadi's latest submission for this driver into my local
copy, but haven't pushed it to the net repo yet.  I have a few hours
available tomorrow where I'll finish this up and also look more
closely into JCPV's regression fix for the ne2000-related build
failure.

regards,
Ben



From wd at denx.de  Mon Apr 14 03:09:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 03:09:36 +0200
Subject: [U-Boot-Users] [PATCH] Add support for setting the I2C bus
	speed in fsl_i2c.c
In-Reply-To: Your message of "Thu, 27 Mar 2008 10:45:22 BST."
	<1206611122.23794.13.camel@localhost>
Message-ID: <20080414010936.90A94248B9@gemini.denx.de>

In message <1206611122.23794.13.camel at localhost> you wrote:
> 
> This patch should resolve the compilation issues on 547x/548x cpus.

Unfortunately it's missing your Signed-off-by: line.

Also, please post patches inline rather than attachments.

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: wd at denx.de
How come everyone's going so slow if it's called rush hour?



From wd at denx.de  Mon Apr 14 03:09:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 03:09:36 +0200
Subject: [U-Boot-Users] [RFC] Rename include/md5.h to u-boot-md5.h
In-Reply-To: Your message of "Wed, 02 Apr 2008 16:19:07 CDT."
	<1207171147-3228-1-git-send-email-afleming@freescale.com>
Message-ID: <20080414010936.68BEB247E9@gemini.denx.de>

In message <1207171147-3228-1-git-send-email-afleming at freescale.com> you wrote:
> Some systems have md5.h installed in /usr/include/.  This isn't the desired
> file (we want the one in include/md5.h).  This will avoid the conflict.
> This fixes the host tools building problem
> 
> Signed-off-by: Andy Fleming <afleming at freescale.com>
> ---
> 
> This fixes the problem for me, at least...
> 
>  common/image.c       |    4 ++--
>  include/u-boot-md5.h |   23 +++++++++++++++++++++++
>  lib_generic/md5.c    |    2 +-
>  3 files changed, 26 insertions(+), 3 deletions(-)
>  create mode 100644 include/u-boot-md5.h

Applied with slight modification: I decided to use a separate
directory, i. e. include/u-boot/md5.h

Thanks a lot!

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: wd at denx.de
The rule on staying alive as a program manager is to give 'em a  num-
ber or give 'em a date, but never give 'em both at once.



From wd at denx.de  Mon Apr 14 03:09:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 03:09:36 +0200
Subject: [U-Boot-Users] [PATCH] Add support for setting the I2C bus
	speed in fsl_i2c.c
In-Reply-To: Your message of "Thu, 27 Mar 2008 11:42:42 PDT."
	<4791E710007FEB4BBF83775D787F462F06EAF512@az33exm22.fsl.freescale.net>
Message-ID: <20080414010936.A1028248BB@gemini.denx.de>

In message <4791E710007FEB4BBF83775D787F462F06EAF512 at az33exm22.fsl.freescale.net> you wrote:
> Yes. Thanks.
...
> Then how about doing this:
> 
> --- a/include/asm-m68k/global_data.h
> +++ b/include/asm-m68k/global_data.h
> @@ -47,6 +47,9 @@ typedef	struct	global_data {
>  	unsigned long	vco_clk;
>  	unsigned long	flb_clk;
>  #endif
> +#ifdef CONFIG_FSL_I2C
> +	u32 i2c1_clk;
> +#endif
>  	unsigned long	ram_size;	/* RAM size */
>  	unsigned long	reloc_off;	/* Relocation Offset */
>  	unsigned long	reset_status;	/* reset status register at boot
> 
> 
> --
> Timur Tabi

So will somebody submit a proper patch with usable commit message and
proper Signed-off-by: line, please?

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: wd at denx.de
The connection between the language in which we think/program and the
problems and solutions we can imagine is very close. For this  reason
restricting  language  features  with  the intent of eliminating pro-
grammer errors is at best dangerous.
               - Bjarne Stroustrup in "The  C++ Programming Language"



From wd at denx.de  Mon Apr 14 03:09:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 03:09:36 +0200
Subject: [U-Boot-Users] [PATCH v2] Introduce phys_size_t and move
	phys_addr_t into asm/types.h
In-Reply-To: Your message of "Thu, 27 Mar 2008 11:46:38 CDT."
	<Pine.LNX.4.64.0803271146190.1503@blarg.am.freescale.net>
Message-ID: <20080414010936.B0FBF247E9@gemini.denx.de>

In message <Pine.LNX.4.64.0803271146190.1503 at blarg.am.freescale.net> you wrote:
> Also add CONFIG_PHYS_64BIT on powerpc to deal with 32-bit ppc's
> that have larger physical addresses like 44x, 85xx, and 86xx.
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
>  include/asm-arm/io.h           |    2 --
>  include/asm-arm/types.h        |    3 +++
>  include/asm-avr32/io.h         |    2 --
>  include/asm-avr32/types.h      |    3 +++
>  include/asm-blackfin/io.h      |    2 --
>  include/asm-blackfin/types.h   |    3 +++
>  include/asm-i386/io.h          |    2 --
>  include/asm-i386/types.h       |    3 +++
>  include/asm-m68k/io.h          |    2 --
>  include/asm-m68k/types.h       |    3 +++
>  include/asm-microblaze/io.h    |    2 --
>  include/asm-microblaze/types.h |    3 +++
>  include/asm-mips/io.h          |    2 --
>  include/asm-mips/types.h       |    8 ++++++++
>  include/asm-nios/io.h          |    2 --
>  include/asm-nios/types.h       |    3 +++
>  include/asm-nios2/io.h         |    2 --
>  include/asm-ppc/io.h           |    2 --
>  include/asm-ppc/types.h        |    8 ++++++++
>  include/asm-sh/io.h            |    2 --
>  include/asm-sh/types.h         |    3 +++
>  21 files changed, 40 insertions(+), 22 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: wd at denx.de
"The POP3 server service depends on the SMTP  server  service,  which
failed to start because of the following error: The operation comple-
ted successfully."                         -- Windows NT Server v3.51



From wd at denx.de  Mon Apr 14 03:09:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 03:09:36 +0200
Subject: [U-Boot-Users] [PATCH 04/13] microblaze: add Emaclite ethernet
	driver
In-Reply-To: Your message of "Fri, 28 Mar 2008 14:41:05 BST."
	<de470d32d7222874eac8134583889844c80e4bcb.1206711077.git.monstr@monstr.eu>
Message-ID: <20080414010936.C0F24248B9@gemini.denx.de>

In message <de470d32d7222874eac8134583889844c80e4bcb.1206711077.git.monstr at monstr.eu> you wrote:
> From: Michal Simek <monstr at monstr.eu>
> 
> 
> Signed-off-by: Michal Simek <monstr at monstr.eu>

I see you sneaked this in via your microblaze custodian repo. This was
a Bad Thing, and I ask you not to do such things. You were supposed to
run this through the Net custodian.

Ditto for [PATCH 05/13] microblaze: add Emac ethernet driver

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: wd at denx.de
You Don't Have To Be 'Damned' To Work Here, But It Helps!!!
                                             - Terry Pratchett, _Eric_



From wd at denx.de  Mon Apr 14 03:09:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 03:09:36 +0200
Subject: [U-Boot-Users] [PATCH] Move init_sequence table into code.
In-Reply-To: Your message of "Fri, 28 Mar 2008 16:45:58 BST."
	<1206719159-11200-1-git-send-email-Joakim.Tjernlund@transmode.se>
Message-ID: <20080414010936.E130C248B9@gemini.denx.de>

In message <1206719159-11200-1-git-send-email-Joakim.Tjernlund at transmode.se> you wrote:
> Global variables are not ideal before relocation to RAM.

Byt they don't cause any real problem either, or am I missing
something?

I tend to reject the patch.

> -init_fnc_t *init_sequence[] = {

The original idea of having such a list  of  funtion  pointers  which
just  get executed one after another was to be able to wrap this into
some "#ifndef CONFIG_INIT_SEQUENCE" and use this to allow for  board-
specific init sequences by just adding a #define with the needed list
of functions to the board config files.

Even though this feature never was used so far, I still  hesitate  to
throw  it away - at least as long as I don't see benefits for the new
solution.

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: wd at denx.de
Never worry about theory as long as  the  machinery  does  what  it's
supposed to do.                                      - R. A. Heinlein



From wd at denx.de  Mon Apr 14 03:09:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 03:09:36 +0200
Subject: [U-Boot-Users] [PATCH] Fix 8xx build to conditionally compile
	fdt.o
In-Reply-To: Your message of "Sat, 29 Mar 2008 22:06:31 EDT."
	<20080330020631.GA3868@cideas.com>
Message-ID: <20080414010936.D153B247E9@gemini.denx.de>

In message <20080330020631.GA3868 at cideas.com> you wrote:
> Change to COBJS-y method so that the fdt.o library can be properly
> conditionally compiled.  Without this change, the mpc8xx boards that
> don't use CONFIG_OF_LIBFDT still build the fdt.o, causing code bloat
> and compile warnings.
> 
> Signed-off-by: Gerald Van Baren <vanbaren at cideas.com>

Unfortunately this doesn't apply any more. Could you please rebase and
resubmit? Thanks in advance.

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: wd at denx.de
Thought for the day: What if there were no hypothetical situations?



From wd at denx.de  Mon Apr 14 03:09:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 03:09:36 +0200
Subject: [U-Boot-Users] [PATCH] Change env_get_char from a global
	function ptr to a function.
In-Reply-To: Your message of "Sat, 05 Apr 2008 19:31:33 +0200."
	<024e01c89742$e48d4b80$ada7e280$@Tjernlund@transmode.se>
Message-ID: <20080414010936.F3D50247E9@gemini.denx.de>

In message <024e01c89742$e48d4b80$ada7e280$@Tjernlund at transmode.se> you wrote:
> Did you try this one or did du skip it this release?

Unfortunately this doesn't apply any more:

Applying Change env_get_char from a global function ptr to a function.
error: patch failed: common/cmd_bootm.c:1150
error: common/cmd_bootm.c: patch does not apply
error: patch failed: common/fdt_support.c:225
error: common/fdt_support.c: patch does not apply
error: patch failed: common/ft_build.c:396
error: common/ft_build.c: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged common/cmd_bootm.c
CONFLICT (content): Merge conflict in common/cmd_bootm.c
Auto-merged common/cmd_nvedit.c
Auto-merged common/fdt_support.c
CONFLICT (content): Merge conflict in common/fdt_support.c
Auto-merged common/ft_build.c
CONFLICT (content): Merge conflict in common/ft_build.c
Auto-merged include/common.h
Failed to merge in the changes.
Patch failed at 0001.


Could you please update and resubmit? Thanks in advance.

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: wd at denx.de
You don't have to worry about me. I might have been born yesterday...
but I stayed up all night.



From vapier at gentoo.org  Mon Apr 14 03:22:35 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 13 Apr 2008 21:22:35 -0400
Subject: [U-Boot-Users] [PATCH v2 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: <f8328f7c0804131809s4f84e828q9fde705157399c9b@mail.gmail.com>
References: <20080328094435.GG4719@pengutronix.de>
	<20080413220155.37FEA248BF@gemini.denx.de>
	<f8328f7c0804131809s4f84e828q9fde705157399c9b@mail.gmail.com>
Message-ID: <200804132122.35906.vapier@gentoo.org>

On Sunday 13 April 2008, Ben Warren wrote:
> On Sun, Apr 13, 2008 at 6:01 PM, Wolfgang Denk <wd at denx.de> wrote:
> > In message <20080328094435.GG4719 at pengutronix.de> you wrote:
> >  > On Thu, Mar 27, 2008 at 02:23:44PM -0400, Nick Droogh wrote:
> >  > > Hi Everyone,
> >  > >
> >  > > Would this driver work with the LAN9218 chip as well?
> >  >
> >  > The chips in this family differ in that some of them have an
> >  > integrated phy and others not. Some have a 16bit bus interface and
> >  > others have a 32bit bus interface.
> >  > So yes, the driver should work with the 9218.
> >
> >  Ben, it seems discussion stopped here without a decision or so. What's
> >  the state of this driver, then?
>
> I'm so sorry for non-responsiveness on this.  I hate to make excuses
> but I'm in the midst of moving my family across the country and um,
> some things have slipped through the cracks.
>
> I've pulled Guennadi's latest submission for this driver into my local
> copy, but haven't pushed it to the net repo yet.  I have a few hours
> available tomorrow where I'll finish this up and also look more
> closely into JCPV's regression fix for the ne2000-related build
> failure.

i'm guessing the eeprom programmer i posted wont be part of this.  should i 
just wait for everything to hit mainline and then post a patch to add it 
then ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080413/c677299a/attachment.pgp 

From biggerbadderben at gmail.com  Mon Apr 14 03:29:34 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Sun, 13 Apr 2008 21:29:34 -0400
Subject: [U-Boot-Users] [PATCH v2 4/7] add SMSC LAN9x1x Network driver
In-Reply-To: <200804132122.35906.vapier@gentoo.org>
References: <20080328094435.GG4719@pengutronix.de>
	<20080413220155.37FEA248BF@gemini.denx.de>
	<f8328f7c0804131809s4f84e828q9fde705157399c9b@mail.gmail.com>
	<200804132122.35906.vapier@gentoo.org>
Message-ID: <f8328f7c0804131829y77306048pd64742cd421a6955@mail.gmail.com>

On Sun, Apr 13, 2008 at 9:22 PM, Mike Frysinger <vapier at gentoo.org> wrote:
>
> On Sunday 13 April 2008, Ben Warren wrote:
>  > On Sun, Apr 13, 2008 at 6:01 PM, Wolfgang Denk <wd at denx.de> wrote:
>  > > In message <20080328094435.GG4719 at pengutronix.de> you wrote:
>  > >  > On Thu, Mar 27, 2008 at 02:23:44PM -0400, Nick Droogh wrote:
>  > >  > > Hi Everyone,
>  > >  > >
>  > >  > > Would this driver work with the LAN9218 chip as well?
>  > >  >
>  > >  > The chips in this family differ in that some of them have an
>  > >  > integrated phy and others not. Some have a 16bit bus interface and
>  > >  > others have a 32bit bus interface.
>  > >  > So yes, the driver should work with the 9218.
>  > >
>  > >  Ben, it seems discussion stopped here without a decision or so. What's
>  > >  the state of this driver, then?
>  >
>  > I'm so sorry for non-responsiveness on this.  I hate to make excuses
>  > but I'm in the midst of moving my family across the country and um,
>  > some things have slipped through the cracks.
>  >
>  > I've pulled Guennadi's latest submission for this driver into my local
>  > copy, but haven't pushed it to the net repo yet.  I have a few hours
>  > available tomorrow where I'll finish this up and also look more
>  > closely into JCPV's regression fix for the ne2000-related build
>  > failure.
>
>  i'm guessing the eeprom programmer i posted wont be part of this.  should i
>  just wait for everything to hit mainline and then post a patch to add it
>  then ?
>  -mike
>
Right - this particular one has been given the OK as a bug fix for
1.3.3.  The EEPROM programmer will make it into the next release.

regards,
Ben



From gvb.uboot at gmail.com  Mon Apr 14 05:31:12 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Sun, 13 Apr 2008 23:31:12 -0400
Subject: [U-Boot-Users] [PATCH] Fix 8xx build to conditionally compile
	fdt.o
In-Reply-To: <20080414010936.D153B247E9@gemini.denx.de>
References: <20080414010936.D153B247E9@gemini.denx.de>
Message-ID: <4802D000.6050005@gmail.com>

Wolfgang Denk wrote:
> In message <20080330020631.GA3868 at cideas.com> you wrote:
>> Change to COBJS-y method so that the fdt.o library can be properly
>> conditionally compiled.  Without this change, the mpc8xx boards that
>> don't use CONFIG_OF_LIBFDT still build the fdt.o, causing code bloat
>> and compile warnings.
>>
>> Signed-off-by: Gerald Van Baren <vanbaren at cideas.com>
> 
> Unfortunately this doesn't apply any more. Could you please rebase and
> resubmit? Thanks in advance.
> 
> Best regards,
> 
> Wolfgang Denk

Hi Wolfgang,

I abandoned this patch, Jean-Christoph wrote a better version that I 
picked up and *has been already applied* to u-boot master repo by way of 
the u-boot-fdt repo.

Reference:
<http://article.gmane.org/gmane.comp.boot-loaders.u-boot/39324>

Thanks,
gvb




From ulf.samuelsson at atmel.com  Mon Apr 14 08:01:28 2008
From: ulf.samuelsson at atmel.com (Ulf Samuelsson)
Date: Mon, 14 Apr 2008 08:01:28 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
References: <1208030816.23686.13.camel@elrond.atmel.sweden>
	<1208093705.23686.8.camel@voyager.dsnet>
Message-ID: <02c001c89df5$0056b550$040514ac@atmel.com>

> 
> Le samedi 12 avril 2008 ? 22:06 +0200, Ulf Samuelsson a ?crit :
>> Add support for the AT91RM9200EK Board.
> 
> Hi Ulf,
> 
> I do have a few issues with your patch. As you have seen, I started
> adapting the Atmel changes for the AT91SAM boards, and in doing so I
> tried to implement (well, quite a lot was borrowed from Linux) a common
> infrastructure for the SAM9 and CAP9 CPUs/boards.
> 
> I think that the AT91RM9200 could integrate quite well in the existing
> framework. I haven't done the job myself yet because I have quite
> limited ressources at the moment (and this is why I chose
> 'arch-at91sam9' instead of 'arch-at91'...) but since you're contributing
> a new port it may be the right time to do it.
> 
> This means for example:
> - using at91 gpio macros: at91_set_A_periph(), etc.
> - using the standard CFI flash driver instead of the custom one
> - maybe others...
> 

The at91rm9200dk board already exists with similar code.

I think the chances that it someone will work on this is higher
if the code is inside U-Boot than outside U-Boot though.

BTW: Why not have the AVR32 and AT91 use the same.
    The PIO peripheral is the same.

> Ah, and it would be much easier to quote and comment on your patches if
> they were inlined in your mails.
> 

OK

> Thanks,
> 
> Stelian.
> -- 
> Stelian Pop <stelian at popies.net>


Best Regards
Ulf Samuelsson





From ulf.samuelsson at atmel.com  Mon Apr 14 08:00:27 2008
From: ulf.samuelsson at atmel.com (Ulf Samuelsson)
Date: Mon, 14 Apr 2008 08:00:27 +0200
Subject: [U-Boot-Users] [PATCH] Add support for Atmel flash
References: <1208027002.23686.7.camel@elrond.atmel.sweden>
	<1208093818.23686.11.camel@voyager.dsnet>
Message-ID: <02bf01c89df4$fe986380$040514ac@atmel.com>

> Le samedi 12 avril 2008 ? 21:03 +0200, Ulf Samuelsson a ?crit :
>> Add ID codes for most recent Atmel NOR flashes
> 
> Is there any added value on using the atmel flash driver instead of the
> standard CFI driver ? It surely doesn't have any on the SAM9/CAP9
> boards, but I'm not sure of the older AT91RM9200.
> 
> Thanks,
> -- 
> Stelian Pop <stelian at popies.net>
> 


It is mainly time related.
This flash driver is well tested on the AT91RM9200EK.
The standard CFI driver is not.
While CFI should work, I do not have time to make a thorough test.

Best Regards
Ulf Samuelsson





From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH] Add CONFIG_MII_INIT support to related
	boards
In-Reply-To: Your message of "Sun, 30 Mar 2008 01:22:13 CDT."
	<1206858133-18090-1-git-send-email-Tsi-Chung.Liew@freescale.com>
Message-ID: <20080414063340.3C333248B9@gemini.denx.de>

In message <1206858133-18090-1-git-send-email-Tsi-Chung.Liew at freescale.com> you wrote:
> From: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
> 
> Replace CONFIG_8xx and CONFIG_MCF532x to CONFIG_MII_INIT in
> cmd_init.c. Add CONFIG_MII_INIT to board configuration files
> that use mii_init() in cmd_init.c.
> 
> Signed-off-by: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
> ---
>  board/fads/fads.h              |    1 +
>  common/cmd_mii.c               |    2 +-
>  include/configs/Adder.h        |    1 +
>  include/configs/EB+MCF-EV123.h |    1 +
>  include/configs/EP88x.h        |    1 +
>  include/configs/GEN860T.h      |    1 +
>  include/configs/M5235EVB.h     |    1 +
>  include/configs/M5271EVB.h     |    1 +
>  include/configs/M5275EVB.h     |    1 +
>  include/configs/M5282EVB.h     |    1 +
>  include/configs/M5329EVB.h     |    1 +
>  include/configs/M5373EVB.h     |    1 +
>  include/configs/M54455EVB.h    |    4 ++--
>  include/configs/M5475EVB.h     |    1 +
>  include/configs/M5485EVB.h     |    1 +
>  include/configs/NETPHONE.h     |    1 +
>  include/configs/NETTA.h        |    1 +
>  include/configs/NETTA2.h       |    1 +
>  include/configs/TK885D.h       |    2 ++
>  include/configs/TOP860.h       |    1 +
>  include/configs/TQM885D.h      |    1 +
>  include/configs/cobra5272.h    |    1 +
>  include/configs/idmr.h         |    3 ++-
>  include/configs/spc1920.h      |    1 +
>  include/configs/stxxtc.h       |    1 +
>  include/configs/uc100.h        |    1 +
>  26 files changed, 29 insertions(+), 4 deletions(-)


Applied, thanks.

Viele Gr??e,

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: wd at denx.de
It is dangerous to be right on a subject  on  which  the  established
authorities are wrong.                                    -- Voltaire



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Additional PCI IDs for IDE and
	network controllers
In-Reply-To: Your message of "Mon, 31 Mar 2008 01:32:01 +0200."
	<Pine.LNX.4.64.0803310104320.6825@axis700.grange>
Message-ID: <20080414063340.5D7E2248B9@gemini.denx.de>

In message <Pine.LNX.4.64.0803310104320.6825 at axis700.grange> you wrote:
> These PCI IDs are required by the Linkstation platforms.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Sorry, does not apply - please rebase and resubmit:

Applying Additional PCI IDs for IDE and network controllers
error: patch failed: include/pci_ids.h:2073
error: include/pci_ids.h: patch does not apply
Using index info to reconstruct a base tree...
error: patch failed: include/pci_ids.h:2073
error: include/pci_ids.h: patch does not apply
Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Cannot fall back to three-way merge.
Patch failed at 0001.


> 
> Sorry for a last minute submission... Woould be good to get this and the 
> following patch in for 1.3.3. Haven't found a PCI custodian, so, CC-ing 
> Wolfgang.

No need to Cc: me. I read this list.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is common sense to take a method and try it. If it fails, admit it
frankly and try another. But above all, try something.
                                              - Franklin D. Roosevelt



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Support for LinkStation / KuroBox HD
	and HG PPC models
In-Reply-To: Your message of "Mon, 31 Mar 2008 01:32:15 +0200."
	<Pine.LNX.4.64.0803310112130.6825@axis700.grange>
Message-ID: <20080414063340.6D0C1248AB@gemini.denx.de>

In message <Pine.LNX.4.64.0803310112130.6825 at axis700.grange> you wrote:
> This patch is based on the port by Mihai Georgian (see linkstation.c for 
> Copyright information) and implements support for LinkStation / KuroBox HD 
> and HG PPC models from Buffalo Technology, whereby HD is deactivated at 
> the moment, pending network driver fixing.
> 
> Notice to users: this is pretty much a barebone port. Support for network 
> on HG models is already in the U-Boot mainline, but you might also want 
> patches to switch fan / phy modes depending on the negotiated ethernet 
> parameters. This patch also doesn't support console switching, booting EM 
> mode, Buffalo specific ext2 magic number. So, if you want to use any of 
> those, you need additional patches. Otherwise this patche provides a fully 
> functional u-boot with a network console on your system.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
> 
> As the comment in the Makefile states, HD is disabled at the moment due to 
> a problem with the network driver, which has to be investigated further, 
> as hardware availability and time permit.
> 
>  MAKEALL                         |    1 +
>  Makefile                        |   12 ++
>  board/linkstation/Makefile      |   40 +++
>  board/linkstation/avr.c         |  293 ++++++++++++++++++++++
>  board/linkstation/config.mk     |   50 ++++
>  board/linkstation/hwctl.c       |  135 +++++++++++
>  board/linkstation/ide.c         |   99 ++++++++
>  board/linkstation/linkstation.c |  130 ++++++++++
>  include/configs/linkstation.h   |  509 +++++++++++++++++++++++++++++++++++++++
>  9 files changed, 1267 insertions(+), 0 deletions(-)
>  create mode 100644 board/linkstation/Makefile
 create mode 100644 board/linkstation/avr.c
>  create mode 100644 board/linkstation/config.mk
>  create mode 100644 board/linkstation/hwctl.c
>  create mode 100644 board/linkstation/ide.c
>  create mode 100644 board/linkstation/linkstation.c
>  create mode 100644 include/configs/linkstation.h


Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Time is an illusion perpetrated by the manufacturers of space.



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH] Fix OneNAND read
In-Reply-To: Your message of "Mon, 31 Mar 2008 10:40:36 +0900."
	<20080331014036.GA30866@party>
Message-ID: <20080414063340.8C91D248BB@gemini.denx.de>

In message <20080331014036.GA30866 at party> you wrote:
> It should access with 16-bit instead of 8-bit
> 
> Now it uses the generic memcpy with 8-bit access. It means it reads wrong data from OneNAND.
> 
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
> diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c

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: wd at denx.de
It is easier to write an incorrect program than understand a  correct
one.



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH] Fix OneNAND erase command
In-Reply-To: Your message of "Mon, 31 Mar 2008 10:40:19 +0900."
	<20080331014019.GA30858@party>
Message-ID: <20080414063340.7CC77248B9@gemini.denx.de>

In message <20080331014019.GA30858 at party> you wrote:
> It mis-calculates the block address.
> Also fix DECLARE_GLOBAL_DATA_PTR in env_onenand.
> 
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
> diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c

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: wd at denx.de
Our OS who art in CPU, UNIX be thy name.
Thy programs run, thy syscalls done,
In kernel as it is in user!



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH] bugfix: the watchdog post for lwmon5
In-Reply-To: Your message of "Tue, 01 Apr 2008 15:13:03 +0200."
	<20080401131303.17520@gmx.net>
Message-ID: <20080414063340.D00D6248C1@gemini.denx.de>

In message <20080401131303.17520 at gmx.net> you wrote:
> You are right! I've checked it again and find the mistake by myself. 
> 
> Subject: [PATCH] bugfix: lwmon5 watchdog post
> If the hardware watchdog detects a voltage error, the watchdog set GPIO62 to low.
> The watchdog POST have to detect this lowpegel.
> 
> Signed-off-by: Sascha Laue <leglas0 at legpc180.leg.liebherr.i>

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: wd at denx.de
News is what a chap who doesn't care much  about  anything  wants  to
read. And it's only news until he's read it. After that it's dead.
                           - Evelyn Waugh _Scoop_ (1938) bk. 1, ch. 5



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH] ata: update the libata.h from ata.h of
	linux kernel
In-Reply-To: Your message of "Tue, 01 Apr 2008 15:22:11 +0800."
	<1207034531.3676.4.camel@localhost.localdomain>
Message-ID: <20080414063340.C02FB248BF@gemini.denx.de>

In message <1207034531.3676.4.camel at localhost.localdomain> you wrote:
> Current libata.h of u-boot is out of sync from linux kernel,
> this patch make it be consistent with linux kernel.
> 
> Signed-off-by: Dave Liu <daveliu at freescale.com>
> Signed-off-by: Tor Krill <tor at excito.com>
> ---
>  drivers/block/fsl_sata.c |   14 +-
>  include/libata.h         |  644 +++++++++++++++++++++++++++++++++++++++-------
>  2 files changed, 561 insertions(+), 97 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: wd at denx.de
"Why waste negative entropy on comments, when you could use the  same
entropy to create bugs instead?"                        - Steve Elias



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH][resubmit] QE IO: Add initial data to pin
	configuration + read/write functions
In-Reply-To: Your message of "Sun, 30 Mar 2008 06:45:25 PDT."
	<16381440.post@talk.nabble.com>
Message-ID: <20080414063340.4D4A2248AB@gemini.denx.de>

In message <16381440.post at talk.nabble.com> you wrote:
> 
> On the MPC83xx & MPC85xx architectures that have QE, add initial data to the
> pin configuration table (qe_iop_conf_tab). This is relevant for GPIO pins
> defined as output. One can setup a value of -1 to leave the value unchanged.
> QE initialization tables in all relevant boards were also replaced.
> In addition, add IO pin read & write functions.
> This patch also includes commands for reading and writing parallel I/O ports
> (pario command).
> 
> Signed-off-by: David Saada <david.saada at ecitele.com>
> 
>  b/common/cmd_pario.c                      |   85 +++++++++
>  board/freescale/mpc8323erdb/mpc8323erdb.c |   74 +++----
>  board/freescale/mpc832xemds/mpc832xemds.c |   74 +++----
>  board/freescale/mpc8360emds/mpc8360emds.c |  110 +++++------
>  board/freescale/mpc8360erdk/mpc8360erdk.c |  280
> +++++++++++++++---------------
>  board/freescale/mpc8568mds/mpc8568mds.c   |  106 +++++------
>  common/Makefile                           |    1 
>  cpu/mpc83xx/cpu_init.c                    |    7 
>  cpu/mpc83xx/qe_io.c                       |   59 +++++-
>  cpu/mpc85xx/cpu_init.c                    |    7 
>  cpu/mpc85xx/qe_io.c                       |   58 +++++-
>  include/ioports.h                         |    8 
>  12 files changed, 526 insertions(+), 343 deletions(-)
> 
> --- a/include/ioports.h	2008-03-28 01:49:12.000000000 +0200
> +++ b/include/ioports.h	2008-03-30 16:11:09.514274000 +0300
> @@ -60,6 +60,14 @@ typedef struct {
>  	int		dir;
>  	int		open_drain;
>  	int		assign;
> +	int		data;
>  } qe_iop_conf_t;
>  
>  #define QE_IOP_TAB_END	(-1)
> +
> +void qe_config_iopin(u8 port, u8 pin, int dir, int open_drain, int assign, 
> +					 int data);
> +void qe_read_iopin(u8 port, u8 pin, int *data);
> +void qe_write_iopin(u8 port, u8 pin, int data);
> +
> +
> --- a/cpu/mpc85xx/cpu_init.c	2008-03-28 01:49:12.000000000 +0200
> +++ b/cpu/mpc85xx/cpu_init.c	2008-03-30 15:42:32.913152000 +0300
> @@ -39,15 +39,13 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  #ifdef CONFIG_QE
>  extern qe_iop_conf_t qe_iop_conf_tab[];
> -extern void qe_config_iopin(u8 port, u8 pin, int dir,
> -				int open_drain, int assign);
>  extern void qe_init(uint qe_base);
>  extern void qe_reset(void);
>  
>  static void config_qe_ioports(void)
>  {
>  	u8      port, pin;
> -	int     dir, open_drain, assign;
> +	int     dir, open_drain, assign, data;
>  	int     i;
>  
>  	for (i = 0; qe_iop_conf_tab[i].assign != QE_IOP_TAB_END; i++) {
> @@ -56,7 +54,8 @@ static void config_qe_ioports(void)
>  		dir		= qe_iop_conf_tab[i].dir;
>  		open_drain	= qe_iop_conf_tab[i].open_drain;
>  		assign		= qe_iop_conf_tab[i].assign;
> -		qe_config_iopin(port, pin, dir, open_drain, assign);
> +		data		= qe_iop_conf_tab[i].data;
> +		qe_config_iopin(port, pin, dir, open_drain, assign, data);
>  	}
>  }
>  #endif
> --- a/cpu/mpc85xx/qe_io.c	2008-03-28 01:49:12.000000000 +0200
> +++ b/cpu/mpc85xx/qe_io.c	2008-03-30 15:44:56.961332000 +0300
> @@ -27,16 +27,30 @@
>  
>  #if defined(CONFIG_QE)
>  #define	NUM_OF_PINS	32
> -void qe_config_iopin(u8 port, u8 pin, int dir, int open_drain, int assign)
> +void qe_config_iopin(u8 port, u8 pin, int dir, int open_drain, int assign, 
> +					 int data)
>  {
>  	u32			pin_2bit_mask;
>  	u32			pin_2bit_dir;
>  	u32			pin_2bit_assign;
>  	u32			pin_1bit_mask;
>  	u32			tmp_val;
> -	volatile ccsr_gur_t 	*gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
> -	volatile par_io_t	*par_io = (volatile par_io_t *)
> -						&(gur->qe_par_io);
> +	ccsr_gur_t 	*gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
> +	par_io_t	*par_io = (par_io_t *) &(gur->qe_par_io);
> +
> +	/* Calculate pin location for 1bit mask */
> +	pin_1bit_mask = (u32)(1 << (NUM_OF_PINS - (pin+1)));
> +
> +	/* Setup the data */
> +	if ((data != -1) &&		/* Don't leave unchanged */ 
> +		(assign == 0) && 	/* GPIO */
> +		(dir & 1)) { 		/* Has output */
> +		tmp_val = in_be32(&par_io[port].cpdat);
> +		if (data)
> +			out_be32(&par_io[port].cpdat, pin_1bit_mask | tmp_val);
> +		else
> +			out_be32(&par_io[port].cpdat, ~pin_1bit_mask & tmp_val);
> +	}
>  
>  	/* Caculate pin location and 2bit mask and dir */
>  	pin_2bit_mask = (u32)(0x3 << (NUM_OF_PINS-(pin%(NUM_OF_PINS/2)+1)*2));
> @@ -55,9 +69,6 @@ void qe_config_iopin(u8 port, u8 pin, in
>  		out_be32(&par_io[port].cpdir1, pin_2bit_dir | tmp_val);
>  	}
>  
> -	/* Calculate pin location for 1bit mask */
> -	pin_1bit_mask = (u32)(1 << (NUM_OF_PINS - (pin+1)));
> -
>  	/* Setup the open drain */
>  	tmp_val = in_be32(&par_io[port].cpodr);
>  	if (open_drain)
> @@ -82,4 +93,37 @@ void qe_config_iopin(u8 port, u8 pin, in
>  	}
>  }
>  
> +void qe_read_iopin(u8 port, u8 pin, int *data)
> +{
> +	u32			pin_1bit_mask;
> +	u32			tmp_val;
> +	ccsr_gur_t 	*gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
> +	par_io_t	*par_io = (par_io_t *) &(gur->qe_par_io);
> +
> +	/* Calculate pin location for 1bit mask */
> +	pin_1bit_mask = (u32)(1 << (NUM_OF_PINS - (pin+1)));
> +
> +	/* Read the data */
> +	tmp_val = in_be32(&par_io[port].cpdat);
> +	*data = (tmp_val >> (NUM_OF_PINS - (pin+1))) & 0x1;
> +}
> +
> +void qe_write_iopin(u8 port, u8 pin, int data)
> +{
> +	u32			pin_1bit_mask;
> +	u32			tmp_val;
> +	ccsr_gur_t 	*gur = (void *)(CFG_MPC85xx_GUTS_ADDR);
> +	par_io_t	*par_io = (par_io_t *) &(gur->qe_par_io);
> +
> +	/* Calculate pin location for 1bit mask */
> +	pin_1bit_mask = (u32)(1 << (NUM_OF_PINS - (pin+1)));
> +
> +	/* Write the data */
> +	tmp_val = in_be32(&par_io[port].cpdat);
> +	if (data)
> +		out_be32(&par_io[port].cpdat, pin_1bit_mask | tmp_val);
> +	else
> +		out_be32(&par_io[port].cpdat, ~pin_1bit_mask & tmp_val);
> +}
> +
>  #endif /* CONFIG_QE */
> --- a/cpu/mpc83xx/cpu_init.c	2008-03-28 01:49:12.000000000 +0200
> +++ b/cpu/mpc83xx/cpu_init.c	2008-03-30 15:45:53.227362000 +0300
> @@ -28,15 +28,13 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  #ifdef CONFIG_QE
>  extern qe_iop_conf_t qe_iop_conf_tab[];
> -extern void qe_config_iopin(u8 port, u8 pin, int dir,
> -			 int open_drain, int assign);
>  extern void qe_init(uint qe_base);
>  extern void qe_reset(void);
>  
>  static void config_qe_ioports(void)
>  {
>  	u8	port, pin;
> -	int	dir, open_drain, assign;
> +	int	dir, open_drain, assign, data;
>  	int	i;
>  
>  	for (i = 0; qe_iop_conf_tab[i].assign != QE_IOP_TAB_END; i++) {
> @@ -45,7 +43,8 @@ static void config_qe_ioports(void)
>  		dir		= qe_iop_conf_tab[i].dir;
>  		open_drain	= qe_iop_conf_tab[i].open_drain;
>  		assign		= qe_iop_conf_tab[i].assign;
> -		qe_config_iopin(port, pin, dir, open_drain, assign);
> +		data		= qe_iop_conf_tab[i].data;
> +		qe_config_iopin(port, pin, dir, open_drain, assign, data);
>  	}
>  }
>  #endif
> --- a/cpu/mpc83xx/qe_io.c	2008-03-28 01:49:12.000000000 +0200
> +++ b/cpu/mpc83xx/qe_io.c	2008-03-30 15:53:43.620970000 +0300
> @@ -26,15 +26,30 @@
>  #include "asm/immap_83xx.h"
>  
>  #define	NUM_OF_PINS	32
> -void qe_config_iopin(u8 port, u8 pin, int dir, int open_drain, int assign)
> +void qe_config_iopin(u8 port, u8 pin, int dir, int open_drain, int assign, 
> +					 int data)
>  {
>  	u32			pin_2bit_mask;
>  	u32			pin_2bit_dir;
>  	u32			pin_2bit_assign;
>  	u32			pin_1bit_mask;
>  	u32			tmp_val;
> -	volatile immap_t	*im = (volatile immap_t *)CFG_IMMR;
> -	volatile qepio83xx_t	*par_io = (volatile qepio83xx_t *)&im->qepio;
> +	immap_t	*im = (immap_t *)CFG_IMMR;
> +	qepio83xx_t	*par_io = (qepio83xx_t *)&im->qepio;
> +
> +	/* Calculate pin location for 1bit mask */
> +	pin_1bit_mask = (u32)(1 << (NUM_OF_PINS - (pin+1)));
> +
> +	/* Setup the data */
> +	if ((data != -1) &&		/* Don't leave unchanged */ 
> +		(assign == 0) && 	/* GPIO */
> +		(dir & 1)) { 		/* Has output */
> +		tmp_val = in_be32(&par_io->ioport[port].pdat);
> +		if (data)
> +			out_be32(&par_io->ioport[port].pdat, pin_1bit_mask | tmp_val);
> +		else
> +			out_be32(&par_io->ioport[port].pdat, ~pin_1bit_mask & tmp_val);
> +	}
>  
>  	/* Caculate pin location and 2bit mask and dir */
>  	pin_2bit_mask = (u32)(0x3 << (NUM_OF_PINS-(pin%(NUM_OF_PINS/2)+1)*2));
> @@ -53,9 +68,6 @@ void qe_config_iopin(u8 port, u8 pin, in
>  		out_be32(&par_io->ioport[port].dir1, pin_2bit_dir | tmp_val);
>  	}
>  
> -	/* Calculate pin location for 1bit mask */
> -	pin_1bit_mask = (u32)(1 << (NUM_OF_PINS - (pin+1)));
> -
>  	/* Setup the open drain */
>  	tmp_val = in_be32(&par_io->ioport[port].podr);
>  	if (open_drain) {
> @@ -80,3 +92,38 @@ void qe_config_iopin(u8 port, u8 pin, in
>  		out_be32(&par_io->ioport[port].ppar1, pin_2bit_assign | tmp_val);
>  	}
>  }
> +
> +void qe_read_iopin(u8 port, u8 pin, int *data)
> +{
> +	u32			pin_1bit_mask;
> +	u32			tmp_val;
> +	immap_t	*im = (immap_t *)CFG_IMMR;
> +	qepio83xx_t	*par_io = (qepio83xx_t *)&im->qepio;
> +
> +	/* Calculate pin location for 1bit mask */
> +	pin_1bit_mask = (u32)(1 << (NUM_OF_PINS - (pin+1)));
> +
> +	/* Read the data */
> +	tmp_val = in_be32(&par_io->ioport[port].pdat);
> +	*data = (tmp_val >> (NUM_OF_PINS - (pin+1))) & 0x1;
> +}
> +
> +void qe_write_iopin(u8 port, u8 pin, int data)
> +{
> +	u32			pin_1bit_mask;
> +	u32			tmp_val;
> +	immap_t	*im = (immap_t *)CFG_IMMR;
> +	qepio83xx_t	*par_io = (qepio83xx_t *)&im->qepio;
> +
> +	/* Calculate pin location for 1bit mask */
> +	pin_1bit_mask = (u32)(1 << (NUM_OF_PINS - (pin+1)));
> +
> +	/* Setup the data */
> +	tmp_val = in_be32(&par_io->ioport[port].pdat);
> +	if (data) {
> +		out_be32(&par_io->ioport[port].pdat, pin_1bit_mask | tmp_val);
> +	} else {
> +		out_be32(&par_io->ioport[port].pdat, ~pin_1bit_mask & tmp_val);
> +	}
> +}
> +
> --- a/board/freescale/mpc8323erdb/mpc8323erdb.c	2008-03-28
> 01:49:12.000000000 +0200
> +++ b/board/freescale/mpc8323erdb/mpc8323erdb.c	2008-03-30
> 15:54:25.959133000 +0300
> @@ -23,47 +23,47 @@
>  
>  const qe_iop_conf_t qe_iop_conf_tab[] = {
>  	/* UCC3 */
> -	{1,  0, 1, 0, 1}, /* TxD0 */
> -	{1,  1, 1, 0, 1}, /* TxD1 */
> -	{1,  2, 1, 0, 1}, /* TxD2 */
> -	{1,  3, 1, 0, 1}, /* TxD3 */
> -	{1,  9, 1, 0, 1}, /* TxER */
> -	{1, 12, 1, 0, 1}, /* TxEN */
> -	{3, 24, 2, 0, 1}, /* TxCLK->CLK10 */
> -
> -	{1,  4, 2, 0, 1}, /* RxD0 */
> -	{1,  5, 2, 0, 1}, /* RxD1 */
> -	{1,  6, 2, 0, 1}, /* RxD2 */
> -	{1,  7, 2, 0, 1}, /* RxD3 */
> -	{1,  8, 2, 0, 1}, /* RxER */
> -	{1, 10, 2, 0, 1}, /* RxDV */
> -	{0, 13, 2, 0, 1}, /* RxCLK->CLK9 */
> -	{1, 11, 2, 0, 1}, /* COL */
> -	{1, 13, 2, 0, 1}, /* CRS */
> +	{1,  0, 1, 0, 1, -1}, /* TxD0 */
> +	{1,  1, 1, 0, 1, -1}, /* TxD1 */
> +	{1,  2, 1, 0, 1, -1}, /* TxD2 */
> +	{1,  3, 1, 0, 1, -1}, /* TxD3 */
> +	{1,  9, 1, 0, 1, -1}, /* TxER */
> +	{1, 12, 1, 0, 1, -1}, /* TxEN */
> +	{3, 24, 2, 0, 1, -1}, /* TxCLK->CLK10 */
> +
> +	{1,  4, 2, 0, 1, -1}, /* RxD0 */
> +	{1,  5, 2, 0, 1, -1}, /* RxD1 */
> +	{1,  6, 2, 0, 1, -1}, /* RxD2 */
> +	{1,  7, 2, 0, 1, -1}, /* RxD3 */
> +	{1,  8, 2, 0, 1, -1}, /* RxER */
> +	{1, 10, 2, 0, 1, -1}, /* RxDV */
> +	{0, 13, 2, 0, 1, -1}, /* RxCLK->CLK9 */
> +	{1, 11, 2, 0, 1, -1}, /* COL */
> +	{1, 13, 2, 0, 1, -1}, /* CRS */
>  
>  	/* UCC2 */
> -	{0, 18, 1, 0, 1}, /* TxD0 */
> -	{0, 19, 1, 0, 1}, /* TxD1 */
> -	{0, 20, 1, 0, 1}, /* TxD2 */
> -	{0, 21, 1, 0, 1}, /* TxD3 */
> -	{0, 27, 1, 0, 1}, /* TxER */
> -	{0, 30, 1, 0, 1}, /* TxEN */
> -	{3, 23, 2, 0, 1}, /* TxCLK->CLK3 */
> -
> -	{0, 22, 2, 0, 1}, /* RxD0 */
> -	{0, 23, 2, 0, 1}, /* RxD1 */
> -	{0, 24, 2, 0, 1}, /* RxD2 */
> -	{0, 25, 2, 0, 1}, /* RxD3 */
> -	{0, 26, 1, 0, 1}, /* RxER */
> -	{0, 28, 2, 0, 1}, /* Rx_DV */
> -	{3, 21, 2, 0, 1}, /* RxCLK->CLK16 */
> -	{0, 29, 2, 0, 1}, /* COL */
> -	{0, 31, 2, 0, 1}, /* CRS */
> +	{0, 18, 1, 0, 1, -1}, /* TxD0 */
> +	{0, 19, 1, 0, 1, -1}, /* TxD1 */
> +	{0, 20, 1, 0, 1, -1}, /* TxD2 */
> +	{0, 21, 1, 0, 1, -1}, /* TxD3 */
> +	{0, 27, 1, 0, 1, -1}, /* TxER */
> +	{0, 30, 1, 0, 1, -1}, /* TxEN */
> +	{3, 23, 2, 0, 1, -1}, /* TxCLK->CLK3 */
> +
> +	{0, 22, 2, 0, 1, -1}, /* RxD0 */
> +	{0, 23, 2, 0, 1, -1}, /* RxD1 */
> +	{0, 24, 2, 0, 1, -1}, /* RxD2 */
> +	{0, 25, 2, 0, 1, -1}, /* RxD3 */
> +	{0, 26, 1, 0, 1, -1}, /* RxER */
> +	{0, 28, 2, 0, 1, -1}, /* Rx_DV */
> +	{3, 21, 2, 0, 1, -1}, /* RxCLK->CLK16 */
> +	{0, 29, 2, 0, 1, -1}, /* COL */
> +	{0, 31, 2, 0, 1, -1}, /* CRS */
>  
> -	{3,  4, 3, 0, 2}, /* MDIO */
> -	{3,  5, 1, 0, 2}, /* MDC */
> +	{3,  4, 3, 0, 2, -1}, /* MDIO */
> +	{3,  5, 1, 0, 2, -1}, /* MDC */
>  
> -	{0,  0, 0, 0, QE_IOP_TAB_END}, /* END of table */
> +	{0,  0, 0, 0, QE_IOP_TAB_END, -1}, /* END of table */
>  };
>  
>  int board_early_init_f(void)
> --- a/board/freescale/mpc832xemds/mpc832xemds.c	2008-03-28
> 01:49:12.000000000 +0200
> +++ b/board/freescale/mpc832xemds/mpc832xemds.c	2008-03-30
> 15:57:01.040395000 +0300
> @@ -31,47 +31,47 @@
>  
>  const qe_iop_conf_t qe_iop_conf_tab[] = {
>  	/* ETH3 */
> -	{1,  0, 1, 0, 1}, /* TxD0 */
> -	{1,  1, 1, 0, 1}, /* TxD1 */
> -	{1,  2, 1, 0, 1}, /* TxD2 */
> -	{1,  3, 1, 0, 1}, /* TxD3 */
> -	{1,  9, 1, 0, 1}, /* TxER */
> -	{1, 12, 1, 0, 1}, /* TxEN */
> -	{3, 24, 2, 0, 1}, /* TxCLK->CLK10 */
> -
> -	{1,  4, 2, 0, 1}, /* RxD0 */
> -	{1,  5, 2, 0, 1}, /* RxD1 */
> -	{1,  6, 2, 0, 1}, /* RxD2 */
> -	{1,  7, 2, 0, 1}, /* RxD3 */
> -	{1,  8, 2, 0, 1}, /* RxER */
> -	{1, 10, 2, 0, 1}, /* RxDV */
> -	{0, 13, 2, 0, 1}, /* RxCLK->CLK9 */
> -	{1, 11, 2, 0, 1}, /* COL */
> -	{1, 13, 2, 0, 1}, /* CRS */
> +	{1,  0, 1, 0, 1, -1}, /* TxD0 */
> +	{1,  1, 1, 0, 1, -1}, /* TxD1 */
> +	{1,  2, 1, 0, 1, -1}, /* TxD2 */
> +	{1,  3, 1, 0, 1, -1}, /* TxD3 */
> +	{1,  9, 1, 0, 1, -1}, /* TxER */
> +	{1, 12, 1, 0, 1, -1}, /* TxEN */
> +	{3, 24, 2, 0, 1, -1}, /* TxCLK->CLK10 */
> +
> +	{1,  4, 2, 0, 1, -1}, /* RxD0 */
> +	{1,  5, 2, 0, 1, -1}, /* RxD1 */
> +	{1,  6, 2, 0, 1, -1}, /* RxD2 */
> +	{1,  7, 2, 0, 1, -1}, /* RxD3 */
> +	{1,  8, 2, 0, 1, -1}, /* RxER */
> +	{1, 10, 2, 0, 1, -1}, /* RxDV */
> +	{0, 13, 2, 0, 1, -1}, /* RxCLK->CLK9 */
> +	{1, 11, 2, 0, 1, -1}, /* COL */
> +	{1, 13, 2, 0, 1, -1}, /* CRS */
>  
>  	/* ETH4 */
> -	{1, 18, 1, 0, 1}, /* TxD0 */
> -	{1, 19, 1, 0, 1}, /* TxD1 */
> -	{1, 20, 1, 0, 1}, /* TxD2 */
> -	{1, 21, 1, 0, 1}, /* TxD3 */
> -	{1, 27, 1, 0, 1}, /* TxER */
> -	{1, 30, 1, 0, 1}, /* TxEN */
> -	{3,  6, 2, 0, 1}, /* TxCLK->CLK8 */
> -
> -	{1, 22, 2, 0, 1}, /* RxD0 */
> -	{1, 23, 2, 0, 1}, /* RxD1 */
> -	{1, 24, 2, 0, 1}, /* RxD2 */
> -	{1, 25, 2, 0, 1}, /* RxD3 */
> -	{1, 26, 1, 0, 1}, /* RxER */
> -	{1, 28, 2, 0, 1}, /* Rx_DV */
> -	{3, 31, 2, 0, 1}, /* RxCLK->CLK7 */
> -	{1, 29, 2, 0, 1}, /* COL */
> -	{1, 31, 2, 0, 1}, /* CRS */
> +	{1, 18, 1, 0, 1, -1}, /* TxD0 */
> +	{1, 19, 1, 0, 1, -1}, /* TxD1 */
> +	{1, 20, 1, 0, 1, -1}, /* TxD2 */
> +	{1, 21, 1, 0, 1, -1}, /* TxD3 */
> +	{1, 27, 1, 0, 1, -1}, /* TxER */
> +	{1, 30, 1, 0, 1, -1}, /* TxEN */
> +	{3,  6, 2, 0, 1, -1}, /* TxCLK->CLK8 */
> +
> +	{1, 22, 2, 0, 1, -1}, /* RxD0 */
> +	{1, 23, 2, 0, 1, -1}, /* RxD1 */
> +	{1, 24, 2, 0, 1, -1}, /* RxD2 */
> +	{1, 25, 2, 0, 1, -1}, /* RxD3 */
> +	{1, 26, 1, 0, 1, -1}, /* RxER */
> +	{1, 28, 2, 0, 1, -1}, /* Rx_DV */
> +	{3, 31, 2, 0, 1, -1}, /* RxCLK->CLK7 */
> +	{1, 29, 2, 0, 1, -1}, /* COL */
> +	{1, 31, 2, 0, 1, -1}, /* CRS */
>  
> -	{3,  4, 3, 0, 2}, /* MDIO */
> -	{3,  5, 1, 0, 2}, /* MDC */
> +	{3,  4, 3, 0, 2, -1}, /* MDIO */
> +	{3,  5, 1, 0, 2, -1}, /* MDC */
>  
> -	{0,  0, 0, 0, QE_IOP_TAB_END}, /* END of table */
> +	{0,  0, 0, 0, QE_IOP_TAB_END, -1}, /* END of table */
>  };
>  
>  int board_early_init_f(void)
> --- a/board/freescale/mpc8360emds/mpc8360emds.c	2008-03-28
> 01:49:12.000000000 +0200
> +++ b/board/freescale/mpc8360emds/mpc8360emds.c	2008-03-30
> 15:57:20.682650000 +0300
> @@ -30,63 +30,63 @@
>  
>  const qe_iop_conf_t qe_iop_conf_tab[] = {
>  	/* GETH1 */
> -	{0,  3, 1, 0, 1}, /* TxD0 */
> -	{0,  4, 1, 0, 1}, /* TxD1 */
> -	{0,  5, 1, 0, 1}, /* TxD2 */
> -	{0,  6, 1, 0, 1}, /* TxD3 */
> -	{1,  6, 1, 0, 3}, /* TxD4 */
> -	{1,  7, 1, 0, 1}, /* TxD5 */
> -	{1,  9, 1, 0, 2}, /* TxD6 */
> -	{1, 10, 1, 0, 2}, /* TxD7 */
> -	{0,  9, 2, 0, 1}, /* RxD0 */
> -	{0, 10, 2, 0, 1}, /* RxD1 */
> -	{0, 11, 2, 0, 1}, /* RxD2 */
> -	{0, 12, 2, 0, 1}, /* RxD3 */
> -	{0, 13, 2, 0, 1}, /* RxD4 */
> -	{1,  1, 2, 0, 2}, /* RxD5 */
> -	{1,  0, 2, 0, 2}, /* RxD6 */
> -	{1,  4, 2, 0, 2}, /* RxD7 */
> -	{0,  7, 1, 0, 1}, /* TX_EN */
> -	{0,  8, 1, 0, 1}, /* TX_ER */
> -	{0, 15, 2, 0, 1}, /* RX_DV */
> -	{0, 16, 2, 0, 1}, /* RX_ER */
> -	{0,  0, 2, 0, 1}, /* RX_CLK */
> -	{2,  9, 1, 0, 3}, /* GTX_CLK - CLK10 */
> -	{2,  8, 2, 0, 1}, /* GTX125 - CLK9 */
> +	{0,  3, 1, 0, 1, -1}, /* TxD0 */
> +	{0,  4, 1, 0, 1, -1}, /* TxD1 */
> +	{0,  5, 1, 0, 1, -1}, /* TxD2 */
> +	{0,  6, 1, 0, 1, -1}, /* TxD3 */
> +	{1,  6, 1, 0, 3, -1}, /* TxD4 */
> +	{1,  7, 1, 0, 1, -1}, /* TxD5 */
> +	{1,  9, 1, 0, 2, -1}, /* TxD6 */
> +	{1, 10, 1, 0, 2, -1}, /* TxD7 */
> +	{0,  9, 2, 0, 1, -1}, /* RxD0 */
> +	{0, 10, 2, 0, 1, -1}, /* RxD1 */
> +	{0, 11, 2, 0, 1, -1}, /* RxD2 */
> +	{0, 12, 2, 0, 1, -1}, /* RxD3 */
> +	{0, 13, 2, 0, 1, -1}, /* RxD4 */
> +	{1,  1, 2, 0, 2, -1}, /* RxD5 */
> +	{1,  0, 2, 0, 2, -1}, /* RxD6 */
> +	{1,  4, 2, 0, 2, -1}, /* RxD7 */
> +	{0,  7, 1, 0, 1, -1}, /* TX_EN */
> +	{0,  8, 1, 0, 1, -1}, /* TX_ER */
> +	{0, 15, 2, 0, 1, -1}, /* RX_DV */
> +	{0, 16, 2, 0, 1, -1}, /* RX_ER */
> +	{0,  0, 2, 0, 1, -1}, /* RX_CLK */
> +	{2,  9, 1, 0, 3, -1}, /* GTX_CLK - CLK10 */
> +	{2,  8, 2, 0, 1, -1}, /* GTX125 - CLK9 */
>  	/* GETH2 */
> -	{0, 17, 1, 0, 1}, /* TxD0 */
> -	{0, 18, 1, 0, 1}, /* TxD1 */
> -	{0, 19, 1, 0, 1}, /* TxD2 */
> -	{0, 20, 1, 0, 1}, /* TxD3 */
> -	{1,  2, 1, 0, 1}, /* TxD4 */
> -	{1,  3, 1, 0, 2}, /* TxD5 */
> -	{1,  5, 1, 0, 3}, /* TxD6 */
> -	{1,  8, 1, 0, 3}, /* TxD7 */
> -	{0, 23, 2, 0, 1}, /* RxD0 */
> -	{0, 24, 2, 0, 1}, /* RxD1 */
> -	{0, 25, 2, 0, 1}, /* RxD2 */
> -	{0, 26, 2, 0, 1}, /* RxD3 */
> -	{0, 27, 2, 0, 1}, /* RxD4 */
> -	{1, 12, 2, 0, 2}, /* RxD5 */
> -	{1, 13, 2, 0, 3}, /* RxD6 */
> -	{1, 11, 2, 0, 2}, /* RxD7 */
> -	{0, 21, 1, 0, 1}, /* TX_EN */
> -	{0, 22, 1, 0, 1}, /* TX_ER */
> -	{0, 29, 2, 0, 1}, /* RX_DV */
> -	{0, 30, 2, 0, 1}, /* RX_ER */
> -	{0, 31, 2, 0, 1}, /* RX_CLK */
> -	{2,  2, 1, 0, 2}, /* GTX_CLK = CLK10 */
> -	{2,  3, 2, 0, 1}, /* GTX125 - CLK4 */
> -
> -	{0,  1, 3, 0, 2}, /* MDIO */
> -	{0,  2, 1, 0, 1}, /* MDC */
> -
> -	{5,  0, 1, 0, 2}, /* UART2_SOUT */
> -	{5,  1, 2, 0, 3}, /* UART2_CTS */
> -	{5,  2, 1, 0, 1}, /* UART2_RTS */
> -	{5,  3, 2, 0, 2}, /* UART2_SIN */
> +	{0, 17, 1, 0, 1, -1}, /* TxD0 */
> +	{0, 18, 1, 0, 1, -1}, /* TxD1 */
> +	{0, 19, 1, 0, 1, -1}, /* TxD2 */
> +	{0, 20, 1, 0, 1, -1}, /* TxD3 */
> +	{1,  2, 1, 0, 1, -1}, /* TxD4 */
> +	{1,  3, 1, 0, 2, -1}, /* TxD5 */
> +	{1,  5, 1, 0, 3, -1}, /* TxD6 */
> +	{1,  8, 1, 0, 3, -1}, /* TxD7 */
> +	{0, 23, 2, 0, 1, -1}, /* RxD0 */
> +	{0, 24, 2, 0, 1, -1}, /* RxD1 */
> +	{0, 25, 2, 0, 1, -1}, /* RxD2 */
> +	{0, 26, 2, 0, 1, -1}, /* RxD3 */
> +	{0, 27, 2, 0, 1, -1}, /* RxD4 */
> +	{1, 12, 2, 0, 2, -1}, /* RxD5 */
> +	{1, 13, 2, 0, 3, -1}, /* RxD6 */
> +	{1, 11, 2, 0, 2, -1}, /* RxD7 */
> +	{0, 21, 1, 0, 1, -1}, /* TX_EN */
> +	{0, 22, 1, 0, 1, -1}, /* TX_ER */
> +	{0, 29, 2, 0, 1, -1}, /* RX_DV */
> +	{0, 30, 2, 0, 1, -1}, /* RX_ER */
> +	{0, 31, 2, 0, 1, -1}, /* RX_CLK */
> +	{2,  2, 1, 0, 2, -1}, /* GTX_CLK = CLK10 */
> +	{2,  3, 2, 0, 1, -1}, /* GTX125 - CLK4 */
> +
> +	{0,  1, 3, 0, 2, -1}, /* MDIO */
> +	{0,  2, 1, 0, 1, -1}, /* MDC */
> +
> +	{5,  0, 1, 0, 2, -1}, /* UART2_SOUT */
> +	{5,  1, 2, 0, 3, -1}, /* UART2_CTS */
> +	{5,  2, 1, 0, 1, -1}, /* UART2_RTS */
> +	{5,  3, 2, 0, 2, -1}, /* UART2_SIN */
>  
> -	{0,  0, 0, 0, QE_IOP_TAB_END}, /* END of table */
> +	{0,  0, 0, 0, QE_IOP_TAB_END, -1}, /* END of table */
>  };
>  
>  int board_early_init_f(void)
> --- a/board/freescale/mpc8360erdk/mpc8360erdk.c	2008-03-28
> 01:49:12.000000000 +0200
> +++ b/board/freescale/mpc8360erdk/mpc8360erdk.c	2008-03-30
> 15:57:40.425878000 +0300
> @@ -26,165 +26,165 @@
>  
>  const qe_iop_conf_t qe_iop_conf_tab[] = {
>  	/* MDIO */
> -	{0,  1, 3, 0, 2}, /* MDIO */
> -	{0,  2, 1, 0, 1}, /* MDC */
> +	{0,  1, 3, 0, 2, -1}, /* MDIO */
> +	{0,  2, 1, 0, 1, -1}, /* MDC */
>  
>  	/* UCC1 - UEC (Gigabit) */
> -	{0,  3, 1, 0, 1}, /* TxD0 */
> -	{0,  4, 1, 0, 1}, /* TxD1 */
> -	{0,  5, 1, 0, 1}, /* TxD2 */
> -	{0,  6, 1, 0, 1}, /* TxD3 */
> -	{0,  9, 2, 0, 1}, /* RxD0 */
> -	{0, 10, 2, 0, 1}, /* RxD1 */
> -	{0, 11, 2, 0, 1}, /* RxD2 */
> -	{0, 12, 2, 0, 1}, /* RxD3 */
> -	{0,  7, 1, 0, 1}, /* TX_EN */
> -	{0,  8, 1, 0, 1}, /* TX_ER */
> -	{0, 15, 2, 0, 1}, /* RX_DV */
> -	{0,  0, 2, 0, 1}, /* RX_CLK */
> -	{2,  9, 1, 0, 3}, /* GTX_CLK - CLK10 */
> -	{2,  8, 2, 0, 1}, /* GTX125 - CLK9 */
> +	{0,  3, 1, 0, 1, -1}, /* TxD0 */
> +	{0,  4, 1, 0, 1, -1}, /* TxD1 */
> +	{0,  5, 1, 0, 1, -1}, /* TxD2 */
> +	{0,  6, 1, 0, 1, -1}, /* TxD3 */
> +	{0,  9, 2, 0, 1, -1}, /* RxD0 */
> +	{0, 10, 2, 0, 1, -1}, /* RxD1 */
> +	{0, 11, 2, 0, 1, -1}, /* RxD2 */
> +	{0, 12, 2, 0, 1, -1}, /* RxD3 */
> +	{0,  7, 1, 0, 1, -1}, /* TX_EN */
> +	{0,  8, 1, 0, 1, -1}, /* TX_ER */
> +	{0, 15, 2, 0, 1, -1}, /* RX_DV */
> +	{0,  0, 2, 0, 1, -1}, /* RX_CLK */
> +	{2,  9, 1, 0, 3, -1}, /* GTX_CLK - CLK10 */
> +	{2,  8, 2, 0, 1, -1}, /* GTX125 - CLK9 */
>  
>  	/* UCC2 - UEC (Gigabit) */
> -	{0, 17, 1, 0, 1}, /* TxD0 */
> -	{0, 18, 1, 0, 1}, /* TxD1 */
> -	{0, 19, 1, 0, 1}, /* TxD2 */
> -	{0, 20, 1, 0, 1}, /* TxD3 */
> -	{0, 23, 2, 0, 1}, /* RxD0 */
> -	{0, 24, 2, 0, 1}, /* RxD1 */
> -	{0, 25, 2, 0, 1}, /* RxD2 */
> -	{0, 26, 2, 0, 1}, /* RxD3 */
> -	{0, 21, 1, 0, 1}, /* TX_EN */
> -	{0, 22, 1, 0, 1}, /* TX_ER */
> -	{0, 29, 2, 0, 1}, /* RX_DV */
> -	{0, 31, 2, 0, 1}, /* RX_CLK */
> -	{2,  2, 1, 0, 2}, /* GTX_CLK - CLK10 */
> -	{2,  3, 2, 0, 1}, /* GTX125 - CLK4 */
> +	{0, 17, 1, 0, 1, -1}, /* TxD0 */
> +	{0, 18, 1, 0, 1, -1}, /* TxD1 */
> +	{0, 19, 1, 0, 1, -1}, /* TxD2 */
> +	{0, 20, 1, 0, 1, -1}, /* TxD3 */
> +	{0, 23, 2, 0, 1, -1}, /* RxD0 */
> +	{0, 24, 2, 0, 1, -1}, /* RxD1 */
> +	{0, 25, 2, 0, 1, -1}, /* RxD2 */
> +	{0, 26, 2, 0, 1, -1}, /* RxD3 */
> +	{0, 21, 1, 0, 1, -1}, /* TX_EN */
> +	{0, 22, 1, 0, 1, -1}, /* TX_ER */
> +	{0, 29, 2, 0, 1, -1}, /* RX_DV */
> +	{0, 31, 2, 0, 1, -1}, /* RX_CLK */
> +	{2,  2, 1, 0, 2, -1}, /* GTX_CLK - CLK10 */
> +	{2,  3, 2, 0, 1, -1}, /* GTX125 - CLK4 */
>  
>  	/* UCC7 - UEC */
> -	{4,  0, 1, 0, 1}, /* TxD0 */
> -	{4,  1, 1, 0, 1}, /* TxD1 */
> -	{4,  2, 1, 0, 1}, /* TxD2 */
> -	{4,  3, 1, 0, 1}, /* TxD3 */
> -	{4,  6, 2, 0, 1}, /* RxD0 */
> -	{4,  7, 2, 0, 1}, /* RxD1 */
> -	{4,  8, 2, 0, 1}, /* RxD2 */
> -	{4,  9, 2, 0, 1}, /* RxD3 */
> -	{4,  4, 1, 0, 1}, /* TX_EN */
> -	{4,  5, 1, 0, 1}, /* TX_ER */
> -	{4, 12, 2, 0, 1}, /* RX_DV */
> -	{4, 13, 2, 0, 1}, /* RX_ER */
> -	{4, 10, 2, 0, 1}, /* COL */
> -	{4, 11, 2, 0, 1}, /* CRS */
> -	{2, 18, 2, 0, 1}, /* TX_CLK - CLK19 */
> -	{2, 19, 2, 0, 1}, /* RX_CLK - CLK20 */
> +	{4,  0, 1, 0, 1, -1}, /* TxD0 */
> +	{4,  1, 1, 0, 1, -1}, /* TxD1 */
> +	{4,  2, 1, 0, 1, -1}, /* TxD2 */
> +	{4,  3, 1, 0, 1, -1}, /* TxD3 */
> +	{4,  6, 2, 0, 1, -1}, /* RxD0 */
> +	{4,  7, 2, 0, 1, -1}, /* RxD1 */
> +	{4,  8, 2, 0, 1, -1}, /* RxD2 */
> +	{4,  9, 2, 0, 1, -1}, /* RxD3 */
> +	{4,  4, 1, 0, 1, -1}, /* TX_EN */
> +	{4,  5, 1, 0, 1, -1}, /* TX_ER */
> +	{4, 12, 2, 0, 1, -1}, /* RX_DV */
> +	{4, 13, 2, 0, 1, -1}, /* RX_ER */
> +	{4, 10, 2, 0, 1, -1}, /* COL */
> +	{4, 11, 2, 0, 1, -1}, /* CRS */
> +	{2, 18, 2, 0, 1, -1}, /* TX_CLK - CLK19 */
> +	{2, 19, 2, 0, 1, -1}, /* RX_CLK - CLK20 */
>  
>  	/* UCC4 - UEC */
> -	{1, 14, 1, 0, 1}, /* TxD0 */
> -	{1, 15, 1, 0, 1}, /* TxD1 */
> -	{1, 16, 1, 0, 1}, /* TxD2 */
> -	{1, 17, 1, 0, 1}, /* TxD3 */
> -	{1, 20, 2, 0, 1}, /* RxD0 */
> -	{1, 21, 2, 0, 1}, /* RxD1 */
> -	{1, 22, 2, 0, 1}, /* RxD2 */
> -	{1, 23, 2, 0, 1}, /* RxD3 */
> -	{1, 18, 1, 0, 1}, /* TX_EN */
> -	{1, 19, 1, 0, 2}, /* TX_ER */
> -	{1, 26, 2, 0, 1}, /* RX_DV */
> -	{1, 27, 2, 0, 1}, /* RX_ER */
> -	{1, 24, 2, 0, 1}, /* COL */
> -	{1, 25, 2, 0, 1}, /* CRS */
> -	{2,  6, 2, 0, 1}, /* TX_CLK - CLK7 */
> -	{2,  7, 2, 0, 1}, /* RX_CLK - CLK8 */
> +	{1, 14, 1, 0, 1, -1}, /* TxD0 */
> +	{1, 15, 1, 0, 1, -1}, /* TxD1 */
> +	{1, 16, 1, 0, 1, -1}, /* TxD2 */
> +	{1, 17, 1, 0, 1, -1}, /* TxD3 */
> +	{1, 20, 2, 0, 1, -1}, /* RxD0 */
> +	{1, 21, 2, 0, 1, -1}, /* RxD1 */
> +	{1, 22, 2, 0, 1, -1}, /* RxD2 */
> +	{1, 23, 2, 0, 1, -1}, /* RxD3 */
> +	{1, 18, 1, 0, 1, -1}, /* TX_EN */
> +	{1, 19, 1, 0, 2, -1}, /* TX_ER */
> +	{1, 26, 2, 0, 1, -1}, /* RX_DV */
> +	{1, 27, 2, 0, 1, -1}, /* RX_ER */
> +	{1, 24, 2, 0, 1, -1}, /* COL */
> +	{1, 25, 2, 0, 1, -1}, /* CRS */
> +	{2,  6, 2, 0, 1, -1}, /* TX_CLK - CLK7 */
> +	{2,  7, 2, 0, 1, -1}, /* RX_CLK - CLK8 */
>  
>  	/* PCI1 */
> -	{5,  4, 2, 0, 3}, /* PCI_M66EN */
> -	{5,  5, 1, 0, 3}, /* PCI_INTA */
> -	{5,  6, 1, 0, 3}, /* PCI_RSTO */
> -	{5,  7, 3, 0, 3}, /* PCI_C_BE0 */
> -	{5,  8, 3, 0, 3}, /* PCI_C_BE1 */
> -	{5,  9, 3, 0, 3}, /* PCI_C_BE2 */
> -	{5, 10, 3, 0, 3}, /* PCI_C_BE3 */
> -	{5, 11, 3, 0, 3}, /* PCI_PAR */
> -	{5, 12, 3, 0, 3}, /* PCI_FRAME */
> -	{5, 13, 3, 0, 3}, /* PCI_TRDY */
> -	{5, 14, 3, 0, 3}, /* PCI_IRDY */
> -	{5, 15, 3, 0, 3}, /* PCI_STOP */
> -	{5, 16, 3, 0, 3}, /* PCI_DEVSEL */
> -	{5, 17, 0, 0, 0}, /* PCI_IDSEL */
> -	{5, 18, 3, 0, 3}, /* PCI_SERR */
> -	{5, 19, 3, 0, 3}, /* PCI_PERR */
> -	{5, 20, 3, 0, 3}, /* PCI_REQ0 */
> -	{5, 21, 2, 0, 3}, /* PCI_REQ1 */
> -	{5, 22, 2, 0, 3}, /* PCI_GNT2 */
> -	{5, 23, 3, 0, 3}, /* PCI_GNT0 */
> -	{5, 24, 1, 0, 3}, /* PCI_GNT1 */
> -	{5, 25, 1, 0, 3}, /* PCI_GNT2 */
> -	{5, 26, 0, 0, 0}, /* PCI_CLK0 */
> -	{5, 27, 0, 0, 0}, /* PCI_CLK1 */
> -	{5, 28, 0, 0, 0}, /* PCI_CLK2 */
> -	{5, 29, 0, 0, 3}, /* PCI_SYNC_OUT */
> -	{6,  0, 3, 0, 3}, /* PCI_AD0 */
> -	{6,  1, 3, 0, 3}, /* PCI_AD1 */
> -	{6,  2, 3, 0, 3}, /* PCI_AD2 */
> -	{6,  3, 3, 0, 3}, /* PCI_AD3 */
> -	{6,  4, 3, 0, 3}, /* PCI_AD4 */
> -	{6,  5, 3, 0, 3}, /* PCI_AD5 */
> -	{6,  6, 3, 0, 3}, /* PCI_AD6 */
> -	{6,  7, 3, 0, 3}, /* PCI_AD7 */
> -	{6,  8, 3, 0, 3}, /* PCI_AD8 */
> -	{6,  9, 3, 0, 3}, /* PCI_AD9 */
> -	{6, 10, 3, 0, 3}, /* PCI_AD10 */
> -	{6, 11, 3, 0, 3}, /* PCI_AD11 */
> -	{6, 12, 3, 0, 3}, /* PCI_AD12 */
> -	{6, 13, 3, 0, 3}, /* PCI_AD13 */
> -	{6, 14, 3, 0, 3}, /* PCI_AD14 */
> -	{6, 15, 3, 0, 3}, /* PCI_AD15 */
> -	{6, 16, 3, 0, 3}, /* PCI_AD16 */
> -	{6, 17, 3, 0, 3}, /* PCI_AD17 */
> -	{6, 18, 3, 0, 3}, /* PCI_AD18 */
> -	{6, 19, 3, 0, 3}, /* PCI_AD19 */
> -	{6, 20, 3, 0, 3}, /* PCI_AD20 */
> -	{6, 21, 3, 0, 3}, /* PCI_AD21 */
> -	{6, 22, 3, 0, 3}, /* PCI_AD22 */
> -	{6, 23, 3, 0, 3}, /* PCI_AD23 */
> -	{6, 24, 3, 0, 3}, /* PCI_AD24 */
> -	{6, 25, 3, 0, 3}, /* PCI_AD25 */
> -	{6, 26, 3, 0, 3}, /* PCI_AD26 */
> -	{6, 27, 3, 0, 3}, /* PCI_AD27 */
> -	{6, 28, 3, 0, 3}, /* PCI_AD28 */
> -	{6, 29, 3, 0, 3}, /* PCI_AD29 */
> -	{6, 30, 3, 0, 3}, /* PCI_AD30 */
> -	{6, 31, 3, 0, 3}, /* PCI_AD31 */
> +	{5,  4, 2, 0, 3, -1}, /* PCI_M66EN */
> +	{5,  5, 1, 0, 3, -1}, /* PCI_INTA */
> +	{5,  6, 1, 0, 3, -1}, /* PCI_RSTO */
> +	{5,  7, 3, 0, 3, -1}, /* PCI_C_BE0 */
> +	{5,  8, 3, 0, 3, -1}, /* PCI_C_BE1 */
> +	{5,  9, 3, 0, 3, -1}, /* PCI_C_BE2 */
> +	{5, 10, 3, 0, 3, -1}, /* PCI_C_BE3 */
> +	{5, 11, 3, 0, 3, -1}, /* PCI_PAR */
> +	{5, 12, 3, 0, 3, -1}, /* PCI_FRAME */
> +	{5, 13, 3, 0, 3, -1}, /* PCI_TRDY */
> +	{5, 14, 3, 0, 3, -1}, /* PCI_IRDY */
> +	{5, 15, 3, 0, 3, -1}, /* PCI_STOP */
> +	{5, 16, 3, 0, 3, -1}, /* PCI_DEVSEL */
> +	{5, 17, 0, 0, 0, -1}, /* PCI_IDSEL */
> +	{5, 18, 3, 0, 3, -1}, /* PCI_SERR */
> +	{5, 19, 3, 0, 3, -1}, /* PCI_PERR */
> +	{5, 20, 3, 0, 3, -1}, /* PCI_REQ0 */
> +	{5, 21, 2, 0, 3, -1}, /* PCI_REQ1 */
> +	{5, 22, 2, 0, 3, -1}, /* PCI_GNT2 */
> +	{5, 23, 3, 0, 3, -1}, /* PCI_GNT0 */
> +	{5, 24, 1, 0, 3, -1}, /* PCI_GNT1 */
> +	{5, 25, 1, 0, 3, -1}, /* PCI_GNT2 */
> +	{5, 26, 0, 0, 0, -1}, /* PCI_CLK0 */
> +	{5, 27, 0, 0, 0, -1}, /* PCI_CLK1 */
> +	{5, 28, 0, 0, 0, -1}, /* PCI_CLK2 */
> +	{5, 29, 0, 0, 3, -1}, /* PCI_SYNC_OUT */
> +	{6,  0, 3, 0, 3, -1}, /* PCI_AD0 */
> +	{6,  1, 3, 0, 3, -1}, /* PCI_AD1 */
> +	{6,  2, 3, 0, 3, -1}, /* PCI_AD2 */
> +	{6,  3, 3, 0, 3, -1}, /* PCI_AD3 */
> +	{6,  4, 3, 0, 3, -1}, /* PCI_AD4 */
> +	{6,  5, 3, 0, 3, -1}, /* PCI_AD5 */
> +	{6,  6, 3, 0, 3, -1}, /* PCI_AD6 */
> +	{6,  7, 3, 0, 3, -1}, /* PCI_AD7 */
> +	{6,  8, 3, 0, 3, -1}, /* PCI_AD8 */
> +	{6,  9, 3, 0, 3, -1}, /* PCI_AD9 */
> +	{6, 10, 3, 0, 3, -1}, /* PCI_AD10 */
> +	{6, 11, 3, 0, 3, -1}, /* PCI_AD11 */
> +	{6, 12, 3, 0, 3, -1}, /* PCI_AD12 */
> +	{6, 13, 3, 0, 3, -1}, /* PCI_AD13 */
> +	{6, 14, 3, 0, 3, -1}, /* PCI_AD14 */
> +	{6, 15, 3, 0, 3, -1}, /* PCI_AD15 */
> +	{6, 16, 3, 0, 3, -1}, /* PCI_AD16 */
> +	{6, 17, 3, 0, 3, -1}, /* PCI_AD17 */
> +	{6, 18, 3, 0, 3, -1}, /* PCI_AD18 */
> +	{6, 19, 3, 0, 3, -1}, /* PCI_AD19 */
> +	{6, 20, 3, 0, 3, -1}, /* PCI_AD20 */
> +	{6, 21, 3, 0, 3, -1}, /* PCI_AD21 */
> +	{6, 22, 3, 0, 3, -1}, /* PCI_AD22 */
> +	{6, 23, 3, 0, 3, -1}, /* PCI_AD23 */
> +	{6, 24, 3, 0, 3, -1}, /* PCI_AD24 */
> +	{6, 25, 3, 0, 3, -1}, /* PCI_AD25 */
> +	{6, 26, 3, 0, 3, -1}, /* PCI_AD26 */
> +	{6, 27, 3, 0, 3, -1}, /* PCI_AD27 */
> +	{6, 28, 3, 0, 3, -1}, /* PCI_AD28 */
> +	{6, 29, 3, 0, 3, -1}, /* PCI_AD29 */
> +	{6, 30, 3, 0, 3, -1}, /* PCI_AD30 */
> +	{6, 31, 3, 0, 3, -1}, /* PCI_AD31 */
>  
>  	/* NAND */
> -	{4, 18, 2, 0, 0}, /* NAND_RYnBY */
> +	{4, 18, 2, 0, 0, -1}, /* NAND_RYnBY */
>  
>  	/* DUART - UART2 */
> -	{5,  0, 1, 0, 2}, /* UART2_SOUT */
> -	{5,  2, 1, 0, 1}, /* UART2_RTS */
> -	{5,  3, 2, 0, 2}, /* UART2_SIN */
> -	{5,  1, 2, 0, 3}, /* UART2_CTS */
> +	{5,  0, 1, 0, 2, -1}, /* UART2_SOUT */
> +	{5,  2, 1, 0, 1, -1}, /* UART2_RTS */
> +	{5,  3, 2, 0, 2, -1}, /* UART2_SIN */
> +	{5,  1, 2, 0, 3, -1}, /* UART2_CTS */
>  
>  	/* UCC5 - UART3 */
> -	{3,  0, 1, 0, 1}, /* UART3_TX */
> -	{3,  4, 1, 0, 1}, /* UART3_RTS */
> -	{3,  6, 2, 0, 1}, /* UART3_RX */
> -	{3, 12, 2, 0, 0}, /* UART3_CTS */
> -	{3, 13, 2, 0, 0}, /* UCC5_CD */
> +	{3,  0, 1, 0, 1, -1}, /* UART3_TX */
> +	{3,  4, 1, 0, 1, -1}, /* UART3_RTS */
> +	{3,  6, 2, 0, 1, -1}, /* UART3_RX */
> +	{3, 12, 2, 0, 0, -1}, /* UART3_CTS */
> +	{3, 13, 2, 0, 0, -1}, /* UCC5_CD */
>  
>  	/* UCC6 - UART4 */
> -	{3, 14, 1, 0, 1}, /* UART4_TX */
> -	{3, 18, 1, 0, 1}, /* UART4_RTS */
> -	{3, 20, 2, 0, 1}, /* UART4_RX */
> -	{3, 26, 2, 0, 0}, /* UART4_CTS */
> -	{3, 27, 2, 0, 0}, /* UCC6_CD */
> +	{3, 14, 1, 0, 1, -1}, /* UART4_TX */
> +	{3, 18, 1, 0, 1, -1}, /* UART4_RTS */
> +	{3, 20, 2, 0, 1, -1}, /* UART4_RX */
> +	{3, 26, 2, 0, 0, -1}, /* UART4_CTS */
> +	{3, 27, 2, 0, 0, -1}, /* UCC6_CD */
>  
>  	/* Fujitsu MB86277 (MINT) graphics controller */
> -	{0, 30, 1, 0, 0}, /* nSRESET_GRAPHICS */
> -	{1,  5, 1, 0, 0}, /* nXRST_GRAPHICS */
> -	{1,  7, 1, 0, 0}, /* LVDS_BKLT_CTR */
> -	{2, 16, 1, 0, 0}, /* LVDS_BKLT_EN */
> +	{0, 30, 1, 0, 0, -1}, /* nSRESET_GRAPHICS */
> +	{1,  5, 1, 0, 0, -1}, /* nXRST_GRAPHICS */
> +	{1,  7, 1, 0, 0, -1}, /* LVDS_BKLT_CTR */
> +	{2, 16, 1, 0, 0, -1}, /* LVDS_BKLT_EN */
>  
>  	/* AD7843 ADC/Touchscreen controller */
>  	{4, 14, 1, 0, 0}, /* SPI_nCS0 */
> @@ -204,7 +204,7 @@ const qe_iop_conf_t qe_iop_conf_tab[] = 
>  	{4, 21, 1, 0, 0}, /* SUSPND */
>  
>  	/* END of table */
> -	{0,  0, 0, 0, QE_IOP_TAB_END},
> +	{0,  0, 0, 0, QE_IOP_TAB_END, -1},
>  };
>  
>  int board_early_init_f(void)
> --- a/board/freescale/mpc8568mds/mpc8568mds.c	2008-03-28 01:49:12.000000000
> +0200
> +++ b/board/freescale/mpc8568mds/mpc8568mds.c	2008-03-30 15:57:57.592361000
> +0300
> @@ -37,64 +37,64 @@
>  
>  const qe_iop_conf_t qe_iop_conf_tab[] = {
>  	/* GETH1 */
> -	{4, 10, 1, 0, 2}, /* TxD0 */
> -	{4,  9, 1, 0, 2}, /* TxD1 */
> -	{4,  8, 1, 0, 2}, /* TxD2 */
> -	{4,  7, 1, 0, 2}, /* TxD3 */
> -	{4, 23, 1, 0, 2}, /* TxD4 */
> -	{4, 22, 1, 0, 2}, /* TxD5 */
> -	{4, 21, 1, 0, 2}, /* TxD6 */
> -	{4, 20, 1, 0, 2}, /* TxD7 */
> -	{4, 15, 2, 0, 2}, /* RxD0 */
> -	{4, 14, 2, 0, 2}, /* RxD1 */
> -	{4, 13, 2, 0, 2}, /* RxD2 */
> -	{4, 12, 2, 0, 2}, /* RxD3 */
> -	{4, 29, 2, 0, 2}, /* RxD4 */
> -	{4, 28, 2, 0, 2}, /* RxD5 */
> -	{4, 27, 2, 0, 2}, /* RxD6 */
> -	{4, 26, 2, 0, 2}, /* RxD7 */
> -	{4, 11, 1, 0, 2}, /* TX_EN */
> -	{4, 24, 1, 0, 2}, /* TX_ER */
> -	{4, 16, 2, 0, 2}, /* RX_DV */
> -	{4, 30, 2, 0, 2}, /* RX_ER */
> -	{4, 17, 2, 0, 2}, /* RX_CLK */
> -	{4, 19, 1, 0, 2}, /* GTX_CLK */
> -	{1, 31, 2, 0, 3}, /* GTX125 */
> +	{4, 10, 1, 0, 2, -1}, /* TxD0 */
> +	{4,  9, 1, 0, 2, -1}, /* TxD1 */
> +	{4,  8, 1, 0, 2, -1}, /* TxD2 */
> +	{4,  7, 1, 0, 2, -1}, /* TxD3 */
> +	{4, 23, 1, 0, 2, -1}, /* TxD4 */
> +	{4, 22, 1, 0, 2, -1}, /* TxD5 */
> +	{4, 21, 1, 0, 2, -1}, /* TxD6 */
> +	{4, 20, 1, 0, 2, -1}, /* TxD7 */
> +	{4, 15, 2, 0, 2, -1}, /* RxD0 */
> +	{4, 14, 2, 0, 2, -1}, /* RxD1 */
> +	{4, 13, 2, 0, 2, -1}, /* RxD2 */
> +	{4, 12, 2, 0, 2, -1}, /* RxD3 */
> +	{4, 29, 2, 0, 2, -1}, /* RxD4 */
> +	{4, 28, 2, 0, 2, -1}, /* RxD5 */
> +	{4, 27, 2, 0, 2, -1}, /* RxD6 */
> +	{4, 26, 2, 0, 2, -1}, /* RxD7 */
> +	{4, 11, 1, 0, 2, -1}, /* TX_EN */
> +	{4, 24, 1, 0, 2, -1}, /* TX_ER */
> +	{4, 16, 2, 0, 2, -1}, /* RX_DV */
> +	{4, 30, 2, 0, 2, -1}, /* RX_ER */
> +	{4, 17, 2, 0, 2, -1}, /* RX_CLK */
> +	{4, 19, 1, 0, 2, -1}, /* GTX_CLK */
> +	{1, 31, 2, 0, 3, -1}, /* GTX125 */
>  
>  	/* GETH2 */
> -	{5, 10, 1, 0, 2}, /* TxD0 */
> -	{5,  9, 1, 0, 2}, /* TxD1 */
> -	{5,  8, 1, 0, 2}, /* TxD2 */
> -	{5,  7, 1, 0, 2}, /* TxD3 */
> -	{5, 23, 1, 0, 2}, /* TxD4 */
> -	{5, 22, 1, 0, 2}, /* TxD5 */
> -	{5, 21, 1, 0, 2}, /* TxD6 */
> -	{5, 20, 1, 0, 2}, /* TxD7 */
> -	{5, 15, 2, 0, 2}, /* RxD0 */
> -	{5, 14, 2, 0, 2}, /* RxD1 */
> -	{5, 13, 2, 0, 2}, /* RxD2 */
> -	{5, 12, 2, 0, 2}, /* RxD3 */
> -	{5, 29, 2, 0, 2}, /* RxD4 */
> -	{5, 28, 2, 0, 2}, /* RxD5 */
> -	{5, 27, 2, 0, 3}, /* RxD6 */
> -	{5, 26, 2, 0, 2}, /* RxD7 */
> -	{5, 11, 1, 0, 2}, /* TX_EN */
> -	{5, 24, 1, 0, 2}, /* TX_ER */
> -	{5, 16, 2, 0, 2}, /* RX_DV */
> -	{5, 30, 2, 0, 2}, /* RX_ER */
> -	{5, 17, 2, 0, 2}, /* RX_CLK */
> -	{5, 19, 1, 0, 2}, /* GTX_CLK */
> -	{1, 31, 2, 0, 3}, /* GTX125 */
> -	{4,  6, 3, 0, 2}, /* MDIO */
> -	{4,  5, 1, 0, 2}, /* MDC */
> +	{5, 10, 1, 0, 2, -1}, /* TxD0 */
> +	{5,  9, 1, 0, 2, -1}, /* TxD1 */
> +	{5,  8, 1, 0, 2, -1}, /* TxD2 */
> +	{5,  7, 1, 0, 2, -1}, /* TxD3 */
> +	{5, 23, 1, 0, 2, -1}, /* TxD4 */
> +	{5, 22, 1, 0, 2, -1}, /* TxD5 */
> +	{5, 21, 1, 0, 2, -1}, /* TxD6 */
> +	{5, 20, 1, 0, 2, -1}, /* TxD7 */
> +	{5, 15, 2, 0, 2, -1}, /* RxD0 */
> +	{5, 14, 2, 0, 2, -1}, /* RxD1 */
> +	{5, 13, 2, 0, 2, -1}, /* RxD2 */
> +	{5, 12, 2, 0, 2, -1}, /* RxD3 */
> +	{5, 29, 2, 0, 2, -1}, /* RxD4 */
> +	{5, 28, 2, 0, 2, -1}, /* RxD5 */
> +	{5, 27, 2, 0, 3, -1}, /* RxD6 */
> +	{5, 26, 2, 0, 2, -1}, /* RxD7 */
> +	{5, 11, 1, 0, 2, -1}, /* TX_EN */
> +	{5, 24, 1, 0, 2, -1}, /* TX_ER */
> +	{5, 16, 2, 0, 2, -1}, /* RX_DV */
> +	{5, 30, 2, 0, 2, -1}, /* RX_ER */
> +	{5, 17, 2, 0, 2, -1}, /* RX_CLK */
> +	{5, 19, 1, 0, 2, -1}, /* GTX_CLK */
> +	{1, 31, 2, 0, 3, -1}, /* GTX125 */
> +	{4,  6, 3, 0, 2, -1}, /* MDIO */
> +	{4,  5, 1, 0, 2, -1}, /* MDC */
>  
>  	/* UART1 */
> -	{2, 0, 1, 0, 2}, /* UART_SOUT1 */
> -	{2, 1, 1, 0, 2}, /* UART_RTS1 */
> -	{2, 2, 2, 0, 2}, /* UART_CTS1 */
> -	{2, 3, 2, 0, 2}, /* UART_SIN1 */
> +	{2, 0, 1, 0, 2, -1}, /* UART_SOUT1 */
> +	{2, 1, 1, 0, 2, -1}, /* UART_RTS1 */
> +	{2, 2, 2, 0, 2, -1}, /* UART_CTS1 */
> +	{2, 3, 2, 0, 2, -1}, /* UART_SIN1 */
>  
> -	{0,  0, 0, 0, QE_IOP_TAB_END}, /* END of table */
> +	{0,  0, 0, 0, QE_IOP_TAB_END, -1}, /* END of table */
>  };
>  
>  
> --- a/common/Makefile	2008-03-28 01:49:12.000000000 +0200
+++ b/common/Makefile	2008-03-30 15:59:57.944754000 +0300
> @@ -81,6 +81,7 @@ COBJS-$(CONFIG_CMD_NET) += cmd_net.o
>  COBJS-y += cmd_nvedit.o
>  COBJS-y += cmd_onenand.o
>  COBJS-$(CONFIG_CMD_OTP) += cmd_otp.o
> +COBJS-$(CONFIG_CMD_PARIO) += cmd_pario.o
>  ifdef CONFIG_PCI
>  COBJS-$(CONFIG_CMD_PCI) += cmd_pci.o
>  endif
> 0a1,85
> --- /dev/null	2008-03-30 10:13:32.378222985 +0300
> +++ b/common/cmd_pario.c	2008-03-30 16:00:43.124433000 +0300
> @@ -0,0 +1,85 @@
> +/*
> + * Copyright 2008 ECI Telecommunication.
> + *
> + * (C) Copyright 2008 David Saada <david.saada at ecitele.com>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <common.h>
> +#include <command.h>
> +#include <ioports.h>
> +
> +int do_pario (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
> +{
> +	char op;
> +	int	port, pin, data;
> +	static char	last_op;
> +	static int last_port, last_pin, last_data;
> +
> +	/*
> +	 * We use the last specified parameters, unless new ones are
> +	 * entered.
> +	 */
> +	op = last_op;
> +	port = last_port;
> +	pin = last_pin;
> +	data = last_data;
> +
> +	if ((flag & CMD_FLAG_REPEAT) == 0) {
> +		op = argv[1][0];
> +
> +		if (argc >= 3)
> +			port = simple_strtoul (argv[2], NULL, 10);
> +		if (argc >= 4)
> +			pin = simple_strtoul (argv[3], NULL, 10);
> +		if (argc >= 5)
> +			data = simple_strtoul (argv[4], NULL, 10);
> +	}
> +
> +	if (op == 'r') {
> +		qe_read_iopin(port ,pin ,&data);
> +		printf("%d\n", data);
> +	} else if (op == 'w') {
> +		qe_write_iopin(port ,pin ,data);
> +	} else {
> +		printf("Usage:\n%s\n", cmdtp->usage);
> +		return 1;
> +	}
> +
> +	/*
> +	 * Save the parameters for repeats.
> +	 */
> +	last_op = op;
> +	last_port = port;
> +	last_pin = pin;
> +	last_data = data;
> +
> +	return 0;
> +}
> +
> +/***************************************************/
> +
> +U_BOOT_CMD(
> +	pario,	5,	1,	do_pario,
> +	"pario     - Parallel I/O utility commands\n",
> +	"read   <port> <pin>        - read from port <port> (0-5) pin <pin>
> (0-31)\n"
> +	"pario write  <port> <pin> <data> - write to port  <port> (0-5) pin <pin>
> (0-31)\n"
> +);
> +
> 
> -- 
> View this message in context: http://www.nabble.com/-PATCH--resubmit--QE-IO%3A-Add-initial-data-to-pin-configuration-%2B-read-write-functions-tp16381440p16381440.html
> Sent from the Uboot - Users mailing list archive at Nabble.com.
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH] Allow use of ARCH=powerpc when building
In-Reply-To: Your message of "Mon, 31 Mar 2008 11:59:27 CDT."
	<Pine.LNX.4.64.0803311158200.4556@blarg.am.freescale.net>
Message-ID: <20080414063340.B0C80248AB@gemini.denx.de>

In message <Pine.LNX.4.64.0803311158200.4556 at blarg.am.freescale.net> you wrote:
> The linux kernel is now mostly ARCH=powerpc, so to make life easier
> allow use to use ARCH=powerpc and convert it to ARCH=ppc.
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
> 
> Identical to the patch 'Allow use to use ARCH=powerpc when building', but
> this one the subject makes a bit more sense.

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: wd at denx.de
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev



From wd at denx.de  Mon Apr 14 08:33:40 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 08:33:40 +0200
Subject: [U-Boot-Users] [PATCH] Add apollon board MAINTAINERS entry
In-Reply-To: Your message of "Mon, 31 Mar 2008 10:40:54 +0900."
	<20080331014054.GA30874@party>
Message-ID: <20080414063340.9C2AD248BD@gemini.denx.de>

In message <20080331014054.GA30874 at party> you wrote:
> Add apollon board MAINTAINERS entry
> 
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> ---
> diff --git a/MAINTAINERS b/MAINTAINERS

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: wd at denx.de
A consultant is a person who borrows your watch, tells you what  time
it is, pockets the watch, and sends you a bill for it.



From monstr at seznam.cz  Mon Apr 14 08:53:58 2008
From: monstr at seznam.cz (Michal Simek)
Date: Mon, 14 Apr 2008 08:53:58 +0200
Subject: [U-Boot-Users] [PATCH 04/13] microblaze: add Emaclite ethernet
	driver
In-Reply-To: <20080414010936.C0F24248B9@gemini.denx.de>
References: <20080414010936.C0F24248B9@gemini.denx.de>
Message-ID: <4802FF86.8010504@seznam.cz>

Hi Wolfgang,

this code was sent to mailing list I think twice. I think Grant reviewed this
code once, didn't he?

For Ben.
Can you look at drivers/net/xilinx_emac.c and xilinx_emaclite.c?

>> Signed-off-by: Michal Simek <monstr at monstr.eu>
> 
> I see you sneaked this in via your microblaze custodian repo. This was
> a Bad Thing, and I ask you not to do such things. You were supposed to
> run this through the Net custodian.

Sorry for that. Explanation is above.

> Ditto for [PATCH 05/13] microblaze: add Emac ethernet driver
> 
> Best regards,
> 
> Wolfgang Denk

Best regards,
Michal Simek





From plagnioj at jcrosoft.com  Mon Apr 14 08:46:59 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 14 Apr 2008 08:46:59 +0200
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: <Pine.LNX.4.64.0803261812210.5050@axis700.grange>
References: <Pine.LNX.4.64.0803261812210.5050@axis700.grange>
Message-ID: <20080414064659.GB17663@game.jcrosoft.org>

On 20:40 Wed 26 Mar     , Guennadi Liakhovetski wrote:
> From: Sascha Hauer <s.hauer at pengutronix.de>
> 
> This patch adds an i2c driver for Freescale i.MX processors
> 
> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
> 
> No changes wrt v1
> 
>  drivers/i2c/Makefile  |    1 +
>  drivers/i2c/mxc_i2c.c |  202 +++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 203 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/i2c/mxc_i2c.c
> 
> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
> index 29d6c03..071ef00 100644
> --- a/drivers/i2c/Makefile
> +++ b/drivers/i2c/Makefile
> @@ -29,6 +29,7 @@ COBJS-y += fsl_i2c.o
>  COBJS-y += omap1510_i2c.o
>  COBJS-y += omap24xx_i2c.o
>  COBJS-y += tsi108_i2c.o
> +COBJS-y += mxc_i2c.o
>  
>  COBJS	:= $(COBJS-y)
>  SRCS 	:= $(COBJS:.o=.c)
> diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
> new file mode 100644
> index 0000000..a218329
> --- /dev/null
> +++ b/drivers/i2c/mxc_i2c.c
> @@ -0,0 +1,202 @@
> +/*
> + * i2c driver for Freescale mx31
> + *
> + * (c) 2007 Pengutronix, Sascha Hauer <s.hauer at pengutronix.de>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <common.h>
> +
> +#if defined(CONFIG_HARD_I2C) && defined (CONFIG_I2C_MXC)
Please stop to define this here, move it the Makefile

Wolfgang,
Is it possible to NACK all patch that add new driver that do this

Best Regards,
J.



From leon.kernel at gmail.com  Mon Apr 14 09:15:35 2008
From: leon.kernel at gmail.com (Leon.Z)
Date: Mon, 14 Apr 2008 15:15:35 +0800
Subject: [U-Boot-Users] Use reset CMD to start another u-boot failed.
Message-ID: <4803049a.0fba720a.38ec.fffff326@mx.google.com>

The original u-boot running on board was burn AT 0xFFF00000,
(Flash is mapped to 0xFE000000-0xFFFFFFFF)
The CFG_RESET_ADDRESS = 0xFE000000

The original and new u-boot file difference is only two place.
1. CONFIG_AUTOBOOT_PROMPT (use it to verify the new u-boot startup correctly)
2. board/myboard/config.mk->TEXT_BASE = 0xFE000000
Then I place the new u-boot.bin file to the 0xFE000000,
and then run the "reset" cmd from original u-boot's prompt.

but it's seem the new u-boot was not startup.
the console still print the original u-boot's CONFIG_AUTOBOOT_PROMPT.

Am I miss some step? Or some where need to pay attention to?

============
The original u-boot flinfo.
Original u-boot.bin was place to the FFF00000-FFF3FFFF(2 sector)
CFG_ENV_ADDR = FFF40000(1 sector),CFG_RESET_ADDRESS = 0xFE000000


cilon=> flinfo

Bank # 1: Intel 28F128J3A (16 Mbit, 128 x 128K)
  Size: 16 MB in 128 Sectors
  Sector Start Addresses:
    FE000000      FE020000      FE040000      FE060000      FE080000     
    FE0A0000      FE0C0000      FE0E0000      FE100000      FE120000     
    FE140000      FE160000      FE180000      FE1A0000      FE1C0000     
    FE1E0000      FE200000      FE220000      FE240000      FE260000     
    FE280000      FE2A0000      FE2C0000      FE2E0000      FE300000     
    FE320000      FE340000      FE360000      FE380000      FE3A0000     
    FE3C0000      FE3E0000      FE400000      FE420000      FE440000     
    FE460000      FE480000      FE4A0000      FE4C0000      FE4E0000     
    FE500000      FE520000      FE540000      FE560000      FE580000     
    FE5A0000      FE5C0000      FE5E0000      FE600000      FE620000     
    FE640000      FE660000      FE680000      FE6A0000      FE6C0000     
    FE6E0000      FE700000      FE720000      FE740000      FE760000     
    FE780000      FE7A0000      FE7C0000      FE7E0000      FE800000     
    FE820000      FE840000      FE860000      FE880000      FE8A0000     
    FE8C0000      FE8E0000      FE900000      FE920000      FE940000     
    FE960000      FE980000      FE9A0000      FE9C0000      FE9E0000     
    FEA00000      FEA20000      FEA40000      FEA60000      FEA80000     
    FEAA0000      FEAC0000      FEAE0000      FEB00000      FEB20000     
    FEB40000      FEB60000      FEB80000      FEBA0000      FEBC0000     
    FEBE0000      FEC00000      FEC20000      FEC40000      FEC60000     
    FEC80000      FECA0000      FECC0000      FECE0000      FED00000     
    FED20000      FED40000      FED60000      FED80000      FEDA0000     
    FEDC0000      FEDE0000      FEE00000      FEE20000      FEE40000     
    FEE60000      FEE80000      FEEA0000      FEEC0000      FEEE0000     
    FEF00000      FEF20000      FEF40000      FEF60000      FEF80000     
    FEFA0000      FEFC0000      FEFE0000     

Bank # 2: Intel 28F128J3A (16 Mbit, 128 x 128K)
  Size: 16 MB in 128 Sectors
  Sector Start Addresses:
    FF000000      FF020000      FF040000      FF060000      FF080000     
    FF0A0000      FF0C0000      FF0E0000      FF100000      FF120000     
    FF140000      FF160000      FF180000      FF1A0000      FF1C0000     
    FF1E0000      FF200000      FF220000      FF240000      FF260000     
    FF280000      FF2A0000      FF2C0000      FF2E0000      FF300000     
    FF320000      FF340000      FF360000      FF380000      FF3A0000     
    FF3C0000      FF3E0000      FF400000      FF420000      FF440000     
    FF460000      FF480000      FF4A0000      FF4C0000      FF4E0000     
    FF500000      FF520000      FF540000      FF560000      FF580000     
    FF5A0000      FF5C0000      FF5E0000      FF600000      FF620000     
    FF640000      FF660000      FF680000      FF6A0000      FF6C0000     
    FF6E0000      FF700000      FF720000      FF740000      FF760000     
    FF780000      FF7A0000      FF7C0000      FF7E0000      FF800000     
    FF820000      FF840000      FF860000      FF880000      FF8A0000     
    FF8C0000      FF8E0000      FF900000      FF920000      FF940000     
    FF960000      FF980000      FF9A0000      FF9C0000      FF9E0000     
    FFA00000      FFA20000      FFA40000      FFA60000      FFA80000     
    FFAA0000      FFAC0000      FFAE0000      FFB00000      FFB20000     
    FFB40000      FFB60000      FFB80000      FFBA0000      FFBC0000     
    FFBE0000      FFC00000      FFC20000      FFC40000      FFC60000     
    FFC80000      FFCA0000      FFCC0000      FFCE0000      FFD00000     
    FFD20000      FFD40000      FFD60000      FFD80000      FFDA0000     
    FFDC0000      FFDE0000      FFE00000      FFE20000      FFE40000     
    FFE60000      FFE80000      FFEA0000      FFEC0000      FFEE0000     
    FFF00000 (RO) FFF20000 (RO) FFF40000 (RO) FFF60000      FFF80000     
    FFFA0000      FFFC0000      FFFE0000

????????Leon.Z
????????leon.kernel at gmail.com
??????????2008-04-14

From sander at vermin.nl  Mon Apr 14 10:10:05 2008
From: sander at vermin.nl (Sander Vermin)
Date: Mon, 14 Apr 2008 10:10:05 +0200
Subject: [U-Boot-Users] Uboot (AT91 tree) macb in MII mode
Message-ID: <4803115D.5050603@vermin.nl>

Hi All,

I have been struggling the last week to get the macb Ethernet driver in 
MII mode.

[in short]
I have communication over the MDIO interface, my activity led blinks but 
no ehternet.

[the long story]
I have a custom board build out of the schematics of the AT91SAM9260EK 
board. On my boar I did not use the DM9161 but the KS8721chip. On the 
ATMEL board the PHY works in RMII mode, on my board I used MII mode like 
this board from OLIMEX [1].

Olimex was kind enough to make Uboot nandflash build working with there 
board, And deliver sources I cant compile, due to an error: Hardware 
float vs software float. But I want a dataflash version because I am 
using a BGA chip with nandflash bug.

In my current setup I use the latest git of the AT91 tree with the 
following defines:
#define CONFIG_MACB            1
#define    CONFIG_MII                1
#undef CONFIG_RMII
#define CONFIG_NET_MULTI        1
#define CONFIG_NET_RETRY_COUNT        5000
#define CONFIG_RESET_PHY_R        1

With this config I have the MDIO interface working, when I try to ping 
or TFTP I only get time outs / host not alive errors.

Is there someone out there how has the MII mode working?

Best regards,

Sander


[1] http://www.olimex.com/dev/sam9-L9260.html (schematics on the bottom 
of the page)





From casainho at gmail.com  Mon Apr 14 10:33:55 2008
From: casainho at gmail.com (Casainho)
Date: Mon, 14 Apr 2008 09:33:55 +0100
Subject: [U-Boot-Users] questions about stand alone application - flash a LED
Message-ID: <7e415a090804140133u749f74adufa3a8044d34755ee@mail.gmail.com>

Hello :-)

I am looking for an example code for a Flash LED, for a stand alone
application. I did read the examples like "hello world" and the
/doc/standalone.

I would like to know If I can build a stand alone application without
build the u-boot -- I would appreciate if someone point me to a
tutorial, I just find examples for load Linux...

I am a newbie in 32 bits world. I am trying to port Rockbox*, the Free
Software firmware for audio DAPs like IPods, Sansas, etc., for a
Free/Open hardware, the Rockbox Player**.

I need to use u-boot to launch that firmware, first I would like to
start doing a flash led application. I did build u-boot, using the
sources that came with the dev. board I am using, with success however
the firmware I want to build don't build with arm-linux-gcc, just with
arm-elf-gcc.

I appreciate any suggestions, any guidance. Thank you.

Jorge Pinto,

http://www.casainho.net

* http://www.rockbox.org/
** http://www.rockbox.org/twiki/bin/view/Main/RockboxPlayer



From lg at denx.de  Mon Apr 14 10:53:12 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Mon, 14 Apr 2008 10:53:12 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH v3 7/7] Support for the MX31ADS evaluation
	board from Freescale
In-Reply-To: <20080413220155.68321248C3@gemini.denx.de>
References: <20080413220155.68321248C3@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804141041570.5332@axis700.grange>

This patch adds support for the MX31ADS evaluation board from Freescale, 
initialization code is copied from RedBoot sources, also provided by 
Freescale.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---


On Mon, 14 Apr 2008, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0803262023180.5050 at axis700.grange> you wrote:
> > This patch adds support for the MX31ADS evaluation board from Freescale, 
> > initialization code is copied from RedBoot sources, also provided by 
> > Freescale.
> > 
> > Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> Cannot apply this one:
> 
> Applying Support for the MX31ADS evaluation board from Freescale
> error: patch failed: include/asm-arm/arch-mx31/mx31-regs.h:133
> error: include/asm-arm/arch-mx31/mx31-regs.h: patch does not apply

Ok, you probably applied previous patches, specifically the 2/7 with the 
--whitespace=fix option, then the last empty line had been removed, and 
now the patch doesn't apply cleanly any more. Below is a version without 
that empty line.

> fatal: mode change for board/imx31_litekit/config.mk, which is not in
> current HEAD

No idea where this could come from. You did try to apply this patch after 
the litekit, didn't you? Then the file should already be there. Anyway, I 
tried with your current tree and the patch below, and it seems to work 
now, please try.

Thanks
Guennadi

Changes since v2: merge with upstream

 MAKEALL                                     |    1 +
 Makefile                                    |    3 +
 board/mx31ads/Makefile                      |   47 +++++
 board/{imx31_litekit => mx31ads}/config.mk  |    0 
 board/mx31ads/lowlevel_init.S               |  281 +++++++++++++++++++++++++++
 board/mx31ads/mx31ads.c                     |   95 +++++++++
 board/{imx31_litekit => mx31ads}/u-boot.lds |    0 
 include/asm-arm/arch-mx31/mx31-regs.h       |   14 ++
 include/configs/mx31ads.h                   |  157 +++++++++++++++
 9 files changed, 598 insertions(+), 0 deletions(-)
 create mode 100644 board/mx31ads/Makefile
 copy board/{imx31_litekit => mx31ads}/config.mk (100%)
 create mode 100644 board/mx31ads/lowlevel_init.S
 create mode 100644 board/mx31ads/mx31ads.c
 copy board/{imx31_litekit => mx31ads}/u-boot.lds (100%)
 create mode 100644 include/configs/mx31ads.h

diff --git a/MAKEALL b/MAKEALL
index 0ca866f..d192ed2 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -504,6 +504,7 @@ LIST_ARM11="		\
 	apollon		\
 	imx31_litekit	\
 	imx31_phycore	\
+	mx31ads		\
 "
 
 #########################################################################
diff --git a/Makefile b/Makefile
index b3cbb20..207f5bc 100644
--- a/Makefile
+++ b/Makefile
@@ -2601,6 +2601,9 @@ imx31_litekit_config	: unconfig
 imx31_phycore_config	: unconfig
 	@$(MKCONFIG) $(@:_config=) arm arm1136 imx31_phycore NULL mx31
 
+mx31ads_config		: unconfig
+	@$(MKCONFIG) $(@:_config=) arm arm1136 mx31ads NULL mx31
+
 #========================================================================
 # i386
 #========================================================================
diff --git a/board/mx31ads/Makefile b/board/mx31ads/Makefile
new file mode 100644
index 0000000..dfadd96
--- /dev/null
+++ b/board/mx31ads/Makefile
@@ -0,0 +1,47 @@
+#
+# Copyright (C) 2008, Guennadi Liakhovetski <lg at denx.de>
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).a
+
+COBJS	:= mx31ads.o
+SOBJS	:= lowlevel_init.o
+
+SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+SOBJS	:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB):	$(obj).depend $(OBJS) $(SOBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+	rm -f $(SOBJS) $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/imx31_litekit/config.mk b/board/mx31ads/config.mk
similarity index 100%
copy from board/imx31_litekit/config.mk
copy to board/mx31ads/config.mk
diff --git a/board/mx31ads/lowlevel_init.S b/board/mx31ads/lowlevel_init.S
new file mode 100644
index 0000000..099a7ca
--- /dev/null
+++ b/board/mx31ads/lowlevel_init.S
@@ -0,0 +1,281 @@
+/*
+ * Copyright (C) 2008, Guennadi Liakhovetski <lg at denx.de>
+ *
+ * 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 <asm/arch/mx31-regs.h>
+
+.macro REG reg, val
+	ldr r2, =\reg
+	ldr r3, =\val
+	str r3, [r2]
+.endm
+
+.macro REG8 reg, val
+	ldr r2, =\reg
+	ldr r3, =\val
+	strb r3, [r2]
+.endm
+
+.macro DELAY loops
+	ldr r2, =\loops
+1:
+	subs	r2, r2, #1
+	nop
+	bcs 1b
+.endm
+
+/* RedBoot: AIPS setup - Only setup MPROTx registers.
+ * The PACR default values are good.*/
+.macro init_aips
+	/*
+	 * Set all MPROTx to be non-bufferable, trusted for R/W,
+	 * not forced to user-mode.
+	 */
+	ldr r0, =0x43F00000
+	ldr r1, =0x77777777
+	str r1, [r0, #0x00]
+	str r1, [r0, #0x04]
+	ldr r0, =0x53F00000
+	str r1, [r0, #0x00]
+	str r1, [r0, #0x04]
+
+	/*
+	 * Clear the on and off peripheral modules Supervisor Protect bit
+	 * for SDMA to access them. Did not change the AIPS control registers
+	 * (offset 0x20) access type
+	 */
+	ldr r0, =0x43F00000
+	ldr r1, =0x0
+	str r1, [r0, #0x40]
+	str r1, [r0, #0x44]
+	str r1, [r0, #0x48]
+	str r1, [r0, #0x4C]
+	ldr r1, [r0, #0x50]
+	and r1, r1, #0x00FFFFFF
+	str r1, [r0, #0x50]
+
+	ldr r0, =0x53F00000
+	ldr r1, =0x0
+	str r1, [r0, #0x40]
+	str r1, [r0, #0x44]
+	str r1, [r0, #0x48]
+	str r1, [r0, #0x4C]
+	ldr r1, [r0, #0x50]
+	and r1, r1, #0x00FFFFFF
+	str r1, [r0, #0x50]
+.endm /* init_aips */
+
+/* RedBoot: MAX (Multi-Layer AHB Crossbar Switch) setup */
+.macro init_max
+	ldr r0, =0x43F04000
+	/* MPR - priority is M4 > M2 > M3 > M5 > M0 > M1 */
+	ldr r1, =0x00302154
+	str r1, [r0, #0x000]        /* for S0 */
+	str r1, [r0, #0x100]        /* for S1 */
+	str r1, [r0, #0x200]        /* for S2 */
+	str r1, [r0, #0x300]        /* for S3 */
+	str r1, [r0, #0x400]        /* for S4 */
+	/* SGPCR - always park on last master */
+	ldr r1, =0x10
+	str r1, [r0, #0x010]        /* for S0 */
+	str r1, [r0, #0x110]        /* for S1 */
+	str r1, [r0, #0x210]        /* for S2 */
+	str r1, [r0, #0x310]        /* for S3 */
+	str r1, [r0, #0x410]        /* for S4 */
+	/* MGPCR - restore default values */
+	ldr r1, =0x0
+	str r1, [r0, #0x800]        /* for M0 */
+	str r1, [r0, #0x900]        /* for M1 */
+	str r1, [r0, #0xA00]        /* for M2 */
+	str r1, [r0, #0xB00]        /* for M3 */
+	str r1, [r0, #0xC00]        /* for M4 */
+	str r1, [r0, #0xD00]        /* for M5 */
+.endm /* init_max */
+
+/* RedBoot: M3IF setup */
+.macro init_m3if
+	/* Configure M3IF registers */
+	ldr r1, =0xB8003000
+	/*
+	* M3IF Control Register (M3IFCTL)
+	* MRRP[0] = L2CC0 not on priority list (0 << 0)	= 0x00000000
+	* MRRP[1] = L2CC1 not on priority list (0 << 0)	= 0x00000000
+	* MRRP[2] = MBX not on priority list (0 << 0)	= 0x00000000
+	* MRRP[3] = MAX1 not on priority list (0 << 0)	= 0x00000000
+	* MRRP[4] = SDMA not on priority list (0 << 0)	= 0x00000000
+	* MRRP[5] = MPEG4 not on priority list (0 << 0)	= 0x00000000
+	* MRRP[6] = IPU1 on priority list (1 << 6)	= 0x00000040
+	* MRRP[7] = IPU2 not on priority list (0 << 0)	= 0x00000000
+	*						------------
+	*						  0x00000040
+	*/
+	ldr r0, =0x00000040
+	str r0, [r1]  /* M3IF control reg */
+.endm /* init_m3if */
+
+/* RedBoot: To support 133MHz DDR */
+.macro  init_drive_strength
+	/*
+	 * Disable maximum drive strength SDRAM/DDR lines by clearing DSE1 bits
+	 * in SW_PAD_CTL registers
+	 */
+
+	/* SDCLK */
+	ldr r1, =0x43FAC200
+	ldr r0, [r1, #0x6C]
+	bic r0, r0, #(1 << 12)
+	str r0, [r1, #0x6C]
+
+	/* CAS */
+	ldr r0, [r1, #0x70]
+	bic r0, r0, #(1 << 22)
+	str r0, [r1, #0x70]
+
+	/* RAS */
+	ldr r0, [r1, #0x74]
+	bic r0, r0, #(1 << 2)
+	str r0, [r1, #0x74]
+
+	/* CS2 (CSD0) */
+	ldr r0, [r1, #0x7C]
+	bic r0, r0, #(1 << 22)
+	str r0, [r1, #0x7C]
+
+	/* DQM3 */
+	ldr r0, [r1, #0x84]
+	bic r0, r0, #(1 << 22)
+	str r0, [r1, #0x84]
+
+	/* DQM2, DQM1, DQM0, SD31-SD0, A25-A0, MA10 (0x288..0x2DC) */
+	ldr r2, =22	/* (0x2E0 - 0x288) / 4 = 22 */
+pad_loop:
+	ldr r0, [r1, #0x88]
+	bic r0, r0, #(1 << 22)
+	bic r0, r0, #(1 << 12)
+	bic r0, r0, #(1 << 2)
+	str r0, [r1, #0x88]
+	add r1, r1, #4
+	subs r2, r2, #0x1
+	bne pad_loop
+.endm /* init_drive_strength */
+
+/* CPLD on CS4 setup */
+.macro init_cs4
+	ldr r0, =WEIM_BASE
+	ldr r1, =0x0000D843
+	str r1, [r0, #0x40]
+	ldr r1, =0x22252521
+	str r1, [r0, #0x44]
+	ldr r1, =0x22220A00
+	str r1, [r0, #0x48]
+.endm /* init_cs4 */
+
+.globl lowlevel_init
+lowlevel_init:
+
+	/* Redboot initializes very early AIPS, what for?
+	 * Then it also initializes Multi-Layer AHB Crossbar Switch,
+	 * M3IF */
+	/* Also setup the Peripheral Port Remap register inside the core */
+	ldr r0, =0x40000015        /* start from AIPS 2GB region */
+	mcr p15, 0, r0, c15, c2, 4
+
+	init_aips
+
+	init_max
+
+	init_m3if
+
+	init_drive_strength
+
+	init_cs4
+
+	/* Image Processing Unit: */
+	/* Too early to switch display on? */
+	REG	IPU_CONF, IPU_CONF_DI_EN	/* Switch on Display Interface */
+	/* Clock Control Module: */
+	REG	CCM_CCMR, 0x074B0BF5		/* Use CKIH, MCU PLL off */
+
+	DELAY 0x40000
+
+	REG	CCM_CCMR, 0x074B0BF5 | CCMR_MPE			/* MCU PLL on */
+	REG	CCM_CCMR, (0x074B0BF5 | CCMR_MPE) & ~CCMR_MDS	/* Switch to MCU PLL */
+
+	/* PBC CPLD on CS4 */
+	mov	r1, #CS4_BASE
+	ldrh	r1, [r1, #0x2]
+	/* Is 27MHz switch set? */
+	ands	r1, r1, #0x16
+
+	/* 532-133-66.5 */
+	ldr	r0, =CCM_BASE
+	ldr	r1, =0xFF871D58
+	/* PDR0 */
+	str	r1, [r0, #0x4]
+	ldreq	r1, MPCTL_PARAM_532
+	ldrne	r1, MPCTL_PARAM_532_27
+	/* MPCTL */
+	str	r1, [r0, #0x10]
+
+	/* Set UPLL=240MHz, USB=60MHz */
+	ldr	r1, =0x49FCFE7F
+	/* PDR1 */
+	str	r1, [r0, #0x8]
+	ldreq	r1, UPCTL_PARAM_240
+	ldrne	r1, UPCTL_PARAM_240_27
+	/* UPCTL */
+	str	r1, [r0, #0x14]
+	/* default CLKO to 1/8 of the ARM core */
+	mov	r1, #0x000002C0
+	add	r1, r1, #0x00000006
+	/* COSR */
+	str	r1, [r0, #0x1c]
+
+	/* RedBoot sets 0x1ff, 7, 3, 5, 1, 3, 0 */
+/*	REG	CCM_PDR0, PDR0_CSI_PODF(0x1ff) | PDR0_PER_PODF(7) | PDR0_HSP_PODF(2) | PDR0_NFC_PODF(6) | PDR0_IPG_PODF(1) | PDR0_MAX_PODF(2) | PDR0_MCU_PODF(0)*/
+
+	/* Redboot: 0, 51, 10, 12 / 0, 14, 9, 13 */
+/*	REG	CCM_MPCTL, PLL_PD(0) | PLL_MFD(0x33) | PLL_MFI(7) | PLL_MFN(0x23)*/
+	/* Default: 1, 4, 12, 1 */
+	REG	CCM_SPCTL, PLL_PD(1) | PLL_MFD(4) | PLL_MFI(12) | PLL_MFN(1)
+
+	/* B8xxxxxx - NAND, 8xxxxxxx - CSD0 RAM */
+	REG	0xB8001010, 0x00000004
+	REG	0xB8001004, 0x006ac73a
+	REG	0xB8001000, 0x92100000
+	REG	0x80000f00, 0x12344321
+	REG	0xB8001000, 0xa2100000
+	REG	0x80000000, 0x12344321
+	REG	0x80000000, 0x12344321
+	REG	0xB8001000, 0xb2100000
+	REG8	0x80000033, 0xda
+	REG8	0x81000000, 0xff
+	REG	0xB8001000, 0x82226080
+	REG	0x80000000, 0xDEADBEEF
+	REG	0xB8001010, 0x0000000c
+
+	mov	pc, lr
+
+MPCTL_PARAM_532:
+	.word (((1-1) << 26) + ((52-1) << 16) + (10 << 10) + (12 << 0))
+MPCTL_PARAM_532_27:
+	.word (((1-1) << 26) + ((15-1) << 16) + (9  << 10) + (13 << 0))
+UPCTL_PARAM_240:
+	.word (((2-1) << 26) + ((13-1) << 16) + (9  << 10) + (3  << 0))
+UPCTL_PARAM_240_27:
+	.word (((2-1) << 26) + ((9 -1) << 16) + (8  << 10) + (8  << 0))
diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c
new file mode 100644
index 0000000..a92adb7
--- /dev/null
+++ b/board/mx31ads/mx31ads.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2008, Guennadi Liakhovetski <lg at denx.de>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/mx31.h>
+#include <asm/arch/mx31-regs.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int dram_init (void)
+{
+	gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
+	gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+
+	return 0;
+}
+
+int board_init (void)
+{
+	int i;
+#if 0
+	/* CS0: Nor Flash */
+	/*
+	 * These are values from the RedBoot sources by Freescale. However,
+	 * under U-Boot with this configuration 32-bit accesses don't work,
+	 * lower 16 bits of data are read twice for each 32-bit read.
+	 */
+	__REG(CSCR_U(0)) = 0x23524E80;
+	__REG(CSCR_L(0)) = 0x10000D03; /* WRAP bit (1) is suspicious here, but
+					* disabling it doesn't help either */
+	__REG(CSCR_A(0)) = 0x00720900;
+#endif
+
+	/* setup pins for UART1 */
+	mx31_gpio_mux(MUX_RXD1__UART1_RXD_MUX);
+	mx31_gpio_mux(MUX_TXD1__UART1_TXD_MUX);
+	mx31_gpio_mux(MUX_RTS1__UART1_RTS_B);
+	mx31_gpio_mux(MUX_RTS1__UART1_CTS_B);
+
+	/* PBC setup */
+	/* Enable UART transceivers also reset the Ethernet/external UART */
+	readw(CS4_BASE + 4);
+
+	writew(0x8023, CS4_BASE + 4);
+
+	/* RedBoot also has an empty loop with 100000 iterations here -
+	 * clock doesn't run yet */
+	for (i = 0; i < 100000; i++)
+		;
+
+	/* Clear the reset, toggle the LEDs */
+	writew(0xDF, CS4_BASE + 6);
+
+	/* clock still doesn't run */
+	for (i = 0; i < 100000; i++)
+		;
+
+	/* See 1.5.4 in IMX31ADSE_PERI_BUS_CNTRL_CPLD_RM.pdf */
+	readb(CS4_BASE + 8);
+	readb(CS4_BASE + 7);
+	readb(CS4_BASE + 8);
+	readb(CS4_BASE + 7);
+
+	gd->bd->bi_arch_number = 447;		/* board id for linux */
+	gd->bd->bi_boot_params = 0x80000100;	/* adress of boot parameters */
+
+	return 0;
+}
+
+int checkboard (void)
+{
+	printf("Board: MX31ADS\n");
+	return 0;
+}
diff --git a/board/imx31_litekit/u-boot.lds b/board/mx31ads/u-boot.lds
similarity index 100%
copy from board/imx31_litekit/u-boot.lds
copy to board/mx31ads/u-boot.lds
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h b/include/asm-arm/arch-mx31/mx31-regs.h
index c004478..e9c7671 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -133,5 +133,19 @@
 #define MUX_CSPI2_MOSI__I2C2_SCL ((MUX_CTL_ALT1 << 8) | MUX_CTL_CSPI2_MOSI)
 #define MUX_CSPI2_MISO__I2C2_SCL ((MUX_CTL_ALT1 << 8) | MUX_CTL_CSPI2_MISO)
 
+/*
+ * Memory regions and CS
+ */
+#define IPU_MEM_BASE	0x70000000
+#define CSD0_BASE	0x80000000
+#define CSD1_BASE	0x90000000
+#define CS0_BASE	0xA0000000
+#define CS1_BASE	0xA8000000
+#define CS2_BASE	0xB0000000
+#define CS3_BASE	0xB2000000
+#define CS4_BASE	0xB4000000
+#define CS4_PSRAM_BASE	0xB5000000
+#define CS5_BASE	0xB6000000
+#define PCMCIA_MEM_BASE	0xC0000000
 
 #endif /* __ASM_ARCH_MX31_REGS_H */
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
new file mode 100644
index 0000000..49e733b
--- /dev/null
+++ b/include/configs/mx31ads.h
@@ -0,0 +1,166 @@
+/*
+ * Copyright (C) 2008, Guennadi Liakhovetski <lg at denx.de>
+ *
+ * Configuration settings for the MX31ADS Freescale board.
+ *
+ * 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
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#include <asm/arch/mx31-regs.h>
+
+ /* High Level Configuration Options */
+#define CONFIG_ARM1136		1		/* This is an arm1136 CPU core */
+#define CONFIG_MX31		1		/* in a mx31 */
+#define CONFIG_MX31_HCLK_FREQ	26000000	/* RedBoot says 26MHz */
+#define CONFIG_MX31_CLK32	32000
+
+#define CONFIG_DISPLAY_CPUINFO
+#define CONFIG_DISPLAY_BOARDINFO
+
+/*
+ * Disabled for now due to build problems under Debian and a significant increase
+ * in the final file size: 144260 vs. 109536 Bytes.
+ */
+#if 0
+#define CONFIG_OF_LIBFDT		1
+#define CONFIG_FIT			1
+#define CONFIG_FIT_VERBOSE		1
+#endif
+
+#define CONFIG_CMDLINE_TAG		1	/* enable passing of ATAGs */
+#define CONFIG_SETUP_MEMORY_TAGS	1
+#define CONFIG_INITRD_TAG		1
+
+/*
+ * Size of malloc() pool
+ */
+#define CFG_MALLOC_LEN		(CFG_ENV_SIZE + 128 * 1024)
+#define CFG_GBL_DATA_SIZE	128  /* size in bytes reserved for initial data */
+
+/*
+ * Hardware drivers
+ */
+
+#define CONFIG_MX31_UART	1
+#define CFG_MX31_UART1		1
+
+/* allow to overwrite serial and ethaddr */
+#define CONFIG_ENV_OVERWRITE
+#define CONFIG_CONS_INDEX	1
+#define CONFIG_BAUDRATE		115200
+#define CFG_BAUDRATE_TABLE	{9600, 19200, 38400, 57600, 115200}
+
+/***********************************************************
+ * Command definition
+ ***********************************************************/
+
+#include <config_cmd_default.h>
+
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_PING
+
+#define CONFIG_BOOTDELAY	3
+
+#define CONFIG_NETMASK		255.255.255.0
+#define CONFIG_IPADDR		192.168.23.168
+#define CONFIG_SERVERIP		192.168.23.2
+
+#define	CONFIG_EXTRA_ENV_SETTINGS											\
+	"bootargs_base=setenv bootargs console=ttymxc0,115200\0"							\
+	"bootargs_nfs=setenv bootargs $(bootargs) root=/dev/nfs ip=dhcp nfsroot=$(serverip):$(nfsrootfs),v3,tcp\0"	\
+	"bootcmd=run bootcmd_net\0"											\
+	"bootcmd_net=run bootargs_base bootargs_mtd bootargs_nfs; tftpboot 0x80000000 uImage-mx31; bootm\0"		\
+	"prg_uboot=tftpboot 0x80000000 u-boot-mx31ads.bin; protect off 0xa0000000 0xa001ffff; erase 0xa0000000 0xa001ffff; cp.b 0x80000000 0xa0000000 $(filesize)\0"
+
+
+#define CONFIG_DRIVER_CS8900	1
+#define CS8900_BASE		0xb4020300
+#define CS8900_BUS16		1	/* the Linux driver does accesses as shorts */
+
+/*
+ * Miscellaneous configurable options
+ */
+#define CFG_LONGHELP		/* undef to save memory */
+#define CFG_PROMPT		"=> "
+#define CFG_CBSIZE		256		/* Console I/O Buffer Size */
+/* Print Buffer Size */
+#define CFG_PBSIZE		(CFG_CBSIZE+sizeof(CFG_PROMPT)+16)
+#define CFG_MAXARGS		16		/* max number of command args */
+#define CFG_BARGSIZE		CFG_CBSIZE	/* Boot Argument Buffer Size */
+
+#define CFG_MEMTEST_START	0		/* memtest works on */
+#define CFG_MEMTEST_END		0x10000
+
+#undef	CFG_CLKS_IN_HZ		/* everything, incl board info, in Hz */
+
+#define CFG_LOAD_ADDR		CSD0_BASE	/* default load address */
+
+#define CFG_HZ			32000
+
+#define CONFIG_CMDLINE_EDITING	1
+
+/*-----------------------------------------------------------------------
+ * Stack sizes
+ *
+ * The stack sizes are set up in start.S using the settings below
+ */
+#define CONFIG_STACKSIZE	(128 * 1024)	/* regular stack */
+
+/*-----------------------------------------------------------------------
+ * Physical Memory Map
+ */
+#define CONFIG_NR_DRAM_BANKS	1
+#define PHYS_SDRAM_1		CSD0_BASE
+#define PHYS_SDRAM_1_SIZE	(128 * 1024 * 1024)
+
+/*-----------------------------------------------------------------------
+ * FLASH and environment organization
+ */
+#define CFG_FLASH_BASE		CS0_BASE
+#define CFG_MAX_FLASH_BANKS	1		/* max number of memory banks */
+#define CFG_MAX_FLASH_SECT	262		/* max number of sectors on one chip */
+#define CFG_MONITOR_BASE	CFG_FLASH_BASE	/* Monitor at beginning of flash */
+#define CFG_MONITOR_LEN		(128 * 1024)	/* Reserve 128KiB */
+
+#define	CFG_ENV_IS_IN_FLASH	1
+#define CFG_ENV_SECT_SIZE	(32 * 1024)
+#define CFG_ENV_SIZE		CFG_ENV_SECT_SIZE
+/* S29WS256N NOR flash has 4 32KiB small sectors at the beginning and at the end.
+ * The rest of 32MiB is in 128KiB big sectors. U-Boot occupies the low 4 sectors,
+ * if we put environment next to it, we will have to occupy 128KiB for it.
+ * Putting it at the top of flash we use only 32KiB. */
+#define CFG_ENV_ADDR		(CFG_MONITOR_BASE + 32 * 1024 * 1024 - CFG_ENV_SIZE)
+
+/*-----------------------------------------------------------------------
+ * CFI FLASH driver setup
+ */
+#define CFG_FLASH_CFI			1 /* Flash memory is CFI compliant */
+#define CFG_FLASH_CFI_DRIVER		1 /* Use drivers/cfi_flash.c */
+#if 0 /* Doesn't work yet, work in progress */
+#define CFG_FLASH_USE_BUFFER_WRITE	1 /* Use buffered writes (~10x faster) */
+#endif
+#define CFG_FLASH_PROTECTION		1 /* Use hardware sector protection */
+
+/*
+ * JFFS2 partitions
+ */
+#undef CONFIG_JFFS2_CMDLINE
+#define CONFIG_JFFS2_DEV	"nor0"
+
+#endif /* __CONFIG_H */
-- 
1.5.4




From stelian at popies.net  Mon Apr 14 11:08:59 2008
From: stelian at popies.net (Stelian Pop)
Date: Mon, 14 Apr 2008 11:08:59 +0200
Subject: [U-Boot-Users] Uboot (AT91 tree) macb in MII mode
In-Reply-To: <4803115D.5050603@vermin.nl>
References: <4803115D.5050603@vermin.nl>
Message-ID: <1208164139.6399.23.camel@galileo>


Le lundi 14 avril 2008 ? 10:10 +0200, Sander Vermin a ?crit :
> Hi All,
> 
> I have been struggling the last week to get the macb Ethernet driver in 
> MII mode.
> 
> [in short]
> I have communication over the MDIO interface, my activity led blinks but 
> no ehternet.
> 
> [the long story]
> I have a custom board build out of the schematics of the AT91SAM9260EK 
> board. On my boar I did not use the DM9161 but the KS8721chip. On the 
> ATMEL board the PHY works in RMII mode, on my board I used MII mode like 
> this board from OLIMEX [1].

Do you have a working Linux kernel with a working network interface ? 
The Linux and U-Boot macb driver and PIO configuration is very close,
and if you manage to make it work under Linux you'll probably have
little trouble finding out the problem.

> Olimex was kind enough to make Uboot nandflash build working with there 
> board, And deliver sources I cant compile, due to an error: Hardware 
> float vs software float. But I want a dataflash version because I am 
> using a BGA chip with nandflash bug.

I don't see what NAND has to do with ethernet here.

> In my current setup I use the latest git of the AT91 tree with the 
> following defines:
> #define CONFIG_MACB            1
> #define    CONFIG_MII                1
> #undef CONFIG_RMII
> #define CONFIG_NET_MULTI        1
> #define CONFIG_NET_RETRY_COUNT        5000
> #define CONFIG_RESET_PHY_R        1
> 
> With this config I have the MDIO interface working, when I try to ping 
> or TFTP I only get time outs / host not alive errors.

Does the board send anything at all ? Try sniffing the net wire (using
tcpdump for example).

Also, what cross chain are you using ? I have seen strange network
errors when using recent compilers which after investigation were -Os
optimisation errors. (using the latest CodeSourcery toolchain for
example).

> Is there someone out there how has the MII mode working?

If I'm correct, Olimex has. So closer inspection of their code may
reveal some information.

Stelian.
-- 
Stelian Pop <stelian at popies.net>




From stelian at popies.net  Mon Apr 14 11:19:33 2008
From: stelian at popies.net (Stelian Pop)
Date: Mon, 14 Apr 2008 11:19:33 +0200
Subject: [U-Boot-Users] [PATCH] Add support for Atmel flash
In-Reply-To: <02bf01c89df4$fe986380$040514ac@atmel.com>
References: <1208027002.23686.7.camel@elrond.atmel.sweden>
	<1208093818.23686.11.camel@voyager.dsnet>
	<02bf01c89df4$fe986380$040514ac@atmel.com>
Message-ID: <1208164773.6399.34.camel@galileo>


Le lundi 14 avril 2008 ? 08:00 +0200, Ulf Samuelsson a ?crit :
> > Le samedi 12 avril 2008 ? 21:03 +0200, Ulf Samuelsson a ?crit :
> >> Add ID codes for most recent Atmel NOR flashes
> > 
> > Is there any added value on using the atmel flash driver instead of the
> > standard CFI driver ? It surely doesn't have any on the SAM9/CAP9
> > boards, but I'm not sure of the older AT91RM9200.
> > 
> > Thanks,
> > -- 
> > Stelian Pop <stelian at popies.net>
> > 
> 
> 
> It is mainly time related.
> This flash driver is well tested on the AT91RM9200EK.
> The standard CFI driver is not.
> While CFI should work, I do not have time to make a thorough test.

Linux seems to use the CFI driver, just like every other SAM/CAP board,
so it should be safe to switch to the standard CFI driver.

The only remaining issue is testing, and I was hoping you could do this
as part of the new board porting. :)

Thanks,

-- 
Stelian Pop <stelian at popies.net>




From stelian at popies.net  Mon Apr 14 11:16:26 2008
From: stelian at popies.net (Stelian Pop)
Date: Mon, 14 Apr 2008 11:16:26 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
In-Reply-To: <02c001c89df5$0056b550$040514ac@atmel.com>
References: <1208030816.23686.13.camel@elrond.atmel.sweden>
	<1208093705.23686.8.camel@voyager.dsnet>
	<02c001c89df5$0056b550$040514ac@atmel.com>
Message-ID: <1208164586.6399.30.camel@galileo>


Le lundi 14 avril 2008 ? 08:01 +0200, Ulf Samuelsson a ?crit :

> The at91rm9200dk board already exists with similar code.
> 
> I think the chances that it someone will work on this is higher
> if the code is inside U-Boot than outside U-Boot though.

Not sure about this. If it's there and it works there will be little
incentive to change...

At the same time, you are doing some testing for the new code, and for
(almost) the same price you could (implement and) test the cleaned up
version instead.

> BTW: Why not have the AVR32 and AT91 use the same.
>     The PIO peripheral is the same.

It may be a good idea for the future.

However, this is not how it is done today in Linux, and I've tried to
minimize changes (especially in the header files) to ease the porting.

Thanks,
-- 
Stelian Pop <stelian at popies.net>




From sander at vermin.nl  Mon Apr 14 11:19:08 2008
From: sander at vermin.nl (Sander Vermin)
Date: Mon, 14 Apr 2008 11:19:08 +0200
Subject: [U-Boot-Users] Uboot (AT91 tree) macb in MII mode
In-Reply-To: <1208164139.6399.23.camel@galileo>
References: <4803115D.5050603@vermin.nl> <1208164139.6399.23.camel@galileo>
Message-ID: <4803218C.7040600@vermin.nl>

Stelian Pop schreef:
> Le lundi 14 avril 2008 ? 10:10 +0200, Sander Vermin a ?crit :
>   
>> Hi All,
>>
>> I have been struggling the last week to get the macb Ethernet driver in 
>> MII mode.
>>
>> [in short]
>> I have communication over the MDIO interface, my activity led blinks but 
>> no ehternet.
>>
>> [the long story]
>> I have a custom board build out of the schematics of the AT91SAM9260EK 
>> board. On my boar I did not use the DM9161 but the KS8721chip. On the 
>> ATMEL board the PHY works in RMII mode, on my board I used MII mode like 
>> this board from OLIMEX [1].
>>     
>
> Do you have a working Linux kernel with a working network interface ? 
> The Linux and U-Boot macb driver and PIO configuration is very close,
> and if you manage to make it work under Linux you'll probably have
> little trouble finding out the problem.
>   
Are all settings of uboot overwritten by linux? I am not to comfortable 
hacking in the Linux kernel and I had the focus on Uboot.
>> Olimex was kind enough to make Uboot nandflash build working with there 
>> board, And deliver sources I cant compile, due to an error: Hardware 
>> float vs software float. But I want a dataflash version because I am 
>> using a BGA chip with nandflash bug.
>>     
>
> I don't see what NAND has to do with ethernet here.
>   
The AT91SAM9260 BGA chip has a bug, that booting from NAND has problems.
>   
>> In my current setup I use the latest git of the AT91 tree with the 
>> following defines:
>> #define CONFIG_MACB            1
>> #define    CONFIG_MII                1
>> #undef CONFIG_RMII
>> #define CONFIG_NET_MULTI        1
>> #define CONFIG_NET_RETRY_COUNT        5000
>> #define CONFIG_RESET_PHY_R        1
>>
>> With this config I have the MDIO interface working, when I try to ping 
>> or TFTP I only get time outs / host not alive errors.
>>     
>
> Does the board send anything at all ? Try sniffing the net wire (using
> tcpdump for example).
>
> Also, what cross chain are you using ? I have seen strange network
> errors when using recent compilers which after investigation were -Os
> optimisation errors. (using the latest CodeSourcery toolchain for
> example).
>   
I am using the compilers from buildroot.
>   
>> Is there someone out there how has the MII mode working?
>>     
>
> If I'm correct, Olimex has. So closer inspection of their code may
> reveal some information.
>
> Stelian.
>   
Olimex has indeed, but that is a old version of uboot, the old ETHER 
driver and not the new. I inspected the initialization code on the ARM 
side, that was the same. The rest of te code is completely different, so 
spotting differences is difficult.

Sander




From stelian at popies.net  Mon Apr 14 11:41:36 2008
From: stelian at popies.net (Stelian Pop)
Date: Mon, 14 Apr 2008 11:41:36 +0200
Subject: [U-Boot-Users] Uboot (AT91 tree) macb in MII mode
In-Reply-To: <4803218C.7040600@vermin.nl>
References: <4803115D.5050603@vermin.nl> <1208164139.6399.23.camel@galileo>
	<4803218C.7040600@vermin.nl>
Message-ID: <1208166096.6399.51.camel@galileo>


Le lundi 14 avril 2008 ? 11:19 +0200, Sander Vermin a ?crit :

> > Do you have a working Linux kernel with a working network interface ? 
> > The Linux and U-Boot macb driver and PIO configuration is very close,
> > and if you manage to make it work under Linux you'll probably have
> > little trouble finding out the problem.
> >   
> Are all settings of uboot overwritten by linux?

Almost all the settings are overwritten, yes.

>  I am not to comfortable 
> hacking in the Linux kernel and I had the focus on Uboot.

So you do not have a working Linux kernel. This was my question.

> >> Olimex was kind enough to make Uboot nandflash build working with there 
> >> board, And deliver sources I cant compile, due to an error: Hardware 
> >> float vs software float. But I want a dataflash version because I am 
> >> using a BGA chip with nandflash bug.
> >>     
> >
> > I don't see what NAND has to do with ethernet here.
> >   
> The AT91SAM9260 BGA chip has a bug, that booting from NAND has problems.

Ok, but this has nothing to do with the Ethernet, right ? If the
ethernet is supposed to work with their U-Boot version, it will probably
work as well if you configure U-Boot to boot from dataflash instead of
NAND flash.

> > Also, what cross chain are you using ? I have seen strange network
> > errors when using recent compilers which after investigation were -Os
> > optimisation errors. (using the latest CodeSourcery toolchain for
> > example).
> >   
> I am using the compilers from buildroot.

This doesn't learn us anything about the gcc version you're using.

The official toolchain for U-Boot is the DENX ELDK:
http://www.denx.de/wiki/DULG/ELDK . I don't really think this is your
issue, but when nothing works it may make sense to put yourself in a
well known configuration.

> Olimex has indeed, but that is a old version of uboot, the old ETHER 
> driver and not the new. I inspected the initialization code on the ARM 
> side, that was the same. The rest of te code is completely different, so 
> spotting differences is difficult.

Ah, I understand. However, there must be a difference somewhere. I'm not
sure about this board, but on the SAM boards a software reset has to be
performed once the PHY address is configured to activate the PHY (look
into at91sam9260.c). Maybe your board needs something equivalent ?

-- 
Stelian Pop <stelian at popies.net>




From sander at vermin.nl  Mon Apr 14 11:52:13 2008
From: sander at vermin.nl (Sander Vermin)
Date: Mon, 14 Apr 2008 11:52:13 +0200
Subject: [U-Boot-Users] Uboot (AT91 tree) macb in MII mode
In-Reply-To: <1208166096.6399.51.camel@galileo>
References: <4803115D.5050603@vermin.nl> <1208164139.6399.23.camel@galileo>	
	<4803218C.7040600@vermin.nl> <1208166096.6399.51.camel@galileo>
Message-ID: <4803294D.6010205@vermin.nl>

Stelian Pop schreef:
> Le lundi 14 avril 2008 ? 11:19 +0200, Sander Vermin a ?crit :
>
>   
>>> Do you have a working Linux kernel with a working network interface ? 
>>> The Linux and U-Boot macb driver and PIO configuration is very close,
>>> and if you manage to make it work under Linux you'll probably have
>>> little trouble finding out the problem.
>>>   
>>>       
>> Are all settings of uboot overwritten by linux?
>>     
>
> Almost all the settings are overwritten, yes.
>
>   
Oke, olimex has a demo linux with working ethernet.. I can try to put 
this on my board with my current uboot.
>>  I am not to comfortable 
>> hacking in the Linux kernel and I had the focus on Uboot.
>>     
>
> So you do not have a working Linux kernel. This was my question.
>
>   
>>>> Olimex was kind enough to make Uboot nandflash build working with there 
>>>> board, And deliver sources I cant compile, due to an error: Hardware 
>>>> float vs software float. But I want a dataflash version because I am 
>>>> using a BGA chip with nandflash bug.
>>>>     
>>>>         
>>> I don't see what NAND has to do with ethernet here.
>>>   
>>>       
>> The AT91SAM9260 BGA chip has a bug, that booting from NAND has problems.
>>     
>
> Ok, but this has nothing to do with the Ethernet, right ? If the
> ethernet is supposed to work with their U-Boot version, it will probably
> work as well if you configure U-Boot to boot from dataflash instead of
> NAND flash.
>
>   
>>> Also, what cross chain are you using ? I have seen strange network
>>> errors when using recent compilers which after investigation were -Os
>>> optimisation errors. (using the latest CodeSourcery toolchain for
>>> example).
>>>   
>>>       
>> I am using the compilers from buildroot.
>>     
>
> This doesn't learn us anything about the gcc version you're using.
>
> The official toolchain for U-Boot is the DENX ELDK:
> http://www.denx.de/wiki/DULG/ELDK . I don't really think this is your
> issue, but when nothing works it may make sense to put yourself in a
> well known configuration.
>
>   
Is there some pre compiled  arm version?
>> Olimex has indeed, but that is a old version of uboot, the old ETHER 
>> driver and not the new. I inspected the initialization code on the ARM 
>> side, that was the same. The rest of te code is completely different, so 
>> spotting differences is difficult.
>>     
>
> Ah, I understand. However, there must be a difference somewhere. I'm not
> sure about this board, but on the SAM boards a software reset has to be
> performed once the PHY address is configured to activate the PHY (look
> into at91sam9260.c). Maybe your board needs something equivalent ?
>
>   
Currently I am using the at91sam9260ek config with the options above edited.

Sander




From luigi.mantellini at idf-hit.com  Mon Apr 14 12:47:44 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Mon, 14 Apr 2008 12:47:44 +0200
Subject: [U-Boot-Users] [RFC] Create include/u-boot directory
In-Reply-To: <20080412122528.GA17663@game.jcrosoft.org>
References: <20080412122528.GA17663@game.jcrosoft.org>
Message-ID: <1208170064.8561.1.camel@localhost>

I think that a separate include directory for u-boot is a good idea.

ciao

luigi

On sab, 2008-04-12 at 14:25 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:

> Hi,
> 
> 	I proposing to create an include directory name u-boot like it's
> 	done in linux (include/linux) where we put all relate u-boot
> 	headers except configs and asms dirs.
> 	It will allow us to be sure to be independent form the host
> 	system as example
> 
> 	The include will look like this
> 
> #ls -alh include
> total 72K
> drwxr-xr-x 16 j j 4,0K avr 12 14:17 .
> drwxr-xr-x 32 j j 4,0K avr 12 14:08 ..
> drwxr-xr-x 20 j j 4,0K avr 12 14:01 asm-arm
> drwxr-xr-x  3 j j 4,0K mar 31 12:02 asm-avr32
> drwxr-xr-x  8 j j 4,0K avr 12 05:58 asm-blackfin
> drwxr-xr-x  3 j j 4,0K mar 31 12:02 asm-i386
> drwxr-xr-x  3 j j 4,0K avr 12 05:58 asm-m68k
> drwxr-xr-x  3 j j 4,0K mar 31 12:02 asm-microblaze
> drwxr-xr-x  2 j j 4,0K avr 12 14:01 asm-mips
> drwxr-xr-x  2 j j 4,0K mar 31 12:02 asm-nios
> drwxr-xr-x  2 j j 4,0K mar 31 12:02 asm-nios2
> drwxr-xr-x  2 j j 4,0K avr 12 06:27 asm-ppc
> drwxr-xr-x  2 j j 4,0K avr 12 05:58 asm-sh
> drwxr-xr-x  2 j j 8,0K avr 12 05:59 configs
> -rw-r--r--  1 j j  110 mar 31 12:02 .gitignore
> drwxr-xr-x  4 j j 4,0K avr 12 05:58 linux
> drwxr-xr-x  7 j j 4,0K avr 12 14:17 u-boot
> 
> Best Regards,
> J.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

Industrie Dial Face S.p.A.
Luigi Mantellini
R&D - Software
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI), Italy
Tel.:   +39 02 5167 2813
Fax:    +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com
GPG fingerprint: 3DD1 7B71 FBDF 6376
1B4A
                 B003 175F E979 907E
1650
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080414/d2f7f257/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idf_logo.gif
Type: image/gif
Size: 4122 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080414/d2f7f257/attachment.gif 

From tal.omer.17 at gmail.com  Mon Apr 14 12:59:28 2008
From: tal.omer.17 at gmail.com (Tal Omer)
Date: Mon, 14 Apr 2008 13:59:28 +0300
Subject: [U-Boot-Users] PQIII-8548: Problems in DDR2 configuration
Message-ID: <a7b5ae0b0804140359h6c493501gb88bf6d113be176f@mail.gmail.com>

Hi

I have PQIII-8548 problems in DDR2 configuration.
And look for leads. Help will be welcomed.

Details below - Thanks in advance.
     ++Tal
 ---------------------------------------------------
1. Board is propeitery board
2. CPU: 8548 (e500 core, v2)
3. SDRAM is DDR2 (not DIMM)
4. DDR is working while using REG file (with JTAG loader).
5. DDR is *not*, working uboot.
6. Burn/Access FLASH is OK
    L2-SRAM access is OK
    TLB/LAW - triple check - OK

 Few trials so far:
1. using the "spd_sdram" to load the parameters,
    while removing the "CFG_READ_SPD" and taking the parameters from teh REG
file,
    we get the WRITE ok, and the READ not
    (using SCOPE to view the signals)
2. In all cases:
    The D_INIT set in "sdram_cfg_2" *do not* fill the DRAM with
    the known value of "sdram_data_init".

    Rather, after the DRAM is enabled, and we set D_INIT once again.
    It fills the DRAM with the known value of "sdram_data_init".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080414/3289d091/attachment.htm 

From plagnioj at jcrosoft.com  Mon Apr 14 13:18:29 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 14 Apr 2008 13:18:29 +0200
Subject: [U-Boot-Users] [PATCH] Add support for Atmel flash
In-Reply-To: <1208164773.6399.34.camel@galileo>
References: <1208027002.23686.7.camel@elrond.atmel.sweden>
	<1208093818.23686.11.camel@voyager.dsnet>
	<02bf01c89df4$fe986380$040514ac@atmel.com>
	<1208164773.6399.34.camel@galileo>
Message-ID: <20080414111829.GC17663@game.jcrosoft.org>

On 11:19 Mon 14 Apr     , Stelian Pop wrote:
> 
> Le lundi 14 avril 2008 ? 08:00 +0200, Ulf Samuelsson a ?crit :
> > > Le samedi 12 avril 2008 ? 21:03 +0200, Ulf Samuelsson a ?crit :
> > >> Add ID codes for most recent Atmel NOR flashes
> > > 
> > > Is there any added value on using the atmel flash driver instead of the
> > > standard CFI driver ? It surely doesn't have any on the SAM9/CAP9
> > > boards, but I'm not sure of the older AT91RM9200.
> > > 
> > > Thanks,
> > > -- 
> > > Stelian Pop <stelian at popies.net>
> > > 
> > 
> > 
> > It is mainly time related.
> > This flash driver is well tested on the AT91RM9200EK.
> > The standard CFI driver is not.
> > While CFI should work, I do not have time to make a thorough test.
> 
> Linux seems to use the CFI driver, just like every other SAM/CAP board,
> so it should be safe to switch to the standard CFI driver.

I agree with Stelian, I prefer you use the CFI driver, but I known that
there is somme difference between then. Untill you've test and qualify the CFI
driver for the AT91RM9200EK. I'll ack your patch.

Best Regards,
J.



From stelian at popies.net  Mon Apr 14 13:28:23 2008
From: stelian at popies.net (Stelian Pop)
Date: Mon, 14 Apr 2008 13:28:23 +0200
Subject: [U-Boot-Users] Uboot (AT91 tree) macb in MII mode
In-Reply-To: <4803294D.6010205@vermin.nl>
References: <4803115D.5050603@vermin.nl> <1208164139.6399.23.camel@galileo>
	<4803218C.7040600@vermin.nl> <1208166096.6399.51.camel@galileo>
	<4803294D.6010205@vermin.nl>
Message-ID: <1208172503.6399.60.camel@galileo>


Le lundi 14 avril 2008 ? 11:52 +0200, Sander Vermin a ?crit :
> >
> > The official toolchain for U-Boot is the DENX ELDK:
> > http://www.denx.de/wiki/DULG/ELDK . I don't really think this is your
> > issue, but when nothing works it may make sense to put yourself in a
> > well known configuration.
> >
> >   
> Is there some pre compiled  arm version?

ftp://ftp.denx.de/pub/eldk/4.1/arm-linux-x86/iso

ARM support in latest ELDK (4.2) seems to lag a bit ...

> >> Olimex has indeed, but that is a old version of uboot, the old ETHER 
> >> driver and not the new. I inspected the initialization code on the ARM 
> >> side, that was the same. The rest of te code is completely different, so 
> >> spotting differences is difficult.
> >>     
> >
> > Ah, I understand. However, there must be a difference somewhere. I'm not
> > sure about this board, but on the SAM boards a software reset has to be
> > performed once the PHY address is configured to activate the PHY (look
> > into at91sam9260.c). Maybe your board needs something equivalent ?
> >
> >   
> Currently I am using the at91sam9260ek config with the options above edited.

This means that you're doing the soft-reset sequence I told you above
(in boards/atmel/at91sam9260ek/at91sam9260ek.c). Maybe your board
doesn't need this, try commenting out the relevant code in
at91sam9260ek_macb_hw_init() (keep only the gpio set_A/B_periph().

-- 
Stelian Pop <stelian at popies.net>




From ulf.samuelsson at atmel.com  Mon Apr 14 13:15:43 2008
From: ulf.samuelsson at atmel.com (Ulf Samuelsson)
Date: Mon, 14 Apr 2008 13:15:43 +0200
Subject: [U-Boot-Users] [PATCH] Add support for Atmel flash
References: <1208027002.23686.7.camel@elrond.atmel.sweden>
	<1208093818.23686.11.camel@voyager.dsnet>
	<02bf01c89df4$fe986380$040514ac@atmel.com>
	<1208164773.6399.34.camel@galileo>
Message-ID: <07e001c89e24$620c3e80$dfb5fea9@atmel.com>


> 
> Le lundi 14 avril 2008 ? 08:00 +0200, Ulf Samuelsson a ?crit :
>> > Le samedi 12 avril 2008 ? 21:03 +0200, Ulf Samuelsson a ?crit :
>> >> Add ID codes for most recent Atmel NOR flashes
>> > 
>> > Is there any added value on using the atmel flash driver instead of the
>> > standard CFI driver ? It surely doesn't have any on the SAM9/CAP9
>> > boards, but I'm not sure of the older AT91RM9200.
>> > 
>> > Thanks,
>> > -- 
>> > Stelian Pop <stelian at popies.net>
>> > 
>> 
>> 
>> It is mainly time related.
>> This flash driver is well tested on the AT91RM9200EK.
>> The standard CFI driver is not.
>> While CFI should work, I do not have time to make a thorough test.
> 
> Linux seems to use the CFI driver, just like every other SAM/CAP board,
> so it should be safe to switch to the standard CFI driver.
> 
> The only remaining issue is testing, and I was hoping you could do this
> as part of the new board porting. :)
> 


This is not "porting of a new board".
This board support has existed for 3-4 years in the Atmel U-Boot.

Best Regards
Ulf Samuelsson



From sew_s at tqs.de  Mon Apr 14 14:32:50 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Mon, 14 Apr 2008 14:32:50 +0200
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
In-Reply-To: <506076.61710.qm@web51008.mail.re2.yahoo.com>
References: <506076.61710.qm@web51008.mail.re2.yahoo.com>
Message-ID: <48034EF2.1070106@tqs.de>

Hi Fabio,

Fabio Estevam schrieb:
> Hi Guennadi,
> 
> Now I generated uImage correctly and it boots fine.

How did you build this Kernel? Did you use the LTIB?

Regards
Jens



From tur at semihalf.com  Mon Apr 14 14:53:39 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Mon, 14 Apr 2008 14:53:39 +0200
Subject: [U-Boot-Users] [PATCH] Memory footprint optimizations
In-Reply-To: <20080409225610.6043224842@gemini.denx.de>
References: <20080409225610.6043224842@gemini.denx.de>
Message-ID: <480353D3.4090607@semihalf.com>

Wolfgang Denk wrote:
> In message <20080409213733.5006.37998.stgit at pollux.denx.de> you wrote:
>> As suggested by Wolfgang Denk:
>> - remove wrappers for image printing function
>> - merge getenv_verify and getenv_autostart into one parametrized function
> ...
>> -	image_print_contents (hdr);
>> +	image_print_contents (hdr, "   ");
> 
> Now we have some 20+ calls of
> 
> 	image_print_contents (hdr, "   ");
> 
> plus two calls of
> 
> 	image_print_contents (hdr, "");
> 
> Maybe there is some clever way to get rid of this second argument?

We could use the following two facts:
1. the image contents are printed with only two indentations: 0 or 3 spaces,
2. indentation with 3 spaces is used in U-Boot, indentation with 0
spaces is used in mkimage.

With the following change we could then drop the second argument altogether:

--- a/common/image.c
+++ b/common/image.c
@@ -301,8 +301,16 @@ static void image_print_type (image_header_t *hdr)
   * returns:
   *     no returned results
   */
-void image_print_contents (image_header_t *hdr, const char *p)
+void image_print_contents (image_header_t *hdr)
  {
+       const char *p;
+
+#ifdef USE_HOSTCC
+       p = "";
+#else
+       p = "   ";
+#endif
+


If the above is what is wanted, I'll prepare a patch -- comments are
welcome.

Regards,
Bartlomiej



From dzu at denx.de  Mon Apr 14 14:55:21 2008
From: dzu at denx.de (Detlev Zundel)
Date: Mon, 14 Apr 2008 14:55:21 +0200
Subject: [U-Boot-Users] System hangs while starting: get clone of
	u-boot-at91.git - part 2 of 2
In-Reply-To: <AA28F077645B324881335614E4F7C428034CBA@win-ex01.bench.com> (Ken
	Fuchs's message of "Fri, 11 Apr 2008 16:20:00 -0500")
References: <AA28F077645B324881335614E4F7C428034CBA@win-ex01.bench.com>
Message-ID: <m27if0r3ye.fsf@ohwell.denx.de>

Hi Ken,

> This problem has been repeatable for nearly the past 2 hours.
>
> I did a clone of the same git repository without any problems earlier
> today, except it wouldn't build properly.
>
> Any suggestions about what is wrong with the clone attempt and what can
> be done to fix it?

The problem was an (now) incorrect http-alternates file in the
repositories.  All repositories have been fixed.  Let me know if any
further problem appears.

Cheers
  Detlev

-- 
I have always observed that the pretensions of all people are in
exact inverse ratio to their merits; this is one of the axioms of
morals.                            -- Joseph Lagrange
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From dzu at denx.de  Mon Apr 14 15:12:37 2008
From: dzu at denx.de (Detlev Zundel)
Date: Mon, 14 Apr 2008 15:12:37 +0200
Subject: [U-Boot-Users] u-boot wiki and arch-specific details
In-Reply-To: <200804131926.41049.vapier@gentoo.org> (Mike Frysinger's message
	of "Sun, 13 Apr 2008 19:26:40 -0400")
References: <200804131926.41049.vapier@gentoo.org>
Message-ID: <m2zlrwpol6.fsf@ohwell.denx.de>

Hi Mike,

> we maintain a Blackfin-specific u-boot wiki that goes into quite a bit of 
> detail, some of which is duplicated with the main u-boot wiki.  how do people 
> feel about extending the u-boot wiki to allow for arch-specific details ?

What exactly do you have in mind?  I surely don't see any principal
problem here.

It would certainly be valuable to get all U-Boot related info collected
in a central place and have pointers wherever that make sense...

Cheers
  Detlev

-- 
In short: much of our country's [USA] counterterrorism security spending is
not designed to protect us from the terrorists,  but instead to protect our
public officials from criticism when another attack occurs.
                                   -- Bruce Schneier
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From dzu at denx.de  Mon Apr 14 15:27:14 2008
From: dzu at denx.de (Detlev Zundel)
Date: Mon, 14 Apr 2008 15:27:14 +0200
Subject: [U-Boot-Users] Use reset CMD to start another u-boot failed.
In-Reply-To: <4803049a.0fba720a.38ec.fffff326@mx.google.com> (Leon Z.'s
	message of "Mon, 14 Apr 2008 15:15:35 +0800")
References: <4803049a.0fba720a.38ec.fffff326@mx.google.com>
Message-ID: <m2ve2kpnwt.fsf@ohwell.denx.de>

Hi Leon,

You could help us a little answer your questions by giving some more
details - pretty obvious things like architecture or board name come to
mind...

> The original u-boot running on board was burn AT 0xFFF00000,
> (Flash is mapped to 0xFE000000-0xFFFFFFFF)
> The CFG_RESET_ADDRESS = 0xFE000000

What was the original U-Boot?  Was that a configuration in mainline?

Why on earth are you trying to tamper with CFG_RESET_ADDRESS?  This
should really not be changed as it is only used to do force a reset of a
board *for certain architectures*.  I am not even sure that
CFG_RESET_ADDRESS is relevant for your board.  Moreover if you read the
source code, this address is usually a *nonexistant* address to force a
machine check exception.  It is definitely not a hook to start a
different incarnation of U-Boot.

> The original and new u-boot file difference is only two place.
> 1. CONFIG_AUTOBOOT_PROMPT (use it to verify the new u-boot startup correctly)
> 2. board/myboard/config.mk->TEXT_BASE = 0xFE000000
> Then I place the new u-boot.bin file to the 0xFE000000,
> and then run the "reset" cmd from original u-boot's prompt.
>
> but it's seem the new u-boot was not startup.
> the console still print the original u-boot's CONFIG_AUTOBOOT_PROMPT.
>
> Am I miss some step? Or some where need to pay attention to?

The short answer is - only change what you need in your configuration
and replace the "original u-boot".  I have no idea why changing
CONFIG_AUTOBOOT_PROMPT needs a separate U-Boot at all.

> The original u-boot flinfo.
> Original u-boot.bin was place to the FFF00000-FFF3FFFF(2 sector)
> CFG_ENV_ADDR = FFF40000(1 sector),CFG_RESET_ADDRESS = 0xFE000000
>
>
> cilon=> flinfo
>
> Bank # 1: Intel 28F128J3A (16 Mbit, 128 x 128K)
>   Size: 16 MB in 128 Sectors
>   Sector Start Addresses:
>     FE000000      FE020000      FE040000      FE060000      FE080000     

[....]

Without any details about your board, this information is pretty useless
to us.

Cheers
  Detlev

-- 
In short: much of our country's [USA] counterterrorism security spending is
not designed to protect us from the terrorists,  but instead to protect our
public officials from criticism when another attack occurs.
                                   -- Bruce Schneier
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From plagnioj at jcrosoft.com  Mon Apr 14 15:26:38 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 14 Apr 2008 15:26:38 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
In-Reply-To: <1208030816.23686.13.camel@elrond.atmel.sweden>
References: <1208030816.23686.13.camel@elrond.atmel.sweden>
Message-ID: <20080414132638.GD17663@game.jcrosoft.org>

> +
> +	/* Correct IRDA resistor problem */
> +	/* Set PA23_TXD in Output */
> +	((AT91PS_PIO) AT91C_BASE_PIOA)->PIO_OER = AT91C_PA23_TXD2;
> +
> +	/* memory and cpu-speed are setup before relocation */
> +	/* so we do _nothing_ here */
> +
> +	/* arch number of AT91RM9200DK-Board */
> +	gd->bd->bi_arch_number = MACH_TYPE_AT91RM9200EK;
> +	/* adress of boot parameters */
> +	gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
> +
> +	return 0;
> +}
> +
> +int dram_init (void)
> +{
> +	gd->bd->bi_dram[0].start = PHYS_SDRAM;
> +	gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
> +	return 0;
> +}
> +
> +#ifdef CONFIG_DRIVER_ETHER
> +#if defined(CONFIG_CMD_NET)
Could you put it on the same line
> +
> +/*
> + * Name:
> + *	at91rm9200_GetPhyInterface
> + * Description:
> + *	Initialise the interface functions to the PHY
> + * Arguments:
> + *	None
> + * Return value:
> + *	None
> + */
> +void at91rm9200_GetPhyInterface(AT91PS_PhyOps p_phyops)
> +{
> +	p_phyops->Init = dm9161_InitPhy;
> +	p_phyops->IsPhyConnected = dm9161_IsPhyConnected;
> +	p_phyops->GetLinkSpeed = dm9161_GetLinkSpeed;
> +	p_phyops->AutoNegotiate = dm9161_AutoNegotiate;
> +}
> +
> +#endif
> +#endif	/* CONFIG_DRIVER_ETHER */
> +
> +/*
> + * Disk On Chip (NAND) Millenium initialization.
> + * The NAND lives in the CS2* space
> + */
> +#if defined(CONFIG_CMD_NAND)
> +extern ulong nand_probe (ulong physadr);
> +
> +#define AT91_SMARTMEDIA_BASE 0x40000000	/* physical address to access memory on NCS3 */
> +void nand_init (void)
> +{
> +	/* Setup Smart Media, fitst enable the address range of CS3 */
> +	*AT91C_EBI_CSA |= AT91C_EBI_CS3A_SMC_SmartMedia;
> +	/* set the bus interface characteristics based on
> +	   tDS Data Set up Time 30 - ns
> +	   tDH Data Hold Time 20 - ns
> +	   tALS ALE Set up Time 20 - ns
> +	   16ns at 60 MHz ~= 3  */
Please use this style of comment
/*
 * .......
 */
> +/*memory mapping structures */
> +#define SM_ID_RWH	(5 << 28)
> +#define SM_RWH		(1 << 28)
> +#define SM_RWS		(0 << 24)
> +#define SM_TDF		(1 << 8)
> +#define SM_NWS		(3)
> +	AT91C_BASE_SMC2->SMC2_CSR[3] = (SM_RWH | SM_RWS |
> +		AT91C_SMC2_ACSS_STANDARD | AT91C_SMC2_DBW_8 |
> +		SM_TDF | AT91C_SMC2_WSEN | SM_NWS);
> +
> +	/* enable the SMOE line PC0=SMCE, A21=CLE, A22=ALE */
> +	*AT91C_PIOC_ASR = AT91C_PC0_BFCK | AT91C_PC1_BFRDY_SMOE |
> +		AT91C_PC3_BFBAA_SMWE;
> +	*AT91C_PIOC_PDR = AT91C_PC0_BFCK | AT91C_PC1_BFRDY_SMOE |
> +		AT91C_PC3_BFBAA_SMWE;
> +
> +	/* Configure PC2 as input (signal READY of the SmartMedia) */
> +	*AT91C_PIOC_PER = AT91C_PC2_BFAVD;	/* enable direct output enable */
> +	*AT91C_PIOC_ODR = AT91C_PC2_BFAVD;	/* disable output */
> +
> +	/* Configure PB1 as input (signal Card Detect of the SmartMedia) */
> +	*AT91C_PIOB_PER = AT91C_PIO_PB1;	/* enable direct output enable */
> +	*AT91C_PIOB_ODR = AT91C_PIO_PB1;	/* disable output */
> +
> +	/* PIOB and PIOC clock enabling */
> +	*AT91C_PMC_PCER = 1 << AT91C_ID_PIOB;
> +	*AT91C_PMC_PCER = 1 << AT91C_ID_PIOC;
> +ulong myflush(void);
> +
> +
> +/* Flash Organization Structure */
> +typedef struct OrgDef
> +{
> +	unsigned int sector_number;
> +	unsigned int sector_size;
> +} OrgDef;
Do not start car name with Upercase
> +
> +
> +/* Flash Organizations */
> +OrgDef OrgAT49BV16x4[] =
> +{
> +	{  8,  8*1024 },	/*   8 *  8 kBytes sectors */
> +	{  2, 32*1024 },	/*   2 * 32 kBytes sectors */
> +	{ 30, 64*1024 },	/*  30 * 64 kBytes sectors */
> +};
> +
> +OrgDef OrgAT49BV16x4A[] =
> +{
> +	{  8,  8*1024 },	/*   8 *  8 kBytes sectors */
> +	{ 31, 64*1024 },	/*  31 * 64 kBytes sectors */
> +};
> +
> +OrgDef OrgAT49BV6416[] =
> +{
> +	{   8,  8*1024 },	/*   8 *  8 kBytes sectors */
> +	{ 127, 64*1024 },	/* 127 * 64 kBytes sectors */
> +};
> +
> +flash_info_t    flash_info[CFG_MAX_FLASH_BANKS];
> +
> +/* AT49BV1614A Codes */
> +#define FLASH_CODE1		0xAA
> +#define FLASH_CODE2		0x55
> +#define ID_IN_CODE		0x90
> +#define ID_OUT_CODE		0xF0
> +
Please remove one empty line
> +
> +#define CMD_READ_ARRAY		0x00F0
> +#define CMD_UNLOCK1		0x00AA
> +#define CMD_UNLOCK2		0x0055
> +#define CMD_ERASE_SETUP		0x0080
> +#define CMD_ERASE_CONFIRM	0x0030
> +#define CMD_PROGRAM		0x00A0
> +		printf ("AT49BV6416 (64Mbit)\n");
> +	}
> +}
> +
> +ushort flash_number_sector(OrgDef *pOrgDef, unsigned int nb_blocks)
> +{
> +	int i, nb_sectors = 0;
please split it in 2 lines
> +
> +	for (i=0; i<nb_blocks; i++){
> +		nb_sectors += pOrgDef[i].sector_number;
> +	}
	for (i=0; i<nb_blocks; i++)
		nb_sectors += pOrgDef[i].sector_number;
> +
> +	return nb_sectors;
> +}
> +
> +void flash_unlock_sector(flash_info_t * info, unsigned int sector)
> +{
> +	volatile u16 *addr = (volatile u16 *) (info->start[sector]);
> +
> +	MEM_FLASH_ADDR1 = CMD_UNLOCK1;
> +	*addr = CMD_SECTOR_UNLOCK;
> +}
> +
> +
> +ulong flash_init (void)
> +{
> +	int i, j, k;
> +	unsigned int flash_nb_blocks, sector;
> +	unsigned int start_address;
> +	OrgDef *pOrgDef;
> +
Please remove empty line
> +	ulong size = 0;
> +
> +	for (i = 0; i < CFG_MAX_FLASH_BANKS; i++) {
> +		ulong flashbase = 0;
> +
> +		flash_identification (&flash_info[i]);
> +
> +		if ((flash_info[i].flash_id & FLASH_TYPEMASK) ==
> +			(ATM_ID_BV1614 & FLASH_TYPEMASK)) {
> +
> +			pOrgDef = OrgAT49BV16x4;
> +			flash_nb_blocks = sizeof (OrgAT49BV16x4) / sizeof (OrgDef);
> +		} else if ((flash_info[i].flash_id & FLASH_TYPEMASK) ==
> +	for (i = 0; i < info->sector_count; i++) {
> +		if ((i % 5) == 0) {
> +			printf ("\n   ");
> +		}
> +		
Please remove whitespace
> +		if(info->protect[i] != FLAG_PROTECT_INVALID) {
> +			printf (" %08lX%s", info->start[i],
> +				info->protect[i] ? " (RO)" : "     ");
> +		}
> +	}
> +	printf ("\n");
> +}
> +
> +/*-----------------------------------------------------------------------
> + */
> +
> +int flash_erase (flash_info_t * info, int s_first, int s_last)
> +{
> +	ulong result;
> +	int iflag, cflag, prot, sect;
> +	int rc = ERR_OK;
> +	int chip1;
> +
> +	/* first look for protection bits */
> +
> +	if (info->flash_id == FLASH_UNKNOWN)
> +		return ERR_UNKNOWN_FLASH_TYPE;
> +
> +	if ((s_first < 0) || (s_first > s_last)) {
> +		return ERR_INVAL;
> +	}
please like this
	if ((s_first < 0) || (s_first > s_last))
		return ERR_INVAL;

and please the same for the other
> +
> +	if ((info->flash_id & FLASH_VENDMASK) !=
> +		(ATM_MANUFACT & FLASH_VENDMASK)) {
> +		return ERR_UNKNOWN_FLASH_VENDOR;
> +	}
> +
> +	prot = 0;
> +	for (sect = s_first; sect <= s_last; ++sect) {
> +		if (info->protect[sect]) {
> +			prot++;
> +		}
> +void	green_LED_off(void)
> +{
> +	AT91PS_PIO	PIOB	= AT91C_BASE_PIOB;
> +	PIOB->PIO_SODR		= GREEN_LED;
> +}
> +
> +void	yellow_LED_off(void)
> +{
> +	AT91PS_PIO	PIOB	= AT91C_BASE_PIOB;
> +	PIOB->PIO_SODR		= YELLOW_LED;
> +}
> +
> +void	red_LED_off(void)
> +{
> +	AT91PS_PIO	PIOB	= AT91C_BASE_PIOB;
> +	PIOB->PIO_SODR		= RED_LED;
> +}
> +
> +
> +void coloured_LED_init (void)
> +{
> +	DECLARE_GLOBAL_DATA_PTR;
> +	AT91PS_PIO	PIOB	= AT91C_BASE_PIOB;
> +	AT91PS_PMC	PMC	= AT91C_BASE_PMC;
Please add an empty line
> +	PMC->PMC_PCER		= (1 << AT91C_ID_PIOB);	/* Enable PIOB clock */
> +	/* Disable peripherals on LEDs */
> +	PIOB->PIO_PER		= AT91C_PIO_PB2 | AT91C_PIO_PB1 | AT91C_PIO_PB0;
> +	/* Enable pins as outputs */
> +	PIOB->PIO_OER		= AT91C_PIO_PB2 | AT91C_PIO_PB1 | AT91C_PIO_PB0;
> +	/* Turn all LEDs OFF */
> +	PIOB->PIO_SODR		= AT91C_PIO_PB2 | AT91C_PIO_PB1 | AT91C_PIO_PB0;
> +}
> diff -urN u-boot.cmp/board/atmel/at91rm9200ek/Makefile u-boot/board/atmel/at91rm9200ek/Makefile
> --- u-boot.cmp/board/atmel/at91rm9200ek/Makefile	1970-01-01 01:00:00.000000000 +0100
> +++ u-boot/board/atmel/at91rm9200ek/Makefile	2008-04-12 21:56:14.000000000 +0200
> @@ -0,0 +1,50 @@
> +#
> +# (C) Copyright 2003
> +# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
> +#
> +# See file CREDITS for list of people who contributed to this
> +# project.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation; either version 2 of
> +# the License, or (at your option) any later version.
> + *
> + * This program is 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 <common.h>
> +#include <asm/arch/AT91RM9200.h>
> +#include <at91rm9200_net.h>
> +#include <dm9161.h>
> +
> +int board_late_init(void)
> +{
> +	DECLARE_GLOBAL_DATA_PTR;
> +	
please remove whitespace
> +	/* Fix Ethernet Initialization Bug when starting Linux from U-Boot */
> +	eth_init(gd->bd);
> +	return 0;
> +}
> +
> +
> +/* checks if addr is in RAM */
> +int addr2ram(ulong addr) {
> +  int result = 0;
> +  
please remove whitespace
> +  if((addr >= PHYS_SDRAM) && (addr < (PHYS_SDRAM + PHYS_SDRAM_SIZE)))
> +    result = 1;
> +
> +  return result;
> +}
> +
> diff -urN u-boot.cmp/board/atmel/at91rm9200ek/mux.c u-boot/board/atmel/at91rm9200ek/mux.c
> --- u-boot.cmp/board/atmel/at91rm9200ek/mux.c	1970-01-01 01:00:00.000000000 +0100
> +++ u-boot/board/atmel/at91rm9200ek/mux.c	2008-04-12 21:15:08.000000000 +0200
> @@ -0,0 +1,37 @@
> +#include <config.h>
> +#include <common.h>
> +#include <asm/hardware.h>
> +#include <dataflash.h>
> +
> +int AT91F_GetMuxStatus(void) {
> +#ifdef	DATAFLASH_MMC_SELECT
> +	AT91C_BASE_PIOB->PIO_PER = DATAFLASH_MMC_SELECT; /* Set in PIO mode */
> +	AT91C_BASE_PIOB->PIO_OER = DATAFLASH_MMC_SELECT; /* Configure in output */
> +
> +
please remothe 1 empty line
> +	if(AT91C_BASE_PIOB->PIO_ODSR & DATAFLASH_MMC_SELECT) {
> +		return 1;
> +	} else {
> +		return 0;
> +	}
> +#endif
> +	return 0;
> +}
> +
> +void AT91F_SelectMMC(void) {
> +#ifdef	DATAFLASH_MMC_SELECT
> +	AT91C_BASE_PIOB->PIO_PER = DATAFLASH_MMC_SELECT;	/* Set in PIO mode */
> +	AT91C_BASE_PIOB->PIO_OER = DATAFLASH_MMC_SELECT;	/* Configure in output */
> +	/* Set Output */
> +	AT91C_BASE_PIOB->PIO_SODR = DATAFLASH_MMC_SELECT;
> +#endif
> +}
> +
> +void AT91F_SelectSPI(void) {
> +#ifdef	DATAFLASH_MMC_SELECT
> +	AT91C_BASE_PIOB->PIO_PER = DATAFLASH_MMC_SELECT;	/* Set in PIO mode */
> +	AT91C_BASE_PIOB->PIO_OER = DATAFLASH_MMC_SELECT;	/* Configure in output */
> +	/* Clear Output */
> +	AT91C_BASE_PIOB->PIO_CODR = DATAFLASH_MMC_SELECT;
> +#endif
> +}
> diff -urN u-boot.cmp/board/atmel/at91rm9200ek/partition.c u-boot/board/atmel/at91rm9200ek/partition.c
> --- u-boot.cmp/board/atmel/at91rm9200ek/partition.c	1970-01-01 01:00:00.000000000 +0100
> +++ u-boot/board/atmel/at91rm9200ek/partition.c	2008-04-12 20:35:54.000000000 +0200
> @@ -0,0 +1,38 @@
> +/*
> + *
> + * 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 <common.h>
> +#include <config.h>
> +#include <asm/hardware.h>
> +#include <dataflash.h>
> +
> +AT91S_DATAFLASH_INFO dataflash_info[CFG_MAX_DATAFLASH_BANKS];
> +
> +struct dataflash_addr cs[CFG_MAX_DATAFLASH_BANKS] = {
> +	{CFG_DATAFLASH_LOGIC_ADDR_CS0, 0},	/* Logical adress, CS */
> +	{CFG_DATAFLASH_LOGIC_ADDR_CS3, 3}
> +};
> +
> +/*define the area offsets*/
> +dataflash_protect_t area_list[NB_DATAFLASH_AREA] = {
> +	{0x00000000, 0x000041FF, FLAG_PROTECT_SET,   0, "Bootstrap"},
> +	{0x00004200, 0x000083FF, FLAG_PROTECT_CLEAR, 0, "Environment"},
> +	{0x00008400, 0x00041FFF, FLAG_PROTECT_SET,   0, "U-Boot"},
> +	{0x00042000, 0x00251FFF, FLAG_PROTECT_CLEAR, 0,	"Kernel"},
> +	{0x00252000, 0xFFFFFFFF, FLAG_PROTECT_CLEAR, 0,	"FS"},
> +};
Coulde create a default one?
> diff -urN u-boot.cmp/board/atmel/at91rm9200ek/u-boot.lds u-boot/board/atmel/at91rm9200ek/u-boot.lds
> --- u-boot.cmp/board/atmel/at91rm9200ek/u-boot.lds	1970-01-01 01:00:00.000000000 +0100
> +++ u-boot/board/atmel/at91rm9200ek/u-boot.lds	2008-04-12 21:15:08.000000000 +0200
> @@ -0,0 +1,57 @@
> +/*
> + * (C) Copyright 2002
> + * Gary Jennejohn, DENX Software Engineering, <gj at denx.de>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
> +/*OUTPUT_FORMAT("elf32-arm", "elf32-arm", "elf32-arm")*/
please remove it
> +OUTPUT_ARCH(arm)
> +ENTRY(_start)
> +SECTIONS
> +{
> +	. = 0x00000000;
> +
> +	. = ALIGN(4);
> +	.text      :
> +	{
> +	  cpu/arm920t/start.o	(.text)
> +	  *(.text)
> +	}
> +
> +	. = ALIGN(4);
> +	.rodata : { *(.rodata) }
> +
> +	. = ALIGN(4);
> +	.data : { *(.data) }
> +
> +	. = ALIGN(4);
> +	.got : { *(.got) }
> +
> +	. = .;
> +	__u_boot_cmd_start = .;
> +	.u_boot_cmd : { *(.u_boot_cmd) }
> +	__u_boot_cmd_end = .;
> +
> +	. = ALIGN(4);
> +	__bss_start = .;
> +	.bss : { *(.bss) }
> +	_end = .;
> +}
> Filerna u-boot.cmp/.git/index och u-boot/.git/index skiljer
> diff -urN u-boot.cmp/include/configs/at91rm9200ek.h u-boot/include/configs/at91rm9200ek.h
> --- u-boot.cmp/include/configs/at91rm9200ek.h	1970-01-01 01:00:00.000000000 +0100
> +++ u-boot/include/configs/at91rm9200ek.h	2008-04-12 22:01:34.000000000 +0200
> @@ -0,0 +1,267 @@
> +/*
> + * Ulf Samuelsson <ulf at atmel.com>
> + * Rick Bronson <rick at efn.org>
> + *
> + * Configuration settings for the AT91RM9200EK board.
> + *
> + * 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
> + */
> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +/* ARM asynchronous clock */
> +#define AT91C_MAIN_CLOCK	179712000	/* from 18.432 MHz crystal (18432000 / 4 * 39) */
> +#define AT91C_MASTER_CLOCK	59904000	/* peripheral clock (AT91C_MASTER_CLOCK / 3) */
> +/* #define AT91C_MASTER_CLOCK	44928000 */	/* peripheral clock (AT91C_MASTER_CLOCK / 4) */
please remove it
> +
> +#define AT91_SLOW_CLOCK		32768	/* slow clock */
> +
> +#define CONFIG_ARM920T		1	/* This is an ARM920T Core	*/
> +#define CONFIG_AT91RM9200	1	/* It's an Atmel AT91RM9200 SoC	*/
> +#define CONFIG_AT91RM9200EK	1	/* on an AT91RM9200DK Board	*/
> +#undef  CONFIG_USE_IRQ			/* we don't need IRQ/FIQ stuff */	
Please remove the whitespace
> +#define USE_920T_MMU		1
> +
> +#define CONFIG_CMDLINE_TAG	1	/* enable passing of ATAGs	*/
> +
> +#undef	CONFIG_HWFLOW			/* don't include RTS/CTS flow control support	*/
> +
> +#undef	CONFIG_MODEM_SUPPORT		/* disable modem initialization stuff */
> +
> +#define CONFIG_BOOTDELAY      3
> +/* #define CONFIG_ENV_OVERWRITE	1 */
> +
> +/*
> + * BOOTP options
> + */
> +#define CONFIG_BOOTP_BOOTFILESIZE
> +#define CONFIG_BOOTP_BOOTPATH
> +#define CONFIG_BOOTP_GATEWAY
> +#define CONFIG_BOOTP_HOSTNAME
> +
please remove 1 empty line
> +
> +/*
> + * Command line configuration.
> + */
> +#include <config_cmd_default.h>
> +
> +#define CONFIG_CMD_MII
> +#define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_FAT
> +#define CONFIG_CMD_MUX
> +#define CFG_MEMTEST_END			CFG_MEMTEST_START + PHYS_SDRAM_SIZE - 262144
> +
> +#define CONFIG_DRIVER_ETHER
> +#define CONFIG_NET_RETRY_COUNT		20
> +#define CONFIG_AT91C_USE_RMII
> +
> +/* AC Characteristics */
> +/* DLYBS = tCSS = 250ns min and DLYBCT = tCSH = 250ns */
> +#define DATAFLASH_TCSS	(0xC << 16)
> +#define DATAFLASH_TCHS	(0x1 << 24)
> +
> +#define CONFIG_HAS_DATAFLASH		1
> +#define CFG_SPI_WRITE_TOUT		(5*CFG_HZ)
> +#define CFG_MAX_DATAFLASH_BANKS 	2
please remove whitespace
> +#define CFG_MAX_DATAFLASH_PAGES 	16384
please remove whitespace
> +#define CFG_DATAFLASH_LOGIC_ADDR_CS0	0xC0000000	/* Logical adress for CS0 */
> +#define CFG_DATAFLASH_LOGIC_ADDR_CS3	0xD0000000	/* Logical adress for CS3 */
> +#define	CFG_SUPPORT_BLOCK_ERASE		1
> +#define	DATAFLASH_MMC_SELECT		AT91C_PIO_PB22
> +
> +#define PHYS_FLASH_1			0x10000000
> +#define PHYS_FLASH_SIZE			0x800000  /* 8 megs main flash */
> +#define CFG_FLASH_BASE			PHYS_FLASH_1
> +#define CFG_MAX_FLASH_BANKS		1
> +#define CFG_MAX_FLASH_SECT		256
> +#define CFG_FLASH_ERASE_TOUT		(2*CFG_HZ) /* Timeout for Flash Erase */
> +#define CFG_FLASH_WRITE_TOUT		(2*CFG_HZ) /* Timeout for Flash Write */
> +
> +#define	CFG_ENV_IS_IN_DATAFLASH		1
> +
> +#ifdef CFG_ENV_IS_IN_DATAFLASH
> +
> +#define CFG_ENV_OFFSET			0x4200
> +#define CFG_ENV_ADDR			(CFG_DATAFLASH_LOGIC_ADDR_CS0 + CFG_ENV_OFFSET)
> +#define CFG_ENV_SIZE			0x2000  /* 8 * 1056 really , but start.s is not OK with this*/
> +
> +#else
> +#define CFG_ENV_IS_IN_FLASH		1
> +#ifdef CONFIG_SKIP_LOWLEVEL_INIT
> +#define CFG_ENV_ADDR			(PHYS_FLASH_1 + 0x60000)  /* after u-boot.bin */
> +#define CFG_ENV_SIZE			0x10000 /* sectors are 64K here */
> +#else
> +#define CFG_ENV_ADDR			(PHYS_FLASH_1 + 0xe000)  /* between boot.bin and u-boot.bin.gz */
> +#define CFG_ENV_SIZE			0x2000  /* 0x8000 */
> +#endif	/* CONFIG_SKIP_LOWLEVEL_INIT */
> +#endif	/* CFG_ENV_IS_IN_DATAFLASH */
> +
> +
please remove 1 empty line
> +#define CFG_LOAD_ADDR		0x21000000  /* default load address */
> +
> +#ifdef CONFIG_SKIP_LOWLEVEL_INIT
> +#define CFG_BOOT_SIZE		0x00 /* 0 KBytes */
> +#define CFG_U_BOOT_BASE		PHYS_FLASH_1
> +#define CFG_U_BOOT_SIZE		0x60000 /* 384 KBytes */
> +#else
> +#define CFG_BOOT_SIZE		0x6000 /* 24 KBytes */
> +#define CFG_U_BOOT_BASE		(PHYS_FLASH_1 + 0x10000)
> +#define CFG_U_BOOT_SIZE		0x10000 /* 64 KBytes */
> +#endif	/* CONFIG_SKIP_LOWLEVEL_INIT */
> +
> +#define CFG_BAUDRATE_TABLE	{115200 , 19200, 38400, 57600, 9600 }
> +
> +#define CFG_PROMPT		"U-Boot> "	/* Monitor Command Prompt */
> +#define CFG_CBSIZE		256		/* Console I/O Buffer Size */
> +#define CFG_MAXARGS		16		/* max number of command args */
> +#define CFG_PBSIZE		(CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /* Print Buffer Size */
> +
> +#ifndef __ASSEMBLY__
> +/*-----------------------------------------------------------------------
> + * Board specific extension for bd_info
> + *
> + * This structure is embedded in the global bd_info (bd_t) structure
> + * and can be used by the board specific code (eg board/...)
> + */
> +
> +struct bd_info_ext {
> +	/* helper variable for board environment handling
> +	 *
> +	 * env_crc_valid == 0    =>   uninitialised
> +	 * env_crc_valid  > 0    =>   environment crc in flash is valid
> +	 * env_crc_valid  < 0    =>   environment crc in flash is invalid
> +	 */
> +	int env_crc_valid;
> +};
> +#endif
> +
> +#define CFG_HZ 1000
> +#define CFG_HZ_CLOCK AT91C_MASTER_CLOCK/2	/* AT91C_TC0_CMR is implicitly set to */
Please algin them
> +					/* AT91C_TC_TIMER_DIV1_CLOCK */
> +
> +#define CONFIG_STACKSIZE	(32*1024)	/* regular stack */
> +#define CONFIG_STACKSIZE_IRQ  	(4*1024)        /* IRQ stack */
please remove whitespace
> +#define CONFIG_STACKSIZE_FIQ  	(4*1024) 
please remove whitespace
> +/*
> +#ifdef CONFIG_USE_IRQ
> +#error CONFIG_USE_IRQ not supported
> +#endif
> +*/
please remove it
> +#endif
Best Regards,
J.



From fabioestevam at yahoo.com  Mon Apr 14 15:44:04 2008
From: fabioestevam at yahoo.com (Fabio Estevam)
Date: Mon, 14 Apr 2008 06:44:04 -0700 (PDT)
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
In-Reply-To: <48034EF2.1070106@tqs.de>
Message-ID: <837660.62709.qm@web51009.mail.re2.yahoo.com>

Hi Jens,

Yes, I used LTIB for building the kernel:

export SYSCFG_KTARG=uImage
./ltib -p kernel -m prep
./ltib -p kernel -m scbuild
./ltib -p kernel -m scdeploy

The uImage is generated at:
.../rpm/BUILD/linux/arch/arm/boot/uImage 

Regards,

Fabio Estevam

--- Jens Gehrlein <sew_s at tqs.de> wrote:

> Hi Fabio,
> 
> Fabio Estevam schrieb:
> > Hi Guennadi,
> > 
> > Now I generated uImage correctly and it boots
> fine.
> 
> How did you build this Kernel? Did you use the LTIB?
> 
> Regards
> Jens
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008
> JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still
> time to save $100. 
> Use priority code J8TL2D2. 
>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ



From tur at semihalf.com  Mon Apr 14 15:44:16 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Mon, 14 Apr 2008 15:44:16 +0200
Subject: [U-Boot-Users] [PATCH] Boot-related documentation update
In-Reply-To: <338C97F4-E6A0-47B3-94AB-3D8E6EA9BBDA@kernel.crashing.org>
References: <338C97F4-E6A0-47B3-94AB-3D8E6EA9BBDA@kernel.crashing.org>
Message-ID: <20080414134306.15603.84966.stgit@pollux.denx.de>

- document 'bootm_low' and 'bootm_size' environment variables
- update inaccurate CFG_BOOTMAPSZ entry

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---
Addressed comment by Kumar, changed patch description accordingly.

 README |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 5d059e7..63b1417 100644
--- a/README
+++ b/README
@@ -1994,8 +1994,11 @@ Configuration Settings:
 - CFG_BOOTMAPSZ:
 		Maximum size of memory mapped by the startup code of
 		the Linux kernel; all data that must be processed by
-		the Linux kernel (bd_info, boot arguments, eventually
-		initrd image) must be put below this limit.
+		the Linux kernel (bd_info, boot arguments, FDT blob if
+		used) must be put below this limit, unless "bootm_low"
+		enviroment variable is defined and non-zero. In such case
+		all data for the Linux kernel must be between "bootm_low"
+		and "bootm_low" + CFG_BOOTMAPSZ.
 
 - CFG_MAX_FLASH_BANKS:
 		Max number of Flash memory banks
@@ -2733,6 +2736,20 @@ Some configuration options can be set using Environment Variables:
 
   bootfile	- Name of the image to load with TFTP
 
+  bootm_low	- Memory range available for image processing in the bootm
+		  command can be restricted. This variable is given as
+		  a hexadecimal number and defines lowest address allowed
+		  for use by the bootm command. See also "bootm_size"
+		  environment variable. Address defined by "bootm_low" is
+		  also the base of the initial memory mapping for the Linux
+		  kernel -- see the descripton of CFG_BOOTMAPSZ.
+
+  bootm_size	- Memory range available for image processing in the bootm
+		  command can be restricted. This variable is given as
+		  a hexadecimal number and defines the size of the region
+		  allowed for use by the bootm command. See also "bootm_low"
+		  environment variable.
+
   autoload	- if set to "no" (any string beginning with 'n'),
 		  "bootp" will just load perform a lookup of the
 		  configuration from the BOOTP server, but not try to




From sew_s at tqs.de  Mon Apr 14 16:34:25 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Mon, 14 Apr 2008 16:34:25 +0200
Subject: [U-Boot-Users] Loading a kernel on MX31ADS using U-boot
In-Reply-To: <837660.62709.qm@web51009.mail.re2.yahoo.com>
References: <837660.62709.qm@web51009.mail.re2.yahoo.com>
Message-ID: <48036B71.9030704@tqs.de>

Fabio Estevam schrieb:
> Hi Jens,
> 
> Yes, I used LTIB for building the kernel:
> 
> export SYSCFG_KTARG=uImage
> ./ltib -p kernel -m prep
> ./ltib -p kernel -m scbuild
> ./ltib -p kernel -m scdeploy
> 
> The uImage is generated at:
> .../rpm/BUILD/linux/arch/arm/boot/uImage 
> 
> Regards,
> 
> Fabio Estevam

Thank you very much.
I will try it as soon as I come to the Linux part.

Regards
Jens



From galak at kernel.crashing.org  Mon Apr 14 16:02:01 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Mon, 14 Apr 2008 09:02:01 -0500
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: <20080414064659.GB17663@game.jcrosoft.org>
References: <Pine.LNX.4.64.0803261812210.5050@axis700.grange>
	<20080414064659.GB17663@game.jcrosoft.org>
Message-ID: <E1DB3CD3-DC33-48DC-85AD-B906995D0823@kernel.crashing.org>


On Apr 14, 2008, at 1:46 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 20:40 Wed 26 Mar     , Guennadi Liakhovetski wrote:
>> From: Sascha Hauer <s.hauer at pengutronix.de>
>>
>> This patch adds an i2c driver for Freescale i.MX processors
>>
>> Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
>> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
>>
>> ---
>>
>> No changes wrt v1
>>
>> drivers/i2c/Makefile  |    1 +
>> drivers/i2c/mxc_i2c.c |  202 +++++++++++++++++++++++++++++++++++++++ 
>> ++++++++++
>> 2 files changed, 203 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/i2c/mxc_i2c.c
>>
>> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
>> index 29d6c03..071ef00 100644
>> --- a/drivers/i2c/Makefile
>> +++ b/drivers/i2c/Makefile
>> @@ -29,6 +29,7 @@ COBJS-y += fsl_i2c.o
>> COBJS-y += omap1510_i2c.o
>> COBJS-y += omap24xx_i2c.o
>> COBJS-y += tsi108_i2c.o
>> +COBJS-y += mxc_i2c.o
>>
>> COBJS	:= $(COBJS-y)
>> SRCS 	:= $(COBJS:.o=.c)
>> diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
>> new file mode 100644
>> index 0000000..a218329
>> --- /dev/null
>> +++ b/drivers/i2c/mxc_i2c.c
>> @@ -0,0 +1,202 @@
>> +/*
>> + * i2c driver for Freescale mx31
>> + *
>> + * (c) 2007 Pengutronix, Sascha Hauer <s.hauer at pengutronix.de>
>> + *
>> + * See file CREDITS for list of people who contributed to this
>> + * project.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>> + * MA 02111-1307 USA
>> + */
>> +
>> +#include <common.h>
>> +
>> +#if defined(CONFIG_HARD_I2C) && defined (CONFIG_I2C_MXC)
> Please stop to define this here, move it the Makefile
>
> Wolfgang,
> Is it possible to NACK all patch that add new driver that do this

Also, I believe the imx I2C is the same as the PPC I2C HW.  I havent  
verified this but the register set looks oddly identical.

- k



From scottwood at freescale.com  Mon Apr 14 18:34:55 2008
From: scottwood at freescale.com (Scott Wood)
Date: Mon, 14 Apr 2008 11:34:55 -0500
Subject: [U-Boot-Users] [PATCH 1/2] Don't panic if a controller driver
	does ecc its own way.
In-Reply-To: <20080413220154.ED2CB248B9@gemini.denx.de>
References: <20080324175302.GA1280@ld0162-tx32.am.freescale.net>
	<20080413220154.ED2CB248B9@gemini.denx.de>
Message-ID: <20080414163455.GA7061@ld0162-tx32.am.freescale.net>

On Mon, Apr 14, 2008 at 12:01:54AM +0200, Wolfgang Denk wrote:
> In message <20080324175302.GA1280 at ld0162-tx32.am.freescale.net> you wrote:
> > Some hardware, such as the enhanced local bus controller used on some
> > mpc83xx chips, does ecc transparently when reading and writing data, rather
> > than providing a generic calculate/correct mechanism that can be exported to
> > the nand subsystem.
> > 
> > The subsystem should not BUG() when calculate, correct, or hwctl are
> > missing, if the methods that call them have been overridden.
> > 
> > Signed-off-by: Scott Wood <scottwood at freescale.com>
> 
> This should go through the 83xx custodian, but I haven't seen this
> yet?

Why should it go through 83xx?  It's a patch against generic NAND code.

> Anyway, it does not apply any more:
> 
> Applying Don't panic if a controller driver does ecc its own way.
> error: patch failed: drivers/mtd/nand/nand_base.c:2593
> error: drivers/mtd/nand/nand_base.c: patch does not apply
> fatal: sha1 information is lacking or useless
> (drivers/mtd/nand/nand_base.c).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.

Did you try applying it against the 2.6.22.1 branch of the nand
repository (IIRC, the non-commit-message patch comment specified that)?

-Scott



From becky.bruce at freescale.com  Mon Apr 14 18:39:17 2008
From: becky.bruce at freescale.com (Becky Bruce)
Date: Mon, 14 Apr 2008 11:39:17 -0500
Subject: [U-Boot-Users] SYNC definition problem
In-Reply-To: <147FF9C26CABB646A5A97CC5B270727E04246120@az33exm20.fsl.freescale.net>
References: <147FF9C26CABB646A5A97CC5B270727E04246120@az33exm20.fsl.freescale.net>
Message-ID: <9FEBF552-CEFA-476D-AED4-39F1CE2252CF@freescale.com>


On Apr 11, 2008, at 5:27 PM, Yang Ronda wrote:
> Hi,
>
> I was trying to turn on I-Cache while u-boot is executing out of  
> Flash on MPC5121 ADS board, and just found the board refused to  
> boot. After debug and tried many different ways, we finally found  
> that the root of the problem is the SYNC macro definition in u-boot  
> include/ppc_asm.tmpl file. The SYNC was defined as
>
> #define SYNC \
>  sync; \
>  isync

The problem isn't the macro definition.  That macro is used all over  
the place - changing global macros to fix a single problem is not a  
good idea unless there's something inherently wrong with the macro.   
Which there isn't, in this case.

>
> By turning on I-cache on powerpc e300 core, ICE bit of HID0 needs  
> to be set. Before setting ICE, an isync operation need to be  
> issued. In the cpu/mpc512x/start.S file, this is done by using a  
> 'SYNC' statement. But we found we need to add one more sync  
> operation to guarantee isync is complete.

You should only need a single isync before writing the ICE bit.  I  
looked at that file, and everywhere I see a write to the ICE bit,  
there's no SYNC macro being used. Have you changed the code?  It's  
likely that something completely different is causing your problem,  
and the extra sync is masking the problem.

-Becky




From vapier at gentoo.org  Mon Apr 14 19:34:57 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 14 Apr 2008 13:34:57 -0400
Subject: [U-Boot-Users] u-boot wiki and arch-specific details
In-Reply-To: <m2zlrwpol6.fsf@ohwell.denx.de>
References: <200804131926.41049.vapier@gentoo.org>
	<m2zlrwpol6.fsf@ohwell.denx.de>
Message-ID: <200804141334.57715.vapier@gentoo.org>

On Monday 14 April 2008, Detlev Zundel wrote:
> > we maintain a Blackfin-specific u-boot wiki that goes into quite a bit of
> > detail, some of which is duplicated with the main u-boot wiki.  how do
> > people feel about extending the u-boot wiki to allow for arch-specific
> > details ?
>
> What exactly do you have in mind?  I surely don't see any principal
> problem here.
>
> It would certainly be valuable to get all U-Boot related info collected
> in a central place and have pointers wherever that make sense...

from my reading of the wiki, it's more of a technical/command reference than a 
guide.  the wiki we maintain is geared to be more of a guide.  i think the 
two can be merged, i just dont want to convert things only to find out people 
dont want to take it that direction.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080414/e371cb7b/attachment.pgp 

From dzu at denx.de  Mon Apr 14 19:44:58 2008
From: dzu at denx.de (Detlev Zundel)
Date: Mon, 14 Apr 2008 19:44:58 +0200
Subject: [U-Boot-Users] [PATCH] bugfix: the watchdog post for lwmon5
In-Reply-To: <20080414063340.D00D6248C1@gemini.denx.de> (Wolfgang Denk's
	message of "Mon, 14 Apr 2008 08:33:40 +0200")
References: <20080414063340.D00D6248C1@gemini.denx.de>
Message-ID: <m2iqyknxet.fsf@ohwell.denx.de>

Hi,

> In message <20080401131303.17520 at gmx.net> you wrote:
>> You are right! I've checked it again and find the mistake by myself. 
>> 
>> Subject: [PATCH] bugfix: lwmon5 watchdog post
>> If the hardware watchdog detects a voltage error, the watchdog set GPIO62 to low.
>> The watchdog POST have to detect this lowpegel.
>> 
>> Signed-off-by: Sascha Laue <leglas0 at legpc180.leg.liebherr.i>

It just occured to me, Sascha you should check your git-setup.

Very likely a "git-config --global user.email <real e-mail>" helps you
out here.

Cheers
  Detlev

-- 
Die eine Haelfte der Welt lacht ueber die andere, und Narren sind alle.
                                    --- Baltasar Gracian
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From afleming at gmail.com  Mon Apr 14 19:59:28 2008
From: afleming at gmail.com (Andy Fleming)
Date: Mon, 14 Apr 2008 12:59:28 -0500
Subject: [U-Boot-Users] [PATCH][resubmit] QE IO: Add initial data to pin
	configuration + read/write functions
In-Reply-To: <16381440.post@talk.nabble.com>
References: <16381440.post@talk.nabble.com>
Message-ID: <2acbd3e40804141059g3835c9fdv433bc43789b3f7ca@mail.gmail.com>

On Sun, Mar 30, 2008 at 8:45 AM, David Saada <David.Saada at ecitele.com> wrote:
>
>  On the MPC83xx & MPC85xx architectures that have QE, add initial data to the
>  pin configuration table (qe_iop_conf_tab). This is relevant for GPIO pins
>  defined as output. One can setup a value of -1 to leave the value unchanged.
>  QE initialization tables in all relevant boards were also replaced.
>  In addition, add IO pin read & write functions.
>  This patch also includes commands for reading and writing parallel I/O ports
>  (pario command).
>
>  Signed-off-by: David Saada <david.saada at ecitele.com>

I have managed to apply your patch.  But I *still* had to correct
several line-wrap errors.  I suggest that maybe nabble is not the
solution you hope it is.  If you wish to continue submitting patches
to opensource groups, it'll be a good idea to find a solution that
works.  Suggestion: test by sending the email to yourself, and see if
you can apply the patch to a clean branch.

Anyway, I'll wait for Kim's ACK before pushing it up into my dev-1.3.4 branch



From plagnioj at jcrosoft.com  Mon Apr 14 19:53:21 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 14 Apr 2008 19:53:21 +0200
Subject: [U-Boot-Users] [PATCH] Reorder ARM boards in Makefile
In-Reply-To: <1208026563.23686.4.camel@elrond.atmel.sweden>
References: <1208026563.23686.4.camel@elrond.atmel.sweden>
Message-ID: <20080414175321.GE17663@game.jcrosoft.org>

On 20:56 Sat 12 Apr     , Ulf Samuelsson wrote:
> Rearrange ARM boards in Makefile so that ARM926EJ-S boards
> are no longer under ARM92xT header.
> 
> Signed-off-by: Ulf Samuelsson <ulf at atmel.com>
> 
> -- 
> Best Regards
> Ulf Samuelsson
> 

> diff -urN u-boot.cmp/Makefile u-boot/Makefile
> --- u-boot.cmp/Makefile	2008-04-12 07:05:14.000000000 +0200
Ack-By Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Best Regards,
J.



From Ronda.Yang at freescale.com  Mon Apr 14 20:56:36 2008
From: Ronda.Yang at freescale.com (Yang Ronda)
Date: Mon, 14 Apr 2008 11:56:36 -0700
Subject: [U-Boot-Users] SYNC definition problem
In-Reply-To: <9FEBF552-CEFA-476D-AED4-39F1CE2252CF@freescale.com>
References: <147FF9C26CABB646A5A97CC5B270727E04246120@az33exm20.fsl.freescale.net>
	<9FEBF552-CEFA-476D-AED4-39F1CE2252CF@freescale.com>
Message-ID: <147FF9C26CABB646A5A97CC5B270727E0429479A@az33exm20.fsl.freescale.net>

 

> -----Original Message-----
> From: Bruce Becky 
> Sent: Monday, April 14, 2008 11:39 AM
> To: Yang Ronda
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] SYNC definition problem
> 
> 
> On Apr 11, 2008, at 5:27 PM, Yang Ronda wrote:
> > Hi,
> >
> > I was trying to turn on I-Cache while u-boot is executing 
> out of Flash 
> > on MPC5121 ADS board, and just found the board refused to 
> boot. After 
> > debug and tried many different ways, we finally found that 
> the root of 
> > the problem is the SYNC macro definition in u-boot 
> > include/ppc_asm.tmpl file. The SYNC was defined as
> >
> > #define SYNC \
> >  sync; \
> >  isync
> 
> The problem isn't the macro definition.  That macro is used 
> all over the place - changing global macros to fix a single 
> problem is not a  
> good idea unless there's something inherently wrong with the macro.   
> Which there isn't, in this case.
> 

We checked with a PowerPC core designer showing him this definition. He
said the safe way to use isync is that always issue a sync operation
after isync. Yes nothing is wrong with this macro, but maybe it will be
better by adding a sync in the end? The core designer said "issue a sync
after isync" is documented somewhere, I couldn't find this document
though.

> >
> > By turning on I-cache on powerpc e300 core, ICE bit of HID0 needs  
> > to be set. Before setting ICE, an isync operation need to be  
> > issued. In the cpu/mpc512x/start.S file, this is done by using a  
> > 'SYNC' statement. But we found we need to add one more sync  
> > operation to guarantee isync is complete.
> 
> You should only need a single isync before writing the ICE bit.  I  
> looked at that file, and everywhere I see a write to the ICE bit,  
> there's no SYNC macro being used. Have you changed the code?  It's  
> likely that something completely different is causing your problem,  
> and the extra sync is masking the problem.
> 

In board config header file, I changed CFG_HID0_INIT and CFG_HID0_FINAL
definition by setting ICE. Then use line 389 to line 397 of
cpu/mpc512x/start.S to enable I-Cache. 
	lis	r3, CFG_HID0_INIT at h
	ori	r3, r3, CFG_HID0_INIT at l
	SYNC
	mtspr	HID0, r3

	lis	r3, CFG_HID0_FINAL at h
	ori	r3, r3, CFG_HID0_FINAL at l
	SYNC
	mtspr	HID0, r3

We are trying to speed up the booting process, so we turn on I-Cache
while the code is still running out of Flash. But interesting thing is
that, if we use icache_enable function, which is called while execution
is out of RAM, we don't need to issue sync after isync. Maybe this is
because the Flash is slower than RAM, so we need a sync after isync to
guarantee isync finished execution?
 

Best Regards,
Ronda



From kenneth at southpole.se  Mon Apr 14 21:08:41 2008
From: kenneth at southpole.se (Kenneth Johansson)
Date: Mon, 14 Apr 2008 21:08:41 +0200
Subject: [U-Boot-Users] Fixup entries
In-Reply-To: <009e01c89a95$ebd30960$c3791c20$@Tjernlund@transmode.se>
References: <1207733537.6954.32.camel@localhost.localdomain>
	<1207740219.5826.71.camel@gentoo-jocke.transmode.se>
	<1207752413.6954.52.camel@localhost.localdomain>
	<005a01c89a5d$8e9c67b0$abd53710$@Tjernlund@transmode.se>
	<1207782004.8774.6.camel@duo>
	<009e01c89a95$ebd30960$c3791c20$@Tjernlund@transmode.se>
Message-ID: <1208200121.7466.43.camel@localhost.localdomain>


On Thu, 2008-04-10 at 01:03 +0200, Joakim Tjernlund wrote:
> > -----Original Message-----
> > From: kenneth johansson [mailto:kenneth at southpole.se]
> > I had this misconception that the GOT was all that was needed for
> > relocation.
> > Could not find any useful information on what rules apply to gcc and
> > binutils for handling stuff in this fixup section.
> > 
> > Anybody have any information on this?
> 
> Nope, never found anything either. To see a working one in u-boot, look at
> mpc83xx start.S and its linker scripts.
> 
>  Jocke
> 
> 

Found some code from gcc that do the relocation in the same way we want
in u-boot. 

http://gcc.gnu.org/viewcvs/trunk/gcc/config/rs6000/eabi.asm?revision=130805&view=markup

I tried to call __eabi and link with libgcc plus ecrti.o, ecrtn.o  but
in the end I had one silly undefined symbol(.Lfini) that I could not get
past the linker. 

But I think copying that code over into u-boot could not hurt. And
considering the age of that code I can't imagine that anybody has a tool
chain that can't handle using the -mrelocatable. It would be nice to
remove the manual relocation done when it's not needed it is just
confusing.






From wd at denx.de  Mon Apr 14 21:50:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:49 +0200
Subject: [U-Boot-Users] [PATCH 04/13] microblaze: add Emaclite ethernet
	driver
In-Reply-To: Your message of "Mon, 14 Apr 2008 08:53:58 +0200."
	<4802FF86.8010504@seznam.cz>
Message-ID: <20080414195049.BE758248A0@gemini.denx.de>

Dear Michal,

in message <4802FF86.8010504 at seznam.cz> you wrote:
> 
> this code was sent to mailing list I think twice. I think Grant reviewed this
> code once, didn't he?

Maybe, I don't remember the details. But if Ben had accepted the
patch, he would have checked it into the u-boot-net custodian
repository, where network stuff belongs to.

It should not go through other repositories normally (unless Ben gives
his explicit permission).


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: wd at denx.de
"The lesser of two evils -- is evil."             - Seymour (Sy) Leon



From wd at denx.de  Mon Apr 14 21:50:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:49 +0200
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: Your message of "Mon, 14 Apr 2008 08:46:59 +0200."
	<20080414064659.GB17663@game.jcrosoft.org>
Message-ID: <20080414195049.D198D248B9@gemini.denx.de>

In message <20080414064659.GB17663 at game.jcrosoft.org> you wrote:
>
> > +#if defined(CONFIG_HARD_I2C) && defined (CONFIG_I2C_MXC)
> Please stop to define this here, move it the Makefile

Hm... While I agree with the simple standard case of a single
"#ifdef", I'm not so 100% sure it is a good thing to add such complex
expressions to the Makefile.

Aren't we just moving the #ifdef hell from one place to another?

> Wolfgang,
> Is it possible to NACK all patch that add new driver that do this

You mean, automatically? I would not know how to do 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: wd at denx.de
"Deliver yesterday, code today, think tomorrow."



From wd at denx.de  Mon Apr 14 21:50:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:49 +0200
Subject: [U-Boot-Users] [RFC] Create include/u-boot directory
In-Reply-To: Your message of "Sat, 12 Apr 2008 14:25:28 +0200."
	<20080412122528.GA17663@game.jcrosoft.org>
Message-ID: <20080414195049.E1CD6248BB@gemini.denx.de>

In message <20080412122528.GA17663 at game.jcrosoft.org> you wrote:
> 
> 	I proposing to create an include directory name u-boot like it's

This already happened. See latest commits.

> 	done in linux (include/linux) where we put all relate u-boot
> 	headers except configs and asms dirs.

Please don't reorganize everything just for the fun of it - just
where it makes sense.

Remember that ther eis only potential for confusion for very few,
very specific host applications mkimage, fw_*env).

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: wd at denx.de
I'm what passes for a Unix guru in my office. This is  a  frightening
concept. - Lee Ann Goldstein, in <3k55ba$c43 at butch.lmsc.lockheed.com>



From wd at denx.de  Mon Apr 14 21:50:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:50 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Don't panic if a controller driver
	does ecc its own way.
In-Reply-To: Your message of "Mon, 14 Apr 2008 11:34:55 CDT."
	<20080414163455.GA7061@ld0162-tx32.am.freescale.net>
Message-ID: <20080414195050.0DC4B248B9@gemini.denx.de>

In message <20080414163455.GA7061 at ld0162-tx32.am.freescale.net> you wrote:
>
> > > Some hardware, such as the enhanced local bus controller used on some
> > > mpc83xx chips, does ecc transparently when reading and writing data, rather
> > > than providing a generic calculate/correct mechanism that can be exported to
> > > the nand subsystem.
> > > 
> > > The subsystem should not BUG() when calculate, correct, or hwctl are
> > > missing, if the methods that call them have been overridden.
> > > 
> > > Signed-off-by: Scott Wood <scottwood at freescale.com>
> > 
> > This should go through the 83xx custodian, but I haven't seen this
> > yet?
> 
> Why should it go through 83xx?  It's a patch against generic NAND code.

It seems to be 83xx specific code to me?

> > Anyway, it does not apply any more:
> > 
> > Applying Don't panic if a controller driver does ecc its own way.
> > error: patch failed: drivers/mtd/nand/nand_base.c:2593
> > error: drivers/mtd/nand/nand_base.c: patch does not apply
> > fatal: sha1 information is lacking or useless
> > (drivers/mtd/nand/nand_base.c).
> > Repository lacks necessary blobs to fall back on 3-way merge.
> > Cannot fall back to three-way merge.
> 
> Did you try applying it against the 2.6.22.1 branch of the nand
> repository (IIRC, the non-commit-message patch comment specified that)?

No, I tried to apply this to the U-Boot repository. Maybe this was my
fault? Is this supposed to go into Linux, then?

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: wd at denx.de
Murder is contrary to the laws of man and God.
	-- M-5 Computer, "The Ultimate Computer", stardate 4731.3



From wd at denx.de  Mon Apr 14 21:50:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:50 +0200
Subject: [U-Boot-Users] [PATCH] Use `ln -sf` rather than `rm -f && ln -s`
In-Reply-To: Your message of "Mon, 28 Jan 2008 15:57:55 EST."
	<200801281557.55976.vapier@gentoo.org>
Message-ID: <20080414195050.1DDE8248A0@gemini.denx.de>

In message <200801281557.55976.vapier at gentoo.org> you wrote:
>
> > > -		@rm -f $(obj)environment.c
> > > -		ln -s $(src)../common/environment.c $(obj)environment.c
> > > +		ln -s -f $(src)../common/environment.c $(obj)environment.c
> >
> > Be careful here. Are you 100% sure that all systems in the field will
> > behave exactly as your's is doing?
> 
> i really dont understand what you mean.  any POSIX compliant system will 
> behave exactly as it's supposed to: if the destination exists already, unlink 
> it just before creating the link.

I finally fund such a situation again.

# cat /proc/version 
Linux version 2.6.22.14-72.fc6 (brewbuilder at ls20-bc1-14.build.redhat.com) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)) #1 SMP Wed Nov 21 14:10:25 EST 2007
# cat /etc/issue
Fedora Core release 6 (Zod)
Kernel \r on an \m

# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
# cd /opt
# ls -ld eldk eldk-4.2-2008-03-27 eldk-4.2-2008-04-01
lrwxrwxrwx  1 root root   19 Apr  4 04:01 eldk -> eldk-4.2-2008-03-27
drwxr-xr-x 14 root root 4096 Apr  8 23:37 eldk-4.2-2008-03-27
drwxr-xr-x 14 root root 4096 Apr  3 13:38 eldk-4.2-2008-04-01


Now we try:

# ln -sf eldk-4.2-2008-04-01 eldk
# echo $?
0

And what do you think we got?

# ls -ld eldk eldk-4.2-2008-03-27 eldk-4.2-2008-04-01
lrwxrwxrwx  1 root root   19 Apr  4 04:01 eldk -> eldk-4.2-2008-03-27
drwxr-xr-x 14 root root 4096 Apr 14 21:27 eldk-4.2-2008-03-27
drwxr-xr-x 14 root root 4096 Apr  3 13:38 eldk-4.2-2008-04-01


This is what I mean when I say that "rm -f foo ; ln -s bar foo" is
*NOT* exactly equivalent to "ln -sf bar foo". The former will always
work, the latter won't.

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: wd at denx.de
"Wagner's music is better than it sounds."               - Mark Twain



From wd at denx.de  Mon Apr 14 21:50:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:50 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
In-Reply-To: Your message of "Sat, 12 Apr 2008 22:06:56 +0200."
	<1208030816.23686.13.camel@elrond.atmel.sweden>
Message-ID: <20080414195050.3D821248A0@gemini.denx.de>

In message <1208030816.23686.13.camel at elrond.atmel.sweden> you wrote:
> 
> Add support for the AT91RM9200EK Board.

I guess you are aware that the merge window is not open, i. e. you are
submitting this only for discussion here...

> diff -urN u-boot.cmp/board/atmel/at91rm9200ek/at91rm9200ek.c u-boot/board/atmel/at91rm9200ek/at91rm9200ek.c
> --- u-boot.cmp/board/atmel/at91rm9200ek/at91rm9200ek.c	1970-01-01 01:00:00.000000000 +0100
> +++ u-boot/board/atmel/at91rm9200ek/at91rm9200ek.c	2008-04-12 21:28:59.000000000 +0200
> @@ -0,0 +1,142 @@
> +/*
> + * (C) Copyright 2002
> + * Sysgo Real-Time Solutions, GmbH <www.elinos.com>
> + * Marius Groeger <mgroeger at sysgo.de>

A new file, and these are the only copyright holders? Really? Ditto
for the other files.

There are coding style issues: trailing white space,

> diff -urN u-boot.cmp/board/atmel/at91rm9200ek/flash.c u-boot/board/atmel/at91rm9200ek/flash.c
> --- u-boot.cmp/board/atmel/at91rm9200ek/flash.c	1970-01-01 01:00:00.000000000 +0100
> +++ u-boot/board/atmel/at91rm9200ek/flash.c	2008-04-12 21:15:08.000000000 +0200
> @@ -0,0 +1,509 @@
> +/*
> + * (C) Copyright 2002
> + * Lineo, Inc. <www.lineo.com>
> + * Bernhard Kuhn <bkuhn at lineo.com>

I think this is CFI conformant flash, isn't it? So please use the CFI
driver instead.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Multitasking:
                     several applications can crash at the same time.



From wd at denx.de  Mon Apr 14 21:50:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:49 +0200
Subject: [U-Boot-Users] [PATCH] Memory footprint optimizations
In-Reply-To: Your message of "Mon, 14 Apr 2008 14:53:39 +0200."
	<480353D3.4090607@semihalf.com>
Message-ID: <20080414195049.F1CE9248A0@gemini.denx.de>

In message <480353D3.4090607 at semihalf.com> you wrote:
>
> We could use the following two facts:
> 1. the image contents are printed with only two indentations: 0 or 3 spaces,
> 2. indentation with 3 spaces is used in U-Boot, indentation with 0
> spaces is used in mkimage.
> 
> With the following change we could then drop the second argument altogether:

Ah! Excellent.

> +#ifdef USE_HOSTCC
> +       p = "";
> +#else
> +       p = "   ";
> +#endif
> 
> If the above is what is wanted, I'll prepare a patch -- comments are
> welcome.

Yes, please.

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: wd at denx.de
War isn't a good life, but it's life.
	-- Kirk, "A Private Little War", stardate 4211.8



From wd at denx.de  Mon Apr 14 21:50:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:50 +0200
Subject: [U-Boot-Users] [PATCH] Add support for Atmel flash
In-Reply-To: Your message of "Sun, 13 Apr 2008 15:36:58 +0200."
	<1208093818.23686.11.camel@voyager.dsnet>
Message-ID: <20080414195050.4D7E5248BB@gemini.denx.de>

In message <1208093818.23686.11.camel at voyager.dsnet> you wrote:
> 
> Le samedi 12 avril 2008 =E0 21:03 +0200, Ulf Samuelsson a =E9crit :
> > Add ID codes for most recent Atmel NOR flashes
> 
> Is there any added value on using the atmel flash driver instead of the
> standard CFI driver ? It surely doesn't have any on the SAM9/CAP9
> boards, but I'm not sure of the older AT91RM9200.

I don't think there is.

For the existing boards, the already exisitng values should be
sufficient, and for new boards we should use the CFI driver.

I intend to NAK new boards with CFI conformant flashes that don't use
the CFI driver unless thay have very good reasons.

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: wd at denx.de
"The more data I punch in this card,  the lighter it becomes, and the
lower the mailing cost."
                     - Stan Kelly-Bootle, "The Devil's DP Dictionary"



From wd at denx.de  Mon Apr 14 21:50:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 14 Apr 2008 21:50:50 +0200
Subject: [U-Boot-Users] [PATCH] Add build date environment variable
In-Reply-To: Your message of "Sat, 12 Apr 2008 21:09:41 +0200."
	<1208027381.23686.10.camel@elrond.atmel.sweden>
Message-ID: <20080414195050.2DBAC248B9@gemini.denx.de>

In message <1208027381.23686.10.camel at elrond.atmel.sweden> you wrote:
> 
> Add environment for the date when U-Boot is built

It seems that nobody is ever using this variable, so why add it?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"It takes all sorts of in & out-door schooling to get adapted  to  my
kind of fooling"                                           - R. Frost



From scottwood at freescale.com  Mon Apr 14 21:55:24 2008
From: scottwood at freescale.com (Scott Wood)
Date: Mon, 14 Apr 2008 14:55:24 -0500
Subject: [U-Boot-Users] [PATCH 1/2] Don't panic if a controller driver
 does ecc its own way.
In-Reply-To: <20080414195050.0DC4B248B9@gemini.denx.de>
References: <20080414195050.0DC4B248B9@gemini.denx.de>
Message-ID: <4803B6AC.50603@freescale.com>

Wolfgang Denk wrote:
> In message <20080414163455.GA7061 at ld0162-tx32.am.freescale.net> you wrote:
>>>> Some hardware, such as the enhanced local bus controller used on some
>>>> mpc83xx chips, does ecc transparently when reading and writing data, rather
>>>> than providing a generic calculate/correct mechanism that can be exported to
>>>> the nand subsystem.
>>>>
>>>> The subsystem should not BUG() when calculate, correct, or hwctl are
>>>> missing, if the methods that call them have been overridden.
>>>>
>>>> Signed-off-by: Scott Wood <scottwood at freescale.com>
>>> This should go through the 83xx custodian, but I haven't seen this
>>> yet?
>> Why should it go through 83xx?  It's a patch against generic NAND code.
> 
> It seems to be 83xx specific code to me?

It's not.  It is removing a restriction in the NAND code that happens to 
interfere with what the FSL NAND driver needs to do.

>> Did you try applying it against the 2.6.22.1 branch of the nand
>> repository (IIRC, the non-commit-message patch comment specified that)?
> 
> No, I tried to apply this to the U-Boot repository. Maybe this was my
> fault? Is this supposed to go into Linux, then?

No, it's supposed to go into the 2.6.22.1 branch of Stefan's u-boot NAND 
tree.  This change is already in the Linux NAND code.

-Scott



From kim.phillips at freescale.com  Mon Apr 14 22:01:43 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Mon, 14 Apr 2008 15:01:43 -0500
Subject: [U-Boot-Users] [PATCH][resubmit] QE IO: Add initial data to pin
 configuration + read/write functions
In-Reply-To: <2acbd3e40804141059g3835c9fdv433bc43789b3f7ca@mail.gmail.com>
References: <16381440.post@talk.nabble.com>
	<2acbd3e40804141059g3835c9fdv433bc43789b3f7ca@mail.gmail.com>
Message-ID: <20080414150143.259988a2.kim.phillips@freescale.com>

On Mon, 14 Apr 2008 12:59:28 -0500
"Andy Fleming" <afleming at gmail.com> wrote:

> On Sun, Mar 30, 2008 at 8:45 AM, David Saada <David.Saada at ecitele.com> wrote:
> >
> >  On the MPC83xx & MPC85xx architectures that have QE, add initial data to the
> >  pin configuration table (qe_iop_conf_tab). This is relevant for GPIO pins
> >  defined as output. One can setup a value of -1 to leave the value unchanged.
> >  QE initialization tables in all relevant boards were also replaced.
> >  In addition, add IO pin read & write functions.
> >  This patch also includes commands for reading and writing parallel I/O ports
> >  (pario command).
> >
> >  Signed-off-by: David Saada <david.saada at ecitele.com>
> 
> I have managed to apply your patch.  But I *still* had to correct
> several line-wrap errors.  I suggest that maybe nabble is not the
> solution you hope it is.  If you wish to continue submitting patches
> to opensource groups, it'll be a good idea to find a solution that
> works.  Suggestion: test by sending the email to yourself, and see if
> you can apply the patch to a clean branch.
> 
> Anyway, I'll wait for Kim's ACK before pushing it up into my dev-1.3.4 branch

see:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38991

Kim



From casainho at gmail.com  Mon Apr 14 22:18:18 2008
From: casainho at gmail.com (J.P. Casainho)
Date: Mon, 14 Apr 2008 21:18:18 +0100
Subject: [U-Boot-Users] questions about stand alone application - flash
	a LED
In-Reply-To: <48032361.25bb720a.38ba.1253@mx.google.com>
References: <48032361.25bb720a.38ba.1253@mx.google.com>
Message-ID: <200804142118.18422.casainho@gmail.com>

Hello Leon :-)

Thank you for your help!! :-)

I understand now that is not dificult to make a stand alone application, It's 
easy :-) - I am trying to learn the art of building, using GCC, make files, 
linking... :-)

Many thanks - have a nice days :-)

-- 
Cumprimentos,

JPCasainho - http://www.Casainho.net


On Monday 14 April 2008 10:26:54 Leon.Z wrote:
> HI:)
>
> You can use the go CMD to test your app.
> Here post my used step.
>
> Write a simple code.It's just include a function definition
> 	void _start()
>     {
>     }
> Then compile it.After do that use following step:
> ppc_82xx-ld -Bstatic -Ttext 0x00001000 board/bname/ttt.o -o ttt.elf
>
> -bash-2.05b$ ppc_82xx-objdump -d ttt.elf
>
> ttt.elf:     file format elf32-powerpc
>
> Disassembly of section .text:
>
> 00001000 <_start>:
>     1000:       94 21 ff e8     stwu    r1,-24(r1)
>     1004:       38 21 00 18     addi    r1,r1,24
>     1008:       4e 80 00 20     blr
> -bash-2.05b$
>
> you can see the function just call the stack operation.
> then you can put your test code to the _start function's body,
> and run the step above again.
>
> finally to get a pure bin file:
> ppc_82xx-objcopy --gap-fill=0xff -O binary ttt.elf ttt.bin
>
> and then test the code in the u-boot prompt:
> u-boot> tftp 0x1000 ttt.bin
> u-boot> go 0x1000
>
>
> ======= 2008-04-14 16:33:55 ????????=======
>
> >Hello :-)
> >
> >I am looking for an example code for a Flash LED, for a stand alone
> >application. I did read the examples like "hello world" and the
> >/doc/standalone.
> >
> >I would like to know If I can build a stand alone application without
> >build the u-boot -- I would appreciate if someone point me to a
> >tutorial, I just find examples for load Linux...
> >
> >I am a newbie in 32 bits world. I am trying to port Rockbox*, the Free
> >Software firmware for audio DAPs like IPods, Sansas, etc., for a
> >Free/Open hardware, the Rockbox Player**.
> >
> >I need to use u-boot to launch that firmware, first I would like to
> >start doing a flash led application. I did build u-boot, using the
> >sources that came with the dev. board I am using, with success however
> >the firmware I want to build don't build with arm-linux-gcc, just with
> >arm-elf-gcc.
> >
> >I appreciate any suggestions, any guidance. Thank you.
> >
> >Jorge Pinto,
> >
> >http://www.casainho.net
> >
> >* http://www.rockbox.org/
> >** http://www.rockbox.org/twiki/bin/view/Main/RockboxPlayer
> >
> >-------------------------------------------------------------------------
> >This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >Don't miss this year's exciting event. There's still time to save $100.
> >Use priority code J8TL2D2.
> >http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/jav
> >aone _______________________________________________
> >U-Boot-Users mailing list
> >U-Boot-Users at lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
> = = = = = = = = = = = = = = = = = = = =
>
>
> ?????????
> ??
>
>
> ????????Leon.Z
> ????????leon.kernel at gmail.com
> ??????????2008-04-14



From lilja.magnus at gmail.com  Mon Apr 14 22:33:44 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Mon, 14 Apr 2008 22:33:44 +0200
Subject: [U-Boot-Users] [PATCH] Fix name of i.MX31 boards in config file
	header
Message-ID: <4803BFA8.4020104@gmail.com>

Correct the names of the i.MX31 Litekit and phyCORE boards in config files.

Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
---

 include/configs/imx31_litekit.h |    2 +-
 include/configs/imx31_phycore.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 2a6f59a..777750b 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -4,7 +4,7 @@
  * Richard Woodruff <r-woodruff2 at ti.com>
  * Kshitij Gupta <kshitij at ti.com>
  *
- * Configuration settings for the 242x TI H4 board.
+ * Configuration settings for the LogicPD i.MX31 Litekit board.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
diff --git a/include/configs/imx31_phycore.h b/include/configs/imx31_phycore.h
index e067b76..c29654b 100644
--- a/include/configs/imx31_phycore.h
+++ b/include/configs/imx31_phycore.h
@@ -4,7 +4,7 @@
  * Richard Woodruff <r-woodruff2 at ti.com>
  * Kshitij Gupta <kshitij at ti.com>
  *
- * Configuration settings for the 242x TI H4 board.
+ * Configuration settings for the phyCORE i.MX31 board.
  *
  * See file CREDITS for list of people who contributed to this
  * project.



From joakim.tjernlund at transmode.se  Mon Apr 14 23:01:50 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Mon, 14 Apr 2008 23:01:50 +0200
Subject: [U-Boot-Users] [PATCH] Change env_get_char from a
	global	function ptr to a function.
In-Reply-To: <20080414010936.F3D50247E9@gemini.denx.de>
References: <20080414010936.F3D50247E9@gemini.denx.de>
Message-ID: <1208206910.5911.20.camel@gentoo-jocke.transmode.se>


On Mon, 2008-04-14 at 03:09 +0200, Wolfgang Denk wrote:
> In message <024e01c89742$e48d4b80$ada7e280$@Tjernlund at transmode.se> you wrote:
> > Did you try this one or did du skip it this release?
> 
> Unfortunately this doesn't apply any more:
> 
> Applying Change env_get_char from a global function ptr to a function.
> error: patch failed: common/cmd_bootm.c:1150
> error: common/cmd_bootm.c: patch does not apply
> error: patch failed: common/fdt_support.c:225
> error: common/fdt_support.c: patch does not apply
> error: patch failed: common/ft_build.c:396
> error: common/ft_build.c: patch does not apply
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Auto-merged common/cmd_bootm.c
> CONFLICT (content): Merge conflict in common/cmd_bootm.c
> Auto-merged common/cmd_nvedit.c
> Auto-merged common/fdt_support.c
> CONFLICT (content): Merge conflict in common/fdt_support.c
> Auto-merged common/ft_build.c
> CONFLICT (content): Merge conflict in common/ft_build.c
> Auto-merged include/common.h
> Failed to merge in the changes.
> Patch failed at 0001.
> 
> 
> Could you please update and resubmit? Thanks in advance.
> 
> Best regards,
> 
> Wolfgang Denk

OK, here it is.

>From 96fdcd78686c22aa6be56575c9f37d1943c91222 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
Date: Mon, 14 Apr 2008 22:59:00 +0200
Subject: [PATCH] Change env_get_char from a global function ptr to a function.

This avoids an early global data reference.
---
 api/api.c           |    1 -
 common/cmd_nvedit.c |    3 ---
 common/env_common.c |   19 +++++++++++++------
 common/env_eeprom.c |    1 -
 common/env_nvram.c  |    1 -
 common/ft_build.c   |    2 --
 include/common.h    |    1 +
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/api/api.c b/api/api.c
index 0598d90..c1b2b60 100644
--- a/api/api.c
+++ b/api/api.c
@@ -40,7 +40,6 @@
 
 /* U-Boot routines needed */
 extern int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
-extern uchar (*env_get_char)(int);
 extern uchar *env_get_addr(int);
 
 /*****************************************************************************
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index cab727f..dc05f68 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -68,9 +68,6 @@ DECLARE_GLOBAL_DATA_PTR;
 /************************************************************************
 ************************************************************************/
 
-/* Function that returns a character from the environment */
-extern uchar (*env_get_char)(int);
-
 /* Function that returns a pointer to a value from the environment */
 /* (Only memory version supported / needed). */
 extern uchar *env_get_addr(int);
diff --git a/common/env_common.c b/common/env_common.c
index a494812..f366fdb 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -50,7 +50,6 @@ extern void env_relocate_spec (void);
 extern uchar env_get_char_spec(int);
 
 static uchar env_get_char_init (int index);
-uchar (*env_get_char)(int) = env_get_char_init;
 
 /************************************************************************
  * Default settings to be used when no valid environment is found
@@ -182,6 +181,19 @@ uchar env_get_char_memory (int index)
 }
 #endif
 
+uchar env_get_char (int index)
+{
+	uchar c;
+
+	/* if relocated to RAM */
+	if (gd->flags & GD_FLG_RELOC)
+		c = env_get_char_memory(index);
+	else
+		c = env_get_char_init(index);
+
+	return (c);
+}
+
 uchar *env_get_addr (int index)
 {
 	if (gd->env_valid) {
@@ -215,11 +227,6 @@ void env_relocate (void)
 	DEBUGF ("%s[%d] malloced ENV at %p\n", __FUNCTION__,__LINE__,env_ptr);
 #endif
 
-	/*
-	 * After relocation to RAM, we can always use the "memory" functions
-	 */
-	env_get_char = env_get_char_memory;
-
 	if (gd->env_valid == 0) {
 #if defined(CONFIG_GTH)	|| defined(CFG_ENV_IS_NOWHERE)	/* Environment not changable */
 		puts ("Using default environment\n\n");
diff --git a/common/env_eeprom.c b/common/env_eeprom.c
index 2adc129..fae87ca 100644
--- a/common/env_eeprom.c
+++ b/common/env_eeprom.c
@@ -38,7 +38,6 @@ env_t *env_ptr = NULL;
 
 char * env_name_spec = "EEPROM";
 
-extern uchar (*env_get_char)(int);
 extern uchar env_get_char_memory (int index);
 
 
diff --git a/common/env_nvram.c b/common/env_nvram.c
index 7c18896..bfc8d02 100644
--- a/common/env_nvram.c
+++ b/common/env_nvram.c
@@ -63,7 +63,6 @@ char * env_name_spec = "NVRAM";
 extern uchar default_environment[];
 extern int default_environment_size;
 
-extern uchar (*env_get_char)(int);
 extern uchar env_get_char_memory (int index);
 
 #ifdef CONFIG_AMIGAONEG3SE
diff --git a/common/ft_build.c b/common/ft_build.c
index 0e5699a..0b6c2b7 100644
--- a/common/ft_build.c
+++ b/common/ft_build.c
@@ -396,8 +396,6 @@ void *ft_get_prop(void *bphp, const char *propname, int *szp)
 
 /********************************************************************/
 
-/* Function that returns a character from the environment */
-extern uchar(*env_get_char) (int);
 
 void ft_setup(void *blob, bd_t * bd, ulong initrd_start, ulong initrd_end)
 {
diff --git a/include/common.h b/include/common.h
index 39bcd30..8630780 100644
--- a/include/common.h
+++ b/include/common.h
@@ -229,6 +229,7 @@ extern ulong load_addr;		/* Default Load Address */
 /* common/cmd_nvedit.c */
 int	env_init     (void);
 void	env_relocate (void);
+uchar	env_get_char (int);
 int	envmatch     (uchar *, int);
 char	*getenv	     (char *);
 int	getenv_r     (char *name, char *buf, unsigned len);
-- 
1.5.4.5





From joakim.tjernlund at transmode.se  Mon Apr 14 23:06:24 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Mon, 14 Apr 2008 23:06:24 +0200
Subject: [U-Boot-Users] [PATCH] Move init_sequence table into code.
In-Reply-To: <20080414010936.E130C248B9@gemini.denx.de>
References: <20080414010936.E130C248B9@gemini.denx.de>
Message-ID: <1208207184.5911.26.camel@gentoo-jocke.transmode.se>


On Mon, 2008-04-14 at 03:09 +0200, Wolfgang Denk wrote:
> In message <1206719159-11200-1-git-send-email-Joakim.Tjernlund at transmode.se> you wrote:
> > Global variables are not ideal before relocation to RAM.
> 
> Byt they don't cause any real problem either, or am I missing
> something?

Makes u-boot smaller too.
It is a step closer towards full relocation of u-boot, I want to get rid
of using global data while in FLASH.

> 
> I tend to reject the patch.
> 
> > -init_fnc_t *init_sequence[] = {
> 
> The original idea of having such a list  of  funtion  pointers  which
> just  get executed one after another was to be able to wrap this into
> some "#ifndef CONFIG_INIT_SEQUENCE" and use this to allow for  board-
> specific init sequences by just adding a #define with the needed list
> of functions to the board config files.

You can do that with weak functions too. Just make all the functions
weak, then a board can overide with its own function.

> 
> Even though this feature never was used so far, I still  hesitate  to
> throw  it away - at least as long as I don't see benefits for the new
> solution.
> 
> Best regards,
> 
> Wolfgang Denk
> 



From lg at denx.de  Tue Apr 15 00:28:21 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Tue, 15 Apr 2008 00:28:21 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: <20080414195049.D198D248B9@gemini.denx.de>
References: <20080414195049.D198D248B9@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804150024500.5332@axis700.grange>

On Mon, 14 Apr 2008, Wolfgang Denk wrote:

> In message <20080414064659.GB17663 at game.jcrosoft.org> you wrote:
> >
> > > +#if defined(CONFIG_HARD_I2C) && defined (CONFIG_I2C_MXC)
> > Please stop to define this here, move it the Makefile
> 
> Hm... While I agree with the simple standard case of a single
> "#ifdef", I'm not so 100% sure it is a good thing to add such complex
> expressions to the Makefile.
> 
> Aren't we just moving the #ifdef hell from one place to another?

Wouldn't it be logical to assume, that if CONFIG_I2C_MXC is defined, 
CONFIG_HARD_I2C is meant too? So, we could just put in i2c.h

#ifdef CONFIG_I2C_MXC
#define CONFIG_HARD_I2C
#endif

And then use the simple

OBJC-$(CONFIG_I2C_MXC) += ...

Incremental patch?

in the Makefile? I personally do prefer when unneeded .c files do not get 
compiled at all, rather than compiled to "0"-byte big objects. Makes the 
build process and the resulting tree look cleaner, and the image a bit 
smaller.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From bluecolour.sz at gmail.com  Tue Apr 15 04:42:50 2008
From: bluecolour.sz at gmail.com (cheesiong)
Date: Tue, 15 Apr 2008 10:42:50 +0800
Subject: [U-Boot-Users] Hi, I am new to U-Boot, how do I get started?
Message-ID: <8ab1d9170804141942w47c9b906re59345e964345467@mail.gmail.com>

hi all,
 i read the Readme in the top directory of U-boot 1.3.2. i hope this subject
is appropriate.
 i have a question on the makefile, i want to know where is the $obj define,
but it seem it define implicitly when use it.

 sample:
VERSION = 1
PATCHLEVEL = 3
SUBLEVEL = 2
EXTRAVERSION =
U_BOOT_VERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
VERSION_FILE = $(obj)include/version_autogenerated.h

so my question is, where is the version_autogenerated.h file? because i
couldn;t find it, so i am not sure what is the purpose of this line.
please enlighten me on the usage of the the $obj if possible.
i am new to u-boot, thank you.

regards,-keo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080415/657c697a/attachment.htm 

From hroapynaf at 02.246.ne.jp  Wed Apr 16 08:58:23 2008
From: hroapynaf at 02.246.ne.jp (Jeannette Greene)
Date: Wed, 16 Apr 2008 05:58:23 -0100
Subject: [U-Boot-Users] Medical Doctor List in the US
Message-ID: <097501b0had0$u3467li0$4593q6x0@Delldim5150






Licensed Medical Doctors in America 

788,606 in total <> 17,054 emails

Many different medical specialties

Sort by over a dozen different fields

Cost just slashed -  $390


+++ GET THE 4 ITEMS BELOW AS A GIFT WHEN YOU ORDER +++

>> US Pharmaceutical Company Executives Listing
  47,000 names and emails of the major positions

>> List of US Hospitals
  23,000 Admins in more than 7,000 hospitals {a $399 value]

>> Listing of American Dentists
  More than half a million listings [worth $499 alone!]

>> American Chiropractors Directory
  100,000 Chiropractors in the USA (worth $250 alone)

reply by email:      brethartford at hotmail.com

  

valid until Apr18


By sending an email with 595  in the subject you will have your email revoked



From biggerbadderben at gmail.com  Tue Apr 15 05:47:56 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Mon, 14 Apr 2008 23:47:56 -0400
Subject: [U-Boot-Users] [PATCH] NE2000: Fix regresssion introduced by
	e710185aae90 on non AX88796
In-Reply-To: <1207976419-6571-1-git-send-email-plagnioj@jcrosoft.com>
References: <47FF7C44.6040600@comsys.ro>
	<1207976419-6571-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <f8328f7c0804142047q34b74ac5k942a3d1ecb202b5a@mail.gmail.com>

On Sat, Apr 12, 2008 at 1:00 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj at jcrosoft.com> wrote:
> Move non-inlied functions into specific drivers file
>  Set get_prom as weak
>
>  Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>  Signed-off-by: Vlad Lungu <vlad at comsys.ro>
>
>  diff --git a/drivers/net/Makefile b/drivers/net/Makefile
>  index eafd267..99e068b 100644
>  --- a/drivers/net/Makefile
>  +++ b/drivers/net/Makefile
>  @@ -42,7 +42,10 @@ COBJS-y += lan91c96.o
>   COBJS-y += macb.o
>   COBJS-y += mcffec.o
>   COBJS-y += natsemi.o
>  -COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o
>  +ifeq ($(CONFIG_DRIVER_NE2000),y)
>  +COBJS-y += ne2000.o
>  +COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o
>  +endif
>   COBJS-y += netarm_eth.o
>   COBJS-y += netconsole.o
>   COBJS-y += ns7520_eth.o
>  diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
>  new file mode 100644
>  index 0000000..7e3e3bb
>  --- /dev/null
>  +++ b/drivers/net/ax88796.c
>  @@ -0,0 +1,155 @@
>  +/*
>  + * (c) 2008 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>  + * (c) 2007 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
>  + *

Your work is appreciated, but moving code to a different file doesn't
entitle you to copyright.

regards,
Ben



From grant.likely at secretlab.ca  Tue Apr 15 06:21:23 2008
From: grant.likely at secretlab.ca (Grant Likely)
Date: Mon, 14 Apr 2008 23:21:23 -0500
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: <Pine.LNX.4.64.0804150024500.5332@axis700.grange>
References: <20080414195049.D198D248B9@gemini.denx.de>
	<Pine.LNX.4.64.0804150024500.5332@axis700.grange>
Message-ID: <fa686aa40804142121h65bf8b73t168bc19beb260de8@mail.gmail.com>

On Mon, Apr 14, 2008 at 5:28 PM, Guennadi Liakhovetski <lg at denx.de> wrote:
> On Mon, 14 Apr 2008, Wolfgang Denk wrote:
>
>  > In message <20080414064659.GB17663 at game.jcrosoft.org> you wrote:
>  > >
>  > > > +#if defined(CONFIG_HARD_I2C) && defined (CONFIG_I2C_MXC)
>  > > Please stop to define this here, move it the Makefile
>  >
>  > Hm... While I agree with the simple standard case of a single
>  > "#ifdef", I'm not so 100% sure it is a good thing to add such complex
>  > expressions to the Makefile.
>  >
>  > Aren't we just moving the #ifdef hell from one place to another?
>
>  Wouldn't it be logical to assume, that if CONFIG_I2C_MXC is defined,
>  CONFIG_HARD_I2C is meant too? So, we could just put in i2c.h
>
>  #ifdef CONFIG_I2C_MXC
>  #define CONFIG_HARD_I2C
>  #endif
>
>  And then use the simple
>
>  OBJC-$(CONFIG_I2C_MXC) += ...
>

Yes, this is the way I'd solve the problem.

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.



From tj_jac at yahoo.co.in  Tue Apr 15 06:26:45 2008
From: tj_jac at yahoo.co.in (Tiju)
Date: Tue, 15 Apr 2008 09:56:45 +0530 (IST)
Subject: [U-Boot-Users] Linux kernel startup (s3c24xx)
Message-ID: <572383.4595.qm@web94603.mail.in2.yahoo.com>

Hi All,

I am using buildroot to create a cpio image. Following is the output.

Starting kernel ...

Uncompressing Linux............................................................................................
Linux version 2.6.24.4-default (tiju at tiju) (gcc version 4.2.1) #57 Tue Apr 15 08:58:38 IST 2008
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=00007177
Machine: DPB2440
Warning: bad configuration page, trying to continue
Memory policy: ECC disabled, Data cache writeback
CPU S3C2440A (id 0x32440001)
S3C244X: core 405.000 MHz, memory 101.250 MHz, peripheral 50.625 MHz
S3C24XX Clocks, (c) 2004 Simtec Electronics
CLOCK: Slow mode (1.500 MHz), fast, MPLL on, UPLL on
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
CPU0: D cache: 16384 bytes, associativity 64, 32 byte lines, 8 sets
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 4064
Kernel command line: root=/dev/ram0 rw console=ttySAC0,115200
irq: clearing pending ext status 00000b00
irq: clearing subpending status 00000003
irq: clearing subpending status 00000002
PID hash table entries: 64 (order: 6, 256 bytes)
timer tcon=00500000, tcnt a4ca, tcfg 00000200,00000000, usec 00001e57
Console: colour dummy device 80x30
console [ttySAC0] enabled
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 16MB = 16MB total
Memory: 12620KB available (2184K code, 342K data, 1032K init)
Security Framework initialized
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 64 bytes
NET: Registered protocol family 16
S3C2440: Initialising architecture
S3C2440: IRQ Support
S3C2440: Clock Support, DVS off
S3C24XX DMA Driver, (c) 2003-2004,2006 Simtec Electronics
DMA channel 0 at c1800000, irq 33
DMA channel 1 at c1800040, irq 34
DMA channel 2 at c1800080, irq 35
DMA channel 3 at c18000c0, irq 36
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1.975:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
s3c2440-uart.0: s3c2410_serial0 at MMIO 0x50000000 (irq = 70) is a S3C2440
s3c2440-uart.1: s3c2410_serial1 at MMIO 0x50004000 (irq = 73) is a S3C2440
s3c2440-uart.2: s3c2410_serial2 at MMIO 0x50008000 (irq = 76) is a S3C2440
mice: PS/2 mouse device common for all mice
S3C2410 Watchdog Timer, (c) 2004 Simtec Electronics
s3c2410-wdt s3c2410-wdt: watchdog inactive, reset disabled, irq enabled
NET: Registered protocol family 1
NET: Registered protocol family 17
registered taskstats version 1
Freeing init memory: 1032K

Thats it. Nothing else appears. Keyboard is active. What could be the problem?

Thanks in advance.
Tiju





      Best Jokes, Best Friends, Best Food and more. Go to http://in.promos.yahoo.com/groups/bestofyahoo/




From Alex.Lindenlevy at Colorado.EDU  Tue Apr 15 06:32:39 2008
From: Alex.Lindenlevy at Colorado.EDU (Loren A. Linden Levy)
Date: Mon, 14 Apr 2008 22:32:39 -0600
Subject: [U-Boot-Users] Modify Clock rate
Message-ID: <20080414223239.0a916549@uncle-pecos.Colorado.EDU>

Hi,

Is there a way to modify the clock rate in u-boot? I want to
artificially set the clock rate on an m5282 to 32MHz instead of
66MHz. Thanks for any advice.

Alex

-- 
 -- 
---------------------------------------------
Loren A. Linden Levy
Department of Physics 
390 UCB 
University of Colorado
Boulder, CO   80309-0390
Tel:   303-735-6146 (CU) / +049 040 8998 4789 (DESY) 
Fax:   303-492-3352 (CU) / +049 040 8998 4034 (DESY) 
Cell:  303-332-2768 (U.S.) / +049 (0)151 5496 1831 (Germany)
Email: Loren.Lindenlevy at colorado.edu
url:   http://up.colorado.edu/~lindenle
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used 
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080414/134dacc4/attachment.pgp 

From biggerbadderben at gmail.com  Tue Apr 15 06:32:57 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Tue, 15 Apr 2008 00:32:57 -0400
Subject: [U-Boot-Users] Pull request - net
Message-ID: <f8328f7c0804142132q37c5f523u343192ccf734e751@mail.gmail.com>

Wolfgang,

The following changes since commit 3dfd4aab929cccddb63d9ea509967861e1333b52:
  Sascha Laue (1):
        Fix watchdog POST for lwmon5

are available in the git repository at:

  git://www.denx.de/git/u-boot-net.git master

Guennadi Liakhovetski (1):
      Clean up smsc911x driver

Sascha Hauer (1):
      add SMSC LAN9x1x Network driver

 drivers/net/Makefile            |    1 +
 drivers/net/smc911x.c           |  686 +++++++++++++++++++++++++++++++++++++++
 include/configs/imx31_litekit.h |    1 +
 include/configs/imx31_phycore.h |    1 +
 4 files changed, 689 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/smc911x.c

regards,
Ben



From wd at denx.de  Tue Apr 15 06:35:18 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 15 Apr 2008 06:35:18 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Don't panic if a controller driver
	does ecc its own way.
In-Reply-To: Your message of "Mon, 14 Apr 2008 14:55:24 CDT."
	<4803B6AC.50603@freescale.com>
Message-ID: <20080415043518.8C2F5248B9@gemini.denx.de>

In message <4803B6AC.50603 at freescale.com> you wrote:
>
> > No, I tried to apply this to the U-Boot repository. Maybe this was my
> > fault? Is this supposed to go into Linux, then?
> 
> No, it's supposed to go into the 2.6.22.1 branch of Stefan's u-boot NAND 
> tree.  This change is already in the Linux NAND code.

I see. OK, so it's really Stefan who needs to react here.

Thanks for the explanations.

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: wd at denx.de
Only in our dreams we are free.  The rest of the time we need  wages.
                                    - Terry Pratchett, _Wyrd Sisters_



From wd at denx.de  Tue Apr 15 06:35:18 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 15 Apr 2008 06:35:18 +0200
Subject: [U-Boot-Users] [PATCH] Move init_sequence table into code.
In-Reply-To: Your message of "Mon, 14 Apr 2008 23:06:24 +0200."
	<1208207184.5911.26.camel@gentoo-jocke.transmode.se>
Message-ID: <20080415043518.9FF24248BB@gemini.denx.de>

In message <1208207184.5911.26.camel at gentoo-jocke.transmode.se> you wrote:
> 
> It is a step closer towards full relocation of u-boot, I want to get rid
> of using global data while in FLASH.

I doubt that this will work, but I'd love to be surprised :-)

> > The original idea of having such a list  of  funtion  pointers  which
> > just  get executed one after another was to be able to wrap this into
> > some "#ifndef CONFIG_INIT_SEQUENCE" and use this to allow for  board-
> > specific init sequences by just adding a #define with the needed list
> > of functions to the board config files.
> 
> You can do that with weak functions too. Just make all the functions
> weak, then a board can overide with its own function.

That would not, for example, to allow to change the sequence - say
one board needs to initialize PCI very early, but another one very
late.

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: wd at denx.de
If the hours are long enough and the pay  is  short  enough,  someone
will say it's women's work.



From wd at denx.de  Tue Apr 15 06:35:18 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 15 Apr 2008 06:35:18 +0200
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: Your message of "Tue, 15 Apr 2008 00:28:21 +0200."
	<Pine.LNX.4.64.0804150024500.5332@axis700.grange>
Message-ID: <20080415043518.B01BE24657@gemini.denx.de>

In message <Pine.LNX.4.64.0804150024500.5332 at axis700.grange> you wrote:
> > 
> > Aren't we just moving the #ifdef hell from one place to another?
> 
> Wouldn't it be logical to assume, that if CONFIG_I2C_MXC is defined, 
> CONFIG_HARD_I2C is meant too? So, we could just put in i2c.h

Well, what exactly is CONFIG_I2C_MXC supposed to mean? Sorry for
asking, but I cannot find it documented anywhere (hint! hint! This
needs to be fixed!). I tend to believe that in it's current form it's
redundant, meaning that we have both CONFIG_CMD_I2C and CONFIG_MX31.

> #ifdef CONFIG_I2C_MXC
> #define CONFIG_HARD_I2C
> #endif

Depending on the intended meaning of CONFIG_I2C_MXC there could also
be someone who wants to use soft-I2C on that processors.

> in the Makefile? I personally do prefer when unneeded .c files do not get 
> compiled at all, rather than compiled to "0"-byte big objects. Makes the 
> build process and the resulting tree look cleaner, and the image a bit 
> smaller.

Me too.

But then, I definitely want to keep the Makefiles simple and clean,
too.

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: wd at denx.de
"... freedom ... is a worship word..."
"It is our worship word too."
	-- Cloud William and Kirk, "The Omega Glory", stardate unknown



From plagnioj at jcrosoft.com  Tue Apr 15 06:35:49 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 15 Apr 2008 06:35:49 +0200
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: <fa686aa40804142121h65bf8b73t168bc19beb260de8@mail.gmail.com>
References: <20080414195049.D198D248B9@gemini.denx.de>
	<Pine.LNX.4.64.0804150024500.5332@axis700.grange>
	<fa686aa40804142121h65bf8b73t168bc19beb260de8@mail.gmail.com>
Message-ID: <20080415043549.GF17663@game.jcrosoft.org>

On 23:21 Mon 14 Apr     , Grant Likely wrote:
> On Mon, Apr 14, 2008 at 5:28 PM, Guennadi Liakhovetski <lg at denx.de> wrote:
> > On Mon, 14 Apr 2008, Wolfgang Denk wrote:
> >
> >  > In message <20080414064659.GB17663 at game.jcrosoft.org> you wrote:
> >  > >
> >  > > > +#if defined(CONFIG_HARD_I2C) && defined (CONFIG_I2C_MXC)
> >  > > Please stop to define this here, move it the Makefile
> >  >
> >  > Hm... While I agree with the simple standard case of a single
> >  > "#ifdef", I'm not so 100% sure it is a good thing to add such complex
> >  > expressions to the Makefile.
> >  >
> >  > Aren't we just moving the #ifdef hell from one place to another?
> >
> >  Wouldn't it be logical to assume, that if CONFIG_I2C_MXC is defined,
> >  CONFIG_HARD_I2C is meant too? So, we could just put in i2c.h
> >
> >  #ifdef CONFIG_I2C_MXC
> >  #define CONFIG_HARD_I2C
> >  #endif
> >
> >  And then use the simple
> >
> >  OBJC-$(CONFIG_I2C_MXC) += ...
> >
> 
> Yes, this is the way I'd solve the problem.
I dont't like the idean to modify the i2c.h for each i2c drivers
implemetation. I prefer to keep it into the config file and move it to
the Kconfig.
I hope that I've time the next merge window to send it.

Best Regards,
J.



From ulf.samuelsson at atmel.com  Mon Apr 14 22:44:56 2008
From: ulf.samuelsson at atmel.com (Ulf Samuelsson)
Date: Mon, 14 Apr 2008 22:44:56 +0200
Subject: [U-Boot-Users] [PATCH] Add build date environment variable
References: <20080414195050.2DBAC248B9@gemini.denx.de>
Message-ID: <000a01c89eb5$29eb3a10$070514ac@atmel.com>

> In message <1208027381.23686.10.camel at elrond.atmel.sweden> you wrote:
>> 
>> Add environment for the date when U-Boot is built
> 
> It seems that nobody is ever using this variable, so why add it?
> 
> Best regards,
> 
> Wolfgang Denk
> 


Have other patches in my own u-boot which uses it.
I plan to submit these patches later, but they depend on having other things included.


Best Regards
Ulf Samuelsson





From biggerbadderben at gmail.com  Tue Apr 15 07:00:33 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Tue, 15 Apr 2008 01:00:33 -0400
Subject: [U-Boot-Users] [PATCH 04/13] microblaze: add Emaclite ethernet
	driver
In-Reply-To: <20080414195049.BE758248A0@gemini.denx.de>
References: <4802FF86.8010504@seznam.cz>
	<20080414195049.BE758248A0@gemini.denx.de>
Message-ID: <f8328f7c0804142200s57aa5fect3307d85e3e188e3f@mail.gmail.com>

On Mon, Apr 14, 2008 at 3:50 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Michal,
>
>
>  in message <4802FF86.8010504 at seznam.cz> you wrote:
>  >
>  > this code was sent to mailing list I think twice. I think Grant reviewed this
>  > code once, didn't he?
>
>  Maybe, I don't remember the details. But if Ben had accepted the
>  patch, he would have checked it into the u-boot-net custodian
>  repository, where network stuff belongs to.
>
>  It should not go through other repositories normally (unless Ben gives
>  his explicit permission).
>

I did see these patches, but haven't reviewed yet.  I'll have a look
in the next couple of days and will provide feedback.

regards,
Ben



From r63238 at freescale.com  Tue Apr 15 07:10:29 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 15 Apr 2008 13:10:29 +0800
Subject: [U-Boot-Users] [PATCH 1/3] mpc83xx: update the default load address
	for 837xemds	board
Message-ID: <1208236229.3656.1.camel@localhost.localdomain>

Update the default load address. if not, the kernel image
will be overwritten when u-boot boot the latest linux kernel.

Signed-off-by: Dave Liu <daveliu at freescale.com>
---
 include/configs/MPC837XEMDS.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h
index 7fc0f7e..b2b4aa1 100644
--- a/include/configs/MPC837XEMDS.h
+++ b/include/configs/MPC837XEMDS.h
@@ -595,7 +595,7 @@
 
 #define CONFIG_BAUDRATE 115200
 
-#define CONFIG_LOADADDR 200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR 2000000	/* default location for tftp and bootm */
 
 #define CONFIG_BOOTDELAY 6	/* -1 disables auto-boot */
 #undef CONFIG_BOOTARGS		/* the boot command will set bootargs */
@@ -605,7 +605,7 @@
    "consoledev=ttyS0\0"							\
    "ramdiskaddr=1000000\0"						\
    "ramdiskfile=ramfs.83xx\0"						\
-   "fdtaddr=400000\0"							\
+   "fdtaddr=3000000\0"							\
    "fdtfile=mpc8379_mds.dtb\0"						\
    ""
 
-- 
1.5.4.rc4






From r63238 at freescale.com  Tue Apr 15 07:11:11 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 15 Apr 2008 13:11:11 +0800
Subject: [U-Boot-Users] [PATCH 2/3] mpc83xx: remove the unused CPM's stuff
Message-ID: <1208236272.3656.2.camel@localhost.localdomain>

The MPC83xx family never have CPM block, so remove it from 83xx.

Signed-off-by: Dave Liu <daveliu at freescale.com>
---
 cpu/mpc83xx/fdt.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/cpu/mpc83xx/fdt.c b/cpu/mpc83xx/fdt.c
index b39f678..02c4d05 100644
--- a/cpu/mpc83xx/fdt.c
+++ b/cpu/mpc83xx/fdt.c
@@ -63,13 +63,5 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 		"clock-frequency", bd->bi_busfreq, 1);
 #endif
 
-#ifdef CONFIG_CPM2
-	do_fixup_by_compat_u32(blob, "fsl,cpm2-scc-uart",
-		"current-speed", bd->bi_baudrate, 1);
-
-	do_fixup_by_compat_u32(blob, "fsl,cpm2-brg",
-		"clock-frequency", bd->bi_brgfreq, 1);
-#endif
-
 	fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
 }
-- 
1.5.4.rc4






From r63238 at freescale.com  Tue Apr 15 07:12:23 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 15 Apr 2008 13:12:23 +0800
Subject: [U-Boot-Users] [PATCH 3/3] mpc83xx: clean up the readme for 83xx
	boards
Message-ID: <1208236343.3656.4.camel@localhost.localdomain>

1. correct the typo
2. correct the memory map for 837xerdb board

Signed-off-by: Dave Liu <daveliu at freescale.com>
---
 doc/README.mpc8313erdb |    4 ++--
 doc/README.mpc8315erdb |    2 +-
 doc/README.mpc837xemds |    2 +-
 doc/README.mpc837xerdb |   13 ++++++-------
 4 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/doc/README.mpc8313erdb b/doc/README.mpc8313erdb
index 7ad4cc7..21580f9 100644
--- a/doc/README.mpc8313erdb
+++ b/doc/README.mpc8313erdb
@@ -3,10 +3,10 @@ Freescale MPC8313ERDB Board
 
 1.	Board Switches and Jumpers
 
-	SW3 is used to set CFG_RESET_SOURCE.
+	S3 is used to set CFG_RESET_SOURCE.
 
 	To boot the image at 0xFE000000 in NOR flash, use these DIP
-	switche settings for SW3 SW4:
+	switch settings for S3 S4:
 
 	+------+	+------+
 	|      |	| **** |
diff --git a/doc/README.mpc8315erdb b/doc/README.mpc8315erdb
index c630cf8..e77eba7 100644
--- a/doc/README.mpc8315erdb
+++ b/doc/README.mpc8315erdb
@@ -6,7 +6,7 @@ Freescale MPC8315ERDB Board
 	S3 is used to set CFG_RESET_SOURCE.
 
 	To boot the image at 0xFE000000 in NOR flash, use these DIP
-	switche settings for S3 S4:
+	switch settings for S3 S4:
 
 	+------+	+------+
 	|      |	| **** |
diff --git a/doc/README.mpc837xemds b/doc/README.mpc837xemds
index 3f0cdf7..7823595 100644
--- a/doc/README.mpc837xemds
+++ b/doc/README.mpc837xemds
@@ -49,7 +49,7 @@ Freescale MPC837xEMDS Board
 	0xe010_0000	0xe02f_ffff	Empty			2M
 	0xe030_0000	0xe03f_ffff	PCI IO			1M
 	0xe040_0000	0xe05f_ffff	Empty			2M
-	0xe060_0000	0xe060_8000	NAND Flash		32K
+	0xe060_0000	0xe060_7fff	NAND Flash		32K
 	0xf400_0000	0xf7ff_ffff	Empty			64M
 	0xf800_0000	0xf800_7fff	BCSR on CS1		32K
 	0xfe00_0000	0xffff_ffff	NOR Flash on CS0	32M
diff --git a/doc/README.mpc837xerdb b/doc/README.mpc837xerdb
index 8f0192a..510e3bb 100644
--- a/doc/README.mpc837xerdb
+++ b/doc/README.mpc837xerdb
@@ -1,4 +1,4 @@
-Freescale MPC837xEMDS Board
+Freescale MPC837xE-RDB Board
 -----------------------------------------
 
 1.	Board Description
@@ -38,12 +38,11 @@ Freescale MPC837xEMDS Board
 	===========================	=================	=======		=========
 	0x0000_0000	0x0fff_ffff	DDR			256M		64
 	0x1000_0000	0x7fff_ffff	Empty			1.75G		-
-	0x8000_0000	0x9fff_ffff	PCI1 memory space	512M		32
-	0xa000_0000	0xbfff_ffff	PCI2 memory space	512M		32
-	0xc200_0000	0xc2ff_ffff	PCI1 I/O space		16M		32
-	0xc300_0000	0xc3ff_ffff	PCI2 I/O space		16M		32
+	0x8000_0000	0x8fff_ffff	PCI MEM prefetch	256M		32
+	0x9000_0000	0x9fff_ffff	PCI MEM non-prefetch	256M		32
+	0xe030_0000	0xe03f_ffff	PCI I/O space		1M		32
 	0xe000_0000	0xe00f_ffff	Int Mem Reg Space	1M		-
-	0xe280_0000	0xe47f_ffff	NAND Flash		32M		8
+	0xe060_0000	0xe060_7fff	NAND Flash		32K		8
 	0xfe00_0000	0xfe7f_ffff	NOR Flash on CS0	8M		16
 
 
@@ -55,7 +54,7 @@ Freescale MPC837xEMDS Board
 
     CONFIG_MPC83XX	    MPC83xx family for both MPC8349 and MPC8360
     CONFIG_MPC837X	    MPC837x specific
-    CONFIG_MPC837XERDB	    MPC837XEMDS board specific
+    CONFIG_MPC837XERDB	    MPC837xE-RDB board specific
 
 
 4. Compilation
-- 
1.5.4.rc4






From r63238 at freescale.com  Tue Apr 15 07:22:03 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 15 Apr 2008 13:22:03 +0800
Subject: [U-Boot-Users] [PATCH][RFC] lib_ppc: make the flush_cache stronger
Message-ID: <1208236923.3656.15.camel@localhost.localdomain>

Current flush_cache code does

1. clean the dcache with dcbst, but not invalidate dcache
2. invalidate icache

This patch use the dcbf instead of dcbst to have stronger
semantic, clean the dcache and invalidate dcache.

Signed-off-by: Dave Liu <daveliu at freescale.com>
---

To meet DMA safe operation on cache enabled system, such as
DMA_TO_DEVICE/DMA_FROM_DEVICE/DMA_BIDIRECTIONAL

We have two options:

1. Separate functions for them like linux kernel.
   A. clean dcache (dcbst) for DMA_TO_DEVICE
   B. invalidate dcache (dcbi) for DMA_FROM_DEVICE
   C. flush dcache (dcbf) for DMA_BIDIRECTIONAL.
2. Make current flush_cache stronger semanctic.
   use the dcbf instead of dcbst.

Which one is better? or you have better option?
Please suggest.

Thanks,
Dave

 lib_ppc/cache.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib_ppc/cache.c b/lib_ppc/cache.c
index 27e1a82..f4039ba 100644
--- a/lib_ppc/cache.c
+++ b/lib_ppc/cache.c
@@ -34,9 +34,9 @@ void flush_cache (ulong start_addr, ulong size)
 		for (addr = start_addr;
 		     addr < end_addr;
 		     addr += CFG_CACHELINE_SIZE) {
-			asm ("dcbst 0,%0": :"r" (addr));
+			asm ("dcbf 0,%0": :"r" (addr));
 		}
-		asm ("sync");	/* Wait for all dcbst to complete on bus */
+		asm ("sync");	/* Wait for all dcbf to complete on bus */
 
 		for (addr = start_addr;
 		     addr < end_addr;
-- 
1.5.4.rc4






From r.schwebel at pengutronix.de  Tue Apr 15 07:37:46 2008
From: r.schwebel at pengutronix.de (Robert Schwebel)
Date: Tue, 15 Apr 2008 07:37:46 +0200
Subject: [U-Boot-Users] [PATCH] Fix name of i.MX31 boards in config	file
	header
In-Reply-To: <4803BFA8.4020104@gmail.com>
References: <4803BFA8.4020104@gmail.com>
Message-ID: <20080415053746.GG13814@pengutronix.de>

On Mon, Apr 14, 2008 at 10:33:44PM +0200, Magnus Lilja wrote:
> - * Configuration settings for the 242x TI H4 board.
> + * Configuration settings for the phyCORE i.MX31 board.

This is "phyCORE-i.MX31".

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9




From r.schwebel at pengutronix.de  Tue Apr 15 07:39:19 2008
From: r.schwebel at pengutronix.de (Robert Schwebel)
Date: Tue, 15 Apr 2008 07:39:19 +0200
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: <Pine.LNX.4.64.0804150024500.5332@axis700.grange>
References: <20080414195049.D198D248B9@gemini.denx.de>
	<Pine.LNX.4.64.0804150024500.5332@axis700.grange>
Message-ID: <20080415053919.GH13814@pengutronix.de>

On Tue, Apr 15, 2008 at 12:28:21AM +0200, Guennadi Liakhovetski wrote:
> I personally do prefer when unneeded .c files do not get compiled at
> all, rather than compiled to "0"-byte big objects. Makes the build
> process and the resulting tree look cleaner, and the image a bit
> smaller.

That's how it is done in u-boot-v2, btw.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9




From joakim.tjernlund at transmode.se  Tue Apr 15 08:40:21 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 15 Apr 2008 08:40:21 +0200
Subject: [U-Boot-Users] [PATCH] Move init_sequence table into code.
In-Reply-To: <20080415043518.9FF24248BB@gemini.denx.de>
References: <20080415043518.9FF24248BB@gemini.denx.de>
Message-ID: <1208241621.5911.32.camel@gentoo-jocke.transmode.se>


On Tue, 2008-04-15 at 06:35 +0200, Wolfgang Denk wrote:
> In message <1208207184.5911.26.camel at gentoo-jocke.transmode.se> you wrote:
> > 
> > It is a step closer towards full relocation of u-boot, I want to get rid
> > of using global data while in FLASH.
> 
> I doubt that this will work, but I'd love to be surprised :-)

It is not going to be a walk in the park :) The big remaining part
is string literals while still in flash, not sure how to solve these
yet.

> 
> > > The original idea of having such a list  of  funtion  pointers  which
> > > just  get executed one after another was to be able to wrap this into
> > > some "#ifndef CONFIG_INIT_SEQUENCE" and use this to allow for  board-
> > > specific init sequences by just adding a #define with the needed list
> > > of functions to the board config files.
> > 
> > You can do that with weak functions too. Just make all the functions
> > weak, then a board can overide with its own function.
> 
> That would not, for example, to allow to change the sequence - say
> one board needs to initialize PCI very early, but another one very
> late.

True, but as no one even uses this code ATM, it can't be a big deal.

 Jocke



From ulf.samuelsson at atmel.com  Tue Apr 15 09:58:23 2008
From: ulf.samuelsson at atmel.com (Ulf Samuelsson)
Date: Tue, 15 Apr 2008 09:58:23 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
References: <20080414195050.3D821248A0@gemini.denx.de>
Message-ID: <010601c89ed1$e51c4dd0$070514ac@atmel.com>

> In message <1208030816.23686.13.camel at elrond.atmel.sweden> you wrote:
>> 
>> Add support for the AT91RM9200EK Board.
> 
> I guess you are aware that the merge window is not open, i. e. you are
> submitting this only for discussion here...
> 

The goal is to have the board included when the merge window reopens.

>> diff -urN u-boot.cmp/board/atmel/at91rm9200ek/at91rm9200ek.c u-boot/board/atmel/at91rm9200ek/at91rm9200ek.c
>> --- u-boot.cmp/board/atmel/at91rm9200ek/at91rm9200ek.c 1970-01-01 01:00:00.000000000 +0100
>> +++ u-boot/board/atmel/at91rm9200ek/at91rm9200ek.c 2008-04-12 21:28:59.000000000 +0200
>> @@ -0,0 +1,142 @@
>> +/*
>> + * (C) Copyright 2002
>> + * Sysgo Real-Time Solutions, GmbH <www.elinos.com>
>> + * Marius Groeger <mgroeger at sysgo.de>
> 
> A new file, and these are the only copyright holders? Really? Ditto
> for the other files.
> 

Not a new file, a 3+ years old file.

> There are coding style issues: trailing white space,

OK.

>> diff -urN u-boot.cmp/board/atmel/at91rm9200ek/flash.c u-boot/board/atmel/at91rm9200ek/flash.c
>> --- u-boot.cmp/board/atmel/at91rm9200ek/flash.c 1970-01-01 01:00:00.000000000 +0100
>> +++ u-boot/board/atmel/at91rm9200ek/flash.c 2008-04-12 21:15:08.000000000 +0200
>> @@ -0,0 +1,509 @@
>> +/*
>> + * (C) Copyright 2002
>> + * Lineo, Inc. <www.lineo.com>
>> + * Bernhard Kuhn <bkuhn at lineo.com>
> 
> I think this is CFI conformant flash, isn't it? So please use the CFI
> driver instead.

This code has been tested on the AT91RM9200EK board (not by me)
and CFI code has not been tested on the AT91RM9200EK board.

So I see four possible choices.
1) Do not add AT91RM9200EK support in u-boot.
2) Add current *tested* support for AT91RM9200EK
3) Add AT91RM9200EK with CFI support without more than rudimentary testing
4) Wait until someone else tests CFI support on AT91RM9200EK and submits

----
Option 5) 
    "Add AT91RM9200EK after me thorougly testing CFI support" 
    is not going to happen due to time constraints and/or other priorities.

The flash driver already exists in the AT91RM9200DK board support package.
This board is obsolete since 4 years or so.
Most people using U-boot for AT91 does not use the main trunk.
They use the Atmel specific version for which there exist no good method
for non-Atmel people to submit patches.

I think the most practical approach to allow getting rid of the Atmel specific
version is to include the legacy stuff (AT91RM9200 related) first.
Then move the shared stuff to an board/atmel/common directory
to make it easy to clean up for those interested later.

> 
> Best regards,
> 


Best Regards
Ulf Samuelsson




From g.liakhovetski at gmx.de  Tue Apr 15 10:24:14 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Tue, 15 Apr 2008 10:24:14 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH 1/2 v2] Additional PCI IDs for IDE and
	network controllers
In-Reply-To: <20080414063340.5D7E2248B9@gemini.denx.de>
References: <20080414063340.5D7E2248B9@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804151021100.5159@axis700.grange>

These PCI IDs are required by the Linkstation platforms.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

---

diff --git a/include/pci_ids.h b/include/pci_ids.h
index 5481fff..61c2203 100644
--- a/include/pci_ids.h
+++ b/include/pci_ids.h
@@ -1472,6 +1472,8 @@
 #define PCI_DEVICE_ID_ITE_IT8172G	0x8172
 #define PCI_DEVICE_ID_ITE_IT8172G_AUDIO 0x0801
 #define PCI_DEVICE_ID_ITE_IT8181	0x8181
+#define PCI_DEVICE_ID_ITE_8211		0x8211
+#define PCI_DEVICE_ID_ITE_8212		0x8212
 #define PCI_DEVICE_ID_ITE_8872		0x8872
 
 #define PCI_DEVICE_ID_ITE_IT8330G_0	0xe886
@@ -2073,3 +2075,6 @@
 #define PCI_DEVICE_ID_MPC8641		0x7010
 #define PCI_DEVICE_ID_MPC8641D		0x7011
 #define PCI_DEVICE_ID_MPC8610		0x7018
+
+#define PCI_VENDOR_ID_ADMTEK		0x1317
+#define PCI_DEVICE_ID_ADMTEK_AN983B	0x0985



From Frank.Prepelica at ubidyne.com  Tue Apr 15 10:34:40 2008
From: Frank.Prepelica at ubidyne.com (Frank Prepelica)
Date: Tue, 15 Apr 2008 10:34:40 +0200
Subject: [U-Boot-Users] How to configure the MPC8313ERDB to support 2x128MB
	DDR
Message-ID: <29DC34A6B43468409F5A371CFE34E8496357FA@ex01.ads.ubidyne.de>

Hi all,

 

I'm using a customized MPC8313ERDB board, which means we replaced the
Vitesse switch with a second

Marvell PHY and we are using 64MB of NOR flash instead of 8MB.

Furthermore we added a second DDR RAM (additional 128MB) on that board. 

 

I adapted U-Boot (v1.3.1) to support the 64MB flash memory and the
second Marvell PHY. This works really fine.

But I got problems when adding the second 128MB RAM module. 

 

I just thought I change the value of 

 

#define CFG_DDR_SIZE to 256

 

But after that I see the 128MB of the first RAM module mirrored at
address 0x0800 0000.

 

Therefore I guess there's more configuration necessary, of course there
is.

 

I don't know where to set the DDRLAWBAR1 to base address 0x0800 0000
because I can't even see 

DDRLAWBAR0 for the first 128MB RAM module. I found nothing in the
MPC8313ERDB.h

 

Could anyone please tell me which defines I have to change or I have to
add. Are there further changes necessary in the

board specific file sdram.c?

 

Thanks for any hint!

 

 

Best regards,

 

	
	 	 
 


Frank Prepelica
Software Design Engineer

Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany

Phone:             +49 731 88 00 71 58

Fax:                 +49 731 88 00 71 99
Email:              frank.prepelica at ubidyne.com
Homepage:       www.ubidyne.com <http://www.ubidyne.com> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080415/36aa82a5/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 83 bytes
Desc: image002.gif
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080415/36aa82a5/attachment.gif 

From lg at denx.de  Tue Apr 15 10:54:49 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Tue, 15 Apr 2008 10:54:49 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH v2 3/7] add an i2c driver for mx31
In-Reply-To: <20080415043518.B01BE24657@gemini.denx.de>
References: <20080415043518.B01BE24657@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804151031580.5159@axis700.grange>

On Tue, 15 Apr 2008, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0804150024500.5332 at axis700.grange> you wrote:
> > > 
> > > Aren't we just moving the #ifdef hell from one place to another?
> > 
> > Wouldn't it be logical to assume, that if CONFIG_I2C_MXC is defined, 
> > CONFIG_HARD_I2C is meant too? So, we could just put in i2c.h
> 
> Well, what exactly is CONFIG_I2C_MXC supposed to mean? Sorry for
> asking, but I cannot find it documented anywhere (hint! hint! This
> needs to be fixed!). I tend to believe that in it's current form it's
> redundant, meaning that we have both CONFIG_CMD_I2C and CONFIG_MX31.

Ok, looking at examples, e.g., at cpu/mpc824x/drivers/i2c/i2c.c, it looks 
like u-boot presumes, that a system may only want to use one (hardware) 
i2c driver. I don't understand why this restriction is made, but if we 
want to keep it, we could just drop CONFIG_I2C_MXC and just use 
CONFIG_HARD_I2C. As for redundancy - that's exactly the reason why I don't 
think it is redundant. I can imagine an i.MX31 based system with another 
hardware i2c controller, wanting to use the external one and not needing 
the built-in one.

My preference would be to let CONFIG_I2C_MXC mean "use the mxc_i2c.c 
driver for I2C controllers like those on i.MX* / MXC SoCs from Freescale," 
similar to how i2c host drivers under drivers/i2c use their (also not 
always documented) config options:

CONFIG_TSI108_I2C, CONFIG_DRIVER_OMAP24XX_I2C, CONFIG_DRIVER_OMAP1510_I2C

and they just define both the hartdware-specific config and 
CONFIG_HARD_I2C in their *_config.h, but check only for the specific one 
in the .c file. So, shall I just remove the ifdef from .c, add

OBJS-$(CONFIG_I2C_MXC) += ...

to the Makefile and add it to the README?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From r63238 at freescale.com  Tue Apr 15 11:12:17 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 15 Apr 2008 17:12:17 +0800
Subject: [U-Boot-Users] How to configure the MPC8313ERDB to
	support	2x128MBDDR
In-Reply-To: <29DC34A6B43468409F5A371CFE34E8496357FA@ex01.ads.ubidyne.de>
References: <29DC34A6B43468409F5A371CFE34E8496357FA@ex01.ads.ubidyne.de>
Message-ID: <1208250737.3785.7.camel@localhost.localdomain>

<snip>
> I?m using a customized MPC8313ERDB board, which means we replaced the
> Vitesse switch with a second
> 
> Marvell PHY and we are using 64MB of NOR flash instead of 8MB.
> 
> Furthermore we added a second DDR RAM (additional 128MB) on that
> board. 

Did the second DDR RAM module use the other chip select?
If yes, you have to enable the chip select for it. 

> I adapted U-Boot (v1.3.1) to support the 64MB flash memory and the
> second Marvell PHY. This works really fine.
> 
> But I got problems when adding the second 128MB RAM module. 
> 
> I just thought I change the value of 
> #define CFG_DDR_SIZE to 256

not enough if you only change it.

> But after that I see the 128MB of the first RAM module mirrored at
> address 0x0800 0000.

> Therefore I guess there?s more configuration necessary, of course
> there is.
> I don?t know where to set the DDRLAWBAR1 to base address 0x0800 0000
> because I can?t even see 
> 
> DDRLAWBAR0 for the first 128MB RAM module. I found nothing in the
> MPC8313ERDB.h

If you are using the mpc8313erdb/sdram.c as reference, I believe the
code auto-calculate the DDRLAW (256MB).
 
> 
> Could anyone please tell me which defines I have to change or I have
> to add. Are there further changes necessary in the
> 
> board specific file sdram.c?






From pierre.savary at kerlink.fr  Tue Apr 15 12:18:20 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Tue, 15 Apr 2008 12:18:20 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <20080412112810.5b874157@mjolnir.drzeus.cx>
References: <20080411174827.105e31ef@mjolnir.drzeus.cx>	<AA28F077645B324881335614E4F7C428034CB5@win-ex01.bench.com>
	<20080412112810.5b874157@mjolnir.drzeus.cx>
Message-ID: <000001c89ee2$09250e00$1b6f2a00$@savary@kerlink.fr>

Then my MMC 4GB works with my Linux kernel but if I can't load my kernel
(located on the first part of this MMC) ... it's not really interesting :(

So, somebody does already use MMC v4 with U-boot???

Thanks in advance

Pierre

-----Message d'origine-----
De?: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] De la part de Pierre
Ossman
Envoy??: samedi 12 avril 2008 11:28
??: Ken.Fuchs at bench.com
Cc?: pierre.savary at kerlink.fr; u-boot-users at lists.sourceforge.net
Objet?: Re: [U-Boot-Users] drivers MMCplus for at91sam9x

On Fri, 11 Apr 2008 13:54:13 -0500
Ken.Fuchs at bench.com wrote:

> 
> The manual for the AT91SAM926x processors clearly states that the
> MCI controller supports MMC 2.2.  I asked Atmel whether this controller
> could support 4 bits to an MMC 4.x chip and they said _no_.   The answer
> is supposedly from their engineering group in France.
> 

What they answered was if Atmel would support such a solution, not if
the hardware would.

> 
> How does one program the MCI controller to send 4 bit (parallel) data
> an MMC 4.x chip, with or without telling it that it is communicating
> to a 4-bit SD chip?  The only way to get 4 bits of data out of the MCI
> is to tell it that it is connected to a SD (1.0) chip.  If you program
> the MCI to communicate with an MMC chip, it will send data out only on
> the low order bit.

You tell it to use all four bits. That's it. The setting isn't MMC/SD,
it's 1-bit/4-bit.

> Both ends of the communication link must considered.  It may not be
> sufficient that the MMC chip is MMC 4.x; The fact that the MCI
> controller is only MMC 2.2 or SD 1.0 compliant, may or may not impact
> this special handling.

It does not in the slightest. Remember that these controllers are
extremely dumb. The low level behaviour of the protocol hasn't changed
since the very first specs, so only software needs to be changed to
support even the newest features.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users




From lg at denx.de  Tue Apr 15 13:32:55 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Tue, 15 Apr 2008 13:32:55 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH 1/3] New i.MX31 SPI driver
Message-ID: <Pine.LNX.4.64.0804151323530.5159@axis700.grange>

This is an SPI driver for i.MX and MXC based SoCs from Freescale. So far 
only implemented and tested on i.MX31, can with a modified register layout 
and definitions be used for i.MX27, I think, MXC CPUs have similar SPI 
controllers too.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

diff --git a/README b/README
index 0a04d73..4556e87 100644
--- a/README
+++ b/README
@@ -1406,6 +1407,11 @@ The following options need to be configured:
 		Currently supported on some MPC8xxx processors.  For an
 		example, see include/configs/mpc8349emds.h.
 
+		CONFIG_MXC_SPI
+
+		Enables the driver for the SPI controllers on i.MX and MXC
+		SoCs. Currently only i.MX31 is supported.
+
 - FPGA Support: CONFIG_FPGA
 
 		Enables FPGA subsystem.
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 0b7a2df..bc8a104 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
 LIB	:= $(obj)libspi.a
 
 COBJS-y += mpc8xxx_spi.o
+COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
new file mode 100644
index 0000000..da1a9e3
--- /dev/null
+++ b/drivers/spi/mxc_spi.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright (C) 2008 Sascha Hauer, Pengutronix 
+ *
+ * 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 <common.h>
+#include <spi.h>
+#include <asm/io.h>
+
+#ifdef CONFIG_MX27
+/* i.MX27 has a completely wrong register layout and register definitions in the
+ * datasheet, the correct one is in the Freescale's Linux driver */
+
+#error "i.MX27 CSPI not supported due to drastic differences in register definisions" \
+"See linux mxc_spi driver from Freescale for details."
+
+#else
+
+#define MXC_CSPIRXDATA		0x00
+#define MXC_CSPITXDATA		0x04
+#define MXC_CSPICTRL		0x08
+#define MXC_CSPIINT		0x0C
+#define MXC_CSPIDMA		0x10
+#define MXC_CSPISTAT		0x14
+#define MXC_CSPIPERIOD		0x18
+#define MXC_CSPITEST		0x1C
+#define MXC_CSPIRESET		0x00
+
+#define MXC_CSPICTRL_EN		(1 << 0)
+#define MXC_CSPICTRL_MODE	(1 << 1)
+#define MXC_CSPICTRL_XCH	(1 << 2)
+#define MXC_CSPICTRL_SMC	(1 << 3)
+#define MXC_CSPICTRL_POL	(1 << 4)
+#define MXC_CSPICTRL_PHA	(1 << 5)
+#define MXC_CSPICTRL_SSCTL	(1 << 6)
+#define MXC_CSPICTRL_SSPOL 	(1 << 7)
+#define MXC_CSPICTRL_CHIPSELECT(x)	(((x) & 0x3) << 24)
+#define MXC_CSPICTRL_BITCOUNT(x)	(((x) & 0x1f) << 8)
+#define MXC_CSPICTRL_DATARATE(x)	(((x) & 0x7) << 16)
+
+#define MXC_CSPIPERIOD_32KHZ	(1 << 15)
+
+static unsigned long spi_bases[] = {
+	0x43fa4000,
+	0x50010000,
+	0x53f84000,
+};
+
+static unsigned long spi_base;
+
+#endif
+
+spi_chipsel_type spi_chipsel[] = {
+	(spi_chipsel_type)0,
+	(spi_chipsel_type)1,
+	(spi_chipsel_type)2,
+	(spi_chipsel_type)3,
+};
+int spi_chipsel_cnt = sizeof(spi_chipsel) / sizeof(spi_chipsel[0]);
+
+static inline u32 reg_read(unsigned long addr)
+{
+	return *(volatile unsigned long*)addr;
+}
+
+static inline void reg_write(unsigned long addr, u32 val)
+{
+	*(volatile unsigned long*)addr = val;
+}
+
+static u32 spi_xchg_single(u32 data, int bitlen)
+{
+
+	unsigned int cfg_reg = reg_read(spi_base + MXC_CSPICTRL);
+
+	if (MXC_CSPICTRL_BITCOUNT(bitlen - 1) != (cfg_reg & MXC_CSPICTRL_BITCOUNT(31))) {
+		cfg_reg = (cfg_reg & ~MXC_CSPICTRL_BITCOUNT(31)) |
+			MXC_CSPICTRL_BITCOUNT(bitlen - 1);
+		reg_write(spi_base + MXC_CSPICTRL, cfg_reg);
+	}
+
+	reg_write(spi_base + MXC_CSPITXDATA, data);
+
+	cfg_reg |= MXC_CSPICTRL_XCH;
+
+	reg_write(spi_base + MXC_CSPICTRL, cfg_reg);
+
+	while (reg_read(spi_base + MXC_CSPICTRL) & MXC_CSPICTRL_XCH)
+		;
+
+	return reg_read(spi_base + MXC_CSPIRXDATA);
+}
+
+int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
+{
+	int n_blks = (bitlen + 31) / 32;
+	u32 *out_l, *in_l;
+	int i;
+
+	if ((int)dout & 3 || (int)din & 3) {
+		printf("Error: unaligned buffers in: %p, out: %p\n", din, dout);
+		return 1;
+	}
+
+	if (!spi_base)
+		spi_select(CONFIG_MXC_SPI_IFACE, (int)chipsel, SPI_MODE_2 | SPI_CS_HIGH);
+
+	for (i = 0, in_l = (u32 *)din, out_l = (u32 *)dout;
+	     i < n_blks;
+	     i++, in_l++, out_l++, bitlen -= 32)
+		*in_l = spi_xchg_single(*out_l, bitlen);
+
+	return 0;
+}
+
+void spi_init(void)
+{
+}
+
+int spi_select(unsigned int bus, unsigned int dev, unsigned long mode)
+{
+	unsigned int ctrl_reg;
+
+	if (bus >= sizeof(spi_bases) / sizeof(spi_bases[0]) ||
+	    dev > 3)
+		return 1;
+
+	spi_base = spi_bases[bus];
+
+	ctrl_reg = MXC_CSPICTRL_CHIPSELECT(dev) |
+		MXC_CSPICTRL_BITCOUNT(31) |
+		MXC_CSPICTRL_DATARATE(7) | /* FIXME: calculate data rate */
+		MXC_CSPICTRL_EN |
+		MXC_CSPICTRL_MODE;
+
+	if (mode & SPI_CPHA)
+		ctrl_reg |= MXC_CSPICTRL_PHA;
+	if (!(mode & SPI_CPOL))
+		ctrl_reg |= MXC_CSPICTRL_POL;
+	if (mode & SPI_CS_HIGH)
+		ctrl_reg |= MXC_CSPICTRL_SSPOL;
+
+	reg_write(spi_base + MXC_CSPIRESET, 1);
+	udelay(1);
+	reg_write(spi_base + MXC_CSPICTRL, ctrl_reg);
+	reg_write(spi_base + MXC_CSPIPERIOD,
+		  MXC_CSPIPERIOD_32KHZ);
+	reg_write(spi_base + MXC_CSPIINT, 0);
+
+	return 0;
+}
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h b/include/asm-arm/arch-mx31/mx31-regs.h
index e9c7671..ba9080e 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -37,6 +37,9 @@
 #define CCM_UPCTL	(CCM_BASE + 0x10)
 #define CCM_SPCTL	(CCM_BASE + 0x18)
 #define CCM_COSR	(CCM_BASE + 0x1C)
+#define CCM_CGR0	(CCM_BASE + 0x20)
+#define CCM_CGR1	(CCM_BASE + 0x24)
+#define CCM_CGR2	(CCM_BASE + 0x28)
 
 #define CCMR_MDS	(1 << 7)
 #define CCMR_SBYCS	(1 << 4)
@@ -118,7 +121,9 @@
 #define MUX_CTL_RXD1		0x82
 #define MUX_CTL_TXD1		0x83
 #define MUX_CTL_CSPI2_MISO	0x84
-/* 0x85 .. 0x8a */
+#define MUX_CTL_CSPI2_SS0	0x85
+#define MUX_CTL_CSPI2_SS1	0x86
+#define MUX_CTL_CSPI2_SS2	0x87
 #define MUX_CTL_CSPI2_MOSI	0x8b
 
 /* The modes a specific pin can be in
diff --git a/include/spi.h b/include/spi.h
index 03dc5bc..3a55a68 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -24,6 +24,18 @@
 #ifndef _SPI_H_
 #define _SPI_H_
 
+/* SPI mode flags */
+#define	SPI_CPHA	0x01			/* clock phase */
+#define	SPI_CPOL	0x02			/* clock polarity */
+#define	SPI_MODE_0	(0|0)			/* (original MicroWire) */
+#define	SPI_MODE_1	(0|SPI_CPHA)
+#define	SPI_MODE_2	(SPI_CPOL|0)
+#define	SPI_MODE_3	(SPI_CPOL|SPI_CPHA)
+#define	SPI_CS_HIGH	0x04			/* chipselect active high? */
+#define	SPI_LSB_FIRST	0x08			/* per-word bits-on-wire */
+#define	SPI_3WIRE	0x10			/* SI/SO signals shared */
+#define	SPI_LOOP	0x20			/* loopback mode */
+
 /*
  * The function call pointer type used to drive the chip select.
  */
@@ -68,6 +80,8 @@ void spi_init(void);
  *
  *   Returns: 0 on success, not 0 on failure
  */
-int  spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din);
+int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din);
+
+int spi_select(unsigned int bus, unsigned int dev, unsigned long mode);
 
 #endif	/* _SPI_H_ */



From lg at denx.de  Tue Apr 15 13:33:04 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Tue, 15 Apr 2008 13:33:04 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH 2/3] RTC driver for MC13783
Message-ID: <Pine.LNX.4.64.0804151327550.5159@axis700.grange>

MC13783 is a multifunction IS with an SPI interface to the host. This 
driver handles the RTC controller in this chip.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

diff --git a/README b/README
index 0a04d73..4556e87 100644
--- a/README
+++ b/README
@@ -689,6 +689,7 @@ The following options need to be configured:
 		CONFIG_RTC_DS164x	- use Dallas DS164x RTC
 		CONFIG_RTC_ISL1208	- use Intersil ISL1208 RTC
 		CONFIG_RTC_MAX6900	- use Maxim, Inc. MAX6900 RTC
+		CONFIG_RTC_MC13783	- use MC13783 RTC
 
 		Note that if the RTC uses I2C, then the I2C interface
 		must also be configured. See I2C Support, below.
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 800ab99..2e0c118 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -45,6 +45,7 @@ COBJS-y += m41t60.o
 COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
 COBJS-y += m48t35ax.o
 COBJS-y += max6900.o
+COBJS-$(CONFIG_RTC_MC13783) += mc13783-rtc.o
 COBJS-y += mc146818.o
 COBJS-y += mcfrtc.o
 COBJS-y += mk48t59.o
diff --git a/drivers/rtc/mc13783-rtc.c b/drivers/rtc/mc13783-rtc.c
new file mode 100644
index 0000000..35b1b8b
--- /dev/null
+++ b/drivers/rtc/mc13783-rtc.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright (C) 2008, Guennadi Liakhovetski <lg at denx.de>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <rtc.h>
+#include <spi.h>
+
+int rtc_get(struct rtc_time *rtc)
+{
+	u32 day1, day2, time;
+	u32 reg;
+	int err, tim, i = 0;
+
+	spi_select(1, 0, SPI_MODE_2 | SPI_CS_HIGH);
+
+	do {
+		reg = 0x2c000000;
+		err = spi_xfer(0, 32, (uchar *)&reg, (uchar *)&day1);
+
+		if (err)
+			return err;
+
+		reg = 0x28000000;
+		err = spi_xfer(0, 32, (uchar *)&reg, (uchar *)&time);
+
+		if (err)
+			return err;
+
+		reg = 0x2c000000;
+		err = spi_xfer(0, 32, (uchar *)&reg, (uchar *)&day2);
+
+		if (err)
+			return err;
+	} while (day1 != day2 && i++ < 3);
+
+	tim = day1 * 86400 + time;
+	to_tm(tim, rtc);
+
+	rtc->tm_yday = 0;
+	rtc->tm_isdst = 0;
+
+	return 0;
+}
+
+void rtc_set(struct rtc_time *rtc)
+{
+	u32 time, day, reg;
+
+	time = mktime(rtc->tm_year, rtc->tm_mon, rtc->tm_mday,
+		      rtc->tm_hour, rtc->tm_min, rtc->tm_sec);
+	day = time / 86400;
+	time %= 86400;
+
+	reg = 0x2c000000 | day | 0x80000000;
+	spi_xfer(0, 32, (uchar *)&reg, (uchar *)&day);
+
+	reg = 0x28000000 | time | 0x80000000;
+	spi_xfer(0, 32, (uchar *)&reg, (uchar *)&time);
+}
+
+void rtc_reset(void)
+{
+}



From lg at denx.de  Tue Apr 15 13:33:11 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Tue, 15 Apr 2008 13:33:11 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH 3/3] MX31ADS environment variable update,
	spi and rtc support
Message-ID: <Pine.LNX.4.64.0804151330040.5159@axis700.grange>

Update MX31ADS default environment to better match the flash layout and 
the memory map, support SPI and RTC.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c
index 5a7d8c9..a75cc2d 100644
--- a/board/mx31ads/mx31ads.c
+++ b/board/mx31ads/mx31ads.c
@@ -57,6 +57,18 @@ int board_init (void)
 	mx31_gpio_mux(MUX_RTS1__UART1_RTS_B);
 	mx31_gpio_mux(MUX_RTS1__UART1_CTS_B);
 
+	/* SPI2 */
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS2);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SCLK);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SPI_RDY);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_MOSI);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_MISO);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS0);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS1);
+
+	/* start SPI2 clock */
+	__REG(CCM_CGR2) = __REG(CCM_CGR2) | (3 << 4);
+
 	/* PBC setup */
 	/* Enable UART transceivers also reset the Ethernet/external UART */
 	readw(CS4_BASE + 4);
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index 78e2545..5286e1f 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -51,7 +51,7 @@
  * Size of malloc() pool
  */
 #define CFG_MALLOC_LEN		(CFG_ENV_SIZE + 128 * 1024)
-#define CFG_GBL_DATA_SIZE	128  /* size in bytes reserved for initial data */
+#define CFG_GBL_DATA_SIZE	128	/* size in bytes reserved for initial data */
 
 /*
  * Hardware drivers
@@ -60,6 +60,12 @@
 #define CONFIG_MX31_UART	1
 #define CFG_MX31_UART1		1
 
+#define CONFIG_HARD_SPI		1
+#define CONFIG_MXC_SPI		1
+#define CONFIG_MXC_SPI_IFACE	1	/* Default SPI interface number */
+
+#define CONFIG_RTC_MC13783	1
+
 /* allow to overwrite serial and ethaddr */
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_CONS_INDEX	1
@@ -73,20 +79,33 @@
 #include <config_cmd_default.h>
 
 #define CONFIG_CMD_PING
+#define CONFIG_CMD_SPI
+#define CONFIG_CMD_DATE
 
 #define CONFIG_BOOTDELAY	3
 
 #define CONFIG_NETMASK		255.255.255.0
 #define CONFIG_IPADDR		192.168.23.168
 #define CONFIG_SERVERIP		192.168.23.2
-
-#define	CONFIG_EXTRA_ENV_SETTINGS											\
-	"bootargs_base=setenv bootargs console=ttymxc0,115200\0"							\
-	"bootargs_nfs=setenv bootargs $(bootargs) root=/dev/nfs ip=dhcp nfsroot=$(serverip):$(nfsrootfs),v3,tcp\0"	\
-	"bootcmd=run bootcmd_net\0"											\
-	"bootcmd_net=run bootargs_base bootargs_mtd bootargs_nfs; tftpboot 0x80000000 uImage-mx31; bootm\0"		\
-	"prg_uboot=tftpboot 0x80000000 u-boot-mx31ads.bin; protect off 0xa0000000 0xa001ffff; erase 0xa0000000 0xa001ffff; cp.b 0x80000000 0xa0000000 $(filesize)\0"
-
+#define CONFIG_LOADADDR		(CSD0_BASE + 0x800000)	/* loadaddr env var */
+
+#define	CONFIG_EXTRA_ENV_SETTINGS					\
+	"netdev=eth0\0"							\
+	"uboot_addr=0xa0000000\0"					\
+	"uboot=mx31ads/u-boot.bin\0"					\
+	"kernel=mx31ads/uImage\0"					\
+	"nfsroot=/opt/eldk/arm\0"					\
+	"bootargs_base=setenv bootargs console=ttymxc0,115200\0"	\
+	"bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs "	\
+		"ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0"	\
+	"bootcmd=run bootcmd_net\0"					\
+	"bootcmd_net=run bootargs_base bootargs_nfs; "			\
+		"tftpboot ${loadaddr} ${kernel}; bootm\0"		\
+	"prg_uboot=tftpboot ${loadaddr} ${uboot}; "			\
+		"protect off ${uboot_addr} 0xa003ffff; "		\
+		"erase ${uboot_addr} 0xa003ffff; "			\
+		"cp.b ${loadaddr} ${uboot_addr} ${filesize}; "		\
+		"setenv filesize; saveenv\0"
 
 #define CONFIG_DRIVER_CS8900	1
 #define CS8900_BASE		0xb4020300
@@ -120,7 +139,7 @@
 
 #undef	CFG_CLKS_IN_HZ		/* everything, incl board info, in Hz */
 
-#define CFG_LOAD_ADDR		CSD0_BASE	/* default load address */
+#define CFG_LOAD_ADDR		CONFIG_LOADADDR
 
 #define CFG_HZ			32000
 



From lg at denx.de  Tue Apr 15 14:14:25 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Tue, 15 Apr 2008 14:14:25 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH v2 1/3] New i.MX31 SPI driver
Message-ID: <Pine.LNX.4.64.0804151412120.5159@axis700.grange>

This is an SPI driver for i.MX and MXC based SoCs from Freescale. So far
only implemented and tested on i.MX31, can with a modified register layout
and definitions be used for i.MX27, I think, MXC CPUs have similar SPI
controllers too.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

Changes since v1: fix a copy-paste error

 README                                |    5 +
 drivers/spi/Makefile                  |    1 +
 drivers/spi/mxc_spi.c                 |  166 +++++++++++++++++++++++++++++++++
 include/asm-arm/arch-mx31/mx31-regs.h |    7 +-
 include/spi.h                         |   16 +++-
 5 files changed, 193 insertions(+), 2 deletions(-)
 create mode 100644 drivers/spi/mxc_spi.c

diff --git a/README b/README
index 7c16345..d201b92 100644
--- a/README
+++ b/README
@@ -1414,6 +1414,11 @@ The following options need to be configured:
 		Currently supported on some MPC8xxx processors.  For an
 		example, see include/configs/mpc8349emds.h.
 
+		CONFIG_MXC_SPI
+
+		Enables the driver for the SPI controllers on i.MX and MXC
+		SoCs. Currently only i.MX31 is supported.
+
 - FPGA Support: CONFIG_FPGA
 
 		Enables FPGA subsystem.
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 0b7a2df..bc8a104 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
 LIB	:= $(obj)libspi.a
 
 COBJS-y += mpc8xxx_spi.o
+COBJS-$(CONFIG_MXC_SPI) += mxc_spi.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
new file mode 100644
index 0000000..b2e3ab9
--- /dev/null
+++ b/drivers/spi/mxc_spi.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright (C) 2008, Guennadi Liakhovetski <lg at denx.de>
+ *
+ * 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 <common.h>
+#include <spi.h>
+#include <asm/io.h>
+
+#ifdef CONFIG_MX27
+/* i.MX27 has a completely wrong register layout and register definitions in the
+ * datasheet, the correct one is in the Freescale's Linux driver */
+
+#error "i.MX27 CSPI not supported due to drastic differences in register definisions" \
+"See linux mxc_spi driver from Freescale for details."
+
+#else
+
+#define MXC_CSPIRXDATA		0x00
+#define MXC_CSPITXDATA		0x04
+#define MXC_CSPICTRL		0x08
+#define MXC_CSPIINT		0x0C
+#define MXC_CSPIDMA		0x10
+#define MXC_CSPISTAT		0x14
+#define MXC_CSPIPERIOD		0x18
+#define MXC_CSPITEST		0x1C
+#define MXC_CSPIRESET		0x00
+
+#define MXC_CSPICTRL_EN		(1 << 0)
+#define MXC_CSPICTRL_MODE	(1 << 1)
+#define MXC_CSPICTRL_XCH	(1 << 2)
+#define MXC_CSPICTRL_SMC	(1 << 3)
+#define MXC_CSPICTRL_POL	(1 << 4)
+#define MXC_CSPICTRL_PHA	(1 << 5)
+#define MXC_CSPICTRL_SSCTL	(1 << 6)
+#define MXC_CSPICTRL_SSPOL 	(1 << 7)
+#define MXC_CSPICTRL_CHIPSELECT(x)	(((x) & 0x3) << 24)
+#define MXC_CSPICTRL_BITCOUNT(x)	(((x) & 0x1f) << 8)
+#define MXC_CSPICTRL_DATARATE(x)	(((x) & 0x7) << 16)
+
+#define MXC_CSPIPERIOD_32KHZ	(1 << 15)
+
+static unsigned long spi_bases[] = {
+	0x43fa4000,
+	0x50010000,
+	0x53f84000,
+};
+
+static unsigned long spi_base;
+
+#endif
+
+spi_chipsel_type spi_chipsel[] = {
+	(spi_chipsel_type)0,
+	(spi_chipsel_type)1,
+	(spi_chipsel_type)2,
+	(spi_chipsel_type)3,
+};
+int spi_chipsel_cnt = sizeof(spi_chipsel) / sizeof(spi_chipsel[0]);
+
+static inline u32 reg_read(unsigned long addr)
+{
+	return *(volatile unsigned long*)addr;
+}
+
+static inline void reg_write(unsigned long addr, u32 val)
+{
+	*(volatile unsigned long*)addr = val;
+}
+
+static u32 spi_xchg_single(u32 data, int bitlen)
+{
+
+	unsigned int cfg_reg = reg_read(spi_base + MXC_CSPICTRL);
+
+	if (MXC_CSPICTRL_BITCOUNT(bitlen - 1) != (cfg_reg & MXC_CSPICTRL_BITCOUNT(31))) {
+		cfg_reg = (cfg_reg & ~MXC_CSPICTRL_BITCOUNT(31)) |
+			MXC_CSPICTRL_BITCOUNT(bitlen - 1);
+		reg_write(spi_base + MXC_CSPICTRL, cfg_reg);
+	}
+
+	reg_write(spi_base + MXC_CSPITXDATA, data);
+
+	cfg_reg |= MXC_CSPICTRL_XCH;
+
+	reg_write(spi_base + MXC_CSPICTRL, cfg_reg);
+
+	while (reg_read(spi_base + MXC_CSPICTRL) & MXC_CSPICTRL_XCH)
+		;
+
+	return reg_read(spi_base + MXC_CSPIRXDATA);
+}
+
+int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din)
+{
+	int n_blks = (bitlen + 31) / 32;
+	u32 *out_l, *in_l;
+	int i;
+
+	if ((int)dout & 3 || (int)din & 3) {
+		printf("Error: unaligned buffers in: %p, out: %p\n", din, dout);
+		return 1;
+	}
+
+	if (!spi_base)
+		spi_select(CONFIG_MXC_SPI_IFACE, (int)chipsel, SPI_MODE_2 | SPI_CS_HIGH);
+
+	for (i = 0, in_l = (u32 *)din, out_l = (u32 *)dout;
+	     i < n_blks;
+	     i++, in_l++, out_l++, bitlen -= 32)
+		*in_l = spi_xchg_single(*out_l, bitlen);
+
+	return 0;
+}
+
+void spi_init(void)
+{
+}
+
+int spi_select(unsigned int bus, unsigned int dev, unsigned long mode)
+{
+	unsigned int ctrl_reg;
+
+	if (bus >= sizeof(spi_bases) / sizeof(spi_bases[0]) ||
+	    dev > 3)
+		return 1;
+
+	spi_base = spi_bases[bus];
+
+	ctrl_reg = MXC_CSPICTRL_CHIPSELECT(dev) |
+		MXC_CSPICTRL_BITCOUNT(31) |
+		MXC_CSPICTRL_DATARATE(7) | /* FIXME: calculate data rate */
+		MXC_CSPICTRL_EN |
+		MXC_CSPICTRL_MODE;
+
+	if (mode & SPI_CPHA)
+		ctrl_reg |= MXC_CSPICTRL_PHA;
+	if (!(mode & SPI_CPOL))
+		ctrl_reg |= MXC_CSPICTRL_POL;
+	if (mode & SPI_CS_HIGH)
+		ctrl_reg |= MXC_CSPICTRL_SSPOL;
+
+	reg_write(spi_base + MXC_CSPIRESET, 1);
+	udelay(1);
+	reg_write(spi_base + MXC_CSPICTRL, ctrl_reg);
+	reg_write(spi_base + MXC_CSPIPERIOD,
+		  MXC_CSPIPERIOD_32KHZ);
+	reg_write(spi_base + MXC_CSPIINT, 0);
+
+	return 0;
+}
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h b/include/asm-arm/arch-mx31/mx31-regs.h
index 380b401..d04072e 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -37,6 +37,9 @@
 #define CCM_UPCTL	(CCM_BASE + 0x10)
 #define CCM_SPCTL	(CCM_BASE + 0x18)
 #define CCM_COSR	(CCM_BASE + 0x1C)
+#define CCM_CGR0	(CCM_BASE + 0x20)
+#define CCM_CGR1	(CCM_BASE + 0x24)
+#define CCM_CGR2	(CCM_BASE + 0x28)
 
 #define CCMR_MDS	(1 << 7)
 #define CCMR_SBYCS	(1 << 4)
@@ -118,7 +121,9 @@
 #define MUX_CTL_RXD1		0x82
 #define MUX_CTL_TXD1		0x83
 #define MUX_CTL_CSPI2_MISO	0x84
-/* 0x85 .. 0x8a */
+#define MUX_CTL_CSPI2_SS0	0x85
+#define MUX_CTL_CSPI2_SS1	0x86
+#define MUX_CTL_CSPI2_SS2	0x87
 #define MUX_CTL_CSPI2_MOSI	0x8b
 
 /* The modes a specific pin can be in
diff --git a/include/spi.h b/include/spi.h
index 03dc5bc..3a55a68 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -24,6 +24,18 @@
 #ifndef _SPI_H_
 #define _SPI_H_
 
+/* SPI mode flags */
+#define	SPI_CPHA	0x01			/* clock phase */
+#define	SPI_CPOL	0x02			/* clock polarity */
+#define	SPI_MODE_0	(0|0)			/* (original MicroWire) */
+#define	SPI_MODE_1	(0|SPI_CPHA)
+#define	SPI_MODE_2	(SPI_CPOL|0)
+#define	SPI_MODE_3	(SPI_CPOL|SPI_CPHA)
+#define	SPI_CS_HIGH	0x04			/* chipselect active high? */
+#define	SPI_LSB_FIRST	0x08			/* per-word bits-on-wire */
+#define	SPI_3WIRE	0x10			/* SI/SO signals shared */
+#define	SPI_LOOP	0x20			/* loopback mode */
+
 /*
  * The function call pointer type used to drive the chip select.
  */
@@ -68,6 +80,8 @@ void spi_init(void);
  *
  *   Returns: 0 on success, not 0 on failure
  */
-int  spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din);
+int spi_xfer(spi_chipsel_type chipsel, int bitlen, uchar *dout, uchar *din);
+
+int spi_select(unsigned int bus, unsigned int dev, unsigned long mode);
 
 #endif	/* _SPI_H_ */
-- 
1.5.4




From lg at denx.de  Tue Apr 15 14:15:30 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Tue, 15 Apr 2008 14:15:30 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH v2 2/3] RTC driver for MC13783
Message-ID: <Pine.LNX.4.64.0804151414260.5159@axis700.grange>

MC13783 is a multifunction IS with an SPI interface to the host. This
driver handles the RTC controller in this chip.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

Changes since v1: update to current git HEAD

 README                    |    1 +
 drivers/rtc/Makefile      |    1 +
 drivers/rtc/mc13783-rtc.c |   82 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 84 insertions(+), 0 deletions(-)
 create mode 100644 drivers/rtc/mc13783-rtc.c

diff --git a/README b/README
index d201b92..7c5f9a0 100644
--- a/README
+++ b/README
@@ -672,6 +672,7 @@ The following options need to be configured:
 
 		CONFIG_RTC_MPC8xx	- use internal RTC of MPC8xx
 		CONFIG_RTC_PCF8563	- use Philips PCF8563 RTC
+		CONFIG_RTC_MC13783	- use MC13783 RTC
 		CONFIG_RTC_MC146818	- use MC146818 RTC
 		CONFIG_RTC_DS1307	- use Maxim, Inc. DS1307 RTC
 		CONFIG_RTC_DS1337	- use Maxim, Inc. DS1337 RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 800ab99..2e0c118 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -45,6 +45,7 @@ COBJS-y += m41t60.o
 COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
 COBJS-y += m48t35ax.o
 COBJS-y += max6900.o
+COBJS-$(CONFIG_RTC_MC13783) += mc13783-rtc.o
 COBJS-y += mc146818.o
 COBJS-y += mcfrtc.o
 COBJS-y += mk48t59.o
diff --git a/drivers/rtc/mc13783-rtc.c b/drivers/rtc/mc13783-rtc.c
new file mode 100644
index 0000000..35b1b8b
--- /dev/null
+++ b/drivers/rtc/mc13783-rtc.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright (C) 2008, Guennadi Liakhovetski <lg at denx.de>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <rtc.h>
+#include <spi.h>
+
+int rtc_get(struct rtc_time *rtc)
+{
+	u32 day1, day2, time;
+	u32 reg;
+	int err, tim, i = 0;
+
+	spi_select(1, 0, SPI_MODE_2 | SPI_CS_HIGH);
+
+	do {
+		reg = 0x2c000000;
+		err = spi_xfer(0, 32, (uchar *)&reg, (uchar *)&day1);
+
+		if (err)
+			return err;
+
+		reg = 0x28000000;
+		err = spi_xfer(0, 32, (uchar *)&reg, (uchar *)&time);
+
+		if (err)
+			return err;
+
+		reg = 0x2c000000;
+		err = spi_xfer(0, 32, (uchar *)&reg, (uchar *)&day2);
+
+		if (err)
+			return err;
+	} while (day1 != day2 && i++ < 3);
+
+	tim = day1 * 86400 + time;
+	to_tm(tim, rtc);
+
+	rtc->tm_yday = 0;
+	rtc->tm_isdst = 0;
+
+	return 0;
+}
+
+void rtc_set(struct rtc_time *rtc)
+{
+	u32 time, day, reg;
+
+	time = mktime(rtc->tm_year, rtc->tm_mon, rtc->tm_mday,
+		      rtc->tm_hour, rtc->tm_min, rtc->tm_sec);
+	day = time / 86400;
+	time %= 86400;
+
+	reg = 0x2c000000 | day | 0x80000000;
+	spi_xfer(0, 32, (uchar *)&reg, (uchar *)&day);
+
+	reg = 0x28000000 | time | 0x80000000;
+	spi_xfer(0, 32, (uchar *)&reg, (uchar *)&time);
+}
+
+void rtc_reset(void)
+{
+}
-- 
1.5.4




From monstr at seznam.cz  Tue Apr 15 15:01:42 2008
From: monstr at seznam.cz (Michal Simek)
Date: Tue, 15 Apr 2008 15:01:42 +0200
Subject: [U-Boot-Users] [PATCH 04/13] microblaze: add Emaclite ethernet
	driver
In-Reply-To: <f8328f7c0804142200s57aa5fect3307d85e3e188e3f@mail.gmail.com>
References: <4802FF86.8010504@seznam.cz>	
	<20080414195049.BE758248A0@gemini.denx.de>
	<f8328f7c0804142200s57aa5fect3307d85e3e188e3f@mail.gmail.com>
Message-ID: <4804A736.6010804@seznam.cz>

Hi Ben,

>> Dear Michal,
>>
>>  in message <4802FF86.8010504 at seznam.cz> you wrote:
>>  >
>>  > this code was sent to mailing list I think twice. I think Grant reviewed this
>>  > code once, didn't he?
>>
>>  Maybe, I don't remember the details. But if Ben had accepted the
>>  patch, he would have checked it into the u-boot-net custodian
>>  repository, where network stuff belongs to.
>>
>>  It should not go through other repositories normally (unless Ben gives
>>  his explicit permission).
>>
> 
> I did see these patches, but haven't reviewed yet.  I'll have a look
> in the next couple of days and will provide feedback.
> 
> regards,
> Ben

Thanks for it,

Michal Simek



From tveletip_1977 at 247onsitetech.com  Tue Apr 15 16:23:59 2008
From: tveletip_1977 at 247onsitetech.com (lyndel)
Date: Tue, 15 Apr 2008 08:23:59 -0600
Subject: [U-Boot-Users] Length and girth competition champion
Message-ID: <F707AF33.C%tveletip_1977@247onsitetech.com>

It will grown and grown with our new herbal formula http://www.niebagine.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080415/4d545c86/attachment.htm 

From plagnioj at jcrosoft.com  Tue Apr 15 16:20:52 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 15 Apr 2008 16:20:52 +0200
Subject: [U-Boot-Users] [PATCH 2/3] RTC driver for MC13783
In-Reply-To: <Pine.LNX.4.64.0804151327550.5159@axis700.grange>
References: <Pine.LNX.4.64.0804151327550.5159@axis700.grange>
Message-ID: <20080415142052.GA30532@game.jcrosoft.org>

On 13:33 Tue 15 Apr     , Guennadi Liakhovetski wrote:
> MC13783 is a multifunction IS with an SPI interface to the host. This 
> driver handles the RTC controller in this chip.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
Ack-By Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>



From wd at denx.de  Tue Apr 15 18:23:11 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 15 Apr 2008 18:23:11 +0200
Subject: [U-Boot-Users] [PATCH] Add build date environment variable
In-Reply-To: Your message of "Mon, 14 Apr 2008 22:44:56 +0200."
	<000a01c89eb5$29eb3a10$070514ac@atmel.com>
Message-ID: <20080415162311.4FFCC24657@gemini.denx.de>

In message <000a01c89eb5$29eb3a10$070514ac at atmel.com> you wrote:
>
> >> Add environment for the date when U-Boot is built
> > 
> > It seems that nobody is ever using this variable, so why add it?
> 
> Have other patches in my own u-boot which uses it.
> I plan to submit these patches later, but they depend on having other
> things included.

Then please include this with the first patch that actually uses the
feature.

And please make sure to document it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Superior ability breeds superior ambition.
	-- Spock, "Space Seed", stardate 3141.9



From wd at denx.de  Tue Apr 15 18:23:11 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 15 Apr 2008 18:23:11 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
In-Reply-To: Your message of "Tue, 15 Apr 2008 09:58:23 +0200."
	<010601c89ed1$e51c4dd0$070514ac@atmel.com>
Message-ID: <20080415162311.6022D248B9@gemini.denx.de>

In message <010601c89ed1$e51c4dd0$070514ac at atmel.com> you wrote:
>
> > I guess you are aware that the merge window is not open, i. e. you are
> > submitting this only for discussion here...
> 
> The goal is to have the board included when the merge window reopens.

OK, so this submission was for review only.

> >> @@ -0,0 +1,142 @@
> >> +/*
> >> + * (C) Copyright 2002
> >> + * Sysgo Real-Time Solutions, GmbH <www.elinos.com>
> >> + * Marius Groeger <mgroeger at sysgo.de>
> > 
> > A new file, and these are the only copyright holders? Really? Ditto
> > for the other files.
> > 
> 
> Not a new file, a 3+ years old file.

OK, but the copyright entries are still obviously not up to date.
Please fix.

In all similar files, too.

> >> --- u-boot.cmp/board/atmel/at91rm9200ek/flash.c 1970-01-01 01:00:00.000000000 +0100
> >> +++ u-boot/board/atmel/at91rm9200ek/flash.c 2008-04-12 21:15:08.000000000 +0200
> >> @@ -0,0 +1,509 @@
> >> +/*
> >> + * (C) Copyright 2002
> >> + * Lineo, Inc. <www.lineo.com>
> >> + * Bernhard Kuhn <bkuhn at lineo.com>
> > 
> > I think this is CFI conformant flash, isn't it? So please use the CFI
> > driver instead.
> 
> This code has been tested on the AT91RM9200EK board (not by me)
> and CFI code has not been tested on the AT91RM9200EK board.

Then please change the implementation to use the CFI driver, and test
it. There is enough time to make it for the next merge window.

> So I see four possible choices.
> 1) Do not add AT91RM9200EK support in u-boot.
> 2) Add current *tested* support for AT91RM9200EK
> 3) Add AT91RM9200EK with CFI support without more than rudimentary
> testing
> 4) Wait until someone else tests CFI support on AT91RM9200EK and submits
> ----
> Option 5) 
>     "Add AT91RM9200EK after me thorougly testing CFI support" 
>     is not going to happen due to time constraints and/or other
> priorities.

6) Submit patches for AT91RM9200EK with CFI support and wait for
   community feedback.
> 
> The flash driver already exists in the AT91RM9200DK board support
> package.

Yes, this is on the remove list, too.

> This board is obsolete since 4 years or so.

That doesn't really matter. We're talking about adding new code to
the public tree, and we have certain rules doing this. One of these
rules is not to repeat old mistakes - in this case not to add
proprietary flash drivers when the CFI driver can be used.

> I think the most practical approach to allow getting rid of the Atmel
> specific
> version is to include the legacy stuff (AT91RM9200 related) first.
> Then move the shared stuff to an board/atmel/common directory
> to make it easy to clean up for those interested later.

Sorry, we all know how the "clean up later" approach (doesn't) work.

Please change the implementation to use the CFI driver. I will reject
the proprietary flash driver unless there are strikt technical
reasons why the CFI driver cannot be used.

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: wd at denx.de
"I may be synthetic, but I'm not stupid"  -  the  artificial  person,
from _Aliens_



From Ken.Fuchs at bench.com  Tue Apr 15 18:51:18 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Tue, 15 Apr 2008 11:51:18 -0500
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <000001c89ee2$09250e00$1b6f2a00$@savary@kerlink.fr>
Message-ID: <AA28F077645B324881335614E4F7C428034CBC@win-ex01.bench.com>

Pierre Savary wrote:

> Then my MMC 4GB works with my Linux kernel but if I can't 
> load my kernel
> (located on the first part of this MMC) ... it's not really 
> interesting :(

> So, somebody does already use MMC v4 with U-boot???

Assuming a AT91SAM926x MCI controller:

Probably.  Given an MMC v2.x compliant U-Boot driver, it
would be relatively easy to add support for an MMC v4.x chip.
If there is an MMC v4.x compliant Linux driver, it could be
ported to U-Boot (Many, if not most, U-Boot drivers are ports
from the corresponding Linux driver.)  Alternatively, if both
an MMC v2.x compliant U-Boot driver and MMC v4.x compliant Linux
driver exist, the port would be trivial; just copy the MMC v4.x
Linux code into the corresponding places in the MMC v2.2 U-Boot
driver until it supports your MMC v4.x chip.

Such an MMC v4.x U-Boot AT91SAM926x MCI driver should be able to
support any v4.x MMC chip, at least via a one bit MMC bus.  (I
remain unconvinced that the AT91SAM926x MCI controller can support
a 4 bit MMC bus; only a working MCI driver using a 4 bit MMC bus
verified by a logic analyzer or similar compliance/debugging device
would be convincing enough.)

If the Linux AT91SAM926x MCI driver supports a 4 bit MMC bus, then
the U-Boot AT91SAM926x MCI driver can borrow the Linux driver's
code and support a 4 bit bus also.

Sincerely,

Ken Fuchs

> -----Message d'origine-----
> De?: u-boot-users-bounces at lists.sourceforge.net
> [mailto:u-boot-users-bounces at lists.sourceforge.net] De la 
> part de Pierre
> Ossman
> Envoy??: samedi 12 avril 2008 11:28
> ??: Ken.Fuchs at bench.com
> Cc?: pierre.savary at kerlink.fr; u-boot-users at lists.sourceforge.net
> Objet?: Re: [U-Boot-Users] drivers MMCplus for at91sam9x
> 
> On Fri, 11 Apr 2008 13:54:13 -0500
> Ken.Fuchs at bench.com wrote:
> 
> > 
> > The manual for the AT91SAM926x processors clearly states that the
> > MCI controller supports MMC 2.2.  I asked Atmel whether 
> this controller
> > could support 4 bits to an MMC 4.x chip and they said _no_. 
>   The answer
> > is supposedly from their engineering group in France.
> > 
> 
> What they answered was if Atmel would support such a solution, not if
> the hardware would.
> 
> > 
> > How does one program the MCI controller to send 4 bit 
> (parallel) data
> > an MMC 4.x chip, with or without telling it that it is communicating
> > to a 4-bit SD chip?  The only way to get 4 bits of data out 
> of the MCI
> > is to tell it that it is connected to a SD (1.0) chip.  If 
> you program
> > the MCI to communicate with an MMC chip, it will send data 
> out only on
> > the low order bit.
> 
> You tell it to use all four bits. That's it. The setting isn't MMC/SD,
> it's 1-bit/4-bit.
> 
> > Both ends of the communication link must considered.  It may not be
> > sufficient that the MMC chip is MMC 4.x; The fact that the MCI
> > controller is only MMC 2.2 or SD 1.0 compliant, may or may 
> not impact
> > this special handling.
> 
> It does not in the slightest. Remember that these controllers are
> extremely dumb. The low level behaviour of the protocol hasn't changed
> since the very first specs, so only software needs to be changed to
> support even the newest features.
> 
> Rgds
> -- 
>      -- Pierre Ossman
> 
>   Linux kernel, MMC maintainer        http://www.kernel.org
>   PulseAudio, core developer          http://pulseaudio.org
>   rdesktop, core developer          http://www.rdesktop.org
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to 
> save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
.sun.com/javao
ne
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users




From lilja.magnus at gmail.com  Tue Apr 15 19:09:10 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Tue, 15 Apr 2008 19:09:10 +0200
Subject: [U-Boot-Users] [PATCH] Fix name of i.MX31 boards in config file
 header
In-Reply-To: <20080415053746.GG13814@pengutronix.de>
References: <4803BFA8.4020104@gmail.com>
	<20080415053746.GG13814@pengutronix.de>
Message-ID: <4804E136.4050202@gmail.com>

Correct the name of the i.MX31 Litekit and phyCORE boards in config files.

Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
---

 Corrected the phyCORE name after comment from Robert Schwebel.

 include/configs/imx31_litekit.h |    2 +-
 include/configs/imx31_phycore.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 2a6f59a..777750b 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -4,7 +4,7 @@
  * Richard Woodruff <r-woodruff2 at ti.com>
  * Kshitij Gupta <kshitij at ti.com>
  *
- * Configuration settings for the 242x TI H4 board.
+ * Configuration settings for the LogicPD i.MX31 Litekit board.
  *
  * See file CREDITS for list of people who contributed to this
  * project.
diff --git a/include/configs/imx31_phycore.h b/include/configs/imx31_phycore.h
index e067b76..aaa3390 100644
--- a/include/configs/imx31_phycore.h
+++ b/include/configs/imx31_phycore.h
@@ -4,7 +4,7 @@
  * Richard Woodruff <r-woodruff2 at ti.com>
  * Kshitij Gupta <kshitij at ti.com>
  *
- * Configuration settings for the 242x TI H4 board.
+ * Configuration settings for the phyCORE-i.MX31 board.
  *
  * See file CREDITS for list of people who contributed to this
  * project.




From afleming at gmail.com  Tue Apr 15 21:25:15 2008
From: afleming at gmail.com (Andy Fleming)
Date: Tue, 15 Apr 2008 14:25:15 -0500
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <-6021840981243159212@unknownmsgid>
References: <20080411174827.105e31ef@mjolnir.drzeus.cx>
	<AA28F077645B324881335614E4F7C428034CB5@win-ex01.bench.com>
	<20080412112810.5b874157@mjolnir.drzeus.cx>
	<-6021840981243159212@unknownmsgid>
Message-ID: <2acbd3e40804151225y356cac7eh73887a55f9e268c9@mail.gmail.com>

On Tue, Apr 15, 2008 at 5:18 AM, Pierre Savary <pierre.savary at kerlink.fr> wrote:
> Then my MMC 4GB works with my Linux kernel but if I can't load my kernel
>  (located on the first part of this MMC) ... it's not really interesting :(
>
>  So, somebody does already use MMC v4 with U-boot???

I've got one that works.  However, I don't have a 4GB MMC card with
v4.  I thought I did, but it turned out the card just takes advantage
of the fact that older versions can address 4GB, even though the spec
says 2GB is the max.

However, I'm fairly confident in the code (it's been tested in
simulated environments, and reflects what the Linux code does).  I'm
currently working on bringing it forward to the top of tree (I started
it before drivers/ got rearranged).  I'm actually hoping to generalize
it some so we can share it between all MMC/SD users.

Andy



From ulf.samuelsson at atmel.com  Tue Apr 15 23:35:48 2008
From: ulf.samuelsson at atmel.com (Ulf Samuelsson)
Date: Tue, 15 Apr 2008 23:35:48 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
References: <20080415162311.6022D248B9@gemini.denx.de>
Message-ID: <01b601c89f40$b9b02030$070514ac@atmel.com>


> 6) Submit patches for AT91RM9200EK with CFI support and wait for
>   community feedback.
>> 

No time, so that won't happen (as I told you).

>> The flash driver already exists in the AT91RM9200DK board support
>> package.
> 
> Yes, this is on the remove list, too.
> 

Fine,
Once someone replaces the flash driver for the DK with CFI driver, and test it...
I can use this as the base for an AT91RM9200EK patch.

Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57



From stelian at popies.net  Wed Apr 16 00:01:17 2008
From: stelian at popies.net (Stelian Pop)
Date: Wed, 16 Apr 2008 00:01:17 +0200
Subject: [U-Boot-Users] [PATCH] Add support for AT91RM9200EK board
In-Reply-To: <01b601c89f40$b9b02030$070514ac@atmel.com>
References: <20080415162311.6022D248B9@gemini.denx.de>
	<01b601c89f40$b9b02030$070514ac@atmel.com>
Message-ID: <1208296877.398.4.camel@voyager.dsnet>


Le mardi 15 avril 2008 ? 23:35 +0200, Ulf Samuelsson a ?crit :
> > 6) Submit patches for AT91RM9200EK with CFI support and wait for
> >   community feedback.
> >> 
> 
> No time, so that won't happen (as I told you).

Did you look at what we're talking about ? Adding CFI support means:
	- removing the old driver
	- adding half a dozen #defines to the config file
	- some minimal glue to make the thing compile.
(and you even have working examples - the AT91CAP9ADK and AT91SAM9260
boards - to look at how it's done).

I'd say this is something that can be done in probably less time that
you're spending here arguing about it.

Stelian.
-- 
Stelian Pop <stelian at popies.net>




From arasv at magtech.com.au  Wed Apr 16 01:41:22 2008
From: arasv at magtech.com.au (Aras Vaichas)
Date: Wed, 16 Apr 2008 09:41:22 +1000
Subject: [U-Boot-Users] Modify Clock rate
In-Reply-To: <20080414223239.0a916549@uncle-pecos.Colorado.EDU>
References: <20080414223239.0a916549@uncle-pecos.Colorado.EDU>
Message-ID: <48053D22.6090708@magtech.com.au>

Loren A. Linden Levy wrote:
> Hi,
>
> Is there a way to modify the clock rate in u-boot? I want to
> artificially set the clock rate on an m5282 to 32MHz instead of
> 66MHz. Thanks for any advice.
>
>   
I don't know anything about this CPU at all but I know how to search for
things in source code.

What I did was:

$ grep -ir m5282 ./u-boot-source-code/

and discovered that this pattern appears in only a few unique files. A
file called cpu/mcf52x2/cpu_init.c looks like a likely candidate for
setting up CPU specific stuff to me.

I then had a quick look at this file and found an #if
defined(CONFIG_M5282) and a function called cpu_init_f(void). Looks like
a good place to start.

248 #if defined(CONFIG_M5282)
249 /*
250  * Breath some life into the CPU...
251  *
252  * Set up the memory map,
253  * initialize a bunch of registers,
254  * initialize the UPM's
255  */
256 void cpu_init_f(void)
257 {
258 #ifndef CONFIG_WATCHDOG
259         /* disable watchdog if we aren't using it */
260         MCFWTM_WCR = 0;
261 #endif
262
263 #ifndef CONFIG_MONITOR_IS_IN_RAM
264         /* Set speed /PLL */
265         MCFCLOCK_SYNCR =
266             MCFCLOCK_SYNCR_MFD(CFG_MFD) | MCFCLOCK_SYNCR_RFD(CFG_RFD);
267         while (!(MCFCLOCK_SYNSR & MCFCLOCK_SYNSR_LOCK)) ;


In fact, if you had of looked in the "doc" directory first, you would
have also seen this file doc/README.m68k which says:

143 CFG_MFD
144                 -- defines the PLL Multiplication Factor Devider
145                    (see table 9-4 of MCF user manual)
146 CFG_RFD         -- defines the PLL Reduce Frecuency Devider
147                    (see table 9-4 of MCF user manual)

I didn't know this CPU was an m68K based cpu, so I didn't know to do
this first. Did you know it was an m68K based CPU?

Then look up those registers to see where they might be set, usually
this occurs in the include directory:

$ grep -r CFG_MFD include/*
include/configs/EB+MCF-EV123.h:#define CFG_MFD                  0x01   
/* PLL Multiplication Factor Devider */
include/configs/M5282EVB.h:#define CFG_MFD                      0x02   
/* PLL Multiplication Factor Devider */

There you go. Easy. Make a copy of your config file, the board files and
you can make yourself a custom system.

Now just look up those registers in the PLL section of the datasheet for
your CPU.

Aras

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From gautham.kantharaju at gmail.com  Wed Apr 16 06:35:10 2008
From: gautham.kantharaju at gmail.com (Gautham K)
Date: Wed, 16 Apr 2008 10:05:10 +0530
Subject: [U-Boot-Users] File system
Message-ID: <bcd5c5130804152135p21d2c9b6v2987e911437a4d53@mail.gmail.com>

Hi ,

I am Gautham here, my kernel is up and running and atlast it gives :-
"Kernel panic unable to mount file system"

can anybody tell what may be the problem??

Thanx in advance,

Reagards,
-- 
Gautham

Neural Systems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080416/d2702bb3/attachment.htm 

From chetannanda at gmail.com  Wed Apr 16 07:30:00 2008
From: chetannanda at gmail.com (Chetan Nanda)
Date: Wed, 16 Apr 2008 11:00:00 +0530
Subject: [U-Boot-Users] File system
In-Reply-To: <bcd5c5130804152135p21d2c9b6v2987e911437a4d53@mail.gmail.com>
References: <bcd5c5130804152135p21d2c9b6v2987e911437a4d53@mail.gmail.com>
Message-ID: <7f245da80804152230m4f0a3419u18ff3bff41a13248@mail.gmail.com>

On Wed, Apr 16, 2008 at 10:05 AM, Gautham K
<gautham.kantharaju at gmail.com> wrote:
> Hi ,
>
> I am Gautham here, my kernel is up and running and atlast it gives :-
> "Kernel panic unable to mount file system"
>
Where is your root filesystem present (it could be on NFS server or
ramdisk included in kernel image)? and also 'bootarg' environment
variable should be properly set do that up-coming kernel able to find
root filesystem.
> can anybody tell what may be the problem??
>
> Thanx in advance,
>
>  Reagards,
> --
> Gautham
>
> Neural Systems
> -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
>  U-Boot-Users mailing list
>  U-Boot-Users at lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>



From matthias.fuchs at esd-electronics.com  Wed Apr 16 08:28:38 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Wed, 16 Apr 2008 08:28:38 +0200
Subject: [U-Boot-Users] PCI express NIC for testing?
In-Reply-To: <4801BC25.8060303@grandegger.com>
References: <4801BC25.8060303@grandegger.com>
Message-ID: <200804160828.38564.matthias.fuchs@esd-electronics.com>

Hi Wolfgang,

what about using a PCIe extension box with a conentional PCI NIC.
The EX-1010 (www.exsys.ch) is low cost for such a system.

Just an idea.

Matthias

On Sunday 13 April 2008 09:54:13 Wolfgang Grandegger wrote:
> Hello,
>
> I'm looking for a PCIe card, preferably a NIC, to test PCIe under
> U-Boot. I have realized, that the E1000 driver of U-Boot does not have
> support for PCIe cards. It actually lags behind the Linux driver a lot
> and porting seems to require substantial effort (different SPD EEPROM,
> PCIe, etc.). Are there other choices?
>
> TIA.
>
> Wolfgang.



From pmeloy at shaw.ca  Wed Apr 16 08:30:52 2008
From: pmeloy at shaw.ca (pat)
Date: Tue, 15 Apr 2008 23:30:52 -0700
Subject: [U-Boot-Users] Success after all with S3C2410 and 1.3.2
Message-ID: <1208327452.6472.4.camel@rhodan.shaw.ca>

I gave it one more shot using manually added Openmoko patches (just a
few) and using the qt2410.h in configs. I had to adjust a few things
then hunt down errors from missing or depricated config_cmd but now its
running!

Its too bad the openmoko patches weren't snapshotted against a release
version of u-boot. If I had any clue how to do it I'd make the patches
against 1.3.2 release for a fully featured smdk2410-alike (once I find
out if any less verbose problems exist in my setup and fix them).





From matthias.fuchs at esd-electronics.com  Wed Apr 16 08:31:39 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Wed, 16 Apr 2008 08:31:39 +0200
Subject: [U-Boot-Users] [PATCH] Add build date environment variable
In-Reply-To: <000a01c89eb5$29eb3a10$070514ac@atmel.com>
References: <20080414195050.2DBAC248B9@gemini.denx.de>
	<000a01c89eb5$29eb3a10$070514ac@atmel.com>
Message-ID: <200804160831.40088.matthias.fuchs@esd-electronics.com>

Hi Ulf.

did you have a look at the CONFIG_VERSION_VARIABLE option?
Even this is something different, it might help you.

Matthias

On Monday 14 April 2008 22:44:56 Ulf Samuelsson wrote:
> > In message <1208027381.23686.10.camel at elrond.atmel.sweden> you wrote:
> >> Add environment for the date when U-Boot is built
> >
> > It seems that nobody is ever using this variable, so why add it?
> >
> > Best regards,
> >
> > Wolfgang Denk
>
> Have other patches in my own u-boot which uses it.
> I plan to submit these patches later, but they depend on having other
> things included.



From pierre.savary at kerlink.fr  Wed Apr 16 10:55:47 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Wed, 16 Apr 2008 10:55:47 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <2acbd3e40804151225y356cac7eh73887a55f9e268c9@mail.gmail.com>
References: <20080411174827.105e31ef@mjolnir.drzeus.cx>	<AA28F077645B324881335614E4F7C428034CB5@win-ex01.bench.com>	<20080412112810.5b874157@mjolnir.drzeus.cx>	<-6021840981243159212@unknownmsgid>
	<2acbd3e40804151225y356cac7eh73887a55f9e268c9@mail.gmail.com>
Message-ID: <000901c89f9f$aa877680$ff966380$@savary@kerlink.fr>

Hi,
Perhaps that I could help you...? I could test it with many different MMC
(2GB, 4GB, 8GB) (Samsung and Micron). Could you share with me your source
code?
Thanks in advance for your help,

Best Regards

Pierre


-----Message d'origine-----
De?: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] De la part de Andy
Fleming
Envoy??: mardi 15 avril 2008 21:25
??: Pierre Savary
Cc?: u-boot-users at lists.sourceforge.net; drzeus-mmc at drzeus.cx
Objet?: Re: [U-Boot-Users] drivers MMCplus for at91sam9x

On Tue, Apr 15, 2008 at 5:18 AM, Pierre Savary <pierre.savary at kerlink.fr>
wrote:
> Then my MMC 4GB works with my Linux kernel but if I can't load my kernel
>  (located on the first part of this MMC) ... it's not really interesting
:(
>
>  So, somebody does already use MMC v4 with U-boot???

I've got one that works.  However, I don't have a 4GB MMC card with
v4.  I thought I did, but it turned out the card just takes advantage
of the fact that older versions can address 4GB, even though the spec
says 2GB is the max.

However, I'm fairly confident in the code (it's been tested in
simulated environments, and reflects what the Linux code does).  I'm
currently working on bringing it forward to the top of tree (I started
it before drivers/ got rearranged).  I'm actually hoping to generalize
it some so we can share it between all MMC/SD users.

Andy

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users




From luigi.mantellini at idf-hit.com  Wed Apr 16 12:44:20 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Wed, 16 Apr 2008 12:44:20 +0200
Subject: [U-Boot-Users] MTD Concat support
Message-ID: <1208342660.26135.33.camel@localhost>

Hi Guys,

I'm a question regarding the MTD Concat support in U-BOOT.
My system has 2 Flash (x16MB) driven by 2 different Chipselects. The
memory layout is the following:

[0xbe000000 -> 0xbeffffff ] Flash#0 CS#0
?[0xbf000000 -> 0xbfffffff ] Flash#1 CS#1

I would link to create a JFFS2 partition across the two flash banks with size about 28M. In other hands I should meet the following partition layout:

[0xbe000000 -> 0xbfc00000 ] JFFS2 root 
[0xbfc00000 -> 0xbfe00000 ] U-BOOT code
[0xbfe00000 -> 0xbfffffff ] DATA

Into the JFFS2 filesystem there are the Kernel images and a lot of spare datas.

How I can say to U-boot to consider the two flashes as a single space of
memory (in order to place a big JFFS2 filesystem)? In Linux I can
achieve this using the MTD Concat driver but I don't understand How I
can do in U-boot.

Thanks a lot for any comments.


ciao

luigi

-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650







From vlad at comsys.ro  Wed Apr 16 13:47:10 2008
From: vlad at comsys.ro (Vlad Lungu)
Date: Wed, 16 Apr 2008 14:47:10 +0300
Subject: [U-Boot-Users] MTD Concat support
In-Reply-To: <1208342660.26135.33.camel@localhost>
References: <1208342660.26135.33.camel@localhost>
Message-ID: <4805E73E.5050604@comsys.ro>

Luigi 'Comio' Mantellini wrote:
> Hi Guys,
>
> I'm a question regarding the MTD Concat support in U-BOOT.
> My system has 2 Flash (x16MB) driven by 2 different Chipselects. The
> memory layout is the following:
>
> [0xbe000000 -> 0xbeffffff ] Flash#0 CS#0
> ?[0xbf000000 -> 0xbfffffff ] Flash#1 CS#1
>
> I would link to create a JFFS2 partition across the two flash banks with size about 28M. In other hands I should meet the following partition layout:
>
> [0xbe000000 -> 0xbfc00000 ] JFFS2 root 
> [0xbfc00000 -> 0xbfe00000 ] U-BOOT code
> [0xbfe00000 -> 0xbfffffff ] DATA
>
>   
So you have 16+12Mo then u-boot then 2 Mo left. 
> Into the JFFS2 filesystem there are the Kernel images and a lot of spare datas.
>   
That's a rather big JFFS filesystem. Do you plan booting from it? Isn't 
it rather slow? It would take a few seconds (5-10) to
scan the FS on this under U-Boot. I would recommend two strategies here:
-put the uImage directly in the NOR flash. Maybe in those 2 Mo at the 
end or somewhere else. Update it from Linux
or if you screw up, from the network.
-create a smaller partition (like 4Mo) and keep two kernels there, main 
and spare. Mount it under /boot in Linux.
Boot from there. Use the rest of the available space as root with the 
MTD concat driver but don't touch it from U-Boot.
Will boot much faster than from a 28Mo partition, you can use *summary* 
information on root (not supported in U-Boot)
for faster mount in Linux, more versatile than uImage in NOR (you can 
have 1 or more spares depending on kernel sizes and partition size).
> How I can say to U-boot to consider the two flashes as a single space of
> memory (in order to place a big JFFS2 filesystem)? In Linux I can
> achieve this using the MTD Concat driver but I don't understand How I
> can do in U-boot.
>   
What you are asking could be already possible, or require just a few 
modifications, but you have to ask yourself: do I really HAVE to do this?

Regards,
Vlad




From luigi.mantellini at idf-hit.com  Wed Apr 16 14:26:10 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Wed, 16 Apr 2008 14:26:10 +0200
Subject: [U-Boot-Users] MTD Concat support
In-Reply-To: <4805E73E.5050604@comsys.ro>
References: <1208342660.26135.33.camel@localhost> <4805E73E.5050604@comsys.ro>
Message-ID: <1208348770.26135.51.camel@localhost>

Hi Vlad,
Hi list,

see inline comments.

On mer, 2008-04-16 at 14:47 +0300, Vlad Lungu wrote:
> Luigi 'Comio' Mantellini wrote:
> > Hi Guys,
> >
> ..
> > [0xbe000000 -> 0xbfc00000 ] JFFS2 root 
> > [0xbfc00000 -> 0xbfe00000 ] U-BOOT code
> > [0xbfe00000 -> 0xbfffffff ] DATA
> >
> >   
> So you have 16+12Mo then u-boot then 2 Mo left. 
Yes. :)
> > Into the JFFS2 filesystem there are the Kernel images and a lot of spare datas.
> >   
> That's a rather big JFFS filesystem. Do you plan booting from it? Isn't 
> it rather slow? It would take a few seconds (5-10) to
> scan the FS on this under U-Boot. I would recommend two strategies here:
I know that the JFFS2 is rather slow, but I have this constraint on my
application. The kernel images are provided as a big all-in-one file
that contains the kernel and the rootfs (which will mounted via a
loopback device). Unfortunately I cannot change this logic because a lot
of user-space software (made by external providers) assumes a big images
repository to store the monolithic images.

> -put the uImage directly in the NOR flash. Maybe in those 2 Mo at the 
> end or somewhere else. Update it from Linux
> or if you screw up, from the network.
> -create a smaller partition (like 4Mo) and keep two kernels there, main 
> and spare. Mount it under /boot in Linux.

I cannot follow these solutions because I need to keep monolithic images
(large about 8-10 MB) without explode them.

> Boot from there. Use the rest of the available space as root with the 
> MTD concat driver but don't touch it from U-Boot.
The JFFS2 partition will not contain the ready-for-use rootfs but
monolithic images that will be mounted using the loopback devices. This
is a constraint of my application :S and I cannot change it.

> Will boot much faster than from a 28Mo partition, you can use *summary* 
> information on root (not supported in U-Boot)
> for faster mount in Linux, more versatile than uImage in NOR (you can 
> have 1 or more spares depending on kernel sizes and partition size).

Can you explain this point?

> > How I can say to U-boot to consider the two flashes as a single space of
> > memory (in order to place a big JFFS2 filesystem)? In Linux I can
> > achieve this using the MTD Concat driver but I don't understand How I
> > can do in U-boot.
> >   
> What you are asking could be already possible, or require just a few 
> modifications, but you have to ask yourself: do I really HAVE to do this?
> 

The answer is pretty simple: the flash layout is a project
constraint :D. I know that this approach is very slow, but the target
application is a device that should be rebooted about once in a year.

Thanks a lot for your observations.

ciao

luigi
> Regards,
> Vlad

-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650







From vlad at comsys.ro  Wed Apr 16 15:05:25 2008
From: vlad at comsys.ro (Vlad Lungu)
Date: Wed, 16 Apr 2008 16:05:25 +0300
Subject: [U-Boot-Users] MTD Concat support
In-Reply-To: <1208348770.26135.51.camel@localhost>
References: <1208342660.26135.33.camel@localhost>	 <4805E73E.5050604@comsys.ro>
	<1208348770.26135.51.camel@localhost>
Message-ID: <4805F995.6090301@comsys.ro>

Luigi 'Comio' Mantellini wrote:
> Hi Vlad,
> Hi list,
>
> see inline comments.
>
> [SNIP]
>> That's a rather big JFFS filesystem. Do you plan booting from it? Isn't 
>> it rather slow? It would take a few seconds (5-10) to
>> scan the FS on this under U-Boot. I would recommend two strategies here:
>>     
> I know that the JFFS2 is rather slow, but I have this constraint on my
> application. The kernel images are provided as a big all-in-one file
> that contains the kernel and the rootfs (which will mounted via a
> loopback device). Unfortunately I cannot change this logic because a lot
> of user-space software (made by external providers) assumes a big images
> repository to store the monolithic images.
>
>   
At 8-10Mo, that's 2 , maybe 3 images. Definitely only 2 if you want any 
kind of performance
on this thing (full JFFS filesystems tend to be rather slow on write). 
As for loopback ... do you
mean ramdisk, by any chance? If not, is that some custom image format? 
Or you store the fs
image uncompressed in the uImage and  play games with offset and length? 
In that case,
you're killing performance again.
>> -put the uImage directly in the NOR flash. Maybe in those 2 Mo at the 
>> end or somewhere else. Update it from Linux
>> or if you screw up, from the network.
>> -create a smaller partition (like 4Mo) and keep two kernels there, main 
>> and spare. Mount it under /boot in Linux.
>>     
>
> I cannot follow these solutions because I need to keep monolithic images
> (large about 8-10 MB) without explode them.
>
>   
I was thinking in terms of smallish kernels + root on JFFS. This is not 
the case, it seems.
>> Boot from there. Use the rest of the available space as root with the 
>> MTD concat driver but don't touch it from U-Boot.
>>     
> The JFFS2 partition will not contain the ready-for-use rootfs but
> monolithic images that will be mounted using the loopback devices. This
> is a constraint of my application :S and I cannot change it.
>
>   
In this case, using JFFS is definitely overkill.
>> Will boot much faster than from a 28Mo partition, you can use *summary* 
>> information on root (not supported in U-Boot)
>> for faster mount in Linux, more versatile than uImage in NOR (you can 
>> have 1 or more spares depending on kernel sizes and partition size).
>>     
>
> Can you explain this point?
>
>   
This was valid in the context of "rootfs on JFFS", so disregard the 
observations.
>>> How I can say to U-boot to consider the two flashes as a single space of
>>> memory (in order to place a big JFFS2 filesystem)? In Linux I can
>>> achieve this using the MTD Concat driver but I don't understand How I
>>> can do in U-boot.
>>>   
>>>       
>> What you are asking could be already possible, or require just a few 
>> modifications, but you have to ask yourself: do I really HAVE to do this?
>>
>>     
>
> The answer is pretty simple: the flash layout is a project
> constraint :D. I know that this approach is very slow, but the target
> application is a device that should be rebooted about once in a year.
>   

Well, it all depends if you really mean loopback or if it is ramdisk. 
Loopback feels totally wrong unless the rootfs is read-only. Really.
If it is ramdisk, I guess you could store uImages directly in the NOR 
flash (one at the beginning, one at the end so you know you can
easily replace any of them, or if you know that they are <9Mo, 3 of them 
equally spaced).

Anyway,  back to your original question: if the flash devices are 
identical and the erase sectors have the same size, you could probably
 fill flash_info[] yourself instead of auto-detecting and pretend you 
have a single flash twice the size (i.e. 32Mo). After all, this is NOR
flash so you're not  actually using sector numbers like with NAND parts. 
And the addresses are consecutive, so for all intents and purposes,
it looks like a big flash until you do READ_ID.

Vlad





From luigi.mantellini at idf-hit.com  Wed Apr 16 15:55:32 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Wed, 16 Apr 2008 15:55:32 +0200
Subject: [U-Boot-Users] MTD Concat support
In-Reply-To: <4805F995.6090301@comsys.ro>
References: <1208342660.26135.33.camel@localhost>
	<4805E73E.5050604@comsys.ro> <1208348770.26135.51.camel@localhost>
	<4805F995.6090301@comsys.ro>
Message-ID: <1208354132.26135.61.camel@localhost>

Hi Vlad and list,

see inline comments.

On mer, 2008-04-16 at 16:05 +0300, Vlad Lungu wrote:
> Luigi 'Comio' Mantellini wrote:
> > .. cut...
> >
> > The answer is pretty simple: the flash layout is a project
> > constraint :D. I know that this approach is very slow, but the target
> > application is a device that should be rebooted about once in a year.
> >   
> 
> Well, it all depends if you really mean loopback or if it is ramdisk. 
> Loopback feels totally wrong unless the rootfs is read-only.

The rootfs will be Read-only. Any write access will be redirected to a
ramdisk. Only during the "upgrading" activity the JFFS2 will be write
from an custom user application, while during the normal activity both
JFFS2 and loopback-mounted Root filesystem will be Read-only.

> Really.
> If it is ramdisk, I guess you could store uImages directly in the NOR 
> flash (one at the beginning, one at the end so you know you can
> easily replace any of them, or if you know that they are <9Mo, 3 of them 
> equally spaced).

I cannot store the uImages in separated memory space...

> 
> Anyway,  back to your original question: if the flash devices are 
> identical and the erase sectors have the same size, you could probably
>  fill flash_info[] yourself instead of auto-detecting and pretend you 
> have a single flash twice the size (i.e. 32Mo). After all, this is NOR
> flash so you're not  actually using sector numbers like with NAND parts. 
> And the addresses are consecutive, so for all intents and purposes,
> it looks like a big flash until you do READ_ID.
> 

Ok. This can be a solution.

thanks

luigi
> Vlad
> 

-- 
     ______       Luigi Mantellini
   .'______'.     R&D - Software
  (.'      '.)    Industrie Dial Face S.p.A.
  ( :=----=: )    Via Canzo, 4
  ('.______.')    20068 Peschiera Borromeo (MI), Italy
   '.______.'     Tel.: +39 02 5167 2813
                  Fax:  +39 02 5167 2459
Ind.  Dial Face   Email: luigi.mantellini at idf-hit.com
www.idf-hit.com   GPG fingerprint: 3DD1 7B71 FBDF 6376 1B4A
                                   B003 175F E979 907E 1650







From schutztr_1960 at 04146572.schule.bwl.de  Wed Apr 16 15:57:16 2008
From: schutztr_1960 at 04146572.schule.bwl.de (Kiser)
Date: Wed, 16 Apr 2008 14:57:16 +0100
Subject: [U-Boot-Users] Half the time twice the erection
Message-ID: <87B90E72.2%schutztr_1960@04146572.schule.bwl.de>

Don't let the effects of aging diminish your sex life http://www.bueglani.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080416/eaae8c34/attachment.htm 

From giometti at enneenne.com  Wed Apr 16 18:46:06 2008
From: giometti at enneenne.com (Rodolfo Giometti)
Date: Wed, 16 Apr 2008 18:46:06 +0200
Subject: [U-Boot-Users] Again on PCMCIA/IDE and PXA270
Message-ID: <20080416164606.GE9860@enneenne.com>

Hello,

Using a 1GB CF on my system I get:

   equantum> pinit on
   KINGSTON CF CARD 1GB
               Fixed Disk Card
               IDE interface 
               [silicon] [unique] [single] [sleep] [standby] [idle] [low power]
   equantum> ide reset

   Reset IDE: Bus 0: ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x51
   OK 
     Device 0: ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_inb (dev= 0, port= 0x1f2) : @ 0x200001f2 -> 0x01
   ide_inb (dev= 0, port= 0x1f3) : @ 0x200001f3 -> 0x01
   ide_inb (dev= 0, port= 0x1f4) : @ 0x200001f4 -> 0x00
   ide_outb (dev= 0, port= 0x1f7, val= 0xec) : @ 0x200001f7
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x81
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x58
   in input data base for read is 200001f0

Here follows the CF configuration words from command IDENTIFY DEVICE:

   0000) 8a84:.. ae07:.. 0000:.. 1000:.. 0000:.. 4002:@. 3f00:?. 1e00:.. 
   0008) 203d: = 0000:.. 4643:FC 4731:G1 2042: B 2020:   2020:   2020:   
   0010) 3030:00 3030:00 3130:10 4642:FB 0200:.. 0200:.. 0400:.. 3032:02 
   0018) 3730:70 3130:10 3133:13 4643:FC 4320:C  5241:RA 2044: D 4731:G1 
   0020) 2042: B 2020:   2020:   2020:   2020:   2020:   2020:   2020:   
   0028) 2020:   2020:   2020:   2020:   2020:   2020:   2020:   0180:.. 
   0030) 0000:.. 0002:.. 0000:.. 0002:.. 0000:.. 0300:.. ae07:.. 1000:.. 
   0038) 3f00:?. 203d: = 1e00:.. 0001:.. 203d: = 1e00:.. 0000:.. 0000:.. 
   0040) 0300:.. 0000:.. 0000:.. 7800:x. 7800:x. 0000:.. 0000:.. 0000:.. 
   0048) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0050) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0058) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0060) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0068) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0070) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0078) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0080) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0088) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0090) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0098) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00a0) 0000:.. 0000:.. 0000:.. 9204:.. 1b00:.. 0000:.. 0000:.. 0000:.. 
   00a8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00b0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00b8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00c0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00c8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00d0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00d8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00e0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00e8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00f0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00f8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0100) 0000:.. 0000:.. e0ab:.. 02a3:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0108) 0000:.. 0000:.. 6002:`. f2a2:.. b001:.. f2a2:.. f487:.. 00a3:.. 
   0110) e0ab:.. 02a3:.. 8002:.. f2a2:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0118) 0000:.. 0000:.. 0000:.. 0000:.. c005:.. 01a3:.. 7802:x. f2a2:.. 
   0120) 8002:.. f2a2:.. 1400:.. 0000:.. c801:.. f2a2:.. 1800:.. 0000:.. 
   0128) 0b00:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0130) 0000:.. 0000:.. 0100:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0138) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. b001:.. f2a2:.. 
   0140) 0000:.. 0000:.. 80fe:.. efa2:.. 30fe:0. efa2:.. 44fe:D. efa2:.. 
   0148) 0000:.. 0000:.. 0200:.. 0000:.. 7c0b:|. 01a3:.. 0000:.. 0000:.. 
   0150) e001:.. f2a2:.. 0000:.. 0000:.. 6400:d. 0000:.. 0000:.. 0000:.. 
   0158) 0000:.. 0000:.. e002:.. f2a2:.. b001:.. f2a2:.. c802:.. f2a2:.. 
   0160) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0200:.. 0000:.. 
   0168) ffff:.. ffff:.. 30ff:0. efa2:.. 0200:.. 0000:.. 0100:.. 0000:.. 
   0170) 0100:.. 0000:.. 0caf:.. 6200:b. 0000:.. 0000:.. b40c:.. 01a3:.. 
   0178) 1cb7:.. 02a3:.. 0100:.. 0000:.. 0200:.. 0000:.. acf2:.. 00a3:.. 
   0180) 94f4:.. 00a3:.. 8034:.4 00a3:.. 0200:.. 0000:.. 3600:6. f0a2:.. 
   0188) 3132:12 0000:.. 0000:.. 0000:.. 0100:.. 0000:.. 0000:.. 0000:.. 
   0190) 0000:.. 0000:.. 0100:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0198) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   01a0) 0000:.. 0000:.. 0000:.. 0000:.. 0100:.. 0000:.. 0000:.. 0000:.. 
   01a8) 0000:.. 0000:.. 0100:.. 0000:.. a80d:.. 02a3:.. 0200:.. 0000:.. 
   01b0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   01b8) 0000:.. 0000:.. adff:.. efa2:.. 0600:.. 0000:.. c851:.Q 02a3:.. 
   01c0) ffff:.. ffff:.. ffff:.. ffff:.. c25b:.[ f3e9:.. a810:.. 00a3:.. 
   01c8) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01d0) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01d8) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01e0) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01e8) ffff:.. ffff:.. 0100:.. 0000:.. 0100:.. 0000:.. 28ca:(. 00a3:.. 
   01f0) 6400:d. 0000:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01f8) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 

The device is correctly identified:

   Model: CF CARD 1GB  Firm: 20070131 Ser#: FCG1 B      000010FB
               Type: Removable Hard Disk
               Capacity: 967.6 MB = 0.9 GB (1981728 x 512)
   ide_read dev 0 start 0, blocks 1 buffer at A2EFF91C
   ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x51
   IDE read: warning, device 0 not ready
   ide_outb (dev= 0, port= 0x1f7, val= 0xe5) : @ 0x200001f7
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x50
   ide_inb (dev= 0, port= 0x1f2) : @ 0x200001f2 -> 0x00
   Powersaving 00
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x50
   write low bits
   ide_outb (dev= 0, port= 0x1f2, val= 0x01) : @ 0x200001f2
   ide_outb (dev= 0, port= 0x1f3, val= 0x00) : @ 0x200001f3
   ide_outb (dev= 0, port= 0x1f4, val= 0x00) : @ 0x200001f4
   ide_outb (dev= 0, port= 0x1f5, val= 0x00) : @ 0x200001f5
   ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_outb (dev= 0, port= 0x1f7, val= 0x20) : @ 0x200001f7
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x80
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x58
   in input data base for read is 200001f0
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x50
   ide_inb (dev= 0, port= 0x1f1) : @ 0x200001f1 -> 0x00

Also we can read the first sector correctly (error == 0):

   IDE read: error 00
   ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_outb (dev= 0, port= 0x1f7, val= 0x03) : @ 0x200001f7
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x81
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x50
   ide_inb (dev= 0, port= 0x1f1) : @ 0x200001f1 -> 0x20
   IDE read: extd  20

But this is the *only* CF that works! Just putting another one I get:

   equantum> pinit on
    
               Fixed Disk Card
               IDE interface 
               [silicon] [single] [sleep] [standby] [idle] [low power]
   equantum> ide reset

   Reset IDE: Bus 0: ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x51
   OK 
     Device 0: ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_inb (dev= 0, port= 0x1f2) : @ 0x200001f2 -> 0xd1
   ide_outb (dev= 0, port= 0x1f7, val= 0xec) : @ 0x200001f7
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0xd1
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x58
   in input data base for read is 200001f0

   0000) 8a84:.. f401:.. 0000:.. 1000:.. 0000:.. 1002:.. 2000: . 0300:.. 
   0008) 00e8:.. 0000:.. 4349:CI 4146:AF 3031:01 3030:00 3030:00 3435:45 
   0010) 2031: 1 2020:   2020:   2020:   0200:.. 0200:.. 0400:.. 6172:ar 
   0018) 3330:30 302e:0. 6630:f0 6e49:nI 7564:ud 7473:ts 6972:ir 6c61:la 
   0020) 4320:C  2046: F 6143:aC 6472:dr 2020:   2020:   2020:   2020:   
   0028) 2020:   2020:   2020:   2020:   2020:   2020:   2020:   0100:.. 
   0030) 0000:.. 0002:.. 0000:.. 0002:.. 0000:.. 0100:.. f401:.. 1000:.. 
   0038) 2000: . 00e8:.. 0300:.. 0001:.. 00e8:.. 0300:.. 0000:.. 0000:.. 
   0040) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0048) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0050) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0058) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0060) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0068) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0070) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0078) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0080) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0088) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0090) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0098) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00a0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00a8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00b0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00b8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00c0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00c8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00d0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00d8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00e0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00e8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00f0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   00f8) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0100) 0000:.. 0000:.. e0ab:.. 02a3:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0108) 0000:.. 0000:.. 6002:`. f2a2:.. b001:.. f2a2:.. f487:.. 00a3:.. 
   0110) e0ab:.. 02a3:.. 8002:.. f2a2:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0118) 0000:.. 0000:.. 0000:.. 0000:.. c005:.. 01a3:.. 7802:x. f2a2:.. 
   0120) 8002:.. f2a2:.. 1400:.. 0000:.. c801:.. f2a2:.. 1800:.. 0000:.. 
   0128) 0b00:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0130) 0000:.. 0000:.. 0100:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0138) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. b001:.. f2a2:.. 
   0140) 0000:.. 0000:.. 80fe:.. efa2:.. 30fe:0. efa2:.. 44fe:D. efa2:.. 
   0148) 0000:.. 0000:.. 0200:.. 0000:.. 7c0b:|. 01a3:.. 0000:.. 0000:.. 
   0150) e001:.. f2a2:.. 0000:.. 0000:.. 6400:d. 0000:.. 0000:.. 0000:.. 
   0158) 0000:.. 0000:.. e002:.. f2a2:.. b001:.. f2a2:.. c802:.. f2a2:.. 
   0160) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0200:.. 0000:.. 
   0168) ffff:.. ffff:.. 30ff:0. efa2:.. 0200:.. 0000:.. 0100:.. 0000:.. 
   0170) 0100:.. 0000:.. 0caf:.. 6200:b. 0000:.. 0000:.. b40c:.. 01a3:.. 
   0178) 1cb7:.. 02a3:.. 0100:.. 0000:.. 0200:.. 0000:.. acf2:.. 00a3:.. 
   0180) 94f4:.. 00a3:.. 8034:.4 00a3:.. 0200:.. 0000:.. 3600:6. f0a2:.. 
   0188) 3132:12 0000:.. 0000:.. 0000:.. 0100:.. 0000:.. 0000:.. 0000:.. 
   0190) 0000:.. 0000:.. 0100:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   0198) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   01a0) 0000:.. 0000:.. 0000:.. 0000:.. 0100:.. 0000:.. 0000:.. 0000:.. 
   01a8) 0000:.. 0000:.. 0100:.. 0000:.. a80d:.. 02a3:.. 0200:.. 0000:.. 
   01b0) 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 0000:.. 
   01b8) 0000:.. 0000:.. adff:.. efa2:.. 0600:.. 0000:.. c851:.Q 02a3:.. 
   01c0) ffff:.. ffff:.. ffff:.. ffff:.. c25b:.[ f3e9:.. a810:.. 00a3:.. 
   01c8) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01d0) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01d8) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01e0) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01e8) ffff:.. ffff:.. 0100:.. 0000:.. 0100:.. 0000:.. 28ca:(. 00a3:.. 
   01f0) 6400:d. 0000:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 
   01f8) ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. ffff:.. 

The card is correctly identified:

   Model: Industrial CF Card Firm: ra03.00f Ser#: CIAF01000045 1
               Type: Removable Hard Disk
               Capacity: 125.0 MB = 0.1 GB (256000 x 512)
   ide_read dev 0 start 0, blocks 1 buffer at A2EFF91C
   ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0xd0
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x51
   IDE read: warning, device 0 not ready
   ide_outb (dev= 0, port= 0x1f7, val= 0xe5) : @ 0x200001f7
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0xd1
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x50
   ide_inb (dev= 0, port= 0x1f2) : @ 0x200001f2 -> 0x00
   Powersaving 00
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x50
   write low bits
   ide_outb (dev= 0, port= 0x1f2, val= 0x01) : @ 0x200001f2
   ide_outb (dev= 0, port= 0x1f3, val= 0x00) : @ 0x200001f3
   ide_outb (dev= 0, port= 0x1f4, val= 0x00) : @ 0x200001f4
   ide_outb (dev= 0, port= 0x1f5, val= 0x00) : @ 0x200001f5
   ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_outb (dev= 0, port= 0x1f7, val= 0x20) : @ 0x200001f7
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0xd1
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x51
   Error (no IRQ) dev 0 blk 0: status 0x51
   ide_inb (dev= 0, port= 0x1f1) : @ 0x200001f1 -> 0x10

But the ide_read() returns error!

   IDE read: error 10

Using the REQUEST_SENSE command I get:

   ide_outb (dev= 0, port= 0x1f6, val= 0xe0) : @ 0x200001f6
   ide_outb (dev= 0, port= 0x1f7, val= 0x03) : @ 0x200001f7
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0xd0
   ide_inb (dev= 0, port= 0x1f7) : @ 0x200001f7 -> 0x50
   ide_inb (dev= 0, port= 0x1f1) : @ 0x200001f1 -> 0x1f
   IDE read: extd  1f

Which means: Data Transfer Error / Aborted Command

Any suggestions?

Rodolfo

P.S. Sorry for the long post...

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at linux.it
Embedded Systems                     phone:	+39 349 2432127
UNIX programming                     skype:     rodolfo.giometti



From vlad at comsys.ro  Wed Apr 16 20:39:53 2008
From: vlad at comsys.ro (Vlad Lungu)
Date: Wed, 16 Apr 2008 21:39:53 +0300
Subject: [U-Boot-Users] MTD Concat support
In-Reply-To: <1208354132.26135.61.camel@localhost>
References: <1208342660.26135.33.camel@localhost>	<4805E73E.5050604@comsys.ro>
	<1208348770.26135.51.camel@localhost>	<4805F995.6090301@comsys.ro>
	<1208354132.26135.61.camel@localhost>
Message-ID: <480647F9.4080305@comsys.ro>

Luigi 'Comio' Mantellini wrote:
>>
>> Well, it all depends if you really mean loopback or if it is ramdisk. 
>> Loopback feels totally wrong unless the rootfs is read-only.
>>     
>
> The rootfs will be Read-only. Any write access will be redirected to a
> ramdisk. Only during the "upgrading" activity the JFFS2 will be write
> from an custom user application, while during the normal activity both
> JFFS2 and loopback-mounted Root filesystem will be Read-only.
>
>   
It still feels wrong :-), but I see how this is supposed to work.  
You're probably using just that 2 Mo piece for
data or you're not saving anything on the NOR flash. Highly customized 
application.
>> Really.
>> If it is ramdisk, I guess you could store uImages directly in the NOR 
>> flash (one at the beginning, one at the end so you know you can
>> easily replace any of them, or if you know that they are <9Mo, 3 of them 
>> equally spaced).
>>     
>
> I cannot store the uImages in separated memory space...
>
>   
I have some ideas about how you could do it, but it might be too much 
trouble and not enough gain.
>> Anyway,  back to your original question: if the flash devices are 
>> identical and the erase sectors have the same size, you could probably
>>  fill flash_info[] yourself instead of auto-detecting and pretend you 
>> have a single flash twice the size (i.e. 32Mo). After all, this is NOR
>> flash so you're not  actually using sector numbers like with NAND parts. 
>> And the addresses are consecutive, so for all intents and purposes,
>> it looks like a big flash until you do READ_ID.
>>
>>     
>
> Ok. This can be a solution.

This should be very easy to test. First, check the data sheet and see if 
all erase sectors are the same size (64ko or 128ko) or
inspect the device geometry (Number of Erase Block Regions,offset 2c in 
the CFI id string, should be 1). If not,
this will probably not work like described and you'll need to hack some 
structures a bit(provide fake erase block region info, from 2 to 4,
if more than 2, you're out of luck, but that's highly unlikely).  If 
they are equal:
a) if you're configuring flash_info[] by hand, double the sector number 
in the first element and don't fill the second
b) if you're auto-detecting, don't :-) Dump the info and fill the first 
element by hand, with twice the number of sectors.

Good luck,
Vlad




From luigi.mantellini at idf-hit.com  Wed Apr 16 21:11:31 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Wed, 16 Apr 2008 21:11:31 +0200
Subject: [U-Boot-Users] MTD Concat support
In-Reply-To: <480647F9.4080305@comsys.ro>
References: <1208342660.26135.33.camel@localhost>
	<4805E73E.5050604@comsys.ro> <1208348770.26135.51.camel@localhost>
	<4805F995.6090301@comsys.ro> <1208354132.26135.61.camel@localhost>
	<480647F9.4080305@comsys.ro>
Message-ID: <1208373091.3818.19.camel@cassini.comioland>

Hi Vlad,

Il giorno mer, 16/04/2008 alle 21.39 +0300, Vlad Lungu ha scritto:
> > The rootfs will be Read-only. Any write access will be redirected to a
> > ramdisk. Only during the "upgrading" activity the JFFS2 will be write
> > from an custom user application, while during the normal activity both
> > JFFS2 and loopback-mounted Root filesystem will be Read-only.
> >
> >   
> It still feels wrong :-), but I see how this is supposed to work.  
> You're probably using just that 2 Mo piece for
> data or you're not saving anything on the NOR flash. Highly customized 
> application.

The datas are "stored" on a ramdisk :) The system retrieves the
configuration from a remote system during booting.
    
> >
> > I cannot store the uImages in separated memory space...
> >
> >   
> I have some ideas about how you could do it, but it might be too much 
> trouble and not enough gain.

On this point I have a strong constraint: The Kernel image (vmlinux
+rootfs) cannot be modified by system.

> >
> > Ok. This can be a solution.
> 
> This should be very easy to test. First, check the data sheet and see if 
> all erase sectors are the same size (64ko or 128ko) or
> inspect the device geometry (Number of Erase Block Regions,offset 2c in 
> the CFI id string, should be 1). If not,
> this will probably not work like described and you'll need to hack some 
> structures a bit(provide fake erase block region info, from 2 to 4,
> if more than 2, you're out of luck, but that's highly unlikely).  If 
> they are equal:
> a) if you're configuring flash_info[] by hand, double the sector number 
> in the first element and don't fill the second
> b) if you're auto-detecting, don't :-) Dump the info and fill the first 
> element by hand, with twice the number of sectors.
> 

I have 2 identical flash chip from spansion. 

Anyway, from my modest point of view, the u-boot flash memory model is
too rigid. I would like a "linux" model like this:
                         -----------
                         |         |-> [ MTD Driver ] -> Flash 1 (Nor)
---> flash operation --> | MTD Mux |-> ?[ MTD Driver ] -> Flash 2 (Nand)
                         |         |-> ?[ MTD Driver ] -> Flash n (XXX)
                         -----------

MTD Mus is itself a MTD Driver. This infrastructure could be implemented
using smart descriptor to keep the need callback.

Best regards,

luigi


> Good luck,
> Vlad

-- 
Ing. Luigi Mantellini
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI)
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com
  




From luigi.mantellini at idf-hit.com  Wed Apr 16 23:06:00 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Wed, 16 Apr 2008 23:06:00 +0200
Subject: [U-Boot-Users] MTD Concat support
In-Reply-To: <48065219.6030003@comsys.ro>
References: <1208342660.26135.33.camel@localhost>
	<4805E73E.5050604@comsys.ro> <1208348770.26135.51.camel@localhost>
	<4805F995.6090301@comsys.ro> <1208354132.26135.61.camel@localhost>
	<480647F9.4080305@comsys.ro>
	<1208373091.3818.19.camel@cassini.comioland>
	<48065219.6030003@comsys.ro>
Message-ID: <1208379960.3818.34.camel@cassini.comioland>

Il giorno mer, 16/04/2008 alle 22.23 +0300, Vlad Lungu ha scritto:

> Luigi 'Comio' Mantellini wrote:
> [snip]
> > I have 2 identical flash chip from spansion. 
> >   
> Can you tell me the part number so I can do a quick check on it?


I'll send you the exact part number tomorrow.


> > Anyway, from my modest point of view, the u-boot flash memory model is
> > too rigid. I would like a "linux" model like this:
> >                          -----------
> >                          |         |-> [ MTD Driver ] -> Flash 1 (Nor)
> > ---> flash operation --> | MTD Mux |-> ?[ MTD Driver ] -> Flash 2 (Nand)
> >                          |         |-> ?[ MTD Driver ] -> Flash n (XXX)
> >                          -----------
> >   
> I don't think it works that way in Linux. The devices you're 
> concatenating must be basically the same (both nor or nand,
> same width, same sector size / OOB area size for NAND, etc ) . That's 
> what I understand after a quick read of the docs.
> 

Yes, you're right. I just proposed a different architecture that is not
implemented in U-boot :)


> > MTD Mus is itself a MTD Driver. This infrastructure could be implemented
> > using smart descriptor to keep the need callback.
> >   
> 
> You could easily do that, but you still need to have similar devices. 
> Anyway, we're talking about an embedded bootloader here, you put too 
> much stuff in it and it gets bigger than the actual application :-)
> 


I don't think that my proposed architecture is more complex than the
actual u-boot implementation. Anyway, to implement proposed idea, we
need a descriptor that keeps also the needed callbacks (like init,
getsize, writebuffer, ...) as well as needed information (address base,
bank number, ...). This architecture should permit to integrate and
create a single front-end for all mtd devices avoiding to replicate the
politics. Every mtd should define just the mechanisms and exports a
descriptor.

I think that these considerations are off-topic... but I prefer to share
my vision.

Thanks a lot,

luigi


> Vlad
> 


Ing. Luigi Mantellini
Industrie Dial Face S.p.A.
Via Canzo, 4 
20068 Peschiera Borromeo (MI)
Tel.: +39 02 5167 2813
Fax: +39 02 5167 2459
E-mail: luigi.mantellini at idf-hit.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080416/e844efa6/attachment.htm 

From nelson at telia.com  Wed Apr 16 23:34:24 2008
From: nelson at telia.com (cecilio arindam)
Date: Wed, 16 Apr 2008 21:34:24 +0000
Subject: [U-Boot-Users] Fw:
Message-ID: <000801c8a018$0264f4e3$42a5918a@rcwuag>

Visit our New Discount Shop and KEEP your greens INTACT!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080416/68d53eda/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 6006 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080416/68d53eda/attachment.gif 

From Ken.Fuchs at bench.com  Thu Apr 17 01:30:36 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 16 Apr 2008 18:30:36 -0500
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <2acbd3e40804151225y356cac7eh73887a55f9e268c9@mail.gmail.com>
Message-ID: <AA28F077645B324881335614E4F7C428034CC4@win-ex01.bench.com>

Congratulations!  It will be great to have MMC v4.x support in U-Boot.

The following segment of code from
linux-2.6.25-rc9/drivers/mmc/host/at91_mci.c is confusing:

if (host->board->wire4) {
        if (cpu_is_at91sam9260() || cpu_is_at91sam9263())
                mmc->caps |= MMC_CAP_4_BIT_DATA;
        else
                dev_warn(&pdev->dev, "4 wire bus mode not supported"
                        " - using 1 wire\n");
}

This code seems to imply that MMC 4 bits works on the AT91SAM9260 and
AT91SAM9263, but not any of the others in this processor family,
possibly due to a hardware bug.  Any comments on why the Linux AT91 MCI
driver doesn't support an 4 bit MMC bus for all AT91SAM9 processors?

I mention this because it may impact the AT91 MCI U-Boot device driver.

Sincerely,

Ken Fuchs

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Andy Fleming
> Sent: Tuesday, April 15, 2008 14:25
> To: Pierre Savary
> Cc: u-boot-users at lists.sourceforge.net; drzeus-mmc at drzeus.cx
> Subject: Re: [U-Boot-Users] drivers MMCplus for at91sam9x
> 
> 
> On Tue, Apr 15, 2008 at 5:18 AM, Pierre Savary 
> <pierre.savary at kerlink.fr> wrote:
> > Then my MMC 4GB works with my Linux kernel but if I can't 
> load my kernel
> >  (located on the first part of this MMC) ... it's not 
> really interesting :(
> >
> >  So, somebody does already use MMC v4 with U-boot???
> 
> I've got one that works.  However, I don't have a 4GB MMC card with
> v4.  I thought I did, but it turned out the card just takes advantage
> of the fact that older versions can address 4GB, even though the spec
> says 2GB is the max.
> 
> However, I'm fairly confident in the code (it's been tested in
> simulated environments, and reflects what the Linux code does).  I'm
> currently working on bringing it forward to the top of tree (I started
> it before drivers/ got rearranged).  I'm actually hoping to generalize
> it some so we can share it between all MMC/SD users.
> 
> Andy
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to 
> save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
.sun.com/javaone
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users



From pmeloy at shaw.ca  Thu Apr 17 03:58:10 2008
From: pmeloy at shaw.ca (pat)
Date: Wed, 16 Apr 2008 18:58:10 -0700
Subject: [U-Boot-Users] Help making jffs2 image
Message-ID: <1208397490.10202.12.camel@rhodan.shaw.ca>

I can't seem to make a jffs2 image that u-Boot or the kernel can read. I
know the nand read/write works because I've written kernels and ramdisks
to nand (at many different locations) and they always read back and boot
flawlessly. The JFFS2 image, on the other hand, makes u-boot take about
12 minutes to perform an "ls" on the jffs2 partition with hardware ecc
disabled and fails completely with a bazillion ecc errors when hardware
ecc is on.

I had a brainstorm earlier today and thought perhaps the compression
type used by mkfs.jffs2 (1.5 and 1.6) wasn't enabled in the kernel so I
went back and built a new kernel with every compression type built into
the kernel that appears under the advanced compression heading. No
change, same problems.

What I've used to create the jffs2 is an emdebian crossd build put into
a directory (using sudo to get the device files etc) then the command
line is

sudo mkfs.jffs2 -l -n -s 527 -e 0x4000 --pad=0x200000 -d myroot -o
myroot.jffs2

I then copy that to my tftp directory, tftp to the s3c2410 device at
0x30800000 (ram is 0x30000000 to 0x40000000) and use:

nand write.jffs2 0x30800000 jffs2 0x2000000

I've also tried not specifying a page size (527 sounds odd) and using
nand write instead of write.jffs2.

This is on a s3c2410 board and the nand routines came from the qt2410
patches at openmoko (like I sand, the nand write works perfectly with
uImage and uRamdisk writes/reads).

Any idea where I'm going wrong?





From plagnioj at jcrosoft.com  Thu Apr 17 05:49:24 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 17 Apr 2008 05:49:24 +0200
Subject: [U-Boot-Users] Again on PCMCIA/IDE and PXA270
In-Reply-To: <20080416164606.GE9860@enneenne.com>
References: <20080416164606.GE9860@enneenne.com>
Message-ID: <20080417034924.GA3353@game.jcrosoft.org>

On 18:46 Wed 16 Apr     , Rodolfo Giometti wrote:
> Hello,
> 
> Using a 1GB CF on my system I get:
> 
>    equantum> pinit on
>    KINGSTON CF CARD 1GB
>                Fixed Disk Card
>                IDE interface 
>                [silicon] [unique] [single] [sleep] [standby] [idle] [low power]
>    equantum> ide reset
> 
 Could you gice more information about your environment : u-boot
 version, hard init, etc...

 And also could specify the Voltage of the Flash that you use 3.3V, 5V,
 3.3/5V.

Best Regards,
J.



From h.mohamedthalib at gdatech.co.in  Thu Apr 17 05:58:40 2008
From: h.mohamedthalib at gdatech.co.in (Mohamed Thalib .H)
Date: Thu, 17 Apr 2008 09:28:40 +0530
Subject: [U-Boot-Users] File system
In-Reply-To: <bcd5c5130804152135p21d2c9b6v2987e911437a4d53@mail.gmail.com>
References: <bcd5c5130804152135p21d2c9b6v2987e911437a4d53@mail.gmail.com>
Message-ID: <4806CAF0.5020405@gdatech.co.in>

Hi Gautham

Please send the log.. it will be hard to guess what exactly happens...

Gautham K wrote:
> Hi ,
>
> I am Gautham here, my kernel is up and running and atlast it gives :- 
> "Kernel panic unable to mount file system"
>
> can anybody tell what may be the problem??
>
> Thanx in advance,
>
> Reagards,
> -- 
> Gautham
>
> Neural Systems
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ------------------------------------------------------------------------
>
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>   


-------------------

We recently installed the spam filter from Abaca. It's over 99% accurate.
Check it out - http://www.abaca.com/success/story.cgi?domain=gdatech.co.in

-------------------




From giometti at enneenne.com  Thu Apr 17 10:23:43 2008
From: giometti at enneenne.com (Rodolfo Giometti)
Date: Thu, 17 Apr 2008 10:23:43 +0200
Subject: [U-Boot-Users] Again on PCMCIA/IDE and PXA270
In-Reply-To: <20080417034924.GA3353@game.jcrosoft.org>
References: <20080416164606.GE9860@enneenne.com>
	<20080417034924.GA3353@game.jcrosoft.org>
Message-ID: <20080417082343.GA12487@enneenne.com>

On Thu, Apr 17, 2008 at 05:49:24AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:46 Wed 16 Apr     , Rodolfo Giometti wrote:
> > Hello,
> > 
> > Using a 1GB CF on my system I get:
> > 
> >    equantum> pinit on
> >    KINGSTON CF CARD 1GB
> >                Fixed Disk Card
> >                IDE interface 
> >                [silicon] [unique] [single] [sleep] [standby] [idle] [low power]
> >    equantum> ide reset
> > 
>  Could you gice more information about your environment : u-boot
>  version, hard init, etc...

Yes, sorry. u-boot version 1.2.0 running on PXA270 based board.

What do you mean by "hard init"? The GPIOs settings or so?

>  And also could specify the Voltage of the Flash that you use 3.3V, 5V,
>  3.3/5V.

The voltage is 3.3.

Thanks for your help,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at linux.it
Embedded Systems                     phone:	+39 349 2432127
UNIX programming                     skype:     rodolfo.giometti



From casainho at gmail.com  Thu Apr 17 11:32:19 2008
From: casainho at gmail.com (Casainho)
Date: Thu, 17 Apr 2008 10:32:19 +0100
Subject: [U-Boot-Users] The -Ttext value for ARM9?,
	AT91SAM9260 in a stand alone application
Message-ID: <7e415a090804170232w71ce1a77sc11e2550b970ffea@mail.gmail.com>

Hello :-)

I would like to know what is the value of -Ttext in an ARM9, in
AT91SAM9260, for a stand alone application.

I am compiling using: "arm-elf-ld -Bstatic -Ttext 0x00001000
flash_led.o -o flash_led.elf", looking at the example gived by Mr.
Leon.Z, however that example is for PPC MCU.

I am a newbie in 32 bits and U-boot. Can someone point me to the
U-boot documentation where I can read and understand what should be
the value? - I already read the manual and doc files in the source
code, however I couldn?t figure what should be that value. Thank you.

My original message with title: "questions about stand alone
application - flash a LED"
http://sourceforge.net/mailarchive/forum.php?thread_name=200804142118.18422.casainho%40gmail.com&forum_name=u-boot-users



From plagnioj at jcrosoft.com  Thu Apr 17 11:45:50 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 17 Apr 2008 11:45:50 +0200
Subject: [U-Boot-Users] Again on PCMCIA/IDE and PXA270
In-Reply-To: <20080417082343.GA12487@enneenne.com>
References: <20080416164606.GE9860@enneenne.com>
	<20080417034924.GA3353@game.jcrosoft.org>
	<20080417082343.GA12487@enneenne.com>
Message-ID: <20080417094550.GA17606@game.jcrosoft.org>

On 10:23 Thu 17 Apr     , Rodolfo Giometti wrote:
> On Thu, Apr 17, 2008 at 05:49:24AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 18:46 Wed 16 Apr     , Rodolfo Giometti wrote:
> > > Hello,
> > > 
> > > Using a 1GB CF on my system I get:
> > > 
> > >    equantum> pinit on
> > >    KINGSTON CF CARD 1GB
> > >                Fixed Disk Card
> > >                IDE interface 
> > >                [silicon] [unique] [single] [sleep] [standby] [idle] [low power]
> > >    equantum> ide reset
> > > 
> >  Could you gice more information about your environment : u-boot
> >  version, hard init, etc...
> 
> Yes, sorry. u-boot version 1.2.0 running on PXA270 based board.
Please update to the current version

and take a look on this patch
Date: Fri, 04 Apr 2008 15:17:18 +0200
From: Martin Krause <martin.krause at tqs.de>
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] [PATCH v2] IDE: fix bug in reset sequence

> 
> What do you mean by "hard init"? The GPIOs settings or so?
Yes and other configuration

Best Regards,
J.



From giometti at enneenne.com  Thu Apr 17 14:51:02 2008
From: giometti at enneenne.com (Rodolfo Giometti)
Date: Thu, 17 Apr 2008 14:51:02 +0200
Subject: [U-Boot-Users] Again on PCMCIA/IDE and PXA270
In-Reply-To: <20080417094550.GA17606@game.jcrosoft.org>
References: <20080416164606.GE9860@enneenne.com>
	<20080417034924.GA3353@game.jcrosoft.org>
	<20080417082343.GA12487@enneenne.com>
	<20080417094550.GA17606@game.jcrosoft.org>
Message-ID: <20080417125102.GE13263@enneenne.com>

On Thu, Apr 17, 2008 at 11:45:50AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Please update to the current version

Yes, I'll do it, but I'm still working on this version since another
board PXA255 based, with the same code version, works perfectly!

> and take a look on this patch
> Date: Fri, 04 Apr 2008 15:17:18 +0200
> From: Martin Krause <martin.krause at tqs.de>
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] [PATCH v2] IDE: fix bug in reset sequence

I saw it but it changes nothing...

> > 
> > What do you mean by "hard init"? The GPIOs settings or so?
> Yes and other configuration

Memory controller registers:

48000000: 08000bc9 021ba018 7ff87ff8 7ff87ff9    ................
48000010: 7ffc123c 00000002 00000000 00000000    <...............
48000020: 00000000 00000000 00050a3e 00000000    ........>.......
48000030: 00050a3e 00000000 0002c5a2 00000000    >...............
48000040: 00320032 00000009 02000234 55555588    2.2.....4....UUU
48000050: 55555555 00000005 00000000 55555555    UUUU........UUUU
48000060: 55555555 00000100 80000fff 00000000    UUUU............

GPIO settings:

40e00000: 001ff3fd 01ffffd6 732de3a4 c8e98008    ..........-s....
40e00010: fccfab83 063bffff 00000000 00000000    ......;.........
40e00020: 00000000 00000000 00000000 00000000    ................
40e00030: 00000000 00000000 00000000 00000000    ................
40e00040: 00000000 00000000 00000000 00000000    ................
40e00050: 00000000 80000000 a5254010 699a955a    .........@%.Z..i
40e00060: aaa5a0aa 6aaaaaaa 01000556 45554020    .......jV... @UE
40e00070: 00000146 00000000 00000000 00000000    F...............
40e00080: 00000000 00000000 00000000 00000000    ................
40e00090: 00000000 00000000 00000000 00000000    ................
40e000a0: 00000000 00000000 00000000 00000000    ................
40e000b0: 00000000 00000000 00000000 00000000    ................
40e000c0: 00000000 00000000 00000000 00000000    ................
40e000d0: 00000000 00000000 00000000 00000000    ................
40e000e0: 00000000 00000000 00000000 00000000    ................
40e000f0: 00000000 00000000 00000000 00000000    ................
40e00100: 01d1ffef 00000000 00000000 002a4010    .............@*.
40e00110: 00000000 00000000 00000000 00000000    ................
40e00120: 00000000 00000000 00000000 00000000    ................
40e00130: 00000000 00000000 00000000 00000000    ................
40e00140: 00000000 00000000 00000000 00000000    ................
40e00150: 00000000 00000000 00000000 00000000    ................

Thanks,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at linux.it
Embedded Systems                     phone:	+39 349 2432127
UNIX programming                     skype:     rodolfo.giometti



From dirk.behme at googlemail.com  Thu Apr 17 16:22:06 2008
From: dirk.behme at googlemail.com (Dirk Behme)
Date: Thu, 17 Apr 2008 16:22:06 +0200
Subject: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
In-Reply-To: <000901c89bd8$1b35a1c0$3a4d010a@Emea.Arm.com>
References: <000901c89bd8$1b35a1c0$3a4d010a@Emea.Arm.com>
Message-ID: <48075D0E.8050501@googlemail.com>

Peter Pearse wrote:
>>-----Original Message-----
>>From: wd at denx.de [mailto:wd at denx.de] 
>>Sent: 11 April 2008 14:18
>>To: Peter Pearse
>>Cc: 'Guennadi Liakhovetski'; u-boot-users at lists.sourceforge.net
>>Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
>>
>>In message <000301c89bd0$21749350$3a4d010a at Emea.Arm.com> you wrote:
>>
>>> 
>>>
>>>>Actually, I think, even Peter should not reset his tree, 
>>
>>but revert 
>>
>>>>just as well as you are going to do it: his tree is publically 
>>>>accessible too, and if he resets his tree, it will become 
>>
>>unclear, 
>>
>>>>where respective commits from the central tree come from.
>>>
>>>Agreed.
>>>
>>>I shall revert u-boot-arm commits in the order listed.
>>
>>OK, I reverted the commits in the master branch now.
> 
> 
> And I've reverted u-boot-arm

What's the status of re-applying the reverted patches?

I really like to see

[PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and cleanup

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38505

in mainline.

Sorry if I missed anything,

Dirk



From peter.pearse at arm.com  Thu Apr 17 16:32:35 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Thu, 17 Apr 2008 15:32:35 +0100
Subject: [U-Boot-Users] FW:  [GIT PULL] Please pull u-boot-arm
Message-ID: <000101c8a097$e0f8d990$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: Peter Pearse [mailto:peter.pearse at arm.com] 
> Sent: 17 April 2008 15:25
> To: 'Dirk Behme'
> Subject: RE: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> 
>  
> 
> > -----Original Message-----
> > From: Dirk Behme [mailto:dirk.behme at googlemail.com]
> > Sent: 17 April 2008 15:22
> > To: Peter Pearse
> > Cc: wd at denx.de; u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> > 
> > Peter Pearse wrote:
> > >>-----Original Message-----
> > >>From: wd at denx.de [mailto:wd at denx.de]
> > >>Sent: 11 April 2008 14:18
> > >>To: Peter Pearse
> > >>Cc: 'Guennadi Liakhovetski'; u-boot-users at lists.sourceforge.net
> > >>Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm
> > >>
> > >>In message <000301c89bd0$21749350$3a4d010a at Emea.Arm.com> 
> you wrote:
> > >>
> > >>> 
> > >>>
> > >>>>Actually, I think, even Peter should not reset his tree,
> > >>
> > >>but revert
> > >>
> > >>>>just as well as you are going to do it: his tree is publically 
> > >>>>accessible too, and if he resets his tree, it will become
> > >>
> > >>unclear,
> > >>
> > >>>>where respective commits from the central tree come from.
> > >>>
> > >>>Agreed.
> > >>>
> > >>>I shall revert u-boot-arm commits in the order listed.
> > >>
> > >>OK, I reverted the commits in the master branch now.
> > > 
> > > 
> > > And I've reverted u-boot-arm
> > 
> > What's the status of re-applying the reverted patches?
> > 
> > I really like to see
> > 
> > [PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and 
> > cleanup
> > 
> > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38505
> > 
> > in mainline.
> > 
> > Sorry if I missed anything,
> 
> Dirk
> 	Sorry, I'm still sorting my mail system.
> 
> 	Perhaps another ARM guardian could pick it up.
> Regards
> 
> Peter
> 
> 
> > 
> > Dirk
> > 





From skuribay at ruby.dti.ne.jp  Thu Apr 17 16:35:13 2008
From: skuribay at ruby.dti.ne.jp (Shinya Kuribayashi)
Date: Thu, 17 Apr 2008 23:35:13 +0900
Subject: [U-Boot-Users] [PATCH][MIPS] Use jr as register jump instruction
Message-ID: <48076021.9090908@ruby.dti.ne.jp>

Current assembler codes are inconsistent in the way of register jump
instruction usage; some use jr, some use j. Of course GNU as allows both
usages, but as can be expected from `Jump Register' the mnemonic `jr' is
more intuitive than `j'. For example, Linux doesn't have `j <reg>' usage
at all.

Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
---

 board/dbau1x00/lowlevel_init.S  |    2 +-
 board/gth2/lowlevel_init.S      |    2 +-
 board/incaip/lowlevel_init.S    |    8 ++++----
 board/pb1x00/lowlevel_init.S    |    2 +-
 board/purple/lowlevel_init.S    |    2 +-
 board/qemu-mips/lowlevel_init.S |    2 +-
 cpu/mips/cache.S                |    4 ++--
 cpu/mips/incaip_wdt.S           |    2 +-
 cpu/mips/start.S                |    6 +++---
 9 files changed, 15 insertions(+), 15 deletions(-)


diff --git a/board/dbau1x00/lowlevel_init.S b/board/dbau1x00/lowlevel_init.S
index 14a7846..27b51f7 100644
--- a/board/dbau1x00/lowlevel_init.S
+++ b/board/dbau1x00/lowlevel_init.S
@@ -586,5 +586,5 @@ noCacheJump:
 	sw	t1, 0(t0)
 	sync
 
-	j	ra
+	jr	ra
 	nop
diff --git a/board/gth2/lowlevel_init.S b/board/gth2/lowlevel_init.S
index eea378a..bf615c1 100644
--- a/board/gth2/lowlevel_init.S
+++ b/board/gth2/lowlevel_init.S
@@ -450,7 +450,7 @@ mtc:	sw	zero, 0(t0)
 	nop
 	nop
 memtestend:
-	j	ra
+	jr	ra
 	nop
 
 memhang:
diff --git a/board/incaip/lowlevel_init.S b/board/incaip/lowlevel_init.S
index b39f93d..08f7f21 100644
--- a/board/incaip/lowlevel_init.S
+++ b/board/incaip/lowlevel_init.S
@@ -105,7 +105,7 @@ __ebu_init:
 	li	t2, 0x684143FD
 	sw	t2, EBU_BUSCON1(t1)
 3:
-	j	ra
+	jr	ra
 	nop
 
 	.end	ebu_init
@@ -170,7 +170,7 @@ __cgu_init:
 	li	t2, 0x80000001
 	sw	t2, CGU_MUXCR(t1)
 5:
-	j	ra
+	jr	ra
 	nop
 
 	.end	cgu_init
@@ -266,7 +266,7 @@ __sdram_init:
 	li	t2, 0x00000001
 	sw	t2, MC_CTRLENA(t1)
 
-	j	ra
+	jr	ra
 	nop
 
 	.end	sdram_init
@@ -298,7 +298,7 @@ lowlevel_init:
 	nop
 	move	ra, t0
 
-	j	ra
+	jr	ra
 	nop
 
 	.end	lowlevel_init
diff --git a/board/pb1x00/lowlevel_init.S b/board/pb1x00/lowlevel_init.S
index e851e2f..98bb394 100644
--- a/board/pb1x00/lowlevel_init.S
+++ b/board/pb1x00/lowlevel_init.S
@@ -388,5 +388,5 @@ skip_memsetup:
 	*/
 	sync
 
-	j	ra
+	jr	ra
 	nop
diff --git a/board/purple/lowlevel_init.S b/board/purple/lowlevel_init.S
index 668124a..b9d03fc 100644
--- a/board/purple/lowlevel_init.S
+++ b/board/purple/lowlevel_init.S
@@ -33,5 +33,5 @@ lowlevel_init:
 	li	t0, MC_IOGP
 	li	t1, 0xf24
 	sw	t1, 0(t0)
-	j	ra
+	jr	ra
 	nop
diff --git a/board/qemu-mips/lowlevel_init.S b/board/qemu-mips/lowlevel_init.S
index 28166bc..836e027 100644
--- a/board/qemu-mips/lowlevel_init.S
+++ b/board/qemu-mips/lowlevel_init.S
@@ -37,5 +37,5 @@ lowlevel_init:
 	mtc0	zero, CP0_WIRED
 	nop
 
-	j	ra
+	jr	ra
 	nop
diff --git a/cpu/mips/cache.S b/cpu/mips/cache.S
index 89ada71..f593968 100644
--- a/cpu/mips/cache.S
+++ b/cpu/mips/cache.S
@@ -282,7 +282,7 @@ LEAF(dcache_disable)
 	and	t0, t0, t1
 	ori	t0, t0, CONF_CM_UNCACHED
 	mtc0	t0, CP0_CONFIG
-	j	ra
+	jr	ra
 	END(dcache_disable)
 
 #ifdef CFG_INIT_RAM_LOCK_MIPS
@@ -308,7 +308,7 @@ mips_cache_lock:
 	move	a1, a2
 	icacheop(a0,a1,a2,a3,0x1d)
 
-	j	ra
+	jr	ra
 
 	.end	mips_cache_lock
 #endif /* CFG_INIT_RAM_LOCK_MIPS */
diff --git a/cpu/mips/incaip_wdt.S b/cpu/mips/incaip_wdt.S
index 71adaa1..2ebcc91 100644
--- a/cpu/mips/incaip_wdt.S
+++ b/cpu/mips/incaip_wdt.S
@@ -68,5 +68,5 @@ disable_incaip_wdt:
 	li	t1, WD_WRITE_ENDINIT
 	sw	t1, WD_CON0(t0)		/* end command */
 
-	j	ra
+	jr	ra
 	nop
diff --git a/cpu/mips/start.S b/cpu/mips/start.S
index baac2ce..6e1a78c 100644
--- a/cpu/mips/start.S
+++ b/cpu/mips/start.S
@@ -286,7 +286,7 @@ reset:
 	la	sp, 0(t0)
 
 	la	t9, board_init_f
-	j	t9
+	jr	t9
 	nop
 
 /*
@@ -342,7 +342,7 @@ relocate_code:
 	/* Jump to where we've relocated ourselves.
 	 */
 	addi	t0, a2, in_ram - _start
-	j	t0
+	jr	t0
 	nop
 
 	.gpword	_GLOBAL_OFFSET_TABLE_	/* _GLOBAL_OFFSET_TABLE_ - _gp	*/
@@ -387,7 +387,7 @@ in_ram:
 
 	move	a0, a1
 	la	t9, board_init_r
-	j	t9
+	jr	t9
 	move	a1, a2		/* delay slot			*/
 
 	.end	relocate_code



From dzu at denx.de  Thu Apr 17 16:50:01 2008
From: dzu at denx.de (Detlev Zundel)
Date: Thu, 17 Apr 2008 16:50:01 +0200
Subject: [U-Boot-Users] u-boot wiki and arch-specific details
In-Reply-To: <200804141334.57715.vapier@gentoo.org> (Mike Frysinger's message
	of "Mon, 14 Apr 2008 13:34:57 -0400")
References: <200804131926.41049.vapier@gentoo.org>
	<m2zlrwpol6.fsf@ohwell.denx.de> <200804141334.57715.vapier@gentoo.org>
Message-ID: <m2tzi0cz8m.fsf@ohwell.denx.de>

Hi Mike,

> On Monday 14 April 2008, Detlev Zundel wrote:
>> > we maintain a Blackfin-specific u-boot wiki that goes into quite a bit of
>> > detail, some of which is duplicated with the main u-boot wiki.  how do
>> > people feel about extending the u-boot wiki to allow for arch-specific
>> > details ?
>>
>> What exactly do you have in mind?  I surely don't see any principal
>> problem here.
>>
>> It would certainly be valuable to get all U-Boot related info collected
>> in a central place and have pointers wherever that make sense...
>
> from my reading of the wiki, it's more of a technical/command reference than a 
> guide.  the wiki we maintain is geared to be more of a guide.  i think the 
> two can be merged, i just dont want to convert things only to find out people 
> dont want to take it that direction.

Just to be clear, we are discussing the DULG wiki, right?  

I agree that in the current state the documentation is more a reference
but IIRC that wasn't really a conscious design decision.  It simply
turned out this way in the end.

So I do not see any general problem in adding "guide style" sections in
there.  Maybe then most of the current documentation can then be shifted
to a "commands reference" section.

One problem I see though is how to correctly adapt such sections to the
board specific nature of the DULG.  Hopefully we can get away with
mostly generic text passages and only a few ifdefs.  It would be very
helpful to know more concrete plans (outline!) to think further about
these implications.

Cheers
  Detlev

-- 
Applied mathematicians do it by computer simulation.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From dzu at denx.de  Thu Apr 17 17:03:59 2008
From: dzu at denx.de (Detlev Zundel)
Date: Thu, 17 Apr 2008 17:03:59 +0200
Subject: [U-Boot-Users] questions about stand alone application - flash
	a LED
In-Reply-To: <200804142118.18422.casainho@gmail.com> (J. P. Casainho's message
	of "Mon, 14 Apr 2008 21:18:18 +0100")
References: <48032361.25bb720a.38ba.1253@mx.google.com>
	<200804142118.18422.casainho@gmail.com>
Message-ID: <m2prsocylc.fsf@ohwell.denx.de>

Hi,

>> You can use the go CMD to test your app.
>> Here post my used step.
>>
>> Write a simple code.It's just include a function definition
>> 	void _start()
>>     {
>>     }
>> Then compile it.After do that use following step:
>> ppc_82xx-ld -Bstatic -Ttext 0x00001000 board/bname/ttt.o -o ttt.elf

It just occured to me that you are overwriting the InstructionTLBMiss
exception vector here.  Are you sure you want to do this?

This is one of the reasons why in examples/Makefile always 0x40000 is
chosen for the standalone apps:

ifeq ($(ARCH),ppc)
LOAD_ADDR = 0x40000
endif

Cheers
  Detlev

-- 
A stated design goal of Motif was to give the X Window System the
window management capabilities of HP's circa-1988 window manager and
the visual elegance of Microsoft Windows. We kid you not.
                                          -- The UNIX Haters Handbook
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From lancee.ware at gmail.com  Thu Apr 17 17:27:11 2008
From: lancee.ware at gmail.com (Lance Ware)
Date: Thu, 17 Apr 2008 11:27:11 -0400
Subject: [U-Boot-Users] EHCI USB 2.0 Patch
Message-ID: <48076C4F.7090206@gmail.com>

Hello,

I wanted to know how could I get a hold of the USB 2.0 patch for 
u-boot.  I am currently testing a OHCI/EHCI compliant pci usb device. I 
have the OHCI part working but would like to have use of the EHCI part 
of the device from the usb device.

Thanks,
Lance



From agust at denx.de  Thu Apr 17 18:15:27 2008
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 17 Apr 2008 18:15:27 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix crash on sequoia with cache
	enabled
Message-ID: <1208448927-4803-1-git-send-email-agust@denx.de>

Currently U-Boot crashes on sequoia board in CPU POST if
cache is enabled (CONFIG_4xx_DCACHE defined). The cache
won't be disabled by change_tlb before CPU POST because
there is an insufficient adress range check since
CFG_MEM_TOP_HIDE was introduced. This patch tries to fix
this problem.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 cpu/ppc4xx/tlb.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/cpu/ppc4xx/tlb.c b/cpu/ppc4xx/tlb.c
index 2bfcba1..f44822d 100644
--- a/cpu/ppc4xx/tlb.c
+++ b/cpu/ppc4xx/tlb.c
@@ -149,7 +149,9 @@ void change_tlb(u32 vaddr, u32 size, u32 tlb_word2_i_value)
 			/*
 			 * Now check the end-address if it's in the range
 			 */
-			if ((tlb_vaddr + tlb_size - 1) <= (vaddr + size - 1)) {
+			if (((tlb_vaddr + tlb_size - 1) <= (vaddr + size - 1)) ||
+			    ((tlb_vaddr < (vaddr + size - 1)) &&
+			     ((tlb_vaddr + tlb_size - 1) > (vaddr + size - 1)))) {
 				/*
 				 * Found a TLB in the range.
 				 * Change cache attribute in tlb2 word.
-- 
1.5.3.3




From Plamen.Panteleev at mps.bg  Thu Apr 17 18:18:01 2008
From: Plamen.Panteleev at mps.bg (Plamen Panteleev)
Date: Thu, 17 Apr 2008 19:18:01 +0300
Subject: [U-Boot-Users] winCE
Message-ID: <48077839.4020108@mps.bg>

Hi,

Can I install U-Boot over redboot for booting Windows CE


Plamen Panteleev,
MPS,Ltd




From agust at denx.de  Thu Apr 17 18:18:00 2008
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 17 Apr 2008 18:18:00 +0200
Subject: [U-Boot-Users] [PATCH] Fix crash on sequoia in ppc_4xx_eth_init
Message-ID: <1208449080-4825-1-git-send-email-agust@denx.de>

Currently U-Boot crashes in ppc_4xx_eth_init on sequoia
with cache enabled (TLB Parity exeption). This patch
fixes the problem.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 cpu/ppc4xx/4xx_enet.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/cpu/ppc4xx/4xx_enet.c b/cpu/ppc4xx/4xx_enet.c
index 007cb4f..c40e0ca 100644
--- a/cpu/ppc4xx/4xx_enet.c
+++ b/cpu/ppc4xx/4xx_enet.c
@@ -1083,7 +1083,11 @@ static int ppc_4xx_eth_init (struct eth_device *dev, bd_t * bis)
 #ifdef CONFIG_4xx_DCACHE
 		flush_dcache_range(bd_cached, bd_cached + MAL_ALLOC_SIZE);
 		if (!last_used_ea)
+#if defined(CFG_MEM_TOP_HIDE)
+			bd_uncached = bis->bi_memsize + CFG_MEM_TOP_HIDE;
+#else
 			bd_uncached = bis->bi_memsize;
+#endif
 		else
 			bd_uncached = last_used_ea + MAL_ALLOC_SIZE;
 
-- 
1.5.3.3




From njayaswal at tataelxsi.co.in  Thu Apr 17 19:13:47 2008
From: njayaswal at tataelxsi.co.in (Neeraj Jayaswal)
Date: Thu, 17 Apr 2008 22:43:47 +0530
Subject: [U-Boot-Users] U-Boot : USB Slave Mode ?
Message-ID: <000201c8a0ae$6693e020$42053c0a@telxsi.com>

Hi All,
I am new to U-Boot, hence apologies if the question sounds a bit basic. I
have a ARM926EJS board, and I want to configure it in USB Slave mode.
Please suggest if U-Boot supports this mode ? If yes then what changes are
required ?

Thanks,
Neeraj


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.




From andre.schwarz at matrix-vision.de  Thu Apr 17 19:28:17 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 17 Apr 2008 19:28:17 +0200
Subject: [U-Boot-Users] [PATCH] fix system config overwrite @ MPC834x
Message-ID: <480788B1.9090208@matrix-vision.de>

Kim,

during 83xx setup the "System I/O configuration register high" gets 
overwritten
with user defined value if CFG_SICRH is defined.

Regarding to the MPC834x manual (Table 5-28 reve.1) bits 28+29 of SICRH 
must keep
their reset value regardless of configuration.

On my board (using RGMII) those bits are set after reset - yet it's 
unclear where they come from.

The patch keeps both bits on MPC834x.


Cheers,
Andre

Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
--

 cpu/mpc83xx/cpu_init.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/cpu/mpc83xx/cpu_init.c b/cpu/mpc83xx/cpu_init.c
index fba5b02..66cc1c2 100644
--- a/cpu/mpc83xx/cpu_init.c
+++ b/cpu/mpc83xx/cpu_init.c
@@ -59,6 +59,8 @@ static void config_qe_ioports(void)
  */
 void cpu_init_f (volatile immap_t * im)
 {
+    u32 tmp_sicrh = 0;
+
     /* Pointer is writable since we allocated a register for it */
     gd = (gd_t *) (CFG_INIT_RAM_ADDR + CFG_GBL_DATA_OFFSET);
 
@@ -181,7 +183,11 @@ void cpu_init_f (volatile immap_t * im)
 
     /* System General Purpose Register */
 #ifdef CFG_SICRH
-    im->sysconf.sicrh = CFG_SICRH;
+#ifdef CONFIG_MPC834X
+    /* regarding to MPC34x manual rev.1 bits 28..29 must be preserved */
+    tmp_sicrh = im->sysconf.sicrh & 0x0000000C;
+#endif
+    im->sysconf.sicrh = CFG_SICRH | tmp_sicrh;
 #endif
 #ifdef CFG_SICRL
     im->sysconf.sicrl = CFG_SICRL;


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From ceqcharz at yahoo.com  Thu Apr 17 19:32:48 2008
From: ceqcharz at yahoo.com (Dave)
Date: Thu, 17 Apr 2008 10:32:48 -0700 (PDT)
Subject: [U-Boot-Users] TLB parity errors on 440EP/Yosemite board
Message-ID: <457423.79169.qm@web45102.mail.sp1.yahoo.com>

Hi,
I am adding a TLB entry to the table of TLB entries in
the init.S for the Yosemite board.   Whenever u-boot
accesses this memory space I get the following error.

Machine Check Exception.
Caused by (from msr): regs 07f2adb0 TLB Parity Error

Any ideas what I could be doing wrong to cause this?

Thanks,
Dave




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ




From vapier at gentoo.org  Thu Apr 17 20:01:48 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Thu, 17 Apr 2008 14:01:48 -0400
Subject: [U-Boot-Users] u-boot wiki and arch-specific details
In-Reply-To: <m2tzi0cz8m.fsf@ohwell.denx.de>
References: <200804131926.41049.vapier@gentoo.org>
	<200804141334.57715.vapier@gentoo.org>
	<m2tzi0cz8m.fsf@ohwell.denx.de>
Message-ID: <200804171401.58162.vapier@gentoo.org>

On Thursday 17 April 2008, Detlev Zundel wrote:
> Hi Mike,
>
> > On Monday 14 April 2008, Detlev Zundel wrote:
> >> > we maintain a Blackfin-specific u-boot wiki that goes into quite a bit
> >> > of detail, some of which is duplicated with the main u-boot wiki.  how
> >> > do people feel about extending the u-boot wiki to allow for
> >> > arch-specific details ?
> >>
> >> What exactly do you have in mind?  I surely don't see any principal
> >> problem here.
> >>
> >> It would certainly be valuable to get all U-Boot related info collected
> >> in a central place and have pointers wherever that make sense...
> >
> > from my reading of the wiki, it's more of a technical/command reference
> > than a guide.  the wiki we maintain is geared to be more of a guide.  i
> > think the two can be merged, i just dont want to convert things only to
> > find out people dont want to take it that direction.
>
> Just to be clear, we are discussing the DULG wiki, right?

is there any other worth talking about :)

> I agree that in the current state the documentation is more a reference
> but IIRC that wasn't really a conscious design decision.  It simply
> turned out this way in the end.
>
> So I do not see any general problem in adding "guide style" sections in
> there.  Maybe then most of the current documentation can then be shifted
> to a "commands reference" section.

OK

> One problem I see though is how to correctly adapt such sections to the
> board specific nature of the DULG.  Hopefully we can get away with
> mostly generic text passages and only a few ifdefs.  It would be very
> helpful to know more concrete plans (outline!) to think further about
> these implications.

so talking to some people on our side and i realized i forgot about a lame 
(but important) aspect.  we need to retain full copyright over our docs.  we 
license it all under a non commercial creative commons license, but sometimes 
we get customer requests to include portions of our docs into their work but 
under their own rules.  if i were to merge the our wiki with the DULG one, we 
couldnt in good faith continue that practice.  so the wiki's will have to 
remain sep, but i can push content into the public one to improve it, just 
not vice versa.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080417/e86a8447/attachment.pgp 

From andre.schwarz at matrix-vision.de  Thu Apr 17 20:32:27 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 17 Apr 2008 20:32:27 +0200
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <20080331131830.bdd5c146.kim.phillips@freescale.com>
References: <1206714585-13569-1-git-send-email-tor@excito.com>	<47F0EEBE.2010905@gmail.com>
	<20080331131830.bdd5c146.kim.phillips@freescale.com>
Message-ID: <480797BB.8090507@matrix-vision.de>

Tor,

after all my VSC8601 is up and running on MPC8343  :-)

I'm sorry to say that I don't find this patch ok after going through the 
manuals :

Register 0x17 is a very coarse setting. If the capabilities of the PHY 
should be taken into account and be configurable we should use the skew 
control in extended register 0x1c. This should be definable - 
CFG_VSC8601_SKEWFIX simply applies maximum skew ...

After all changing the bits in register 0x17 _require_ a soft reset by 
asserting bit 15 in register 0 before they are going to work.

Obviously this patch has no effect at all.
Do you reset the PHY manually after this configuration ?

This PHY definitely needs a proper setup function since there are quite 
interesting registers which need read-modify-write.


What do you think ?


regards,
Andre

Kim Phillips schrieb:
> On Mon, 31 Mar 2008 10:01:34 -0400
> Ben Warren <biggerbadderben at gmail.com> wrote:
>
>   
>> Tor Krill wrote:
>>     
>>> Add phy_info for Vitesse VSC8601.
>>> Add config option, CFG_VSC8601_SKEWFIX, to enable RGMII skew timing compensation.
>>>
>>> Signed-off-by: Tor Krill <tor at excito.com>
>>>   
>>>       
>> Acked-by: Ben Warren <biggerbadderben at gmail.com>
>>     
>
> I don't have a Vitesse 8601, so technically I can't ack it, but I can:
>
> Reviewed-by: Kim Phillips <kim.phillips at freescale.com>
>
> minor nit: it would be nice if the following:
>
>   
>>> +#ifdef CFG_VSC8601_SKEWFIX
>>> +				{MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
>>> +#endif
>>>       
>
> were made to have spaces after commas, and flow onto a separate
> line so as to not be a 96 char line..
>
> Kim
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080417/fa4537ba/attachment.htm 

From kim.phillips at freescale.com  Thu Apr 17 22:56:15 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Thu, 17 Apr 2008 15:56:15 -0500
Subject: [U-Boot-Users] [PATCH] fix system config overwrite @ MPC834x
In-Reply-To: <480788B1.9090208@matrix-vision.de>
References: <480788B1.9090208@matrix-vision.de>
Message-ID: <20080417155615.43fa3791.kim.phillips@freescale.com>

On Thu, 17 Apr 2008 19:28:17 +0200
Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:

> Kim,
> 
Hello Andre,

I can't apply this:

Applying fix system config overwrite @ MPC834x
error: patch failed: cpu/mpc83xx/cpu_init.c:59
error: cpu/mpc83xx/cpu_init.c: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved".
If you would prefer to skip this patch, instead run "git-am --skip".

> during 83xx setup the "System I/O configuration register high" gets 
> overwritten
> with user defined value if CFG_SICRH is defined.
> 
> Regarding to the MPC834x manual (Table 5-28 reve.1) bits 28+29 of SICRH 
> must keep
> their reset value regardless of configuration.
> 
> On my board (using RGMII) those bits are set after reset - yet it's 
> unclear where they come from.
> 
> The patch keeps both bits on MPC834x.
> 
> 
> Cheers,
> Andre
> 
> Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
> --

fyi, commit message text you don't want applied in the tree history
(such as "Kim," and "Cheers, Andre") goes here, below the '---' line.

>      /* System General Purpose Register */
>  #ifdef CFG_SICRH
> -    im->sysconf.sicrh = CFG_SICRH;
> +#ifdef CONFIG_MPC834X
> +    /* regarding to MPC34x manual rev.1 bits 28..29 must be preserved */
> +    tmp_sicrh = im->sysconf.sicrh & 0x0000000C;
> +#endif
> +    im->sysconf.sicrh = CFG_SICRH | tmp_sicrh;
>  #endif

also, can you extend the ifdef to include CONFIG_MPC8313 in addition to
the MPC834X?  That's the only other one that could use this fix.

Thanks,

Kim



From jiehanca at yahoo.com.cn  Thu Apr 17 23:01:40 2008
From: jiehanca at yahoo.com.cn (jie han)
Date: Fri, 18 Apr 2008 05:01:40 +0800 (CST)
Subject: [U-Boot-Users] Search for mpc8641d patch
Message-ID: <261826.85908.qm@web15101.mail.cnb.yahoo.com>

Hi everyone:

Could you tell my where can I download MPC8641D ASMP support u-boot patch ?Thanks ahead,
by the way,do I need to rewrite bootm command to support two dts images load?

Sincerely,

Jie




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080418/638f47f2/attachment.htm 

From x0nishan at ti.com  Thu Apr 17 23:21:43 2008
From: x0nishan at ti.com (Menon, Nishanth)
Date: Thu, 17 Apr 2008 16:21:43 -0500
Subject: [U-Boot-Users] [RFC] recommendations for a proprietary POST testcase
Message-ID: <8E8BB316C604E94AA019A54D0A5A82A2018F6899@dlee13.ent.ti.com>

Hi,

I am looking at issues in moving from a proprietary diagnostics on a
platform we have, to a solution using U-Boot's POST infrastructure. 

I am sure many of us here have faced the condition where certain
peripherals may not become open source due to legal restrictions. In the
case of POST support, the API set is not exported for a U-Boot
standalone application to use. Writing a POST code linked within U-Boot
for a proprietary device may have implications of being completely
linked with U-Boot and subject to GPL-v2 distribution requirements.

I wonder if anyone can share their experiences to what folks have done
in such cases.

Regards,
Nishanth Menon



From Haiying.Wang at freescale.com  Thu Apr 17 23:26:54 2008
From: Haiying.Wang at freescale.com (Haiying Wang)
Date: Thu, 17 Apr 2008 17:26:54 -0400
Subject: [U-Boot-Users] Search for mpc8641d patch
In-Reply-To: <261826.85908.qm@web15101.mail.cnb.yahoo.com>
References: <261826.85908.qm@web15101.mail.cnb.yahoo.com>
Message-ID: <1208467614.2963.47.camel@r54964-12.am.freescale.net>

On Fri, 2008-04-18 at 05:01 +0800, jie han wrote:
> Hi everyone:
> 
> Could you tell my where can I download MPC8641D ASMP support u-boot
> patch ?Thanks ahead,
> by the way,do I need to rewrite bootm command to support two dts
> images load?
> 

8641D ASMP support was not submitted to opensource, you can download
MPC8641D BSP from Freescale website and find the patch in the BSP.
http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_BSP_PPC&fsrch=1

Haiying






From Ken.Fuchs at bench.com  Fri Apr 18 00:00:04 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Thu, 17 Apr 2008 17:00:04 -0500
Subject: [U-Boot-Users] winCE
In-Reply-To: <48077839.4020108@mps.bg>
Message-ID: <AA28F077645B324881335614E4F7C428034CC8@win-ex01.bench.com>

Plamen Panteleev wrote:

> Can I install U-Boot over redboot for booting Windows CE

Simply installing U-Boot over RedBoot will result
in a system that comes up with U-Boot running, but
(probably) _can't_ boot CE!

Usually MS Windows CE is booted by Eboot which is built
with the CE kernel NK.bin (a Microsoft proprietary
format) or NK.nb0 (raw binary).

Assuming RedBoot is the bootloader for your MS Windows
CE kernel, you simply need to get U-Boot to duplicate
the sequence of actions that RedBoot currently does to
boot MS Windows CE.

I would guess that your RedBoot bootloader is either
directly loading the NK.nb0 raw CE kernel image or it
is chainloading Eboot (presumably from the same boot
device as RedBoot) and Eboot loads the NK.bin CE kernel
image.  (Note that the first option is preferable, since
two bootloaders on the same system is problematic.)

You need to provide more information, like what board
are you using, what the boot devices are, and how
RedBoot is currently booting CE, etc.

Sincerely,

Ken Fuchs



From avinashs36 at yahoo.com  Fri Apr 18 00:48:06 2008
From: avinashs36 at yahoo.com (Avinash Vijayvergia)
Date: Thu, 17 Apr 2008 15:48:06 -0700 (PDT)
Subject: [U-Boot-Users] Want to add command in uboot
Message-ID: <895609.34146.qm@web39508.mail.mud.yahoo.com>

Hi

I am working on AT91SAM9260. I want to add one command "COM1 xxx" to the uboot command set. After typing this command on uboot prompt the string xxx should be transmitted out of COM1 and any reception on COM1 should be displayed on the debug terminal. Can some one suggest me how to do this?

Thanks
Avinash




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080417/8bd7e5bf/attachment.htm 

From plagnioj at jcrosoft.com  Fri Apr 18 02:17:36 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 18 Apr 2008 02:17:36 +0200
Subject: [U-Boot-Users] FW:  [GIT PULL] Please pull u-boot-arm
In-Reply-To: <000101c8a097$e0f8d990$3a4d010a@Emea.Arm.com>
References: <000101c8a097$e0f8d990$3a4d010a@Emea.Arm.com>
Message-ID: <20080418001736.GA12486@game.jcrosoft.org>

On 15:32 Thu 17 Apr     , Peter Pearse wrote:
>  
> > > 
> > > What's the status of re-applying the reverted patches?
> > > 
> > > I really like to see
> > > 
> > > [PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and 
> > > cleanup
> > > 
> > > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38505
> > > 
> > > in mainline.
> > > 
> > > Sorry if I missed anything,
> > 
> > Dirk
> > 	Sorry, I'm still sorting my mail system.
> > 
> > 	Perhaps another ARM guardian could pick it up.
> > Regards
> > 
> > Peter
> > 
I'll pick it up

Best Regards,
J.



From arasv at magtech.com.au  Fri Apr 18 03:42:23 2008
From: arasv at magtech.com.au (Aras Vaichas)
Date: Fri, 18 Apr 2008 11:42:23 +1000
Subject: [U-Boot-Users] Want to add command in uboot
In-Reply-To: <895609.34146.qm@web39508.mail.mud.yahoo.com>
References: <895609.34146.qm@web39508.mail.mud.yahoo.com>
Message-ID: <4807FC7F.50907@magtech.com.au>

Avinash Vijayvergia wrote:
> Hi
>
> I am working on AT91SAM9260. I want to add one command "COM1 xxx" to
> the uboot command set. After typing this command on uboot prompt the
> string xxx should be transmitted out of COM1 and any reception on COM1
> should be displayed on the debug terminal. Can some one suggest me how
> to do this?
>
AT91SAM9260 has no "COM1", this is a PC term.

Have you looked at the source code?

Have you read the documentation that comes with U-Boot? There is a whole
directory full of useful information in ./doc

e.g. doc/README.commands

This file tells you about how to add your command. Also look at how all
the other commands are done.

Then look in the ./common directory. There is a file called serial.c.
Maybe this file contains function calls for the serial port?

Then take a look at the ./board/... files and see how other people
send/receive data via the serial port.

Aras





______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



From wd at denx.de  Fri Apr 18 06:14:12 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:12 +0200
Subject: [U-Boot-Users] [PATCH] Change env_get_char from a global
	function ptr to a function.
In-Reply-To: Your message of "Mon, 14 Apr 2008 23:01:50 +0200."
	<1208206910.5911.20.camel@gentoo-jocke.transmode.se>
Message-ID: <20080418041412.C1A6C248BB@gemini.denx.de>

In message <1208206910.5911.20.camel at gentoo-jocke.transmode.se> you wrote:
...
> > Could you please update and resubmit? Thanks in advance.
> 
> OK, here it is.
> 
> >From 96fdcd78686c22aa6be56575c9f37d1943c91222 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
> Date: Mon, 14 Apr 2008 22:59:00 +0200
> Subject: [PATCH] Change env_get_char from a global function ptr to a function.
> 
> This avoids an early global data reference.
> ---
>  api/api.c           |    1 -
>  common/cmd_nvedit.c |    3 ---
>  common/env_common.c |   19 +++++++++++++------
>  common/env_eeprom.c |    1 -
>  common/env_nvram.c  |    1 -
>  common/ft_build.c   |    2 --
>  include/common.h    |    1 +
>  7 files changed, 14 insertions(+), 14 deletions(-)

Thanks, applied.

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: wd at denx.de
A stone was placed at a ford in a river with the inscription:
"When this stone is covered it is dangerous to ford here."



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH 1/2 v2] Additional PCI IDs for IDE and
	network controllers
In-Reply-To: Your message of "Tue, 15 Apr 2008 10:24:14 +0200."
	<Pine.LNX.4.64.0804151021100.5159@axis700.grange>
Message-ID: <20080418041413.12A4F248B9@gemini.denx.de>

In message <Pine.LNX.4.64.0804151021100.5159 at axis700.grange> you wrote:
> These PCI IDs are required by the Linkstation platforms.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>
> 
> ---
> 
> diff --git a/include/pci_ids.h b/include/pci_ids.h
> index 5481fff..61c2203 100644
> --- a/include/pci_ids.h
> +++ b/include/pci_ids.h

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The night sky over the planet Krikkit is the least interesting  sight
in the entire Universe.
                 - Douglas Adams _Life, the Universe, and Everything_



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] Move init_sequence table into code.
In-Reply-To: Your message of "Tue, 15 Apr 2008 08:40:21 +0200."
	<1208241621.5911.32.camel@gentoo-jocke.transmode.se>
Message-ID: <20080418041413.02A8F248A0@gemini.denx.de>

In message <1208241621.5911.32.camel at gentoo-jocke.transmode.se> you wrote:
> 
> It is not going to be a walk in the park :) The big remaining part
> is string literals while still in flash, not sure how to solve these
> yet.
> 
> > 
> > > > The original idea of having such a list  of  funtion  pointers  which
> > > > just  get executed one after another was to be able to wrap this into
> > > > some "#ifndef CONFIG_INIT_SEQUENCE" and use this to allow for  board-
> > > > specific init sequences by just adding a #define with the needed list
> > > > of functions to the board config files.
> > > 
> > > You can do that with weak functions too. Just make all the functions
> > > weak, then a board can overide with its own function.
> > 
> > That would not, for example, to allow to change the sequence - say
> > one board needs to initialize PCI very early, but another one very
> > late.
> 
> True, but as no one even uses this code ATM, it can't be a big deal.

OK. Well, this is not a bug fix, but a (more or less invasive) change
to basic infrastructure. I will not add this so shortly before a
release. Please rebase and resubmit when the next merge window is
open.

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: wd at denx.de
"You ain't experienced..." "Well, nor are you." "That's true. But the
point is ... the point is ... the point is we've been not experienced
for a lot longer than you. We've got  a  lot  of  experience  of  not
having any experience."           - Terry Pratchett, _Witches Abroad_



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] Add support for LZMA uncompression
	algorithm.
In-Reply-To: Your message of "Tue, 01 Apr 2008 11:18:09 +0200."
	<1207041489.12115.2.camel@localhost>
Message-ID: <20080418041413.2272E248A0@gemini.denx.de>

In message <1207041489.12115.2.camel at localhost> you wrote:
> ---
>  Makefile                   |    1 +
>  README                     |   23 ++
>  common/cmd_bootm.c         |   23 ++
>  common/image.c             |    7 +-
>  include/image.h            |    1 +
>  include/lzma/LzmaDecode.h  |   31 ++
>  include/lzma/LzmaTools.h   |   31 ++
>  include/lzma/LzmaTypes.h   |   31 ++
>  lib_lzma/LGPL.txt          |  504 +++++++++++++++++++++++++++++++++
>  lib_lzma/LzmaDecode.c      |  584 ++++++++++++++++++++++++++++++++++++++
>  lib_lzma/LzmaDecode.h      |  113 ++++++++
>  lib_lzma/LzmaTools.c       |  143 ++++++++++
>  lib_lzma/LzmaTools.h       |   35 +++
>  lib_lzma/LzmaTypes.h       |   45 +++
>  lib_lzma/Makefile          |   51 ++++
>  lib_lzma/README.txt        |   28 ++
>  lib_lzma/history.txt       |  198 +++++++++++++
>  lib_lzma/import_lzmasdk.sh |   38 +++
>  lib_lzma/lzma.txt          |  663 ++++++++++++++++++++++++++++++++++++++++++++
>  19 files changed, 2548 insertions(+), 2 deletions(-)
>  create mode 100644 include/lzma/LzmaDecode.h
>  create mode 100644 include/lzma/LzmaTools.h
>  create mode 100644 include/lzma/LzmaTypes.h
>  create mode 100644 lib_lzma/LGPL.txt
>  create mode 100644 lib_lzma/LzmaDecode.c
>  create mode 100644 lib_lzma/LzmaDecode.h
>  create mode 100644 lib_lzma/LzmaTools.c
>  create mode 100644 lib_lzma/LzmaTools.h
>  create mode 100644 lib_lzma/LzmaTypes.h
>  create mode 100644 lib_lzma/Makefile
>  create mode 100644 lib_lzma/README.txt
>  create mode 100644 lib_lzma/history.txt
>  create mode 100644 lib_lzma/import_lzmasdk.sh
>  create mode 100644 lib_lzma/lzma.txt

Signed-off-by line is missing. Please add and resubmit.

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: wd at denx.de
History tends to exaggerate.
	-- Col. Green, "The Savage Curtain", stardate 5906.4



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] Remove duplicate #undef SHOW_INFO inside
	drivers\usb\usb_ohci.c
In-Reply-To: Your message of "Wed, 02 Apr 2008 11:04:43 +0530."
	<5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF5@blrms.slti.sanyo.co.in>
Message-ID: <20080418041413.41F80248A0@gemini.denx.de>

In message <5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF5 at blrms.slti.sanyo.co.in> you wrote:
> 
> In drivers\usb\usb_ohci.c file, SHOW_INFO is undef at 2 locations. @line
> 77 and @line 112. Below patch removes them for code size savings.

Applied, thanks, but *please* provide proper patches with usable file
name information next time. I recommend to use git-format-patch to
create the patches.

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: wd at denx.de
On the subject of C program indentation: "In My Egotistical  Opinion,
most  people's  C  programs  should be indented six feet downward and
covered with dirt."                               - Blair P. Houghton



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] s3c4510b_eth: fix 'packed' attribute
	ignored for fields of MACFrame
In-Reply-To: Your message of "Tue, 01 Apr 2008 14:07:10 +0200."
	<1207051630-25394-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080418041413.32176248B9@gemini.denx.de>

In message <1207051630-25394-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/drivers/net/s3c4510b_eth.h b/drivers/net/s3c4510b_eth.h
> index cbddba7..048307f 100644
> --- a/drivers/net/s3c4510b_eth.h
> +++ b/drivers/net/s3c4510b_eth.h

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Vulcans worship peace above all.
	-- McCoy, "Return to Tomorrow", stardate 4768.3



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH 1/2] cmd_log.c: Fix assignment differ in
	signedness
In-Reply-To: Your message of "Wed, 02 Apr 2008 08:03:57 +0200."
	<1207116238-7253-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080418041413.51BD0248BB@gemini.denx.de>

In message <1207116238-7253-2-git-send-email-plagnioj at jcrosoft.com> you wrote:
> In function 'logbuff_init_ptrs':
> cmd_log.c:79: warning: pointer targets in assignment differ in signedness
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/common/cmd_log.c b/common/cmd_log.c
> index 34b36ff..b9f9ba0 100644
> --- a/common/cmd_log.c
> +++ b/common/cmd_log.c

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: wd at denx.de
Contrary to popular belief, thinking does not cause brain damage.



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5
In-Reply-To: Your message of "Thu, 03 Apr 2008 14:43:11 +0200."
	<20080403124311.204560@gmx.net>
Message-ID: <20080418041413.71A2C248B9@gemini.denx.de>

In message <20080403124311.204560 at gmx.net> you wrote:
> Subject: [PATCH] disable CONFIG_ZERO_BOOTDELAY for lwmon5
> Change configuartion for lwmon5 board.
> 
> Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> ---
>  include/configs/lwmon5.h |    1 -
>  1 files changed, 0 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: wd at denx.de
God made the integers; all else is the work of Man.       - Kronecker



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH 2/2] ds174x: Fix warning on return in
	rtc_get and rtc_set function
In-Reply-To: Your message of "Wed, 02 Apr 2008 08:03:58 +0200."
	<1207116238-7253-3-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080418041413.61552248A0@gemini.denx.de>

In message <1207116238-7253-3-git-send-email-plagnioj at jcrosoft.com> you wrote:
> ds174x.c: In function 'rtc_get':
> ds174x.c:117: warning: no return statement in function returning non-void
> ds174x.c: In function 'rtc_set':
> ds174x.c:146: warning: 'return' with a value, in function returning void
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

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: wd at denx.de
Anything free is worth what you pay for it.



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] Rename 'addcon' to 'addcons' environment
	command for Keymile boards.
In-Reply-To: Your message of "Thu, 03 Apr 2008 14:18:47 +0200."
	<1207225128-13989-1-git-send-email-dzu@denx.de>
Message-ID: <20080418041413.914A1248B9@gemini.denx.de>

In message <1207225128-13989-1-git-send-email-dzu at denx.de> you wrote:
> The latter name with 13 users is already established, so we will use
> that.
> 
> Signed-off-by: Detlev Zundel <dzu at denx.de>
> ---
>  include/configs/mgcoge.h |    4 ++--
>  include/configs/mgsuvd.h |    4 ++--
>  2 files changed, 4 insertions(+), 4 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: wd at denx.de
Speed of a tortoise breaking the sound barrier         = 1 Machturtle



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] IDE: fix bug in reset sequence
In-Reply-To: Your message of "Thu, 03 Apr 2008 13:37:56 +0200."
	<20080403113721.28821.11173.stgit@tq-sewsrv-4.tq-net.de>
Message-ID: <20080418041413.81AB5248A0@gemini.denx.de>

In message <20080403113721.28821.11173.stgit at tq-sewsrv-4.tq-net.de> you wrote:
> According to the ata (ata5) specification the RESET- signal
> shall be asserted for at least 25 us. Without this patch,
> the RESET- signal is asserted on some boards for only < 1 us
> (e. g. on the TQM5200). This patch adds a general delay of
> 25 us to the RESET- signal.
> 
> Without this patch a Platinum 4 GiB CF card is not recognised
> properly on boards with a TQM5200 (STK52xx, TB5200).
> 
> Signed-off-by: Martin Krause <martin.krause at tqs.de>

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You can fool some of the people all of the time, and You can fool all
of the people some of the time, but You can't fool mom.



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] TQM5200: fix default IDE reset level
In-Reply-To: Your message of "Thu, 03 Apr 2008 14:29:01 +0200."
	<20080403122856.1207.24711.stgit@tq-sewsrv-4.tq-net.de>
Message-ID: <20080418041413.B0B40248B9@gemini.denx.de>

In message <20080403122856.1207.24711.stgit at tq-sewsrv-4.tq-net.de> you wrote:
> Bevore the first call of ide_reset() the default level of
> the IDE reset signal on the TQM5200 is low (reset asserted).
> This patch sets the default value to high (reset not asserted).
> 
> Currently this patch fixes no real problem, but it is cleaner
> to assert the reset only on demand, and not permanently.
> 
> Signed-off-by: Martin Krause <martin.krause at tqs.de>
> ---
> 
>  board/tqm5200/tqm5200.c |    3 +++
>  1 files changed, 3 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: wd at denx.de
Chapter 1 -- The story so  far:
In the beginning the Universe was created. This has  made  a  lot  of
people very angry and been widely regarded as a bad move.



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] [Cosmetic] Realign
	CONFIG_EXTRA_ENV_SETTING for Keymile boards.
In-Reply-To: Your message of "Thu, 03 Apr 2008 14:18:48 +0200."
	<1207225128-13989-2-git-send-email-dzu@denx.de>
Message-ID: <20080418041413.A10B3248A0@gemini.denx.de>

In message <1207225128-13989-2-git-send-email-dzu at denx.de> you wrote:
> Signed-off-by: Detlev Zundel <dzu at denx.de>
> ---
>  include/configs/mgcoge.h |   56 +++++++++++++++++++++++-----------------------
>  include/configs/mgsuvd.h |   50 ++++++++++++++++++++--------------------
>  2 files changed, 53 insertions(+), 53 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: wd at denx.de
Alles Gescheite ist schon gedacht worden, man mu? nur versuchen,
es noch einmal zu denken.          -- Goethe, Maximen und Reflexionen



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH v2] IDE: fix bug in reset sequence
In-Reply-To: Your message of "Fri, 04 Apr 2008 15:17:18 +0200."
	<20080404130906.24594.85188.stgit@tq-sewsrv-4.tq-net.de>
Message-ID: <20080418041413.C0586248A0@gemini.denx.de>

In message <20080404130906.24594.85188.stgit at tq-sewsrv-4.tq-net.de> you wrote:
> According to the ata (ata5) specification the RESET- signal
> shall be asserted for at least 25 us. Without this patch,
> the RESET- signal is asserted on some boards for only < 1 us
> (e. g. on the TQM5200). This patch adds a general delay of
> 25 us to the RESET- signal.

Already applied.

If you want to send follow-ups to previous postings. please make sure
to keep the reference information intact. As is, it was impossible to
me to see that this message belonged to a previous posting (and, even
worse, I didn't see that there was a follow-up to the one I checked
in).

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: wd at denx.de
"Obviously, a major malfunction has occurred."
              -- Steve Nesbitt, voice of Mission Control, January 28,
                 1986, as the shuttle Challenger exploded within view
                 of the grandstands.



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some
	85xx chips
In-Reply-To: Your message of "Fri, 04 Apr 2008 11:15:58 CDT."
	<1207325758-1333-1-git-send-email-timur@freescale.com>
Message-ID: <20080418041413.D015A248B9@gemini.denx.de>

In message <1207325758-1333-1-git-send-email-timur at freescale.com> you wrote:
> Some 85xx chips use CCB as the base clock for the I2C.  Some use CCB/2, and
> some use CCB/3.  There is no pattern that can be used to determine which
> chips use which frequency, so the only way to determine is to look up the
> actual SOC designation and use the right value for that SOC.
> 
> Update immap_85xx.h to include the GUTS PORDEVSR2 register.
> 
> Signed-off-by: Timur Tabi <timur at freescale.com>

Will this goin through the 85xx custodian repo, or should I pull this
directly?

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: wd at denx.de
Death, when unnecessary, is a tragic thing.
	-- Flint, "Requiem for Methuselah", stardate 5843.7



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some
	86xx chips
In-Reply-To: Your message of "Fri, 04 Apr 2008 11:16:11 CDT."
	<1207325771-1374-1-git-send-email-timur@freescale.com>
Message-ID: <20080418041413.E011A248A0@gemini.denx.de>

In message <1207325771-1374-1-git-send-email-timur at freescale.com> you wrote:
> Some 86xx chips use CCB as the base clock for the I2C, and others used CCB/2.
> There is no pattern that can be used to determine which chips use which
> frequency, so the only way to determine is to look up the actual SOC
> designation and use the right value for that SOC.
> 
> Signed-off-by: Timur Tabi <timur at freescale.com>

Will this goin through the 86xx custodian repo, or should I pull this
directly?

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: wd at denx.de
"In the long run, every program becomes rococo, and then rubble."
- Alan Perlis



From wd at denx.de  Fri Apr 18 06:14:14 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:14 +0200
Subject: [U-Boot-Users] [PATCH] nand_spl: Update nand_spl to support 2k
	page size NAND devices
In-Reply-To: Your message of "Tue, 08 Apr 2008 10:31:00 +0200."
	<1207643460-22199-1-git-send-email-sr@denx.de>
Message-ID: <20080418041414.0EB7D248A0@gemini.denx.de>

In message <1207643460-22199-1-git-send-email-sr at denx.de> you wrote:
> This patch adds support for booting from 2k page sized NAND device
> (e.g. Micron 29F2G08AAC).

Will you submit a pull request for the NAND repo, then, please?

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: wd at denx.de
CAUTION:  The Mass of This Product Contains the Energy Equivalent  of
85 Million Tons of TNT per Net Ounce of Weight.



From wd at denx.de  Fri Apr 18 06:14:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:13 +0200
Subject: [U-Boot-Users] [MIPS] cpu/mips/cpu.c: Fix flush_cache bug
In-Reply-To: Your message of "Tue, 08 Apr 2008 16:20:35 +0900."
	<47FB1CC3.2090904@necel.com>
Message-ID: <20080418041413.F2FC0248B9@gemini.denx.de>

In message <47FB1CC3.2090904 at necel.com> you wrote:
> Cache operations have to take line address (addr), not start_addr.
> I noticed this bug when debugging ping failure.
> 
> Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi at necel.com>
> ---
> 
>  cpu/mips/cpu.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 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: wd at denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
                                                          - Doug Gwyn



From wd at denx.de  Fri Apr 18 06:14:14 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:14 +0200
Subject: [U-Boot-Users] [PATCH] 85xx: Fix detection of MP cpu spin up
In-Reply-To: Your message of "Wed, 09 Apr 2008 04:20:57 CDT."
	<Pine.LNX.4.64.0804090420320.17674@blarg.am.freescale.net>
Message-ID: <20080418041414.3F202248B9@gemini.denx.de>

In message <Pine.LNX.4.64.0804090420320.17674 at blarg.am.freescale.net> you wrote:
> We were looking at the wrong memory offset to determine of a secondary
> cpu had been spun up or not.  Also added a warning message if the
> all the secondary cpus we expect don't spin up.
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>

Andy?

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: wd at denx.de
You young'uns. That was *long* before AltaVista,  DejaNews,  or  even
(gasp) the *Web*! In fact, we typed that thread on steam-powered card
punchers, and shipped it around via Pony Express.
            -- Randal Schwartz in <8cwww1cd0d.fsf at gadget.cscaper.com>



From galak at kernel.crashing.org  Fri Apr 18 06:16:00 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Thu, 17 Apr 2008 23:16:00 -0500
Subject: [U-Boot-Users] [PATCH] 85xx: Use SVR_SOC_VER instead of SVR_VER
In-Reply-To: <20080418041414.2F738248A0@gemini.denx.de>
References: <20080418041414.2F738248A0@gemini.denx.de>
Message-ID: <F14130BF-EB76-4071-8EC2-F120FD78921D@kernel.crashing.org>


On Apr 17, 2008, at 11:14 PM, Wolfgang Denk wrote:
> In message <Pine.LNX.4.64.0804081043260.9248 at blarg.am.freescale.net>  
> you wrote:
>> The recent change introduced by 'Update SVR numbers to expand  
>> support'
>> now requires that we use SVR_SOC_VER instead of SVR_VER if we want
>> to compare against a particular processor id.
>>
>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>
> Andy, will you send a pull request soon, or should I pull this in
> directly?

Already in your tree.  Commit f3e04bdc3f360c66801a9048956e61e41a16edba

- k



From galak at kernel.crashing.org  Fri Apr 18 06:16:28 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Thu, 17 Apr 2008 23:16:28 -0500
Subject: [U-Boot-Users] [PATCH] 85xx: Fix detection of MP cpu spin up
In-Reply-To: <20080418041414.3F202248B9@gemini.denx.de>
References: <20080418041414.3F202248B9@gemini.denx.de>
Message-ID: <59527E82-BBA7-4620-942D-44DA209448D8@kernel.crashing.org>


On Apr 17, 2008, at 11:14 PM, Wolfgang Denk wrote:
> In message <Pine.LNX. 
> 4.64.0804090420320.17674 at blarg.am.freescale.net> you wrote:
>> We were looking at the wrong memory offset to determine of a  
>> secondary
>> cpu had been spun up or not.  Also added a warning message if the
>> all the secondary cpus we expect don't spin up.
>>
>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>
> Andy?

Already in your tree.  Commit 97b3ecb575a92fa34c1765229dbc06f2b662f139

- k



From gururajakr at sanyo.co.in  Fri Apr 18 06:39:45 2008
From: gururajakr at sanyo.co.in (Gururaja Hebbar K R)
Date: Fri, 18 Apr 2008 10:09:45 +0530
Subject: [U-Boot-Users] [PATCH] Remove duplicate #undef SHOW_INFO inside
	drivers\usb\usb_ohci.c
References: <20080418041413.41F80248A0@gemini.denx.de>
Message-ID: <5BF78BCE8D9BF14A83F836BD9E3916BA0DDC35@blrms.slti.sanyo.co.in>

Hi,

Thanks and sorry for the mistake. will sure make it a point not to
repeat this.

Regards
Gururaja 

-----Original Message-----
From: wd at denx.de [mailto:wd at denx.de] 
Sent: Thursday, April 17, 2008 9:14 PM
To: Gururaja Hebbar K R
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [PATCH] Remove duplicate #undef SHOW_INFO inside
drivers\usb\usb_ohci.c

In message
<5BF78BCE8D9BF14A83F836BD9E3916BA0DDAF5 at blrms.slti.sanyo.co.in> you
wrote:
> 
> In drivers\usb\usb_ohci.c file, SHOW_INFO is undef at 2 locations. 
> @line
> 77 and @line 112. Below patch removes them for code size savings.

Applied, thanks, but *please* provide proper patches with usable file
name information next time. I recommend to use git-format-patch to
create the patches.

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: wd at denx.de On
the subject of C program indentation: "In My Egotistical  Opinion, most
people's  C  programs  should be indented six feet downward and
covered with dirt."                               - Blair P. Houghton



From wd at denx.de  Fri Apr 18 06:14:14 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:14 +0200
Subject: [U-Boot-Users] [PATCH] 85xx: Use SVR_SOC_VER instead of SVR_VER
In-Reply-To: Your message of "Tue, 08 Apr 2008 10:45:50 CDT."
	<Pine.LNX.4.64.0804081043260.9248@blarg.am.freescale.net>
Message-ID: <20080418041414.2F738248A0@gemini.denx.de>

In message <Pine.LNX.4.64.0804081043260.9248 at blarg.am.freescale.net> you wrote:
> The recent change introduced by 'Update SVR numbers to expand support'
> now requires that we use SVR_SOC_VER instead of SVR_VER if we want
> to compare against a particular processor id.
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>

Andy, will you send a pull request soon, or should I pull this in
directly?

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: wd at denx.de
Without facts, the decision cannot be made logically. You  must  rely
on your human intuition.
	-- Spock, "Assignment: Earth", stardate unknown



From wd at denx.de  Fri Apr 18 06:14:14 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:14 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Canyonlands default
	environment to work with new image support
In-Reply-To: Your message of "Wed, 09 Apr 2008 12:57:00 +0200."
	<1207738620-23994-1-git-send-email-sr@denx.de>
Message-ID: <20080418041414.4F3F5248A0@gemini.denx.de>

In message <1207738620-23994-1-git-send-email-sr at denx.de> you wrote:
> Since the new image support checks for image overwriting, the default
> environment needs to get adjusted to use correct addresses.
...
> -	"nupdate=nand erase 0 60000;nand write 200000 0 60000;"		\
> +	"nupdate=nand erase 0 100000;nand write 200000 0 100000;"	\

Does "nand write" support the "+${filesize}" notation (yet)?

If not, how about adding it?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Is truth not truth for all?
	-- Natira, "For the World is Hollow and I have Touched
		   the Sky", stardate 5476.4.



From yanjun.luo at gmail.com  Fri Apr 18 07:32:33 2008
From: yanjun.luo at gmail.com (yanjun.luo)
Date: Fri, 18 Apr 2008 13:32:33 +0800
Subject: [U-Boot-Users] iMX27 support status
Message-ID: <200804181332278125413@gmail.com>

Hi,
I'll debug my iMX27 board next month, I know that iMX27ADS
use redboot, but I want to use U-BOOT. I checked current code
from git, but only find iMX31's code.

How about the status of  iMX27 support?

Regards,
Yanjun Luo.





From wd at denx.de  Fri Apr 18 07:41:27 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 07:41:27 +0200
Subject: [U-Boot-Users] [RFC] recommendations for a proprietary POST
	testcase
In-Reply-To: Your message of "Thu, 17 Apr 2008 16:21:43 CDT."
	<8E8BB316C604E94AA019A54D0A5A82A2018F6899@dlee13.ent.ti.com>
Message-ID: <20080418054127.34EAA248BB@gemini.denx.de>

In message <8E8BB316C604E94AA019A54D0A5A82A2018F6899 at dlee13.ent.ti.com> you wrote:
> 
> I am looking at issues in moving from a proprietary diagnostics on a
> platform we have, to a solution using U-Boot's POST infrastructure. 

I'm afraid this doesn't work.

I understand  that  by  "proprietary"  you  mean  non-GPL.  The  only
explicit  exception  that  is  (and  will)  be  allowed for U-boot is
standalone applications. Such applications  can  use  a  well-defined
interface  to  U-Boot  which  eports  some  basic services, but it is
definitely not intended to allow you more extensive use of the U-Boot
infrastructure. We will not allow for any kind of masqueraded linking
of non-GPL code against U-Boot.

If you want to use the POST infrastructure for your  own  test  code,
please  add  it  (under  GPL,  of  course) to the U-Boot code. Alter-
natively, you can use a standalone application,  but  this  will  not
have full access to each and every function that exists in U-Boot.

> I am sure many of us here have faced the condition where certain
> peripherals may not become open source due to legal restrictions. In the

Actually, we haven't.

First, peripherals are hardware. They cannot "become open source"
because hardware does not become software. And I see no reason why
even hardware which requires a strict NDA to get access to the
documentation should not be supported by Free Software drivers.

> case of POST support, the API set is not exported for a U-Boot
> standalone application to use. Writing a POST code linked within U-Boot

Correct, and we will not export any such internal APIs for standalone
applications. That would undermine the whole philosophy of  the  GPL,
as  it  would  mean  not more or less that providing a way of linking
against GPL code without putting your code under GPL,  too.  This  is
not intended.

> for a proprietary device may have implications of being completely
> linked with U-Boot and subject to GPL-v2 distribution requirements.

Indeed that will be the case. Ich you want to  use  the  POST  infra-
structure  or  similar "internal" functions, please release your code
under GPL, too.

You get so much code for free, please contribute back.

> I wonder if anyone can share their experiences to what folks have done
> in such cases.

We have always released our code under GPL. It's that simple.

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: wd at denx.de
Minds are like parachutes - they only function when open.



From wd at denx.de  Fri Apr 18 07:41:27 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 07:41:27 +0200
Subject: [U-Boot-Users] Want to add command in uboot
In-Reply-To: Your message of "Thu, 17 Apr 2008 15:48:06 PDT."
	<895609.34146.qm@web39508.mail.mud.yahoo.com>
Message-ID: <20080418054127.54C50248B9@gemini.denx.de>

In message <895609.34146.qm at web39508.mail.mud.yahoo.com> you wrote:
>
> I am working on AT91SAM9260. I want to add one command "COM1 xxx" to the uboot command set. After typing this command on uboot prompt the string xxx should be transmitted out of COM1 and any reception on COM1 should be displayed on the debug terminal. C
> an some one suggest me how to do this?

I recommend to get a better understanding of the existing U-Boot code
first. Then you will see that no such command is needed. Support for
multiple serial devices is already present.You just have to enable
this correctly in your configuration. To switch I/O channels, a simple
"setenv" command will be sufficient.

> --0-479714745-1208472486=:34146
> Content-Type: text/html; charset=us-ascii

Please never post HTML here!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Speed of a tortoise breaking the sound barrier         = 1 Machturtle



From wd at denx.de  Fri Apr 18 07:41:27 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 07:41:27 +0200
Subject: [U-Boot-Users] Search for mpc8641d patch
In-Reply-To: Your message of "Thu, 17 Apr 2008 17:26:54 EDT."
	<1208467614.2963.47.camel@r54964-12.am.freescale.net>
Message-ID: <20080418054127.44F02248AB@gemini.denx.de>

Dear Haiying,

in message <1208467614.2963.47.camel at r54964-12.am.freescale.net> you wrote:
>
> 8641D ASMP support was not submitted to opensource, you can download

I think the terminology is not quite correct.

> MPC8641D BSP from Freescale website and find the patch in the BSP.
> http://www.freescale.com/webapp/sps/site/overview.jsp?code=CW_BSP_PPC&fsrch=1

If Freescale distributes the code (like you are doing by enabling
download from a publicly available server) then you *MUST* adhere to
the GPL license conditions which apply to that code. And GPL is one
of the approved Open Source licenses, see
http://www.opensource.org/licenses


I am pretty sure you are aware of this and meant something  different
(not submitted to the mainline tree, resp. o the public mailing list,
or  similar),  but  it  is  important to use precise terms, so please
allow for this small correction.

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: wd at denx.de
                  Nail here --X-- for new monitor.



From wd at denx.de  Fri Apr 18 06:14:14 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 06:14:14 +0200
Subject: [U-Boot-Users] [PATCH] removing conflicting NAND ID
In-Reply-To: Your message of "Tue, 08 Apr 2008 10:24:24 EDT."
	<1207664664-27804-1-git-send-email-vapier@gentoo.org>
Message-ID: <20080418041414.1ECE6248B9@gemini.denx.de>

In message <1207664664-27804-1-git-send-email-vapier at gentoo.org> you wrote:
> There are two NAND entries with ID 0xDC and this obviously causes problems.
> In the kernel, they punted the first entry, so we should do the same.
> 
> See this upstream e-mail for more info:
> http://lists.infradead.org/pipermail/linux-mtd/2007-July/018795.html
> 
> Signed-off-by: Michael Hennerich <michael.hennerich at analog.com>
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> CC: Michael Morony <michael.morony at gmail.com>
> ---
>  drivers/mtd/nand/nand_ids.c |    2 --
>  1 files changed, 0 insertions(+), 2 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: wd at denx.de
I express preference for a chronological  sequence  of  events  which
precludes a violence.   - Terry Pratchett, _The Dark Side of the Sun_



From njayaswal at tataelxsi.co.in  Fri Apr 18 08:01:38 2008
From: njayaswal at tataelxsi.co.in (Neeraj Jayaswal)
Date: Fri, 18 Apr 2008 11:31:38 +0530
Subject: [U-Boot-Users] U-Boot : USB Slave Mode ?
Message-ID: <002f01c8a119$aaf5a9e0$42053c0a@telxsi.com>

Hi,

Does U-Boot support USB Slave mode ?

I have an ARM926EJS board with USB-OTG. I can configure it in USB Slave mode
using some register settings.
But I need to run U-Boot on top of it so that I can access the USB Slave
functionality.

Kindly suggest how I can use U-Boot in USB Slave mode and what configuration
changes are required ?

Thanks in Advance.

Regards,
Neeraj


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.




From r.schwebel at pengutronix.de  Fri Apr 18 08:49:22 2008
From: r.schwebel at pengutronix.de (Robert Schwebel)
Date: Fri, 18 Apr 2008 08:49:22 +0200
Subject: [U-Boot-Users] iMX27 support status
In-Reply-To: <200804181332278125413@gmail.com>
References: <200804181332278125413@gmail.com>
Message-ID: <20080418064922.GC13814@pengutronix.de>

On Fri, Apr 18, 2008 at 01:32:33PM +0800, yanjun.luo wrote:
> I'll debug my iMX27 board next month, I know that iMX27ADS
> use redboot, but I want to use U-BOOT. I checked current code
> from git, but only find iMX31's code.
> 
> How about the status of  iMX27 support?

i.MX27 and the ADS is supported in the u-boot-v2 tree:
http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-v2.git;a=summary

Note that nobody invested much work in the ADS yet, our forcus was on
the phyCORE-i.MX27 board.

And when you want to start with Linux, please have a look at our patch
series for the board:
http://www.pengutronix.de/software/linux-i.MX/index_en.html

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9




From ulf.samuelsson at atmel.com  Fri Apr 18 07:52:46 2008
From: ulf.samuelsson at atmel.com (Ulf Samuelsson)
Date: Fri, 18 Apr 2008 07:52:46 +0200
Subject: [U-Boot-Users] Want to add command in uboot
References: <20080418054127.54C50248B9@gemini.denx.de>
Message-ID: <00be01c8a121$1c2971d0$0b0514ac@atmel.com>

>>
>> I am working on AT91SAM9260. I want to add one command "COM1 xxx" to the uboot command set. After typing this command on uboot prompt the string xxx should be transmitted out of COM1 and any reception on COM1 should be displayed on the debug terminal. C
>> an some one suggest me how to do this?
> 
> I recommend to get a better understanding of the existing U-Boot code
> first. Then you will see that no such command is needed. Support for
> multiple serial devices is already present.You just have to enable
> this correctly in your configuration. To switch I/O channels, a simple
> "setenv" command will be sufficient.
> 
> 

I think that he wants to have the console on DBGU (Debug UART),

COM1 "xxx" will send the string to UART1, and a response is received on UART1.
The response should be echoed on DBGU

Is that really possible?

I would do it a bit different though.
I would have a command which puts u-boot in a transparent mode
just forwarding any incoming data on the DBGU to the selected
USART (or SPI or whatever).
All incoming data on the selected channel is forwarded to DBGU.

Aborted by pressing a combination of keys (Ctrl-C three times?).


> Best regards,
> 
> Wolfgang Denk
> 


Best Regards
Ulf Samuelsson





From Martin.Krause at tqs.de  Fri Apr 18 09:38:13 2008
From: Martin.Krause at tqs.de (Martin Krause)
Date: Fri, 18 Apr 2008 09:38:13 +0200
Subject: [U-Boot-Users] [PATCH v2] IDE: fix bug in reset sequence
In-Reply-To: <20080418041413.C0586248A0@gemini.denx.de>
Message-ID: <47F3F98010FF784EBEE6526EAAB078D10635DF13@tq-mailsrv.tq-net.de>

u-boot-users-bounces at lists.sourceforge.net wrote on :
> In message <20080404130906.24594.85188.stgit at tq-sewsrv-4.tq-net.de>
> you wrote: 
> > According to the ata (ata5) specification the RESET- signal
> > shall be asserted for at least 25 us. Without this patch,
> > the RESET- signal is asserted on some boards for only < 1 us
> > (e. g. on the TQM5200). This patch adds a general delay of
> > 25 us to the RESET- signal.
> 
> Already applied.
> 
> If you want to send follow-ups to previous postings. please make sure
> to keep the reference information intact. As is, it was impossible to

I'm sorry for that! I tried to mark this patch as follup-up by the
"v2" in the Subject, but I see, that this was not sufficient.

What do you mean with reference information? The message id?
Does anyone know, how I can re-send a modified patch with git (or 
stacked git which I use normally) without generating a new message ID 
(and without copy- and pasteing the new patch in the reply email)?

Best Regards,
Martin Krause

--
TQ-Systems GmbH
Muehlstrasse 2, Gut Delling, D-82229 Seefeld
Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl
http://www.tq-group.com



From tor at excito.com  Fri Apr 18 10:40:47 2008
From: tor at excito.com (Tor Krill)
Date: Fri, 18 Apr 2008 08:40:47 +0000 (UTC)
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <480797BB.8090507@matrix-vision.de>
Message-ID: <NPAblFOq.1208508046.5957230.tor@localhost>



Hi,

On 4/17/2008, "Andre Schwarz" <andre.schwarz at matrix-vision.de> wrote:

>Tor,
>
>after all my VSC8601 is up and running on MPC8343  :-)
>
>I'm sorry to say that I don't find this patch ok after going through the
>manuals :
>
>Register 0x17 is a very coarse setting. If the capabilities of the PHY
>should be taken into account and be configurable we should use the skew
>control in extended register 0x1c. This should be definable -
>CFG_VSC8601_SKEWFIX simply applies maximum skew ...

Sure it certainly could have been done in a more configurable way. But
you have to decide what you need. For us this was an apropriate level
atm that scratched our itch. If we where to expose every setting from
the start we still would not have been done  ;)

>After all changing the bits in register 0x17 _require_ a soft reset by
>asserting bit 15 in register 0 before they are going to work.
>
>Obviously this patch has no effect at all.
>Do you reset the PHY manually after this configuration ?

According to our datasheet (dated july 2006) only changes of bit 12 in
this register needs a software reset to take. We don't reset the phy
after changing this and the change obviously work (we have tested and
verified that it won't work without the change).

>This PHY definitely needs a proper setup function since there are quite
>interesting registers which need read-modify-write.
>
>What do you think ?

Perhaps a patch to improve what you find missing?

/Tor

>
>Kim Phillips schrieb:
>> On Mon, 31 Mar 2008 10:01:34 -0400
>> Ben Warren <biggerbadderben at gmail.com> wrote:
>>
>>
>>> Tor Krill wrote:
>>>
>>>> Add phy_info for Vitesse VSC8601.
>>>> Add config option, CFG_VSC8601_SKEWFIX, to enable RGMII skew timing compensation.
>>>>
>>>> Signed-off-by: Tor Krill <tor at excito.com>
>>>>
>>>>
>>> Acked-by: Ben Warren <biggerbadderben at gmail.com>
>>>
>>
>> I don't have a Vitesse 8601, so technically I can't ack it, but I can:
>>
>> Reviewed-by: Kim Phillips <kim.phillips at freescale.com>
>>
>> minor nit: it would be nice if the following:
>>
>>
>>>> +#ifdef CFG_VSC8601_SKEWFIX
>>>> +				{MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
>>>> +#endif
>>>>
>>
>> were made to have spaces after commas, and flow onto a separate
>> line so as to not be a 96 char line..
>>
>> Kim
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> U-Boot-Users mailing list
>> U-Boot-Users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>
>
>
>
>MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
>Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH] Fix regression introduced by a typo in
	"Tidied other cpu/arm920t/start.S code"
In-Reply-To: Your message of "Wed, 09 Apr 2008 17:34:08 +0200."
	<Pine.LNX.4.64.0804091725330.5671@axis700.grange>
Message-ID: <20080418075453.56788248B9@gemini.denx.de>

In message <Pine.LNX.4.64.0804091725330.5671 at axis700.grange> you wrote:
> Restore logic reverted by commit
> 
> commit 80767a6cead9990d9e77e62be947843c2c72f469
> Author: Peter Pearse <peter.pearse at arm.com>
> Date:   Wed Sep 5 16:04:41 2007 +0100
> 
>     Changed API name to coloured_led.h
>     Removed code using deprecated ifdef CONFIG_BOOTBINFUNC
>     Tidied other cpu/arm920t/start.S code
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
> 
> commit 4edc89c17c34c10885082ddbc73b9416e8ff4f5a
> Author: Guennadi Liakhovetski <lyakh at 6a.(none)>
> Date:   Wed Apr 9 17:05:52 2008 +0200
> 
>     Fix reverted ifdef
>     
>     Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> diff --git a/cpu/arm920t/start.S b/cpu/arm920t/start.S
> index ae86002..acc00ad 100644
> --- a/cpu/arm920t/start.S
> +++ b/cpu/arm920t/start.S

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: wd at denx.de
IMPORTANT NOTICE TO PURCHASERS: The Entire Physical Universe,  Inclu-
ding  This Product, May One Day Collapse Back into an Infinitesimally
Small Space. Should  Another  Universe  Subsequently  Re-emerge,  the
Existence of This Product in That Universe Cannot Be Guaranteed.



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH] qemu-mips: add CFI support
In-Reply-To: Your message of "Thu, 10 Apr 2008 10:31:35 +0200."
	<1207816295-9586-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080418075453.76784248B9@gemini.denx.de>

In message <1207816295-9586-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
...
> @@ -74,16 +74,12 @@
>  #define CONFIG_CMD_ELF
>  #define CONFIG_CMD_FAT
>  #define CONFIG_CMD_EXT2
> -#undef  CONFIG_CMD_IMLS
> -#undef  CONFIG_CMD_FLASH
> -#undef  CONFIG_CMD_LOADB
^^^^^^^^^^^^^^^^^^^^^^^^^^^
> -#undef  CONFIG_CMD_LOADS
^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  #define CONFIG_CMD_DHCP
> +#define CONFIG_CMD_PING
^^^^^^^^^^^^^^^^^^^^^^^^^^^

These changes are neither related to CFI support nor mentioned in the
subject. This is misleading.

> -#define	CFG_MONITOR_LEN		(192 << 10)
> +#define	CFG_MONITOR_LEN		(192 << 11)

It would be much better readable if you wrote "384 << 10" instead -
everybody will then see immediately that this is 384 KiB.

But - is this really needed? Has your image become that big?
Please check!!

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: wd at denx.de
Prepare for tomorrow -- get ready.
	-- Edith Keeler, "The City On the Edge of Forever",
	   stardate unknown



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH] Boot-related documentation update
In-Reply-To: Your message of "Mon, 14 Apr 2008 15:44:16 +0200."
	<20080414134306.15603.84966.stgit@pollux.denx.de>
Message-ID: <20080418075453.66A35248AB@gemini.denx.de>

In message <20080414134306.15603.84966.stgit at pollux.denx.de> you wrote:
> - document 'bootm_low' and 'bootm_size' environment variables
> - update inaccurate CFG_BOOTMAPSZ entry
> 
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> Addressed comment by Kumar, changed patch description accordingly.
> 
>  README |   21 +++++++++++++++++++--
>  1 files changed, 19 insertions(+), 2 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: wd at denx.de
It [being a Vulcan] means to adopt a philosophy, a way of life  which
is logical and beneficial. We cannot disregard that philosophy merely
for personal gain, no matter how important that gain might be.
	-- Spock, "Journey to Babel", stardate 3842.4



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH] Request to remove SEARCH_DIR from lds
	files
In-Reply-To: Your message of "Thu, 10 Apr 2008 16:11:46 CDT."
	<47FE8292.3020502@windriver.com>
Message-ID: <20080418075453.865A5248AB@gemini.denx.de>

In message <47FE8292.3020502 at windriver.com> you wrote:
> 
> Unless someone has an objection, would it be possible to remove all
> the SEARCH_DIR() directives from the lds files with the attached
> patch?

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: wd at denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.                                               - Bill Gates



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH 2/2] [new uImage] Restore the ability to
	continue booting after legacy image overwrite
In-Reply-To: Your message of "Fri, 11 Apr 2008 11:07:49 +0200."
	<20080411090749.7630.39554.stgit@hekate.izotz.org>
Message-ID: <20080418075453.A5EEB248AB@gemini.denx.de>

In message <20080411090749.7630.39554.stgit at hekate.izotz.org> you wrote:
> Before new uImage code was merged, bootm code allowed for the kernel image to
> get overwritten during decompresion. new uImage introduced a check for image
> overwrites and refused to boot the image that got overwritten. This patch
> restores the old behavior. It also adds a warning when the image overwriten is
> a multi-image file, because in such case accessing componentes other than the
> first one will fail.
> 
> Signed-off-by: Marian Balakowicz <m8 at semihalf.com>
> ---
> 
>  common/cmd_bootm.c     |   37 ++++++++++++++++++++++++++-----------
>  common/image.c         |    2 +-
>  include/image.h        |    3 ++-
>  lib_arm/bootm.c        |    2 +-
>  lib_avr32/bootm.c      |    2 +-
>  lib_blackfin/bootm.c   |    2 +-
>  lib_m68k/bootm.c       |    2 +-
>  lib_microblaze/bootm.c |    2 +-
>  lib_mips/bootm.c       |    2 +-
>  lib_nios2/bootm.c      |    2 +-
>  lib_ppc/bootm.c        |    4 ++--
>  lib_sh/bootm.c         |    2 +-
>  12 files changed, 39 insertions(+), 23 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: wd at denx.de
Save energy:  Drive a smaller shell.



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH 1/2] [new uImage] ppc: Fix ftd_blob
	variable init when processing raw blob
In-Reply-To: Your message of "Fri, 11 Apr 2008 11:07:43 +0200."
	<20080411090743.7630.11993.stgit@hekate.izotz.org>
Message-ID: <20080418075453.963D7248BB@gemini.denx.de>

In message <20080411090743.7630.11993.stgit at hekate.izotz.org> you wrote:
> Set fdt_blob variable before its value is printed out.
> 
> Signed-off-by: Marian Balakowicz <m8 at semihalf.com>
> ---
> 
>  lib_ppc/bootm.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

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



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Use watchdog-aware functions when
	calculating hashes of images
In-Reply-To: Your message of "Sat, 12 Apr 2008 13:15:20 +0200."
	<20080412111520.16495.11791.stgit@pollux.denx.de>
Message-ID: <20080418075453.D5100248B9@gemini.denx.de>

In message <20080412111520.16495.11791.stgit at pollux.denx.de> you wrote:
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> 
>  common/image.c      |   43 +++++++++----------------------------------
>  include/image.h     |   17 +++++++++++++++--
>  lib_generic/crc32.c |    1 +
>  lib_generic/md5.c   |    4 ++++
>  lib_generic/sha1.c  |    4 ++++
>  5 files changed, 33 insertions(+), 36 deletions(-)

This patch doesn't apply - please rebase against current top of tree
and resubmit.

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: wd at denx.de
The ideal situation is to have massive computing power right at home.
Something that dims the streetlights and shrinks the picture  on  the
neighbours' TVs when you boot it up.



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH] Fix dependency generation for older gcc
	versions
In-Reply-To: Your message of "Fri, 11 Apr 2008 21:20:14 +0300."
	<47FFABDE.9030604@comsys.ro>
Message-ID: <20080418075453.B5B5C248B9@gemini.denx.de>

In message <47FFABDE.9030604 at comsys.ro> you wrote:
>  With gcc 3.3.3 at least, compilation fails with
> 
> Generating include/autoconf.mk
> gcc: compilation of header file requested
> make: *** [include/autoconf.mk] Error 1
> 
> since commit 16fe77752eee099b9fb61ed73460e51cc94b37ba.
> 
> Signed-off-by: Vlad Lungu <vlad at comsys.ro>

Your patch was line-wrapped:

>  Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index e5b4210..ef6927b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -425,7 +425,7 @@ $(obj)include/autoconf.mk: $(obj)include/config.h 
> $(VERSION_FILE)
^^^^^^^^^^^^^^^^^ here
>      @$(XECHO) Generating include/autoconf.mk ; \
>      set -e ; \
>      : Generate the dependancies ; \
> -    $(CC) -M $(HOST_CFLAGS) $(CPPFLAGS) -MQ $@ include/common.h > 
> $@.dep ; \
^^^^^^^^^^^^^^^^^ and here
> +    $(CC) -x c -M $(HOST_CFLAGS) $(CPPFLAGS) -MQ $@ include/common.h > 
> $@.dep ; \
^^^^^^^^^^^^^^^^^ and here
>      : Extract the config macros ; \
>      $(CPP) $(CFLAGS) -dM include/common.h | sed -n -f 
> tools/scripts/define2mk.sed > $@
^^^^^^^^^^^^^^^^^ and here

Manually applied.

Please make sure to fix your mailer!!!

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: wd at denx.de
Superior ability breeds superior ambition.
	-- Spock, "Space Seed", stardate 3141.9



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH] gitignore: udpate stgit generated and
	.patch file
In-Reply-To: Your message of "Sat, 12 Apr 2008 14:08:45 +0200."
	<1208002125-20003-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080418075454.00314248AB@gemini.denx.de>

In message <1208002125-20003-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/.gitignore b/.gitignore
> index 7c56594..89e96f5 100644
> --- a/.gitignore
> +++ b/.gitignore

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: wd at denx.de
Here is an Appalachian version of management's answer  to  those  who
are  concerned  with  the fate of the project: "Don't worry about the
mule. Just load the wagon."         - Mike Dennison's hillbilly uncle



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH] Clean up dataflash partitioning
In-Reply-To: Your message of "Sat, 12 Apr 2008 20:29:44 +0200."
	<1208024984.8004.10.camel@elrond.atmel.sweden>
Message-ID: <20080418075454.0FF51248B9@gemini.denx.de>

In message <1208024984.8004.10.camel at elrond.atmel.sweden> you wrote:
> 
> This patch removes the board dependent parts from
> "drivers/mtd/dataflash.c".
> Each board relying on this, will have the appropriate
> code in a new file, "partition.c" in the board directory.
> board Makefiles updated to use the file.
> 
> The dataflash partitions are aligned on sector/page boundaries.
> 
> The CONFIG_NEW_DF_PARTITION was used to create named partitions
> This is now the default operation, and the CONFIG variable is removed.
> 
> Signed-off-by: Ulf Samuelsson <ulf at atmel.com>

Applied, thanks.

> --=-4PTOBbJqMcii1Pmj++mI
> Content-Disposition: attachment; filename=partition.patch
> Content-Type: text/x-patch; name=partition.patch; charset=UTF-8
> Content-Transfer-Encoding: 7bit

But please post patches inline instead of as MIME attachments.

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: wd at denx.de
Eeeek!
'eval' on strings should have been named 'evil'.    -- Tom Phoenix in
        <Pine.GSO.3.96.980526121813.27437N-100000 at user2.teleport.com>



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH] Reorder ARM boards in Makefile
In-Reply-To: Your message of "Sat, 12 Apr 2008 20:56:03 +0200."
	<1208026563.23686.4.camel@elrond.atmel.sweden>
Message-ID: <20080418075454.2BD17248AB@gemini.denx.de>

In message <1208026563.23686.4.camel at elrond.atmel.sweden> you wrote:
> 
> Rearrange ARM boards in Makefile so that ARM926EJ-S boards
> are no longer under ARM92xT header.
> 
> Signed-off-by: Ulf Samuelsson <ulf at atmel.com>

Applied, thanks.

> --=-6LOI7smgvgUuHf2ZDm56
> Content-Disposition: attachment; filename=Makefile.Reorder-ARM.patch
> Content-Type: text/x-patch; name=Makefile.Reorder-ARM.patch; charset=UTF-8
> Content-Transfer-Encoding: 7bit

Again: please post patches inline. Do NOT use attachments.

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: wd at denx.de
Dealing with failure is easy: work hard to improve. Success  is  also
easy  to  handle:  you've  solved  the  wrong  problem.  Work hard to
improve.



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Add support for calulacting hashes
	with watchdog triggering
In-Reply-To: Your message of "Sat, 12 Apr 2008 13:15:03 +0200."
	<20080412111502.16495.46710.stgit@pollux.denx.de>
Message-ID: <20080418075453.C573B248AB@gemini.denx.de>

In message <20080412111502.16495.46710.stgit at pollux.denx.de> you wrote:
> Implement watchodg-aware variants of hash calculation functions:
> - crc32_wd()
> - md5_wd()
> - sha1_csum_wd()
> The above functions calculate the hash of the input buffer in chunks,
> triggering the watchdog after processing each chunk. The chunk size is given
> as a function call parameter.
> 
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> 
>  include/common.h    |    1 +
>  include/md5.h       |    8 ++++++++
>  include/sha1.h      |   11 +++++++++++
>  lib_generic/crc32.c |   27 +++++++++++++++++++++++++++
>  lib_generic/md5.c   |   36 ++++++++++++++++++++++++++++++++++++
>  lib_generic/sha1.c  |   33 +++++++++++++++++++++++++++++++++
>  6 files changed, 116 insertions(+), 0 deletions(-)

This doesn't apply any more - for example, include/md5.h does not
exist any more.

Please rebase against current top of tree and resubmit.

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: wd at denx.de
It is not best to swap horses while crossing the river.
- Abraham Lincoln



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH] Add support for Atmel flash
In-Reply-To: Your message of "Sat, 12 Apr 2008 21:03:22 +0200."
	<1208027002.23686.7.camel@elrond.atmel.sweden>
Message-ID: <20080418075454.3C419248B9@gemini.denx.de>

In message <1208027002.23686.7.camel at elrond.atmel.sweden> you wrote:
> 
> Add ID codes for most recent Atmel NOR flashes
> 
> Signed-off-by: Ulf Samuelsson <ulf at atmel.com>

Rejected. Please use the CFI driver for newly added code. For this,
such defines are not needed.

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: wd at denx.de
"There is such a fine line between genius and stupidity."
- David St. Hubbins, "Spinal Tap"



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH] allow ports to override go behavior
In-Reply-To: Your message of "Sun, 13 Apr 2008 19:42:19 EDT."
	<1208130139-18440-2-git-send-email-vapier@gentoo.org>
Message-ID: <20080418075454.5BC57248B9@gemini.denx.de>

In message <1208130139-18440-2-git-send-email-vapier at gentoo.org> you wrote:
> Split the arch-specific logic out of the common go code and into a dedicated
> weak function called do_go_exec() that lives in cpu directories.  This will
> need review from i386/nios people to make sure I didn't break them.
> ---
>  common/cmd_boot.c |   33 +++++----------------------------
>  lib_i386/board.c  |    8 ++++++++
>  lib_nios/board.c  |   10 ++++++++++
>  3 files changed, 23 insertions(+), 28 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: wd at denx.de
In the bathtub of history the truth is harder to hold than the  soap,
and much more difficult to find ...     - Terry Pratchett, _Sourcery_



From wd at denx.de  Fri Apr 18 09:54:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:53 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Add support for calulacting hashes
	with watchdog triggering
Message-ID: <20080418075453.E4ADC248BB@gemini.denx.de>

> In message <20080412111502.16495.46710.stgit at pollux.denx.de> you wrote:
> > Implement watchodg-aware variants of hash calculation functions:
> > - crc32_wd()
> > - md5_wd()
> > - sha1_csum_wd()
> > The above functions calculate the hash of the input buffer in chunks,
> > triggering the watchdog after processing each chunk. The chunk size is given
> > as a function call parameter.
> > 
> > Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> > ---
> > 
> >  include/common.h    |    1 +
> >  include/md5.h       |    8 ++++++++
> >  include/sha1.h      |   11 +++++++++++
> >  lib_generic/crc32.c |   27 +++++++++++++++++++++++++++
> >  lib_generic/md5.c   |   36 ++++++++++++++++++++++++++++++++++++
> >  lib_generic/sha1.c  |   33 +++++++++++++++++++++++++++++++++
> >  6 files changed, 116 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: wd at denx.de
> It is not best to swap horses while crossing the river.
> - Abraham Lincoln



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH] allow ports to override bootelf behavior
In-Reply-To: Your message of "Sun, 13 Apr 2008 19:42:18 EDT."
	<1208130139-18440-1-git-send-email-vapier@gentoo.org>
Message-ID: <20080418075454.4C1F7248AB@gemini.denx.de>

In message <1208130139-18440-1-git-send-email-vapier at gentoo.org> you wrote:
> Change the bootelf setup function into a dedicated weak function called
> do_bootelf_exec.  This way ports can control the behavior however they
> like before/after calling the ELF entry point.
> ---
>  common/cmd_elf.c |   33 +++++++++++++++++++++------------
>  1 files changed, 21 insertions(+), 12 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: wd at denx.de
Question: How does one get fresh air into a Russian church?
Answer:   One clicks on an icon, and a window opens!



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH] Fix name of i.MX31 boards in config file
	header
In-Reply-To: Your message of "Tue, 15 Apr 2008 19:09:10 +0200."
	<4804E136.4050202@gmail.com>
Message-ID: <20080418075454.6B80E248AB@gemini.denx.de>

In message <4804E136.4050202 at gmail.com> you wrote:
> Correct the name of the i.MX31 Litekit and phyCORE boards in config files.
> 
> Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
> ---
> 
>  Corrected the phyCORE name after comment from Robert Schwebel.
> 
>  include/configs/imx31_litekit.h |    2 +-
>  include/configs/imx31_phycore.h |    2 +-
>  2 files changed, 2 insertions(+), 2 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: wd at denx.de
"Free markets select for winning solutions."        - Eric S. Raymond



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] Pull request - net
In-Reply-To: Your message of "Tue, 15 Apr 2008 00:32:57 EDT."
	<f8328f7c0804142132q37c5f523u343192ccf734e751@mail.gmail.com>
Message-ID: <20080418075454.79608248B9@gemini.denx.de>

Dear Ben,

in message <f8328f7c0804142132q37c5f523u343192ccf734e751 at mail.gmail.com> you wrote:
> 
> The following changes since commit 3dfd4aab929cccddb63d9ea509967861e1333b52:
>   Sascha Laue (1):
>         Fix watchdog POST for lwmon5
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-net.git master
> 
> Guennadi Liakhovetski (1):
>       Clean up smsc911x driver
> 
> Sascha Hauer (1):
>       add SMSC LAN9x1x Network driver
> 
>  drivers/net/Makefile            |    1 +
>  drivers/net/smc911x.c           |  686 +++++++++++++++++++++++++++++++++++++++
>  include/configs/imx31_litekit.h |    1 +
>  include/configs/imx31_phycore.h |    1 +
>  4 files changed, 689 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/net/smc911x.c

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: wd at denx.de
Lots of folks confuse bad management with destiny.   -- Frank Hubbard



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH v2 2/3] RTC driver for MC13783
In-Reply-To: Your message of "Tue, 15 Apr 2008 14:15:30 +0200."
	<Pine.LNX.4.64.0804151414260.5159@axis700.grange>
Message-ID: <20080418075454.99413248B9@gemini.denx.de>

In message <Pine.LNX.4.64.0804151414260.5159 at axis700.grange> you wrote:
> MC13783 is a multifunction IS with an SPI interface to the host. This
> driver handles the RTC controller in this chip.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
> 
> Changes since v1: update to current git HEAD
> 
>  README                    |    1 +
>  drivers/rtc/Makefile      |    1 +
>  drivers/rtc/mc13783-rtc.c |   82 +++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 84 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/rtc/mc13783-rtc.c

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: wd at denx.de
Oh, that sound of male ego.  You travel halfway across the galaxy and
it's still the same song.
	-- Eve McHuron, "Mudd's Women", stardate 1330.1



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH v2 1/3] New i.MX31 SPI driver
In-Reply-To: Your message of "Tue, 15 Apr 2008 14:14:25 +0200."
	<Pine.LNX.4.64.0804151412120.5159@axis700.grange>
Message-ID: <20080418075454.896D9248AB@gemini.denx.de>

In message <Pine.LNX.4.64.0804151412120.5159 at axis700.grange> you wrote:
> This is an SPI driver for i.MX and MXC based SoCs from Freescale. So far
> only implemented and tested on i.MX31, can with a modified register layout
> and definitions be used for i.MX27, I think, MXC CPUs have similar SPI
> controllers too.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
> 
> Changes since v1: fix a copy-paste error
> 
>  README                                |    5 +
>  drivers/spi/Makefile                  |    1 +
>  drivers/spi/mxc_spi.c                 |  166 +++++++++++++++++++++++++++++++++
>  include/asm-arm/arch-mx31/mx31-regs.h |    7 +-
>  include/spi.h                         |   16 +++-
>  5 files changed, 193 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/spi/mxc_spi.c

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: wd at denx.de
If ignorance is bliss, why aren't there more happy people?



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH][MIPS] Use jr as register jump instruction
In-Reply-To: Your message of "Thu, 17 Apr 2008 23:35:13 +0900."
	<48076021.9090908@ruby.dti.ne.jp>
Message-ID: <20080418075454.B922A248B9@gemini.denx.de>

In message <48076021.9090908 at ruby.dti.ne.jp> you wrote:
> Current assembler codes are inconsistent in the way of register jump
> instruction usage; some use jr, some use j. Of course GNU as allows both
> usages, but as can be expected from `Jump Register' the mnemonic `jr' is
> more intuitive than `j'. For example, Linux doesn't have `j <reg>' usage
> at all.
> 
> Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
> ---
> 
>  board/dbau1x00/lowlevel_init.S  |    2 +-
>  board/gth2/lowlevel_init.S      |    2 +-
>  board/incaip/lowlevel_init.S    |    8 ++++----
>  board/pb1x00/lowlevel_init.S    |    2 +-
>  board/purple/lowlevel_init.S    |    2 +-
>  board/qemu-mips/lowlevel_init.S |    2 +-
>  cpu/mips/cache.S                |    4 ++--
>  cpu/mips/incaip_wdt.S           |    2 +-
>  cpu/mips/start.S                |    6 +++---
>  9 files changed, 15 insertions(+), 15 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: wd at denx.de
READ THIS BEFORE OPENING PACKAGE: According to Certain Suggested Ver-
sions of the Grand Unified Theory, the Primary Particles Constituting
this Product May Decay to Nothingness Within the  Next  Four  Hundred
Million Years.



From mk at denx.de  Fri Apr 18 09:58:13 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Fri, 18 Apr 2008 09:58:13 +0200
Subject: [U-Boot-Users] U-Boot : USB Slave Mode ?
In-Reply-To: <002f01c8a119$aaf5a9e0$42053c0a@telxsi.com> (Neeraj Jayaswal's
	message of "Fri\, 18 Apr 2008 11\:31\:38 +0530")
References: <002f01c8a119$aaf5a9e0$42053c0a@telxsi.com>
Message-ID: <87skxjd27e.fsf@denx.de>

Dear Neeraj,

Posting a similar message several times will get you ignored or
flamed. Don't do it.

"Neeraj Jayaswal" <njayaswal at tataelxsi.co.in> writes:

> Does U-Boot support USB Slave mode ?

Not out of the box, though IIRC this has been done before.

> I have an ARM926EJS board with USB-OTG. I can configure it in USB Slave mode
> using some register settings.
> But I need to run U-Boot on top of it so that I can access the USB Slave
> functionality.
>
> Kindly suggest how I can use U-Boot in USB Slave mode and what configuration
> changes are required ?

You will have to implement it. Can you help me understand why exactly
you would want such a feature in U-Boot?

> The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.
>
> Contact your Administrator for further information.

Please contact your administrator for further information on how to get
rid of this useless message.

Best regards

Markus Klotzbuecher

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



From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH 3/3] MX31ADS environment variable update,
	spi and rtc support
In-Reply-To: Your message of "Tue, 15 Apr 2008 13:33:11 +0200."
	<Pine.LNX.4.64.0804151330040.5159@axis700.grange>
Message-ID: <20080418075454.A8E32248AB@gemini.denx.de>

In message <Pine.LNX.4.64.0804151330040.5159 at axis700.grange> you wrote:
> Update MX31ADS default environment to better match the flash layout and 
> the memory map, support SPI and RTC.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
> 
> diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c

This doesn't apply at all:

Applying MX31ADS environment variable update, spi and rtc support
error: board/mx31ads/mx31ads.c: does not exist in index
error: include/configs/mx31ads.h: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
CONFLICT (delete/modify): board/mx31ads/mx31ads.c deleted in HEAD and
modified in MX31ADS environment variable update, spi and rtc support.
Version MX31ADS environment variable update, spi and rtc support of
board/mx31ads/mx31ads.c left in tree.
CONFLICT (delete/modify): include/configs/mx31ads.h deleted in HEAD
and modified in MX31ADS environment variable update, spi and rtc
support. Version MX31ADS environment variable update, spi and rtc
support of include/configs/mx31ads.h left in tree.
Failed to merge in the changes.
Patch failed at 0001.


Please fix and resubmit.

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: wd at denx.de
Alan Turing thought about criteria to settle the question of  whether
machines  can think, a question of which we now know that it is about
as relevant as the question of whether submarines can swim.
                                                   -- Edsger Dijkstra



From mk at denx.de  Fri Apr 18 10:13:48 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Fri, 18 Apr 2008 10:13:48 +0200
Subject: [U-Boot-Users] EHCI USB 2.0 Patch
In-Reply-To: <48076C4F.7090206@gmail.com> (Lance Ware's message of "Thu\,
	17 Apr 2008 11\:27\:11 -0400")
References: <48076C4F.7090206@gmail.com>
Message-ID: <87k5ivd1hf.fsf@denx.de>

Dear Lance,

Lance Ware <lancee.ware at gmail.com> writes:

> I wanted to know how could I get a hold of the USB 2.0 patch for 
> u-boot.  I am currently testing a OHCI/EHCI compliant pci usb device. I 
> have the OHCI part working but would like to have use of the EHCI part 
> of the device from the usb device.

You can easily find the EHCI patch in the archives. The reason I didn't
apply it so far was that the code is currently not used by anyone, but I
would be more than happy to change this.

One issue with this patch is that doesn't support companion controllers,
so you have to choose exclusively between EHCI or OHCI.

Best regards

Markus Klotzbuecher

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



From njayaswal at tataelxsi.co.in  Fri Apr 18 10:20:06 2008
From: njayaswal at tataelxsi.co.in (Neeraj Jayaswal)
Date: Fri, 18 Apr 2008 13:50:06 +0530
Subject: [U-Boot-Users] U-Boot : USB Slave Mode ?
In-Reply-To: <87skxjd27e.fsf@denx.de>
Message-ID: <003601c8a12d$02fd8af0$42053c0a@telxsi.com>

Sorry, will not be repeated again !!

Regards,
Neeraj

-----Original Message-----
From: Markus Klotzbucher [mailto:mk at denx.de]
Sent: Friday, April 18, 2008 1:28 PM
To: njayaswal at tataelxsi.co.in
Cc: 'Wolfgang Denk'; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] U-Boot : USB Slave Mode ?


Dear Neeraj,

Posting a similar message several times will get you ignored or
flamed. Don't do it.

"Neeraj Jayaswal" <njayaswal at tataelxsi.co.in> writes:

> Does U-Boot support USB Slave mode ?

Not out of the box, though IIRC this has been done before.

> I have an ARM926EJS board with USB-OTG. I can configure it in USB Slave
mode
> using some register settings.
> But I need to run U-Boot on top of it so that I can access the USB Slave
> functionality.
>
> Kindly suggest how I can use U-Boot in USB Slave mode and what
configuration
> changes are required ?

You will have to implement it. Can you help me understand why exactly
you would want such a feature in U-Boot?

> The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s) and
may contain proprietary, confidential or privileged information. If you are
not the intended recipient, you should not disseminate, distribute or copy
this e-mail. Please notify the sender immediately and destroy all copies of
this message and any attachments contained in it.
>
> Contact your Administrator for further information.

Please contact your administrator for further information on how to get
rid of this useless message.

Best regards

Markus Klotzbuecher

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


The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it.

Contact your Administrator for further information.




From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix crash on sequoia with cache
	enabled
In-Reply-To: Your message of "Thu, 17 Apr 2008 18:15:27 +0200."
	<1208448927-4803-1-git-send-email-agust@denx.de>
Message-ID: <20080418075454.C8F71248AB@gemini.denx.de>

In message <1208448927-4803-1-git-send-email-agust at denx.de> you wrote:
> Currently U-Boot crashes on sequoia board in CPU POST if
> cache is enabled (CONFIG_4xx_DCACHE defined). The cache
> won't be disabled by change_tlb before CPU POST because
> there is an insufficient adress range check since
> CFG_MEM_TOP_HIDE was introduced. This patch tries to fix
> this problem.
> 
> Signed-off-by: Anatolij Gustschin <agust at denx.de>
> ---
>  cpu/ppc4xx/tlb.c |    4 +++-
>  1 files changed, 3 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: wd at denx.de
If it went on at this rate, in several billion  years  he'd  be  rich
beyond his wildest dreams!            - Terry Pratchett, _Soul Music_



From andre.schwarz at matrix-vision.de  Fri Apr 18 10:48:51 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Fri, 18 Apr 2008 10:48:51 +0200
Subject: [U-Boot-Users] [PATCH] fix system config overwrite @ MPC834x
In-Reply-To: <20080417155615.43fa3791.kim.phillips@freescale.com>
References: <480788B1.9090208@matrix-vision.de>
	<20080417155615.43fa3791.kim.phillips@freescale.com>
Message-ID: <48086073.4060306@matrix-vision.de>

Kim,

doing a git-pull gives "Already up-to-date."
The patch is produced with "git-diff --patch-with-stat 
cpu/mpc83xx/cpu_init.c"

Am I doing anything wrong ?

Since all my patches have problems in getting applied there's obviously 
a problem on my side ...



regards,
Andre

Kim Phillips schrieb:
> On Thu, 17 Apr 2008 19:28:17 +0200
> Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:
>
>   
>> Kim,
>>
>>     
> Hello Andre,
>
> I can't apply this:
>
> Applying fix system config overwrite @ MPC834x
> error: patch failed: cpu/mpc83xx/cpu_init.c:59
> error: cpu/mpc83xx/cpu_init.c: patch does not apply
> Patch failed at 0001.
> When you have resolved this problem run "git-am --resolved".
> If you would prefer to skip this patch, instead run "git-am --skip".
>
>   
>> during 83xx setup the "System I/O configuration register high" gets 
>> overwritten
>> with user defined value if CFG_SICRH is defined.
>>
>> Regarding to the MPC834x manual (Table 5-28 reve.1) bits 28+29 of SICRH 
>> must keep
>> their reset value regardless of configuration.
>>
>> On my board (using RGMII) those bits are set after reset - yet it's 
>> unclear where they come from.
>>
>> The patch keeps both bits on MPC834x.
>>
>>
>> Cheers,
>> Andre
>>
>> Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
>> --
>>     
>
> fyi, commit message text you don't want applied in the tree history
> (such as "Kim," and "Cheers, Andre") goes here, below the '---' line.
>
>   
>>      /* System General Purpose Register */
>>  #ifdef CFG_SICRH
>> -    im->sysconf.sicrh = CFG_SICRH;
>> +#ifdef CONFIG_MPC834X
>> +    /* regarding to MPC34x manual rev.1 bits 28..29 must be preserved */
>> +    tmp_sicrh = im->sysconf.sicrh & 0x0000000C;
>> +#endif
>> +    im->sysconf.sicrh = CFG_SICRH | tmp_sicrh;
>>  #endif
>>     
>
> also, can you extend the ifdef to include CONFIG_MPC8313 in addition to
> the MPC834X?  That's the only other one that could use this fix.
>
> Thanks,
>
> Kim
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080418/d3ae38e5/attachment.htm 

From wd at denx.de  Fri Apr 18 09:54:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 18 Apr 2008 09:54:54 +0200
Subject: [U-Boot-Users] [PATCH] Fix crash on sequoia in ppc_4xx_eth_init
In-Reply-To: Your message of "Thu, 17 Apr 2008 18:18:00 +0200."
	<1208449080-4825-1-git-send-email-agust@denx.de>
Message-ID: <20080418075454.D8BF0248B9@gemini.denx.de>

In message <1208449080-4825-1-git-send-email-agust at denx.de> you wrote:
> Currently U-Boot crashes in ppc_4xx_eth_init on sequoia
> with cache enabled (TLB Parity exeption). This patch
> fixes the problem.
> 
> Signed-off-by: Anatolij Gustschin <agust at denx.de>
> ---
>  cpu/ppc4xx/4xx_enet.c |    4 ++++
>  1 files changed, 4 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: wd at denx.de
The further the spiritual evolution of  mankind  advances,  the  more
certain  it seems to me that the path to genuine religiosity does not
lie through the fear of life, and the fear of death, and blind faith,
but through striving after rational knowledge.      - Albert Einstein



From lg at denx.de  Fri Apr 18 11:28:59 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Fri, 18 Apr 2008 11:28:59 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH 3/3] MX31ADS environment variable update,
 spi and rtc support
In-Reply-To: <20080418075454.A8E32248AB@gemini.denx.de>
References: <20080418075454.A8E32248AB@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804181125170.5725@axis700.grange>

On Fri, 18 Apr 2008, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0804151330040.5159 at axis700.grange> you wrote:
> > Update MX31ADS default environment to better match the flash layout and 
> > the memory map, support SPI and RTC.
> > 
> > Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> > 
> > ---
> > 
> > diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c
> 
> This doesn't apply at all:
> 
> Applying MX31ADS environment variable update, spi and rtc support
> error: board/mx31ads/mx31ads.c: does not exist in index
> error: include/configs/mx31ads.h: does not exist in index

Wolfgang, please excuse me if I am missing something obvious. But the 
above two errors seem to suggest, that the basis mx31ads patch is missing 
in this tree. And an "MX31ADS ... update" shall certainly be applied on 
the top of that one. To be precise, this is what should be applied first:

[PATCH v3 7/7] Support for the MX31ADS evaluation board from Freescale

Could you please verify that it has indeed been applied to your tree?...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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



From tur at semihalf.com  Fri Apr 18 11:56:17 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Fri, 18 Apr 2008 11:56:17 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix PPC440 build breakage due to
	missing	dcache_enable symbol
Message-ID: <20080418095616.18864.23500.stgit@pollux.denx.de>

Recent commit a4986459 adds reference to dcache_enable, thus breaking the
build on PPC440. This patch adds a stub for dcache_enable, similarly to
what's being done for other cache operations.

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 cpu/ppc4xx/cache.S |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/cpu/ppc4xx/cache.S b/cpu/ppc4xx/cache.S
index 5124dec..ceb3ec0 100644
--- a/cpu/ppc4xx/cache.S
+++ b/cpu/ppc4xx/cache.S
@@ -166,9 +166,11 @@ _GLOBAL(invalidate_dcache)
 #ifdef CONFIG_440
 
        .globl  dcache_disable
+       .globl  dcache_enable
        .globl  icache_disable
        .globl  icache_enable
 dcache_disable:
+dcache_enable:
 icache_disable:
 icache_enable:
 	blr




From tur at semihalf.com  Fri Apr 18 12:15:07 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Fri, 18 Apr 2008 12:15:07 +0200
Subject: [U-Boot-Users] [PATCH v2] ppc4xx: Fix PPC440 build breakage due to
	missing	dcache_enable symbol
In-Reply-To: <20080418095616.18864.23500.stgit@pollux.denx.de>
References: <20080418095616.18864.23500.stgit@pollux.denx.de>
Message-ID: <20080418101306.469.90871.stgit@pollux.denx.de>

Recent commit 017e9b79 adds reference to dcache_enable, thus breaking the
build on PPC440. This patch adds a stub for dcache_enable, similarly to
what's being done for other cache operations.

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---
Fixed an off-by-one error in the commit id -- it should be 017e9b79
instead of a4986459.

 cpu/ppc4xx/cache.S |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/cpu/ppc4xx/cache.S b/cpu/ppc4xx/cache.S
index 5124dec..ceb3ec0 100644
--- a/cpu/ppc4xx/cache.S
+++ b/cpu/ppc4xx/cache.S
@@ -166,9 +166,11 @@ _GLOBAL(invalidate_dcache)
 #ifdef CONFIG_440
 
        .globl  dcache_disable
+       .globl  dcache_enable
        .globl  icache_disable
        .globl  icache_enable
 dcache_disable:
+dcache_enable:
 icache_disable:
 icache_enable:
 	blr




From tur at semihalf.com  Fri Apr 18 12:39:23 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Fri, 18 Apr 2008 12:39:23 +0200
Subject: [U-Boot-Users] [PATCH v2] Memory footprint optimizations
In-Reply-To: <20080414195049.F1CE9248A0@gemini.denx.de>
References: <20080414195049.F1CE9248A0@gemini.denx.de>
Message-ID: <20080418103903.9139.17257.stgit@pollux.denx.de>

As suggested by Wolfgang Denk:
- image printing functions:
  - remove wrappers
  - remove indentation prefix from functions' signatures
- merge getenv_verify and getenv_autostart into one parametrized function

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 board/siemens/common/fpga.c |    2 +-
 common/cmd_autoscript.c     |    2 +-
 common/cmd_bootm.c          |    4 ++-
 common/cmd_ximg.c           |    2 +-
 common/image.c              |   56 ++++++++++++++++++-------------------------
 include/image.h             |    9 ++-----
 tools/mkimage.c             |    6 ++---
 7 files changed, 34 insertions(+), 47 deletions(-)

diff --git a/board/siemens/common/fpga.c b/board/siemens/common/fpga.c
index 48c1850..ac0022e 100644
--- a/board/siemens/common/fpga.c
+++ b/board/siemens/common/fpga.c
@@ -160,7 +160,7 @@ static int fpga_load (fpga_t* fpga, ulong addr, int checkall)
     data = (uchar*)image_get_data (hdr);
     len  = image_get_data_size (hdr);
 
-    verify = getenv_verify ();
+    verify = getenv_yesno ("verify");
     if (verify) {
 	if (!image_check_dcrc (hdr)) {
 	    strcpy (msg, "Bad Image Data CRC");
diff --git a/common/cmd_autoscript.c b/common/cmd_autoscript.c
index 1a37b90..932f638 100644
--- a/common/cmd_autoscript.c
+++ b/common/cmd_autoscript.c
@@ -65,7 +65,7 @@ autoscript (ulong addr, const char *fit_uname)
 	size_t		fit_len;
 #endif
 
-	verify = getenv_verify ();
+	verify = getenv_yesno ("verify");
 
 	switch (genimg_get_format ((void *)addr)) {
 	case IMAGE_FORMAT_LEGACY:
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 3a0c83d..0722641 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -133,8 +133,8 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 	struct lmb lmb;
 
 	memset ((void *)&images, 0, sizeof (images));
-	images.verify = getenv_verify();
-	images.autostart = getenv_autostart();
+	images.verify = getenv_yesno ("verify");
+	images.autostart = getenv_yesno ("autostart");
 	images.lmb = &lmb;
 
 	lmb_init(&lmb);
diff --git a/common/cmd_ximg.c b/common/cmd_ximg.c
index 7916fc1..2753389 100644
--- a/common/cmd_ximg.c
+++ b/common/cmd_ximg.c
@@ -51,7 +51,7 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 	size_t		fit_len;
 #endif
 
-	verify = getenv_verify ();
+	verify = getenv_yesno ("verify");
 
 	if (argc > 1) {
 		addr = simple_strtoul(argv[1], NULL, 16);
diff --git a/common/image.c b/common/image.c
index d218f2f..9b1108f 100644
--- a/common/image.c
+++ b/common/image.c
@@ -316,19 +316,27 @@ static void image_print_type (image_header_t *hdr)
 }
 
 /**
- * __image_print_contents - prints out the contents of the legacy format image
+ * image_print_contents - prints out the contents of the legacy format image
  * @hdr: pointer to the legacy format image header
  * @p: pointer to prefix string
  *
- * __image_print_contents() formats a multi line legacy image contents description.
+ * image_print_contents() formats a multi line legacy image contents description.
  * The routine prints out all header fields followed by the size/offset data
  * for MULTI/SCRIPT images.
  *
  * returns:
  *     no returned results
  */
-static void __image_print_contents (image_header_t *hdr, const char *p)
+void image_print_contents (image_header_t *hdr)
 {
+	const char *p;
+
+#ifdef USE_HOSTCC
+	p = "";
+#else
+	p = "   ";
+#endif
+
 	printf ("%sImage Name:   %.*s\n", p, IH_NMLEN, image_get_name (hdr));
 #if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) || defined(USE_HOSTCC)
 	printf ("%sCreated:      ", p);
@@ -366,15 +374,6 @@ static void __image_print_contents (image_header_t *hdr, const char *p)
 	}
 }
 
-inline void image_print_contents (image_header_t *hdr)
-{
-	__image_print_contents (hdr, "   ");
-}
-
-inline void image_print_contents_noindent (image_header_t *hdr)
-{
-	__image_print_contents (hdr, "");
-}
 
 #ifndef USE_HOSTCC
 /**
@@ -444,15 +443,9 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 /* Shared dual-format routines */
 /*****************************************************************************/
 #ifndef USE_HOSTCC
-int getenv_verify (void)
-{
-	char *s = getenv ("verify");
-	return (s && (*s == 'n')) ? 0 : 1;
-}
-
-int getenv_autostart (void)
+int getenv_yesno (char *var)
 {
-	char *s = getenv ("autostart");
+	char *s = getenv (var);
 	return (s && (*s == 'n')) ? 0 : 1;
 }
 
@@ -1265,18 +1258,18 @@ static void fit_get_debug (const void *fit, int noffset,
 }
 
 /**
- * __fit_print_contents - prints out the contents of the FIT format image
+ * fit_print_contents - prints out the contents of the FIT format image
  * @fit: pointer to the FIT format image header
  * @p: pointer to prefix string
  *
- * __fit_print_contents() formats a multi line FIT image contents description.
+ * fit_print_contents() formats a multi line FIT image contents description.
  * The routine prints out FIT image properties (root node level) follwed by
  * the details of each component image.
  *
  * returns:
  *     no returned results
  */
-static void __fit_print_contents (const void *fit, const char *p)
+void fit_print_contents (const void *fit)
 {
 	char *desc;
 	char *uname;
@@ -1286,10 +1279,17 @@ static void __fit_print_contents (const void *fit, const char *p)
 	int ndepth;
 	int count = 0;
 	int ret;
+	const char *p;
 #if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) || defined(USE_HOSTCC)
 	time_t timestamp;
 #endif
 
+#ifdef USE_HOSTCC
+	p = "";
+#else
+	p = "   ";
+#endif
+
 	/* Root node properties */
 	ret = fit_get_desc (fit, 0, &desc);
 	printf ("%sFIT description: ", p);
@@ -1361,16 +1361,6 @@ static void __fit_print_contents (const void *fit, const char *p)
 	}
 }
 
-inline void fit_print_contents (const void *fit)
-{
-	__fit_print_contents (fit, "   ");
-}
-
-inline void fit_print_contents_noindent (const void *fit)
-{
-	__fit_print_contents (fit, "");
-}
-
 /**
  * fit_image_print - prints out the FIT component image details
  * @fit: pointer to the FIT format image header
diff --git a/include/image.h b/include/image.h
index 60fdb2b..4076484 100644
--- a/include/image.h
+++ b/include/image.h
@@ -364,8 +364,7 @@ int image_check_hcrc (image_header_t *hdr);
 int image_check_dcrc (image_header_t *hdr);
 #ifndef USE_HOSTCC
 int image_check_dcrc_wd (image_header_t *hdr, ulong chunksize);
-int getenv_verify (void);
-int getenv_autostart (void);
+int getenv_yesno (char *var);
 ulong getenv_bootm_low(void);
 ulong getenv_bootm_size(void);
 void memmove_wd (void *to, void *from, size_t len, ulong chunksz);
@@ -392,8 +391,7 @@ ulong image_multi_count (image_header_t *hdr);
 void image_multi_getimg (image_header_t *hdr, ulong idx,
 			ulong *data, ulong *len);
 
-inline void image_print_contents (image_header_t *hdr);
-inline void image_print_contents_noindent (image_header_t *hdr);
+void image_print_contents (image_header_t *hdr);
 
 #ifndef USE_HOSTCC
 static inline int image_check_target_arch (image_header_t *hdr)
@@ -469,8 +467,7 @@ inline int fit_parse_conf (const char *spec, ulong addr_curr,
 inline int fit_parse_subimage (const char *spec, ulong addr_curr,
 		ulong *addr, const char **image_name);
 
-inline void fit_print_contents (const void *fit);
-inline void fit_print_contents_noindent (const void *fit);
+void fit_print_contents (const void *fit);
 void fit_image_print (const void *fit, int noffset, const char *p);
 void fit_image_print_hash (const void *fit, int noffset, const char *p);
 
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 6e1ff2b..ea7a826 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -229,10 +229,10 @@ NXTARG:		;
 		if (fdt_check_header (ptr)) {
 			/* old-style image */
 			image_verify_header ((char *)ptr, sbuf.st_size);
-			image_print_contents_noindent ((image_header_t *)ptr);
+			image_print_contents ((image_header_t *)ptr);
 		} else {
 			/* FIT image */
-			fit_print_contents_noindent (ptr);
+			fit_print_contents (ptr);
 		}
 
 		(void) munmap((void *)ptr, sbuf.st_size);
@@ -363,7 +363,7 @@ NXTARG:		;
 
 	image_set_hcrc (hdr, checksum);
 
-	image_print_contents_noindent (hdr);
+	image_print_contents (hdr);
 
 	(void) munmap((void *)ptr, sbuf.st_size);
 




From iuqnierp at 2.mol.bio.msu.ru  Fri Apr 18 12:59:36 2008
From: iuqnierp at 2.mol.bio.msu.ru (acevez)
Date: Fri, 18 Apr 2008 12:59:36 +0200
Subject: [U-Boot-Users] Your bazooka will explode her
Message-ID: <DAFD088F.6%iuqnierp@2.mol.bio.msu.ru>

Your make device will make her jaw drop http://www.oeiriueeb.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080418/9989199a/attachment.htm 

From uboot_user at yahoo.com  Fri Apr 18 13:13:03 2008
From: uboot_user at yahoo.com (U-Boot User)
Date: Fri, 18 Apr 2008 04:13:03 -0700 (PDT)
Subject: [U-Boot-Users] I need Help in U-Boot Interrupt support
Message-ID: <616554.79311.qm@web45709.mail.sp1.yahoo.com>

An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080418/222a4c70/attachment.htm 

From andre.schwarz at matrix-vision.de  Fri Apr 18 13:20:06 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Fri, 18 Apr 2008 13:20:06 +0200
Subject: [U-Boot-Users] PCI stopped working on MPC8343
Message-ID: <480883E6.5000304@matrix-vision.de>

Last week my PCI bus has been running fine showing all devices.
Right now no devices are shown on the bus.

I'm using CONFIG_83XX_GENERIC_PCI with common setup code for PCI.

Nothing changed from my side during the last 2 weeks.


Did I miss any changes in u-boot ?


regards,
Andre Schwarz
Matrix Vision



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From emoserob2000 at HJMALONE.COM  Fri Apr 18 14:28:16 2008
From: emoserob2000 at HJMALONE.COM (krafft)
Date: Fri, 18 Apr 2008 08:28:16 -0400
Subject: [U-Boot-Users] Increase your instrument size
Message-ID: <A7280BC8.C%emoserob2000@HJMALONE.COM>

Be true to yourself, get your manhood what he needs today, dont wait any longer. http://www.nuueitao.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080418/462a3178/attachment.htm 

From zhukov at tst.spb.su  Fri Apr 18 14:39:14 2008
From: zhukov at tst.spb.su (Zhukov)
Date: Fri, 18 Apr 2008 16:39:14 +0400
Subject: [U-Boot-Users] --- NAND for AT91RM9200
Message-ID: <15211966187.20080418163914@tst.spb.su>

Hello, people!

    For ARM at91rm9200, I turn on NAND support. Now any request to address
    0x40000000 hangs the u-boot while loading. (This happens on calling
    "NanD_Command" within function "NanD_IdentChip" within cmd_nand.c).
    U-boot hangs both with and without Nand chip plugged.

    It looks like something wrong with SMC or EBI, but I didn't see
    anything suspicious in those registers.

    Please help, experienced one!

Best regards,
Andrew




From sr at denx.de  Fri Apr 18 15:26:04 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 15:26:04 +0200
Subject: [U-Boot-Users] [PATCH] nand_spl: Update nand_spl to support 2k
	page size NAND devices
In-Reply-To: <20080418041414.0EB7D248A0@gemini.denx.de>
References: <20080418041414.0EB7D248A0@gemini.denx.de>
Message-ID: <200804181526.04340.sr@denx.de>

On Friday 18 April 2008, Wolfgang Denk wrote:
> In message <1207643460-22199-1-git-send-email-sr at denx.de> you wrote:
> > This patch adds support for booting from 2k page sized NAND device
> > (e.g. Micron 29F2G08AAC).
>
> Will you submit a pull request for the NAND repo, then, please?

Yes, in a short while.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 18 15:32:24 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 15:32:24 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Canyonlands default
	environment to work with new image support
In-Reply-To: <20080418041414.4F3F5248A0@gemini.denx.de>
References: <20080418041414.4F3F5248A0@gemini.denx.de>
Message-ID: <200804181532.24641.sr@denx.de>

On Friday 18 April 2008, Wolfgang Denk wrote:
> In message <1207738620-23994-1-git-send-email-sr at denx.de> you wrote:
> > Since the new image support checks for image overwriting, the default
> > environment needs to get adjusted to use correct addresses.
>
> ...
>
> > -	"nupdate=nand erase 0 60000;nand write 200000 0 60000;"		\
> > +	"nupdate=nand erase 0 100000;nand write 200000 0 100000;"	\
>
> Does "nand write" support the "+${filesize}" notation (yet)?

I don't think so.

> If not, how about adding it?

Yes, would be great. Patches welcome. :)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From Joakim.Tjernlund at transmode.se  Fri Apr 18 15:57:01 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Fri, 18 Apr 2008 15:57:01 +0200
Subject: [U-Boot-Users] [PATCH] fw_printenv: Add -v and -q options.
Message-ID: <1208527021-16460-1-git-send-email-Joakim.Tjernlund@transmode.se>

Add -v for verbose output, "Unlocking flash...", "Done" etc.
Add -q for quiet operation, do not print error and verbose
messages.
Add a --help(-help, -?) option too.

The -q option is intended for scripting.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund at transmode.se>
---

I hope this patch can be merge now as fw_printenv/fw_setenv is
only a demo applikation.

 tools/env/fw_env.c      |  189 +++++++++++++++++++++++++++--------------------
 tools/env/fw_env.h      |   16 +++-
 tools/env/fw_env_main.c |   43 ++++++++---
 3 files changed, 153 insertions(+), 95 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index e083a5b..07872b4 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -26,6 +26,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <stddef.h>
+#include <stdarg.h>
 #include <string.h>
 #include <sys/types.h>
 #include <sys/ioctl.h>
@@ -53,6 +54,8 @@ typedef struct envdev_s {
 
 static envdev_t envdevices[2];
 static int curdev;
+static int fw_quiet = 0;
+static int fw_verbose = 0;
 
 #define DEVNAME(i)    envdevices[(i)].devname
 #define DEVOFFSET(i)  envdevices[(i)].devoff
@@ -164,6 +167,43 @@ static char *envmatch (char * s1, char * s2);
 static int env_init (void);
 static int parse_config (void);
 
+int check_option(int *argc, char *argv[], const char *option)
+{
+	int i,j;
+
+	for (i = 1; i < *argc; i++)
+		if (strcmp (argv[i], option) == 0) {
+			for (j=i; j < *argc; j++)
+				argv[j] = argv[j+1]; /* remove option */
+			*argc -= 1;
+			return 1;
+		}
+	return 0;
+}
+
+void check_quiet(int *argc, char *argv[])
+{
+	if (check_option(argc, argv, "-q"))
+		fw_quiet = 1;
+}
+
+void check_verbose(int *argc, char *argv[])
+{
+	if (check_option(argc, argv, "-v"))
+		fw_verbose = 1;
+}
+
+void fw_print(const char *fmt, ...)
+{
+	va_list ap;
+
+	if (fw_quiet)
+		return;
+	va_start(ap, fmt);
+	vfprintf(stderr, fmt, ap);
+	va_end(ap);
+}
+
 #if defined(CONFIG_FILE)
 static int get_config (char *);
 #endif
@@ -192,8 +232,8 @@ char *fw_getenv (char *name)
 
 		for (nxt = env; *nxt; ++nxt) {
 			if (nxt >= &environment.data[ENV_SIZE]) {
-				fprintf (stderr, "## Error: "
-					"environment not terminated\n");
+				fw_print("## Error: "
+					 "environment not terminated\n");
 				return (NULL);
 			}
 		}
@@ -221,8 +261,8 @@ void fw_printenv (int argc, char *argv[])
 		for (env = environment.data; *env; env = nxt + 1) {
 			for (nxt = env; *nxt; ++nxt) {
 				if (nxt >= &environment.data[ENV_SIZE]) {
-					fprintf (stderr, "## Error: "
-						"environment not terminated\n");
+					fw_print("## Error: "
+						 "environment not terminated\n");
 					return;
 				}
 			}
@@ -232,13 +272,11 @@ void fw_printenv (int argc, char *argv[])
 		return;
 	}
 
-	if (strcmp (argv[1], "-n") == 0) {
+	if (check_option(&argc, argv, "-n")) {
 		n_flag = 1;
-		++argv;
-		--argc;
 		if (argc != 2) {
-			fprintf (stderr, "## Error: "
-				"`-n' option requires exactly one argument\n");
+			fw_print("## Error: "
+				 "`-n' option requires exactly one argument\n");
 			return;
 		}
 	} else {
@@ -253,8 +291,8 @@ void fw_printenv (int argc, char *argv[])
 
 			for (nxt = env; *nxt; ++nxt) {
 				if (nxt >= &environment.data[ENV_SIZE]) {
-					fprintf (stderr, "## Error: "
-						"environment not terminated\n");
+					fw_print("## Error: "
+						 "environment not terminated\n");
 					return;
 				}
 			}
@@ -269,7 +307,7 @@ void fw_printenv (int argc, char *argv[])
 			}
 		}
 		if (!val)
-			fprintf (stderr, "## Error: \"%s\" not defined\n", name);
+			fw_print("## Error: \"%s\" not defined\n", name);
 	}
 }
 
@@ -303,8 +341,8 @@ int fw_setenv (int argc, char *argv[])
 	for (nxt = env = environment.data; *env; env = nxt + 1) {
 		for (nxt = env; *nxt; ++nxt) {
 			if (nxt >= &environment.data[ENV_SIZE]) {
-				fprintf (stderr, "## Error: "
-					"environment not terminated\n");
+				fw_print("## Error: "
+					 "environment not terminated\n");
 				return (EINVAL);
 			}
 		}
@@ -321,7 +359,7 @@ int fw_setenv (int argc, char *argv[])
 		 */
 		if ((strcmp (name, "ethaddr") == 0) ||
 			(strcmp (name, "serial#") == 0)) {
-			fprintf (stderr, "Can't overwrite \"%s\"\n", name);
+			fw_print("Can't overwrite \"%s\"\n", name);
 			return (EROFS);
 		}
 
@@ -358,7 +396,7 @@ int fw_setenv (int argc, char *argv[])
 		len += strlen (argv[i]) + 1;
 	}
 	if (len > (&environment.data[ENV_SIZE] - env)) {
-		fprintf (stderr,
+		fw_print(
 			"Error: environment overflow, \"%s\" deleted\n",
 			name);
 		return (-1);
@@ -382,7 +420,7 @@ int fw_setenv (int argc, char *argv[])
 
 	/* write environment back to flash */
 	if (flash_io (O_RDWR)) {
-		fprintf (stderr, "Error: can't write fw_env to flash\n");
+		fw_print("Error: can't write fw_env to flash\n");
 		return (-1);
 	}
 
@@ -396,7 +434,7 @@ static int flash_io (int mode)
 	char *data = NULL;
 
 	if ((fd = open (DEVNAME (curdev), mode)) < 0) {
-		fprintf (stderr,
+		fw_print(
 			"Can't open %s: %s\n",
 			DEVNAME (curdev), strerror (errno));
 		return (-1);
@@ -412,7 +450,7 @@ static int flash_io (int mode)
 			/* switch to next partition for writing */
 			otherdev = !curdev;
 			if ((fdr = open (DEVNAME (otherdev), mode)) < 0) {
-				fprintf (stderr,
+				fw_print(
 					"Can't open %s: %s\n",
 					DEVNAME (otherdev),
 					strerror (errno));
@@ -422,7 +460,8 @@ static int flash_io (int mode)
 			otherdev = curdev;
 			fdr = fd;
 		}
-		printf ("Unlocking flash...\n");
+		if (fw_verbose)
+			fw_print("Unlocking flash...\n");
 		erase.length = DEVESIZE (otherdev);
 		erase.start = DEVOFFSET (otherdev);
 		ioctl (fdr, MEMUNLOCK, &erase);
@@ -434,11 +473,12 @@ static int flash_io (int mode)
 			environment.flags = active_flag;
 		}
 
-		printf ("Done\n");
+		if (fw_verbose)
+			fw_print("Done\n");
 		resid = DEVESIZE (otherdev) - CFG_ENV_SIZE;
 		if (resid) {
 			if ((data = malloc (resid)) == NULL) {
-				fprintf (stderr,
+				fw_print(
 					"Cannot malloc %d bytes: %s\n",
 					resid,
 					strerror (errno));
@@ -446,13 +486,13 @@ static int flash_io (int mode)
 			}
 			if (lseek (fdr, DEVOFFSET (otherdev) + CFG_ENV_SIZE, SEEK_SET)
 				== -1) {
-				fprintf (stderr, "seek error on %s: %s\n",
+				fw_print("seek error on %s: %s\n",
 					DEVNAME (otherdev),
 					strerror (errno));
 				return (-1);
 			}
 			if ((rc = read (fdr, data, resid)) != resid) {
-				fprintf (stderr,
+				fw_print(
 					"read error on %s: %s\n",
 					DEVNAME (otherdev),
 					strerror (errno));
@@ -460,43 +500,42 @@ static int flash_io (int mode)
 			}
 		}
 
-		printf ("Erasing old environment...\n");
+		if (fw_verbose)
+			fw_print("Erasing old environment...\n");
 
 		erase.length = DEVESIZE (otherdev);
 		erase.start = DEVOFFSET (otherdev);
 		if (ioctl (fdr, MEMERASE, &erase) != 0) {
-			fprintf (stderr, "MTD erase error on %s: %s\n",
+			fw_print("MTD erase error on %s: %s\n",
 				DEVNAME (otherdev),
 				strerror (errno));
 			return (-1);
 		}
 
-		printf ("Done\n");
+		if (fw_verbose)
+			fw_print("Done\n");
 
-		printf ("Writing environment to %s...\n", DEVNAME (otherdev));
+		if (fw_verbose)
+			fw_print("Writing environment to %s...\n", DEVNAME (otherdev));
 		if (lseek (fdr, DEVOFFSET (otherdev), SEEK_SET) == -1) {
-			fprintf (stderr,
-				"seek error on %s: %s\n",
-				DEVNAME (otherdev), strerror (errno));
+			fw_print("seek error on %s: %s\n",
+				 DEVNAME (otherdev), strerror (errno));
 			return (-1);
 		}
 		if (write (fdr, &environment, len) != len) {
-			fprintf (stderr,
-				"CRC write error on %s: %s\n",
-				DEVNAME (otherdev), strerror (errno));
+			fw_print("CRC write error on %s: %s\n",
+				 DEVNAME (otherdev), strerror (errno));
 			return (-1);
 		}
 		if (write (fdr, environment.data, ENV_SIZE) != ENV_SIZE) {
-			fprintf (stderr,
-				"Write error on %s: %s\n",
-				DEVNAME (otherdev), strerror (errno));
+			fw_print("Write error on %s: %s\n",
+				 DEVNAME (otherdev), strerror (errno));
 			return (-1);
 		}
 		if (resid) {
 			if (write (fdr, data, resid) != resid) {
-				fprintf (stderr,
-					"write error on %s: %s\n",
-					DEVNAME (curdev), strerror (errno));
+				fw_print("write error on %s: %s\n",
+					 DEVNAME (curdev), strerror (errno));
 				return (-1);
 			}
 			free (data);
@@ -505,20 +544,21 @@ static int flash_io (int mode)
 			/* change flag on current active env partition */
 			if (lseek (fd, DEVOFFSET (curdev) + sizeof (ulong), SEEK_SET)
 				== -1) {
-				fprintf (stderr, "seek error on %s: %s\n",
-					DEVNAME (curdev), strerror (errno));
+				fw_print("seek error on %s: %s\n",
+					 DEVNAME (curdev), strerror (errno));
 				return (-1);
 			}
 			if (write (fd, &obsolete_flag, sizeof (obsolete_flag)) !=
 				sizeof (obsolete_flag)) {
-				fprintf (stderr,
-					"Write error on %s: %s\n",
-					DEVNAME (curdev), strerror (errno));
+				fw_print("Write error on %s: %s\n",
+					  DEVNAME (curdev), strerror (errno));
 				return (-1);
 			}
 		}
-		printf ("Done\n");
-		printf ("Locking ...\n");
+		if (fw_verbose)
+			fw_print("Done\n");
+		if (fw_verbose)
+			fw_print("Locking ...\n");
 		erase.length = DEVESIZE (otherdev);
 		erase.start = DEVOFFSET (otherdev);
 		ioctl (fdr, MEMLOCK, &erase);
@@ -527,40 +567,36 @@ static int flash_io (int mode)
 			erase.start = DEVOFFSET (curdev);
 			ioctl (fd, MEMLOCK, &erase);
 			if (close (fdr)) {
-				fprintf (stderr,
-					"I/O error on %s: %s\n",
+				fw_print("I/O error on %s: %s\n",
 					DEVNAME (otherdev),
 					strerror (errno));
 				return (-1);
 			}
 		}
-		printf ("Done\n");
+		if (fw_verbose)
+			fw_print("Done\n");
 	} else {
 
 		if (lseek (fd, DEVOFFSET (curdev), SEEK_SET) == -1) {
-			fprintf (stderr,
-				"seek error on %s: %s\n",
-				DEVNAME (curdev), strerror (errno));
+			fw_print("seek error on %s: %s\n",
+				 DEVNAME (curdev), strerror (errno));
 			return (-1);
 		}
 		if (read (fd, &environment, len) != len) {
-			fprintf (stderr,
-				"CRC read error on %s: %s\n",
-				DEVNAME (curdev), strerror (errno));
+			fw_print("CRC read error on %s: %s\n",
+				 DEVNAME (curdev), strerror (errno));
 			return (-1);
 		}
 		if ((rc = read (fd, environment.data, ENV_SIZE)) != ENV_SIZE) {
-			fprintf (stderr,
-				"Read error on %s: %s\n",
-				DEVNAME (curdev), strerror (errno));
+			fw_print("Read error on %s: %s\n",
+				 DEVNAME (curdev), strerror (errno));
 			return (-1);
 		}
 	}
 
 	if (close (fd)) {
-		fprintf (stderr,
-			"I/O error on %s: %s\n",
-			DEVNAME (curdev), strerror (errno));
+		fw_print("I/O error on %s: %s\n",
+			 DEVNAME (curdev), strerror (errno));
 		return (-1);
 	}
 
@@ -600,9 +636,8 @@ static int env_init (void)
 		return 1;
 
 	if ((addr1 = calloc (1, ENV_SIZE)) == NULL) {
-		fprintf (stderr,
-			"Not enough memory for environment (%ld bytes)\n",
-			ENV_SIZE);
+		fw_print("Not enough memory for environment (%ld bytes)\n",
+			 ENV_SIZE);
 		return (errno);
 	}
 
@@ -617,8 +652,7 @@ static int env_init (void)
 			   == environment.crc);
 	if (!HaveRedundEnv) {
 		if (!crc1_ok) {
-			fprintf (stderr,
-				"Warning: Bad CRC, using default environment\n");
+			fw_print("Warning: Bad CRC, using default environment\n");
 			memcpy(environment.data, default_environment, sizeof default_environment);
 		}
 	} else {
@@ -626,9 +660,8 @@ static int env_init (void)
 
 		curdev = 1;
 		if ((addr2 = calloc (1, ENV_SIZE)) == NULL) {
-			fprintf (stderr,
-				"Not enough memory for environment (%ld bytes)\n",
-				ENV_SIZE);
+			fw_print("Not enough memory for environment (%ld bytes)\n",
+				 ENV_SIZE);
 			return (errno);
 		}
 		environment.data = addr2;
@@ -654,8 +687,7 @@ static int env_init (void)
 			curdev = 1;
 			free (addr1);
 		} else if (!crc1_ok && !crc2_ok) {
-			fprintf (stderr,
-				"Warning: Bad CRC, using default environment\n");
+			fw_print("Warning: Bad CRC, using default environment\n");
 			memcpy(environment.data, default_environment, sizeof default_environment);
 			curdev = 0;
 			free (addr1);
@@ -702,8 +734,7 @@ static int parse_config ()
 #if defined(CONFIG_FILE)
 	/* Fills in DEVNAME(), ENVSIZE(), DEVESIZE(). Or don't. */
 	if (get_config (CONFIG_FILE)) {
-		fprintf (stderr,
-			"Cannot parse config file: %s\n", strerror (errno));
+		fw_print("Cannot parse config file: %s\n", strerror (errno));
 		return 1;
 	}
 #else
@@ -720,16 +751,14 @@ static int parse_config ()
 #endif
 #endif
 	if (stat (DEVNAME (0), &st)) {
-		fprintf (stderr,
-			"Cannot access MTD device %s: %s\n",
-			DEVNAME (0), strerror (errno));
+		fw_print("Cannot access MTD device %s: %s\n",
+			 DEVNAME (0), strerror (errno));
 		return 1;
 	}
 
 	if (HaveRedundEnv && stat (DEVNAME (1), &st)) {
-		fprintf (stderr,
-			"Cannot access MTD device %s: %s\n",
-			DEVNAME (1), strerror (errno));
+		fw_print("Cannot access MTD device %s: %s\n",
+			 DEVNAME (1), strerror (errno));
 		return 1;
 	}
 	return 0;
diff --git a/tools/env/fw_env.h b/tools/env/fw_env.h
index 58607de..bde6e75 100644
--- a/tools/env/fw_env.h
+++ b/tools/env/fw_env.h
@@ -27,17 +27,18 @@
  * See included "fw_env.config" sample file (TRAB board)
  * for notes on configuration.
  */
-#define CONFIG_FILE     "/etc/fw_env.config"
+
+/* #define CONFIG_FILE     "/etc/fw_env.config" */
 
 #define HAVE_REDUND /* For systems with 2 env sectors */
 #define DEVICE1_NAME      "/dev/mtd1"
 #define DEVICE2_NAME      "/dev/mtd2"
 #define DEVICE1_OFFSET    0x0000
-#define ENV1_SIZE         0x4000
-#define DEVICE1_ESIZE     0x4000
+#define ENV1_SIZE         0x2000
+#define DEVICE1_ESIZE     (32*1024) /* 32 KB */
 #define DEVICE2_OFFSET    0x0000
-#define ENV2_SIZE         0x4000
-#define DEVICE2_ESIZE     0x4000
+#define ENV2_SIZE         0x2000
+#define DEVICE2_ESIZE     (32*1024) /* 32 KB */
 
 #define CONFIG_BAUDRATE		115200
 #define CONFIG_BOOTDELAY	5	/* autoboot after 5 seconds	*/
@@ -51,4 +52,9 @@ extern void  fw_printenv(int argc, char *argv[]);
 extern char *fw_getenv  (char *name);
 extern int fw_setenv  (int argc, char *argv[]);
 
+extern int  check_option(int *argc, char *argv[], const char *option);
+extern void check_quiet(int *argc, char *argv[]);
+extern void check_verbose(int *argc, char *argv[]);
+extern void fw_print(const char *fmt, ...);
+
 extern unsigned	long  crc32	 (unsigned long, const unsigned char *, unsigned);
diff --git a/tools/env/fw_env_main.c b/tools/env/fw_env_main.c
index 696e30e..91776ea 100644
--- a/tools/env/fw_env_main.c
+++ b/tools/env/fw_env_main.c
@@ -51,28 +51,51 @@ main(int argc, char *argv[])
 {
 	char *p;
 	char *cmdname = *argv;
+	int help;
 
 	if ((p = strrchr (cmdname, '/')) != NULL) {
 		cmdname = p + 1;
 	}
+	help = check_option(&argc, argv, "--help");
+	help |= check_option(&argc, argv, "-help");
+	help |= check_option(&argc, argv, "-?");
+	check_quiet(&argc, argv); /* checks for -q */
+	check_verbose(&argc, argv); /* checks for -v */
 
 	if (strcmp(cmdname, CMD_PRINTENV) == 0) {
-
-			fw_printenv (argc, argv);
-
+		if (help) {
+			printf("Usage: "CMD_PRINTENV" "
+			       "-q -v -n [name...]\n\n"
+			       "Print firmware environment variables\n\n"
+			       "Options:\n"
+			       "-q - quiet, do not print error messages\n"
+			       "-v - verbose\n"
+			       "-n - print only value\n");
 			return (EXIT_SUCCESS);
+		}
+
+		fw_printenv (argc, argv);
+		return (EXIT_SUCCESS);
 
 	} else if (strcmp(cmdname, CMD_SETENV) == 0) {
+		if (help) {
+			printf("Usage: "CMD_SETENV" "
+			       "-q -v  name [value]\n\n"
+			       "Set/Unset firmware environment variable\n\n"
+			       "Options:\n"
+			       "-q - quiet, do not print error messages\n"
+			       "-v - verbose\n");
+			return (EXIT_SUCCESS);
+		}
 
-			if (fw_setenv (argc, argv) != 0)
-				return (EXIT_FAILURE);
+		if (fw_setenv (argc, argv) != 0)
+			return (EXIT_FAILURE);
 
-			return (EXIT_SUCCESS);
+		return (EXIT_SUCCESS);
 	}
 
-	fprintf (stderr,
-		"Identity crisis - may be called as `" CMD_PRINTENV
-		"' or as `" CMD_SETENV "' but not as `%s'\n",
-		cmdname);
+	fw_print("Identity crisis - may be called as `" CMD_PRINTENV
+		 "' or as `" CMD_SETENV "' but not as `%s'\n",
+		 cmdname);
 	return (EXIT_FAILURE);
 }
-- 
1.5.4.5




From lrj at acm.org  Fri Apr 18 16:17:00 2008
From: lrj at acm.org (Larry Johnson)
Date: Fri, 18 Apr 2008 10:17:00 -0400
Subject: [U-Boot-Users] PCI stopped working on MPC8343
In-Reply-To: <480883E6.5000304@matrix-vision.de>
References: <480883E6.5000304@matrix-vision.de>
Message-ID: <4808AD5C.8080202@acm.org>

Andre Schwarz wrote:
> Last week 
> my PCI bus has been running fine showing all devices.
> Right now no devices are shown on the bus.
> 
> I'm using CONFIG_83XX_GENERIC_PCI with common setup code for PCI.
> 
> Nothing changed from my side during the last 2 weeks.
> 
> 
> Did I miss any changes in u-boot ?
> 
> 
> regards,
> Andre Schwarz
> Matrix Vision

Hi Andre and everyone,

I was just about to post on I problem I belatedly found with PCI on our
Korat PPC400EPx board.  (I believe the same problem exists on the
Sequoia board, but have not proved it.)  What appears to have broken it
was the following patch (I got to use "git bisect" for the first time):

<patch>
commit 55774b512fdf63c0516d441cc5da7c54bbffb7f2
Author: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
Date:   Fri Mar 7 16:04:25 2008 +0900

    pci: Add CONFIG_PCI_SKIP_HOST_BRIDGE config option
    
    In current source code, when the device number of PCI is 0, process PCI
    bridge without fail. However, when the device number is 0, it is not PCI
    always bridge. There are times when device of PCI allocates.
    
    When CONFIG_PCI_SKIP_HOST_BRIDGE is enable, this problem is solved when
    use this patch.
    
    Signed-off-by: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
    Acked-by: Stefan Roese <sr at denx.de>

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 50ca6b0..7944b66 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -425,6 +425,9 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)
 	     dev <  PCI_BDF(bus,PCI_MAX_PCI_DEVICES-1,PCI_MAX_PCI_FUNCTIONS-1);
 	     dev += PCI_BDF(0,0,1))
 	{
+
+	/* Bus 0 is not necessarily PCI bridge. */
+#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
 		/* Skip our host bridge */
 		if ( dev == PCI_BDF(hose->first_busno,0,0) ) {
 #if defined(CONFIG_PCI_CONFIG_HOST_BRIDGE)              /* don't skip host bridge */
@@ -434,10 +437,11 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)
 			if (getenv("pciconfighost") == NULL) {
 				continue; /* Skip our host bridge */
 			}
-#else
+#else /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
 			continue; /* Skip our host bridge */
-#endif
+#endif /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
 		}
+#endif /* CONFIG_PCI_SKIP_HOST_BRIDGE */
 
 		if (PCI_FUNC(dev) && !found_multi)
 			continue;
@@ -473,8 +477,11 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)
 				hose->fixup_irq(hose, dev);
 
 #ifdef CONFIG_PCI_SCAN_SHOW
+#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
 			/* Skip our host bridge */
-			if ( dev != PCI_BDF(hose->first_busno,0,0) ) {
+			if ( dev != PCI_BDF(hose->first_busno,0,0) )
+#endif
+			{
 			    unsigned char int_line;
 
 			    pci_hose_read_config_byte(hose, dev, PCI_INTERRUPT_LINE,

</patch>

The patch changes the behavior of the code _unless_
CONFIG_PCI_SKIP_HOST_BRIDGE is defined.  Defining that switch in the
Korat configuration fixes the problem.  The MPC8323ERDB configuration
has also been patched to add the switch, so maybe this is is the cause
of your problem as well.

I was going to submit the patch for Korat, but then decided I'd first
like to ask Nobuhiro and the group whether it might not be better to
change the occurrences of

#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)

in "drivers/pci/pci.c" to

#if !defined(CONFIG_PCI_NO_SKIP_HOST_BRIDGE)

That would allow those boards that need to patch to specify it
explicity, while leaving the default functionality unchanged.

Comments?

Best regards,
Larry




From lware2002 at hotmail.com  Fri Apr 18 16:16:47 2008
From: lware2002 at hotmail.com (Lance Ware)
Date: Fri, 18 Apr 2008 10:16:47 -0400
Subject: [U-Boot-Users] U-Boot 2.0 EHCI driver
Message-ID: <4808AD4F.6000300@hotmail.com>

Markus,

I have been searching the mailing list archive but haven't been able to 
find the EHCI patch.  Could you send me a link to the message with the 
patch.

Thanks,
Lance



From bernard at largestprime.net  Fri Apr 18 16:21:35 2008
From: bernard at largestprime.net (Bernard Blackham)
Date: Fri, 18 Apr 2008 22:21:35 +0800
Subject: [U-Boot-Users] ubi and u-boot
Message-ID: <4808AE6F.4030505@largestprime.net>

[apologies for the cross post]

Is anyone working on ubi/ubifs support in u-boot?

Kind regards,
Bernard.



From andre.schwarz at matrix-vision.de  Fri Apr 18 16:27:25 2008
From: andre.schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Fri, 18 Apr 2008 16:27:25 +0200
Subject: [U-Boot-Users] PCI stopped working on MPC8343
In-Reply-To: <4808AD5C.8080202@acm.org>
References: <480883E6.5000304@matrix-vision.de> <4808AD5C.8080202@acm.org>
Message-ID: <4808AFCD.5070909@matrix-vision.de>

Larry,

you're right - but it doesn't fix my problem.


Thanks,
Andr?


Larry Johnson schrieb:
> Andre Schwarz wrote:
>> Last week my PCI bus has been running fine showing all devices.
>> Right now no devices are shown on the bus.
>>
>> I'm using CONFIG_83XX_GENERIC_PCI with common setup code for PCI.
>>
>> Nothing changed from my side during the last 2 weeks.
>>
>>
>> Did I miss any changes in u-boot ?
>>
>>
>> regards,
>> Andre Schwarz
>> Matrix Vision
> 
> Hi Andre and everyone,
> 
> I was just about to post on I problem I belatedly found with PCI on our
> Korat PPC400EPx board.  (I believe the same problem exists on the
> Sequoia board, but have not proved it.)  What appears to have broken it
> was the following patch (I got to use "git bisect" for the first time):
> 
> <patch>
> commit 55774b512fdf63c0516d441cc5da7c54bbffb7f2
> Author: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
> Date:   Fri Mar 7 16:04:25 2008 +0900
> 
>    pci: Add CONFIG_PCI_SKIP_HOST_BRIDGE config option
>       In current source code, when the device number of PCI is 0, 
> process PCI
>    bridge without fail. However, when the device number is 0, it is not PCI
>    always bridge. There are times when device of PCI allocates.
>       When CONFIG_PCI_SKIP_HOST_BRIDGE is enable, this problem is solved 
> when
>    use this patch.
>       Signed-off-by: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
>    Acked-by: Stefan Roese <sr at denx.de>
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 50ca6b0..7944b66 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -425,6 +425,9 @@ int pci_hose_scan_bus(struct pci_controller *hose, 
> int bus)
>          dev <  PCI_BDF(bus,PCI_MAX_PCI_DEVICES-1,PCI_MAX_PCI_FUNCTIONS-1);
>          dev += PCI_BDF(0,0,1))
>     {
> +
> +    /* Bus 0 is not necessarily PCI bridge. */
> +#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
>         /* Skip our host bridge */
>         if ( dev == PCI_BDF(hose->first_busno,0,0) ) {
> #if defined(CONFIG_PCI_CONFIG_HOST_BRIDGE)              /* don't skip 
> host bridge */
> @@ -434,10 +437,11 @@ int pci_hose_scan_bus(struct pci_controller *hose, 
> int bus)
>             if (getenv("pciconfighost") == NULL) {
>                 continue; /* Skip our host bridge */
>             }
> -#else
> +#else /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
>             continue; /* Skip our host bridge */
> -#endif
> +#endif /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
>         }
> +#endif /* CONFIG_PCI_SKIP_HOST_BRIDGE */
> 
>         if (PCI_FUNC(dev) && !found_multi)
>             continue;
> @@ -473,8 +477,11 @@ int pci_hose_scan_bus(struct pci_controller *hose, 
> int bus)
>                 hose->fixup_irq(hose, dev);
> 
> #ifdef CONFIG_PCI_SCAN_SHOW
> +#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
>             /* Skip our host bridge */
> -            if ( dev != PCI_BDF(hose->first_busno,0,0) ) {
> +            if ( dev != PCI_BDF(hose->first_busno,0,0) )
> +#endif
> +            {
>                 unsigned char int_line;
> 
>                 pci_hose_read_config_byte(hose, dev, PCI_INTERRUPT_LINE,
> 
> </patch>
> 
> The patch changes the behavior of the code _unless_
> CONFIG_PCI_SKIP_HOST_BRIDGE is defined.  Defining that switch in the
> Korat configuration fixes the problem.  The MPC8323ERDB configuration
> has also been patched to add the switch, so maybe this is is the cause
> of your problem as well.
> 
> I was going to submit the patch for Korat, but then decided I'd first
> like to ask Nobuhiro and the group whether it might not be better to
> change the occurrences of
> 
> #if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
> 
> in "drivers/pci/pci.c" to
> 
> #if !defined(CONFIG_PCI_NO_SKIP_HOST_BRIDGE)
> 
> That would allow those boards that need to patch to specify it
> explicity, while leaving the default functionality unchanged.
> 
> Comments?
> 
> Best regards,
> Larry
> 


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From sr at denx.de  Fri Apr 18 16:30:00 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 16:30:00 +0200
Subject: [U-Boot-Users] [nand-flash] Please pull
	git://www.denx.de/git/u-boot-nand-flash.git
In-Reply-To: <200801161433.39904.sr@denx.de>
References: <20070423123237.295A13535D2@atlas.denx.de>
	<200801131511.46692.sr@denx.de> <200801161433.39904.sr@denx.de>
Message-ID: <200804181630.00321.sr@denx.de>

The following changes since commit 5e3dca577b7c1bf58bd2b48449b18b7e7dcd8e04:
  Anatolij Gustschin (1):
        Fix crash on sequoia in ppc_4xx_eth_init

are available in the git repository at:

  git://www.denx.de/git/u-boot-nand-flash.git master

Stefan Roese (1):
      nand_spl: Update nand_spl to support 2k page size NAND devices

 nand_spl/nand_boot.c |   64 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 63 insertions(+), 1 deletions(-)



From matthias.fuchs at esd-electronics.com  Fri Apr 18 16:28:46 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Fri, 18 Apr 2008 16:28:46 +0200
Subject: [U-Boot-Users] [PATCH] video: Add missing free for logo memory
Message-ID: <200804181628.46905.matthias.fuchs@esd-electronics.com>

This patch adds some missing free()s and does some coding style clean up.

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 drivers/video/cfb_console.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 4f73067..751c2c4 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -830,7 +830,7 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
 		dst = malloc(CFG_VIDEO_LOGO_MAX_SIZE);
 		if (dst == NULL) {
 			printf("Error: malloc in gunzip failed!\n");
-			return(1);
+			return 1;
 		}
 		if (gunzip(dst, CFG_VIDEO_LOGO_MAX_SIZE, (uchar *)bmp_image, &len) != 0) {
 			printf ("Error: no valid bmp or bmp.gz image at %lx\n", bmp_image);
@@ -849,6 +849,7 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
 		if (!((bmp->header.signature[0] == 'B') &&
 		      (bmp->header.signature[1] == 'M'))) {
 			printf ("Error: no valid bmp.gz image at %lx\n", bmp_image);
+			free(dst);
 			return 1;
 		}
 #else
@@ -869,6 +870,8 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
 	if (compression != BMP_BI_RGB) {
 		printf ("Error: compression type %ld not supported\n",
 			compression);
+		if (dst)
+			free(dst);
 		return 1;
 	}
 
@@ -1046,12 +1049,11 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
 	}
 
 #ifdef CONFIG_VIDEO_BMP_GZIP
-	if (dst) {
+	if (dst)
 		free(dst);
-	}
 #endif
 
-	return (0);
+	return 0;
 }
 #endif
 
-- 
1.5.3




From matthias.fuchs at esd-electronics.com  Fri Apr 18 16:29:40 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Fri, 18 Apr 2008 16:29:40 +0200
Subject: [U-Boot-Users] [PATCH] cfi-flash: Add CFG_FLASH_AUTOPROTECT_LIST
Message-ID: <200804181629.40697.matthias.fuchs@esd-electronics.com>

This patch adds a configurable flash auto protection list that can be used
to make U-Boot protect flash regions in flash_init().

The idea has been discussed on the u-boot mailing list starting
on Nov 18th, 2007.

Even this patch brings a new feature it is used as a bugfix for 4xx
platforms where flash_init() does not completely protect the
monitor's flash range in all situations.

U-Boot protects the flash range from CFG_MONITOR_BASE to
(CFG_MONITOR_BASE + monitor_flash_len  - 1) by default. This does not
include the reset vector at 0xfffffffc.

Example:
#define CFG_FLASH_AUTOPROTECT_LIST {{0xfff80000, 0x80000}}

This config option will auto protect the last 512k of flash that
contains the bootloader on board like APC405 and PMC405.

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 drivers/mtd/cfi_flash.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index e3cfb8a..68ab55f 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1873,6 +1873,12 @@ unsigned long flash_init (void)
 {
 	unsigned long size = 0;
 	int i;
+#if defined(CFG_FLASH_AUTOPROTECT_LIST)
+	struct apl_s {
+		ulong start;
+		ulong size;
+	} apl[] = CFG_FLASH_AUTOPROTECT_LIST;
+#endif
 
 #ifdef CFG_FLASH_PROTECTION
 	char *s = getenv("unlock");
@@ -1966,6 +1972,17 @@ unsigned long flash_init (void)
 		       CFG_ENV_ADDR_REDUND + CFG_ENV_SIZE_REDUND - 1,
 		       flash_get_info(CFG_ENV_ADDR_REDUND));
 #endif
+
+#if defined(CFG_FLASH_AUTOPROTECT_LIST)
+	for (i = 0; i < (sizeof(apl) / sizeof(struct apl_s)); i++) {
+		debug("autoprotecting from %08x to %08x\n",
+		      apl[i].start, apl[i].start + apl[i].size - 1);
+		flash_protect (FLAG_PROTECT_SET,
+			       apl[i].start,
+			       apl[i].start + apl[i].size - 1,
+			       flash_get_info(apl[i].start));
+	}
+#endif
 	return (size);
 }
 
-- 
1.5.3




From sr at denx.de  Fri Apr 18 16:49:45 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 16:49:45 +0200
Subject: [U-Boot-Users] [PATCH] allow ports to override bootelf behavior
In-Reply-To: <20080418075454.4C1F7248AB@gemini.denx.de>
References: <20080418075454.4C1F7248AB@gemini.denx.de>
Message-ID: <200804181649.45582.sr@denx.de>

On Friday 18 April 2008, Wolfgang Denk wrote:
> In message <1208130139-18440-1-git-send-email-vapier at gentoo.org> you wrote:
> > Change the bootelf setup function into a dedicated weak function called
> > do_bootelf_exec.  This way ports can control the behavior however they
> > like before/after calling the ELF entry point.
> > ---
> >  common/cmd_elf.c |   33 +++++++++++++++++++++------------
> >  1 files changed, 21 insertions(+), 12 deletions(-)
>
> Applied, thanks.

Unfortunately this breaks all 440 ports using elf:

Configuring for sequoia board...
common/libcommon.a(cmd_elf.o): In function `do_bootelf_exec':
/home/stefan/git/u-boot/u-boot/common/cmd_elf.c:54: undefined reference to `dcache_enable'
make: *** [u-boot] Error 1
ppc_4xx-size: './u-boot': No such file

No dcache_enble() here currently. I'll send a patch to add
dcache_enable() to 440 in a short while. But this could affect
other platforms as well.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 18 16:51:39 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 16:51:39 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
Message-ID: <1208530299-9817-1-git-send-email-sr@denx.de>

dcache_enable() was missing for 440 and the patch
017e9b7925f74878d0e9475388cca9bda5ef9482 ["allow ports to override bootelf
"] behavior uses this function.

Note: Currently the cache handling functions like
d/icache_disable/enable() are NOP's on 440. This may be changed in the
future.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 cpu/ppc4xx/cache.S |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/cpu/ppc4xx/cache.S b/cpu/ppc4xx/cache.S
index 5124dec..ceb3ec0 100644
--- a/cpu/ppc4xx/cache.S
+++ b/cpu/ppc4xx/cache.S
@@ -166,9 +166,11 @@ _GLOBAL(invalidate_dcache)
 #ifdef CONFIG_440
 
        .globl  dcache_disable
+       .globl  dcache_enable
        .globl  icache_disable
        .globl  icache_enable
 dcache_disable:
+dcache_enable:
 icache_disable:
 icache_enable:
 	blr
-- 
1.5.5




From sr at denx.de  Fri Apr 18 16:57:15 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 16:57:15 +0200
Subject: [U-Boot-Users] PCI stopped working on MPC8343
In-Reply-To: <4808AD5C.8080202@acm.org>
References: <480883E6.5000304@matrix-vision.de> <4808AD5C.8080202@acm.org>
Message-ID: <200804181657.16177.sr@denx.de>

On Friday 18 April 2008, Larry Johnson wrote:
> I was just about to post on I problem I belatedly found with PCI on our
> Korat PPC400EPx board.  (I believe the same problem exists on the
> Sequoia board, but have not proved it.)  What appears to have broken it
> was the following patch (I got to use "git bisect" for the first time):

> <patch>
> commit 55774b512fdf63c0516d441cc5da7c54bbffb7f2
> Author: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
> Date:   Fri Mar 7 16:04:25 2008 +0900
>
>     pci: Add CONFIG_PCI_SKIP_HOST_BRIDGE config option

<snip>

> The patch changes the behavior of the code _unless_
> CONFIG_PCI_SKIP_HOST_BRIDGE is defined.  Defining that switch in the
> Korat configuration fixes the problem.  The MPC8323ERDB configuration
> has also been patched to add the switch, so maybe this is is the cause
> of your problem as well.
>
> I was going to submit the patch for Korat, but then decided I'd first
> like to ask Nobuhiro and the group whether it might not be better to
> change the occurrences of
>
> #if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
>
> in "drivers/pci/pci.c" to
>
> #if !defined(CONFIG_PCI_NO_SKIP_HOST_BRIDGE)
>
> That would allow those boards that need to patch to specify it
> explicity, while leaving the default functionality unchanged.
>
> Comments?

Yes, I totally agree. Patches should *not* change the default behavior. We 
should change it as you suggested. Sorry, I must have missed this.

Nobuhiro, could you please send a new patch to fix this problem?

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 18 17:02:21 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 17:02:21 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: <200804111649.37273.sr@denx.de>
References: <20070423123237.295A13535D2@atlas.denx.de>
	<200804091258.06646.sr@denx.de> <200804111649.37273.sr@denx.de>
Message-ID: <200804181702.21886.sr@denx.de>

The following changes since commit 5e3dca577b7c1bf58bd2b48449b18b7e7dcd8e04:
  Anatolij Gustschin (1):
        Fix crash on sequoia in ppc_4xx_eth_init

are available in the git repository at:

  git://www.denx.de/git/u-boot-ppc4xx.git master

Stefan Roese (4):
      ppc4xx: Add Glacier NAND booting target
      ppc4xx: Adjust Canyonlands fixed DDR2 setup (NAND booting) to 512MB SODIMM
      ppc4xx: Change Canyonlands to support booting from 2k page NAND devices
      ppc4xx: Add dcache_enable() for 440

 Makefile                                     |    5 ++++-
 board/amcc/canyonlands/bootstrap.c           |   13 +++++++++++++
 board/amcc/canyonlands/init.S                |    1 +
 board/amcc/canyonlands/u-boot-nand.lds       |    4 ++--
 cpu/ppc4xx/cache.S                           |    2 ++
 include/configs/canyonlands.h                |   26 ++++++++++++++++----------
 nand_spl/board/amcc/canyonlands/config.mk    |    6 +++---
 nand_spl/board/amcc/canyonlands/ddr2_fixed.c |    8 ++++----
 8 files changed, 45 insertions(+), 20 deletions(-)



From sr at denx.de  Fri Apr 18 17:08:01 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 17:08:01 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Don't panic if a controller driver
	does ecc its own way.
In-Reply-To: <4803B6AC.50603@freescale.com>
References: <20080414195050.0DC4B248B9@gemini.denx.de>
	<4803B6AC.50603@freescale.com>
Message-ID: <200804181708.01405.sr@denx.de>

On Monday 14 April 2008, Scott Wood wrote:
> >> Did you try applying it against the 2.6.22.1 branch of the nand
> >> repository (IIRC, the non-commit-message patch comment specified that)?
> >
> > No, I tried to apply this to the U-Boot repository. Maybe this was my
> > fault? Is this supposed to go into Linux, then?
>
> No, it's supposed to go into the 2.6.22.1 branch of Stefan's u-boot NAND
> tree.  This change is already in the Linux NAND code.

I'll update the 2.6.22.1 branch shortly (when time permits). Sorry for the 
delay.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 18 17:10:37 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 17:10:37 +0200
Subject: [U-Boot-Users] [PATCH v2 2/2] Freescale eLBC FCM NAND driver
In-Reply-To: <20080413220155.7853F248BB@gemini.denx.de>
References: <20080413220155.7853F248BB@gemini.denx.de>
Message-ID: <200804181710.38264.sr@denx.de>

On Monday 14 April 2008, Wolfgang Denk wrote:
> > This is a driver for the Flash Control Machine of the enhanched Local Bus
> > Controller found on some Freescale chips (such as the mpc8313 and the
> > mpc8379).
> >
> > Signed-off-by: Scott Wood <scottwood at freescale.com>
> > ---
> > Fixed one instance of trailing whitespace, moved the conditional to the
> > makefile, and increased the hardware timeout to the maximum after
> > receiving a report that some boards need higher that the old setting.
> >
> >  drivers/mtd/nand/Makefile        |    1 +
> >  drivers/mtd/nand/fsl_elbc_nand.c |  759
> > ++++++++++++++++++++++++++++++++++++++ 2 files changed, 760
> > insertions(+), 0 deletions(-)
> >  create mode 100644 drivers/mtd/nand/fsl_elbc_nand.c
>
> I think you should pull this into the u-boot-nand-flash repo, or are
> there any objections against this patch?

No. But this is for the 2.6.22.1 branch too. I'll merge it when I find the 
time.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From matthias.fuchs at esd-electronics.com  Fri Apr 18 17:24:32 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Fri, 18 Apr 2008 17:24:32 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: fix sys_get_info() for 405GP(r)
Message-ID: <200804181724.32661.matthias.fuchs@esd-electronics.com>

This patch assigns the correct EBC clock for 405GP(r) CPUs
to PPC4xx_SYS_INFO structure. Without this patch U-Boot
uses an uninitialized EBC clock in its startup message.

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 cpu/ppc4xx/speed.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/cpu/ppc4xx/speed.c b/cpu/ppc4xx/speed.c
index fa79952..05b42fe 100644
--- a/cpu/ppc4xx/speed.c
+++ b/cpu/ppc4xx/speed.c
@@ -165,6 +165,8 @@ void get_sys_info (PPC4xx_SYS_INFO * sysInfo)
 		}
 	}
 
+	sysInfo->freqEBC = sysInfo->freqPLB / sysInfo->pllExtBusDiv;
+
 	sysInfo->freqUART = sysInfo->freqProcessor;
 }
 
-- 
1.5.3




From plagnioj at jcrosoft.com  Fri Apr 18 18:01:57 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Fri, 18 Apr 2008 18:01:57 +0200
Subject: [U-Boot-Users] [PATCH] cfi-flash: Add	CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: <200804181629.40697.matthias.fuchs@esd-electronics.com>
References: <200804181629.40697.matthias.fuchs@esd-electronics.com>
Message-ID: <20080418160157.GB12486@game.jcrosoft.org>

On 16:29 Fri 18 Apr     , Matthias Fuchs wrote:
> This patch adds a configurable flash auto protection list that can be used
> to make U-Boot protect flash regions in flash_init().
> 
> The idea has been discussed on the u-boot mailing list starting
> on Nov 18th, 2007.
> 
> Even this patch brings a new feature it is used as a bugfix for 4xx
> platforms where flash_init() does not completely protect the
> monitor's flash range in all situations.
> 
> U-Boot protects the flash range from CFG_MONITOR_BASE to
> (CFG_MONITOR_BASE + monitor_flash_len  - 1) by default. This does not
> include the reset vector at 0xfffffffc.
> 
> Example:
> #define CFG_FLASH_AUTOPROTECT_LIST {{0xfff80000, 0x80000}}
> 
> This config option will auto protect the last 512k of flash that
> contains the bootloader on board like APC405 and PMC405.
> 
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
> ---
>  drivers/mtd/cfi_flash.c |   17 +++++++++++++++++
>  1 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index e3cfb8a..68ab55f 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -1873,6 +1873,12 @@ unsigned long flash_init (void)
>  {
>  	unsigned long size = 0;
>  	int i;
> +#if defined(CFG_FLASH_AUTOPROTECT_LIST)
> +	struct apl_s {
> +		ulong start;
> +		ulong size;
> +	} apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> +#endif
I think it will be better to create a weak structure.

Best Regards,
J.



From sr at denx.de  Fri Apr 18 18:12:24 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 18:12:24 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: fix sys_get_info() for 405GP(r)
In-Reply-To: <200804181724.32661.matthias.fuchs@esd-electronics.com>
References: <200804181724.32661.matthias.fuchs@esd-electronics.com>
Message-ID: <200804181812.24707.sr@denx.de>

On Friday 18 April 2008, Matthias Fuchs wrote:
> This patch assigns the correct EBC clock for 405GP(r) CPUs
> to PPC4xx_SYS_INFO structure. Without this patch U-Boot
> uses an uninitialized EBC clock in its startup message.

Added to u-boot-ppc4xx custodian repo. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From kim.phillips at freescale.com  Fri Apr 18 18:20:46 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Fri, 18 Apr 2008 11:20:46 -0500
Subject: [U-Boot-Users] [PATCH] fix system config overwrite @ MPC834x
In-Reply-To: <48086073.4060306@matrix-vision.de>
References: <480788B1.9090208@matrix-vision.de>
	<20080417155615.43fa3791.kim.phillips@freescale.com>
	<48086073.4060306@matrix-vision.de>
Message-ID: <20080418112046.ce82252a.kim.phillips@freescale.com>

On Fri, 18 Apr 2008 10:48:51 +0200
Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:

> Kim,
> 
> doing a git-pull gives "Already up-to-date."
> The patch is produced with "git-diff --patch-with-stat 
> cpu/mpc83xx/cpu_init.c"

using git-commit and git-format-patch is recommended, but that's
probably not the problem here.  Have you followed the instructions for
Thunderbird in linux-2.6/Documentation/email-clients.txt?  You can test
by using git-am on patches you email yourself.

Kim



From galak at kernel.crashing.org  Fri Apr 18 18:29:01 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 18 Apr 2008 11:29:01 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx: Fix size of cpu-release-addr property
Message-ID: <Pine.LNX.4.64.0804181128440.6860@blarg.am.freescale.net>

The cpu-release-addr is defined as always being a 64-bit quanity regardless
if we are running on a 32-bit or 64-bit machine.
---
 cpu/mpc85xx/fdt.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cpu/mpc85xx/fdt.c b/cpu/mpc85xx/fdt.c
index bde6d1e..bb87740 100644
--- a/cpu/mpc85xx/fdt.c
+++ b/cpu/mpc85xx/fdt.c
@@ -52,7 +52,7 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
 			if (*reg == id) {
 				fdt_setprop_string(blob, off, "status", "okay");
 			} else {
-				u32 val = *reg * SIZE_BOOT_ENTRY + spin_tbl_addr;
+				u64 val = *reg * SIZE_BOOT_ENTRY + spin_tbl_addr;
 				val = cpu_to_fdt32(val);
 				fdt_setprop_string(blob, off, "status",
 								"disabled");
-- 
1.5.4.1




From jwboyer at gmail.com  Fri Apr 18 18:40:08 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 18 Apr 2008 11:40:08 -0500
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <4808AE6F.4030505@largestprime.net>
References: <4808AE6F.4030505@largestprime.net>
Message-ID: <1208536808.6654.6.camel@vader.jdub.homelinux.org>

On Fri, 2008-04-18 at 22:21 +0800, Bernard Blackham wrote:
> [apologies for the cross post]
> 
> Is anyone working on ubi/ubifs support in u-boot?

I am not aware of anyone actively working on porting UBI to upstream
U-Boot at this exact moment.

josh




From jamie at shareable.org  Fri Apr 18 18:59:57 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Fri, 18 Apr 2008 17:59:57 +0100
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <1208536808.6654.6.camel@vader.jdub.homelinux.org>
References: <4808AE6F.4030505@largestprime.net>
	<1208536808.6654.6.camel@vader.jdub.homelinux.org>
Message-ID: <20080418165957.GG31520@shareable.org>

Josh Boyer wrote:
> On Fri, 2008-04-18 at 22:21 +0800, Bernard Blackham wrote:
> > [apologies for the cross post]
> > Is anyone working on ubi/ubifs support in u-boot?
> 
> I am not aware of anyone actively working on porting UBI to upstream
> U-Boot at this exact moment.

Is it even a good idea?  The UBI (version 1 :-) initial scan is not
fast for large flash, and if the bootloader does it too, that's twice
as much time to boot.

However, if there was a protocol for bootloader to pass the scan
results to the booted kernel, that would be very nice.

-- Jamie



From galak at kernel.crashing.org  Fri Apr 18 18:57:15 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 18 Apr 2008 11:57:15 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx: Round up frequency calculations to get
 reasonable output
Message-ID: <Pine.LNX.4.64.0804181156410.4255@blarg.am.freescale.net>

eg. because of rounding error we can get 799Mhz instead of 800Mhz.

Signed-off-by: Dejan Minic <minic at freescale.com>
Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
 cpu/mpc85xx/cpu.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index dcd8817..6972bb1 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -65,6 +65,11 @@ struct cpu_type cpu_type_list [] = {
 	CPU_TYPE_ENTRY(8572_E),
 };

+static inline unsigned long integer_round (unsigned long val, unsigned long div)
+{
+	return ((val + (div/2)) / div);
+}
+
 int checkcpu (void)
 {
 	sys_info_t sysinfo;
@@ -116,22 +121,21 @@ int checkcpu (void)
 	get_sys_info(&sysinfo);

 	puts("Clock Configuration:\n");
-	printf("       CPU:%4lu MHz, ", sysinfo.freqProcessor / 1000000);
-	printf("CCB:%4lu MHz,\n", sysinfo.freqSystemBus / 1000000);
-
+	printf("       CPU:%4lu MHz, ", integer_round(sysinfo.freqProcessor,1000000));
+	printf("CCB:%4lu MHz,\n", integer_round(sysinfo.freqSystemBus,1000000));
 	ddr_ratio = ((gur->porpllsr) & 0x00003e00) >> 9;
 	switch (ddr_ratio) {
 	case 0x0:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		integer_round(sysinfo.freqDDRBus,2000000), integer_round(sysinfo.freqDDRBus,1000000));
 		break;
 	case 0x7:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate) (Synchronous), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		integer_round(sysinfo.freqDDRBus, 2000000), integer_round(sysinfo.freqDDRBus, 1000000));
 		break;
 	default:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate) (Asynchronous), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		integer_round(sysinfo.freqDDRBus, 2000000), integer_round(sysinfo.freqDDRBus,1000000));
 		break;
 	}

@@ -154,7 +158,7 @@ int checkcpu (void)
 		 clkdiv *= 2;
 #endif
 		printf("LBC:%4lu MHz\n",
-		       sysinfo.freqSystemBus / 1000000 / clkdiv);
+		       integer_round(sysinfo.freqSystemBus, 1000000) / clkdiv);
 	} else {
 		printf("LBC: unknown (lcrr: 0x%08x)\n", lcrr);
 	}
-- 
1.5.4.1




From Ken.Fuchs at bench.com  Fri Apr 18 19:01:38 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 18 Apr 2008 12:01:38 -0500
Subject: [U-Boot-Users] What methods of software authentication does U-Boot
	support?
Message-ID: <AA28F077645B324881335614E4F7C428034CCB@win-ex01.bench.com>

Goal:

U-Boot will run only software that has been
authenticated to be from the system's producer.  

--- A Potential Authentication Method ---

The producer of the system generates a cryptographic
[private-key, public-key] pair, storing the public-key
on the same media as U-Boot (i.e. NOR flash; perhaps
as a read-only environment variable) on all systems
and keeping the private-key hidden at a secure site.
A hash of the software is generated, encrypted
with the private key and shipped with the software.

U-Boot reads the private-key encrypted hash and decodes
it with its public-key.  U-Boot loads the software and
generates the hash.  If both hashes match, the software
is authenticated and U-Boot executes the authenticated
software.

--- Comment ---

U-Boot obviously supports loading and verification of
the generated hash, but I haven't been able to locate
public-key cryptographic or other authentication support
in U-Boot.  Perhaps, it is available as a loadable
(stand-alone) module?

Any comments or suggestions?

Sincerely,

Ken Fuchs



From lrj at acm.org  Fri Apr 18 18:51:12 2008
From: lrj at acm.org (Larry Johnson)
Date: Fri, 18 Apr 2008 12:51:12 -0400
Subject: [U-Boot-Users] PCI stopped working on MPC8343
In-Reply-To: <4808AFCD.5070909@matrix-vision.de>
References: <480883E6.5000304@matrix-vision.de> <4808AD5C.8080202@acm.org>
	<4808AFCD.5070909@matrix-vision.de>
Message-ID: <4808D180.1000604@acm.org>

Andr? Schwarz wrote:
> Larry,
> 
> you're right - but it doesn't fix my problem.
> 
> 
> Thanks,
> Andr?
> 
> 
> Larry Johnson schrieb:
>> Andre Schwarz wrote:
>>> Last week my PCI bus has been running fine showing all devices.
>>> Right now no devices are shown on the bus.
>>>
>>> I'm using CONFIG_83XX_GENERIC_PCI with common setup code for PCI.
>>>
>>> Nothing changed from my side during the last 2 weeks.
>>>
>>>
>>> Did I miss any changes in u-boot ?
>>>
>>>
>>> regards,
>>> Andre Schwarz
>>> Matrix Vision
>>
>> Hi Andre and everyone,
>>
>> I was just about to post on I problem I belatedly found with PCI on our
>> Korat PPC400EPx board.  (I believe the same problem exists on the
>> Sequoia board, but have not proved it.)  What appears to have broken it
>> was the following patch (I got to use "git bisect" for the first time):
>>
>> <snip>

I'm sorry to hear that. (And it was such a nice theory!)

Best regards,
Larry




From afleming at gmail.com  Fri Apr 18 19:11:28 2008
From: afleming at gmail.com (Andy Fleming)
Date: Fri, 18 Apr 2008 12:11:28 -0500
Subject: [U-Boot-Users] [PATCH] 85xx: Round up frequency calculations to
	get reasonable output
In-Reply-To: <Pine.LNX.4.64.0804181156410.4255@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804181156410.4255@blarg.am.freescale.net>
Message-ID: <2acbd3e40804181011xd27f71em71559cb5f65c62ac@mail.gmail.com>

On Fri, Apr 18, 2008 at 11:57 AM, Kumar Gala <galak at kernel.crashing.org> wrote:
> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
>
>  Signed-off-by: Dejan Minic <minic at freescale.com>
>  Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
>  Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>  ---
>   cpu/mpc85xx/cpu.c |   18 +++++++++++-------
>   1 files changed, 11 insertions(+), 7 deletions(-)
>
>  diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
>  index dcd8817..6972bb1 100644
>  --- a/cpu/mpc85xx/cpu.c
>  +++ b/cpu/mpc85xx/cpu.c
>  @@ -65,6 +65,11 @@ struct cpu_type cpu_type_list [] = {
>         CPU_TYPE_ENTRY(8572_E),
>   };
>
>  +static inline unsigned long integer_round (unsigned long val, unsigned long div)
>  +{
>  +       return ((val + (div/2)) / div);
>  +}
>  +


Ok, but I don't think we can really call it integer_round().  Can we
call it something that reflects what it does?  Like, rounded_divide()
or something?

Andy



From bernard at largestprime.net  Fri Apr 18 19:49:47 2008
From: bernard at largestprime.net (Bernard Blackham)
Date: Sat, 19 Apr 2008 01:49:47 +0800
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <20080418165957.GG31520@shareable.org>
References: <4808AE6F.4030505@largestprime.net>
	<1208536808.6654.6.camel@vader.jdub.homelinux.org>
	<20080418165957.GG31520@shareable.org>
Message-ID: <4808DF3B.2080702@largestprime.net>

Jamie Lokier wrote:
> Josh Boyer wrote:
>>> Is anyone working on ubi/ubifs support in u-boot?
>> I am not aware of anyone actively working on porting UBI to upstream
>> U-Boot at this exact moment.
> 
> Is it even a good idea?

 From what I've seen, UBI is the first solution with the potential for 
reliably booting from NAND flash - specifically, dealing with 
read-disturbance from adjacent blocks causing bit errors in critical 
boot blocks. This could save useful things like your kernel image (where 
it's rarely written, but it and blocks around it are read often enough 
to cause an annoying bitflip or two). The rewriting can be done once 
userspace boots, but having it in UBI to begin with makes this easier.

(Unless there's a much easier way to deal with read-disturbance that 
I've missed, in which case please lart me).

Wolfgang showed some interest briefly too.[1]

 > The UBI (version 1 :-) initial scan is not
> fast for large flash, and if the bootloader does it too, that's twice
> as much time to boot.
 >
> However, if there was a protocol for bootloader to pass the scan
> results to the booted kernel, that would be very nice.

If there's no compelling reasons not to, I'll try and find some time to 
work on ubi in uboot. I'm not expecting it to be easy though :)

Cheers,
Bernard.

[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/32602



From sr at denx.de  Fri Apr 18 19:55:16 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 19:55:16 +0200
Subject: [U-Boot-Users] TLB parity errors on 440EP/Yosemite board
In-Reply-To: <457423.79169.qm@web45102.mail.sp1.yahoo.com>
References: <457423.79169.qm@web45102.mail.sp1.yahoo.com>
Message-ID: <200804181955.17033.sr@denx.de>

On Thursday 17 April 2008, Dave wrote:
> I am adding a TLB entry to the table of TLB entries in
> the init.S for the Yosemite board.   Whenever u-boot
> accesses this memory space I get the following error.
>
> Machine Check Exception.
> Caused by (from msr): regs 07f2adb0 TLB Parity Error
>
> Any ideas what I could be doing wrong to cause this?

Which TLB entry are you adding? Please send the code-line. And why do you add 
it?

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 18 20:03:58 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 18 Apr 2008 20:03:58 +0200
Subject: [U-Boot-Users] [PATCH v2] ppc4xx: Fix PPC440 build breakage due
	to missing dcache_enable symbol
In-Reply-To: <20080418101306.469.90871.stgit@pollux.denx.de>
References: <20080418095616.18864.23500.stgit@pollux.denx.de>
	<20080418101306.469.90871.stgit@pollux.denx.de>
Message-ID: <200804182003.58966.sr@denx.de>

On Friday 18 April 2008, Bartlomiej Sieka wrote:
> Recent commit 017e9b79 adds reference to dcache_enable, thus breaking the
> build on PPC440. This patch adds a stub for dcache_enable, similarly to
> what's being done for other cache operations.

Finally I manage to read the mailing lists. And you fixed the problem too. :) 
Great, thanks.

BTW: Please keep me on CC on all ppc4xx (or CFI etc) related patches. This way 
I "see" the patches earlier.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From Andre.Schwarz at matrix-vision.de  Fri Apr 18 20:31:05 2008
From: Andre.Schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Fri, 18 Apr 2008 20:31:05 +0200
Subject: [U-Boot-Users] [PATCH] fix system config overwrite @ MPC834x
In-Reply-To: <20080418112046.ce82252a.kim.phillips@freescale.com>
References: <480788B1.9090208@matrix-vision.de>	<20080417155615.43fa3791.kim.phillips@freescale.com>	<48086073.4060306@matrix-vision.de>
	<20080418112046.ce82252a.kim.phillips@freescale.com>
Message-ID: <4808E8E9.7000804@matrix-vision.de>

Thanks - I'll give it another try on monday.


Cheers,
Andr?

Kim Phillips wrote:
> On Fri, 18 Apr 2008 10:48:51 +0200
> Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:
>
>   
>> Kim,
>>
>> doing a git-pull gives "Already up-to-date."
>> The patch is produced with "git-diff --patch-with-stat 
>> cpu/mpc83xx/cpu_init.c"
>>     
>
> using git-commit and git-format-patch is recommended, but that's
> probably not the problem here.  Have you followed the instructions for
> Thunderbird in linux-2.6/Documentation/email-clients.txt?  You can test
> by using git-am on patches you email yourself.
>
> Kim
>   



MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080418/6a56cc61/attachment.htm 

From jwboyer at gmail.com  Fri Apr 18 21:19:01 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 18 Apr 2008 14:19:01 -0500
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <20080418165957.GG31520@shareable.org>
References: <4808AE6F.4030505@largestprime.net>
	<1208536808.6654.6.camel@vader.jdub.homelinux.org>
	<20080418165957.GG31520@shareable.org>
Message-ID: <1208546341.6654.8.camel@vader.jdub.homelinux.org>

On Fri, 2008-04-18 at 17:59 +0100, Jamie Lokier wrote:
> Josh Boyer wrote:
> > On Fri, 2008-04-18 at 22:21 +0800, Bernard Blackham wrote:
> > > [apologies for the cross post]
> > > Is anyone working on ubi/ubifs support in u-boot?
> > 
> > I am not aware of anyone actively working on porting UBI to upstream
> > U-Boot at this exact moment.
> 
> Is it even a good idea?  The UBI (version 1 :-) initial scan is not
> fast for large flash, and if the bootloader does it too, that's twice
> as much time to boot.

It's a good idea, yes.  Particularly if you want to boot from NAND
flash.

Can you define "large device"?  It only scans the first 1 or 2 pages for
each eraseblock to build up the volume tables.  That really isn't that
slow...

> However, if there was a protocol for bootloader to pass the scan
> results to the booted kernel, that would be very nice.

Maybe.  I was never fully convinced of that.

josh




From tor at excito.com  Fri Apr 18 22:24:31 2008
From: tor at excito.com (Tor Krill)
Date: Fri, 18 Apr 2008 20:24:31 +0000 (UTC)
Subject: [U-Boot-Users] U-Boot 2.0 EHCI driver
In-Reply-To: <4808AD4F.6000300@hotmail.com>
Message-ID: <xRGYPO7D.1208550270.6182700.tor@localhost>



I usually use nntp when searching for old stuff. Use
nntp://news.gmane.org/gmane.comp.boot-loaders.u-boot and search for
ehci. Its easy to find.

Regarding EHCI, this is something im interested in as well and will see
if i can get any time testing this patch soon. (Our SOC actually has
built in EHCI and thus the PCI part does not work for us. But it seemed
quite easy to refactor that part(?))

/Tor

On 4/18/2008, "Lance Ware" <lware2002 at hotmail.com> wrote:

>Markus,
>
>I have been searching the mailing list archive but haven't been able to
>find the EHCI patch.  Could you send me a link to the message with the
>patch.
>
>Thanks,
>Lance
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>Don't miss this year's exciting event. There's still time to save $100.
>Use priority code J8TL2D2.
>http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users
>



From kim.phillips at freescale.com  Fri Apr 18 23:32:11 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Fri, 18 Apr 2008 16:32:11 -0500
Subject: [U-Boot-Users] What methods of software authentication does
 U-Boot support?
In-Reply-To: <AA28F077645B324881335614E4F7C428034CCB@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CCB@win-ex01.bench.com>
Message-ID: <20080418163211.d5a1ee64.kim.phillips@freescale.com>

On Fri, 18 Apr 2008 12:01:38 -0500
<Ken.Fuchs at bench.com> wrote:

> Goal:
> 
> U-Boot will run only software that has been
> authenticated to be from the system's producer.  
> 
> --- A Potential Authentication Method ---
> 
> The producer of the system generates a cryptographic
> [private-key, public-key] pair, storing the public-key
> on the same media as U-Boot (i.e. NOR flash; perhaps
> as a read-only environment variable) on all systems
> and keeping the private-key hidden at a secure site.
> A hash of the software is generated, encrypted
> with the private key and shipped with the software.
> 
> U-Boot reads the private-key encrypted hash and decodes
> it with its public-key.  U-Boot loads the software and
> generates the hash.  If both hashes match, the software
> is authenticated and U-Boot executes the authenticated
> software.
> 
> --- Comment ---
> 
> U-Boot obviously supports loading and verification of
> the generated hash, but I haven't been able to locate
> public-key cryptographic or other authentication support
> in U-Boot.  Perhaps, it is available as a loadable
> (stand-alone) module?
> 
> Any comments or suggestions?
> 
this patch taps into openssl:

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/23977

or you might want to reuse some of linux' crypto library code.

Kim



From galak at kernel.crashing.org  Fri Apr 18 23:28:46 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 18 Apr 2008 16:28:46 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH v2] 85xx: Round up frequency calculations to
 get reasonable output
Message-ID: <Pine.LNX.4.64.0804181628090.13828@blarg.am.freescale.net>

eg. because of rounding error we can get 799Mhz instead of 800Mhz.

Signed-off-by: Dejan Minic <minic at freescale.com>
Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

renamed integer_round to rounded_divide per Andy's request.

 cpu/mpc85xx/cpu.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index dcd8817..8efae26 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -65,6 +65,11 @@ struct cpu_type cpu_type_list [] = {
 	CPU_TYPE_ENTRY(8572_E),
 };

+static inline unsigned long rounded_divide (unsigned long val, unsigned long div)
+{
+	return ((val + (div/2)) / div);
+}
+
 int checkcpu (void)
 {
 	sys_info_t sysinfo;
@@ -116,22 +121,21 @@ int checkcpu (void)
 	get_sys_info(&sysinfo);

 	puts("Clock Configuration:\n");
-	printf("       CPU:%4lu MHz, ", sysinfo.freqProcessor / 1000000);
-	printf("CCB:%4lu MHz,\n", sysinfo.freqSystemBus / 1000000);
-
+	printf("       CPU:%4lu MHz, ", rounded_divide(sysinfo.freqProcessor,1000000));
+	printf("CCB:%4lu MHz,\n", rounded_divide(sysinfo.freqSystemBus,1000000));
 	ddr_ratio = ((gur->porpllsr) & 0x00003e00) >> 9;
 	switch (ddr_ratio) {
 	case 0x0:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		rounded_divide(sysinfo.freqDDRBus,2000000), rounded_divide(sysinfo.freqDDRBus,1000000));
 		break;
 	case 0x7:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate) (Synchronous), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		rounded_divide(sysinfo.freqDDRBus, 2000000), rounded_divide(sysinfo.freqDDRBus, 1000000));
 		break;
 	default:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate) (Asynchronous), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		rounded_divide(sysinfo.freqDDRBus, 2000000), rounded_divide(sysinfo.freqDDRBus,1000000));
 		break;
 	}

@@ -154,7 +158,7 @@ int checkcpu (void)
 		 clkdiv *= 2;
 #endif
 		printf("LBC:%4lu MHz\n",
-		       sysinfo.freqSystemBus / 1000000 / clkdiv);
+		       rounded_divide(sysinfo.freqSystemBus, 1000000) / clkdiv);
 	} else {
 		printf("LBC: unknown (lcrr: 0x%08x)\n", lcrr);
 	}
-- 
1.5.4.1




From Ken.Fuchs at bench.com  Sat Apr 19 00:35:52 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 18 Apr 2008 17:35:52 -0500
Subject: [U-Boot-Users] U-Boot WinCE booting support?
In-Reply-To: <200802071659.19600.sr@denx.de>
Message-ID: <AA28F077645B324881335614E4F7C428034CCF@win-ex01.bench.com>

On Thursday, February 07, 2008 09:59, Stefan Roese wrote:

> I'm wondering what may be needed to boot WinCE (6.0) images 
> from U-Boot. 
> Searching the web leads to some pages that mention booting 
> WinCE is possible. 
> But my understanding is that some additional patches are 
> necessary and the 
> official U-Boot doesn't support this currently.
> 
> Does anybody have experience with this? Any hints appreciated.

It is my understanding that:

MS Windows CE (6.0) typically starts with the assumption that
Eboot has setup the MMU for it.  To fix this problem, the MMU code
could be moved from Eboot to the early OEM code in the CE kernel.

The NK.nb0 raw file would be easier to boot (than the proprietary
NK.bin file) via U-Boot.  In my experience, the NK.nb0 file is not
much larger than the NK.bin, though that can vary greatly,
especially if the kernel contains a lot of empty space.

Sincerely,

Ken Fuchs



From afleming at gmail.com  Sat Apr 19 00:43:40 2008
From: afleming at gmail.com (Andy Fleming)
Date: Fri, 18 Apr 2008 17:43:40 -0500
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some
	85xx chips
In-Reply-To: <1207325758-1333-1-git-send-email-timur@freescale.com>
References: <1207325758-1333-1-git-send-email-timur@freescale.com>
Message-ID: <2acbd3e40804181543g3885a5a5h3c1248a7bddf0c82@mail.gmail.com>

On Fri, Apr 4, 2008 at 11:15 AM, Timur Tabi <timur at freescale.com> wrote:
> Some 85xx chips use CCB as the base clock for the I2C.  Some use CCB/2, and
>  some use CCB/3.  There is no pattern that can be used to determine which
>  chips use which frequency, so the only way to determine is to look up the
>  actual SOC designation and use the right value for that SOC.
>
>  Update immap_85xx.h to include the GUTS PORDEVSR2 register.
>
>  Signed-off-by: Timur Tabi <timur at freescale.com>

Applied, thanks



From afleming at gmail.com  Sat Apr 19 00:45:20 2008
From: afleming at gmail.com (Andy Fleming)
Date: Fri, 18 Apr 2008 17:45:20 -0500
Subject: [U-Boot-Users] [PATCH] 85xx: Fix size of cpu-release-addr
	property
In-Reply-To: <Pine.LNX.4.64.0804181128440.6860@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804181128440.6860@blarg.am.freescale.net>
Message-ID: <2acbd3e40804181545y3b98f3bajcf8123838252c762@mail.gmail.com>

On Fri, Apr 18, 2008 at 11:29 AM, Kumar Gala <galak at kernel.crashing.org> wrote:
> The cpu-release-addr is defined as always being a 64-bit quanity regardless
>  if we are running on a 32-bit or 64-bit machine.

Applied, thanks.



From afleming at gmail.com  Sat Apr 19 00:46:56 2008
From: afleming at gmail.com (Andy Fleming)
Date: Fri, 18 Apr 2008 17:46:56 -0500
Subject: [U-Boot-Users] [PATCH v2] 85xx: Round up frequency calculations
	to get reasonable output
In-Reply-To: <Pine.LNX.4.64.0804181628090.13828@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804181628090.13828@blarg.am.freescale.net>
Message-ID: <2acbd3e40804181546o3ee9432bre6ba521e7076b96@mail.gmail.com>

On Fri, Apr 18, 2008 at 4:28 PM, Kumar Gala <galak at kernel.crashing.org> wrote:
> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
>
>  Signed-off-by: Dejan Minic <minic at freescale.com>
>  Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
>  Signed-off-by: Kumar Gala <galak at kernel.crashing.org>

Applied, thanks



From afleming at freescale.com  Sat Apr 19 00:49:16 2008
From: afleming at freescale.com (Andy Fleming)
Date: Fri, 18 Apr 2008 17:49:16 -0500
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
Message-ID: <1208558956-6531-1-git-send-email-afleming@freescale.com>

are available in the git repository at:

  git://www.denx.de/git/u-boot-mpc85xx.git master

Kumar Gala (2):
      85xx: Fix size of cpu-release-addr property
      85xx: Round up frequency calculations to get reasonable output

Timur Tabi (1):
      Fix calculation of I2C clock for some 85xx chips

 cpu/mpc85xx/cpu.c            |   18 +++++++++++-------
 cpu/mpc85xx/fdt.c            |    2 +-
 cpu/mpc85xx/speed.c          |   31 ++++++++++++++++++++++++++++++-
 include/asm-ppc/immap_85xx.h |    4 +++-
 4 files changed, 45 insertions(+), 10 deletions(-)



From info at fuarlar.us  Sat Apr 19 01:02:56 2008
From: info at fuarlar.us (Kent Antalya e-davetiye)
Date: Sat, 19 Apr 2008 02:02:56 +0300
Subject: [U-Boot-Users] =?iso-8859-9?q?Kent_Fuarlar=FD_=DEimdi_Antalya=27d?=
	=?iso-8859-9?q?a_-_Davetlisiniz!!!?=
Message-ID: <c4fb4600bd5f6344cb654dce245daa31@fuarlar.us>




kent antalya e-davetiye








  
     
  

  
     
  

  
    
      
        
          Yukar?daki davetiyenin ??k???n? alarak yada linkteki formu doldurarak fuar?m?z? ?cretsiz ziyaret edebilirsiniz. 

        
      
      Online Fuar Davetiyesi 
      i?in t?klay?n... 

      

     
  

  
     Listemizden ??kmak istiyorsan?z l?tfen buraya t?klay?n.   
  

  
    Marmara Tan&#305;t&#305;m Fuarc?l?k

            Istanbul (Merkez) Tel: +90 212 481 04 04 Fax: +90 212 481 04 74

            Ankara (&#350;ube) Tel: +90 312 426 64 22 Fax: +90 312 426 64 41

            Izmir (Sube) Tel: +90 232 422 00 93 Fax: +90 232  422 16 33

  
  


 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080419/7855ad30/attachment.htm 

From pmeloy at shaw.ca  Sat Apr 19 01:15:13 2008
From: pmeloy at shaw.ca (pat)
Date: Fri, 18 Apr 2008 16:15:13 -0700
Subject: [U-Boot-Users] Help making jffs2 image
In-Reply-To: <1208397490.10202.12.camel@rhodan.shaw.ca>
References: <1208397490.10202.12.camel@rhodan.shaw.ca>
Message-ID: <1208560513.26233.6.camel@rhodan.shaw.ca>

On Wed, 2008-04-16 at 18:58 -0700, pat wrote:
> I can't seem to make a jffs2 image that u-Boot or the kernel can read. I

Ok, I got further. I turned on the generic platform nand device driver
and I made another jffs2 image but this time with 512 byte page size. I
think I understand the 512+ notation in the datasheet now - the extra
bytes are for badblock markers/clean markers and not for jffs2 data. By
using the larger number i was putting jffs2 data outside of where the
jffs2 routines would be looking for it and therefore ecc was freaking
out (and software ecc taking forever because it was correcting
everything as it went along).

At least, thats my guess...

So now I can boot to an initrd and mount the jffs2 partition without
complaints but it doesn't seem to want to boot straight to jffs2.
Although it says the file system was mounted it says it can't open a
console then the kernel panics because it can't sync.

I've compiled another kernel with all the nand/jffs2 debugging at its
most verbose, maybe it'll rise up and smack me in the forehead with
whatever it is I'm doing wrong (and I know it'll be something dumb, it
always is).





From vapier at gentoo.org  Sat Apr 19 02:37:01 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 18 Apr 2008 20:37:01 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: overhaul i2c driver
Message-ID: <1208565421-19690-1-git-send-email-vapier@gentoo.org>

The current Blackfin i2c driver does not work properly with certain devices
due to it breaking up transfers incorrectly.  This is a rewrite of the
driver and relocates it to the newer place in the source tree.

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
I couldn't get git-format-patch to detect the rename (tried -B, -M, and -C),
but the resulting diff between the files isn't terribly readable in the
first place, so it shouldn't be that big of a deal.

 cpu/blackfin/Makefile         |    2 +-
 cpu/blackfin/i2c.c            |  444 -----------------------------------------
 drivers/i2c/Makefile          |    1 +
 drivers/i2c/bfin-twi_i2c.c    |  300 +++++++++++++++++++++++++++
 include/configs/bf533-ezkit.h |    2 +-
 include/configs/bf533-stamp.h |    2 +-
 include/configs/bf537-stamp.h |   43 +----
 7 files changed, 308 insertions(+), 486 deletions(-)
 delete mode 100644 cpu/blackfin/i2c.c
 create mode 100644 drivers/i2c/bfin-twi_i2c.c

diff --git a/cpu/blackfin/Makefile b/cpu/blackfin/Makefile
index f194a38..b3a8b1e 100644
--- a/cpu/blackfin/Makefile
+++ b/cpu/blackfin/Makefile
@@ -17,7 +17,7 @@ EXTRA    :=
 CEXTRA   := initcode.o
 SEXTRA   := start.o
 SOBJS    := interrupt.o cache.o flush.o
-COBJS    := cpu.o traps.o interrupts.o reset.o serial.o i2c.o watchdog.o
+COBJS    := cpu.o traps.o interrupts.o reset.o serial.o watchdog.o
 
 ifeq ($(CONFIG_BFIN_BOOT_MODE),BFIN_BOOT_BYPASS)
 COBJS    += initcode.o
diff --git a/cpu/blackfin/i2c.c b/cpu/blackfin/i2c.c
deleted file mode 100644
index 47be258..0000000
--- a/cpu/blackfin/i2c.c
+++ /dev/null
@@ -1,444 +0,0 @@
-/*
- * i2c.c - driver for Blackfin on-chip TWI/I2C
- *
- * Copyright (c) 2006-2008 Analog Devices Inc.
- *
- * Licensed under the GPL-2 or later.
- */
-
-#include <common.h>
-
-#ifdef CONFIG_HARD_I2C
-
-#include <asm/blackfin.h>
-#include <i2c.h>
-#include <asm/io.h>
-#include <asm/mach-common/bits/twi.h>
-
-/* Two-Wire Interface		(0xFFC01400 - 0xFFC014FF) */
-#ifdef TWI0_CLKDIV
-#define bfin_read_TWI_CLKDIV()               bfin_read_TWI0_CLKDIV()
-#define bfin_write_TWI_CLKDIV(val)           bfin_write_TWI0_CLKDIV(val)
-#define bfin_read_TWI_CONTROL()              bfin_read_TWI0_CONTROL()
-#define bfin_write_TWI_CONTROL(val)          bfin_write_TWI0_CONTROL(val)
-#define bfin_read_TWI_SLAVE_CTL()            bfin_read_TWI0_SLAVE_CTL()
-#define bfin_write_TWI_SLAVE_CTL(val)        bfin_write_TWI0_SLAVE_CTL(val)
-#define bfin_read_TWI_SLAVE_STAT()           bfin_read_TWI0_SLAVE_STAT()
-#define bfin_write_TWI_SLAVE_STAT(val)       bfin_write_TWI0_SLAVE_STAT(val)
-#define bfin_read_TWI_SLAVE_ADDR()           bfin_read_TWI0_SLAVE_ADDR()
-#define bfin_write_TWI_SLAVE_ADDR(val)       bfin_write_TWI0_SLAVE_ADDR(val)
-#define bfin_read_TWI_MASTER_CTL()           bfin_read_TWI0_MASTER_CTL()
-#define bfin_write_TWI_MASTER_CTL(val)       bfin_write_TWI0_MASTER_CTL(val)
-#define bfin_read_TWI_MASTER_STAT()          bfin_read_TWI0_MASTER_STAT()
-#define bfin_write_TWI_MASTER_STAT(val)      bfin_write_TWI0_MASTER_STAT(val)
-#define bfin_read_TWI_MASTER_ADDR()          bfin_read_TWI0_MASTER_ADDR()
-#define bfin_write_TWI_MASTER_ADDR(val)      bfin_write_TWI0_MASTER_ADDR(val)
-#define bfin_read_TWI_INT_STAT()             bfin_read_TWI0_INT_STAT()
-#define bfin_write_TWI_INT_STAT(val)         bfin_write_TWI0_INT_STAT(val)
-#define bfin_read_TWI_INT_MASK()             bfin_read_TWI0_INT_MASK()
-#define bfin_write_TWI_INT_MASK(val)         bfin_write_TWI0_INT_MASK(val)
-#define bfin_read_TWI_FIFO_CTL()             bfin_read_TWI0_FIFO_CTL()
-#define bfin_write_TWI_FIFO_CTL(val)         bfin_write_TWI0_FIFO_CTL(val)
-#define bfin_read_TWI_FIFO_STAT()            bfin_read_TWI0_FIFO_STAT()
-#define bfin_write_TWI_FIFO_STAT(val)        bfin_write_TWI0_FIFO_STAT(val)
-#define bfin_read_TWI_XMT_DATA8()            bfin_read_TWI0_XMT_DATA8()
-#define bfin_write_TWI_XMT_DATA8(val)        bfin_write_TWI0_XMT_DATA8(val)
-#define bfin_read_TWI_XMT_DATA_16()          bfin_read_TWI0_XMT_DATA16()
-#define bfin_write_TWI_XMT_DATA16(val)       bfin_write_TWI0_XMT_DATA16(val)
-#define bfin_read_TWI_RCV_DATA8()            bfin_read_TWI0_RCV_DATA8()
-#define bfin_write_TWI_RCV_DATA8(val)        bfin_write_TWI0_RCV_DATA8(val)
-#define bfin_read_TWI_RCV_DATA16()           bfin_read_TWI0_RCV_DATA16()
-#define bfin_write_TWI_RCV_DATA16(val)       bfin_write_TWI0_RCV_DATA16(val)
-#endif
-
-#ifdef DEBUG_I2C
-#define PRINTD(fmt,args...)	do {	\
-	DECLARE_GLOBAL_DATA_PTR;	\
-	if (gd->have_console)		\
-		printf(fmt ,##args);	\
-	} while (0)
-#else
-#define PRINTD(fmt,args...)
-#endif
-
-#ifndef CONFIG_TWICLK_KHZ
-#define CONFIG_TWICLK_KHZ	50
-#endif
-
-/* All transfers are described by this data structure */
-struct i2c_msg {
-	u16 addr;		/* slave address */
-	u16 flags;
-#define I2C_M_STOP		0x2
-#define I2C_M_RD		0x1
-	u16 len;		/* msg length */
-	u8 *buf;		/* pointer to msg data */
-};
-
-/**
- * i2c_reset: - reset the host controller
- */
-static void i2c_reset(void)
-{
-	/* Disable TWI */
-	bfin_write_TWI_CONTROL(0);
-	SSYNC();
-
-	/* Set TWI internal clock as 10MHz */
-	bfin_write_TWI_CONTROL(((get_sclk() / 1024 / 1024 + 5) / 10) & 0x7F);
-
-	/* Set Twi interface clock as specified */
-	if (CONFIG_TWICLK_KHZ > 400)
-		bfin_write_TWI_CLKDIV(((5 * 1024 / 400) << 8) | ((5 * 1024 /
-						400) & 0xFF));
-	else
-		bfin_write_TWI_CLKDIV(((5 * 1024 /
-					CONFIG_TWICLK_KHZ) << 8) | ((5 * 1024 /
-						CONFIG_TWICLK_KHZ)
-						& 0xFF));
-
-	/* Enable TWI */
-	bfin_write_TWI_CONTROL(bfin_read_TWI_CONTROL() | TWI_ENA);
-	SSYNC();
-}
-
-int wait_for_completion(struct i2c_msg *msg, int timeout_count)
-{
-	unsigned short twi_int_stat;
-	unsigned short mast_stat;
-	int i;
-
-	for (i = 0; i < timeout_count; i++) {
-		twi_int_stat = bfin_read_TWI_INT_STAT();
-		mast_stat = bfin_read_TWI_MASTER_STAT();
-
-		if (XMTSERV & twi_int_stat) {
-			/* Transmit next data */
-			if (msg->len > 0) {
-				bfin_write_TWI_XMT_DATA8(*(msg->buf++));
-				msg->len--;
-			} else if (msg->flags & I2C_M_STOP)
-				bfin_write_TWI_MASTER_CTL
-				    (bfin_read_TWI_MASTER_CTL() | STOP);
-			SSYNC();
-			/* Clear status */
-			bfin_write_TWI_INT_STAT(XMTSERV);
-			SSYNC();
-			i = 0;
-		}
-		if (RCVSERV & twi_int_stat) {
-			if (msg->len > 0) {
-				/* Receive next data */
-				*(msg->buf++) = bfin_read_TWI_RCV_DATA8();
-				msg->len--;
-			} else if (msg->flags & I2C_M_STOP) {
-				bfin_write_TWI_MASTER_CTL
-				    (bfin_read_TWI_MASTER_CTL() | STOP);
-				SSYNC();
-			}
-			/* Clear interrupt source */
-			bfin_write_TWI_INT_STAT(RCVSERV);
-			SSYNC();
-			i = 0;
-		}
-		if (MERR & twi_int_stat) {
-			bfin_write_TWI_INT_STAT(MERR);
-			bfin_write_TWI_INT_MASK(0);
-			bfin_write_TWI_MASTER_STAT(0x3e);
-			bfin_write_TWI_MASTER_CTL(0);
-			SSYNC();
-			/*
-			 * if both err and complete int stats are set,
-			 * return proper results.
-			 */
-			if (MCOMP & twi_int_stat) {
-				bfin_write_TWI_INT_STAT(MCOMP);
-				bfin_write_TWI_INT_MASK(0);
-				bfin_write_TWI_MASTER_CTL(0);
-				SSYNC();
-				/*
-				 * If it is a quick transfer,
-				 * only address bug no data, not an err.
-				 */
-				if (msg->len == 0 && mast_stat & BUFRDERR)
-					return 0;
-				/*
-				 * If address not acknowledged return -3,
-				 * else return 0.
-				 */
-				else if (!(mast_stat & ANAK))
-					return 0;
-				else
-					return -3;
-			}
-			return -1;
-		}
-		if (MCOMP & twi_int_stat) {
-			bfin_write_TWI_INT_STAT(MCOMP);
-			SSYNC();
-			bfin_write_TWI_INT_MASK(0);
-			bfin_write_TWI_MASTER_CTL(0);
-			SSYNC();
-			return 0;
-		}
-	}
-	if (msg->flags & I2C_M_RD)
-		return -4;
-	else
-		return -2;
-}
-
-/**
- * i2c_transfer: - Transfer one byte over the i2c bus
- *
- * This function can tranfer a byte over the i2c bus in both directions.
- * It is used by the public API functions.
- *
- * @return:	 0: transfer successful
- *		-1: transfer fail
- *		-2: transmit timeout
- *		-3: ACK missing
- *		-4: receive timeout
- *		-5: controller not ready
- */
-int i2c_transfer(struct i2c_msg *msg)
-{
-	int ret = 0;
-	int timeout_count = 10000;
-	int len = msg->len;
-
-	if (!(bfin_read_TWI_CONTROL() & TWI_ENA)) {
-		ret = -5;
-		goto transfer_error;
-	}
-
-	while (bfin_read_TWI_MASTER_STAT() & BUSBUSY)
-		continue;
-
-	/* Set Transmit device address */
-	bfin_write_TWI_MASTER_ADDR(msg->addr);
-
-	/*
-	 * FIFO Initiation.
-	 * Data in FIFO should be discarded before start a new operation.
-	 */
-	bfin_write_TWI_FIFO_CTL(0x3);
-	SSYNC();
-	bfin_write_TWI_FIFO_CTL(0);
-	SSYNC();
-
-	if (!(msg->flags & I2C_M_RD)) {
-		/* Transmit first data */
-		if (msg->len > 0) {
-			PRINTD("1 in i2c_transfer: buf=%d, len=%d\n", *msg->buf,
-			       len);
-			bfin_write_TWI_XMT_DATA8(*(msg->buf++));
-			msg->len--;
-			SSYNC();
-		}
-	}
-
-	/* clear int stat */
-	bfin_write_TWI_INT_STAT(MERR | MCOMP | XMTSERV | RCVSERV);
-
-	/* Interrupt mask . Enable XMT, RCV interrupt */
-	bfin_write_TWI_INT_MASK(MCOMP | MERR |
-			((msg->flags & I2C_M_RD) ? RCVSERV : XMTSERV));
-	SSYNC();
-
-	if (len > 0 && len <= 255)
-		bfin_write_TWI_MASTER_CTL((len << 6));
-	else if (msg->len > 255) {
-		bfin_write_TWI_MASTER_CTL((0xff << 6));
-		msg->flags &= I2C_M_STOP;
-	} else
-		bfin_write_TWI_MASTER_CTL(0);
-
-	/* Master enable */
-	bfin_write_TWI_MASTER_CTL(bfin_read_TWI_MASTER_CTL() | MEN |
-			((msg->flags & I2C_M_RD)
-			 ? MDIR : 0) | ((CONFIG_TWICLK_KHZ >
-					 100) ? FAST : 0));
-	SSYNC();
-
-	ret = wait_for_completion(msg, timeout_count);
-	PRINTD("3 in i2c_transfer: ret=%d\n", ret);
-
- transfer_error:
-	switch (ret) {
-	case 1:
-		PRINTD(("i2c_transfer: error: transfer fail\n"));
-		break;
-	case 2:
-		PRINTD(("i2c_transfer: error: transmit timeout\n"));
-		break;
-	case 3:
-		PRINTD(("i2c_transfer: error: ACK missing\n"));
-		break;
-	case 4:
-		PRINTD(("i2c_transfer: error: receive timeout\n"));
-		break;
-	case 5:
-		PRINTD(("i2c_transfer: error: controller not ready\n"));
-		i2c_reset();
-		break;
-	default:
-		break;
-	}
-	return ret;
-
-}
-
-/* ---------------------------------------------------------------------*/
-/* API Functions							*/
-/* ---------------------------------------------------------------------*/
-
-void i2c_init(int speed, int slaveaddr)
-{
-	i2c_reset();
-}
-
-/**
- * i2c_probe: - Test if a chip answers for a given i2c address
- *
- * @chip:	address of the chip which is searched for
- * @return: 	0 if a chip was found, -1 otherwhise
- */
-
-int i2c_probe(uchar chip)
-{
-	struct i2c_msg msg;
-	u8 probebuf;
-
-	i2c_reset();
-
-	probebuf = 0;
-	msg.addr = chip;
-	msg.flags = 0;
-	msg.len = 1;
-	msg.buf = &probebuf;
-	if (i2c_transfer(&msg))
-		return -1;
-
-	msg.addr = chip;
-	msg.flags = I2C_M_RD;
-	msg.len = 1;
-	msg.buf = &probebuf;
-	if (i2c_transfer(&msg))
-		return -1;
-
-	return 0;
-}
-
-/**
- *   i2c_read: - Read multiple bytes from an i2c device
- *
- *   chip:    I2C chip address, range 0..127
- *   addr:    Memory (register) address within the chip
- *   alen:    Number of bytes to use for addr (typically 1, 2 for larger
- *		memories, 0 for register type devices with only one
- *		register)
- *   buffer:  Where to read/write the data
- *   len:     How many bytes to read/write
- *
- *   Returns: 0 on success, not 0 on failure
- */
-
-int i2c_read(uchar chip, uint addr, int alen, uchar * buffer, int len)
-{
-	struct i2c_msg msg;
-	u8 addr_bytes[3];	/* lowest...highest byte of data address */
-
-	PRINTD("i2c_read: chip=0x%x, addr=0x%x, alen=0x%x, len=0x%x\n", chip,
-			addr, alen, len);
-
-	if (alen > 0) {
-		addr_bytes[0] = (u8) ((addr >> 0) & 0x000000FF);
-		addr_bytes[1] = (u8) ((addr >> 8) & 0x000000FF);
-		addr_bytes[2] = (u8) ((addr >> 16) & 0x000000FF);
-		msg.addr = chip;
-		msg.flags = 0;
-		msg.len = alen;
-		msg.buf = addr_bytes;
-		if (i2c_transfer(&msg))
-			return -1;
-	}
-
-	/* start read sequence */
-	PRINTD(("i2c_read: start read sequence\n"));
-	msg.addr = chip;
-	msg.flags = I2C_M_RD;
-	msg.len = len;
-	msg.buf = buffer;
-	if (i2c_transfer(&msg))
-		return -1;
-
-	return 0;
-}
-
-/**
- *   i2c_write: -  Write multiple bytes to an i2c device
- *
- *   chip:    I2C chip address, range 0..127
- *   addr:    Memory (register) address within the chip
- *   alen:    Number of bytes to use for addr (typically 1, 2 for larger
- *		memories, 0 for register type devices with only one
- *		register)
- *   buffer:  Where to read/write the data
- *   len:     How many bytes to read/write
- *
- *   Returns: 0 on success, not 0 on failure
- */
-
-int i2c_write(uchar chip, uint addr, int alen, uchar * buffer, int len)
-{
-	struct i2c_msg msg;
-	u8 addr_bytes[3];	/* lowest...highest byte of data address */
-
-	PRINTD
-		("i2c_write: chip=0x%x, addr=0x%x, alen=0x%x, len=0x%x, buf0=0x%x\n",
-		 chip, addr, alen, len, buffer[0]);
-
-	/* chip address write */
-	if (alen > 0) {
-		addr_bytes[0] = (u8) ((addr >> 0) & 0x000000FF);
-		addr_bytes[1] = (u8) ((addr >> 8) & 0x000000FF);
-		addr_bytes[2] = (u8) ((addr >> 16) & 0x000000FF);
-		msg.addr = chip;
-		msg.flags = 0;
-		msg.len = alen;
-		msg.buf = addr_bytes;
-		if (i2c_transfer(&msg))
-			return -1;
-	}
-
-	/* start read sequence */
-	PRINTD(("i2c_write: start write sequence\n"));
-	msg.addr = chip;
-	msg.flags = 0;
-	msg.len = len;
-	msg.buf = buffer;
-	if (i2c_transfer(&msg))
-		return -1;
-
-	return 0;
-
-}
-
-uchar i2c_reg_read(uchar chip, uchar reg)
-{
-	uchar buf;
-
-	PRINTD("i2c_reg_read: chip=0x%02x, reg=0x%02x\n", chip, reg);
-	i2c_read(chip, reg, 0, &buf, 1);
-	return (buf);
-}
-
-void i2c_reg_write(uchar chip, uchar reg, uchar val)
-{
-	PRINTD("i2c_reg_write: chip=0x%02x, reg=0x%02x, val=0x%02x\n", chip,
-			reg, val);
-	i2c_write(chip, reg, 0, &val, 1);
-}
-
-#endif /* CONFIG_HARD_I2C */
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 071ef00..0ad23ef 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -25,6 +25,7 @@ include $(TOPDIR)/config.mk
 
 LIB 	:= $(obj)libi2c.a
 
+COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
 COBJS-y += fsl_i2c.o
 COBJS-y += omap1510_i2c.o
 COBJS-y += omap24xx_i2c.o
diff --git a/drivers/i2c/bfin-twi_i2c.c b/drivers/i2c/bfin-twi_i2c.c
new file mode 100644
index 0000000..9aceb0a
--- /dev/null
+++ b/drivers/i2c/bfin-twi_i2c.c
@@ -0,0 +1,300 @@
+/*
+ * i2c.c - driver for Blackfin on-chip TWI/I2C
+ *
+ * Copyright (c) 2006-2008 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include <common.h>
+#include <i2c.h>
+
+#include <asm/blackfin.h>
+#include <asm/mach-common/bits/twi.h>
+
+#define debugi(fmt, args...) \
+	debug( \
+		"MSTAT:0x%03x FSTAT:0x%x ISTAT:0x%02x\t" \
+		"%-20s:%-3i: " fmt "\n", \
+		bfin_read_TWI_MASTER_STAT(), bfin_read_TWI_FIFO_STAT(), bfin_read_TWI_INT_STAT(), \
+		__func__, __LINE__, ## args)
+
+#ifdef TWI0_CLKDIV
+#define bfin_write_TWI_CLKDIV(val)           bfin_write_TWI0_CLKDIV(val)
+#define bfin_write_TWI_CONTROL(val)          bfin_write_TWI0_CONTROL(val)
+#define bfin_read_TWI_CONTROL(val)           bfin_read_TWI0_CONTROL(val)
+#define bfin_write_TWI_MASTER_ADDR(val)      bfin_write_TWI0_MASTER_ADDR(val)
+#define bfin_write_TWI_XMT_DATA8(val)        bfin_write_TWI0_XMT_DATA8(val)
+#define bfin_read_TWI_RCV_DATA8()            bfin_read_TWI0_RCV_DATA8()
+#define bfin_read_TWI_INT_STAT()             bfin_read_TWI0_INT_STAT()
+#define bfin_write_TWI_INT_STAT(val)         bfin_write_TWI0_INT_STAT(val)
+#define bfin_read_TWI_MASTER_STAT()          bfin_read_TWI0_MASTER_STAT()
+#define bfin_write_TWI_MASTER_STAT(val)      bfin_write_TWI0_MASTER_STAT(val)
+#define bfin_read_TWI_MASTER_CTL()           bfin_read_TWI0_MASTER_CTL()
+#define bfin_write_TWI_MASTER_CTL(val)       bfin_write_TWI0_MASTER_CTL(val)
+#define bfin_write_TWI_INT_MASK(val)         bfin_write_TWI0_INT_MASK(val)
+#define bfin_write_TWI_FIFO_CTL(val)         bfin_write_TWI0_FIFO_CTL(val)
+#endif
+
+#ifdef CONFIG_TWICLK_KHZ
+# error do not define CONFIG_TWICLK_KHZ ... use CFG_I2C_SPEED
+#endif
+#if CFG_I2C_SPEED > 400000
+# error The Blackfin I2C hardware can only operate at 400KHz max
+#endif
+
+/* All transfers are described by this data structure */
+struct i2c_msg {
+	u8 flags;
+#define I2C_M_COMBO		0x4
+#define I2C_M_STOP		0x2
+#define I2C_M_READ		0x1
+	int len;		/* msg length */
+	u8 *buf;		/* pointer to msg data */
+	int alen;		/* addr length */
+	u8 *abuf;		/* addr buffer */
+};
+
+/**
+ *	wait_for_completion: manage the transfer
+ */
+static int wait_for_completion(struct i2c_msg *msg)
+{
+	uint16_t int_stat;
+
+	while (!ctrlc()) {
+		int_stat = bfin_read_TWI_INT_STAT();
+
+		if (int_stat & XMTSERV) {
+			debugi("processing XMTSERV");
+			bfin_write_TWI_INT_STAT(XMTSERV);
+			SSYNC();
+			if (msg->alen) {
+				bfin_write_TWI_XMT_DATA8(*(msg->abuf++));
+				--msg->alen;
+			} else if (!(msg->flags & I2C_M_COMBO) && msg->len) {
+				bfin_write_TWI_XMT_DATA8(*(msg->buf++));
+				--msg->len;
+			} else {
+				bfin_write_TWI_MASTER_CTL(bfin_read_TWI_MASTER_CTL() |
+					(msg->flags & I2C_M_COMBO ? RSTART | MDIR : STOP));
+				SSYNC();
+			}
+		}
+		if (int_stat & RCVSERV) {
+			debugi("processing RCVSERV");
+			bfin_write_TWI_INT_STAT(RCVSERV);
+			SSYNC();
+			if (msg->len) {
+				*(msg->buf++) = bfin_read_TWI_RCV_DATA8();
+				--msg->len;
+			} else if (msg->flags & I2C_M_STOP) {
+				bfin_write_TWI_MASTER_CTL(bfin_read_TWI_MASTER_CTL() | STOP);
+				SSYNC();
+			}
+		}
+		if (int_stat & MERR) {
+			debugi("processing MERR");
+			bfin_write_TWI_INT_STAT(MERR);
+			SSYNC();
+			break;
+		}
+		if (int_stat & MCOMP) {
+			debugi("processing MCOMP");
+			bfin_write_TWI_INT_STAT(MCOMP);
+			SSYNC();
+			if (msg->flags & I2C_M_COMBO && msg->len) {
+				bfin_write_TWI_MASTER_CTL((bfin_read_TWI_MASTER_CTL() & ~RSTART) |
+					(min(msg->len, 0xff) << 6) | MEN | MDIR);
+				SSYNC();
+			} else
+				break;
+		}
+	}
+
+	return msg->len;
+}
+
+/**
+ * i2c_transfer - setup an i2c transfer
+ *
+ *	Here we just get the i2c stuff all prepped and ready, and then tail off
+ *	into wait_for_completion() for all the bits to go.
+ *
+ *	@return:	0 if things worked, non-0 if things failed
+ */
+static int i2c_transfer(uchar chip, uint addr, int alen, uchar *buffer, int len, u8 flags)
+{
+	uchar addr_buffer[] = {
+		(addr >>  0),
+		(addr >>  8),
+		(addr >> 16),
+	};
+	struct i2c_msg msg = {
+		.flags = flags | (len >= 0xff ? I2C_M_STOP : 0),
+		.buf   = buffer,
+		.len   = len,
+		.abuf  = addr_buffer,
+		.alen  = alen,
+	};
+	int ret;
+
+	memset(buffer, 0xff, len);
+	debugi("chip=0x%x addr=0x%02x alen=%i buf[0]=0x%02x len=%i flags=0x%02x[%s] ",
+		chip, addr, alen, buffer[0], len, flags, (flags & I2C_M_READ ? "rd" : "wr"));
+
+	/* wait for things to settle */
+	while (bfin_read_TWI_MASTER_STAT() & BUSBUSY)
+		if (ctrlc())
+			return 1;
+
+	/* Set Transmit device address */
+	bfin_write_TWI_MASTER_ADDR(chip);
+
+	/* Clear the FIFO before starting things */
+	bfin_write_TWI_FIFO_CTL(XMTFLUSH | RCVFLUSH);
+	SSYNC();
+	bfin_write_TWI_FIFO_CTL(0);
+	SSYNC();
+
+	/* prime the pump */
+	if (msg.alen) {
+		len = msg.alen;
+		debugi("first byte=0x%02x", *msg.abuf);
+		bfin_write_TWI_XMT_DATA8(*(msg.abuf++));
+		--msg.alen;
+	} else if (!(msg.flags & I2C_M_READ) && msg.len) {
+		debugi("first byte=0x%02x", *msg.buf);
+		bfin_write_TWI_XMT_DATA8(*(msg.buf++));
+		--msg.len;
+	}
+
+	/* clear int stat */
+	bfin_write_TWI_MASTER_STAT(-1);
+	bfin_write_TWI_INT_STAT(-1);
+	bfin_write_TWI_INT_MASK(0);
+	SSYNC();
+
+	/* Master enable */
+	bfin_write_TWI_MASTER_CTL(
+			(bfin_read_TWI_MASTER_CTL() & FAST) |
+			(min(len, 0xff) << 6) | MEN |
+			((msg.flags & I2C_M_READ) ? MDIR : 0)
+	);
+	SSYNC();
+	debugi("CTL=0x%04x", bfin_read_TWI_MASTER_CTL());
+
+	/* process the rest */
+	ret = wait_for_completion(&msg);
+	debugi("ret=%d", ret);
+
+	if (ret) {
+		bfin_write_TWI_MASTER_CTL(bfin_read_TWI_MASTER_CTL() & ~MEN);
+		bfin_write_TWI_CONTROL(bfin_read_TWI_CONTROL() & ~TWI_ENA);
+		SSYNC();
+		bfin_write_TWI_CONTROL(bfin_read_TWI_CONTROL() | TWI_ENA);
+		SSYNC();
+	}
+
+	return ret;
+}
+
+/*
+ * Initialization, must be called once on start up, may be called
+ * repeatedly to change the speed and slave addresses.
+ */
+void i2c_init(int speed, int slaveaddr)
+{
+	uint8_t prescale = ((get_sclk() / 1024 / 1024 + 5) / 10) & 0x7F;
+
+	debugi("CONTROL:0x%04x CLKDIV:0x%04x", prescale,
+        ((5 * 1024 / (speed / 1000)) << 8) |
+        ((5 * 1024 / (speed / 1000)) & 0xFF));
+
+	/* Set TWI internal clock as 10MHz */
+	bfin_write_TWI_CONTROL(prescale);
+
+	/* Set TWI interface clock as specified */
+	bfin_write_TWI_CLKDIV(
+		((5 * 1024 / (speed / 1000)) << 8) |
+		((5 * 1024 / (speed / 1000)) & 0xFF)
+	);
+
+	/* Don't turn it on */
+	bfin_write_TWI_MASTER_CTL(speed > 100000 ? FAST : 0);
+
+	/* But enable it */
+	bfin_write_TWI_CONTROL(TWI_ENA | prescale);
+	SSYNC();
+
+#if CFG_I2C_SLAVE
+# error I2C slave support not tested/supported
+	/* If they want us as a slave, do it */
+	if (slaveaddr) {
+		bfin_write_TWI_SLAVE_ADDR(slaveaddr);
+		bfin_write_TWI_SLAVE_CTL(SEN);
+	}
+#endif
+}
+
+/**
+ * i2c_probe: - Test if a chip answers for a given i2c address
+ *
+ * @chip:	address of the chip which is searched for
+ * @return: 	0 if a chip was found, -1 otherwhise
+ */
+int i2c_probe(uchar chip)
+{
+	u8 byte;
+	return i2c_read(chip, 0, 0, &byte, 1);
+}
+
+/**
+ *   i2c_read: - Read multiple bytes from an i2c device
+ *
+ *   chip:    I2C chip address, range 0..127
+ *   addr:    Memory (register) address within the chip
+ *   alen:    Number of bytes to use for addr (typically 1, 2 for larger
+ *              memories, 0 for register type devices with only one
+ *              register)
+ *   buffer:  Where to read/write the data
+ *   len:     How many bytes to read/write
+ *
+ *   Returns: 0 on success, not 0 on failure
+ */
+int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int len)
+{
+	return i2c_transfer(chip, addr, alen, buffer, len, (alen ? I2C_M_COMBO : I2C_M_READ));
+}
+
+/**
+ *   i2c_write: -  Write multiple bytes to an i2c device
+ *
+ *   chip:    I2C chip address, range 0..127
+ *   addr:    Memory (register) address within the chip
+ *   alen:    Number of bytes to use for addr (typically 1, 2 for larger
+ *              memories, 0 for register type devices with only one
+ *              register)
+ *   buffer:  Where to read/write the data
+ *   len:     How many bytes to read/write
+ *
+ *   Returns: 0 on success, not 0 on failure
+ */
+int i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len)
+{
+	return i2c_transfer(chip, addr, alen, buffer, len, 0);
+}
+
+/*
+ * Utility routines to read/write registers.
+ */
+uchar i2c_reg_read(uchar chip, uchar reg)
+{
+	uchar buf;
+	i2c_read(chip, reg, 1, &buf, 1);
+	return buf;
+}
+void i2c_reg_write(uchar chip, uchar reg, uchar val)
+{
+	i2c_write(chip, reg, 1, &val, 1);
+}
diff --git a/include/configs/bf533-ezkit.h b/include/configs/bf533-ezkit.h
index 2f551ad..f267301 100644
--- a/include/configs/bf533-ezkit.h
+++ b/include/configs/bf533-ezkit.h
@@ -198,7 +198,7 @@
 #define I2C_DELAY	udelay(5)	/* 1/4 I2C clock duration */
 
 #define CFG_I2C_SPEED		50000
-#define CFG_I2C_SLAVE		0xFE
+#define CFG_I2C_SLAVE		0
 
 #define CFG_BOOTM_LEN		0x4000000	/* Large Image Length, set to 64 Meg */
 
diff --git a/include/configs/bf533-stamp.h b/include/configs/bf533-stamp.h
index 66a0af6..feadf86 100644
--- a/include/configs/bf533-stamp.h
+++ b/include/configs/bf533-stamp.h
@@ -300,7 +300,7 @@
 #define I2C_DELAY		udelay(5)	/* 1/4 I2C clock duration */
 
 #define CFG_I2C_SPEED		50000
-#define CFG_I2C_SLAVE		0xFE
+#define CFG_I2C_SLAVE		0
 #endif /* CONFIG_SOFT_I2C */
 
 /*
diff --git a/include/configs/bf537-stamp.h b/include/configs/bf537-stamp.h
index 39c7359..d4bac82 100644
--- a/include/configs/bf537-stamp.h
+++ b/include/configs/bf537-stamp.h
@@ -306,13 +306,11 @@
 
 /*
  * I2C settings
- * By default PF1 is used as SDA and PF0 as SCL on the Stamp board
  */
-/* #define CONFIG_SOFT_I2C	1*/	/* I2C bit-banged */
-#define CONFIG_HARD_I2C		1	/* I2C TWI */
-#if defined CONFIG_HARD_I2C
-#define CONFIG_TWICLK_KHZ	50
-#endif
+#define CONFIG_HARD_I2C		1
+#define CONFIG_BFIN_TWI_I2C	1
+#define CFG_I2C_SPEED		50000
+#define CFG_I2C_SLAVE		0
 
 #define CONFIG_EBIU_SDRRC_VAL  0x306
 #define CONFIG_EBIU_SDGCTL_VAL 0x91114d
@@ -322,39 +320,6 @@
 #define CONFIG_EBIU_AMBCTL0_VAL		0x7BB07BB0
 #define CONFIG_EBIU_AMBCTL1_VAL		0xFFC27BB0
 
-#if defined CONFIG_SOFT_I2C
-/*
- * Software (bit-bang) I2C driver configuration
- */
-#define PF_SCL			PF0
-#define PF_SDA			PF1
-
-#define I2C_INIT		(*pFIO_DIR |=  PF_SCL); asm("ssync;")
-#define I2C_ACTIVE		(*pFIO_DIR |=  PF_SDA); *pFIO_INEN &= ~PF_SDA; asm("ssync;")
-#define I2C_TRISTATE		(*pFIO_DIR &= ~PF_SDA); *pFIO_INEN |= PF_SDA; asm("ssync;")
-#define I2C_READ		((volatile)(*pFIO_FLAG_D & PF_SDA) != 0); asm("ssync;")
-#define I2C_SDA(bit)		if(bit) { \
-					*pFIO_FLAG_S = PF_SDA; \
-					asm("ssync;"); \
-					} \
-				else    { \
-					*pFIO_FLAG_C = PF_SDA; \
-					asm("ssync;"); \
-					}
-#define I2C_SCL(bit)		if(bit) { \
-					*pFIO_FLAG_S = PF_SCL; \
-					asm("ssync;"); \
-					} \
-				else    { \
-					*pFIO_FLAG_C = PF_SCL; \
-					asm("ssync;"); \
-					}
-#define I2C_DELAY		udelay(5)	/* 1/4 I2C clock duration */
-#endif
-
-#define CFG_I2C_SPEED		50000
-#define CFG_I2C_SLAVE		0xFE
-
 /* 0xFF, 0x7BB07BB0, 0x22547BB0 */
 /* #define AMGCTLVAL		(AMBEN_P0 | AMBEN_P1 | AMBEN_P2 | AMCKEN)
 #define AMBCTL0VAL		(B1WAT_7 | B1RAT_11 | B1HT_2 | B1ST_3 | B1TT_4 | ~B1RDYPOL | \
-- 
1.5.5




From plagnioj at jcrosoft.com  Sat Apr 19 07:07:55 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 19 Apr 2008 07:07:55 +0200
Subject: [U-Boot-Users] [PATCH/review] Blackfin: overhaul i2c driver
In-Reply-To: <1208565421-19690-1-git-send-email-vapier@gentoo.org>
References: <1208565421-19690-1-git-send-email-vapier@gentoo.org>
Message-ID: <20080419050755.GC12486@game.jcrosoft.org>

On 20:37 Fri 18 Apr     , Mike Frysinger wrote:
> The current Blackfin i2c driver does not work properly with certain devices
> due to it breaking up transfers incorrectly.  This is a rewrite of the
> driver and relocates it to the newer place in the source tree.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
> I couldn't get git-format-patch to detect the rename (tried -B, -M, and -C),
> but the resulting diff between the files isn't terribly readable in the
> first place, so it shouldn't be that big of a deal.
> 
>  cpu/blackfin/Makefile         |    2 +-
>  cpu/blackfin/i2c.c            |  444 -----------------------------------------
>  drivers/i2c/Makefile          |    1 +
>  drivers/i2c/bfin-twi_i2c.c    |  300 +++++++++++++++++++++++++++
>  include/configs/bf533-ezkit.h |    2 +-
>  include/configs/bf533-stamp.h |    2 +-
>  include/configs/bf537-stamp.h |   43 +----
>  7 files changed, 308 insertions(+), 486 deletions(-)
>  delete mode 100644 cpu/blackfin/i2c.c
>  create mode 100644 drivers/i2c/bfin-twi_i2c.c
> 
> new file mode 100644
> index 0000000..9aceb0a
> --- /dev/null
> +++ b/drivers/i2c/bfin-twi_i2c.c
> @@ -0,0 +1,300 @@
> +/*
> + * i2c.c - driver for Blackfin on-chip TWI/I2C
> + *
> + * Copyright (c) 2006-2008 Analog Devices Inc.
> + *
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#include <common.h>
> +#include <i2c.h>
> +
> +#include <asm/blackfin.h>
> +#include <asm/mach-common/bits/twi.h>
> +
> +#define debugi(fmt, args...) \
> +	debug( \
> +		"MSTAT:0x%03x FSTAT:0x%x ISTAT:0x%02x\t" \
> +		"%-20s:%-3i: " fmt "\n", \
> +		bfin_read_TWI_MASTER_STAT(), bfin_read_TWI_FIFO_STAT(), bfin_read_TWI_INT_STAT(), \
could you split it
> +		__func__, __LINE__, ## args)
> +
<snip>
> +#if CFG_I2C_SLAVE
> +# error I2C slave support not tested/supported
> +	/* If they want us as a slave, do it */
> +	if (slaveaddr) {
> +		bfin_write_TWI_SLAVE_ADDR(slaveaddr);
> +		bfin_write_TWI_SLAVE_CTL(SEN);
> +	}
> +#endif
> +}
> +
> +/**
> + * i2c_probe: - Test if a chip answers for a given i2c address
> + *
> + * @chip:	address of the chip which is searched for
> + * @return: 	0 if a chip was found, -1 otherwhise
              ^
whitespace
> + */
> +int i2c_probe(uchar chip)
> +{
> +	u8 byte;
add an empty line
> +	return i2c_read(chip, 0, 0, &byte, 1);
> +}
> +
> +/**
> + *   i2c_read: - Read multiple bytes from an i2c device
> + *
> + *   chip:    I2C chip address, range 0..127
> + *   addr:    Memory (register) address within the chip
> + *   alen:    Number of bytes to use for addr (typically 1, 2 for larger
> + *              memories, 0 for register type devices with only one
> + *              register)
> + *   buffer:  Where to read/write the data
> + *   len:     How many bytes to read/write
> + *
> + *   Returns: 0 on success, not 0 on failure
> + */
> +int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int len)
> +{
> +	return i2c_transfer(chip, addr, alen, buffer, len, (alen ? I2C_M_COMBO : I2C_M_READ));
> +}
> +
> +/**
> + *   i2c_write: -  Write multiple bytes to an i2c device
> + *
> + *   chip:    I2C chip address, range 0..127
> + *   addr:    Memory (register) address within the chip
> + *   alen:    Number of bytes to use for addr (typically 1, 2 for larger
> + *              memories, 0 for register type devices with only one
> + *              register)
> + *   buffer:  Where to read/write the data
> + *   len:     How many bytes to read/write
> + *
> + *   Returns: 0 on success, not 0 on failure
> + */
> +int i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len)
> +{
> +	return i2c_transfer(chip, addr, alen, buffer, len, 0);
> +}
> +
> +/*
> + * Utility routines to read/write registers.
> + */
> +uchar i2c_reg_read(uchar chip, uchar reg)
> +{
> +	uchar buf;
add an empty line
> +	i2c_read(chip, reg, 1, &buf, 1);
> +	return buf;
> +}
add an empty line
> +void i2c_reg_write(uchar chip, uchar reg, uchar val)
> +{
> +	i2c_write(chip, reg, 1, &val, 1);
> +}
> diff --git a/include/configs/bf533-ezkit.h b/include/configs/bf533-ezkit.h
> index 2f551ad..f267301 100644
> --- a/include/configs/bf533-ezkit.h
> +++ b/include/configs/bf533-ezkit.h
> @@ -198,7 +198,7 @@
>  #define I2C_DELAY	udelay(5)	/* 1/4 I2C clock duration */
>  
>  #define CFG_I2C_SPEED		50000
> -#define CFG_I2C_SLAVE		0xFE
> +#define CFG_I2C_SLAVE		0
>  
>  #define CFG_BOOTM_LEN		0x4000000	/* Large Image Length, set to 64 Meg */
>  
> diff --git a/include/configs/bf533-stamp.h b/include/configs/bf533-stamp.h
> index 66a0af6..feadf86 100644
> --- a/include/configs/bf533-stamp.h
> +++ b/include/configs/bf533-stamp.h
> @@ -300,7 +300,7 @@
>  #define I2C_DELAY		udelay(5)	/* 1/4 I2C clock duration */
>  
>  #define CFG_I2C_SPEED		50000
> -#define CFG_I2C_SLAVE		0xFE
> +#define CFG_I2C_SLAVE		0
Could you comment this in the commit please.

Best Regards,
J.



From vapier at gentoo.org  Sat Apr 19 07:45:50 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sat, 19 Apr 2008 01:45:50 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
Message-ID: <1208583950-9454-1-git-send-email-vapier@gentoo.org>

Override the default go/boote handlers as we want to disable both data and
instruction cache before executing external programs (since Blackfin cache
handling requires a software handler in U-Boot which may be overwritten).

Signed-off-by: Mike Frysinger <vapier at gentoo.org>
---
 lib_blackfin/Makefile            |    2 +-
 lib_blackfin/{bootm.c => boot.c} |   20 ++++++++++++++++++++
 2 files changed, 21 insertions(+), 1 deletions(-)
 rename lib_blackfin/{bootm.c => boot.c} (80%)

diff --git a/lib_blackfin/Makefile b/lib_blackfin/Makefile
index 3617104..879c37f 100644
--- a/lib_blackfin/Makefile
+++ b/lib_blackfin/Makefile
@@ -37,7 +37,7 @@ SOBJS-y	+= memmove.o
 SOBJS-y	+= memset.o
 
 COBJS-y	+= board.o
-COBJS-y	+= bootm.o
+COBJS-y	+= boot.o
 COBJS-y	+= cache.o
 COBJS-y	+= muldi3.o
 COBJS-y	+= post.o
diff --git a/lib_blackfin/bootm.c b/lib_blackfin/boot.c
similarity index 80%
rename from lib_blackfin/bootm.c
rename to lib_blackfin/boot.c
index ef4b112..5ea4afb 100644
--- a/lib_blackfin/bootm.c
+++ b/lib_blackfin/boot.c
@@ -77,3 +77,23 @@ void do_bootm_linux(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[],
 	if (images->autostart)
 		do_reset (cmdtp, flag, argc, argv);
 }
+
+unsigned long do_go_exec(ulong (*entry)(int, char *[]), int argc, char *argv[])
+{
+	int d = dcache_status();
+	int i = icache_status();
+
+	dcache_disable();
+	icache_disable();
+
+	int ret = entry(argc, argv);
+
+	if (d) dcache_enable();
+	if (i) icache_enable();
+
+	return ret;
+}
+unsigned long do_bootelf_exec(ulong (*entry)(int, char *[]), int argc, char *argv[])
+{
+	return do_go_exec(entry, argc, argv);
+}
-- 
1.5.5




From matthias.fuchs at esd-electronics.com  Sat Apr 19 13:30:04 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Sat, 19 Apr 2008 13:30:04 +0200
Subject: [U-Boot-Users]
	=?iso-8859-1?q?=5BPATCH=5D_cfi-flash=3A_Add=09CFG?=
	=?iso-8859-1?q?=5FFLASH=5FAUTOPROTECT=5FLIST?=
In-Reply-To: <20080418160157.GB12486@game.jcrosoft.org>
References: <200804181629.40697.matthias.fuchs@esd-electronics.com>
	<20080418160157.GB12486@game.jcrosoft.org>
Message-ID: <200804191330.04925.matthias.fuchs@esd-electronics.com>

Hi Jean-Christophe,

is it possible to use weak structures? Or do you mean
a weak function that initializes my autoprotect list?

Please give me an idea and I will implement it.

Matthias

On Friday 18 April 2008 18:01:57 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> > index e3cfb8a..68ab55f 100644
> > --- a/drivers/mtd/cfi_flash.c
> > +++ b/drivers/mtd/cfi_flash.c
> > @@ -1873,6 +1873,12 @@ unsigned long flash_init (void)
> >  {
> >  	unsigned long size = 0;
> >  	int i;
> > +#if defined(CFG_FLASH_AUTOPROTECT_LIST)
> > +	struct apl_s {
> > +		ulong start;
> > +		ulong size;
> > +	} apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> > +#endif
>
> I think it will be better to create a weak structure.
>
> Best Regards,
> J.



From sr at denx.de  Sat Apr 19 14:02:23 2008
From: sr at denx.de (Stefan Roese)
Date: Sat, 19 Apr 2008 14:02:23 +0200
Subject: [U-Boot-Users]
	=?iso-8859-1?q?=5BPATCH=5D_cfi-flash=3A_Add=09CFG?=
	=?iso-8859-1?q?=5FFLASH=5FAUTOPROTECT=5FLIST?=
In-Reply-To: <200804191330.04925.matthias.fuchs@esd-electronics.com>
References: <200804181629.40697.matthias.fuchs@esd-electronics.com>
	<20080418160157.GB12486@game.jcrosoft.org>
	<200804191330.04925.matthias.fuchs@esd-electronics.com>
Message-ID: <200804191402.23386.sr@denx.de>

Hi Matthias,

On Saturday 19 April 2008, Matthias Fuchs wrote:
> is it possible to use weak structures? Or do you mean
> a weak function that initializes my autoprotect list?
>
> Please give me an idea and I will implement it.

I don't know if it's possible to implement a weak structure, but I
would prefer something like this instead of your original
implementation (no #ifdef's in the code):

struct apl_s {
	u32 start;
	u32 size;
};

#if !defined(CFG_FLASH_AUTOPROTECT_LIST)
struct apl_s apl[] = { };
#else
struct apl_s apl[] = CFG_FLASH_AUTOPROTECT_LIST;
#endif

And then later in the code:

+       for (i = 0; i < ARRAY_SIZE(apl); i++) {
+               debug("autoprotecting from %08x to %08x\n",
+                     apl[i].start, apl[i].start + apl[i].size - 1);
+               flash_protect (FLAG_PROTECT_SET,
+                              apl[i].start,
+                              apl[i].start + apl[i].size - 1,
+                              flash_get_info(apl[i].start));
+       }

What do you think? 
> Matthias
>
> On Friday 18 April 2008 18:01:57 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> > > index e3cfb8a..68ab55f 100644
> > > --- a/drivers/mtd/cfi_flash.c
> > > +++ b/drivers/mtd/cfi_flash.c
> > > @@ -1873,6 +1873,12 @@ unsigned long flash_init (void)
> > >  {
> > >  	unsigned long size = 0;
> > >  	int i;
> > > +#if defined(CFG_FLASH_AUTOPROTECT_LIST)
> > > +	struct apl_s {
> > > +		ulong start;
> > > +		ulong size;
> > > +	} apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> > > +#endif
> >
> > I think it will be better to create a weak structure.
> >
> > Best Regards,
> > J.
>
> !DSPAM:4809d80874783629025813!



-- 
Viele Gr??e,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From gvb.uboot at gmail.com  Sat Apr 19 14:55:58 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Sat, 19 Apr 2008 08:55:58 -0400
Subject: [U-Boot-Users] [PATCH] fix system config overwrite @ MPC834x
In-Reply-To: <20080418112046.ce82252a.kim.phillips@freescale.com>
References: <480788B1.9090208@matrix-vision.de>	<20080417155615.43fa3791.kim.phillips@freescale.com>	<48086073.4060306@matrix-vision.de>
	<20080418112046.ce82252a.kim.phillips@freescale.com>
Message-ID: <4809EBDE.2040905@gmail.com>

Kim Phillips wrote:
> On Fri, 18 Apr 2008 10:48:51 +0200
> Andre Schwarz <andre.schwarz at matrix-vision.de> wrote:
> 
>> Kim,
>>
>> doing a git-pull gives "Already up-to-date."
>> The patch is produced with "git-diff --patch-with-stat 
>> cpu/mpc83xx/cpu_init.c"
> 
> using git-commit and git-format-patch is recommended, but that's
> probably not the problem here.  Have you followed the instructions for
> Thunderbird in linux-2.6/Documentation/email-clients.txt?  You can test
> by using git-am on patches you email yourself.
> 
> Kim

Hi Andre,

Another thing I do when something I think should work doesn't is to make 
a fresh clone of the git repository, apply my new patch to it, and 
regenerate the patch from that.  Sometimes I get confused as to the 
state of my working directory, what has been applied to it, what I've 
pulled from, etc.  (I used to be really sharp, but then I discovered 
beer and the edges are a little duller now.)

FWIIW, I keep a local pristine copy of the denx.de master repository 
(and others I am interested in), doing a nightly pull in a cron job. 
This allows me to make a new working clone of what should be a clean 
repository without hammering denx.de.  Worst case, I hammer denx.de 
occasionally. :-/

Best regards,
gvb



From matthias.fuchs at esd-electronics.com  Sat Apr 19 16:50:32 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Sat, 19 Apr 2008 16:50:32 +0200
Subject: [U-Boot-Users]
	=?iso-8859-1?q?=5BPATCH=5D_cfi-flash=3A_Add=09CFG?=
	=?iso-8859-1?q?=5FFLASH=5FAUTOPROTECT=5FLIST?=
In-Reply-To: <200804191402.23386.sr@denx.de>
References: <200804181629.40697.matthias.fuchs@esd-electronics.com>
	<200804191330.04925.matthias.fuchs@esd-electronics.com>
	<200804191402.23386.sr@denx.de>
Message-ID: <200804191650.32303.matthias.fuchs@esd-electronics.com>

Hi Stefan,

I could also life with your approach, but it will add code
even to platforms that do not use the new option.

In this case I would prefer it against the weak implementation.

Matthias

On Saturday 19 April 2008 14:02:23 Stefan Roese wrote:
> Hi Matthias,
>
> On Saturday 19 April 2008, Matthias Fuchs wrote:
> > is it possible to use weak structures? Or do you mean
> > a weak function that initializes my autoprotect list?
> >
> > Please give me an idea and I will implement it.
>
> I don't know if it's possible to implement a weak structure, but I
> would prefer something like this instead of your original
> implementation (no #ifdef's in the code):
>
> struct apl_s {
> 	u32 start;
> 	u32 size;
> };
>
> #if !defined(CFG_FLASH_AUTOPROTECT_LIST)
> struct apl_s apl[] = { };
> #else
> struct apl_s apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> #endif
>
> And then later in the code:
>
> +       for (i = 0; i < ARRAY_SIZE(apl); i++) {
> +               debug("autoprotecting from %08x to %08x\n",
> +                     apl[i].start, apl[i].start + apl[i].size - 1);
> +               flash_protect (FLAG_PROTECT_SET,
> +                              apl[i].start,
> +                              apl[i].start + apl[i].size - 1,
> +                              flash_get_info(apl[i].start));
> +       }
>
> What do you think?
>
> > Matthias
> >
> > On Friday 18 April 2008 18:01:57 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> > > > index e3cfb8a..68ab55f 100644
> > > > --- a/drivers/mtd/cfi_flash.c
> > > > +++ b/drivers/mtd/cfi_flash.c
> > > > @@ -1873,6 +1873,12 @@ unsigned long flash_init (void)
> > > >  {
> > > >  	unsigned long size = 0;
> > > >  	int i;
> > > > +#if defined(CFG_FLASH_AUTOPROTECT_LIST)
> > > > +	struct apl_s {
> > > > +		ulong start;
> > > > +		ulong size;
> > > > +	} apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> > > > +#endif
> > >
> > > I think it will be better to create a weak structure.
> > >
> > > Best Regards,
> > > J.
> >
> > !DSPAM:4809d80874783629025813!



-- 
-------------------------------------------------------------------------
Dipl.-Ing. Matthias Fuchs
Head of System Design

esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Phone: +49-511-37298-0 - Fax: +49-511-37298-68
Please visit our homepage http://www.esd.eu
Quality Products - Made in Germany
-------------------------------------------------------------------------
Gesch?ftsf?hrer: Klaus Detering, Dr. Werner Schulze
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
-------------------------------------------------------------------------



From plagnioj at jcrosoft.com  Sat Apr 19 17:33:43 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 19 Apr 2008 17:33:43 +0200
Subject: [U-Boot-Users] [PATCH] cfi-flash:	Add?CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: <200804191650.32303.matthias.fuchs@esd-electronics.com>
References: <200804181629.40697.matthias.fuchs@esd-electronics.com>
	<200804191330.04925.matthias.fuchs@esd-electronics.com>
	<200804191402.23386.sr@denx.de>
	<200804191650.32303.matthias.fuchs@esd-electronics.com>
Message-ID: <20080419153342.GA12162@game.jcrosoft.org>

On 16:50 Sat 19 Apr     , Matthias Fuchs wrote:
> Hi Stefan,
> 
> I could also life with your approach, but it will add code
> even to platforms that do not use the new option.
> 
> In this case I would prefer it against the weak implementation.
I've already answer about it to Timur in this e-mail
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/37814/match=weak

I'm preparing a path about adding this define

import compiler-gcc header from linux and add

#ifndef __weak_alias
#ifndef __weak_alias(fct) __attribute__((weak,alias(#fct)))
#endif

so just add __weak to your default stucture and overwrite in the board

Best Regards,
J.



From plagnioj at jcrosoft.com  Sat Apr 19 17:59:20 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 19 Apr 2008 17:59:20 +0200
Subject: [U-Boot-Users] [PATCH] Fix show_boot_progress prototype
Message-ID: <1208620760-23645-1-git-send-email-plagnioj@jcrosoft.com>

in commit fad634071 "make show_boot_progress () weak."
show_boot_progress is supposed to be declared as weak but declare as inline
instead of.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/include/common.h b/include/common.h
index 8630780..eeb6686 100644
--- a/include/common.h
+++ b/include/common.h
@@ -661,7 +661,7 @@ int	pcmcia_init (void);
 /*
  * Board-specific Platform code can reimplement show_boot_progress () if needed
  */
-void inline show_boot_progress (int val);
+void __attribute__((weak)) show_boot_progress (int val);
 
 #ifdef CONFIG_INIT_CRITICAL
 #error CONFIG_INIT_CRITICAL is deprecated!
-- 
1.5.4.5




From plagnioj at jcrosoft.com  Sat Apr 19 18:46:54 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 19 Apr 2008 18:46:54 +0200
Subject: [U-Boot-Users] [PATCH] image: remove inline for
	image_print_contents and image_print_contents_noindent
In-Reply-To: <1208620760-23645-1-git-send-email-plagnioj@jcrosoft.com>
References: <1208620760-23645-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1208623614-26957-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/common/image.c b/common/image.c
index d218f2f..ac033df 100644
--- a/common/image.c
+++ b/common/image.c
@@ -366,12 +366,12 @@ static void __image_print_contents (image_header_t *hdr, const char *p)
 	}
 }
 
-inline void image_print_contents (image_header_t *hdr)
+void image_print_contents (image_header_t *hdr)
 {
 	__image_print_contents (hdr, "   ");
 }
 
-inline void image_print_contents_noindent (image_header_t *hdr)
+void image_print_contents_noindent (image_header_t *hdr)
 {
 	__image_print_contents (hdr, "");
 }
diff --git a/include/image.h b/include/image.h
index 60fdb2b..491d1cb 100644
--- a/include/image.h
+++ b/include/image.h
@@ -392,8 +392,8 @@ ulong image_multi_count (image_header_t *hdr);
 void image_multi_getimg (image_header_t *hdr, ulong idx,
 			ulong *data, ulong *len);
 
-inline void image_print_contents (image_header_t *hdr);
-inline void image_print_contents_noindent (image_header_t *hdr);
+void image_print_contents (image_header_t *hdr);
+void image_print_contents_noindent (image_header_t *hdr);
 
 #ifndef USE_HOSTCC
 static inline int image_check_target_arch (image_header_t *hdr)
-- 
1.5.4.5




From matthias.fuchs at esd-electronics.com  Sat Apr 19 19:22:53 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Sat, 19 Apr 2008 19:22:53 +0200
Subject: [U-Boot-Users]
	=?iso-8859-1?q?=5BPATCH=5D_cfi-flash=3A=09Add=3FCF?=
	=?iso-8859-1?q?G=5FFLASH=5FAUTOPROTECT=5FLIST?=
In-Reply-To: <20080419153342.GA12162@game.jcrosoft.org>
References: <200804181629.40697.matthias.fuchs@esd-electronics.com>
	<200804191650.32303.matthias.fuchs@esd-electronics.com>
	<20080419153342.GA12162@game.jcrosoft.org>
Message-ID: <200804191922.53883.matthias.fuchs@esd-electronics.com>

Hi,

I tried this in cfi_flash.c:

struct apl_s   {
	ulong start;
	ulong size;
}

struct apl_s apl[] __attribute__((weak)) = {};

I added a redeclaration of apl into my board code.

Now I ran into the problem that the ARRAY_SIZE macro
on apl in cfi_flash.c does not take care of the redeclation. So
it evaluated to 0 instead of the real size of the array
from my board code.

Now I could

a) add a delimiter to the apl array (e.g. size=0 for the last entry)
b) implement Stefan approach
c) ???

Any idea?

Matthias

On Saturday 19 April 2008 17:33:43 Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:50 Sat 19 Apr     , Matthias Fuchs wrote:
> > Hi Stefan,
> >
> > I could also life with your approach, but it will add code
> > even to platforms that do not use the new option.
> >
> > In this case I would prefer it against the weak implementation.
>
> I've already answer about it to Timur in this e-mail
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/37814/match=weak
>
> I'm preparing a path about adding this define
>
> import compiler-gcc header from linux and add
>
> #ifndef __weak_alias
> #ifndef __weak_alias(fct) __attribute__((weak,alias(#fct)))
> #endif
>
> so just add __weak to your default stucture and overwrite in the board
>
> Best Regards,
> J.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
>one _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users



-- 
-------------------------------------------------------------------------
Dipl.-Ing. Matthias Fuchs
Head of System Design

esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Phone: +49-511-37298-0 - Fax: +49-511-37298-68
Please visit our homepage http://www.esd.eu
Quality Products - Made in Germany
-------------------------------------------------------------------------
Gesch?ftsf?hrer: Klaus Detering, Dr. Werner Schulze
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
-------------------------------------------------------------------------



From shenzhenshanhudao at 126.com  Sat Apr 19 21:35:55 2008
From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=)
Date: Sun, 20 Apr 2008 03:35:55 +0800
Subject: [U-Boot-Users] (no subject)
Message-ID: <E1JnIqR-0002nf-DQ@mail.sourceforge.net>

?????????
                
    ??????2008?????????????????????????
?
?????????????????? ????????????
    
    ?????????????????????????????????

???????????......???????????????????????

?????????????????????????????????????

???????????
?
                              ???0755-81153047?
?
                              ???0755-81172940?
?
                              ???15817477278?
?
                              ????????
?
   ???
                                                         

                                                                ???



From luigi.mantellini at idf-hit.com  Fri Apr 18 09:50:19 2008
From: luigi.mantellini at idf-hit.com (Luigi 'Comio' Mantellini)
Date: Fri, 18 Apr 2008 09:50:19 +0200
Subject: [U-Boot-Users] [PATCH] Add support for LZMA uncompression algorithm.
In-Reply-To: <20080418041413.2272E248A0@gemini.denx.de>
References: <20080418041413.2272E248A0@gemini.denx.de>
Message-ID: <1208505019-9634-1-git-send-email-luigi.mantellini@idf-hit.com>


Signed-off-by: Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
---
 Makefile                   |    1 +
 README                     |   23 ++
 common/cmd_bootm.c         |   23 ++
 common/image.c             |    7 +-
 include/image.h            |    1 +
 include/lzma/LzmaDecode.h  |   31 ++
 include/lzma/LzmaTools.h   |   31 ++
 include/lzma/LzmaTypes.h   |   31 ++
 lib_lzma/LGPL.txt          |  504 +++++++++++++++++++++++++++++++++
 lib_lzma/LzmaDecode.c      |  584 ++++++++++++++++++++++++++++++++++++++
 lib_lzma/LzmaDecode.h      |  113 ++++++++
 lib_lzma/LzmaTools.c       |  142 ++++++++++
 lib_lzma/LzmaTools.h       |   35 +++
 lib_lzma/LzmaTypes.h       |   45 +++
 lib_lzma/Makefile          |   51 ++++
 lib_lzma/README.txt        |   28 ++
 lib_lzma/history.txt       |  198 +++++++++++++
 lib_lzma/import_lzmasdk.sh |   38 +++
 lib_lzma/lzma.txt          |  663 ++++++++++++++++++++++++++++++++++++++++++++
 19 files changed, 2547 insertions(+), 2 deletions(-)
 create mode 100644 include/lzma/LzmaDecode.h
 create mode 100644 include/lzma/LzmaTools.h
 create mode 100644 include/lzma/LzmaTypes.h
 create mode 100644 lib_lzma/LGPL.txt
 create mode 100644 lib_lzma/LzmaDecode.c
 create mode 100644 lib_lzma/LzmaDecode.h
 create mode 100644 lib_lzma/LzmaTools.c
 create mode 100644 lib_lzma/LzmaTools.h
 create mode 100644 lib_lzma/LzmaTypes.h
 create mode 100644 lib_lzma/Makefile
 create mode 100644 lib_lzma/README.txt
 create mode 100644 lib_lzma/history.txt
 create mode 100644 lib_lzma/import_lzmasdk.sh
 create mode 100644 lib_lzma/lzma.txt

diff --git a/Makefile b/Makefile
index e56889e..253fa9f 100644
--- a/Makefile
+++ b/Makefile
@@ -199,6 +199,7 @@ endif
 OBJS := $(addprefix $(obj),$(OBJS))
 
 LIBS  = lib_generic/libgeneric.a
+LIBS += lib_lzma/lib_lzma.a
 LIBS += $(shell if [ -f board/$(VENDOR)/common/Makefile ]; then echo \
 	"board/$(VENDOR)/common/lib$(VENDOR).a"; fi)
 LIBS += board/$(BOARDDIR)/lib$(BOARD).a
diff --git a/README b/README
index 7c16345..3f10f9c 100644
--- a/README
+++ b/README
@@ -1031,6 +1031,29 @@ The following options need to be configured:
 		the malloc area (as defined by CFG_MALLOC_LEN) should
 		be at least 4MB.
 
+		CONFIG_LZMA
+
+		If this option is set, support for lzma compressed
+		images is included.
+
+		Note: The LZMA algorithm adds about 2KB of code and it
+		requires an amount of dynamic memory that is given by the
+		formula:
+
+		         (1846 + 768 << (lc + lp)) * sizeof(uint16)
+
+		Where lc and lp stand for, respectively, Literal context bits
+		and Literal pos bits.
+
+		This value is upper-bounded by 14MB in the worst case. Anyway,
+		for a ~4MB large kernel image, we have lc=3 and lp=0 for a
+		total amount of (1846 + 768 << (3 + 0)) * 2 = ~41KB... that is
+		a very small buffer.
+                
+		Use the lzmainfo tool to determinate the lc and lp values and
+		then calculate the  amount of needed dynamic memory (ensuring
+		the appropriate CFG_MALLOC_LEN value).
+
 - MII/PHY support:
 		CONFIG_PHY_ADDR
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9e5ce4b..ba6de50 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -40,6 +40,13 @@
 #include <hush.h>
 #endif
 
+#ifdef CONFIG_LZMA
+#define _7ZIP_BYTE_DEFINED /* Byte already defined by zlib */
+#include <lzma/LzmaTypes.h>
+#include <lzma/LzmaDecode.h>
+#include <lzma/LzmaTools.h>
+#endif /* CONFIG_LZMA */
+
 DECLARE_GLOBAL_DATA_PTR;
 
 extern int gunzip (void *dst, int dstlen, unsigned char *src, unsigned long *lenp);
@@ -271,6 +278,22 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		load_end = load_start + unc_len;
 		break;
 #endif /* CONFIG_BZIP2 */
+#ifdef CONFIG_LZMA
+	case IH_COMP_LZMA:
+		printf ("   Uncompressing %s ... ", type_name);
+
+		int ret = lzmaBuffToBuffDecompress(
+			(unsigned char *)load_start, &unc_len,
+			(unsigned char *)os_data, os_len);
+		if (ret != LZMA_RESULT_OK) {
+			printf ("LZMA: uncompress or overwrite error %d "
+				"- must RESET board to recover\n", ret);
+			show_boot_progress (-6);
+			do_reset (cmdtp, flag, argc, argv);
+		}
+		load_end = load_start + unc_len;
+		break;
+#endif /* CONFIG_LZMA */
 	default:
 		if (iflag)
 			enable_interrupts();
diff --git a/common/image.c b/common/image.c
index 9e63432..01cea4e 100644
--- a/common/image.c
+++ b/common/image.c
@@ -152,6 +152,9 @@ static table_entry_t uimage_comp[] = {
 	{	IH_COMP_NONE,	"none",		"uncompressed",		},
 	{	IH_COMP_BZIP2,	"bzip2",	"bzip2 compressed",	},
 	{	IH_COMP_GZIP,	"gzip",		"gzip compressed",	},
+#if defined(CONFIG_LZMA) || defined(USE_HOSTCC)
+	{	IH_COMP_LZMA,	"lzma",		"lzma compressed",	},
+#endif
 	{	-1,		"",		"",			},
 };
 
@@ -1950,7 +1953,7 @@ static int calculate_hash (const void *data, int data_len, const char *algo,
 	return 0;
 }
 
-#ifdef USE_HOSTCC
+// #ifdef USE_HOSTCC
 /**
  * fit_set_hashes - process FIT component image nodes and calculate hashes
  * @fit: pointer to the FIT format image header
@@ -2119,7 +2122,7 @@ int fit_image_hash_set_value (void *fit, int noffset, uint8_t *value,
 
 	return 0;
 }
-#endif /* USE_HOSTCC */
+// #endif /* USE_HOSTCC */
 
 /**
  * fit_image_check_hashes - verify data intergity
diff --git a/include/image.h b/include/image.h
index c1a6cbb..ef38edc 100644
--- a/include/image.h
+++ b/include/image.h
@@ -164,6 +164,7 @@
 #define IH_COMP_NONE		0	/*  No	 Compression Used	*/
 #define IH_COMP_GZIP		1	/* gzip	 Compression Used	*/
 #define IH_COMP_BZIP2		2	/* bzip2 Compression Used	*/
+#define IH_COMP_LZMA		3	/* lzma  Compression Used	*/
 
 #define IH_MAGIC	0x27051956	/* Image Magic Number		*/
 #define IH_NMLEN		32	/* Image Name Length		*/
diff --git a/include/lzma/LzmaDecode.h b/include/lzma/LzmaDecode.h
new file mode 100644
index 0000000..618c005
--- /dev/null
+++ b/include/lzma/LzmaDecode.h
@@ -0,0 +1,31 @@
+/*
+ * Fake include for LzmaDecode.h
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __LZMADECODE_H__FAKE__
+#define __LZMADECODE_H__FAKE__
+
+#include "../../lib_lzma/LzmaDecode.h"
+
+#endif
diff --git a/include/lzma/LzmaTools.h b/include/lzma/LzmaTools.h
new file mode 100644
index 0000000..ac96800
--- /dev/null
+++ b/include/lzma/LzmaTools.h
@@ -0,0 +1,31 @@
+/*
+ * Fake include for LzmaTools.h
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __LZMATOOLS_H__FAKE__
+#define __LZMATOOLS_H__FAKE__
+
+#include "../../lib_lzma/LzmaTools.h"
+
+#endif
diff --git a/include/lzma/LzmaTypes.h b/include/lzma/LzmaTypes.h
new file mode 100644
index 0000000..f26c1a8
--- /dev/null
+++ b/include/lzma/LzmaTypes.h
@@ -0,0 +1,31 @@
+/*
+ * Fake include for LzmaTypes.h
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __LZMATYPES_H__FAKE__
+#define __LZMATYPES_H__FAKE__
+
+#include "../../lib_lzma/LzmaTypes.h"
+
+#endif
diff --git a/lib_lzma/LGPL.txt b/lib_lzma/LGPL.txt
new file mode 100644
index 0000000..f3926a6
--- /dev/null
+++ b/lib_lzma/LGPL.txt
@@ -0,0 +1,504 @@
+      GNU LESSER GENERAL PUBLIC LICENSE
+           Version 2.1, February 1999
+
+ Copyright (C) 1991, 1999 Free Software Foundation, Inc.
+     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+[This is the first released version of the Lesser GPL.  It also counts
+ as the successor of the GNU Library Public License, version 2, hence
+ the version number 2.1.]
+
+          Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+Licenses are intended to guarantee your freedom to share and change
+free software--to make sure the software is free for all its users.
+
+  This license, the Lesser General Public License, applies to some
+specially designated software packages--typically libraries--of the
+Free Software Foundation and other authors who decide to use it.  You
+can use it too, but we suggest you first think carefully about whether
+this license or the ordinary General Public License is the better
+strategy to use in any particular case, based on the explanations below.
+
+  When we speak of free software, we are referring to freedom of use,
+not price.  Our General Public Licenses are designed to make sure that
+you have the freedom to distribute copies of free software (and charge
+for this service if you wish); that you receive source code or can get
+it if you want it; that you can change the software and use pieces of
+it in new free programs; and that you are informed that you can do
+these things.
+
+  To protect your rights, we need to make restrictions that forbid
+distributors to deny you these rights or to ask you to surrender these
+rights.  These restrictions translate to certain responsibilities for
+you if you distribute copies of the library or if you modify it.
+
+  For example, if you distribute copies of the library, whether gratis
+or for a fee, you must give the recipients all the rights that we gave
+you.  You must make sure that they, too, receive or can get the source
+code.  If you link other code with the library, you must provide
+complete object files to the recipients, so that they can relink them
+with the library after making changes to the library and recompiling
+it.  And you must show them these terms so they know their rights.
+
+  We protect your rights with a two-step method: (1) we copyright the
+library, and (2) we offer you this license, which gives you legal
+permission to copy, distribute and/or modify the library.
+
+  To protect each distributor, we want to make it very clear that
+there is no warranty for the free library.  Also, if the library is
+modified by someone else and passed on, the recipients should know
+that what they have is not the original version, so that the original
+author's reputation will not be affected by problems that might be
+introduced by others.
+
+  Finally, software patents pose a constant threat to the existence of
+any free program.  We wish to make sure that a company cannot
+effectively restrict the users of a free program by obtaining a
+restrictive license from a patent holder.  Therefore, we insist that
+any patent license obtained for a version of the library must be
+consistent with the full freedom of use specified in this license.
+
+  Most GNU software, including some libraries, is covered by the
+ordinary GNU General Public License.  This license, the GNU Lesser
+General Public License, applies to certain designated libraries, and
+is quite different from the ordinary General Public License.  We use
+this license for certain libraries in order to permit linking those
+libraries into non-free programs.
+
+  When a program is linked with a library, whether statically or using
+a shared library, the combination of the two is legally speaking a
+combined work, a derivative of the original library.  The ordinary
+General Public License therefore permits such linking only if the
+entire combination fits its criteria of freedom.  The Lesser General
+Public License permits more lax criteria for linking other code with
+the library.
+
+  We call this license the "Lesser" General Public License because it
+does Less to protect the user's freedom than the ordinary General
+Public License.  It also provides other free software developers Less
+of an advantage over competing non-free programs.  These disadvantages
+are the reason we use the ordinary General Public License for many
+libraries.  However, the Lesser license provides advantages in certain
+special circumstances.
+
+  For example, on rare occasions, there may be a special need to
+encourage the widest possible use of a certain library, so that it becomes
+a de-facto standard.  To achieve this, non-free programs must be
+allowed to use the library.  A more frequent case is that a free
+library does the same job as widely used non-free libraries.  In this
+case, there is little to gain by limiting the free library to free
+software only, so we use the Lesser General Public License.
+
+  In other cases, permission to use a particular library in non-free
+programs enables a greater number of people to use a large body of
+free software.  For example, permission to use the GNU C Library in
+non-free programs enables many more people to use the whole GNU
+operating system, as well as its variant, the GNU/Linux operating
+system.
+
+  Although the Lesser General Public License is Less protective of the
+users' freedom, it does ensure that the user of a program that is
+linked with the Library has the freedom and the wherewithal to run
+that program using a modified version of the Library.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.  Pay close attention to the difference between a
+"work based on the library" and a "work that uses the library".  The
+former contains code derived from the library, whereas the latter must
+be combined with the library in order to run.
+
+      GNU LESSER GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License Agreement applies to any software library or other
+program which contains a notice placed by the copyright holder or
+other authorized party saying it may be distributed under the terms of
+this Lesser General Public License (also called "this License").
+Each licensee is addressed as "you".
+
+  A "library" means a collection of software functions and/or data
+prepared so as to be conveniently linked with application programs
+(which use some of those functions and data) to form executables.
+
+  The "Library", below, refers to any such software library or work
+which has been distributed under these terms.  A "work based on the
+Library" means either the Library or any derivative work under
+copyright law: that is to say, a work containing the Library or a
+portion of it, either verbatim or with modifications and/or translated
+straightforwardly into another language.  (Hereinafter, translation is
+included without limitation in the term "modification".)
+
+  "Source code" for a work means the preferred form of the work for
+making modifications to it.  For a library, complete source code means
+all the source code for all modules it contains, plus any associated
+interface definition files, plus the scripts used to control compilation
+and installation of the library.
+
+  Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running a program using the Library is not restricted, and output from
+such a program is covered only if its contents constitute a work based
+on the Library (independent of the use of the Library in a tool for
+writing it).  Whether that is true depends on what the Library does
+and what the program that uses the Library does.
+  
+  1. You may copy and distribute verbatim copies of the Library's
+complete source code as you receive it, in any medium, provided that
+you conspicuously and appropriately publish on each copy an
+appropriate copyright notice and disclaimer of warranty; keep intact
+all the notices that refer to this License and to the absence of any
+warranty; and distribute a copy of this License along with the
+Library.
+
+  You may charge a fee for the physical act of transferring a copy,
+and you may at your option offer warranty protection in exchange for a
+fee.
+
+  2. You may modify your copy or copies of the Library or any portion
+of it, thus forming a work based on the Library, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) The modified work must itself be a software library.
+
+    b) You must cause the files modified to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    c) You must cause the whole of the work to be licensed at no
+    charge to all third parties under the terms of this License.
+
+    d) If a facility in the modified Library refers to a function or a
+    table of data to be supplied by an application program that uses
+    the facility, other than as an argument passed when the facility
+    is invoked, then you must make a good faith effort to ensure that,
+    in the event an application does not supply such function or
+    table, the facility still operates, and performs whatever part of
+    its purpose remains meaningful.
+
+    (For example, a function in a library to compute square roots has
+    a purpose that is entirely well-defined independent of the
+    application.  Therefore, Subsection 2d requires that any
+    application-supplied function or table used by this function must
+    be optional: if the application does not supply it, the square
+    root function must still compute square roots.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Library,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Library, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote
+it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Library.
+
+In addition, mere aggregation of another work not based on the Library
+with the Library (or with a work based on the Library) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may opt to apply the terms of the ordinary GNU General Public
+License instead of this License to a given copy of the Library.  To do
+this, you must alter all the notices that refer to this License, so
+that they refer to the ordinary GNU General Public License, version 2,
+instead of to this License.  (If a newer version than version 2 of the
+ordinary GNU General Public License has appeared, then you can specify
+that version instead if you wish.)  Do not make any other change in
+these notices.
+
+  Once this change is made in a given copy, it is irreversible for
+that copy, so the ordinary GNU General Public License applies to all
+subsequent copies and derivative works made from that copy.
+
+  This option is useful when you wish to copy part of the code of
+the Library into a program that is not a library.
+
+  4. You may copy and distribute the Library (or a portion or
+derivative of it, under Section 2) in object code or executable form
+under the terms of Sections 1 and 2 above provided that you accompany
+it with the complete corresponding machine-readable source code, which
+must be distributed under the terms of Sections 1 and 2 above on a
+medium customarily used for software interchange.
+
+  If distribution of object code is made by offering access to copy
+from a designated place, then offering equivalent access to copy the
+source code from the same place satisfies the requirement to
+distribute the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  5. A program that contains no derivative of any portion of the
+Library, but is designed to work with the Library by being compiled or
+linked with it, is called a "work that uses the Library".  Such a
+work, in isolation, is not a derivative work of the Library, and
+therefore falls outside the scope of this License.
+
+  However, linking a "work that uses the Library" with the Library
+creates an executable that is a derivative of the Library (because it
+contains portions of the Library), rather than a "work that uses the
+library".  The executable is therefore covered by this License.
+Section 6 states terms for distribution of such executables.
+
+  When a "work that uses the Library" uses material from a header file
+that is part of the Library, the object code for the work may be a
+derivative work of the Library even though the source code is not.
+Whether this is true is especially significant if the work can be
+linked without the Library, or if the work is itself a library.  The
+threshold for this to be true is not precisely defined by law.
+
+  If such an object file uses only numerical parameters, data
+structure layouts and accessors, and small macros and small inline
+functions (ten lines or less in length), then the use of the object
+file is unrestricted, regardless of whether it is legally a derivative
+work.  (Executables containing this object code plus portions of the
+Library will still fall under Section 6.)
+
+  Otherwise, if the work is a derivative of the Library, you may
+distribute the object code for the work under the terms of Section 6.
+Any executables containing that work also fall under Section 6,
+whether or not they are linked directly with the Library itself.
+
+  6. As an exception to the Sections above, you may also combine or
+link a "work that uses the Library" with the Library to produce a
+work containing portions of the Library, and distribute that work
+under terms of your choice, provided that the terms permit
+modification of the work for the customer's own use and reverse
+engineering for debugging such modifications.
+
+  You must give prominent notice with each copy of the work that the
+Library is used in it and that the Library and its use are covered by
+this License.  You must supply a copy of this License.  If the work
+during execution displays copyright notices, you must include the
+copyright notice for the Library among them, as well as a reference
+directing the user to the copy of this License.  Also, you must do one
+of these things:
+
+    a) Accompany the work with the complete corresponding
+    machine-readable source code for the Library including whatever
+    changes were used in the work (which must be distributed under
+    Sections 1 and 2 above); and, if the work is an executable linked
+    with the Library, with the complete machine-readable "work that
+    uses the Library", as object code and/or source code, so that the
+    user can modify the Library and then relink to produce a modified
+    executable containing the modified Library.  (It is understood
+    that the user who changes the contents of definitions files in the
+    Library will not necessarily be able to recompile the application
+    to use the modified definitions.)
+
+    b) Use a suitable shared library mechanism for linking with the
+    Library.  A suitable mechanism is one that (1) uses at run time a
+    copy of the library already present on the user's computer system,
+    rather than copying library functions into the executable, and (2)
+    will operate properly with a modified version of the library, if
+    the user installs one, as long as the modified version is
+    interface-compatible with the version that the work was made with.
+
+    c) Accompany the work with a written offer, valid for at
+    least three years, to give the same user the materials
+    specified in Subsection 6a, above, for a charge no more
+    than the cost of performing this distribution.
+
+    d) If distribution of the work is made by offering access to copy
+    from a designated place, offer equivalent access to copy the above
+    specified materials from the same place.
+
+    e) Verify that the user has already received a copy of these
+    materials or that you have already sent this user a copy.
+
+  For an executable, the required form of the "work that uses the
+Library" must include any data and utility programs needed for
+reproducing the executable from it.  However, as a special exception,
+the materials to be distributed need not include anything that is
+normally distributed (in either source or binary form) with the major
+components (compiler, kernel, and so on) of the operating system on
+which the executable runs, unless that component itself accompanies
+the executable.
+
+  It may happen that this requirement contradicts the license
+restrictions of other proprietary libraries that do not normally
+accompany the operating system.  Such a contradiction means you cannot
+use both them and the Library together in an executable that you
+distribute.
+
+  7. You may place library facilities that are a work based on the
+Library side-by-side in a single library together with other library
+facilities not covered by this License, and distribute such a combined
+library, provided that the separate distribution of the work based on
+the Library and of the other library facilities is otherwise
+permitted, and provided that you do these two things:
+
+    a) Accompany the combined library with a copy of the same work
+    based on the Library, uncombined with any other library
+    facilities.  This must be distributed under the terms of the
+    Sections above.
+
+    b) Give prominent notice with the combined library of the fact
+    that part of it is a work based on the Library, and explaining
+    where to find the accompanying uncombined form of the same work.
+
+  8. You may not copy, modify, sublicense, link with, or distribute
+the Library except as expressly provided under this License.  Any
+attempt otherwise to copy, modify, sublicense, link with, or
+distribute the Library is void, and will automatically terminate your
+rights under this License.  However, parties who have received copies,
+or rights, from you under this License will not have their licenses
+terminated so long as such parties remain in full compliance.
+
+  9. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Library or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Library (or any work based on the
+Library), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Library or works based on it.
+
+  10. Each time you redistribute the Library (or any work based on the
+Library), the recipient automatically receives a license from the
+original licensor to copy, distribute, link with or modify the Library
+subject to these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties with
+this License.
+
+  11. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Library at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Library by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Library.
+
+If any portion of this section is held invalid or unenforceable under any
+particular circumstance, the balance of the section is intended to apply,
+and the section as a whole is intended to apply in other circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  12. If the distribution and/or use of the Library is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Library under this License may add
+an explicit geographical distribution limitation excluding those countries,
+so that distribution is permitted only in or among countries not thus
+excluded.  In such case, this License incorporates the limitation as if
+written in the body of this License.
+
+  13. The Free Software Foundation may publish revised and/or new
+versions of the Lesser General Public License from time to time.
+Such new versions will be similar in spirit to the present version,
+but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Library
+specifies a version number of this License which applies to it and
+"any later version", you have the option of following the terms and
+conditions either of that version or of any later version published by
+the Free Software Foundation.  If the Library does not specify a
+license version number, you may choose any version ever published by
+the Free Software Foundation.
+
+  14. If you wish to incorporate parts of the Library into other free
+programs whose distribution conditions are incompatible with these,
+write to the author to ask for permission.  For software which is
+copyrighted by the Free Software Foundation, write to the Free
+Software Foundation; we sometimes make exceptions for this.  Our
+decision will be guided by the two goals of preserving the free status
+of all derivatives of our free software and of promoting the sharing
+and reuse of software generally.
+
+          NO WARRANTY
+
+  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
+WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
+OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
+KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
+LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
+THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
+AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
+FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
+LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
+RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
+FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
+SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGES.
+
+         END OF TERMS AND CONDITIONS
+
+           How to Apply These Terms to Your New Libraries
+
+  If you develop a new library, and you want it to be of the greatest
+possible use to the public, we recommend making it free software that
+everyone can redistribute and change.  You can do so by permitting
+redistribution under these terms (or, alternatively, under the terms of the
+ordinary General Public License).
+
+  To apply these terms, attach the following notices to the library.  It is
+safest to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the library's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This library is free software; you can redistribute it and/or
+    modify it under the terms of the GNU Lesser General Public
+    License as published by the Free Software Foundation; either
+    version 2.1 of the License, or (at your option) any later version.
+
+    This library 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
+    Lesser General Public License for more details.
+
+    You should have received a copy of the GNU Lesser General Public
+    License along with this library; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+
+Also add information on how to contact you by electronic and paper mail.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the library, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the
+  library `Frob' (a library for tweaking knobs) written by James Random Hacker.
+
+  <signature of Ty Coon>, 1 April 1990
+  Ty Coon, President of Vice
+
+That's all there is to it!
+
+
diff --git a/lib_lzma/LzmaDecode.c b/lib_lzma/LzmaDecode.c
new file mode 100644
index 0000000..71c62c4
--- /dev/null
+++ b/lib_lzma/LzmaDecode.c
@@ -0,0 +1,584 @@
+/*
+  LzmaDecode.c
+  LZMA Decoder (optimized for Speed version)
+  
+  LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
+  http://www.7-zip.org/
+
+  LZMA SDK is licensed under two licenses:
+  1) GNU Lesser General Public License (GNU LGPL)
+  2) Common Public License (CPL)
+  It means that you can select one of these two licenses and 
+  follow rules of that license.
+
+  SPECIAL EXCEPTION:
+  Igor Pavlov, as the author of this Code, expressly permits you to 
+  statically or dynamically link your Code (or bind by name) to the 
+  interfaces of this file without subjecting your linked Code to the 
+  terms of the CPL or GNU LGPL. Any modifications or additions 
+  to this file, however, are subject to the LGPL or CPL terms.
+*/
+
+#include "LzmaDecode.h"
+
+#define kNumTopBits 24
+#define kTopValue ((UInt32)1 << kNumTopBits)
+
+#define kNumBitModelTotalBits 11
+#define kBitModelTotal (1 << kNumBitModelTotalBits)
+#define kNumMoveBits 5
+
+#define RC_READ_BYTE (*Buffer++)
+
+#define RC_INIT2 Code = 0; Range = 0xFFFFFFFF; \
+  { int i; for(i = 0; i < 5; i++) { RC_TEST; Code = (Code << 8) | RC_READ_BYTE; }}
+
+#ifdef _LZMA_IN_CB
+
+#define RC_TEST { if (Buffer == BufferLim) \
+  { SizeT size; int result = InCallback->Read(InCallback, &Buffer, &size); if (result != LZMA_RESULT_OK) return result; \
+  BufferLim = Buffer + size; if (size == 0) return LZMA_RESULT_DATA_ERROR; }}
+
+#define RC_INIT Buffer = BufferLim = 0; RC_INIT2
+
+#else
+
+#define RC_TEST { if (Buffer == BufferLim) return LZMA_RESULT_DATA_ERROR; }
+
+#define RC_INIT(buffer, bufferSize) Buffer = buffer; BufferLim = buffer + bufferSize; RC_INIT2
+ 
+#endif
+
+#define RC_NORMALIZE if (Range < kTopValue) { RC_TEST; Range <<= 8; Code = (Code << 8) | RC_READ_BYTE; }
+
+#define IfBit0(p) RC_NORMALIZE; bound = (Range >> kNumBitModelTotalBits) * *(p); if (Code < bound)
+#define UpdateBit0(p) Range = bound; *(p) += (kBitModelTotal - *(p)) >> kNumMoveBits;
+#define UpdateBit1(p) Range -= bound; Code -= bound; *(p) -= (*(p)) >> kNumMoveBits;
+
+#define RC_GET_BIT2(p, mi, A0, A1) IfBit0(p) \
+  { UpdateBit0(p); mi <<= 1; A0; } else \
+  { UpdateBit1(p); mi = (mi + mi) + 1; A1; } 
+  
+#define RC_GET_BIT(p, mi) RC_GET_BIT2(p, mi, ; , ;)               
+
+#define RangeDecoderBitTreeDecode(probs, numLevels, res) \
+  { int i = numLevels; res = 1; \
+  do { CProb *p = probs + res; RC_GET_BIT(p, res) } while(--i != 0); \
+  res -= (1 << numLevels); }
+
+
+#define kNumPosBitsMax 4
+#define kNumPosStatesMax (1 << kNumPosBitsMax)
+
+#define kLenNumLowBits 3
+#define kLenNumLowSymbols (1 << kLenNumLowBits)
+#define kLenNumMidBits 3
+#define kLenNumMidSymbols (1 << kLenNumMidBits)
+#define kLenNumHighBits 8
+#define kLenNumHighSymbols (1 << kLenNumHighBits)
+
+#define LenChoice 0
+#define LenChoice2 (LenChoice + 1)
+#define LenLow (LenChoice2 + 1)
+#define LenMid (LenLow + (kNumPosStatesMax << kLenNumLowBits))
+#define LenHigh (LenMid + (kNumPosStatesMax << kLenNumMidBits))
+#define kNumLenProbs (LenHigh + kLenNumHighSymbols) 
+
+
+#define kNumStates 12
+#define kNumLitStates 7
+
+#define kStartPosModelIndex 4
+#define kEndPosModelIndex 14
+#define kNumFullDistances (1 << (kEndPosModelIndex >> 1))
+
+#define kNumPosSlotBits 6
+#define kNumLenToPosStates 4
+
+#define kNumAlignBits 4
+#define kAlignTableSize (1 << kNumAlignBits)
+
+#define kMatchMinLen 2
+
+#define IsMatch 0
+#define IsRep (IsMatch + (kNumStates << kNumPosBitsMax))
+#define IsRepG0 (IsRep + kNumStates)
+#define IsRepG1 (IsRepG0 + kNumStates)
+#define IsRepG2 (IsRepG1 + kNumStates)
+#define IsRep0Long (IsRepG2 + kNumStates)
+#define PosSlot (IsRep0Long + (kNumStates << kNumPosBitsMax))
+#define SpecPos (PosSlot + (kNumLenToPosStates << kNumPosSlotBits))
+#define Align (SpecPos + kNumFullDistances - kEndPosModelIndex)
+#define LenCoder (Align + kAlignTableSize)
+#define RepLenCoder (LenCoder + kNumLenProbs)
+#define Literal (RepLenCoder + kNumLenProbs)
+
+#if Literal != LZMA_BASE_SIZE
+StopCompilingDueBUG
+#endif
+
+int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size)
+{
+  unsigned char prop0;
+  if (size < LZMA_PROPERTIES_SIZE)
+    return LZMA_RESULT_DATA_ERROR;
+  prop0 = propsData[0];
+  if (prop0 >= (9 * 5 * 5))
+    return LZMA_RESULT_DATA_ERROR;
+  {
+    for (propsRes->pb = 0; prop0 >= (9 * 5); propsRes->pb++, prop0 -= (9 * 5));
+    for (propsRes->lp = 0; prop0 >= 9; propsRes->lp++, prop0 -= 9);
+    propsRes->lc = prop0;
+    /*
+    unsigned char remainder = (unsigned char)(prop0 / 9);
+    propsRes->lc = prop0 % 9;
+    propsRes->pb = remainder / 5;
+    propsRes->lp = remainder % 5;
+    */
+  }
+
+  #ifdef _LZMA_OUT_READ
+  {
+    int i;
+    propsRes->DictionarySize = 0;
+    for (i = 0; i < 4; i++)
+      propsRes->DictionarySize += (UInt32)(propsData[1 + i]) << (i * 8);
+    if (propsRes->DictionarySize == 0)
+      propsRes->DictionarySize = 1;
+  }
+  #endif
+  return LZMA_RESULT_OK;
+}
+
+#define kLzmaStreamWasFinishedId (-1)
+
+int LzmaDecode(CLzmaDecoderState *vs,
+    #ifdef _LZMA_IN_CB
+    ILzmaInCallback *InCallback,
+    #else
+    const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
+    #endif
+    unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed)
+{
+  CProb *p = vs->Probs;
+  SizeT nowPos = 0;
+  Byte previousByte = 0;
+  UInt32 posStateMask = (1 << (vs->Properties.pb)) - 1;
+  UInt32 literalPosMask = (1 << (vs->Properties.lp)) - 1;
+  int lc = vs->Properties.lc;
+
+  #ifdef _LZMA_OUT_READ
+  
+  UInt32 Range = vs->Range;
+  UInt32 Code = vs->Code;
+  #ifdef _LZMA_IN_CB
+  const Byte *Buffer = vs->Buffer;
+  const Byte *BufferLim = vs->BufferLim;
+  #else
+  const Byte *Buffer = inStream;
+  const Byte *BufferLim = inStream + inSize;
+  #endif
+  int state = vs->State;
+  UInt32 rep0 = vs->Reps[0], rep1 = vs->Reps[1], rep2 = vs->Reps[2], rep3 = vs->Reps[3];
+  int len = vs->RemainLen;
+  UInt32 globalPos = vs->GlobalPos;
+  UInt32 distanceLimit = vs->DistanceLimit;
+
+  Byte *dictionary = vs->Dictionary;
+  UInt32 dictionarySize = vs->Properties.DictionarySize;
+  UInt32 dictionaryPos = vs->DictionaryPos;
+
+  Byte tempDictionary[4];
+
+  #ifndef _LZMA_IN_CB
+  *inSizeProcessed = 0;
+  #endif
+  *outSizeProcessed = 0;
+  if (len == kLzmaStreamWasFinishedId)
+    return LZMA_RESULT_OK;
+
+  if (dictionarySize == 0)
+  {
+    dictionary = tempDictionary;
+    dictionarySize = 1;
+    tempDictionary[0] = vs->TempDictionary[0];
+  }
+
+  if (len == kLzmaNeedInitId)
+  {
+    {
+      UInt32 numProbs = Literal + ((UInt32)LZMA_LIT_SIZE << (lc + vs->Properties.lp));
+      UInt32 i;
+      for (i = 0; i < numProbs; i++)
+        p[i] = kBitModelTotal >> 1; 
+      rep0 = rep1 = rep2 = rep3 = 1;
+      state = 0;
+      globalPos = 0;
+      distanceLimit = 0;
+      dictionaryPos = 0;
+      dictionary[dictionarySize - 1] = 0;
+      #ifdef _LZMA_IN_CB
+      RC_INIT;
+      #else
+      RC_INIT(inStream, inSize);
+      #endif
+    }
+    len = 0;
+  }
+  while(len != 0 && nowPos < outSize)
+  {
+    UInt32 pos = dictionaryPos - rep0;
+    if (pos >= dictionarySize)
+      pos += dictionarySize;
+    outStream[nowPos++] = dictionary[dictionaryPos] = dictionary[pos];
+    if (++dictionaryPos == dictionarySize)
+      dictionaryPos = 0;
+    len--;
+  }
+  if (dictionaryPos == 0)
+    previousByte = dictionary[dictionarySize - 1];
+  else
+    previousByte = dictionary[dictionaryPos - 1];
+
+  #else /* if !_LZMA_OUT_READ */
+
+  int state = 0;
+  UInt32 rep0 = 1, rep1 = 1, rep2 = 1, rep3 = 1;
+  int len = 0;
+  const Byte *Buffer;
+  const Byte *BufferLim;
+  UInt32 Range;
+  UInt32 Code;
+
+  #ifndef _LZMA_IN_CB
+  *inSizeProcessed = 0;
+  #endif
+  *outSizeProcessed = 0;
+
+  {
+    UInt32 i;
+    UInt32 numProbs = Literal + ((UInt32)LZMA_LIT_SIZE << (lc + vs->Properties.lp));
+    for (i = 0; i < numProbs; i++)
+      p[i] = kBitModelTotal >> 1;
+  }
+  
+  #ifdef _LZMA_IN_CB
+  RC_INIT;
+  #else
+  RC_INIT(inStream, inSize);
+  #endif
+
+  #endif /* _LZMA_OUT_READ */
+
+  while(nowPos < outSize)
+  {
+    CProb *prob;
+    UInt32 bound;
+    int posState = (int)(
+        (nowPos 
+        #ifdef _LZMA_OUT_READ
+        + globalPos
+        #endif
+        )
+        & posStateMask);
+
+    prob = p + IsMatch + (state << kNumPosBitsMax) + posState;
+    IfBit0(prob)
+    {
+      int symbol = 1;
+      UpdateBit0(prob)
+      prob = p + Literal + (LZMA_LIT_SIZE * 
+        (((
+        (nowPos 
+        #ifdef _LZMA_OUT_READ
+        + globalPos
+        #endif
+        )
+        & literalPosMask) << lc) + (previousByte >> (8 - lc))));
+
+      if (state >= kNumLitStates)
+      {
+        int matchByte;
+        #ifdef _LZMA_OUT_READ
+        UInt32 pos = dictionaryPos - rep0;
+        if (pos >= dictionarySize)
+          pos += dictionarySize;
+        matchByte = dictionary[pos];
+        #else
+        matchByte = outStream[nowPos - rep0];
+        #endif
+        do
+        {
+          int bit;
+          CProb *probLit;
+          matchByte <<= 1;
+          bit = (matchByte & 0x100);
+          probLit = prob + 0x100 + bit + symbol;
+          RC_GET_BIT2(probLit, symbol, if (bit != 0) break, if (bit == 0) break)
+        }
+        while (symbol < 0x100);
+      }
+      while (symbol < 0x100)
+      {
+        CProb *probLit = prob + symbol;
+        RC_GET_BIT(probLit, symbol)
+      }
+      previousByte = (Byte)symbol;
+
+      outStream[nowPos++] = previousByte;
+      #ifdef _LZMA_OUT_READ
+      if (distanceLimit < dictionarySize)
+        distanceLimit++;
+
+      dictionary[dictionaryPos] = previousByte;
+      if (++dictionaryPos == dictionarySize)
+        dictionaryPos = 0;
+      #endif
+      if (state < 4) state = 0;
+      else if (state < 10) state -= 3;
+      else state -= 6;
+    }
+    else             
+    {
+      UpdateBit1(prob);
+      prob = p + IsRep + state;
+      IfBit0(prob)
+      {
+        UpdateBit0(prob);
+        rep3 = rep2;
+        rep2 = rep1;
+        rep1 = rep0;
+        state = state < kNumLitStates ? 0 : 3;
+        prob = p + LenCoder;
+      }
+      else
+      {
+        UpdateBit1(prob);
+        prob = p + IsRepG0 + state;
+        IfBit0(prob)
+        {
+          UpdateBit0(prob);
+          prob = p + IsRep0Long + (state << kNumPosBitsMax) + posState;
+          IfBit0(prob)
+          {
+            #ifdef _LZMA_OUT_READ
+            UInt32 pos;
+            #endif
+            UpdateBit0(prob);
+            
+            #ifdef _LZMA_OUT_READ
+            if (distanceLimit == 0)
+            #else
+            if (nowPos == 0)
+            #endif
+              return LZMA_RESULT_DATA_ERROR;
+            
+            state = state < kNumLitStates ? 9 : 11;
+            #ifdef _LZMA_OUT_READ
+            pos = dictionaryPos - rep0;
+            if (pos >= dictionarySize)
+              pos += dictionarySize;
+            previousByte = dictionary[pos];
+            dictionary[dictionaryPos] = previousByte;
+            if (++dictionaryPos == dictionarySize)
+              dictionaryPos = 0;
+            #else
+            previousByte = outStream[nowPos - rep0];
+            #endif
+            outStream[nowPos++] = previousByte;
+            #ifdef _LZMA_OUT_READ
+            if (distanceLimit < dictionarySize)
+              distanceLimit++;
+            #endif
+
+            continue;
+          }
+          else
+          {
+            UpdateBit1(prob);
+          }
+        }
+        else
+        {
+          UInt32 distance;
+          UpdateBit1(prob);
+          prob = p + IsRepG1 + state;
+          IfBit0(prob)
+          {
+            UpdateBit0(prob);
+            distance = rep1;
+          }
+          else 
+          {
+            UpdateBit1(prob);
+            prob = p + IsRepG2 + state;
+            IfBit0(prob)
+            {
+              UpdateBit0(prob);
+              distance = rep2;
+            }
+            else
+            {
+              UpdateBit1(prob);
+              distance = rep3;
+              rep3 = rep2;
+            }
+            rep2 = rep1;
+          }
+          rep1 = rep0;
+          rep0 = distance;
+        }
+        state = state < kNumLitStates ? 8 : 11;
+        prob = p + RepLenCoder;
+      }
+      {
+        int numBits, offset;
+        CProb *probLen = prob + LenChoice;
+        IfBit0(probLen)
+        {
+          UpdateBit0(probLen);
+          probLen = prob + LenLow + (posState << kLenNumLowBits);
+          offset = 0;
+          numBits = kLenNumLowBits;
+        }
+        else
+        {
+          UpdateBit1(probLen);
+          probLen = prob + LenChoice2;
+          IfBit0(probLen)
+          {
+            UpdateBit0(probLen);
+            probLen = prob + LenMid + (posState << kLenNumMidBits);
+            offset = kLenNumLowSymbols;
+            numBits = kLenNumMidBits;
+          }
+          else
+          {
+            UpdateBit1(probLen);
+            probLen = prob + LenHigh;
+            offset = kLenNumLowSymbols + kLenNumMidSymbols;
+            numBits = kLenNumHighBits;
+          }
+        }
+        RangeDecoderBitTreeDecode(probLen, numBits, len);
+        len += offset;
+      }
+
+      if (state < 4)
+      {
+        int posSlot;
+        state += kNumLitStates;
+        prob = p + PosSlot +
+            ((len < kNumLenToPosStates ? len : kNumLenToPosStates - 1) << 
+            kNumPosSlotBits);
+        RangeDecoderBitTreeDecode(prob, kNumPosSlotBits, posSlot);
+        if (posSlot >= kStartPosModelIndex)
+        {
+          int numDirectBits = ((posSlot >> 1) - 1);
+          rep0 = (2 | ((UInt32)posSlot & 1));
+          if (posSlot < kEndPosModelIndex)
+          {
+            rep0 <<= numDirectBits;
+            prob = p + SpecPos + rep0 - posSlot - 1;
+          }
+          else
+          {
+            numDirectBits -= kNumAlignBits;
+            do
+            {
+              RC_NORMALIZE
+              Range >>= 1;
+              rep0 <<= 1;
+              if (Code >= Range)
+              {
+                Code -= Range;
+                rep0 |= 1;
+              }
+            }
+            while (--numDirectBits != 0);
+            prob = p + Align;
+            rep0 <<= kNumAlignBits;
+            numDirectBits = kNumAlignBits;
+          }
+          {
+            int i = 1;
+            int mi = 1;
+            do
+            {
+              CProb *prob3 = prob + mi;
+              RC_GET_BIT2(prob3, mi, ; , rep0 |= i);
+              i <<= 1;
+            }
+            while(--numDirectBits != 0);
+          }
+        }
+        else
+          rep0 = posSlot;
+        if (++rep0 == (UInt32)(0))
+        {
+          /* it's for stream version */
+          len = kLzmaStreamWasFinishedId;
+          break;
+        }
+      }
+
+      len += kMatchMinLen;
+      #ifdef _LZMA_OUT_READ
+      if (rep0 > distanceLimit) 
+      #else
+      if (rep0 > nowPos)
+      #endif
+        return LZMA_RESULT_DATA_ERROR;
+
+      #ifdef _LZMA_OUT_READ
+      if (dictionarySize - distanceLimit > (UInt32)len)
+        distanceLimit += len;
+      else
+        distanceLimit = dictionarySize;
+      #endif
+
+      do
+      {
+        #ifdef _LZMA_OUT_READ
+        UInt32 pos = dictionaryPos - rep0;
+        if (pos >= dictionarySize)
+          pos += dictionarySize;
+        previousByte = dictionary[pos];
+        dictionary[dictionaryPos] = previousByte;
+        if (++dictionaryPos == dictionarySize)
+          dictionaryPos = 0;
+        #else
+        previousByte = outStream[nowPos - rep0];
+        #endif
+        len--;
+        outStream[nowPos++] = previousByte;
+      }
+      while(len != 0 && nowPos < outSize);
+    }
+  }
+  RC_NORMALIZE;
+
+  #ifdef _LZMA_OUT_READ
+  vs->Range = Range;
+  vs->Code = Code;
+  vs->DictionaryPos = dictionaryPos;
+  vs->GlobalPos = globalPos + (UInt32)nowPos;
+  vs->DistanceLimit = distanceLimit;
+  vs->Reps[0] = rep0;
+  vs->Reps[1] = rep1;
+  vs->Reps[2] = rep2;
+  vs->Reps[3] = rep3;
+  vs->State = state;
+  vs->RemainLen = len;
+  vs->TempDictionary[0] = tempDictionary[0];
+  #endif
+
+  #ifdef _LZMA_IN_CB
+  vs->Buffer = Buffer;
+  vs->BufferLim = BufferLim;
+  #else
+  *inSizeProcessed = (SizeT)(Buffer - inStream);
+  #endif
+  *outSizeProcessed = nowPos;
+  return LZMA_RESULT_OK;
+}
diff --git a/lib_lzma/LzmaDecode.h b/lib_lzma/LzmaDecode.h
new file mode 100644
index 0000000..8382fa8
--- /dev/null
+++ b/lib_lzma/LzmaDecode.h
@@ -0,0 +1,113 @@
+/* 
+  LzmaDecode.h
+  LZMA Decoder interface
+
+  LZMA SDK 4.40 Copyright (c) 1999-2006 Igor Pavlov (2006-05-01)
+  http://www.7-zip.org/
+
+  LZMA SDK is licensed under two licenses:
+  1) GNU Lesser General Public License (GNU LGPL)
+  2) Common Public License (CPL)
+  It means that you can select one of these two licenses and 
+  follow rules of that license.
+
+  SPECIAL EXCEPTION:
+  Igor Pavlov, as the author of this code, expressly permits you to 
+  statically or dynamically link your code (or bind by name) to the 
+  interfaces of this file without subjecting your linked code to the 
+  terms of the CPL or GNU LGPL. Any modifications or additions 
+  to this file, however, are subject to the LGPL or CPL terms.
+*/
+
+#ifndef __LZMADECODE_H
+#define __LZMADECODE_H
+
+#include "LzmaTypes.h"
+
+/* #define _LZMA_IN_CB */
+/* Use callback for input data */
+
+/* #define _LZMA_OUT_READ */
+/* Use read function for output data */
+
+/* #define _LZMA_PROB32 */
+/* It can increase speed on some 32-bit CPUs, 
+   but memory usage will be doubled in that case */
+
+/* #define _LZMA_LOC_OPT */
+/* Enable local speed optimizations inside code */
+
+#ifdef _LZMA_PROB32
+#define CProb UInt32
+#else
+#define CProb UInt16
+#endif
+
+#define LZMA_RESULT_OK 0
+#define LZMA_RESULT_DATA_ERROR 1
+
+#ifdef _LZMA_IN_CB
+typedef struct _ILzmaInCallback
+{
+  int (*Read)(void *object, const unsigned char **buffer, SizeT *bufferSize);
+} ILzmaInCallback;
+#endif
+
+#define LZMA_BASE_SIZE 1846
+#define LZMA_LIT_SIZE 768
+
+#define LZMA_PROPERTIES_SIZE 5
+
+typedef struct _CLzmaProperties
+{
+  int lc;
+  int lp;
+  int pb;
+  #ifdef _LZMA_OUT_READ
+  UInt32 DictionarySize;
+  #endif
+}CLzmaProperties;
+
+int LzmaDecodeProperties(CLzmaProperties *propsRes, const unsigned char *propsData, int size);
+
+#define LzmaGetNumProbs(Properties) (LZMA_BASE_SIZE + (LZMA_LIT_SIZE << ((Properties)->lc + (Properties)->lp)))
+
+#define kLzmaNeedInitId (-2)
+
+typedef struct _CLzmaDecoderState
+{
+  CLzmaProperties Properties;
+  CProb *Probs;
+
+  #ifdef _LZMA_IN_CB
+  const unsigned char *Buffer;
+  const unsigned char *BufferLim;
+  #endif
+
+  #ifdef _LZMA_OUT_READ
+  unsigned char *Dictionary;
+  UInt32 Range;
+  UInt32 Code;
+  UInt32 DictionaryPos;
+  UInt32 GlobalPos;
+  UInt32 DistanceLimit;
+  UInt32 Reps[4];
+  int State;
+  int RemainLen;
+  unsigned char TempDictionary[4];
+  #endif
+} CLzmaDecoderState;
+
+#ifdef _LZMA_OUT_READ
+#define LzmaDecoderInit(vs) { (vs)->RemainLen = kLzmaNeedInitId; }
+#endif
+
+int LzmaDecode(CLzmaDecoderState *vs,
+    #ifdef _LZMA_IN_CB
+    ILzmaInCallback *inCallback,
+    #else
+    const unsigned char *inStream, SizeT inSize, SizeT *inSizeProcessed,
+    #endif
+    unsigned char *outStream, SizeT outSize, SizeT *outSizeProcessed);
+
+#endif
diff --git a/lib_lzma/LzmaTools.c b/lib_lzma/LzmaTools.c
new file mode 100644
index 0000000..3d1cc02
--- /dev/null
+++ b/lib_lzma/LzmaTools.c
@@ -0,0 +1,142 @@
+/*
+ * Usefuls routines based on the LzmaTest.c file from LZMA SDK 4.57
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * Copyright (C) 1999-2005 Igor Pavlov
+ *
+ * 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
+ */
+
+/*
+ * LZMA_Alone stream format:
+ *
+ * uchar   Properties[5]
+ * uint64  Uncompressed size
+ * uchar   data[*]
+ *
+ */
+
+#include <config.h>
+#include <common.h>
+
+#ifdef CONFIG_LZMA
+
+#define LZMA_PROPERTIES_OFFSET 0
+#define LZMA_SIZE_OFFSET       LZMA_PROPERTIES_SIZE
+#define LZMA_DATA_OFFSET       LZMA_SIZE_OFFSET+sizeof(uint64_t)
+
+#include "LzmaTools.h"
+#include "LzmaDecode.h"
+
+#include <linux/string.h>
+#include <malloc.h>
+
+int lzmaBuffToBuffDecompress (unsigned char *outStream, SizeT *uncompressedSize,
+			      unsigned char *inStream,  SizeT  length)
+{
+	int res = LZMA_RESULT_DATA_ERROR;
+	int i;
+	
+	SizeT outSizeFull = 0xFFFFFFFF; /* 4GBytes limit */
+	SizeT inProcessed;
+	SizeT outProcessed;
+	SizeT outSize;
+	SizeT outSizeHigh;
+	CLzmaDecoderState state;  /* it's about 24-80 bytes structure, if int is 32-bit */
+	unsigned char properties[LZMA_PROPERTIES_SIZE];
+	SizeT compressedSize = (SizeT)(length - LZMA_DATA_OFFSET);
+
+	debug ("LZMA: Image address............... 0x%lx\n", inStream);
+	debug ("LZMA: Properties address.......... 0x%lx\n", inStream + LZMA_PROPERTIES_OFFSET);
+	debug ("LZMA: Uncompressed size address... 0x%lx\n", inStream + LZMA_SIZE_OFFSET);
+	debug ("LZMA: Compressed data address..... 0x%lx\n", inStream + LZMA_DATA_OFFSET);
+	debug ("LZMA: Destination address......... 0x%lx\n", outStream);
+
+	memcpy(properties, inStream + LZMA_PROPERTIES_OFFSET, LZMA_PROPERTIES_SIZE);
+ 
+  	memset(&state, 0, sizeof(state));
+	res = LzmaDecodeProperties(&state.Properties,
+				 properties,
+				 LZMA_PROPERTIES_SIZE);
+	if (res != LZMA_RESULT_OK) {
+		return res;
+	}
+
+	outSize = 0;
+	outSizeHigh = 0;
+	/* Read the uncompressed size */
+	for (i = 0; i < 8; i++) {
+        	unsigned char b = inStream[LZMA_SIZE_OFFSET + i];
+	        if (i < 4) {
+        	        outSize     += (UInt32)(b) << (i * 8);
+        	} else {
+	                outSizeHigh += (UInt32)(b) << ((i - 4) * 8);
+        	}
+	}
+
+	outSizeFull = (SizeT)outSize;
+	if (sizeof(SizeT) >= 8) {
+        	/*
+	         * SizeT is a 64 bit uint => We can manage files larger than 4GB!
+        	 *
+        	 */
+	        outSizeFull |= (((SizeT)outSizeHigh << 16) << 16);
+	} else if (outSizeHigh != 0 || (UInt32)(SizeT)outSize != outSize) {
+	        /*
+        	 * SizeT is a 32 bit uint => We cannot manage files larger than
+        	 * 4GB!
+        	 *
+        	 */
+		debug ("LZMA: 64bit support not enabled.\n");
+	        return LZMA_RESULT_DATA_ERROR;
+	}
+
+	debug ("LZMA: Uncompresed size............ 0x%lx\n", outSizeFull);
+	debug ("LZMA: Compresed size.............. 0x%lx\n", compressedSize);
+	debug ("LZMA: Dynamic memory needed....... 0x%lx", LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
+
+	state.Probs = (CProb *)malloc(LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
+
+	if (state.Probs == 0
+	    || (outStream == 0 && outSizeFull != 0)
+	    || (inStream == 0 && compressedSize != 0)) {
+		free(state.Probs);
+		debug ("\n");
+		return LZMA_RESULT_DATA_ERROR;
+	}
+
+	debug (" allocated.\n");
+
+	/* Decompress */
+
+	res = LzmaDecode(&state,
+		inStream + LZMA_DATA_OFFSET, compressedSize, &inProcessed,
+		outStream, outSizeFull,  &outProcessed);
+	if (res != LZMA_RESULT_OK)  {
+		return res;
+	}
+
+	*uncompressedSize = outProcessed;
+	free(state.Probs);
+	return res;
+}
+
+#endif
diff --git a/lib_lzma/LzmaTools.h b/lib_lzma/LzmaTools.h
new file mode 100644
index 0000000..ea51eef
--- /dev/null
+++ b/lib_lzma/LzmaTools.h
@@ -0,0 +1,35 @@
+/*
+ * Usefuls routines based on the LzmaTest.c file from LZMA SDK 4.57
+ *
+ * Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+ * Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+ *
+ * Copyright (C) 1999-2005 Igor Pavlov
+ *
+ * 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
+ */
+ 
+#ifndef __LZMA_TOOL_H__
+#define __LZMA_TOOL_H__
+
+#include "LzmaTypes.h"
+
+extern int lzmaBuffToBuffDecompress (unsigned char *outStream, SizeT *uncompressedSize,
+			      unsigned char *inStream,  SizeT  length);
+#endif
diff --git a/lib_lzma/LzmaTypes.h b/lib_lzma/LzmaTypes.h
new file mode 100644
index 0000000..5e860c9
--- /dev/null
+++ b/lib_lzma/LzmaTypes.h
@@ -0,0 +1,45 @@
+/* 
+LzmaTypes.h 
+
+Types for LZMA Decoder
+
+This file written and distributed to public domain by Igor Pavlov.
+This file is part of LZMA SDK 4.40 (2006-05-01)
+*/
+
+#ifndef __LZMATYPES_H
+#define __LZMATYPES_H
+
+#ifndef _7ZIP_BYTE_DEFINED
+#define _7ZIP_BYTE_DEFINED
+typedef unsigned char Byte;
+#endif 
+
+#ifndef _7ZIP_UINT16_DEFINED
+#define _7ZIP_UINT16_DEFINED
+typedef unsigned short UInt16;
+#endif 
+
+#ifndef _7ZIP_UINT32_DEFINED
+#define _7ZIP_UINT32_DEFINED
+#ifdef _LZMA_UINT32_IS_ULONG
+typedef unsigned long UInt32;
+#else
+typedef unsigned int UInt32;
+#endif
+#endif 
+
+/* #define _LZMA_NO_SYSTEM_SIZE_T */
+/* You can use it, if you don't want <stddef.h> */
+
+#ifndef _7ZIP_SIZET_DEFINED
+#define _7ZIP_SIZET_DEFINED
+#ifdef _LZMA_NO_SYSTEM_SIZE_T
+typedef UInt32 SizeT;
+#else
+#include <stddef.h>
+typedef size_t SizeT;
+#endif
+#endif
+
+#endif
diff --git a/lib_lzma/Makefile b/lib_lzma/Makefile
new file mode 100644
index 0000000..e314241
--- /dev/null
+++ b/lib_lzma/Makefile
@@ -0,0 +1,51 @@
+#
+# Copyright (C) 2007-2008 Industrie Dial Face S.p.A.
+# Luigi 'Comio' Mantellini (luigi.mantellini at idf-hit.com)
+#
+# (C) Copyright 2003-2006
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib_lzma.a
+
+SOBJS	=
+
+COBJS-y +=	LzmaDecode.o \
+		LzmaTools.o
+
+COBJS	= $(COBJS-y)
+SRCS 	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(SOBJS) $(COBJS))
+
+$(LIB):	$(obj).depend $(OBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS)
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
+
diff --git a/lib_lzma/README.txt b/lib_lzma/README.txt
new file mode 100644
index 0000000..8af698d
--- /dev/null
+++ b/lib_lzma/README.txt
@@ -0,0 +1,28 @@
+The lib_lzma functionality was written by Igor Pavlov. 
+The original source cames from the LZMA SDK web page:
+
+URL: 		http://www.7-zip.org/sdk.html
+Author:         Igor Pavlov
+
+The import is made using the import_lzmasdk.sh script that:
+
+* untars the lzmaXYY.tar.bz2 file (from the download web page)
+* copies the files LzmaDecode.h, LzmaTypes.h, LzmaDecode.c, history.txt,
+  LGPL.txt, and lzma.txt from source archive into the lib_lzma directory (pwd).
+
+Example:
+
+ ./import_lzmasdk.sh ~/lzma457.tar.bz2
+
+Notice: The files from lzma sdk are not _modified_ by this script!
+
+The files LzmaTools.{c,h} are provided to export the lzmaBuffToBuffDecompress()
+function that wraps the complex LzmaDecode() function from the LZMA SDK. The
+do_bootm() function uses the lzmaBuffToBuffDecopress() function to expand the
+compressed image.
+
+The directory U-BOOT/include/lzma contains stubs files that permit to use the
+library directly from U-BOOT code without touching the original LZMA SDK's
+files.
+
+Luigi 'Comio' Mantellini <luigi.mantellini at idf-hit.com>
diff --git a/lib_lzma/history.txt b/lib_lzma/history.txt
new file mode 100644
index 0000000..8a035bb
--- /dev/null
+++ b/lib_lzma/history.txt
@@ -0,0 +1,198 @@
+HISTORY of the LZMA SDK
+-----------------------
+
+  4.57           2007-12-12
+  -------------------------
+    - Speed optimizations in ?++ LZMA Decoder. 
+    - Small changes for more compatibility with some C/C++ compilers.
+
+  
+  4.49 beta      2007-07-05
+  -------------------------
+    - .7z ANSI-C Decoder:
+         - now it supports BCJ and BCJ2 filters
+         - now it supports files larger than 4 GB.
+         - now it supports "Last Write Time" field for files.
+    - C++ code for .7z archives compressing/decompressing from 7-zip 
+      was included to LZMA SDK.
+      
+
+  4.43           2006-06-04
+  -------------------------
+    - Small changes for more compatibility with some C/C++ compilers.
+      
+
+  4.42           2006-05-15
+  -------------------------
+    - Small changes in .h files in ANSI-C version.
+      
+
+  4.39 beta      2006-04-14
+  -------------------------
+    - Bug in versions 4.33b:4.38b was fixed:
+      C++ version of LZMA encoder could not correctly compress 
+      files larger than 2 GB with HC4 match finder (-mfhc4).
+      
+
+  4.37 beta      2005-04-06
+  -------------------------
+    - Fixes in C++ code: code could no be compiled if _NO_EXCEPTIONS was defined. 
+
+  
+  4.35 beta      2005-03-02
+  -------------------------
+    - Bug was fixed in C++ version of LZMA Decoder:
+       If encoded stream was corrupted, decoder could access memory 
+       outside of allocated range.
+
+  
+  4.34 beta      2006-02-27
+  -------------------------
+    - Compressing speed and memory requirements for compressing were increased
+    - LZMA now can use only these match finders: HC4, BT2, BT3, BT4
+
+  
+  4.32           2005-12-09
+  -------------------------
+    - Java version of LZMA SDK was included
+
+
+  4.30           2005-11-20
+  -------------------------
+    - Compression ratio was improved in -a2 mode
+    - Speed optimizations for compressing in -a2 mode
+    - -fb switch now supports values up to 273
+    - Bug in 7z_C (7zIn.c) was fixed:
+      It used Alloc/Free functions from different memory pools.
+      So if program used two memory pools, it worked incorrectly.
+    - 7z_C: .7z format supporting was improved
+    - LZMA# SDK (C#.NET version) was included
+
+
+  4.27 (Updated) 2005-09-21
+  -------------------------
+   - Some GUIDs/interfaces in C++ were changed.
+     IStream.h:
+       ISequentialInStream::Read now works as old ReadPart
+       ISequentialOutStream::Write now works as old WritePart
+
+  
+  4.27           2005-08-07
+  -------------------------
+    - Bug in LzmaDecodeSize.c was fixed:
+       if _LZMA_IN_CB and _LZMA_OUT_READ were defined,
+       decompressing worked incorrectly.
+
+
+  4.26           2005-08-05
+  -------------------------
+    - Fixes in 7z_C code and LzmaTest.c:
+      previous versions could work incorrectly,
+      if malloc(0) returns 0
+
+
+  4.23           2005-06-29
+  -------------------------
+    - Small fixes in C++ code
+
+
+  4.22           2005-06-10
+  -------------------------
+    - Small fixes
+
+
+  4.21           2005-06-08
+  -------------------------
+    - Interfaces for ANSI-C LZMA Decoder (LzmaDecode.c) were changed
+    - New additional version of ANSI-C LZMA Decoder with zlib-like interface:
+        - LzmaStateDecode.h
+        - LzmaStateDecode.c
+        - LzmaStateTest.c
+    - ANSI-C LZMA Decoder now can decompress files larger than 4 GB
+
+  
+  4.17           2005-04-18
+  -------------------------
+    - New example for RAM->RAM compressing/decompressing: 
+      LZMA + BCJ (filter for x86 code):
+        - LzmaRam.h
+        - LzmaRam.cpp
+        - LzmaRamDecode.h
+        - LzmaRamDecode.c
+        - -f86 switch for lzma.exe
+
+  
+  4.16           2005-03-29
+  -------------------------
+    - Bug was fixed in LzmaDecode.c (ANSI-C LZMA Decoder): 
+       If _LZMA_OUT_READ was defined, and if encoded stream was corrupted,
+       decoder could access memory outside of allocated range.
+    - Speed optimization of ANSI-C LZMA Decoder (now it's about 20% faster).
+      Old version of LZMA Decoder now is in file LzmaDecodeSize.c. 
+      LzmaDecodeSize.c can provide slightly smaller code than LzmaDecode.c
+    - Small speed optimization in LZMA C++ code
+    - filter for SPARC's code was added
+    - Simplified version of .7z ANSI-C Decoder was included
+
+
+  4.06           2004-09-05
+  -------------------------
+    - Bug in v4.05 was fixed:
+        LZMA-Encoder didn't release output stream in some cases.
+
+
+  4.05           2004-08-25
+  -------------------------
+    - Source code of filters for x86, IA-64, ARM, ARM-Thumb 
+      and PowerPC code was included to SDK
+    - Some internal minor changes
+
+
+  4.04           2004-07-28
+  -------------------------
+    - More compatibility with some C++ compilers
+
+
+  4.03           2004-06-18
+  -------------------------
+    - "Benchmark" command was added. It measures compressing 
+      and decompressing speed and shows rating values. 
+      Also it checks hardware errors.
+
+
+  4.02           2004-06-10
+  -------------------------
+    - C++ LZMA Encoder/Decoder code now is more portable
+      and it can be compiled by GCC on Linux.
+
+
+  4.01           2004-02-15
+  -------------------------
+    - Some detection of data corruption was enabled.
+        LzmaDecode.c / RangeDecoderReadByte
+        .....
+        {
+          rd->ExtraBytes = 1;
+          return 0xFF;
+        }
+
+
+  4.00           2004-02-13
+  -------------------------
+    - Original version of LZMA SDK
+
+
+
+HISTORY of the LZMA
+-------------------
+  2001-2007:  Improvements to LZMA compressing/decompressing code, 
+              keeping compatibility with original LZMA format
+  1996-2001:  Development of LZMA compression format
+
+  Some milestones:
+
+  2001-08-30: LZMA compression was added to 7-Zip
+  1999-01-02: First version of 7-Zip was released
+  
+
+End of document
diff --git a/lib_lzma/import_lzmasdk.sh b/lib_lzma/import_lzmasdk.sh
new file mode 100644
index 0000000..3b4e232
--- /dev/null
+++ b/lib_lzma/import_lzmasdk.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+usage() {
+	echo "Usage: $0 lzmaVERSION.tar.bz2" >&2
+	echo >&2
+	exit 1
+}
+
+if [ "$1" = "" ] ; then
+ 	 usage
+fi
+
+if [ ! -f $1 ] ; then
+	echo "$1 doesn't exist!" >&2
+	exit 1
+fi
+
+BASENAME=`basename $1 .tar.bz2`
+TMPDIR=/tmp/tmp_lib_$BASENAME
+FILES="C/Compress/Lzma/LzmaDecode.h
+      C/Compress/Lzma/LzmaTypes.h  
+      C/Compress/Lzma/LzmaDecode.c 
+      history.txt                  
+      LGPL.txt                     
+      lzma.txt"
+
+
+mkdir -p $TMPDIR
+echo "Untar $1 -> $TMPDIR"
+tar -jxf $1 -C $TMPDIR
+
+for i in $FILES; do
+	echo Copying  $TMPDIR/$i \-\> `basename $i`
+	cp $TMPDIR/$i .
+	chmod -x `basename $i`
+done
+
+echo "done!"
diff --git a/lib_lzma/lzma.txt b/lib_lzma/lzma.txt
new file mode 100644
index 0000000..74935bf
--- /dev/null
+++ b/lib_lzma/lzma.txt
@@ -0,0 +1,663 @@
+LZMA SDK 4.57
+-------------
+
+LZMA SDK   Copyright (C) 1999-2007 Igor Pavlov
+
+LZMA SDK provides the documentation, samples, header files, libraries, 
+and tools you need to develop applications that use LZMA compression.
+
+LZMA is default and general compression method of 7z format
+in 7-Zip compression program (www.7-zip.org). LZMA provides high 
+compression ratio and very fast decompression.
+
+LZMA is an improved version of famous LZ77 compression algorithm. 
+It was improved in way of maximum increasing of compression ratio,
+keeping high decompression speed and low memory requirements for 
+decompressing.
+
+
+
+LICENSE
+-------
+
+LZMA SDK is available under any of the following licenses:
+
+1) GNU Lesser General Public License (GNU LGPL)
+2) Common Public License (CPL)
+3) Simplified license for unmodified code (read SPECIAL EXCEPTION) 
+4) Proprietary license 
+
+It means that you can select one of these four options and follow rules of that license.
+
+
+1,2) GNU LGPL and CPL licenses are pretty similar and both these
+licenses are classified as 
+ - "Free software licenses" at http://www.gnu.org/ 
+ - "OSI-approved" at http://www.opensource.org/
+
+
+3) SPECIAL EXCEPTION
+
+Igor Pavlov, as the author of this code, expressly permits you 
+to statically or dynamically link your code (or bind by name) 
+to the files from LZMA SDK without subjecting your linked 
+code to the terms of the CPL or GNU LGPL. 
+Any modifications or additions to files from LZMA SDK, however, 
+are subject to the GNU LGPL or CPL terms.
+
+SPECIAL EXCEPTION allows you to use LZMA SDK in applications with closed code, 
+while you keep LZMA SDK code unmodified.
+
+
+SPECIAL EXCEPTION #2: Igor Pavlov, as the author of this code, expressly permits 
+you to use this code under the same terms and conditions contained in the License 
+Agreement you have for any previous version of LZMA SDK developed by Igor Pavlov.
+
+SPECIAL EXCEPTION #2 allows owners of proprietary licenses to use latest version 
+of LZMA SDK as update for previous versions.
+
+
+SPECIAL EXCEPTION #3: Igor Pavlov, as the author of this code, expressly permits 
+you to use code of the following files: 
+BranchTypes.h, LzmaTypes.h, LzmaTest.c, LzmaStateTest.c, LzmaAlone.cpp, 
+LzmaAlone.cs, LzmaAlone.java
+as public domain code. 
+
+
+4) Proprietary license
+
+LZMA SDK also can be available under a proprietary license which 
+can include:
+
+1) Right to modify code without subjecting modified code to the 
+terms of the CPL or GNU LGPL
+2) Technical support for code
+
+To request such proprietary license or any additional consultations,
+send email message from that page:
+http://www.7-zip.org/support.html
+
+
+You should have received a copy of the GNU Lesser General Public
+License along with this library; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+
+You should have received a copy of the Common Public License
+along with this library.
+
+
+LZMA SDK Contents
+-----------------
+
+LZMA SDK includes:
+
+  - C++ source code of LZMA compressing and decompressing
+  - ANSI-C compatible source code for LZMA decompressing
+  - C# source code for LZMA compressing and decompressing
+  - Java source code for LZMA compressing and decompressing
+  - Compiled file->file LZMA compressing/decompressing program for Windows system
+
+ANSI-C LZMA decompression code was ported from original C++ sources to C.
+Also it was simplified and optimized for code size. 
+But it is fully compatible with LZMA from 7-Zip.
+
+
+UNIX/Linux version 
+------------------
+To compile C++ version of file->file LZMA, go to directory
+C/7zip/Compress/LZMA_Alone 
+and type "make" or "make clean all" to recompile all.
+
+In some UNIX/Linux versions you must compile LZMA with static libraries.
+To compile with static libraries, change string in makefile
+LIB = -lm
+to string  
+LIB = -lm -static
+
+
+Files
+---------------------
+C        - C source code
+CPP      - CPP source code
+CS       - C# source code
+Java     - Java source code
+lzma.txt - LZMA SDK description (this file)
+7zFormat.txt - 7z Format description
+7zC.txt  - 7z ANSI-C Decoder description (this file)
+methods.txt  - Compression method IDs for .7z
+LGPL.txt - GNU Lesser General Public License
+CPL.html - Common Public License
+lzma.exe - Compiled file->file LZMA encoder/decoder for Windows
+history.txt - history of the LZMA SDK
+
+
+Source code structure
+---------------------
+
+C  - C files
+    Compress - files related to compression/decompression
+      Lz     - files related to LZ (Lempel-Ziv) compression algorithm
+      Lzma   - ANSI-C compatible LZMA decompressor
+
+        LzmaDecode.h  - interface for LZMA decoding on ANSI-C
+        LzmaDecode.c      - LZMA decoding on ANSI-C (new fastest version)
+        LzmaDecodeSize.c  - LZMA decoding on ANSI-C (old size-optimized version)
+        LzmaTest.c        - test application that decodes LZMA encoded file
+        LzmaTypes.h       - basic types for LZMA Decoder
+        LzmaStateDecode.h - interface for LZMA decoding (State version)
+        LzmaStateDecode.c - LZMA decoding on ANSI-C (State version)
+        LzmaStateTest.c   - test application (State version)
+
+      Branch       - Filters for x86, IA-64, ARM, ARM-Thumb, PowerPC and SPARC code
+
+    Archive - files related to archiving
+      7z_C     - 7z ANSI-C Decoder
+
+
+CPP -- CPP files
+
+  Common  - common files for C++ projects
+  Windows - common files for Windows related code
+  7zip    - files related to 7-Zip Project
+
+    Common   - common files for 7-Zip
+
+    Compress - files related to compression/decompression
+
+      LZ     - files related to LZ (Lempel-Ziv) compression algorithm
+
+      Copy         - Copy coder
+      RangeCoder   - Range Coder (special code of compression/decompression)
+      LZMA         - LZMA compression/decompression on C++
+      LZMA_Alone   - file->file LZMA compression/decompression
+
+      Branch       - Filters for x86, IA-64, ARM, ARM-Thumb, PowerPC and SPARC code
+
+    Archive - files related to archiving
+
+      Common   - common files for archive handling
+      7z       - 7z C++ Encoder/Decoder
+
+    Bundles    - Modules that are bundles of other modules
+  
+      Alone7z           - 7zr.exe: Standalone version of 7z.exe that supports only 7z/LZMA/BCJ/BCJ2
+      Format7zR         - 7zr.dll: Reduced version of 7za.dll: extracting/compressing to 7z/LZMA/BCJ/BCJ2
+      Format7zExtractR  - 7zxr.dll: Reduced version of 7zxa.dll: extracting from 7z/LZMA/BCJ/BCJ2.
+
+    UI        - User Interface files
+         
+      Client7z - Test application for 7za.dll,  7zr.dll, 7zxr.dll
+      Common   - Common UI files
+      Console  - Code for console archiver
+
+
+
+CS - C# files
+  7zip
+    Common   - some common files for 7-Zip
+    Compress - files related to compression/decompression
+      LZ     - files related to LZ (Lempel-Ziv) compression algorithm
+      LZMA         - LZMA compression/decompression
+      LzmaAlone    - file->file LZMA compression/decompression
+      RangeCoder   - Range Coder (special code of compression/decompression)
+
+Java  - Java files
+  SevenZip
+    Compression    - files related to compression/decompression
+      LZ           - files related to LZ (Lempel-Ziv) compression algorithm
+      LZMA         - LZMA compression/decompression
+      RangeCoder   - Range Coder (special code of compression/decompression)
+
+C/C++ source code of LZMA SDK is part of 7-Zip project.
+
+You can find ANSI-C LZMA decompressing code at folder 
+  C/7zip/Compress/Lzma
+7-Zip doesn't use that ANSI-C LZMA code and that code was developed 
+specially for this SDK. And files from C/7zip/Compress/Lzma do not need 
+files from other directories of SDK for compiling.
+
+7-Zip source code can be downloaded from 7-Zip's SourceForge page:
+
+  http://sourceforge.net/projects/sevenzip/
+
+
+LZMA features
+-------------
+  - Variable dictionary size (up to 1 GB)
+  - Estimated compressing speed: about 1 MB/s on 1 GHz CPU
+  - Estimated decompressing speed: 
+      - 8-12 MB/s on 1 GHz Intel Pentium 3 or AMD Athlon
+      - 500-1000 KB/s on 100 MHz ARM, MIPS, PowerPC or other simple RISC
+  - Small memory requirements for decompressing (8-32 KB + DictionarySize)
+  - Small code size for decompressing: 2-8 KB (depending from 
+    speed optimizations) 
+
+LZMA decoder uses only integer operations and can be 
+implemented in any modern 32-bit CPU (or on 16-bit CPU with some conditions).
+
+Some critical operations that affect to speed of LZMA decompression:
+  1) 32*16 bit integer multiply
+  2) Misspredicted branches (penalty mostly depends from pipeline length)
+  3) 32-bit shift and arithmetic operations
+
+Speed of LZMA decompressing mostly depends from CPU speed.
+Memory speed has no big meaning. But if your CPU has small data cache, 
+overall weight of memory speed will slightly increase.
+
+
+How To Use
+----------
+
+Using LZMA encoder/decoder executable
+--------------------------------------
+
+Usage:  LZMA <e|d> inputFile outputFile [<switches>...]
+
+  e: encode file
+
+  d: decode file
+
+  b: Benchmark. There are two tests: compressing and decompressing 
+     with LZMA method. Benchmark shows rating in MIPS (million 
+     instructions per second). Rating value is calculated from 
+     measured speed and it is normalized with AMD Athlon 64 X2 CPU
+     results. Also Benchmark checks possible hardware errors (RAM 
+     errors in most cases). Benchmark uses these settings:
+     (-a1, -d21, -fb32, -mfbt4). You can change only -d. Also you 
+     can change number of iterations. Example for 30 iterations:
+       LZMA b 30
+     Default number of iterations is 10.
+
+<Switches>
+  
+
+  -a{N}:  set compression mode 0 = fast, 1 = normal
+          default: 1 (normal)
+
+  d{N}:   Sets Dictionary size - [0, 30], default: 23 (8MB)
+          The maximum value for dictionary size is 1 GB = 2^30 bytes.
+          Dictionary size is calculated as DictionarySize = 2^N bytes. 
+          For decompressing file compressed by LZMA method with dictionary 
+          size D = 2^N you need about D bytes of memory (RAM).
+
+  -fb{N}: set number of fast bytes - [5, 273], default: 128
+          Usually big number gives a little bit better compression ratio 
+          and slower compression process.
+
+  -lc{N}: set number of literal context bits - [0, 8], default: 3
+          Sometimes lc=4 gives gain for big files.
+
+  -lp{N}: set number of literal pos bits - [0, 4], default: 0
+          lp switch is intended for periodical data when period is 
+          equal 2^N. For example, for 32-bit (4 bytes) 
+          periodical data you can use lp=2. Often it's better to set lc0, 
+          if you change lp switch.
+
+  -pb{N}: set number of pos bits - [0, 4], default: 2
+          pb switch is intended for periodical data 
+          when period is equal 2^N.
+
+  -mf{MF_ID}: set Match Finder. Default: bt4. 
+              Algorithms from hc* group doesn't provide good compression 
+              ratio, but they often works pretty fast in combination with 
+              fast mode (-a0).
+
+              Memory requirements depend from dictionary size 
+              (parameter "d" in table below). 
+
+               MF_ID     Memory                   Description
+
+                bt2    d *  9.5 + 4MB  Binary Tree with 2 bytes hashing.
+                bt3    d * 11.5 + 4MB  Binary Tree with 3 bytes hashing.
+                bt4    d * 11.5 + 4MB  Binary Tree with 4 bytes hashing.
+                hc4    d *  7.5 + 4MB  Hash Chain with 4 bytes hashing.
+
+  -eos:   write End Of Stream marker. By default LZMA doesn't write 
+          eos marker, since LZMA decoder knows uncompressed size 
+          stored in .lzma file header.
+
+  -si:    Read data from stdin (it will write End Of Stream marker).
+  -so:    Write data to stdout
+
+
+Examples:
+
+1) LZMA e file.bin file.lzma -d16 -lc0 
+
+compresses file.bin to file.lzma with 64 KB dictionary (2^16=64K)  
+and 0 literal context bits. -lc0 allows to reduce memory requirements 
+for decompression.
+
+
+2) LZMA e file.bin file.lzma -lc0 -lp2
+
+compresses file.bin to file.lzma with settings suitable 
+for 32-bit periodical data (for example, ARM or MIPS code).
+
+3) LZMA d file.lzma file.bin
+
+decompresses file.lzma to file.bin.
+
+
+Compression ratio hints
+-----------------------
+
+Recommendations
+---------------
+
+To increase compression ratio for LZMA compressing it's desirable 
+to have aligned data (if it's possible) and also it's desirable to locate
+data in such order, where code is grouped in one place and data is 
+grouped in other place (it's better than such mixing: code, data, code,
+data, ...).
+
+
+Using Filters
+-------------
+You can increase compression ratio for some data types, using
+special filters before compressing. For example, it's possible to 
+increase compression ratio on 5-10% for code for those CPU ISAs: 
+x86, IA-64, ARM, ARM-Thumb, PowerPC, SPARC.
+
+You can find C/C++ source code of such filters in folder "7zip/Compress/Branch"
+
+You can check compression ratio gain of these filters with such 
+7-Zip commands (example for ARM code):
+No filter:
+  7z a a1.7z a.bin -m0=lzma
+
+With filter for little-endian ARM code:
+  7z a a2.7z a.bin -m0=bc_arm -m1=lzma        
+
+With filter for big-endian ARM code (using additional Swap4 filter):
+  7z a a3.7z a.bin -m0=swap4 -m1=bc_arm -m2=lzma
+
+It works in such manner:
+Compressing    = Filter_encoding + LZMA_encoding
+Decompressing  = LZMA_decoding + Filter_decoding
+
+Compressing and decompressing speed of such filters is very high,
+so it will not increase decompressing time too much.
+Moreover, it reduces decompression time for LZMA_decoding, 
+since compression ratio with filtering is higher.
+
+These filters convert CALL (calling procedure) instructions 
+from relative offsets to absolute addresses, so such data becomes more 
+compressible. Source code of these CALL filters is pretty simple
+(about 20 lines of C++), so you can convert it from C++ version yourself.
+
+For some ISAs (for example, for MIPS) it's impossible to get gain from such filter.
+
+
+LZMA compressed file format
+---------------------------
+Offset Size Description
+  0     1   Special LZMA properties for compressed data
+  1     4   Dictionary size (little endian)
+  5     8   Uncompressed size (little endian). -1 means unknown size
+ 13         Compressed data
+
+
+ANSI-C LZMA Decoder
+~~~~~~~~~~~~~~~~~~~
+
+To compile ANSI-C LZMA Decoder you can use one of the following files sets:
+1) LzmaDecode.h + LzmaDecode.c + LzmaTest.c  (fastest version)
+2) LzmaDecode.h + LzmaDecodeSize.c + LzmaTest.c  (old size-optimized version)
+3) LzmaStateDecode.h + LzmaStateDecode.c + LzmaStateTest.c  (zlib-like interface)
+
+
+Memory requirements for LZMA decoding
+-------------------------------------
+
+LZMA decoder doesn't allocate memory itself, so you must 
+allocate memory and send it to LZMA.
+
+Stack usage of LZMA decoding function for local variables is not 
+larger than 200 bytes.
+
+How To decompress data
+----------------------
+
+LZMA Decoder (ANSI-C version) now supports 5 interfaces:
+1) Single-call Decompressing
+2) Single-call Decompressing with input stream callback
+3) Multi-call Decompressing with output buffer
+4) Multi-call Decompressing with input callback and output buffer
+5) Multi-call State Decompressing (zlib-like interface)
+
+Variant-5 is similar to Variant-4, but Variant-5 doesn't use callback functions.
+
+Decompressing steps
+-------------------
+
+1) read LZMA properties (5 bytes):
+   unsigned char properties[LZMA_PROPERTIES_SIZE];
+
+2) read uncompressed size (8 bytes, little-endian)
+
+3) Decode properties:
+
+  CLzmaDecoderState state;  /* it's 24-140 bytes structure, if int is 32-bit */
+
+  if (LzmaDecodeProperties(&state.Properties, properties, LZMA_PROPERTIES_SIZE) != LZMA_RESULT_OK)
+    return PrintError(rs, "Incorrect stream properties");
+
+4) Allocate memory block for internal Structures:
+
+  state.Probs = (CProb *)malloc(LzmaGetNumProbs(&state.Properties) * sizeof(CProb));
+  if (state.Probs == 0)
+    return PrintError(rs, kCantAllocateMessage);
+
+  LZMA decoder uses array of CProb variables as internal structure.
+  By default, CProb is unsigned_short. But you can define _LZMA_PROB32 to make 
+  it unsigned_int. It can increase speed on some 32-bit CPUs, but memory 
+  usage will be doubled in that case.
+
+
+5) Main Decompressing
+
+You must use one of the following interfaces:
+
+5.1 Single-call Decompressing
+-----------------------------
+When to use: RAM->RAM decompressing
+Compile files: LzmaDecode.h, LzmaDecode.c
+Compile defines: no defines
+Memory Requirements:
+  - Input buffer: compressed size
+  - Output buffer: uncompressed size
+  - LZMA Internal Structures (~16 KB for default settings) 
+
+Interface:
+  int res = LzmaDecode(&state, 
+      inStream, compressedSize, &inProcessed,
+      outStream, outSize, &outProcessed);
+
+
+5.2 Single-call Decompressing with input stream callback
+--------------------------------------------------------
+When to use: File->RAM or Flash->RAM decompressing.
+Compile files: LzmaDecode.h, LzmaDecode.c
+Compile defines: _LZMA_IN_CB
+Memory Requirements:
+  - Buffer for input stream: any size (for example, 16 KB)
+  - Output buffer: uncompressed size
+  - LZMA Internal Structures (~16 KB for default settings) 
+
+Interface:
+  typedef struct _CBuffer
+  {
+    ILzmaInCallback InCallback;
+    FILE *File;
+    unsigned char Buffer[kInBufferSize];
+  } CBuffer;
+
+  int LzmaReadCompressed(void *object, const unsigned char **buffer, SizeT *size)
+  {
+    CBuffer *bo = (CBuffer *)object;
+    *buffer = bo->Buffer;
+    *size = MyReadFile(bo->File, bo->Buffer, kInBufferSize);
+    return LZMA_RESULT_OK;
+  }
+
+  CBuffer g_InBuffer;
+
+  g_InBuffer.File = inFile;
+  g_InBuffer.InCallback.Read = LzmaReadCompressed;
+  int res = LzmaDecode(&state, 
+      &g_InBuffer.InCallback,
+      outStream, outSize, &outProcessed);
+
+
+5.3 Multi-call decompressing with output buffer
+-----------------------------------------------
+When to use: RAM->File decompressing 
+Compile files: LzmaDecode.h, LzmaDecode.c
+Compile defines: _LZMA_OUT_READ
+Memory Requirements:
+ - Input buffer: compressed size
+ - Buffer for output stream: any size (for example, 16 KB)
+ - LZMA Internal Structures (~16 KB for default settings) 
+ - LZMA dictionary (dictionary size is encoded in stream properties)
+ 
+Interface:
+
+  state.Dictionary = (unsigned char *)malloc(state.Properties.DictionarySize);
+
+  LzmaDecoderInit(&state);
+  do
+  {
+    LzmaDecode(&state,
+      inBuffer, inAvail, &inProcessed,
+      g_OutBuffer, outAvail, &outProcessed);
+    inAvail -= inProcessed;
+    inBuffer += inProcessed;
+  }
+  while you need more bytes
+
+  see LzmaTest.c for more details.
+
+
+5.4 Multi-call decompressing with input callback and output buffer
+------------------------------------------------------------------
+When to use: File->File decompressing 
+Compile files: LzmaDecode.h, LzmaDecode.c
+Compile defines: _LZMA_IN_CB, _LZMA_OUT_READ
+Memory Requirements:
+ - Buffer for input stream: any size (for example, 16 KB)
+ - Buffer for output stream: any size (for example, 16 KB)
+ - LZMA Internal Structures (~16 KB for default settings) 
+ - LZMA dictionary (dictionary size is encoded in stream properties)
+ 
+Interface:
+
+  state.Dictionary = (unsigned char *)malloc(state.Properties.DictionarySize);
+ 
+  LzmaDecoderInit(&state);
+  do
+  {
+    LzmaDecode(&state,
+      &bo.InCallback,
+      g_OutBuffer, outAvail, &outProcessed);
+  }
+  while you need more bytes
+
+  see LzmaTest.c for more details:
+
+
+5.5 Multi-call State Decompressing (zlib-like interface)
+------------------------------------------------------------------
+When to use: file->file decompressing 
+Compile files: LzmaStateDecode.h, LzmaStateDecode.c
+Compile defines:
+Memory Requirements:
+ - Buffer for input stream: any size (for example, 16 KB)
+ - Buffer for output stream: any size (for example, 16 KB)
+ - LZMA Internal Structures (~16 KB for default settings) 
+ - LZMA dictionary (dictionary size is encoded in stream properties)
+ 
+Interface:
+
+  state.Dictionary = (unsigned char *)malloc(state.Properties.DictionarySize);
+
+  
+  LzmaDecoderInit(&state);
+  do
+  {
+    res = LzmaDecode(&state,
+      inBuffer, inAvail, &inProcessed,
+      g_OutBuffer, outAvail, &outProcessed,
+      finishDecoding);
+    inAvail -= inProcessed;
+    inBuffer += inProcessed;
+  }
+  while you need more bytes
+
+  see LzmaStateTest.c for more details:
+
+
+6) Free all allocated blocks
+
+
+Note
+----
+LzmaDecodeSize.c is size-optimized version of LzmaDecode.c.
+But compiled code of LzmaDecodeSize.c can be larger than 
+compiled code of LzmaDecode.c. So it's better to use 
+LzmaDecode.c in most cases.
+
+
+EXIT codes
+-----------
+
+LZMA decoder can return one of the following codes:
+
+#define LZMA_RESULT_OK 0
+#define LZMA_RESULT_DATA_ERROR 1
+
+If you use callback function for input data and you return some 
+error code, LZMA Decoder also returns that code.
+
+
+
+LZMA Defines
+------------
+
+_LZMA_IN_CB    - Use callback for input data
+
+_LZMA_OUT_READ - Use read function for output data
+
+_LZMA_LOC_OPT  - Enable local speed optimizations inside code.
+                 _LZMA_LOC_OPT is only for LzmaDecodeSize.c (size-optimized version).
+                 _LZMA_LOC_OPT doesn't affect LzmaDecode.c (speed-optimized version)
+                 and LzmaStateDecode.c
+
+_LZMA_PROB32   - It can increase speed on some 32-bit CPUs, 
+                 but memory usage will be doubled in that case
+
+_LZMA_UINT32_IS_ULONG  - Define it if int is 16-bit on your compiler
+                         and long is 32-bit.
+
+_LZMA_SYSTEM_SIZE_T  - Define it if you want to use system's size_t.
+                       You can use it to enable 64-bit sizes supporting
+
+
+
+C++ LZMA Encoder/Decoder 
+~~~~~~~~~~~~~~~~~~~~~~~~
+C++ LZMA code use COM-like interfaces. So if you want to use it, 
+you can study basics of COM/OLE.
+
+By default, LZMA Encoder contains all Match Finders.
+But for compressing it's enough to have just one of them.
+So for reducing size of compressing code you can define:
+  #define COMPRESS_MF_BT
+  #define COMPRESS_MF_BT4
+and it will use only bt4 match finder.
+
+
+---
+
+http://www.7-zip.org
+http://www.7-zip.org/support.html
-- 
1.5.4.3




From wd at denx.de  Sun Apr 20 03:14:10 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 03:14:10 +0200
Subject: [U-Boot-Users] [PATCH] cfi-flash: Add CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: Your message of "Fri, 18 Apr 2008 18:01:57 +0200."
	<20080418160157.GB12486@game.jcrosoft.org>
Message-ID: <20080420011410.709C5248A0@gemini.denx.de>

In message <20080418160157.GB12486 at game.jcrosoft.org> you wrote:
>
> > +#if defined(CFG_FLASH_AUTOPROTECT_LIST)
> > +	struct apl_s {
> > +		ulong start;
> > +		ulong size;
> > +	} apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> > +#endif
> I think it will be better to create a weak structure.

In the interest of memory footprint I prefer to stick with the #ifdef
here.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Motto of the Electrical Engineer: Working computer hardware is a  lot
like an erect penis: it stays up as long as you don't fuck with it.



From plagnioj at jcrosoft.com  Sun Apr 20 05:19:40 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sun, 20 Apr 2008 05:19:40 +0200
Subject: [U-Boot-Users] setenv declatation on ppc
Message-ID: <20080420031940.GA27176@game.jcrosoft.org>

Hi,

	 is someone could explain me why setenv need to be inline for
	 PPC?

Best Regards,
J.



From plagnioj at jcrosoft.com  Sun Apr 20 05:54:35 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sun, 20 Apr 2008 05:54:35 +0200
Subject: [U-Boot-Users] [PATCH]	cfi-flash:?Add?CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: <200804191922.53883.matthias.fuchs@esd-electronics.com>
References: <200804181629.40697.matthias.fuchs@esd-electronics.com>
	<200804191650.32303.matthias.fuchs@esd-electronics.com>
	<20080419153342.GA12162@game.jcrosoft.org>
	<200804191922.53883.matthias.fuchs@esd-electronics.com>
Message-ID: <20080420035435.GB27176@game.jcrosoft.org>

On 19:22 Sat 19 Apr     , Matthias Fuchs wrote:
> Hi,
> 
> I tried this in cfi_flash.c:
> 
> struct apl_s   {
> 	ulong start;
> 	ulong size;
> }
> 
> struct apl_s apl[] __attribute__((weak)) = {};

The problem with weak var is that the first declaration define the
sizeof the var. and the other define the data;

As sugest Wolfgang we could do it like this

in cfi_flash.c


--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1873,6 +1873,12 @@ unsigned long flash_init (void)
 {
 	unsigned long size = 0;
 	int i;
+if define(CONFIG_FLASH_AUTOPROTECT)
+struct apl_s apl[] = init_flash_autoprotect();
+#endif

#ifdef CFG_FLASH_PROTECTION
 	char *s = getenv("unlock");
@@ -1966,6 +1972,17 @@ unsigned long flash_init (void)
 		       CFG_ENV_ADDR_REDUND + CFG_ENV_SIZE_REDUND - 1,
 		       flash_get_info(CFG_ENV_ADDR_REDUND));
 #endif
+
+#if defined(CONFIG_FLASH_AUTOPROTECT)
+	for (i = 0; i < (sizeof(apl) / sizeof(struct apl_s)); i++) {
+		debug("autoprotecting from %08x to %08x\n",
+		      apl[i].start, apl[i].start + apl[i].size - 1);
+		flash_protect (FLAG_PROTECT_SET,
+			       apl[i].start,
+			       apl[i].start + apl[i].size - 1,
+			       flash_get_info(apl[i].start));
+	}
+#endif

in config header

struct apl_s apl* inline init_flash_autoprotect()
{
	struct apl_s a[] = {
	{1, 3},
	{4, 5},
	};

	return a;
}
Best Regards,
J.



From vapier at gentoo.org  Sun Apr 20 06:51:03 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 20 Apr 2008 00:51:03 -0400
Subject: [U-Boot-Users] 1.3.3 merge window still open ?
Message-ID: <200804200051.03542.vapier@gentoo.org>

i dont see 1.3.3-rc1 tagged yet ... i have updates (not strictly bugfixes) 
queued up ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080420/7a12b2d0/attachment.pgp 

From wd at denx.de  Sun Apr 20 07:25:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 07:25:54 +0200
Subject: [U-Boot-Users] 1.3.3 merge window still open ?
In-Reply-To: Your message of "Sun, 20 Apr 2008 00:51:03 EDT."
	<200804200051.03542.vapier@gentoo.org>
Message-ID: <20080420052554.D43A324035@gemini.denx.de>

In message <200804200051.03542.vapier at gentoo.org> you wrote:
> 
> i dont see 1.3.3-rc1 tagged yet ... i have updates (not strictly bugfixes)>  
> queued up ...

The merge window is closed; see
http://www.denx.de/wiki/UBoot/ReleaseCycle

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: wd at denx.de
The important thing about being a leader is not being right or wrong,
but being *certain*.                    - Terry Pratchett, _Truckers_



From wd at denx.de  Sun Apr 20 08:36:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:46 +0200
Subject: [U-Boot-Users] [PATCH] Add support for u-boot in svn and
	localversion-* files
In-Reply-To: Your message of "Tue, 08 Apr 2008 14:00:57 EDT."
	<1207677657-31722-1-git-send-email-vapier@gentoo.org>
Message-ID: <20080420063646.A5514248C7@gemini.denx.de>

In message <1207677657-31722-1-git-send-email-vapier at gentoo.org> you wrote:
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
>  tools/setlocalversion |   14 ++++++++++++++
>  1 files changed, 14 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: wd at denx.de
They weren't that important. They were merely at the top. The  people
who  really  run organizations are usually found several levels down,
where it's still possible to get things done.
                                      - Terry Pratchett, _Small Gods_



From wd at denx.de  Sun Apr 20 08:36:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:46 +0200
Subject: [U-Boot-Users] [PATCH v2] MX31ADS network and flash updates
In-Reply-To: Your message of "Thu, 03 Apr 2008 17:04:22 +0200."
	<Pine.LNX.4.64.0804031701310.18539@axis700.grange>
Message-ID: <20080420063646.95934248C6@gemini.denx.de>

In message <Pine.LNX.4.64.0804031701310.18539 at axis700.grange> you wrote:
> This patch depends on the previous two patches, introducing the 
> CONFIG_FLASH_SPANSION_S29WS_N and CONFIG_ARP_TIMEOUT configuration 
> options. It allows U-Boot to use buffered writes to the Spansion NOR flash 
> installed on this board, and eliminates long delays in network transfers 
> after the board startup.
> 
> Also modify flash layout to embed main and redundant environment blocks in 
> the U-Boot image.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Build a system that even a fool can use and only a fool will want  to
use it.



From wd at denx.de  Sun Apr 20 08:36:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:46 +0200
Subject: [U-Boot-Users] [PATCH v3 7/7] Support for the MX31ADS
	evaluation board from Freescale
In-Reply-To: Your message of "Mon, 14 Apr 2008 10:53:12 +0200."
	<Pine.LNX.4.64.0804141041570.5332@axis700.grange>
Message-ID: <20080420063646.81B0D24657@gemini.denx.de>

In message <Pine.LNX.4.64.0804141041570.5332 at axis700.grange> you wrote:
> This patch adds support for the MX31ADS evaluation board from Freescale, 
> initialization code is copied from RedBoot sources, also provided by 
> Freescale.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
...
> Changes since v2: merge with upstream
> 
>  MAKEALL                                     |    1 +
>  Makefile                                    |    3 +
>  board/mx31ads/Makefile                      |   47 +++++
>  board/{imx31_litekit => mx31ads}/config.mk  |    0 
>  board/mx31ads/lowlevel_init.S               |  281 +++++++++++++++++++++++++++
>  board/mx31ads/mx31ads.c                     |   95 +++++++++
>  board/{imx31_litekit => mx31ads}/u-boot.lds |    0 
>  include/asm-arm/arch-mx31/mx31-regs.h       |   14 ++
>  include/configs/mx31ads.h                   |  157 +++++++++++++++
>  9 files changed, 598 insertions(+), 0 deletions(-)
>  create mode 100644 board/mx31ads/Makefile
>  copy board/{imx31_litekit => mx31ads}/config.mk (100%)
>  create mode 100644 board/mx31ads/lowlevel_init.S
>  create mode 100644 board/mx31ads/mx31ads.c
>  copy board/{imx31_litekit => mx31ads}/u-boot.lds (100%)
>  create mode 100644 include/configs/mx31ads.h

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Parkinson's Law:  Work expands to fill the time alloted it.



From wd at denx.de  Sun Apr 20 08:36:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:46 +0200
Subject: [U-Boot-Users] [PATCH/review] Blackfin: fix up UART status bit
	handling
In-Reply-To: Your message of "Wed, 09 Apr 2008 02:06:22 EDT."
	<1207721182-29697-2-git-send-email-vapier@gentoo.org>
Message-ID: <20080420063646.B519624657@gemini.denx.de>

In message <1207721182-29697-2-git-send-email-vapier at gentoo.org> you wrote:
> Some Blackfin UARTs are read-to-clear while others are write-to-clear.
> This can cause problems when we poll the LSR and then later try and handle
> any errors detected.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>

I guess I will receive a pull request for the BF custodian repo for
this and the other "PATCH/review" messages you posted?

Do you have any plan when you will send the pull request?

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: wd at denx.de
The human mind ordinarily operates at only ten percent of its capaci-
ty - the rest is overhead for the operating system.



From wd at denx.de  Sun Apr 20 08:36:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:46 +0200
Subject: [U-Boot-Users] [PATCH/review] Blackfin: make baud calculation
	more accurate
In-Reply-To: Your message of "Wed, 09 Apr 2008 02:06:21 EDT."
	<1207721182-29697-1-git-send-email-vapier@gentoo.org>
Message-ID: <20080420063646.C4BD7248C6@gemini.denx.de>

In message <1207721182-29697-1-git-send-email-vapier at gentoo.org> you wrote:
> We should use the algorithm in the Linux kernel so that the UART divisor
> calculation is more accurate.  It also fixes problems on some picky UARTs
> that have sampling anomalies.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
>  cpu/blackfin/serial.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/cpu/blackfin/serial.h b/cpu/blackfin/serial.h
> index 1f0f4b4..d268da5 100644
> --- a/cpu/blackfin/serial.h
> +++ b/cpu/blackfin/serial.h
> @@ -179,7 +179,7 @@ static inline void serial_early_set_baud(uint32_t baud)
>  	 * The +1 is to make sure we over sample just a little
^^^^^^^^^^^^^^^^^^^

Fix!

>  	 * rather than under sample the incoming signals.
>  	 */
> -	uint16_t divisor = (get_sclk() / (baud * 16)) + 1;
> +	uint16_t divisor = (get_sclk() + (baud * 8)) / (baud * 16);

Please make sure to adjust the comment, as there is no "+1" any more
in the new code.

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: wd at denx.de
I am pleased to see that we have differences.  May we together become
greater than the sum of both of us.
	-- Surak of Vulcan, "The Savage Curtain", stardate 5906.4



From wd at denx.de  Sun Apr 20 08:36:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:46 +0200
Subject: [U-Boot-Users] [PATCH/review] Blackfin: update cpu header
	definitions from latest Blackfin toolchain
In-Reply-To: Your message of "Wed, 09 Apr 2008 02:17:11 EDT."
	<1207721831-32630-2-git-send-email-vapier@gentoo.org>
Message-ID: <20080420063646.D783E24657@gemini.denx.de>

In message <1207721831-32630-2-git-send-email-vapier at gentoo.org> you wrote:
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
>  cpu/blackfin/initcode.c                         |    2 +-
>  include/asm-blackfin/mach-common/bits/bootrom.h |   11 ++++
>  include/asm-blackfin/mach-common/bits/ebiu.h    |    2 +-
>  include/asm-blackfin/mach-common/bits/lockbox.h |   68 +++++++++++-----------
>  4 files changed, 47 insertions(+), 36 deletions(-)
...
> diff --git a/include/asm-blackfin/mach-common/bits/lockbox.h b/include/asm-blackfin/mach-common/bits/lockbox.h
> index 8b696f3..09310e1 100644
> --- a/include/asm-blackfin/mach-common/bits/lockbox.h
> +++ b/include/asm-blackfin/mach-common/bits/lockbox.h
> @@ -11,14 +11,14 @@
>  
>  /* SESR argument structure. Expected to reside at 0xFF900018. */
>  typedef struct SESR_args {
> -	unsigned short usFlags;		/* security firmware flags		*/
> -	unsigned short usIRQMask;	/* interrupt mask			*/
> -	unsigned long ulMessageSize;	/* message length in bytes		*/
> -	unsigned long ulSFEntryPoint;	/* entry point of secure function	*/
> -	unsigned long ulMessagePtr;	/* pointer to the buffer containing	*/
> -					/* the digital signature and message	*/
> -	unsigned long ulReserved1;	/* reserved				*/
> -	unsigned long ulReserved2;	/* reserved				*/
> +  unsigned short  usFlags;            /* security firmware flags            */
> +  unsigned short  usIRQMask;          /* interrupt mask                     */
> +  unsigned long   ulMessageSize;      /* message length in bytes            */
> +  unsigned long   ulSFEntryPoint;     /* entry point of secure function     */
> +  unsigned long   ulMessagePtr;       /* pointer to the buffer containing
> +                                         the digital signature and message  */
> +  unsigned long   ulReserved1;        /* reserved                           */
> +  unsigned long   ulReserved2;        /* reserved                           */

Indentation by TABs, please!!

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: wd at denx.de
"The lesser of two evils -- is evil."             - Seymour (Sy) Leon



From wd at denx.de  Sun Apr 20 08:36:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:46 +0200
Subject: [U-Boot-Users] ne2000 compile error
In-Reply-To: Your message of "Fri, 11 Apr 2008 17:57:08 +0300."
	<47FF7C44.6040600@comsys.ro>
Message-ID: <20080420063646.E77E5248C6@gemini.denx.de>

In message <47FF7C44.6040600 at comsys.ro> you wrote:
>
> Fixed it for now. #ifndef CONFIG_DRIVER_AX88796 could be replaced with 
> something a little more generic
> like a CFG_CUSTOM_GET_PROM_NE2000 or something. Or the code could be 
> implemented in a .c file and the
> generic get_prom() could be made weak. I think that implementing 
> non-static, non-inlined functions in header files
> is bad style. Breaking existing code in the process is even worse.

Unfortunately your patch is line wrapped and thus unusable.

Please fix your mailer setup and resubmit. I really recommend to use
git tools to send the messages.

> --- a/drivers/net/ne2000.c
> +++ b/drivers/net/ne2000.c
> @@ -125,6 +125,9 @@ dp83902a_init(void)
>      dp83902a_priv_data_t *dp = &nic;
>      u8* base;
>  
> +#if defined(NE2000_BASIC_INIT)
> +    int i;
> +#endif
>      DEBUG_FUNCTION();
>  
>      base = dp->base;
> @@ -738,6 +741,94 @@ u8 dev_addr[6];
>  #define PCNET_RESET    0x1f    /* Issue a read to reset, a write to 
> clear. */
^^^^^^^^^^^^^^^^^^^^ Here

>  #define PCNET_MISC    0x18    /* For IBM CCAE and Socket EA cards */
>  
> +#ifndef CONFIG_DRIVER_AX88796L
> +static void pcnet_reset_8390(void)
> +{
> +    int i, r;
> +
> +    PRINTK("nic base is %lx\n", nic_base);
> +
> +    n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
> +    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
> n2k_inb(E8390_CMD));
^^^^^^^^^^^^^^^^^^^^ Here

> +    n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
> +    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
> n2k_inb(E8390_CMD));
^^^^^^^^^^^^^^^^^^^^ Here

> +    n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
> +    PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, 
> n2k_inb(E8390_CMD));
^^^^^^^^^^^^^^^^^^^^ Here

And so on...

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: wd at denx.de
"The combination of a number of things to make existence worthwhile."
"Yes, the philosophy of 'none,' meaning 'all.'"
	-- Spock and Lincoln, "The Savage Curtain", stardate 5906.4



From wd at denx.de  Sun Apr 20 08:36:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:47 +0200
Subject: [U-Boot-Users] [PATCH] NE2000: Fix regresssion introduced by
	e710185aae90 on non AX88796
In-Reply-To: Your message of "Sat, 12 Apr 2008 07:00:19 +0200."
	<1207976419-6571-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080420063647.03886248C7@gemini.denx.de>

In message <1207976419-6571-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Move non-inlied functions into specific drivers file
> Set get_prom as weak
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Signed-off-by: Vlad Lungu <vlad at comsys.ro>

Are you planning to fix and resubmit the patch according to Ben's
comment?

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: wd at denx.de
"Here's a fish hangs in the net like a poor man's right in  the  law.
'Twill hardly come out."     - Shakespeare, Pericles, Act II, Scene 1



From wd at denx.de  Sun Apr 20 08:36:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:47 +0200
Subject: [U-Boot-Users] [PATCH] Fixed pcnet io_base
In-Reply-To: Your message of "Wed, 10 Oct 2007 23:02:09 +0300."
	<470D2FC1.3070906@comsys.ro>
Message-ID: <20080420063647.46DC8248C6@gemini.denx.de>


Dear Ben,

this patch is still on my "open" list. Can you please review and
apply if it makes sense to you? Thanks.

------- Forwarded Message

Date:    Wed, 10 Oct 2007 23:02:09 +0300
From:    Vlad Lungu <vlad at comsys.ro>
To:      u-boot-users at lists.sourceforge.net, wd at denx.de
Subject: [PATCH] Fixed pcnet io_base

Bus and phys address are not always the same

Signed-off-by: Vlad Lungu <vlad at comsys.ro>
---
 drivers/pcnet.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/pcnet.c b/drivers/pcnet.c
index 2af0e8f..22edb48 100644
--- a/drivers/pcnet.c
+++ b/drivers/pcnet.c
@@ -196,6 +196,7 @@ int pcnet_initialize(bd_t *bis)
 	 * Setup the PCI device.
 	 */
 	pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0, (unsigned int *)&de
v->iobase);
+	dev->iobase=pci_io_to_phys(devbusfn,dev->iobase);
 	dev->iobase &= ~0xf;
 
 	PCNET_DEBUG1("%s: devbusfn=0x%x iobase=0x%x: ",
-- 
1.5.2.2

------- End of Forwarded Message


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: wd at denx.de
Where a calculator on the ENIAC is equipped with 18,000 vacuum  tubes
and  weighs  30  tons,  computers  in  the future may have only 1,000
vacuum tubes and weigh only 1/2 tons. - Popular Mechanics, March 1949



From wd at denx.de  Sun Apr 20 08:36:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:47 +0200
Subject: [U-Boot-Users] [PATCH] Added Am79C970A chip id to pcnet (fwd)
Message-ID: <20080420063647.56A32248C7@gemini.denx.de>

Dear Ben,

this patch is still on my "open" list. Can you please review and
apply if it makes sense to you? Thanks.

------- Forwarded Message

Date:    Wed, 10 Oct 2007 23:04:23 +0300
From:    Vlad Lungu <vlad at comsys.ro>
To:      u-boot-users at lists.sourceforge.net, wd at denx.de
Subject: [PATCH] Added Am79C970A chip id to pcnet

Signed-off-by: Vlad Lungu <vlad at comsys.ro>
---
 drivers/pcnet.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/pcnet.c b/drivers/pcnet.c
index 22edb48..3424846 100644
--- a/drivers/pcnet.c
+++ b/drivers/pcnet.c
@@ -261,6 +261,9 @@ static int pcnet_probe(struct eth_device* dev, bd_t *bis, i
nt dev_nr)
        return -1;
     chip_version = (chip_version >> 12) & 0xffff;
     switch (chip_version) {
+    case 0x2621:
+	chipname = "PCnet/PCI II 79C970A"; /* PCI */
+	break;
 #ifdef CONFIG_PCNET_79C973
     case 0x2625:
 	chipname = "PCnet/FAST III 79C973"; /* PCI */
-- 
1.5.2.2

------- End of Forwarded Message


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: wd at denx.de
Old programmers never die, they just branch to a new address.



From wd at denx.de  Sun Apr 20 08:36:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:47 +0200
Subject: [U-Boot-Users]  [PATCH] ads5121e DRAM init (fwd)
Message-ID: <20080420063647.6735424657@gemini.denx.de>

Dear Chris,

as discussed, I have this patch for the ads5121e DRAM init code
sitting in my queue; you mentioned you had a more recent / better
patch available. I would appreciate if you could submit it soon to
this mailing list so we can include it as part of the upcoming next
U-Boot release.

Thanks in advance.

------- Forwarded Message

Date:    Wed, 02 Apr 2008 20:34:14 +0200
From:    Kenneth Johansson <kenneth at southpole.se>
To:      u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] [PATCH] ads5121e DRAM init


    Do the DRAM init according to micron MT47H64M8B6-37E
    documentation.
    
    Signed-off-by: Kenneth Johansson <kenneth at southpole.se>

diff --git a/board/ads5121/ads5121.c b/board/ads5121/ads5121.c
index 8629b03..606cc6b 100644
--- a/board/ads5121/ads5121.c
+++ b/board/ads5121/ads5121.c
@@ -158,26 +158,18 @@ long int fixed_sdram (void)
 		im->mddrc.ddr_command = CFG_MICRON_NOP;
 
 	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_EM2;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
-	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_EM2;
-	im->mddrc.ddr_command = CFG_MICRON_EM3;
-	im->mddrc.ddr_command = CFG_MICRON_EN_DLL;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM2;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM3;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_MR_DLL_RESET;
+                                
 	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
 	im->mddrc.ddr_command = CFG_MICRON_RFSH;
-	im->mddrc.ddr_command = CFG_MICRON_INIT_DEV_OP;
-	im->mddrc.ddr_command = CFG_MICRON_OCD_DEFAULT;
-	im->mddrc.ddr_command = CFG_MICRON_PCHG_ALL;
-	im->mddrc.ddr_command = CFG_MICRON_NOP;
+	im->mddrc.ddr_command = CFG_MICRON_RFSH;
+
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_MR;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM_OCD;
+	im->mddrc.ddr_command = CFG_MICRON_DDR2_LM_EM_EXIT;
 
 	/* Start MDDRC */
 	im->mddrc.ddr_time_config0 = CFG_MDDRC_TIME_CFG0_RUN;
diff --git a/include/configs/ads5121.h b/include/configs/ads5121.h
index c147424..83781c6 100644
--- a/include/configs/ads5121.h
+++ b/include/configs/ads5121.h
@@ -117,14 +117,22 @@
 #define CFG_MDDRC_TIME_CFG1	0x54EC1168
 #define CFG_MDDRC_TIME_CFG2	0x35210864
 
-#define CFG_MICRON_NOP		0x01380000
-#define CFG_MICRON_PCHG_ALL	0x01100400
-#define CFG_MICRON_EM2		0x01020000
-#define CFG_MICRON_EM3		0x01030000
-#define CFG_MICRON_EN_DLL	0x01010000
-#define CFG_MICRON_RFSH		0x01080000
-#define CFG_MICRON_INIT_DEV_OP	0x01000432
-#define CFG_MICRON_OCD_DEFAULT	0x01010780
+/* DRAM commands */
+#define CFG_MICRON_NOP			0x01380000
+#define CFG_MICRON_PCHG_ALL		0x01100400
+#define CFG_MICRON_RFSH			0x01080000
+
+/* DDR2 specific commands */
+#define CFG_MICRON_DDR2_LM_MR_DLL_RESET	0x01000100	/* reset DLL   
     */
+#define CFG_MICRON_DDR2_LM_MR		0x01000432	/* burst lenght 4   */
+							/* CAS 3            */
+							/* Write recovery 3 */
+#define CFG_MICRON_DDR2_LM_EM_OCD	0x01010780	/* OCD default      */
+							/* DQS# enable      */
+#define CFG_MICRON_DDR2_LM_EM_EXIT	0x01010400	/* DQS# enable      */
+#define CFG_MICRON_DDR2_LM_EM		0x01010000
+#define CFG_MICRON_DDR2_LM_EM2		0x01020000
+#define CFG_MICRON_DDR2_LM_EM3		0x01030000
 
 /* DDR Priority Manager Configuration */
 #define CFG_MDDRCGRP_PM_CFG1	0x000777AA



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users


------- End of Forwarded Message

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: wd at denx.de
The reasonable man adapts himself to the world; the unreasonable  one
persists  in  trying  to  adapt  the  world to himself. Therefore all
progress depends on the unreasonable man."      - George Bernard Shaw



From wd at denx.de  Sun Apr 20 08:36:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 08:36:47 +0200
Subject: [U-Boot-Users] usb_ohci.c: warning: dereferencing type-punned
	pointer will break strict-aliasing rules
Message-ID: <20080420063647.77F3C248C6@gemini.denx.de>

Hello Markus,

the OHCI driver code is still emitting lots of warning messages:

usb_ohci.c: In function 'roothub_a':
usb_ohci.c:156: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:156: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'roothub_b':
usb_ohci.c:158: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'roothub_status':
usb_ohci.c:160: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'sohci_return_job':
usb_ohci.c:521: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:522: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:524: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:525: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'ep_link':
usb_ohci.c:635: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:643: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:651: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:659: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'ep_unlink':
usb_ohci.c:722: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:724: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:739: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:741: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'td_submit_job':
usb_ohci.c:907: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:923: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'ohci_submit_rh_msg':
usb_ohci.c:1275: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1399: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'hc_reset':
usb_ohci.c:1590: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1591: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1593: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1603: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1611: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1614: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1615: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'hc_start':
usb_ohci.c:1641: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1642: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1644: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1647: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1649: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1650: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1655: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1661: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1664: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1667: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1671: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1673: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c: In function 'hc_interrupt':
usb_ohci.c:1706: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1710: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1743: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1744: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1746: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1747: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1752: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1760: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1762: warning: dereferencing type-punned pointer will break strict-aliasing rules
usb_ohci.c:1766: warning: dereferencing type-punned pointer will break strict-aliasing rules



Could you please have a look?

Thanks in advance.

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: wd at denx.de
Horses just naturally have mohawk haircuts.



From vapier at gentoo.org  Sun Apr 20 09:08:38 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 20 Apr 2008 03:08:38 -0400
Subject: [U-Boot-Users] [PATCH/review] Blackfin: fix up UART status bit
	handling
In-Reply-To: <20080420063646.B519624657@gemini.denx.de>
References: <20080420063646.B519624657@gemini.denx.de>
Message-ID: <200804200308.40844.vapier@gentoo.org>

On Sunday 20 April 2008, Wolfgang Denk wrote:
> In message <1207721182-29697-2-git-send-email-vapier at gentoo.org> you wrote:
> > Some Blackfin UARTs are read-to-clear while others are write-to-clear.
> > This can cause problems when we poll the LSR and then later try and
> > handle any errors detected.
> >
> > Signed-off-by: Mike Frysinger <vapier at gentoo.org>
>
> I guess I will receive a pull request for the BF custodian repo for
> this and the other "PATCH/review" messages you posted?

anything i post with "PATCH/review" is intended for review only.  i'll stick 
them into the BF repo and have you pull them later since you didnt like me 
asking for straight pulls.

> Do you have any plan when you will send the pull request?

that's why i asked about the merge window.  since it's closed, i wont make any 
requests until it's open.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080420/f101227f/attachment.pgp 

From lilja.magnus at gmail.com  Sun Apr 20 10:35:03 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Sun, 20 Apr 2008 10:35:03 +0200
Subject: [U-Boot-Users] [PATCH] i.MX31: Fix architecture numbers for ADS and
	Litekit boards
Message-ID: <480B0037.2040305@gmail.com>

Correct the Linux architecture number for i.MX31 Litekit and ADS boards.

Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
---

 board/imx31_litekit/imx31_litekit.c |    2 +-
 board/mx31ads/mx31ads.c             |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/board/imx31_litekit/imx31_litekit.c b/board/imx31_litekit/imx31_litekit.c
index 5ba60e9..e0fbf25 100644
--- a/board/imx31_litekit/imx31_litekit.c
+++ b/board/imx31_litekit/imx31_litekit.c
@@ -52,7 +52,7 @@ int board_init (void)
 	mx31_gpio_mux(MUX_RTS1__UART1_RTS_B);
 	mx31_gpio_mux(MUX_RTS1__UART1_CTS_B);
 
-	gd->bd->bi_arch_number = 447;		/* board id for linux */
+	gd->bd->bi_arch_number = MACH_TYPE_MX31LITE; /* board id for linux */
 	gd->bd->bi_boot_params = (0x80000100);	/* adress of boot parameters */
 
 	return 0;
diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c
index 7c50c02..4fc95b4 100644
--- a/board/mx31ads/mx31ads.c
+++ b/board/mx31ads/mx31ads.c
@@ -81,7 +81,7 @@ int board_init (void)
 	readb(CS4_BASE + 8);
 	readb(CS4_BASE + 7);
 
-	gd->bd->bi_arch_number = 447;		/* board id for linux */
+	gd->bd->bi_arch_number = MACH_TYPE_MX31ADS;	/* board id for linux */
 	gd->bd->bi_boot_params = 0x80000100;	/* adress of boot parameters */
 
 	return 0;



From lilja.magnus at gmail.com  Sun Apr 20 10:36:36 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Sun, 20 Apr 2008 10:36:36 +0200
Subject: [U-Boot-Users] [PATCH] i.MX31: Use symbolic names for Litekit
	membases.
Message-ID: <480B0094.9040008@gmail.com>

Use symbolic names instead of hard coded addresses for Litekit membases.

Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
---

 include/configs/imx31_litekit.h |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)


diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 605eb40..5e97cfa 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -28,6 +28,8 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
+#include <asm/arch/mx31-regs.h>
+
  /* High Level Configuration Options */
 #define CONFIG_ARM1136		1    /* This is an arm1136 CPU core */
 #define CONFIG_MX31		1    /* in a mx31 */
@@ -91,7 +93,7 @@
 
 
 #define CONFIG_DRIVER_SMC911X		1
-#define CONFIG_DRIVER_SMC911X_BASE	0xb4020000
+#define CONFIG_DRIVER_SMC911X_BASE	(CS4_BASE + 0x00020000)
 #define CONFIG_DRIVER_SMC911X_32_BIT	1
 
 /*
@@ -127,18 +129,18 @@
  * Physical Memory Map
  */
 #define CONFIG_NR_DRAM_BANKS	1
-#define PHYS_SDRAM_1		0x80000000
+#define PHYS_SDRAM_1		CSD0_BASE
 #define PHYS_SDRAM_1_SIZE	(128 * 1024 * 1024)
 
 /*-----------------------------------------------------------------------
  * FLASH and environment organization
  */
-#define CFG_FLASH_BASE		0xa0000000
+#define CFG_FLASH_BASE		CS0_BASE
 #define CFG_MAX_FLASH_BANKS	1           /* max number of memory banks */
 #define CFG_MAX_FLASH_SECT	128	     /* max number of sectors on one chip */
 #define CFG_MONITOR_BASE	CFG_FLASH_BASE /* Monitor at beginning of flash */
 
-#define CFG_ENV_ADDR		0xa01f0000
+#define CFG_ENV_ADDR		(CFG_FLASH_BASE + 0x001f0000)
 #define	CFG_ENV_IS_IN_FLASH	1
 #define CFG_ENV_SECT_SIZE	(64 * 1024)
 #define CFG_ENV_SIZE		(64 * 1024)



From lilja.magnus at gmail.com  Sun Apr 20 10:38:12 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Sun, 20 Apr 2008 10:38:12 +0200
Subject: [U-Boot-Users] [PATCH] i.MX31: Enable SPI and MC13783/RTC support
 for the Litekit board
Message-ID: <480B00F4.6030406@gmail.com>

This patch enables SPI and MC13783/RTC support for the Litekit board.

Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
---

 board/imx31_litekit/imx31_litekit.c |   12 ++++++++++++
 include/configs/imx31_litekit.h     |    8 ++++++++
 2 files changed, 20 insertions(+), 0 deletions(-)


diff --git a/board/imx31_litekit/imx31_litekit.c b/board/imx31_litekit/imx31_litekit.c
index e0fbf25..263dd9f 100644
--- a/board/imx31_litekit/imx31_litekit.c
+++ b/board/imx31_litekit/imx31_litekit.c
@@ -52,6 +52,18 @@ int board_init (void)
 	mx31_gpio_mux(MUX_RTS1__UART1_RTS_B);
 	mx31_gpio_mux(MUX_RTS1__UART1_CTS_B);
 
+	/* SPI2 */
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS2);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SCLK);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SPI_RDY);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_MOSI);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_MISO);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS0);
+	mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS1);
+
+	/* start SPI2 clock */
+	__REG(CCM_CGR2) = __REG(CCM_CGR2) | (3 << 4);
+
 	gd->bd->bi_arch_number = MACH_TYPE_MX31LITE; /* board id for linux */
 	gd->bd->bi_boot_params = (0x80000100);	/* adress of boot parameters */
 
diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 5e97cfa..4281d73 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -63,6 +63,12 @@
 #define CONFIG_MX31_UART	1
 #define CFG_MX31_UART1		1
 
+#define CONFIG_HARD_SPI		1
+#define CONFIG_MXC_SPI		1
+#define CONFIG_MXC_SPI_IFACE	1
+
+#define CONFIG_RTC_MC13783	1
+
 /* allow to overwrite serial and ethaddr */
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_CONS_INDEX	1
@@ -77,6 +83,8 @@
 
 #define CONFIG_CMD_MII
 #define CONFIG_CMD_PING
+#define CONFIG_CMD_SPI
+#define CONFIG_CMD_DATE
 
 #define CONFIG_BOOTDELAY	3
 



From slzhang1980 at gmail.com  Sun Apr 20 11:01:49 2008
From: slzhang1980 at gmail.com (=?GB2312?B?1cXKwMDW?=)
Date: Sun, 20 Apr 2008 17:01:49 +0800
Subject: [U-Boot-Users] Help! u-boot-1.3.2 booting linux-2.6.25 kernel,
	hanging after Booting using the fdt at 0x600000
Message-ID: <8d59c9040804200201l74c86335q1db2dcc8467a62bb@mail.gmail.com>

Hi, all,

      I'm tying to porting the kernel (2.6.25) to the mpc8247
platform, use the u-boot (1.3.2)
after run the command:

>tftp 300000 uImage; tftp 600000 mpc8247.dtb; bootm 300000 - 600000

the output like this:

[snip]
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x600000

then, hanging...

and this is my mpc8247.dts, reference to mgcoge.dts and ep8248e.dts
from www.denx.de.
--------------------------------------------------------------------------------------------------------
/ {
       model = "MPC8247";
       compatible = "fsl,mpc8247";
       #address-cells = <1>;
       #size-cells = <1>;

       aliases {
               ethernet0 = &eth0;
               serial0 = &scc1;
       };

       cpus {
               #address-cells = <1>;
               #size-cells = <0>;

               PowerPC,8247 at 0 {
                       device_type = "cpu";
                       reg = <0>;
                       d-cache-line-size = <20>;
                       i-cache-line-size = <20>;
                       d-cache-size = <4000>;
                       i-cache-size = <4000>;
                       bus-frequency = <0>;
                       timebase-frequency = <0>;
                       clock-frequency = <0>;
               };
       };

       memory {
               device_type = "memory";
               reg = <0 0>;
       };

       localbus at fb010100 {
               compatible = "fsl,mpc8247-localbus",
                            "fsl,pq2-localbus";
               #address-cells = <2>;
               #size-cells = <1>;
               reg = <fb010100 40>;

               ranges = <0 0 fb000000 00800000>;

               flash at 0,0 {
                       compatible = "cfi-flash";
                       reg = <0 0 800000>;
                       #address-cells = <1>;
                       #size-cells = <1>;
                       bank-width = <2>;
                       device-width = <2>;
               };

       };

       soc at fb000000 {
               #address-cells = <1>;
               #size-cells = <1>;
               device_type = "soc";
               compatible = "fsl,mpc8247", "fsl,pq2-soc";
               ranges = <00000000 fb000000 00053000>;
               reg = <fb000000 00053000>;

               cpm at 119c0 {
                       #address-cells = <1>;
                       #size-cells = <1>;
                       compatible = "fsl,mpc8247-cpm", "fsl,cpm2";
                       reg = <119c0 30>;
                       ranges;

                       muram at 0 {
                               #address-cells = <1>;
                               #size-cells = <1>;
                               ranges = <0 0 10000>;

                               data at 0 {
                                       compatible = "fsl,cpm-muram-data";
                                       reg = <0 2000 9800 800>;
                               };
                       };

                       brg at 119f0 {
                               compatible = "fsl,mpc8272-brg",
                                            "fsl,cpm2-brg",
                                            "fsl,cpm-brg";
                               reg = <119f0 10 115f0 10>;
                       };

                       /* Monitor port/SCC1 */
                       scc1: serial at 11a00 {
                               device_type = "serial";
                               compatible = "fsl,mpc8247-smc-uart",
                                            "fsl,cpm2-smc-uart";
                               reg = <11a00 20 8000 100>;
                               interrupts = <28 8>;
                               interrupt-parent = <&PIC>;
                               fsl,cpm-brg = <1>;
                               fsl,cpm-command = <8c00000>;
                       };

                       mdio at 10d60 {
                               device_type = "mdio";
                               compatible = "fsl,mpc8247-mdio-bitbang",
                                            "fsl,mpc8272-mdio-bitbang",
                                            "fsl,cpm2-mdio-bitbang";
                               reg = <10d60 14>;
                               #address-cells = <1>;
                               #size-cells = <0>;
                               fsl,mdio-pin = <1d>;
                               fsl,mdc-pin = <7>;

                               PHY0: ethernet-phy0 {
                                             device_type = "ethernet-phy";
                                             interrupt-parent = <&PIC>;
                                             interrupts = <3b 8>;
                                             reg = <0>;
                               };

                               PHY1: ethernet-phy1 {
                                             device_type = "ethernet-phy";
                                             interrupt-parent = <&PIC>;
                                             interrupts = <3a 8>;
                                             reg = <3>;
                               };
                       };

                       eth0: ethernet at 11300 {
                               device_type = "network";
                               compatible = "fsl,mpc8272-scc-enet",
                                            "fsl,cpm2-scc-enet";
                               reg = <11300 20 8400 100 11390 1>;
                               mac-address = [ 00 00 00 00 00 00 ];
                               interrupts = <20 8>;
                               interrupt-parent = <&PIC>;
                               phy-handle = <&PHY0>;
                               rx-clock = <9>;
                               tx-clock = <a>;
                               linux,network-index = <0>;
                               fsl,cpm-command = <12000300>;
                       };

                       eth1: ethernet at 11320 {
                               device_type = "network";
                               compatible = "fsl,mpc8272-scc-enet",
                                            "fsl,cpm2-scc-enet";
                               reg = <11320 20 8500 100 113b0 1>;
                               mac-address = [ 00 00 00 00 00 00 ];
                               interrupts = <21 8>;
                               interrupt-parent = <&PIC>;
                               phy-handle = <&PHY1>;
                               rx-clock = <d>;
                               tx-clock = <e>;
                               linux,network-index = <1>;
                               fsl,cpm-command = <16200300>;
                       };

                       usb at 11b60 {
                               #address-cells = <1>;
                               #size-cells = <0>;
                               compatible = "fsl,mpc8247-usb",
                                            "fsl,cpm2-usb";
                               reg = <11b60 18 8b00 100>;
                               interrupt-parent = <&PIC>;
                               interrupts = <b 8>;
                               fsl,cpm-command = <2e600000>;
                       };
               };

               PIC: interrupt-controller at 10c00 {
                       compatible = "fsl,mpc8247-pic", "fsl,pq2-pic";
                       #interrupt-cells = <2>;
                       interrupt-controller;
                       reg = <10c00 28>;
               };
       };

       chosen {
               linux,stdout-path = "/soc/cpm/serial at 11a00";
       };
};
---------------------------------------------------------------------------------------------------------

I have use the method by lighting the led, and found out the kernel
hang at the call
at  bl  call_setup_cpu (in ../kernel/head_32.S). In fact, it hang at
the function
setup_common_caches (in ../kernel/cpu_setup_6xx.S), I think it show
that the kernel
can not enable the I-caches and D-caches.

Why?
Please help me, thanks!



From matthias.fuchs at esd-electronics.com  Sun Apr 20 15:22:40 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Sun, 20 Apr 2008 15:22:40 +0200
Subject: [U-Boot-Users] [PATCH] cfi-flash: Add CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: <20080420011410.709C5248A0@gemini.denx.de>
References: <20080420011410.709C5248A0@gemini.denx.de>
Message-ID: <200804201522.40808.matthias.fuchs@esd-electronics.com>

Hi Wolfgang,

even though I like the weak stuff, I agree with you. I also like Stefan's
idea about removing the #ifdef from the code.

So I will update my patch in this direction.

The main idea behind my patch is to fix the bootloader autoprotection
for 4xx. Do you (sr, J., others) think i is also a good idea to add this:

        /* Monitor protection ON by default */
#if (CFG_MONITOR_BASE >= CFG_FLASH_BASE)
        flash_protect (FLAG_PROTECT_SET,
                       CFG_MONITOR_BASE,
+#if defined(CONFIG_4xx)
			0xffffffff,
+#else
                       CFG_MONITOR_BASE + monitor_flash_len  - 1,
+#endif
                       flash_get_info(CFG_MONITOR_BASE));
#endif

To be honest, I hope to get my autoprotection patch into 1.3.3 (as a bug fix).
But the above three lines would be satisfactory for fixing the issue.
Finally I would like to have both changes applied.

Matthias

On Sunday 20 April 2008 03:14:10 Wolfgang Denk wrote:
> In message <20080418160157.GB12486 at game.jcrosoft.org> you wrote:
> > > +#if defined(CFG_FLASH_AUTOPROTECT_LIST)
> > > +	struct apl_s {
> > > +		ulong start;
> > > +		ulong size;
> > > +	} apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> > > +#endif
> >
> > I think it will be better to create a weak structure.
>
> In the interest of memory footprint I prefer to stick with the #ifdef
> here.
>
> Best regards,
>
> Wolfgang Denk




From biggerbadderben at gmail.com  Sun Apr 20 15:49:56 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Sun, 20 Apr 2008 09:49:56 -0400
Subject: [U-Boot-Users] [PATCH] Added Am79C970A chip id to pcnet (fwd)
In-Reply-To: <20080420063647.56A32248C7@gemini.denx.de>
References: <20080420063647.56A32248C7@gemini.denx.de>
Message-ID: <f8328f7c0804200649y2ffa9fd8gfdd7e003297bd8f@mail.gmail.com>

Hi Wolfgang,

On Sun, Apr 20, 2008 at 2:36 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Ben,
>
>  this patch is still on my "open" list. Can you please review and
>  apply if it makes sense to you? Thanks.
>

I don't have access to my build machine right now, and this looks
harmless.  Please pull directly.

regards,
Ben
>  ------- Forwarded Message
>
>  Date:    Wed, 10 Oct 2007 23:04:23 +0300
>  From:    Vlad Lungu <vlad at comsys.ro>
>  To:      u-boot-users at lists.sourceforge.net, wd at denx.de
>  Subject: [PATCH] Added Am79C970A chip id to pcnet
>
>  Signed-off-by: Vlad Lungu <vlad at comsys.ro>
>  ---
>   drivers/pcnet.c |    3 +++
>   1 files changed, 3 insertions(+), 0 deletions(-)
>
>  diff --git a/drivers/pcnet.c b/drivers/pcnet.c
>  index 22edb48..3424846 100644
>  --- a/drivers/pcnet.c
>  +++ b/drivers/pcnet.c
>  @@ -261,6 +261,9 @@ static int pcnet_probe(struct eth_device* dev, bd_t *bis, i
>  nt dev_nr)
>         return -1;
>      chip_version = (chip_version >> 12) & 0xffff;
>      switch (chip_version) {
>  +    case 0x2621:
>  +       chipname = "PCnet/PCI II 79C970A"; /* PCI */
>  +       break;
>   #ifdef CONFIG_PCNET_79C973
>      case 0x2625:
>         chipname = "PCnet/FAST III 79C973"; /* PCI */
>  --
>  1.5.2.2
>
>  ------- End of Forwarded Message
>
>
>  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: wd at denx.de
>  Old programmers never die, they just branch to a new address.
>



From biggerbadderben at gmail.com  Sun Apr 20 16:02:08 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Sun, 20 Apr 2008 10:02:08 -0400
Subject: [U-Boot-Users] [PATCH] Fixed pcnet io_base
In-Reply-To: <20080420063647.46DC8248C6@gemini.denx.de>
References: <470D2FC1.3070906@comsys.ro>
	<20080420063647.46DC8248C6@gemini.denx.de>
Message-ID: <f8328f7c0804200702x40841be6k286dd6e335440692@mail.gmail.com>

Hi Wolfgang,

On Sun, Apr 20, 2008 at 2:36 AM, Wolfgang Denk <wd at denx.de> wrote:
>
>  Dear Ben,
>
>  this patch is still on my "open" list. Can you please review and
>  apply if it makes sense to you? Thanks.
>

This looks OK to me.  Assuming that pci_io_to_phys() is defined on all
relevant architectures, I have no objections.  Unfortunately I can't
run MAKEALL right now, so if it's not too much of a bother please pull
directly.  We can always pull it out if there's a problem, I guess.

regards,
Ben
>  ------- Forwarded Message
>
>  Date:    Wed, 10 Oct 2007 23:02:09 +0300
>  From:    Vlad Lungu <vlad at comsys.ro>
>  To:      u-boot-users at lists.sourceforge.net, wd at denx.de
>  Subject: [PATCH] Fixed pcnet io_base
>
>  Bus and phys address are not always the same
>
>  Signed-off-by: Vlad Lungu <vlad at comsys.ro>
>  ---
>   drivers/pcnet.c |    1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
>  diff --git a/drivers/pcnet.c b/drivers/pcnet.c
>  index 2af0e8f..22edb48 100644
>  --- a/drivers/pcnet.c
>  +++ b/drivers/pcnet.c
>  @@ -196,6 +196,7 @@ int pcnet_initialize(bd_t *bis)
>          * Setup the PCI device.
>          */
>         pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0, (unsigned int *)&de
>  v->iobase);
>  +       dev->iobase=pci_io_to_phys(devbusfn,dev->iobase);
>         dev->iobase &= ~0xf;
>
>         PCNET_DEBUG1("%s: devbusfn=0x%x iobase=0x%x: ",
>  --
>  1.5.2.2
>
>  ------- End of Forwarded Message
>
>
>  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: wd at denx.de
>  Where a calculator on the ENIAC is equipped with 18,000 vacuum  tubes
>  and  weighs  30  tons,  computers  in  the future may have only 1,000
>  vacuum tubes and weigh only 1/2 tons. - Popular Mechanics, March 1949
>



From jamie at shareable.org  Sun Apr 20 18:04:14 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Sun, 20 Apr 2008 17:04:14 +0100
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <1208546341.6654.8.camel@vader.jdub.homelinux.org>
References: <4808AE6F.4030505@largestprime.net>
	<1208536808.6654.6.camel@vader.jdub.homelinux.org>
	<20080418165957.GG31520@shareable.org>
	<1208546341.6654.8.camel@vader.jdub.homelinux.org>
Message-ID: <20080420160413.GC14268@shareable.org>

Josh Boyer wrote:
> > Is it even a good idea?  The UBI (version 1 :-) initial scan is not
> > fast for large flash, and if the bootloader does it too, that's twice
> > as much time to boot.
> 
> It's a good idea, yes.  Particularly if you want to boot from NAND
> flash.
> 
> Can you define "large device"?  It only scans the first 1 or 2 pages for
> each eraseblock to build up the volume tables.  That really isn't that
> slow...

I was thinking this:

Hamish Moffatt wrote (Message-ID: <20080407073227.GA6317 at cloud.net.au>):
> Sorry I should've said 512MiB perhaps: 512 megabytes.
> UBI attach time appears to be about 6 seconds.

If 6 seconds is as fast as it can be done, annoying but fair enough.

Adding _another_ 6 seconds to the boot time seems a lot to me.

The only ways I see to improve the speed in general are:

   1. Partition the NAND into multiple independent UBIs, so the boot
      loader doesn't have the scan the whole chip, but that is
      obviously not so good for wear levelling.  (It's probably
      alright, though, if it's like the /boot partition on a standard
      Linux distro - not updated very often.)

   2. Change UBI's data structure so that the number of pages it needs
      to read is a sub-linear function of the number of erase blocks.
      I think this is what's meant by 'UBI 2'.

To remove the double scan:

> > However, if there was a protocol for bootloader to pass the scan
> > results to the booted kernel, that would be very nice.
> 
> Maybe.  I was never fully convinced of that.

I can understand the hesitation, but I think 6 seconds just to find
the kernel - especially when doing a 'disk resume' - is quite a lot.

Note that I haven't tried UBI myself yet.  I'm going on what has been
written to the list so far, as quoted above.

-- Jamie



From jwboyer at gmail.com  Sun Apr 20 18:44:13 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Sun, 20 Apr 2008 11:44:13 -0500
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <20080420160413.GC14268@shareable.org>
References: <4808AE6F.4030505@largestprime.net>
	<1208536808.6654.6.camel@vader.jdub.homelinux.org>
	<20080418165957.GG31520@shareable.org>
	<1208546341.6654.8.camel@vader.jdub.homelinux.org>
	<20080420160413.GC14268@shareable.org>
Message-ID: <1208709853.6654.23.camel@vader.jdub.homelinux.org>

On Sun, 2008-04-20 at 17:04 +0100, Jamie Lokier wrote:
> Josh Boyer wrote:
> > > Is it even a good idea?  The UBI (version 1 :-) initial scan is not
> > > fast for large flash, and if the bootloader does it too, that's twice
> > > as much time to boot.
> > 
> > It's a good idea, yes.  Particularly if you want to boot from NAND
> > flash.
> > 
> > Can you define "large device"?  It only scans the first 1 or 2 pages for
> > each eraseblock to build up the volume tables.  That really isn't that
> > slow...
> 
> I was thinking this:
> 
> Hamish Moffatt wrote (Message-ID: <20080407073227.GA6317 at cloud.net.au>):
> > Sorry I should've said 512MiB perhaps: 512 megabytes.
> > UBI attach time appears to be about 6 seconds.
> 
> If 6 seconds is as fast as it can be done, annoying but fair enough.

You should read that thread a bit more carefully.  The scan time is
highly dependent upon the NAND driver beneath UBI.  For example, a UBI
scan/attach on a 1GiB device on OLPC was 2 seconds.

> 
> Adding _another_ 6 seconds to the boot time seems a lot to me.

You mean adding another "X amount of time depending on factors outside
of UBI's control."

> The only ways I see to improve the speed in general are:
> 
>    1. Partition the NAND into multiple independent UBIs, so the boot
>       loader doesn't have the scan the whole chip, but that is
>       obviously not so good for wear levelling.  (It's probably
>       alright, though, if it's like the /boot partition on a standard
>       Linux distro - not updated very often.)
> 
>    2. Change UBI's data structure so that the number of pages it needs
>       to read is a sub-linear function of the number of erase blocks.
>       I think this is what's meant by 'UBI 2'.
> 
> To remove the double scan:
> 
> > > However, if there was a protocol for bootloader to pass the scan
> > > results to the booted kernel, that would be very nice.
> > 
> > Maybe.  I was never fully convinced of that.
> 
> I can understand the hesitation, but I think 6 seconds just to find
> the kernel - especially when doing a 'disk resume' - is quite a lot.

You should really stop quoting this 6 second number.

Anyway, passing the scan results from a bootloader becomes very
involved.  You have to store it somewhere, probably preserving a section
of DRAM, which isn't always easy.

> Note that I haven't tried UBI myself yet.  I'm going on what has been
> written to the list so far, as quoted above.

Maybe you should try it :).

josh




From jamie at shareable.org  Sun Apr 20 19:29:37 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Sun, 20 Apr 2008 18:29:37 +0100
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <1208709853.6654.23.camel@vader.jdub.homelinux.org>
References: <4808AE6F.4030505@largestprime.net>
	<1208536808.6654.6.camel@vader.jdub.homelinux.org>
	<20080418165957.GG31520@shareable.org>
	<1208546341.6654.8.camel@vader.jdub.homelinux.org>
	<20080420160413.GC14268@shareable.org>
	<1208709853.6654.23.camel@vader.jdub.homelinux.org>
Message-ID: <20080420172937.GA16184@shareable.org>

Josh Boyer wrote:
> > Hamish Moffatt wrote (Message-ID: <20080407073227.GA6317 at cloud.net.au>):
> > > Sorry I should've said 512MiB perhaps: 512 megabytes.
> > > UBI attach time appears to be about 6 seconds.
> > 
> > If 6 seconds is as fast as it can be done, annoying but fair enough.
> 
> You should read that thread a bit more carefully.  The scan time is
> highly dependent upon the NAND driver beneath UBI.  For example, a UBI
> scan/attach on a 1GiB device on OLPC was 2 seconds.

Ah, I intended to quote the 2 seconds too but forgot, sorry.  I think
2 seconds per gigabyte is a significant time, too, but not so much.

The followup suggested it was due to the speed of the chip, not so
much the driver.

> > Adding _another_ 6 seconds to the boot time seems a lot to me.
> 
> You mean adding another "X amount of time depending on factors outside
> of UBI's control."

Well, yes, that would be a reason to consider whether doing it is a
good idea :-)

> > I can understand the hesitation, but I think 6 seconds just to find
> > the kernel - especially when doing a 'disk resume' - is quite a lot.
> 
> You should really stop quoting this 6 second number.

Let's call it 2 seconds per gigabyte, then.

> > Note that I haven't tried UBI myself yet.  I'm going on what has been
> > written to the list so far, as quoted above.
> 
> Maybe you should try it :).

I will when good looking figures are being quoted on the list ;-)

-- Jamie



From matthias.fuchs at esd-electronics.com  Sun Apr 20 19:37:32 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Sun, 20 Apr 2008 19:37:32 +0200
Subject: [U-Boot-Users] [PATCH V2] cfi-flash: Add CFG_FLASH_AUTOPROTECT_LIST
Message-ID: <200804201937.32557.matthias.fuchs@esd-electronics.com>

This patch adds a configurable flash auto protection list that can be used
to make U-Boot protect flash regions in flash_init().

The idea has been discussed on the u-boot mailing list starting
on Nov 18th, 2007.

Even this patch brings a new feature it is used as a bugfix for 4xx
platforms where flash_init() does not completely protect the
monitor's flash range in all situations.

U-Boot protects the flash range from CFG_MONITOR_BASE to
(CFG_MONITOR_BASE + monitor_flash_len  - 1) by default. This does not
include the reset vector at 0xfffffffc.

Example:
#define CFG_FLASH_AUTOPROTECT_LIST {{0xfff80000, 0x80000}}

This config option will auto protect the last 512k of flash that
contains the bootloader on board like APC405 and PMC405.

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 drivers/mtd/cfi_flash.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index e3cfb8a..fad9e8b 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -169,6 +169,17 @@ flash_info_t flash_info[CFG_MAX_FLASH_BANKS];		/* FLASH chips info */
 #define CFG_FLASH_CFI_WIDTH	FLASH_CFI_8BIT
 #endif
 
+struct apl_s {
+	ulong start;
+	ulong size;
+};
+
+#if !defined(CFG_FLASH_AUTOPROTECT_LIST)
+struct apl_s apl[] = {};
+#else
+struct apl_s apl[] = CFG_FLASH_AUTOPROTECT_LIST;
+#endif
+
 typedef unsigned long flash_sect_t;
 
 /* CFI standard query structure */
@@ -1966,6 +1977,16 @@ unsigned long flash_init (void)
 		       CFG_ENV_ADDR_REDUND + CFG_ENV_SIZE_REDUND - 1,
 		       flash_get_info(CFG_ENV_ADDR_REDUND));
 #endif
+
+	for (i = 0; i < ARRAY_SIZE(apl); i++) {
+		debug ("autoprotecting from %08x to %08x\n",
+		       apl[i].start, apl[i].start + apl[i].size - 1);
+		flash_protect (FLAG_PROTECT_SET,
+			       apl[i].start,
+			       apl[i].start + apl[i].size - 1,
+			       flash_get_info (apl[i].start));
+	}
+
 	return (size);
 }
 
-- 
1.5.3




From wd at denx.de  Sun Apr 20 23:52:31 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 20 Apr 2008 23:52:31 +0200
Subject: [U-Boot-Users] [PATCH] cfi-flash: Add CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: Your message of "Sun, 20 Apr 2008 15:22:40 +0200."
	<200804201522.40808.matthias.fuchs@esd-electronics.com>
Message-ID: <20080420215231.9B0F824657@gemini.denx.de>

Dear Matthias,

in message <200804201522.40808.matthias.fuchs at esd-electronics.com> you wrote:
> 
> even though I like the weak stuff, I agree with you. I also like Stefan's
> idea about removing the #ifdef from the code.
> 
> So I will update my patch in this direction.

Thanks.

> The main idea behind my patch is to fix the bootloader autoprotection
> for 4xx. Do you (sr, J., others) think i is also a good idea to add this:
> 
>         /* Monitor protection ON by default */
> #if (CFG_MONITOR_BASE >= CFG_FLASH_BASE)
>         flash_protect (FLAG_PROTECT_SET,
>                        CFG_MONITOR_BASE,
> +#if defined(CONFIG_4xx)
> 			0xffffffff,
> +#else
>                        CFG_MONITOR_BASE + monitor_flash_len  - 1,
> +#endif
>                        flash_get_info(CFG_MONITOR_BASE));
> #endif

No, I don't think this is a good idea.

First, I don't see what is so special about 4xx here. There are other
processors which have the reset vector at  the  end  of  the  address
space as well, so why do it for 4xx and not - for example - for 85xx?

Also, what makes you think it is  reasonable  to  protect  everything
from  CFG_MONITOR_BASE  to  the  end  of  memory? Yes, we usually pot
U-Boot close to the  end  of  the  flash  memory,  but  there  is  no
guarantee that every board configuration works that way. We could put
U-Boot  at  the  beginning  of  the  flash instead and just reserve a
single sector at the end of the flash for the reset vector. OK,  that
would need adaption of the linker script as well, but ...

I don't think this hardwired, absolute constant makes sense to me. If
0xffffffff is really the value to use, then it should be identical to
the "CFG_MONITOR_BASE + monitor_flash_len - 1" expression,  and  then
we should have no need for the #ifdef at all.

> To be honest, I hope to get my autoprotection patch into 1.3.3 (as a bug fix).

I see.


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: wd at denx.de
Microsoft Compatibility:
     your old Windows 3.11 application crash exactly as the new ones.



From wd at denx.de  Mon Apr 21 00:22:37 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 00:22:37 +0200
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: Your message of "Sat, 19 Apr 2008 01:49:47 +0800."
	<4808DF3B.2080702@largestprime.net>
Message-ID: <20080420222237.4AE5324657@gemini.denx.de>

In message <4808DF3B.2080702 at largestprime.net> you wrote:
> 
> Wolfgang showed some interest briefly too.[1]

I am definitely interested.

>  > The UBI (version 1 :-) initial scan is not
> > fast for large flash, and if the bootloader does it too, that's twice
> > as much time to boot.

We have the same (at at least similar) problems when using JFFS2 file
systems in U-Boot. Yet, being able to do this is quite useful in many
situations.

> > However, if there was a protocol for bootloader to pass the scan
> > results to the booted kernel, that would be very nice.

That would be of course a good thing to have :-)

> If there's no compelling reasons not to, I'll try and find some time to 
> work on ubi in uboot. I'm not expecting it to be easy though :)

Thanks in advance, and good luck!

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: wd at denx.de
All these theories, diverse as they are, have two things  in  common:
they explain the observed facts, and they are completeley and utterly
wrong.                       - Terry Pratchett, _The Light Fantastic_



From wd at denx.de  Mon Apr 21 00:34:07 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 00:34:07 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: Your message of "Fri, 18 Apr 2008 16:51:39 +0200."
	<1208530299-9817-1-git-send-email-sr@denx.de>
Message-ID: <20080420223407.63490248CB@gemini.denx.de>

In message <1208530299-9817-1-git-send-email-sr at denx.de> you wrote:
> dcache_enable() was missing for 440 and the patch
> 017e9b7925f74878d0e9475388cca9bda5ef9482 ["allow ports to override bootelf
> "] behavior uses this function.
> 
> Note: Currently the cache handling functions like
> d/icache_disable/enable() are NOP's on 440. This may be changed in the
> future.

Sorry, but I don't think this is a good idea. Actually I tend to
reject this patch.

> --- a/cpu/ppc4xx/cache.S
> +++ b/cpu/ppc4xx/cache.S
> @@ -166,9 +166,11 @@ _GLOBAL(invalidate_dcache)
>  #ifdef CONFIG_440
>  
>         .globl  dcache_disable
> +       .globl  dcache_enable
>         .globl  icache_disable
>         .globl  icache_enable
>  dcache_disable:
> +dcache_enable:
>  icache_disable:
>  icache_enable:
>  	blr

I was not are that we have such code in U-Boot; I think it  is  plain
unacceptable.  Either  we  implement these functions correctly, i. e.
such that they perform the actions their name suggests, or we do  not
define these functions at all.

But providing a function that promises to enable  or  disable  the  I
resp.  D  cache, and which then actually does nothing, is *extremely*
misleading. I see all kind of regressions and lost  time  because  of
people debug completely different parts of the code just because they
don't know that these functions are dummies.


Please: let's not do this. May I please ask to clean this up?

Yes,  I  am  aware  that  the   current   (new)   implementation   of
do_bootelf_exec()  needs  to  be fixed for this, too - and maybe some
other places as well. But this is important enough to me.

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: wd at denx.de
Q:  What's a light-year?
A:  One-third less calories than a regular year.



From wd at denx.de  Mon Apr 21 01:15:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:15:54 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix PPC440 build breakage due to
	missing dcache_enable symbol
In-Reply-To: Your message of "Fri, 18 Apr 2008 11:56:17 +0200."
	<20080418095616.18864.23500.stgit@pollux.denx.de>
Message-ID: <20080420231554.833C1248A6@gemini.denx.de>

In message <20080418095616.18864.23500.stgit at pollux.denx.de> you wrote:
> Recent commit a4986459 adds reference to dcache_enable, thus breaking the
> build on PPC440. This patch adds a stub for dcache_enable, similarly to
> what's being done for other cache operations.
> 
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> 
>  cpu/ppc4xx/cache.S |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/cpu/ppc4xx/cache.S b/cpu/ppc4xx/cache.S
> index 5124dec..ceb3ec0 100644
> --- a/cpu/ppc4xx/cache.S
> +++ b/cpu/ppc4xx/cache.S
> @@ -166,9 +166,11 @@ _GLOBAL(invalidate_dcache)
>  #ifdef CONFIG_440
>  
>         .globl  dcache_disable
> +       .globl  dcache_enable
>         .globl  icache_disable
>         .globl  icache_enable
>  dcache_disable:
> +dcache_enable:
>  icache_disable:
>  icache_enable:
>  	blr

Thanks, but as mentiuoned before (in my message to Stafan as the  4xx
custodian), the whole idea of having such "stubs" (I'd rather call it
"bad and evil fakes") seems not acceptable to me.

I want to see this cleaned up.

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: wd at denx.de
Question: How does one get fresh air into a Russian church?
Answer:   One clicks on an icon, and a window opens!



From wd at denx.de  Mon Apr 21 01:19:07 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:19:07 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Canyonlands default
	environment to work with new image support
In-Reply-To: Your message of "Fri, 18 Apr 2008 15:32:24 +0200."
	<200804181532.24641.sr@denx.de>
Message-ID: <20080420231907.44027248A6@gemini.denx.de>

In message <200804181532.24641.sr at denx.de> you wrote:
>
> > Does "nand write" support the "+${filesize}" notation (yet)?
> 
> I don't think so.
> 
> > If not, how about adding it?
> 
> Yes, would be great. Patches welcome. :)

How about you adding it?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
That's the thing about people who think  they  hate  computers.  What
they really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"



From wd at denx.de  Mon Apr 21 01:23:27 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:23:27 +0200
Subject: [U-Boot-Users] [PATCH] fw_printenv: Add -v and -q options.
In-Reply-To: Your message of "Fri, 18 Apr 2008 15:57:01 +0200."
	<1208527021-16460-1-git-send-email-Joakim.Tjernlund@transmode.se>
Message-ID: <20080420232327.DF45E248A6@gemini.denx.de>

In message <1208527021-16460-1-git-send-email-Joakim.Tjernlund at transmode.se> you wrote:
> Add -v for verbose output, "Unlocking flash...", "Done" etc.
> Add -q for quiet operation, do not print error and verbose
> messages.

This seems kind of redundandant to me.

And not printing error messages seems an error to me.

> Add a --help(-help, -?) option too.
> 
> The -q option is intended for scripting.

Feel free to add "2>/dev/null" to your scripts when you think this is
really what you want to have.

> +int check_option(int *argc, char *argv[], const char *option)
> +{
> +	int i,j;
> +
> +	for (i = 1; i < *argc; i++)
> +		if (strcmp (argv[i], option) == 0) {
> +			for (j=i; j < *argc; j++)
> +				argv[j] = argv[j+1]; /* remove option */
> +			*argc -= 1;
> +			return 1;
> +		}
> +	return 0;
> +}
> +
> +void check_quiet(int *argc, char *argv[])
> +{
> +	if (check_option(argc, argv, "-q"))
> +		fw_quiet = 1;
> +}
> +
> +void check_verbose(int *argc, char *argv[])
> +{
> +	if (check_option(argc, argv, "-v"))
> +		fw_verbose = 1;
> +}

I've seen many diffeent versions of argument checking code.  This  is
not  a  nice one. See for example "tools/mkimage.c" for the "classic"
approach.

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: wd at denx.de
Perl already has an IDE.  It's called Unix.
                      -- Tom Christiansen in 375bd509 at cs.colorado.edu



From wd at denx.de  Mon Apr 21 01:28:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:28:00 +0200
Subject: [U-Boot-Users] [PATCH] 85xx: Round up frequency calculations to
	get reasonable output
In-Reply-To: Your message of "Fri, 18 Apr 2008 11:57:15 CDT."
	<Pine.LNX.4.64.0804181156410.4255@blarg.am.freescale.net>
Message-ID: <20080420232800.D878A248A6@gemini.denx.de>

In message <Pine.LNX.4.64.0804181156410.4255 at blarg.am.freescale.net> you wrote:
> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
> 
> Signed-off-by: Dejan Minic <minic at freescale.com>
> Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
>  cpu/mpc85xx/cpu.c |   18 +++++++++++-------
>  1 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
> index dcd8817..6972bb1 100644
> --- a/cpu/mpc85xx/cpu.c
> +++ b/cpu/mpc85xx/cpu.c
> @@ -65,6 +65,11 @@ struct cpu_type cpu_type_list [] = {
>  	CPU_TYPE_ENTRY(8572_E),
>  };
> 
> +static inline unsigned long integer_round (unsigned long val, unsigned long div)
> +{
> +	return ((val + (div/2)) / div);
> +}
> +

As already mentioned, "integer_round" is not a good  name  for  this.
Also,  it  seems  this  should not live in cpu/mpc85xx/cpu.c but in a
more central place and be  used  by  lots  of  other  code  as  well.
Actually  you  might  want  to make it a macro to allow for different
data types as well.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When properly administered, vacations do not  diminish  productivity:
for every week you're away and get nothing done, there's another when
your boss is away and you get twice as much done.  -- Daniel B. Luten



From wd at denx.de  Mon Apr 21 01:32:20 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:32:20 +0200
Subject: [U-Boot-Users] What methods of software authentication does
	U-Boot support?
In-Reply-To: Your message of "Fri, 18 Apr 2008 16:32:11 CDT."
	<20080418163211.d5a1ee64.kim.phillips@freescale.com>
Message-ID: <20080420233220.DE0A4248A6@gemini.denx.de>

In message <20080418163211.d5a1ee64.kim.phillips at freescale.com> you wrote:
>
> > U-Boot will run only software that has been
> > authenticated to be from the system's producer.  

Seems it's time to start a discussion to switch to GPL v3...


> > Any comments or suggestions?
> > 
> this patch taps into openssl:

Be careful. Linking against openssl is not possible because the
openssl licence is not compatible with GPL; see for example
http://www.gnome.org/~markmc/openssl-and-the-gpl.html

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: wd at denx.de
Your own mileage may vary.



From wd at denx.de  Mon Apr 21 01:33:05 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:33:05 +0200
Subject: [U-Boot-Users] [PATCH v2] 85xx: Round up frequency calculations
	to get reasonable output
In-Reply-To: Your message of "Fri, 18 Apr 2008 17:46:56 CDT."
	<2acbd3e40804181546o3ee9432bre6ba521e7076b96@mail.gmail.com>
Message-ID: <20080420233305.C65D0248A6@gemini.denx.de>

In message <2acbd3e40804181546o3ee9432bre6ba521e7076b96 at mail.gmail.com> you wrote:
> On Fri, Apr 18, 2008 at 4:28 PM, Kumar Gala <galak at kernel.crashing.org> wrote:
> > eg. because of rounding error we can get 799Mhz instead of 800Mhz.
> >
> >  Signed-off-by: Dejan Minic <minic at freescale.com>
> >  Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
> >  Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> 
> Applied, thanks

Please undo. I NAK this, at least in the current form.

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: wd at denx.de
Niklaus Wirth has lamented that, whereas Europeans pronounce his name
correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-
les Worth). Which is to say that Europeans  call  him  by  name,  but
Americans call him by value.



From wd at denx.de  Mon Apr 21 01:33:41 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:33:41 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
In-Reply-To: Your message of "Fri, 18 Apr 2008 17:49:16 CDT."
	<1208558956-6531-1-git-send-email-afleming@freescale.com>
Message-ID: <20080420233341.612B3248A6@gemini.denx.de>

In message <1208558956-6531-1-git-send-email-afleming at freescale.com> you wrote:
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc85xx.git master
> 
> Kumar Gala (2):
>       85xx: Fix size of cpu-release-addr property
>       85xx: Round up frequency calculations to get reasonable output
> 
> Timur Tabi (1):
>       Fix calculation of I2C clock for some 85xx chips

Sory, can't pull because of the "Round up" patch that was NAKed.

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: wd at denx.de
The use of Microsoft crippleware systems is a sin that  carries  with
it its own punishment.
         -- Tom Christiansen in <6bo3fr$pj8$5 at csnews.cs.colorado.edu>



From wd at denx.de  Mon Apr 21 01:38:02 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:38:02 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Sat, 19 Apr 2008 01:45:50 EDT."
	<1208583950-9454-1-git-send-email-vapier@gentoo.org>
Message-ID: <20080420233803.053F9248A6@gemini.denx.de>

In message <1208583950-9454-1-git-send-email-vapier at gentoo.org> you wrote:
> Override the default go/boote handlers as we want to disable both data and
> instruction cache before executing external programs (since Blackfin cache
> handling requires a software handler in U-Boot which may be overwritten).

Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
not overwrite (or otherwise meddle with) any U-Boot code.

I think you should not change cache status for "go".

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: wd at denx.de
... The things love can drive a man to -- the  ecstasies,  the  mise-
ries,  the broken rules, the desperate chances, the glorious failures
and the glorious victories.
	-- McCoy, "Requiem for Methuselah", stardate 5843.7



From wd at denx.de  Mon Apr 21 01:39:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:39:54 +0200
Subject: [U-Boot-Users] [PATCH] image: remove inline for
	image_print_contents and image_print_contents_noindent
In-Reply-To: Your message of "Sat, 19 Apr 2008 18:46:54 +0200."
	<1208623614-26957-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080420233954.1DC98248A6@gemini.denx.de>

In message <1208623614-26957-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Would you please explain *why* you are doing this?

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: wd at denx.de
The so-called "desktop metaphor" of today's workstations  is  instead
an  "airplane-seat"  metaphor.  Anyone who has shuffled a lap full of
papers while seated between two portly passengers will recognize  the
difference -- one can see only a very few things at once.
                                                   - Fred Brooks, Jr.



From wd at denx.de  Mon Apr 21 01:44:27 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:44:27 +0200
Subject: [U-Boot-Users] [PATCH] cfi-flash:?Add?CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: Your message of "Sun, 20 Apr 2008 05:54:35 +0200."
	<20080420035435.GB27176@game.jcrosoft.org>
Message-ID: <20080420234427.22149248A6@gemini.denx.de>

In message <20080420035435.GB27176 at game.jcrosoft.org> you wrote:
>
> As sugest Wolfgang we could do it like this

I did not suggest to use weak at all here!

> struct apl_s apl* inline init_flash_autoprotect()
> {
> 	struct apl_s a[] = {
> 	{1, 3},
> 	{4, 5},
> 	};
> 
> 	return a;
> }

Are you sure this works?

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: wd at denx.de
Remember that Beethoven wrote his first symphony in C ...



From wd at denx.de  Mon Apr 21 01:45:39 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 01:45:39 +0200
Subject: [U-Boot-Users] [PATCH V2] cfi-flash: Add
	CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: Your message of "Sun, 20 Apr 2008 19:37:32 +0200."
	<200804201937.32557.matthias.fuchs@esd-electronics.com>
Message-ID: <20080420234539.708B6248A6@gemini.denx.de>

In message <200804201937.32557.matthias.fuchs at esd-electronics.com> you wrote:
> This patch adds a configurable flash auto protection list that can be used
> to make U-Boot protect flash regions in flash_init().
> 
> The idea has been discussed on the u-boot mailing list starting
> on Nov 18th, 2007.
> 
> Even this patch brings a new feature it is used as a bugfix for 4xx
> platforms where flash_init() does not completely protect the
> monitor's flash range in all situations.
> 
> U-Boot protects the flash range from CFG_MONITOR_BASE to
> (CFG_MONITOR_BASE + monitor_flash_len  - 1) by default. This does not
> include the reset vector at 0xfffffffc.
> 
> Example:
> #define CFG_FLASH_AUTOPROTECT_LIST {{0xfff80000, 0x80000}}
> 
> This config option will auto protect the last 512k of flash that
> contains the bootloader on board like APC405 and PMC405.
> 
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
> ---
>  drivers/mtd/cfi_flash.c |   21 +++++++++++++++++++++
>  1 files changed, 21 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> index e3cfb8a..fad9e8b 100644
> --- a/drivers/mtd/cfi_flash.c
> +++ b/drivers/mtd/cfi_flash.c
> @@ -169,6 +169,17 @@ flash_info_t flash_info[CFG_MAX_FLASH_BANKS];		/* FLASH chips info */
>  #define CFG_FLASH_CFI_WIDTH	FLASH_CFI_8BIT
>  #endif
>  
> +struct apl_s {
> +	ulong start;
> +	ulong size;
> +};
> +
> +#if !defined(CFG_FLASH_AUTOPROTECT_LIST)
> +struct apl_s apl[] = {};
> +#else
> +struct apl_s apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> +#endif

No. Please don't add any code nor data when CFG_FLASH_AUTOPROTECT_LIST
is undefined.

>  typedef unsigned long flash_sect_t;
>  
>  /* CFI standard query structure */
> @@ -1966,6 +1977,16 @@ unsigned long flash_init (void)
>  		       CFG_ENV_ADDR_REDUND + CFG_ENV_SIZE_REDUND - 1,
>  		       flash_get_info(CFG_ENV_ADDR_REDUND));
>  #endif
> +
> +	for (i = 0; i < ARRAY_SIZE(apl); i++) {
> +		debug ("autoprotecting from %08x to %08x\n",
> +		       apl[i].start, apl[i].start + apl[i].size - 1);
> +		flash_protect (FLAG_PROTECT_SET,
> +			       apl[i].start,
> +			       apl[i].start + apl[i].size - 1,
> +			       flash_get_info (apl[i].start));
> +	}
> +

No. Please don't add any code nor data when CFG_FLASH_AUTOPROTECT_LIST
is undefined.

NAK.

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: wd at denx.de
Lady Nancy Astor:
    "Winston, if you were my husband, I'd put poison in your coffee."
Winston Churchill:
    "Nancy, if you were my wife, I'd drink it."



From vapier at gentoo.org  Mon Apr 21 02:31:31 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Sun, 20 Apr 2008 20:31:31 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <20080420233803.053F9248A6@gemini.denx.de>
References: <20080420233803.053F9248A6@gemini.denx.de>
Message-ID: <200804202031.31936.vapier@gentoo.org>

On Sunday 20 April 2008, Wolfgang Denk wrote:
> In message <1208583950-9454-1-git-send-email-vapier at gentoo.org> you wrote:
> > Override the default go/boote handlers as we want to disable both data
> > and instruction cache before executing external programs (since Blackfin
> > cache handling requires a software handler in U-Boot which may be
> > overwritten).
>
> Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
> not overwrite (or otherwise meddle with) any U-Boot code.
>
> I think you should not change cache status for "go".

reality is that people often times use go to execute their binary blobs.  i 
also see it this way: go means to jump to some address and most likely never 
return.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080420/eccf9a97/attachment.pgp 

From hamish at cloud.net.au  Mon Apr 21 03:05:21 2008
From: hamish at cloud.net.au (Hamish Moffatt)
Date: Mon, 21 Apr 2008 11:05:21 +1000
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <20080420160413.GC14268@shareable.org>
References: <4808AE6F.4030505@largestprime.net>
	<1208536808.6654.6.camel@vader.jdub.homelinux.org>
	<20080418165957.GG31520@shareable.org>
	<1208546341.6654.8.camel@vader.jdub.homelinux.org>
	<20080420160413.GC14268@shareable.org>
Message-ID: <20080421010521.GA6317@cloud.net.au>

On Sun, Apr 20, 2008 at 05:04:14PM +0100, Jamie Lokier wrote:
> I was thinking this:
> 
> Hamish Moffatt wrote (Message-ID: <20080407073227.GA6317 at cloud.net.au>):
> > Sorry I should've said 512MiB perhaps: 512 megabytes.
> > UBI attach time appears to be about 6 seconds.
> 
> If 6 seconds is as fast as it can be done, annoying but fair enough.
> 
> Adding _another_ 6 seconds to the boot time seems a lot to me.

Yes. I have a prototype system here booting a minimal system from NOR
flash then booting the full system from NAND via kexec. I'm suffering
my 6 seconds of UBI attach time twice each boot.

Six seconds does seem to be abnormal though - I don't have a hardware
NAND controller so it's all software ECC, GPIO for chip selects etc. The
performance is said to be much better with a hardware controller.

> To remove the double scan:
> 
> > > However, if there was a protocol for bootloader to pass the scan
> > > results to the booted kernel, that would be very nice.

That would certainly help my case. Fortunately my device is usually
always-on and therefore boot time is not critical, and we don't
suspend/resume.


Hamish
-- 
Hamish Moffatt VK3SB <hamish at debian.org> <hamish at cloud.net.au>



From sr at denx.de  Mon Apr 21 06:33:24 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 06:33:24 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Canyonlands default
	environment to work with new image support
In-Reply-To: <20080420231907.44027248A6@gemini.denx.de>
References: <20080420231907.44027248A6@gemini.denx.de>
Message-ID: <200804210633.24894.sr@denx.de>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804181532.24641.sr at denx.de> you wrote:
> > > Does "nand write" support the "+${filesize}" notation (yet)?
> >
> > I don't think so.
> >
> > > If not, how about adding it?
> >
> > Yes, would be great. Patches welcome. :)
>
> How about you adding it?

Are you asking me personally? Sorry, I have no time currently doing such a 
thing.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From aneesh_g at cms.com  Mon Apr 21 06:29:49 2008
From: aneesh_g at cms.com (Aneesh)
Date: Mon, 21 Apr 2008 09:59:49 +0530
Subject: [U-Boot-Users] USB SUPPORT
Message-ID: <1208752189.2935.10.camel@Aneesh>

Hi,
    I am using an at91rm9200dk custom board.I want  to boot kernel and
ram disk from the usb stick.for that i tried to enable the usb support
in the uboot.but now i am getting a message like no storage devices
found .
i gave the configurations in include/configs/at91rm9200dk.h
like follows

#define CONFIG_DOS_PARTITION 1
#define CONFIG_USB_OHCI      1
#define CONFIG_USB_STORAGE  1

#define CONFIG_COMMANDS		\
		       ((CONFIG_CMD_DFL | CFG_CMD_MII | CFG_CMD_NET | CFG_CMD_USB | \
			CFG_CMD_DHCP ) & \
		      ~(CFG_CMD_BDI | \
			CFG_CMD_IMI | \
			CFG_CMD_AUTOSCRIPT | \
			CFG_CMD_FPGA | \
			CFG_CMD_MISC | \
			CFG_CMD_LOADS))

Is this configuration is right?
i am not able to acess the USB stick using Storage USB Commands. My
U-boot version is 1.1.5. 
 Any one can help?
regards 
Aneesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080421/460828b4/attachment.htm 

From sr at denx.de  Mon Apr 21 06:58:06 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 06:58:06 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: <20080420223407.63490248CB@gemini.denx.de>
References: <20080420223407.63490248CB@gemini.denx.de>
Message-ID: <200804210658.07170.sr@denx.de>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <1208530299-9817-1-git-send-email-sr at denx.de> you wrote:
> > dcache_enable() was missing for 440 and the patch
> > 017e9b7925f74878d0e9475388cca9bda5ef9482 ["allow ports to override
> > bootelf "] behavior uses this function.
> >
> > Note: Currently the cache handling functions like
> > d/icache_disable/enable() are NOP's on 440. This may be changed in the
> > future.
>
> Sorry, but I don't think this is a good idea. Actually I tend to
> reject this patch.
>
> > --- a/cpu/ppc4xx/cache.S
> > +++ b/cpu/ppc4xx/cache.S
> > @@ -166,9 +166,11 @@ _GLOBAL(invalidate_dcache)
> >  #ifdef CONFIG_440
> >
> >         .globl  dcache_disable
> > +       .globl  dcache_enable
> >         .globl  icache_disable
> >         .globl  icache_enable
> >  dcache_disable:
> > +dcache_enable:
> >  icache_disable:
> >  icache_enable:
> >  	blr
>
> I was not are that we have such code in U-Boot; I think it  is  plain
> unacceptable.  Either  we  implement these functions correctly, i. e.
> such that they perform the actions their name suggests, or we do  not
> define these functions at all.

So what do you suggest instead? Removing these functions completely for 440? 
This would result in bigger changes to common code currently using those 
functions (especially dcache_disable). Probably by using more #ifdefs there 
which I would really like not to see.

> But providing a function that promises to enable  or  disable  the  I
> resp.  D  cache, and which then actually does nothing, is *extremely*
> misleading. I see all kind of regressions and lost  time  because  of
> people debug completely different parts of the code just because they
> don't know that these functions are dummies.
>
> Please: let's not do this. May I please ask to clean this up?

OK, I removed this patch from my custodian repository. But I assume that you 
are you asking for additional changes too. Are you asking me to remove (a) 
all dummy cache entries or (b) to support *real* cache support functions for 
440? (a) would lead as explained above to bigger code changes in the common 
code and (b) is extremely difficult and I just have no time for such a thing 
currently.

BTW: All the already existing 440 dummy cache entries were not introduced by 
myself.

> Yes,  I  am  aware  that  the   current   (new)   implementation   of
> do_bootelf_exec()  needs  to  be fixed for this, too - and maybe some
> other places as well. But this is important enough to me.

Understood. We should propably revert this patch then.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Mon Apr 21 07:00:25 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 07:00:25 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Sun, 20 Apr 2008 20:31:31 EDT."
	<200804202031.31936.vapier@gentoo.org>
Message-ID: <20080421050025.55BE224764@gemini.denx.de>

In message <200804202031.31936.vapier at gentoo.org> you wrote:
> 
> > Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
> > not overwrite (or otherwise meddle with) any U-Boot code.
> >
> > I think you should not change cache status for "go".
> 
> reality is that people often times use go to execute their binary blobs.  i
> also see it this way: go means to jump to some address and most likely never 
> return.

This may be your private interpretation, but it is wrong.

Intended and documented behaviour is that "go" is used to start
standalone applications, which are supposed to return.

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: wd at denx.de
They're usually so busy thinking about what  happens  next  that  the
only  time they ever find out what is happening now is when they come
to look back on it.                 - Terry Pratchett, _Wyrd Sisters_



From wd at denx.de  Mon Apr 21 07:04:43 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 07:04:43 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: Your message of "Mon, 21 Apr 2008 06:58:06 +0200."
	<200804210658.07170.sr@denx.de>
Message-ID: <20080421050443.66E1424764@gemini.denx.de>

In message <200804210658.07170.sr at denx.de> you wrote:
>
> So what do you suggest instead? Removing these functions completely for 440? 

Please let's either proviude real, working implementations, or remove
the functions.

> This would result in bigger changes to common code currently using those 
> functions (especially dcache_disable). Probably by using more #ifdefs there 
> which I would really like not to see.

I don't like to see these either, but it's better than lying in the
face of the user.

> OK, I removed this patch from my custodian repository. But I assume that you 
> are you asking for additional changes too. Are you asking me to remove (a) 
> all dummy cache entries or (b) to support *real* cache support functions for 
> 440? (a) would lead as explained above to bigger code changes in the common 
> code and (b) is extremely difficult and I just have no time for such a thing 
> currently.

Yes, let's do either (a) or (b). There is no other choice.

> BTW: All the already existing 440 dummy cache entries were not introduced by 
> myself.

I am aware of this.

> > Yes,  I  am  aware  that  the   current   (new)   implementation   of
> > do_bootelf_exec()  needs  to  be fixed for this, too - and maybe some
> > other places as well. But this is important enough to me.
> 
> Understood. We should propably revert this patch then.

This still leaves the problem of the current "implementation" of  the
other  stubs. Please note that as is, we even have *random* behaviour
of the code, as the  functions  are  supposed  to  return  the  cache
status, but no return value gets loaded.

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: wd at denx.de
You're dead, Jim.
	-- McCoy, "The Tholian Web", stardate unknown



From vapier at gentoo.org  Mon Apr 21 07:25:42 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 21 Apr 2008 01:25:42 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <20080421050025.55BE224764@gemini.denx.de>
References: <20080421050025.55BE224764@gemini.denx.de>
Message-ID: <200804210125.45077.vapier@gentoo.org>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804202031.31936.vapier at gentoo.org> you wrote:
> > > Umnmm... no. "go" is supposed to be return to U-Boot, i. e. it must
> > > not overwrite (or otherwise meddle with) any U-Boot code.
> > >
> > > I think you should not change cache status for "go".
> >
> > reality is that people often times use go to execute their binary blobs. 
> > i also see it this way: go means to jump to some address and most likely
> > never return.
>
> This may be your private interpretation, but it is wrong.
>
> Intended and documented behaviour is that "go" is used to start
> standalone applications, which are supposed to return.

then how exactly are people supposed to execute their flat binaries ?  none of 
the other boot methods allow for straight jumps that i'm aware of.  otherwise 
i'm going to have to add even more bloat to add a slight variation on the go 
command: one where the documentation doesnt require it to return.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/ac68d99c/attachment.pgp 

From sr at denx.de  Mon Apr 21 07:29:53 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 07:29:53 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: <20080421050443.66E1424764@gemini.denx.de>
References: <20080421050443.66E1424764@gemini.denx.de>
Message-ID: <200804210729.53635.sr@denx.de>

On Monday 21 April 2008, Wolfgang Denk wrote:
> > This would result in bigger changes to common code currently using those
> > functions (especially dcache_disable). Probably by using more #ifdefs
> > there which I would really like not to see.
>
> I don't like to see these either, but it's better than lying in the
> face of the user.

Please note that it is not so easy on 440 to even define *what exactly* the 
functions/commands d/icache_en/disable mean. This is because 440 has MMU 
support and we can have different cache setups for all TLB entries. So to 
which TLB entries should these functions refer? Just those mapping SDRAM? 
And/or FLASH? And/or internal SRAM? ...

> > OK, I removed this patch from my custodian repository. But I assume that
> > you are you asking for additional changes too. Are you asking me to
> > remove (a) all dummy cache entries or (b) to support *real* cache support
> > functions for 440? (a) would lead as explained above to bigger code
> > changes in the common code and (b) is extremely difficult and I just have
> > no time for such a thing currently.
>
> Yes, let's do either (a) or (b). There is no other choice.

From my point of view, both "solutions" should not be done outside of a 
merge-window. I'll try to find some time to implement on of those options in 
the next weeks. But perhaps somebody else has more "free time" and sends 
patches to implement (and test) this stuff.

> > > Yes,  I  am  aware  that  the   current   (new)   implementation   of
> > > do_bootelf_exec()  needs  to  be fixed for this, too - and maybe some
> > > other places as well. But this is important enough to me.
> >
> > Understood. We should propably revert this patch then.
>
> This still leaves the problem of the current "implementation" of  the
> other  stubs. Please note that as is, we even have *random* behaviour
> of the code, as the  functions  are  supposed  to  return  the  cache
> status, but no return value gets loaded.

I don't see such a problem with *random* behavior. d/icache_status return 0 on 
440.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From littlesweetmelon at gmail.com  Mon Apr 21 07:49:53 2008
From: littlesweetmelon at gmail.com (=?GB2312?B?zPC5zw==?=)
Date: Mon, 21 Apr 2008 13:49:53 +0800
Subject: [U-Boot-Users] [uboot] Walnut PPC405GP flash
Message-ID: <cdb837ea0804202249w453cbb87td879ff09ec138bd4@mail.gmail.com>

Howdy,
    I'm a beginner of embedded system. I'm working on a board of Walnut
PPC405GP which use PPCBOOT 1.1.2.
One day I tried to write some data into unused area of the flash:

>> fli
Bank # 1: AMD AM29F040 (512 Kbit, uniform sector size)
  Size: 512 KB in 8 Sectors
  Sector Start Addresses:
    FFF80000  RO  FFF90000  RO  FFFA0000  RO  FFFB0000      FFFC0000
    FFFD0000      FFFE0000      FFFF0000

I use the last sector:
>> md ffff0000
ffff0000: 00000000 00000000 00000000 00000000    ................
ffff0010: 00000000 00000000 00000000 00000000    ................
ffff0020: 00000000 00000000 00000000 00000000    ................
ffff0030: 00000000 00000000 00000000 00000000    ................
ffff0040: 00000000 00000000 00000000 00000000    ................
ffff0050: 00000000 00000000 00000000 00000000    ................
ffff0060: 00000000 00000000 00000000 00000000    ................
ffff0070: 00000000 00000000 00000000 00000000    ................
ffff0080: 00000000 00000000 00000000 00000000    ................
ffff0090: 00000000 00000000 00000000 00000000    ................
ffff00a0: 00000000 00000000 00000000 00000000    ................
ffff00b0: 00000000 00000000 00000000 00000000    ................
ffff00c0: 00000000 00000000 00000000 00000000    ................
ffff00d0: 00000000 00000000 00000000 00000000    ................
ffff00e0: 00000000 00000000 00000000 00000000    ................
ffff00f0: 00000000 00000000 00000000 00000000    ................

>> protected off ffff0000 ffffffff
Un-Protected 1 sectors
>> erase ffff0000 ffffffff
Erase Flash from 0xffff0000 to 0xffffffff
Erasing sector ffff0000
. done
Erased 1 sectors

!! Now I tried to copy a small file data to this area by using tftp.
>> tftp ffff0000 data_file
405GP Eth Status:
   data len error 0
   rx frames 0
   rx 0
   rx_prot_err 0
   int_err 0
   tx_err_log:
      [0] 0
      [1] 0
      [2] 0
      [3] 0
      [4] 0
      [5] 0
      [6] 0
      [7] 0
      [8] 0
      [9] 0
   rx_err_log:
      [0] 0
      [1] 0
      [2] 0
      [3] 0
      [4] 0
      [5] 0
      [6] 0
      [7] 0
      [8] 0
      [9] 0

ENET Speed is 100 Mbps - FULL duplex connection
*** ERROR: `ipaddr' not set
Well, set the target addr first, then:

>> dhcp
405GP Eth Status:
   data len error 0
   rx frames 0
   rx 0
   rx_prot_err 0
   int_err 0
   tx_err_log:
      [0] 0
      [1] 0
      [2] 0
      [3] 0
      [4] 0
      [5] 0
      [6] 0
      [7] 0
      [8] 0
      [9] 0
   rx_err_log:
      [0] 0
      [1] 0
      [2] 0
      [3] 0
      [4] 0
      [5] 0
      [6] 0
      [7] 0
      [8] 0
      [9] 0

ENET Speed is 100 Mbps - FULL duplex connection
BOOTP broadcast 1
DHCPHandler: got packet: (src=67, dst=68, len=548) state: 3
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=548) state: 3
DHCP: state=SELECTING bp_file: "uImage"
TRANSITIONING TO REQUESTING STATE
Bootfile: uImage
DhcpSendRequestPkt: Sending DHCPREQUEST
Transmitting DHCPREQUEST packet: len = 308
DHCPHandler: got packet: (src=67, dst=68, len=548) state: 4
Filtering pkt = 0
DHCPHandler: got DHCP packet: (src=67, dst=68, len=548) state: 4
DHCP State: REQUESTING
Bootfile: uImage
DHCP client bound to address 192.168.1.201
ARP broadcast 1
Got good ARP - start TFTP
TFTP from server 192.168.1.200; our IP address is 192.168.1.201
Filename 'uImage'.
Load address: 0xffff0000
Loading: *##############NIP: 00000200 XER: 00000000 LR: 67E12A71 REGS:
01faea48 TRAP: 0700 DAR: 00080000
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00

GPR00: 00000001 01FAEB38 40000000 01FAEB48 80000000 00000002 01FB016D
01C80764
GPR08: 01FF5060 01FF5074 FFFFFFFF 01FF54B4 00000000 7C6BFE6C 01FF4400
02050000
GPR16: E45EA284 DC212086 02CACA22 F3844306 00001000 01FAEB38 00000000
67E12A71
GPR24: 76585F5E 00000001 00000000 01FAEF8C 00000004 00000000 01FF44CC
01FF52A4
** Illegal Instruction **
Call backtrace:
Program Check Exception

 ========================
You can see my mistake...>_< A big uImage file is copied to flash, rather
than data_file.
After that, the Walnut board cannot boot anymore... I wonder why. The data
is simply copied to
the unused sector, while other sectors are under protection. It should be
safe even if I made mistakes.

Thank you very much.
---
ShenLei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080421/d359ae8c/attachment.htm 

From MAILER-DAEMON at aol.com  Mon Apr 21 08:05:48 2008
From: MAILER-DAEMON at aol.com (Mail Delivery Subsystem)
Date: Mon, 21 Apr 2008 02:05:48 -0400 (EDT)
Subject: [U-Boot-Users] Returned mail: Service unavailable
Message-ID: <200804210605.CAA03427@rly-mb01.mail.aol.com>

A non-text attachment was scrubbed...
Name: not available
Type: text/rfc822-headers
Size: 709 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/07d4da9e/attachment.bin 

From sr at denx.de  Mon Apr 21 08:24:45 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 08:24:45 +0200
Subject: [U-Boot-Users] [uboot] Walnut PPC405GP flash
In-Reply-To: <cdb837ea0804202249w453cbb87td879ff09ec138bd4@mail.gmail.com>
References: <cdb837ea0804202249w453cbb87td879ff09ec138bd4@mail.gmail.com>
Message-ID: <200804210824.45648.sr@denx.de>

On Monday 21 April 2008, ?? wrote:
>     I'm a beginner of embedded system. I'm working on a board of Walnut
> PPC405GP which use PPCBOOT 1.1.2.

Wow, that's ancient. I suggest to update to the current version.

Please find some comments below.

> One day I tried to write some data into unused area of the flash:
> >> fli
>
> Bank # 1: AMD AM29F040 (512 Kbit, uniform sector size)
>   Size: 512 KB in 8 Sectors
>   Sector Start Addresses:
>     FFF80000  RO  FFF90000  RO  FFFA0000  RO  FFFB0000      FFFC0000
>     FFFD0000      FFFE0000      FFFF0000
>
> I use the last sector:
> >> md ffff0000
>
> ffff0000: 00000000 00000000 00000000 00000000    ................
> ffff0010: 00000000 00000000 00000000 00000000    ................
> ffff0020: 00000000 00000000 00000000 00000000    ................
> ffff0030: 00000000 00000000 00000000 00000000    ................
> ffff0040: 00000000 00000000 00000000 00000000    ................
> ffff0050: 00000000 00000000 00000000 00000000    ................
> ffff0060: 00000000 00000000 00000000 00000000    ................
> ffff0070: 00000000 00000000 00000000 00000000    ................
> ffff0080: 00000000 00000000 00000000 00000000    ................
> ffff0090: 00000000 00000000 00000000 00000000    ................
> ffff00a0: 00000000 00000000 00000000 00000000    ................
> ffff00b0: 00000000 00000000 00000000 00000000    ................
> ffff00c0: 00000000 00000000 00000000 00000000    ................
> ffff00d0: 00000000 00000000 00000000 00000000    ................
> ffff00e0: 00000000 00000000 00000000 00000000    ................
> ffff00f0: 00000000 00000000 00000000 00000000    ................
>
> >> protected off ffff0000 ffffffff
>
> Un-Protected 1 sectors
>
> >> erase ffff0000 ffffffff
>
> Erase Flash from 0xffff0000 to 0xffffffff
> Erasing sector ffff0000
> . done
> Erased 1 sectors

You should not have erased this sector. It's part of the U-Boot (PPCBoot) 
image and erasing it (without reflashing) will lead to a non breaking system.

> !! Now I tried to copy a small file data to this area by using tftp.
>
> >> tftp ffff0000 data_file
>
> 405GP Eth Status:
>    data len error 0
>    rx frames 0
>    rx 0
>    rx_prot_err 0
>    int_err 0
>    tx_err_log:
>       [0] 0
>       [1] 0
>       [2] 0
>       [3] 0
>       [4] 0
>       [5] 0
>       [6] 0
>       [7] 0
>       [8] 0
>       [9] 0
>    rx_err_log:
>       [0] 0
>       [1] 0
>       [2] 0
>       [3] 0
>       [4] 0
>       [5] 0
>       [6] 0
>       [7] 0
>       [8] 0
>       [9] 0

I have never seen such a debug log.

> ENET Speed is 100 Mbps - FULL duplex connection
> *** ERROR: `ipaddr' not set
>
> Well, set the target addr first, then:
> >> dhcp
>
> 405GP Eth Status:
>    data len error 0
>    rx frames 0
>    rx 0
>    rx_prot_err 0
>    int_err 0
>    tx_err_log:
>       [0] 0
>       [1] 0
>       [2] 0
>       [3] 0
>       [4] 0
>       [5] 0
>       [6] 0
>       [7] 0
>       [8] 0
>       [9] 0
>    rx_err_log:
>       [0] 0
>       [1] 0
>       [2] 0
>       [3] 0
>       [4] 0
>       [5] 0
>       [6] 0
>       [7] 0
>       [8] 0
>       [9] 0
>
> ENET Speed is 100 Mbps - FULL duplex connection
> BOOTP broadcast 1
> DHCPHandler: got packet: (src=67, dst=68, len=548) state: 3
> Filtering pkt = 0
> DHCPHandler: got DHCP packet: (src=67, dst=68, len=548) state: 3
> DHCP: state=SELECTING bp_file: "uImage"
> TRANSITIONING TO REQUESTING STATE
> Bootfile: uImage
> DhcpSendRequestPkt: Sending DHCPREQUEST
> Transmitting DHCPREQUEST packet: len = 308
> DHCPHandler: got packet: (src=67, dst=68, len=548) state: 4
> Filtering pkt = 0
> DHCPHandler: got DHCP packet: (src=67, dst=68, len=548) state: 4
> DHCP State: REQUESTING
> Bootfile: uImage
> DHCP client bound to address 192.168.1.201
> ARP broadcast 1
> Got good ARP - start TFTP
> TFTP from server 192.168.1.200; our IP address is 192.168.1.201
> Filename 'uImage'.
> Load address: 0xffff0000
> Loading: *##############NIP: 00000200 XER: 00000000 LR: 67E12A71 REGS:
> 01faea48 TRAP: 0700 DAR: 00080000
> MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
>
> GPR00: 00000001 01FAEB38 40000000 01FAEB48 80000000 00000002 01FB016D
> 01C80764
> GPR08: 01FF5060 01FF5074 FFFFFFFF 01FF54B4 00000000 7C6BFE6C 01FF4400
> 02050000
> GPR16: E45EA284 DC212086 02CACA22 F3844306 00001000 01FAEB38 00000000
> 67E12A71
> GPR24: 76585F5E 00000001 00000000 01FAEF8C 00000004 00000000 01FF44CC
> 01FF52A4
> ** Illegal Instruction **
> Call backtrace:
> Program Check Exception
>
>  ========================
> You can see my mistake...>_< A big uImage file is copied to flash, rather
> than data_file.
> After that, the Walnut board cannot boot anymore... I wonder why. The data
> is simply copied to
> the unused sector, while other sectors are under protection. It should be
> safe even if I made mistakes.

No, it's not unused. The 4xx reset vector is at 0xfffffffc, so it definitely 
is needed. I'm afraid your FLASH image is corrupted now. The only way out is 
reflashing using a JTAG debugger like the BDI2000.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From littlesweetmelon at gmail.com  Mon Apr 21 08:42:51 2008
From: littlesweetmelon at gmail.com (=?GB2312?B?zPC5zw==?=)
Date: Mon, 21 Apr 2008 14:42:51 +0800
Subject: [U-Boot-Users] [uboot] Walnut PPC405GP flash
In-Reply-To: <200804210824.45648.sr@denx.de>
References: <cdb837ea0804202249w453cbb87td879ff09ec138bd4@mail.gmail.com>
	<200804210824.45648.sr@denx.de>
Message-ID: <cdb837ea0804202342i4285ee8em4794993560b06182@mail.gmail.com>

Yep! The ppcboot is very ancient. hehe.
Actually, my board is DHT-walnut: http://elinux.org/DHT-Walnut_U_Boot
The web provides a pre-compiled bin uboot 1.1.4  for my board. The size is
256KB.
I downloaded it, and burn this bin into flash. But the board is still not
work.
Well, you point out a very important thing that 4xx use 0xfffffffc as the
reset vector.
My flash is 512KB larger, therefore the bin only fills the first 256KB of
the flash.
The reset vector is not set correct. Am I correct? It seem that it depends
on how CPU
maps flash contents into address space. And how to set it? I don't know
how to determine the real entry of a specific uboot-bin.  :<

Thank you for your help.
---
ShenLei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080421/c5450851/attachment.htm 

From sr at denx.de  Mon Apr 21 08:46:41 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 08:46:41 +0200
Subject: [U-Boot-Users] PATCH - Fix oob data copied into supplied buffer
In-Reply-To: <46F84B37.5050305@boundarydevices.com>
References: <20070922230326.188F224811@gemini.denx.de>
	<46F84B37.5050305@boundarydevices.com>
Message-ID: <200804210846.41664.sr@denx.de>

On Tuesday 25 September 2007, Troy Kisky wrote:
> First segment fixes a typo
> Second segment fixes a bug where oob data may be copied incorrectly.
> Third segment adds an error message when exiting due to write protect.
> Forth segment fixes a bug where oobavail may be set incorrectly.
>
> All segments are independent and may be accepted or rejected as deemed
> appropriate. Do they need to be separate patches?
> Signed-off-by: Troy Kisky <troy.kisky at boundarydevices.com>

Sorry, I missed this for a long time and Wolfgang just reminded me of it.

Added to u-boot-nand-flash repo. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Mon Apr 21 09:02:37 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 09:02:37 +0200
Subject: [U-Boot-Users] [PATCH] M18 flash (Sibley) support (attempt 2)
In-Reply-To: <E1IbE2e-000EEu-00.vasiliy-leonenko-mail-ru@f97.mail.ru>
References: <E1IbE2e-000EEu-00.vasiliy-leonenko-mail-ru@f97.mail.ru>
Message-ID: <200804210902.38080.sr@denx.de>

Hi Vasily,

On Friday 28 September 2007, Vasiliy Leoenenko wrote:
> > Your patch was corrupted by your mailer which wrapped long lines. It
> > cannot be applied.
>
> Thank you very much for your reply. Gmail wrapped long lines. So I changed
> mail box. This is the second attempt.
>
> The patch was verified on different kinds of NOR using Mainstone II
> platform - no issues are found on u-boot (versions 1.3.0-rc1 and
> 1.3.0-rc2).
>
> Any comments and suggestions are welcome.

Sorry, but I really forgot about this patch. Could you please resend this 
patch against the current tot, since it doesn't apply cleanly anymore?

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From matthias.fuchs at esd-electronics.com  Mon Apr 21 09:23:17 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 09:23:17 +0200
Subject: [U-Boot-Users] [PATCH V2] cfi-flash: Add
	CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: <20080420234539.708B6248A6@gemini.denx.de>
References: <20080420234539.708B6248A6@gemini.denx.de>
Message-ID: <200804210923.18006.matthias.fuchs@esd-electronics.com>

Hi,

let me summarize: let's take my initial patch that I posted on Friday.
At least two people will be satisfied :-)

Matthias

On Monday 21 April 2008 01:45, Wolfgang Denk wrote:
> In message <200804201937.32557.matthias.fuchs at esd-electronics.com> you wrote:
> > This patch adds a configurable flash auto protection list that can be used
> > to make U-Boot protect flash regions in flash_init().
> > 
> > The idea has been discussed on the u-boot mailing list starting
> > on Nov 18th, 2007.
> > 
> > Even this patch brings a new feature it is used as a bugfix for 4xx
> > platforms where flash_init() does not completely protect the
> > monitor's flash range in all situations.
> > 
> > U-Boot protects the flash range from CFG_MONITOR_BASE to
> > (CFG_MONITOR_BASE + monitor_flash_len  - 1) by default. This does not
> > include the reset vector at 0xfffffffc.
> > 
> > Example:
> > #define CFG_FLASH_AUTOPROTECT_LIST {{0xfff80000, 0x80000}}
> > 
> > This config option will auto protect the last 512k of flash that
> > contains the bootloader on board like APC405 and PMC405.
> > 
> > Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
> > ---
> >  drivers/mtd/cfi_flash.c |   21 +++++++++++++++++++++
> >  1 files changed, 21 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> > index e3cfb8a..fad9e8b 100644
> > --- a/drivers/mtd/cfi_flash.c
> > +++ b/drivers/mtd/cfi_flash.c
> > @@ -169,6 +169,17 @@ flash_info_t flash_info[CFG_MAX_FLASH_BANKS];		/* FLASH chips info */
> >  #define CFG_FLASH_CFI_WIDTH	FLASH_CFI_8BIT
> >  #endif
> >  
> > +struct apl_s {
> > +	ulong start;
> > +	ulong size;
> > +};
> > +
> > +#if !defined(CFG_FLASH_AUTOPROTECT_LIST)
> > +struct apl_s apl[] = {};
> > +#else
> > +struct apl_s apl[] = CFG_FLASH_AUTOPROTECT_LIST;
> > +#endif
> 
> No. Please don't add any code nor data when CFG_FLASH_AUTOPROTECT_LIST
> is undefined.
> 
> >  typedef unsigned long flash_sect_t;
> >  
> >  /* CFI standard query structure */
> > @@ -1966,6 +1977,16 @@ unsigned long flash_init (void)
> >  		       CFG_ENV_ADDR_REDUND + CFG_ENV_SIZE_REDUND - 1,
> >  		       flash_get_info(CFG_ENV_ADDR_REDUND));
> >  #endif
> > +
> > +	for (i = 0; i < ARRAY_SIZE(apl); i++) {
> > +		debug ("autoprotecting from %08x to %08x\n",
> > +		       apl[i].start, apl[i].start + apl[i].size - 1);
> > +		flash_protect (FLAG_PROTECT_SET,
> > +			       apl[i].start,
> > +			       apl[i].start + apl[i].size - 1,
> > +			       flash_get_info (apl[i].start));
> > +	}
> > +
> 
> No. Please don't add any code nor data when CFG_FLASH_AUTOPROTECT_LIST
> is undefined.
> 
> NAK.
> 
> Best regards,
> 
> Wolfgang Denk
> 



From wd at denx.de  Mon Apr 21 09:26:48 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 09:26:48 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Mon, 21 Apr 2008 01:25:42 EDT."
	<200804210125.45077.vapier@gentoo.org>
Message-ID: <20080421072648.0BAAA247AF@gemini.denx.de>

In message <200804210125.45077.vapier at gentoo.org> you wrote:
>
> > Intended and documented behaviour is that "go" is used to start
> > standalone applications, which are supposed to return.
> 
> then how exactly are people supposed to execute their flat binaries ?  none of 

I am not an expert for the Blackfin implementation. But "go"  is  for
standalone applications. The "boot*" commands are intended to boot OS
images.

> the other boot methods allow for straight jumps that i'm aware of.  otherwise 
> i'm going to have to add even more bloat to add a slight variation on the go 
> command: one where the documentation doesnt require it to return.

That makes no sense to me. If you want to boot some OS, use a "boot*"
commands, not "go" or the like.

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: wd at denx.de
Sometimes a man will tell his bartender things he'll never tell his doctor.
	-- Dr. Phillip Boyce, "The Menagerie" ("The Cage"),
	   stardate unknown.



From joakim.tjernlund at transmode.se  Mon Apr 21 09:38:38 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Mon, 21 Apr 2008 09:38:38 +0200
Subject: [U-Boot-Users] [PATCH] fw_printenv: Add -v and -q options.
In-Reply-To: <20080420232327.DF45E248A6@gemini.denx.de>
References: <20080420232327.DF45E248A6@gemini.denx.de>
Message-ID: <1208763518.23644.44.camel@gentoo-jocke.transmode.se>


On Mon, 2008-04-21 at 01:23 +0200, Wolfgang Denk wrote:
> In message <1208527021-16460-1-git-send-email-Joakim.Tjernlund at transmode.se> you wrote:
> > Add -v for verbose output, "Unlocking flash...", "Done" etc.
> > Add -q for quiet operation, do not print error and verbose
> > messages.
> 
> This seems kind of redundandant to me.
> 
> And not printing error messages seems an error to me.

Perhaps a little overkill. How about removing the -v printouts 
"Unlocking flash...", "Done" etc. and removing the
  "## Error: \"%s\" not defined\n", name);
message?

The verbose messages are a bit annoying when using it interactively
and the error message when it can't find a variable too.
Note that this particular error message is only
printed when using the -n option.

> 
> > Add a --help(-help, -?) option too.
> > 
> > The -q option is intended for scripting.
> 
> Feel free to add "2>/dev/null" to your scripts when you think this is
> really what you want to have.

Yes, can do that too, just figured I could add a -q  while I was at it.

> 
> > +int check_option(int *argc, char *argv[], const char *option)
> > +{
> > +	int i,j;
> > +
> > +	for (i = 1; i < *argc; i++)
> > +		if (strcmp (argv[i], option) == 0) {
> > +			for (j=i; j < *argc; j++)
> > +				argv[j] = argv[j+1]; /* remove option */
> > +			*argc -= 1;
> > +			return 1;
> > +		}
> > +	return 0;
> > +}
> > +
> > +void check_quiet(int *argc, char *argv[])
> > +{
> > +	if (check_option(argc, argv, "-q"))
> > +		fw_quiet = 1;
> > +}
> > +
> > +void check_verbose(int *argc, char *argv[])
> > +{
> > +	if (check_option(argc, argv, "-v"))
> > +		fw_verbose = 1;
> > +}
> 
> I've seen many diffeent versions of argument checking code.  This  is
> not  a  nice one. See for example "tools/mkimage.c" for the "classic"
> approach.

:), I figured it was creative so I didn't have to touch so much of the
existing code.



From wd at denx.de  Mon Apr 21 09:44:12 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 09:44:12 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: Your message of "Mon, 21 Apr 2008 07:29:53 +0200."
	<200804210729.53635.sr@denx.de>
Message-ID: <20080421074412.AF691247AF@gemini.denx.de>

Dear Stefan,

in message <200804210729.53635.sr at denx.de> you wrote:
>
> > I don't like to see these either, but it's better than lying in the
> > face of the user.
> 
> Please note that it is not so easy on 440 to even define *what exactly* the
> functions/commands d/icache_en/disable mean. This is because 440 has MMU 
> support and we can have different cache setups for all TLB entries. So to 
> which TLB entries should these functions refer? Just those mapping SDRAM? 
> And/or FLASH? And/or internal SRAM? ...

You are the 440 expert, not me :-)

> > > you are you asking for additional changes too. Are you asking me to
> > > remove (a) all dummy cache entries or (b) to support *real* cache suppo> rt
> > > functions for 440? (a) would lead as explained above to bigger code
> > > changes in the common code and (b) is extremely difficult and I just ha> ve
> > > no time for such a thing currently.
> >
> > Yes, let's do either (a) or (b). There is no other choice.
> 
> From my point of view, both "solutions" should not be done outside of a 
> merge-window. I'll try to find some time to implement on of those options in 
> the next weeks. But perhaps somebody else has more "free time" and sends 
> patches to implement (and test) this stuff.

I agree that it is probably not  possible  to  fix  this  right  now,
especially  since the actual problem is older, it just became visible
now.

But I insist that this must be fixed  for  the  next  release  -  and
actually it seems to be a good thing to really enable the instruction
cache  -  this would allow to speed up booting on 440 systems quite a
bit.

> > This still leaves the problem of the current "implementation" of  the
> > other  stubs. Please note that as is, we even have *random* behaviour
> > of the code, as the  functions  are  supposed  to  return  the  cache
> > status, but no return value gets loaded.
> 
> I don't see such a problem with *random* behavior. d/icache_status return 0 on 
> 440.

Ah, you are  right.  I  thought  that  the  {i,d}cache_{en,dis}able()
functions  returned a status, but they are indeed void. Sorry for the
false alarm.

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: wd at denx.de
There's no sense in being precise  when  you  don't  even  know  what
you're talking about.                             -- John von Neumann



From peter.pearse at arm.com  Mon Apr 21 09:24:22 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Mon, 21 Apr 2008 08:24:22 +0100
Subject: [U-Boot-Users] FW:  [GIT PULL] Please pull u-boot-arm
In-Reply-To: <20080418001736.GA12486@game.jcrosoft.org>
References: <000101c8a097$e0f8d990$3a4d010a@Emea.Arm.com>
	<20080418001736.GA12486@game.jcrosoft.org>
Message-ID: <000001c8a380$b881b9f0$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagnioj at jcrosoft.com] 
> Sent: 18 April 2008 01:18
> To: Peter Pearse
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] FW: [GIT PULL] Please pull u-boot-arm
> 
> On 15:32 Thu 17 Apr     , Peter Pearse wrote:
> >  
> > > > 
> > > > What's the status of re-applying the reverted patches?
> > > > 
> > > > I really like to see
> > > > 
> > > > [PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and 
> > > > cleanup
--- snip ---
> > > 
> > > Dirk
> > > 	Sorry, I'm still sorting my mail system.
> > > 
> > > 	Perhaps another ARM guardian could pick it up.
> > > Regards
> > > 
> > > Peter
> > > 
> I'll pick it up
> 
> Best Regards,
> J.
> 
Thanks Jean-Chritophe

Regards

Peter





From giometti at enneenne.com  Mon Apr 21 09:47:49 2008
From: giometti at enneenne.com (Rodolfo Giometti)
Date: Mon, 21 Apr 2008 09:47:49 +0200
Subject: [U-Boot-Users] [PATCH] video: Add missing free for logo memory
In-Reply-To: <200804181628.46905.matthias.fuchs@esd-electronics.com>
References: <200804181628.46905.matthias.fuchs@esd-electronics.com>
Message-ID: <20080421074748.GA11596@enneenne.com>

On Fri, Apr 18, 2008 at 04:28:46PM +0200, Matthias Fuchs wrote:
> This patch adds some missing free()s and does some coding style clean up.

Please, separate the patches or just send the one which fixes memory
allocation only.

> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
> ---
>  drivers/video/cfb_console.c |   10 ++++++----
>  1 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
> index 4f73067..751c2c4 100644
> --- a/drivers/video/cfb_console.c
> +++ b/drivers/video/cfb_console.c
> @@ -830,7 +830,7 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
>  		dst = malloc(CFG_VIDEO_LOGO_MAX_SIZE);
>  		if (dst == NULL) {
>  			printf("Error: malloc in gunzip failed!\n");
> -			return(1);
> +			return 1;
>  		}
>  		if (gunzip(dst, CFG_VIDEO_LOGO_MAX_SIZE, (uchar *)bmp_image, &len) != 0) {
>  			printf ("Error: no valid bmp or bmp.gz image at %lx\n", bmp_image);
> @@ -849,6 +849,7 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
>  		if (!((bmp->header.signature[0] == 'B') &&
>  		      (bmp->header.signature[1] == 'M'))) {
>  			printf ("Error: no valid bmp.gz image at %lx\n", bmp_image);
> +			free(dst);

Do you need checking for dst==NULL? (see below)

>  			return 1;
>  		}
>  #else
> @@ -869,6 +870,8 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
>  	if (compression != BMP_BI_RGB) {
>  		printf ("Error: compression type %ld not supported\n",
>  			compression);
> +		if (dst)
> +			free(dst);

Maybe you don't need checking for dst==NULL... (see above)

>  		return 1;
>  	}
>  
> @@ -1046,12 +1049,11 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
>  	}
>  
>  #ifdef CONFIG_VIDEO_BMP_GZIP
> -	if (dst) {
> +	if (dst)
>  		free(dst);

Ditto.

> -	}
>  #endif
>  
> -	return (0);
> +	return 0;
>  }
>  #endif
>  
> -- 
> 1.5.3

Thanks,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at linux.it
Embedded Systems                     phone:	+39 349 2432127
UNIX programming                     skype:     rodolfo.giometti



From vapier at gentoo.org  Mon Apr 21 09:49:26 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 21 Apr 2008 03:49:26 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <20080421072648.0BAAA247AF@gemini.denx.de>
References: <20080421072648.0BAAA247AF@gemini.denx.de>
Message-ID: <200804210349.27495.vapier@gentoo.org>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804210125.45077.vapier at gentoo.org> you wrote:
> > > Intended and documented behaviour is that "go" is used to start
> > > standalone applications, which are supposed to return.
> >
> > then how exactly are people supposed to execute their flat binaries ? 
> > none of
>
> I am not an expert for the Blackfin implementation. But "go"  is  for
> standalone applications. The "boot*" commands are intended to boot OS
> images.
>
> > the other boot methods allow for straight jumps that i'm aware of. 
> > otherwise i'm going to have to add even more bloat to add a slight
> > variation on the go command: one where the documentation doesnt require
> > it to return.
>
> That makes no sense to me. If you want to boot some OS, use a "boot*"
> commands, not "go" or the like.

i'm not talking about operating system code, i'm talking about flat binary 
applications that run bare metal.  something like "u-boot.bin" where it's 
just a binary blob that gets loaded and u-boot jumps to it and never returns.

since "go" isnt appropriate according to you (and seeing as how none of the 
boot commands are appropriate), then the only next step is to implement 
a "jump" command that is exactly like "go" except it doesnt return.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/ac20f856/attachment.pgp 

From sr at denx.de  Mon Apr 21 10:23:57 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 10:23:57 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: <20080421074412.AF691247AF@gemini.denx.de>
References: <20080421074412.AF691247AF@gemini.denx.de>
Message-ID: <200804211023.57611.sr@denx.de>

Hi Wolfgang,

On Monday 21 April 2008, Wolfgang Denk wrote:
> > Please note that it is not so easy on 440 to even define *what exactly*
> > the functions/commands d/icache_en/disable mean. This is because 440 has
> > MMU support and we can have different cache setups for all TLB entries.
> > So to which TLB entries should these functions refer? Just those mapping
> > SDRAM? And/or FLASH? And/or internal SRAM? ...
>
> You are the 440 expert, not me :-)

This has nothing to do with 440. It's more a general question. But OK, from my 
understanding, it makes most sense that the i/dcache U-Boot commands touch 
the cache attributes of all SDRAM related TLB's.

> > > > you are you asking for additional changes too. Are you asking me to
> > > > remove (a) all dummy cache entries or (b) to support *real* cache
> > > > suppo> rt functions for 440? (a) would lead as explained above to
> > > > bigger code changes in the common code and (b) is extremely difficult
> > > > and I just ha> ve no time for such a thing currently.
> > >
> > > Yes, let's do either (a) or (b). There is no other choice.
> >
> > From my point of view, both "solutions" should not be done outside of a
> > merge-window. I'll try to find some time to implement on of those options
> > in the next weeks. But perhaps somebody else has more "free time" and
> > sends patches to implement (and test) this stuff.
>
> I agree that it is probably not  possible  to  fix  this  right  now,
> especially  since the actual problem is older, it just became visible
> now.

I knew they existed and still thing this is no problem. But we seem to 
disagree here.

> But I insist that this must be fixed  for  the  next  release  -  and
> actually it seems to be a good thing to really enable the instruction
> cache  -  this would allow to speed up booting on 440 systems quite a
> bit.

You might remember that I mentioned that this currently existing cache support 
for 440 is not finished yet. There are still some issues, for example some 
drivers like USB won't work currently with d-cache enabled. This is the 
reason that I didn't enable this option for any of the 4xx boards that I 
maintain. Please note that I already spent some days of my "free time" to 
this cache support on 440. Matthias Fuchs also has contributed here.

And what does this mean that you "insist that this must be fixed for the next 
release"? I'm sorry, but I personally can't promise to "fix" this issue until 
the next merge window opens.

> > > This still leaves the problem of the current "implementation" of  the
> > > other  stubs. Please note that as is, we even have *random* behaviour
> > > of the code, as the  functions  are  supposed  to  return  the  cache
> > > status, but no return value gets loaded.
> >
> > I don't see such a problem with *random* behavior. d/icache_status return
> > 0 on 440.
>
> Ah, you are  right.  I  thought  that  the  {i,d}cache_{en,dis}able()
> functions  returned a status, but they are indeed void. Sorry for the
> false alarm.

OK.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Mon Apr 21 10:34:18 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 10:34:18 +0200
Subject: [U-Boot-Users] [uboot] Walnut PPC405GP flash
In-Reply-To: <cdb837ea0804202342i4285ee8em4794993560b06182@mail.gmail.com>
References: <cdb837ea0804202249w453cbb87td879ff09ec138bd4@mail.gmail.com>
	<200804210824.45648.sr@denx.de>
	<cdb837ea0804202342i4285ee8em4794993560b06182@mail.gmail.com>
Message-ID: <200804211034.18719.sr@denx.de>

On Monday 21 April 2008, ?? wrote:
> Yep! The ppcboot is very ancient. hehe.
> Actually, my board is DHT-walnut: http://elinux.org/DHT-Walnut_U_Boot

So, it's no "real" Walnut. Then the official Walnut U-Boot will probably not 
work for your board.

> The web provides a pre-compiled bin uboot 1.1.4  for my board. The size is
> 256KB.

4xx U-Boot images need to get loaded at the "end" of flash. So a 256k image 
need to get loaded at 0xfffc0000.

> I downloaded it, and burn this bin into flash. But the board is still not
> work.
> Well, you point out a very important thing that 4xx use 0xfffffffc as the
> reset vector.
> My flash is 512KB larger, therefore the bin only fills the first 256KB of
> the flash.
> The reset vector is not set correct. Am I correct? It seem that it depends
> on how CPU
> maps flash contents into address space. And how to set it? I don't know
> how to determine the real entry of a specific uboot-bin.  :<

As mentioned above, you have to program a 256k image to 0xfffc0000.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From tur at semihalf.com  Mon Apr 21 10:39:53 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Mon, 21 Apr 2008 10:39:53 +0200
Subject: [U-Boot-Users] [PATCH] image: remove inline
 for	image_print_contents and image_print_contents_noindent
In-Reply-To: <1208623614-26957-1-git-send-email-plagnioj@jcrosoft.com>
References: <1208620760-23645-1-git-send-email-plagnioj@jcrosoft.com>
	<1208623614-26957-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <480C52D9.7050404@semihalf.com>

Jean-Christophe PLAGNIOL-VILLARD wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

Hi Jean-Christophe,

Please have a look at my patch:

Date: Fri, 18 Apr 2008 12:39:23 +0200
Subject: [U-Boot-Users] [PATCH v2] Memory footprint optimizations

It rearranges image printing functions, in particular it removes the
image_print_contents_noindent() function and changes the implementation
of image_print_contents() making it non-inline among other things. So it
seems that your changes will not be necessary eventually (apart from the
rationale for them, which Wolfgang has already asked about).

Regards,
Bartlomiej



From matthias.fuchs at esd-electronics.com  Mon Apr 21 10:51:19 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 10:51:19 +0200
Subject: [U-Boot-Users] [PATCH] video: Add missing free for logo memory
In-Reply-To: <20080421074748.GA11596@enneenne.com>
References: <200804181628.46905.matthias.fuchs@esd-electronics.com>
	<20080421074748.GA11596@enneenne.com>
Message-ID: <200804211051.19698.matthias.fuchs@esd-electronics.com>

On Monday 21 April 2008 09:47, Rodolfo Giometti wrote:
> On Fri, Apr 18, 2008 at 04:28:46PM +0200, Matthias Fuchs wrote:
> > This patch adds some missing free()s and does some coding style clean up.
> 
> Please, separate the patches or just send the one which fixes memory
> allocation only.
Please see my comments below. I will resubmit the patch. But w/o the cleanup.

Matthias

> 
> > Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
> > ---
> >  drivers/video/cfb_console.c |   10 ++++++----
> >  1 files changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
> > index 4f73067..751c2c4 100644
> > --- a/drivers/video/cfb_console.c
> > +++ b/drivers/video/cfb_console.c
> > @@ -830,7 +830,7 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
> >  		dst = malloc(CFG_VIDEO_LOGO_MAX_SIZE);
> >  		if (dst == NULL) {
> >  			printf("Error: malloc in gunzip failed!\n");
> > -			return(1);
> > +			return 1;
> >  		}
> >  		if (gunzip(dst, CFG_VIDEO_LOGO_MAX_SIZE, (uchar *)bmp_image, &len) != 0) {
> >  			printf ("Error: no valid bmp or bmp.gz image at %lx\n", bmp_image);
> > @@ -849,6 +849,7 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
> >  		if (!((bmp->header.signature[0] == 'B') &&
> >  		      (bmp->header.signature[1] == 'M'))) {
> >  			printf ("Error: no valid bmp.gz image at %lx\n", bmp_image);
> > +			free(dst);
> 
> Do you need checking for dst==NULL? (see below)
No, not here!

> 
> >  			return 1;
> >  		}
> >  #else
> > @@ -869,6 +870,8 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
> >  	if (compression != BMP_BI_RGB) {
> >  		printf ("Error: compression type %ld not supported\n",
> >  			compression);
> > +		if (dst)
> > +			free(dst);
> 
> Maybe you don't need checking for dst==NULL... (see above)
You need it! But I forgot to add the #ifdef CONFIG_VIDEO_BMP_GZIP.

> 
> >  		return 1;
> >  	}
> >  
> > @@ -1046,12 +1049,11 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
> >  	}
> >  
> >  #ifdef CONFIG_VIDEO_BMP_GZIP
> > -	if (dst) {
> > +	if (dst)
> >  		free(dst);
> 
> Ditto.
> 
> > -	}
> >  #endif
> >  
> > -	return (0);
> > +	return 0;
> >  }
> >  #endif
> >  
> > -- 
> > 1.5.3
> 
> Thanks,
> 
> Rodolfo
> 



From wd at denx.de  Mon Apr 21 10:58:20 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 10:58:20 +0200
Subject: [U-Boot-Users] [PATCH] video: Add missing free for logo memory
In-Reply-To: Your message of "Mon, 21 Apr 2008 09:47:49 +0200."
	<20080421074748.GA11596@enneenne.com>
Message-ID: <20080421085820.9AC4A24764@gemini.denx.de>

In message <20080421074748.GA11596 at enneenne.com> you wrote:
> On Fri, Apr 18, 2008 at 04:28:46PM +0200, Matthias Fuchs wrote:
> > This patch adds some missing free()s and does some coding style clean up.
> 
> Please, separate the patches or just send the one which fixes memory
> allocation only.

In principle you are right, but I think this is still acceptable.
Please turn a blind eye...

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: wd at denx.de
"Beware of bugs in the above code; I have only proved it correct, not
tried it."                                             - Donald Knuth



From wd at denx.de  Mon Apr 21 11:03:25 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 11:03:25 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Mon, 21 Apr 2008 03:49:26 EDT."
	<200804210349.27495.vapier@gentoo.org>
Message-ID: <20080421090325.6C85D24764@gemini.denx.de>

In message <200804210349.27495.vapier at gentoo.org> you wrote:
>
> > That makes no sense to me. If you want to boot some OS, use a "boot*"
> > commands, not "go" or the like.
> 
> i'm not talking about operating system code, i'm talking about flat binary
> applications that run bare metal.  something like "u-boot.bin" where it's 
> just a binary blob that gets loaded and u-boot jumps to it and never returns.
> since "go" isnt appropriate according to you (and seeing as how none of the>  
> boot commands are appropriate), then the only next step is to implement 
> a "jump" command that is exactly like "go" except it doesnt return.

This makes no sense. If it is ``exactly like "go"'' it doesn't matter
if the code returns or not (and actually this is what I'm  trying  to
point out all the time).

It's just that "go" shall retain the standard U-Boot environment for
application it runs, and that the applications need to take care if
they need to meddle with interrupts, exception handlers, etc.


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: wd at denx.de
F u cn rd ths u cnt spl wrth a dm!



From wd at denx.de  Mon Apr 21 11:12:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 11:12:55 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: Your message of "Mon, 21 Apr 2008 10:23:57 +0200."
	<200804211023.57611.sr@denx.de>
Message-ID: <20080421091255.1E5A224764@gemini.denx.de>

In message <200804211023.57611.sr at denx.de> you wrote:
> 
> > You are the 440 expert, not me :-)
> 
> This has nothing to do with 440. It's more a general question. But OK, from my 

Well, it affects only processors which need MMU support. Most doen't.

> understanding, it makes most sense that the i/dcache U-Boot commands touch 
> the cache attributes of all SDRAM related TLB's.

In general, the chackes should be enabled whenever and whereever
possible.

I think it should be pretty safe to enable the I cache for all SDRAM,
SRAM and flash areas; or,  put  differently,  for  all  memory  areas
except maybe any mapped PCI memory windows.

If possible, also D cahce should be enabled, but I cannot judge if
this works or not with the given driver code.

Also, it depends on where the initial stack and data is located  (you
probably cannot disable caches if you put initial data in cache).

> > I agree that it is probably not  possible  to  fix  this  right  now,
> > especially  since the actual problem is older, it just became visible
> > now.
> 
> I knew they existed and still thing this is no problem. But we seem to 
> disagree here.

The problem is that the code is misleading. I read some  source  file
and  see  "icache_enable()",  so  I  expect  that  the  I cache is on
afterwards. It is  completely  counterintuitive  if  it  isn't.  Such
things  have  caused  debugging  nightmares  before, and I don't have
enough hair left to tear the rest on such things.

> You might remember that I mentioned that this currently existing cache support 
> for 440 is not finished yet. There are still some issues, for example some 

Yes, I do remember that. But I assumed that the implementation is just
missing. Those fake functions are unacceptable.

> drivers like USB won't work currently with d-cache enabled. This is the 
> reason that I didn't enable this option for any of the 4xx boards that I 
> maintain. Please note that I already spent some days of my "free time" to 
> this cache support on 440. Matthias Fuchs also has contributed here.

I appreciate this.

> And what does this mean that you "insist that this must be fixed for the next 
> release"? I'm sorry, but I personally can't promise to "fix" this issue until 
> the next merge window opens.

Next release means the one that comes after the next merge window.


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: wd at denx.de
I object to intellect without discipline;  I object to power without
constructive purpose.
	-- Spock, "The Squire of Gothos", stardate 2124.5



From matthias.fuchs at esd-electronics.com  Mon Apr 21 11:19:04 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 11:19:04 +0200
Subject: [U-Boot-Users] [PATCH V2] video: Add missing free for logo memory
Message-ID: <200804211119.04324.matthias.fuchs@esd-electronics.com>

This patch adds two missing free()s.

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 drivers/video/cfb_console.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 4f73067..68b9861 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -849,6 +849,7 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
 		if (!((bmp->header.signature[0] == 'B') &&
 		      (bmp->header.signature[1] == 'M'))) {
 			printf ("Error: no valid bmp.gz image at %lx\n", bmp_image);
+			free(dst);
 			return 1;
 		}
 #else
@@ -869,6 +870,10 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
 	if (compression != BMP_BI_RGB) {
 		printf ("Error: compression type %ld not supported\n",
 			compression);
+#ifdef CONFIG_VIDEO_BMP_GZIP
+		if (dst)
+			free(dst);
+#endif
 		return 1;
 	}
 
-- 
1.5.3




From vapier at gentoo.org  Mon Apr 21 11:41:40 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 21 Apr 2008 05:41:40 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <20080421090325.6C85D24764@gemini.denx.de>
References: <20080421090325.6C85D24764@gemini.denx.de>
Message-ID: <200804210541.41085.vapier@gentoo.org>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804210349.27495.vapier at gentoo.org> you wrote:
> > > That makes no sense to me. If you want to boot some OS, use a "boot*"
> > > commands, not "go" or the like.
> >
> > i'm not talking about operating system code, i'm talking about flat
> > binary applications that run bare metal.  something like "u-boot.bin"
> > where it's just a binary blob that gets loaded and u-boot jumps to it and
> > never returns. since "go" isnt appropriate according to you (and seeing
> > as how none of the> boot commands are appropriate), then the only next
> > step is to implement a "jump" command that is exactly like "go" except it
> > doesnt return.
>
> This makes no sense. If it is ``exactly like "go"'' it doesn't matter
> if the code returns or not (and actually this is what I'm  trying  to
> point out all the time).

the obvious implication is that i would add the cache disabling hooks to the 
jump command instead of the go command since you wont allow the hook around 
go.

> It's just that "go" shall retain the standard U-Boot environment for
> application it runs, and that the applications need to take care if
> they need to meddle with interrupts, exception handlers, etc.

U-Boot sets up no interrupts and the only exceptions that occur on the 
Blackfin are for cache handling.  disabling the caches forces a sane 
environment where applications dont have to deal with a chicken/egg of having 
to setup exception handlers before taking an exception.  we've seen it 
already with customers.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/1f91120b/attachment.pgp 

From matthias.fuchs at esd-electronics.com  Mon Apr 21 11:37:54 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 11:37:54 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update esd's common LCD code for 405
	boards
Message-ID: <200804211137.55194.matthias.fuchs@esd-electronics.com>

- Coding style cleanup (long lines)
- Add s1d13505 support
- Make some functions return a result code instead of void

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/common/lcd.c                    |  123 ++++++++++++++++++++---------
 board/esd/common/s1d13505_640_480_16bpp.h |   66 +++++++++++++++
 2 files changed, 151 insertions(+), 38 deletions(-)
 create mode 100644 board/esd/common/s1d13505_640_480_16bpp.h

diff --git a/board/esd/common/lcd.c b/board/esd/common/lcd.c
index ed50def..c23dc81 100644
--- a/board/esd/common/lcd.c
+++ b/board/esd/common/lcd.c
@@ -44,37 +44,57 @@ void lcd_setup(int lcd, int config)
 		/*
 		 * Set endianess and reset lcd controller 0 (small)
 		 */
-		out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & ~CFG_LCD0_RST); /* set reset to low */
+
+		/* set reset to low */
+		out_be32((void*)GPIO0_OR,
+			 in_be32((void*)GPIO0_OR) & ~CFG_LCD0_RST);
 		udelay(10); /* wait 10us */
-		if (config == 1)
-			out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN); /* big-endian */
-		else
-			out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & ~CFG_LCD_ENDIAN); /* little-endian */
+		if (config == 1) {
+			/* big-endian */
+			out_be32((void*)GPIO0_OR,
+				 in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN);
+		} else {
+			/* little-endian */
+			out_be32((void*)GPIO0_OR,
+				 in_be32((void*)GPIO0_OR) & ~CFG_LCD_ENDIAN);
+		}
 		udelay(10); /* wait 10us */
-		out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD0_RST); /* set reset to high */
+		/* set reset to high */
+		out_be32((void*)GPIO0_OR,
+			 in_be32((void*)GPIO0_OR) | CFG_LCD0_RST);
 	} else {
 		/*
 		 * Set endianess and reset lcd controller 1 (big)
 		 */
-		out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & ~CFG_LCD1_RST); /* set reset to low */
+
+		/* set reset to low */
+		out_be32((void*)GPIO0_OR,
+			 in_be32((void*)GPIO0_OR) & ~CFG_LCD1_RST);
 		udelay(10); /* wait 10us */
-		if (config == 1)
-			out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN); /* big-endian */
-		else
-			out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & ~CFG_LCD_ENDIAN); /* little-endian */
+		if (config == 1) {
+			/* big-endian */
+			out_be32((void*)GPIO0_OR,
+				 in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN);
+		} else {
+			/* little-endian */
+			out_be32((void*)GPIO0_OR,
+				 in_be32((void*)GPIO0_OR) & ~CFG_LCD_ENDIAN);
+		}
 		udelay(10); /* wait 10us */
-		out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD1_RST); /* set reset to high */
+		/* set reset to high */
+		out_be32((void*)GPIO0_OR,
+			 in_be32((void*)GPIO0_OR) | CFG_LCD1_RST);
 	}
 
 	/*
 	 * CFG_LCD_ENDIAN may also be FPGA_RESET, so set inactive
 	 */
-	out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN); /* set reset high again */
+	out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN);
 }
 #endif /* CFG_LCD_ENDIAN */
 
 
-void lcd_bmp(uchar *logo_bmp)
+int lcd_bmp(uchar *logo_bmp)
 {
 	int i;
 	uchar *ptr;
@@ -99,13 +119,18 @@ void lcd_bmp(uchar *logo_bmp)
 		len = CFG_VIDEO_LOGO_MAX_SIZE;
 		dst = malloc(CFG_VIDEO_LOGO_MAX_SIZE);
 		if (dst == NULL) {
-			printf("Error: malloc in gunzip failed!\n");
-			return;
+			printf("Error: malloc for gunzip failed!\n");
+			return 1;
+		}
+		if (gunzip(dst, CFG_VIDEO_LOGO_MAX_SIZE,
+			   (uchar *)logo_bmp, &len) != 0) {
+			free(dst);
+			return 1;
+		}
+		if (len == CFG_VIDEO_LOGO_MAX_SIZE) {
+			printf("Image could be truncated"
+			       " (increase CFG_VIDEO_LOGO_MAX_SIZE)!\n");
 		}
-		if (gunzip(dst, CFG_VIDEO_LOGO_MAX_SIZE, (uchar *)logo_bmp, &len) != 0)
-			return;
-		if (len == CFG_VIDEO_LOGO_MAX_SIZE)
-			printf("Image could be truncated (increase CFG_VIDEO_LOGO_MAX_SIZE)!\n");
 
 		/*
 		 * Check for bmp mark 'BM'
@@ -113,7 +138,7 @@ void lcd_bmp(uchar *logo_bmp)
 		if (*(ushort *)dst != 0x424d) {
 			printf("LCD: Unknown image format!\n");
 			free(dst);
-			return;
+			return 1;
 		}
 	} else {
 		/*
@@ -150,7 +175,7 @@ void lcd_bmp(uchar *logo_bmp)
 		printf("LCD: Unknown bpp (%d) im image!\n", bpp);
 		if ((dst != NULL) && (dst != (uchar *)logo_bmp))
 			free(dst);
-		return;
+		return 1;
 	}
 	printf(" (%d*%d, %dbpp)\n", width, height, bpp);
 
@@ -180,23 +205,28 @@ void lcd_bmp(uchar *logo_bmp)
 			if (bpp == 24) {
 				for (x = 0; x < width; x++) {
 					/*
-					 * Generate epson 16bpp fb-format from 24bpp image
+					 * Generate epson 16bpp fb-format
+					 * from 24bpp image
 					 */
 					b = *bmp++ >> 3;
 					g = *bmp++ >> 2;
 					r = *bmp++ >> 3;
-					val = ((r & 0x1f) << 11) | ((g & 0x3f) << 5) | (b & 0x1f);
+					val = ((r & 0x1f) << 11) |
+						((g & 0x3f) << 5) |
+						(b & 0x1f);
 					*ptr2++ = val;
 				}
 			} else if (bpp == 8) {
 				for (x = 0; x < line_size; x++) {
 					/* query rgb value from palette */
-					ptr = (unsigned char *)(dst + 14 + 40) ;
+					ptr = (unsigned char *)(dst + 14 + 40);
 					ptr += (*bmp++) << 2;
 					b = *ptr++ >> 3;
 					g = *ptr++ >> 2;
 					r = *ptr++ >> 3;
-					val = ((r & 0x1f) << 11) | ((g & 0x3f) << 5) | (b & 0x1f);
+					val = ((r & 0x1f) << 11) |
+						((g & 0x3f) << 5) |
+						(b & 0x1f);
 					*ptr2++ = val;
 				}
 			}
@@ -208,11 +238,12 @@ void lcd_bmp(uchar *logo_bmp)
 
 	if ((dst != NULL) && (dst != (uchar *)logo_bmp))
 		free(dst);
+	return 0;
 }
 
 
-void lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
-	      uchar *logo_bmp, ulong len)
+int lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
+	     uchar *logo_bmp, ulong len)
 {
 	int i;
 	ushort s1dReg;
@@ -263,8 +294,22 @@ void lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
 		lcd_reg += 0x10000; /* add offset for 705 regs */
 		puts("LCD:   S1D13705");
 	} else {
-		puts("LCD:   No controller detected!\n");
-		return;
+		out_8(&lcd_reg[0x1a], 0x00);
+		udelay(1000);
+		if (in_8(&lcd_reg[1]) == 0x0c) {
+			/*
+			 * S1D13505 detected
+			 */
+			reg_byte_swap = TRUE;
+			palette_index = 0x25;
+			palette_value = 0x27;
+			lcd_depth = 16;
+
+			puts("LCD:   S1D13505");
+		} else {
+			puts("LCD:   No controller detected!\n");
+			return 1;
+		}
 	}
 
 	/*
@@ -279,7 +324,7 @@ void lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
 				s1dReg &= ~0x0001;
 		}
 		s1dValue = regs[i].Value;
-		lcd_reg[s1dReg] = s1dValue;
+		out_8(&lcd_reg[s1dReg], s1dValue);
 	}
 
 	/*
@@ -291,15 +336,15 @@ void lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
 	/*
 	 * Display bmp image
 	 */
-	lcd_bmp(logo_bmp);
+	return lcd_bmp(logo_bmp);
 }
 
-#if defined(CONFIG_VIDEO_SM501)
 int do_esdbmp(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
 	ulong addr;
+#ifdef CONFIG_VIDEO_SM501
 	char *str;
-
+#endif
 	if (argc != 2) {
 		printf ("Usage:\n%s\n", cmdtp->usage);
 		return 1;
@@ -307,19 +352,22 @@ int do_esdbmp(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 
 	addr = simple_strtoul(argv[1], NULL, 16);
 
+#ifdef CONFIG_VIDEO_SM501
 	str = getenv("bd_type");
 	if ((strcmp(str, "ppc221") == 0) || (strcmp(str, "ppc231") == 0)) {
 		/*
 		 * SM501 available, use standard bmp command
 		 */
-		return (video_display_bitmap(addr, 0, 0));
+		return video_display_bitmap(addr, 0, 0);
 	} else {
 		/*
 		 * No SM501 available, use esd epson bmp command
 		 */
-		lcd_bmp((uchar *)addr);
-		return 0;
+		return lcd_bmp((uchar *)addr);
 	}
+#else
+	return lcd_bmp((uchar *)addr);
+#endif
 }
 
 U_BOOT_CMD(
@@ -327,4 +375,3 @@ U_BOOT_CMD(
 	"esdbmp   - display BMP image\n",
 	"<imageAddr> - display image\n"
 );
-#endif
diff --git a/board/esd/common/s1d13505_640_480_16bpp.h b/board/esd/common/s1d13505_640_480_16bpp.h
new file mode 100644
index 0000000..19b3e0a
--- /dev/null
+++ b/board/esd/common/s1d13505_640_480_16bpp.h
@@ -0,0 +1,66 @@
+/*
+ * (C) Copyright 2008
+ * Matthias Fuchs, esd gmbh germany, matthias.fuchs at esd-electronics.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/*
+ * Panel:  640x480 50Hz TFT Single 18-bit (PCLK=20.000 MHz)
+ * Memory:  DRAM (MCLK=40.000 MHz)
+ */
+static S1D_REGS regs_13505_640_480_16bpp[] =
+{
+	{0x1B,0x00},   /* Miscellaneous Register */
+	{0x23,0x20},   /* Performance Enhancement Register 1 */
+	{0x01,0x30},   /* Memory Configuration Register */
+	{0x22,0x24},   /* Performance Enhancement Register 0 */
+	{0x02,0x25},   /* Panel Type Register */
+	{0x03,0x00},   /* MOD Rate Register */
+	{0x04,0x4F},   /* Horizontal Display Width Register */
+	{0x05,0x0c},   /* Horizontal Non-Display Period Register */
+	{0x06,0x00},   /* HRTC/FPLINE Start Position Register */
+	{0x07,0x01},   /* HRTC/FPLINE Pulse Width Register */
+	{0x08,0xDF},   /* Vertical Display Height Register 0 */
+	{0x09,0x01},   /* Vertical Display Height Register 1 */
+	{0x0A,0x3E},   /* Vertical Non-Display Period Register */
+	{0x0B,0x00},   /* VRTC/FPFRAME Start Position Register */
+	{0x0C,0x01},   /* VRTC/FPFRAME Pulse Width Register */
+	{0x0E,0xFF},   /* Screen 1 Line Compare Register 0 */
+	{0x0F,0x03},   /* Screen 1 Line Compare Register 1 */
+	{0x10,0x00},   /* Screen 1 Display Start Address Register 0 */
+	{0x11,0x00},   /* Screen 1 Display Start Address Register 1 */
+	{0x12,0x00},   /* Screen 1 Display Start Address Register 2 */
+	{0x13,0x00},   /* Screen 2 Display Start Address Register 0 */
+	{0x14,0x00},   /* Screen 2 Display Start Address Register 1 */
+	{0x15,0x00},   /* Screen 2 Display Start Address Register 2 */
+	{0x16,0x80},   /* Memory Address Offset Register 0 */
+	{0x17,0x02},   /* Memory Address Offset Register 1 */
+	{0x18,0x00},   /* Pixel Panning Register */
+	{0x19,0x01},   /* Clock Configuration Register */
+	{0x1A,0x00},   /* Power Save Configuration Register */
+	{0x1C,0x00},   /* MD Configuration Readback Register 0 */
+	{0x1E,0x06},   /* General IO Pins Configuration Register 0 */
+	{0x1F,0x00},   /* General IO Pins Configuration Register 1 */
+	{0x20,0x00},   /* General IO Pins Control Register 0 */
+	{0x21,0x00},   /* General IO Pins Control Register 1 */
+	{0x23,0x20},   /* Performance Enhancement Register 1 */
+	{0x0D,0x15},   /* Display Mode Register */
+};
+
-- 
1.5.3




From sr at denx.de  Mon Apr 21 11:45:27 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 21 Apr 2008 11:45:27 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: <20080421091255.1E5A224764@gemini.denx.de>
References: <20080421091255.1E5A224764@gemini.denx.de>
Message-ID: <200804211145.28004.sr@denx.de>

On Monday 21 April 2008, Wolfgang Denk wrote:
> > This has nothing to do with 440. It's more a general question. But OK,
> > from my
>
> Well, it affects only processors which need MMU support. Most doen't.

I'm not so sure here anymore with all the newer PPC's and other platforms. But 
I have to admit that I'm no expert for those other platforms.

> > understanding, it makes most sense that the i/dcache U-Boot commands
> > touch the cache attributes of all SDRAM related TLB's.
>
> In general, the chackes should be enabled whenever and whereever
> possible.
>
> I think it should be pretty safe to enable the I cache for all SDRAM,
> SRAM and flash areas; or,  put  differently,  for  all  memory  areas
> except maybe any mapped PCI memory windows.
>
> If possible, also D cahce should be enabled, but I cannot judge if
> this works or not with the given driver code.
>
> Also, it depends on where the initial stack and data is located  (you
> probably cannot disable caches if you put initial data in cache).

Another problemtic issue could be the POST area for caches etc. I know that 
self modifying code is used here in some places. This could be more 
problematic with caches enabled.

<snip>

> > And what does this mean that you "insist that this must be fixed for the
> > next release"? I'm sorry, but I personally can't promise to "fix" this
> > issue until the next merge window opens.
>
> Next release means the one that comes after the next merge window.

I did understand this part of the sentence. I'm just not sure what should 
happen with the current code if it doesn't get changed. Again, I personally 
can't promise to "fix" this issue until the next merge window opens.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Mon Apr 21 12:07:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 12:07:49 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Mon, 21 Apr 2008 05:41:40 EDT."
	<200804210541.41085.vapier@gentoo.org>
Message-ID: <20080421100749.377CD247AF@gemini.denx.de>

In message <200804210541.41085.vapier at gentoo.org> you wrote:
>
> > This makes no sense. If it is ``exactly like "go"'' it doesn't matter
> > if the code returns or not (and actually this is what I'm  trying  to
> > point out all the time).
> 
> the obvious implication is that i would add the cache disabling hooks to the 
> jump command instead of the go command since you wont allow the hook around 
> go.

So it would NOT be ``exactly like "go"''.

Providing both a "go" and a "jump" command which differ just in cahce
handling seems broken to me. If you want to add such a feature,  then
I recommend to do it as part of "go", but make it optional, i. e. in-
troduce a new optional argument to the "go" command, something like

	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]

> > It's just that "go" shall retain the standard U-Boot environment for
> > application it runs, and that the applications need to take care if
> > they need to meddle with interrupts, exception handlers, etc.
> 
> U-Boot sets up no interrupts and the only exceptions that occur on the 
> Blackfin are for cache handling.  disabling the caches forces a sane 

There is more procvessors in  this  world  than  just  Blackfin,  and
others  *do*  enable  interrupts,  etc.  It  is  important to me that
implementations behave the same no matter which architecture you  are
using.


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: wd at denx.de
Where there's no emotion, there's no motive for violence.
	-- Spock, "Dagger of the Mind", stardate 2715.1



From matthias.fuchs at esd-electronics.com  Mon Apr 21 11:36:08 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 11:36:08 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update bootlogo for APC405 boards
Message-ID: <200804211136.08349.matthias.fuchs@esd-electronics.com>

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/apc405/logo_640_480_24bpp.c |  800 +++++++++++++++++++++++----------
 1 files changed, 565 insertions(+), 235 deletions(-)

diff --git a/board/esd/apc405/logo_640_480_24bpp.c b/board/esd/apc405/logo_640_480_24bpp.c
index c52a430..eb81329 100644
--- a/board/esd/apc405/logo_640_480_24bpp.c
+++ b/board/esd/apc405/logo_640_480_24bpp.c
@@ -1,235 +1,565 @@
-  0x1f,0x8b,0x08,0x08,0x85,0xd1,0x0f,0x40,0x00,0x03,0x61,0x62,0x67,0x5f,0x6c,0x6f,
-  0x67,0x6f,0x5f,0x36,0x34,0x30,0x5f,0x34,0x38,0x30,0x2e,0x62,0x6d,0x70,0x00,0xed,
-  0xd9,0xcb,0x91,0x25,0x3b,0x15,0x05,0xd0,0x02,0x03,0x08,0x86,0x98,0x80,0x05,0x18,
-  0xc0,0x1c,0x9f,0x30,0x05,0x53,0x18,0x60,0x08,0x9e,0x14,0x8f,0xe6,0x17,0x74,0xd5,
-  0xad,0xca,0x94,0xce,0x2f,0x33,0xd7,0x8a,0x7c,0x13,0x78,0x71,0xb4,0x25,0xdd,0xd6,
-  0x8e,0x86,0x3f,0xfe,0xe9,0x0f,0xbf,0xfd,0xcd,0xdb,0x3f,0xfd,0xe1,0x97,0x7f,0x7e,
-  0xff,0xcb,0x3f,0x7f,0xfe,0xf5,0xdb,0xdb,0xdf,0x7f,0xf5,0xf6,0xf6,0xab,0xb7,0xdf,
-  0xfd,0xf8,0xcf,0xdf,0x7e,0xf9,0xef,0xff,0xf6,0xcb,0xbf,0xf2,0xb7,0x7f,0xfd,0x6b,
-  0x3f,0xfc,0xf9,0x2f,0x7f,0xf9,0x2b,0x00,0x50,0xeb,0x0d,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x62,0xbc,0xbf,0xf8,0x00,0x80,0x35,0xaf,0xba,0x35,0xf0,
-  0x03,0x80,0x67,0x2a,0x28,0x59,0xed,0x0c,0x00,0x6f,0xdd,0xad,0xaa,0x94,0x01,0x78,
-  0x82,0xf6,0xc6,0xd4,0xc8,0x00,0x3c,0xca,0x25,0x4a,0x70,0x48,0x0c,0x00,0xd8,0x34,
-  0xad,0x61,0x5b,0x76,0x04,0x00,0x35,0xee,0x57,0xbb,0x9f,0xba,0x7a,0x7e,0x00,0x6e,
-  0xe3,0xf6,0x9d,0xfb,0xb5,0x5b,0x6e,0x0a,0x80,0xc9,0x1e,0xde,0xbc,0x1f,0x3d,0x64,
-  0x9b,0x00,0xb4,0x50,0xb8,0x07,0x3d,0x7c,0xfb,0x00,0x84,0xf0,0x57,0xdd,0x05,0x4e,
-  0x03,0x80,0x1d,0x9a,0x77,0x93,0x93,0x01,0xe0,0x2c,0xe5,0x1b,0xcb,0x11,0x01,0xf0,
-  0x35,0xb5,0x9b,0xca,0xa1,0x01,0xf0,0x13,0x7f,0xe7,0x2d,0xe6,0x00,0x01,0xd0,0xbc,
-  0x5d,0x1c,0x26,0xc0,0x63,0x29,0xdf,0x5e,0x4e,0x15,0xe0,0x81,0x34,0xef,0x10,0x4e,
-  0x18,0xe0,0x39,0x34,0xef,0x34,0x4e,0x1b,0xe0,0xde,0xfc,0x6f,0xce,0xf3,0x39,0x76,
-  0x80,0xfb,0x51,0xbe,0x57,0xe1,0xfc,0x01,0x6e,0x43,0xf9,0x5e,0x8b,0x5b,0x00,0xb8,
-  0x01,0xcd,0x0b,0x00,0xc5,0xfc,0xcd,0x17,0x00,0x8a,0x29,0x5f,0x00,0x28,0xa6,0x7c,
-  0x81,0x73,0xde,0x3f,0xe8,0x4e,0x04,0x97,0xa3,0x79,0x81,0xa3,0x3e,0xd6,0xee,0xa7,
-  0xba,0x63,0xc2,0x25,0x3c,0xa7,0x7f,0x43,0xfe,0x9a,0x7f,0xbf,0x63,0xb9,0xb3,0x83,
-  0x65,0xa1,0x3b,0x0e,0xda,0x39,0x4c,0xb7,0x00,0x1f,0xa4,0x16,0xcd,0xb4,0xca,0x1b,
-  0x15,0xe6,0xa2,0x09,0xaf,0x64,0xa1,0x2f,0x8e,0xbf,0xfc,0x6b,0xc3,0xdf,0x37,0x2a,
-  0x69,0x73,0xb9,0x96,0xc3,0xfc,0x6f,0x80,0xae,0xd8,0x30,0x55,0xf6,0x1b,0x5e,0xd9,
-  0x26,0x47,0xfe,0xc0,0x8e,0x0a,0x73,0xd1,0x84,0x57,0xb2,0xd3,0x17,0x49,0xc3,0xdf,
-  0xcb,0xfb,0xf7,0xe3,0xba,0x35,0xc7,0xf8,0xd3,0xd2,0x65,0x69,0xe1,0x0a,0x6e,0xd6,
-  0x77,0xd3,0xf2,0x74,0x5d,0x4a,0x76,0xc2,0x2b,0x59,0x2e,0x8b,0xbc,0xe1,0xef,0x7d,
-  0xfd,0xfb,0xbe,0x54,0x6a,0xf5,0x21,0x97,0xa3,0xc2,0x75,0xdc,0xac,0xef,0x0e,0xfe,
-  0x81,0x1d,0x15,0xa6,0xfd,0xd0,0x7e,0x5a,0xf7,0x6e,0x52,0x5f,0xfe,0xfd,0x66,0x59,
-  0x9e,0xb0,0x29,0xfb,0x00,0x8b,0x43,0xc2,0x05,0x15,0x54,0x4c,0x65,0x95,0x0c,0x8c,
-  0xd4,0x75,0x2f,0x6b,0x09,0x77,0x32,0xcf,0x95,0xf7,0xf2,0xef,0x37,0xcb,0xf2,0x84,
-  0x4d,0xd9,0x1b,0xac,0x0c,0x09,0x17,0x54,0x56,0x2e,0x95,0x6d,0x72,0x24,0xd5,0xa8,
-  0x30,0xa3,0x12,0x86,0x84,0x1f,0x27,0xef,0xf1,0xdf,0x9f,0xbc,0x36,0x21,0x4a,0xd2,
-  0x06,0xcb,0xe2,0xc1,0x65,0x95,0x35,0x4b,0x65,0x9b,0x1c,0x09,0x36,0x2a,0x4c,0x7b,
-  0xc8,0x6f,0x17,0xbd,0xbc,0xbc,0xc7,0x7f,0x7f,0xf2,0xda,0x84,0x40,0xe1,0xbb,0xab,
-  0xc9,0x06,0x57,0x56,0xd9,0x2c,0x95,0x7d,0x77,0x24,0xd8,0xa8,0x30,0xd3,0x42,0xc6,
-  0xee,0x62,0x84,0xbc,0xc7,0x7f,0x7f,0xf2,0xda,0x84,0x40,0xe1,0xbb,0xab,0xc9,0x06,
-  0x57,0x56,0x59,0x2b,0x95,0x55,0x72,0x30,0xde,0x9c,0x24,0xed,0x09,0xdf,0x8f,0xad,
-  0x7b,0x61,0x79,0x8f,0xff,0xfe,0xe4,0xb5,0x09,0xb1,0x62,0x77,0x57,0x10,0x0c,0x2e,
-  0xae,0xb2,0x56,0x2a,0xab,0xe4,0x60,0xbc,0x39,0x49,0xda,0x13,0xbe,0x1f,0x5e,0xf7,
-  0xc2,0x92,0x1e,0xff,0xfd,0x5a,0x59,0x9b,0x10,0x2b,0x70,0x6b,0xb1,0x02,0x2e,0x1e,
-  0x26,0x2a,0xee,0x94,0xca,0x36,0x39,0x92,0x70,0x54,0x98,0x69,0x09,0xc3,0xf7,0xd2,
-  0x2f,0xe9,0xf1,0xdf,0x1f,0xbb,0x30,0x21,0x5c,0xc8,0xbe,0x32,0x04,0x5c,0x3c,0x8c,
-  0x53,0x5f,0x28,0x95,0x6d,0x72,0x24,0xe1,0xa8,0x30,0xed,0x21,0x4f,0xad,0x7b,0x49,
-  0x19,0x8f,0x7f,0x48,0xa7,0xac,0x0d,0xc9,0x30,0x30,0x55,0xe4,0x2f,0x00,0xa6,0xa8,
-  0x2f,0x94,0xca,0xbe,0x3b,0x92,0x70,0x54,0x98,0x69,0x21,0xb3,0xf7,0xd5,0xa0,0xbb,
-  0x49,0xfe,0xe7,0x12,0xc1,0xba,0xb3,0xfc,0x5b,0xe1,0x0f,0x04,0xca,0xd4,0x17,0x4a,
-  0x65,0x95,0x1c,0x0c,0x39,0x27,0x49,0x7b,0xc2,0x8f,0x21,0xb3,0xb7,0x56,0xad,0xbb,
-  0x49,0xfe,0x27,0x24,0x58,0xc6,0x06,0xa3,0xa6,0x05,0x66,0x0b,0xfc,0x01,0xc0,0x18,
-  0xf5,0x85,0x52,0x59,0x25,0x07,0x43,0xce,0x49,0xd2,0x9e,0xf0,0x55,0xc8,0xd4,0xdd,
-  0x95,0xda,0x29,0x94,0x58,0x21,0xc1,0x32,0xf6,0x18,0x32,0x2a,0xf6,0xfc,0xf7,0xef,
-  0x1d,0xe6,0xb9,0x7d,0x9b,0x1c,0xc9,0x39,0x27,0x49,0x7b,0xc2,0x2f,0x42,0xa6,0x6e,
-  0xb0,0xd4,0x72,0xa7,0x04,0x8a,0x4a,0x95,0xb1,0xc7,0x90,0x39,0xb1,0xc1,0x76,0xae,
-  0x1b,0xa6,0xba,0x7d,0x9b,0x1c,0xc9,0x39,0x2a,0xcc,0xd8,0x84,0xd9,0xbf,0x8a,0x3a,
-  0xcb,0x9d,0x12,0x28,0x2a,0x55,0xc6,0x1e,0x43,0xe6,0xc4,0x06,0xdb,0xb9,0x6e,0x98,
-  0xaa,0xbe,0x4a,0x36,0x17,0xcd,0x88,0x3a,0x27,0xc9,0x84,0x84,0x5f,0x87,0x4c,0xfd,
-  0x61,0x14,0x59,0xee,0x94,0x40,0x51,0xa9,0x32,0xb6,0x19,0x3e,0x24,0x75,0x9b,0x70,
-  0x59,0xc5,0x3d,0xb2,0xb9,0x68,0x5e,0xda,0x39,0x49,0x26,0x9c,0xd8,0x7e,0x98,0xd1,
-  0x96,0x3b,0x25,0x50,0x54,0xaa,0x8c,0x6d,0x86,0x0f,0x49,0xdd,0x26,0x5c,0x56,0x71,
-  0x8f,0x6c,0x2e,0x9a,0x97,0x76,0x4e,0x92,0xf6,0x84,0x51,0xc7,0x35,0xd7,0x72,0xa7,
-  0x04,0x8a,0x4a,0x95,0xb1,0xcd,0xf0,0x21,0xa9,0xdb,0x84,0xcb,0xaa,0xef,0x91,0xcd,
-  0x75,0x1b,0x0b,0xa5,0x2c,0xcc,0xfc,0x84,0x35,0x3f,0x92,0x44,0xcb,0xb5,0x12,0x25,
-  0x2a,0x52,0xc6,0x36,0x43,0x0e,0x2a,0x2f,0x12,0xdc,0x45,0x71,0x89,0xec,0xaf,0xdb,
-  0x5b,0x28,0x35,0x61,0xae,0x12,0xb2,0xe0,0x77,0x92,0x65,0xb9,0x56,0x42,0x04,0x46,
-  0xca,0xd8,0x66,0xc8,0x41,0xe5,0x45,0x82,0xbb,0xa8,0x2f,0x91,0xcd,0x75,0x93,0x02,
-  0xcf,0x49,0x72,0xad,0x90,0x05,0x3f,0x95,0x14,0xcb,0xb5,0x12,0x22,0x30,0x52,0xc6,
-  0x36,0x43,0x0e,0x2a,0x2f,0x12,0xdc,0x45,0x7d,0x89,0x6c,0xae,0x9b,0x17,0x78,0x4e,
-  0x92,0xf6,0x84,0xa7,0x42,0x16,0xfc,0x5a,0xe2,0x2d,0xd7,0x4a,0x88,0xc0,0x48,0x19,
-  0xdb,0x0c,0x39,0xa8,0xbc,0x48,0x70,0x17,0xf5,0x25,0xb2,0xb9,0x6e,0x5e,0xe0,0x51,
-  0x61,0x2e,0x94,0xb0,0xe6,0x07,0x13,0x6c,0xb9,0x56,0x42,0x04,0x46,0xca,0xd8,0x66,
-  0xc8,0x41,0xe5,0x45,0x82,0x1b,0xa9,0x6c,0x90,0xfd,0x75,0xf3,0x0a,0x65,0x54,0x98,
-  0x6b,0x25,0x2c,0xfb,0xcd,0x84,0x59,0xae,0x95,0x10,0x81,0x91,0x32,0xf6,0x18,0x3e,
-  0x24,0x75,0x9b,0x70,0x65,0x95,0x0d,0xb2,0xbf,0x6e,0x5e,0xa1,0x8c,0x0a,0x73,0xb9,
-  0x84,0x65,0x3f,0x9b,0x30,0xcb,0xcd,0xb2,0x29,0x36,0x4f,0xc6,0x06,0xc3,0x87,0xa4,
-  0x6e,0x13,0xae,0xac,0xb2,0x41,0xf6,0xd7,0xcd,0xeb,0x94,0x39,0x49,0xae,0x98,0xb0,
-  0xf2,0x97,0x13,0x23,0xa4,0x02,0x02,0xab,0x64,0x61,0xd4,0x17,0xd3,0x96,0x07,0xbe,
-  0x27,0xf4,0xef,0xf2,0x90,0x4f,0xa7,0xc1,0x8d,0x54,0x36,0xc8,0xfe,0xba,0xa9,0x9d,
-  0x32,0x2a,0xcc,0x8d,0xe3,0x8d,0x10,0x52,0x01,0x81,0x55,0xb2,0x30,0x2a,0x7c,0xda,
-  0xc7,0x99,0xbd,0x43,0x3e,0x9d,0x06,0x37,0x52,0xf6,0x3e,0x87,0xac,0x9b,0xda,0x29,
-  0xa3,0xc2,0x5c,0x2e,0xde,0xa9,0x84,0xfd,0x42,0x2a,0x20,0xb0,0x4a,0x16,0x46,0x85,
-  0x4f,0xfb,0x38,0xb3,0x77,0xc8,0xa7,0xd3,0xe0,0x46,0x2a,0xdf,0xe7,0xfd,0x75,0x53,
-  0x3b,0x65,0x54,0x98,0xcb,0xc5,0x3b,0x9b,0xb0,0x59,0x48,0x05,0x04,0x56,0xc9,0xc2,
-  0xa8,0xc0,0x54,0xaf,0x06,0x86,0xcc,0xd9,0xc9,0xf3,0x69,0x2a,0xb8,0x8b,0xca,0xf7,
-  0x39,0x64,0xe9,0xbc,0x4e,0x19,0x15,0xa6,0xf1,0xa0,0x76,0xee,0xb7,0xfe,0x57,0xb4,
-  0x91,0x75,0xbb,0x02,0x02,0x7b,0xe4,0xec,0xa8,0x57,0x03,0xd7,0xe6,0x84,0x4f,0x8b,
-  0x8a,0xf4,0x2a,0x18,0xdc,0x45,0xe5,0xfb,0xbc,0xb9,0x6e,0x6a,0xad,0xcc,0x49,0x32,
-  0xfc,0xa0,0xa2,0xd2,0x36,0xdb,0xaf,0x80,0xc0,0x1e,0x39,0x3b,0x2a,0x43,0x60,0xaa,
-  0xd8,0xad,0xed,0xdc,0x32,0xcc,0x56,0xff,0x44,0xef,0xac,0x9b,0x5a,0x2b,0xf5,0x91,
-  0x66,0x7e,0x65,0xd7,0xda,0x69,0xbf,0x02,0x02,0x7b,0xe4,0xec,0xa8,0x0c,0x81,0xa9,
-  0x62,0xb7,0xb6,0x73,0xcb,0x30,0x5b,0xfd,0x13,0xbd,0xb3,0x6e,0x6a,0xad,0xb4,0x17,
-  0xdf,0x90,0xaf,0xf2,0x66,0xdb,0xec,0x57,0x40,0x60,0x8f,0x9c,0x1d,0x15,0x2e,0x36,
-  0x55,0xec,0xd6,0x96,0xaf,0x18,0xae,0xa0,0xfe,0x89,0x5e,0x5e,0x37,0xb5,0x56,0xda,
-  0x8b,0x6f,0xc8,0x57,0x7c,0xb3,0x3d,0x36,0x5b,0x20,0xb6,0x47,0x16,0xa6,0x05,0x0a,
-  0x4f,0x15,0xbb,0xb5,0x9d,0x5b,0x86,0xf1,0x5a,0x9e,0xe8,0xb5,0x75,0x53,0x6b,0xa5,
-  0xbd,0xf8,0x26,0x7c,0xf5,0x37,0xdb,0x63,0xb3,0x05,0x62,0x4b,0xe4,0xec,0xb4,0x40,
-  0x19,0xa9,0x62,0xb7,0xb6,0x76,0xbf,0x70,0x11,0x5d,0x0f,0xf5,0xb4,0x72,0x69,0xef,
-  0xbe,0x09,0x5f,0x94,0x96,0x45,0x4f,0x46,0xdc,0x68,0x81,0xd8,0x12,0x39,0x3b,0x2d,
-  0x4a,0x52,0xaa,0xd8,0xad,0x2d,0xdc,0x2c,0x5c,0x4a,0xcb,0x43,0x3d,0xb0,0x5c,0xda,
-  0xeb,0xaf,0xf7,0x0b,0xd4,0xb8,0xf4,0xe1,0x88,0x1b,0x2d,0x10,0x5b,0x22,0x67,0xa7,
-  0xed,0x0b,0x3f,0x9f,0x57,0xc3,0x6b,0xa2,0xc2,0xc5,0xd5,0x3f,0x98,0x03,0xfb,0xa5,
-  0xbd,0x01,0x1b,0xbf,0x58,0xed,0x01,0x0e,0x44,0xdc,0x68,0x81,0xd8,0x12,0x39,0x3b,
-  0x6d,0x53,0xc6,0xf9,0xbc,0x9a,0x5f,0x96,0x16,0xae,0xac,0xe5,0xb5,0x9c,0x56,0x31,
-  0xed,0x25,0xd8,0xf8,0x85,0x6b,0x0f,0xf0,0x5d,0xbe,0x8d,0x16,0x88,0x2d,0x91,0xb3,
-  0xd3,0xf6,0x85,0x9f,0xcf,0xab,0xe1,0x35,0x51,0xe1,0xe2,0x5a,0x5e,0xcb,0x69,0x15,
-  0xd3,0x5e,0x82,0x2d,0x5f,0x92,0x21,0x31,0x5e,0xe7,0xdb,0x68,0x81,0xd8,0x12,0x39,
-  0x3b,0x2d,0x4a,0x52,0xaa,0xd8,0xad,0x2d,0xdc,0x2c,0x5c,0x4d,0xcb,0xbb,0x3d,0xad,
-  0x6b,0xda,0xab,0x70,0xda,0x81,0x14,0xdf,0x6f,0xa9,0x9d,0x16,0x88,0x6d,0x90,0x53,
-  0xd3,0x62,0x65,0xa4,0xda,0xba,0x15,0x78,0xa8,0xfa,0xd7,0x7b,0x60,0xdd,0xb4,0x17,
-  0xe2,0x9c,0xa3,0xd8,0x37,0x30,0xd2,0xff,0xe7,0x5b,0xea,0x94,0xf0,0x3e,0x3a,0x3b,
-  0x30,0x56,0x78,0xaa,0x80,0x8b,0x81,0x27,0x2a,0x7e,0x30,0x07,0x96,0x4e,0x7b,0x2d,
-  0x4e,0x38,0x84,0x28,0x93,0xb3,0xfd,0xc8,0xb7,0x54,0x2b,0xe1,0x7d,0x74,0x76,0x60,
-  0xac,0xf0,0x54,0x31,0x77,0x03,0x4f,0x54,0xfc,0x5a,0x4e,0xab,0x9e,0xf6,0x72,0x6c,
-  0x3f,0x81,0x58,0xa3,0x13,0xae,0xd5,0x4a,0x78,0x1f,0x9d,0x1d,0xf8,0xe9,0xd8,0xb5,
-  0x21,0x5f,0x24,0x8c,0x9d,0x06,0x1c,0x50,0xfc,0x54,0x4e,0x2b,0xa0,0xf6,0x7e,0x1c,
-  0x72,0x0e,0x51,0xc6,0x06,0xfb,0x11,0x6e,0xa9,0x56,0xc2,0xfb,0xe8,0xec,0xc0,0x57,
-  0x63,0xd7,0xe6,0xbc,0x4a,0x18,0x3b,0x0d,0x38,0xa6,0xf2,0xb5,0x9c,0xd6,0x3b,0xed,
-  0xb5,0x38,0xed,0x40,0xea,0xef,0xb7,0xce,0x5a,0xad,0x84,0x97,0xd1,0xa9,0x81,0xdf,
-  0x4e,0x8e,0x9a,0xb6,0x36,0xe7,0x8b,0x60,0xc0,0x01,0x95,0x0f,0xe6,0xc0,0xba,0x69,
-  0x2f,0xc4,0x81,0x67,0x52,0x7c,0xbf,0x45,0xd6,0x6a,0x25,0xbc,0x8c,0x4e,0x0d,0xfc,
-  0x76,0x72,0xd4,0xb4,0xb5,0x39,0x05,0xc1,0xe0,0xee,0xca,0x5e,0xcb,0x81,0x5d,0xd3,
-  0xde,0x86,0x5d,0x5f,0x92,0x51,0x61,0x3e,0x84,0x3b,0x5f,0x04,0xe1,0xf5,0x71,0xb2,
-  0x91,0xbe,0x99,0x1c,0x35,0x6d,0x6d,0x4e,0x41,0x30,0x78,0x80,0xb2,0xd7,0x72,0x5a,
-  0xcb,0xb4,0xf7,0x60,0xe3,0x97,0x61,0x4e,0x92,0xcf,0xc2,0x9d,0x2f,0x82,0xf0,0xfa,
-  0x38,0xd9,0x48,0xdf,0x4c,0x8e,0x9a,0xb6,0x36,0xa7,0x20,0x18,0x3c,0x43,0xcd,0x83,
-  0x39,0xad,0x65,0xda,0x4b,0xb0,0xfd,0x8b,0x35,0x21,0xc3,0xeb,0x70,0xe7,0x8b,0x20,
-  0xbc,0x3e,0x4e,0x36,0xd2,0x37,0x93,0xa3,0xa6,0xad,0xcd,0x29,0x08,0x06,0x8f,0x51,
-  0xf0,0x60,0x4e,0xeb,0x97,0x51,0x61,0x66,0x1e,0xd1,0x29,0x13,0x32,0xbc,0x0e,0x77,
-  0xb2,0x0b,0x32,0xba,0xe3,0xd4,0xcc,0x6f,0x87,0x47,0x4d,0x5b,0x9b,0x53,0x10,0x0c,
-  0x1e,0xa3,0xe0,0xb5,0x1c,0x58,0x2e,0xa3,0xc2,0x74,0x1d,0x54,0x94,0xf6,0x00,0x5f,
-  0x86,0x3b,0xd9,0x05,0x19,0xdd,0x71,0x6a,0xe6,0xb7,0xc3,0xa3,0xa6,0xad,0xcd,0x29,
-  0x08,0x06,0x4f,0x92,0xfd,0x60,0x16,0xd7,0xca,0x91,0x9c,0xa3,0xc2,0x5c,0x28,0x5b,
-  0x6c,0xe6,0x0a,0x67,0xbb,0x20,0xa3,0x3b,0x4e,0xcd,0xfc,0x76,0x78,0xd4,0xb4,0xb5,
-  0x39,0x05,0xc1,0xe0,0x49,0x0a,0xde,0xcc,0xca,0x4e,0x39,0x12,0x72,0x54,0x98,0xc6,
-  0x78,0x51,0xda,0x03,0x7c,0x19,0xee,0x4c,0x17,0x64,0x74,0xc7,0xc9,0x46,0xfa,0x66,
-  0x78,0xd4,0xb4,0xb5,0x39,0x05,0xc1,0xe0,0x61,0x6e,0x53,0x28,0x07,0x43,0xce,0x49,
-  0xd2,0x9e,0x30,0x44,0xef,0xea,0xdf,0x85,0x3b,0xd3,0x05,0x19,0xdd,0x71,0xb2,0x91,
-  0xbe,0x19,0x1e,0x35,0x6d,0x6d,0x4e,0x41,0x30,0x78,0x9e,0xd4,0x37,0xb3,0xb2,0xef,
-  0x8e,0x84,0x1c,0x15,0xa6,0x3d,0xe1,0xbe,0xc6,0xa5,0x0f,0x84,0x3b,0xd3,0x05,0x19,
-  0xdd,0x71,0xb2,0x91,0xbe,0x19,0x1e,0x35,0x6d,0x6d,0x4e,0x41,0x30,0x78,0xa4,0xbc,
-  0x67,0xb3,0xb8,0xef,0x8e,0x24,0x1c,0x15,0xe6,0x72,0xf1,0xa2,0xd2,0x56,0x38,0xd5,
-  0x05,0x19,0xc5,0x71,0xbe,0x94,0xbe,0x9a,0x1f,0x35,0x6d,0x6d,0x4e,0x41,0x30,0x78,
-  0xa4,0xbc,0x97,0xb3,0xb2,0x4d,0x0e,0xc6,0x1b,0x15,0xa6,0x37,0xe1,0xbe,0xc6,0xa5,
-  0x0f,0x84,0x3b,0xd3,0x05,0x19,0xc5,0x71,0xbe,0x94,0x5e,0xce,0x5f,0x1b,0xf5,0xe9,
-  0xb4,0xc0,0x51,0xe1,0xd3,0xe0,0x91,0xf2,0x1e,0xcf,0xca,0xbe,0x3b,0x12,0x6f,0x4e,
-  0x92,0x09,0x21,0x37,0x75,0xad,0x7b,0x2c,0x5c,0x8e,0xec,0x00,0xb1,0x5b,0x08,0x3f,
-  0x99,0x8c,0x39,0xf0,0x78,0x49,0x8f,0x67,0x65,0xdf,0x1d,0x89,0x37,0x27,0xc9,0x84,
-  0x90,0x9b,0xba,0xd6,0x3d,0x9c,0x2f,0x41,0xef,0xea,0x67,0x5d,0x2b,0x18,0x3c,0x5b,
-  0xf8,0xfb,0x59,0xd9,0x77,0x47,0xb2,0x8d,0x0a,0x33,0x21,0xe4,0x8e,0xae,0x75,0x0f,
-  0xe7,0x6b,0x2d,0x8e,0x8c,0xd5,0xcf,0x1a,0x9b,0x2d,0xe2,0x7a,0xe1,0x7e,0x62,0xdf,
-  0xcf,0xe2,0xbe,0x3b,0x12,0x6c,0x54,0x98,0x8b,0x26,0xdc,0xcf,0x59,0xa1,0xb7,0x35,
-  0xc2,0x57,0x5f,0x30,0x36,0xdb,0xf6,0xdd,0xc2,0x5d,0xc5,0x3e,0xa1,0x95,0x6d,0x72,
-  0x24,0xd5,0xa8,0x30,0x17,0x4d,0xb8,0x9f,0xb3,0x42,0x6f,0x6b,0x84,0xaf,0x1e,0x9b,
-  0x76,0x6c,0x30,0x78,0xbc,0xc0,0x57,0xb4,0xb2,0x4d,0x8e,0xa4,0x9a,0x93,0xe4,0xba,
-  0x09,0xf7,0x73,0x56,0xe8,0x2d,0x8e,0xf0,0xd5,0x63,0xa3,0x4e,0xce,0x06,0x8f,0x17,
-  0xf5,0x90,0x56,0xb6,0xc9,0x91,0x48,0x73,0x92,0xb4,0xc7,0xdb,0x7c,0x09,0xbb,0xd6,
-  0x3d,0x9c,0xaf,0xb5,0x38,0xc2,0x57,0x0f,0x8f,0x3a,0x36,0x18,0x70,0xc1,0xbe,0x9b,
-  0x96,0x27,0xef,0xcc,0x1b,0x13,0x86,0x44,0x2d,0xd2,0xd8,0x1d,0xb1,0x4b,0x27,0x45,
-  0x1d,0x1b,0x0c,0x88,0x78,0x4e,0x8b,0x0b,0xe5,0xc8,0x1f,0xf0,0x39,0x49,0xe6,0x9f,
-  0x55,0x52,0xda,0x22,0x8d,0xc5,0x11,0xb8,0xf4,0x6d,0x72,0x9e,0xcd,0x06,0x6c,0x3f,
-  0xa7,0xd3,0x6a,0x65,0x4e,0x92,0xe1,0x07,0x95,0x17,0xb5,0x48,0x63,0x77,0x04,0x2e,
-  0x9d,0x9a,0xb3,0x2c,0xea,0x42,0x30,0xe0,0x87,0x9d,0x17,0x75,0x5a,0xad,0xcc,0x49,
-  0xd2,0x78,0x44,0x9b,0x3d,0xd8,0xb5,0xee,0xc9,0x94,0x7d,0xf5,0x11,0xb8,0x74,0x52,
-  0xc2,0xca,0xb4,0x3b,0xd9,0x80,0x8d,0x77,0x75,0x5a,0xad,0x74,0x95,0xdd,0xc0,0x2f,
-  0xf5,0xc7,0x90,0xb1,0xee,0xc9,0x94,0x7d,0x0d,0x12,0xb8,0x74,0x52,0xc2,0x9a,0xc0,
-  0x9b,0xa9,0x80,0xff,0x58,0x7b,0x5a,0xa7,0xd5,0x4a,0x7b,0xeb,0xcd,0xf9,0x52,0x7f,
-  0x09,0x19,0xeb,0x9e,0x4c,0xd9,0xd7,0x23,0x81,0x4b,0x87,0x67,0x2b,0x8b,0x1d,0x18,
-  0x0c,0x58,0x7a,0x5d,0xa7,0xd5,0x4a,0x7b,0xeb,0xcd,0xf9,0x52,0x7f,0x06,0x19,0xeb,
-  0x9e,0x4c,0xd9,0xd7,0x23,0x51,0x4b,0x87,0x07,0xab,0x49,0x9e,0x11,0x0c,0x58,0x7a,
-  0x5d,0xa7,0x35,0x4b,0x7b,0xf1,0x4d,0xf8,0x52,0x7f,0x03,0x49,0xeb,0x52,0x4a,0xe7,
-  0xc2,0x3c,0x67,0x1f,0xd8,0x69,0xe5,0xd2,0xde,0x7d,0x13,0xbe,0xa4,0xdb,0xcf,0x5b,
-  0x97,0x1e,0x9a,0x17,0xe6,0x39,0xfe,0xc0,0x4e,0x2b,0x97,0xf6,0xee,0x6b,0xff,0x32,
-  0xee,0xbd,0x60,0x69,0x00,0xfe,0xeb,0xc8,0x03,0x3b,0xad,0x5f,0xda,0xeb,0xaf,0xfd,
-  0x0b,0xbc,0xee,0xb2,0xa5,0x01,0xf8,0xc9,0x91,0x37,0x76,0x5a,0xc5,0xb4,0x37,0x60,
-  0xe3,0x17,0x7b,0xd7,0x95,0xab,0x03,0xf0,0xd1,0xd7,0x6f,0xec,0xb4,0x96,0x69,0x2f,
-  0xc1,0xae,0x2f,0xf0,0x96,0x5b,0x02,0x00,0xf0,0xd1,0x17,0x6f,0xec,0xb4,0xa2,0x69,
-  0xef,0xc1,0x96,0x2f,0xea,0x7e,0xbb,0x02,0x00,0xf0,0xca,0xab,0x67,0x76,0x5a,0xd7,
-  0xb4,0x57,0xe1,0xb4,0x03,0x39,0x78,0xb3,0x8d,0x01,0x00,0x58,0x30,0xb0,0x6e,0xda,
-  0x0b,0x71,0xd4,0x69,0x14,0x1c,0x17,0x00,0x2d,0xa6,0x95,0x4e,0x7b,0x27,0x4e,0x38,
-  0x84,0xca,0xbb,0x03,0xa0,0xc5,0xb4,0xea,0x69,0x6f,0xc6,0xc6,0xbd,0xb7,0xdc,0x1d,
-  0x00,0x2d,0xa6,0x75,0x50,0x7b,0x45,0xb6,0xec,0xba,0xeb,0xe2,0x00,0xe8,0x32,0xad,
-  0x89,0xda,0x8b,0xf2,0x12,0x8d,0x76,0xad,0xb4,0x00,0x7c,0x74,0xd7,0x86,0xba,0x31,
-  0x17,0x01,0x00,0xc5,0x94,0x2f,0x00,0x14,0x53,0xbe,0x00,0x50,0xcc,0xff,0x05,0x00,
-  0x00,0xc5,0x94,0x2f,0xc0,0xa3,0x78,0xcc,0x27,0x08,0x2c,0x5f,0x57,0x06,0x70,0x15,
-  0xde,0xf3,0x5e,0xca,0x17,0xe0,0xc9,0x3c,0xec,0x2d,0x94,0x2f,0x00,0xff,0xe2,0x79,
-  0xaf,0x11,0xdb,0xbc,0x6e,0x07,0xe0,0x1e,0xbc,0xf3,0xa9,0x94,0x2f,0x00,0x5f,0xf3,
-  0xe0,0x87,0x53,0xbe,0x00,0x1c,0xe4,0xf1,0x0f,0xa1,0x79,0x01,0x58,0xa0,0x0b,0x96,
-  0x85,0x37,0xaf,0x33,0x07,0x78,0x1a,0x8d,0x70,0x8a,0xda,0x05,0x20,0x8a,0x82,0x38,
-  0xc2,0xdf,0x79,0x01,0x48,0xa5,0x32,0x7e,0xa2,0x79,0x01,0x28,0xa3,0x3b,0xde,0xd2,
-  0x9a,0xf7,0x39,0x07,0x08,0xc0,0xb2,0xa7,0xb5,0x49,0x5e,0xe7,0xde,0xef,0xac,0x00,
-  0x28,0x70,0xfb,0x5a,0xd1,0xbc,0x00,0x8c,0x75,0xcb,0xc6,0x51,0xbb,0x00,0x5c,0xc5,
-  0x0d,0x3a,0xc8,0x5f,0x78,0x01,0xb8,0x81,0xc9,0xdd,0x94,0x5d,0xb5,0x3a,0x17,0x80,
-  0x76,0xed,0xcd,0x55,0xd6,0xb6,0x6a,0x17,0x80,0xb1,0xea,0xdb,0x50,0xf3,0x02,0xc0,
-  0x47,0xed,0xa5,0xa9,0x73,0x01,0x78,0xb2,0xf6,0x26,0x55,0xb5,0x00,0xd0,0xde,0xb6,
-  0x3a,0x17,0x00,0x3e,0xa5,0x5e,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
-  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xea,0xfc,0x03,0x26,
-  0x84,0x0a,0xd6,0x36,0x10,0x0e,0x00,
+  0x1f,0x8b,0x08,0x08,0x30,0x72,0x03,0x48,0x00,0x03,0x56,0x6f,0x6c,0x76,0x6f,0x5f,
+  0x53,0x74,0x61,0x72,0x74,0x6c,0x6f,0x67,0x6f,0x2e,0x62,0x6d,0x70,0x00,0xed,0x9d,
+  0x5f,0x70,0x14,0x47,0x7e,0xc7,0x25,0x7b,0x95,0x19,0xb6,0xdb,0x3a,0x9f,0x57,0xc7,
+  0x5d,0x24,0xee,0xb0,0x45,0x4c,0x59,0x96,0xcf,0x04,0x82,0xcf,0x10,0x0e,0xdb,0x01,
+  0xc7,0x94,0x75,0x18,0x9f,0x1d,0xc5,0x87,0x1c,0x22,0xaa,0x8c,0xb8,0x9c,0x51,0x91,
+  0x14,0x92,0xec,0x33,0xc1,0x50,0x8a,0x40,0x25,0x07,0x43,0x9d,0x0e,0x10,0xb7,0x1b,
+  0xa1,0xde,0x55,0x6f,0xf9,0xd1,0x55,0x79,0xc8,0x3d,0xfa,0x2d,0xe5,0x47,0x3f,0xfa,
+  0xd1,0x95,0x37,0x3f,0xfa,0xd1,0x8f,0x4e,0xf7,0xcc,0x74,0xf7,0xaf,0xe7,0xdf,0x4a,
+  0xe2,0x02,0xa2,0xf2,0xfd,0xc0,0x6c,0xcf,0xac,0x66,0x7a,0xfa,0xcf,0xaf,0x7f,0xfd,
+  0xeb,0x5f,0xf7,0xcc,0x1e,0x7a,0xed,0x67,0xff,0x55,0xe9,0xd2,0xfc,0x4c,0x05,0x4f,
+  0xa9,0x70,0xf6,0xa1,0xae,0xae,0xff,0xe9,0xee,0xea,0xea,0xee,0x0a,0xa3,0xef,0xbb,
+  0xfe,0xb3,0xd2,0xf5,0xdf,0xbd,0x5d,0xd1,0x66,0x38,0xf5,0xe8,0x13,0x5d,0x93,0x6a,
+  0x9b,0x56,0xdb,0xa9,0x1f,0xa9,0x7d,0xb5,0x4d,0xab,0xed,0xd4,0xa3,0x43,0xea,0xfb,
+  0x21,0xf5,0xfd,0x50,0xd7,0x05,0xb5,0x9d,0xfa,0x91,0x3a,0x56,0xdb,0xb4,0xda,0x4e,
+  0x3d,0xa1,0xf6,0xd5,0x36,0xad,0xc3,0x1f,0xed,0x56,0xdf,0xed,0x56,0xdf,0xed,0x56,
+  0xdf,0xa9,0x7d,0xb5,0x5d,0xd0,0xfb,0x43,0x6a,0x5f,0x6d,0x17,0x74,0xf8,0xc4,0x7e,
+  0x75,0xbc,0x5f,0x1d,0xef,0x57,0xc7,0xfb,0xbb,0xae,0xa8,0x6d,0x72,0xb7,0x3a,0x56,
+  0xdb,0x85,0xdd,0x7a,0xff,0x90,0xda,0x3f,0xa4,0xf6,0x0f,0x75,0x5d,0xd1,0xfb,0xfb,
+  0xd5,0xbe,0xde,0x76,0x8f,0xa8,0xfd,0x11,0xb5,0x3f,0xd2,0x75,0x45,0x87,0x87,0x54,
+  0xa8,0xb6,0x6b,0x87,0xf4,0xfe,0x9b,0x6a,0xff,0x4d,0xb5,0xff,0x66,0xd7,0x85,0x11,
+  0xb5,0xaf,0xb6,0x6b,0x51,0xf8,0xb6,0x0a,0xdf,0xee,0xba,0xa5,0xb6,0x2b,0x6f,0xaa,
+  0x7d,0xb5,0xdd,0x7a,0x53,0xef,0x9f,0x52,0xfb,0xa7,0xd4,0xbe,0x0a,0xdf,0x56,0xe1,
+  0xdb,0x3a,0x9c,0x54,0xe1,0x64,0xd7,0x1d,0xb5,0x5d,0x3b,0xa5,0xf6,0xd5,0x76,0x47,
+  0x87,0x93,0x7a,0x7f,0x5a,0xed,0x4f,0x77,0x7d,0xa2,0xb6,0x5b,0x93,0x6a,0x5f,0x6d,
+  0x9f,0x44,0xe1,0x05,0x15,0x5e,0xe8,0xba,0x33,0xad,0xc2,0x69,0x1d,0x5e,0x51,0xe1,
+  0x95,0xae,0x4f,0xd5,0x76,0xe7,0x82,0xda,0x57,0xdb,0xa7,0x51,0x78,0x4d,0x85,0xd7,
+  0xba,0x3e,0xb9,0xa2,0x42,0xb5,0xfd,0x51,0x87,0xd7,0xf4,0xfe,0x2d,0xb5,0x7f,0x4b,
+  0xed,0xab,0x50,0x6d,0x9f,0xde,0x52,0xa1,0xde,0xae,0xdd,0x51,0xfb,0x77,0xd4,0xfe,
+  0x9d,0xae,0xcf,0x74,0x78,0x47,0x85,0x77,0xf4,0xf1,0x27,0xea,0xf8,0x13,0x75,0xac,
+  0x42,0xb5,0x7d,0xae,0xc3,0x4f,0x54,0xf8,0x89,0x3e,0xfe,0x54,0x1d,0x7f,0xaa,0x8e,
+  0x55,0xa8,0xb7,0x4f,0xf5,0xf6,0xc7,0xae,0x2f,0xd4,0xf6,0xf9,0x1f,0x55,0xf8,0x47,
+  0x1d,0x7e,0xa6,0xc2,0xcf,0xba,0xbe,0xd4,0xe1,0x67,0x2a,0xfc,0x4c,0x87,0x9f,0xab,
+  0xf0,0xf3,0xae,0xaf,0x74,0xf8,0xb9,0x0a,0x3f,0xd7,0xe1,0x17,0x2a,0xfc,0xa2,0xeb,
+  0xcb,0x2f,0x54,0xf8,0x85,0x0e,0xbf,0x54,0xe1,0x97,0x5d,0x5f,0xab,0xed,0xcb,0x2f,
+  0xd5,0xbe,0xda,0xbe,0x8e,0xc2,0xaf,0x54,0xf8,0x55,0xd7,0x37,0x6a,0xfb,0xea,0x2b,
+  0xb5,0xaf,0xb6,0x6f,0xa2,0xf0,0x6b,0x15,0x7e,0xdd,0xf5,0xf5,0xd7,0x2a,0x8c,0xb6,
+  0x6f,0xba,0xbe,0x55,0xdb,0x37,0xdf,0xa8,0xf0,0x1b,0x1d,0x7e,0xab,0xc2,0x6f,0xbb,
+  0xbe,0x53,0xdb,0x37,0xdf,0xaa,0x7d,0xb5,0x7d,0x17,0x85,0xdf,0xa9,0xf0,0xbb,0xae,
+  0x6f,0xbf,0x53,0x21,0xb6,0x7b,0xbe,0xb5,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0xff,0x1f,0xa4,0x98,0xdc,0xd6,0x99,
+  0xc3,0x42,0xde,0xfd,0x9d,0xd4,0x26,0x64,0x4b,0x2c,0x5d,0x99,0x99,0x78,0xe3,0xa5,
+  0x9f,0x26,0x31,0xff,0xc5,0xfe,0x57,0x4f,0x4c,0x9e,0xbf,0xba,0x2c,0x5a,0x52,0xca,
+  0x76,0xa7,0xbb,0x34,0x4f,0xfc,0x78,0x0d,0xa9,0xdd,0x18,0x3f,0x2d,0xcb,0x63,0x6b,
+  0xf9,0x99,0xce,0x31,0x3c,0x3e,0xd7,0xba,0xeb,0x52,0x52,0x45,0x20,0xa5,0x90,0x62,
+  0xf9,0xea,0x85,0x7f,0x39,0xfe,0xea,0xcf,0x76,0xc4,0x31,0xef,0xf8,0xcb,0xbf,0x19,
+  0x9d,0x98,0x9e,0xbb,0xd1,0x54,0x65,0xd4,0x6e,0x76,0x2e,0xa7,0x07,0x07,0x59,0xdf,
+  0xce,0x18,0x0f,0xd4,0xc6,0x58,0x18,0x7d,0xaa,0x7d,0xfb,0x4d,0xb4,0xaf,0x83,0xf3,
+  0x77,0x7d,0x9f,0x76,0x4b,0x15,0xeb,0xe2,0xd4,0xb1,0xa7,0x75,0xe4,0x9c,0xeb,0x1b,
+  0xc4,0x77,0xe0,0xa1,0x0a,0xfa,0xfe,0x7a,0x6c,0xb6,0xa1,0xce,0xe8,0x14,0xcd,0x28,
+  0x4f,0xd2,0xe7,0x92,0x16,0x7d,0x72,0x73,0xc0,0x6d,0xda,0xb9,0x77,0x46,0x71,0x60,
+  0xb2,0xb9,0xa3,0xe4,0xe6,0x52,0x4c,0x70,0xff,0xda,0x74,0x02,0xa2,0xf2,0xdb,0xdb,
+  0x31,0xfd,0x9d,0x11,0x6d,0xd1,0x98,0x1d,0x3f,0x30,0x10,0xf0,0xb0,0x87,0x27,0x09,
+  0x54,0x9f,0x5b,0x2a,0xc1,0x16,0xc6,0x86,0x8e,0x4e,0xdd,0x10,0xb2,0x73,0x31,0x3d,
+  0x38,0x88,0xf1,0x9e,0xc0,0x2b,0x47,0x66,0x6b,0xce,0x96,0x33,0x67,0xe1,0xae,0xbb,
+  0xcf,0xf2,0xad,0xa9,0x23,0x3b,0x1f,0x8e,0xe3,0x56,0xe2,0x62,0x25,0x46,0x7f,0xa1,
+  0x04,0x3f,0xe4,0x95,0xbe,0x7d,0x27,0x3f,0xea,0xd4,0xb0,0x47,0x49,0xc3,0x88,0x93,
+  0x66,0x84,0x8f,0xc7,0x07,0xbe,0x58,0x18,0x29,0x8f,0x5b,0x56,0x12,0x24,0x67,0xba,
+  0x0b,0xe2,0xa3,0x32,0xf9,0x6b,0x2f,0x6d,0xb3,0xb2,0xca,0x4d,0xbb,0xa1,0xed,0x36,
+  0x11,0xfe,0x99,0xbb,0x2e,0x25,0x79,0x65,0xec,0x67,0xbd,0xac,0x27,0x29,0xa6,0x28,
+  0x6b,0x81,0xad,0x05,0xbd,0x53,0xd9,0xf9,0xda,0x6f,0xeb,0x77,0x7d,0x9b,0x4d,0xc3,
+  0x8d,0x3e,0xa7,0x3f,0x42,0xdb,0xae,0x13,0xf9,0xe0,0x4e,0x2a,0xff,0x59,0x6e,0xb0,
+  0x6f,0xd1,0x9d,0x45,0x53,0xde,0x3e,0xff,0x72,0x5f,0x54,0xe3,0x41,0x1c,0x9d,0x91,
+  0xf3,0xf8,0x0e,0x5a,0x1e,0x2b,0xd1,0x9f,0x7e,0xfa,0x8f,0x57,0x5b,0x2d,0x59,0x28,
+  0x85,0xab,0xa3,0x3c,0xa5,0x7f,0x9c,0xe6,0xa3,0xb2,0x64,0x02,0x5f,0x89,0xe7,0x06,
+  0x56,0x68,0x1f,0x2f,0x94,0x3f,0xa5,0xbb,0x47,0x55,0xe1,0x70,0xbf,0x95,0xfa,0x9f,
+  0x71,0x01,0x0e,0x2f,0x17,0xa7,0xbd,0x73,0x39,0x35,0x5b,0x57,0x4f,0x3e,0xad,0x23,
+  0xab,0x98,0x32,0x22,0xad,0x2d,0x8c,0x8b,0x29,0xfa,0xeb,0x0f,0x5e,0x79,0xaf,0xde,
+  0xd2,0xd6,0xcc,0x06,0xef,0xb5,0x79,0x10,0xc7,0x8c,0x1a,0x70,0x8d,0x98,0xd6,0x11,
+  0x37,0x7f,0x19,0x6c,0x28,0x31,0xda,0xd0,0x2d,0xe4,0x8a,0xb8,0x3c,0x32,0x10,0xc7,
+  0x69,0xb5,0x12,0x55,0x55,0xf6,0xce,0xb1,0x50,0x3d,0x73,0x62,0xa9,0x55,0x68,0xe0,
+  0x8c,0x72,0x7b,0x1e,0xf7,0x35,0x1f,0x67,0x59,0x05,0xc8,0x89,0x44,0x12,0x7d,0x95,
+  0x34,0x34,0xe6,0x72,0xae,0xc3,0x62,0xfd,0x27,0x9b,0x8b,0x7d,0x61,0x46,0xe5,0x59,
+  0x5d,0xe8,0xb4,0x70,0xc8,0xce,0x6c,0xd4,0x34,0x53,0xc6,0xc9,0xed,0x89,0x5d,0x44,
+  0xb1,0x52,0x69,0xe7,0x5e,0x61,0x45,0x37,0xda,0xfa,0xca,0x85,0xe6,0x86,0x65,0x7d,
+  0xd3,0x20,0xaf,0x7e,0xbf,0x27,0x34,0x22,0x60,0x1b,0x1b,0xad,0x15,0xa3,0x6c,0x7a,
+  0x4e,0xad,0xbf,0x07,0x96,0x5a,0x60,0xe5,0xf2,0x6f,0xf7,0x54,0x79,0x25,0x30,0xe2,
+  0xe2,0x2b,0x2e,0xee,0x14,0x61,0x52,0xd2,0xea,0xfb,0xbe,0xd1,0xeb,0x05,0x25,0xdb,
+  0x1a,0xf5,0x5a,0x87,0x8d,0x20,0x55,0x3d,0x4e,0xc0,0x3a,0x6a,0xbe,0xd0,0x7e,0x59,
+  0x22,0x7f,0x2b,0x23,0x41,0x36,0x86,0x1c,0xf5,0xc7,0xc2,0x9f,0x6c,0xa0,0x6b,0x8c,
+  0x4a,0x49,0x2e,0x8e,0xf6,0x25,0x11,0xf9,0x96,0x90,0x67,0x23,0xd8,0xa4,0x87,0xac,
+  0x87,0xed,0x9a,0x7e,0xd0,0x15,0xa0,0x14,0x87,0x3b,0xd5,0x8a,0x15,0x98,0x1f,0xdc,
+  0x5e,0x77,0xf4,0xcd,0xb6,0x6c,0xd5,0xcf,0x0c,0x71,0xd7,0xaf,0x5b,0x05,0xeb,0x0b,
+  0x5f,0x46,0x20,0x6b,0x23,0x0b,0x2d,0x91,0x37,0xcc,0x1b,0x4d,0xd4,0x0d,0xb7,0xba,
+  0x87,0x59,0x15,0xc4,0xd3,0x79,0xe1,0x44,0x55,0x19,0xbb,0x82,0x68,0x2e,0x77,0xeb,
+  0xe8,0xbb,0x6d,0x85,0xf2,0xd7,0x9a,0xaf,0x5a,0x93,0x84,0x5e,0x6f,0x74,0xb1,0x35,
+  0x65,0xd5,0xe7,0xd8,0x06,0xcc,0x14,0xd5,0xf1,0xce,0xbd,0x4a,0x93,0x9c,0x1a,0x40,
+  0x39,0x13,0xc3,0x53,0x0f,0x2c,0x7c,0xea,0xec,0xc6,0xfb,0xfb,0xcd,0x80,0xbc,0x54,
+  0xa1,0x55,0x44,0x3b,0x30,0x5a,0xa7,0xf1,0xdf,0x46,0x55,0x45,0xac,0x37,0xfe,0xe6,
+  0xcc,0x40,0x24,0x7d,0xae,0xa2,0xd2,0x5a,0x29,0x39,0xe0,0xbe,0x51,0x57,0x09,0xd9,
+  0xb1,0xdb,0x39,0x45,0xbb,0x1a,0xf7,0xbf,0x5e,0x67,0x9e,0x19,0x96,0x72,0x4f,0x28,
+  0xdc,0x87,0xaf,0x5a,0xec,0x85,0xa6,0x9a,0x8b,0xf4,0x9f,0x92,0x8e,0xe7,0xcd,0x88,
+  0x8c,0x74,0xf0,0xe9,0x51,0x70,0xfc,0x27,0x5e,0xbb,0xb9,0xee,0x5a,0x10,0xf2,0xe6,
+  0x21,0xed,0x04,0xf0,0x06,0xf1,0xa9,0xb6,0x64,0xeb,0x86,0x9a,0xbb,0xea,0xf3,0xc9,
+  0xf3,0x1b,0x35,0x8b,0x36,0x03,0x62,0x6f,0x0f,0xcb,0x64,0x95,0x76,0xbc,0xc4,0xf6,
+  0x08,0x6b,0xbf,0x5b,0x6f,0x0f,0x2c,0xff,0x30,0xa2,0x7d,0x2d,0x71,0x8c,0x39,0x9d,
+  0xa0,0x89,0x9c,0xbb,0x42,0x4f,0x64,0xa7,0xaa,0xae,0xd9,0xf1,0x61,0x2b,0x57,0xff,
+  0x69,0x2a,0xf1,0xa7,0x91,0x2e,0x62,0xda,0xa5,0xfa,0xc6,0xf8,0x44,0x13,0xb0,0xc8,
+  0xb0,0xaf,0x24,0x27,0xd0,0xe1,0x89,0xba,0x69,0x61,0xff,0x2b,0xcf,0x87,0xae,0xea,
+  0x13,0x5d,0x4e,0x2d,0x09,0x4e,0x2d,0x96,0xf0,0xf5,0xf6,0xfa,0x8a,0x49,0x69,0xf9,
+  0x7f,0xdd,0xae,0xa4,0xaf,0x1a,0x98,0xd2,0x77,0x41,0x60,0x9b,0x07,0x69,0x2a,0x9c,
+  0x28,0x76,0xf6,0x10,0x3f,0xd6,0x90,0xed,0x07,0x52,0x04,0xa5,0x94,0x33,0xa4,0x49,
+  0x85,0x34,0xfb,0x9e,0x61,0x6d,0xf2,0xfc,0xf2,0xfa,0x74,0xbd,0x14,0x73,0x43,0x29,
+  0x8d,0xe3,0x44,0x25,0x8c,0xdd,0x2e,0xd5,0x20,0xf2,0xfe,0xa5,0x07,0xb1,0xd1,0x1d,
+  0x43,0x36,0x5a,0x97,0xe9,0xca,0x1c,0xad,0x24,0xc2,0x54,0x49,0x62,0xf4,0xaf,0xf4,
+  0x92,0xcd,0x9d,0xd0,0x91,0x8f,0xaa,0x3e,0x21,0x74,0xf2,0x6a,0x75,0x72,0xc1,0xf8,
+  0x57,0xae,0x8a,0x61,0x6f,0x38,0xe0,0x8f,0xce,0x32,0x5e,0xc6,0xbe,0x85,0x75,0x15,
+  0x93,0x14,0xcb,0xa3,0x29,0xfb,0xce,0x06,0xaa,0x19,0xc6,0xc9,0x0c,0x74,0x27,0x42,
+  0xbd,0x62,0x34,0x78,0xea,0x92,0xee,0x97,0x1e,0x40,0x09,0x94,0x8d,0x21,0x93,0xa9,
+  0x8c,0xf0,0x51,0xc1,0xb1,0xed,0x7c,0x6e,0x3d,0x05,0xbb,0x2a,0x26,0x7a,0x8d,0xe1,
+  0xe7,0x1b,0xcf,0x11,0xd5,0x03,0x27,0x3f,0xb8,0x3e,0xfb,0x9b,0x91,0x3f,0xb7,0x46,
+  0x1c,0xb1,0xe1,0x92,0xaf,0x82,0x27,0x2f,0xa7,0x4c,0x40,0x59,0x5f,0x5a,0x5a,0xba,
+  0xb5,0x64,0x39,0x5f,0x75,0x62,0xed,0x27,0x5b,0x1f,0x54,0x2f,0x91,0x53,0xcd,0x85,
+  0x37,0xe6,0x26,0xdf,0xda,0x63,0xa5,0xdc,0xe9,0xfc,0xa2,0xfe,0x57,0x8a,0xb3,0xcc,
+  0x0c,0x9e,0x38,0x1d,0xe0,0x64,0x06,0xa5,0x49,0x3a,0x5e,0x6a,0xae,0xa7,0x98,0x9a,
+  0x1f,0xef,0xce,0x76,0xe8,0x46,0x2b,0x07,0x6c,0xe0,0x8d,0xc9,0xcb,0xd7,0x3f,0x38,
+  0x79,0xb0,0x4a,0x6f,0x64,0xd5,0x6f,0xa2,0x76,0x47,0x1f,0xcc,0x71,0xc8,0xca,0x99,
+  0x20,0x6b,0x8a,0xdb,0x5a,0xe4,0x44,0xf8,0xa2,0x12,0xaf,0xb0,0xe7,0xd7,0x3c,0xf3,
+  0xd3,0x94,0xb2,0x31,0x42,0xa6,0x53,0xfc,0xd1,0xaa,0xba,0xc7,0x91,0x79,0xd1,0x6a,
+  0x8b,0x55,0x29,0x96,0xc6,0x9f,0x08,0x79,0x85,0x9e,0x45,0xbb,0xea,0xbe,0x0f,0xd2,
+  0xb7,0x14,0x4a,0x21,0x29,0x93,0x2c,0xfe,0x68,0xcf,0x71,0x5a,0x79,0xb4,0x73,0x8c,
+  0xbe,0x59,0x90,0xed,0x55,0x35,0x08,0x97,0xf4,0x23,0x9a,0x03,0x5c,0x7c,0x67,0x27,
+  0xd1,0xed,0xf1,0xd5,0xdb,0x64,0xae,0x0e,0x91,0x8d,0x27,0x78,0xf1,0x54,0x0a,0xf7,
+  0xc7,0x6a,0x51,0xf7,0x3e,0xbb,0x76,0x33,0xb9,0x29,0x2f,0x0c,0xc4,0xe9,0x75,0x02,
+  0x9d,0x08,0x18,0x7f,0x98,0xf1,0x1d,0x67,0x1a,0x2d,0xd1,0x6e,0x35,0xa5,0x58,0x78,
+  0x29,0x5d,0x88,0x26,0xe3,0x5c,0x69,0xf5,0x97,0xea,0xeb,0x92,0xf9,0xcd,0x81,0x6c,
+  0x0c,0x30,0xaf,0xf4,0x78,0x46,0xf8,0x12,0xa7,0x67,0xf2,0xf7,0xb0,0x7a,0x7e,0xad,
+  0x5d,0x8b,0x5c,0x5d,0xdc,0x43,0x34,0x11,0xb7,0xae,0xb3,0x58,0xe0,0x07,0x2e,0x39,
+  0x5d,0xd3,0x5c,0x7a,0xc1,0x77,0x7c,0xd3,0xb1,0x50,0xd8,0x3b,0x51,0x3a,0xd9,0x34,
+  0xc7,0xec,0xa9,0x19,0xf5,0xc7,0x83,0xca,0xd5,0xa2,0xe6,0xd2,0x6c,0x37,0x8e,0x3f,
+  0xea,0x3c,0x86,0xd1,0x67,0x81,0xfe,0x13,0xe3,0xa4,0x48,0x9c,0xa4,0xd0,0xb1,0x54,
+  0x2a,0xa2,0xb5,0xcf,0xc2,0x49,0x31,0x51,0x73,0x96,0x9e,0x5f,0x1b,0x6a,0xff,0x17,
+  0x75,0xd7,0x24,0xc4,0x74,0x2d,0x4e,0x45,0x40,0x6e,0x68,0x47,0xe1,0xbb,0x6e,0x3d,
+  0x78,0x53,0x72,0xe2,0x44,0xe2,0xf6,0xa3,0xae,0x0c,0x7f,0x0e,0x98,0x9b,0xe2,0x48,
+  0x32,0x3b,0x2c,0xd6,0x98,0xcd,0x95,0x7f,0x1b,0x70,0xd7,0xb9,0x22,0x8d,0x5b,0x6e,
+  0xf7,0xee,0xdf,0x4b,0x57,0xb0,0x52,0x8a,0xb1,0x6a,0x56,0xf3,0x25,0xf7,0x55,0xc3,
+  0xee,0x52,0xf9,0xab,0x90,0x04,0x7a,0x52,0x12,0x45,0x51,0x28,0x7f,0xda,0xdd,0x7b,
+  0x79,0xc8,0xaf,0xf9,0x02,0xfb,0xef,0x66,0xbf,0xd2,0xfc,0xd6,0xe1,0x9d,0x4a,0x1f,
+  0x0d,0x6c,0x69,0xb2,0x99,0xb5,0xf6,0x12,0xcb,0xc7,0x2a,0xc6,0xc0,0x73,0x7a,0xcd,
+  0xcc,0xde,0xb0,0x77,0x49,0xb7,0xda,0x94,0xcd,0x85,0xa1,0x8a,0x57,0x4a,0xa4,0xc1,
+  0x85,0x7c,0x70,0xe1,0x41,0xd3,0x80,0x32,0xf2,0xe9,0x67,0xfb,0x2f,0xa3,0x3d,0xa2,
+  0xaf,0x46,0x76,0xd0,0x52,0x09,0xd8,0xe4,0x5a,0x32,0xa9,0x3a,0xc6,0x0b,0x35,0x6e,
+  0x86,0x98,0x9e,0xb3,0x2c,0x8a,0x7c,0x57,0x83,0xcc,0xe5,0xa9,0xee,0x55,0xb4,0x4e,
+  0xb2,0x8c,0xe6,0x63,0x66,0xea,0xb3,0xe7,0x68,0x89,0x75,0x33,0xeb,0x52,0x1d,0xa6,
+  0x84,0x4f,0xc7,0x77,0xb5,0xe8,0x4a,0x25,0xfd,0xab,0xf2,0xe6,0x4e,0xe3,0xad,0x89,
+  0x92,0x96,0xab,0xff,0x84,0x7c,0xc3,0x17,0x6c,0x9e,0x0e,0xd4,0x67,0xef,0xaf,0x88,
+  0x9d,0xa2,0x06,0x37,0x3b,0xff,0x63,0x4d,0xb2,0x20,0xc5,0xc1,0x90,0xa5,0xa4,0xd8,
+  0xf4,0xf4,0x2c,0x2e,0x6b,0x22,0x54,0x42,0xfe,0x7e,0x90,0x78,0x90,0x38,0xc9,0xb3,
+  0x9e,0x1e,0xe8,0x5f,0xc8,0x37,0x1f,0x36,0x2b,0xad,0xf6,0x51,0xaa,0x95,0xb8,0x27,
+  0x7c,0xc9,0x1f,0x7a,0xb6,0xde,0x9c,0x32,0x23,0xb0,0xf8,0x8f,0x3b,0xea,0x6b,0x28,
+  0x59,0x29,0x17,0xfb,0x73,0x5d,0xc2,0xba,0xb6,0x78,0xb8,0xfd,0x7a,0x5a,0x3d,0x48,
+  0x31,0x12,0xfa,0x0d,0x81,0xb4,0x6d,0x55,0x11,0xc5,0x13,0x13,0x46,0xff,0x71,0x92,
+  0x76,0xa2,0xcd,0xaf,0x96,0x25,0x53,0xb4,0x6f,0x3c,0x6d,0xee,0xa2,0x6b,0xf1,0xf1,
+  0x1c,0xb3,0x4d,0xca,0x8f,0x6b,0xdd,0xf9,0x63,0x5f,0x12,0x8c,0x35,0x86,0x7c,0xc3,
+  0xf9,0x9f,0xd6,0x62,0x01,0xca,0xe6,0xb8,0xeb,0xc6,0x5d,0x6f,0x1e,0x1f,0x85,0xec,
+  0x55,0xa1,0x6c,0x5c,0x8f,0x95,0xf9,0xa8,0xb3,0x4e,0x4f,0x98,0x26,0xee,0x8b,0xe1,
+  0x0d,0x4f,0x90,0xde,0x17,0xe4,0x7c,0x6f,0x40,0x73,0x91,0x12,0xbe,0xb8,0x0e,0xc7,
+  0xa5,0x78,0x96,0x9b,0xe3,0xe8,0xcc,0x7f,0x5c,0x4b,0x07,0xdc,0xd8,0x1b,0x79,0x55,
+  0x88,0xd4,0x11,0x8b,0xb2,0x77,0x36,0xe3,0xd6,0x13,0xb2,0xbe,0x27,0x74,0x86,0x5c,
+  0xaa,0x6d,0x87,0x7d,0xf3,0x85,0x37,0x9d,0x73,0x2a,0x23,0xe3,0x1b,0x66,0x25,0xf6,
+  0x5f,0x52,0x06,0x97,0x6b,0x64,0x7e,0x2b,0xb7,0xff,0x6d,0x1e,0xb6,0x91,0x73,0x3b,
+  0xad,0xe7,0x4f,0x1f,0x07,0x03,0xb7,0xda,0x33,0xe4,0x24,0x75,0xf3,0x81,0xfa,0x1a,
+  0x24,0x41,0x5e,0xee,0xf5,0x92,0xeb,0x75,0xf1,0xe1,0xce,0xdb,0xe9,0xa4,0x2b,0x9b,
+  0x65,0x9a,0xf1,0x3f,0x8b,0xcf,0xf5,0x84,0x2f,0xd6,0xa2,0x47,0x1e,0x24,0x13,0x50,
+  0x8a,0x97,0xfc,0x9a,0xe3,0xa9,0x7a,0xd7,0xdf,0x3f,0x79,0xbb,0x2d,0x3e,0x24,0xfa,
+  0x50,0xfd,0xb1,0xef,0x56,0xe7,0x75,0x30,0x62,0xd4,0xac,0x72,0xf1,0x4d,0xa6,0x58,
+  0xb8,0x46,0xf5,0x10,0x36,0x73,0xc9,0xbf,0xbb,0xee,0xd9,0x17,0x23,0x2d,0x94,0x83,
+  0xb7,0xda,0x05,0x82,0x94,0xd2,0x7f,0xb6,0x47,0x4c,0x64,0xb9,0x5c,0xfe,0x9a,0x32,
+  0x9a,0x4e,0x36,0x57,0xe7,0xf5,0xbf,0x62,0x8e,0x39,0x09,0x4f,0x69,0x3d,0xeb,0x29,
+  0x3e,0xad,0x2c,0x88,0xe7,0x38,0x4d,0x72,0xcf,0xaf,0x3a,0xc9,0x82,0x4a,0x57,0x7d,
+  0x28,0x8e,0x82,0x2e,0x6b,0x30,0xfd,0xd1,0xc3,0xec,0x52,0x36,0x06,0x35,0x80,0x3f,
+  0x14,0x92,0x06,0x47,0x8b,0x4a,0xd7,0xda,0xc4,0x6a,0xce,0x8d,0x36,0x29,0xf2,0x12,
+  0xeb,0xce,0xf1,0x1e,0x50,0x6d,0x18,0x56,0xcf,0xb6,0x54,0x27,0x71,0xd0,0x0d,0x46,
+  0xf5,0xb7,0x6f,0xe4,0x48,0x8f,0x47,0x53,0xce,0x54,0x2b,0xfe,0x44,0x26,0xd5,0xab,
+  0x03,0x4b,0xb9,0x97,0x8b,0x11,0x57,0xb0,0x21,0x51,0x32,0xb1,0x6f,0xe2,0xa5,0x4c,
+  0x5f,0x94,0x10,0xc9,0x5f,0x98,0x49,0xba,0xf9,0xec,0xa4,0xff,0x9a,0x8d,0x1d,0x6e,
+  0x54,0x9e,0xa7,0xff,0xc4,0x5e,0x2b,0x54,0x39,0x7d,0x65,0x9c,0xb5,0xc1,0x65,0x75,
+  0xde,0x2c,0x6d,0xc7,0x8c,0xd7,0x6e,0x74,0xe8,0x0b,0x95,0x8d,0xfc,0x9a,0x6d,0x95,
+  0x36,0xd1,0xb6,0x3e,0xc2,0x91,0xdc,0x61,0xbf,0xfc,0xa8,0xe6,0x8d,0x51,0x88,0xe3,
+  0x91,0xf1,0x6a,0xdf,0x5c,0xfb,0x81,0x91,0x40,0xf1,0x57,0xa1,0xad,0x28,0x32,0xb3,
+  0x6e,0x65,0x45,0x67,0x50,0xaf,0x39,0x5d,0x95,0xf3,0x55,0xaf,0x95,0x15,0xdb,0xf4,
+  0x86,0xfa,0x8e,0xf4,0xc4,0x39,0x77,0x02,0x52,0x79,0x27,0x5f,0xfc,0xda,0xbf,0xeb,
+  0x23,0xe7,0xa6,0x14,0x0d,0x0f,0x7e,0x9b,0xaf,0x74,0xe5,0x6c,0x4a,0x15,0xa5,0x5c,
+  0x13,0x1d,0xd2,0xaa,0x9a,0xd2,0x49,0x27,0x01,0x59,0xfd,0x27,0xdb,0xef,0x15,0xa4,
+  0xc9,0x0a,0x9f,0x62,0x4a,0xdd,0xa4,0x25,0x0f,0xd3,0xbf,0x2b,0xeb,0xad,0xd3,0x2c,
+  0x5c,0x6b,0x96,0x73,0xa7,0xfe,0xa8,0xdb,0x41,0x07,0x03,0x05,0xfe,0x14,0x79,0x2c,
+  0xe3,0x53,0xb0,0xc3,0xef,0x80,0xed,0x79,0x50,0x7a,0x60,0xd9,0x3e,0xc7,0x69,0x7b,
+  0x4d,0x09,0x5f,0xfc,0x55,0xe5,0x5f,0xb5,0xc3,0xb6,0xdd,0x1e,0xe1,0x4e,0xc1,0xa8,
+  0xed,0xa5,0x9c,0x59,0x59,0x1a,0xb5,0x98,0xd0,0x9a,0xd5,0x17,0x0a,0x73,0x97,0x90,
+  0x0d,0x34,0x72,0xaf,0x96,0x6d,0xf1,0x46,0x4f,0x95,0xce,0xb0,0x52,0x6d,0xc3,0x82,
+  0x5d,0x05,0x63,0x60,0xad,0xff,0xb8,0x9f,0x01,0x2a,0x31,0xa5,0xe3,0x0f,0x9d,0x37,
+  0x71,0xcd,0xd5,0x7e,0xd6,0xff,0x2c,0xc5,0x90,0x89,0x96,0xaa,0x3e,0xbf,0xe3,0xdb,
+  0xb3,0x12,0x9d,0xfa,0x51,0xaf,0x73,0x23,0xab,0xbf,0x54,0x17,0x3a,0x88,0xbe,0xd8,
+  0x13,0x64,0x1e,0x72,0x60,0xd6,0x58,0x9e,0x68,0xe6,0x6a,0xee,0xa6,0x5c,0xac,0x11,
+  0x9f,0x82,0xb5,0x41,0x79,0xb2,0x3a,0x7a,0xe6,0x01,0x59,0x0d,0x23,0x1b,0x4f,0xd2,
+  0xfa,0xf2,0x17,0xe1,0x99,0xfa,0x7f,0x21,0xae,0x73,0xb1,0x58,0x33,0x85,0x1a,0x17,
+  0x70,0xb9,0x7b,0x5f,0x2e,0x0d,0xb8,0x28,0xa9,0xe5,0x14,0x5f,0x3c,0x52,0x30,0x83,
+  0xd2,0x6c,0xcf,0x06,0xd5,0x8c,0x39,0xe0,0x22,0x99,0xca,0xbd,0xa9,0x9c,0x63,0x44,
+  0xde,0xa8,0xe6,0x8b,0x22,0xea,0x34,0xfe,0x50,0xdd,0x95,0xd8,0x65,0x6f,0x93,0xd1,
+  0x7f,0x52,0x4c,0xd2,0x86,0xe4,0x8f,0x15,0x6c,0xdb,0xbd,0xa4,0x6f,0xd1,0x94,0xe2,
+  0x97,0x64,0xb4,0x1f,0x32,0x7e,0xb0,0x7c,0x4e,0x4c,0x4e,0x5a,0xf3,0xd8,0x77,0xea,
+  0xc4,0xf7,0xb8,0x51,0x74,0x59,0xf3,0xb0,0x97,0x8c,0x54,0x71,0x0d,0x8b,0x07,0x63,
+  0x04,0x2c,0x27,0xf4,0x0a,0x46,0x6f,0x09,0x5d,0x26,0x43,0xbd,0xa6,0x05,0x8b,0x31,
+  0xd3,0x32,0xe3,0x82,0xdf,0x5b,0x6a,0x64,0x88,0x31,0xe7,0xad,0x35,0x03,0x69,0xdb,
+  0x67,0x84,0xec,0x82,0x9e,0x01,0xcb,0xbf,0x70,0x90,0x34,0x07,0x67,0x91,0x27,0x09,
+  0xdb,0xd1,0xc8,0xbd,0xc8,0xd9,0x7f,0x3c,0x2d,0x7c,0x6b,0xb0,0xff,0x74,0x49,0xbc,
+  0xd1,0x63,0xd4,0x59,0xc6,0xfe,0x13,0xf5,0xed,0x3c,0xd5,0xb5,0x73,0x17,0x24,0x19,
+  0x7a,0x21,0x76,0xd1,0xc9,0xe6,0x52,0x8d,0x2e,0xfb,0x67,0x95,0x8b,0xa5,0xb7,0x5e,
+  0x1a,0xe0,0x79,0xee,0x87,0x24,0xf6,0xbd,0x45,0x4d,0xbc,0x29,0x2f,0x55,0x79,0x95,
+  0xae,0xbf,0x31,0x5d,0x44,0x54,0x00,0x3d,0x93,0x7f,0x82,0x07,0xf0,0xee,0x01,0xb7,
+  0xfb,0x8d,0x34,0x59,0x05,0x43,0x85,0x2f,0xca,0xdc,0x51,0x53,0x1d,0x4a,0xa3,0x71,
+  0x57,0x3a,0xea,0xa4,0xf7,0xcb,0x5c,0xed,0xb7,0xcd,0x2a,0x5e,0xab,0x8e,0x48,0xd1,
+  0xb2,0x81,0xe5,0x62,0x89,0x78,0x23,0xb5,0x4c,0x95,0xa6,0xaf,0x87,0x9f,0xcb,0x5d,
+  0x7d,0x38,0xcb,0xb2,0x67,0x13,0x4b,0xa2,0xb3,0xfc,0xad,0xfe,0xda,0x9e,0xed,0xeb,
+  0x3f,0x75,0xa1,0x7c,0x3b,0xa7,0x6b,0x4f,0xb9,0xaa,0xd8,0x42,0x7c,0xb6,0xea,0x2f,
+  0xc7,0xe8,0x9f,0x2b,0xe1,0xee,0x62,0x63,0x4c,0x9f,0x9c,0xac,0x6d,0x31,0x31,0xf9,
+  0xeb,0x2e,0x26,0x0a,0x92,0xad,0x5a,0xbe,0x48,0xad,0x29,0xf2,0x6a,0xb0,0x7b,0xe8,
+  0x81,0xb0,0x00,0x57,0x8f,0x07,0x4e,0x57,0xa4,0x84,0xcf,0xc8,0x60,0xcd,0x75,0x01,
+  0x72,0xa2,0xe2,0xe9,0x97,0xa1,0xe5,0x92,0x5a,0x9d,0xf6,0x2c,0xc9,0x44,0x10,0xed,
+  0x88,0xf1,0x95,0xe2,0x0b,0x5b,0x97,0x9c,0x06,0x70,0x46,0x8d,0x19,0xdc,0x05,0x07,
+  0xf3,0x06,0x94,0xd2,0xcd,0xff,0xe6,0x38,0xd1,0x3b,0xfa,0xff,0xf4,0xf0,0xea,0x43,
+  0x9b,0xca,0x94,0xff,0xb9,0x29,0x6f,0xd6,0x3c,0xe5,0x92,0x09,0xf4,0x04,0xe5,0x51,
+  0x7b,0x03,0x59,0x7f,0xdc,0x24,0x3c,0xf2,0x5a,0x56,0xa7,0x0b,0x75,0x91,0x94,0xcd,
+  0x21,0xaa,0xea,0x19,0x15,0x3e,0x9d,0x85,0xeb,0xc5,0x29,0x96,0x63,0x46,0x6f,0x72,
+  0x7f,0xf8,0x1b,0xe5,0xba,0x7a,0xf9,0x01,0x30,0x00,0x5b,0xbf,0xaf,0x71,0x3a,0x2e,
+  0xf0,0xb2,0x60,0x3a,0x4e,0xb7,0x8e,0x5c,0xae,0x34,0x86,0x9c,0xb2,0x54,0x65,0xfe,
+  0xd0,0x99,0x02,0x6f,0x88,0x42,0xbc,0x1c,0x2f,0xec,0x63,0x8c,0x0a,0x9f,0xb9,0x38,
+  0x9c,0x28,0xee,0x1f,0x64,0xbd,0x46,0x2a,0x21,0x1d,0xf0,0xc7,0x6e,0xe5,0xc9,0x92,
+  0x9d,0xff,0x65,0x24,0x81,0x64,0xfc,0xdb,0xb9,0xff,0xbd,0x6a,0xaf,0x4c,0xf5,0xbf,
+  0xb2,0x79,0xac,0x70,0xc9,0x5d,0x12,0x04,0xac,0x76,0xc3,0x5d,0xb4,0x32,0x69,0xfe,
+  0x18,0x44,0x02,0x32,0x98,0x3f,0xd4,0x6a,0x6b,0xd1,0x9e,0x8f,0xce,0xf1,0x54,0x29,
+  0x69,0x3f,0x03,0x25,0x5a,0xac,0x35,0x93,0xb7,0x5a,0x32,0xb9,0x3c,0x64,0x6f,0x75,
+  0xc8,0xef,0x26,0x40,0x8a,0x5f,0xd8,0x64,0xa7,0xd7,0x55,0x1a,0x67,0x5d,0xb0,0xdd,
+  0xb3,0xb7,0xa6,0x9c,0xbf,0x4b,0x17,0xd0,0x8f,0x8b,0x66,0xe1,0x64,0xb3,0x5e,0xf3,
+  0x9c,0x2e,0xae,0x77,0x88,0x84,0xbc,0x72,0xa9,0x2c,0x5d,0xcf,0xbb,0xc7,0x39,0x3c,
+  0x4f,0x5b,0xec,0xb8,0x39,0x9b,0x37,0xee,0xb6,0xf6,0x9f,0x3f,0x85,0x6f,0x3e,0x3b,
+  0xca,0x9f,0x1a,0x50,0x56,0x8d,0x19,0x9c,0xea,0x7f,0xe5,0x47,0x8f,0x38,0xe3,0x35,
+  0x33,0xeb,0x9b,0xa4,0xcb,0x7b,0xda,0x43,0x0c,0xf9,0x73,0x63,0x13,0x45,0xcd,0x54,
+  0x46,0x7d,0xb5,0x3f,0x61,0x4d,0x4c,0x95,0x9e,0x7d,0x25,0x53,0xb9,0xf2,0x7a,0x85,
+  0x79,0x7d,0x04,0xb1,0xb0,0xf5,0xa2,0xf1,0x07,0xa0,0x03,0x9e,0xaf,0x9a,0x32,0x32,
+  0x99,0xe6,0xee,0x28,0x96,0x1e,0x7f,0xa1,0x41,0x33,0x72,0x16,0xd8,0x02,0x0a,0xab,
+  0x63,0x85,0x05,0x3b,0x45,0x84,0x8f,0xf4,0x0e,0xe6,0xda,0x7c,0xe7,0x73,0x7c,0x13,
+  0xf9,0x0f,0x44,0x09,0xa7,0xdb,0x37,0x67,0x07,0xf2,0x2e,0xcd,0xd1,0x7f,0x74,0x16,
+  0x64,0x0d,0xfa,0xef,0xfa,0xc3,0xe6,0x42,0x5f,0xff,0x49,0x71,0x38,0x24,0x71,0xe6,
+  0x69,0x9c,0x6a,0xc5,0x9b,0x67,0x93,0xcd,0x0f,0x48,0x47,0xaa,0x94,0x51,0x7f,0x66,
+  0x0a,0xcd,0x9e,0xb9,0x93,0x34,0x78,0x4f,0x13,0x44,0x05,0x37,0x5a,0x96,0x6a,0xf1,
+  0xc3,0xa2,0xf4,0x44,0x9f,0xb3,0x1d,0x32,0x7c,0xff,0xd1,0x33,0x1a,0xb4,0x9f,0xe3,
+  0xa9,0x3c,0x68,0x81,0x79,0x5a,0x78,0xee,0x03,0x79,0xd1,0x77,0x7e,0xf5,0xdd,0xcc,
+  0xaf,0x58,0x21,0x47,0x2b,0xd9,0x27,0xe8,0xb8,0xf5,0xe9,0x6c,0x2b,0xee,0xb8,0xf5,
+  0x63,0x16,0xf6,0x12,0xeb,0x49,0x23,0x9a,0xa1,0x96,0xa7,0x13,0x8c,0xfe,0xe3,0x9e,
+  0xd8,0xad,0x53,0xff,0x25,0x57,0x10,0xd5,0xa1,0x9f,0x98,0xbf,0xd4,0x5b,0x89,0xf3,
+  0x40,0x2c,0x4b,0x3f,0x60,0xfc,0x37,0x44,0x64,0x95,0xce,0x12,0xcf,0xb9,0x8e,0x54,
+  0x27,0x5c,0xc9,0x51,0x7e,0x7e,0x6f,0xb9,0xb1,0x2b,0x75,0x10,0x98,0xb4,0x9f,0x2d,
+  0x2b,0xa6,0x95,0x7d,0xdd,0x8c,0xf4,0x11,0x69,0x6f,0xe9,0x44,0x79,0x86,0xef,0x3f,
+  0x49,0x35,0xdb,0xb1,0xbe,0x13,0x42,0xa3,0xc5,0x15,0x1f,0xa4,0x0a,0x40,0xbc,0xc0,
+  0xb6,0xb8,0x46,0xc6,0x83,0x63,0x05,0xde,0x2d,0xf9,0x32,0x1d,0x2b,0xfa,0xcf,0x04,
+  0xa9,0x60,0xb8,0x64,0x56,0x40,0xb6,0xe7,0x49,0x1a,0x7c,0xf3,0x20,0xfa,0x2a,0xaf,
+  0xd3,0x37,0xfe,0x3f,0x1a,0x38,0xa7,0x44,0xe7,0xf1,0x47,0xbb,0x1d,0xe9,0xbf,0xe8,
+  0xca,0x41,0x92,0x27,0xa9,0x67,0xde,0x4c,0x63,0x2c,0xd0,0x34,0x01,0xdf,0xb9,0x9c,
+  0xca,0xc2,0x2c,0xab,0x90,0x16,0x10,0xd4,0x16,0xf3,0x9d,0x4d,0x72,0xc1,0xd7,0x00,
+  0xcc,0x0a,0x5f,0x6c,0x6a,0x7c,0x50,0x36,0x79,0x22,0x5f,0x28,0xea,0x23,0xa2,0x9c,
+  0x8f,0x75,0xca,0xf0,0xfd,0x46,0x3c,0x4b,0x47,0xfc,0xe9,0x1a,0x8f,0x67,0x39,0xfe,
+  0x3a,0x95,0xff,0x55,0x39,0xff,0x08,0x5d,0xfa,0x13,0xf4,0x16,0xbc,0xa8,0x45,0x3c,
+  0x47,0xcd,0x37,0x57,0x2a,0x71,0xc4,0x95,0xe7,0x4a,0xc4,0x41,0xb6,0x17,0xfd,0x2b,
+  0x52,0x23,0xe8,0xca,0xb5,0x9c,0x8b,0xf2,0xec,0x3f,0xd2,0xa5,0xad,0xc1,0xff,0x52,
+  0x3f,0x77,0x6e,0x2a,0xfe,0x37,0x43,0x32,0x2d,0xe4,0x4c,0xd5,0xb3,0x46,0x49,0xe0,
+  0xf4,0xfb,0x4c,0x6a,0x34,0x25,0xc4,0x61,0x2b,0x4a,0x91,0xe0,0x8e,0xe4,0xcb,0xd1,
+  0xea,0x79,0xd3,0xaa,0xe8,0xcc,0xba,0xab,0x8f,0xd9,0x32,0xdf,0xb5,0x1c,0xe9,0x31,
+  0xe9,0x22,0x5a,0xc3,0xa6,0xeb,0x48,0x87,0x0c,0xdf,0x67,0xa4,0x98,0xa6,0xb9,0x4d,
+  0x75,0xc3,0x89,0x4f,0xf4,0x91,0xb9,0x94,0xfa,0x53,0xea,0xe0,0x28,0xa7,0xd7,0xf0,
+  0x83,0xf9,0x4d,0x54,0x6e,0x27,0xad,0xd1,0x0d,0x22,0x8c,0x4c,0x1d,0x2c,0x29,0x57,
+  0xd1,0xbe,0xcd,0xa8,0x04,0x11,0x83,0x5c,0xef,0x76,0xf3,0x8b,0x39,0x17,0xe5,0xda,
+  0x7f,0xce,0xea,0xec,0xdc,0xff,0x46,0x93,0xc0,0xd1,0x26,0x05,0x71,0x30,0xca,0xfa,
+  0x10,0x4f,0x3d,0x63,0xe4,0x8d,0xb1,0xa3,0xd1,0x6f,0x7a,0xba,0xb5,0xa5,0x46,0xd3,
+  0x35,0x62,0x34,0xaa,0xdd,0xf9,0xfc,0x69,0x9b,0xc9,0xec,0x62,0x09,0x6a,0x2c,0xcf,
+  0x97,0x24,0xbb,0x29,0x47,0xbb,0xbd,0x36,0xe6,0x05,0x9c,0xed,0x2b,0xcf,0xf0,0xfd,
+  0xa6,0x55,0x7f,0x92,0xe6,0x97,0xda,0x67,0xe6,0x28,0x7f,0xf2,0xfc,0x46,0x9f,0xeb,
+  0xad,0x55,0x50,0xcd,0x93,0x86,0xb6,0x6c,0x6c,0xf5,0x1e,0x46,0xf3,0xfb,0xe1,0x80,
+  0xfd,0x6d,0x99,0x7b,0x5e,0xd6,0xfb,0x32,0xb6,0x38,0x35,0xe8,0xa6,0x4a,0xc6,0xbf,
+  0xbe,0x79,0x6a,0xac,0x84,0x35,0xe8,0xbf,0x7c,0x56,0xe5,0x24,0x91,0x0b,0x5f,0x05,
+  0x5a,0x57,0x40,0x30,0x9b,0x5d,0xb0,0xd0,0xfc,0xa5,0x37,0x6c,0xe7,0xe9,0x8e,0x24,
+  0x39,0x6d,0x2c,0x35,0x7e,0x4d,0xcd,0xf0,0x2d,0x96,0x16,0xd3,0x18,0x6d,0x63,0xb6,
+  0x8b,0x30,0x25,0xf5,0x17,0x1b,0xca,0xf0,0x3d,0x43,0x4c,0xb8,0x15,0x4b,0xe9,0x67,
+  0x68,0x4c,0x36,0x6a,0x8b,0x39,0xa5,0xb6,0x12,0xbb,0xf7,0xad,0x9b,0x3a,0xf7,0x21,
+  0x1b,0x29,0x6a,0x5e,0xc7,0x4b,0xba,0x79,0x7d,0x50,0x79,0xa5,0x74,0x60,0x57,0xef,
+  0x73,0xc2,0x94,0xd2,0x0f,0xfa,0xab,0x5c,0xf9,0xcb,0xea,0x26,0xd2,0xfd,0xad,0xc5,
+  0xfe,0xcb,0x25,0x99,0xf2,0xc9,0x9b,0x8c,0x36,0xe6,0xc4,0x9f,0xb1,0x17,0xf3,0xba,
+  0x80,0x1b,0x35,0x72,0xb2,0x4a,0x49,0xee,0x7b,0x13,0x57,0xc7,0xb3,0xfa,0x8f,0xae,
+  0x22,0x2b,0x7a,0xfb,0x4d,0x94,0x34,0x31,0xe6,0xab,0x65,0xda,0xd0,0x55,0xf0,0xf4,
+  0x86,0x32,0x7c,0xaf,0x50,0x05,0x5b,0x09,0xb3,0x09,0xf7,0x6c,0xe1,0xf0,0x78,0xde,
+  0xeb,0xa7,0xa2,0x75,0x05,0xa1,0x2d,0xa2,0x90,0xcd,0xe4,0x2c,0xf7,0x96,0xab,0x3b,
+  0xad,0xb8,0x38,0xab,0xd2,0x69,0xa5,0x17,0x4a,0xed,0xbf,0x25,0xe6,0xa5,0xc8,0x9a,
+  0x59,0x89,0x3c,0xe6,0xf9,0x0e,0xcd,0xfa,0x17,0xee,0x29,0xaa,0x75,0xd8,0x7f,0xf9,
+  0x29,0x69,0x1e,0xe7,0xcc,0x3e,0x89,0x9b,0x5a,0xf4,0x6c,0xfa,0x80,0xde,0x85,0xbc,
+  0xc8,0xa3,0xa7,0xe5,0xac,0x66,0x2a,0x78,0x6f,0xa2,0x98,0x0a,0x7d,0xfb,0x8f,0xce,
+  0xf3,0xa9,0xfd,0xf9,0xb2,0x54,0xcb,0xd7,0xc9,0x1d,0x78,0x26,0x8d,0x9b,0xbb,0xff,
+  0x15,0xe6,0xfd,0x29,0x64,0xdc,0x9b,0x1a,0x88,0xf0,0x81,0x5b,0x79,0x57,0xb6,0xe4,
+  0x84,0x2b,0x22,0x7d,0xc5,0xce,0xdc,0x67,0xe1,0xcc,0x0b,0x3d,0x8c,0x18,0x70,0x4f,
+  0x2b,0x3d,0x57,0x92,0x34,0xb9,0xba,0xe8,0x04,0x8e,0xd4,0x87,0x89,0xad,0xb2,0xb8,
+  0xe6,0xf1,0xaf,0xa9,0xd8,0x8d,0xe9,0xbf,0xd5,0xb6,0xb8,0xb1,0x35,0xcc,0xea,0x60,
+  0x1a,0x28,0xf1,0x1c,0xc9,0x77,0x12,0x37,0xb6,0xd3,0xd3,0x82,0xea,0xd9,0xbc,0x69,
+  0xeb,0x0b,0xd9,0x25,0x85,0x9c,0x7c,0x7e,0x58,0xda,0x4d,0x8c,0x14,0x18,0xa5,0xf1,
+  0xe7,0xc8,0xfa,0x33,0x7c,0x0f,0xb9,0x96,0x99,0xd2,0x24,0x26,0x5a,0x72,0xf4,0x9b,
+  0xfc,0x41,0x9b,0x6c,0x3c,0xe5,0x39,0xad,0x7a,0x26,0x72,0x9c,0x0b,0xf2,0x65,0xaa,
+  0xb9,0x9c,0xa9,0x94,0x0c,0x62,0x87,0xcb,0xdc,0x7f,0x91,0xff,0xc5,0x95,0xa9,0x91,
+  0x74,0xab,0xa6,0x73,0x06,0x85,0xb2,0xcc,0xfe,0xdb,0xb8,0xfe,0x13,0xc7,0xe8,0x92,
+  0x1a,0x9e,0x3b,0xce,0xec,0x2b,0x58,0x21,0xda,0x3a,0x4b,0x4c,0x3a,0x1e,0xf0,0xbc,
+  0x59,0xb8,0xd5,0x6b,0xcc,0x19,0xc5,0x4e,0x03,0x58,0x5f,0xcf,0xfb,0xa5,0xfa,0xef,
+  0x85,0x74,0x96,0xad,0x06,0xd5,0x3b,0x6f,0x6f,0x20,0xc3,0xf7,0x0a,0x29,0x5e,0xed,
+  0x76,0xf6,0x14,0xb3,0x7a,0xc9,0xeb,0x2e,0x87,0x1a,0xb9,0x8b,0x18,0xd5,0x20,0x71,
+  0x26,0xa0,0x4d,0x8e,0x0f,0x2c,0x65,0x4f,0x92,0x7f,0x4f,0x84,0xc7,0x13,0x86,0xe8,
+  0x9b,0xd2,0x57,0x2c,0x37,0x2f,0x32,0xbf,0x38,0xbd,0x34,0x56,0x1e,0xcf,0x9b,0x7f,
+  0xcb,0x5b,0xff,0x42,0x44,0x7e,0x43,0xf2,0xd7,0x94,0x0b,0xbd,0x41,0xda,0x3d,0x97,
+  0x09,0x8e,0x17,0x2c,0xf5,0x14,0xe2,0x2f,0x49,0x9b,0xe6,0xf9,0xef,0x4d,0xbc,0xdd,
+  0x9b,0x35,0x70,0x49,0x37,0x71,0xb6,0x6c,0xfc,0x21,0x9e,0xcf,0x7b,0xd2,0x20,0x89,
+  0x21,0x64,0x67,0xd7,0x9f,0xe1,0x7b,0x86,0x9c,0xfb,0x1e,0x15,0x3e,0x9e,0x36,0x5e,
+  0x75,0xb3,0xe5,0x33,0x85,0x2f,0x1c,0x10,0x7b,0xad,0x0e,0x88,0x64,0xe4,0x78,0x3b,
+  0xa3,0x01,0xc5,0x87,0x19,0xe1,0xb3,0x5e,0x05,0xfd,0x7d,0xd9,0x3b,0x04,0xe5,0xc9,
+  0x8a,0x5f,0x9c,0xbe,0xff,0x66,0x24,0x6f,0xd5,0x97,0x79,0xfe,0x2d,0xdf,0xfe,0xdb,
+  0xe0,0xf8,0x43,0xbc,0x68,0x6e,0x9b,0x5e,0xf1,0xe7,0xac,0xd1,0xed,0xb7,0x0b,0x17,
+  0xa1,0xbd,0xe7,0x8d,0xa1,0xc2,0xfe,0xa5,0x8c,0xd2,0x97,0xcd,0x3d,0xcc,0x59,0x7b,
+  0x46,0xf8,0xec,0x5d,0xca,0xe7,0xdf,0x56,0x7e,0x98,0x1a,0x36,0x5b,0x8b,0x25,0x8a,
+  0xa0,0x64,0xe9,0xcc,0x7d,0x47,0xec,0x73,0xba,0xce,0xf7,0xfc,0xd9,0x4e,0x93,0xef,
+  0x2d,0x9c,0xfb,0x91,0xf2,0x12,0xd5,0x01,0x21,0xaf,0xfd,0x2e,0x7b,0x4a,0x7d,0x80,
+  0xa8,0x20,0x2a,0xdc,0xb1,0x5f,0xec,0x52,0x49,0xcb,0x6e,0x3e,0x4f,0x9d,0x09,0xf4,
+  0x56,0x51,0x25,0xcd,0xe4,0x54,0x8a,0x2c,0xf4,0xff,0xc5,0xf7,0xdb,0x98,0xfd,0x77,
+  0x89,0xa7,0x62,0x4c,0x0d,0xd2,0xb4,0x78,0x4d,0x16,0x3f,0x85,0x20,0x0e,0xd8,0x12,
+  0xd0,0x89,0x78,0xe8,0xad,0xec,0x99,0xe2,0x64,0xd5,0x96,0x49,0xfa,0xe1,0x3a,0x65,
+  0x5a,0xee,0x2d,0x73,0x93,0x2e,0xc6,0xaf,0xf2,0xf2,0x46,0xcd,0xce,0x2c,0x7a,0x76,
+  0x13,0x2f,0x80,0x4e,0x66,0xde,0xb2,0x33,0xb3,0x2e,0x3b,0x0f,0x3d,0x32,0xd7,0x2c,
+  0x7a,0xd6,0xb1,0xbd,0x2a,0x0e,0x85,0x15,0x32,0x60,0x0b,0x72,0x1e,0xd2,0x12,0x47,
+  0x39,0x59,0xad,0xef,0x3f,0x2a,0xcd,0x82,0x9e,0x92,0xf5,0x57,0xed,0xc8,0xfd,0x42,
+  0xbd,0x0a,0x76,0x04,0xaa,0x3b,0x96,0xbe,0x7a,0x9e,0x5a,0xfe,0x3f,0xf0,0xff,0x49,
+  0xb1,0x27,0x6f,0xaa,0xd7,0xf8,0x5d,0xe2,0x76,0x34,0x5c,0xb8,0xb6,0x4a,0xf5,0x09,
+  0x73,0xbd,0x21,0x75,0x3b,0xd5,0x3e,0x4e,0x17,0x93,0xd4,0xab,0xbe,0xa8,0xfa,0xf3,
+  0x57,0x7f,0x04,0x65,0xeb,0xaf,0xe8,0x3b,0xf3,0x6c,0x14,0xa6,0xc1,0x84,0xfc,0xc4,
+  0xba,0xf3,0x7b,0xcf,0x90,0xcb,0xc3,0x4e,0x2b,0x65,0x47,0x1f,0x91,0x0a,0xe4,0x87,
+  0xcb,0xd6,0xef,0x88,0x8f,0xec,0x64,0x7d,0x14,0xf4,0x66,0x1e,0xb2,0x89,0x9f,0x18,
+  0xf3,0x5b,0x34,0xf1,0xf7,0x84,0x23,0x25,0xf2,0x77,0x91,0x75,0x53,0x55,0xec,0x39,
+  0x72,0x78,0xf8,0x62,0xee,0x35,0xb9,0xf6,0x9f,0xd3,0xee,0x1b,0x91,0x3f,0x31,0x5d,
+  0xe5,0xc4,0xd0,0xa5,0xc6,0x99,0xd1,0x83,0x8c,0xbd,0xb7,0x52,0x1c,0x81,0x14,0xaf,
+  0xc4,0x05,0x6a,0x0c,0xd1,0xc3,0x99,0x52,0x6a,0x36,0x87,0x83,0xac,0x92,0x75,0xd9,
+  0x2e,0x71,0x00,0xae,0x8e,0x25,0x4d,0xc0,0x1f,0x41,0x27,0x05,0x57,0x5d,0x58,0x77,
+  0x7e,0xef,0x19,0x7a,0x64,0x96,0x99,0x9b,0xf5,0x8e,0x18,0xeb,0xbd,0x56,0x52,0x61,
+  0xca,0xda,0x3b,0xca,0xac,0xbe,0xd1,0xa5,0xf0,0x42,0x56,0x5a,0xeb,0xb5,0xcc,0xb0,
+  0x8c,0x0c,0x89,0xfb,0x97,0x73,0xe2,0x8d,0x69,0x8e,0x6e,0x49,0x55,0x86,0x37,0x2c,
+  0x9a,0xca,0xbb,0x46,0x16,0xdb,0x7f,0x7c,0x83,0xf6,0x5f,0x6b,0x65,0x67,0xc8,0xd3,
+  0x33,0xbe,0x4e,0x97,0xc7,0xa2,0xb8,0xb7,0x6c,0x82,0x56,0xc8,0xeb,0x8f,0x6c,0xb1,
+  0x92,0xa5,0xa3,0x48,0xcf,0xc2,0x49,0xbd,0x00,0xd0,0x5f,0xba,0xe7,0x15,0x14,0x2f,
+  0x5a,0x7f,0xaf,0x58,0x1e,0x4a,0xbd,0x29,0xc0,0xd3,0x24,0xe9,0x15,0x11,0x9b,0x08,
+  0xd9,0x18,0xf4,0x5a,0x9c,0xd7,0xf7,0x26,0x43,0x85,0x60,0xb4,0xe4,0x01,0x3e,0x6d,
+  0x59,0x2c,0x6e,0x25,0x46,0x1d,0xaf,0xb0,0x8b,0xd9,0xe7,0x04,0x8f,0x9b,0xd7,0xdb,
+  0xa6,0xcd,0xa6,0x28,0xb8,0x58,0x78,0x03,0xb1,0xc3,0x89,0x9b,0x3f,0x2c,0xd2,0x5f,
+  0xee,0xc8,0x7f,0xaf,0x7c,0xb1,0xfd,0x17,0x3f,0xff,0xb1,0x7e,0xf5,0xd7,0x9c,0x48,
+  0x19,0xae,0xd9,0x20,0x64,0xb3,0xe5,0xef,0xfa,0x11,0xa3,0x5b,0xaa,0x56,0x30,0xd4,
+  0x15,0xfb,0xb2,0x13,0x75,0xf1,0x53,0x82,0x05,0xf6,0x65,0xb5,0xf0,0xf9,0x23,0xd9,
+  0xbe,0xe0,0x44,0xd5,0x4b,0x58,0xac,0x14,0xcf,0x6e,0xde,0xe5,0xa7,0x72,0x3c,0xb5,
+  0x54,0xcc,0x29,0x1a,0x13,0x84,0xfd,0x7f,0x28,0x7f,0xbb,0x81,0x14,0x63,0xa6,0xb1,
+  0xc6,0x31,0x3c,0x9b,0x51,0x04,0xad,0xa5,0xfe,0x9c,0xdb,0xd8,0x46,0xfa,0x5a,0xa1,
+  0xe6,0x98,0xf5,0xa6,0xa0,0xec,0xf5,0xc9,0x1a,0xbc,0x02,0x97,0x84,0x79,0xff,0x55,
+  0xc6,0xfe,0x8b,0x3f,0xcb,0x9f,0xff,0xcd,0xcb,0x60,0x7b,0xa9,0x7f,0x8b,0x6b,0x9c,
+  0x9c,0x28,0x19,0x66,0xa3,0x0f,0x0f,0x77,0x78,0xca,0x4c,0xde,0xec,0x7f,0x88,0xc8,
+  0x46,0xc8,0x3e,0xc8,0x88,0x6b,0x6b,0x32,0xe5,0x01,0xa4,0x96,0x50,0x95,0x2d,0x16,
+  0x44,0x2c,0x9a,0x87,0xe8,0xe0,0x8e,0x4e,0x23,0xeb,0xa3,0xe1,0xcd,0xab,0xfe,0xda,
+  0x37,0x33,0x2d,0xce,0x69,0xc0,0xd8,0x90,0xad,0x84,0xa7,0x4b,0x7e,0x7a,0x28,0x42,
+  0x2e,0x6d,0x67,0xd4,0x38,0xe2,0x53,0x19,0xdb,0x3a,0x9e,0x61,0x4e,0x19,0x26,0xe6,
+  0x28,0x18,0x28,0x58,0xba,0x2f,0xc4,0xeb,0x69,0x83,0x9c,0xa6,0x76,0xb8,0xe8,0xf9,
+  0xf3,0x1c,0x1d,0xe5,0x3e,0x37,0xd0,0xff,0x36,0x8f,0x87,0x99,0x08,0xd3,0x7a,0x3c,
+  0x6b,0xf6,0x66,0x72,0x73,0x92,0x9a,0x05,0x3c,0xcc,0x79,0x7c,0x7e,0x79,0x57,0xea,
+  0x0e,0xc4,0x4f,0x55,0xe5,0xef,0x14,0x44,0x2c,0x17,0xa3,0x17,0x70,0xe4,0x6a,0xc0,
+  0xa0,0xc2,0x8a,0x7d,0x67,0xf7,0x19,0x29,0xc5,0xdf,0x85,0xe9,0xe7,0x2a,0xa8,0xe6,
+  0x8e,0xa7,0xd4,0x8a,0x47,0x75,0x86,0xe6,0x99,0x2a,0x55,0x0a,0x95,0x9c,0x67,0xe1,
+  0xea,0x83,0x41,0xe8,0x0f,0x7b,0x93,0x1b,0xe8,0xef,0x2a,0x13,0xf9,0xef,0x2f,0xd2,
+  0x0f,0xf6,0xe7,0xb9,0x5d,0x62,0x3d,0x16,0xbe,0x5f,0xe0,0xee,0xc8,0x9d,0xff,0x75,
+  0xb6,0xe7,0x7a,0xe5,0x4f,0xae,0x2c,0xfe,0x80,0x5e,0xcf,0xbd,0x54,0x18,0x05,0x7b,
+  0xac,0x63,0x34,0xb2,0x3e,0xc8,0x9c,0x9c,0xa8,0x62,0x9a,0x4c,0xe7,0x5a,0x4a,0xf3,
+  0xc6,0x18,0xee,0xdb,0x1b,0x71,0x19,0x6c,0xbd,0x99,0x9b,0xf0,0x55,0x79,0x8c,0x11,
+  0x2f,0x24,0x27,0xa9,0xd3,0x25,0xb0,0x77,0xf3,0x3a,0x5f,0xe4,0xd5,0xef,0x33,0x7f,
+  0xf0,0x6a,0xab,0xd8,0xd6,0x7b,0x65,0xba,0xfc,0xd5,0x1a,0x51,0x3c,0x77,0x9e,0xf2,
+  0xa4,0x24,0x98,0xc8,0xda,0x36,0x33,0xd1,0x9d,0xa8,0xf7,0xc4,0xf8,0x44,0x38,0x0b,
+  0xb7,0x66,0x1f,0x01,0xd1,0x36,0x64,0xf4,0xfe,0xa1,0xec,0xc8,0x25,0xfe,0x92,0x1f,
+  0x2e,0xfa,0xa9,0xa9,0x7c,0xfb,0xcf,0x7e,0xae,0x5b,0xff,0xe9,0x64,0xe4,0x5b,0x7f,
+  0xce,0xc6,0xaf,0xdd,0xe8,0xdc,0x4a,0xe5,0x59,0x5f,0x47,0x6d,0x4f,0xb7,0x6c,0xb9,
+  0x2a,0x5f,0x4f,0x2f,0x3b,0x25,0xae,0x23,0x36,0x92,0xab,0xf0,0xe5,0xc7,0x8f,0xd2,
+  0x87,0x86,0x53,0x36,0xd4,0xf7,0xaf,0xac,0xfb,0x07,0x5a,0xee,0x15,0x52,0x1c,0x4e,
+  0x7c,0x2c,0xb6,0x15,0xfb,0x12,0xa2,0x0b,0x60,0x77,0xe7,0xd7,0xa8,0x2b,0x51,0x79,
+  0xcf,0xf8,0xdb,0xe3,0x02,0xc8,0x99,0x85,0x13,0xe3,0x01,0x29,0x15,0x6f,0x89,0xbf,
+  0xea,0x24,0x46,0xbd,0xb7,0x7a,0xc6,0xac,0xca,0x8f,0x1e,0xc9,0x79,0xcd,0x23,0x4f,
+  0x74,0xc8,0xd3,0xf5,0x22,0xbb,0xa0,0xc0,0xff,0x67,0x26,0x20,0xd6,0x2b,0x7f,0xad,
+  0x79,0xc6,0x72,0x4a,0x89,0x0e,0x87,0x02,0xf6,0x76,0xc7,0x4e,0x4e,0xff,0x94,0xe0,
+  0xb3,0x5b,0x48,0xdb,0xeb,0xe6,0x27,0xd3,0x66,0x4a,0x53,0xd6,0xe3,0x37,0x64,0xfb,
+  0xab,0x5c,0xcd,0x51,0xef,0xc5,0xbc,0xc7,0x9d,0x9b,0x87,0x43,0x6f,0x90,0xef,0x2b,
+  0xcf,0x73,0x9b,0xb4,0xf3,0x55,0xb4,0xe6,0x0a,0x1b,0xb5,0x69,0xa7,0x61,0x6f,0xce,
+  0x2b,0xe7,0xb2,0xc8,0xe6,0x1e,0xba,0xa4,0x8f,0xe9,0x21,0x73,0xaa,0x92,0xa3,0x65,
+  0xe8,0x9e,0x65,0x49,0xab,0xf0,0xd1,0xcc,0xfb,0x63,0x94,0x50,0x37,0xec,0xdb,0xca,
+  0x3d,0xf9,0xd1,0x0a,0x93,0xf1,0x6d,0x1f,0x17,0x4a,0x51,0x99,0xfe,0xdb,0xc0,0xf8,
+  0x37,0x9a,0xba,0xc8,0xd5,0x80,0xc6,0xfb,0xc2,0xc2,0xc1,0xfc,0x37,0x81,0xa4,0x63,
+  0x3a,0x6f,0x9b,0x5e,0xfc,0xc4,0xd6,0xad,0xcc,0xbc,0x92,0xbc,0xfe,0x23,0x4f,0x83,
+  0x71,0x7a,0x4b,0x3e,0x58,0xcf,0x1a,0x2a,0xe2,0x9c,0x9b,0x2d,0x49,0x0f,0x5a,0x54,
+  0x45,0x6c,0x5e,0xf1,0x6b,0x8b,0x7d,0x61,0xae,0xa2,0xa0,0x7a,0xf0,0xc5,0xb5,0xbc,
+  0x3c,0x4e,0xc6,0xaf,0xba,0x33,0xed,0x94,0x55,0x83,0x9c,0xd5,0xaa,0xb2,0xbe,0x8b,
+  0xcc,0x6b,0xba,0xa6,0x1a,0x69,0xce,0x70,0x7b,0xc6,0xbb,0x2a,0x45,0xf4,0xfb,0x7e,
+  0x9c,0x76,0x2a,0x81,0x13,0xc1,0x0b,0xc5,0x8f,0x83,0xcd,0xb2,0x7c,0xfb,0x6f,0x43,
+  0xe3,0xdf,0x66,0xfb,0x3c,0xf3,0x8a,0xc7,0x1f,0x5e,0x26,0x06,0xc7,0x64,0xd9,0xc3,
+  0x69,0x24,0x4b,0x07,0x9c,0xf0,0xe9,0xc4,0xfd,0x32,0xa3,0xf4,0xa5,0x98,0x21,0xb6,
+  0xb7,0x6b,0x7c,0x41,0x9c,0xf6,0x97,0xd3,0xbd,0x51,0x53,0x5e,0xae,0xb9,0x47,0x3f,
+  0xbc,0x2b,0x74,0x12,0xf5,0x0b,0x8f,0x36,0xed,0xeb,0xff,0x3e,0xc8,0x5b,0xca,0xeb,
+  0x37,0xf0,0x6a,0xb1,0x96,0x21,0xac,0xea,0xae,0xdc,0x8d,0x80,0x55,0x59,0x05,0x23,
+  0x69,0xab,0x51,0xb6,0x9b,0x8b,0x3b,0x6c,0xe9,0xa4,0x9f,0x68,0x63,0x6c,0x57,0xea,
+  0x4d,0xc5,0x52,0x9c,0xee,0x76,0x23,0x6a,0x2a,0x3f,0x51,0xcd,0x9d,0x29,0x76,0xb6,
+  0x15,0xcc,0xff,0xda,0xcf,0xf5,0xf5,0xbf,0x52,0x3c,0x1b,0x66,0xa3,0xf3,0x86,0x69,
+  0xec,0xa1,0xe1,0xb2,0x97,0x8f,0x10,0xc4,0x15,0x77,0x91,0xca,0x55,0xf0,0xd8,0xd5,
+  0xac,0x75,0x23,0x8e,0xbb,0x0e,0x88,0x0a,0x5f,0xfc,0x39,0xe9,0xbd,0xaa,0xa9,0xa5,
+  0x86,0x68,0x83,0x3d,0x2c,0x34,0xf2,0xe6,0x64,0x3b,0x36,0x52,0x76,0xdd,0xde,0xbc,
+  0xef,0x1f,0x97,0x8d,0xe1,0x48,0x61,0x65,0x15,0x05,0xf1,0x72,0xbd,0xbe,0xd6,0xaa,
+  0x6a,0xc6,0x0f,0xd9,0xd8,0x71,0x42,0x6f,0xce,0xcf,0x22,0x89,0xa5,0x5d,0x9e,0x75,
+  0x4d,0x06,0x94,0xbc,0x1a,0xec,0xa1,0x6f,0x20,0x97,0xf2,0xce,0x71,0xd3,0xa8,0x3d,
+  0x41,0x8d,0x8b,0xf8,0x7b,0x53,0x9d,0x7e,0xff,0x83,0xa8,0xf5,0xd4,0xb3,0x70,0xeb,
+  0xf3,0xbf,0xac,0xaa,0x41,0x83,0x93,0x84,0xbc,0xe9,0x09,0x9d,0xa8,0xf7,0xd7,0x68,
+  0xe2,0x4b,0x71,0xa4,0x4a,0x17,0x29,0x57,0x32,0x4e,0x43,0xfd,0xc0,0xf0,0x19,0x66,
+  0xa7,0xcb,0x19,0xcd,0x82,0xbe,0x55,0xed,0xd7,0xd4,0xea,0x95,0x62,0xe1,0x49,0xba,
+  0x4c,0xda,0x33,0x6d,0x42,0xb6,0xaf,0xe4,0xc9,0xfe,0xfb,0x8e,0x9c,0xec,0x66,0x74,
+  0x4e,0x33,0x2f,0xe8,0xbf,0xb9,0xe6,0x77,0x17,0xea,0x57,0xdd,0x11,0x2d,0x13,0x1e,
+  0xc8,0x4a,0x88,0x94,0x8d,0x83,0x56,0x88,0xd2,0xeb,0xd5,0x42,0xfe,0x93,0x4b,0xb6,
+  0x37,0x6a,0xca,0xa5,0x83,0xd1,0x19,0xb4,0x0f,0x4a,0x4a,0x58,0x57,0xc2,0x4c,0xe9,
+  0x8b,0x44,0x3d,0xfd,0x97,0x5d,0x54,0xbc,0x3e,0xfd,0xd7,0xd8,0x99,0xf5,0xa9,0xd9,
+  0xcf,0x28,0x55,0xbc,0x7c,0xe6,0xcd,0x2b,0x81,0xd6,0xe2,0x63,0xd4,0x95,0x18,0xb2,
+  0x7f,0xcb,0x59,0x3f,0x2b,0xde,0xab,0x71,0x2f,0xcf,0x44,0xc2,0x42,0x76,0x6c,0xd9,
+  0xa9,0x34,0x31,0xdd,0x47,0x7f,0xc7,0xd6,0xae,0x87,0x88,0xd3,0x76,0xb0,0xb1,0x26,
+  0xab,0xe0,0x5e,0xa1,0x86,0x04,0xaa,0xed,0x58,0x6e,0x6f,0x8f,0x66,0x34,0x53,0xde,
+  0x3f,0xee,0x54,0x85,0xca,0xc5,0x3b,0xc2,0x9e,0xde,0x8a,0x46,0x14,0xd2,0x8f,0x50,
+  0xb8,0x38,0x57,0x6e,0xd4,0xa8,0x1d,0xc9,0xd8,0xf9,0xf8,0x2f,0x2d,0x73,0x79,0x34,
+  0xbc,0x13,0xaf,0x9b,0xe1,0xab,0x53,0x51,0xa6,0x8b,0x09,0x7a,0x5f,0x99,0x5f,0x95,
+  0xaa,0x7f,0x91,0xcd,0xdb,0x27,0x7f,0x92,0x7a,0xc3,0x80,0xab,0x82,0x90,0x6f,0xbd,
+  0xe8,0x0f,0x36,0x5b,0xf4,0x36,0x32,0x76,0xa2,0xd1,0x89,0xdf,0x90,0x8e,0x5f,0x78,
+  0x75,0x41,0x7a,0xf8,0x1d,0x54,0xd3,0xfd,0x21,0x8a,0x6b,0xe5,0xa4,0x6f,0x1c,0xe7,
+  0x4c,0x4f,0x84,0xd5,0x39,0x41,0xae,0x49,0x19,0x1e,0x4d,0xfd,0xdb,0x5e,0x0e,0x31,
+  0xea,0x15,0x72,0x65,0xaf,0x70,0xf7,0xd2,0xe8,0xa7,0x3e,0x9b,0x72,0x6e,0x7b,0x48,
+  0xd5,0x1f,0x1d,0xdc,0x86,0x95,0x9d,0x93,0x8d,0x96,0x7e,0x61,0x67,0x6b,0x75,0xfe,
+  0x25,0x53,0x42,0x01,0x29,0x24,0x53,0x54,0x47,0x36,0x97,0xf8,0xb5,0xdf,0x9b,0x99,
+  0x9a,0x51,0xff,0xcd,0xbf,0xa3,0x45,0x4a,0xcf,0xb5,0xce,0xde,0x49,0x77,0xba,0xfa,
+  0x7f,0xce,0x5f,0xed,0x24,0xae,0x46,0xdf,0xda,0xbf,0x1e,0xe8,0xf6,0xb2,0x3f,0x6c,
+  0xaf,0x8b,0x83,0xc8,0x25,0xd3,0x12,0x13,0xb5,0x2d,0xde,0xd8,0xd7,0x99,0x36,0xea,
+  0xa0,0xba,0xef,0xef,0xde,0x39,0xfb,0xee,0xd8,0x91,0xad,0x69,0x63,0xd4,0x75,0xa5,
+  0x9c,0x3d,0x73,0x39,0xa5,0x6e,0xc4,0x95,0x99,0xe9,0x19,0x72,0xb7,0x13,0xa5,0x39,
+  0x7b,0xf8,0x9d,0x73,0xa4,0x14,0xa6,0xa6,0xbd,0x79,0x0b,0x29,0xaf,0xd2,0x1c,0xab,
+  0x5c,0x0d,0x10,0x7d,0x55,0x10,0xe5,0x4e,0xaf,0x94,0xa6,0x52,0xcf,0x49,0xaf,0xd8,
+  0xc4,0x45,0x27,0x9c,0x4e,0xe9,0xb4,0x13,0xd3,0xb4,0x98,0xa6,0x2e,0x6a,0xc9,0x6a,
+  0x8a,0x6b,0x7f,0xc5,0x42,0x96,0xee,0x24,0xe2,0x46,0xc4,0x59,0xb5,0xff,0xb5,0xf1,
+  0x77,0xcf,0xbe,0x33,0x7a,0xd0,0xfe,0xd5,0x3a,0x75,0xdc,0x5a,0xe0,0x47,0xc7,0x3a,
+  0xcf,0x1b,0xdc,0x5b,0xb6,0x25,0x15,0x1d,0x1b,0x7d,0x9c,0x0c,0x2e,0xf3,0x1e,0x66,
+  0x88,0x83,0xe4,0xbc,0x30,0x2e,0x0a,0x7f,0x8a,0x49,0xfe,0x03,0xab,0xc4,0x3f,0x59,
+  0x1a,0x1a,0xe9,0x20,0x11,0xb9,0x3b,0x25,0x77,0x9b,0xd5,0x17,0x2b,0x05,0x70,0x7d,
+  0x8f,0xad,0x3a,0x7f,0xa4,0xa7,0x8e,0xb6,0xe8,0xcb,0x02,0xce,0xa9,0xc1,0x66,0x17,
+  0x00,0xc7,0xa7,0xd5,0x4e,0x64,0x7f,0xdd,0x5b,0xff,0xfe,0x6a,0x48,0xfe,0xa7,0x2e,
+  0x4e,0xa9,0xf7,0xb8,0x2a,0x13,0xdd,0xcf,0xd9,0x98,0x27,0x7f,0xca,0xf8,0x72,0x05,
+  0xa4,0xff,0x9b,0xbc,0x15,0x94,0x91,0x1d,0x69,0xc6,0x07,0xba,0x30,0x0e,0xfb,0x89,
+  0xab,0x6f,0xad,0x24,0x25,0xc9,0xcc,0xf3,0x4b,0x4e,0x21,0x87,0xc9,0x02,0x79,0x53,
+  0xd0,0x2c,0x32,0x5b,0xf4,0x73,0xef,0xef,0x3c,0xe6,0x5a,0x66,0xea,0x05,0x0e,0x3c,
+  0x8c,0x52,0xa5,0x2f,0x76,0x0d,0x99,0xbb,0x22,0xd2,0x9f,0x7b,0x16,0x72,0x7f,0x29,
+  0xfe,0x7e,0xb2,0x2d,0xa9,0x9e,0x30,0x12,0x8e,0xa0,0x5c,0xf7,0x25,0x86,0x61,0x18,
+  0x95,0x5a,0x74,0x99,0x2a,0x04,0xff,0xfd,0x1a,0x62,0xdc,0xd4,0x92,0x29,0x7a,0x72,
+  0x71,0xb4,0xd8,0x32,0xfe,0x99,0xe9,0xf8,0xac,0x4a,0x24,0x7f,0xfa,0x97,0x26,0xc5,
+  0xe9,0x5a,0xf4,0x23,0xd1,0x99,0xc5,0xd6,0x2c,0xa9,0x89,0xec,0x90,0xd5,0xb6,0x1b,
+  0xf6,0xfc,0xc7,0xab,0x69,0x33,0x20,0xfa,0xfd,0xe9,0x24,0x89,0xb6,0x8e,0x8b,0x15,
+  0x56,0x92,0xda,0xe4,0xdc,0x6e,0x3e,0xe6,0x37,0xaa,0xd3,0x8c,0xa6,0x9a,0x07,0xac,
+  0x68,0xea,0x97,0xc8,0x83,0x89,0x32,0x4e,0x42,0xea,0x75,0x9a,0x8d,0x3e,0x73,0x42,
+  0x68,0xfb,0x4a,0x7b,0x75,0x68,0xaf,0x8a,0x3f,0x83,0xfd,0x51,0x6a,0x94,0x15,0xd0,
+  0xbc,0xba,0x97,0xf5,0xf8,0x36,0x70,0x22,0xf7,0xd6,0x82,0xb1,0x7f,0x4c,0x4d,0x7f,
+  0x70,0xb6,0xf5,0x5d,0xfd,0xdb,0x14,0x9b,0x4b,0xfc,0xda,0xdb,0xb8,0xf3,0x7a,0x98,
+  0x01,0x98,0x6b,0x40,0xd6,0xe3,0xee,0xfe,0x94,0xf1,0x06,0x5e,0xf5,0x46,0x6b,0xab,
+  0xe3,0xce,0x8f,0x42,0x7c,0xc3,0xf9,0x11,0x87,0xb1,0xfc,0x45,0x88,0x8f,0x0f,0xc6,
+  0x0d,0x9f,0x98,0x36,0xe4,0x36,0xce,0x8b,0x40,0xfd,0x2e,0x3a,0xe8,0x1e,0xfc,0xe7,
+  0xbc,0xa5,0x38,0xab,0xa3,0xc4,0x39,0x63,0x8d,0x76,0x9b,0x59,0x4e,0xd2,0x16,0x66,
+  0xf3,0x7a,0xc2,0xd3,0x7f,0xcd,0x49,0x6a,0xcd,0xe7,0x14,0x8d,0x1b,0x77,0xa4,0xf3,
+  0x9d,0x74,0x96,0xfc,0xb0,0x9f,0xba,0xe5,0x9a,0x73,0x7b,0x96,0x5c,0x97,0xd8,0xb9,
+  0xfb,0x6d,0xfe,0x84,0xf8,0xf5,0x80,0xb9,0xc8,0x5b,0x73,0x48,0x7a,0x5c,0x27,0x7b,
+  0xa4,0x6a,0xc3,0xde,0x43,0x79,0xef,0x0a,0xb8,0xef,0x6c,0x33,0xa3,0x5d,0x93,0x07,
+  0xda,0xf3,0xb1,0xf4,0x9f,0x68,0x93,0x32,0x39,0xf6,0x1f,0xae,0x6e,0x8e,0xd3,0x81,
+  0x19,0x2d,0x9c,0x74,0xc4,0xd1,0x01,0x99,0xe1,0x90,0xe2,0xb2,0xf9,0xed,0x64,0xa2,
+  0xdf,0xfc,0x28,0xb2,0x03,0xd7,0xe0,0x27,0x13,0xf9,0x4f,0xe1,0xb5,0x47,0x43,0x77,
+  0xb5,0x57,0x2b,0xa4,0x5b,0xf2,0xc6,0x30,0x24,0x67,0x39,0xf2,0x67,0xc5,0x25,0xe7,
+  0x74,0x96,0x89,0x29,0x75,0x5b,0x9e,0xee,0x7f,0x97,0xfb,0x9c,0xd0,0x16,0x5d,0xe7,
+  0x1c,0xb1,0x3f,0x4f,0x8a,0x58,0x3f,0xf0,0x20,0x1a,0xe3,0xfd,0xae,0x08,0x48,0x12,
+  0x5c,0xdb,0xf4,0x23,0x8e,0xb3,0xfb,0xa2,0x1e,0xc5,0xfd,0x89,0x64,0xe6,0x4f,0x49,
+  0xa4,0xff,0x6c,0xda,0x5d,0x73,0xb2,0x46,0x98,0xfb,0x53,0x40,0xbe,0x21,0x23,0xd0,
+  0xab,0x5e,0xb3,0x5a,0x1d,0xb7,0x15,0x5c,0x16,0x71,0x52,0xce,0x3d,0x4e,0xff,0xb5,
+  0xf5,0x10,0xf7,0xca,0xcf,0x59,0xd5,0x99,0x4e,0x54,0x20,0xbc,0xf1,0x9e,0x51,0x39,
+  0x0f,0xb1,0x1f,0x8e,0x37,0x8a,0x56,0x42,0x8c,0x72,0x5b,0x0d,0x24,0xf9,0x7e,0xda,
+  0x82,0x6c,0x5e,0xe3,0x9c,0x65,0xe5,0xaf,0xa0,0x68,0xbc,0x25,0x26,0x7e,0xe6,0xdc,
+  0x6d,0x8b,0xf4,0x5f,0xc9,0x75,0xde,0x4d,0x9c,0xfe,0xd3,0xbf,0xb1,0x2d,0x1a,0x13,
+  0x03,0x15,0xce,0x42,0xee,0x37,0x24,0xda,0x2c,0x9d,0x0c,0x46,0xe1,0xc3,0x07,0x66,
+  0x57,0x37,0xa9,0xcf,0xd9,0xea,0x3f,0x56,0x10,0x14,0xdb,0x4c,0x49,0x90,0x63,0xff,
+  0xad,0x3d,0xc6,0xd4,0x0c,0xaf,0x90,0x57,0x7e,0xa1,0x5a,0xf7,0x16,0xaa,0x94,0xad,
+  0x39,0x9f,0xd4,0x76,0x72,0x14,0xf0,0x1e,0x36,0x3c,0x7e,0xbb,0xd0,0xc9,0x26,0x47,
+  0x4b,0x66,0x28,0xca,0x73,0x16,0xe4,0xca,0xdf,0x7a,0xb2,0x95,0x8e,0x2e,0x33,0xfe,
+  0x58,0xee,0xe3,0x6b,0xbc,0x5a,0x07,0x3f,0xf7,0x3d,0x9b,0x4a,0x02,0xcf,0xec,0xa9,
+  0x52,0xa1,0x0d,0xdc,0xa8,0x2a,0x70,0xc2,0xa7,0x3e,0xc3,0x2d,0xbc,0x5a,0xfb,0xdb,
+  0x8b,0x9b,0xb1,0xe7,0x8d,0x31,0xf6,0x9f,0x31,0xe5,0x6d,0x3e,0xd8,0x1a,0xbf,0x4f,
+  0x8d,0x7f,0x23,0xfd,0xb7,0xe6,0x98,0x88,0xfd,0x97,0x5c,0x2e,0x45,0xfd,0xfc,0xa1,
+  0xc7,0xe8,0x9a,0x2a,0xe6,0xf0,0xea,0x65,0xd7,0x89,0x85,0x48,0x1b,0x14,0x09,0xa0,
+  0xb1,0xff,0x36,0x90,0x33,0x16,0x8e,0xd3,0x76,0x91,0xd8,0x7f,0x1b,0x2c,0xa0,0x58,
+  0xa5,0x1d,0xf6,0x13,0xb7,0x5c,0x5b,0x4f,0xb1,0xef,0xf7,0x4c,0x1c,0x21,0xb5,0x33,
+  0xe6,0xfa,0xc9,0xa1,0x74,0xf1,0xd0,0x23,0xd3,0x85,0xf7,0xbf,0xf2,0xfe,0x1f,0xe4,
+  0x26,0xfe,0xc1,0xe9,0x6d,0xb1,0x15,0x75,0x17,0x9b,0x6f,0xff,0x29,0xfd,0xb7,0x9e,
+  0xab,0x73,0x7e,0x21,0x49,0x15,0x6e,0x7d,0x6a,0x64,0xb8,0xd7,0x9c,0xa3,0x7f,0xa0,
+  0x35,0x72,0x4a,0x24,0x8e,0x0f,0x35,0x24,0xac,0x6c,0x3f,0x38,0xfe,0x71,0x2b,0x3a,
+  0xb5,0x38,0x67,0xa3,0xe1,0xc6,0x33,0x15,0x8e,0xfb,0xbe,0xec,0x7f,0xba,0xbb,0x32,
+  0x0a,0xd8,0x96,0xf4,0xf8,0xb7,0xb6,0x9e,0x18,0x7e,0x9e,0x32,0xdd,0xa2,0x07,0x5f,
+  0x45,0x7b,0x7e,0xec,0xc0,0x40,0x45,0x97,0x49,0xc0,0xad,0xb3,0x26,0x2a,0xa6,0x64,
+  0x10,0xdc,0xbb,0xeb,0xd8,0x7b,0x0d,0x99,0x7d,0xf4,0x7f,0x33,0xb1,0x4d,0x25,0x38,
+  0xbc,0xab,0x7f,0xbe,0xfe,0x6b,0x8d,0x6b,0xcb,0x64,0xad,0xff,0x32,0xfa,0x4f,0xa3,
+  0x17,0x2e,0x28,0x35,0x38,0x77,0xfa,0xe8,0x33,0xfd,0x55,0x5d,0xa2,0xba,0x78,0x43,
+  0x16,0xf9,0xb7,0x58,0x6d,0x60,0xdf,0x5b,0x33,0xbf,0x17,0x5a,0xed,0x75,0xf8,0xd9,
+  0xc8,0xd1,0xf5,0x24,0xc4,0xff,0xc7,0xc3,0x13,0xbe,0x51,0x31,0x79,0x97,0x65,0xc4,
+  0xc2,0x43,0x7e,0xea,0x96,0x6b,0x6c,0x1d,0x97,0xa7,0xe5,0xcf,0x24,0x4b,0x0a,0xb1,
+  0x38,0x33,0x76,0x60,0x30,0xfa,0x39,0x8a,0xe8,0x59,0xbc,0xb8,0xb0,0x58,0xb5,0x7f,
+  0x68,0xe4,0xf4,0x5c,0x5d,0xc8,0x4e,0xbf,0x6d,0x78,0xdf,0x79,0x66,0xdb,0xc0,0xb6,
+  0x6d,0xd1,0xb6,0xc1,0x8f,0xc1,0x94,0xfd,0x77,0x7a,0xdb,0x7a,0x62,0xc8,0x59,0x90,
+  0xa0,0x23,0x91,0xed,0x96,0x92,0xb0,0x96,0x10,0x37,0x17,0x66,0x4e,0xbf,0x35,0xf2,
+  0xea,0x91,0x91,0x23,0xaf,0xbe,0xf2,0xfa,0xc9,0x73,0x17,0xaf,0xdf,0x16,0x2d,0x3d,
+  0x2d,0x55,0xb4,0xca,0xd9,0x21,0x4f,0xdc,0x45,0xae,0x7e,0xec,0x3f,0xfd,0x2e,0xa6,
+  0xee,0xa2,0x80,0xf4,0xc7,0xc0,0x8f,0x8f,0xf9,0x8a,0xbe,0xb1,0x63,0x3d,0xc5,0xf4,
+  0x72,0xc1,0x93,0x08,0xda,0xfe,0x50,0xa5,0xd4,0xbc,0x7d,0xfd,0xe2,0xb9,0x93,0x47,
+  0x47,0x74,0x29,0x1d,0x79,0xf5,0x57,0xef,0xfe,0x76,0xe1,0xc6,0xb2,0x68,0xe9,0x39,
+  0x3f,0xb1,0x29,0xc7,0xbc,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+  0x00,0x00,0x00,0x00,0x00,0xe0,0x4f,0xc5,0xff,0x02,0x04,0xc4,0x15,0x0c,0x36,0xb4,
+  0x04,0x00,
-- 
1.5.3




From wd at denx.de  Mon Apr 21 12:27:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 12:27:13 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add dcache_enable() for 440
In-Reply-To: Your message of "Mon, 21 Apr 2008 11:45:27 +0200."
	<200804211145.28004.sr@denx.de>
Message-ID: <20080421102713.8B9BE247AF@gemini.denx.de>

In message <200804211145.28004.sr at denx.de> you wrote:
>
> > Well, it affects only processors which need MMU support. Most doen't.
> 
> I'm not so sure here anymore with all the newer PPC's and other platforms. But 
> I have to admit that I'm no expert for those other platforms.

It's only processors which run in 32 bit  mode  but  are  capable  of
addressing > 32 bit physical address space.

> Another problemtic issue could be the POST area for caches etc. I know that 
> self modifying code is used here in some places. This could be more 
> problematic with caches enabled.

The POST code is supposed to take care of that.

> > Next release means the one that comes after the next merge window.
> 
> I did understand this part of the sentence. I'm just not sure what should 
> happen with the current code if it doesn't get changed. Again, I personally 
> can't promise to "fix" this issue until the next merge window opens.

If you fix it "until the next merge window opens", it will come in
time for the next release, so we all are happy.

For now (i. e. for the upcoming 1.3.3 release), let's use this  quick
and really dirty hack to silence the 440 build errors.

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: wd at denx.de
There you go man, Keep as cool as you can. It riles them  to  believe
that you perceive the web they weave. Keep on being free!



From vapier at gentoo.org  Mon Apr 21 12:35:07 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 21 Apr 2008 06:35:07 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <20080421100749.377CD247AF@gemini.denx.de>
References: <20080421100749.377CD247AF@gemini.denx.de>
Message-ID: <200804210635.08416.vapier@gentoo.org>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804210541.41085.vapier at gentoo.org> you wrote:
> > > This makes no sense. If it is ``exactly like "go"'' it doesn't matter
> > > if the code returns or not (and actually this is what I'm  trying  to
> > > point out all the time).
> >
> > the obvious implication is that i would add the cache disabling hooks to
> > the jump command instead of the go command since you wont allow the hook
> > around go.
>
> So it would NOT be ``exactly like "go"''.

well, duh.  my point was that you're making "go" get duplicated just to 
conform to documentation.  the command name itself "go" doesnt really conjurn 
up usage of "executing an application and returning" ... fits better with "go 
to this location and never come back".  "run" probably would have been a 
better name.  but that's hindsight for you.

> Providing both a "go" and a "jump" command which differ just in cahce
> handling seems broken to me. If you want to add such a feature,  then
> I recommend to do it as part of "go", but make it optional, i. e. in-
> troduce a new optional argument to the "go" command, something like
>
> 	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]

cache is just an example.  other arches may want to do other sort of "system 
breakdown/cleanup" before relinquishing control.  option flags to commands 
really doesnt fit the style of u-boot (i expect that sort of painful option 
parsing in redboot, not really u-boot).

so we can do:
	go [-noret] addr [args...]
or we can add "jump" to cmd_boot.c and merge the differences by just using a 
function pointer to "do_go_exec" or "do_jump_exec".

> > > It's just that "go" shall retain the standard U-Boot environment for
> > > application it runs, and that the applications need to take care if
> > > they need to meddle with interrupts, exception handlers, etc.
> >
> > U-Boot sets up no interrupts and the only exceptions that occur on the
> > Blackfin are for cache handling.  disabling the caches forces a sane
>
> There is more procvessors in  this  world  than  just  Blackfin,  and
> others  *do*  enable  interrupts,  etc.  It  is  important to me that
> implementations behave the same no matter which architecture you  are
> using.

i never said Blackfin was the only thing that mattered.  in fact, my goal is 
to make it so that people using this facility get a more standard initial 
environment before they start taking over the system.  i guess i wont point 
out the U-Boot policy about not using interrupts ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/ce750ff8/attachment.pgp 

From vapier at gentoo.org  Mon Apr 21 12:59:42 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 21 Apr 2008 06:59:42 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <200804210635.08416.vapier@gentoo.org>
References: <20080421100749.377CD247AF@gemini.denx.de>
	<200804210635.08416.vapier@gentoo.org>
Message-ID: <200804210659.43481.vapier@gentoo.org>

On Monday 21 April 2008, Mike Frysinger wrote:
> On Monday 21 April 2008, Wolfgang Denk wrote:
> > Providing both a "go" and a "jump" command which differ just in cahce
> > handling seems broken to me. If you want to add such a feature,  then
> > I recommend to do it as part of "go", but make it optional, i. e. in-
> > troduce a new optional argument to the "go" command, something like
> >
> > 	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]
>
> cache is just an example.  other arches may want to do other sort of
> "system breakdown/cleanup" before relinquishing control.  option flags to
> commands really doesnt fit the style of u-boot (i expect that sort of
> painful option parsing in redboot, not really u-boot).
>
> so we can do:
> 	go [-noret] addr [args...]
> or we can add "jump" to cmd_boot.c and merge the differences by just using
> a function pointer to "do_go_exec" or "do_jump_exec".

untested poc attached
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/edee92fc/attachment.pgp 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-jump-cmd.patch
Type: text/x-diff
Size: 1779 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/edee92fc/attachment.patch 

From plagnioj at jcrosoft.com  Mon Apr 21 13:37:48 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 21 Apr 2008 13:37:48 +0200
Subject: [U-Boot-Users] [PATCH] Fix missing dcache_enable symbol and declare
	cache function as weak
In-Reply-To: <1208530299-9817-1-git-send-email-sr@denx.de>
References: <1208530299-9817-1-git-send-email-sr@denx.de>
Message-ID: <1208777868-11252-1-git-send-email-plagnioj@jcrosoft.com>

Recent commit a4986459 adds reference to dcache_enable set dcache and ecache
function as __weak.

For cache status function it will return 0 if the function is not implemented

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/include/common.h b/include/common.h
index f2adebf..ca68802 100644
--- a/include/common.h
+++ b/include/common.h
@@ -386,12 +386,12 @@ void	wr_ic_adr     (uint);
 uint	rd_dc_cst     (void);
 void	wr_dc_cst     (uint);
 void	wr_dc_adr     (uint);
-int	icache_status (void);
-void	icache_enable (void);
-void	icache_disable(void);
-int	dcache_status (void);
-void	dcache_enable (void);
-void	dcache_disable(void);
+int	icache_status (void) __attribute__((weak));
+void	icache_enable (void) __attribute__((weak));
+void	icache_disable(void) __attribute__((weak));
+int	dcache_status (void) __attribute__((weak));
+void	dcache_enable (void) __attribute__((weak));
+void	dcache_disable(void) __attribute__((weak));
 void	relocate_code (ulong, gd_t *, ulong) __attribute__ ((noreturn));
 ulong	get_endaddr   (void);
 void	trap_init     (ulong);
-- 
1.5.4.5




From matthias.fuchs at esd-electronics.com  Mon Apr 21 13:46:06 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 13:46:06 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update bootlogo for APC405 boards
Message-ID: <200804211346.06941.matthias.fuchs@esd-electronics.com>

Hi,

because of the lists size limit and because I did not find any
other suitable way to submit this patch, I am posting a link to the patch file:

http://www.esd-electronics.com/Customer/mf/0001-4xx-Update-bootlogo-for-APC405-boards.patch

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/apc405/logo_640_480_24bpp.c |  800 +++++++++++++++++++++++----------
 1 files changed, 565 insertions(+), 235 deletions(-)





From matthias.fuchs at esd-electronics.com  Mon Apr 21 13:47:37 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 13:47:37 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update FPGA image for APC405 boards
Message-ID: <200804211347.37429.matthias.fuchs@esd-electronics.com>

Hi,

because of the lists size limit and because I did not find any
other suitable way to submit this patch, I am posting a link to the patch file:

http://www.esd-electronics.com/Customer/mf/0002-4xx-Update-FPGA-image-for-APC405-boards.patch

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/apc405/fpgadata.c | 4284 ++++++++++++++++++++-----------------------
 1 files changed, 2004 insertions(+), 2280 deletions(-)




From kenneth at southpole.se  Mon Apr 21 14:07:38 2008
From: kenneth at southpole.se (Kenneth Johansson)
Date: Mon, 21 Apr 2008 14:07:38 +0200
Subject: [U-Boot-Users] What methods of software authentication does
	U-Boot support?
In-Reply-To: <20080420233220.DE0A4248A6@gemini.denx.de>
References: <20080420233220.DE0A4248A6@gemini.denx.de>
Message-ID: <1208779658.7326.47.camel@localhost.localdomain>


On Mon, 2008-04-21 at 01:32 +0200, Wolfgang Denk wrote:
> In message <20080418163211.d5a1ee64.kim.phillips at freescale.com> you wrote:
> >
> > > U-Boot will run only software that has been
> > > authenticated to be from the system's producer.  
> 
> Seems it's time to start a discussion to switch to GPL v3...
> 
> 
> > > Any comments or suggestions?
> > > 
> > this patch taps into openssl:
> 
> Be careful. Linking against openssl is not possible because the
> openssl licence is not compatible with GPL; see for example
> http://www.gnome.org/~markmc/openssl-and-the-gpl.html
> 
> Best regards,
> 
> Wolfgang Denk
> 

For a u-boot friendly version of RSA look at
http://xyssl.org/code/source/rsa/

I have not used it as the client put the secure(authenticated) image
thing on hold but it was the best I could find in the limited time I put
into it.







From giometti at enneenne.com  Mon Apr 21 14:12:04 2008
From: giometti at enneenne.com (Rodolfo Giometti)
Date: Mon, 21 Apr 2008 14:12:04 +0200
Subject: [U-Boot-Users] [PATCH V2] video: Add missing free for logo
	memory
In-Reply-To: <200804211119.04324.matthias.fuchs@esd-electronics.com>
References: <200804211119.04324.matthias.fuchs@esd-electronics.com>
Message-ID: <20080421121204.GJ8404@enneenne.com>

On Mon, Apr 21, 2008 at 11:19:04AM +0200, Matthias Fuchs wrote:
> This patch adds two missing free()s.
> 
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Thanks, applied.

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti at enneenne.com
Linux Device Driver                             giometti at linux.it
Embedded Systems                     phone:	+39 349 2432127
UNIX programming                     skype:     rodolfo.giometti



From wd at denx.de  Mon Apr 21 14:13:12 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 14:13:12 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Mon, 21 Apr 2008 06:35:07 EDT."
	<200804210635.08416.vapier@gentoo.org>
Message-ID: <20080421121312.5A8BF24764@gemini.denx.de>

In message <200804210635.08416.vapier at gentoo.org> you wrote:
>
> well, duh.  my point was that you're making "go" get duplicated just to 
> conform to documentation.  the command name itself "go" doesnt really conjurn 
> up usage of "executing an application and returning" ... fits better with "go 
> to this location and never come back".  "run" probably would have been a 
> better name.  but that's hindsight for you.

You are right. Today I would probably name this "call".

> > 	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]
> 
> cache is just an example.  other arches may want to do other sort of "system 
> breakdown/cleanup" before relinquishing control.  option flags to commands

As the situation is, other arches seem to be just fine  as  it.  It's
only BF which needs a pork sausage.

> really doesnt fit the style of u-boot (i expect that sort of painful option
> parsing in redboot, not really u-boot).

I don;t like it either, but just ading random new commands is even
worse.

> so we can do:
> 	go [-noret] addr [args...]

Ummm... "no return" programs is just an example.  Other  pograms  may
want  to  do  other  sort of "system breakdown/cleanup" before relin-
quishing control.

> or we can add "jump" to cmd_boot.c and merge the differences by just using > a 
> function pointer to "do_go_exec" or "do_jump_exec".

Adn then we add "call" and "exec" and "do" and so oon just for  other
needed options? I say no.

> i never said Blackfin was the only thing that mattered.  in fact, my goal is 
> to make it so that people using this facility get a more standard initial 
> environment before they start taking over the system.  i guess i wont point
> out the U-Boot policy about not using interrupts ...

Are you aware that U-Boot does use interrupts here and there? That we
actually  provide  functions  to  register  interrupt   handlers   to
standalone programs, etc. ?

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: wd at denx.de
Shakespeare's Law of Prototyping: (Hamlet III, iv, 156-160)
        O, throw away the worser part of it,
        And live the purer with the other half.



From wd at denx.de  Mon Apr 21 14:14:11 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 14:14:11 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Mon, 21 Apr 2008 06:59:42 EDT."
	<200804210659.43481.vapier@gentoo.org>
Message-ID: <20080421121411.CBD9424764@gemini.denx.de>

In message <200804210659.43481.vapier at gentoo.org> you wrote:
>
> > or we can add "jump" to cmd_boot.c and merge the differences by just using
> > a function pointer to "do_go_exec" or "do_jump_exec".
> 
> untested poc attached

Don't waste efforts on this. I will not accept it.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In the realm of scientific observation, luck is granted only to those
who are prepared.                                     - Louis Pasteur



From wd at denx.de  Mon Apr 21 14:18:15 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 14:18:15 +0200
Subject: [U-Boot-Users] [PATCH] Fix missing dcache_enable symbol and
	declare cache function as weak
In-Reply-To: Your message of "Mon, 21 Apr 2008 13:37:48 +0200."
	<1208777868-11252-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080421121815.9614724764@gemini.denx.de>

In message <1208777868-11252-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Recent commit a4986459 adds reference to dcache_enable set dcache and ecache
> function as __weak.
> 
> For cache status function it will return 0 if the function is not implemented
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

I hereby reject this.

As discussed before (both here on the ML and on IRC), this is
completely the wrong move to take.

My concern is not silencing  compile  errors,  but  making  the  code
actually easy to read and to understand. And for this it is extremely
important that the code actually does what it claims to do. If I read
"icache_enable()"  I  want  to  be  able  to rely on the icache being
enabled, and not having to check zillions of other source  or  header
files  if there is just a dummy function that does nothing or a macro
definition that lies into my face either.

"But let your statement be, 'Yes, yes ' or 'No, no'; anything beyond
these is of evil." << Matthew 5:37 >>

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: wd at denx.de
A conservative is a man with two perfectly good legs  who  has  never
learned to walk.                              - Franklin D. Roosevelt



From matthias.fuchs at esd-electronics.com  Mon Apr 21 14:42:06 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 14:42:06 +0200
Subject: [U-Boot-Users] [PATCH 2/5] 4xx: update esd's common auto_update
	code for 405 boards
Message-ID: <200804211442.06377.matthias.fuchs@esd-electronics.com>

- Coding style cleanup (long lines)
- improve handling of protected flash regions
- remove dead code

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/common/auto_update.c |  208 ++++++++++++++++++---------------------
 board/esd/common/auto_update.h |   15 ++-
 2 files changed, 106 insertions(+), 117 deletions(-)

diff --git a/board/esd/common/auto_update.c b/board/esd/common/auto_update.c
index 1bf81c6..7e6eea0 100644
--- a/board/esd/common/auto_update.c
+++ b/board/esd/common/auto_update.c
@@ -44,29 +44,16 @@
 extern au_image_t au_image[];
 extern int N_AU_IMAGES;
 
-#define AU_DEBUG
-#undef AU_DEBUG
-
-#undef debug
-#ifdef	AU_DEBUG
-#define debug(fmt,args...)	printf (fmt ,##args)
-#else
-#define debug(fmt,args...)
-#endif	/* AU_DEBUG */
-
-
-#define LOAD_ADDR ((unsigned char *)0x100000)   /* where to load files into memory */
-#define MAX_LOADSZ 0x1e00000
+/* where to load files into memory */
+#define LOAD_ADDR ((unsigned char *)0x100000)
+#define MAX_LOADSZ 0x1c00000
 
 /* externals */
 extern int fat_register_device(block_dev_desc_t *, int);
 extern int file_fat_detectfs(void);
 extern long file_fat_read(const char *, void *, unsigned long);
-long do_fat_read (const char *filename, void *buffer, unsigned long maxsize, int dols);
-#ifdef CONFIG_VFD
-extern int trab_vfd (ulong);
-extern int transfer_pic(unsigned char, unsigned char *, int, int);
-#endif
+long do_fat_read (const char *filename, void *buffer,
+		  unsigned long maxsize, int dols);
 extern int flash_sect_erase(ulong, ulong);
 extern int flash_sect_protect (int, ulong, ulong);
 extern int flash_write (char *, ulong, ulong);
@@ -78,14 +65,15 @@ extern int flash_write (char *, ulong, ulong);
 #define NANDRW_JFFS2	0x02
 #define NANDRW_JFFS2_SKIP	0x04
 extern struct nand_chip nand_dev_desc[];
-extern int nand_legacy_rw(struct nand_chip* nand, int cmd, size_t start, size_t len,
-		   size_t * retlen, u_char * buf);
-extern int nand_legacy_erase(struct nand_chip* nand, size_t ofs, size_t len, int clean);
+extern int nand_legacy_rw(struct nand_chip* nand, int cmd,
+			  size_t start, size_t len,
+			  size_t * retlen, u_char * buf);
+extern int nand_legacy_erase(struct nand_chip* nand, size_t ofs,
+			     size_t len, int clean);
 #endif
 
 extern block_dev_desc_t ide_dev_desc[CFG_IDE_MAXDEVICE];
 
-
 int au_check_cksum_valid(int i, long nbytes)
 {
 	image_header_t *hdr;
@@ -117,7 +105,6 @@ int au_check_cksum_valid(int i, long nbytes)
 	return 0;
 }
 
-
 int au_check_header_valid(int i, long nbytes)
 {
 	image_header_t *hdr;
@@ -132,20 +119,11 @@ int au_check_header_valid(int i, long nbytes)
 #endif
 
 	/* check the easy ones first */
-#undef CHECK_VALID_DEBUG
-#ifdef CHECK_VALID_DEBUG
-	printf("magic %#x %#x ", image_get_magic (hdr), IH_MAGIC);
-	printf("arch %#x %#x ", image_get_arch (hdr), IH_ARCH_PPC);
-	printf("size %#x %#lx ", image_get_data_size (hdr), nbytes);
-	printf("type %#x %#x ", image_get_type (hdr), IH_TYPE_KERNEL);
-#endif
-	if (nbytes < image_get_header_size ())
-	{
+	if (nbytes < image_get_header_size ()) {
 		printf ("Image %s bad header SIZE\n", au_image[i].name);
 		return -1;
 	}
-	if (!image_check_magic (hdr) || !image_check_arch (hdr, IH_ARCH_PPC))
-	{
+	if (!image_check_magic (hdr) || !image_check_arch (hdr, IH_ARCH_PPC)) {
 		printf ("Image %s bad MAGIC or ARCH\n", au_image[i].name);
 		return -1;
 	}
@@ -155,11 +133,13 @@ int au_check_header_valid(int i, long nbytes)
 	}
 
 	/* check the type - could do this all in one gigantic if() */
-	if ((au_image[i].type == AU_FIRMWARE) && !image_check_type (hdr, IH_TYPE_FIRMWARE)) {
+	if (((au_image[i].type & AU_TYPEMASK) == AU_FIRMWARE) &&
+	    !image_check_type (hdr, IH_TYPE_FIRMWARE)) {
 		printf ("Image %s wrong type\n", au_image[i].name);
 		return -1;
 	}
-	if ((au_image[i].type == AU_SCRIPT) && !image_check_type (hdr, IH_TYPE_SCRIPT)) {
+	if (((au_image[i].type & AU_TYPEMASK) == AU_SCRIPT) &&
+	    !image_check_type (hdr, IH_TYPE_SCRIPT)) {
 		printf ("Image %s wrong type\n", au_image[i].name);
 		return -1;
 	}
@@ -167,22 +147,9 @@ int au_check_header_valid(int i, long nbytes)
 	/* recycle checksum */
 	checksum = image_get_data_size (hdr);
 
-#if 0 /* test-only */
-	/* for kernel and app the image header must also fit into flash */
-	if (idx != IDX_DISK)
-		checksum += image_get_header_size ();
-	/* check the size does not exceed space in flash. HUSH scripts */
-	/* all have ausize[] set to 0 */
-	if ((ausize[idx] != 0) && (ausize[idx] < checksum)) {
-		printf ("Image %s is bigger than FLASH\n", au_image[i].name);
-		return -1;
-	}
-#endif
-
 	return 0;
 }
 
-
 int au_do_update(int i, long sz)
 {
 	image_header_t *hdr;
@@ -203,7 +170,7 @@ int au_do_update(int i, long sz)
 	}
 #endif
 
-	switch (au_image[i].type) {
+	switch (au_image[i].type & AU_TYPEMASK) {
 	case AU_SCRIPT:
 		printf("Executing script %s\n", au_image[i].name);
 
@@ -243,38 +210,43 @@ int au_do_update(int i, long sz)
 		 */
 		if (au_image[i].type == AU_FIRMWARE) {
 			char *orig = (char*)start;
-			char *new  = (char *)((char *)hdr + image_get_header_size ());
+			char *new  = (char *)((char *)hdr +
+					      image_get_header_size ());
 			nbytes = image_get_data_size (hdr);
 
-			while(--nbytes) {
+			while (--nbytes) {
 				if (*orig++ != *new++) {
 					break;
 				}
 			}
 			if (!nbytes) {
-				printf("Skipping firmware update - images are identical\n");
+				printf ("Skipping firmware update - "
+					"images are identical\n");
 				break;
 			}
 		}
 
 		/* unprotect the address range */
-		/* this assumes that ONLY the firmware is protected! */
-		if (au_image[i].type == AU_FIRMWARE) {
-			flash_sect_protect(0, start, end);
+		if (((au_image[i].type & AU_FLAGMASK) == AU_PROTECT) ||
+		    (au_image[i].type == AU_FIRMWARE)) {
+			flash_sect_protect (0, start, end);
 		}
 
 		/*
 		 * erase the address range.
 		 */
 		if (au_image[i].type != AU_NAND) {
-			printf("Updating NOR FLASH with image %s\n", au_image[i].name);
+			printf ("Updating NOR FLASH with image %s\n",
+				au_image[i].name);
 			debug ("flash_sect_erase(%lx, %lx);\n", start, end);
-			flash_sect_erase(start, end);
+			flash_sect_erase (start, end);
 		} else {
 #if defined(CONFIG_CMD_NAND) && defined(CFG_NAND_LEGACY)
-			printf("Updating NAND FLASH with image %s\n", au_image[i].name);
+			printf ("Updating NAND FLASH with image %s\n",
+				au_image[i].name);
 			debug ("nand_legacy_erase(%lx, %lx);\n", start, end);
-			rc = nand_legacy_erase (nand_dev_desc, start, end - start + 1, 0);
+			rc = nand_legacy_erase (nand_dev_desc, start,
+						end - start + 1, 0);
 			debug ("nand_legacy_erase returned %x\n", rc);
 #endif
 		}
@@ -296,20 +268,26 @@ int au_do_update(int i, long sz)
 		 * copy the data from RAM to FLASH
 		 */
 		if (au_image[i].type != AU_NAND) {
-			debug ("flash_write(%p, %lx %x)\n", addr, start, nbytes);
-			rc = flash_write((char *)addr, start, nbytes);
+			debug ("flash_write(%p, %lx, %x)\n",
+			       addr, start, nbytes);
+			rc = flash_write ((char *)addr, start,
+					  (nbytes + 1) & ~1);
 		} else {
 #if defined(CONFIG_CMD_NAND) && defined(CFG_NAND_LEGACY)
-			debug ("nand_legacy_rw(%p, %lx %x)\n", addr, start, nbytes);
-			rc = nand_legacy_rw(nand_dev_desc, NANDRW_WRITE | NANDRW_JFFS2,
-				     start, nbytes, (size_t *)&total, (uchar *)addr);
-			debug ("nand_legacy_rw: ret=%x total=%d nbytes=%d\n", rc, total, nbytes);
+			debug ("nand_legacy_rw(%p, %lx, %x)\n",
+			       addr, start, nbytes);
+			rc = nand_legacy_rw (nand_dev_desc,
+					     NANDRW_WRITE | NANDRW_JFFS2,
+					     start, nbytes, (size_t *)&total,
+					     (uchar *)addr);
+			debug ("nand_legacy_rw: ret=%x total=%d nbytes=%d\n",
+			       rc, total, nbytes);
 #else
 			rc = -1;
 #endif
 		}
 		if (rc != 0) {
-			printf("Flashing failed due to error %d\n", rc);
+			printf ("Flashing failed due to error %d\n", rc);
 			return -1;
 		}
 
@@ -317,23 +295,30 @@ int au_do_update(int i, long sz)
 		 * check the dcrc of the copy
 		 */
 		if (au_image[i].type != AU_NAND) {
-			rc = crc32 (0, (uchar *)(start + off), image_get_data_size (hdr));
+			rc = crc32 (0, (uchar *)(start + off),
+				    image_get_data_size (hdr));
 		} else {
 #if defined(CONFIG_CMD_NAND) && defined(CFG_NAND_LEGACY)
-			rc = nand_legacy_rw(nand_dev_desc, NANDRW_READ | NANDRW_JFFS2 | NANDRW_JFFS2_SKIP,
-				     start, nbytes, (size_t *)&total, (uchar *)addr);
-			rc = crc32 (0, (uchar *)(addr + off), image_get_data_size (hdr));
+			rc = nand_legacy_rw (nand_dev_desc,
+					     NANDRW_READ | NANDRW_JFFS2 |
+					     NANDRW_JFFS2_SKIP,
+					     start, nbytes, (size_t *)&total,
+					     (uchar *)addr);
+			rc = crc32 (0, (uchar *)(addr + off),
+				    image_get_data_size (hdr));
 #endif
 		}
 		if (rc != image_get_dcrc (hdr)) {
-			printf ("Image %s Bad Data Checksum After COPY\n", au_image[i].name);
+			printf ("Image %s Bad Data Checksum After COPY\n",
+				au_image[i].name);
 			return -1;
 		}
 
 		/* protect the address range */
 		/* this assumes that ONLY the firmware is protected! */
-		if (au_image[i].type == AU_FIRMWARE) {
-			flash_sect_protect(1, start, end);
+		if (((au_image[i].type & AU_FLAGMASK) == AU_PROTECT) ||
+		    (au_image[i].type == AU_FIRMWARE)) {
+			flash_sect_protect (1, start, end);
 		}
 
 		break;
@@ -345,7 +330,6 @@ int au_do_update(int i, long sz)
 	return 0;
 }
 
-
 static void process_macros (const char *input, char *output)
 {
 	char c, prev;
@@ -359,16 +343,17 @@ static void process_macros (const char *input, char *output)
 #ifdef DEBUG_PARSER
 	char *output_start = output;
 
-	printf ("[PROCESS_MACROS] INPUT len %d: \"%s\"\n", strlen(input), input);
+	printf ("[PROCESS_MACROS] INPUT len %d: \"%s\"\n",
+		strlen(input), input);
 #endif
 
-	prev = '\0';			/* previous character	*/
+	prev = '\0';			/* previous character */
 
 	while (inputcnt && outputcnt) {
 	    c = *input++;
 	    inputcnt--;
 
-	    if (state!=3) {
+	    if (state != 3) {
 	    /* remove one level of escape characters */
 	    if ((c == '\\') && (prev != '\\')) {
 		if (inputcnt-- == 0)
@@ -379,7 +364,7 @@ static void process_macros (const char *input, char *output)
 	    }
 
 	    switch (state) {
-	    case 0:			/* Waiting for (unescaped) $	*/
+	    case 0:			/* Waiting for (unescaped) $ */
 		if ((c == '\'') && (prev != '\\')) {
 			state = 3;
 			break;
@@ -391,7 +376,7 @@ static void process_macros (const char *input, char *output)
 			outputcnt--;
 		}
 		break;
-	    case 1:			/* Waiting for (	*/
+	    case 1:			/* Waiting for ( */
 		if (c == '(' || c == '{') {
 			state++;
 			varname_start = input;
@@ -410,7 +395,8 @@ static void process_macros (const char *input, char *output)
 		if (c == ')' || c == '}') {
 			int i;
 			char envname[CFG_CBSIZE], *envval;
-			int envcnt = input-varname_start-1; /* Varname # of chars */
+			/* Varname # of chars */
+			int envcnt = input - varname_start - 1;
 
 			/* Get the varname */
 			for (i = 0; i < envcnt; i++) {
@@ -448,11 +434,10 @@ static void process_macros (const char *input, char *output)
 
 #ifdef DEBUG_PARSER
 	printf ("[PROCESS_MACROS] OUTPUT len %d: \"%s\"\n",
-		strlen(output_start), output_start);
+		strlen (output_start), output_start);
 #endif
 }
 
-
 /*
  * this is called from board_init() after the hardware has been set up
  * and is usable. That seems like a good time to do this.
@@ -460,84 +445,84 @@ static void process_macros (const char *input, char *output)
  */
 int do_auto_update(void)
 {
-	block_dev_desc_t *stor_dev;
+	block_dev_desc_t *stor_dev = NULL;
 	long sz;
 	int i, res, cnt, old_ctrlc, got_ctrlc;
 	char buffer[32];
 	char str[80];
+	int n;
 
-	/*
-	 * Check whether a CompactFlash is inserted
-	 */
-	if (ide_dev_desc[0].type == DEV_TYPE_UNKNOWN) {
-		return -1;       /* no disk detected! */
+	if  (ide_dev_desc[0].type != DEV_TYPE_UNKNOWN) {
+		stor_dev = get_dev ("ide", 0);
+		if (stor_dev == NULL) {
+			debug ("ide: unknown device\n");
+			return -1;
+		}
 	}
 
-	/* check whether it has a partition table */
-	stor_dev = get_dev("ide", 0);
-	if (stor_dev == NULL) {
-		debug ("Uknown device type\n");
-		return -1;
-	}
-	if (fat_register_device(stor_dev, 1) != 0) {
-		debug ("Unable to register ide disk 0:1 for fatls\n");
+	if (fat_register_device (stor_dev, 1) != 0) {
+		debug ("Unable to register ide disk 0:1\n");
 		return -1;
 	}
 
 	/*
 	 * Check if magic file is present
 	 */
-	if (do_fat_read(AU_MAGIC_FILE, buffer, sizeof(buffer), LS_NO) <= 0) {
+	if ((n = do_fat_read (AU_MAGIC_FILE, buffer,
+			      sizeof(buffer), LS_NO)) <= 0) {
+		debug ("No auto_update magic file (n=%d)\n", n);
 		return -1;
 	}
 
 #ifdef CONFIG_AUTO_UPDATE_SHOW
-	board_auto_update_show(1);
+	board_auto_update_show (1);
 #endif
 	puts("\nAutoUpdate Disk detected! Trying to update system...\n");
 
 	/* make sure that we see CTRL-C and save the old state */
-	old_ctrlc = disable_ctrlc(0);
+	old_ctrlc = disable_ctrlc (0);
 
 	/* just loop thru all the possible files */
 	for (i = 0; i < N_AU_IMAGES; i++) {
 		/*
 		 * Try to expand the environment var in the fname
 		 */
-		process_macros(au_image[i].name, str);
-		strcpy(au_image[i].name, str);
+		process_macros (au_image[i].name, str);
+		strcpy (au_image[i].name, str);
 
 		printf("Reading %s ...", au_image[i].name);
 		/* just read the header */
-		sz = do_fat_read(au_image[i].name, LOAD_ADDR, image_get_header_size (), LS_NO);
+		sz = do_fat_read (au_image[i].name, LOAD_ADDR,
+				  image_get_header_size (), LS_NO);
 		debug ("read %s sz %ld hdr %d\n",
 			au_image[i].name, sz, image_get_header_size ());
 		if (sz <= 0 || sz < image_get_header_size ()) {
 			puts(" not found\n");
 			continue;
 		}
-		if (au_check_header_valid(i, sz) < 0) {
+		if (au_check_header_valid (i, sz) < 0) {
 			puts(" header not valid\n");
 			continue;
 		}
-		sz = do_fat_read(au_image[i].name, LOAD_ADDR, MAX_LOADSZ, LS_NO);
+		sz = do_fat_read (au_image[i].name, LOAD_ADDR,
+				  MAX_LOADSZ, LS_NO);
 		debug ("read %s sz %ld hdr %d\n",
 			au_image[i].name, sz, image_get_header_size ());
 		if (sz <= 0 || sz <= image_get_header_size ()) {
 			puts(" not found\n");
 			continue;
 		}
-		if (au_check_cksum_valid(i, sz) < 0) {
+		if (au_check_cksum_valid (i, sz) < 0) {
 			puts(" checksum not valid\n");
 			continue;
 		}
 		puts(" done\n");
 
 		do {
-			res = au_do_update(i, sz);
+			res = au_do_update (i, sz);
 			/* let the user break out of the loop */
-			if (ctrlc() || had_ctrlc()) {
-				clear_ctrlc();
+			if (ctrlc() || had_ctrlc ()) {
+				clear_ctrlc ();
 				if (res < 0)
 					got_ctrlc = 1;
 				break;
@@ -547,17 +532,16 @@ int do_auto_update(void)
 	}
 
 	/* restore the old state */
-	disable_ctrlc(old_ctrlc);
+	disable_ctrlc (old_ctrlc);
 
 	puts("AutoUpdate finished\n\n");
 #ifdef CONFIG_AUTO_UPDATE_SHOW
-	board_auto_update_show(0);
+	board_auto_update_show (0);
 #endif
 
 	return 0;
 }
 
-
 int auto_update(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
 	do_auto_update();
diff --git a/board/esd/common/auto_update.h b/board/esd/common/auto_update.h
index e2af3c7..3ed0e16 100644
--- a/board/esd/common/auto_update.h
+++ b/board/esd/common/auto_update.h
@@ -29,16 +29,21 @@
 
 #define AU_MAGIC_FILE   "__auto_update"
 
-#define AU_SCRIPT       1
-#define AU_FIRMWARE     2
-#define AU_NOR          3
-#define AU_NAND         4
+#define AU_TYPEMASK     0x000000ff
+#define AU_FLAGMASK     0xffff0000
+
+#define AU_PROTECT      0x80000000
+
+#define AU_SCRIPT       0x01
+#define AU_FIRMWARE     (0x02 | AU_PROTECT)
+#define AU_NOR          0x03
+#define AU_NAND         0x04
 
 struct au_image_s {
 	char name[80];
 	ulong start;
 	ulong size;
-	int type;
+	ulong type;
 };
 
 typedef struct au_image_s au_image_t;
-- 
1.5.3




From matthias.fuchs at esd-electronics.com  Mon Apr 21 14:42:21 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 14:42:21 +0200
Subject: [U-Boot-Users] [PATCH 5/5] 4xx: Remove unused APC405 strataflash
	driver
Message-ID: <200804211442.22060.matthias.fuchs@esd-electronics.com>

The APC405 board support has been migrated to use the common
CFI flash driver.

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/apc405/strataflash.c |  789 ----------------------------------------
 1 files changed, 0 insertions(+), 789 deletions(-)
 delete mode 100644 board/esd/apc405/strataflash.c

diff --git a/board/esd/apc405/strataflash.c b/board/esd/apc405/strataflash.c
deleted file mode 100644
index ad7a71d..0000000
--- a/board/esd/apc405/strataflash.c
+++ /dev/null
@@ -1,789 +0,0 @@
-/*
- * (C) Copyright 2002
- * Brad Kemp, Seranoa Networks, Brad.Kemp at seranoa.com
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include <common.h>
-#include <asm/processor.h>
-
-#undef  DEBUG_FLASH
-/*
- * This file implements a Common Flash Interface (CFI) driver for ppcboot.
- * The width of the port and the width of the chips are determined at initialization.
- * These widths are used to calculate the address for access CFI data structures.
- * It has been tested on an Intel Strataflash implementation.
- *
- * References
- * JEDEC Standard JESD68 - Common Flash Interface (CFI)
- * JEDEC Standard JEP137-A Common Flash Interface (CFI) ID Codes
- * Intel Application Note 646 Common Flash Interface (CFI) and Command Sets
- * Intel 290667-008 3 Volt Intel StrataFlash Memory datasheet
- *
- * TODO
- * Use Primary Extended Query table (PRI) and Alternate Algorithm Query Table (ALT) to determine if protection is available
- * Add support for other command sets Use the PRI and ALT to determine command set
- * Verify erase and program timeouts.
- */
-
-#define FLASH_CMD_CFI			0x98
-#define FLASH_CMD_READ_ID		0x90
-#define FLASH_CMD_RESET			0xff
-#define FLASH_CMD_BLOCK_ERASE		0x20
-#define FLASH_CMD_ERASE_CONFIRM		0xD0
-#define FLASH_CMD_WRITE			0x40
-#define FLASH_CMD_PROTECT		0x60
-#define FLASH_CMD_PROTECT_SET		0x01
-#define FLASH_CMD_PROTECT_CLEAR		0xD0
-#define FLASH_CMD_CLEAR_STATUS		0x50
-#define FLASH_CMD_WRITE_TO_BUFFER       0xE8
-#define FLASH_CMD_WRITE_BUFFER_CONFIRM  0xD0
-
-#define FLASH_STATUS_DONE		0x80
-#define FLASH_STATUS_ESS		0x40
-#define FLASH_STATUS_ECLBS		0x20
-#define FLASH_STATUS_PSLBS		0x10
-#define FLASH_STATUS_VPENS		0x08
-#define FLASH_STATUS_PSS		0x04
-#define FLASH_STATUS_DPS		0x02
-#define FLASH_STATUS_R			0x01
-#define FLASH_STATUS_PROTECT		0x01
-
-#define FLASH_OFFSET_CFI		0x55
-#define FLASH_OFFSET_CFI_RESP		0x10
-#define FLASH_OFFSET_WTOUT		0x1F
-#define FLASH_OFFSET_WBTOUT             0x20
-#define FLASH_OFFSET_ETOUT		0x21
-#define FLASH_OFFSET_CETOUT             0x22
-#define FLASH_OFFSET_WMAX_TOUT		0x23
-#define FLASH_OFFSET_WBMAX_TOUT         0x24
-#define FLASH_OFFSET_EMAX_TOUT		0x25
-#define FLASH_OFFSET_CEMAX_TOUT         0x26
-#define FLASH_OFFSET_SIZE		0x27
-#define FLASH_OFFSET_INTERFACE          0x28
-#define FLASH_OFFSET_BUFFER_SIZE        0x2A
-#define FLASH_OFFSET_NUM_ERASE_REGIONS	0x2C
-#define FLASH_OFFSET_ERASE_REGIONS	0x2D
-#define FLASH_OFFSET_PROTECT		0x02
-#define FLASH_OFFSET_USER_PROTECTION    0x85
-#define FLASH_OFFSET_INTEL_PROTECTION   0x81
-
-#define FLASH_MAN_CFI			0x01000000
-
-typedef union {
-	unsigned char c;
-	unsigned short w;
-	unsigned long l;
-} cfiword_t;
-
-typedef union {
-	unsigned char * cp;
-	unsigned short *wp;
-	unsigned long *lp;
-} cfiptr_t;
-
-#define NUM_ERASE_REGIONS 4
-
-flash_info_t	flash_info[CFG_MAX_FLASH_BANKS]; /* info for FLASH chips	*/
-
-/*-----------------------------------------------------------------------
- * Functions
- */
-
-static void flash_add_byte(flash_info_t *info, cfiword_t * cword, uchar c);
-static void flash_make_cmd(flash_info_t * info, uchar cmd, void * cmdbuf);
-static void flash_write_cmd(flash_info_t * info, int sect, uchar offset, uchar cmd);
-static int flash_isequal(flash_info_t * info, int sect, uchar offset, uchar cmd);
-static int flash_isset(flash_info_t * info, int sect, uchar offset, uchar cmd);
-static int flash_detect_cfi(flash_info_t * info);
-static ulong flash_get_size (ulong base, int banknum);
-static int flash_write_cfiword (flash_info_t *info, ulong dest, cfiword_t cword);
-static int flash_full_status_check(flash_info_t * info, ulong sector, ulong tout, char * prompt);
-#ifdef CFG_FLASH_USE_BUFFER_WRITE
-static int flash_write_cfibuffer(flash_info_t * info, ulong dest, uchar * cp, int len);
-#endif
-/*-----------------------------------------------------------------------
- * create an address based on the offset and the port width
- */
-inline uchar * flash_make_addr(flash_info_t * info, int sect, int offset)
-{
-	return ((uchar *)(info->start[sect] + (offset * info->portwidth)));
-}
-/*-----------------------------------------------------------------------
- * read a character at a port width address
- */
-inline uchar flash_read_uchar(flash_info_t * info, uchar offset)
-{
-	uchar *cp;
-	cp = flash_make_addr(info, 0, offset);
-	return (cp[info->portwidth - 1]);
-}
-
-/*-----------------------------------------------------------------------
- * read a short word by swapping for ppc format.
- */
-ushort flash_read_ushort(flash_info_t * info, int sect,  uchar offset)
-{
-    uchar * addr;
-
-    addr = flash_make_addr(info, sect, offset);
-    return ((addr[(2*info->portwidth) - 1] << 8) | addr[info->portwidth - 1]);
-
-}
-
-/*-----------------------------------------------------------------------
- * read a long word by picking the least significant byte of each maiximum
- * port size word. Swap for ppc format.
- */
-ulong flash_read_long(flash_info_t * info, int sect,  uchar offset)
-{
-    uchar * addr;
-
-    addr = flash_make_addr(info, sect, offset);
-    return ( (addr[(2*info->portwidth) - 1] << 24 ) | (addr[(info->portwidth) -1] << 16) |
-	    (addr[(4*info->portwidth) - 1] << 8) | addr[(3*info->portwidth) - 1]);
-
-}
-
-/*-----------------------------------------------------------------------
- */
-unsigned long flash_init (void)
-{
-	unsigned long size;
-	int i;
-	unsigned long  address;
-
-
-	/* The flash is positioned back to back, with the demultiplexing of the chip
-	 * based on the A24 address line.
-	 *
-	 */
-
-	address = CFG_FLASH_BASE;
-	size = 0;
-
-	/* Init: no FLASHes known */
-	for (i=0; i<CFG_MAX_FLASH_BANKS; ++i) {
-		flash_info[i].flash_id = FLASH_UNKNOWN;
-		size += flash_info[i].size = flash_get_size(address, i);
-		address += CFG_FLASH_INCREMENT;
-		if (flash_info[0].flash_id == FLASH_UNKNOWN) {
-			printf ("## Unknown FLASH on Bank %d - Size = 0x%08lx = %ld MB\n",i,
-				flash_info[0].size, flash_info[i].size<<20);
-		}
-	}
-
-#if 0 /* test-only */
-	/* Monitor protection ON by default */
-#if (CFG_MONITOR_BASE >= CFG_FLASH_BASE)
-	for(i=0; flash_info[0].start[i] < CFG_MONITOR_BASE+CFG_MONITOR_LEN-1; i++)
-		(void)flash_real_protect(&flash_info[0], i, 1);
-#endif
-#else
-	/* monitor protection ON by default */
-	flash_protect (FLAG_PROTECT_SET,
-		       - CFG_MONITOR_LEN,
-		       - 1, &flash_info[1]);
-#endif
-
-	return (size);
-}
-
-/*-----------------------------------------------------------------------
- */
-int flash_erase (flash_info_t *info, int s_first, int s_last)
-{
-	int rcode = 0;
-	int prot;
-	int sect;
-
-	if( info->flash_id != FLASH_MAN_CFI) {
-		printf ("Can't erase unknown flash type - aborted\n");
-		return 1;
-	}
-	if ((s_first < 0) || (s_first > s_last)) {
-		printf ("- no sectors to erase\n");
-		return 1;
-	}
-
-	prot = 0;
-	for (sect=s_first; sect<=s_last; ++sect) {
-		if (info->protect[sect]) {
-			prot++;
-		}
-	}
-	if (prot) {
-		printf ("- Warning: %d protected sectors will not be erased!\n",
-			prot);
-	} else {
-		printf ("\n");
-	}
-
-
-	for (sect = s_first; sect<=s_last; sect++) {
-		if (info->protect[sect] == 0) { /* not protected */
-			flash_write_cmd(info, sect, 0, FLASH_CMD_CLEAR_STATUS);
-			flash_write_cmd(info, sect, 0, FLASH_CMD_BLOCK_ERASE);
-			flash_write_cmd(info, sect, 0, FLASH_CMD_ERASE_CONFIRM);
-
-			if(flash_full_status_check(info, sect, info->erase_blk_tout, "erase")) {
-				rcode = 1;
-			} else
-				printf(".");
-		}
-	}
-	printf (" done\n");
-	return rcode;
-}
-
-/*-----------------------------------------------------------------------
- */
-void flash_print_info  (flash_info_t *info)
-{
-	int i;
-
-	if (info->flash_id != FLASH_MAN_CFI) {
-		printf ("missing or unknown FLASH type\n");
-		return;
-	}
-
-	printf("CFI conformant FLASH (%d x %d)",
-	       (info->portwidth	 << 3 ), (info->chipwidth  << 3 ));
-	printf ("  Size: %ld MB in %d Sectors\n",
-		info->size >> 20, info->sector_count);
-	printf(" Erase timeout %ld ms, write timeout %ld ms, buffer write timeout %ld ms, buffer size %d\n",
-	       info->erase_blk_tout, info->write_tout, info->buffer_write_tout, info->buffer_size);
-
-	printf ("  Sector Start Addresses:");
-	for (i=0; i<info->sector_count; ++i) {
-#ifdef CFG_FLASH_EMPTY_INFO
-		int k;
-		int size;
-		int erased;
-		volatile unsigned long *flash;
-
-		/*
-		 * Check if whole sector is erased
-		 */
-		if (i != (info->sector_count-1))
-		  size = info->start[i+1] - info->start[i];
-		else
-		  size = info->start[0] + info->size - info->start[i];
-		erased = 1;
-		flash = (volatile unsigned long *)info->start[i];
-		size = size >> 2;        /* divide by 4 for longword access */
-		for (k=0; k<size; k++)
-		  {
-		    if (*flash++ != 0xffffffff)
-		      {
-			erased = 0;
-			break;
-		      }
-		  }
-
-		if ((i % 5) == 0)
-			printf ("\n   ");
-		/* print empty and read-only info */
-		printf (" %08lX%s%s",
-			info->start[i],
-			erased ? " E" : "  ",
-			info->protect[i] ? "RO " : "   ");
-#else
-		if ((i % 5) == 0)
-			printf ("\n   ");
-		printf (" %08lX%s",
-			info->start[i],
-			info->protect[i] ? " (RO)" : "     ");
-#endif
-	}
-	printf ("\n");
-	return;
-}
-
-/*-----------------------------------------------------------------------
- * Copy memory to flash, returns:
- * 0 - OK
- * 1 - write timeout
- * 2 - Flash not erased
- */
-int write_buff (flash_info_t *info, uchar *src, ulong addr, ulong cnt)
-{
-	ulong wp;
-	ulong cp;
-	int aln;
-	cfiword_t cword;
-	int i, rc;
-
-	/* get lower aligned address */
-	wp = (addr & ~(info->portwidth - 1));
-
-	/* handle unaligned start */
-	if((aln = addr - wp) != 0) {
-		cword.l = 0;
-		cp = wp;
-		for(i=0;i<aln; ++i, ++cp)
-			flash_add_byte(info, &cword, (*(uchar *)cp));
-
-		for(; (i< info->portwidth) && (cnt > 0) ; i++) {
-			flash_add_byte(info, &cword, *src++);
-			cnt--;
-			cp++;
-		}
-		for(; (cnt == 0) && (i < info->portwidth); ++i, ++cp)
-			flash_add_byte(info, &cword, (*(uchar *)cp));
-		if((rc = flash_write_cfiword(info, wp, cword)) != 0)
-			return rc;
-		wp = cp;
-	}
-
-#ifdef CFG_FLASH_USE_BUFFER_WRITE
-	while(cnt >= info->portwidth) {
-		i = info->buffer_size > cnt? cnt: info->buffer_size;
-		if((rc = flash_write_cfibuffer(info, wp, src,i)) != ERR_OK)
-			return rc;
-		wp += i;
-		src += i;
-		cnt -=i;
-	}
-#else
-	/* handle the aligned part */
-	while(cnt >= info->portwidth) {
-		cword.l = 0;
-		for(i = 0; i < info->portwidth; i++) {
-			flash_add_byte(info, &cword, *src++);
-		}
-		if((rc = flash_write_cfiword(info, wp, cword)) != 0)
-			return rc;
-		wp += info->portwidth;
-		cnt -= info->portwidth;
-	}
-#endif /* CFG_FLASH_USE_BUFFER_WRITE */
-	if (cnt == 0) {
-		return (0);
-	}
-
-	/*
-	 * handle unaligned tail bytes
-	 */
-	cword.l = 0;
-	for (i=0, cp=wp; (i<info->portwidth) && (cnt>0); ++i, ++cp) {
-		flash_add_byte(info, &cword, *src++);
-		--cnt;
-	}
-	for (; i<info->portwidth; ++i, ++cp) {
-		flash_add_byte(info, & cword, (*(uchar *)cp));
-	}
-
-	return flash_write_cfiword(info, wp, cword);
-}
-
-/*-----------------------------------------------------------------------
- */
-int flash_real_protect(flash_info_t *info, long sector, int prot)
-{
-	int retcode = 0;
-
-	flash_write_cmd(info, sector, 0, FLASH_CMD_CLEAR_STATUS);
-	flash_write_cmd(info, sector, 0, FLASH_CMD_PROTECT);
-	if(prot)
-		flash_write_cmd(info, sector, 0, FLASH_CMD_PROTECT_SET);
-	else
-		flash_write_cmd(info, sector, 0, FLASH_CMD_PROTECT_CLEAR);
-
-	if((retcode = flash_full_status_check(info, sector, info->erase_blk_tout,
-					 prot?"protect":"unprotect")) == 0) {
-
-		info->protect[sector] = prot;
-		/* Intel's unprotect unprotects all locking */
-		if(prot == 0) {
-			int i;
-			for(i = 0 ; i<info->sector_count; i++) {
-				if(info->protect[i])
-					flash_real_protect(info, i, 1);
-			}
-		}
-	}
-
-	return retcode;
-}
-/*-----------------------------------------------------------------------
- *  wait for XSR.7 to be set. Time out with an error if it does not.
- *  This routine does not set the flash to read-array mode.
- */
-static int flash_status_check(flash_info_t * info, ulong sector, ulong tout, char * prompt)
-{
-	ulong start;
-
-	/* Wait for command completion */
-	start = get_timer (0);
-	while(!flash_isset(info, sector, 0, FLASH_STATUS_DONE)) {
-		if (get_timer(start) > info->erase_blk_tout) {
-			printf("Flash %s timeout at address %lx\n", prompt, info->start[sector]);
-			flash_write_cmd(info, sector, 0, FLASH_CMD_RESET);
-			return ERR_TIMOUT;
-		}
-	}
-	return ERR_OK;
-}
-/*-----------------------------------------------------------------------
- * Wait for XSR.7 to be set, if it times out print an error, otherwise do a full status check.
- * This routine sets the flash to read-array mode.
- */
-static int flash_full_status_check(flash_info_t * info, ulong sector, ulong tout, char * prompt)
-{
-	int retcode;
-	retcode = flash_status_check(info, sector, tout, prompt);
-	if((retcode == ERR_OK) && !flash_isequal(info,sector, 0, FLASH_STATUS_DONE)) {
-		retcode = ERR_INVAL;
-		printf("Flash %s error at address %lx\n", prompt,info->start[sector]);
-		if(flash_isset(info, sector, 0, FLASH_STATUS_ECLBS | FLASH_STATUS_PSLBS)){
-			printf("Command Sequence Error.\n");
-		} else if(flash_isset(info, sector, 0, FLASH_STATUS_ECLBS)){
-			printf("Block Erase Error.\n");
-			retcode = ERR_NOT_ERASED;
-		} else if (flash_isset(info, sector, 0, FLASH_STATUS_PSLBS)) {
-			printf("Locking Error\n");
-		}
-		if(flash_isset(info, sector, 0, FLASH_STATUS_DPS)){
-			printf("Block locked.\n");
-			retcode = ERR_PROTECTED;
-		}
-		if(flash_isset(info, sector, 0, FLASH_STATUS_VPENS))
-			printf("Vpp Low Error.\n");
-	}
-	flash_write_cmd(info, sector, 0, FLASH_CMD_RESET);
-	return retcode;
-}
-/*-----------------------------------------------------------------------
- */
-static void flash_add_byte(flash_info_t *info, cfiword_t * cword, uchar c)
-{
-	switch(info->portwidth) {
-	case FLASH_CFI_8BIT:
-		cword->c = c;
-		break;
-	case FLASH_CFI_16BIT:
-		cword->w = (cword->w << 8) | c;
-		break;
-	case FLASH_CFI_32BIT:
-		cword->l = (cword->l << 8) | c;
-	}
-}
-
-
-/*-----------------------------------------------------------------------
- * make a proper sized command based on the port and chip widths
- */
-static void flash_make_cmd(flash_info_t * info, uchar cmd, void * cmdbuf)
-{
-	int i;
-	uchar *cp = (uchar *)cmdbuf;
-	for(i=0; i< info->portwidth; i++)
-		*cp++ = ((i+1) % info->chipwidth) ? '\0':cmd;
-}
-
-/*
- * Write a proper sized command to the correct address
- */
-static void flash_write_cmd(flash_info_t * info, int sect, uchar offset, uchar cmd)
-{
-
-	volatile cfiptr_t addr;
-	cfiword_t cword;
-	addr.cp = flash_make_addr(info, sect, offset);
-	flash_make_cmd(info, cmd, &cword);
-	switch(info->portwidth) {
-	case FLASH_CFI_8BIT:
-		*addr.cp = cword.c;
-		break;
-	case FLASH_CFI_16BIT:
-		*addr.wp = cword.w;
-		break;
-	case FLASH_CFI_32BIT:
-		*addr.lp = cword.l;
-		break;
-	}
-}
-
-/*-----------------------------------------------------------------------
- */
-static int flash_isequal(flash_info_t * info, int sect, uchar offset, uchar cmd)
-{
-	cfiptr_t cptr;
-	cfiword_t cword;
-	int retval;
-	cptr.cp = flash_make_addr(info, sect, offset);
-	flash_make_cmd(info, cmd, &cword);
-	switch(info->portwidth) {
-	case FLASH_CFI_8BIT:
-		retval = (cptr.cp[0] == cword.c);
-		break;
-	case FLASH_CFI_16BIT:
-		retval = (cptr.wp[0] == cword.w);
-		break;
-	case FLASH_CFI_32BIT:
-		retval = (cptr.lp[0] == cword.l);
-		break;
-	default:
-		retval = 0;
-		break;
-	}
-	return retval;
-}
-/*-----------------------------------------------------------------------
- */
-static int flash_isset(flash_info_t * info, int sect, uchar offset, uchar cmd)
-{
-	cfiptr_t cptr;
-	cfiword_t cword;
-	int retval;
-	cptr.cp = flash_make_addr(info, sect, offset);
-	flash_make_cmd(info, cmd, &cword);
-	switch(info->portwidth) {
-	case FLASH_CFI_8BIT:
-		retval = ((cptr.cp[0] & cword.c) == cword.c);
-		break;
-	case FLASH_CFI_16BIT:
-		retval = ((cptr.wp[0] & cword.w) == cword.w);
-		break;
-	case FLASH_CFI_32BIT:
-		retval = ((cptr.lp[0] & cword.l) == cword.l);
-		break;
-	default:
-		retval = 0;
-		break;
-	}
-	return retval;
-}
-
-/*-----------------------------------------------------------------------
- * detect if flash is compatible with the Common Flash Interface (CFI)
- * http://www.jedec.org/download/search/jesd68.pdf
- *
-*/
-static int flash_detect_cfi(flash_info_t * info)
-{
-
-	for(info->portwidth=FLASH_CFI_8BIT; info->portwidth <= FLASH_CFI_32BIT;
-	    info->portwidth <<= 1) {
-		for(info->chipwidth =FLASH_CFI_BY8;
-		    info->chipwidth <= info->portwidth;
-		    info->chipwidth <<= 1) {
-			flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
-			flash_write_cmd(info, 0, FLASH_OFFSET_CFI, FLASH_CMD_CFI);
-			if(flash_isequal(info, 0, FLASH_OFFSET_CFI_RESP,'Q') &&
-			   flash_isequal(info, 0, FLASH_OFFSET_CFI_RESP + 1, 'R') &&
-			   flash_isequal(info, 0, FLASH_OFFSET_CFI_RESP + 2, 'Y'))
-				return 1;
-		}
-	}
-	return 0;
-}
-/*
- * The following code cannot be run from FLASH!
- *
- */
-static ulong flash_get_size (ulong base, int banknum)
-{
-	flash_info_t * info = &flash_info[banknum];
-	int i, j;
-	int sect_cnt;
-	unsigned long sector;
-	unsigned long tmp;
-	int size_ratio;
-	uchar num_erase_regions;
-	int  erase_region_size;
-	int  erase_region_count;
-
-	info->start[0] = base;
-
-	if(flash_detect_cfi(info)){
-#ifdef DEBUG_FLASH
-		printf("portwidth=%d chipwidth=%d\n", info->portwidth, info->chipwidth); /* test-only */
-#endif
-		size_ratio = info->portwidth / info->chipwidth;
-		num_erase_regions = flash_read_uchar(info, FLASH_OFFSET_NUM_ERASE_REGIONS);
-#ifdef DEBUG_FLASH
-		printf("found %d erase regions\n", num_erase_regions);
-#endif
-		sect_cnt = 0;
-		sector = base;
-		for(i = 0 ; i < num_erase_regions; i++) {
-			if(i > NUM_ERASE_REGIONS) {
-				printf("%d erase regions found, only %d used\n",
-				       num_erase_regions, NUM_ERASE_REGIONS);
-				break;
-			}
-			tmp = flash_read_long(info, 0, FLASH_OFFSET_ERASE_REGIONS);
-			erase_region_size = (tmp & 0xffff)? ((tmp & 0xffff) * 256): 128;
-			tmp >>= 16;
-			erase_region_count = (tmp & 0xffff) +1;
-			for(j = 0; j< erase_region_count; j++) {
-				info->start[sect_cnt] = sector;
-				sector += (erase_region_size * size_ratio);
-				info->protect[sect_cnt] = flash_isset(info, sect_cnt, FLASH_OFFSET_PROTECT, FLASH_STATUS_PROTECT);
-				sect_cnt++;
-			}
-		}
-
-		info->sector_count = sect_cnt;
-		/* multiply the size by the number of chips */
-		info->size = (1 << flash_read_uchar(info, FLASH_OFFSET_SIZE)) * size_ratio;
-		info->buffer_size = (1 << flash_read_ushort(info, 0, FLASH_OFFSET_BUFFER_SIZE));
-		tmp = 1 << flash_read_uchar(info, FLASH_OFFSET_ETOUT);
-		info->erase_blk_tout = (tmp * (1 << flash_read_uchar(info, FLASH_OFFSET_EMAX_TOUT)));
-		tmp = 1 << flash_read_uchar(info, FLASH_OFFSET_WBTOUT);
-		info->buffer_write_tout = (tmp * (1 << flash_read_uchar(info, FLASH_OFFSET_WBMAX_TOUT)));
-		tmp = 1 << flash_read_uchar(info, FLASH_OFFSET_WTOUT);
-		info->write_tout = (tmp * (1 << flash_read_uchar(info, FLASH_OFFSET_WMAX_TOUT)))/ 1000;
-		info->flash_id = FLASH_MAN_CFI;
-	}
-
-	flash_write_cmd(info, 0, 0, FLASH_CMD_RESET);
-	return(info->size);
-}
-
-
-/*-----------------------------------------------------------------------
- */
-static int flash_write_cfiword (flash_info_t *info, ulong dest, cfiword_t cword)
-{
-
-	cfiptr_t ctladdr;
-	cfiptr_t cptr;
-	int flag;
-
-	ctladdr.cp = flash_make_addr(info, 0, 0);
-	cptr.cp = (uchar *)dest;
-
-
-	/* Check if Flash is (sufficiently) erased */
-	switch(info->portwidth) {
-	case FLASH_CFI_8BIT:
-		flag = ((cptr.cp[0] & cword.c) == cword.c);
-		break;
-	case FLASH_CFI_16BIT:
-		flag = ((cptr.wp[0] & cword.w) == cword.w);
-		break;
-	case FLASH_CFI_32BIT:
-		flag = ((cptr.lp[0] & cword.l)	== cword.l);
-		break;
-	default:
-		return 2;
-	}
-	if(!flag)
-		return 2;
-
-	/* Disable interrupts which might cause a timeout here */
-	flag = disable_interrupts();
-
-	flash_write_cmd(info, 0, 0, FLASH_CMD_CLEAR_STATUS);
-	flash_write_cmd(info, 0, 0, FLASH_CMD_WRITE);
-
-	switch(info->portwidth) {
-	case FLASH_CFI_8BIT:
-		cptr.cp[0] = cword.c;
-		break;
-	case FLASH_CFI_16BIT:
-		cptr.wp[0] = cword.w;
-		break;
-	case FLASH_CFI_32BIT:
-		cptr.lp[0] = cword.l;
-		break;
-	}
-
-	/* re-enable interrupts if necessary */
-	if(flag)
-		enable_interrupts();
-
-	return flash_full_status_check(info, 0, info->write_tout, "write");
-}
-
-#ifdef CFG_FLASH_USE_BUFFER_WRITE
-
-/* loop through the sectors from the highest address
- * when the passed address is greater or equal to the sector address
- * we have a match
- */
-static int find_sector(flash_info_t *info, ulong addr)
-{
-	int sector;
-	for(sector = info->sector_count - 1; sector >= 0; sector--) {
-		if(addr >= info->start[sector])
-			break;
-	}
-	return sector;
-}
-
-static int flash_write_cfibuffer(flash_info_t * info, ulong dest, uchar * cp, int len)
-{
-
-	int sector;
-	int cnt;
-	int retcode;
-	volatile cfiptr_t src;
-	volatile cfiptr_t dst;
-
-	src.cp = cp;
-	dst.cp = (uchar *)dest;
-	sector = find_sector(info, dest);
-	flash_write_cmd(info, sector, 0, FLASH_CMD_CLEAR_STATUS);
-	flash_write_cmd(info, sector, 0, FLASH_CMD_WRITE_TO_BUFFER);
-	if((retcode = flash_status_check(info, sector, info->buffer_write_tout,
-					 "write to buffer")) == ERR_OK) {
-		switch(info->portwidth) {
-		case FLASH_CFI_8BIT:
-			cnt = len;
-			break;
-		case FLASH_CFI_16BIT:
-			cnt = len >> 1;
-			break;
-		case FLASH_CFI_32BIT:
-			cnt = len >> 2;
-			break;
-		default:
-			return ERR_INVAL;
-			break;
-		}
-		flash_write_cmd(info, sector, 0, (uchar)cnt-1);
-		while(cnt-- > 0) {
-			switch(info->portwidth) {
-			case FLASH_CFI_8BIT:
-				*dst.cp++ = *src.cp++;
-				break;
-			case FLASH_CFI_16BIT:
-				*dst.wp++ = *src.wp++;
-				break;
-			case FLASH_CFI_32BIT:
-				*dst.lp++ = *src.lp++;
-				break;
-			default:
-				return ERR_INVAL;
-				break;
-			}
-		}
-		flash_write_cmd(info, sector, 0, FLASH_CMD_WRITE_BUFFER_CONFIRM);
-		retcode = flash_full_status_check(info, sector, info->buffer_write_tout,
-					     "buffer write");
-	}
-	flash_write_cmd(info, sector, 0, FLASH_CMD_CLEAR_STATUS);
-	return retcode;
-}
-#endif /* CFG_USE_FLASH_BUFFER_WRITE */
-- 
1.5.3




From matthias.fuchs at esd-electronics.com  Mon Apr 21 14:42:11 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 14:42:11 +0200
Subject: [U-Boot-Users] [PATCH 3/5] 4xx: Update APC405 board support
Message-ID: <200804211442.12130.matthias.fuchs@esd-electronics.com>

- enable esd's auto_update mechanism
- fix LCD support on latest hardware revision (uses other LCD controller)
- support alternative flash layout on rev. 1.8 boards
- coding style cleanup

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/apc405/Makefile |    4 +-
 board/esd/apc405/apc405.c |  360 ++++++++++++++++++++++++++++++---------------
 2 files changed, 241 insertions(+), 123 deletions(-)

diff --git a/board/esd/apc405/Makefile b/board/esd/apc405/Makefile
index 024997e..c57cd6b 100644
--- a/board/esd/apc405/Makefile
+++ b/board/esd/apc405/Makefile
@@ -28,7 +28,9 @@ endif
 
 LIB	= $(obj)lib$(BOARD).a
 
-COBJS	= $(BOARD).o strataflash.o ../common/misc.o
+COBJS	= $(BOARD).o \
+	../common/misc.o \
+	../common/auto_update.o
 
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS))
diff --git a/board/esd/apc405/apc405.c b/board/esd/apc405/apc405.c
index 078df00..b663184 100644
--- a/board/esd/apc405/apc405.c
+++ b/board/esd/apc405/apc405.c
@@ -1,4 +1,7 @@
 /*
+ * (C) Copyright 2005-2008
+ * Matthias Fuchs, esd gmbh germany, matthias.fuchs at esd-electronics.com
+ *
  * (C) Copyright 2001-2003
  * Stefan Roese, esd gmbh germany, stefan.roese at esd-electronics.com
  *
@@ -23,17 +26,22 @@
 
 #include <common.h>
 #include <asm/processor.h>
+#include <asm/io.h>
 #include <command.h>
 #include <malloc.h>
+#include <flash.h>
+#include <asm/4xx_pci.h>
+#include <pci.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#if 0
-#define FPGA_DEBUG
-#endif
+#undef FPGA_DEBUG
 
 extern int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
 extern void lxt971_no_sleep(void);
+extern ulong flash_get_size (ulong base, int banknum);
+
+int flash_banks = CFG_MAX_FLASH_BANKS_DETECT;
 
 /* fpga configuration data - gzip compressed and generated by bin2c */
 const unsigned char fpgadata[] =
@@ -46,82 +54,94 @@ const unsigned char fpgadata[] =
  */
 #include "../common/fpga.c"
 
-
 /* Prototypes */
 int gunzip(void *, int, unsigned char *, unsigned long *);
 
-
 #ifdef CONFIG_LCD_USED
 /* logo bitmap data - gzip compressed and generated by bin2c */
 unsigned char logo_bmp[] =
 {
-#include CFG_LCD_LOGO_NAME
+#include "logo_640_480_24bpp.c"
 };
 
 /*
  * include common lcd code (for esd boards)
  */
 #include "../common/lcd.c"
-
-#include CFG_LCD_HEADER_NAME
+#include "../common/s1d13505_640_480_16bpp.h"
+#include "../common/s1d13806_640_480_16bpp.h"
 #endif /* CONFIG_LCD_USED */
 
+/*
+ * include common auto-update code (for esd boards)
+ */
+#include "../common/auto_update.h"
+
+au_image_t au_image[] = {
+	{"preinst.img", 0, -1, AU_SCRIPT},
+	{"u-boot.img", 0xfff80000, 0x00080000, AU_FIRMWARE | AU_PROTECT},
+	{"pImage", 0xfe000000, 0x00100000, AU_NOR | AU_PROTECT},
+	{"pImage.initrd", 0xfe100000, 0x00400000, AU_NOR | AU_PROTECT},
+	{"work.img", 0xfe500000, 0x01400000, AU_NOR},
+	{"data.img", 0xff900000, 0x00580000, AU_NOR},
+	{"logo.img", 0xffe80000, 0x00100000, AU_NOR | AU_PROTECT},
+	{"postinst.img", 0, 0, AU_SCRIPT},
+};
+
+int N_AU_IMAGES = (sizeof(au_image) / sizeof(au_image[0]));
 
 int board_revision(void)
 {
 	unsigned long cntrl0Reg;
-	unsigned long value;
+	volatile unsigned long value;
 
 	/*
 	 * Get version of APC405 board from GPIO's
 	 */
 
-	/*
-	 * Setup GPIO pins (CS2/GPIO11 and CS3/GPIO12 as GPIO)
-	 */
+	/* Setup GPIO pins (CS2/GPIO11, CS3/GPIO12 and CS4/GPIO13 as GPIO) */
 	cntrl0Reg = mfdcr(cntrl0);
-	mtdcr(cntrl0, cntrl0Reg | 0x03000000);
-	out32(GPIO0_ODR, in32(GPIO0_ODR) & ~0x00180000);
-	out32(GPIO0_TCR, in32(GPIO0_TCR) & ~0x00180000);
-	udelay(1000);                   /* wait some time before reading input */
-	value = in32(GPIO0_IR) & 0x00180000;       /* get config bits */
+	mtdcr(cntrl0, cntrl0Reg | 0x03800000);
+	out_be32((void*)GPIO0_ODR, in_be32((void*)GPIO0_ODR) & ~0x001c0000);
+	out_be32((void*)GPIO0_TCR, in_be32((void*)GPIO0_TCR) & ~0x001c0000);
+
+	/* wait some time before reading input */
+	udelay(1000);
 
+	/* get config bits */
+	value = in_be32((void*)GPIO0_IR) & 0x001c0000;
 	/*
 	 * Restore GPIO settings
 	 */
 	mtdcr(cntrl0, cntrl0Reg);
 
 	switch (value) {
-	case 0x00180000:
-		/* CS2==1 && CS3==1 -> version <= 1.2 */
+	case 0x001c0000:
+		/* CS2==1 && CS3==1 && CS4==1 -> version <= 1.2 */
 		return 2;
-	case 0x00080000:
-		/* CS2==0 && CS3==1 -> version 1.3 */
+	case 0x000c0000:
+		/* CS2==0 && CS3==1 && CS4==1 -> version 1.3 */
 		return 3;
-#if 0 /* not yet manufactured ! */
-	case 0x00100000:
-		/* CS2==1 && CS3==0 -> version 1.4 */
-		return 4;
-	case 0x00000000:
-		/* CS2==0 && CS3==0 -> version 1.5 */
-		return 5;
-#endif
+	case 0x00180000:
+		/* CS2==1 && CS3==1 && CS4==0 -> version 1.6 */
+		return 6;
+	case 0x00140000:
+		/* CS2==1 && CS3==0 && CS4==1 -> version 1.8 */
+		return 8;
 	default:
 		/* should not be reached! */
 		return 0;
 	}
 }
 
-
 int board_early_init_f (void)
 {
 	/*
-	 * First pull fpga-prg pin low, to disable fpga logic (on version 2 board)
+	 * First pull fpga-prg pin low, to disable fpga logic
 	 */
-	out32(GPIO0_ODR, 0x00000000);        /* no open drain pins      */
-	out32(GPIO0_TCR, CFG_FPGA_PRG);      /* setup for output        */
-	out32(GPIO0_OR,  CFG_FPGA_PRG);      /* set output pins to high */
-	out32(GPIO0_OR, 0);                  /* pull prg low            */
+	out_be32((void*)GPIO0_ODR, 0x00000000);        /* no open drain pins */
+	out_be32((void*)GPIO0_TCR, CFG_FPGA_PRG);      /* setup for output   */
+	out_be32((void*)GPIO0_OR, 0);                  /* pull prg low       */
 
 	/*
 	 * IRQ 0-15  405GP internally generated; active high; level sensitive
@@ -140,48 +160,61 @@ int board_early_init_f (void)
 	mtdcr(uiccr, 0x00000000);       /* set all to be non-critical*/
 	mtdcr(uicpr, 0xFFFFFF81);       /* set int polarities */
 	mtdcr(uictr, 0x10000000);       /* set int trigger levels */
-	mtdcr(uicvcr, 0x00000001);      /* set vect base=0,INT0 highest priority*/
+	mtdcr(uicvcr, 0x00000001);      /* set vect base=0 */
 	mtdcr(uicsr, 0xFFFFFFFF);       /* clear all ints */
 
 	/*
-	 * EBC Configuration Register: set ready timeout to 512 ebc-clks -> ca. 15 us
+	 * EBC Configuration Register: set ready timeout to 512 ebc-clks
+	 */
+	mtebc(epcr, 0xa8400000); /* ebc always driven */
+
+	/*
+	 * New boards have a single 32MB flash connected to CS0
+	 * instead of two 16MB flashes on CS0+1.
 	 */
-#if 1 /* test-only */
-	mtebc (epcr, 0xa8400000); /* ebc always driven */
-#else
-	mtebc (epcr, 0x28400000); /* ebc in high-z */
-#endif
+	if (board_revision() >= 8) {
+		/* disable CS1 */
+		mtebc(pb1ap, 0);
+		mtebc(pb1cr, 0);
+
+		/* resize CS0 to 32MB */
+		mtebc(pb0ap, CFG_EBC_PB0AP_HWREV8);
+		mtebc(pb0cr, CFG_EBC_PB0CR_HWREV8);
+	}
 
 	return 0;
 }
 
-
-/* ------------------------------------------------------------------------- */
-
-int misc_init_f (void)
+int board_early_init_r(void)
 {
-	return 0;  /* dummy implementation */
+	if (gd->board_type >= 8)
+		flash_banks = 1;
+
+	return 0;
 }
 
+#define FUJI_BASE    0xf0100200
+#define LCDBL_PWM    0xa0
+#define LCDBL_PWMMIN 0xa4
+#define LCDBL_PWMMAX 0xa8
 
-int misc_init_r (void)
+int misc_init_r(void)
 {
-	volatile unsigned short *fpga_mode =
-		(unsigned short *)((ulong)CFG_FPGA_BASE_ADDR + CFG_FPGA_CTRL);
-	volatile unsigned short *fpga_ctrl2 =
-		(unsigned short *)((ulong)CFG_FPGA_BASE_ADDR + CFG_FPGA_CTRL2);
-	volatile unsigned char *duart0_mcr =
-		(unsigned char *)((ulong)DUART0_BA + 4);
-	volatile unsigned char *duart1_mcr =
-		(unsigned char *)((ulong)DUART1_BA + 4);
-	volatile unsigned short *fuji_lcdbl_pwm =
-		(unsigned short *)((ulong)0xf0100200 + 0xa0);
+	u16 *fpga_mode = (u16 *)(CFG_FPGA_BASE_ADDR + CFG_FPGA_CTRL);
+	u16 *fpga_ctrl2 =(u16 *)(CFG_FPGA_BASE_ADDR + CFG_FPGA_CTRL2);
+	u8 *duart0_mcr = (u8 *)(DUART0_BA + 4);
+	u8 *duart1_mcr = (u8 *)(DUART1_BA + 4);
 	unsigned char *dst;
 	ulong len = sizeof(fpgadata);
 	int status;
 	int index;
 	int i;
 	unsigned long cntrl0Reg;
+	char *str;
+	uchar *logo_addr;
+	ulong logo_size;
+	ushort minb, maxb;
+	int result;
 
 	/*
 	 * Setup GPIO pins (CS6+CS7 as GPIO)
@@ -190,9 +223,9 @@ int misc_init_r (void)
 	mtdcr(cntrl0, cntrl0Reg | 0x00300000);
 
 	dst = malloc(CFG_FPGA_MAX_SIZE);
-	if (gunzip (dst, CFG_FPGA_MAX_SIZE, (uchar *)fpgadata, &len) != 0) {
-		printf ("GUNZIP ERROR - must RESET board to recover\n");
-		do_reset (NULL, 0, 0, NULL);
+	if (gunzip(dst, CFG_FPGA_MAX_SIZE, (uchar *)fpgadata, &len) != 0) {
+		printf("GUNZIP ERROR - must RESET board to recover\n");
+		do_reset(NULL, 0, 0, NULL);
 	}
 
 	status = fpga_boot(dst, len);
@@ -200,31 +233,34 @@ int misc_init_r (void)
 		printf("\nFPGA: Booting failed ");
 		switch (status) {
 		case ERROR_FPGA_PRG_INIT_LOW:
-			printf("(Timeout: INIT not low after asserting PROGRAM*)\n ");
+			printf("(Timeout: "
+			       "INIT not low after asserting PROGRAM*)\n ");
 			break;
 		case ERROR_FPGA_PRG_INIT_HIGH:
-			printf("(Timeout: INIT not high after deasserting PROGRAM*)\n ");
+			printf("(Timeout: "
+			       "INIT not high after deasserting PROGRAM*)\n ");
 			break;
 		case ERROR_FPGA_PRG_DONE:
-			printf("(Timeout: DONE not high after programming FPGA)\n ");
+			printf("(Timeout: "
+			       "DONE not high after programming FPGA)\n ");
 			break;
 		}
 
 		/* display infos on fpgaimage */
 		index = 15;
-		for (i=0; i<4; i++) {
+		for (i = 0; i < 4; i++) {
 			len = dst[index];
 			printf("FPGA: %s\n", &(dst[index+1]));
-			index += len+3;
+			index += len + 3;
 		}
-		putc ('\n');
+		putc('\n');
 		/* delayed reboot */
-		for (i=20; i>0; i--) {
+		for (i = 20; i > 0; i--) {
 			printf("Rebooting in %2d seconds \r",i);
-			for (index=0;index<1000;index++)
+			for (index = 0; index < 1000; index++)
 				udelay(1000);
 		}
-		putc ('\n');
+		putc('\n');
 		do_reset(NULL, 0, 0, NULL);
 	}
 
@@ -235,12 +271,12 @@ int misc_init_r (void)
 
 	/* display infos on fpgaimage */
 	index = 15;
-	for (i=0; i<4; i++) {
+	for (i = 0; i < 4; i++) {
 		len = dst[index];
-		printf("%s ", &(dst[index+1]));
-		index += len+3;
+		printf("%s ", &(dst[index + 1]));
+		index += len + 3;
 	}
-	putc ('\n');
+	putc('\n');
 
 	free(dst);
 
@@ -255,51 +291,117 @@ int misc_init_r (void)
 	/*
 	 * Write board revision in FPGA
 	 */
-	*fpga_ctrl2 = (*fpga_ctrl2 & 0xfff0) | (gd->board_type & 0x000f);
+	out_be16(fpga_ctrl2,
+		 (in_be16(fpga_ctrl2) & 0xfff0) | (gd->board_type & 0x000f));
 
 	/*
 	 * Enable power on PS/2 interface (with reset)
 	 */
-	*fpga_mode |= CFG_FPGA_CTRL_PS2_RESET;
+	out_be16(fpga_mode, in_be16(fpga_mode) | CFG_FPGA_CTRL_PS2_RESET);
 	for (i=0;i<100;i++)
 		udelay(1000);
 	udelay(1000);
-	*fpga_mode &= ~CFG_FPGA_CTRL_PS2_RESET;
+	out_be16(fpga_mode, in_be16(fpga_mode) & ~CFG_FPGA_CTRL_PS2_RESET);
 
 	/*
 	 * Enable interrupts in exar duart mcr[3]
 	 */
-	*duart0_mcr = 0x08;
-	*duart1_mcr = 0x08;
+	out_8(duart0_mcr, 0x08);
+	out_8(duart1_mcr, 0x08);
 
 	/*
 	 * Init lcd interface and display logo
 	 */
-	lcd_init((uchar *)CFG_LCD_BIG_REG, (uchar *)CFG_LCD_BIG_MEM,
-		 regs_13806_640_480_16bpp,
-		 sizeof(regs_13806_640_480_16bpp)/sizeof(regs_13806_640_480_16bpp[0]),
-		 logo_bmp, sizeof(logo_bmp));
+	str = getenv("splashimage");
+	if (str) {
+		logo_addr = (uchar *)simple_strtoul(str, NULL, 16);
+		logo_size = CFG_VIDEO_LOGO_MAX_SIZE;
+	} else {
+		logo_addr = logo_bmp;
+		logo_size = sizeof(logo_bmp);
+	}
+
+	if (gd->board_type >= 6) {
+		result = lcd_init((uchar *)CFG_LCD_BIG_REG,
+				  (uchar *)CFG_LCD_BIG_MEM,
+				  regs_13505_640_480_16bpp,
+				  sizeof(regs_13505_640_480_16bpp) /
+				  sizeof(regs_13505_640_480_16bpp[0]),
+				  logo_addr, logo_size);
+		if (result && str) {
+			/* retry with internal image */
+			logo_addr = logo_bmp;
+			logo_size = sizeof(logo_bmp);
+			lcd_init((uchar *)CFG_LCD_BIG_REG,
+				 (uchar *)CFG_LCD_BIG_MEM,
+				 regs_13505_640_480_16bpp,
+				 sizeof(regs_13505_640_480_16bpp) /
+				 sizeof(regs_13505_640_480_16bpp[0]),
+				 logo_addr, logo_size);
+		}
+	} else {
+		result = lcd_init((uchar *)CFG_LCD_BIG_REG,
+				  (uchar *)CFG_LCD_BIG_MEM,
+				  regs_13806_640_480_16bpp,
+				  sizeof(regs_13806_640_480_16bpp) /
+				  sizeof(regs_13806_640_480_16bpp[0]),
+				  logo_addr, logo_size);
+		if (result && str) {
+			/* retry with internal image */
+			logo_addr = logo_bmp;
+			logo_size = sizeof(logo_bmp);
+			lcd_init((uchar *)CFG_LCD_BIG_REG,
+				 (uchar *)CFG_LCD_BIG_MEM,
+				 regs_13806_640_480_16bpp,
+				 sizeof(regs_13806_640_480_16bpp) /
+				 sizeof(regs_13806_640_480_16bpp[0]),
+				 logo_addr, logo_size);
+		}
+	}
 
 	/*
 	 * Reset microcontroller and setup backlight PWM controller
 	 */
-	*fpga_mode |= 0x0014;
+	out_be16(fpga_mode, in_be16(fpga_mode) | 0x0014);
 	for (i=0;i<10;i++)
 		udelay(1000);
-	*fpga_mode |= 0x001c;
-	*fuji_lcdbl_pwm = 0x00ff;
+	out_be16(fpga_mode, in_be16(fpga_mode) | 0x001c);
+
+	minb = 0;
+	maxb = 0xff;
+	str = getenv("lcdbl");
+	if (str) {
+		minb = (ushort)simple_strtoul(str, &str, 16) & 0x00ff;
+		if (str && (*str=',')) {
+			str++;
+			maxb = (ushort)simple_strtoul(str, NULL, 16) & 0x00ff;
+		} else
+			minb = 0;
+
+		out_be16((u16 *)(FUJI_BASE + LCDBL_PWMMIN), minb);
+		out_be16((u16 *)(FUJI_BASE + LCDBL_PWMMAX), maxb);
+
+		printf("LCDBL: min=0x%02x, max=0x%02x\n", minb, maxb);
+	}
+	out_be16((u16 *)(FUJI_BASE + LCDBL_PWM), 0xff);
+
+	if (getenv("usb_self") == NULL) {
+		setenv("usb_load", CFG_USB_LOAD_COMMAND);
+		setenv("usbargs", CFG_USB_ARGS);
+		setenv("bootcmd", CONFIG_BOOTCOMMAND);
+		setenv("usb_self", CFG_USB_SELF_COMMAND);
+		saveenv();
+	}
 
 	return (0);
 }
 
-
 /*
  * Check Board Identity:
  */
-
 int checkboard (void)
 {
-	unsigned char str[64];
+	char str[64];
 	int i = getenv_r ("serial#", str, sizeof(str));
 
 	puts ("Board: ");
@@ -311,18 +413,11 @@ int checkboard (void)
 	}
 
 	gd->board_type = board_revision();
-	printf(", Rev 1.%ld\n", gd->board_type);
-
-	/*
-	 * Disable sleep mode in LXT971
-	 */
-	lxt971_no_sleep();
+	printf(", Rev. 1.%ld\n", gd->board_type);
 
 	return 0;
 }
 
-/* ------------------------------------------------------------------------- */
-
 long int initdram (int board_type)
 {
 	unsigned long val;
@@ -330,43 +425,64 @@ long int initdram (int board_type)
 	mtdcr(memcfga, mem_mb0cf);
 	val = mfdcr(memcfgd);
 
-#if 0
-	printf("\nmb0cf=%x\n", val); /* test-only */
-	printf("strap=%x\n", mfdcr(strap)); /* test-only */
-#endif
-
 	return (4*1024*1024 << ((val & 0x000e0000) >> 17));
 }
 
-/* ------------------------------------------------------------------------- */
-
-int testdram (void)
+#ifdef CONFIG_IDE_RESET
+void ide_set_reset(int on)
 {
-	/* TODO: XXX XXX XXX */
-	printf ("test: 16 MB - ok\n");
+	u16 *fpga_mode = (u16 *)(CFG_FPGA_BASE_ADDR + CFG_FPGA_CTRL);
 
-	return (0);
+	/*
+	 * Assert or deassert CompactFlash Reset Pin
+	 */
+	if (on) {
+		out_be16(fpga_mode,
+			 in_be16(fpga_mode) & ~CFG_FPGA_CTRL_CF_RESET);
+	} else {
+		out_be16(fpga_mode,
+			 in_be16(fpga_mode) | CFG_FPGA_CTRL_CF_RESET);
+	}
 }
+#endif /* CONFIG_IDE_RESET */
 
-/* ------------------------------------------------------------------------- */
+void reset_phy(void)
+{
+	/*
+	 * Disable sleep mode in LXT971
+	 */
+	lxt971_no_sleep();
+}
 
-#ifdef CONFIG_IDE_RESET
+#if defined(CONFIG_USB_OHCI_NEW) && defined(CFG_USB_OHCI_BOARD_INIT)
+int usb_board_init(void)
+{
+	return 0;
+}
 
-void ide_set_reset(int on)
+int usb_board_stop(void)
 {
-	volatile unsigned short *fpga_mode =
-		(unsigned short *)((ulong)CFG_FPGA_BASE_ADDR + CFG_FPGA_CTRL);
+	unsigned short tmp;
+	int i;
 
 	/*
-	 * Assert or deassert CompactFlash Reset Pin
+	 * reset PCI bus
+	 * This is required to make some very old Linux OHCI driver
+	 * work after U-Boot has used the OHCI controller.
 	 */
-	if (on) {		/* assert RESET */
-		*fpga_mode &= ~(CFG_FPGA_CTRL_CF_RESET);
-	} else {		/* release RESET */
-		*fpga_mode |= CFG_FPGA_CTRL_CF_RESET;
-	}
-}
+	pci_read_config_word(PCIDEVID_405GP, PCIBRDGOPT2, &tmp);
+	pci_write_config_word(PCIDEVID_405GP, PCIBRDGOPT2, (tmp | 0x1000));
 
-#endif /* CONFIG_IDE_RESET */
+	for (i = 0; i < 100; i++)
+		udelay(1000);
 
-/* ------------------------------------------------------------------------- */
+	pci_write_config_word(PCIDEVID_405GP, PCIBRDGOPT2, tmp);
+	return 0;
+}
+
+int usb_board_init_fail(void)
+{
+	usb_board_stop();
+	return 0;
+}
+#endif /* defined(CONFIG_USB_OHCI) && defined(CFG_USB_OHCI_BOARD_INIT) */
-- 
1.5.3




From matthias.fuchs at esd-electronics.com  Mon Apr 21 14:42:17 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 14:42:17 +0200
Subject: [U-Boot-Users] [PATCH 4/5] 4xx: Update APC405 configuration
Message-ID: <200804211442.18126.matthias.fuchs@esd-electronics.com>

- enable esd's auto_update mechanism
- support alternative flash layout on rev. 1.8 boards
- update default environment
- use common CFI flash driver
- coding style cleanup

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 include/configs/APC405.h |  346 ++++++++++++++++++++++++++--------------------
 1 files changed, 193 insertions(+), 153 deletions(-)

diff --git a/include/configs/APC405.h b/include/configs/APC405.h
index f6495e4..5b04888 100644
--- a/include/configs/APC405.h
+++ b/include/configs/APC405.h
@@ -1,4 +1,7 @@
 /*
+ * (C) Copyright 2005-2008
+ * Matthias Fuchs, esd gmbh germany, matthias.fuchs at esd-electronics.com
+ *
  * (C) Copyright 2001-2004
  * Stefan Roese, esd gmbh germany, stefan.roese at esd-electronics.com
  *
@@ -24,7 +27,6 @@
 /*
  * board/config.h - configuration options, board specific
  */
-
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
@@ -32,42 +34,78 @@
  * High Level Configuration Options
  * (easy to change)
  */
-
 #define CONFIG_405GP		1	/* This is a PPC405 CPU		*/
 #define CONFIG_4xx		1	/* ...member of PPC4xx family   */
 #define CONFIG_APCG405		1	/* ...on a APC405 board 	*/
 
 #define CONFIG_BOARD_EARLY_INIT_F 1	/* call board_early_init_f()	*/
+#define CONFIG_BOARD_EARLY_INIT_R 1
 #define CONFIG_MISC_INIT_R      1       /* call misc_init_r()           */
 
 #define CONFIG_SYS_CLK_FREQ     33333400 /* external frequency to pll   */
 
 #define CONFIG_BOARD_TYPES	1	/* support board types		*/
 
-#define CONFIG_BAUDRATE		9600
-#define CONFIG_BOOTDELAY	3	/* autoboot after 3 seconds	*/
+#define CONFIG_BAUDRATE		115200
+#define CONFIG_BOOTDELAY	1	/* autoboot after 3 seconds	*/
 
 #undef	CONFIG_BOOTARGS
-#define CONFIG_RAMBOOTCOMMAND							\
-	"setenv bootargs root=/dev/ram rw nfsroot=${serverip}:${rootpath} "	\
-	"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off;"	\
-	"bootm ffc00000 ffca0000"
-#define CONFIG_NFSBOOTCOMMAND							\
-	"setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath} "	\
-	"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off;"	\
-	"bootm ffc00000"
-#define CONFIG_BOOTCOMMAND CONFIG_RAMBOOTCOMMAND
+
+#define CFG_USB_LOAD_COMMAND	"fatload usb 0 200000 pImage;"		\
+				"fatload usb 0 300000 pImage.initrd"
+#define CFG_USB_SELF_COMMAND	"usb start;run usb_load;usb stop;"	\
+				"run ramargs addip addcon usbargs;"	\
+				"bootm 200000 300000"
+#define CFG_USB_ARGS		"setenv bootargs $(bootargs) usbboot=1"
+
+#define CONFIG_EXTRA_ENV_SETTINGS                                       \
+        "hostname=abg405\0"                                             \
+        "bd_type=abg405\0"                                              \
+	"serial#=AA0000\0"                                              \
+        "kernel_addr=fe000000\0"                                        \
+        "ramdisk_addr=fe100000\0"                                       \
+        "ramargs=setenv bootargs root=/dev/ram rw\0"                    \
+        "nfsargs=setenv bootargs root=/dev/nfs rw "                     \
+                "nfsroot=$(serverip):$(rootpath)\0"                     \
+        "addip=setenv bootargs $(bootargs) "                            \
+                "ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask)"      \
+                ":$(hostname)::off panic=1\0"                           \
+        "addcon=setenv bootargs $(bootargs) console=ttyS0,$(baudrate)"  \
+                " $(optargs)\0"                                         \
+        "flash_self=run ramargs addip addcon;"                          \
+                "bootm $(kernel_addr) $(ramdisk_addr)\0"                \
+        "net_nfs=tftp 200000 $(img);run nfsargs addip addcon;"          \
+                "bootm\0"                                               \
+        "rootpath=/tftpboot/abg405/target_root\0"                       \
+        "img=/tftpboot/abg405/pImage\0"                                 \
+        "load=tftp 100000 /tftpboot/abg405/u-boot.bin\0"		\
+        "update=protect off fff80000 ffffffff;era fff80000 ffffffff;"   \
+                "cp.b 100000 fff80000 80000\0"                          \
+        "ipaddr=10.0.111.111\0"                                         \
+        "netmask=255.255.0.0\0"                                         \
+        "serverip=10.0.0.190\0"						\
+        "splashimage=ffe80000\0"                                        \
+	"usb_load="CFG_USB_LOAD_COMMAND"\0"				\
+	"usb_self="CFG_USB_SELF_COMMAND"\0"				\
+	"usbargs="CFG_USB_ARGS"\0"					\
+        ""
+#define CONFIG_BOOTCOMMAND	"run flash_self;run usb_self"
+
+#define CONFIG_ETHADDR		00:02:27:8e:00:00
 
 #define CONFIG_LOADS_ECHO	1	/* echo on for serial download	*/
 #define CFG_LOADS_BAUD_CHANGE	1	/* allow baudrate change	*/
 
+#define CONFIG_NET_MULTI	1
+#undef  CONFIG_HAS_ETH1
+
 #define CONFIG_MII		1	/* MII PHY management		*/
-#define	CONFIG_PHY_ADDR		0	/* PHY address			*/
-#define CONFIG_LXT971_NO_SLEEP  1       /* disable sleep mode in LXT971 */
+#define CONFIG_PHY_ADDR		0	/* PHY address			*/
+#define CONFIG_LXT971_NO_SLEEP	1
+#define CONFIG_RESET_PHY_R	1	/* use reset_phy() */
 
 #define CONFIG_PHY_CLK_FREQ	EMAC_STACR_CLK_66MHZ /* 66 MHz OPB clock*/
 
-
 /*
  * BOOTP options
  */
@@ -76,7 +114,6 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
-
 /*
  * Command line configuration.
  */
@@ -93,95 +130,86 @@
 #define CONFIG_CMD_MII
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_EEPROM
+#define CONFIG_CMD_USB
+#define CONFIG_CMD_AUTOSCRIPT
 
 #define CONFIG_MAC_PARTITION
 #define CONFIG_DOS_PARTITION
 
 #define CONFIG_SUPPORT_VFAT
 
-#undef  CONFIG_WATCHDOG			/* watchdog disabled		*/
+#define CONFIG_AUTO_UPDATE	1	/* autoupdate via CF or USB */
 
-#define CONFIG_RTC_MC146818             /* DS1685 is MC146818 compatible*/
-#define CFG_RTC_REG_BASE_ADDR	 0xF0000500 /* RTC Base Address         */
+#undef  CONFIG_WATCHDOG			/* watchdog disabled */
 
-#define	CONFIG_SDRAM_BANK0	1	/* init onboard SDRAM bank 0	*/
+#define CONFIG_RTC_MC146818		/* DS1685 is MC146818 compatible*/
+#define CFG_RTC_REG_BASE_ADDR 0xF0000500 /* RTC Base Address */
+
+#define CONFIG_SDRAM_BANK0	1	/* init onboard SDRAM bank 0 */
 
 /*
  * Miscellaneous configurable options
  */
-#define CFG_LONGHELP			/* undef to save memory		*/
-#define CFG_PROMPT	"=> "		/* Monitor Command Prompt	*/
-
-#undef	CFG_HUSH_PARSER			/* use "hush" command parser	*/
-#ifdef	CFG_HUSH_PARSER
-#define	CFG_PROMPT_HUSH_PS2	"> "
-#endif
+#define CFG_LONGHELP			/* undef to save memory */
+#define CFG_PROMPT	"=> "		/* Monitor Command Prompt */
+#define CONFIG_CMDLINE_EDITING	1	/* add command line history */
 
 #if defined(CONFIG_CMD_KGDB)
-#define	CFG_CBSIZE	1024		/* Console I/O Buffer Size	*/
+#define CFG_CBSIZE	1024		/* Console I/O Buffer Size */
 #else
-#define	CFG_CBSIZE	256		/* Console I/O Buffer Size	*/
+#define CFG_CBSIZE	256		/* Console I/O Buffer Size */
 #endif
 #define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /* Print Buffer Size */
-#define CFG_MAXARGS	16		/* max number of command args	*/
-#define CFG_BARGSIZE	CFG_CBSIZE	/* Boot Argument Buffer Size	*/
+#define CFG_MAXARGS	16		/* max number of command args */
+#define CFG_BARGSIZE	CFG_CBSIZE	/* Boot Argument Buffer Size */
 
-#define CFG_DEVICE_NULLDEV      1       /* include nulldev device       */
+#define CFG_DEVICE_NULLDEV	1	/* include nulldev device */
 
-#define CFG_CONSOLE_INFO_QUIET  1       /* don't print console @ startup*/
+#define CFG_CONSOLE_INFO_QUIET	1	/* don't print console @ startup*/
 
-#define CFG_MEMTEST_START	0x0400000	/* memtest works on	*/
-#define CFG_MEMTEST_END		0x0C00000	/* 4 ... 12 MB in DRAM	*/
+#define CFG_MEMTEST_START	0x0400000 /* memtest works on */
+#define CFG_MEMTEST_END		0x0C00000 /* 4 ... 12 MB in DRAM */
 
-#if 1 /* test-only */
 #define CFG_EXT_SERIAL_CLOCK    14745600 /* use external serial clock   */
-#else
-#undef  CFG_EXT_SERIAL_CLOCK           /* no external serial clock used */
-#define CFG_IGNORE_405_UART_ERRATA_59   /* ignore ppc405gp errata #59   */
-#define CFG_BASE_BAUD       691200
-#endif
 
 /* The following table includes the supported baudrates */
 #define CFG_BAUDRATE_TABLE      \
-	{ 300, 600, 1200, 2400, 4800, 9600, 19200, 38400,     \
+	{ 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, \
 	 57600, 115200, 230400, 460800, 921600 }
 
 #define CFG_LOAD_ADDR	0x100000	/* default load address */
 #define CFG_EXTBDINFO	1		/* To use extended board_into (bd_t) */
 
-#define	CFG_HZ		1000		/* decrementer freq: 1 ms ticks	*/
+#define	CFG_HZ		1000		/* decrementer freq: 1 ms ticks */
 
 #define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0 */
 
 /* Only interrupt boot if space is pressed */
 /* If a long serial cable is connected but */
 /* other end is dead, garbage will be read */
-#define CONFIG_AUTOBOOT_KEYED 1
-#define CONFIG_AUTOBOOT_PROMPT "Press SPACE to abort autoboot in %d seconds\n"
-#define CONFIG_AUTOBOOT_DELAY_STR "d"
+#define CONFIG_AUTOBOOT_KEYED	1
+#define CONFIG_AUTOBOOT_PROMPT	"Press SPACE to abort autoboot in %d seconds\n"
+#undef CONFIG_AUTOBOOT_DELAY_STR
 #define CONFIG_AUTOBOOT_STOP_STR " "
 
-#define CONFIG_VERSION_VARIABLE	1       /* include version env variable */
+#define CONFIG_VERSION_VARIABLE	1	/* include version env variable */
 
-#define CFG_RX_ETH_BUFFER	16      /* use 16 rx buffer on 405 emac */
+#define CFG_RX_ETH_BUFFER	16	/* use 16 rx buffer on 405 emac */
 
-/*-----------------------------------------------------------------------
+/*
  * PCI stuff
- *-----------------------------------------------------------------------
  */
-#define PCI_HOST_ADAPTER 0              /* configure as pci adapter     */
-#define PCI_HOST_FORCE  1               /* configure as pci host        */
-#define PCI_HOST_AUTO   2               /* detected via arbiter enable  */
+#define PCI_HOST_ADAPTER	0	/* configure as pci adapter     */
+#define PCI_HOST_FORCE		1	/* configure as pci host        */
+#define PCI_HOST_AUTO		2	/* detected via arbiter enable  */
 
-#define CONFIG_PCI			/* include pci support	        */
-#define CONFIG_PCI_HOST	PCI_HOST_FORCE  /* select pci host function     */
+#define CONFIG_PCI			/* include pci support          */
+#define CONFIG_PCI_HOST PCI_HOST_FORCE	/* select pci host function     */
 #define CONFIG_PCI_PNP			/* do pci plug-and-play         */
 					/* resource configuration       */
 
-#define CONFIG_PCI_SCAN_SHOW            /* print pci devices @ startup  */
-
-#define CONFIG_PCI_CONFIG_HOST_BRIDGE 1 /* don't skip host bridge config*/
-
+#define CONFIG_PCI_SCAN_SHOW		/* print pci devices @ startup  */
+#define CONFIG_PCI_SKIP_HOST_BRIDGE 1
 #define CFG_PCI_SUBSYS_VENDORID 0x12FE  /* PCI Vendor ID: esd gmbh      */
 #define CFG_PCI_SUBSYS_DEVICEID 0x0405  /* PCI Device ID: CPCI-405      */
 #define CFG_PCI_CLASSCODE       0x0b20  /* PCI Class Code: Processor/PPC*/
@@ -192,119 +220,123 @@
 #define CFG_PCI_PTM2MS  0xffc00001      /* 4MB, enable                  */
 #define CFG_PCI_PTM2PCI 0x04000000      /* Host: use this pci address   */
 
-/*-----------------------------------------------------------------------
+/*
  * IDE/ATA stuff
- *-----------------------------------------------------------------------
  */
-#undef  CONFIG_IDE_8xx_DIRECT               /* no pcmcia interface required */
-#undef  CONFIG_IDE_LED                  /* no led for ide supported     */
-#define CONFIG_IDE_RESET	1	/* reset for ide supported	*/
+#undef  CONFIG_IDE_8xx_DIRECT		/* no pcmcia interface required */
+#undef  CONFIG_IDE_LED			/* no led for ide supported */
+#define CONFIG_IDE_RESET	1	/* reset for ide supported */
 
-#define	CFG_IDE_MAXBUS	        1		/* max. 1 IDE busses	*/
-#define	CFG_IDE_MAXDEVICE	(CFG_IDE_MAXBUS*1) /* max. 1 drives per IDE bus */
+#define CFG_IDE_MAXBUS		1		/* max. 1 IDE busses */
+#define CFG_IDE_MAXDEVICE	(CFG_IDE_MAXBUS) /* max. 1 drives per IDE bus */
 
-#define	CFG_ATA_BASE_ADDR	0xF0100000
-#define	CFG_ATA_IDE0_OFFSET	0x0000
+#define CFG_ATA_BASE_ADDR	0xF0100000
+#define CFG_ATA_IDE0_OFFSET	0x0000
 
-#define CFG_ATA_DATA_OFFSET	0x0000	/* Offset for data I/O			*/
-#define	CFG_ATA_REG_OFFSET	0x0000	/* Offset for normal register accesses	*/
-#define CFG_ATA_ALT_OFFSET	0x0000	/* Offset for alternate registers	*/
+#define CFG_ATA_DATA_OFFSET	0x0000	/* Offset for data I/O */
+#define CFG_ATA_REG_OFFSET	0x0000	/* Offset for normal register access */
+#define CFG_ATA_ALT_OFFSET	0x0000	/* Offset for alternate registers */
 
-/*-----------------------------------------------------------------------
+/*
  * Start addresses for the final memory configuration
  * (Set up by the startup code)
  * Please note that CFG_SDRAM_BASE _must_ start at 0
  */
 #define CFG_SDRAM_BASE		0x00000000
 #define CFG_MONITOR_BASE	0xFFF80000
-#define CFG_MONITOR_LEN		(512 * 1024)	/* Reserve 512 kB for Monitor	*/
-#define CFG_MALLOC_LEN		(2*1024*1024)	/* Reserve 2MB for malloc()	*/
+#define CFG_MONITOR_LEN		(512 * 1024)	/* Reserve 512 kB for Monitor */
+#define CFG_MALLOC_LEN		(2*1024*1024)	/* Reserve 2MB for malloc() */
 
 /*
  * For booting Linux, the board info and command line data
  * have to be in the first 8 MB of memory, since this is
  * the maximum mapped by the Linux kernel during initialization.
  */
-#define CFG_BOOTMAPSZ		(8 << 20)	/* Initial Memory map for Linux */
+#define CFG_BOOTMAPSZ		(8 << 20)	/* Init. Memory map for Linux */
 
-/*-----------------------------------------------------------------------
+/*
  * FLASH organization
  */
-#define CFG_FLASH_CFI		1	/* Flash is CFI conformant		*/
-#define CFG_MAX_FLASH_SECT	128	/* max number of sectors on one chip	*/
-#define CFG_MAX_FLASH_BANKS	2	/* max number of memory banks		*/
-#undef CFG_FLASH_PROTECTION		/* don't use hardware protection	*/
-#define CFG_FLASH_USE_BUFFER_WRITE 1	/* use buffered writes (20x faster)	*/
-#define CFG_FLASH_BASE		0xFE000000 /* test-only...*/
-#define CFG_FLASH_INCREMENT	0x01000000 /* test-only */
-
-#define CFG_FLASH_EMPTY_INFO            /* print 'E' for empty sector on flinfo */
+#ifndef __ASSEMBLY__
+extern int flash_banks;
+#endif
 
-#define CFG_JFFS2_FIRST_BANK    0           /* use for JFFS2 */
-#define CFG_JFFS2_NUM_BANKS     1           /* ! second bank contains u-boot    */
+#define CFG_FLASH_BASE		0xFE000000
+#define CFG_FLASH_CFI		1	/* Flash is CFI conformant */
+#define CFG_FLASH_CFI_DRIVER	1	/* Use the common driver */
+#define CFG_MAX_FLASH_SECT	256	/* max num of sects on one chip */
+#define CFG_MAX_FLASH_BANKS	flash_banks /* max num of flash banks */
+					    /* updated in board_early_init_r */
+#define CFG_MAX_FLASH_BANKS_DETECT 2
+#define CFG_FLASH_QUIET_TEST	1
+#define CFG_FLASH_INCREMENT	0x01000000
+#define CFG_FLASH_PROTECTION	1	/* use hardware protection */
+#define CFG_FLASH_AUTOPROTECT_LIST { \
+				{0xfe000000, 0x500000}, \
+				{0xffe80000, 0x180000} \
+				}
+#define CFG_FLASH_USE_BUFFER_WRITE 1	/* use buffered writes (20x faster) */
+#define CFG_FLASH_BANKS_LIST	{ \
+				CFG_FLASH_BASE, \
+				CFG_FLASH_BASE + CFG_FLASH_INCREMENT \
+				}
+#define CFG_FLASH_EMPTY_INFO	/* print 'E' for empty sector on flinfo */
 
-/*-----------------------------------------------------------------------
+/*
  * Environment Variable setup
  */
-#define CFG_ENV_IS_IN_EEPROM    1       /* use EEPROM for environment vars */
-#define CFG_ENV_OFFSET          0x000   /* environment starts at the beginning of the EEPROM */
-#define CFG_ENV_SIZE            0x800   /* 2048 bytes may be used for env vars*/
-				   /* total size of a CAT24WC16 is 2048 bytes */
+#define CFG_ENV_IS_IN_EEPROM	1	/* use EEPROM for environment vars */
+#define CFG_ENV_OFFSET		0x000	/* environment starts at the */
+					/* beginning of the EEPROM */
+#define CFG_ENV_SIZE		0x800	/* 2048 bytes may be used for env vars*/
+#define CONFIG_ENV_OVERWRITE	1	/* allow overwriting vendor vars */
 
-#define CFG_NVRAM_BASE_ADDR	0xF0000500		/* NVRAM base address	*/
-#define CFG_NVRAM_SIZE		242		        /* NVRAM size		*/
+#define CFG_NVRAM_BASE_ADDR	0xF0000500	/* NVRAM base address */
+#define CFG_NVRAM_SIZE		242		/* NVRAM size */
 
-/*-----------------------------------------------------------------------
+/*
  * I2C EEPROM (CAT24WC16) for environment
  */
 #define CONFIG_HARD_I2C			/* I2c with hardware support */
-#define CFG_I2C_SPEED		400000	/* I2C speed and slave address */
+#define CFG_I2C_SPEED		100000	/* I2C speed and slave address */
 #define CFG_I2C_SLAVE		0x7F
 
-#define CFG_I2C_EEPROM_ADDR	0x50	/* EEPROM CAT28WC08		*/
-#define CFG_I2C_EEPROM_ADDR_LEN	1	/* Bytes of address		*/
-/* mask of address bits that overflow into the "EEPROM chip address"    */
+#define CFG_I2C_EEPROM_ADDR	0x50	/* EEPROM CAT28WC08 */
+#define CFG_I2C_EEPROM_ADDR_LEN	1	/* Bytes of address */
+/* mask of address bits that overflow into the "EEPROM chip address" */
 #define CFG_I2C_EEPROM_ADDR_OVERFLOW	0x07
-#define CFG_EEPROM_PAGE_WRITE_BITS 4	/* The Catalyst CAT24WC08 has	*/
+#define CFG_EEPROM_PAGE_WRITE_BITS 4	/* The Catalyst CAT24WC08 has */
 					/* 16 byte page write mode using*/
-					/* last	4 bits of the address	*/
-#define CFG_EEPROM_PAGE_WRITE_DELAY_MS	10   /* and takes up to 10 msec */
+					/* last	4 bits of the address */
+#define CFG_EEPROM_PAGE_WRITE_DELAY_MS	10 /* and takes up to 10 msec */
 #define CFG_EEPROM_PAGE_WRITE_ENABLE
 
-/*-----------------------------------------------------------------------
- * Cache Configuration
- */
-#define CFG_DCACHE_SIZE		16384	/* For AMCC 405 CPUs, older 405 ppc's   */
-					/* have only 8kB, 16kB is save here     */
-#define CFG_CACHELINE_SIZE	32	/* ...			*/
-#if defined(CONFIG_CMD_KGDB)
-#define CFG_CACHELINE_SHIFT	5	/* log base 2 of the above value	*/
-#endif
-
-/*-----------------------------------------------------------------------
+/*
  * External Bus Controller (EBC) Setup
  */
-#define FLASH0_BA       0xFF000000          /* FLASH 0 Base Address             */
-#define FLASH1_BA       0xFE000000          /* FLASH 1 Base Address             */
-#define CAN_BA          0xF0000000          /* CAN Base Address                 */
-#define DUART0_BA       0xF0000400          /* DUART Base Address               */
-#define DUART1_BA       0xF0000408          /* DUART Base Address               */
-#define RTC_BA          0xF0000500          /* RTC Base Address                 */
-#define PS2_BA          0xF0000600          /* PS/2 Base Address                */
-#define CF_BA           0xF0100000          /* CompactFlash Base Address        */
-#define FPGA_BA         0xF0100100          /* FPGA internal Base Address       */
-#define FUJI_BA         0xF0100200          /* Fuji internal Base Address       */
-#define PCMCIA1_BA      0x20000000          /* PCMCIA Slot 1 Base Address       */
-#define PCMCIA2_BA      0x28000000          /* PCMCIA Slot 2 Base Address       */
-#define VGA_BA          0xF1000000          /* Epson VGA Base Address           */
-
-#define CFG_FPGA_BASE_ADDR      FPGA_BA     /* FPGA internal Base Address       */
-
-/* Memory Bank 0 (Flash Bank 0) initialization                                  */
+#define FLASH0_BA       (CFG_FLASH_BASE + CFG_FLASH_INCREMENT) /* FLASH 0 BA */
+#define FLASH1_BA       CFG_FLASH_BASE      /* FLASH 1 Base Address          */
+#define CAN_BA          0xF0000000          /* CAN Base Address              */
+#define DUART0_BA       0xF0000400          /* DUART Base Address            */
+#define DUART1_BA       0xF0000408          /* DUART Base Address            */
+#define RTC_BA          0xF0000500          /* RTC Base Address              */
+#define PS2_BA          0xF0000600          /* PS/2 Base Address             */
+#define CF_BA           0xF0100000          /* CompactFlash Base Address     */
+#define FPGA_BA         0xF0100100          /* FPGA internal Base Address    */
+#define FUJI_BA         0xF0100200          /* Fuji internal Base Address    */
+#define PCMCIA1_BA      0x20000000          /* PCMCIA Slot 1 Base Address    */
+#define PCMCIA2_BA      0x28000000          /* PCMCIA Slot 2 Base Address    */
+#define VGA_BA          0xF1000000          /* Epson VGA Base Address        */
+
+#define CFG_FPGA_BASE_ADDR      FPGA_BA     /* FPGA internal Base Address    */
+
+/* Memory Bank 0 (Flash Bank 0) initialization                               */
 #define CFG_EBC_PB0AP   0x92015480
 #define CFG_EBC_PB0CR   FLASH0_BA | 0x9A000 /* BAS=0xFF0,BS=16MB,BU=R/W,BW=16bit*/
+#define CFG_EBC_PB0AP_HWREV8 CFG_EBC_PB0AP
+#define CFG_EBC_PB0CR_HWREV8 FLASH1_BA | 0xBA000 /* BS=32MB */
 
-/* Memory Bank 1 (Flash Bank 1) initialization                                  */
+/* Memory Bank 1 (Flash Bank 1) initialization                               */
 #define CFG_EBC_PB1AP   0x92015480
 #define CFG_EBC_PB1CR   FLASH1_BA | 0x9A000 /* BAS=0xFE0,BS=16MB,BU=R/W,BW=16bit*/
 
@@ -328,7 +360,7 @@
 #define CFG_EBC_PB6AP   0x050007C0   /* BWT=2,WBN=1,WBF=1,TH=1,RE=1,SOR=1,BEM=1 */
 #define CFG_EBC_PB6CR   PCMCIA2_BA | 0xFA000 /*BAS=0x280,BS=128MB,BU=R/W,BW=16bit*/
 
-/*-----------------------------------------------------------------------
+/*
  * FPGA stuff
  */
 
@@ -351,48 +383,56 @@
 #define CFG_FPGA_INIT           0x00010000  /* FPGA init pin (ppc input)     */
 #define CFG_FPGA_DONE           0x00008000  /* FPGA done pin (ppc input)     */
 
-/*-----------------------------------------------------------------------
+/*
  * LCD Setup
  */
+#define CFG_LCD_BIG_MEM		(VGA_BA + 0x200000) /* S1D13806 Mem Base */
+#define CFG_LCD_BIG_REG		VGA_BA /* S1D13806 Reg Base */
 
-#define CFG_LCD_BIG_MEM         0xF1200000  /* Epson S1D13806 Mem Base Address  */
-#define CFG_LCD_BIG_REG         0xF1000000  /* Epson S1D13806 Reg Base Address  */
-
-#define CONFIG_LCD_BIG          2           /* Epson S1D13806 used              */
+#define CONFIG_LCD_BIG		2 /* Epson S1D13806 used */
 
 /* Image information... */
-#define CONFIG_LCD_USED         CONFIG_LCD_BIG
-#define CFG_LCD_HEADER_NAME     "../common/s1d13806_640_480_16bpp.h"
-#define CFG_LCD_LOGO_NAME       "logo_640_480_24bpp.c"
+#define CONFIG_LCD_USED		CONFIG_LCD_BIG
 
-#define CFG_LCD_MEM             CFG_LCD_BIG_MEM
-#define CFG_LCD_REG             CFG_LCD_BIG_REG
+#define CFG_LCD_MEM		CFG_LCD_BIG_MEM
+#define CFG_LCD_REG		CFG_LCD_BIG_REG
 
 #define CFG_VIDEO_LOGO_MAX_SIZE (1 << 20)
 
-/*-----------------------------------------------------------------------
+/*
  * Definitions for initial stack pointer and data area (in data cache)
  */
 
 /* use on chip memory ( OCM ) for temperary stack until sdram is tested */
-#define CFG_TEMP_STACK_OCM        1
+#define CFG_TEMP_STACK_OCM	1
 
 /* On Chip Memory location */
 #define CFG_OCM_DATA_ADDR	0xF8000000
 #define CFG_OCM_DATA_SIZE	0x1000
 
-#define CFG_INIT_RAM_ADDR	CFG_OCM_DATA_ADDR /* inside of SDRAM		*/
-#define CFG_INIT_RAM_END	CFG_OCM_DATA_SIZE /* End of used area in RAM	*/
-#define CFG_GBL_DATA_SIZE      128  /* size in bytes reserved for initial data */
-#define CFG_GBL_DATA_OFFSET    (CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
-#define CFG_INIT_SP_OFFSET      CFG_GBL_DATA_OFFSET
+#define CFG_INIT_RAM_ADDR	CFG_OCM_DATA_ADDR /* inside of SDRAM */
+#define CFG_INIT_RAM_END	CFG_OCM_DATA_SIZE /* End of used area in RAM */
+#define CFG_GBL_DATA_SIZE	128 /* reserved bytes for initial data */
+#define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
+#define CFG_INIT_SP_OFFSET	CFG_GBL_DATA_OFFSET
 
 /*
  * Internal Definitions
  *
  * Boot Flags
  */
-#define BOOTFLAG_COLD	0x01		/* Normal Power-On: Boot from FLASH	*/
-#define BOOTFLAG_WARM	0x02		/* Software reboot			*/
+#define BOOTFLAG_COLD	0x01		/* Normal Power-On: Boot from FLASH */
+#define BOOTFLAG_WARM	0x02		/* Software reboot */
 
-#endif	/* __CONFIG_H */
+/*
+ * PCI OHCI controller
+ */
+#define CONFIG_USB_OHCI_NEW	1
+#define CONFIG_PCI_OHCI		1
+#define CFG_OHCI_SWAP_REG_ACCESS 1
+#define CFG_USB_OHCI_MAX_ROOT_PORTS 15
+#define CFG_USB_OHCI_SLOT_NAME	"ohci_pci"
+#define CONFIG_USB_STORAGE	1
+#define CFG_USB_OHCI_BOARD_INIT 1
+
+#endif /* __CONFIG_H */
-- 
1.5.3




From matthias.fuchs at esd-electronics.com  Mon Apr 21 14:41:59 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 14:41:59 +0200
Subject: [U-Boot-Users] [PATCH 1/5] 4xx: Update esd's common LCD code for
	405 boards
Message-ID: <200804211441.59979.matthias.fuchs@esd-electronics.com>

- Coding style cleanup (long lines)
- Add s1d13505 support
- Make some functions return a result code instead of void

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/common/lcd.c                    |  123 ++++++++++++++++++++---------
 board/esd/common/s1d13505_640_480_16bpp.h |   66 +++++++++++++++
 2 files changed, 151 insertions(+), 38 deletions(-)
 create mode 100644 board/esd/common/s1d13505_640_480_16bpp.h

diff --git a/board/esd/common/lcd.c b/board/esd/common/lcd.c
index ed50def..c23dc81 100644
--- a/board/esd/common/lcd.c
+++ b/board/esd/common/lcd.c
@@ -44,37 +44,57 @@ void lcd_setup(int lcd, int config)
 		/*
 		 * Set endianess and reset lcd controller 0 (small)
 		 */
-		out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & ~CFG_LCD0_RST); /* set reset to low */
+
+		/* set reset to low */
+		out_be32((void*)GPIO0_OR,
+			 in_be32((void*)GPIO0_OR) & ~CFG_LCD0_RST);
 		udelay(10); /* wait 10us */
-		if (config == 1)
-			out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN); /* big-endian */
-		else
-			out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & ~CFG_LCD_ENDIAN); /* little-endian */
+		if (config == 1) {
+			/* big-endian */
+			out_be32((void*)GPIO0_OR,
+				 in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN);
+		} else {
+			/* little-endian */
+			out_be32((void*)GPIO0_OR,
+				 in_be32((void*)GPIO0_OR) & ~CFG_LCD_ENDIAN);
+		}
 		udelay(10); /* wait 10us */
-		out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD0_RST); /* set reset to high */
+		/* set reset to high */
+		out_be32((void*)GPIO0_OR,
+			 in_be32((void*)GPIO0_OR) | CFG_LCD0_RST);
 	} else {
 		/*
 		 * Set endianess and reset lcd controller 1 (big)
 		 */
-		out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & ~CFG_LCD1_RST); /* set reset to low */
+
+		/* set reset to low */
+		out_be32((void*)GPIO0_OR,
+			 in_be32((void*)GPIO0_OR) & ~CFG_LCD1_RST);
 		udelay(10); /* wait 10us */
-		if (config == 1)
-			out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN); /* big-endian */
-		else
-			out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) & ~CFG_LCD_ENDIAN); /* little-endian */
+		if (config == 1) {
+			/* big-endian */
+			out_be32((void*)GPIO0_OR,
+				 in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN);
+		} else {
+			/* little-endian */
+			out_be32((void*)GPIO0_OR,
+				 in_be32((void*)GPIO0_OR) & ~CFG_LCD_ENDIAN);
+		}
 		udelay(10); /* wait 10us */
-		out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD1_RST); /* set reset to high */
+		/* set reset to high */
+		out_be32((void*)GPIO0_OR,
+			 in_be32((void*)GPIO0_OR) | CFG_LCD1_RST);
 	}
 
 	/*
 	 * CFG_LCD_ENDIAN may also be FPGA_RESET, so set inactive
 	 */
-	out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN); /* set reset high again */
+	out_be32((void*)GPIO0_OR, in_be32((void*)GPIO0_OR) | CFG_LCD_ENDIAN);
 }
 #endif /* CFG_LCD_ENDIAN */
 
 
-void lcd_bmp(uchar *logo_bmp)
+int lcd_bmp(uchar *logo_bmp)
 {
 	int i;
 	uchar *ptr;
@@ -99,13 +119,18 @@ void lcd_bmp(uchar *logo_bmp)
 		len = CFG_VIDEO_LOGO_MAX_SIZE;
 		dst = malloc(CFG_VIDEO_LOGO_MAX_SIZE);
 		if (dst == NULL) {
-			printf("Error: malloc in gunzip failed!\n");
-			return;
+			printf("Error: malloc for gunzip failed!\n");
+			return 1;
+		}
+		if (gunzip(dst, CFG_VIDEO_LOGO_MAX_SIZE,
+			   (uchar *)logo_bmp, &len) != 0) {
+			free(dst);
+			return 1;
+		}
+		if (len == CFG_VIDEO_LOGO_MAX_SIZE) {
+			printf("Image could be truncated"
+			       " (increase CFG_VIDEO_LOGO_MAX_SIZE)!\n");
 		}
-		if (gunzip(dst, CFG_VIDEO_LOGO_MAX_SIZE, (uchar *)logo_bmp, &len) != 0)
-			return;
-		if (len == CFG_VIDEO_LOGO_MAX_SIZE)
-			printf("Image could be truncated (increase CFG_VIDEO_LOGO_MAX_SIZE)!\n");
 
 		/*
 		 * Check for bmp mark 'BM'
@@ -113,7 +138,7 @@ void lcd_bmp(uchar *logo_bmp)
 		if (*(ushort *)dst != 0x424d) {
 			printf("LCD: Unknown image format!\n");
 			free(dst);
-			return;
+			return 1;
 		}
 	} else {
 		/*
@@ -150,7 +175,7 @@ void lcd_bmp(uchar *logo_bmp)
 		printf("LCD: Unknown bpp (%d) im image!\n", bpp);
 		if ((dst != NULL) && (dst != (uchar *)logo_bmp))
 			free(dst);
-		return;
+		return 1;
 	}
 	printf(" (%d*%d, %dbpp)\n", width, height, bpp);
 
@@ -180,23 +205,28 @@ void lcd_bmp(uchar *logo_bmp)
 			if (bpp == 24) {
 				for (x = 0; x < width; x++) {
 					/*
-					 * Generate epson 16bpp fb-format from 24bpp image
+					 * Generate epson 16bpp fb-format
+					 * from 24bpp image
 					 */
 					b = *bmp++ >> 3;
 					g = *bmp++ >> 2;
 					r = *bmp++ >> 3;
-					val = ((r & 0x1f) << 11) | ((g & 0x3f) << 5) | (b & 0x1f);
+					val = ((r & 0x1f) << 11) |
+						((g & 0x3f) << 5) |
+						(b & 0x1f);
 					*ptr2++ = val;
 				}
 			} else if (bpp == 8) {
 				for (x = 0; x < line_size; x++) {
 					/* query rgb value from palette */
-					ptr = (unsigned char *)(dst + 14 + 40) ;
+					ptr = (unsigned char *)(dst + 14 + 40);
 					ptr += (*bmp++) << 2;
 					b = *ptr++ >> 3;
 					g = *ptr++ >> 2;
 					r = *ptr++ >> 3;
-					val = ((r & 0x1f) << 11) | ((g & 0x3f) << 5) | (b & 0x1f);
+					val = ((r & 0x1f) << 11) |
+						((g & 0x3f) << 5) |
+						(b & 0x1f);
 					*ptr2++ = val;
 				}
 			}
@@ -208,11 +238,12 @@ void lcd_bmp(uchar *logo_bmp)
 
 	if ((dst != NULL) && (dst != (uchar *)logo_bmp))
 		free(dst);
+	return 0;
 }
 
 
-void lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
-	      uchar *logo_bmp, ulong len)
+int lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
+	     uchar *logo_bmp, ulong len)
 {
 	int i;
 	ushort s1dReg;
@@ -263,8 +294,22 @@ void lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
 		lcd_reg += 0x10000; /* add offset for 705 regs */
 		puts("LCD:   S1D13705");
 	} else {
-		puts("LCD:   No controller detected!\n");
-		return;
+		out_8(&lcd_reg[0x1a], 0x00);
+		udelay(1000);
+		if (in_8(&lcd_reg[1]) == 0x0c) {
+			/*
+			 * S1D13505 detected
+			 */
+			reg_byte_swap = TRUE;
+			palette_index = 0x25;
+			palette_value = 0x27;
+			lcd_depth = 16;
+
+			puts("LCD:   S1D13505");
+		} else {
+			puts("LCD:   No controller detected!\n");
+			return 1;
+		}
 	}
 
 	/*
@@ -279,7 +324,7 @@ void lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
 				s1dReg &= ~0x0001;
 		}
 		s1dValue = regs[i].Value;
-		lcd_reg[s1dReg] = s1dValue;
+		out_8(&lcd_reg[s1dReg], s1dValue);
 	}
 
 	/*
@@ -291,15 +336,15 @@ void lcd_init(uchar *lcd_reg, uchar *lcd_mem, S1D_REGS *regs, int reg_count,
 	/*
 	 * Display bmp image
 	 */
-	lcd_bmp(logo_bmp);
+	return lcd_bmp(logo_bmp);
 }
 
-#if defined(CONFIG_VIDEO_SM501)
 int do_esdbmp(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
 	ulong addr;
+#ifdef CONFIG_VIDEO_SM501
 	char *str;
-
+#endif
 	if (argc != 2) {
 		printf ("Usage:\n%s\n", cmdtp->usage);
 		return 1;
@@ -307,19 +352,22 @@ int do_esdbmp(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 
 	addr = simple_strtoul(argv[1], NULL, 16);
 
+#ifdef CONFIG_VIDEO_SM501
 	str = getenv("bd_type");
 	if ((strcmp(str, "ppc221") == 0) || (strcmp(str, "ppc231") == 0)) {
 		/*
 		 * SM501 available, use standard bmp command
 		 */
-		return (video_display_bitmap(addr, 0, 0));
+		return video_display_bitmap(addr, 0, 0);
 	} else {
 		/*
 		 * No SM501 available, use esd epson bmp command
 		 */
-		lcd_bmp((uchar *)addr);
-		return 0;
+		return lcd_bmp((uchar *)addr);
 	}
+#else
+	return lcd_bmp((uchar *)addr);
+#endif
 }
 
 U_BOOT_CMD(
@@ -327,4 +375,3 @@ U_BOOT_CMD(
 	"esdbmp   - display BMP image\n",
 	"<imageAddr> - display image\n"
 );
-#endif
diff --git a/board/esd/common/s1d13505_640_480_16bpp.h b/board/esd/common/s1d13505_640_480_16bpp.h
new file mode 100644
index 0000000..19b3e0a
--- /dev/null
+++ b/board/esd/common/s1d13505_640_480_16bpp.h
@@ -0,0 +1,66 @@
+/*
+ * (C) Copyright 2008
+ * Matthias Fuchs, esd gmbh germany, matthias.fuchs at esd-electronics.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/*
+ * Panel:  640x480 50Hz TFT Single 18-bit (PCLK=20.000 MHz)
+ * Memory:  DRAM (MCLK=40.000 MHz)
+ */
+static S1D_REGS regs_13505_640_480_16bpp[] =
+{
+	{0x1B,0x00},   /* Miscellaneous Register */
+	{0x23,0x20},   /* Performance Enhancement Register 1 */
+	{0x01,0x30},   /* Memory Configuration Register */
+	{0x22,0x24},   /* Performance Enhancement Register 0 */
+	{0x02,0x25},   /* Panel Type Register */
+	{0x03,0x00},   /* MOD Rate Register */
+	{0x04,0x4F},   /* Horizontal Display Width Register */
+	{0x05,0x0c},   /* Horizontal Non-Display Period Register */
+	{0x06,0x00},   /* HRTC/FPLINE Start Position Register */
+	{0x07,0x01},   /* HRTC/FPLINE Pulse Width Register */
+	{0x08,0xDF},   /* Vertical Display Height Register 0 */
+	{0x09,0x01},   /* Vertical Display Height Register 1 */
+	{0x0A,0x3E},   /* Vertical Non-Display Period Register */
+	{0x0B,0x00},   /* VRTC/FPFRAME Start Position Register */
+	{0x0C,0x01},   /* VRTC/FPFRAME Pulse Width Register */
+	{0x0E,0xFF},   /* Screen 1 Line Compare Register 0 */
+	{0x0F,0x03},   /* Screen 1 Line Compare Register 1 */
+	{0x10,0x00},   /* Screen 1 Display Start Address Register 0 */
+	{0x11,0x00},   /* Screen 1 Display Start Address Register 1 */
+	{0x12,0x00},   /* Screen 1 Display Start Address Register 2 */
+	{0x13,0x00},   /* Screen 2 Display Start Address Register 0 */
+	{0x14,0x00},   /* Screen 2 Display Start Address Register 1 */
+	{0x15,0x00},   /* Screen 2 Display Start Address Register 2 */
+	{0x16,0x80},   /* Memory Address Offset Register 0 */
+	{0x17,0x02},   /* Memory Address Offset Register 1 */
+	{0x18,0x00},   /* Pixel Panning Register */
+	{0x19,0x01},   /* Clock Configuration Register */
+	{0x1A,0x00},   /* Power Save Configuration Register */
+	{0x1C,0x00},   /* MD Configuration Readback Register 0 */
+	{0x1E,0x06},   /* General IO Pins Configuration Register 0 */
+	{0x1F,0x00},   /* General IO Pins Configuration Register 1 */
+	{0x20,0x00},   /* General IO Pins Control Register 0 */
+	{0x21,0x00},   /* General IO Pins Control Register 1 */
+	{0x23,0x20},   /* Performance Enhancement Register 1 */
+	{0x0D,0x15},   /* Display Mode Register */
+};
+
-- 
1.5.3




From matthias.fuchs at esd-electronics.com  Mon Apr 21 15:09:43 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 15:09:43 +0200
Subject: [U-Boot-Users] intended behavior of bootm
Message-ID: <200804211509.43558.matthias.fuchs@esd-electronics.com>

Hi,

I am wondering if bootm behaves correctly on CRC errors in kernel and/or ramdisk images.
This is what I observed:

1) I loaded a Linux kernel into RAM at 0x200000 on a 405 system. I loaded an initial ramdisk images
into RAM at address 0x300000. Now 'bootm 200000 300000' boots my system correctly.

2) Same loading as above. But I made the kernel image CRC check fail (mw 220000 12345678).
I get:
...
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
=>

That's ok.

3) Same loading as above. But I make the ramdisk CRC check fail (mw 320000 12345678).
I get:
## Booting kernel from Legacy Image at 00200000 ...
...
## Loading init Ramdisk from Legacy Image at 00300000 ...
...
   Verifying Checksum ... Bad Data CRC
<system reset>
U-Boot 1.3.2-00450-g77dd47f (Apr 21 2008 - 14:43:23)

Hmm, I expected the same behavior as for a corrupted kernel image.
So what should be the correct behavior? I would like to get back to the prompt
on any CRC error. So is this a bug?

Matthias



From ricard.wanderlof at axis.com  Mon Apr 21 15:36:09 2008
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Mon, 21 Apr 2008 15:36:09 +0200 (CEST)
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <1208779508.5965.371.camel@sauron>
References: <20080420222237.4AE5324657@gemini.denx.de>
	<1208779508.5965.371.camel@sauron>
Message-ID: <Pine.LNX.4.64.0804211533140.27984@lnxricardw.se.axis.com>


On Mon, 21 Apr 2008, Artem Bityutskiy wrote:

> On Mon, 2008-04-21 at 00:22 +0200, Wolfgang Denk wrote:
>> In message <4808DF3B.2080702 at largestprime.net> you wrote:
>>>
>>> Wolfgang showed some interest briefly too.[1]
>>
>> I am definitely interested.
>
> What I would suggest to start with is to teach U-boot to erase flash and
> preserve erase counters, because now it just wipes the erase counters
> out. Also, it would be nice to teach it to flash images properly in case
> of NAND flash.
>

I was under the impression from past emails on the MTD list that the 
internal meta format for UBI has changed a few times over its lifetime.

Assuming this continues, I would think this would cause problems for 
bootloaders such as U-Boot whose flash partitions are not necessarily 
rewritten in the case of a product upgrade - i.e. a firmware upgrade with 
a new kernel would have a new UBI implementation and spec causing an
older bootloader to fail to operate properly with the newer image.

/Ricard
--
Ricard Wolf Wanderl?f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30



From jwboyer at gmail.com  Mon Apr 21 15:44:23 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 21 Apr 2008 08:44:23 -0500
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <Pine.LNX.4.64.0804211533140.27984@lnxricardw.se.axis.com>
References: <20080420222237.4AE5324657@gemini.denx.de>
	<1208779508.5965.371.camel@sauron>
	<Pine.LNX.4.64.0804211533140.27984@lnxricardw.se.axis.com>
Message-ID: <1208785463.6654.34.camel@vader.jdub.homelinux.org>

On Mon, 2008-04-21 at 15:36 +0200, Ricard Wanderlof wrote:
> On Mon, 21 Apr 2008, Artem Bityutskiy wrote:
> 
> > On Mon, 2008-04-21 at 00:22 +0200, Wolfgang Denk wrote:
> >> In message <4808DF3B.2080702 at largestprime.net> you wrote:
> >>>
> >>> Wolfgang showed some interest briefly too.[1]
> >>
> >> I am definitely interested.
> >
> > What I would suggest to start with is to teach U-boot to erase flash and
> > preserve erase counters, because now it just wipes the erase counters
> > out. Also, it would be nice to teach it to flash images properly in case
> > of NAND flash.
> >
> 
> I was under the impression from past emails on the MTD list that the 
> internal meta format for UBI has changed a few times over its lifetime.
> 
> Assuming this continues, I would think this would cause problems for 
> bootloaders such as U-Boot whose flash partitions are not necessarily 
> rewritten in the case of a product upgrade - i.e. a firmware upgrade with 
> a new kernel would have a new UBI implementation and spec causing an
> older bootloader to fail to operate properly with the newer image.

I think there was only 1 time the on-flash format changed, and that was
before UBI was merged upstream.  New features can be introduced with
additional flags, however older versions should be able to ignore those.

Artem, is that right?  My memory is fuzzy here.

josh




From galak at kernel.crashing.org  Mon Apr 21 16:28:36 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Mon, 21 Apr 2008 09:28:36 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH v3] 85xx: Round up frequency calculations to
 get reasonable output
Message-ID: <Pine.LNX.4.64.0804210927530.18126@blarg.am.freescale.net>

eg. because of rounding error we can get 799Mhz instead of 800Mhz.

Introduced DIV_ROUND_UP and roundup taken from linux kernel.

Signed-off-by: Dejan Minic <minic at freescale.com>
Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

Lets see if this version works for people.  Introduced a generic
DIV_ROUND_UP taken from the kernel.

 cpu/mpc85xx/cpu.c |   13 ++++++-------
 include/common.h  |    3 +++
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index dcd8817..74b210c 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -116,22 +116,21 @@ int checkcpu (void)
 	get_sys_info(&sysinfo);

 	puts("Clock Configuration:\n");
-	printf("       CPU:%4lu MHz, ", sysinfo.freqProcessor / 1000000);
-	printf("CCB:%4lu MHz,\n", sysinfo.freqSystemBus / 1000000);
-
+	printf("       CPU:%4lu MHz, ", DIV_ROUND_UP(sysinfo.freqProcessor,1000000));
+	printf("CCB:%4lu MHz,\n", DIV_ROUND_UP(sysinfo.freqSystemBus,1000000));
 	ddr_ratio = ((gur->porpllsr) & 0x00003e00) >> 9;
 	switch (ddr_ratio) {
 	case 0x0:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		DIV_ROUND_UP(sysinfo.freqDDRBus,2000000), DIV_ROUND_UP(sysinfo.freqDDRBus,1000000));
 		break;
 	case 0x7:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate) (Synchronous), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		DIV_ROUND_UP(sysinfo.freqDDRBus, 2000000), DIV_ROUND_UP(sysinfo.freqDDRBus, 1000000));
 		break;
 	default:
 		printf("       DDR:%4lu MHz (%lu MT/s data rate) (Asynchronous), ",
-		sysinfo.freqDDRBus / 2000000, sysinfo.freqDDRBus / 1000000);
+		DIV_ROUND_UP(sysinfo.freqDDRBus, 2000000), DIV_ROUND_UP(sysinfo.freqDDRBus,1000000));
 		break;
 	}

@@ -154,7 +153,7 @@ int checkcpu (void)
 		 clkdiv *= 2;
 #endif
 		printf("LBC:%4lu MHz\n",
-		       sysinfo.freqSystemBus / 1000000 / clkdiv);
+		       DIV_ROUND_UP(sysinfo.freqSystemBus, 1000000) / clkdiv);
 	} else {
 		printf("LBC: unknown (lcrr: 0x%08x)\n", lcrr);
 	}
diff --git a/include/common.h b/include/common.h
index 8630780..348a0cb 100644
--- a/include/common.h
+++ b/include/common.h
@@ -670,6 +670,9 @@ void inline show_boot_progress (int val);

 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

+#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+#define roundup(x, y) ((((x) + ((y) - 1)) / (y)) * (y))
+
 /* Multicore arch functions */
 #ifdef CONFIG_MP
 int cpu_status(int nr);
-- 
1.5.4.1




From galak at kernel.crashing.org  Mon Apr 21 16:36:15 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Mon, 21 Apr 2008 09:36:15 -0500
Subject: [U-Boot-Users] [PATCH] 85xx: Round up frequency calculations to
	get reasonable output
In-Reply-To: <20080420232800.D878A248A6@gemini.denx.de>
References: <20080420232800.D878A248A6@gemini.denx.de>
Message-ID: <2878722E-F872-4DFC-9BDB-6BF6E247A313@kernel.crashing.org>


On Apr 20, 2008, at 6:28 PM, Wolfgang Denk wrote:
> In message <Pine.LNX.4.64.0804181156410.4255 at blarg.am.freescale.net>  
> you wrote:
>> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
>>
>> Signed-off-by: Dejan Minic <minic at freescale.com>
>> Signed-off-by: Srikanth Srinivasan  
>> <srikanth.srinivasan at freescale.com>
>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>> ---
>> cpu/mpc85xx/cpu.c |   18 +++++++++++-------
>> 1 files changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
>> index dcd8817..6972bb1 100644
>> --- a/cpu/mpc85xx/cpu.c
>> +++ b/cpu/mpc85xx/cpu.c
>> @@ -65,6 +65,11 @@ struct cpu_type cpu_type_list [] = {
>> 	CPU_TYPE_ENTRY(8572_E),
>> };
>>
>> +static inline unsigned long integer_round (unsigned long val,  
>> unsigned long div)
>> +{
>> +	return ((val + (div/2)) / div);
>> +}
>> +
>
> As already mentioned, "integer_round" is not a good  name  for  this.
> Also,  it  seems  this  should not live in cpu/mpc85xx/cpu.c but in a
> more central place and be  used  by  lots  of  other  code  as  well.
> Actually  you  might  want  to make it a macro to allow for different
> data types as well.

Ok.  I've posted v3 of the patch that takes DIV_ROUND_UP from the  
kernel.  See if that works for you.

- k



From matthias.fuchs at esd-electronics.com  Mon Apr 21 16:58:25 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 16:58:25 +0200
Subject: [U-Boot-Users] intended behavior of bootm
In-Reply-To: <200804211509.43558.matthias.fuchs@esd-electronics.com>
References: <200804211509.43558.matthias.fuchs@esd-electronics.com>
Message-ID: <200804211658.26095.matthias.fuchs@esd-electronics.com>

Hi,

after going through the boom code I found out, that
setting the 'autostart' variable to 'no' brings me a little closer
to what I want. But finally I end up
in the enable_interrupts() at the very end of do_bootm(). This freezes
my system. The reason for this is the Linux kernel image that is loaded to address 0
and that overwrites the vector table. So reenabling the interrupts in U-Boot with
Linux interrupt table is a bad idea.

So what's the best idea to fix this? I could copy the vector table onto the stack
in do_bootm() and copy it back just before reenabling the interrupts.

Any better idea?

Matthias

On Monday 21 April 2008 15:09, Matthias Fuchs wrote:
> Hi,
> 
> I am wondering if bootm behaves correctly on CRC errors in kernel and/or ramdisk images.
> This is what I observed:
> 
> 1) I loaded a Linux kernel into RAM at 0x200000 on a 405 system. I loaded an initial ramdisk images
> into RAM at address 0x300000. Now 'bootm 200000 300000' boots my system correctly.
> 
> 2) Same loading as above. But I made the kernel image CRC check fail (mw 220000 12345678).
> I get:
> ...
>    Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
> =>
> 
> That's ok.
> 
> 3) Same loading as above. But I make the ramdisk CRC check fail (mw 320000 12345678).
> I get:
> ## Booting kernel from Legacy Image at 00200000 ...
> ...
> ## Loading init Ramdisk from Legacy Image at 00300000 ...
> ...
>    Verifying Checksum ... Bad Data CRC
> <system reset>
> U-Boot 1.3.2-00450-g77dd47f (Apr 21 2008 - 14:43:23)
> 
> Hmm, I expected the same behavior as for a corrupted kernel image.
> So what should be the correct behavior? I would like to get back to the prompt
> on any CRC error. So is this a bug?
> 
> Matthias



From mk at denx.de  Mon Apr 21 17:04:15 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Mon, 21 Apr 2008 17:04:15 +0200
Subject: [U-Boot-Users] USB SUPPORT
In-Reply-To: <1208752189.2935.10.camel@Aneesh> (Aneesh's message of "Mon\,
	21 Apr 2008 09\:59\:49 +0530")
References: <1208752189.2935.10.camel@Aneesh>
Message-ID: <87prsjdzbk.fsf@denx.de>

Hi Aneesh,

Aneesh <aneesh_g at cms.com> writes:

>        I am using an at91rm9200dk custom board.I want  to boot kernel and
>    ram disk from the usb stick.for that i tried to enable the usb support
>    in the uboot.but now i am getting a message like no storage devices
>    found .
>    i gave the configurations in include/configs/at91rm9200dk.h
>    like follows
>    #define CONFIG_DOS_PARTITION 1
>    #define CONFIG_USB_OHCI      1

You should use the new ohci driver and define CONFIG_USB_OHCI_NEW. But
that alone is not enough, please checkout doc/README.generic_usb_ohci.

>    #define CONFIG_USB_STORAGE  1
>    #define CONFIG_COMMANDS \
>           ((CONFIG_CMD_DFL | CFG_CMD_MII | CFG_CMD_NET | CFG_CMD_USB | \
>    CFG_CMD_DHCP ) & \
>          ~(CFG_CMD_BDI | \
>    CFG_CMD_IMI | \
>    CFG_CMD_AUTOSCRIPT | \
>    CFG_CMD_FPGA | \
>    CFG_CMD_MISC | \
>    CFG_CMD_LOADS))
>    Is this configuration is right?
>    i am not able to acess the USB stick using Storage USB Commands. My
>    U-boot version is 1.1.5.

Oh, and please update your U-Boot version to top of git before anything
else.

Best regards

Markus Klotzbuecher

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



From gerald.vanbaren at ge.com  Mon Apr 21 17:16:37 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Mon, 21 Apr 2008 11:16:37 -0400
Subject: [U-Boot-Users] intended behavior of bootm
In-Reply-To: <200804211658.26095.matthias.fuchs@esd-electronics.com>
References: <200804211509.43558.matthias.fuchs@esd-electronics.com>
	<200804211658.26095.matthias.fuchs@esd-electronics.com>
Message-ID: <480CAFD5.7070804@ge.com>

Matthias Fuchs wrote:
> Hi,
> 
> after going through the boom code I found out, that
> setting the 'autostart' variable to 'no' brings me a little closer
> to what I want. But finally I end up
> in the enable_interrupts() at the very end of do_bootm(). This freezes
> my system. The reason for this is the Linux kernel image that is loaded to address 0
> and that overwrites the vector table. So reenabling the interrupts in U-Boot with
> Linux interrupt table is a bad idea.

No, having your (u-boot) interrupt go off while booting linux is a bad idea.

Which interrupt is going off?  Why is it going off (why isn't the 
hardware put into a quiescent state)?

> So what's the best idea to fix this? I could copy the vector table onto the stack
> in do_bootm() and copy it back just before reenabling the interrupts.

NO NO NO.

> Any better idea?
> 
> Matthias

That a u-boot initialized interrupt is occurring is wrong and needs to 
be fixed.
* Traditionally, u-boot does not use interrupts for anything, thus this 
isn't a problem.

* Proper hardware and device driver convention is that the hardware must 
be quiescent when linux is started and the linux device driver must 
(re)configure that hardware the way it wants/needs.  Obviously, this is 
probably a 95% rule (console I/O, memory initialization, some others may 
violate this rule for practical reasons).

* If your u-boot enables interrupt(s), you MUST disable the interrupt 
source before starting linux.  There is NO graceful way of getting linux 
to handle an interrupt that was a result of u-boot's running.  Starting 
linux with interrupts disabled is not a good solution - you may get 
lucky but leaving an active interrupt source is a dangerous game.  At 
best, it is a race condition that you may happen to win today.

Best regards,
gvb



From matthias.fuchs at esd-electronics.com  Mon Apr 21 17:43:18 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 17:43:18 +0200
Subject: [U-Boot-Users] intended behavior of bootm
In-Reply-To: <480CAFD5.7070804@ge.com>
References: <200804211509.43558.matthias.fuchs@esd-electronics.com>
	<200804211658.26095.matthias.fuchs@esd-electronics.com>
	<480CAFD5.7070804@ge.com>
Message-ID: <200804211743.19114.matthias.fuchs@esd-electronics.com>

Hi Jerry,

On Monday 21 April 2008 17:16, Jerry Van Baren wrote:
> Matthias Fuchs wrote:
> > Hi,
> > 
> > after going through the boom code I found out, that
> > setting the 'autostart' variable to 'no' brings me a little closer
> > to what I want. But finally I end up
> > in the enable_interrupts() at the very end of do_bootm(). This freezes
> > my system. The reason for this is the Linux kernel image that is loaded to address 0
> > and that overwrites the vector table. So reenabling the interrupts in U-Boot with
> > Linux interrupt table is a bad idea.
> 
> No, having your (u-boot) interrupt go off while booting linux is a bad idea.
U-Boot calls disable_interrupt() in do_bootm(). That's fact.

> 
> Which interrupt is going off?  Why is it going off (why isn't the 
> hardware put into a quiescent state)?
> 
> > So what's the best idea to fix this? I could copy the vector table onto the stack
> > in do_bootm() and copy it back just before reenabling the interrupts.
> 
> NO NO NO.
At least this works :-)

> 
> > Any better idea?
> > 
> > Matthias
> 
> That a u-boot initialized interrupt is occurring is wrong and needs to 
> be fixed.
> * Traditionally, u-boot does not use interrupts for anything, thus this 
> isn't a problem.
> 
> * Proper hardware and device driver convention is that the hardware must 
> be quiescent when linux is started and the linux device driver must 
> (re)configure that hardware the way it wants/needs.  Obviously, this is 
> probably a 95% rule (console I/O, memory initialization, some others may 
> violate this rule for practical reasons).
> 
> * If your u-boot enables interrupt(s), you MUST disable the interrupt 
> source before starting linux.  There is NO graceful way of getting linux 
> to handle an interrupt that was a result of u-boot's running.  Starting 
> linux with interrupts disabled is not a good solution - you may get 
> lucky but leaving an active interrupt source is a dangerous game.  At 
> best, it is a race condition that you may happen to win today.
So this means that U-Boot calling disable_interrupts before booting Linux (see do_bootm)
is correct. Later my the kernel images is loaded at address 0. This overwrites all U-Boot vectors
in the first 16k of RAM. So when after the kernel is loaded to address 0 and the ramdisk 
CRC checking failed to control is to be passed back to U-Boot it sees a mixed up vector table.
I think the only ways to fix this is to save the table (as I did for testing) or check the ramdisk
images before uncompressing the kernel at address 0.

Except from that I just noticed that 'autostart=no' does not help me, because it completely disables booting
the kernel from bootm.

So how can I achive this:

bootm $(kernel_addr_in_flash) $(randisk_addr_in_flash); run load_images_from_usb_to_ram; bootm $(kernel_addr_in_ram) $(ramdisk_addr_in_ram)

So the the initial bootm fails because of invalid images, U-Boot should load images from a USB media and start them.

Matthias



From matthias.fuchs at esd-electronics.com  Mon Apr 21 18:01:07 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 18:01:07 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update CPU strapping for PMC440 boards
Message-ID: <200804211801.07215.matthias.fuchs@esd-electronics.com>

This patch removes the temporary 'test' strapping option
of the sbe command. The '667' strapping option now uses
a PLB/PCI divider of 3.

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/pmc440/cmd_pmc440.c |   13 +------------
 1 files changed, 1 insertions(+), 12 deletions(-)

diff --git a/board/esd/pmc440/cmd_pmc440.c b/board/esd/pmc440/cmd_pmc440.c
index e9e9746..ef54e67 100644
--- a/board/esd/pmc440/cmd_pmc440.c
+++ b/board/esd/pmc440/cmd_pmc440.c
@@ -293,20 +293,9 @@ int do_setup_bootstrap_eeprom(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]
 			sdsdp[2]=0x40082350;
 			sdsdp[3]=0x0d050000;
 		} else if (!strcmp(argv[1], "667")) {
-			/* PLB=133MHz, PLB/PCI=4 */
+			/* PLB=133MHz, PLB/PCI=3 */
 			printf("Bootstrapping for 667MHz\n");
 			sdsdp[0]=0x8778a256;
-			sdsdp[1]=0x0947a030;
-			sdsdp[2]=0x40082350;
-			sdsdp[3]=0x0d050000;
-		} else if (!strcmp(argv[1], "test")) {
-			/*
-			 * TODO: this will replace the 667 MHz config above.
-			 * But it needs some more testing on a real 667 MHz CPU.
-			 */
-			printf("Bootstrapping for test"
-			       " (667MHz PLB=133PLB PLB/PCI=3)\n");
-			sdsdp[0]=0x8778a256;
 			sdsdp[1]=0x095fa030;
 			sdsdp[2]=0x40082350;
 			sdsdp[3]=0x0d050000;
-- 
1.5.3




From gerald.vanbaren at ge.com  Mon Apr 21 18:28:44 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Mon, 21 Apr 2008 12:28:44 -0400
Subject: [U-Boot-Users] intended behavior of bootm
In-Reply-To: <200804211743.19114.matthias.fuchs@esd-electronics.com>
References: <200804211509.43558.matthias.fuchs@esd-electronics.com>
	<200804211658.26095.matthias.fuchs@esd-electronics.com>
	<480CAFD5.7070804@ge.com>
	<200804211743.19114.matthias.fuchs@esd-electronics.com>
Message-ID: <480CC0BC.9040004@ge.com>

Matthias Fuchs wrote:
> Hi Jerry,
> 
> On Monday 21 April 2008 17:16, Jerry Van Baren wrote:
>> Matthias Fuchs wrote:
>>> Hi,
>>>
>>> after going through the boom code I found out, that
>>> setting the 'autostart' variable to 'no' brings me a little closer
>>> to what I want. But finally I end up
>>> in the enable_interrupts() at the very end of do_bootm(). This freezes
>>> my system. The reason for this is the Linux kernel image that is loaded to address 0
>>> and that overwrites the vector table. So reenabling the interrupts in U-Boot with
>>> Linux interrupt table is a bad idea.
>> No, having your (u-boot) interrupt go off while booting linux is a bad idea.
> U-Boot calls disable_interrupt() in do_bootm(). That's fact.
> 
>> Which interrupt is going off?  Why is it going off (why isn't the 
>> hardware put into a quiescent state)?
>>
>>> So what's the best idea to fix this? I could copy the vector table onto the stack
>>> in do_bootm() and copy it back just before reenabling the interrupts.
>> NO NO NO.
> At least this works :-)

At least once.  Today.  :-/

>>> Any better idea?
>>>
>>> Matthias
>> That a u-boot initialized interrupt is occurring is wrong and needs to 
>> be fixed.
>> * Traditionally, u-boot does not use interrupts for anything, thus this 
>> isn't a problem.
>>
>> * Proper hardware and device driver convention is that the hardware must 
>> be quiescent when linux is started and the linux device driver must 
>> (re)configure that hardware the way it wants/needs.  Obviously, this is 
>> probably a 95% rule (console I/O, memory initialization, some others may 
>> violate this rule for practical reasons).
>>
>> * If your u-boot enables interrupt(s), you MUST disable the interrupt 
>> source before starting linux.  There is NO graceful way of getting linux 
>> to handle an interrupt that was a result of u-boot's running.  Starting 
>> linux with interrupts disabled is not a good solution - you may get 
>> lucky but leaving an active interrupt source is a dangerous game.  At 
>> best, it is a race condition that you may happen to win today.
> So this means that U-Boot calling disable_interrupts before booting Linux (see do_bootm)
> is correct. Later my the kernel images is loaded at address 0. This overwrites all U-Boot vectors
> in the first 16k of RAM. So when after the kernel is loaded to address 0 and the ramdisk 
> CRC checking failed to control is to be passed back to U-Boot it sees a mixed up vector table.
> I think the only ways to fix this is to save the table (as I did for testing)

That is the way of INsanity.

>  or check the ramdisk images before uncompressing the kernel at address 0.

That is the way of sanity.

I missed a piece of the puzzle... the problem isn't an interrupt going 
off in linux-land, the problem is that linux failed to run (CRC error - 
implies a bad load) and you are trying to recover without resetting the 
system.

That isn't reliable.  It is possible that it could be done, but I 
wouldn't bet on it being reliable, at least not long term.  I would 
anticipate that to be a very fragile solution - eventually the linux 
kernel will do *something* different/unexpected before aborting and your 
recovery mechanism will blow up.

Our current solution revolves around verifying the boot image and 
aborting the launch *before* attempting to launch it, before it becomes 
impossible to recover.

In bootm, you will see that there is a "point of no return" 
corresponding to replacing the interrupt vectors.  After the "point of 
no return" we don't attempt to return from the failed bootm, but rather 
reset the hardware to recover.  You are trying to go *way beyond* the 
"point of no return" (all the way to some indeterminate point in the 
linux boot process) and still trying to recover without a reset.  Ouch. 
  You don't know (in general) *what* the linux initialization did (it is 
busy scribbling on memory, if nothing else), so it is impossible to 
guarantee that what it did is reversible.

> Except from that I just noticed that 'autostart=no' does not help me, because it completely disables booting
> the kernel from bootm.
> 
> So how can I achive this:
> 
> bootm $(kernel_addr_in_flash) $(randisk_addr_in_flash); run load_images_from_usb_to_ram; bootm $(kernel_addr_in_ram) $(ramdisk_addr_in_ram)
> 
> So the the initial bootm fails because of invalid images, U-Boot
> should load images from a USB media and start them.

The current u-boot has ways to detect invalid images before leaping. 
The way of sanity is to identify invalid images before leaping, and 
filling in holes in our detection, as necessary.  The new boot image 
format may also be helpful here.

> Matthias

Best regards,
gvb



From Ken.Fuchs at bench.com  Mon Apr 21 18:36:43 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Mon, 21 Apr 2008 11:36:43 -0500
Subject: [U-Boot-Users] USB SUPPORT
In-Reply-To: <1208752189.2935.10.camel@Aneesh>
Message-ID: <AA28F077645B324881335614E4F7C428034CD1@win-ex01.bench.com>

Aneesh wrote:

>     I am using an at91rm9200dk custom board.
> I want to boot kernel and ram disk from the
> usb stick.for that i tried to enable the usb
> support in the uboot. but now i am getting a
> message like no storage devices found .

Someone else has already suggested using a current
U-Boot version via git rather than v1.1.5, so I
will restrict my comments to the old 1.1.5 version.

> i gave the configurations in
> include/configs/at91rm9200dk.h
> like follows

> #define CONFIG_DOS_PARTITION 1
> #define CONFIG_USB_OHCI      1
> #define CONFIG_USB_STORAGE  1

I have a AT91SAM9261-EK (v1.1.5) with
working USB Storage that also includes  ...

#define LITTLEENDIAN        1

as part of the USB configuration.

> #define CONFIG_COMMANDS \
>       ((CONFIG_CMD_DFL | CFG_CMD_MII | CFG_CMD_NET | CFG_CMD_USB | \
> CFG_CMD_DHCP ) & \
>      ~(CFG_CMD_BDI | \
> CFG_CMD_IMI | \
> CFG_CMD_AUTOSCRIPT | \
> CFG_CMD_FPGA | \
> CFG_CMD_MISC | \
> CFG_CMD_LOADS))

> Is this configuration is right?
> i am not able to acess the USB stick
> using Storage USB Commands. My U-boot
> version is 1.1.5. 
> Any one can help?

--- When you get USB Storage working - either v1.1.5 or git ---

You will probably need (at least want)

#define CFG_CMD_FAT

or

#define CFG_CMD_EXT2

to access the FAT or ext2 directories and
files on the USB Storage device.

This may be useful if your kernel and
ramdisk are files on a FAT/ext2 filesystem
(rather than at a fixed locations on the
raw USB device).

u-boot> setenv bootcmd ...
u-boot> saveenv

--- VFAT ---

You may want to include the following for
long filename support (for FAT filesystems):

#define CONFIG_SUPPORT_VFAT

--- FAT16 vs. FAT32 - Atmel U-Boot v1.1.5 issue? ---

I have found that the USB support is better
when the USB Storage device is FAT16 formatted
rather than FAT32 formatted.  For some reason
not all files were accessible on FAT32
formatted media, but I never had any problem
with FAT16 formatted media.

Sincerely,

Ken Fuchs



From trimarchi at gandalf.sssup.it  Mon Apr 21 18:56:28 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Mon, 21 Apr 2008 18:56:28 +0200
Subject: [U-Boot-Users] USB SUPPORT
In-Reply-To: <AA28F077645B324881335614E4F7C428034CD1@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CD1@win-ex01.bench.com>
Message-ID: <480CC73C.8000509@gandalf.sssup.it>

Hi,
> #define CONFIG_SUPPORT_VFAT
>
> --- FAT16 vs. FAT32 - Atmel U-Boot v1.1.5 issue? ---
>
> I have found that the USB support is better
> when the USB Storage device is FAT16 formatted
> rather than FAT32 formatted.  For some reason
> not all files were accessible on FAT32
> formatted media, but I never had any problem
> with FAT16 formatted media.
>
> Sincerely,
>
> Ken Fuchs
>
>   
Can you try this patch?
In the git log there is another patch for vfat to be applied.
Regards Michael

Check if the entry is a valid dir_slot entry, otherwise it is a dentry 
and the
name has to be taken by the get_name function

Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>

---
 fs/fat/fat.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 49c78ed..ddee823 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -470,6 +470,12 @@ get_vfatname(fsdata *mydata, int curclust, __u8 
*cluster,
             return -1;
         }
         slotptr2 = (dir_slot*) get_vfatname_block;
+        if (slotptr2->attr != ATTR_VFAT) {
+            realdent = (dir_entry *)get_vfatname_block;
+            get_name ((dir_entry *)get_vfatname_block, l_name);
+            goto out;
+        }
+
         while (slotptr2->id > 0x01) {
             slotptr2++;
         }
@@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int curclust, __u8 
*cluster,
     else if (*l_name == aRING) *l_name = '?';
     downcase(l_name);
 
+out:
     /* Return the real directory entry */
     memcpy(retdent, realdent, sizeof(dir_entry));
 
-- 1.5.2.1.174.gcd03-dirty



From afleming at gmail.com  Mon Apr 21 19:17:49 2008
From: afleming at gmail.com (Andy Fleming)
Date: Mon, 21 Apr 2008 12:17:49 -0500
Subject: [U-Boot-Users] [PATCH v3] 85xx: Round up frequency calculations
	to get reasonable output
In-Reply-To: <Pine.LNX.4.64.0804210927530.18126@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804210927530.18126@blarg.am.freescale.net>
Message-ID: <2acbd3e40804211017t2a4695d7q1ff1b9c932d12e10@mail.gmail.com>

On Mon, Apr 21, 2008 at 9:28 AM, Kumar Gala <galak at kernel.crashing.org> wrote:
> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
>
>  Introduced DIV_ROUND_UP and roundup taken from linux kernel.
>
>  Signed-off-by: Dejan Minic <minic at freescale.com>
>  Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
>  Signed-off-by: Kumar Gala <galak at kernel.crashing.org>


Shouldn't this be two patches?  One to add the macros, and then one to
use them.  Technically, I'd be overstepping my authority to apply the
first patch.  Though I'd be happy to apply it if Wolfgang ACKs it.

Andy



From plagnioj at jcrosoft.com  Mon Apr 21 19:22:20 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 21 Apr 2008 19:22:20 +0200
Subject: [U-Boot-Users] [PATCH 2/2] qemu-mips: add full functionnalty and
	support of CONFIG_SMALLEST
In-Reply-To: <1208798540-22251-2-git-send-email-plagnioj@jcrosoft.com>
References: <1208798540-22251-1-git-send-email-plagnioj@jcrosoft.com>
	<1208798540-22251-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1208798540-22251-3-git-send-email-plagnioj@jcrosoft.com>

add support of :
#define CONFIG_CMD_ASKENV
#define CONFIG_CMD_LOADS
#define CONFIG_CMD_LOADB
#define CONFIG_CMD_PING
#define CONFIG_CMD_CDP
#define CONFIG_CMD_SAVES
#define CONFIG_CMD_SETEXPR

and keep only :
tftp and dhcp support when CONFIG_SMALLEST is active

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/Makefile b/Makefile
index ab56831..f0cfd76 100644
--- a/Makefile
+++ b/Makefile
@@ -2720,8 +2720,13 @@ gth2_config:	unconfig
 	@echo "#define CONFIG_GTH2 1" >$(obj)include/config.h
 	@$(MKCONFIG) -a gth2 mips mips gth2
 
+qemu_mips_smallest_config	\
 qemu_mips_config: unconfig
 	@mkdir -p $(obj)include
+	@[ -z "$(findstring _smallest_,$@)" ] || \
+		{ echo "#define CONFIG_SMALLEST 1" >>$(obj)include/config.h ; \
+		  $(XECHO) "... config with the minimal functionalities" ; \
+		}
 	@echo "#define CONFIG_QEMU_MIPS 1" >$(obj)include/config.h
 	@$(MKCONFIG) -a qemu-mips mips mips qemu-mips
 
diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index b775714..6a15413 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -71,10 +71,20 @@
 #include <config_cmd_default.h>
 
 #define CONFIG_CMD_ELF
+#ifndef CONFIG_SMALLEST
+#define CONFIG_CMD_ASKENV
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef	CONFIG_CMD_LOADB
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_CDP
+#define CONFIG_CMD_SAVES
+#define CONFIG_CMD_SETEXPR
+#else
 #undef	CONFIG_CMD_LOADS
+#undef	CONFIG_CMD_LOADB
+#undef	CONFIG_CMD_NFS
+#endif
+#undef	CONFIG_CMD_FPGA
 #define CONFIG_CMD_DHCP
 
 #define CONFIG_DRIVER_NE2000
@@ -87,6 +97,7 @@
 #define CFG_NS16550_COM1	(0xb40003f8)
 #define CONFIG_CONS_INDEX	1
 
+#ifndef CONFIG_SMALLEST
 #define CONFIG_CMD_IDE
 #define CONFIG_DOS_PARTITION
 
@@ -103,13 +114,16 @@
  * Miscellaneous configurable options
  */
 #define	CFG_LONGHELP				/* undef to save memory */
+#endif
 
 #define	CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt */
 
+#ifndef CONFIG_SMALLEST
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CFG_HUSH_PARSER
 #define CFG_PROMPT_HUSH_PS2	"> "
+#endif
 
 #define	CFG_CBSIZE		256		/* Console I/O Buffer Size */
 #define	CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)	/* Print Buffer Size */
-- 
1.5.4.5




From plagnioj at jcrosoft.com  Mon Apr 21 19:22:19 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 21 Apr 2008 19:22:19 +0200
Subject: [U-Boot-Users] [PATCH 1/2] qemu-mips: add CFI support and coding
	style cleanup
In-Reply-To: <1208798540-22251-1-git-send-email-plagnioj@jcrosoft.com>
References: <1208798540-22251-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1208798540-22251-2-git-send-email-plagnioj@jcrosoft.com>

add CONFIG_ENV_OVERWRITE

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index e164019..b775714 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -12,7 +12,7 @@
  *
  * 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
+ * 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
@@ -28,13 +28,14 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
-#define CONFIG_QEMU_MIPS        1
+#define CONFIG_MIPS32		1	/* MIPS32 CPU core	*/
+#define CONFIG_QEMU_MIPS	1
 #define CONFIG_MISC_INIT_R
 
 /*IP address is default used by Qemu*/
-#define CONFIG_IPADDR		10.0.2.15    	     /* Our IP address */
-#define CONFIG_SERVERIP		10.0.2.2	     /* Server IP address*/
+#define CONFIG_ENV_OVERWRITE	1
+#define CONFIG_IPADDR		10.0.2.15	/* Our IP address */
+#define CONFIG_SERVERIP		10.0.2.2	/* Server IP address*/
 
 #define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds	*/
 
@@ -56,7 +57,6 @@
 
 #define CONFIG_BOOTCOMMAND	"bootp;bootelf"
 
-
 /*
  * BOOTP options
  */
@@ -65,7 +65,6 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
-
 /*
  * Command line configuration.
  */
@@ -74,21 +73,18 @@
 #define CONFIG_CMD_ELF
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef  CONFIG_CMD_IMLS
-#undef  CONFIG_CMD_FLASH
-#undef  CONFIG_CMD_LOADB
-#undef  CONFIG_CMD_LOADS
+#undef	CONFIG_CMD_LOADB
+#undef	CONFIG_CMD_LOADS
 #define CONFIG_CMD_DHCP
 
 #define CONFIG_DRIVER_NE2000
 #define CONFIG_DRIVER_NE2000_BASE	(0xb4000300)
 
-#define CFG_NO_FLASH
 #define CFG_NS16550
 #define CFG_NS16550_SERIAL
-#define CFG_NS16550_REG_SIZE    1
-#define CFG_NS16550_CLK         115200
-#define CFG_NS16550_COM1        (0xb40003f8)
+#define CFG_NS16550_REG_SIZE	1
+#define CFG_NS16550_CLK		115200
+#define CFG_NS16550_COM1	(0xb40003f8)
 #define CONFIG_CONS_INDEX	1
 
 #define CONFIG_CMD_IDE
@@ -106,17 +102,17 @@
 /*
  * Miscellaneous configurable options
  */
-#define	CFG_LONGHELP				/* undef to save memory      */
+#define	CFG_LONGHELP				/* undef to save memory */
 
-#define	CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt    */
+#define	CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt */
 
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CFG_HUSH_PARSER
 #define CFG_PROMPT_HUSH_PS2	"> "
 
-#define	CFG_CBSIZE		256		/* Console I/O Buffer Size   */
-#define	CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)  /* Print Buffer Size */
+#define	CFG_CBSIZE		256		/* Console I/O Buffer Size */
+#define	CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)	/* Print Buffer Size */
 #define	CFG_MAXARGS		16		/* max number of command args*/
 
 #define CFG_MALLOC_LEN		128*1024
@@ -125,11 +121,11 @@
 
 #define CFG_MHZ			132
 
-#define CFG_HZ                  (CFG_MHZ * 1000000)
+#define CFG_HZ			(CFG_MHZ * 1000000)
 
-#define CFG_SDRAM_BASE		0x80000000     /* Cached addr */
+#define CFG_SDRAM_BASE		0x80000000	/* Cached addr */
 
-#define	CFG_LOAD_ADDR		0x81000000     /* default load address	*/
+#define	CFG_LOAD_ADDR		0x81000000	/* default load address	*/
 
 #define CFG_MEMTEST_START	0x80100000
 #define CFG_MEMTEST_END		0x80800000
@@ -146,11 +142,17 @@
 
 /* We boot from this flash, selected with dip switch */
 #define CFG_FLASH_BASE		0xbfc00000
-
-#define	CFG_ENV_IS_NOWHERE	1
-
+#define	CFG_MAX_FLASH_BANKS	1
+#define	CFG_MAX_FLASH_SECT	128
+#define	CFG_FLASH_CFI		1	/* Flash memory is CFI compliant */
+#define CFG_FLASH_CFI_DRIVER	1
+#define CFG_FLASH_USE_BUFFER_WRITE	1
+
+#define	CFG_ENV_IS_IN_FLASH	1
+#define CFG_ENV_ADDR		(CFG_FLASH_BASE+0x40000)
 /* Address and size of Primary Environment Sector	*/
-#define CFG_ENV_SIZE		0x10000
+#define CFG_ENV_SIZE		0x8000
+
 #undef CONFIG_NET_MULTI
 
 #define MEM_SIZE 128
-- 
1.5.4.5




From plagnioj at jcrosoft.com  Mon Apr 21 19:22:18 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 21 Apr 2008 19:22:18 +0200
Subject: [U-Boot-Users] [PATCH 0/2] NE2000: Fix regresssion introduced by
	e710185aae90 on non AX88796
Message-ID: <1208798540-22251-1-git-send-email-plagnioj@jcrosoft.com>

Move non-inlied functions into specific drivers file
Set get_prom as weak

Coding Style Cleanup

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Signed-off-by: Vlad Lungu <vlad at comsys.ro>

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d5e413b..4131aad 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -42,7 +42,10 @@ COBJS-y += lan91c96.o
 COBJS-y += macb.o
 COBJS-y += mcffec.o
 COBJS-y += natsemi.o
-COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o
+ifeq ($(CONFIG_DRIVER_NE2000),y)
+COBJS-y += ne2000.o
+COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o
+endif
 COBJS-y += netarm_eth.o
 COBJS-y += netconsole.o
 COBJS-y += ns7520_eth.o
diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
new file mode 100644
index 0000000..39cd101
--- /dev/null
+++ b/drivers/net/ax88796.c
@@ -0,0 +1,156 @@
+/*
+ * (c) 2007 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
+ *
+ * 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 <common.h>
+#include "ax88796.h"
+
+/*
+ * Set 1 bit data
+ */
+static void ax88796_bitset(u32 bit)
+{
+	/* DATA1 */
+	if( bit )
+		EEDI_HIGH;
+	else
+		EEDI_LOW;
+
+	EECLK_LOW;
+	udelay(1000);
+	EECLK_HIGH;
+	udelay(1000);
+	EEDI_LOW;
+}
+
+/*
+ * Get 1 bit data
+ */
+static u8 ax88796_bitget(void)
+{
+	u8 bit;
+
+	EECLK_LOW;
+	udelay(1000);
+	/* DATA */
+	bit = EEDO;
+	EECLK_HIGH;
+	udelay(1000);
+
+	return bit;
+}
+
+/*
+ * Send COMMAND to EEPROM
+ */
+static void ax88796_eep_cmd(u8 cmd)
+{
+	ax88796_bitset(BIT_DUMMY);
+	switch(cmd){
+		case MAC_EEP_READ:
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			break;
+
+		case MAC_EEP_WRITE:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(1);
+			break;
+
+		case MAC_EEP_ERACE:
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			break;
+
+		case MAC_EEP_EWEN:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(0);
+			break;
+
+		case MAC_EEP_EWDS:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(0);
+			break;
+		default:
+			break;
+	}
+}
+
+static void ax88796_eep_setaddr(u16 addr)
+{
+	int i ;
+
+	for( i = 7 ; i >= 0 ; i-- )
+		ax88796_bitset(addr & (1 << i));
+}
+
+/*
+ * Get data from EEPROM
+ */
+static u16 ax88796_eep_getdata(void)
+{
+	ushort data = 0;
+	int i;
+
+	ax88796_bitget();	/* DUMMY */
+	for( i = 0 ; i < 16 ; i++ ){
+		data <<= 1;
+		data |= ax88796_bitget();
+	}
+	return data;
+}
+
+static void ax88796_mac_read(u8 *buff)
+{
+	int i ;
+	u16 data;
+	u16 addr = 0;
+
+	for( i = 0 ; i < 3; i++ )
+	{
+		EECS_HIGH;
+		EEDI_LOW;
+		udelay(1000);
+		/* READ COMMAND */
+		ax88796_eep_cmd(MAC_EEP_READ);
+		/* ADDRESS */
+		ax88796_eep_setaddr(addr++);
+		/* GET DATA */
+		data = ax88796_eep_getdata();
+		*buff++ = (uchar)(data & 0xff);
+		*buff++ = (uchar)((data >> 8) & 0xff);
+		EECLK_LOW;
+		EEDI_LOW;
+		EECS_LOW;
+	}
+}
+
+int get_prom(u8* mac_addr)
+{
+	u8 prom[32];
+	int i;
+
+	ax88796_mac_read(prom);
+	for (i = 0; i < 6; i++){
+		mac_addr[i] = prom[i];
+	}
+	return 1;
+}
diff --git a/drivers/net/ax88796.h b/drivers/net/ax88796.h
index 069ae80..aa342cb 100644
--- a/drivers/net/ax88796.h
+++ b/drivers/net/ax88796.h
@@ -79,139 +79,5 @@
 #endif
 
 
-/*
- * Set 1 bit data
- */
-static void ax88796_bitset(u32 bit)
-{
-	/* DATA1 */
-	if( bit )
-		EEDI_HIGH;
-	else
-		EEDI_LOW;
-
-	EECLK_LOW;
-	udelay(1000);
-	EECLK_HIGH;
-	udelay(1000);
-	EEDI_LOW;
-}
-
-/*
- * Get 1 bit data
- */
-static u8 ax88796_bitget(void)
-{
-	u8 bit;
-
-	EECLK_LOW;
-	udelay(1000);
-	/* DATA */
-	bit = EEDO;
-	EECLK_HIGH;
-	udelay(1000);
-
-	return bit;
-}
-
-/*
- * Send COMMAND to EEPROM
- */
-static void ax88796_eep_cmd(u8 cmd)
-{
-	ax88796_bitset(BIT_DUMMY);
-	switch(cmd){
-		case MAC_EEP_READ:
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			break;
-
-		case MAC_EEP_WRITE:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(1);
-			break;
-
-		case MAC_EEP_ERACE:
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			break;
-
-		case MAC_EEP_EWEN:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(0);
-			break;
-
-		case MAC_EEP_EWDS:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(0);
-			break;
-		default:
-			break;
-	}
-}
-
-static void ax88796_eep_setaddr(u16 addr)
-{
-	int i ;
-	for( i = 7 ; i >= 0 ; i-- )
-		ax88796_bitset(addr & (1 << i));
-}
-
-/*
- * Get data from EEPROM
- */
-static u16 ax88796_eep_getdata(void)
-{
-	ushort data = 0;
-	int i;
-
-	ax88796_bitget();	/* DUMMY */
-	for( i = 0 ; i < 16 ; i++ ){
-		data <<= 1;
-		data |= ax88796_bitget();
-	}
-	return data;
-}
-
-static void ax88796_mac_read(u8 *buff)
-{
-	int i ;
-	u16 data, addr = 0;
-
-	for( i = 0 ; i < 3; i++ )
-	{
-		EECS_HIGH;
-		EEDI_LOW;
-		udelay(1000);
-		/* READ COMMAND */
-		ax88796_eep_cmd(MAC_EEP_READ);
-		/* ADDRESS */
-		ax88796_eep_setaddr(addr++);
-		/* GET DATA */
-		data = ax88796_eep_getdata();
-		*buff++ = (uchar)(data & 0xff);
-		*buff++ = (uchar)((data >> 8) & 0xff);
-		EECLK_LOW;
-		EEDI_LOW;
-		EECS_LOW;
-	}
-}
-
-int get_prom(u8* mac_addr)
-{
-	u8 prom[32];
-	int i;
-
-	ax88796_mac_read(prom);
-	for (i = 0; i < 6; i++){
-		mac_addr[i] = prom[i];
-	}
-	return 1;
-}
 
 #endif /* __DRIVERS_AX88796L_H__ */
diff --git a/drivers/net/ne2000.c b/drivers/net/ne2000.c
index 99baeea..3f32693 100644
--- a/drivers/net/ne2000.c
+++ b/drivers/net/ne2000.c
@@ -1,5 +1,5 @@
 /*
-Ported to U-Boot  by Christian Pellegrin <chri at ascensit.com>
+Ported to U-Boot by Christian Pellegrin <chri at ascensit.com>
 
 Based on sources from the Linux kernel (pcnet_cs.c, 8390.h) and
 eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2 wonderful world
@@ -23,7 +23,7 @@ Software Foundation; either version 2 or (at your option) any later version.
 
 eCos 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
+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
@@ -57,13 +57,13 @@ and are covered by the appropriate copyright disclaimers included herein.
 ==========================================================================
 #####DESCRIPTIONBEGIN####
 
-Author(s):    gthomas
-Contributors: gthomas, jskov, rsandifo
-Date:	      2001-06-13
+Author(s):	gthomas
+Contributors:	gthomas, jskov, rsandifo
+Date:		2001-06-13
 Purpose:
 Description:
 
-FIXME:	      Will fail if pinged with large packets (1520 bytes)
+FIXME:		Will fail if pinged with large packets (1520 bytes)
 Add promisc config
 Add SNMP
 
@@ -77,24 +77,26 @@ Add SNMP
 #include <net.h>
 #include <malloc.h>
 
-#define mdelay(n)       udelay((n)*1000)
+#define mdelay(n)	udelay((n)*1000)
 /* forward definition of function used for the uboot interface */
 void uboot_push_packet_len(int len);
 void uboot_push_tx_done(int key, int val);
 
 /*
-  ------------------------------------------------------------------------
-  Debugging details
-
-  Set to perms of:
-  0 disables all debug output
-  1 for process debug output
-  2 for added data IO output: get_reg, put_reg
-  4 for packet allocation/free output
-  8 for only startup status, so we can tell we're installed OK
-*/
-/*#define DEBUG 0xf*/
+ * Debugging details
+ *
+ * Set to perms of:
+ * 0 disables all debug output
+ * 1 for process debug output
+ * 2 for added data IO output: get_reg, put_reg
+ * 4 for packet allocation/free output
+ * 8 for only startup status, so we can tell we're installed OK
+ */
+#if 0
+#define DEBUG 0xf
+#else
 #define DEBUG 0
+#endif
 
 #if DEBUG & 1
 #define DEBUG_FUNCTION() do { printf("%s\n", __FUNCTION__); } while (0)
@@ -124,31 +126,35 @@ dp83902a_init(void)
 {
 	dp83902a_priv_data_t *dp = &nic;
 	u8* base;
+#if defined(NE2000_BASIC_INIT)
+	int i;
+#endif
 
 	DEBUG_FUNCTION();
 
 	base = dp->base;
-	if (!base) return false;  /* No device found */
+	if (!base)
+		return false;	/* No device found */
 
 	DEBUG_LINE();
 
 #if defined(NE2000_BASIC_INIT)
 	/* AX88796L doesn't need */
 	/* Prepare ESA */
-	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE1);  /* Select page 1 */
+	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE1);	/* Select page 1 */
 	/* Use the address from the serial EEPROM */
 	for (i = 0; i < 6; i++)
 		DP_IN(base, DP_P1_PAR0+i, dp->esa[i]);
-	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE0);  /* Select page 0 */
+	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE0);	/* Select page 0 */
 
 	printf("NE2000 - %s ESA: %02x:%02x:%02x:%02x:%02x:%02x\n",
-	       "eeprom",
-	       dp->esa[0],
-	       dp->esa[1],
-	       dp->esa[2],
-	       dp->esa[3],
-	       dp->esa[4],
-	       dp->esa[5] );
+		"eeprom",
+		dp->esa[0],
+		dp->esa[1],
+		dp->esa[2],
+		dp->esa[3],
+		dp->esa[4],
+		dp->esa[5] );
 
 #endif	/* NE2000_BASIC_INIT */
 	return true;
@@ -162,7 +168,7 @@ dp83902a_stop(void)
 
 	DEBUG_FUNCTION();
 
-	DP_OUT(base, DP_CR, DP_CR_PAGE0 | DP_CR_NODMA | DP_CR_STOP);  /* Brutal */
+	DP_OUT(base, DP_CR, DP_CR_PAGE0 | DP_CR_NODMA | DP_CR_STOP);	/* Brutal */
 	DP_OUT(base, DP_ISR, 0xFF);		/* Clear any pending interrupts */
 	DP_OUT(base, DP_IMR, 0x00);		/* Disable all interrupts */
 
@@ -170,11 +176,11 @@ dp83902a_stop(void)
 }
 
 /*
-  This function is called to "start up" the interface.  It may be called
-  multiple times, even when the hardware is already running.  It will be
-  called whenever something "hardware oriented" changes and should leave
-  the hardware ready to send/receive packets.
-*/
+ * This function is called to "start up" the interface. It may be called
+ * multiple times, even when the hardware is already running. It will be
+ * called whenever something "hardware oriented" changes and should leave
+ * the hardware ready to send/receive packets.
+ */
 static void
 dp83902a_start(u8 * enaddr)
 {
@@ -196,16 +202,16 @@ dp83902a_start(u8 * enaddr)
 	dp->tx_started = false;
 	dp->running = true;
 	DP_OUT(base, DP_PSTART, dp->rx_buf_start); /* Receive ring start page */
-	DP_OUT(base, DP_BNDRY, dp->rx_buf_end-1); /* Receive ring boundary */
+	DP_OUT(base, DP_BNDRY, dp->rx_buf_end - 1); /* Receive ring boundary */
 	DP_OUT(base, DP_PSTOP, dp->rx_buf_end);	/* Receive ring end page */
-	dp->rx_next = dp->rx_buf_start-1;
+	dp->rx_next = dp->rx_buf_start - 1;
 	dp->running = true;
 	DP_OUT(base, DP_ISR, 0xFF);		/* Clear any pending interrupts */
 	DP_OUT(base, DP_IMR, DP_IMR_All);	/* Enable all interrupts */
-	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE1 | DP_CR_STOP);  /* Select page 1 */
-	DP_OUT(base, DP_P1_CURP, dp->rx_buf_start);   /* Current page - next free page for Rx */
+	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE1 | DP_CR_STOP);	/* Select page 1 */
+	DP_OUT(base, DP_P1_CURP, dp->rx_buf_start);	/* Current page - next free page for Rx */
 	dp->running = true;
-	for (i = 0;  i < ETHER_ADDR_LEN;  i++) {
+	for (i = 0; i < ETHER_ADDR_LEN; i++) {
 		/* FIXME */
 		/*((vu_short*)( base + ((DP_P1_PAR0 + i) * 2) +
 		 * 0x1400)) = enaddr[i];*/
@@ -214,15 +220,15 @@ dp83902a_start(u8 * enaddr)
 	/* Enable and start device */
 	DP_OUT(base, DP_CR, DP_CR_PAGE0 | DP_CR_NODMA | DP_CR_START);
 	DP_OUT(base, DP_TCR, DP_TCR_NORMAL); /* Normal transmit operations */
-	DP_OUT(base, DP_RCR, DP_RCR_AB);  /* Accept broadcast, no errors, no multicast */
+	DP_OUT(base, DP_RCR, DP_RCR_AB); /* Accept broadcast, no errors, no multicast */
 	dp->running = true;
 }
 
 /*
-  This routine is called to start the transmitter.  It is split out from the
-  data handling routine so it may be called either when data becomes first
-  available or when an Tx interrupt occurs
-*/
+ * This routine is called to start the transmitter. It is split out from the
+ * data handling routine so it may be called either when data becomes first
+ * available or when an Tx interrupt occurs
+ */
 
 static void
 dp83902a_start_xmit(int start_page, int len)
@@ -249,9 +255,9 @@ dp83902a_start_xmit(int start_page, int len)
 }
 
 /*
-  This routine is called to send data to the hardware.  It is known a-priori
-  that there is free buffer space (dp->tx_next).
-*/
+ * This routine is called to send data to the hardware. It is known a-priori
+ * that there is free buffer space (dp->tx_next).
+ */
 static void
 dp83902a_send(u8 *data, int total_len, u32 key)
 {
@@ -265,7 +271,8 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 	DEBUG_FUNCTION();
 
 	len = pkt_len = total_len;
-	if (pkt_len < IEEE_8023_MIN_FRAME) pkt_len = IEEE_8023_MIN_FRAME;
+	if (pkt_len < IEEE_8023_MIN_FRAME)
+		pkt_len = IEEE_8023_MIN_FRAME;
 
 	start_page = dp->tx_next;
 	if (dp->tx_next == dp->tx_buf1) {
@@ -284,17 +291,19 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 	printf("TX prep page %d len %d\n", start_page, pkt_len);
 #endif
 
-	DP_OUT(base, DP_ISR, DP_ISR_RDC);  /* Clear end of DMA */
+	DP_OUT(base, DP_ISR, DP_ISR_RDC);	/* Clear end of DMA */
 	{
-		/* Dummy read. The manual sez something slightly different, */
-		/* but the code is extended a bit to do what Hitachi's monitor */
-		/* does (i.e., also read data). */
+		/*
+		 * Dummy read. The manual sez something slightly different,
+		 * but the code is extended a bit to do what Hitachi's monitor
+		 * does (i.e., also read data).
+		 */
 
 		u16 tmp;
 		int len = 1;
 
-		DP_OUT(base, DP_RSAL, 0x100-len);
-		DP_OUT(base, DP_RSAH, (start_page-1) & 0xff);
+		DP_OUT(base, DP_RSAL, 0x100 - len);
+		DP_OUT(base, DP_RSAH, (start_page - 1) & 0xff);
 		DP_OUT(base, DP_RBCL, len);
 		DP_OUT(base, DP_RBCH, 0);
 		DP_OUT(base, DP_CR, DP_CR_PAGE0 | DP_CR_RDMA | DP_CR_START);
@@ -302,8 +311,10 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 	}
 
 #ifdef CYGHWR_NS_DP83902A_PLF_BROKEN_TX_DMA
-	/* Stall for a bit before continuing to work around random data */
-	/* corruption problems on some platforms. */
+	/*
+	 * Stall for a bit before continuing to work around random data
+	 * corruption problems on some platforms.
+	 */
 	CYGACC_CALL_IF_DELAY_US(1);
 #endif
 
@@ -336,16 +347,18 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 		printf("  + %d bytes of padding\n", pkt_len - total_len);
 #endif
 		/* Padding to 802.3 length was required */
-		for (i = total_len;  i < pkt_len;) {
+		for (i = total_len; i < pkt_len;) {
 			i++;
 			DP_OUT_DATA(dp->data, 0);
 		}
 	}
 
 #ifdef CYGHWR_NS_DP83902A_PLF_BROKEN_TX_DMA
-	/* After last data write, delay for a bit before accessing the */
-	/* device again, or we may get random data corruption in the last */
-	/* datum (on some platforms). */
+	/*
+	 * After last data write, delay for a bit before accessing the
+	 * device again, or we may get random data corruption in the last
+	 * datum (on some platforms).
+	 */
 	CYGACC_CALL_IF_DELAY_US(1);
 #endif
 
@@ -360,21 +373,21 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 	/* Start transmit if not already going */
 	if (!dp->tx_started) {
 		if (start_page == dp->tx1) {
-			dp->tx_int = 1;  /* Expecting interrupt from BUF1 */
+			dp->tx_int = 1; /* Expecting interrupt from BUF1 */
 		} else {
-			dp->tx_int = 2;  /* Expecting interrupt from BUF2 */
+			dp->tx_int = 2; /* Expecting interrupt from BUF2 */
 		}
 		dp83902a_start_xmit(start_page, pkt_len);
 	}
 }
 
 /*
-  This function is called when a packet has been received.  It's job is
-  to prepare to unload the packet from the hardware.  Once the length of
-  the packet is known, the upper layer of the driver can be told.  When
-  the upper layer is ready to unload the packet, the internal function
-  'dp83902a_recv' will be called to actually fetch it from the hardware.
-*/
+ * This function is called when a packet has been received. It's job is
+ * to prepare to unload the packet from the hardware. Once the length of
+ * the packet is known, the upper layer of the driver can be told. When
+ * the upper layer is ready to unload the packet, the internal function
+ * 'dp83902a_recv' will be called to actually fetch it from the hardware.
+ */
 static void
 dp83902a_RxEvent(void)
 {
@@ -407,9 +420,9 @@ dp83902a_RxEvent(void)
 		DP_OUT(base, DP_RSAH, pkt);
 		if (dp->rx_next == pkt) {
 			if (cur == dp->rx_buf_start)
-				DP_OUT(base, DP_BNDRY, dp->rx_buf_end-1);
+				DP_OUT(base, DP_BNDRY, dp->rx_buf_end - 1);
 			else
-				DP_OUT(base, DP_BNDRY, cur-1); /* Update pointer */
+				DP_OUT(base, DP_BNDRY, cur - 1); /* Update pointer */
 			return;
 		}
 		dp->rx_next = pkt;
@@ -420,13 +433,13 @@ dp83902a_RxEvent(void)
 #endif
 
 		/* read header (get data size)*/
-		for (i = 0;  i < sizeof(rcv_hdr);) {
+		for (i = 0; i < sizeof(rcv_hdr);) {
 			DP_IN_DATA(dp->data, rcv_hdr[i++]);
 		}
 
 #if DEBUG & 5
 		printf("rx hdr %02x %02x %02x %02x\n",
-		       rcv_hdr[0], rcv_hdr[1], rcv_hdr[2], rcv_hdr[3]);
+			rcv_hdr[0], rcv_hdr[1], rcv_hdr[2], rcv_hdr[3]);
 #endif
 		len = ((rcv_hdr[3] << 8) | rcv_hdr[2]) - sizeof(rcv_hdr);
 
@@ -434,19 +447,19 @@ dp83902a_RxEvent(void)
 		uboot_push_packet_len(len);
 
 		if (rcv_hdr[1] == dp->rx_buf_start)
-			DP_OUT(base, DP_BNDRY, dp->rx_buf_end-1);
+			DP_OUT(base, DP_BNDRY, dp->rx_buf_end - 1);
 		else
-			DP_OUT(base, DP_BNDRY, rcv_hdr[1]-1); /* Update pointer */
+			DP_OUT(base, DP_BNDRY, rcv_hdr[1] - 1); /* Update pointer */
 	}
 }
 
 /*
-  This function is called as a result of the "eth_drv_recv()" call above.
-  It's job is to actually fetch data for a packet from the hardware once
-  memory buffers have been allocated for the packet.  Note that the buffers
-  may come in pieces, using a scatter-gather list.  This allows for more
-  efficient processing in the upper layers of the stack.
-*/
+ * This function is called as a result of the "eth_drv_recv()" call above.
+ * It's job is to actually fetch data for a packet from the hardware once
+ * memory buffers have been allocated for the packet. Note that the buffers
+ * may come in pieces, using a scatter-gather list. This allows for more
+ * efficient processing in the upper layers of the stack.
+ */
 static void
 dp83902a_recv(u8 *data, int len)
 {
@@ -478,7 +491,7 @@ dp83902a_recv(u8 *data, int len)
 #endif
 
 	saved = false;
-	for (i = 0;  i < 1;  i++) {
+	for (i = 0; i < 1; i++) {
 		if (data) {
 			mlen = len;
 #if DEBUG & 4
@@ -545,8 +558,10 @@ dp83902a_TxEvent(void)
 	uboot_push_tx_done(key, 0);
 }
 
-/* Read the tally counters to clear them.  Called in response to a CNT */
-/* interrupt. */
+/*
+ * Read the tally counters to clear them. Called in response to a CNT
+ * interrupt.
+ */
 static void
 dp83902a_ClearCounters(void)
 {
@@ -560,8 +575,10 @@ dp83902a_ClearCounters(void)
 	DP_OUT(base, DP_ISR, DP_ISR_CNT);
 }
 
-/* Deal with an overflow condition.  This code follows the procedure set */
-/* out in section 7.0 of the datasheet. */
+/*
+ * Deal with an overflow condition. This code follows the procedure set
+ * out in section 7.0 of the datasheet.
+ */
 static void
 dp83902a_Overflow(void)
 {
@@ -581,9 +598,11 @@ dp83902a_Overflow(void)
 	DP_OUT(base, DP_TCR, DP_TCR_LOCAL);
 	DP_OUT(base, DP_CR, DP_CR_START | DP_CR_NODMA);
 
-	/* Read in as many packets as we can and acknowledge any and receive */
-	/* interrupts.  Since the buffer has overflowed, a receive event of */
-	/* some kind will have occured. */
+	/*
+	 * Read in as many packets as we can and acknowledge any and receive
+	 * interrupts. Since the buffer has overflowed, a receive event of
+	 * some kind will have occured.
+	 */
 	dp83902a_RxEvent();
 	DP_OUT(base, DP_ISR, DP_ISR_RxP|DP_ISR_RxE);
 
@@ -591,8 +610,10 @@ dp83902a_Overflow(void)
 	DP_OUT(base, DP_ISR, DP_ISR_OFLW);
 	DP_OUT(base, DP_TCR, DP_TCR_NORMAL);
 
-	/* If a transmit command was issued, but no transmit event has occured, */
-	/* restart it here. */
+	/*
+	 * If a transmit command was issued, but no transmit event has occured,
+	 * restart it here.
+	 */
 	DP_IN(base, DP_ISR, isr);
 	if (dp->tx_started && !(isr & (DP_ISR_TxP|DP_ISR_TxE))) {
 		DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_TXPKT | DP_CR_START);
@@ -609,25 +630,33 @@ dp83902a_poll(void)
 	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE0 | DP_CR_START);
 	DP_IN(base, DP_ISR, isr);
 	while (0 != isr) {
-		/* The CNT interrupt triggers when the MSB of one of the error */
-		/* counters is set.  We don't much care about these counters, but */
-		/* we should read their values to reset them. */
+		/*
+		 * The CNT interrupt triggers when the MSB of one of the error
+		 * counters is set. We don't much care about these counters, but
+		 * we should read their values to reset them.
+		 */
 		if (isr & DP_ISR_CNT) {
 			dp83902a_ClearCounters();
 		}
-		/* Check for overflow.  It's a special case, since there's a */
-		/* particular procedure that must be followed to get back into */
-		/* a running state.a */
+		/*
+		 * Check for overflow. It's a special case, since there's a
+		 * particular procedure that must be followed to get back into
+		 * a running state.a
+		 */
 		if (isr & DP_ISR_OFLW) {
 			dp83902a_Overflow();
 		} else {
-			/* Other kinds of interrupts can be acknowledged simply by */
-			/* clearing the relevant bits of the ISR.  Do that now, then */
-			/* handle the interrupts we care about. */
-			DP_OUT(base, DP_ISR, isr);      /* Clear set bits */
+			/*
+			 * Other kinds of interrupts can be acknowledged simply by
+			 * clearing the relevant bits of the ISR. Do that now, then
+			 * handle the interrupts we care about.
+			 */
+			DP_OUT(base, DP_ISR, isr);	/* Clear set bits */
 			if (!dp->running) break;	/* Is this necessary? */
-			/* Check for tx_started on TX event since these may happen */
-			/* spuriously it seems. */
+			/*
+			 * Check for tx_started on TX event since these may happen
+			 * spuriously it seems.
+			 */
 			if (isr & (DP_ISR_TxP|DP_ISR_TxE) && dp->tx_started) {
 				dp83902a_TxEvent();
 			}
@@ -658,8 +687,8 @@ typedef struct hw_info_t {
 #define HAS_MII		0x40
 #define USE_SHMEM	0x80	/* autodetected */
 
-#define AM79C9XX_HOME_PHY	0x00006B90  /* HomePNA PHY */
-#define AM79C9XX_ETH_PHY	0x00006B70  /* 10baseT PHY */
+#define AM79C9XX_HOME_PHY	0x00006B90	/* HomePNA PHY */
+#define AM79C9XX_ETH_PHY	0x00006B70	/* 10baseT PHY */
 #define MII_PHYID_REV_MASK	0xfffffff0
 #define MII_PHYID_REG1		0x02
 #define MII_PHYID_REG2		0x03
@@ -669,7 +698,7 @@ static hw_info_t hw_info[] = {
 	{ /* Allied Telesis LA-PCM */ 0x0ff0, 0x00, 0x00, 0xf4, 0 },
 	{ /* APEX MultiCard */ 0x03f4, 0x00, 0x20, 0xe5, 0 },
 	{ /* ASANTE FriendlyNet */ 0x4910, 0x00, 0x00, 0x94,
-	  DELAY_OUTPUT | HAS_IBM_MISC },
+			DELAY_OUTPUT | HAS_IBM_MISC },
 	{ /* Danpex EN-6200P2 */ 0x0110, 0x00, 0x40, 0xc7, 0 },
 	{ /* DataTrek NetCard */ 0x0ff0, 0x00, 0x20, 0xe8, 0 },
 	{ /* Dayna CommuniCard E */ 0x0110, 0x00, 0x80, 0x19, 0 },
@@ -677,48 +706,48 @@ static hw_info_t hw_info[] = {
 	{ /* EP-210 Ethernet */ 0x0110, 0x00, 0x40, 0x33, 0 },
 	{ /* EP4000 Ethernet */ 0x01c0, 0x00, 0x00, 0xb4, 0 },
 	{ /* Epson EEN10B */ 0x0ff0, 0x00, 0x00, 0x48,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* ELECOM Laneed LD-CDWA */ 0xb8, 0x08, 0x00, 0x42, 0 },
 	{ /* Hypertec Ethernet */ 0x01c0, 0x00, 0x40, 0x4c, 0 },
 	{ /* IBM CCAE */ 0x0ff0, 0x08, 0x00, 0x5a,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* IBM CCAE */ 0x0ff0, 0x00, 0x04, 0xac,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* IBM CCAE */ 0x0ff0, 0x00, 0x06, 0x29,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* IBM FME */ 0x0374, 0x08, 0x00, 0x5a,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* IBM FME */ 0x0374, 0x00, 0x04, 0xac,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* Kansai KLA-PCM/T */ 0x0ff0, 0x00, 0x60, 0x87,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* NSC DP83903 */ 0x0374, 0x08, 0x00, 0x17,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* NSC DP83903 */ 0x0374, 0x00, 0xc0, 0xa8,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* NSC DP83903 */ 0x0374, 0x00, 0xa0, 0xb0,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* NSC DP83903 */ 0x0198, 0x00, 0x20, 0xe0,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* I-O DATA PCLA/T */ 0x0ff0, 0x00, 0xa0, 0xb0, 0 },
 	{ /* Katron PE-520 */ 0x0110, 0x00, 0x40, 0xf6, 0 },
 	{ /* Kingston KNE-PCM/x */ 0x0ff0, 0x00, 0xc0, 0xf0,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* Kingston KNE-PCM/x */ 0x0ff0, 0xe2, 0x0c, 0x0f,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* Kingston KNE-PC2 */ 0x0180, 0x00, 0xc0, 0xf0, 0 },
 	{ /* Maxtech PCN2000 */ 0x5000, 0x00, 0x00, 0xe8, 0 },
 	{ /* NDC Instant-Link */ 0x003a, 0x00, 0x80, 0xc6, 0 },
 	{ /* NE2000 Compatible */ 0x0ff0, 0x00, 0xa0, 0x0c, 0 },
 	{ /* Network General Sniffer */ 0x0ff0, 0x00, 0x00, 0x65,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* Panasonic VEL211 */ 0x0ff0, 0x00, 0x80, 0x45,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* PreMax PE-200 */ 0x07f0, 0x00, 0x20, 0xe0, 0 },
 	{ /* RPTI EP400 */ 0x0110, 0x00, 0x40, 0x95, 0 },
 	{ /* SCM Ethernet */ 0x0ff0, 0x00, 0x20, 0xcb, 0 },
 	{ /* Socket EA */ 0x4000, 0x00, 0xc0, 0x1b,
-	  DELAY_OUTPUT | HAS_MISC_REG | USE_BIG_BUF },
+			DELAY_OUTPUT | HAS_MISC_REG | USE_BIG_BUF },
 	{ /* Socket LP-E CF+ */ 0x01c0, 0x00, 0xc0, 0x1b, 0 },
 	{ /* SuperSocket RE450T */ 0x0110, 0x00, 0xe0, 0x98, 0 },
 	{ /* Volktek NPL-402CT */ 0x0060, 0x00, 0x40, 0x05, 0 },
@@ -729,8 +758,6 @@ static hw_info_t hw_info[] = {
 
 #define NR_INFO		(sizeof(hw_info)/sizeof(hw_info_t))
 
-static hw_info_t default_info = { 0, 0, 0, 0, 0 };
-
 u8 dev_addr[6];
 
 #define PCNET_CMD	0x00
@@ -738,17 +765,104 @@ u8 dev_addr[6];
 #define PCNET_RESET	0x1f	/* Issue a read to reset, a write to clear. */
 #define PCNET_MISC	0x18	/* For IBM CCAE and Socket EA cards */
 
+static void pcnet_reset_8390(void)
+{
+	int i, r;
+
+	PRINTK("nic base is %lx\n", nic_base);
+
+	n2k_outb(E8390_NODMA + E8390_PAGE0+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+
+	n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
+
+	for (i = 0; i < 100; i++) {
+		if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
+			break;
+		PRINTK("got %x in reset\n", r);
+		udelay(100);
+	}
+	n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
+
+	if (i == 100)
+		printf("pcnet_reset_8390() did not complete.\n");
+} /* pcnet_reset_8390 */
+
+int get_prom(u8* mac_addr) __attribute__ ((weak, alias ("__get_prom")));
+int __get_prom(u8* mac_addr)
+{
+	u8 prom[32];
+	int i, j;
+	struct {
+		u_char value, offset;
+	} program_seq[] = {
+		{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
+		{0x48, EN0_DCFG},		/* Set byte-wide (0x48) access. */
+		{0x00, EN0_RCNTLO},		/* Clear the count regs. */
+		{0x00, EN0_RCNTHI},
+		{0x00, EN0_IMR},		/* Mask completion irq. */
+		{0xFF, EN0_ISR},
+		{E8390_RXOFF, EN0_RXCR},	/* 0x20 Set to monitor */
+		{E8390_TXOFF, EN0_TXCR},	/* 0x02 and loopback mode. */
+		{32, EN0_RCNTLO},
+		{0x00, EN0_RCNTHI},
+		{0x00, EN0_RSARLO},		/* DMA starting at 0x0000. */
+		{0x00, EN0_RSARHI},
+		{E8390_RREAD+E8390_START, E8390_CMD},
+	};
+
+	PRINTK ("trying to get MAC via prom reading\n");
+
+	pcnet_reset_8390 ();
+
+	mdelay (10);
+
+	for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
+		n2k_outb (program_seq[i].value, program_seq[i].offset);
+
+	PRINTK ("PROM:");
+	for (i = 0; i < 32; i++) {
+		prom[i] = n2k_inb (PCNET_DATAPORT);
+		PRINTK (" %02x", prom[i]);
+	}
+	PRINTK ("\n");
+	for (i = 0; i < NR_INFO; i++) {
+		if ((prom[0] == hw_info[i].a0) &&
+			(prom[2] == hw_info[i].a1) &&
+			(prom[4] == hw_info[i].a2)) {
+			PRINTK ("matched board %d\n", i);
+			break;
+		}
+	}
+	if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
+		PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
+		PRINTK ("MAC address is ");
+		for (j = 0; j < 6; j++) {
+			mac_addr[j] = prom[j << 1];
+			PRINTK ("%02x:", mac_addr[i]);
+		}
+		PRINTK ("\n");
+		return (i < NR_INFO) ? i : 0;
+	}
+	return 0;
+}
+
 u32 nic_base;
 
 /* U-boot specific routines */
 static u8 *pbuf = NULL;
 
 static int pkey = -1;
-static int initialized=0;
+static int initialized = 0;
 
 void uboot_push_packet_len(int len) {
 	PRINTK("pushed len = %d\n", len);
-	if (len>=2000) {
+	if (len >= 2000) {
 		printf("NE2000: packet too big\n");
 		return;
 	}
@@ -764,7 +878,7 @@ void uboot_push_tx_done(int key, int val) {
 }
 
 int eth_init(bd_t *bd) {
-	static hw_info_t * r;
+	int r;
 	char ethaddr[20];
 
 	PRINTK("### eth_init\n");
@@ -779,7 +893,7 @@ int eth_init(bd_t *bd) {
 
 #ifdef CONFIG_DRIVER_NE2000_CCR
 	{
-		vu_char *p =  (vu_char *) CONFIG_DRIVER_NE2000_CCR;
+		vu_char *p = (vu_char *) CONFIG_DRIVER_NE2000_CCR;
 
 		PRINTK("CCR before is %x\n", *p);
 		*p = CONFIG_DRIVER_NE2000_VAL;
@@ -811,7 +925,7 @@ int eth_init(bd_t *bd) {
 		return -1;
 
 	dp83902a_start(dev_addr);
-	initialized=1;
+	initialized = 1;
 
 	return 0;
 }
@@ -821,7 +935,7 @@ void eth_halt() {
 	PRINTK("### eth_halt\n");
 	if(initialized)
 		dp83902a_stop();
-	initialized=0;
+	initialized = 0;
 }
 
 int eth_rx() {
diff --git a/drivers/net/ne2000.h b/drivers/net/ne2000.h
index d324a00..0b21612 100644
--- a/drivers/net/ne2000.h
+++ b/drivers/net/ne2000.h
@@ -81,6 +81,7 @@ are GPL, so this is, of course, GPL.
 
 #define DP_DATA     0x10
 #define START_PG    0x50    /* First page of TX buffer */
+#define START_PG2   0x48
 #define STOP_PG     0x80    /* Last page +1 of RX ring */
 
 #define RX_START    0x50
@@ -90,90 +91,4 @@ are GPL, so this is, of course, GPL.
 #define DP_OUT(_b_, _o_, _d_) *( (vu_char *) ((_b_)+(_o_))) = (_d_)
 #define DP_IN_DATA(_b_, _d_)  (_d_) = *( (vu_char *) ((_b_)))
 #define DP_OUT_DATA(_b_, _d_) *( (vu_char *) ((_b_))) = (_d_)
-
-static void pcnet_reset_8390(void)
-{
-	int i, r;
-
-	PRINTK("nic base is %lx\n", nic_base);
-
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-
-	n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
-
-	for (i = 0; i < 100; i++) {
-		if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
-			break;
-		PRINTK("got %x in reset\n", r);
-		udelay(100);
-	}
-	n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
-
-	if (i == 100)
-		printf("pcnet_reset_8390() did not complete.\n");
-} /* pcnet_reset_8390 */
-
-int get_prom(u8* mac_addr)
-{
-	u8 prom[32];
-	int i, j;
-	struct {
-		u_char value, offset;
-	} program_seq[] = {
-		{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
-		{0x48,  EN0_DCFG},		/* Set byte-wide (0x48) access. */
-		{0x00,  EN0_RCNTLO},		/* Clear the count regs. */
-		{0x00,  EN0_RCNTHI},
-		{0x00,  EN0_IMR},		/* Mask completion irq. */
-		{0xFF,  EN0_ISR},
-		{E8390_RXOFF, EN0_RXCR},	/* 0x20  Set to monitor */
-		{E8390_TXOFF, EN0_TXCR},	/* 0x02  and loopback mode. */
-		{32,    EN0_RCNTLO},
-		{0x00,  EN0_RCNTHI},
-		{0x00,  EN0_RSARLO},		/* DMA starting at 0x0000. */
-		{0x00,  EN0_RSARHI},
-		{E8390_RREAD+E8390_START, E8390_CMD},
-	};
-
-	PRINTK ("trying to get MAC via prom reading\n");
-
-	pcnet_reset_8390 ();
-
-	mdelay (10);
-
-	for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
-		n2k_outb (program_seq[i].value, program_seq[i].offset);
-
-	PRINTK ("PROM:");
-	for (i = 0; i < 32; i++) {
-		prom[i] = n2k_inb (PCNET_DATAPORT);
-		PRINTK (" %02x", prom[i]);
-	}
-	PRINTK ("\n");
-	for (i = 0; i < NR_INFO; i++) {
-		if ((prom[0] == hw_info[i].a0) &&
-		    (prom[2] == hw_info[i].a1) &&
-		    (prom[4] == hw_info[i].a2)) {
-			PRINTK ("matched board %d\n", i);
-			break;
-		}
-	}
-	if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
-		PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
-		PRINTK ("MAC address is ");
-		for (j = 0; j < 6; j++) {
-			mac_addr[j] = prom[j << 1];
-			PRINTK ("%02x:", mac_addr[i]);
-		}
-		PRINTK ("\n");
-		return (i < NR_INFO) ? i : 0;
-	}
-	return NULL;
-}
 #endif /* __DRIVERS_NE2000_H__ */
diff --git a/drivers/net/ne2000_base.h b/drivers/net/ne2000_base.h
index 1badf62..d8768e8 100644
--- a/drivers/net/ne2000_base.h
+++ b/drivers/net/ne2000_base.h
@@ -120,7 +120,6 @@ typedef struct dp83902a_priv_data {
  ------------------------------------------------------------------------
  Some forward declarations
 */
-int get_prom( u8* mac_addr);
 static void dp83902a_poll(void);
 
 /* ------------------------------------------------------------------------ */
-- 
1.5.4.5




From galak at kernel.crashing.org  Mon Apr 21 19:34:52 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Mon, 21 Apr 2008 12:34:52 -0500
Subject: [U-Boot-Users] [PATCH v3] 85xx: Round up frequency calculations
	to get reasonable output
In-Reply-To: <2acbd3e40804211017t2a4695d7q1ff1b9c932d12e10@mail.gmail.com>
References: <Pine.LNX.4.64.0804210927530.18126@blarg.am.freescale.net>
	<2acbd3e40804211017t2a4695d7q1ff1b9c932d12e10@mail.gmail.com>
Message-ID: <BF77383A-6FB1-480E-AA52-F089200088C3@kernel.crashing.org>


On Apr 21, 2008, at 12:17 PM, Andy Fleming wrote:
> On Mon, Apr 21, 2008 at 9:28 AM, Kumar Gala  
> <galak at kernel.crashing.org> wrote:
>> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
>>
>> Introduced DIV_ROUND_UP and roundup taken from linux kernel.
>>
>> Signed-off-by: Dejan Minic <minic at freescale.com>
>> Signed-off-by: Srikanth Srinivasan  
>> <srikanth.srinivasan at freescale.com>
>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>
>
> Shouldn't this be two patches?  One to add the macros, and then one to
> use them.  Technically, I'd be overstepping my authority to apply the
> first patch.  Though I'd be happy to apply it if Wolfgang ACKs it.

I think its a bit silly to separate this into two patches.  If you  
aren't comfortably applying it just ack the 85xx bits and ask Wolfgang  
to apply it.

- k



From afleming at gmail.com  Mon Apr 21 19:45:47 2008
From: afleming at gmail.com (Andy Fleming)
Date: Mon, 21 Apr 2008 12:45:47 -0500
Subject: [U-Boot-Users] [PATCH v3] 85xx: Round up frequency calculations
	to get reasonable output
In-Reply-To: <Pine.LNX.4.64.0804210927530.18126@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804210927530.18126@blarg.am.freescale.net>
Message-ID: <2acbd3e40804211045i59d8f56nf9d4d224220252c9@mail.gmail.com>

On Mon, Apr 21, 2008 at 9:28 AM, Kumar Gala <galak at kernel.crashing.org> wrote:
> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
>
>  Introduced DIV_ROUND_UP and roundup taken from linux kernel.
>
>  Signed-off-by: Dejan Minic <minic at freescale.com>
>  Signed-off-by: Srikanth Srinivasan <srikanth.srinivasan at freescale.com>
>  Signed-off-by: Kumar Gala <galak at kernel.crashing.org>

Acked-by: Andy Fleming <afleming at freescale.com>

Andy



From jdl at freescale.com  Mon Apr 21 19:51:13 2008
From: jdl at freescale.com (Jon Loeliger)
Date: Mon, 21 Apr 2008 12:51:13 -0500
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for
	some	86xx chips
In-Reply-To: <20080418041413.E011A248A0@gemini.denx.de>
References: <20080418041413.E011A248A0@gemini.denx.de>
Message-ID: <1208800273.28914.27.camel@ld0161-tx32>

On Fri, 2008-04-18 at 06:14 +0200, Wolfgang Denk wrote:
> In message <1207325771-1374-1-git-send-email-timur at freescale.com> you wrote:
> > Some 86xx chips use CCB as the base clock for the I2C, and others used CCB/2.
> > There is no pattern that can be used to determine which chips use which
> > frequency, so the only way to determine is to look up the actual SOC
> > designation and use the right value for that SOC.
> > 
> > Signed-off-by: Timur Tabi <timur at freescale.com>
> 
> Will this goin through the 86xx custodian repo, or should I pull this
> directly?
> 
> Best regards,
> 
> Wolfgang Denk
> 

Please pick this up directly.

Thanks,
jdl





From plagnioj at jcrosoft.com  Mon Apr 21 19:48:14 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Mon, 21 Apr 2008 19:48:14 +0200
Subject: [U-Boot-Users] [PATCH 2/2 V2] qemu-mips: add full functionnalty and
	support of CONFIG_SMALLEST
In-Reply-To: <1208798540-22251-3-git-send-email-plagnioj@jcrosoft.com>
References: <1208798540-22251-3-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1208800094-23117-1-git-send-email-plagnioj@jcrosoft.com>

add support of :
#define CONFIG_CMD_ASKENV
#define CONFIG_CMD_LOADS
#define CONFIG_CMD_LOADB
#define CONFIG_CMD_PING
#define CONFIG_CMD_CDP
#define CONFIG_CMD_SAVES
#define CONFIG_CMD_SETEXPR

and keep only :
tftp and dhcp support when CONFIG_SMALLEST is active

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
---
 Makefile                    |    5 +++++
 include/configs/qemu-mips.h |   16 +++++++++++++++-
 2 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index ab56831..202ddd9 100644
--- a/Makefile
+++ b/Makefile
@@ -2720,9 +2720,14 @@ gth2_config:	unconfig
 	@echo "#define CONFIG_GTH2 1" >$(obj)include/config.h
 	@$(MKCONFIG) -a gth2 mips mips gth2
 
+qemu_mips_smallest_config	\
 qemu_mips_config: unconfig
 	@mkdir -p $(obj)include
 	@echo "#define CONFIG_QEMU_MIPS 1" >$(obj)include/config.h
+	@[ -z "$(findstring _smallest_,$@)" ] || \
+		{ echo "#define CONFIG_SMALLEST 1" >>$(obj)include/config.h ; \
+		  $(XECHO) "... config with the minimal functionalities" ; \
+		}
 	@$(MKCONFIG) -a qemu-mips mips mips qemu-mips
 
 #########################################################################
diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index b775714..6a15413 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -71,10 +71,20 @@
 #include <config_cmd_default.h>
 
 #define CONFIG_CMD_ELF
+#ifndef CONFIG_SMALLEST
+#define CONFIG_CMD_ASKENV
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef	CONFIG_CMD_LOADB
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_CDP
+#define CONFIG_CMD_SAVES
+#define CONFIG_CMD_SETEXPR
+#else
 #undef	CONFIG_CMD_LOADS
+#undef	CONFIG_CMD_LOADB
+#undef	CONFIG_CMD_NFS
+#endif
+#undef	CONFIG_CMD_FPGA
 #define CONFIG_CMD_DHCP
 
 #define CONFIG_DRIVER_NE2000
@@ -87,6 +97,7 @@
 #define CFG_NS16550_COM1	(0xb40003f8)
 #define CONFIG_CONS_INDEX	1
 
+#ifndef CONFIG_SMALLEST
 #define CONFIG_CMD_IDE
 #define CONFIG_DOS_PARTITION
 
@@ -103,13 +114,16 @@
  * Miscellaneous configurable options
  */
 #define	CFG_LONGHELP				/* undef to save memory */
+#endif
 
 #define	CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt */
 
+#ifndef CONFIG_SMALLEST
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CFG_HUSH_PARSER
 #define CFG_PROMPT_HUSH_PS2	"> "
+#endif
 
 #define	CFG_CBSIZE		256		/* Console I/O Buffer Size */
 #define	CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)	/* Print Buffer Size */
-- 
1.5.4.5




From afleming at freescale.com  Mon Apr 21 20:04:27 2008
From: afleming at freescale.com (Andy Fleming)
Date: Mon, 21 Apr 2008 13:04:27 -0500
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
Message-ID: <1208801067-307-1-git-send-email-afleming@freescale.com>

are available in the git repository at:

  git://www.denx.de/git/u-boot-mpc85xx.git master

Kumar Gala (1):
      85xx: Fix size of cpu-release-addr property

Timur Tabi (1):
      Fix calculation of I2C clock for some 85xx chips

 cpu/mpc85xx/fdt.c            |    2 +-
 cpu/mpc85xx/speed.c          |   31 ++++++++++++++++++++++++++++++-
 include/asm-ppc/immap_85xx.h |    4 +++-
 3 files changed, 34 insertions(+), 3 deletions(-)



From vapier at gentoo.org  Mon Apr 21 20:44:43 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 21 Apr 2008 14:44:43 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <20080421121312.5A8BF24764@gemini.denx.de>
References: <20080421121312.5A8BF24764@gemini.denx.de>
Message-ID: <200804211444.43917.vapier@gentoo.org>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804210635.08416.vapier at gentoo.org> you wrote:
> > > 	go [ -cache={off,d-off,i-off,on,d-on,i-on} ] addr [ args ... ]
> >
> > cache is just an example.  other arches may want to do other sort of
> > "system breakdown/cleanup" before relinquishing control.  option flags to
> > commands
>
> As the situation is, other arches seem to be just fine  as  it.  It's
> only BF which needs a pork sausage.

this is incorrect.  any architecture which wants to overwrite u-boot sanely 
needs to worry about causing exceptions or interrupts.  i just want to make 
the obvious easy since it has caused more than enough support requests.

> > really doesnt fit the style of u-boot (i expect that sort of painful
> > option parsing in redboot, not really u-boot).
>
> I don;t like it either, but just ading random new commands is even
> worse.
>
> > so we can do:
> > 	go [-noret] addr [args...]
>
> Ummm... "no return" programs is just an example.  Other  pograms  may
> want  to  do  other  sort of "system breakdown/cleanup" before relin-
> quishing control.
>
> > or we can add "jump" to cmd_boot.c and merge the differences by just
> > using > a function pointer to "do_go_exec" or "do_jump_exec".
>
> Adn then we add "call" and "exec" and "do" and so oon just for  other
> needed options? I say no.

then implement whatever.  in the mean time i'll keep forking the Blackfin 
code.

> > i never said Blackfin was the only thing that mattered.  in fact, my goal
> > is to make it so that people using this facility get a more standard
> > initial environment before they start taking over the system.  i guess i
> > wont point out the U-Boot policy about not using interrupts ...
>
> Are you aware that U-Boot does use interrupts here and there? That we
> actually  provide  functions  to  register  interrupt   handlers   to
> standalone programs, etc. ?

yes i'm aware, but we arent talking about standalone applications here, so 
those really dont matter.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/902f64c9/attachment.pgp 

From wd at denx.de  Mon Apr 21 21:19:22 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 21:19:22 +0200
Subject: [U-Boot-Users] intended behavior of bootm
In-Reply-To: Your message of "Mon, 21 Apr 2008 15:09:43 +0200."
	<200804211509.43558.matthias.fuchs@esd-electronics.com>
Message-ID: <20080421191922.6E38224764@gemini.denx.de>

Dear Matthias,

in message <200804211509.43558.matthias.fuchs at esd-electronics.com> you wrote:
> 
> I am wondering if bootm behaves correctly on CRC errors in kernel and/or ramdisk images.
> This is what I observed:

Most has already been said in previous replies, so here just a summary
of the situation:

> 3) Same loading as above. But I make the ramdisk CRC check fail (mw 320000 12345678).
> I get:
> ## Booting kernel from Legacy Image at 00200000 ...
> ...
> ## Loading init Ramdisk from Legacy Image at 00300000 ...
> ...
>    Verifying Checksum ... Bad Data CRC
> <system reset>
> U-Boot 1.3.2-00450-g77dd47f (Apr 21 2008 - 14:43:23)
> 
> Hmm, I expected the same behavior as for a corrupted kernel image.

This expectation is incorrect.

> So what should be the correct behavior? I would like to get back to the prompt
> on any CRC error. So is this a bug?

No, it is not a bug. Kernel image and  ramdisk  image  get  processed
sequentiually. As soon as you uncompress and copy the kernel image to
it's  load  address (typically 0x0000 for PowerPC), it will overwrite
the exception vectors used by U-Boot. The next interrupt (for example
timer) would then kill kill you. That's why there is a  point  of  no
return just before we start uncompressing / loading the kernel image.

Any errors after this point can only be resolved by  a reset.

That's intentional and documented. There are no intentions to change
this behaviour.

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: wd at denx.de
Computers are not intelligent.  They only think they are.



From wd at denx.de  Mon Apr 21 21:24:19 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 21:24:19 +0200
Subject: [U-Boot-Users] [PATCH 0/2] NE2000: Fix regresssion introduced
	by e710185aae90 on non AX88796
In-Reply-To: Your message of "Mon, 21 Apr 2008 19:22:18 +0200."
	<1208798540-22251-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080421192419.C76E124764@gemini.denx.de>

In message <1208798540-22251-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Move non-inlied functions into specific drivers file
> Set get_prom as weak
> 
> Coding Style Cleanup

Please split in two (3?) separate patches. 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: wd at denx.de
"Logic and practical information do not seem to apply here."
"You admit that?"
"To deny the facts would be illogical, Doctor"
	-- Spock and McCoy, "A Piece of the Action", stardate unknown



From wd at denx.de  Mon Apr 21 21:26:48 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 21:26:48 +0200
Subject: [U-Boot-Users] [PATCH 2/2 V2] qemu-mips: add full functionnalty
	and support of CONFIG_SMALLEST
In-Reply-To: Your message of "Mon, 21 Apr 2008 19:48:14 +0200."
	<1208800094-23117-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080421192649.03DB424764@gemini.denx.de>

In message <1208800094-23117-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> add support of :
> #define CONFIG_CMD_ASKENV
> #define CONFIG_CMD_LOADS
> #define CONFIG_CMD_LOADB
> #define CONFIG_CMD_PING
> #define CONFIG_CMD_CDP
> #define CONFIG_CMD_SAVES
> #define CONFIG_CMD_SETEXPR
> 
> and keep only :
> tftp and dhcp support when CONFIG_SMALLEST is active

What is the difference between the first patch and patch "V2"?

What is "CONFIG_SMALLEST" ?

What is "full functionnalty"?

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: wd at denx.de
It [being a Vulcan] means to adopt a philosophy, a way of life  which
is logical and beneficial. We cannot disregard that philosophy merely
for personal gain, no matter how important that gain might be.
	-- Spock, "Journey to Babel", stardate 3842.4



From wd at denx.de  Mon Apr 21 21:30:19 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 21:30:19 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update bootlogo for APC405 boards
In-Reply-To: Your message of "Mon, 21 Apr 2008 13:46:06 +0200."
	<200804211346.06941.matthias.fuchs@esd-electronics.com>
Message-ID: <20080421193019.1C40724764@gemini.denx.de>

In message <200804211346.06941.matthias.fuchs at esd-electronics.com> you wrote:
> 
> because of the lists size limit and because I did not find any
> other suitable way to submit this patch, I am posting a link to the patch file:

I don't understand. Your posting was below the hard limit and got
ACKed, and it was distributed over the list. Or am I missing
something?

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: wd at denx.de
Pain is a thing of the mind.  The mind can be controlled.
	-- Spock, "Operation -- Annihilate!" stardate 3287.2



From wd at denx.de  Mon Apr 21 21:45:14 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 21 Apr 2008 21:45:14 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Mon, 21 Apr 2008 14:44:43 EDT."
	<200804211444.43917.vapier@gentoo.org>
Message-ID: <20080421194514.A886224764@gemini.denx.de>

In message <200804211444.43917.vapier at gentoo.org> you wrote:
>
> > Adn then we add "call" and "exec" and "do" and so oon just for  other
> > needed options? I say no.
> 
> then implement whatever.  in the mean time i'll keep forking the Blackfin 
> code.

OK. I offered you a way out. It's your decision.

I tried understanding what you are trying to do, and  even  though  I
feel  it's  not  exactly  an important or frequently used feature for
most of the users I tried to come up with a  compromize  that  allows
you  to  do  what  you  want to do without hurting others and without
polluting the command name space.

I'm sorry that I wasted my time on thinking about this.


> > Are you aware that U-Boot does use interrupts here and there? That we
> > actually  provide  functions  to  register  interrupt   handlers   to
> > standalone programs, etc. ?
> 
> yes i'm aware, but we arent talking about standalone applications here, so
> those really dont matter.

You have a really, really funny way of deciding what matters and what
not. All the things you have in mind do  matter  (even  if  they  are
documented to be unsupported), while other existing and legal ways of
doing things don't matter. That doesn't make working with you an easy
task.

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: wd at denx.de
...the increased productivity fostered by a friendly environment  and
quality  tools  is  essential  to  meet  ever  increasing demands for
software.               - M. D. McIlroy, E. N. Pinson and B. A. Tague



From vapier at gentoo.org  Mon Apr 21 22:58:43 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 21 Apr 2008 16:58:43 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <20080421194514.A886224764@gemini.denx.de>
References: <20080421194514.A886224764@gemini.denx.de>
Message-ID: <200804211658.44036.vapier@gentoo.org>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804211444.43917.vapier at gentoo.org> you wrote:
> > > Adn then we add "call" and "exec" and "do" and so oon just for  other
> > > needed options? I say no.
> >
> > then implement whatever.  in the mean time i'll keep forking the Blackfin
> > code.
>
> OK. I offered you a way out. It's your decision.
>
> I tried understanding what you are trying to do, and  even  though  I
> feel  it's  not  exactly  an important or frequently used feature for
> most of the users I tried to come up with a  compromize  that  allows
> you  to  do  what  you  want to do without hurting others and without
> polluting the command name space.

i consider the cache one aspect of it.  the users shouldnt have to know "oh i 
gotta turn off cache", they just have to know "i'm loading up my code and 
it's going to take over the system".  that is why a "-noret" flags makes 
sense instead of trying to break down specific aspects.  also adding a myriad 
of cache options to one function achieves the same thing as doing:
dcache off; icache off; go <address>

> > > Are you aware that U-Boot does use interrupts here and there? That we
> > > actually  provide  functions  to  register  interrupt   handlers   to
> > > standalone programs, etc. ?
> >
> > yes i'm aware, but we arent talking about standalone applications here,
> > so those really dont matter.
>
> You have a really, really funny way of deciding what matters and what
> not. All the things you have in mind do  matter  (even  if  they  are
> documented to be unsupported), while other existing and legal ways of
> doing things don't matter. That doesn't make working with you an easy
> task.

it's really quite simple.  the need is to jump to an address to execute a blob 
and never return to u-boot.  what features are available to standalone u-boot 
applications (while useful) dont really matter.  such applications rely on 
u-boot remaining resident which is the opposite of what i'm talking about.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/46d3f3e1/attachment.pgp 

From kim.phillips at freescale.com  Mon Apr 21 23:05:06 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Mon, 21 Apr 2008 16:05:06 -0500
Subject: [U-Boot-Users] [PATCH] ppc: Revert patch 70431e8a that used
 _start instead of CFG_MONITOR_BASE
In-Reply-To: <20080410194502.13d37051.kim.phillips@freescale.com>
References: <1207738602-23956-1-git-send-email-sr@denx.de>
	<20080410194502.13d37051.kim.phillips@freescale.com>
Message-ID: <20080421160506.86caca50.kim.phillips@freescale.com>

On Thu, 10 Apr 2008 19:45:02 -0500
Kim Phillips <kim.phillips at freescale.com> wrote:

> On Wed,  9 Apr 2008 12:56:42 +0200
> Stefan Roese <sr at denx.de> wrote:
> 
> > The patch 70431e8a7393b6b793f77957f95b999fc9a269b8 (Make MPC83xx one step
> > closer to full relocation.) doesn't use CFG_MONITOR_BASE anymore. But
> > on 4xx systems _start currently cannot be used for this calculation.
> > So revert back to the original version for now.
> > 
> > Signed-off-by: Stefan Roese <sr at denx.de>
> 
> Acked-by: Kim Phillips <kim.phillips at freescale.com>
> 
hmm..I seem to have false-acked this due to a bug in a build script of
mine.

Currently WD's top of tree renders 83xx kaput.  When I revert this
revert plus Joakim's original 70431e8 commit, things are back to
normal.  I'm not going to pretend I know to fix it up correctly, so
does anyone have a problem with me sending two revert patches until
relocation is properly and comprehensively fixed?

Kim



From kim.phillips at freescale.com  Mon Apr 21 23:57:51 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Mon, 21 Apr 2008 16:57:51 -0500
Subject: [U-Boot-Users] [PATCH 1/3] mpc83xx: update the default load
 address for 837xemds board
In-Reply-To: <1208236229.3656.1.camel@localhost.localdomain>
References: <1208236229.3656.1.camel@localhost.localdomain>
Message-ID: <20080421165751.291605cd.kim.phillips@freescale.com>

On Tue, 15 Apr 2008 13:10:29 +0800
Dave Liu <r63238 at freescale.com> wrote:

> Update the default load address. if not, the kernel image
> will be overwritten when u-boot boot the latest linux kernel.
> 
> Signed-off-by: Dave Liu <daveliu at freescale.com>
> ---
>  include/configs/MPC837XEMDS.h |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h
> index 7fc0f7e..b2b4aa1 100644
> --- a/include/configs/MPC837XEMDS.h
> +++ b/include/configs/MPC837XEMDS.h
> @@ -595,7 +595,7 @@
>  
>  #define CONFIG_BAUDRATE 115200
>  
> -#define CONFIG_LOADADDR 200000	/* default location for tftp and bootm */
> +#define CONFIG_LOADADDR 2000000	/* default location for tftp and bootm */
>  
>  #define CONFIG_BOOTDELAY 6	/* -1 disables auto-boot */
>  #undef CONFIG_BOOTARGS		/* the boot command will set bootargs */
> @@ -605,7 +605,7 @@
>     "consoledev=ttyS0\0"							\
>     "ramdiskaddr=1000000\0"						\
>     "ramdiskfile=ramfs.83xx\0"						\
> -   "fdtaddr=400000\0"							\
> +   "fdtaddr=3000000\0"							\

is such a drastic difference really necessary?  how about we double
them instead?

Kim



From wd at denx.de  Tue Apr 22 00:19:25 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 00:19:25 +0200
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: Your message of "Mon, 21 Apr 2008 16:58:43 EDT."
	<200804211658.44036.vapier@gentoo.org>
Message-ID: <20080421221925.E6FD924764@gemini.denx.de>

In message <200804211658.44036.vapier at gentoo.org> you wrote:
>
> > I tried understanding what you are trying to do, and  even  though  I
> > feel  it's  not  exactly  an important or frequently used feature for
> > most of the users I tried to come up with a  compromize  that  allows
> > you  to  do  what  you  want to do without hurting others and without
> > polluting the command name space.
> 
> i consider the cache one aspect of it.  the users shouldnt have to know "oh i 
> gotta turn off cache", they just have to know "i'm loading up my code and 

I agree that  cache  is  just  one  aspect;  I  disagree  that  users
shouldn't  know what they are doing. On contrary, I want to give them
all necessary control to do what they may want to do. It is a  matter
of higher software levels to provide more convenient abstractions.

> it's going to take over the system".  that is why a "-noret" flags makes 

Who says that *my* application which doesn;t return does the same  as
your  application?  Maybe  I *want* to have the caches on for perfor-
mance?

I accept that the default settings may be not optimal  for  your  use
case,  so please accept that your settings may not be always optimal,
either. As a solution I imagine options to the "go" command.  If  you
consider  this  too  complicated  for your users, please feel free to
provide an alias in an envrionment  variable  which  your  users  can
"run".

> sense instead of trying to break down specific aspects.  also adding a myriad 
> of cache options to one function achieves the same thing as doing:
> dcache off; icache off; go <address>

Ah! You see - there is no need at all for any changes - you can put
*that* sequence in a variable and run it.

So what exactly was the reason we need a new command?

> it's really quite simple.  the need is to jump to an address to execute a blob 
> and never return to u-boot.  what features are available to standalone u-boot 

"go" does that. If your application does not attempt to return, that's
fine.

> applications (while useful) dont really matter.  such applications rely on
> u-boot remaining resident which is the opposite of what i'm talking about.

But then it doesn't hurt, does it? Your application can do anything it
wants as long as it does not attempt to return to U-Boot.


I see zero justification for a  new  command  (and  very  little  for
changes  to  the  implementation  of  "go", but I am still willing to
allow for such  extensions  if  you  think  it's  necessary  or  more
convenient).

I thik this is my last word on this.

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: wd at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie



From Ken.Fuchs at bench.com  Tue Apr 22 00:53:39 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Mon, 21 Apr 2008 17:53:39 -0500
Subject: [U-Boot-Users] USB SUPPORT
In-Reply-To: <480CC73C.8000509@gandalf.sssup.it>
Message-ID: <AA28F077645B324881335614E4F7C428034CD5@win-ex01.bench.com>

micheal wrote:

> Ken Fuchs wrote:

> > #define CONFIG_SUPPORT_VFAT
> >
> > --- FAT16 vs. FAT32 - Atmel U-Boot v1.1.5 issue? ---
> >
> > I have found that the USB support is better
> > when the USB Storage device is FAT16 formatted
> > rather than FAT32 formatted.  For some reason
> > not all files were accessible on FAT32
> > formatted media, but I never had any problem
> > with FAT16 formatted media.

> Can you try this patch?
> In the git log there is another patch for vfat to be applied.

> Check if the entry is a valid dir_slot entry, otherwise it is 
> a dentry 
> and the
> name has to be taken by the get_name function
> 
> Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>

I tried it, but it did not work.

I also tried the earlier patch where Michael Trimarchi
added the CHECK_CLUST() macro, but it still doesn't work.

Next, I compared my fs/fat/fat.c with what was in git a few hours ago.
The only significant differences were in the fat_register_device(),
but after making my fs/fat/fat.c match what's in git (except for
trivial whitespace differences and recent CONFIG_* & CFG_* handling
differences, it still fails to work properly.

Test pen drive content:

$ ls -lU
total 6354
-rw-r--r-- 1 fuchsk mkpasswd    1298 Apr 18 12:57 xy010.ubs
-rw-r--r-- 1 fuchsk mkpasswd    1298 Apr 18 12:57 xy011.ubs
-rw-r--r-- 1 fuchsk mkpasswd    1298 Apr 18 12:57 xy100.ubs
-rw-r--r-- 1 fuchsk mkpasswd    1298 Apr 18 12:57 xy101.ubs
drwxr-xr-x 2 fuchsk mkpasswd       0 Apr 21 17:31 admin
-rw-r--r-- 1 fuchsk mkpasswd    1298 Apr 18 12:57 xy110.ubs
-rw-r--r-- 1 fuchsk mkpasswd    1298 Apr 18 12:58 xy111.ubs
drwxr-xr-x 3 fuchsk mkpasswd       0 Apr 21 17:31 Linux_demo
drwxr-xr-x 2 fuchsk mkpasswd       0 Apr 21 17:31 photos
drwxr-xr-x 2 fuchsk mkpasswd       0 Apr 21 17:31 videos
-rw-r--r-- 1 fuchsk mkpasswd      32 Apr 18 12:56 ab000.txt
-rw-r--r-- 1 fuchsk mkpasswd      32 Apr 18 12:56 ab001.txt
-rw-r--r-- 1 fuchsk mkpasswd      32 Apr 18 12:57 ab010.txt
-rw-r--r-- 1 fuchsk mkpasswd      32 Apr 18 12:57 ab011.txt
-rw-r--r-- 1 fuchsk mkpasswd      32 Apr 18 12:57 ab100.txt
-rw-r--r-- 1 fuchsk mkpasswd      32 Apr 18 12:57 ab101.txt
-rw-r--r-- 1 fuchsk mkpasswd      32 Apr 18 12:57 ab110.txt
-rw-r--r-- 1 fuchsk mkpasswd      32 Apr 18 12:57 ab111.txt
-rw-r--r-- 1 fuchsk mkpasswd  308326 Dec 18  2006 coffee.bmp
-rw-r--r-- 1 fuchsk mkpasswd   24116 Dec 18  2006 debian.bmp
-rw-r--r-- 1 fuchsk mkpasswd  153720 Dec 18  2006 debianlilo.bmp
-rw-r--r-- 1 fuchsk mkpasswd      65 Mar 31 13:01 index.txt
-rw-r--r-- 1 fuchsk mkpasswd     179 Apr 15 11:52 locvar.ubs
-rw-r--r-- 1 fuchsk mkpasswd      95 Apr 15 12:17 locvar1.ubs
-rw-r--r-- 1 fuchsk mkpasswd     101 Apr 15 12:28 locvar2.ubs
-rw-r--r-- 1 fuchsk mkpasswd   23662 Dec 18  2006 sarge.bmp
-rw-r--r-- 1 fuchsk mkpasswd   24116 Dec 18  2006 sid.bmp
-rw-r--r-- 1 fuchsk mkpasswd    6719 Apr 18 12:57 test000.ugz
-rw-r--r-- 1 fuchsk mkpasswd    6719 Apr 18 12:57 test001.ugz
-rw-r--r-- 1 fuchsk mkpasswd    6722 Apr 18 12:57 test010.ugz
-rw-r--r-- 1 fuchsk mkpasswd    6721 Apr 18 12:57 test011.ugz
-rw-r--r-- 1 fuchsk mkpasswd    6720 Apr 18 12:57 test100.ugz
-rw-r--r-- 1 fuchsk mkpasswd    6720 Apr 18 12:57 test101.ugz
-rw-r--r-- 1 fuchsk mkpasswd    6715 Apr 18 12:57 test110.ugz
-rw-r--r-- 1 fuchsk mkpasswd    6717 Apr 18 12:58 test111.ugz
-rw-r--r-- 1 fuchsk mkpasswd   92160 Oct 11  2007 U-Boot-xload.bin
-rw-r--r-- 1 fuchsk mkpasswd 5706338 Apr 18 12:46 xxx1.ugz.dis
-rw-r--r-- 1 fuchsk mkpasswd   41007 Apr 18 12:52 xxx2.ugz.dis
-rw-r--r-- 1 fuchsk mkpasswd   41007 Apr 18 12:56 xxx3.ugz.dis
-rw-r--r-- 1 fuchsk mkpasswd    1298 Apr 18 12:57 xy000.ubs
-rw-r--r-- 1 fuchsk mkpasswd    1298 Apr 18 12:57 xy001.ubs
$ ls -lU | wc
     42     371    2504
$ 

Here's fatls output on an XP FAT32 formatted pen drive:

U-Boot> fatls usb 0:1 /
fatls usb 0:1 /
     1298   xy010.ubs
     1298   xy011.ubs
     1298   xy100.ubs
     1298   xy101.ubs
            admin/
     1298   xy110.ubs
     1298   xy111.ubs
            linux_demo/
            photos/
            videos/
       32   ab000.txt
       32   ab001.txt
       32   ab010.txt
       32   ab011.txt
       32   ab100.txt
       32   ab101.txt
       32   ab110.txt
       32   ab111.txt
   308326   coffee.bmp
    24116   debian.bmp
   153720   debianlilo.bmp
       65   index.txt
      179   locvar.ubs
       95   locvar1.ubs
      101   locvar2.ubs
    23662   sarge.bmp
    24116   sid.bmp
     6719   test000.ugz
     6719   test001.ugz
\365+3.\341
            write.sk4/
 1718159906   .000
            otm.800/
            /
 2016419888   .mmc
 808464432   20000000."

            0.0x2/
            if.ad/
            :1.000/
 808464432   ."
 1948269360   ;
 1920409699   hen

            ite.0/
            .wri/
            .280/
 540028976   "
if.loa
 1763713056   /part3.u.gz;
            f.0x2/
            .280/
 808465457   ho
            0.000/
 544172131   28000.000
 1667566090   ".

            0.10./
 2016419949   ;
 808464432   .ite
 538976266   0x200000.00


40 file(s), 17 dir(s)

U-Boot> 

Here's fatls output on an Linux mkdosfs -F 32 formatted pen drive:

U-Boot> usb reset
usb reset
(Re)start USB...
USB:   scanning bus for devices...
      USB device not responding, giving up (status=20)
3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
U-Boot> fatls usb 0:1 /
fatls usb 0:1 /
       32   ab001.txt
       32   ab101.txt
     1298   xy001.ubs
     1298   xy101.ubs
     6719   test001.ugz
     6720   test101.ugz
            admin/
            linux_demo/
            photos/
            videos/
   308326   coffee.bmp
    24116   debian.bmp
 168636477   version=.3


9 file(s), 4 dir(s)

U-Boot> 

---

Sincerely,

Ken Fuchs



From vapier at gentoo.org  Tue Apr 22 01:08:14 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Mon, 21 Apr 2008 19:08:14 -0400
Subject: [U-Boot-Users] [PATCH] Blackfin: implement go/boote wrappers
In-Reply-To: <20080421221925.E6FD924764@gemini.denx.de>
References: <20080421221925.E6FD924764@gemini.denx.de>
Message-ID: <200804211908.15526.vapier@gentoo.org>

On Monday 21 April 2008, Wolfgang Denk wrote:
> In message <200804211658.44036.vapier at gentoo.org> you wrote:
> > > I tried understanding what you are trying to do, and  even  though  I
> > > feel  it's  not  exactly  an important or frequently used feature for
> > > most of the users I tried to come up with a  compromize  that  allows
> > > you  to  do  what  you  want to do without hurting others and without
> > > polluting the command name space.
> >
> > i consider the cache one aspect of it.  the users shouldnt have to know
> > "oh i gotta turn off cache", they just have to know "i'm loading up my
> > code and
>
> I agree that  cache  is  just  one  aspect;  I  disagree  that  users
> shouldn't  know what they are doing. On contrary, I want to give them
> all necessary control to do what they may want to do. It is a  matter
> of higher software levels to provide more convenient abstractions.

yes, but the fact that we have to turn off caches is not for performance 
reasons.  users should not need to be aware of these system deficiencies 
which is why i'm proposing a "noret" flag.

> > it's going to take over the system".  that is why a "-noret" flags makes
>
> Who says that *my* application which doesn;t return does the same  as
> your  application?  Maybe  I *want* to have the caches on for perfor-
> mance?

i'm not concerned with the performance aspect.  caches on the Blackfin are 
intertwined with protection, and protection handlers require a software 
vector to process exceptions.  the act of executing a program that takes over 
the system means the exception handler is no longer reliable so i have to 
guarantee it wont be called.  based on information given to me from our 
hardware team, this can only be accomplished implicitly by disabling caches.

> I accept that the default settings may be not optimal  for  your  use
> case,  so please accept that your settings may not be always optimal,
> either. As a solution I imagine options to the "go" command.  If  you
> consider  this  too  complicated  for your users, please feel free to
> provide an alias in an envrionment  variable  which  your  users  can
> "run".

i completely accept that the patch i posted to turn off caches for all things 
to "go" result in a suboptimal environment for standalone u-boot 
applications.  for Blackfin usage though, that takes a back seat to things 
silently crashing.

> > applications (while useful) dont really matter.  such applications rely
> > on u-boot remaining resident which is the opposite of what i'm talking
> > about.
>
> But then it doesn't hurt, does it? Your application can do anything it
> wants as long as it does not attempt to return to U-Boot.

except that it may inadvertently do so on Blackfin.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080421/4e200f81/attachment.pgp 

From kim.phillips at freescale.com  Tue Apr 22 01:10:14 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Mon, 21 Apr 2008 18:10:14 -0500
Subject: [U-Boot-Users] [PATCH] lib_ppc: Revert "Make MPC83xx one step
 closer to full relocation."
Message-ID: <20080421181014.7f664c62.kim.phillips@freescale.com>

This reverts commit 70431e8a7393b6b793f77957f95b999fc9a269b8 which has
proven problematic getting right from the start at least on 83xx and
4xx.

Signed-off-by: Kim Phillips <kim.phillips at freescale.com>
---
 cpu/mpc83xx/start.S |   11 ++++-------
 lib_ppc/board.c     |    1 -
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/cpu/mpc83xx/start.S b/cpu/mpc83xx/start.S
index fdf9d35..309eb30 100644
--- a/cpu/mpc83xx/start.S
+++ b/cpu/mpc83xx/start.S
@@ -172,11 +172,8 @@ boot_warm: /* time t 5 */
 	/* there and deflate the flash size back to minimal size      */
 	/*------------------------------------------------------------*/
 	bl map_flash_by_law1
-
-	GET_GOT			/* initialize GOT access	*/
-	lwz r4, GOT(_start)
-	addi r4, r4, -EXC_OFF_SYS_RESET
-
+	lis r4, (CFG_MONITOR_BASE)@h
+	ori r4, r4, (CFG_MONITOR_BASE)@l
 	addi r5, r4, in_flash - _start + EXC_OFF_SYS_RESET
 	mtlr r5
 	blr
@@ -875,8 +872,8 @@ relocate_code:
 	mr	r10, r5		/* Save copy of Destination Address */
 
 	mr	r3,  r5				/* Destination Address */
-	lwz	r4, GOT(_start)
-	addi	r4, r4, -EXC_OFF_SYS_RESET
+	lis	r4, CFG_MONITOR_BASE at h		/* Source      Address */
+	ori	r4, r4, CFG_MONITOR_BASE at l
 	lwz	r5, GOT(__init_end)
 	sub	r5, r5, r4
 	li	r6, CFG_CACHELINE_SIZE		/* Cache Line Size */
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index b2bc4eb..1b8a872 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -124,7 +124,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CFG_MEM_TOP_HIDE	0
 #endif
 
-extern ulong _start;
 extern ulong __init_end;
 extern ulong _end;
 ulong monitor_flash_len;
-- 
1.5.5




From gvb.uboot at gmail.com  Tue Apr 22 02:26:37 2008
From: gvb.uboot at gmail.com (Jerry Van Baren)
Date: Mon, 21 Apr 2008 20:26:37 -0400
Subject: [U-Boot-Users] [PATCH 1/3] mpc83xx: update the default load
 address for 837xemds board
In-Reply-To: <20080421165751.291605cd.kim.phillips@freescale.com>
References: <1208236229.3656.1.camel@localhost.localdomain>
	<20080421165751.291605cd.kim.phillips@freescale.com>
Message-ID: <480D30BD.6010202@gmail.com>

Kim Phillips wrote:
> On Tue, 15 Apr 2008 13:10:29 +0800
> Dave Liu <r63238 at freescale.com> wrote:
> 
>> Update the default load address. if not, the kernel image
>> will be overwritten when u-boot boot the latest linux kernel.
>>
>> Signed-off-by: Dave Liu <daveliu at freescale.com>
>> ---
>>  include/configs/MPC837XEMDS.h |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h
>> index 7fc0f7e..b2b4aa1 100644
>> --- a/include/configs/MPC837XEMDS.h
>> +++ b/include/configs/MPC837XEMDS.h
>> @@ -595,7 +595,7 @@
>>  
>>  #define CONFIG_BAUDRATE 115200
>>  
>> -#define CONFIG_LOADADDR 200000	/* default location for tftp and bootm */
>> +#define CONFIG_LOADADDR 2000000	/* default location for tftp and bootm */
>>  
>>  #define CONFIG_BOOTDELAY 6	/* -1 disables auto-boot */
>>  #undef CONFIG_BOOTARGS		/* the boot command will set bootargs */
>> @@ -605,7 +605,7 @@
>>     "consoledev=ttyS0\0"							\
>>     "ramdiskaddr=1000000\0"						\
>>     "ramdiskfile=ramfs.83xx\0"						\
>> -   "fdtaddr=400000\0"							\
>> +   "fdtaddr=3000000\0"							\
> 
> is such a drastic difference really necessary?  how about we double
> them instead?
> 
> Kim

Hi Kim, Dave,

The current recommended practice on the denx.de wiki is to have a 12K 
FDT blob (0x3000).  My latest personal convention for memory locations 
is to put the FDT blob at a semi-arbitrary base address and set the 
loadaddr 32K higher (could use 64K if we want to be paranoid about blob 
growth).  The advantage is that the kernel can grow or shrink (ha!) 
fairly often, but the blob should remain fairly small and fairly constant.

This is better than dropping pieces all over memory.

This is what I've been running lately:
setenv fdtaddr 400000
setenv loadaddr 408000
setenv ramdiskaddr 1000000

Best regards,
gvb




From j.holzman at genesysdesign.com.au  Tue Apr 22 06:23:28 2008
From: j.holzman at genesysdesign.com.au (Jared Holzman)
Date: Tue, 22 Apr 2008 14:23:28 +1000
Subject: [U-Boot-Users] [PATCH u-boot-at91] Add support for AT91SAM9263EK
Message-ID: <480D6840.4090704@genesysdesign.com.au>

This patch adds support for the AT91SAM9263EK board. It builds on top of 
the support added for the AT91SAM9260EK by Stelian Pop. It was created 
against the u-boot-at91 custodian tree, so I hope this is correct place 
to submit it.
---

diff --git a/Makefile b/Makefile
index cf16bd6..c6d903e 100644
--- a/Makefile
+++ b/Makefile
@@ -2311,6 +2311,9 @@ at91rm9200dk_config    :    unconfig
 at91sam9260ek_config    :    unconfig
     @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9260ek atmel at91sam9
 
+at91sam9263ek_config    :    unconfig
+    @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9263ek atmel at91sam9
+
 cmc_pu2_config    :    unconfig
     @$(MKCONFIG) $(@:_config=) arm arm920t cmc_pu2 NULL at91rm9200
 
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 703784e..499c7da 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -417,13 +417,13 @@ static int macb_init(struct eth_device *netdev, 
bd_t *bd)
 
     /* choose RMII or MII mode. This depends on the board */
 #ifdef CONFIG_RMII
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined 
(CONFIG_AT91SAM9263)
     macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN));
 #else
     macb_writel(macb, USRIO, 0);
 #endif
 #else
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined 
(CONFIG_AT91SAM9263)
     macb_writel(macb, USRIO, MACB_BIT(CLKEN));
 #else
     macb_writel(macb, USRIO, MACB_BIT(MII));
diff --git a/include/asm-arm/arch-at91sam9/hardware.h 
b/include/asm-arm/arch-at91sam9/hardware.h
index 80b334f..4f9f2a8 100644
--- a/include/asm-arm/arch-at91sam9/hardware.h
+++ b/include/asm-arm/arch-at91sam9/hardware.h
@@ -28,6 +28,10 @@
 #include <asm/arch/at91sam9261.h>
 #elif defined(CONFIG_AT91SAM9263)
 #include <asm/arch/at91sam9263.h>
+#define AT91_BASE_EMAC    AT91SAM9263_BASE_EMAC
+#define AT91_BASE_SPI    AT91SAM9263_BASE_SPI0
+#define AT91_ID_UHP    AT91SAM9263_ID_UHP
+#define AT91_PMC_UHP    AT91SAM926x_PMC_UHP
 #elif defined(CONFIG_AT91SAM9RL)
 #include <asm/arch/at91sam9rl.h>
 #elif defined(CONFIG_AT91CAP9)
diff --git a/net/eth.c b/net/eth.c
index 99897ca..f0b9091 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -284,7 +284,7 @@ int eth_initialize(bd_t *bis)
 #if defined(CONFIG_FSLDMAFEC)
     mcdmafec_initialize(bis);
 #endif
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || 
defined(CONFIG_AT91SAM9263)
     at91sam9_eth_initialize(bis);
 #endif
 
-- 

Regards,

Jared Holzman

------------------------------------------------------------------------

*Electronics Design Engineer*

*Genesys Electronics Design Pty Ltd*

Unit 5, 33 Ryde Rd Pymble
NSW, Australia 2073

Direct: +612 9496 8924
Phone: +612 9496 8900
Fax: +612 9496 8999

j.holzman at genesysdesign.com.au <mailto:j.holzman at genesysdesign.com.au>
www.genesysdesign.com.au <http://www.genesysdesign.com.au>

------------------------------------------------------------------------



From danrz at comcast.net  Tue Apr 22 07:36:02 2008
From: danrz at comcast.net (Daniel)
Date: Mon, 21 Apr 2008 23:36:02 -0600
Subject: [U-Boot-Users] mpc8313 nand setup
Message-ID: <04a801c8a43a$c10afb80$4320f280$@net>

Hi All,

I am working on a MPC8313ERDB REVA4 board and need to work with a nand
device using u-boot.  I am using u-boot version 1.3.2 and under the
driver/mtd/nand directory there is a file called nand.c.  In this file it
makes a call to a function called board_nand_init().  From what I can tell
this function is suppose to be located another nand.c file located in
board/freescale/mpc8313erdb but it seems to be missing.  I found this
missing file on the website
www.bitshrine.org/gpp/u-boot-1.1.6-mpc8313erdb-board.patch.  But I haven't
been able to get the source code (nand.c) to compile it (unless I comment
out all errors of course).  Any help would be greatly appreciated.

 

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080421/264646b0/attachment.htm 

From Joakim.Tjernlund at transmode.se  Tue Apr 22 07:49:57 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Tue, 22 Apr 2008 07:49:57 +0200
Subject: [U-Boot-Users] [PATCH] ppc: Revert patch 70431e8a that used
	_start instead of CFG_MONITOR_BASE
In-Reply-To: <20080421160506.86caca50.kim.phillips@freescale.com>
References: <1207738602-23956-1-git-send-email-sr@denx.de>	<20080410194502.13d37051.kim.phillips@freescale.com>
	<20080421160506.86caca50.kim.phillips@freescale.com>
Message-ID: <040601c8a43c$b2c86650$185932f0$@Tjernlund@transmode.se>

> -----Original Message-----
> From: Kim Phillips [mailto:kim.phillips at freescale.com]
> Sent: den 21 april 2008 23:05
> To: Kim Phillips
> Cc: Stefan Roese; u-boot-users at lists.sourceforge.net; joakim.tjernlund at transmode.se
> Subject: Re: [U-Boot-Users] [PATCH] ppc: Revert patch 70431e8a that used _start instead of
> CFG_MONITOR_BASE
> 
> On Thu, 10 Apr 2008 19:45:02 -0500
> Kim Phillips <kim.phillips at freescale.com> wrote:
> 
> > On Wed,  9 Apr 2008 12:56:42 +0200
> > Stefan Roese <sr at denx.de> wrote:
> >
> > > The patch 70431e8a7393b6b793f77957f95b999fc9a269b8 (Make MPC83xx one step
> > > closer to full relocation.) doesn't use CFG_MONITOR_BASE anymore. But
> > > on 4xx systems _start currently cannot be used for this calculation.
> > > So revert back to the original version for now.
> > >
> > > Signed-off-by: Stefan Roese <sr at denx.de>
> >
> > Acked-by: Kim Phillips <kim.phillips at freescale.com>
> >
> hmm..I seem to have false-acked this due to a bug in a build script of
> mine.
> 
> Currently WD's top of tree renders 83xx kaput.  When I revert this
> revert plus Joakim's original 70431e8 commit, things are back to
> normal.  I'm not going to pretend I know to fix it up correctly, so
> does anyone have a problem with me sending two revert patches until
> relocation is properly and comprehensively fixed?

Strange, I got a 8321 and it worked for me. Maybe a toolchain issue? Perhaps
I got something extra in my board port, dunno what though.

If you revert it we are probably not going to solve it. I got no clue
though. Are any other 83xx users out there?

 Jocke




From j.holzman at genesysdesign.com.au  Tue Apr 22 07:48:33 2008
From: j.holzman at genesysdesign.com.au (Jared Holzman)
Date: Tue, 22 Apr 2008 15:48:33 +1000
Subject: [U-Boot-Users] [PATCH u-boot-at91] Add support for AT91SAM9263EK
	(again)
Message-ID: <480D7C31.8070501@genesysdesign.com.au>

Apologies for the previous patch, forgot to add the new files to it. No
wonder it seemed so short.
Here it is again
---
diff --git a/Makefile b/Makefile
index cf16bd6..c6d903e 100644
--- a/Makefile
+++ b/Makefile
@@ -2311,6 +2311,9 @@ at91rm9200dk_config    :    unconfig
at91sam9260ek_config    :    unconfig
     @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9260ek atmel at91sam9

+at91sam9263ek_config    :    unconfig
+    @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9263ek atmel at91sam9
+
cmc_pu2_config    :    unconfig
     @$(MKCONFIG) $(@:_config=) arm arm920t cmc_pu2 NULL at91rm9200

diff --git a/board/atmel/at91sam9263ek/Makefile
b/board/atmel/at91sam9263ek/Makefile
new file mode 100644
index 0000000..72e8faa
--- /dev/null
+++ b/board/atmel/at91sam9263ek/Makefile
@@ -0,0 +1,52 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, wd <at> denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB    = $(obj)lib$(BOARD).a
+
+COBJS-y    += at91sam9263ek.o
+COBJS-y    += led.o
+COBJS-$(CONFIG_CMD_NAND) += nand.o
+
+SRCS    := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS    := $(addprefix $(obj),$(COBJS-y))
+SOBJS    := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):    $(obj).depend $(OBJS) $(SOBJS)
+    $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+    rm -f $(SOBJS) $(OBJS)
+
+distclean:    clean
+    rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c
b/board/atmel/at91sam9263ek/at91sam9263ek.c
new file mode 100644
index 0000000..316cdea
--- /dev/null
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -0,0 +1,239 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop <stelian.pop <at> leadtechdesign.com>
+ * Lead Tech Design <www.leadtechdesign.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/arch/at91sam9263.h>
+#include <asm/arch/at91sam9263_matrix.h>
+#include <asm/arch/at91sam926x_mc.h>
+#include <asm/arch/at91_pmc.h>
+#include <asm/arch/at91_rstc.h>
+#include <asm/arch/gpio.h>
+#include <asm/arch/io.h>
+#if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_MACB)
+#include <net.h>
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
------------------------------------------------------------------------- */
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+
+static void at91sam9263ek_serial_hw_init(void)
+{
+#ifdef CONFIG_USART0
+    at91_set_A_periph(AT91_PIN_PA26, 1);        /* TXD0 */
+    at91_set_A_periph(AT91_PIN_PA27, 0);        /* RXD0 */
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US0);
+#endif
+
+#ifdef CONFIG_USART1
+    at91_set_A_periph(AT91_PIN_PD0, 1);        /* TXD1 */
+    at91_set_A_periph(AT91_PIN_PD1, 0);        /* RXD1 */
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US1);
+#endif
+
+#ifdef CONFIG_USART2
+    at91_set_A_periph(AT91_PIN_PD2, 1);        /* TXD2 */
+    at91_set_A_periph(AT91_PIN_PD3, 0);        /* RXD2 */
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US2);
+#endif
+
+#ifdef CONFIG_USART3    /* DBGU */
+    at91_set_A_periph(AT91_PIN_PC30, 0);        /* DRXD */
+    at91_set_A_periph(AT91_PIN_PC31, 1);        /* DTXD */
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_SYS);
+#endif
+}
+
+#ifdef CONFIG_CMD_NAND
+static void at91sam9263ek_nand_hw_init(void)
+{
+    unsigned long csa;
+
+    /* Enable CS3 */
+    csa = at91_sys_read(AT91_MATRIX_CSA);
+    at91_sys_write(AT91_MATRIX_CSA,
+               csa | AT91_MATRIX_CS3A_SMC_SMARTMEDIA);
+
+    /* Configure SMC CS3 for NAND/SmartMedia */
+    at91_sys_write(AT91_SMC_SETUP(3),
+               AT91_SMC_NWESETUP_(0) | AT91_SMC_NCS_WRSETUP_(0) |
+               AT91_SMC_NRDSETUP_(0) | AT91_SMC_NCS_RDSETUP_(0));
+    at91_sys_write(AT91_SMC_PULSE(3),
+               AT91_SMC_NWEPULSE_(3) | AT91_SMC_NCS_WRPULSE_(3) |
+               AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3));
+    at91_sys_write(AT91_SMC_CYCLE(3),
+               AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5));
+    at91_sys_write(AT91_SMC_MODE(3),
+               AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
+               AT91_SMC_EXNWMODE_DISABLE |
+               AT91_SMC_DBW_8 | AT91_SMC_TDF_(2));
+
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOA);
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOCDE);
+
+    /* Configure RDY/BSY */
+    at91_set_gpio_input(AT91_PIN_PA22, 1);
+
+    /* Enable NandFlash */
+    at91_set_gpio_output(AT91_PIN_PD15, 1);
+}
+#endif
+
+#ifdef CONFIG_HAS_DATAFLASH
+static void at91sam9263ek_spi_hw_init(void)
+{
+    at91_set_B_periph(AT91_PIN_PA5, 0);    /* SPI0_NPCS0 */
+    at91_set_B_periph(AT91_PIN_PA3, 0);    /* SPI0_NPCS1 */
+
+    at91_set_B_periph(AT91_PIN_PA0, 0);    /* SPI0_MISO */
+    at91_set_B_periph(AT91_PIN_PA1, 0);    /* SPI0_MOSI */
+    at91_set_B_periph(AT91_PIN_PA2, 0);    /* SPI0_SPCK */
+
+    /* Enable clock */
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_SPI0);
+}
+#endif
+
+#ifdef CONFIG_MACB
+static void at91sam9263ek_macb_hw_init(void)
+{
+    /* Enable clock */
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_EMAC);
+
+    /*
+     * Disable pull-up on:
+     *    RXDV (PC25) => PHY normal mode (not Test mode)
+     *     ERX0 (PE25) => PHY ADDR0
+     *    ERX1 (PE26) => PHY ADDR1
+     *    ERX2 (PC22) => PHY ADDR2
+     *    ERX3 (PC23) => PHY ADDR3
+     *    ECRS (PE22) => PHY ADDR4  => PHYADDR = 0x0
+     *
+     * PHY has internal pull-down
+     */
+    writel(pin_to_mask(AT91_PIN_PC22) |
+           pin_to_mask(AT91_PIN_PC23) |
+           pin_to_mask(AT91_PIN_PC25),
+           pin_to_controller(AT91_PIN_PC0) + PIO_PUDR);
+    writel(pin_to_mask(AT91_PIN_PE22) |
+           pin_to_mask(AT91_PIN_PE25) |
+           pin_to_mask(AT91_PIN_PE26),
+           pin_to_controller(AT91_PIN_PE0) + PIO_PUDR);
+
+    /* Need to reset PHY -> 500ms reset */
+    at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
+                     AT91_RSTC_ERSTL | (0x0D << 8) |
+                     AT91_RSTC_URSTEN);
+
+    at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_EXTRST);
+
+    /* Wait for end hardware reset */
+    while (!(at91_sys_read(AT91_RSTC_SR) & AT91_RSTC_NRSTL));
+
+    /* Restore NRST value */
+    at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
+                     AT91_RSTC_ERSTL | (0x0 << 8) |
+                     AT91_RSTC_URSTEN);
+
+    /* Re-enable pull-up */
+    writel(pin_to_mask(AT91_PIN_PC22) |
+           pin_to_mask(AT91_PIN_PC23) |
+           pin_to_mask(AT91_PIN_PC25),
+           pin_to_controller(AT91_PIN_PC0) + PIO_PUER);
+    writel(pin_to_mask(AT91_PIN_PE22) |
+           pin_to_mask(AT91_PIN_PE25) |
+           pin_to_mask(AT91_PIN_PE26),
+           pin_to_controller(AT91_PIN_PE0) + PIO_PUER);
+
+    at91_set_A_periph(AT91_PIN_PE21, 0);    /* ETXCK_EREFCK */
+    at91_set_B_periph(AT91_PIN_PC25, 0);    /* ERXDV */
+    at91_set_A_periph(AT91_PIN_PE25, 0);    /* ERX0 */
+    at91_set_A_periph(AT91_PIN_PE26, 0);    /* ERX1 */
+    at91_set_A_periph(AT91_PIN_PE27, 0);    /* ERXER */
+    at91_set_A_periph(AT91_PIN_PE28, 0);    /* ETXEN */
+    at91_set_A_periph(AT91_PIN_PE23, 0);    /* ETX0 */
+    at91_set_A_periph(AT91_PIN_PE24, 0);    /* ETX1 */
+    at91_set_A_periph(AT91_PIN_PE30, 0);    /* EMDIO */
+    at91_set_A_periph(AT91_PIN_PE29, 0);    /* EMDC */
+
+#ifndef CONFIG_RMII
+    at91_set_A_periph(AT91_PIN_PE22, 0);    /* ECRS */
+    at91_set_B_periph(AT91_PIN_PC26, 0);    /* ECOL */
+    at91_set_B_periph(AT91_PIN_PC22, 0);    /* ERX2 */
+    at91_set_B_periph(AT91_PIN_PC23, 0);    /* ERX3 */
+    at91_set_B_periph(AT91_PIN_PC27, 0);    /* ERXCK */
+    at91_set_B_periph(AT91_PIN_PC20, 0);    /* ETX2 */
+    at91_set_B_periph(AT91_PIN_PC21, 0);    /* ETX3 */
+    at91_set_B_periph(AT91_PIN_PC24, 0);    /* ETXER */
+#endif
+
+}
+#endif
+
+int board_init(void)
+{
+    /* Enable Ctrlc */
+    console_init_f();
+
+    /* arch number of at91sam9263EK-Board */
+    gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9263EK;
+    /* adress of boot parameters */
+    gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
+
+    at91sam9263ek_serial_hw_init();
+#ifdef CONFIG_CMD_NAND
+    at91sam9263ek_nand_hw_init();
+#endif
+#ifdef CONFIG_HAS_DATAFLASH
+    at91sam9263ek_spi_hw_init();
+#endif
+#ifdef CONFIG_MACB
+    at91sam9263ek_macb_hw_init();
+#endif
+
+    return 0;
+}
+
+int dram_init(void)
+{
+    gd->bd->bi_dram[0].start = PHYS_SDRAM;
+    gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
+    return 0;
+}
+
+#ifdef CONFIG_RESET_PHY_R
+void reset_phy(void)
+{
+#ifdef CONFIG_MACB
+    /*
+     * Initialize ethernet HW addr prior to starting Linux,
+     * needed for nfsroot
+     */
+    eth_init(gd->bd);
+#endif
+}
+#endif
diff --git a/board/atmel/at91sam9263ek/config.mk
b/board/atmel/at91sam9263ek/config.mk
new file mode 100644
index 0000000..ff2cfd1
--- /dev/null
+++ b/board/atmel/at91sam9263ek/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x23f00000
diff --git a/board/atmel/at91sam9263ek/led.c
b/board/atmel/at91sam9263ek/led.c
new file mode 100644
index 0000000..2a71d61
--- /dev/null
+++ b/board/atmel/at91sam9263ek/led.c
@@ -0,0 +1,78 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop <stelian.pop <at> leadtechdesign.com>
+ * Lead Tech Design <www.leadtechdesign.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/arch/at91sam9263.h>
+#include <asm/arch/at91_pmc.h>
+#include <asm/arch/gpio.h>
+#include <asm/arch/io.h>
+
+#define    POWER_LED    AT91_PIN_PB7    /* this is the power led */
+#define    USER1_LED    AT91_PIN_PB8    /* this is the user led 1 */
+#define USER2_LED    AT91_PIN_PC29    /* this is the user led 2 */
+
+void power_LED_on(void)
+{
+    at91_set_gpio_value(POWER_LED, 1);
+}
+
+void power_LED_off(void)
+{
+    at91_set_gpio_value(POWER_LED, 0);
+}
+
+void user1_LED_on(void)
+{
+    at91_set_gpio_value(USER1_LED, 0);
+}
+
+void user1_LED_off(void)
+{
+    at91_set_gpio_value(USER1_LED, 1);
+}
+
+void user2_LED_on(void)
+{
+    at91_set_gpio_value(USER2_LED, 0);
+}
+
+void user2_LED_off(void)
+{
+    at91_set_gpio_value(USER2_LED, 1);
+}
+
+void coloured_LED_init(void)
+{
+    /* Enable clock */
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOB);
+    at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOCDE);
+
+    at91_set_gpio_output(POWER_LED, 1);
+    at91_set_gpio_output(USER1_LED, 1);
+    at91_set_gpio_output(USER2_LED, 1);
+
+    at91_set_gpio_value(POWER_LED, 0);
+    at91_set_gpio_value(USER1_LED, 1);
+    at91_set_gpio_value(USER2_LED, 1);
+}
diff --git a/board/atmel/at91sam9263ek/nand.c
b/board/atmel/at91sam9263ek/nand.c
new file mode 100644
index 0000000..8c5b4b1
--- /dev/null
+++ b/board/atmel/at91sam9263ek/nand.c
@@ -0,0 +1,76 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop <stelian.pop <at> leadtechdesign.com>
+ * Lead Tech Design <www.leadtechdesign.com>
+ *
+ * (C) Copyright 2006 ATMEL Rousset, Lacressonniere Nicolas
+ *
+ * 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 <common.h>
+#include <asm/arch/at91sam9263.h>
+#include <asm/arch/gpio.h>
+#include <asm/arch/at91_pio.h>
+
+#include <nand.h>
+
+/*
+ *    hardware specific access to control-lines
+ */
+#define    MASK_ALE    (1 << 21)    /* our ALE is AD21 */
+#define    MASK_CLE    (1 << 22)    /* our CLE is AD22 */
+
+static void at91sam9263ek_nand_hwcontrol(struct mtd_info *mtd, int cmd)
+{
+    struct nand_chip *this = mtd->priv;
+    ulong IO_ADDR_W = (ulong) this->IO_ADDR_W;
+
+    IO_ADDR_W &= ~(MASK_ALE|MASK_CLE);
+    switch (cmd) {
+    case NAND_CTL_SETCLE:
+        IO_ADDR_W |= MASK_CLE;
+        break;
+    case NAND_CTL_SETALE:
+        IO_ADDR_W |= MASK_ALE;
+        break;
+    case NAND_CTL_CLRNCE:
+        at91_set_gpio_value(AT91_PIN_PD15, 1);
+        break;
+    case NAND_CTL_SETNCE:
+        at91_set_gpio_value(AT91_PIN_PD15, 0);
+        break;
+    }
+    this->IO_ADDR_W = (void *) IO_ADDR_W;
+}
+
+static int at91sam9263ek_nand_ready(struct mtd_info *mtd)
+{
+    return at91_get_gpio_value(AT91_PIN_PA22);
+}
+
+int board_nand_init(struct nand_chip *nand)
+{
+    nand->eccmode = NAND_ECC_SOFT;
+    nand->hwcontrol = at91sam9263ek_nand_hwcontrol;
+    nand->dev_ready = at91sam9263ek_nand_ready;
+    nand->chip_delay = 20;
+
+    return 0;
+}
diff --git a/board/atmel/at91sam9263ek/u-boot.lds
b/board/atmel/at91sam9263ek/u-boot.lds
new file mode 100644
index 0000000..05a6d83
--- /dev/null
+++ b/board/atmel/at91sam9263ek/u-boot.lds
@@ -0,0 +1,57 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, <gj <at> denx.de>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+/*OUTPUT_FORMAT("elf32-arm", "elf32-arm", "elf32-arm")*/
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+    . = 0x00000000;
+
+    . = ALIGN(4);
+    .text :
+    {
+      cpu/arm926ejs/start.o    (.text)
+      *(.text)
+    }
+
+    . = ALIGN(4);
+    .rodata : { *(.rodata) }
+
+    . = ALIGN(4);
+    .data : { *(.data) }
+
+    . = ALIGN(4);
+    .got : { *(.got) }
+
+    . = .;
+    __u_boot_cmd_start = .;
+    .u_boot_cmd : { *(.u_boot_cmd) }
+    __u_boot_cmd_end = .;
+
+    . = ALIGN(4);
+    __bss_start = .;
+    .bss : { *(.bss) }
+    _end = .;
+}
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 703784e..499c7da 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -417,13 +417,13 @@ static int macb_init(struct eth_device *netdev,
bd_t *bd)

     /* choose RMII or MII mode. This depends on the board */
#ifdef CONFIG_RMII
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined
(CONFIG_AT91SAM9263)
     macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN));
#else
     macb_writel(macb, USRIO, 0);
#endif
#else
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined
(CONFIG_AT91SAM9263)
     macb_writel(macb, USRIO, MACB_BIT(CLKEN));
#else
     macb_writel(macb, USRIO, MACB_BIT(MII));
diff --git a/include/asm-arm/arch-at91sam9/at91sam9263.h
b/include/asm-arm/arch-at91sam9/at91sam9263.h
new file mode 100644
index 0000000..f91a357
--- /dev/null
+++ b/include/asm-arm/arch-at91sam9/at91sam9263.h
@@ -0,0 +1,120 @@
+/*
+ * include/asm-arm/arch-at91/at91sam9263.h
+ *
+ * (C) 2006 Andrew Victor
+ *
+ * Common definitions.
+ * Based on AT91SAM9263 datasheet revision A (Preliminary).
+ *
+ * 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.
+ */
+
+#ifndef AT91SAM9263_H
+#define AT91SAM9263_H
+
+/*
+ * Peripheral identifiers/interrupts.
+ */
+#define AT91_ID_FIQ        0    /* Advanced Interrupt Controller (FIQ) */
+#define AT91_ID_SYS        1    /* System Peripherals */
+#define AT91SAM9263_ID_PIOA    2    /* Parallel IO Controller A */
+#define AT91SAM9263_ID_PIOB    3    /* Parallel IO Controller B */
+#define AT91SAM9263_ID_PIOCDE    4    /* Parallel IO Controller C */
+#define AT91SAM9263_ID_US0    7    /* USART 0 */
+#define AT91SAM9263_ID_US1    8    /* USART 1 */
+#define AT91SAM9263_ID_US2    9    /* USART 2 */
+#define AT91SAM9263_ID_MCI0    10    /* Multimedia Card Interface */
+#define AT91SAM9263_ID_MCI1    11    /* Multimedia Card Interface */
+#define AT91SAM9263_ID_CAN    12    /* CAN Controller */
+#define AT91SAM9263_ID_TWI    13    /* Two-Wire Interface */
+#define AT91SAM9263_ID_SPI0    14    /* Serial Peripheral Interface 0 */
+#define AT91SAM9263_ID_SPI1    15    /* Serial Peripheral Interface 1 */
+#define AT91SAM9263_ID_SSC0    16    /* Serial Synchronous Controller 0 */
+#define AT91SAM9263_ID_SSC1    17    /* Serial Synchronous Controller 1 */
+#define AT91SAM9263_ID_AC97    18    /* AC 97 Controller */
+#define AT91SAM9263_ID_TC012    19    /* Timer Counter 0, 1 and 2 */
+#define AT91SAM9263_ID_PWMC    20    /* PWM Controller */
+#define AT91SAM9263_ID_EMAC    21    /* Ethernet */
+#define AT91SAM9263_ID_2DGE    23    /* 2D Graphics Engine */
+#define AT91SAM9263_ID_UDP    24    /* USB Device Port */
+#define AT91SAM9263_ID_ISI    25    /* Image Sensor Interface */
+#define AT91SAM9263_ID_LCDC    26    /* LCD Controller */
+#define AT91SAM9263_ID_DMA    27    /* DMA Controller */
+#define AT91SAM9263_ID_UHP    29    /* USB Host Controller */
+#define AT91SAM9263_ID_IRQ0    30    /* External IRQ 0 */
+#define AT91SAM9263_ID_IRQ1    31    /* External IRQ 1 */
+
+/*
+ * User Peripheral physical base addresses.
+ */
+#define AT91SAM9263_BASE_UDP        0xfff78000
+#define AT91SAM9263_BASE_TC012        0xfff7C000
+#define AT91SAM9263_BASE_MCI0        0xfff80000
+#define AT91SAM9263_BASE_MCI1        0xfff84000
+#define AT91SAM9263_BASE_TWI        0xfff88000
+#define AT91SAM9263_BASE_US0        0xfff8c000
+#define AT91SAM9263_BASE_US1        0xfff90000
+#define AT91SAM9263_BASE_US2        0xfff94000
+#define AT91SAM9263_BASE_SSC0        0xfff98000
+#define AT91SAM9263_BASE_SSC1        0xfff9c000
+#define AT91SAM9263_BASE_AC97        0xfffa0000
+#define AT91SAM9263_BASE_SPI0        0xfffa4000
+#define AT91SAM9263_BASE_SPI1        0xfffa8000
+#define AT91SAM9263_BASE_CAN0        0xfffac000
+#define AT91SAM9263_BASE_PWMC        0xfffb8000
+#define AT91SAM9263_BASE_EMAC        0xfffbc000
+#define AT91SAM9263_BASE_ISI        0xfffc4000
+#define AT91SAM9263_BASE_2DGE        0xfffc8000
+#define AT91_BASE_SYS            0xffffc000
+
+/*
+ * System Peripherals (offset from AT91_BASE_SYS)
+ */
+#define AT91_ECC    (0xffffe000 - AT91_BASE_SYS)
+#define AT91_SDRAMC    (0xffffe200 - AT91_BASE_SYS)
+#define AT91_SMC    (0xffffe400 - AT91_BASE_SYS)
+#define AT91_ECC1    (0xffffe600 - AT91_BASE_SYS)
+#define AT91_SDRAMC1    (0xffffe800 - AT91_BASE_SYS)
+#define AT91_SMC1    (0xffffea00 - AT91_BASE_SYS)
+#define AT91_MATRIX    (0xffffec00 - AT91_BASE_SYS)
+#define AT91_CCFG    (0xffffed10 - AT91_BASE_SYS)
+#define AT91_DBGU    (0xffffee00 - AT91_BASE_SYS)
+#define AT91_AIC    (0xfffff000 - AT91_BASE_SYS)
+#define AT91_PIOA    (0xfffff200 - AT91_BASE_SYS)
+#define AT91_PIOB    (0xfffff400 - AT91_BASE_SYS)
+#define AT91_PIOC    (0xfffff600 - AT91_BASE_SYS)
+#define AT91_PIOD    (0xfffff800 - AT91_BASE_SYS)
+#define AT91_PIOE    (0xfffffa00 - AT91_BASE_SYS)
+#define AT91_PMC    (0xfffffc00 - AT91_BASE_SYS)
+#define AT91_RSTC    (0xfffffd00 - AT91_BASE_SYS)
+#define AT91_SHDWC    (0xfffffd10 - AT91_BASE_SYS)
+#define AT91_RTT    (0xfffffd20 - AT91_BASE_SYS)
+#define AT91_PIT    (0xfffffd30 - AT91_BASE_SYS)
+#define AT91_WDT    (0xfffffd40 - AT91_BASE_SYS)
+#define AT91_RTT1    (0xfffffd50 - AT91_BASE_SYS)
+#define AT91_GPBR    (0xfffffd60 - AT91_BASE_SYS)
+
+#define AT91_USART0    AT91SAM9263_BASE_US0
+#define AT91_USART1    AT91SAM9263_BASE_US1
+#define AT91_USART2    AT91SAM9263_BASE_US2
+
+/*
+ * Internal Memory.
+ */
+#define AT91SAM9263_ROM_BASE    0x00400000    /* Internal ROM base
address */
+#define AT91SAM9263_ROM_SIZE    SZ_128K        /* Internal ROM size
(128Kb) */
+
+#define AT91SAM9263_SRAM0_BASE    0x00500000    /* Internal SRAM 0 base
address */
+#define AT91SAM9263_SRAM0_SIZE    SZ_16K        /* Internal SRAM 0 size
(16Kb) */
+#define AT91SAM9263_SRAM1_BASE    0x00300000    /* Internal SRAM 1 base
address */
+#define AT91SAM9263_SRAM1_SIZE    SZ_80K        /* Internal SRAM 1 size
(80Kb) */
+
+#define AT91SAM9263_UHP_BASE    0x00A00000    /* USB Host controller */
+
+#define AT91SAM9XE_FLASH_BASE    0x00200000    /* Internal FLASH base
address */
+#define AT91SAM9XE_SRAM_BASE    0x00300000    /* Internal SRAM base
address */
+
+#endif
diff --git a/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h
b/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h
new file mode 100644
index 0000000..c90f01a
--- /dev/null
+++ b/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h
@@ -0,0 +1,88 @@
+/*
+ * include/asm-arm/arch-at91/at91sam9260_matrix.h
+ *
+ * Memory Controllers (MATRIX, EBI) - System peripherals registers.
+ * Based on AT91SAM9260 datasheet revision B.
+ *
+ * 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.
+ */
+
+#ifndef AT91SAM9260_MATRIX_H
+#define AT91SAM9260_MATRIX_H
+
+#define AT91_MATRIX_MCFG0    (AT91_MATRIX + 0x00)    /* Master
Configuration Register 0 */
+#define AT91_MATRIX_MCFG1    (AT91_MATRIX + 0x04)    /* Master
Configuration Register 1 */
+#define AT91_MATRIX_MCFG2    (AT91_MATRIX + 0x08)    /* Master
Configuration Register 2 */
+#define AT91_MATRIX_MCFG3    (AT91_MATRIX + 0x0C)    /* Master
Configuration Register 3 */
+#define AT91_MATRIX_MCFG4    (AT91_MATRIX + 0x10)    /* Master
Configuration Register 4 */
+#define AT91_MATRIX_MCFG5    (AT91_MATRIX + 0x14)    /* Master
Configuration Register 5 */
+#define        AT91_MATRIX_ULBT        (7 << 0)    /* Undefined Length
Burst Type */
+#define            AT91_MATRIX_ULBT_INFINITE    (0 << 0)
+#define            AT91_MATRIX_ULBT_SINGLE        (1 << 0)
+#define            AT91_MATRIX_ULBT_FOUR        (2 << 0)
+#define            AT91_MATRIX_ULBT_EIGHT        (3 << 0)
+#define            AT91_MATRIX_ULBT_SIXTEEN    (4 << 0)
+
+#define AT91_MATRIX_SCFG0    (AT91_MATRIX + 0x40)    /* Slave
Configuration Register 0 */
+#define AT91_MATRIX_SCFG1    (AT91_MATRIX + 0x44)    /* Slave
Configuration Register 1 */
+#define AT91_MATRIX_SCFG2    (AT91_MATRIX + 0x48)    /* Slave
Configuration Register 2 */
+#define AT91_MATRIX_SCFG3    (AT91_MATRIX + 0x4C)    /* Slave
Configuration Register 3 */
+#define AT91_MATRIX_SCFG4    (AT91_MATRIX + 0x50)    /* Slave
Configuration Register 4 */
+#define        AT91_MATRIX_SLOT_CYCLE        (0xff <<  0)    /* Maximum
Number of Allowed Cycles for a Burst */
+#define        AT91_MATRIX_DEFMSTR_TYPE    (3    << 16)    /* Default
Master Type */
+#define            AT91_MATRIX_DEFMSTR_TYPE_NONE    (0 << 16)
+#define            AT91_MATRIX_DEFMSTR_TYPE_LAST    (1 << 16)
+#define            AT91_MATRIX_DEFMSTR_TYPE_FIXED    (2 << 16)
+#define        AT91_MATRIX_FIXED_DEFMSTR    (7    << 18)    /* Fixed
Index of Default Master */
+#define        AT91_MATRIX_ARBT        (3    << 24)    /* Arbitration
Type */
+#define            AT91_MATRIX_ARBT_ROUND_ROBIN    (0 << 24)
+#define            AT91_MATRIX_ARBT_FIXED_PRIORITY    (1 << 24)
+
+#define AT91_MATRIX_PRAS0    (AT91_MATRIX + 0x80)    /* Priority
Register A for Slave 0 */
+#define AT91_MATRIX_PRAS1    (AT91_MATRIX + 0x88)    /* Priority
Register A for Slave 1 */
+#define AT91_MATRIX_PRAS2    (AT91_MATRIX + 0x90)    /* Priority
Register A for Slave 2 */
+#define AT91_MATRIX_PRAS3    (AT91_MATRIX + 0x98)    /* Priority
Register A for Slave 3 */
+#define AT91_MATRIX_PRAS4    (AT91_MATRIX + 0xA0)    /* Priority
Register A for Slave 4 */
+#define        AT91_MATRIX_M0PR        (3 << 0)    /* Master 0 Priority */
+#define        AT91_MATRIX_M1PR        (3 << 4)    /* Master 1 Priority */
+#define        AT91_MATRIX_M2PR        (3 << 8)    /* Master 2 Priority */
+#define        AT91_MATRIX_M3PR        (3 << 12)    /* Master 3 Priority */
+#define        AT91_MATRIX_M4PR        (3 << 16)    /* Master 4 Priority */
+#define        AT91_MATRIX_M5PR        (3 << 20)    /* Master 5 Priority */
+
+#define AT91_MATRIX_MRCR    (AT91_MATRIX + 0x100)    /* Master Remap
Control Register */
+#define        AT91_MATRIX_RCB0        (1 << 0)    /* Remap Command for
AHB Master 0 (ARM926EJ-S Instruction Master) */
+#define        AT91_MATRIX_RCB1        (1 << 1)    /* Remap Command for
AHB Master 1 (ARM926EJ-S Data Master) */
+
+#define AT91_MATRIX_CSA    (AT91_MATRIX + 0x120)    /* EBI0 Chip Select
Assignment Register */
+#define        AT91_MATRIX_CS1A        (1 << 1)    /* Chip Select 1
Assignment */
+#define            AT91_MATRIX_CS1A_SMC        (0 << 1)
+#define            AT91_MATRIX_CS1A_SDRAMC        (1 << 1)
+#define        AT91_MATRIX_CS3A        (1 << 3)    /* Chip Select 3
Assignment */
+#define            AT91_MATRIX_CS3A_SMC        (0 << 3)
+#define            AT91_MATRIX_CS3A_SMC_SMARTMEDIA    (1 << 3)
+#define        AT91_MATRIX_CS4A        (1 << 4)    /* Chip Select 4
Assignment */
+#define            AT91_MATRIX_CS4A_SMC        (0 << 4)
+#define            AT91_MATRIX_CS4A_SMC_CF1    (1 << 4)
+#define        AT91_MATRIX_CS5A        (1 << 5)    /* Chip Select 5
Assignment */
+#define            AT91_MATRIX_CS5A_SMC        (0 << 5)
+#define            AT91_MATRIX_CS5A_SMC_CF2    (1 << 5)
+#define        AT91_MATRIX_DBPUC        (1 << 8)    /* Data Bus Pull-up
Configuration */
+#define        AT91_MATRIX_VDDIOMSEL        (1 << 16)    /* Memory
voltage selection */
+#define            AT91_MATRIX_VDDIOMSEL_1_8V    (0 << 16)
+#define            AT91_MATRIX_VDDIOMSEL_3_3V    (1 << 16)
+#define AT91_MATRIX_EBI1_CSA    (AT91_MATRIX + 0x124)    /* EBI1 Chip
Select Assignment Register */
+#define        AT91_MATRIX_EBI1_CS1A        (1 << 1)    /* Chip Select
1 Assignment */
+#define            AT91_MATRIX_EBI1_CS1A_SMC        (0 << 1)
+#define            AT91_MATRIX_EBI1_CS1A_SDRAMC        (1 << 1)
+#define        AT91_MATRIX_EBI1_CS2A        (1 << 3)    /* Chip Select
3 Assignment */
+#define            AT91_MATRIX_EBI1_CS2A_SMC        (0 << 3)
+#define            AT91_MATRIX_EBI1_CS2A_SMC_SMARTMEDIA    (1 << 3)
+#define        AT91_MATRIX_EBI1_DBPUC        (1 << 8)    /* Data Bus
Pull-up Configuration */
+#define        AT91_MATRIX_EBI1_VDDIOMSEL        (1 << 16)    /* Memory
voltage selection */
+#define            AT91_MATRIX_EBI1_VDDIOMSEL_1_8V    (0 << 16)
+#define            AT91_MATRIX_EBI1_VDDIOMSEL_3_3V    (1 << 16)
+#endif
diff --git a/include/asm-arm/arch-at91sam9/at91sam9263_mc.h
b/include/asm-arm/arch-at91sam9/at91sam9263_mc.h
new file mode 100644
index 0000000..041138f
--- /dev/null
+++ b/include/asm-arm/arch-at91sam9/at91sam9263_mc.h
@@ -0,0 +1,140 @@
+/*
+ * include/asm-arm/arch-at91/at91sam926x_mc.h
+ *
+ * Memory Controllers (SMC, SDRAMC) - System peripherals registers.
+ * Based on AT91SAM9261 datasheet revision D.
+ *
+ * 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.
+ */
+
+#ifndef AT91SAM926x_MC_H
+#define AT91SAM926x_MC_H
+
+/* SDRAM Controller (SDRAMC) registers */
+#define AT91_SDRAMC_MR        (AT91_SDRAMC + 0x00)    /* SDRAM
Controller Mode Register */
+#define        AT91_SDRAMC_MODE    (0xf << 0)        /* Command Mode */
+#define            AT91_SDRAMC_MODE_NORMAL        0
+#define            AT91_SDRAMC_MODE_NOP        1
+#define            AT91_SDRAMC_MODE_PRECHARGE    2
+#define            AT91_SDRAMC_MODE_LMR        3
+#define            AT91_SDRAMC_MODE_REFRESH    4
+#define            AT91_SDRAMC_MODE_EXT_LMR    5
+#define            AT91_SDRAMC_MODE_DEEP        6
+
+#define AT91_SDRAMC_TR        (AT91_SDRAMC + 0x04)    /* SDRAM
Controller Refresh Timer Register */
+#define        AT91_SDRAMC_COUNT    (0xfff << 0)        /* Refresh
Timer Counter */
+
+#define AT91_SDRAMC_CR        (AT91_SDRAMC + 0x08)    /* SDRAM
Controller Configuration Register */
+#define        AT91_SDRAMC_NC        (3 << 0)        /* Number of
Column Bits */
+#define            AT91_SDRAMC_NC_8    (0 << 0)
+#define            AT91_SDRAMC_NC_9    (1 << 0)
+#define            AT91_SDRAMC_NC_10    (2 << 0)
+#define            AT91_SDRAMC_NC_11    (3 << 0)
+#define        AT91_SDRAMC_NR        (3 << 2)        /* Number of Row
Bits */
+#define            AT91_SDRAMC_NR_11    (0 << 2)
+#define            AT91_SDRAMC_NR_12    (1 << 2)
+#define            AT91_SDRAMC_NR_13    (2 << 2)
+#define        AT91_SDRAMC_NB        (1 << 4)        /* Number of Banks */
+#define            AT91_SDRAMC_NB_2    (0 << 4)
+#define            AT91_SDRAMC_NB_4    (1 << 4)
+#define        AT91_SDRAMC_CAS        (3 << 5)        /* CAS Latency */
+#define            AT91_SDRAMC_CAS_1    (1 << 5)
+#define            AT91_SDRAMC_CAS_2    (2 << 5)
+#define            AT91_SDRAMC_CAS_3    (3 << 5)
+#define        AT91_SDRAMC_DBW        (1 << 7)        /* Data Bus Width */
+#define            AT91_SDRAMC_DBW_32    (0 << 7)
+#define            AT91_SDRAMC_DBW_16    (1 << 7)
+#define        AT91_SDRAMC_TWR        (0xf <<  8)        /* Write
Recovery Delay */
+#define        AT91_SDRAMC_TRC        (0xf << 12)        /* Row Cycle
Delay */
+#define        AT91_SDRAMC_TRP        (0xf << 16)        /* Row
Precharge Delay */
+#define        AT91_SDRAMC_TRCD    (0xf << 20)        /* Row to Column
Delay */
+#define        AT91_SDRAMC_TRAS    (0xf << 24)        /* Active to
Precharge Delay */
+#define        AT91_SDRAMC_TXSR    (0xf << 28)        /* Exit Self
Refresh to Active Delay */
+
+#define AT91_SDRAMC_LPR        (AT91_SDRAMC + 0x10)    /* SDRAM
Controller Low Power Register */
+#define        AT91_SDRAMC_LPCB        (3 << 0)    /* Low-power
Configurations */
+#define            AT91_SDRAMC_LPCB_DISABLE        0
+#define            AT91_SDRAMC_LPCB_SELF_REFRESH        1
+#define            AT91_SDRAMC_LPCB_POWER_DOWN        2
+#define            AT91_SDRAMC_LPCB_DEEP_POWER_DOWN    3
+#define        AT91_SDRAMC_PASR        (7 << 4)    /* Partial Array
Self Refresh */
+#define        AT91_SDRAMC_TCSR        (3 << 8)    /* Temperature
Compensated Self Refresh */
+#define        AT91_SDRAMC_DS            (3 << 10)    /* Drive Strenght */
+#define        AT91_SDRAMC_TIMEOUT        (3 << 12)    /* Time to
define when Low Power Mode is enabled */
+#define            AT91_SDRAMC_TIMEOUT_0_CLK_CYCLES    (0 << 12)
+#define            AT91_SDRAMC_TIMEOUT_64_CLK_CYCLES    (1 << 12)
+#define            AT91_SDRAMC_TIMEOUT_128_CLK_CYCLES    (2 << 12)
+
+#define AT91_SDRAMC_IER        (AT91_SDRAMC + 0x14)    /* SDRAM
Controller Interrupt Enable Register */
+#define AT91_SDRAMC_IDR        (AT91_SDRAMC + 0x18)    /* SDRAM
Controller Interrupt Disable Register */
+#define AT91_SDRAMC_IMR        (AT91_SDRAMC + 0x1C)    /* SDRAM
Controller Interrupt Mask Register */
+#define AT91_SDRAMC_ISR        (AT91_SDRAMC + 0x20)    /* SDRAM
Controller Interrupt Status Register */
+#define        AT91_SDRAMC_RES        (1 << 0)        /* Refresh Error
Status */
+
+#define AT91_SDRAMC_MDR        (AT91_SDRAMC + 0x24)    /* SDRAM Memory
Device Register */
+#define        AT91_SDRAMC_MD        (3 << 0)        /* Memory Device
Type */
+#define            AT91_SDRAMC_MD_SDRAM        0
+#define            AT91_SDRAMC_MD_LOW_POWER_SDRAM    1
+
+/* Static Memory Controller (SMC) registers */
+#define AT91_SMC_SETUP(n)    (AT91_SMC + 0x00 + ((n)*0x10))    /* Setup
Register for CS n */
+#define        AT91_SMC_NWESETUP    (0x3f << 0)            /* NWE Setup
Length */
+#define            AT91_SMC_NWESETUP_(x)    ((x) << 0)
+#define        AT91_SMC_NCS_WRSETUP    (0x3f << 8)            /* NCS
Setup Length in Write Access */
+#define            AT91_SMC_NCS_WRSETUP_(x)    ((x) << 8)
+#define        AT91_SMC_NRDSETUP    (0x3f << 16)            /* NRD
Setup Length */
+#define            AT91_SMC_NRDSETUP_(x)    ((x) << 16)
+#define        AT91_SMC_NCS_RDSETUP    (0x3f << 24)            /* NCS
Setup Length in Read Access */
+#define            AT91_SMC_NCS_RDSETUP_(x)    ((x) << 24)
+
+#define AT91_SMC_PULSE(n)    (AT91_SMC + 0x04 + ((n)*0x10))    /* Pulse
Register for CS n */
+#define        AT91_SMC_NWEPULSE    (0x7f <<  0)            /* NWE
Pulse Length */
+#define            AT91_SMC_NWEPULSE_(x)    ((x) << 0)
+#define        AT91_SMC_NCS_WRPULSE    (0x7f <<  8)            /* NCS
Pulse Length in Write Access */
+#define            AT91_SMC_NCS_WRPULSE_(x)((x) << 8)
+#define        AT91_SMC_NRDPULSE    (0x7f << 16)            /* NRD
Pulse Length */
+#define            AT91_SMC_NRDPULSE_(x)    ((x) << 16)
+#define        AT91_SMC_NCS_RDPULSE    (0x7f << 24)            /* NCS
Pulse Length in Read Access */
+#define            AT91_SMC_NCS_RDPULSE_(x)((x) << 24)
+
+#define AT91_SMC_CYCLE(n)    (AT91_SMC + 0x08 + ((n)*0x10))    /* Cycle
Register for CS n */
+#define        AT91_SMC_NWECYCLE    (0x1ff << 0 )            /* Total
Write Cycle Length */
+#define            AT91_SMC_NWECYCLE_(x)    ((x) << 0)
+#define        AT91_SMC_NRDCYCLE    (0x1ff << 16)            /* Total
Read Cycle Length */
+#define            AT91_SMC_NRDCYCLE_(x)    ((x) << 16)
+
+#define AT91_SMC_MODE(n)    (AT91_SMC + 0x0c + ((n)*0x10))    /* Mode
Register for CS n */
+#define        AT91_SMC_READMODE    (1 <<  0)            /* Read Mode */
+#define        AT91_SMC_WRITEMODE    (1 <<  1)            /* Write Mode */
+#define        AT91_SMC_EXNWMODE    (3 <<  4)            /* NWAIT Mode */
+#define            AT91_SMC_EXNWMODE_DISABLE    (0 << 4)
+#define            AT91_SMC_EXNWMODE_FROZEN    (2 << 4)
+#define            AT91_SMC_EXNWMODE_READY        (3 << 4)
+#define        AT91_SMC_BAT        (1 <<  8)            /* Byte Access
Type */
+#define            AT91_SMC_BAT_SELECT        (0 << 8)
+#define            AT91_SMC_BAT_WRITE        (1 << 8)
+#define        AT91_SMC_DBW        (3 << 12)            /* Data Bus
Width */
+#define            AT91_SMC_DBW_8            (0 << 12)
+#define            AT91_SMC_DBW_16            (1 << 12)
+#define            AT91_SMC_DBW_32            (2 << 12)
+#define        AT91_SMC_TDF        (0xf << 16)            /* Data Float
Time. */
+#define            AT91_SMC_TDF_(x)        ((x) << 16)
+#define        AT91_SMC_TDFMODE    (1 << 20)            /* TDF
Optimization - Enabled */
+#define        AT91_SMC_PMEN        (1 << 24)            /* Page Mode
Enabled */
+#define        AT91_SMC_PS        (3 << 28)            /* Page Size */
+#define            AT91_SMC_PS_4            (0 << 28)
+#define            AT91_SMC_PS_8            (1 << 28)
+#define            AT91_SMC_PS_16            (2 << 28)
+#define            AT91_SMC_PS_32            (3 << 28)
+
+#if defined(AT91_SMC1)        /* The AT91SAM9263 has 2 Static Memory
contollers */
+#define AT91_SMC1_SETUP(n)    (AT91_SMC1 + 0x00 + ((n)*0x10))    /*
Setup Register for CS n */
+#define AT91_SMC1_PULSE(n)    (AT91_SMC1 + 0x04 + ((n)*0x10))    /*
Pulse Register for CS n */
+#define AT91_SMC1_CYCLE(n)    (AT91_SMC1 + 0x08 + ((n)*0x10))    /*
Cycle Register for CS n */
+#define AT91_SMC1_MODE(n)    (AT91_SMC1 + 0x0c + ((n)*0x10))    /* Mode
Register for CS n */
+#endif
+
+#endif
diff --git a/include/asm-arm/arch-at91sam9/hardware.h
b/include/asm-arm/arch-at91sam9/hardware.h
index 80b334f..4f9f2a8 100644
--- a/include/asm-arm/arch-at91sam9/hardware.h
+++ b/include/asm-arm/arch-at91sam9/hardware.h
@@ -28,6 +28,10 @@
#include <asm/arch/at91sam9261.h>
#elif defined(CONFIG_AT91SAM9263)
#include <asm/arch/at91sam9263.h>
+#define AT91_BASE_EMAC    AT91SAM9263_BASE_EMAC
+#define AT91_BASE_SPI    AT91SAM9263_BASE_SPI0
+#define AT91_ID_UHP    AT91SAM9263_ID_UHP
+#define AT91_PMC_UHP    AT91SAM926x_PMC_UHP
#elif defined(CONFIG_AT91SAM9RL)
#include <asm/arch/at91sam9rl.h>
#elif defined(CONFIG_AT91CAP9)
diff --git a/include/configs/at91sam9263ek.h
b/include/configs/at91sam9263ek.h
new file mode 100644
index 0000000..3ae9846
--- /dev/null
+++ b/include/configs/at91sam9263ek.h
@@ -0,0 +1,205 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop <stelian.pop <at> leadtechdesign.com>
+ * Lead Tech Design <www.leadtechdesign.com>
+ *
+ * Configuation settings for the AT91SAM9260EK board.
+ *
+ * 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
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/* ARM asynchronous clock */
+#define    CRYSTAL_16_36766MHZ    1
+
+#ifdef CRYSTAL_16_36766MHZ
+
+#define AT91_MAIN_CLOCK    199919000    /* from 16.367 MHz crystal
(16367000 / 14 * 171) */
+#define AT91_MASTER_CLOCK    (199919000/2)    /* peripheral clock
(AT91C_MAIN_CLOCK / 2) */
+
+#endif
+
+#ifdef CRYSTAL_18_432MHZ
+
+#define AT91_MAIN_CLOCK    198656000    /* from 16.367 MHz crystal
(16367000 / 5 * 61) */
+#define AT91_MASTER_CLOCK    (198656000/2)    /* peripheral clock
(AT91C_MAIN_CLOCK / 2) */
+
+#endif/* ARM asynchronous clock */
+
+#define CFG_HZ            1000000        /* 1us resolution */
+
+#define AT91_SLOW_CLOCK        32768    /* slow clock */
+
+#define CONFIG_ARM926EJS    1    /* This is an ARM926EJS Core    */
+#define CONFIG_AT91SAM9263    1    /* It's an Atmel AT91SAM9263 SoC*/
+#define CONFIG_AT91SAM9263EK    1    /* on an AT91SAM9263EK Board    */
+#undef CONFIG_USE_IRQ            /* we don't need IRQ/FIQ stuff    */
+
+#define CONFIG_CMDLINE_TAG    1    /* enable passing of ATAGs    */
+#define CONFIG_SETUP_MEMORY_TAGS 1
+#define CONFIG_INITRD_TAG    1
+
+#define CONFIG_SKIP_LOWLEVEL_INIT
+#define CONFIG_SKIP_RELOCATE_UBOOT
+
+/*
+ * Hardware drivers
+ */
+#define CONFIG_ATMEL_USART    1
+#undef CONFIG_USART0
+#undef CONFIG_USART1
+#undef CONFIG_USART2
+#define CONFIG_USART3        1    /* USART 3 is DBGU */
+
+#define CONFIG_BOOTDELAY    3
+#define CONFIG_BOOTARGS        "console=ttyS0,115200 " \
+                "root=/dev/mtdblock0 rw rootfstype=jffs2"
+
+/* #define CONFIG_ENV_OVERWRITE    1 */
+
+/*
+ * BOOTP options
+ */
+#define CONFIG_BOOTP_BOOTFILESIZE    1
+#define CONFIG_BOOTP_BOOTPATH        1
+#define CONFIG_BOOTP_GATEWAY        1
+#define CONFIG_BOOTP_HOSTNAME        1
+
+/*
+ * Command line configuration.
+ */
+#include <config_cmd_default.h>
+#undef CONFIG_CMD_BDI
+#undef CONFIG_CMD_IMI
+#undef CONFIG_CMD_AUTOSCRIPT
+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_LOADS
+#undef CONFIG_CMD_IMLS
+
+#define CONFIG_CMD_PING        1
+#define CONFIG_CMD_DHCP        1
+#define CONFIG_CMD_NAND        1
+#define CONFIG_CMD_USB        1
+
+/* SDRAM */
+#define CONFIG_NR_DRAM_BANKS        1
+#define PHYS_SDRAM            0x20000000
+#define PHYS_SDRAM_SIZE            0x04000000    /* 64 megs */
+
+/* DataFlash */
+#define CONFIG_HAS_DATAFLASH        1
+#define CFG_SPI_WRITE_TOUT        (5*CFG_HZ)
+#define CFG_MAX_DATAFLASH_BANKS        2
+#define CFG_DATAFLASH_LOGIC_ADDR_CS0    0xC0000000    /* CS0 */
+#define CFG_DATAFLASH_LOGIC_ADDR_CS1    0xD0000000    /* CS1 */
+#define AT91_SPI_CLK            33000000
+#define DATAFLASH_TCSS            (0x1a << 16)
+#define DATAFLASH_TCHS            (0x1 << 24)
+
+/* NAND flash */
+#define NAND_MAX_CHIPS            1
+#define CFG_MAX_NAND_DEVICE        1
+#define CFG_NAND_BASE            0x40000000
+
+/* NOR flash - no real flash on this board */
+#define CFG_NO_FLASH            1
+
+/* Ethernet */
+#define CONFIG_MACB            1
+#define CONFIG_RMII            1
+#define CONFIG_NET_MULTI        1
+#define CONFIG_NET_RETRY_COUNT        20
+#define CONFIG_RESET_PHY_R        1
+
+/* USB */
+#define CONFIG_USB_OHCI_NEW        1
+#define LITTLEENDIAN            1
+#define CONFIG_DOS_PARTITION        1
+#define CFG_USB_OHCI_CPU_INIT        1
+#define CFG_USB_OHCI_REGS_BASE        0x00a00000    /*
AT91SAM9260_UHP_BASE */
+#define CFG_USB_OHCI_SLOT_NAME        "at91sam9263"
+#define CFG_USB_OHCI_MAX_ROOT_PORTS    2
+#define CONFIG_USB_STORAGE        1
+
+#define CFG_LOAD_ADDR            0x22000000    /* load address */
+
+#define CFG_MEMTEST_START        PHYS_SDRAM
+#define CFG_MEMTEST_END            0x23e00000
+
+#undef CFG_USE_DATAFLASH_CS0
+#undef CFG_USE_DATAFLASH_CS1
+#define CFG_USE_NANDFLASH        1
+
+#ifdef CFG_USE_DATAFLASH_CS0
+
+/* bootstrap + u-boot + env + linux in dataflash on CS0 */
+#define CFG_ENV_IS_IN_DATAFLASH    1
+#define CFG_MONITOR_BASE    (CFG_DATAFLASH_LOGIC_ADDR_CS0 + 0x8400)
+#define CFG_ENV_OFFSET        0x4200
+#define CFG_ENV_ADDR        (CFG_DATAFLASH_LOGIC_ADDR_CS0 + CFG_ENV_OFFSET)
+#define CFG_ENV_SIZE        0x4200
+#define CONFIG_BOOTCOMMAND    "cp.b 0xC003DE00 0x22000000 0x200040; bootm"
+
+#elif CFG_USE_DATAFLASH_CS1
+
+/* bootstrap + u-boot + env + linux in dataflash on CS1 */
+#define CFG_ENV_IS_IN_DATAFLASH    1
+#define CFG_MONITOR_BASE    (CFG_DATAFLASH_LOGIC_ADDR_CS1 + 0x8400)
+#define CFG_ENV_OFFSET        0x4200
+#define CFG_ENV_ADDR        (CFG_DATAFLASH_LOGIC_ADDR_CS1 + CFG_ENV_OFFSET)
+#define CFG_ENV_SIZE        0x4200
+#define CONFIG_BOOTCOMMAND    "cp.b 0xD003DE00 0x22000000 0x200040; bootm"
+
+#else /* CFG_USE_NANDFLASH */
+
+/* bootstrap + u-boot + env + linux in nandflash */
+#define CFG_ENV_IS_IN_NAND    1
+#define CFG_ENV_OFFSET        0x60000
+#define CFG_ENV_OFFSET_REDUND    0x80000
+#define CFG_ENV_SIZE        0x20000        /* 1 sector = 128 kB */
+#define CONFIG_BOOTCOMMAND    "nand read 0x22000000 0xA0000 0x200000;
bootm"
+
+#endif
+
+#define CONFIG_BAUDRATE        115200
+#define CFG_BAUDRATE_TABLE    {115200 , 19200, 38400, 57600, 9600 }
+
+#define CFG_PROMPT        "U-Boot> "
+#define CFG_CBSIZE        256
+#define CFG_MAXARGS        16
+#define CFG_PBSIZE        (CFG_CBSIZE + sizeof(CFG_PROMPT) + 16)
+#define CFG_LONGHELP        1
+#define CONFIG_CMDLINE_EDITING    1
+
+#define ROUND(A, B)        (((A) + (B)) & ~((B) - 1))
+/*
+ * Size of malloc() pool
+ */
+#define CFG_MALLOC_LEN        ROUND(3 * CFG_ENV_SIZE + 128*1024, 0x1000)
+#define CFG_GBL_DATA_SIZE    128    /* 128 bytes for initial data */
+
+#define CONFIG_STACKSIZE    (32*1024)    /* regular stack */
+
+#ifdef CONFIG_USE_IRQ
+#error CONFIG_USE_IRQ not supported
+#endif
+
+#endif
diff --git a/net/eth.c b/net/eth.c
index 99897ca..f0b9091 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -284,7 +284,7 @@ int eth_initialize(bd_t *bis)
#if defined(CONFIG_FSLDMAFEC)
     mcdmafec_initialize(bis);
#endif
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) ||
defined(CONFIG_AT91SAM9263)
     at91sam9_eth_initialize(bis);
#endif


-- 

Regards,

Jared Holzman

------------------------------------------------------------------------

*Electronics Design Engineer*

*Genesys Electronics Design Pty Ltd*

Unit 5, 33 Ryde Rd Pymble
NSW, Australia 2073

Direct: +612 9496 8924
Phone: +612 9496 8900
Fax: +612 9496 8999

j.holzman at genesysdesign.com.au <mailto:j.holzman at genesysdesign.com.au>
www.genesysdesign.com.au <http://www.genesysdesign.com.au>

------------------------------------------------------------------------




From plagnioj at jcrosoft.com  Tue Apr 22 08:26:01 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 22 Apr 2008 08:26:01 +0200
Subject: [U-Boot-Users] [PATCH 2/2 V2] qemu-mips: add full	functionnalty
	and support of CONFIG_SMALLEST
In-Reply-To: <20080421192649.03DB424764@gemini.denx.de>
References: <1208800094-23117-1-git-send-email-plagnioj@jcrosoft.com>
	<20080421192649.03DB424764@gemini.denx.de>
Message-ID: <20080422062601.GA22850@game.jcrosoft.org>

On 21:26 Mon 21 Apr     , Wolfgang Denk wrote:
> In message <1208800094-23117-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> > add support of :
> > #define CONFIG_CMD_ASKENV
> > #define CONFIG_CMD_LOADS
> > #define CONFIG_CMD_LOADB
> > #define CONFIG_CMD_PING
> > #define CONFIG_CMD_CDP
> > #define CONFIG_CMD_SAVES
> > #define CONFIG_CMD_SETEXPR
> > 
> > and keep only :
> > tftp and dhcp support when CONFIG_SMALLEST is active
> 
> What is the difference between the first patch and patch "V2"?
> 
I've invert on line in the Makefile

I've put
@[ -z "$(findstring _smallest_,$@)" ] || \ 

before
@echo "#define CONFIG_QEMU_MIPS 1" >$(obj)include/config.h

so the #define CONFIG_SMALLEST is overwrite

> What is "CONFIG_SMALLEST" ?
> 
Built the minimal functionnality to create the smallest u-boot
> What is "full functionnalty"?
> 
Active everythink that we could.

Best regards,
J.



From plagnioj at jcrosoft.com  Tue Apr 22 08:28:36 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 22 Apr 2008 08:28:36 +0200
Subject: [U-Boot-Users] [PATCH 0/2] NE2000: Fix regresssion
	introduced	by e710185aae90 on non AX88796
In-Reply-To: <20080421192419.C76E124764@gemini.denx.de>
References: <1208798540-22251-1-git-send-email-plagnioj@jcrosoft.com>
	<20080421192419.C76E124764@gemini.denx.de>
Message-ID: <20080422062836.GB22850@game.jcrosoft.org>

On 21:24 Mon 21 Apr     , Wolfgang Denk wrote:
> In message <1208798540-22251-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> > Move non-inlied functions into specific drivers file
> > Set get_prom as weak
> > 
> > Coding Style Cleanup
> 
> Please split in two (3?) separate patches. Thanks.

We could separate the Coding style in an other patch
but if possible i'll let it in the same patch.

Seperate the moving of non-inlined functions and the setting of get_prom
as weak is ine block to fix the regression

Best Regards,
J.



From plagnioj at jcrosoft.com  Tue Apr 22 08:32:29 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 22 Apr 2008 08:32:29 +0200
Subject: [U-Boot-Users] [PATCH u-boot-at91] Add support for AT91SAM9263EK
In-Reply-To: <480D6840.4090704@genesysdesign.com.au>
References: <480D6840.4090704@genesysdesign.com.au>
Message-ID: <20080422063229.GC22850@game.jcrosoft.org>

On 14:23 Tue 22 Apr     , Jared Holzman wrote:
> This patch adds support for the AT91SAM9263EK board. It builds on top of 
> the support added for the AT91SAM9260EK by Stelian Pop. It was created 
> against the u-boot-at91 custodian tree, so I hope this is correct place to 
> submit it.
> ---
Patch line wrapped please resend it, use git tools as example
and coding style issue (use tab for indentation)
>
> diff --git a/Makefile b/Makefile
> index cf16bd6..c6d903e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2311,6 +2311,9 @@ at91rm9200dk_config    :    unconfig
> at91sam9260ek_config    :    unconfig
>     @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9260ek atmel at91sam9
> +at91sam9263ek_config    :    unconfig
> +    @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9263ek atmel at91sam9
> +
> cmc_pu2_config    :    unconfig
>     @$(MKCONFIG) $(@:_config=) arm arm920t cmc_pu2 NULL at91rm9200
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 703784e..499c7da 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -417,13 +417,13 @@ static int macb_init(struct eth_device *netdev, bd_t 
> *bd)
>     /* choose RMII or MII mode. This depends on the board */
> #ifdef CONFIG_RMII
> -#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
> +#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined 
> (CONFIG_AT91SAM9263)
We may create an other CONFIG_ for this
>     macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN));
> #else
>     macb_writel(macb, USRIO, 0);
> #endif
> #else
> -#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
> +#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined 
> (CONFIG_AT91SAM9263)
>     macb_writel(macb, USRIO, MACB_BIT(CLKEN));
> #else
>     macb_writel(macb, USRIO, MACB_BIT(MII));
> diff --git a/include/asm-arm/arch-at91sam9/hardware.h 
> b/include/asm-arm/arch-at91sam9/hardware.h
> index 80b334f..4f9f2a8 100644
> --- a/include/asm-arm/arch-at91sam9/hardware.h
Best Regards,
J.



From r63238 at freescale.com  Tue Apr 22 09:17:36 2008
From: r63238 at freescale.com (Dave Liu)
Date: Tue, 22 Apr 2008 15:17:36 +0800
Subject: [U-Boot-Users] [PATCH 1/3] mpc83xx: update the default load
	address for	837xemds board
In-Reply-To: <20080421165751.291605cd.kim.phillips@freescale.com>
References: <1208236229.3656.1.camel@localhost.localdomain>
	<20080421165751.291605cd.kim.phillips@freescale.com>
Message-ID: <1208848656.3789.6.camel@localhost.localdomain>

> > Update the default load address. if not, the kernel image
> > will be overwritten when u-boot boot the latest linux kernel.
> > 
> > Signed-off-by: Dave Liu <daveliu at freescale.com>
> > ---
> >  include/configs/MPC837XEMDS.h |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h
> > index 7fc0f7e..b2b4aa1 100644
> > --- a/include/configs/MPC837XEMDS.h
> > +++ b/include/configs/MPC837XEMDS.h
> > @@ -595,7 +595,7 @@
> >  
> >  #define CONFIG_BAUDRATE 115200
> >  
> > -#define CONFIG_LOADADDR 200000	/* default location for tftp and bootm */
> > +#define CONFIG_LOADADDR 2000000	/* default location for tftp and bootm */
> >  
> >  #define CONFIG_BOOTDELAY 6	/* -1 disables auto-boot */
> >  #undef CONFIG_BOOTARGS		/* the boot command will set bootargs */
> > @@ -605,7 +605,7 @@
> >     "consoledev=ttyS0\0"							\
> >     "ramdiskaddr=1000000\0"						\
> >     "ramdiskfile=ramfs.83xx\0"						\
> > -   "fdtaddr=400000\0"							\
> > +   "fdtaddr=3000000\0"							\
> 
> is such a drastic difference really necessary?  how about we double
> them instead?

Of course, double them is also OK.

I set them as sort. it's better to remember.

ramdiskaddr	= 0x1000000
loadaddr	= 0x2000000
fdtaddr		= 0x3000000.

Thanks,
Dave






From shinya.kuribayashi at necel.com  Tue Apr 22 09:26:44 2008
From: shinya.kuribayashi at necel.com (Shinya Kuribayashi)
Date: Tue, 22 Apr 2008 16:26:44 +0900
Subject: [U-Boot-Users] [PATCH 2/2 V2] qemu-mips: add full functionnalty
 and support of CONFIG_SMALLEST
In-Reply-To: <20080421192649.03DB424764@gemini.denx.de>
References: <20080421192649.03DB424764@gemini.denx.de>
Message-ID: <480D9334.6090808@necel.com>

Wolfgang Denk wrote:
> In message <1208800094-23117-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
>> add support of :
>> #define CONFIG_CMD_ASKENV
>> #define CONFIG_CMD_LOADS
>> #define CONFIG_CMD_LOADB
>> #define CONFIG_CMD_PING
>> #define CONFIG_CMD_CDP
>> #define CONFIG_CMD_SAVES
>> #define CONFIG_CMD_SETEXPR
>>
>> and keep only :
>> tftp and dhcp support when CONFIG_SMALLEST is active
> 
> What is the difference between the first patch and patch "V2"?
> 
> What is "CONFIG_SMALLEST" ?
> 
> What is "full functionnalty"?

Although I said "(I) will push in a week or two" before, but I'll drop
this patch from my pull-request list, since it needs to be logically
sorted out a little more.

Jean, I recommend to change only CFI-support addition stuff. No need to
make things complicated, no commands cleanups, no CodinStyle cleanups.

> Best regards,
> 
> Wolfgang Denk

-- 
Shinya Kuribayashi
NEC Electronics



From shinya.kuribayashi at necel.com  Tue Apr 22 09:38:54 2008
From: shinya.kuribayashi at necel.com (Shinya Kuribayashi)
Date: Tue, 22 Apr 2008 16:38:54 +0900
Subject: [U-Boot-Users] [PATCH 2/2 V2] qemu-mips: add full functionnalty
 and support of CONFIG_SMALLEST
In-Reply-To: <480D9334.6090808@necel.com>
References: <20080421192649.03DB424764@gemini.denx.de>
	<480D9334.6090808@necel.com>
Message-ID: <480D960E.6020109@necel.com>

Shinya Kuribayashi wrote:
> Wolfgang Denk wrote:
>> In message <1208800094-23117-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
>>> add support of :
>>> #define CONFIG_CMD_ASKENV
>>> #define CONFIG_CMD_LOADS
>>> #define CONFIG_CMD_LOADB
>>> #define CONFIG_CMD_PING
>>> #define CONFIG_CMD_CDP
>>> #define CONFIG_CMD_SAVES
>>> #define CONFIG_CMD_SETEXPR
>>>
>>> and keep only :
>>> tftp and dhcp support when CONFIG_SMALLEST is active
>> What is the difference between the first patch and patch "V2"?
>>
>> What is "CONFIG_SMALLEST" ?
>>
>> What is "full functionnalty"?
> 
> Although I said "(I) will push in a week or two" before, but I'll drop
> this patch from my pull-request list, since it needs to be logically
> sorted out a little more.
> 
> Jean, I recommend to change only CFI-support addition stuff. No need to
> make things complicated, no commands cleanups, no CodinStyle cleanups.

I'm sorry, incorrect thread...

-- 
Shinya Kuribayashi
NEC Electronics



From info at fuarlar.us  Tue Apr 22 09:44:57 2008
From: info at fuarlar.us (Kent Antalya e-davetiye)
Date: Tue, 22 Apr 2008 10:44:57 +0300
Subject: [U-Boot-Users] =?iso-8859-9?q?Kent_Fuarlar=FD_Antalya_Bu_Hafta_Ba?=
	=?iso-8859-9?q?=FEl=FDyor_Ka=E7=FDrmay=FDn=2E=2E=2E?=
Message-ID: <9ad90072b86574b05da6510a2f8b88d6@fuarlar.us>




kent antalya e-davetiye







  
     
  



  
     
  

  
     
  

  
    
      
        
          Yukar?daki davetiyenin ??k???n? alarak yada linkteki formu doldurarak fuar?m?z? ?cretsiz ziyaret edebilirsiniz. 

        
      
      Online Fuar Davetiyesi 
      i?in t?klay?n... 

      

     
  

  
      
  

  
    Marmara Tan&#305;t&#305;m Fuarc?l?k

            Istanbul (Merkez) Tel: +90 212 481 04 04 Fax: +90 212 481 04 74

            Ankara (&#350;ube) Tel: +90 312 426 64 22 Fax: +90 312 426 64 41

            Izmir (Sube) Tel: +90 232 422 00 93 Fax: +90 232  422 16 33

  
  




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080422/5961ad07/attachment.htm 

From trimarchi at gandalf.sssup.it  Tue Apr 22 09:53:14 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Tue, 22 Apr 2008 09:53:14 +0200
Subject: [U-Boot-Users] USB SUPPORT
In-Reply-To: <AA28F077645B324881335614E4F7C428034CD5@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CD5@win-ex01.bench.com>
Message-ID: <480D996A.2020007@gandalf.sssup.it>

Hi,
>
> $ ls -lU | wc
>      42     371    2504
> $ 
>
> Here's fatls output on an XP FAT32 formatted pen drive:
>
> U-Boot> fatls usb 0:1 /
> fatls usb 0:1 /
>      1298   xy010.ubs
>      1298   xy011.ubs
>      1298   xy100.ubs
>      1298   xy101.ubs
>             admin/
>      1298   xy110.ubs
>      1298   xy111.ubs
>             linux_demo/
>             photos/
>             videos/
>        32   ab000.txt
>        32   ab001.txt
>        32   ab010.txt
>        32   ab011.txt
>        32   ab100.txt
>        32   ab101.txt
>        32   ab110.txt
>        32   ab111.txt
>    308326   coffee.bmp
>     24116   debian.bmp
>    153720   debianlilo.bmp
>        65   index.txt
>       179   locvar.ubs
>        95   locvar1.ubs
>       101   locvar2.ubs
>     23662   sarge.bmp
>     24116   sid.bmp
>      6719   test000.ugz
>      6719   test001.ugz
> \365+3.\341
>             write.sk4/
>  1718159906   .000
>             otm.800/
>             /
>  2016419888   .mmc
>  808464432   20000000."
>
>             0.0x2/
>             if.ad/
>             :1.000/
>  808464432   ."
>  1948269360   ;
>  1920409699   hen
>
>             ite.0/
>             .wri/
>             .280/
>  540028976   "
> if.loa
>  1763713056   /part3.u.gz;
>             f.0x2/
>             .280/
>  808465457   ho
>             0.000/
>  544172131   28000.000
>  1667566090   ".
>
>             0.10./
>  2016419949   ;
>  808464432   .ite
>  538976266   0x200000.00
>
>
> 40 file(s), 17 dir(s)
>
> U-Boot> 
>   
Can you give an image of it?

Regards Michael




From shenzhenshanhudao at 126.com  Tue Apr 22 11:19:19 2008
From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=)
Date: Tue, 22 Apr 2008 17:19:19 +0800
Subject: [U-Boot-Users] (no subject)
Message-ID: <E1JoEeg-0003yl-8r@mail.sourceforge.net>

?????????
                
    ??????2008?????????????????????????
?
?????????????????? ????????????
    
    ?????????????????????????????????

???????????......???????????????????????

?????????????????????????????????????

???????????
?
                              ???0755-81153047?
?
                              ???0755-81172940?
?
                              ???15817477278?
?
                              ????????
?
   ???
                                                         

                                                                ???



From wd at denx.de  Tue Apr 22 12:01:38 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 12:01:38 +0200
Subject: [U-Boot-Users] [PATCH 2/2 V2] qemu-mips: add full functionnalty
	and support of CONFIG_SMALLEST
In-Reply-To: Your message of "Tue, 22 Apr 2008 08:26:01 +0200."
	<20080422062601.GA22850@game.jcrosoft.org>
Message-ID: <20080422100138.BC262247AF@gemini.denx.de>

In message <20080422062601.GA22850 at game.jcrosoft.org> you wrote:
>
> > What is the difference between the first patch and patch "V2"?
> > 
> I've invert on line in the Makefile

You should explain such things when you post several versions of a
patch. Otherwise it's extremely difficult to understand what exactly
you want.

> > What is "CONFIG_SMALLEST" ?
> > 
> Built the minimal functionnality to create the smallest u-boot

CONFIG_* reads like a standard option toi me, so I was lookign for
appropriate documentation in the README for it. Now I tend to think
this is something that is more private to your board?

Also, "smallest" is certainly not an absolute term ;-)

> > What is "full functionnalty"?
> > 
> Active everythink that we could.

Actually I intended to point out that you might want to fix the
spelling errors...

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: wd at denx.de
Like winter snow on summer lawn, time past is time gone.



From wd at denx.de  Tue Apr 22 12:02:38 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 12:02:38 +0200
Subject: [U-Boot-Users] [PATCH 0/2] NE2000: Fix regresssion introduced
	by e710185aae90 on non AX88796
In-Reply-To: Your message of "Tue, 22 Apr 2008 08:28:36 +0200."
	<20080422062836.GB22850@game.jcrosoft.org>
Message-ID: <20080422100238.BDB04247AF@gemini.denx.de>

In message <20080422062836.GB22850 at game.jcrosoft.org> you wrote:
>
> > > Move non-inlied functions into specific drivers file
> > > Set get_prom as weak
> > > 
> > > Coding Style Cleanup
> > 
> > Please split in two (3?) separate patches. Thanks.
> 
> We could separate the Coding style in an other patch
> but if possible i'll let it in the same patch.

Please split it up, because otherwise the changes are really difficult
to see.

> Seperate the moving of non-inlined functions and the setting of get_prom
> as weak is ine block to fix the regression

OK.

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: wd at denx.de
It's a small world, but I wouldn't want to paint it.



From sr at denx.de  Tue Apr 22 12:22:08 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 12:22:08 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Pass PCIe root-complex/endpoint
	configuration to Linux via the fdt
Message-ID: <1208859728-10908-1-git-send-email-sr@denx.de>

The PCIe root-complex/endpoint setup as configured via the "pcie_mode"
environment variable will now get passed to the Linux kernel by setting
the device_type property of the PCIe device tree node. For normal root-
complex configuration it will keep its defaults value of "pci" and for
endpoint configuration it will get changed to "pci-endpoint".

Signed-off-by: Stefan Roese <sr at denx.de>
---
 cpu/ppc4xx/fdt.c           |   42 ++++++++++++++++++++++++++++++++++++++++++
 include/asm-ppc/4xx_pcie.h |    5 ++++-
 2 files changed, 46 insertions(+), 1 deletions(-)

diff --git a/cpu/ppc4xx/fdt.c b/cpu/ppc4xx/fdt.c
index afcb974..1f4d6f2 100644
--- a/cpu/ppc4xx/fdt.c
+++ b/cpu/ppc4xx/fdt.c
@@ -31,9 +31,46 @@
 #include <libfdt.h>
 #include <libfdt_env.h>
 #include <fdt_support.h>
+#include <asm/4xx_pcie.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/*
+ * Fixup all PCIe nodes by setting the device_type property
+ * to "pci-endpoint" instead is "pci" for endpoint ports.
+ * This property will get checked later by the Linux driver
+ * to properly configure the PCIe port in Linux (again).
+ */
+void fdt_pcie_setup(void *blob)
+{
+	const char *compat = "ibm,plb-pciex";
+	const char *prop = "device_type";
+	const char *prop_val = "pci-endpoint";
+	const u32 *port;
+	int no;
+	int rc;
+
+	/* Search first PCIe node */
+	no = fdt_node_offset_by_compatible(blob, -1, compat);
+	while (no != -FDT_ERR_NOTFOUND) {
+		port = fdt_getprop(blob, no, "port", NULL);
+		if (port == NULL) {
+			printf("WARNING: could not find port property\n");
+		} else {
+			if (is_end_point(*port)) {
+				rc = fdt_setprop(blob, no, prop, prop_val,
+						 strlen(prop_val) + 1);
+				if (rc < 0)
+					printf("WARNING: could not set %s for %s: %s.\n",
+					       prop, compat, fdt_strerror(rc));
+			}
+		}
+
+		/* Jump to next PCIe node */
+		no = fdt_node_offset_by_compatible(blob, no, compat);
+	}
+}
+
 void ft_cpu_setup(void *blob, bd_t *bd)
 {
 	sys_info_t sys_info;
@@ -60,5 +97,10 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 	 * Note: aliases in the dts are required for this
 	 */
 	fdt_fixup_ethernet(blob, bd);
+
+	/*
+	 * Fixup all available PCIe nodes by setting the device_type property
+	 */
+	fdt_pcie_setup(blob);
 }
 #endif /* CONFIG_OF_LIBFDT */
diff --git a/include/asm-ppc/4xx_pcie.h b/include/asm-ppc/4xx_pcie.h
index d27d2a9..5398696 100644
--- a/include/asm-ppc/4xx_pcie.h
+++ b/include/asm-ppc/4xx_pcie.h
@@ -8,10 +8,11 @@
  * option) any later version.
  */
 
-#include <ppc4xx.h>
 #ifndef __4XX_PCIE_H
 #define __4XX_PCIE_H
 
+#include <ppc4xx.h>
+
 #define DCRN_SDR0_CFGADDR	0x00e
 #define DCRN_SDR0_CFGDATA	0x00f
 
@@ -395,6 +396,7 @@ static inline void mdelay(int n)
 		udelay(1000);
 }
 
+#if defined(PCIE0_SDR)
 static inline u32 sdr_base(int port)
 {
 	switch (port) {
@@ -409,5 +411,6 @@ static inline u32 sdr_base(int port)
 #endif
 	}
 }
+#endif /* defined(PCIE0_SDR) */
 
 #endif /* __4XX_PCIE_H */
-- 
1.5.5.1




From tur at semihalf.com  Tue Apr 22 12:27:50 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Tue, 22 Apr 2008 12:27:50 +0200
Subject: [U-Boot-Users] [PATCH v2 0/2] Calculate image hashes with watchdog
	triggering
In-Reply-To: <20080412111343.16495.21545.stgit@pollux.denx.de>
References: <20080412111343.16495.21545.stgit@pollux.denx.de>
Message-ID: <20080422102608.30118.57386.stgit@pollux.denx.de>

Hash calculation of an image can be a time consuming operation, with the
possibility of making the hardware watchdog (if present/enabled) expire in the
middle. Add watchdog-aware hash calculation functions and make image hash
calculation use them.
---
v2 of the patchset, rebased against current TOT (commit dc7746d8).

Bartlomiej Sieka (2):
      Use watchdog-aware functions when calculating hashes of images
      Add support for calulacting hashes with watchdog triggering


 common/image.c       |   43 +++++++++----------------------------------
 include/common.h     |    1 +
 include/image.h      |   17 +++++++++++++++--
 include/sha1.h       |   11 +++++++++++
 include/u-boot/md5.h |    8 ++++++++
 lib_generic/crc32.c  |   28 ++++++++++++++++++++++++++++
 lib_generic/md5.c    |   40 ++++++++++++++++++++++++++++++++++++++++
 lib_generic/sha1.c   |   37 +++++++++++++++++++++++++++++++++++++
 8 files changed, 149 insertions(+), 36 deletions(-)



From tur at semihalf.com  Tue Apr 22 12:27:56 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Tue, 22 Apr 2008 12:27:56 +0200
Subject: [U-Boot-Users] [PATCH v2 1/2] Add support for calulacting hashes
	with watchdog	triggering
In-Reply-To: <20080422102608.30118.57386.stgit@pollux.denx.de>
References: <20080422102608.30118.57386.stgit@pollux.denx.de>
Message-ID: <20080422102756.30118.38437.stgit@pollux.denx.de>

Implement watchodg-aware variants of hash calculation functions:
- crc32_wd()
- md5_wd()
- sha1_csum_wd()
The above functions calculate the hash of the input buffer in chunks,
triggering the watchdog after processing each chunk. The chunk size is given
as a function call parameter.

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 include/common.h     |    1 +
 include/sha1.h       |   11 +++++++++++
 include/u-boot/md5.h |    8 ++++++++
 lib_generic/crc32.c  |   27 +++++++++++++++++++++++++++
 lib_generic/md5.c    |   36 ++++++++++++++++++++++++++++++++++++
 lib_generic/sha1.c   |   33 +++++++++++++++++++++++++++++++++
 6 files changed, 116 insertions(+), 0 deletions(-)

diff --git a/include/common.h b/include/common.h
index 8630780..ec894e7 100644
--- a/include/common.h
+++ b/include/common.h
@@ -605,6 +605,7 @@ int	vsprintf(char *buf, const char *fmt, va_list args);
 
 /* lib_generic/crc32.c */
 ulong crc32 (ulong, const unsigned char *, uint);
+ulong crc32_wd (ulong, const unsigned char *, uint, uint);
 ulong crc32_no_comp (ulong, const unsigned char *, uint);
 
 /* common/console.c */
diff --git a/include/sha1.h b/include/sha1.h
index 15ea13c..734d1fb 100644
--- a/include/sha1.h
+++ b/include/sha1.h
@@ -80,6 +80,17 @@ void sha1_csum( unsigned char *input, int ilen,
 		unsigned char output[20] );
 
 /**
+ * \brief	   Output = SHA-1( input buffer ), with watchdog triggering
+ *
+ * \param input    buffer holding the  data
+ * \param ilen	   length of the input data
+ * \param output   SHA-1 checksum result
+ * \param chunk_sz watchdog triggering period (in bytes of input processed)
+ */
+void sha1_csum_wd (unsigned char *input, int ilen,
+		unsigned char output[20], unsigned int chunk_sz);
+
+/**
  * \brief	   Output = SHA-1( file contents )
  *
  * \param path	   input file name
diff --git a/include/u-boot/md5.h b/include/u-boot/md5.h
index 046d1ee..8b44a7f 100644
--- a/include/u-boot/md5.h
+++ b/include/u-boot/md5.h
@@ -20,4 +20,12 @@ struct MD5Context {
  */
 void md5 (unsigned char *input, int len, unsigned char output[16]);
 
+/*
+ * Calculate and store in 'output' the MD5 digest of 'len' bytes at 'input'.
+ * 'output' must have enough space to hold 16 bytes. If 'chunk' Trigger the
+ * watchdog every 'chunk_sz' bytes of input processed.
+ */
+void md5_wd (unsigned char *input, int len, unsigned char output[16],
+		unsigned int chunk_sz);
+
 #endif /* _MD5_H */
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index df0dbca..0bfb64b 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -197,3 +197,30 @@ uLong ZEXPORT crc32_no_comp(uLong crc, const Bytef *buf, uInt len)
 }
 
 #endif
+
+/*
+ * Calculate the crc32 checksum triggering the watchdog every 'chunk_sz' bytes
+ * of input.
+ */
+ulong crc32_wd (ulong crc, const unsigned char *buf, uint len, uint chunk_sz)
+{
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	const unsigned char *end, *curr;
+	int chunk;
+
+	curr = buf;
+	end = buf + len;
+	while (curr < end) {
+		chunk = end - curr;
+		if (chunk > chunk_sz)
+			chunk = chunk_sz;
+		crc = crc32 (crc, curr, chunk);
+		curr += chunk;
+		WATCHDOG_RESET ();
+	}
+#else
+        crc = crc32 (crc, buf, len);
+#endif
+
+	return crc;
+}
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index 3cee431..20178b8 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -272,3 +272,39 @@ md5 (unsigned char *input, int len, unsigned char output[16])
 	MD5Update(&context, input, len);
 	MD5Final(output, &context);
 }
+
+
+/*
+ * Calculate and store in 'output' the MD5 digest of 'len' bytes at 'input'.
+ * 'output' must have enough space to hold 16 bytes. If 'chunk' Trigger the
+ * watchdog every 'chunk_sz' bytes of input processed.
+ */
+void
+md5_wd (unsigned char *input, int len, unsigned char output[16],
+	unsigned int chunk_sz)
+{
+	struct MD5Context context;
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	unsigned char *end, *curr;
+	int chunk;
+#endif
+
+	MD5Init(&context);
+
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	curr = input;
+	end = input + len;
+	while (curr < end) {
+		chunk = end - curr;
+		if (chunk > chunk_sz)
+			chunk = chunk_sz;
+		MD5Update(&context, curr, chunk);
+		curr += chunk;
+		WATCHDOG_RESET ();
+	}
+#else
+	MD5Update(&context, input, len);
+#endif
+
+	MD5Final(output, &context);
+}
diff --git a/lib_generic/sha1.c b/lib_generic/sha1.c
index 08ffa6b..6950659 100644
--- a/lib_generic/sha1.c
+++ b/lib_generic/sha1.c
@@ -309,6 +309,39 @@ void sha1_csum (unsigned char *input, int ilen, unsigned char output[20])
 }
 
 /*
+ * Output = SHA-1( input buffer ). Trigger the watchdog every 'chunk_sz'
+ * bytes of input processed.
+ */
+void sha1_csum_wd (unsigned char *input, int ilen, unsigned char output[20],
+			unsigned int chunk_sz)
+{
+	sha1_context ctx;
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	unsigned char *end, *curr;
+	int chunk;
+#endif
+
+	sha1_starts (&ctx);
+
+#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
+	curr = input;
+	end = input + ilen;
+	while (curr < end) {
+		chunk = end - curr;
+		if (chunk > chunk_sz)
+			chunk = chunk_sz;
+		sha1_update (&ctx, curr, chunk);
+		curr += chunk;
+		WATCHDOG_RESET ();
+	}
+#else
+	sha1_update (&ctx, input, ilen);
+#endif
+
+	sha1_finish (&ctx, output);
+}
+
+/*
  * Output = HMAC-SHA-1( input buffer, hmac key )
  */
 void sha1_hmac (unsigned char *key, int keylen,




From tur at semihalf.com  Tue Apr 22 12:28:02 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Tue, 22 Apr 2008 12:28:02 +0200
Subject: [U-Boot-Users] [PATCH v2 2/2] Use watchdog-aware functions when
	calculating hashes	of images
In-Reply-To: <20080422102608.30118.57386.stgit@pollux.denx.de>
References: <20080422102608.30118.57386.stgit@pollux.denx.de>
Message-ID: <20080422102802.30118.26894.stgit@pollux.denx.de>

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 common/image.c      |   43 +++++++++----------------------------------
 include/image.h     |   17 +++++++++++++++--
 lib_generic/crc32.c |    1 +
 lib_generic/md5.c   |    4 ++++
 lib_generic/sha1.c  |    4 ++++
 5 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/common/image.c b/common/image.c
index 9b1108f..efb0c4b 100644
--- a/common/image.c
+++ b/common/image.c
@@ -156,6 +156,8 @@ static table_entry_t uimage_comp[] = {
 };
 
 unsigned long crc32 (unsigned long, const unsigned char *, unsigned int);
+unsigned long crc32_wd (unsigned long, const unsigned char *,
+			unsigned int, unsigned int);
 static void genimg_print_size (uint32_t size);
 #if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) || defined(USE_HOSTCC)
 static void genimg_print_time (time_t timestamp);
@@ -183,39 +185,11 @@ int image_check_dcrc (image_header_t *hdr)
 {
 	ulong data = image_get_data (hdr);
 	ulong len = image_get_data_size (hdr);
-	ulong dcrc = crc32 (0, (unsigned char *)data, len);
+	ulong dcrc = crc32_wd (0, (unsigned char *)data, len, CHUNKSZ_CRC32);
 
 	return (dcrc == image_get_dcrc (hdr));
 }
 
-#ifndef USE_HOSTCC
-int image_check_dcrc_wd (image_header_t *hdr, ulong chunksz)
-{
-	ulong dcrc = 0;
-	ulong len = image_get_data_size (hdr);
-	ulong data = image_get_data (hdr);
-
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
-	ulong cdata = data;
-	ulong edata = cdata + len;
-
-	while (cdata < edata) {
-		ulong chunk = edata - cdata;
-
-		if (chunk > chunksz)
-			chunk = chunksz;
-		dcrc = crc32 (dcrc, (unsigned char *)cdata, chunk);
-		cdata += chunk;
-
-		WATCHDOG_RESET ();
-	}
-#else
-	dcrc = crc32 (0, (unsigned char *)data, len);
-#endif
-
-	return (dcrc == image_get_dcrc (hdr));
-}
-#endif /* !USE_HOSTCC */
 
 /**
  * image_multi_count - get component (sub-image) count
@@ -416,7 +390,7 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 
 	if (verify) {
 		puts("   Verifying Checksum ... ");
-		if (!image_check_dcrc_wd (rd_hdr, CHUNKSZ)) {
+		if (!image_check_dcrc (rd_hdr)) {
 			puts ("Bad Data CRC\n");
 			show_boot_progress (-12);
 			return NULL;
@@ -1923,15 +1897,16 @@ static int calculate_hash (const void *data, int data_len, const char *algo,
 			uint8_t *value, int *value_len)
 {
 	if (strcmp (algo, "crc32") == 0 ) {
-		*((uint32_t *)value) = crc32 (0, data, data_len);
+		*((uint32_t *)value) = crc32_wd (0, data, data_len,
+							CHUNKSZ_CRC32);
 		*((uint32_t *)value) = cpu_to_uimage (*((uint32_t *)value));
 		*value_len = 4;
 	} else if (strcmp (algo, "sha1") == 0 ) {
-		sha1_csum ((unsigned char *) data, data_len,
-				(unsigned char *) value);
+		sha1_csum_wd ((unsigned char *) data, data_len,
+				(unsigned char *) value, CHUNKSZ_SHA1);
 		*value_len = 20;
 	} else if (strcmp (algo, "md5") == 0 ) {
-		md5 ((unsigned char *)data, data_len, value);
+		md5_wd ((unsigned char *)data, data_len, value, CHUNKSZ_MD5);
 		*value_len = 16;
 	} else {
 		debug ("Unsupported hash alogrithm\n");
diff --git a/include/image.h b/include/image.h
index 4076484..664e51e 100644
--- a/include/image.h
+++ b/include/image.h
@@ -227,9 +227,23 @@ typedef struct bootm_headers {
 /*
  * Some systems (for example LWMON) have very short watchdog periods;
  * we must make sure to split long operations like memmove() or
- * crc32() into reasonable chunks.
+ * checksum calculations into reasonable chunks.
  */
+#ifndef CHUNKSZ
 #define CHUNKSZ (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_CRC32
+#define CHUNKSZ_CRC32 (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_MD5
+#define CHUNKSZ_MD5 (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_SHA1
+#define CHUNKSZ_SHA1 (64 * 1024)
+#endif
 
 #define uimage_to_cpu(x)		ntohl(x)
 #define cpu_to_uimage(x)		htonl(x)
@@ -363,7 +377,6 @@ static inline void image_set_name (image_header_t *hdr, const char *name)
 int image_check_hcrc (image_header_t *hdr);
 int image_check_dcrc (image_header_t *hdr);
 #ifndef USE_HOSTCC
-int image_check_dcrc_wd (image_header_t *hdr, ulong chunksize);
 int getenv_yesno (char *var);
 ulong getenv_bootm_low(void);
 ulong getenv_bootm_size(void);
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index 0bfb64b..76ac838 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -12,6 +12,7 @@
 #include <common.h>
 #endif
 
+#include <watchdog.h>
 #include "zlib.h"
 
 #define local static
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index 20178b8..78ef475 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -25,6 +25,10 @@
    and to fit the cifs vfs by
    Steve French sfrench at us.ibm.com */
 
+#ifndef USE_HOSTCC
+#include <common.h>
+#endif /* USE_HOSTCC */
+#include <watchdog.h>
 #include <linux/types.h>
 #include <linux/string.h>
 #include <u-boot/md5.h>
diff --git a/lib_generic/sha1.c b/lib_generic/sha1.c
index 6950659..c8ef4d2 100644
--- a/lib_generic/sha1.c
+++ b/lib_generic/sha1.c
@@ -29,6 +29,10 @@
 #define _CRT_SECURE_NO_DEPRECATE 1
 #endif
 
+#ifndef USE_HOSTCC
+#include <common.h>
+#endif /* USE_HOSTCC */
+#include <watchdog.h>
 #include <linux/string.h>
 #include "sha1.h"
 




From ricard.wanderlof at axis.com  Tue Apr 22 13:44:31 2008
From: ricard.wanderlof at axis.com (Ricard Wanderlof)
Date: Tue, 22 Apr 2008 13:44:31 +0200 (CEST)
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <1208785853.5965.388.camel@sauron>
References: <20080420222237.4AE5324657@gemini.denx.de>
	<1208779508.5965.371.camel@sauron>
	<Pine.LNX.4.64.0804211533140.27984@lnxricardw.se.axis.com> 
	<1208785463.6654.34.camel@vader.jdub.homelinux.org>
	<1208785853.5965.388.camel@sauron>
Message-ID: <Pine.LNX.4.64.0804221342130.16969@lnxricardw.se.axis.com>


On Mon, 21 Apr 2008, Artem Bityutskiy wrote:

> On Mon, 2008-04-21 at 08:44 -0500, Josh Boyer wrote:
>> I think there was only 1 time the on-flash format changed, and that was
>> before UBI was merged upstream.  New features can be introduced with
>> additional flags, however older versions should be able to ignore those.
>>
>> Artem, is that right?  My memory is fuzzy here.
>
> [...] We never changed the media format since UBI was merged.

Ok, that sounds reassuring. I think I've been confusing UBI with UBIFS in 
this respect.

/Ricard
--
Ricard Wolf Wanderl?f                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30



From sr at denx.de  Tue Apr 22 13:50:07 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 13:50:07 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update bootlogo for APC405 boards
In-Reply-To: <200804211346.06941.matthias.fuchs@esd-electronics.com>
References: <200804211346.06941.matthias.fuchs@esd-electronics.com>
Message-ID: <200804221350.07773.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> because of the lists size limit and because I did not find any
> other suitable way to submit this patch, I am posting a link to the patch
> file:
>
> http://www.esd-electronics.com/Customer/mf/0001-4xx-Update-bootlogo-for-APC
>405-boards.patch
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 22 13:50:34 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 13:50:34 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update FPGA image for APC405 boards
In-Reply-To: <200804211347.37429.matthias.fuchs@esd-electronics.com>
References: <200804211347.37429.matthias.fuchs@esd-electronics.com>
Message-ID: <200804221350.34754.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> because of the lists size limit and because I did not find any
> other suitable way to submit this patch, I am posting a link to the patch
> file:
>
> http://www.esd-electronics.com/Customer/mf/0002-4xx-Update-FPGA-image-for-A
>PC405-boards.patch
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 22 13:52:03 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 13:52:03 +0200
Subject: [U-Boot-Users] [PATCH 3/5] 4xx: Update APC405 board support
In-Reply-To: <200804211442.12130.matthias.fuchs@esd-electronics.com>
References: <200804211442.12130.matthias.fuchs@esd-electronics.com>
Message-ID: <200804221352.03777.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> - enable esd's auto_update mechanism
> - fix LCD support on latest hardware revision (uses other LCD controller)
> - support alternative flash layout on rev. 1.8 boards
> - coding style cleanup
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 22 13:51:16 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 13:51:16 +0200
Subject: [U-Boot-Users] [PATCH 1/5] 4xx: Update esd's common LCD code
	for 405 boards
In-Reply-To: <200804211441.59979.matthias.fuchs@esd-electronics.com>
References: <200804211441.59979.matthias.fuchs@esd-electronics.com>
Message-ID: <200804221351.16456.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> - Coding style cleanup (long lines)
> - Add s1d13505 support
> - Make some functions return a result code instead of void
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 22 13:51:43 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 13:51:43 +0200
Subject: [U-Boot-Users] [PATCH 2/5] 4xx: update esd's common auto_update
	code for 405 boards
In-Reply-To: <200804211442.06377.matthias.fuchs@esd-electronics.com>
References: <200804211442.06377.matthias.fuchs@esd-electronics.com>
Message-ID: <200804221351.43815.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> - Coding style cleanup (long lines)
> - improve handling of protected flash regions
> - remove dead code
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 22 13:52:51 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 13:52:51 +0200
Subject: [U-Boot-Users] [PATCH 4/5] 4xx: Update APC405 configuration
In-Reply-To: <200804211442.18126.matthias.fuchs@esd-electronics.com>
References: <200804211442.18126.matthias.fuchs@esd-electronics.com>
Message-ID: <200804221352.51503.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> - enable esd's auto_update mechanism
> - support alternative flash layout on rev. 1.8 boards
> - update default environment
> - use common CFI flash driver
> - coding style cleanup
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 22 13:53:12 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 13:53:12 +0200
Subject: [U-Boot-Users] [PATCH 5/5] 4xx: Remove unused APC405
	strataflash driver
In-Reply-To: <200804211442.22060.matthias.fuchs@esd-electronics.com>
References: <200804211442.22060.matthias.fuchs@esd-electronics.com>
Message-ID: <200804221353.12489.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> The APC405 board support has been migrated to use the common
> CFI flash driver.
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 22 13:53:31 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 13:53:31 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update CPU strapping for PMC440
	boards
In-Reply-To: <200804211801.07215.matthias.fuchs@esd-electronics.com>
References: <200804211801.07215.matthias.fuchs@esd-electronics.com>
Message-ID: <200804221353.31979.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> This patch removes the temporary 'test' strapping option
> of the sbe command. The '667' strapping option now uses
> a PLB/PCI divider of 3.
>
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From pierre.savary at kerlink.fr  Tue Apr 22 13:55:09 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Tue, 22 Apr 2008 13:55:09 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <2acbd3e40804151225y356cac7eh73887a55f9e268c9@mail.gmail.com>
References: <20080411174827.105e31ef@mjolnir.drzeus.cx>	<AA28F077645B324881335614E4F7C428034CB5@win-ex01.bench.com>	<20080412112810.5b874157@mjolnir.drzeus.cx>	<-6021840981243159212@unknownmsgid>
	<2acbd3e40804151225y356cac7eh73887a55f9e268c9@mail.gmail.com>
Message-ID: <001a01c8a46f$b85e1dc0$291a5940$@savary@kerlink.fr>

Hi Andy,
Where could we find the driver that works with MMCv4 on at91sam9x?
Best regards

Pierre


-----Message d'origine-----
De?: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] De la part de Andy
Fleming
Envoy??: mardi 15 avril 2008 21:25
??: Pierre Savary
Cc?: u-boot-users at lists.sourceforge.net; drzeus-mmc at drzeus.cx
Objet?: Re: [U-Boot-Users] drivers MMCplus for at91sam9x

On Tue, Apr 15, 2008 at 5:18 AM, Pierre Savary <pierre.savary at kerlink.fr>
wrote:
> Then my MMC 4GB works with my Linux kernel but if I can't load my kernel
>  (located on the first part of this MMC) ... it's not really interesting
:(
>
>  So, somebody does already use MMC v4 with U-boot???

I've got one that works.  However, I don't have a 4GB MMC card with
v4.  I thought I did, but it turned out the card just takes advantage
of the fact that older versions can address 4GB, even though the spec
says 2GB is the max.

However, I'm fairly confident in the code (it's been tested in
simulated environments, and reflects what the Linux code does).  I'm
currently working on bringing it forward to the top of tree (I started
it before drivers/ got rearranged).  I'm actually hoping to generalize
it some so we can share it between all MMC/SD users.

Andy

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users




From David.Saada at ecitele.com  Tue Apr 22 14:05:10 2008
From: David.Saada at ecitele.com (David Saada)
Date: Tue, 22 Apr 2008 15:05:10 +0300
Subject: [U-Boot-Users] Programming ethernet PHY by SPI on MPC8360E-RDK
In-Reply-To: <008f01c8a3dd$3f6fa380$9801a8c0@prismusa.com>
References: <006901c8a0c6$1bd48360$9801a8c0@prismusa.com>
	<3026DA9FE767E2418FA2C568FE4F5CB16B10B8A5AE@ILPTMAIL02.ecitele.com>,
	<008f01c8a3dd$3f6fa380$9801a8c0@prismusa.com>
Message-ID: <3026DA9FE767E2418FA2C568FE4F5CB16B10B8A5AF@ILPTMAIL02.ecitele.com>


> I have been scouring the code (u-boot) to see evidence of using SPI to
> configure the ethernet PHY. I do not find anything that is obvious. The
> board uses BMC54XX ethernet transciever. I will appreciate any insight from
> you .

> I was able to locate and use QE configuration of IO pins. Many thanks.

> Sampath


Sorry, can't help you here.
Maybe somoene from the u-boot list has better knowledge of this?



From sr at denx.de  Tue Apr 22 14:14:59 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 14:14:59 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Canyonlands and Glacier default
	environment for fdt usage
Message-ID: <1208866499-19334-1-git-send-email-sr@denx.de>

This patch fixes the Canyonlands and Glacier default environment to better
fit to the arch/powerpc device-tree kernels. The variables dealing with
arch/ppc booting are removed, since these boards are supported only in
arch/powerpc. Glacier uses the same config file as Canyonlands.

Also, the Glacier now uses non-FPU rootpath, since 460GT has no FPU.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 include/configs/canyonlands.h |   23 +++++++++++++----------
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
index e7896aa..3dd577a 100644
--- a/include/configs/canyonlands.h
+++ b/include/configs/canyonlands.h
@@ -319,15 +319,18 @@
 #define CONFIG_HOSTNAME		canyonlands
 #define CFG_BOOTFILE		"bootfile=canyonlands/uImage\0"
 #define CFG_DTBFILE		"fdt_file=canyonlands/canyonlands.dtb\0"
+#define CFG_ROOTPATH		"rootpath=/opt/eldk/ppc_4xxFP\0"
 #else
 #define CONFIG_HOSTNAME		glacier
 #define CFG_BOOTFILE		"bootfile=glacier/uImage\0"
 #define CFG_DTBFILE		"fdt_file=glacier/glacier.dtb\0"
+#define CFG_ROOTPATH		"rootpath=/opt/eldk/ppc_4xx\0"
 #endif
 
 #define	CONFIG_EXTRA_ENV_SETTINGS					\
 	CFG_BOOTFILE							\
 	CFG_DTBFILE							\
+	CFG_ROOTPATH							\
 	"netdev=eth0\0"							\
 	"nfsargs=setenv bootargs root=/dev/nfs rw "			\
 		"nfsroot=${serverip}:${rootpath}\0"			\
@@ -336,18 +339,18 @@
 		"ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}"	\
 		":${hostname}:${netdev}:off panic=1\0"			\
 	"addtty=setenv bootargs ${bootargs} console=ttyS0,${baudrate}\0"\
-	"net_nfs=tftp 400000 ${bootfile};"				\
-		"tftp ${fdt_addr} ${fdt_file};"				\
-		"run nfsargs addip addtty;"				\
-		"bootm 400000 - ${fdt_addr}\0"				\
-	"net_nfs_fdt=net_nfs\0"						\
-	"flash_nfs=run nfsargs addip addtty;"				\
-		"bootm ${kernel_addr}\0"				\
 	"flash_self=run ramargs addip addtty;"				\
-		"bootm ${kernel_addr} ${ramdisk_addr}\0"		\
-	"rootpath=/opt/eldk/ppc_4xxFP\0"				\
-	"fdt_addr=800000\0"						\
+		"bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr}\0"	\
+	"flash_nfs=run nfsargs addip addtty;"				\
+		"bootm ${kernel_addr} - ${fdt_addr}\0"			\
+	"net_nfs=tftp ${kernel_addr_r} ${bootfile}; "			\
+		"tftp ${fdt_addr_r} ${fdt_file}; "			\
+		"run nfsargs addip addtty;"				\
+		"bootm ${kernel_addr_r} - ${fdt_addr_r}\0"		\
+	"kernel_addr_r=400000\0"					\
+	"fdt_addr_r=800000\0"						\
 	"kernel_addr=fc000000\0"					\
+	"fdt_addr=fc1e0000\0"						\
 	"ramdisk_addr=fc200000\0"					\
 	"initrd_high=30000000\0"					\
 	"load=tftp 200000 ${hostname}/u-boot.bin\0"			\
-- 
1.5.5.1




From sew_s at tqs.de  Tue Apr 22 14:18:33 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Tue, 22 Apr 2008 14:18:33 +0200
Subject: [U-Boot-Users] Question about smc911x driver (16/32 Bit support)
Message-ID: <480DD799.50402@tqs.de>

Hi,

in the source code there is a preprocessor directive
#error "SMC911X: Only 32-bit bus is supported".

We use a LAN9215i, which has a 16 Bit data interface only, connected to 
an i.MX31.

The LAN9215 is in the driver's ID list.

According to the data sheet accesses have to be 2x16 Bit to build the 
device's internal 32 Bit format.

What does this non-32-Bit exclusion exactly mean?
Will the driver work on our HW configuration?

Confused,
Jens



From jamie at shareable.org  Tue Apr 22 14:30:56 2008
From: jamie at shareable.org (Jamie Lokier)
Date: Tue, 22 Apr 2008 13:30:56 +0100
Subject: [U-Boot-Users] ubi and u-boot
In-Reply-To: <1208785463.6654.34.camel@vader.jdub.homelinux.org>
References: <20080420222237.4AE5324657@gemini.denx.de>
	<1208779508.5965.371.camel@sauron>
	<Pine.LNX.4.64.0804211533140.27984@lnxricardw.se.axis.com>
	<1208785463.6654.34.camel@vader.jdub.homelinux.org>
Message-ID: <20080422123054.GA4849@shareable.org>

Josh Boyer wrote:
> > I was under the impression from past emails on the MTD list that the 
> > internal meta format for UBI has changed a few times over its lifetime.
> > 
> > Assuming this continues, I would think this would cause problems for 
> > bootloaders such as U-Boot whose flash partitions are not necessarily 
> > rewritten in the case of a product upgrade - i.e. a firmware upgrade with 
> > a new kernel would have a new UBI implementation and spec causing an
> > older bootloader to fail to operate properly with the newer image.
> 
> I think there was only 1 time the on-flash format changed, and that was
> before UBI was merged upstream.  New features can be introduced with
> additional flags, however older versions should be able to ignore those.

Quite.  As long as the format is changed in an upward compatible way,
it should be fine.  Hopefully the existing format is designed to
ensure that's always possible - at least for everything called 'UBI 1'
since the upstream merge.

-- Jamie



From skuribay at ruby.dti.ne.jp  Tue Apr 22 15:47:27 2008
From: skuribay at ruby.dti.ne.jp (Shinya Kuribayashi)
Date: Tue, 22 Apr 2008 22:47:27 +0900
Subject: [U-Boot-Users] [MIPS] doc/README.mips: Add MIPS notes
Message-ID: <480DEC6F.9040508@ruby.dti.ne.jp>

This is for 1.3.3 release. Please review.

Thanks,

  Shinya

================================>
Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
---

 doc/README.mips |   58 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 58 insertions(+), 0 deletions(-)
 create mode 100644 doc/README.mips


diff --git a/doc/README.mips b/doc/README.mips
new file mode 100644
index 0000000..a5fcae9
--- /dev/null
+++ b/doc/README.mips
@@ -0,0 +1,58 @@
+
+Notes for the MIPS architecture port of U-Boot
+
+Toolchains
+----------
+
+  http://www.denx.de/wiki/DULG/ELDK
+  ELDK < DULG < DENX
+
+  http://www.emdebian.org/crosstools.html
+  Embedded Debian -- Cross-development toolchains
+
+  http://buildroot.uclibc.org/
+  Buildroot
+
+Known Issues
+------------
+
+  * Little endian build problem
+
+    If use non-ELDK toolchains, -EB will be set to CPPFLAGS. Therefore all
+    objects will be generated in big-endian format.
+
+  * Cache incoherency issue caused by do_bootelf_exec() at cmd_elf.c
+
+    Cache will be disabled before entering the loaded ELF image without
+    writing back and invalidating cache lines. This leads to cache
+    incoherency in most cases, unless the code gets loaded after U-Boot
+    re-initializes the cache. The more common uImage 'bootm' command does
+    not suffer this problem.
+
+    [workaround] To avoid this cache incoherency,
+    1) insert flush_cache(all) before calling dcache_disable(), or
+    2) fix dcache_disable() to do both flushing and disabling cache.
+
+  * Note that Linux users need to kill dcache_disable() in do_bootelf_exec()
+    or override do_bootelf_exec() not to disable I-/D-caches, because most
+    Linux/MIPS ports don't re-enable caches after entering kernel_entry.
+
+TODOs
+-----
+
+  * Probe CPU types, I-/D-cache and TLB size etc. automatically
+
+  * Secondary cache support missing
+
+  * Centralize the link directive files
+
+  * Initialize TLB entries redardless of their use
+
+  * R2000/R3000 class parts are not supported
+
+  * Limited testing across different MIPS variants
+
+  * Due to cache initialization issues, the DRAM on board must be
+    initialized in board specific assembler language before the cache init
+    code is run -- that is, initialize the DRAM in lowlevel_init().
+



From sr at denx.de  Tue Apr 22 15:51:06 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 22 Apr 2008 15:51:06 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: <200804181702.21886.sr@denx.de>
References: <20070423123237.295A13535D2@atlas.denx.de>
	<200804111649.37273.sr@denx.de> <200804181702.21886.sr@denx.de>
Message-ID: <200804221551.06813.sr@denx.de>

The following changes since commit 5e3dca577b7c1bf58bd2b48449b18b7e7dcd8e04:
  Anatolij Gustschin (1):
        Fix crash on sequoia in ppc_4xx_eth_init

are available in the git repository at:

  git://www.denx.de/git/u-boot-ppc4xx.git master

Matthias Fuchs (9):
      ppc4xx: Fix sys_get_info() for 405GP(r)
      ppc4xx: Update bootlogo for APC405 boards
      ppc4xx: Update FPGA image for APC405 boards
      ppc4xx: Update esd's common LCD code for 405 boards
      ppc4xx: update esd's common auto_update code for 405 boards
      ppc4xx: Update APC405 board support
      ppc4xx: Update APC405 configuration
      ppc4xx: Remove unused APC405 strataflash driver
      ppc4xx: Update CPU strapping for PMC440 boards

Stefan Roese (6):
      ppc4xx: Add Glacier NAND booting target
      ppc4xx: Adjust Canyonlands fixed DDR2 setup (NAND booting) to 512MB SODIMM
      ppc4xx: Change Canyonlands to support booting from 2k page NAND devices
      ppc4xx: Add dcache_enable() for 440
      ppc4xx: Small coding style cleanup for the latest esd patches
      ppc4xx: Fix Canyonlands and Glacier default environment for fdt usage

 Makefile                                     |    5 +-
 board/amcc/canyonlands/bootstrap.c           |   13 +
 board/amcc/canyonlands/init.S                |    1 +
 board/amcc/canyonlands/u-boot-nand.lds       |    4 +-
 board/esd/apc405/Makefile                    |    4 +-
 board/esd/apc405/apc405.c                    |  360 ++-
 board/esd/apc405/fpgadata.c                  | 4284 ++++++++++++--------------
 board/esd/apc405/logo_640_480_24bpp.c        |  800 ++++--
 board/esd/apc405/strataflash.c               |  789 -----
 board/esd/common/auto_update.c               |  208 +-
 board/esd/common/auto_update.h               |   15 +-
 board/esd/common/lcd.c                       |  123 +-
 board/esd/common/s1d13505_640_480_16bpp.h    |   65 +
 board/esd/pmc440/cmd_pmc440.c                |   13 +-
 cpu/ppc4xx/cache.S                           |    2 +
 cpu/ppc4xx/speed.c                           |    2 +
 include/configs/APC405.h                     |  346 ++-
 include/configs/canyonlands.h                |   49 +-
 nand_spl/board/amcc/canyonlands/config.mk    |    6 +-
 nand_spl/board/amcc/canyonlands/ddr2_fixed.c |    8 +-
 20 files changed, 3320 insertions(+), 3777 deletions(-)
 delete mode 100644 board/esd/apc405/strataflash.c
 create mode 100644 board/esd/common/s1d13505_640_480_16bpp.h



From wd at denx.de  Tue Apr 22 16:24:42 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:42 +0200
Subject: [U-Boot-Users] [PATCH] Enable CODEC POST with CFG_POST_CODEC rather
	than with CFG_POST_DSP.
Message-ID: <1208874293-2123-1-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at pollux.denx.de>

Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
---
 post/tests.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/post/tests.c b/post/tests.c
index 698f85c..ed4ef2b 100644
--- a/post/tests.c
+++ b/post/tests.c
@@ -225,7 +225,7 @@ struct post_test post_list[] =
 	CFG_POST_DSP
     },
 #endif
-#if CONFIG_POST & CFG_POST_DSP
+#if CONFIG_POST & CFG_POST_CODEC
     {
 	"CODEC test",
 	"codec",
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:44 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:44 +0200
Subject: [U-Boot-Users] [PATCH] The patch introduces the CRITICAL feature of
	POST tests. If the test
In-Reply-To: <1208874293-2123-2-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-3-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at pollux.denx.de>

Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 common/main.c                        |    8 +++++++-
 include/asm-arm/global_data.h        |    1 +
 include/asm-avr32/global_data.h      |    1 +
 include/asm-blackfin/global_data.h   |    1 +
 include/asm-i386/global_data.h       |    1 +
 include/asm-m68k/global_data.h       |    1 +
 include/asm-microblaze/global_data.h |    1 +
 include/asm-mips/global_data.h       |    1 +
 include/asm-nios/global_data.h       |    1 +
 include/asm-nios2/global_data.h      |    1 +
 include/asm-ppc/global_data.h        |    1 +
 include/asm-sh/global_data.h         |    1 +
 include/post.h                       |    4 ++++
 post/post.c                          |   18 +++++++++++++++---
 14 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/common/main.c b/common/main.c
index 163ba02..21e7afa 100644
--- a/common/main.c
+++ b/common/main.c
@@ -40,7 +40,7 @@
 
 #include <post.h>
 
-#ifdef CONFIG_SILENT_CONSOLE
+#if defined(CONFIG_SILENT_CONSOLE) || defined(CONFIG_POST)
 DECLARE_GLOBAL_DATA_PTR;
 #endif
 
@@ -369,6 +369,12 @@ void main_loop (void)
 	init_cmd_timeout ();
 # endif	/* CONFIG_BOOT_RETRY_TIME */
 
+#ifdef CONFIG_POST
+	if (gd->flags & GD_FLG_POSTFAIL) {
+		s = getenv("failbootcmd");
+	}
+	else
+#endif /* CONFIG_POST */
 #ifdef CONFIG_BOOTCOUNT_LIMIT
 	if (bootlimit && (bootcount > bootlimit)) {
 		printf ("Warning: Bootlimit (%u) exceeded. Using altbootcmd.\n",
diff --git a/include/asm-arm/global_data.h b/include/asm-arm/global_data.h
index c2d5291..0410b5e 100644
--- a/include/asm-arm/global_data.h
+++ b/include/asm-arm/global_data.h
@@ -60,6 +60,7 @@ typedef	struct	global_data {
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM		*/
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized	*/
 #define	GD_FLG_SILENT	0x00004		/* Silent mode				*/
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed		*/
 
 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r8")
 
diff --git a/include/asm-avr32/global_data.h b/include/asm-avr32/global_data.h
index 681c514..daf64bc 100644
--- a/include/asm-avr32/global_data.h
+++ b/include/asm-avr32/global_data.h
@@ -51,6 +51,7 @@ typedef	struct	global_data {
 #define GD_FLG_RELOC	0x00001		/* Code was relocated to RAM	 */
 #define GD_FLG_DEVINIT	0x00002		/* Devices have been initialized */
 #define GD_FLG_SILENT	0x00004		/* Silent mode			 */
+#define GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed	 */
 
 #define DECLARE_GLOBAL_DATA_PTR register gd_t *gd asm("r5")
 
diff --git a/include/asm-blackfin/global_data.h b/include/asm-blackfin/global_data.h
index cb0dfc2..6debfc7 100644
--- a/include/asm-blackfin/global_data.h
+++ b/include/asm-blackfin/global_data.h
@@ -61,6 +61,7 @@ typedef struct global_data {
 #define	GD_FLG_RELOC	0x00001	/* Code was relocated to RAM     */
 #define	GD_FLG_DEVINIT	0x00002	/* Devices have been initialized */
 #define	GD_FLG_SILENT	0x00004	/* Silent mode                   */
+#define	GD_FLG_POSTFAIL	0x00008	/* Critical POST test failed     */
 
 #define DECLARE_GLOBAL_DATA_PTR     register gd_t * volatile gd asm ("P5")
 
diff --git a/include/asm-i386/global_data.h b/include/asm-i386/global_data.h
index 1d309d5..68a9ad6 100644
--- a/include/asm-i386/global_data.h
+++ b/include/asm-i386/global_data.h
@@ -54,6 +54,7 @@ typedef	struct {
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM		*/
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized	*/
 #define	GD_FLG_SILENT	0x00004		/* Silent mode				*/
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed		*/
 
 extern gd_t *global_data;
 
diff --git a/include/asm-m68k/global_data.h b/include/asm-m68k/global_data.h
index 1e26eb0..958736e 100644
--- a/include/asm-m68k/global_data.h
+++ b/include/asm-m68k/global_data.h
@@ -68,6 +68,7 @@ typedef	struct	global_data {
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM		*/
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized	*/
 #define	GD_FLG_SILENT	0x00004		/* Silent mode				*/
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed		*/
 
 #if 0
 extern gd_t *global_data;
diff --git a/include/asm-microblaze/global_data.h b/include/asm-microblaze/global_data.h
index a6e7834..91243b2 100644
--- a/include/asm-microblaze/global_data.h
+++ b/include/asm-microblaze/global_data.h
@@ -52,6 +52,7 @@ typedef	struct	global_data {
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM		*/
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized	*/
 #define	GD_FLG_SILENT	0x00004		/* Silent mode				*/
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed		*/
 
 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r31")
 
diff --git a/include/asm-mips/global_data.h b/include/asm-mips/global_data.h
index a024194..bd9e4dd 100644
--- a/include/asm-mips/global_data.h
+++ b/include/asm-mips/global_data.h
@@ -54,6 +54,7 @@ typedef	struct	global_data {
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM     */
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized */
 #define	GD_FLG_SILENT	0x00004		/* Silent mode			 */
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed	 */
 
 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("k0")
 
diff --git a/include/asm-nios/global_data.h b/include/asm-nios/global_data.h
index fd11389..ddd66cf 100644
--- a/include/asm-nios/global_data.h
+++ b/include/asm-nios/global_data.h
@@ -45,6 +45,7 @@ typedef	struct	global_data {
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM		*/
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized	*/
 #define	GD_FLG_SILENT	0x00004		/* Silent mode				*/
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed		*/
 
 #define DECLARE_GLOBAL_DATA_PTR     register gd_t *gd asm ("%g7")
 
diff --git a/include/asm-nios2/global_data.h b/include/asm-nios2/global_data.h
index a1ac288..ae5f617 100644
--- a/include/asm-nios2/global_data.h
+++ b/include/asm-nios2/global_data.h
@@ -44,6 +44,7 @@ typedef	struct	global_data {
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM		*/
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized	*/
 #define	GD_FLG_SILENT	0x00004		/* Silent mode				*/
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed		*/
 
 #define DECLARE_GLOBAL_DATA_PTR     register gd_t *gd asm ("r15")
 
diff --git a/include/asm-ppc/global_data.h b/include/asm-ppc/global_data.h
index 205f7ed..e07092b 100644
--- a/include/asm-ppc/global_data.h
+++ b/include/asm-ppc/global_data.h
@@ -164,6 +164,7 @@ typedef	struct	global_data {
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM		*/
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized	*/
 #define	GD_FLG_SILENT	0x00004		/* Silent mode				*/
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed		*/
 
 #if 1
 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm ("r2")
diff --git a/include/asm-sh/global_data.h b/include/asm-sh/global_data.h
index 0a44a34..521a66f 100644
--- a/include/asm-sh/global_data.h
+++ b/include/asm-sh/global_data.h
@@ -44,6 +44,7 @@ typedef	struct global_data
 #define	GD_FLG_RELOC	0x00001		/* Code was relocated to RAM		*/
 #define	GD_FLG_DEVINIT	0x00002		/* Devices have been initialized	*/
 #define	GD_FLG_SILENT	0x00004		/* Silent mode				*/
+#define	GD_FLG_POSTFAIL	0x00008		/* Critical POST test failed		*/
 
 #define DECLARE_GLOBAL_DATA_PTR	register gd_t *gd asm ("r13")
 
diff --git a/include/post.h b/include/post.h
index 12c0e92..ee07d2c 100644
--- a/include/post.h
+++ b/include/post.h
@@ -42,12 +42,16 @@
 #define POST_REBOOT		0x0800	/* test may cause rebooting */
 #define POST_PREREL             0x1000  /* test runs before relocation */
 
+#define POST_CRITICAL		0x2000	/* Use failbootcmd if test failed */
+
 #define POST_MEM		(POST_RAM | POST_ROM)
 #define POST_ALWAYS		(POST_NORMAL	| \
 				 POST_SLOWTEST	| \
 				 POST_MANUAL	| \
 				 POST_POWERON	)
 
+#define POST_FAIL_SAVE		0x80
+
 #ifndef	__ASSEMBLY__
 
 struct post_test {
diff --git a/post/post.c b/post/post.c
index 4ff75ee..1df0657 100644
--- a/post/post.c
+++ b/post/post.c
@@ -157,8 +157,10 @@ static void post_bootmode_test_off (void)
 
 static void post_get_flags (int *test_flags)
 {
-	int  flag[] = {  POST_POWERON,   POST_NORMAL,   POST_SLOWTEST };
-	char *var[] = { "post_poweron", "post_normal", "post_slowtest" };
+	int  flag[] = {  POST_POWERON,   POST_NORMAL,   POST_SLOWTEST,
+			 POST_CRITICAL };
+	char *var[] = { "post_poweron", "post_normal", "post_slowtest",
+			"post_critical" };
 	int varnum = sizeof (var) / sizeof (var[0]);
 	char list[128];			/* long enough for POST list */
 	char *name;
@@ -224,7 +226,9 @@ static int post_run_single (struct post_test *test,
 
 		if (!(flags & POST_REBOOT)) {
 			if ((test_flags & POST_REBOOT) && !(flags & POST_MANUAL)) {
-				post_bootmode_test_on (i);
+				post_bootmode_test_on (
+					(gd->flags & GD_FLG_POSTFAIL) ?
+						POST_FAIL_SAVE | i : i);
 			}
 
 			if (test_flags & POST_PREREL)
@@ -236,10 +240,14 @@ static int post_run_single (struct post_test *test,
 		if (test_flags & POST_PREREL) {
 			if ((*test->test) (flags) == 0)
 				post_log_mark_succ ( test->testid );
+			else if (test_flags & POST_CRITICAL)
+				gd->flags |= GD_FLG_POSTFAIL;
 		} else {
 		if ((*test->test) (flags) != 0) {
 			post_log ("FAILED\n");
 			show_boot_progress (-32);
+			if (test_flags & POST_CRITICAL)
+				gd->flags |= GD_FLG_POSTFAIL;
 		}
 		else
 			post_log ("PASSED\n");
@@ -266,6 +274,10 @@ int post_run (char *name, int flags)
 		unsigned int last;
 
 		if (post_bootmode_get (&last) & POST_POWERTEST) {
+			if (last & POST_FAIL_SAVE) {
+				last &= ~POST_FAIL_SAVE;
+				gd->flags |= GD_FLG_POSTFAIL;
+			}
 			if (last < post_list_size &&
 				(flags & test_flags[last] & POST_ALWAYS) &&
 				(flags & test_flags[last] & POST_MEM)) {
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:46 +0200
Subject: [U-Boot-Users] [PATCH] Add support for the lwmon5 board reset via
	GPIO58.
In-Reply-To: <1208874293-2123-4-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-5-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at pollux.denx.de>

Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 board/lwmon5/lwmon5.c    |    5 +++++
 include/configs/lwmon5.h |    2 ++
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/board/lwmon5/lwmon5.c b/board/lwmon5/lwmon5.c
index 73d5de5..7c5f6cc 100644
--- a/board/lwmon5/lwmon5.c
+++ b/board/lwmon5/lwmon5.c
@@ -594,3 +594,8 @@ void video_get_info_str (int line_number, char *info)
 }
 #endif
 #endif /* CONFIG_VIDEO */
+
+void board_reset(void)
+{
+	gpio_write_bit(CFG_GPIO_BOARD_RESET, 1);
+}
diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
index 6489e0e..e179e4f 100644
--- a/include/configs/lwmon5.h
+++ b/include/configs/lwmon5.h
@@ -36,6 +36,7 @@
 #define CONFIG_BOARD_EARLY_INIT_F 1	/* Call board_early_init_f	*/
 #define CONFIG_BOARD_POSTCLK_INIT 1	/* Call board_postclk_init	*/
 #define CONFIG_MISC_INIT_R	1	/* Call misc_init_r		*/
+#define CONFIG_BOARD_RESET	1	/* Call board_reset		*/
 
 /*-----------------------------------------------------------------------
  * Base addresses -- Note these are effective addresses where the
@@ -516,6 +517,7 @@
 #define CFG_GPIO_EEPROM_EXT_WP	55
 #define CFG_GPIO_HIGHSIDE	56
 #define CFG_GPIO_EEPROM_INT_WP	57
+#define CFG_GPIO_BOARD_RESET	58
 #define CFG_GPIO_LIME_S		59
 #define CFG_GPIO_LIME_RST	60
 #define CFG_GPIO_SYSMON_STATUS	62
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:47 +0200
Subject: [U-Boot-Users] [PATCH] The patch introduces the alternative
	configuration of the log buffer for
In-Reply-To: <1208874293-2123-5-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
	<1208874293-2123-5-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-6-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at pollux.denx.de>

 To enable this, alternative, configuration the U-Boot board configuration
file for lwmon5 includes the definitions of alternative addresses for header
(CONFIG_ALT_LH_ADDR) and buffer (CONFIG_ALT_LB_ADDR).

 The Linux shall be configured with the CONFIG_ALT_LB_LOCATION option set,
and has the BOARD_ALT_LH_ADDR and BOARD_ALT_LB_ADDR constants defined in the
lwmon5 board-specific header (arch/ppc/platforms/4xx/lwmon5.h).

Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 common/cmd_bootm.c       |    4 ++++
 common/cmd_log.c         |   38 ++++++++++++++++++++++++++++++++------
 include/configs/lwmon5.h |    2 ++
 include/ppc440.h         |    2 ++
 lib_ppc/board.c          |    4 ++++
 5 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 9546729..9deb781 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -545,11 +545,15 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int flag,
 	}
 
 #ifdef CONFIG_LOGBUFFER
+#ifndef CONFIG_ALT_LB_ADDR
 	kbd=gd->bd;
 	/* Prevent initrd from overwriting logbuffer */
 	if (initrd_high < (kbd->bi_memsize-LOGBUFF_LEN-LOGBUFF_OVERHEAD))
 		initrd_high = kbd->bi_memsize-LOGBUFF_LEN-LOGBUFF_OVERHEAD;
 	debug ("## Logbuffer at 0x%08lX ", kbd->bi_memsize-LOGBUFF_LEN);
+#else
+	debug ("## Logbuffer at 0x%08lX ", CONFIG_ALT_LB_ADDR);
+#endif
 #endif
 
 	/*
diff --git a/common/cmd_log.c b/common/cmd_log.c
index e593dbe..34b36ff 100644
--- a/common/cmd_log.c
+++ b/common/cmd_log.c
@@ -59,14 +59,25 @@ static char buf[1024];
 static unsigned console_loglevel = 3;
 static unsigned default_message_loglevel = 4;
 static unsigned log_version = 1;
+#ifdef CONFIG_ALT_LB_ADDR
+static volatile logbuff_t *log;
+#else
 static logbuff_t *log;
+#endif
+static char *lbuf;
 
 void logbuff_init_ptrs (void)
 {
 	unsigned long tag, post_word;
 	char *s;
 
+#ifdef CONFIG_ALT_LB_ADDR
+	log = (logbuff_t *)CONFIG_ALT_LH_ADDR;
+	lbuf = (char *)CONFIG_ALT_LB_ADDR;
+#else
 	log = (logbuff_t *)(gd->bd->bi_memsize-LOGBUFF_LEN) - 1;
+	lbuf = log->buf;
+#endif
 
 	/* Set up log version */
 	if ((s = getenv ("logversion")) != NULL)
@@ -101,11 +112,26 @@ void logbuff_init_ptrs (void)
 
 void logbuff_reset (void)
 {
+#ifndef CONFIG_ALT_LB_ADDR
 	memset (log, 0, sizeof (logbuff_t));
-	if (log_version == 2)
+#endif
+	if (log_version == 2) {
 		log->v2.tag = LOGBUFF_MAGIC;
-	else
+#ifdef CONFIG_ALT_LB_ADDR
+		log->v2.start = 0;
+		log->v2.con = 0;
+		log->v2.end = 0;
+		log->v2.chars = 0;
+#endif
+	} else {
 		log->v1.tag = LOGBUFF_MAGIC;
+#ifdef CONFIG_ALT_LB_ADDR
+		log->v1.dummy = 0;
+		log->v1.start = 0;
+		log->v1.size = 0;
+		log->v1.chars = 0;
+#endif
+	}
 }
 
 int drv_logbuff_init (void)
@@ -188,7 +214,7 @@ int do_log (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 				size = log->v1.size;
 			}
 			for (i=0; i < (size&LOGBUFF_MASK); i++) {
-				s = (char *)log->buf+((start+i)&LOGBUFF_MASK);
+				s = lbuf+((start+i)&LOGBUFF_MASK);
 				putc (*s);
 			}
 			return 0;
@@ -196,7 +222,7 @@ int do_log (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 			logbuff_reset ();
 			return 0;
 		} else if (strcmp(argv[1],"info") == 0) {
-			printf ("Logbuffer   at  %08lx\n", (unsigned long)log->buf);
+			printf ("Logbuffer   at  %08lx\n", (unsigned long)lbuf);
 			if (log_version == 2) {
 				printf ("log_start    =  %08lx\n", log->v2.start);
 				printf ("log_end      =  %08lx\n", log->v2.end);
@@ -257,14 +283,14 @@ static int logbuff_printk(const char *line)
 		line_feed = 0;
 		for (; p < buf_end; p++) {
 			if (log_version == 2) {
-				log->buf[log->v2.end & LOGBUFF_MASK] = *p;
+				lbuf[log->v2.end & LOGBUFF_MASK] = *p;
 				log->v2.end++;
 				if (log->v2.end - log->v2.start > LOGBUFF_LEN)
 					log->v2.start++;
 				log->v2.chars++;
 			}
 			else {
-				log->buf[(log->v1.start + log->v1.size) &
+				lbuf[(log->v1.start + log->v1.size) &
 					 LOGBUFF_MASK] = *p;
 				if (log->v1.size < LOGBUFF_LEN)
 					log->v1.size++;
diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
index e179e4f..ced7ba6 100644
--- a/include/configs/lwmon5.h
+++ b/include/configs/lwmon5.h
@@ -244,6 +244,8 @@
 
 #define CFG_POST_CACHE_ADDR	0x7fff0000 /* free virtual address	*/
 #define CONFIG_LOGBUFFER
+#define CONFIG_ALT_LH_ADDR	(CFG_PERIPHERAL_BASE + GPT0_COMP1)
+#define CONFIG_ALT_LB_ADDR	(CFG_OCM_BASE)
 #define CFG_CONSOLE_IS_IN_ENV /* Otherwise it catches logbuffer as output */
 
 /*-----------------------------------------------------------------------
diff --git a/include/ppc440.h b/include/ppc440.h
index 6e3b68d..10517cb 100644
--- a/include/ppc440.h
+++ b/include/ppc440.h
@@ -1434,6 +1434,8 @@
 #define GPT0_COMP5			0x00000094
 #define GPT0_COMP4			0x00000090
 #define GPT0_COMP3			0x0000008C
+#define GPT0_COMP2			0x00000088
+#define GPT0_COMP1			0x00000084
 
 #if defined(CONFIG_440EPX) || defined(CONFIG_440GRX)
 #define SDR0_USB2D0CR                 0x0320
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index fbf1c5d..ee0213e 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -436,10 +436,12 @@ void board_init_f (ulong bootflag)
 	addr = CFG_SDRAM_BASE + get_effective_memsize();
 
 #ifdef CONFIG_LOGBUFFER
+#ifndef CONFIG_ALT_LB_ADDR
 	/* reserve kernel log buffer */
 	addr -= (LOGBUFF_RESERVE);
 	debug ("Reserving %dk for kernel logbuffer at %08lx\n", LOGBUFF_LEN, addr);
 #endif
+#endif
 
 #ifdef CONFIG_PRAM
 	/*
@@ -1126,9 +1128,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
 		pram=0;
 #endif
 #ifdef CONFIG_LOGBUFFER
+#ifndef CONFIG_ALT_LB_ADDR
 		/* Also take the logbuffer into account (pram is in kB) */
 		pram += (LOGBUFF_LEN+LOGBUFF_OVERHEAD)/1024;
 #endif
+#endif
 		sprintf ((char *)memsz, "%ldk", (bd->bi_memsize / 1024) - pram);
 		setenv ("mem", (char *)memsz);
 	}
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:45 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:45 +0200
Subject: [U-Boot-Users] [PATCH] Some fixes to dspic, fpga,
	and gdc post tests for lwmon5.
In-Reply-To: <1208874293-2123-3-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-4-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at pollux.denx.de>

Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 post/board/lwmon5/dspic.c |    2 +-
 post/board/lwmon5/fpga.c  |    4 ++++
 post/board/lwmon5/gdc.c   |    2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/post/board/lwmon5/dspic.c b/post/board/lwmon5/dspic.c
index e8fed89..f1c9c15 100644
--- a/post/board/lwmon5/dspic.c
+++ b/post/board/lwmon5/dspic.c
@@ -94,9 +94,9 @@ int dspic_post_test(int flags)
 	}
 
 	data = dspic_read(DSPIC_SYS_ERROR_REG);
-	if (data != 0) ret = 1;
 	if (data == -1) {
 		post_log("dsPIC : failed read system error\n");
+		ret = 1;
 	} else {
 		post_log("dsPIC SYS-ERROR code: 0x%04X\n", data);
 	}
diff --git a/post/board/lwmon5/fpga.c b/post/board/lwmon5/fpga.c
index 4e3f1d5..b87fc52 100644
--- a/post/board/lwmon5/fpga.c
+++ b/post/board/lwmon5/fpga.c
@@ -39,6 +39,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define FPGA_VERSION_REG	0xC4000040
 #define FPGA_RAM_START		0xC4200000
 #define FPGA_RAM_END		0xC4203FFF
+#define FPGA_STAT		0xC400000C
 
 #define FPGA_PWM_CTRL_REG	0xC4000020
 #define FPGA_PWM_TV_REG		0xC4000024
@@ -93,6 +94,9 @@ int fpga_post_test(int flags)
 	post_log("FPGA : version %u.%u\n",
 		(version >> 8) & 0xFF, version & 0xFF);
 
+	/* Enable write to FPGA RAM */
+	out_be32((void *)FPGA_STAT, in_be32((void *)FPGA_STAT) | 0x1000);
+
 	read_value = get_ram_size((void *)CFG_FPGA_BASE_1, 0x4000);
 	post_log("FPGA RAM size: %d bytes\n", read_value);
 
diff --git a/post/board/lwmon5/gdc.c b/post/board/lwmon5/gdc.c
index 76e5dd6..0e4f0fd 100644
--- a/post/board/lwmon5/gdc.c
+++ b/post/board/lwmon5/gdc.c
@@ -35,7 +35,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define GDC_SCRATCH_REG 0xC1FF8044
+#define GDC_SCRATCH_REG 0xC1FF8008
 #define GDC_VERSION_REG 0xC1FF8084
 #define GDC_RAM_START   0xC0000000
 #define GDC_RAM_END     0xC2000000
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:43 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:43 +0200
Subject: [U-Boot-Users] [PATCH] The patch adds new POST tests for the Lwmon5
	board.
In-Reply-To: <1208874293-2123-1-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-2-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at pollux.denx.de>

* External Watchdog test;
* dsPIC tests;
* FPGA test;
* GDC test;
* Sysmon tests.

Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 board/lwmon5/lwmon5.c        |   19 +++
 include/configs/lwmon5.h     |   92 ++++++++++++++-
 include/post.h               |    5 +
 include/ppc440.h             |    3 +
 post/board/lwmon5/Makefile   |   28 +++++
 post/board/lwmon5/dsp.c      |   58 +++++++++
 post/board/lwmon5/dspic.c    |  109 +++++++++++++++++
 post/board/lwmon5/fpga.c     |  104 ++++++++++++++++
 post/board/lwmon5/gdc.c      |   94 +++++++++++++++
 post/board/lwmon5/sysmon.c   |  265 ++++++++++++++++++++++++++++++++++++++++++
 post/board/lwmon5/watchdog.c |  132 +++++++++++++++++++++
 post/tests.c                 |   26 ++++
 12 files changed, 931 insertions(+), 4 deletions(-)
 create mode 100644 post/board/lwmon5/Makefile
 create mode 100644 post/board/lwmon5/dsp.c
 create mode 100644 post/board/lwmon5/dspic.c
 create mode 100644 post/board/lwmon5/fpga.c
 create mode 100644 post/board/lwmon5/gdc.c
 create mode 100644 post/board/lwmon5/sysmon.c
 create mode 100644 post/board/lwmon5/watchdog.c

diff --git a/board/lwmon5/lwmon5.c b/board/lwmon5/lwmon5.c
index 815c01f..73d5de5 100644
--- a/board/lwmon5/lwmon5.c
+++ b/board/lwmon5/lwmon5.c
@@ -96,6 +96,25 @@ int board_early_init_f(void)
 
 	gpio_write_bit(CFG_GPIO_FLASH_WP, 1);
 
+#if CONFIG_POST & CFG_POST_BSPEC1
+	gpio_write_bit(CFG_GPIO_HIGHSIDE, 1);
+
+	reg = 0; /* reuse as counter */
+	out_be32((void *)CFG_DSPIC_TEST_ADDR,
+		in_be32((void *)CFG_DSPIC_TEST_ADDR)
+			& ~CFG_DSPIC_TEST_MASK);
+	while (!gpio_read_in_bit(CFG_GPIO_DSPIC_READY) && reg++ < 1000) {
+		udelay(1000);
+	}
+	gpio_write_bit(CFG_GPIO_HIGHSIDE, 0);
+	if (gpio_read_in_bit(CFG_GPIO_DSPIC_READY)) {
+		/* set "boot error" flag */
+		out_be32((void *)CFG_DSPIC_TEST_ADDR,
+			in_be32((void *)CFG_DSPIC_TEST_ADDR) |
+			CFG_DSPIC_TEST_MASK);
+	}
+#endif
+
 	/*
 	 * Reset PHY's:
 	 * The PHY's need a 2nd reset pulse, since the MDIO address is latched
diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
index c3f10c7..6489e0e 100644
--- a/include/configs/lwmon5.h
+++ b/include/configs/lwmon5.h
@@ -86,6 +86,15 @@
 #define CFG_POST_ALT_WORD_ADDR	(CFG_PERIPHERAL_BASE + GPT0_COMP6)
 						/* unused GPT0 COMP reg	*/
 
+/* Additional registers for watchdog timer post test */
+
+#define CFG_DSPIC_TEST_ADDR	(CFG_PERIPHERAL_BASE + GPT0_COMP5)
+#define CFG_WATCHDOG_TIME_ADDR	(CFG_PERIPHERAL_BASE + GPT0_COMP4)
+#define CFG_WATCHDOG_FLAGS_ADDR	(CFG_PERIPHERAL_BASE + GPT0_COMP5)
+#define CFG_WATCHDOG_MAGIC	0x12480000
+#define CFG_WATCHDOG_MAGIC_MASK	0xFFFF0000
+#define CFG_DSPIC_TEST_MASK	0x00000001
+
 /*-----------------------------------------------------------------------
  * Serial Port
  *----------------------------------------------------------------------*/
@@ -156,7 +165,81 @@
 				 CFG_POST_MEMORY   | \
 				 CFG_POST_RTC      | \
 				 CFG_POST_SPR      | \
-				 CFG_POST_UART)
+				 CFG_POST_UART     | \
+				 CFG_POST_SYSMON   | \
+				 CFG_POST_WATCHDOG | \
+				 CFG_POST_DSP      | \
+				 CFG_POST_BSPEC1   | \
+				 CFG_POST_BSPEC2   | \
+				 CFG_POST_BSPEC3   | \
+				 CFG_POST_BSPEC4   | \
+				 CFG_POST_BSPEC5)
+
+#define CONFIG_POST_WATCHDOG  {\
+	"Watchdog timer test",				\
+	"watchdog",					\
+	"This test checks the watchdog timer.",		\
+	POST_RAM | POST_POWERON | POST_SLOWTEST | POST_MANUAL | POST_REBOOT, \
+	&lwmon5_watchdog_post_test,			\
+	NULL,						\
+	NULL,						\
+	CFG_POST_WATCHDOG				\
+	}
+
+#define CONFIG_POST_BSPEC1    {\
+	"dsPIC init test",				\
+	"dspic_init",					\
+	"This test returns result of dsPIC READY test run earlier.",	\
+	POST_RAM | POST_ALWAYS,				\
+	&dspic_init_post_test,				\
+	NULL,						\
+	NULL,						\
+	CFG_POST_BSPEC1					\
+	}
+
+#define CONFIG_POST_BSPEC2    {\
+	"dsPIC test",					\
+	"dspic",					\
+	"This test gets result of dsPIC POST and dsPIC version.",	\
+	POST_RAM | POST_ALWAYS,				\
+	&dspic_post_test,				\
+	NULL,						\
+	NULL,						\
+	CFG_POST_BSPEC2					\
+	}
+
+#define CONFIG_POST_BSPEC3    {\
+	"FPGA test",					\
+	"fpga",						\
+	"This test checks FPGA registers and memory.",	\
+	POST_RAM | POST_ALWAYS,				\
+	&fpga_post_test,				\
+	NULL,						\
+	NULL,						\
+	CFG_POST_BSPEC3					\
+	}
+
+#define CONFIG_POST_BSPEC4    {\
+	"GDC test",					\
+	"gdc",						\
+	"This test checks GDC registers and memory.",	\
+	POST_RAM | POST_ALWAYS,				\
+	&gdc_post_test,					\
+	NULL,						\
+	NULL,						\
+	CFG_POST_BSPEC4					\
+	}
+
+#define CONFIG_POST_BSPEC5    {\
+	"SYSMON1 test",					\
+	"sysmon1",					\
+	"This test checks GPIO_62_EPX pin indicating power failure.",	\
+	POST_RAM | POST_MANUAL | POST_NORMAL | POST_SLOWTEST,	\
+	&sysmon1_post_test,				\
+	NULL,						\
+	NULL,						\
+	CFG_POST_BSPEC5					\
+	}
 
 #define CFG_POST_CACHE_ADDR	0x7fff0000 /* free virtual address	*/
 #define CONFIG_LOGBUFFER
@@ -181,6 +264,7 @@
 #define CONFIG_RTC_PCF8563	1		/* enable Philips PCF8563 RTC	*/
 #define CFG_I2C_RTC_ADDR	0x51		/* Philips PCF8563 RTC address	*/
 #define CFG_I2C_KEYBD_ADDR	0x56		/* PIC LWE keyboard		*/
+#define CFG_I2C_DSPIC_IO_ADDR	0x57		/* PIC I/O addr               */
 
 #define	CONFIG_POST_KEY_MAGIC	"3C+3E"	/* press F3 + F5 keys to force POST */
 #if 0
@@ -366,9 +450,6 @@
 #define CFG_PCI_SUBSYS_VENDORID 0x10e8	/* AMCC				*/
 #define CFG_PCI_SUBSYS_ID       0xcafe	/* Whatever			*/
 
-/*
- * ToDo: Watchdog is not test fully, so exclude it for now
- */
 #define CONFIG_HW_WATCHDOG	1	/* Use external HW-Watchdog	*/
 #define CONFIG_WD_PERIOD	40000	/* in usec */
 
@@ -431,10 +512,13 @@
 #define CFG_GPIO_PHY1_RST	12
 #define CFG_GPIO_FLASH_WP	14
 #define CFG_GPIO_PHY0_RST	22
+#define CFG_GPIO_DSPIC_READY	51
 #define CFG_GPIO_EEPROM_EXT_WP	55
+#define CFG_GPIO_HIGHSIDE	56
 #define CFG_GPIO_EEPROM_INT_WP	57
 #define CFG_GPIO_LIME_S		59
 #define CFG_GPIO_LIME_RST	60
+#define CFG_GPIO_SYSMON_STATUS	62
 #define CFG_GPIO_WATCHDOG	63
 
 /*-----------------------------------------------------------------------
diff --git a/include/post.h b/include/post.h
index c8062bb..12c0e92 100644
--- a/include/post.h
+++ b/include/post.h
@@ -93,6 +93,11 @@ extern int post_hotkeys_pressed(void);
 #define CFG_POST_CODEC		0x00002000
 #define CFG_POST_FPU		0x00004000
 #define CFG_POST_ECC		0x00008000
+#define CFG_POST_BSPEC1		0x00010000
+#define CFG_POST_BSPEC2		0x00020000
+#define CFG_POST_BSPEC3		0x00040000
+#define CFG_POST_BSPEC4		0x00080000
+#define CFG_POST_BSPEC5		0x00100000
 
 #endif /* CONFIG_POST */
 
diff --git a/include/ppc440.h b/include/ppc440.h
index 80dd332..6e3b68d 100644
--- a/include/ppc440.h
+++ b/include/ppc440.h
@@ -1431,6 +1431,9 @@
 #define   SDR0_MFR_PKT_REJ_POL         0x00200000   /* Packet Reject Polarity */
 
 #define GPT0_COMP6			0x00000098
+#define GPT0_COMP5			0x00000094
+#define GPT0_COMP4			0x00000090
+#define GPT0_COMP3			0x0000008C
 
 #if defined(CONFIG_440EPX) || defined(CONFIG_440GRX)
 #define SDR0_USB2D0CR                 0x0320
diff --git a/post/board/lwmon5/Makefile b/post/board/lwmon5/Makefile
new file mode 100644
index 0000000..5a92d1c
--- /dev/null
+++ b/post/board/lwmon5/Makefile
@@ -0,0 +1,28 @@
+#
+# (C) Copyright 2008 Dmitry Rakhchev, EmCraft Systems, rda at emcraft.com
+#
+# Developed for DENX Software Engineering GmbH
+#
+# 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
+
+LIB	= libpostlwmon5.a
+
+COBJS	= sysmon.o watchdog.o dspic.o fpga.o dsp.o gdc.o
+
+include $(TOPDIR)/post/rules.mk
diff --git a/post/board/lwmon5/dsp.c b/post/board/lwmon5/dsp.c
new file mode 100644
index 0000000..7b53af9
--- /dev/null
+++ b/post/board/lwmon5/dsp.c
@@ -0,0 +1,58 @@
+/*
+ * (C) Copyright 2008 Dmitry Rakhchev, EmCraft Systems, rda at emcraft.com
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * 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 <common.h>
+
+#ifdef CONFIG_POST
+
+#include <post.h>
+
+
+#if CONFIG_POST & CFG_POST_DSP
+#include <asm/io.h>
+
+/* This test verifies DSP status bits in FPGA */
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DSP_STATUS_REG 0xC4000008
+
+int dsp_post_test(int flags)
+{
+	uint   read_value;
+	int    ret;
+
+	ret = 0;
+	read_value = in_be32((void *)DSP_STATUS_REG) & 0x3;
+	if (read_value != 0x3) {
+		post_log("\nDSP status read %08X\n", read_value);
+		ret = 1;
+	}
+
+	return ret;
+}
+
+#endif /* CONFIG_POST & CFG_POST_DSP */
+#endif /* CONFIG_POST */
+
diff --git a/post/board/lwmon5/dspic.c b/post/board/lwmon5/dspic.c
new file mode 100644
index 0000000..e8fed89
--- /dev/null
+++ b/post/board/lwmon5/dspic.c
@@ -0,0 +1,109 @@
+/*
+ * (C) Copyright 2008 Dmitry Rakhchev, EmCraft Systems, rda at emcraft.com
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * 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 <common.h>
+
+#ifdef CONFIG_POST
+
+/* There are two tests for dsPIC currently implemented:
+ * 1. dsPIC ready test. Done in board_early_init_f(). Only result verified here.
+ * 2. dsPIC POST result test.  This test gets dsPIC POST codes and version.
+ */
+
+#include <post.h>
+
+#include <i2c.h>
+#include <asm/io.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DSPIC_POST_ERROR_REG	0x800
+#define DSPIC_SYS_ERROR_REG	0x802
+#define DSPIC_VERSION_REG	0x804
+
+#if CONFIG_POST & CFG_POST_BSPEC1
+
+/* Verify that dsPIC ready test done early at hw init passed ok */
+int dspic_init_post_test(int flags)
+{
+	if (in_be32((void *)CFG_DSPIC_TEST_ADDR) & CFG_DSPIC_TEST_MASK) {
+		post_log("dsPIC init test failed\n");
+		return 1;
+	}
+
+	return 0;
+}
+
+#endif /* CONFIG_POST & CFG_POST_BSPEC1 */
+
+#if CONFIG_POST & CFG_POST_BSPEC2
+/* Read a register from the dsPIC. */
+int dspic_read(ushort reg)
+{
+	uchar buf[2];
+
+	if (i2c_read(CFG_I2C_DSPIC_IO_ADDR, reg, 2, buf, 2))
+		return -1;
+
+	return (uint)((buf[0] << 8) | buf[1]);
+}
+
+/* Verify error codes regs, display version */
+int dspic_post_test(int flags)
+{
+	int data;
+	int ret = 0;
+
+	post_log("\n");
+	data = dspic_read(DSPIC_VERSION_REG);
+	if (data == -1) {
+		post_log("dsPIC : failed read version\n");
+		ret = 1;
+	} else {
+		post_log("dsPIC version: %u.%u\n",
+			(data >> 8) & 0xFF, data & 0xFF);
+	}
+
+	data = dspic_read(DSPIC_POST_ERROR_REG);
+	if (data != 0) ret = 1;
+	if (data == -1) {
+		post_log("dsPIC : failed read POST code\n");
+	} else {
+		post_log("dsPIC POST code 0x%04X\n", data);
+	}
+
+	data = dspic_read(DSPIC_SYS_ERROR_REG);
+	if (data != 0) ret = 1;
+	if (data == -1) {
+		post_log("dsPIC : failed read system error\n");
+	} else {
+		post_log("dsPIC SYS-ERROR code: 0x%04X\n", data);
+	}
+
+	return ret;
+}
+
+#endif /* CONFIG_POST & CFG_POST_BSPEC2 */
+#endif /* CONFIG_POST */
+
diff --git a/post/board/lwmon5/fpga.c b/post/board/lwmon5/fpga.c
new file mode 100644
index 0000000..4e3f1d5
--- /dev/null
+++ b/post/board/lwmon5/fpga.c
@@ -0,0 +1,104 @@
+/*
+ * (C) Copyright 2008 Dmitry Rakhchev, EmCraft Systems, rda at emcraft.com
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * 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 <common.h>
+
+#ifdef CONFIG_POST
+
+/* This test performs testing of FPGA SCRATCH register,
+ * gets FPGA version and run get_ram_size() on FPGA memory
+ */
+
+#include <post.h>
+
+#include <asm/io.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define FPGA_SCRATCH_REG	0xC4000050
+#define FPGA_VERSION_REG	0xC4000040
+#define FPGA_RAM_START		0xC4200000
+#define FPGA_RAM_END		0xC4203FFF
+
+#define FPGA_PWM_CTRL_REG	0xC4000020
+#define FPGA_PWM_TV_REG		0xC4000024
+
+/* Turn on backlight, set brightness */
+void fpga_backlight_enable(int pwm)
+{
+	out_be16((void *)FPGA_PWM_CTRL_REG, 0x0701);
+	out_be16((void *)FPGA_PWM_TV_REG, pwm);
+}
+
+#if CONFIG_POST & CFG_POST_BSPEC3
+
+static int one_scratch_test(uint value)
+{
+	uint read_value;
+	int ret = 0;
+
+	out_be32((void *)FPGA_SCRATCH_REG, value);
+	/* read other location (protect against data lines capacity) */
+	ret = in_be16((void *)FPGA_VERSION_REG);
+	/* verify test pattern */
+	read_value = in_be32((void *)FPGA_SCRATCH_REG);
+	if (read_value != value) {
+		post_log("FPGA SCRATCH test failed write %08X, read %08X\n",
+			value, read_value);
+		ret = 1;
+	}
+
+	return ret;
+}
+
+/* Verify FPGA, get version & memory size */
+int fpga_post_test(int flags)
+{
+	uint   old_value;
+	ushort version;
+	uint   read_value;
+	int    ret = 0;
+
+	post_log("\n");
+	old_value = in_be32((void *)FPGA_SCRATCH_REG);
+
+	if (one_scratch_test(0x55555555))
+		ret = 1;
+	if (one_scratch_test(0xAAAAAAAA))
+		ret = 1;
+
+	out_be32((void *)FPGA_SCRATCH_REG, old_value);
+
+	version = in_be16((void *)FPGA_VERSION_REG);
+	post_log("FPGA : version %u.%u\n",
+		(version >> 8) & 0xFF, version & 0xFF);
+
+	read_value = get_ram_size((void *)CFG_FPGA_BASE_1, 0x4000);
+	post_log("FPGA RAM size: %d bytes\n", read_value);
+
+	return ret;
+}
+
+#endif /* CONFIG_POST & CFG_POST_BSPEC3 */
+#endif /* CONFIG_POST */
+
diff --git a/post/board/lwmon5/gdc.c b/post/board/lwmon5/gdc.c
new file mode 100644
index 0000000..76e5dd6
--- /dev/null
+++ b/post/board/lwmon5/gdc.c
@@ -0,0 +1,94 @@
+/*
+ * (C) Copyright 2008 Dmitry Rakhchev, EmCraft Systems, rda at emcraft.com
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * 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 <common.h>
+
+#ifdef CONFIG_POST
+
+/* This test attempts to verify board GDC. A scratch register tested, then
+ * simple memory test (get_ram_size()) run over GDC memory.
+ */
+
+#include <post.h>
+
+#include <asm/io.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define GDC_SCRATCH_REG 0xC1FF8044
+#define GDC_VERSION_REG 0xC1FF8084
+#define GDC_RAM_START   0xC0000000
+#define GDC_RAM_END     0xC2000000
+
+#if CONFIG_POST & CFG_POST_BSPEC4
+
+static int gdc_test_reg_one(uint value)
+{
+	int ret = 0;
+	uint read_value;
+
+	/* write test pattern */
+	out_be32((void *)GDC_SCRATCH_REG, value);
+	/* read other location (protect against data lines capacity) */
+	ret = in_be32((void *)GDC_RAM_START);
+	/* verify test pattern */
+	read_value = in_be32((void *)GDC_SCRATCH_REG);
+	if (read_value != value) {
+		post_log("GDC SCRATCH test failed write %08X, read %08X\n",
+			value, read_value);
+		ret = 1;
+	}
+
+	return ret;
+}
+
+/* Verify GDC, get memory size */
+int gdc_post_test(int flags)
+{
+	uint   old_value;
+	int    ret = 0;
+
+	post_log("\n");
+	old_value = in_be32((void *)GDC_SCRATCH_REG);
+
+	if (gdc_test_reg_one(0x55555555))
+		ret = 1;
+	if (gdc_test_reg_one(0xAAAAAAAA))
+		ret = 1;
+
+	out_be32((void *)GDC_SCRATCH_REG, old_value);
+
+	old_value = in_be32((void *)GDC_VERSION_REG);
+	post_log("GDC chip version %u.%u, year %04X\n",
+		(old_value >> 8) & 0xFF, old_value & 0xFF,
+		(old_value >> 16) & 0xFFFF);
+
+	old_value = get_ram_size((void *)GDC_RAM_START,
+				 GDC_RAM_END - GDC_RAM_START);
+	post_log("GDC RAM size: %d bytes\n", old_value);
+
+	return ret;
+}
+#endif /* CONFIG_POST & CFG_POST_BSPEC4 */
+#endif /* CONFIG_POST */
+
diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
new file mode 100644
index 0000000..0eae4c1
--- /dev/null
+++ b/post/board/lwmon5/sysmon.c
@@ -0,0 +1,265 @@
+/*
+ * (C) Copyright 2008 Dmitry Rakhchev, EmCraft Systems, rda at emcraft.com
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * 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 <post.h>
+#include <common.h>
+
+#ifdef CONFIG_POST
+
+/*
+ * SYSMON test
+ *
+ * This test performs the system hardware monitoring.
+ * The test passes when all the following voltages and temperatures
+ * are within allowed ranges:
+ *
+ * Temperature                -40 .. +85 C
+ * +5V                      +4.75 .. +5.25 V
+ * +5V standby              +4.75 .. +5.25 V
+ *
+ * LCD backlight is not enabled if temperature values are not within
+ * allowed ranges (-30 .. + 80). The brightness of backlite can be
+ * controlled by setting "brightness" enviroment variable. Default value is 50%
+ *
+ * See the list of all parameters in the sysmon_table below
+ */
+
+#include <post.h>
+#include <watchdog.h>
+#include <i2c.h>
+
+#if CONFIG_POST & CFG_POST_SYSMON
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define DEFAULT_BRIGHTNESS 50
+
+/* from dspic.c */
+extern int dspic_read(ushort reg);
+/* from fpga.c */
+extern void fpga_backlight_enable(int v);
+
+static int sysmon_temp_invalid;
+
+#define	RELOC(x) if (x != NULL) x = (void *) ((ulong) (x) + gd->reloc_off)
+
+typedef struct sysmon_s sysmon_t;
+typedef struct sysmon_table_s sysmon_table_t;
+
+static void sysmon_dspic_init (sysmon_t * this);
+static int sysmon_dspic_read (sysmon_t * this, uint addr);
+static void sysmon_backlight_disable (sysmon_table_t * this);
+static void sysmon_backlight_enable (sysmon_table_t * this);
+
+struct sysmon_s
+{
+	uchar	chip;
+	void	(*init)(sysmon_t *);
+	int	(*read)(sysmon_t *, uint);
+};
+
+static sysmon_t sysmon_dspic =
+	{CFG_I2C_DSPIC_IO_ADDR, sysmon_dspic_init, sysmon_dspic_read};
+
+static sysmon_t * sysmon_list[] =
+{
+	&sysmon_dspic,
+	NULL
+};
+
+struct sysmon_table_s
+{
+	char *		name;
+	char *		unit_name;
+	sysmon_t *	sysmon;
+	void		(*exec_before)(sysmon_table_t *);
+	void		(*exec_after)(sysmon_table_t *);
+
+	int		unit_precision;
+	int		unit_div;
+	int		unit_min;
+	int		unit_max;
+	uint		val_mask;
+	uint		val_min;
+	uint		val_max;
+	int		val_valid;
+	uint		val_min_alt;
+	uint		val_max_alt;
+	int		val_valid_alt;
+	uint		addr;
+};
+
+static sysmon_table_t sysmon_table[] =
+{
+    {"Temperature", " C", &sysmon_dspic, NULL, sysmon_backlight_disable,
+     1, 1, -32768, 32767, 0xFFFF, 0x8000-40, 0x8000+85, 0,
+                                  0x8000-30, 0x8000+80, 0, 0x12BC},
+
+    {"+ 5 V", "V", &sysmon_dspic, NULL, NULL,
+     100, 1000, -0x8000, 0x7FFF, 0xFFFF, 0x8000+4750, 0x8000+5250, 0,
+                                         0x8000+4750, 0x8000+5250, 0, 0x12CA},
+
+    {"+ 5 V standby", "V", &sysmon_dspic, NULL, sysmon_backlight_enable,
+     100, 1000, -0x8000, 0x7FFF, 0xFFFF, 0x8000+4750, 0x8000+5250, 0,
+                                         0x8000+4750, 0x8000+5250, 0, 0x12C6},
+};
+static int sysmon_table_size = sizeof(sysmon_table) / sizeof(sysmon_table[0]);
+
+int sysmon_init_f (void)
+{
+	sysmon_t ** l;
+
+	for (l = sysmon_list; *l; l++)
+		(*l)->init(*l);
+
+	return 0;
+}
+
+void sysmon_reloc (void)
+{
+	sysmon_t ** l;
+	sysmon_table_t * t;
+
+	for (l = sysmon_list; *l; l++) {
+		RELOC(*l);
+		RELOC((*l)->init);
+		RELOC((*l)->read);
+	}
+
+	for (t = sysmon_table; t < sysmon_table + sysmon_table_size; t ++) {
+		RELOC(t->exec_before);
+		RELOC(t->exec_after);
+		RELOC(t->sysmon);
+	}
+}
+
+static char *sysmon_unit_value (sysmon_table_t *s, uint val)
+{
+	static char buf[32];
+	char *p, sign;
+	int decimal, frac;
+	int unit_val;
+
+	unit_val =
+	    s->unit_min + (s->unit_max - s->unit_min) * val / s->val_mask;
+
+	if (val == -1)
+		return "I/O ERROR";
+
+	if (unit_val < 0) {
+		sign = '-';
+		unit_val = -unit_val;
+	} else
+		sign = '+';
+
+	p = buf + sprintf(buf, "%c%2d", sign, unit_val / s->unit_div);
+
+
+	frac = unit_val % s->unit_div;
+
+	frac /= (s->unit_div / s->unit_precision);
+
+	decimal = s->unit_precision;
+
+	if (decimal != 1)
+		*p++ = '.';
+	for (decimal /= 10; decimal != 0; decimal /= 10)
+		*p++ = '0' + (frac / decimal) % 10;
+	strcpy(p, s->unit_name);
+
+	return buf;
+}
+
+static void sysmon_dspic_init (sysmon_t * this)
+{
+}
+
+static int sysmon_dspic_read (sysmon_t * this, uint addr)
+{
+	int res = dspic_read(addr);
+
+	/* To fit into the table range we should add 0x8000 */
+	return (res == -1) ? -1 : (res + 0x8000);
+}
+
+static void sysmon_backlight_disable (sysmon_table_t * this)
+{
+	if (!this->val_valid_alt)
+		sysmon_temp_invalid = 1;
+}
+
+static void sysmon_backlight_enable (sysmon_table_t * this)
+{
+	char * param;
+	int rc;
+
+	if (!sysmon_temp_invalid) {
+		param = getenv("brightness");
+		rc = param ? simple_strtol(param, NULL, 10) : -1;
+		if (rc >= 0)
+			fpga_backlight_enable(rc);
+		else
+			fpga_backlight_enable(DEFAULT_BRIGHTNESS);
+	}
+}
+
+int sysmon_post_test (int flags)
+{
+	int res = 0;
+	sysmon_table_t * t;
+	int val;
+
+	for (t = sysmon_table; t < sysmon_table + sysmon_table_size; t ++) {
+		if (t->exec_before)
+			t->exec_before(t);
+
+		val = t->sysmon->read(t->sysmon, t->addr);
+		if (val != -1) {
+			t->val_valid = val >= t->val_min && val <= t->val_max;
+			t->val_valid_alt = val >= t->val_min_alt && val <= t->val_max_alt;
+		} else {
+			t->val_valid = 0;
+			t->val_valid_alt = 0;
+		}
+
+		if (t->exec_after)
+			t->exec_after(t);
+
+		if ((!t->val_valid) || (flags & POST_MANUAL)) {
+			printf("%-17s = %-10s ", t->name, sysmon_unit_value(t, val));
+			printf("allowed range");
+			printf(" %-8s ..", sysmon_unit_value(t, t->val_min));
+			printf(" %-8s", sysmon_unit_value(t, t->val_max));
+			printf("     %s\n", t->val_valid ? "OK" : "FAIL");
+		}
+
+		if (!t->val_valid)
+			res = 1;
+	}
+
+	return res;
+}
+
+#endif /* CONFIG_POST & CFG_POST_SYSMON */
+#endif /* CONFIG_POST */
diff --git a/post/board/lwmon5/watchdog.c b/post/board/lwmon5/watchdog.c
new file mode 100644
index 0000000..ad9e6f3
--- /dev/null
+++ b/post/board/lwmon5/watchdog.c
@@ -0,0 +1,132 @@
+/*
+ * (C) Copyright 2008 Dmitry Rakhchev, EmCraft Systems, rda at emcraft.com
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * 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 <common.h>
+
+/* This test verifies if the reason of last reset was an abnormal voltage
+ * condition, than it performs watchdog test, measuing time required to
+ * trigger watchdog reset.
+ */
+
+#ifdef CONFIG_POST
+
+#include <post.h>
+
+#if CONFIG_POST & CFG_POST_WATCHDOG
+
+#include <watchdog.h>
+#include <asm/gpio.h>
+#include <asm/io.h>
+
+static uint watchdog_magic_read(void)
+{
+	return in_be32((void *)CFG_WATCHDOG_FLAGS_ADDR) &
+		CFG_WATCHDOG_MAGIC_MASK;
+}
+
+static void watchdog_magic_write(uint value)
+{
+	out_be32((void *)CFG_WATCHDOG_FLAGS_ADDR, value |
+		(in_be32((void *)CFG_WATCHDOG_FLAGS_ADDR) &
+			~CFG_WATCHDOG_MAGIC_MASK));
+}
+
+int sysmon1_post_test(int flags)
+{
+	if (gpio_read_in_bit(CFG_GPIO_SYSMON_STATUS)) {
+		/* 3.1. GPIO62 is low
+		 * Assuming system voltage failure.
+		 */
+		post_log("Abnormal voltage detected (GPIO62)\n");
+		return 1;
+	}
+
+	return 0;
+}
+
+int lwmon5_watchdog_post_test(int flags)
+{
+	/* On each reset scratch register 1 should be tested,
+	 * but first test GPIO62:
+	 */
+	if (!(flags & POST_MANUAL) && sysmon1_post_test(flags)) {
+		/* 3.1. GPIO62 is low
+		 * Assuming system voltage failure.
+		 */
+		/* 3.1.1. Set scratch register 1 to 0x0000xxxx */
+		watchdog_magic_write(0);
+		/* 3.1.2. Mark test as failed due to voltage?! */
+		return 1;
+	}
+
+	if (watchdog_magic_read() != CFG_WATCHDOG_MAGIC) {
+		/* 3.2. Scratch register 1 differs from magic value 0x1248xxxx
+		 * Assuming PowerOn
+		 */
+		int ints;
+		ulong base;
+		ulong time;
+
+		/* 3.2.1. Set magic value to scratch register */
+		watchdog_magic_write(CFG_WATCHDOG_MAGIC);
+
+		ints = disable_interrupts ();
+		/* 3.2.2. strobe watchdog once */
+		WATCHDOG_RESET();
+		out_be32((void *)CFG_WATCHDOG_TIME_ADDR, 0);
+		/* 3.2.3. save time of strobe in scratch register 2 */
+		base = post_time_ms (0);
+
+		/* 3.2.4. Wait for 150 ms (enough for reset to happen) */
+		while ((time = post_time_ms (base)) < 150)
+			out_be32((void *)CFG_WATCHDOG_TIME_ADDR, time);
+		if (ints)
+			enable_interrupts ();
+
+		/* 3.2.5. Reset didn't happen. - Set 0x0000xxxx
+		 * into scratch register 1
+		 */
+		watchdog_magic_write(0);
+		/* 3.2.6. Mark test as failed. */
+		post_log("hw watchdog time : %u ms, failed ", time);
+		return 2;
+	} else {
+		/* 3.3. Scratch register matches magic value 0x1248xxxx
+		 * Assume this is watchdog-initiated reset
+		 */
+		ulong time;
+		/* 3.3.1. So, the test succeed, save measured time to syslog. */
+		time = in_be32((void *)CFG_WATCHDOG_TIME_ADDR);
+		post_log("hw watchdog time : %u ms, passed ", time);
+		/* 3.3.2. Set scratch register 1 to 0x0000xxxx */
+		watchdog_magic_write(0);
+		return 0;
+	}
+	return -1;
+}
+
+
+#endif /* CONFIG_POST & CFG_POST_WATCHDOG */
+#endif /* CONFIG_POST */
+
diff --git a/post/tests.c b/post/tests.c
index ed4ef2b..53d01e3 100644
--- a/post/tests.c
+++ b/post/tests.c
@@ -48,6 +48,13 @@ extern int dsp_post_test (int flags);
 extern int codec_post_test (int flags);
 extern int ecc_post_test (int flags);
 
+extern int dspic_init_post_test (int flags);
+extern int dspic_post_test (int flags);
+extern int gdc_post_test (int flags);
+extern int fpga_post_test (int flags);
+extern int lwmon5_watchdog_post_test(int flags);
+extern int sysmon1_post_test(int flags);
+
 extern int sysmon_init_f (void);
 
 extern void sysmon_reloc (void);
@@ -68,6 +75,9 @@ struct post_test post_list[] =
     },
 #endif
 #if CONFIG_POST & CFG_POST_WATCHDOG
+#if defined(CONFIG_POST_WATCHDOG)
+	CONFIG_POST_WATCHDOG,
+#else
     {
 	"Watchdog timer test",
 	"watchdog",
@@ -79,6 +89,7 @@ struct post_test post_list[] =
 	CFG_POST_WATCHDOG
     },
 #endif
+#endif
 #if CONFIG_POST & CFG_POST_I2C
     {
 	"I2C test",
@@ -249,6 +260,21 @@ struct post_test post_list[] =
 	CFG_POST_ECC
     },
 #endif
+#if CONFIG_POST & CFG_POST_BSPEC1
+	CONFIG_POST_BSPEC1,
+#endif
+#if CONFIG_POST & CFG_POST_BSPEC2
+	CONFIG_POST_BSPEC2,
+#endif
+#if CONFIG_POST & CFG_POST_BSPEC3
+	CONFIG_POST_BSPEC3,
+#endif
+#if CONFIG_POST & CFG_POST_BSPEC4
+	CONFIG_POST_BSPEC4,
+#endif
+#if CONFIG_POST & CFG_POST_BSPEC4
+	CONFIG_POST_BSPEC5,
+#endif
 };
 
 unsigned int post_list_size = sizeof (post_list) / sizeof (struct post_test);
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:52 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:52 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 watchdog: limit trigger rate
In-Reply-To: <1208874293-2123-10-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
	<1208874293-2123-5-git-send-email-wd@denx.de>
	<1208874293-2123-6-git-send-email-wd@denx.de>
	<1208874293-2123-7-git-send-email-wd@denx.de>
	<1208874293-2123-8-git-send-email-wd@denx.de>
	<1208874293-2123-9-git-send-email-wd@denx.de>
	<1208874293-2123-10-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-11-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at emcraft.com>

Limit the rate of h/w watch-dog triggering on the LWMON5 board by
the CONFIG_WD_MAX_RATE value.

Note that an earlier version of this patch which used microseconds
instead of ticks dis not work. The problem was that we used
usec2ticks() to convert microseconds into ticks. usec2ticks() uses
get_tbclk(), which in turn calls get_sys_info(). It turns out that
this function does a lot of prolonged operations (like divisions)
which take too much time so we do not trigger the watchdog in time,
and it resets the system.

Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 board/lwmon5/lwmon5.c         |   18 ++++++++++++++++++
 include/asm-ppc/global_data.h |    3 +++
 include/configs/lwmon5.h      |    1 +
 3 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/board/lwmon5/lwmon5.c b/board/lwmon5/lwmon5.c
index e5fa259..b63fbdc 100644
--- a/board/lwmon5/lwmon5.c
+++ b/board/lwmon5/lwmon5.c
@@ -476,6 +476,24 @@ int is_pci_host(struct pci_controller *hose)
 void hw_watchdog_reset(void)
 {
 	int val;
+#if defined(CONFIG_WD_MAX_RATE)
+	unsigned long long ct = get_ticks();
+
+	/*
+	 * Don't allow watch-dog triggering more frequently than
+	 * the predefined value CONFIG_WD_MAX_RATE [ticks].
+	 */
+	if (ct >= gd->wdt_last) {
+		if ((ct - gd->wdt_last) < CONFIG_WD_MAX_RATE)
+			return;
+	} else {
+		/* Time base counter had been reset */
+		if (((unsigned long long)(-1) - gd->wdt_last + ct) <
+		    CONFIG_WD_MAX_RATE)
+			return;
+	}
+	gd->wdt_last = get_ticks();
+#endif
 
 	/*
 	 * Toggle watchdog output
diff --git a/include/asm-ppc/global_data.h b/include/asm-ppc/global_data.h
index e07092b..4657604 100644
--- a/include/asm-ppc/global_data.h
+++ b/include/asm-ppc/global_data.h
@@ -155,6 +155,9 @@ typedef	struct	global_data {
 #if defined(CONFIG_LWMON) || defined(CONFIG_LWMON5)
 	unsigned long kbd_status;
 #endif
+#if defined(CONFIG_WD_MAX_RATE)
+	unsigned long long wdt_last;	/* trace watch-dog triggering rate */
+#endif
 	void		**jt;		/* jump table */
 } gd_t;
 
diff --git a/include/configs/lwmon5.h b/include/configs/lwmon5.h
index ced7ba6..58f078b 100644
--- a/include/configs/lwmon5.h
+++ b/include/configs/lwmon5.h
@@ -455,6 +455,7 @@
 
 #define CONFIG_HW_WATCHDOG	1	/* Use external HW-Watchdog	*/
 #define CONFIG_WD_PERIOD	40000	/* in usec */
+#define CONFIG_WD_MAX_RATE	66600	/* in ticks */
 
 /*
  * For booting Linux, the board info and command line data
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:48 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:48 +0200
Subject: [U-Boot-Users] [PATCH] Fix backlight in the lwmon5 POST.
In-Reply-To: <1208874293-2123-6-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
	<1208874293-2123-5-git-send-email-wd@denx.de>
	<1208874293-2123-6-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-7-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at pollux.denx.de>

Backlight was switcehd on even when temperature was too low.

Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 board/lwmon5/lwmon5.c      |   24 +++++++++++++++++++++---
 post/board/lwmon5/fpga.c   |   10 ----------
 post/board/lwmon5/sysmon.c |   33 ++++++++-------------------------
 3 files changed, 29 insertions(+), 38 deletions(-)

diff --git a/board/lwmon5/lwmon5.c b/board/lwmon5/lwmon5.c
index 7c5f6cc..e5fa259 100644
--- a/board/lwmon5/lwmon5.c
+++ b/board/lwmon5/lwmon5.c
@@ -567,11 +567,13 @@ unsigned int board_video_init (void)
 	return CFG_LIME_BASE_0;
 }
 
-void board_backlight_switch (int flag)
+#define DEFAULT_BRIGHTNESS 0x64
+
+static void board_backlight_brightness(int brightness)
 {
-	if (flag) {
+	if (brightness > 0) {
 		/* pwm duty, lamp on */
-		out_be32((void *)(CFG_FPGA_BASE_0 + 0x00000024), 0x64);
+		out_be32((void *)(CFG_FPGA_BASE_0 + 0x00000024), brightness);
 		out_be32((void *)(CFG_FPGA_BASE_0 + 0x00000020), 0x701);
 	} else {
 		/* lamp off */
@@ -580,6 +582,22 @@ void board_backlight_switch (int flag)
 	}
 }
 
+void board_backlight_switch (int flag)
+{
+	char * param;
+	int rc;
+
+	if (flag) {
+		param = getenv("brightness");
+		rc = param ? simple_strtol(param, NULL, 10) : -1;
+		if (rc < 0)
+			rc = DEFAULT_BRIGHTNESS;
+	} else {
+		rc = 0;
+	}
+	board_backlight_brightness(rc);
+}
+
 #if defined(CONFIG_CONSOLE_EXTRA_INFO)
 /*
  * Return text to be printed besides the logo.
diff --git a/post/board/lwmon5/fpga.c b/post/board/lwmon5/fpga.c
index b87fc52..162174c 100644
--- a/post/board/lwmon5/fpga.c
+++ b/post/board/lwmon5/fpga.c
@@ -41,16 +41,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define FPGA_RAM_END		0xC4203FFF
 #define FPGA_STAT		0xC400000C
 
-#define FPGA_PWM_CTRL_REG	0xC4000020
-#define FPGA_PWM_TV_REG		0xC4000024
-
-/* Turn on backlight, set brightness */
-void fpga_backlight_enable(int pwm)
-{
-	out_be16((void *)FPGA_PWM_CTRL_REG, 0x0701);
-	out_be16((void *)FPGA_PWM_TV_REG, pwm);
-}
-
 #if CONFIG_POST & CFG_POST_BSPEC3
 
 static int one_scratch_test(uint value)
diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
index 0eae4c1..f7e51a3 100644
--- a/post/board/lwmon5/sysmon.c
+++ b/post/board/lwmon5/sysmon.c
@@ -49,18 +49,16 @@
 #include <watchdog.h>
 #include <i2c.h>
 
+#if defined(CONFIG_VIDEO)
+#include <mb862xx.h>
+#endif
+
 #if CONFIG_POST & CFG_POST_SYSMON
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define DEFAULT_BRIGHTNESS 50
-
 /* from dspic.c */
 extern int dspic_read(ushort reg);
-/* from fpga.c */
-extern void fpga_backlight_enable(int v);
-
-static int sysmon_temp_invalid;
 
 #define	RELOC(x) if (x != NULL) x = (void *) ((ulong) (x) + gd->reloc_off)
 
@@ -70,7 +68,6 @@ typedef struct sysmon_table_s sysmon_table_t;
 static void sysmon_dspic_init (sysmon_t * this);
 static int sysmon_dspic_read (sysmon_t * this, uint addr);
 static void sysmon_backlight_disable (sysmon_table_t * this);
-static void sysmon_backlight_enable (sysmon_table_t * this);
 
 struct sysmon_s
 {
@@ -120,7 +117,7 @@ static sysmon_table_t sysmon_table[] =
      100, 1000, -0x8000, 0x7FFF, 0xFFFF, 0x8000+4750, 0x8000+5250, 0,
                                          0x8000+4750, 0x8000+5250, 0, 0x12CA},
 
-    {"+ 5 V standby", "V", &sysmon_dspic, NULL, sysmon_backlight_enable,
+    {"+ 5 V standby", "V", &sysmon_dspic, NULL, NULL,
      100, 1000, -0x8000, 0x7FFF, 0xFFFF, 0x8000+4750, 0x8000+5250, 0,
                                          0x8000+4750, 0x8000+5250, 0, 0x12C6},
 };
@@ -205,23 +202,9 @@ static int sysmon_dspic_read (sysmon_t * this, uint addr)
 
 static void sysmon_backlight_disable (sysmon_table_t * this)
 {
-	if (!this->val_valid_alt)
-		sysmon_temp_invalid = 1;
-}
-
-static void sysmon_backlight_enable (sysmon_table_t * this)
-{
-	char * param;
-	int rc;
-
-	if (!sysmon_temp_invalid) {
-		param = getenv("brightness");
-		rc = param ? simple_strtol(param, NULL, 10) : -1;
-		if (rc >= 0)
-			fpga_backlight_enable(rc);
-		else
-			fpga_backlight_enable(DEFAULT_BRIGHTNESS);
-	}
+#if defined(CONFIG_VIDEO)
+	board_backlight_switch(this->val_valid_alt);
+#endif
 }
 
 int sysmon_post_test (int flags)
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:51 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:51 +0200
Subject: [U-Boot-Users] [PATCH] POST: move CONFIG_POST to Makefiles
In-Reply-To: <1208874293-2123-9-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
	<1208874293-2123-5-git-send-email-wd@denx.de>
	<1208874293-2123-6-git-send-email-wd@denx.de>
	<1208874293-2123-7-git-send-email-wd@denx.de>
	<1208874293-2123-8-git-send-email-wd@denx.de>
	<1208874293-2123-9-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-10-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at emcraft.com>

Introduce the new logical option CONFIG_HAS_POST which is set when the
platform has CONFIG_POST set. Use CONFIG_HAS_POST in the post/ Makefiles
to determine should the POST libs be compiled for the selected target
platform, or not.

To avoid breaking u-boot linking process, the empty post/libpost.a file is
created for platforms which do not have POSTs.

Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 Makefile                   |   10 +--------
 include/common.h           |   11 ++++++++++
 post/Makefile              |   47 ++++++++++++++++++++++++++++++++++++++++---
 post/board/lwmon5/Makefile |    3 +-
 post/cpu/ppc4xx/Makefile   |    5 ++-
 post/drivers/Makefile      |    6 +---
 post/lib_ppc/Makefile      |   11 ++++-----
 post/lib_ppc/fpu/Makefile  |    6 ++--
 post/rules.mk              |    2 +
 9 files changed, 72 insertions(+), 29 deletions(-)

diff --git a/Makefile b/Makefile
index 4fde699..b2b59b2 100644
--- a/Makefile
+++ b/Makefile
@@ -233,18 +233,10 @@ LIBS += drivers/rtc/librtc.a
 LIBS += drivers/serial/libserial.a
 LIBS += drivers/usb/libusb.a
 LIBS += drivers/video/libvideo.a
-LIBS += post/libpost.a post/drivers/libpostdrivers.a
-LIBS += $(shell if [ -d post/lib_$(ARCH) ]; then echo \
-	"post/lib_$(ARCH)/libpost$(ARCH).a"; fi)
-LIBS += $(shell if [ -d post/lib_$(ARCH)/fpu ]; then echo \
-	"post/lib_$(ARCH)/fpu/libpost$(ARCH)fpu.a"; fi)
-LIBS += $(shell if [ -d post/cpu/$(CPU) ]; then echo \
-	"post/cpu/$(CPU)/libpost$(CPU).a"; fi)
-LIBS += $(shell if [ -d post/board/$(BOARDDIR) ]; then echo \
-	"post/board/$(BOARDDIR)/libpost$(BOARD).a"; fi)
 LIBS += common/libcommon.a
 LIBS += libfdt/libfdt.a
 LIBS += api/libapi.a
+LIBS += post/libpost.a
 
 LIBS := $(addprefix $(obj),$(LIBS))
 .PHONY : $(LIBS) $(VERSION_FILE)
diff --git a/include/common.h b/include/common.h
index 673afdd..8d435b9 100644
--- a/include/common.h
+++ b/include/common.h
@@ -672,4 +672,15 @@ void inline show_boot_progress (int val);
 
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 
+/* Multicore arch functions */
+#ifdef CONFIG_MP
+int cpu_status(int nr);
+int cpu_reset(int nr);
+int cpu_release(int nr, int argc, char *argv[]);
+#endif
+
+#ifdef CONFIG_POST
+#define CONFIG_HAS_POST
+#endif
+
 #endif	/* __COMMON_H_ */
diff --git a/post/Makefile b/post/Makefile
index f32af95..02b5154 100644
--- a/post/Makefile
+++ b/post/Makefile
@@ -21,11 +21,50 @@
 # MA 02111-1307 USA
 #
 
+include $(TOPDIR)/include/autoconf.mk
 
-SUBDIRS = drivers cpu lib_$(ARCH) board/$(BOARDDIR)
+LIB				= libpost.a
+GPLIB-$(CONFIG_HAS_POST)	+= libgenpost.a
+COBJS-$(CONFIG_HAS_POST)	+= post.o tests.o
 
-LIB	= libpost.a
+SPLIB-$(CONFIG_HAS_POST) = drivers/libpostdrivers.a
+SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d lib_$(ARCH) ]; then echo \
+			    "lib_$(ARCH)/libpost$(ARCH).a"; fi)
+SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d lib_$(ARCH)/fpu ]; then echo \
+			    "lib_$(ARCH)/fpu/libpost$(ARCH)fpu.a"; fi)
+SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d cpu/$(CPU) ]; then echo \
+			    "cpu/$(CPU)/libpost$(CPU).a"; fi)
+SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d board/$(BOARD) ]; then echo \
+			    "board/$(BOARD)/libpost$(BOARD).a"; fi)
 
-COBJS	= post.o tests.o
+GPLIB	:= $(GPLIB-y)
+SPLIB	:= $(SPLIB-y)
+COBJS	:= $(COBJS-y)
+SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+LIB	:= $(obj)$(LIB)
 
-include $(TOPDIR)/post/rules.mk
+all:	$(LIB)
+
+# generic POST library
+$(GPLIB): $(obj).depend $(OBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS)
+
+# specific POST libraries
+$(SPLIB): $(obj).depend
+	$(MAKE) -C $(dir $(subst $(obj),,$@))
+
+# the POST lib archive
+$(LIB): $(GPLIB) $(SPLIB)
+	(echo create $(LIB); for lib in $(GPLIB) $(SPLIB) ; \
+	 do echo addlib $$lib; done; echo save) \
+	| $(AR) -M
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/post/board/lwmon5/Makefile b/post/board/lwmon5/Makefile
index 5a92d1c..3cb6426 100644
--- a/post/board/lwmon5/Makefile
+++ b/post/board/lwmon5/Makefile
@@ -20,9 +20,10 @@
 # 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)/include/autoconf.mk
 
 LIB	= libpostlwmon5.a
 
-COBJS	= sysmon.o watchdog.o dspic.o fpga.o dsp.o gdc.o
+COBJS-$(CONFIG_HAS_POST)	+= sysmon.o watchdog.o dspic.o fpga.o dsp.o gdc.o
 
 include $(TOPDIR)/post/rules.mk
diff --git a/post/cpu/ppc4xx/Makefile b/post/cpu/ppc4xx/Makefile
index e3f44b7..7b13413 100644
--- a/post/cpu/ppc4xx/Makefile
+++ b/post/cpu/ppc4xx/Makefile
@@ -20,10 +20,11 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
+include $(TOPDIR)/include/autoconf.mk
 
 LIB	= libpostppc4xx.a
 
-AOBJS   = cache_4xx.o
-COBJS	= cache.o denali_ecc.o ether.o fpu.o spr.o uart.o watchdog.o
+AOBJS-$(CONFIG_HAS_POST)	+= cache_4xx.o
+COBJS-$(CONFIG_HAS_POST)	+= cache.o denali_ecc.o ether.o fpu.o spr.o uart.o watchdog.o
 
 include $(TOPDIR)/post/rules.mk
diff --git a/post/drivers/Makefile b/post/drivers/Makefile
index cb2f1de..0b6cdf5 100644
--- a/post/drivers/Makefile
+++ b/post/drivers/Makefile
@@ -20,12 +20,10 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
-
-SUBDIRS =
+include $(TOPDIR)/config.mk
 
 LIB	= libpostdrivers.a
 
-COBJS	= i2c.o memory.o rtc.o
+COBJS-$(CONFIG_HAS_POST)	+= i2c.o memory.o rtc.o
 
 include $(TOPDIR)/post/rules.mk
diff --git a/post/lib_ppc/Makefile b/post/lib_ppc/Makefile
index 9f1b329..bd7a232 100644
--- a/post/lib_ppc/Makefile
+++ b/post/lib_ppc/Makefile
@@ -20,14 +20,13 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
-SUBDIRS = fpu
+include $(TOPDIR)/config.mk
 
 LIB	= libpostppc.a
 
-AOBJS	= asm.o
-COBJS	= cpu.o cmp.o cmpi.o two.o twox.o three.o threex.o
-COBJS   += threei.o andi.o srawi.o rlwnm.o rlwinm.o rlwimi.o
-COBJS	+= store.o load.o cr.o b.o multi.o string.o complex.o
+AOBJS-$(CONFIG_HAS_POST)	+= asm.o
+COBJS-$(CONFIG_HAS_POST)	+= cpu.o cmp.o cmpi.o two.o twox.o three.o threex.o
+COBJS-$(CONFIG_HAS_POST)   += threei.o andi.o srawi.o rlwnm.o rlwinm.o rlwimi.o
+COBJS-$(CONFIG_HAS_POST)	+= store.o load.o cr.o b.o multi.o string.o complex.o
 
 include $(TOPDIR)/post/rules.mk
diff --git a/post/lib_ppc/fpu/Makefile b/post/lib_ppc/fpu/Makefile
index 82646c8..db43593 100644
--- a/post/lib_ppc/fpu/Makefile
+++ b/post/lib_ppc/fpu/Makefile
@@ -20,12 +20,12 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
+include $(TOPDIR)/config.mk
 
 LIB	= libpostppcfpu.a
 
-COBJS	+= fpu.o 20001122-1.o 20010114-2.o 20010226-1.o 980619-1.o
-COBJS	+= acc1.o compare-fp-1.o mul-subnormal-single-1.o
+COBJS-$(CONFIG_HAS_POST)	+= fpu.o 20001122-1.o 20010114-2.o 20010226-1.o 980619-1.o
+COBJS-$(CONFIG_HAS_POST)	+= acc1.o compare-fp-1.o mul-subnormal-single-1.o
 
 include $(TOPDIR)/post/rules.mk
 
diff --git a/post/rules.mk b/post/rules.mk
index e2c73c6..94e72be 100644
--- a/post/rules.mk
+++ b/post/rules.mk
@@ -23,6 +23,8 @@
 
 include $(TOPDIR)/config.mk
 
+COBJS	:= $(COBJS-y)
+AOBJS	:= $(AOBJS-y)
 SRCS 	:= $(AOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(AOBJS) $(COBJS))
 LIB	:= $(obj)$(LIB)
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:49 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5: Fix register test logic to match the
	specific GDC h/w.
In-Reply-To: <1208874293-2123-7-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
	<1208874293-2123-5-git-send-email-wd@denx.de>
	<1208874293-2123-6-git-send-email-wd@denx.de>
	<1208874293-2123-7-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-8-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at pollux.denx.de>

Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 post/board/lwmon5/gdc.c |   18 ++++++++++++------
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/post/board/lwmon5/gdc.c b/post/board/lwmon5/gdc.c
index 0e4f0fd..aa1eee0 100644
--- a/post/board/lwmon5/gdc.c
+++ b/post/board/lwmon5/gdc.c
@@ -35,7 +35,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define GDC_SCRATCH_REG 0xC1FF8008
+#define GDC_SCRATCH_REG 0xC1FF8044
 #define GDC_VERSION_REG 0xC1FF8084
 #define GDC_RAM_START   0xC0000000
 #define GDC_RAM_END     0xC2000000
@@ -44,7 +44,7 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static int gdc_test_reg_one(uint value)
 {
-	int ret = 0;
+	int ret;
 	uint read_value;
 
 	/* write test pattern */
@@ -56,10 +56,9 @@ static int gdc_test_reg_one(uint value)
 	if (read_value != value) {
 		post_log("GDC SCRATCH test failed write %08X, read %08X\n",
 			value, read_value);
-		ret = 1;
 	}
 
-	return ret;
+	return (read_value != value);
 }
 
 /* Verify GDC, get memory size */
@@ -71,9 +70,16 @@ int gdc_post_test(int flags)
 	post_log("\n");
 	old_value = in_be32((void *)GDC_SCRATCH_REG);
 
-	if (gdc_test_reg_one(0x55555555))
+	/*
+	 * GPIOC2 register behaviour: the LIME graphics processor has a
+	 * maximum of 5 GPIO ports that can be used in this hardware
+	 * configuration. Thus only the  bits  for these 5 GPIOs can be
+	 * activated in the GPIOC2 register. All other bits will always be
+	 * read as zero.
+	 */
+	if (gdc_test_reg_one(0x00150015))
 		ret = 1;
-	if (gdc_test_reg_one(0xAAAAAAAA))
+	if (gdc_test_reg_one(0x000A000A))
 		ret = 1;
 
 	out_be32((void *)GDC_SCRATCH_REG, old_value);
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:53 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:53 +0200
Subject: [U-Boot-Users] [PATCH] Added watchdog triggering calls in the
	"mtest" test function.
In-Reply-To: <1208874293-2123-11-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
	<1208874293-2123-5-git-send-email-wd@denx.de>
	<1208874293-2123-6-git-send-email-wd@denx.de>
	<1208874293-2123-7-git-send-email-wd@denx.de>
	<1208874293-2123-8-git-send-email-wd@denx.de>
	<1208874293-2123-9-git-send-email-wd@denx.de>
	<1208874293-2123-10-git-send-email-wd@denx.de>
	<1208874293-2123-11-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-12-git-send-email-wd@denx.de>

From: Sergei Poselenov <sposelenov at emcraft.com>

Signed-off-by: Sergei Poselenov <sposelenov at emcraft.com>
---
 common/cmd_mem.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 4262e26..4740664 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -35,6 +35,7 @@
 #ifdef CONFIG_HAS_DATAFLASH
 #include <dataflash.h>
 #endif
+#include <watchdog.h>
 
 #if defined(CONFIG_CMD_MEMORY)		\
     || defined(CONFIG_CMD_I2C)		\
@@ -868,6 +869,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		    }
 		}
 		start[test_offset] = pattern;
+		WATCHDOG_RESET();
 
 		/*
 		 * Check for addr bits stuck low or shorted.
@@ -905,6 +907,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		 * Fill memory with a known pattern.
 		 */
 		for (pattern = 1, offset = 0; offset < num_words; pattern++, offset++) {
+			WATCHDOG_RESET();
 			start[offset] = pattern;
 		}
 
@@ -912,6 +915,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		 * Check each location and invert it for the second pass.
 		 */
 		for (pattern = 1, offset = 0; offset < num_words; pattern++, offset++) {
+		    WATCHDOG_RESET();
 		    temp = start[offset];
 		    if (temp != pattern) {
 			printf ("\nFAILURE (read/write) @ 0x%.8lx:"
@@ -928,6 +932,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		 * Check each location for the inverted pattern and zero it.
 		 */
 		for (pattern = 1, offset = 0; offset < num_words; pattern++, offset++) {
+		    WATCHDOG_RESET();
 		    anti_pattern = ~pattern;
 		    temp = start[offset];
 		    if (temp != anti_pattern) {
@@ -954,6 +959,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 			pattern, "");
 
 		for (addr=start,val=pattern; addr<end; addr++) {
+			WATCHDOG_RESET();
 			*addr = val;
 			val  += incr;
 		}
@@ -961,6 +967,7 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 		puts ("Reading...");
 
 		for (addr=start,val=pattern; addr<end; addr++) {
+			WATCHDOG_RESET();
 			readback = *addr;
 			if (readback != val) {
 				printf ("\nMem error @ 0x%08X: "
-- 
1.5.4.2




From wd at denx.de  Tue Apr 22 16:24:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 16:24:50 +0200
Subject: [U-Boot-Users] [PATCH] POST: preparations for moving CONFIG_POST to
	Makefiles
In-Reply-To: <1208874293-2123-8-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
	<1208874293-2123-5-git-send-email-wd@denx.de>
	<1208874293-2123-6-git-send-email-wd@denx.de>
	<1208874293-2123-7-git-send-email-wd@denx.de>
	<1208874293-2123-8-git-send-email-wd@denx.de>
Message-ID: <1208874293-2123-9-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at emcraft.com>

Remove CONFIG_POST ifdefs from the post/ source files.

Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 post/board/lwmon/sysmon.c                 |    3 ---
 post/board/lwmon5/dsp.c                   |    5 -----
 post/board/lwmon5/dspic.c                 |    4 ----
 post/board/lwmon5/fpga.c                  |    4 ----
 post/board/lwmon5/gdc.c                   |    4 ----
 post/board/lwmon5/sysmon.c                |    3 ---
 post/board/lwmon5/watchdog.c              |    4 ----
 post/board/netta/codec.c                  |    3 ---
 post/board/netta/dsp.c                    |    3 ---
 post/cpu/mpc8xx/cache.c                   |    3 ---
 post/cpu/mpc8xx/cache_8xx.S               |    2 --
 post/cpu/mpc8xx/ether.c                   |    4 ----
 post/cpu/mpc8xx/spr.c                     |    3 ---
 post/cpu/mpc8xx/uart.c                    |    4 ----
 post/cpu/mpc8xx/usb.c                     |    4 ----
 post/cpu/mpc8xx/watchdog.c                |    3 ---
 post/cpu/ppc4xx/cache.c                   |    3 ---
 post/cpu/ppc4xx/cache_4xx.S               |    3 ---
 post/cpu/ppc4xx/denali_ecc.c              |    4 ++--
 post/cpu/ppc4xx/ether.c                   |    3 ---
 post/cpu/ppc4xx/fpu.c                     |    2 --
 post/cpu/ppc4xx/spr.c                     |    3 ---
 post/cpu/ppc4xx/uart.c                    |    3 ---
 post/cpu/ppc4xx/watchdog.c                |    3 ---
 post/drivers/i2c.c                        |    3 ---
 post/drivers/memory.c                     |    3 ---
 post/drivers/rtc.c                        |    3 ---
 post/lib_ppc/andi.c                       |    3 ---
 post/lib_ppc/asm.S                        |    3 ---
 post/lib_ppc/b.c                          |    3 ---
 post/lib_ppc/cmp.c                        |    3 ---
 post/lib_ppc/cmpi.c                       |    3 ---
 post/lib_ppc/complex.c                    |    3 ---
 post/lib_ppc/cpu.c                        |    3 ---
 post/lib_ppc/cr.c                         |    3 ---
 post/lib_ppc/fpu/20001122-1.c             |    3 ---
 post/lib_ppc/fpu/20010114-2.c             |    3 ---
 post/lib_ppc/fpu/20010226-1.c             |    3 ---
 post/lib_ppc/fpu/980619-1.c               |    3 ---
 post/lib_ppc/fpu/acc1.c                   |    3 ---
 post/lib_ppc/fpu/compare-fp-1.c           |    3 ---
 post/lib_ppc/fpu/fpu.c                    |    3 ---
 post/lib_ppc/fpu/mul-subnormal-single-1.c |    3 ---
 post/lib_ppc/load.c                       |    3 ---
 post/lib_ppc/multi.c                      |    3 ---
 post/lib_ppc/rlwimi.c                     |    3 ---
 post/lib_ppc/rlwinm.c                     |    3 ---
 post/lib_ppc/rlwnm.c                      |    3 ---
 post/lib_ppc/srawi.c                      |    3 ---
 post/lib_ppc/store.c                      |    3 ---
 post/lib_ppc/string.c                     |    3 ---
 post/lib_ppc/three.c                      |    3 ---
 post/lib_ppc/threei.c                     |    3 ---
 post/lib_ppc/threex.c                     |    3 ---
 post/lib_ppc/two.c                        |    3 ---
 post/lib_ppc/twox.c                       |    3 ---
 post/post.c                               |    4 ----
 post/tests.c                              |    4 ----
 58 files changed, 2 insertions(+), 182 deletions(-)

diff --git a/post/board/lwmon/sysmon.c b/post/board/lwmon/sysmon.c
index f61d598..ea8b5a9 100644
--- a/post/board/lwmon/sysmon.c
+++ b/post/board/lwmon/sysmon.c
@@ -24,8 +24,6 @@
 #include <post.h>
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 /*
  * SYSMON test
  *
@@ -328,4 +326,3 @@ int sysmon_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_SYSMON */
-#endif /* CONFIG_POST */
diff --git a/post/board/lwmon5/dsp.c b/post/board/lwmon5/dsp.c
index 7b53af9..a96ac7d 100644
--- a/post/board/lwmon5/dsp.c
+++ b/post/board/lwmon5/dsp.c
@@ -24,11 +24,8 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
-
 #if CONFIG_POST & CFG_POST_DSP
 #include <asm/io.h>
 
@@ -54,5 +51,3 @@ int dsp_post_test(int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_DSP */
-#endif /* CONFIG_POST */
-
diff --git a/post/board/lwmon5/dspic.c b/post/board/lwmon5/dspic.c
index f1c9c15..eb1c31c 100644
--- a/post/board/lwmon5/dspic.c
+++ b/post/board/lwmon5/dspic.c
@@ -24,8 +24,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 /* There are two tests for dsPIC currently implemented:
  * 1. dsPIC ready test. Done in board_early_init_f(). Only result verified here.
  * 2. dsPIC POST result test.  This test gets dsPIC POST codes and version.
@@ -105,5 +103,3 @@ int dspic_post_test(int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_BSPEC2 */
-#endif /* CONFIG_POST */
-
diff --git a/post/board/lwmon5/fpga.c b/post/board/lwmon5/fpga.c
index 162174c..b48390b 100644
--- a/post/board/lwmon5/fpga.c
+++ b/post/board/lwmon5/fpga.c
@@ -23,8 +23,6 @@
  */
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 /* This test performs testing of FPGA SCRATCH register,
  * gets FPGA version and run get_ram_size() on FPGA memory
  */
@@ -94,5 +92,3 @@ int fpga_post_test(int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_BSPEC3 */
-#endif /* CONFIG_POST */
-
diff --git a/post/board/lwmon5/gdc.c b/post/board/lwmon5/gdc.c
index aa1eee0..bc16685 100644
--- a/post/board/lwmon5/gdc.c
+++ b/post/board/lwmon5/gdc.c
@@ -23,8 +23,6 @@
  */
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 /* This test attempts to verify board GDC. A scratch register tested, then
  * simple memory test (get_ram_size()) run over GDC memory.
  */
@@ -96,5 +94,3 @@ int gdc_post_test(int flags)
 	return ret;
 }
 #endif /* CONFIG_POST & CFG_POST_BSPEC4 */
-#endif /* CONFIG_POST */
-
diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
index f7e51a3..15661e3 100644
--- a/post/board/lwmon5/sysmon.c
+++ b/post/board/lwmon5/sysmon.c
@@ -25,8 +25,6 @@
 #include <post.h>
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 /*
  * SYSMON test
  *
@@ -245,4 +243,3 @@ int sysmon_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_SYSMON */
-#endif /* CONFIG_POST */
diff --git a/post/board/lwmon5/watchdog.c b/post/board/lwmon5/watchdog.c
index ad9e6f3..699266b 100644
--- a/post/board/lwmon5/watchdog.c
+++ b/post/board/lwmon5/watchdog.c
@@ -29,8 +29,6 @@
  * trigger watchdog reset.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_WATCHDOG
@@ -128,5 +126,3 @@ int lwmon5_watchdog_post_test(int flags)
 
 
 #endif /* CONFIG_POST & CFG_POST_WATCHDOG */
-#endif /* CONFIG_POST */
-
diff --git a/post/board/netta/codec.c b/post/board/netta/codec.c
index e881752..115e331 100644
--- a/post/board/netta/codec.c
+++ b/post/board/netta/codec.c
@@ -31,8 +31,6 @@
  * in the board specific function.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_CODEC
@@ -45,4 +43,3 @@ int codec_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_CODEC */
-#endif /* CONFIG_POST */
diff --git a/post/board/netta/dsp.c b/post/board/netta/dsp.c
index 63531a2..dcef4e8 100644
--- a/post/board/netta/dsp.c
+++ b/post/board/netta/dsp.c
@@ -31,8 +31,6 @@
  * in the board specific function.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_DSP
@@ -45,4 +43,3 @@ int dsp_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_DSP */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/mpc8xx/cache.c b/post/cpu/mpc8xx/cache.c
index 501465c..36965a1 100644
--- a/post/cpu/mpc8xx/cache.c
+++ b/post/cpu/mpc8xx/cache.c
@@ -29,8 +29,6 @@
  * several test scenarios.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include <watchdog.h>
 
@@ -78,4 +76,3 @@ int cache_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_CACHE */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/mpc8xx/cache_8xx.S b/post/cpu/mpc8xx/cache_8xx.S
index 2d41b55..a3fc39b 100644
--- a/post/cpu/mpc8xx/cache_8xx.S
+++ b/post/cpu/mpc8xx/cache_8xx.S
@@ -22,7 +22,6 @@
 
 #include <config.h>
 
-#ifdef CONFIG_POST
 #if defined(CONFIG_MPC823) || \
     defined(CONFIG_MPC850) || \
     defined(CONFIG_MPC855) || \
@@ -492,4 +491,3 @@ cache_post_test6_data:
 
 #endif /* CONFIG_MPC823 || MPC850 || MPC855 || MPC860 */
 #endif /* CONFIG_POST & CFG_POST_CACHE */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/mpc8xx/ether.c b/post/cpu/mpc8xx/ether.c
index 8c87b59..2fa5cf4 100644
--- a/post/cpu/mpc8xx/ether.c
+++ b/post/cpu/mpc8xx/ether.c
@@ -35,8 +35,6 @@
  *   TEST_NUM - number of tests
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #if CONFIG_POST & CFG_POST_ETHER
 #if defined(CONFIG_8xx)
@@ -627,5 +625,3 @@ int ether_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_ETHER */
-
-#endif /* CONFIG_POST */
diff --git a/post/cpu/mpc8xx/spr.c b/post/cpu/mpc8xx/spr.c
index 330b977..83f04da 100644
--- a/post/cpu/mpc8xx/spr.c
+++ b/post/cpu/mpc8xx/spr.c
@@ -33,8 +33,6 @@
  * corresponding table value.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_SPR
@@ -149,4 +147,3 @@ int spr_post_test (int flags)
 	return ret;
 }
 #endif /* CONFIG_POST & CFG_POST_SPR */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/mpc8xx/uart.c b/post/cpu/mpc8xx/uart.c
index fd97e38..635debe 100644
--- a/post/cpu/mpc8xx/uart.c
+++ b/post/cpu/mpc8xx/uart.c
@@ -36,8 +36,6 @@
  *   TEST_NUM - number of tests
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #if CONFIG_POST & CFG_POST_UART
 #if defined(CONFIG_8xx)
@@ -556,5 +554,3 @@ int uart_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_UART */
-
-#endif /* CONFIG_POST */
diff --git a/post/cpu/mpc8xx/usb.c b/post/cpu/mpc8xx/usb.c
index 0c74cfa..5877981 100644
--- a/post/cpu/mpc8xx/usb.c
+++ b/post/cpu/mpc8xx/usb.c
@@ -34,8 +34,6 @@
  * Initialization Example.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_USB
@@ -265,5 +263,3 @@ int usb_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_USB */
-
-#endif /* CONFIG_POST */
diff --git a/post/cpu/mpc8xx/watchdog.c b/post/cpu/mpc8xx/watchdog.c
index 48c4282..f94158a 100644
--- a/post/cpu/mpc8xx/watchdog.c
+++ b/post/cpu/mpc8xx/watchdog.c
@@ -33,8 +33,6 @@
  * reboots, on the second iteration the test routine reports a success.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include <watchdog.h>
 
@@ -75,4 +73,3 @@ int watchdog_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_WATCHDOG */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/ppc4xx/cache.c b/post/cpu/ppc4xx/cache.c
index 466ca92..be6a2bf 100644
--- a/post/cpu/ppc4xx/cache.c
+++ b/post/cpu/ppc4xx/cache.c
@@ -31,8 +31,6 @@
  * several test scenarios.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_CACHE
@@ -122,4 +120,3 @@ int cache_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_CACHE */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/ppc4xx/cache_4xx.S b/post/cpu/ppc4xx/cache_4xx.S
index d5cb075..455ffa0 100644
--- a/post/cpu/ppc4xx/cache_4xx.S
+++ b/post/cpu/ppc4xx/cache_4xx.S
@@ -25,8 +25,6 @@
 
 #include <config.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include <ppc_asm.tmpl>
 #include <ppc_defs.h>
@@ -489,4 +487,3 @@ cache_post_test_inst:
 	blr
 
 #endif /* CONFIG_POST & CFG_POST_CACHE */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/ppc4xx/denali_ecc.c b/post/cpu/ppc4xx/denali_ecc.c
index 439f80d..12a1bbf 100644
--- a/post/cpu/ppc4xx/denali_ecc.c
+++ b/post/cpu/ppc4xx/denali_ecc.c
@@ -31,7 +31,7 @@
 #include <common.h>
 #include <watchdog.h>
 
-#if defined(CONFIG_POST) && (defined(CONFIG_440EPX) || defined(CONFIG_440GRX))
+#if defined(CONFIG_440EPX) || defined(CONFIG_440GRX)
 
 #include <post.h>
 
@@ -268,4 +268,4 @@ int ecc_post_test(int flags)
 	return ret;
 }
 #endif /* CONFIG_POST & CFG_POST_ECC */
-#endif /* defined(CONFIG_POST) && ... */
+#endif /* defined(CONFIG_440EPX) || defined(CONFIG_440GRX) */
diff --git a/post/cpu/ppc4xx/ether.c b/post/cpu/ppc4xx/ether.c
index 4ac7491..ccbfcf9 100644
--- a/post/cpu/ppc4xx/ether.c
+++ b/post/cpu/ppc4xx/ether.c
@@ -37,8 +37,6 @@
  *   TEST_NUM - number of tests
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_ETHER
@@ -430,4 +428,3 @@ out_free:
 }
 
 #endif /* CONFIG_POST & CFG_POST_ETHER */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/ppc4xx/fpu.c b/post/cpu/ppc4xx/fpu.c
index 0c26fe0..fff4169 100644
--- a/post/cpu/ppc4xx/fpu.c
+++ b/post/cpu/ppc4xx/fpu.c
@@ -25,7 +25,6 @@
 
 #include <config.h>
 
-#ifdef CONFIG_POST
 #if defined(CONFIG_440EP) || \
     defined(CONFIG_440EPX)
 
@@ -56,4 +55,3 @@ void fpu_enable(void)
 }
 
 #endif
-#endif /* CONFIG_POST */
diff --git a/post/cpu/ppc4xx/spr.c b/post/cpu/ppc4xx/spr.c
index 37c9559..6152eb2 100644
--- a/post/cpu/ppc4xx/spr.c
+++ b/post/cpu/ppc4xx/spr.c
@@ -35,8 +35,6 @@
  * corresponding table value.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_SPR
@@ -199,4 +197,3 @@ int spr_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_SPR */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/ppc4xx/uart.c b/post/cpu/ppc4xx/uart.c
index f47b48e..27cfb91 100644
--- a/post/cpu/ppc4xx/uart.c
+++ b/post/cpu/ppc4xx/uart.c
@@ -32,8 +32,6 @@
  * characters are transmitted.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_UART
@@ -389,4 +387,3 @@ int uart_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_UART */
-#endif /* CONFIG_POST */
diff --git a/post/cpu/ppc4xx/watchdog.c b/post/cpu/ppc4xx/watchdog.c
index bd4f4c9..7fdecb4 100644
--- a/post/cpu/ppc4xx/watchdog.c
+++ b/post/cpu/ppc4xx/watchdog.c
@@ -35,8 +35,6 @@
  * reboots, on the second iteration the test routine reports a success.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_WATCHDOG
@@ -68,4 +66,3 @@ int watchdog_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_WATCHDOG */
-#endif /* CONFIG_POST */
diff --git a/post/drivers/i2c.c b/post/drivers/i2c.c
index 1b2e644..f54fe99 100644
--- a/post/drivers/i2c.c
+++ b/post/drivers/i2c.c
@@ -23,8 +23,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 /*
  * I2C test
  *
@@ -91,4 +89,3 @@ int i2c_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_I2C */
-#endif /* CONFIG_POST */
diff --git a/post/drivers/memory.c b/post/drivers/memory.c
index fb96985..e94d92c 100644
--- a/post/drivers/memory.c
+++ b/post/drivers/memory.c
@@ -150,8 +150,6 @@
  * the whole RAM.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include <watchdog.h>
 
@@ -483,4 +481,3 @@ int memory_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_MEMORY */
-#endif /* CONFIG_POST */
diff --git a/post/drivers/rtc.c b/post/drivers/rtc.c
index 7d4f9b8..4afe8e6 100644
--- a/post/drivers/rtc.c
+++ b/post/drivers/rtc.c
@@ -38,8 +38,6 @@
  *      nonleap-years.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include <rtc.h>
 
@@ -180,4 +178,3 @@ int rtc_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_RTC */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/andi.c b/post/lib_ppc/andi.c
index 7ddf2ab..e3315bf 100644
--- a/post/lib_ppc/andi.c
+++ b/post/lib_ppc/andi.c
@@ -32,8 +32,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -120,4 +118,3 @@ int cpu_post_test_andi (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/asm.S b/post/lib_ppc/asm.S
index 1279176..6220ed2 100644
--- a/post/lib_ppc/asm.S
+++ b/post/lib_ppc/asm.S
@@ -22,8 +22,6 @@
 
 #include <config.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include <ppc_asm.tmpl>
 #include <ppc_defs.h>
@@ -358,4 +356,3 @@ cpu_post_complex_2_loop:
 blr
 
 #endif
-#endif
diff --git a/post/lib_ppc/b.c b/post/lib_ppc/b.c
index 6e276c4..45b9ff2 100644
--- a/post/lib_ppc/b.c
+++ b/post/lib_ppc/b.c
@@ -37,8 +37,6 @@
  * linked in U-Boot at build time.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -194,4 +192,3 @@ int cpu_post_test_b (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/cmp.c b/post/lib_ppc/cmp.c
index 789a24c..89f754a 100644
--- a/post/lib_ppc/cmp.c
+++ b/post/lib_ppc/cmp.c
@@ -36,8 +36,6 @@
  * the result in and the expected result.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -130,4 +128,3 @@ int cpu_post_test_cmp (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/cmpi.c b/post/lib_ppc/cmpi.c
index e0c2aaf..0afdd71 100644
--- a/post/lib_ppc/cmpi.c
+++ b/post/lib_ppc/cmpi.c
@@ -36,8 +36,6 @@
  * the result in and the expected result.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -130,4 +128,3 @@ int cpu_post_test_cmpi (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/complex.c b/post/lib_ppc/complex.c
index 033584b..271392a 100644
--- a/post/lib_ppc/complex.c
+++ b/post/lib_ppc/complex.c
@@ -31,8 +31,6 @@
  * calculations, but probably under different timing conditions, etc.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -123,4 +121,3 @@ int cpu_post_test_complex (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/cpu.c b/post/lib_ppc/cpu.c
index 4ab6d2d..5c7f761 100644
--- a/post/lib_ppc/cpu.c
+++ b/post/lib_ppc/cpu.c
@@ -32,8 +32,6 @@
  * For more details refer to post/cpu/ *.c files.
  */
 
-#ifdef CONFIG_POST
-
 #include <watchdog.h>
 #include <post.h>
 #include <asm/mmu.h>
@@ -147,4 +145,3 @@ int cpu_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_CPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/cr.c b/post/lib_ppc/cr.c
index da6ef37..0bd9e74 100644
--- a/post/lib_ppc/cr.c
+++ b/post/lib_ppc/cr.c
@@ -46,8 +46,6 @@
  * expected one.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -353,4 +351,3 @@ int cpu_post_test_cr (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/fpu/20001122-1.c b/post/lib_ppc/fpu/20001122-1.c
index f689b82..dece614 100644
--- a/post/lib_ppc/fpu/20001122-1.c
+++ b/post/lib_ppc/fpu/20001122-1.c
@@ -26,8 +26,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_FPU
@@ -59,4 +57,3 @@ int fpu_post_test_math1 (void)
 }
 
 #endif /* CONFIG_POST & CFG_POST_FPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/fpu/20010114-2.c b/post/lib_ppc/fpu/20010114-2.c
index 6e60507..8a17217 100644
--- a/post/lib_ppc/fpu/20010114-2.c
+++ b/post/lib_ppc/fpu/20010114-2.c
@@ -26,8 +26,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_FPU
@@ -63,4 +61,3 @@ int fpu_post_test_math2 (void)
 }
 
 #endif /* CONFIG_POST & CFG_POST_FPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/fpu/20010226-1.c b/post/lib_ppc/fpu/20010226-1.c
index b2c47e3..f366252 100644
--- a/post/lib_ppc/fpu/20010226-1.c
+++ b/post/lib_ppc/fpu/20010226-1.c
@@ -26,8 +26,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_FPU
@@ -51,4 +49,3 @@ int fpu_post_test_math3 (void)
 }
 
 #endif /* CONFIG_POST & CFG_POST_FPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/fpu/980619-1.c b/post/lib_ppc/fpu/980619-1.c
index 990aa0c..7f26482 100644
--- a/post/lib_ppc/fpu/980619-1.c
+++ b/post/lib_ppc/fpu/980619-1.c
@@ -26,8 +26,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_FPU
@@ -57,4 +55,3 @@ int fpu_post_test_math4 (void)
 }
 
 #endif /* CONFIG_POST & CFG_POST_FPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/fpu/acc1.c b/post/lib_ppc/fpu/acc1.c
index 4cecbf6..921282e 100644
--- a/post/lib_ppc/fpu/acc1.c
+++ b/post/lib_ppc/fpu/acc1.c
@@ -26,8 +26,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_FPU
@@ -54,4 +52,3 @@ int fpu_post_test_math5 (void)
 }
 
 #endif /* CONFIG_POST & CFG_POST_FPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/fpu/compare-fp-1.c b/post/lib_ppc/fpu/compare-fp-1.c
index d866ad5..be8f620 100644
--- a/post/lib_ppc/fpu/compare-fp-1.c
+++ b/post/lib_ppc/fpu/compare-fp-1.c
@@ -28,8 +28,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_FPU
@@ -222,4 +220,3 @@ int fpu_post_test_math6 (void)
 }
 
 #endif /* CONFIG_POST & CFG_POST_FPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/fpu/fpu.c b/post/lib_ppc/fpu/fpu.c
index 07dcba8..9ddb67a 100644
--- a/post/lib_ppc/fpu/fpu.c
+++ b/post/lib_ppc/fpu/fpu.c
@@ -34,8 +34,6 @@
  * For more details refer to post/cpu/ *.c files.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_FPU
@@ -89,4 +87,3 @@ int fpu_post_test (int flags)
 }
 
 #endif /* CONFIG_POST & CFG_POST_FPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/fpu/mul-subnormal-single-1.c b/post/lib_ppc/fpu/mul-subnormal-single-1.c
index 67f48da..7e6fe87 100644
--- a/post/lib_ppc/fpu/mul-subnormal-single-1.c
+++ b/post/lib_ppc/fpu/mul-subnormal-single-1.c
@@ -28,8 +28,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 #if CONFIG_POST & CFG_POST_FPU
@@ -100,4 +98,3 @@ int fpu_post_test_math7 (void)
 }
 
 #endif /* CONFIG_POST & CFG_POST_FPU */
-#endif /* CONFIG_POST */
diff --git a/post/lib_ppc/load.c b/post/lib_ppc/load.c
index 393c568..86bc223 100644
--- a/post/lib_ppc/load.c
+++ b/post/lib_ppc/load.c
@@ -41,8 +41,6 @@
  * register (it must change for "load with update" instructions).
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -252,4 +250,3 @@ int cpu_post_test_load (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/multi.c b/post/lib_ppc/multi.c
index 8724384..5d3f584 100644
--- a/post/lib_ppc/multi.c
+++ b/post/lib_ppc/multi.c
@@ -33,8 +33,6 @@
  * of the source and target buffers are then compared.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -78,4 +76,3 @@ int cpu_post_test_multi (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/rlwimi.c b/post/lib_ppc/rlwimi.c
index f65f79a..1d8e61e 100644
--- a/post/lib_ppc/rlwimi.c
+++ b/post/lib_ppc/rlwimi.c
@@ -32,8 +32,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -159,4 +157,3 @@ int cpu_post_test_rlwimi (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/rlwinm.c b/post/lib_ppc/rlwinm.c
index e240c41..113e79d 100644
--- a/post/lib_ppc/rlwinm.c
+++ b/post/lib_ppc/rlwinm.c
@@ -32,8 +32,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -152,4 +150,3 @@ int cpu_post_test_rlwinm (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/rlwnm.c b/post/lib_ppc/rlwnm.c
index 523cf4d..a6684bf 100644
--- a/post/lib_ppc/rlwnm.c
+++ b/post/lib_ppc/rlwnm.c
@@ -32,8 +32,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -162,4 +160,3 @@ int cpu_post_test_rlwnm (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/srawi.c b/post/lib_ppc/srawi.c
index 91c82c9..8c70007 100644
--- a/post/lib_ppc/srawi.c
+++ b/post/lib_ppc/srawi.c
@@ -32,8 +32,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -153,4 +151,3 @@ int cpu_post_test_srawi (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/store.c b/post/lib_ppc/store.c
index f495bf2..09ec485 100644
--- a/post/lib_ppc/store.c
+++ b/post/lib_ppc/store.c
@@ -41,8 +41,6 @@
  * with update" instructions).
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -232,4 +230,3 @@ int cpu_post_test_store (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/string.c b/post/lib_ppc/string.c
index bd83bd1..b2daa88 100644
--- a/post/lib_ppc/string.c
+++ b/post/lib_ppc/string.c
@@ -33,8 +33,6 @@
  * of the source and target buffers are then compared.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -103,4 +101,3 @@ int cpu_post_test_string (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/three.c b/post/lib_ppc/three.c
index c2d7476..a7f1a86 100644
--- a/post/lib_ppc/three.c
+++ b/post/lib_ppc/three.c
@@ -35,8 +35,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -256,4 +254,3 @@ int cpu_post_test_three (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/threei.c b/post/lib_ppc/threei.c
index 79f0178..bbb4f50 100644
--- a/post/lib_ppc/threei.c
+++ b/post/lib_ppc/threei.c
@@ -34,8 +34,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -134,4 +132,3 @@ int cpu_post_test_threei (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/threex.c b/post/lib_ppc/threex.c
index 2c72063..6aac937 100644
--- a/post/lib_ppc/threex.c
+++ b/post/lib_ppc/threex.c
@@ -35,8 +35,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -226,4 +224,3 @@ int cpu_post_test_threex (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/two.c b/post/lib_ppc/two.c
index cfbac5e..3d6b3c0 100644
--- a/post/lib_ppc/two.c
+++ b/post/lib_ppc/two.c
@@ -35,8 +35,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -173,4 +171,3 @@ int cpu_post_test_two (void)
 }
 
 #endif
-#endif
diff --git a/post/lib_ppc/twox.c b/post/lib_ppc/twox.c
index 48d9954..7417a36 100644
--- a/post/lib_ppc/twox.c
+++ b/post/lib_ppc/twox.c
@@ -35,8 +35,6 @@
  * different sets of operand registers and result registers.
  */
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 #include "cpu_asm.h"
 
@@ -173,4 +171,3 @@ int cpu_post_test_twox (void)
 }
 
 #endif
-#endif
diff --git a/post/post.c b/post/post.c
index 1df0657..c016c3a 100644
--- a/post/post.c
+++ b/post/post.c
@@ -30,8 +30,6 @@
 #include <logbuff.h>
 #endif
 
-#ifdef CONFIG_POST
-
 DECLARE_GLOBAL_DATA_PTR;
 
 #define POST_MAX_NUMBER		32
@@ -442,5 +440,3 @@ unsigned long post_time_ms (unsigned long base)
 	return 0; /* Not implemented yet */
 #endif
 }
-
-#endif /* CONFIG_POST */
diff --git a/post/tests.c b/post/tests.c
index 53d01e3..36473e3 100644
--- a/post/tests.c
+++ b/post/tests.c
@@ -27,8 +27,6 @@
 
 #include <common.h>
 
-#ifdef CONFIG_POST
-
 #include <post.h>
 
 extern int cache_post_test (int flags);
@@ -278,5 +276,3 @@ struct post_test post_list[] =
 };
 
 unsigned int post_list_size = sizeof (post_list) / sizeof (struct post_test);
-
-#endif /* CONFIG_POST */
-- 
1.5.4.2




From afleming at freescale.com  Tue Apr 22 17:07:46 2008
From: afleming at freescale.com (Andy Fleming)
Date: Tue, 22 Apr 2008 10:07:46 -0500
Subject: [U-Boot-Users] [PATCH] Add eSDHC driver
In-Reply-To: <001a01c8a46f$b85e1dc0$291a5940$@savary@kerlink.fr>
References: <001a01c8a46f$b85e1dc0$291a5940$@savary@kerlink.fr>
Message-ID: <1208876866-11251-1-git-send-email-afleming@freescale.com>

This is the SD/MMC controller on several of Freescale's more recent parts
---
> Hi Andy,
> Where could we find the driver that works with MMCv4 on at91sam9x?
> Best regards

Pierre, I don't have a driver that works on at91sam9x, I'm afraid.  I have
a driver that nearly works on an mpc837x.  However, some of it is certainly
right, and that may help you.  Also, some of it is wrong (I get intermittent
failures on MMC cards), and maybe someone will look at this driver, and see what
I'm doing wrong.


 Makefile                           |    2 +
 drivers/mmc/Makefile               |   46 ++
 drivers/mmc/fsl_esdhc.c            | 1111 ++++++++++++++++++++++++++++++++++++
 drivers/mmc/fsl_esdhc.h            |  208 +++++++
 include/asm-ppc/arch-mpc83xx/mmc.h |    1 +
 5 files changed, 1368 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mmc/Makefile
 create mode 100644 drivers/mmc/fsl_esdhc.c
 create mode 100644 drivers/mmc/fsl_esdhc.h
 create mode 100644 include/asm-ppc/arch-mpc83xx/mmc.h

diff --git a/Makefile b/Makefile
index e5b4210..cd614a5 100644
--- a/Makefile
+++ b/Makefile
@@ -214,6 +214,7 @@ LIBS += drivers/hwmon/libhwmon.a
 LIBS += drivers/i2c/libi2c.a
 LIBS += drivers/input/libinput.a
 LIBS += drivers/misc/libmisc.a
+LIBS += drivers/mmc/libmmc.a
 LIBS += drivers/mtd/libmtd.a
 LIBS += drivers/mtd/nand/libnand.a
 LIBS += drivers/mtd/nand_legacy/libnand_legacy.a
@@ -383,6 +384,7 @@ TAG_SUBDIRS += drivers/hwmon
 TAG_SUBDIRS += drivers/i2c
 TAG_SUBDIRS += drivers/input
 TAG_SUBDIRS += drivers/misc
+TAG_SUBDIRS += drivers/mmc
 TAG_SUBDIRS += drivers/mtd
 TAG_SUBDIRS += drivers/mtd/nand
 TAG_SUBDIRS += drivers/mtd/nand_legacy
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
new file mode 100644
index 0000000..06e4e88
--- /dev/null
+++ b/drivers/mmc/Makefile
@@ -0,0 +1,46 @@
+#
+# (C) Copyright 2006
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB 	:= $(obj)libmmc.a
+
+COBJS-y += fsl_esdhc.o
+
+COBJS	:= $(COBJS-y)
+SRCS 	:= $(COBJS:.o=.c)
+OBJS 	:= $(addprefix $(obj),$(COBJS))
+
+all:	$(LIB)
+
+$(LIB):	$(obj).depend $(OBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS)
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
new file mode 100644
index 0000000..29af92a
--- /dev/null
+++ b/drivers/mmc/fsl_esdhc.c
@@ -0,0 +1,1111 @@
+/*
+ * Copyright 2007, Freescale Semiconductor, Inc
+ * Andy Fleming
+ *
+ * Based vaguely on the pxa mmc code:
+ * (C) Copyright 2003
+ * Kyle Harris, Nexus Technologies, Inc. kharris at nexus-tech.net
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <config.h>
+#include <common.h>
+#include <command.h>
+#include <mmc.h>
+#include <part.h>
+#include <malloc.h>
+#include <asm/io.h>
+
+#include "fsl_esdhc.h"
+
+#ifdef CONFIG_MMC
+DECLARE_GLOBAL_DATA_PTR;
+
+struct fsl_esdhc {
+	uint	dsaddr;
+	uint	blkattr;
+	uint	cmdarg;
+	uint	xfertyp;
+	uint	cmdrsp0;
+	uint	cmdrsp1;
+	uint	cmdrsp2;
+	uint	cmdrsp3;
+	uint	datport;
+	uint	prsstat;
+	uint	proctl;
+	uint	sysctl;
+	uint	irqstat;
+	uint	irqstaten;
+	uint	irqsigen;
+	uint	autoc12err;
+	uint	hostcapblt;
+	uint	wml;
+	char	reserved1[8];
+	uint	fevt;
+	char	reserved2[168];
+	uint	hostver;
+	char	reserved3[780];
+	uint	scr;
+};
+
+enum {
+	MMC_CMD_RSP_NONE,
+	MMC_CMD_R1 = 1,
+	MMC_CMD_R1b,
+	MMC_CMD_R2,
+	MMC_CMD_R3,
+	MMC_CMD_R4,
+	MMC_CMD_R5,
+	MMC_CMD_R5b,
+	MMC_CMD_R6,
+	MMC_CMD_R7
+};
+
+uint	xfertyps[] = {
+	XFERTYP_RSPTYP_NONE,
+	XFERTYP_RSPTYP_48 | XFERTYP_CICEN | XFERTYP_CCCEN,
+	XFERTYP_RSPTYP_48_BUSY | XFERTYP_CICEN | XFERTYP_CCCEN,
+	XFERTYP_RSPTYP_136 | XFERTYP_CCCEN,
+	XFERTYP_RSPTYP_48,
+	XFERTYP_RSPTYP_48,
+	XFERTYP_RSPTYP_48 | XFERTYP_CICEN | XFERTYP_CCCEN,
+	XFERTYP_RSPTYP_48_BUSY | XFERTYP_CICEN | XFERTYP_CCCEN,
+	XFERTYP_RSPTYP_48 | XFERTYP_CICEN | XFERTYP_CCCEN,
+	XFERTYP_RSPTYP_48 | XFERTYP_CICEN | XFERTYP_CCCEN
+};
+
+struct mmc {
+	volatile void *	regs;
+	uint version;
+	int high_capacity;
+	uint mode;
+	uint ocr;
+	uint scr[2];
+	uint csd[4];
+	char cid[16];
+	ushort rca;
+	uint tran_speed;
+	uint read_bl_len;
+	uint write_bl_len;
+	u64 capacity;
+	block_dev_desc_t block_dev;
+};
+
+static struct mmc *mmc_dev;
+
+block_dev_desc_t *mmc_get_dev(int dev)
+{
+	return (dev == 0) ? &mmc_dev->block_dev : NULL;
+}
+
+struct mmc_cmd {
+	ushort	cmdidx;
+	int	resp_type;
+	uint	cmdarg;
+	char	response[18];
+	uint	flags;
+};
+
+struct mmc_data {
+	char *	buffer;
+	uint	flags;
+	int	blocks;
+	int	blocksize;
+};
+
+/* Return the XFERTYP flags for a given command and data packet */
+uint esdhc_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
+{
+	uint xfertyp = 0;
+
+	if (data) {
+		xfertyp |= XFERTYP_DPSEL | XFERTYP_DMAEN;
+
+		if (data->blocks > 1) {
+			xfertyp |= XFERTYP_MSBSEL;
+			xfertyp |= XFERTYP_BCEN;
+		}
+
+		if (data->flags & MMC_DATA_READ)
+			xfertyp |= XFERTYP_DTDSEL;
+	}
+
+	xfertyp |= xfertyps[cmd->resp_type];
+
+	return xfertyp;
+}
+
+
+/*
+ * Sends a command out on the bus.  Takes the mmc pointer,
+ * a command pointer, and an optional data pointer.
+ */
+static int
+mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct mmc_data *data)
+{
+	uint	xfertyp;
+	uint	irqstat;
+	volatile struct fsl_esdhc *regs = mmc->regs;
+
+	regs->irqstat = -1;
+
+	sync();
+
+	/* Wait for the bus to be idle */
+	while ((regs->prsstat & PRSSTAT_CICHB) ||
+			(regs->prsstat & PRSSTAT_CIDHB))
+		sync();
+
+	while (regs->prsstat & PRSSTAT_DLA)
+		sync();
+
+	/* Wait at least 8 SD clock cycles before the next command */
+	/*
+	 * Note: This is way more than 8 cycles, but 1ms seems to
+	 * resolve timing issues with some cards
+	 */
+	udelay(1000);
+
+	/* Set up for a data transfer if we have one */
+	if (data) {
+		uint wml_value;
+		int timeout;
+
+		wml_value = data->blocksize/4;
+
+		if (data->flags & MMC_DATA_READ) {
+			if (wml_value > 0x10)
+				wml_value = 0x10;
+
+			wml_value = 0x100000 | wml_value;
+		} else {
+			if (wml_value > 0x80)
+				wml_value = 0x80;
+
+			wml_value = wml_value << 16 | 0x10;
+		}
+
+		regs->dsaddr = (uint)data->buffer;
+
+		sync();
+
+		regs->wml = wml_value;
+
+		sync();
+
+		regs->blkattr = data->blocks << 16 | data->blocksize;
+
+		sync();
+
+		timeout = __ilog2(mmc->tran_speed/10);
+		timeout -= 13;
+
+		if (timeout > 14)
+			timeout = 14;
+
+		if (timeout < 0)
+			timeout = 0;
+
+		regs->sysctl &= ~0x000f0000;
+
+		sync();
+
+		regs->sysctl |= timeout << 16;
+
+		sync();
+	}
+
+	/* Figure out the transfer arguments */
+	xfertyp = esdhc_xfertyp(cmd, data);
+
+	/* Send the command */
+	regs->cmdarg = cmd->cmdarg;
+	sync();
+	regs->xfertyp = XFERTYP_CMD(cmd->cmdidx) | xfertyp;
+
+	sync();
+	/* Wait for the command to complete */
+	while (!(regs->irqstat & IRQSTAT_CC))
+		sync();
+
+	irqstat = regs->irqstat;
+
+	sync();
+
+	regs->irqstat = irqstat;
+
+	sync();
+
+	if (irqstat & CMD_ERR)
+		return COMM_ERR;
+
+	if (irqstat & IRQSTAT_CTOE)
+		return TIMEOUT;
+
+	/* Copy the response to the response buffer */
+	if (cmd->resp_type == MMC_CMD_R2) {
+		((uint *)(cmd->response))[0] =
+			(regs->cmdrsp3 << 8) | (regs->cmdrsp2 >> 24);
+		((uint *)(cmd->response))[1] =
+			(regs->cmdrsp2 << 8) | (regs->cmdrsp1 >> 24);
+		((uint *)(cmd->response))[2] =
+			(regs->cmdrsp1 << 8) | (regs->cmdrsp0 >> 24);
+		((uint *)(cmd->response))[3] = (regs->cmdrsp0 << 8);
+	} else
+		((uint *)(cmd->response))[0] = regs->cmdrsp0;
+
+	/* Wait until all of the blocks are transferred */
+	if (data) {
+		do {
+			irqstat = regs->irqstat;
+
+			if (irqstat & DATA_ERR)
+				return COMM_ERR;
+
+			if (irqstat & IRQSTAT_DTOE)
+				return TIMEOUT;
+			sync();
+		} while (!(irqstat & IRQSTAT_TC) &&
+				(regs->prsstat & PRSSTAT_DLA));
+	}
+
+	regs->irqstat = -1;
+	sync();
+
+	return 0;
+}
+
+void set_sysctl(struct mmc *mmc, int clock)
+{
+	int sdhc_clk = gd->sdhc_clk;
+	int div, pre_div;
+	volatile struct fsl_esdhc *regs = mmc->regs;
+	uint clk;
+
+	if (sdhc_clk / 16 > clock) {
+		for (pre_div = 2; pre_div < 256; pre_div *= 2)
+			if ((sdhc_clk / pre_div) <= (clock * 16))
+				break;
+	} else
+		pre_div = 2;
+
+	for (div = 1; div <= 16; div++)
+		if ((sdhc_clk / (div * pre_div)) <= clock)
+			break;
+
+	pre_div >>= 1;
+	div -= 1;
+
+	clk = (pre_div << 8) | (div << 4);
+	regs->sysctl &= ~0x0000fff0;
+	sync();
+	regs->sysctl |= clk;
+	sync();
+
+	udelay(10000);
+
+	regs->sysctl |= SYSCTL_PEREN;
+}
+
+
+int
+mmc_block_write(ulong dst, uchar *src, int len)
+{
+#warning write not yet implemented
+	return 0;
+}
+
+int mmc_set_blocklen(struct mmc *mmc, int len)
+{
+	struct mmc_cmd cmd;
+
+	cmd.cmdidx = SET_BLOCKLEN;
+	cmd.resp_type = MMC_CMD_R1;
+	cmd.cmdarg = len;
+	cmd.flags = 0;
+
+	return mmc_send_cmd(mmc, &cmd, NULL);
+}
+
+int
+mmc_read(ulong src, uchar *dst, int size)
+{
+	struct mmc_cmd cmd;
+	struct mmc_data data;
+	int err;
+	char * buffer;
+	int stoperr = 0;
+	struct mmc *mmc = mmc_dev;
+	int blklen = mmc->read_bl_len;
+	int startblock = src / blklen;
+	int endblock = (src + size - 1) / blklen;
+	int blkcnt = endblock - startblock + 1;
+
+	/* Make a buffer big enough to hold all the blocks we might read */
+	buffer = malloc(blkcnt * blklen);
+
+	if (!buffer) {
+		printf("Could not allocate buffer for MMC read!\n");
+		return -1;
+	}
+
+#warning deal with larger reads (more than 65536 blks) and partial block reads
+	/* We only support full block reads from the card */
+	err = mmc_set_blocklen(mmc, mmc->read_bl_len);
+
+	if (err)
+		return err;
+
+	if (blkcnt > 1)
+		cmd.cmdidx = READ_MULTIPLE_BLOCKS;
+	else
+		cmd.cmdidx = READ_SINGLE_BLOCK;
+
+	if (mmc->high_capacity)
+		cmd.cmdarg = startblock;
+	else
+		cmd.cmdarg = startblock * blklen;
+
+	cmd.resp_type = MMC_CMD_R1;
+	cmd.flags = 0;
+
+	data.buffer = buffer;
+	data.blocks = blkcnt;
+	data.blocksize = blklen;
+	data.flags = MMC_DATA_READ;
+
+	err = mmc_send_cmd(mmc, &cmd, &data);
+
+	if (blkcnt > 1) {
+		cmd.cmdidx = STOP_TRANSMISSION;
+		cmd.cmdarg = 0;
+		cmd.resp_type = MMC_CMD_R1b;
+		cmd.flags = 0;
+		stoperr = mmc_send_cmd(mmc, &cmd, NULL);
+	}
+
+
+	if (err)
+		return err;
+
+	memcpy(dst, buffer + (src & (blklen - 1)), size);
+
+	free(buffer);
+
+	return stoperr;
+}
+
+int
+mmc_write(uchar *src, ulong dst, int size)
+{
+	return 0;
+}
+
+ulong
+mmc_bread(int dev_num, ulong blknr, ulong blkcnt, void *dst)
+{
+	int err;
+	ulong src = blknr * mmc_dev->read_bl_len;
+
+	err = mmc_read(src, dst, blkcnt * mmc_dev->read_bl_len);
+
+	if (err) {
+		printf("block read failed: %d\n", err);
+		return 0;
+	}
+
+	return blkcnt;
+}
+
+int mmc_go_idle(struct mmc* mmc)
+{
+	struct mmc_cmd cmd;
+	int err;
+
+	udelay(1000);
+
+	cmd.cmdidx = GO_IDLE_STATE;
+	cmd.cmdarg = 0;
+	cmd.resp_type = MMC_CMD_RSP_NONE;
+	cmd.flags = 0;
+
+	err = mmc_send_cmd(mmc, &cmd, NULL);
+
+	if (err)
+		return err;
+
+	udelay(2000);
+
+	return 0;
+}
+
+int
+sd_send_op_cond(struct mmc *mmc)
+{
+	int timeout = 1000;
+	int err;
+	struct mmc_cmd cmd;
+
+	do {
+		cmd.cmdidx = APP_CMD;
+		cmd.resp_type = MMC_CMD_R1;
+		cmd.cmdarg = 0;
+		cmd.flags = 0;
+
+		err = mmc_send_cmd(mmc, &cmd, NULL);
+
+		if (err)
+			return err;
+
+		cmd.cmdidx = SD_SEND_OP_COND;
+		cmd.resp_type = MMC_CMD_R3;
+		cmd.cmdarg = 0xff8000;
+
+		if (mmc->version == SD_VERSION_2)
+			cmd.cmdarg |= 0x40000000;
+
+		err = mmc_send_cmd(mmc, &cmd, NULL);
+
+		if (err)
+			return err;
+
+		udelay(1000);
+	} while ((!(cmd.response[0] & OCR_BUSY)) && timeout--);
+
+	if (timeout <= 0)
+		return UNUSABLE_ERR;
+
+	if (mmc->version != SD_VERSION_2)
+		mmc->version = SD_VERSION_1_0;
+
+	mmc->ocr = ((uint *)(cmd.response))[0];
+
+	mmc->high_capacity = ((mmc->ocr & OCR_HCS) == OCR_HCS);
+	mmc->rca = 0;
+
+	return 0;
+}
+
+int mmc_send_op_cond(struct mmc *mmc)
+{
+	int timeout = 1000;
+	struct mmc_cmd cmd;
+	int err;
+
+	/* Some cards seem to need this */
+	mmc_go_idle(mmc);
+
+	do {
+		cmd.cmdidx = MMC_SEND_OP_COND;
+		cmd.resp_type = MMC_CMD_R3;
+		cmd.cmdarg = 0x40ff8000;
+		cmd.flags = 0;
+
+		err = mmc_send_cmd(mmc, &cmd, NULL);
+
+		if (err)
+			return err;
+
+		udelay(1000);
+	} while (!(cmd.response[0] & OCR_BUSY) && timeout--);
+
+	if (timeout <= 0)
+		return UNUSABLE_ERR;
+
+	mmc->version = MMC_VERSION_UNKNOWN;
+	mmc->ocr = ((uint *)(cmd.response))[0];
+
+	mmc->high_capacity = ((mmc->ocr & OCR_HCS) == OCR_HCS);
+	mmc->rca = 0;
+
+	return 0;
+}
+
+
+int mmc_send_ext_csd(struct mmc *mmc, char *ext_csd)
+{
+	struct mmc_cmd cmd;
+	struct mmc_data data;
+	int err;
+
+	/* Get the Card Status Register */
+	cmd.cmdidx = SEND_EXT_CSD;
+	cmd.resp_type = MMC_CMD_R1;
+	cmd.cmdarg = 0;
+	cmd.flags = 0;
+
+	data.buffer = ext_csd;
+	data.blocks = 1;
+	data.blocksize = 512;
+	data.flags = MMC_DATA_READ;
+
+	err = mmc_send_cmd(mmc, &cmd, &data);
+
+	return err;
+}
+
+
+int mmc_change_freq(struct mmc *mmc)
+{
+	struct mmc_cmd cmd;
+	char ext_csd[512];
+	char cardtype;
+	int err;
+
+	mmc->mode = 0;
+
+	/* Only version 4 supports high-speed */
+	if (mmc->version < MMC_VERSION_4)
+		return 0;
+
+	mmc->mode |= MMC_MODE_4BIT;
+
+	err = mmc_send_ext_csd(mmc, ext_csd);
+
+	if (err)
+		return err;
+
+	if (ext_csd[212] || ext_csd[213] || ext_csd[214] || ext_csd[215])
+		mmc->high_capacity = 1;
+
+	cardtype = ext_csd[196] & 0xf;
+
+	/* Set the card to use High Speed */
+	cmd.cmdidx = MMC_SWITCH;
+	cmd.resp_type = MMC_CMD_R1b;
+	cmd.cmdarg = 0x1b90100;
+	cmd.flags = 0;
+
+	err = mmc_send_cmd(mmc, &cmd, NULL);
+
+	if (err)
+		return err;
+
+	/* Now check to see that it worked */
+	err = mmc_send_ext_csd(mmc, ext_csd);
+
+	if (err)
+		return err;
+
+	/* No high-speed support */
+	if (!ext_csd[185])
+		return 0;
+
+	/* High Speed is set, there are two types: 52MHz and 26MHz */
+	if (cardtype & MMC_HS_52MHZ)
+		mmc->mode |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
+	else
+		mmc->mode |= MMC_MODE_HS;
+
+	return 0;
+}
+
+int sd_change_freq(struct mmc *mmc)
+{
+	int err;
+	struct mmc_cmd cmd;
+	uint scr[2];
+	uint switch_status[16];
+	struct mmc_data data;
+	int timeout;
+
+	mmc->mode = 0;
+
+	/* Read the SCR to find out if this card supports higher speeds */
+	cmd.cmdidx = APP_CMD;
+	cmd.resp_type = MMC_CMD_R1;
+	cmd.cmdarg = mmc->rca << 16;
+	cmd.flags = 0;
+
+	err = mmc_send_cmd(mmc, &cmd, NULL);
+
+	if (err)
+		return err;
+
+	cmd.cmdidx = SEND_SCR;
+	cmd.resp_type = MMC_CMD_R1;
+	cmd.cmdarg = 0;
+	cmd.flags = 0;
+
+	timeout = 3;
+
+retry_scr:
+	data.buffer = (char *)&scr;
+	data.blocksize = 8;
+	data.blocks = 1;
+	data.flags = MMC_DATA_READ;
+
+	err = mmc_send_cmd(mmc, &cmd, &data);
+
+	if (err) {
+		if (timeout--)
+			goto retry_scr;
+
+		return err;
+	}
+
+	mmc->scr[0] = scr[0];
+	mmc->scr[1] = scr[1];
+
+	switch ((mmc->scr[0] >> 24) & 0xf) {
+		case 0:
+			mmc->version = SD_VERSION_1_0;
+			break;
+		case 1:
+			mmc->version = SD_VERSION_1_10;
+			break;
+		case 2:
+			mmc->version = SD_VERSION_2;
+			break;
+		default:
+			mmc->version = SD_VERSION_1_0;
+			break;
+	}
+
+	/* Version 1.0 doesn't support switching */
+	if (mmc->version == SD_VERSION_1_0)
+		return 0;
+
+	timeout = 4;
+	while (timeout--) {
+		/* Switch the frequency */
+		cmd.cmdidx = SWITCH_FUNC;
+		cmd.resp_type = MMC_CMD_R1;
+		cmd.cmdarg = 0xfffff1;
+		cmd.flags = 0;
+
+		data.buffer = (char *)&switch_status;
+		data.blocksize = 64;
+		data.blocks = 1;
+		data.flags = MMC_DATA_READ;
+
+		err = mmc_send_cmd(mmc, &cmd, &data);
+
+		if (err)
+			return err;
+
+		/* The high-speed function is busy.  Try again */
+		if (!switch_status[7] & SD_HIGHSPEED_BUSY)
+			break;
+	}
+
+	if (mmc->scr[0] & SD_DATA_4BIT)
+		mmc->mode |= MMC_MODE_4BIT;
+
+	/* If high-speed isn't supported, we return */
+	if (!(switch_status[3] & SD_HIGHSPEED_SUPPORTED))
+		return 0;
+
+	cmd.cmdidx = SWITCH_FUNC;
+	cmd.resp_type = MMC_CMD_R1;
+	cmd.cmdarg = 0x80fffff1;
+	cmd.flags = 0;
+
+	data.buffer = (char *)&switch_status;
+	data.blocksize = 64;
+	data.blocks = 1;
+	data.flags = MMC_DATA_READ;
+
+	err = mmc_send_cmd(mmc, &cmd, &data);
+
+	if (err)
+		return err;
+
+	if ((switch_status[4] & 0x0f000000) == 0x01000000)
+		mmc->mode |= MMC_MODE_HS;
+
+	return 0;
+}
+
+/* frequency bases */
+/* divided by 10 to be nice to platforms without floating point */
+int fbase[] = {
+	10000,
+	100000,
+	1000000,
+	10000000,
+};
+
+/* Multiplier values for TRAN_SPEED.  Multiplied by 10 to be nice
+ * to platforms without floating point.
+ */
+int multipliers[] = {
+	0,	/* reserved */
+	10,
+	12,
+	13,
+	15,
+	20,
+	25,
+	30,
+	35,
+	40,
+	45,
+	50,
+	55,
+	60,
+	70,
+	80,
+};
+
+
+int mmc_startup(struct mmc *mmc)
+{
+	int err;
+	uint mult, freq;
+	uint cmult, csize;
+	struct mmc_cmd cmd;
+	volatile struct fsl_esdhc *regs = mmc->regs;
+
+	/* Put the Card in Identify Mode */
+	cmd.cmdidx = ALL_SEND_CID;
+	cmd.resp_type = MMC_CMD_R2;
+	cmd.cmdarg = 0;
+	cmd.flags = 0;
+
+	err = mmc_send_cmd(mmc, &cmd, NULL);
+
+	if (err)
+		return err;
+
+	memcpy(mmc->cid, cmd.response, 16);
+
+	/*
+	 * For MMC cards, set the Relative Address.
+	 * For SD cards, get the Relatvie Address.
+	 * This also puts the cards into Standby State
+	 */
+	cmd.cmdidx = SEND_RELATIVE_ADDR;
+	cmd.cmdarg = mmc->rca << 16;
+	cmd.resp_type = MMC_CMD_R6;
+	cmd.flags = 0;
+
+	err = mmc_send_cmd(mmc, &cmd, NULL);
+
+	if (err)
+		return err;
+
+	if (IS_SD(mmc))
+		mmc->rca = (((uint *)(cmd.response))[0] >> 16) & 0xffff;
+
+	/* Get the Card-Specific Data */
+	cmd.cmdidx = SEND_CSD;
+	cmd.resp_type = MMC_CMD_R2;
+	cmd.cmdarg = mmc->rca << 16;
+	cmd.flags = 0;
+
+	err = mmc_send_cmd(mmc, &cmd, NULL);
+
+	if (err)
+		return err;
+
+	mmc->csd[0] = ((uint *)(cmd.response))[0];
+	mmc->csd[1] = ((uint *)(cmd.response))[1];
+	mmc->csd[2] = ((uint *)(cmd.response))[2];
+	mmc->csd[3] = ((uint *)(cmd.response))[3];
+
+	if (mmc->version == MMC_VERSION_UNKNOWN) {
+		int version = (cmd.response[0] >> 2) & 0xf;
+
+		switch (version) {
+			case 0:
+				mmc->version = MMC_VERSION_1_2;
+				break;
+			case 1:
+				mmc->version = MMC_VERSION_1_4;
+				break;
+			case 2:
+				mmc->version = MMC_VERSION_2_2;
+				break;
+			case 3:
+				mmc->version = MMC_VERSION_3;
+				break;
+			case 4:
+				mmc->version = MMC_VERSION_4;
+				break;
+			default:
+				mmc->version = MMC_VERSION_1_2;
+				break;
+		}
+	}
+
+	/* divide frequency by 10, since the mults are 10x bigger */
+	freq = fbase[(cmd.response[3] & 0x7)];
+	mult = multipliers[((cmd.response[3] >> 3) & 0xf)];
+
+	mmc->tran_speed = freq * mult;
+
+	mmc->read_bl_len = 1 << ((((uint *)(cmd.response))[1] >> 16) & 0xf);
+
+	if (IS_SD(mmc))
+		mmc->write_bl_len = mmc->read_bl_len;
+	else
+		mmc->write_bl_len = 1 << ((((uint *)(cmd.response))[3] >> 22) & 0xf);
+
+	csize = (mmc->csd[1] & 0x3ff) << 2 | (mmc->csd[2] & 0xc0000000) >> 30;
+	cmult = (mmc->csd[2] & 0x00038000) >> 15;
+
+	mmc->capacity = (csize + 1) << (cmult + 2);
+	mmc->capacity *= mmc->read_bl_len;
+
+	if (mmc->read_bl_len > 512)
+		mmc->read_bl_len = 512;
+
+	if (mmc->write_bl_len > 512)
+		mmc->write_bl_len = 512;
+
+	/* Select the card, and put it into Transfer Mode */
+	cmd.cmdidx = SELECT_CARD;
+	cmd.resp_type = MMC_CMD_R1b;
+	cmd.cmdarg = mmc->rca << 16;
+	cmd.flags = 0;
+	err = mmc_send_cmd(mmc, &cmd, NULL);
+
+	if (err)
+		return err;
+
+	if (IS_SD(mmc))
+		err = sd_change_freq(mmc);
+	else
+		err = mmc_change_freq(mmc);
+
+	if (err)
+		return err;
+
+	if (IS_SD(mmc)) {
+		if (mmc->mode & MMC_MODE_4BIT) {
+			cmd.cmdidx = APP_CMD;
+			cmd.resp_type = MMC_CMD_R1;
+			cmd.cmdarg = mmc->rca << 16;
+			cmd.flags = 0;
+
+			err = mmc_send_cmd(mmc, &cmd, NULL);
+			if (err)
+				return err;
+
+			cmd.cmdidx = SET_BUS_WIDTH;
+			cmd.resp_type = MMC_CMD_R1;
+			cmd.cmdarg = 2;
+			cmd.flags = 0;
+			err = mmc_send_cmd(mmc, &cmd, NULL);
+			if (err)
+				return err;
+
+			regs->proctl |= PROCTL_DTW_4;
+		}
+
+		if (mmc->mode & MMC_MODE_HS)
+			set_sysctl(mmc, 50000000);
+		else
+			set_sysctl(mmc, 25000000);
+	} else {
+		if (mmc->mode & MMC_MODE_4BIT) {
+			/* Set the card to use 4 bit*/
+			cmd.cmdidx = MMC_SWITCH;
+			cmd.resp_type = MMC_CMD_R1b;
+			cmd.cmdarg = 0x1b70100;
+			cmd.flags = 0;
+
+			err = mmc_send_cmd(mmc, &cmd, NULL);
+
+			if (err)
+				return err;
+
+			regs->proctl |= PROCTL_DTW_4;
+		} else if (mmc->mode & MMC_MODE_8BIT) {
+			/* Set the card to use 8 bit*/
+			cmd.cmdidx = MMC_SWITCH;
+			cmd.resp_type = MMC_CMD_R1b;
+			cmd.cmdarg = 0x1b70200;
+			cmd.flags = 0;
+
+			err = mmc_send_cmd(mmc, &cmd, NULL);
+
+			if (err)
+				return err;
+			
+			regs->proctl |= PROCTL_DTW_8;
+		}
+
+		if (mmc->mode & MMC_MODE_HS) {
+			if (mmc->mode & MMC_MODE_HS_52MHz)
+				set_sysctl(mmc, 52000000);
+			else
+				set_sysctl(mmc, 26000000);
+		} else
+			set_sysctl(mmc, 20000000);
+	}
+
+	/* fill in device description */
+	mmc->block_dev.if_type = IF_TYPE_MMC;
+	mmc->block_dev.part_type = PART_TYPE_DOS;
+	mmc->block_dev.dev = 0;
+	mmc->block_dev.lun = 0;
+	mmc->block_dev.type = 0;
+	mmc->block_dev.blksz = mmc->read_bl_len;
+	mmc->block_dev.lba = mmc->capacity/mmc->read_bl_len;
+	sprintf(mmc->block_dev.vendor,"Man %02x%02x%02x Snr %02x%02x%02x%02x",
+			mmc->cid[0], mmc->cid[1], mmc->cid[2],
+			mmc->cid[9], mmc->cid[10], mmc->cid[11], mmc->cid[12]);
+	sprintf(mmc->block_dev.product,"%c%c%c%c%c", mmc->cid[3],
+			mmc->cid[4], mmc->cid[5], mmc->cid[6], mmc->cid[7]);
+	sprintf(mmc->block_dev.revision,"%d.%d", mmc->cid[8] >> 4,
+			mmc->cid[8] & 0xf);
+	mmc->block_dev.removable = 1;
+	mmc->block_dev.block_read = mmc_bread;
+
+	init_part(&mmc->block_dev);
+
+	return 0;
+}
+
+int mmc_send_if_cond(struct mmc *mmc)
+{
+	struct mmc_cmd cmd;
+	int err;
+
+	cmd.cmdidx = SEND_IF_COND;
+	cmd.cmdarg = 0x1aa;
+	cmd.resp_type = MMC_CMD_R7;
+	cmd.flags = 0;
+
+	err = mmc_send_cmd(mmc, &cmd, NULL);
+
+	if (err)
+		return err;
+
+	if (((uint *)(cmd.response))[0] != 0x1aa)
+		return UNUSABLE_ERR;
+	else
+		mmc->version = SD_VERSION_2;
+
+	return 0;
+}
+
+int
+mmc_init(int verbose)
+{
+	volatile immap_t *im = (immap_t *) CFG_IMMR;
+	struct fsl_esdhc *regs = (struct fsl_esdhc *)&im->sdhc;
+	int timeout = 1000;
+	struct mmc *mmc;
+	int err;
+
+	mmc = malloc(sizeof(struct mmc));
+
+	mmc->regs = regs;
+
+	if (mmc_dev)
+		free(mmc_dev);
+
+	mmc_dev = mmc;
+
+	regs->sysctl = SYSCTL_HCKEN | SYSCTL_IPGEN;
+
+	/* Set the clock speed */
+	set_sysctl(mmc, 400000);
+
+	/* Disable the BRR and BWR bits in IRQSTAT */
+	regs->irqstaten &= ~(IRQSTATEN_BRR | IRQSTATEN_BWR);
+
+	/* Put the PROCTL reg back to the default */
+	regs->proctl = PROCTL_INIT;
+
+	while (!(regs->prsstat & PRSSTAT_CINS) && timeout--)
+		udelay(1000);
+
+	if (timeout <= 0)
+		return NO_CARD_ERR;
+
+	/* Reset the Card */
+	err = mmc_go_idle(mmc);
+
+	if (err)
+		return err;
+
+	/* Test for SD version 2 */
+	err = mmc_send_if_cond(mmc);
+
+	/* If we got an error other than timeout, we bail */
+	if (err && err != TIMEOUT)
+		return err;
+
+	/* Now try to get the SD card's operating condition */
+	err = sd_send_op_cond(mmc);
+
+	/* If the command timed out, we check for an MMC card */
+	if (err == TIMEOUT) {
+		err = mmc_send_op_cond(mmc);
+
+		if (err) {
+			printf("Card did not respond to voltage select!\n");
+			return UNUSABLE_ERR;
+		}
+	}
+
+	err = mmc_startup(mmc);
+
+	if (err)
+		printf("Returning with err %d\n", err);
+
+	return err;
+}
+
+int
+mmc2info(ulong addr)
+{
+	/* Hmm... */
+	return 0;
+}
+
+static void print_mmcinfo(struct mmc *mmc)
+{
+	printf("Manufacturer: %x\n", mmc->cid[0] >> 24);
+	printf("OEM: %x\n", (mmc->cid[0] >> 8) & 0xffff);
+	printf("Name: %c%c%c%c%c\n", mmc->cid[0] & 0xff,
+			(mmc->cid[1] >> 24), (mmc->cid[1] >> 16) & 0xff,
+			(mmc->cid[1] >> 8) & 0xff, mmc->cid[1] & 0xff);
+
+	printf("Tran Speed: %d\n", mmc->tran_speed);
+	printf("Rd Block Len: %d\n", mmc->read_bl_len);
+
+	printf("%s version %d.%d\n", IS_SD(mmc) ? "SD" : "MMC",
+			(mmc->version >> 4) & 0xf, mmc->version & 0xf);
+
+	printf("High Capacity: %s\n", mmc->high_capacity ? "Yes" : "No");
+	printf("Capacity: %d\n", mmc->capacity);
+
+	printf("Bus Width: %d-bit\n", (mmc->mode & MMC_MODE_4BIT) ? 4 :
+			(mmc->mode & MMC_MODE_8BIT) ? 8 : 1);
+}
+
+int do_mmcinfo (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+	if (mmc_dev)
+		print_mmcinfo(mmc_dev);
+	else
+		printf("Call mmcinit first\n");
+
+	return 0;
+}
+
+U_BOOT_CMD(mmcinfo, 1, 0, do_mmcinfo, "mmcinfo -- display MMC info\n", NULL);
+
+#endif	/* CONFIG_MMC */
diff --git a/drivers/mmc/fsl_esdhc.h b/drivers/mmc/fsl_esdhc.h
new file mode 100644
index 0000000..cf5f2d1
--- /dev/null
+++ b/drivers/mmc/fsl_esdhc.h
@@ -0,0 +1,208 @@
+/*
+ * FSL SD/MMC Defines
+ *-------------------------------------------------------------------
+ *
+ * Copyright 2007-2008, Freescale Semiconductor, Inc
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License 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
+ *
+ *-------------------------------------------------------------------
+ *
+ */
+
+#ifndef  __FSL_ESDHC_H__
+#define	__FSL_ESDHC_H__
+
+#define SD_VERSION_SD	0x20000
+#define SD_VERSION_2	(SD_VERSION_SD | 0x20)
+#define SD_VERSION_1_0	(SD_VERSION_SD | 0x10)
+#define SD_VERSION_1_10	(SD_VERSION_SD | 0x1a)
+#define MMC_VERSION_MMC		0x10000
+#define MMC_VERSION_UNKNOWN	(MMC_VERSION_MMC)
+#define MMC_VERSION_1_2		(MMC_VERSION_MMC | 0x12)
+#define MMC_VERSION_1_4		(MMC_VERSION_MMC | 0x14)
+#define MMC_VERSION_2_2		(MMC_VERSION_MMC | 0x22)
+#define MMC_VERSION_3		(MMC_VERSION_MMC | 0x30)
+#define MMC_VERSION_4		(MMC_VERSION_MMC | 0x40)
+
+#define MMC_MODE_HS		0x001
+#define MMC_MODE_HS_52MHz	0x010
+#define MMC_MODE_4BIT		0x100
+#define MMC_MODE_8BIT		0x200
+
+#define SD_DATA_4BIT	0x00040000
+
+#define IS_SD(x) (mmc->version & SD_VERSION_SD)
+
+#define MMC_DATA_READ		1
+#define MMC_DATA_WRITE		2
+
+#define NO_CARD_ERR		-16 /* No SD/MMC card inserted */
+#define UNUSABLE_ERR		-17 /* Unusable Card */
+#define COMM_ERR		-18 /* Communications Error */
+#define TIMEOUT			-19
+
+#define GO_IDLE_STATE		0x0
+#define SEND_IF_COND		(8)
+
+#define APP_CMD			(55)
+
+#define MMC_SEND_OP_COND	(1)
+
+#define SD_SEND_OP_COND		(41)
+
+#define ALL_SEND_CID		(2)
+
+#define SEND_RELATIVE_ADDR	(3)
+
+#define SELECT_CARD		(7)
+
+#define SEND_SCR		(51)
+
+#define SEND_EXT_CSD		(8)
+
+#define SEND_CSD		(9)
+
+#define SEND_STATUS		(13)
+
+#define SWITCH_FUNC		(6)
+#define MMC_SWITCH		(6)
+
+#define SET_BUS_WIDTH		(6)
+
+#define STOP_TRANSMISSION	(12)
+
+#define SET_BLOCKLEN		(16)
+
+#define READ_SINGLE_BLOCK	(17)
+#define READ_MULTIPLE_BLOCKS	(18)
+
+#define SD_HIGHSPEED_BUSY	0x00020000
+#define SD_HIGHSPEED_SUPPORTED	0x00020000
+
+#define MMC_HS_TIMING		0x00000100
+#define MMC_HS_52MHZ		0x2
+
+#define OCR_BUSY	0x80
+#define OCR_HCS		0x40000000
+
+/* FSL eSDHC-specific constants */
+#define SYSCTL			0x0002e02c
+#define SYSCTL_INITA		0x08000000
+#define SYSCTL_PEREN		0x00000004
+#define SYSCTL_HCKEN		0x00000002
+#define SYSCTL_IPGEN		0x00000001
+
+#define IRQSTAT			0x0002e030
+#define IRQSTAT_DMAE		(0x10000000)
+#define IRQSTAT_AC12E		(0x01000000)
+#define IRQSTAT_DEBE		(0x00400000)
+#define IRQSTAT_DCE		(0x00200000)
+#define IRQSTAT_DTOE		(0x00100000)
+#define IRQSTAT_CIE		(0x00080000)
+#define IRQSTAT_CEBE		(0x00040000)
+#define IRQSTAT_CCE		(0x00020000)
+#define IRQSTAT_CTOE		(0x00010000)
+#define IRQSTAT_CINT		(0x00000100)
+#define IRQSTAT_CRM		(0x00000080)
+#define IRQSTAT_CINS		(0x00000040)
+#define IRQSTAT_BRR		(0x00000020)
+#define IRQSTAT_BWR		(0x00000010)
+#define IRQSTAT_DINT		(0x00000008)
+#define IRQSTAT_BGE		(0x00000004)
+#define IRQSTAT_TC		(0x00000002)
+#define IRQSTAT_CC		(0x00000001)
+
+#define CMD_ERR		(IRQSTAT_CIE | IRQSTAT_CEBE | IRQSTAT_CCE)
+#define DATA_ERR	(IRQSTAT_DEBE | IRQSTAT_DCE | IRQSTAT_DTOE)
+
+#define IRQSTATEN		0x0002e034
+#define IRQSTATEN_DMAE		(0x10000000)
+#define IRQSTATEN_AC12E		(0x01000000)
+#define IRQSTATEN_DEBE		(0x00400000)
+#define IRQSTATEN_DCE		(0x00200000)
+#define IRQSTATEN_DTOE		(0x00100000)
+#define IRQSTATEN_CIE		(0x00080000)
+#define IRQSTATEN_CEBE		(0x00040000)
+#define IRQSTATEN_CCE		(0x00020000)
+#define IRQSTATEN_CTOE		(0x00010000)
+#define IRQSTATEN_CINT		(0x00000100)
+#define IRQSTATEN_CRM		(0x00000080)
+#define IRQSTATEN_CINS		(0x00000040)
+#define IRQSTATEN_BRR		(0x00000020)
+#define IRQSTATEN_BWR		(0x00000010)
+#define IRQSTATEN_DINT		(0x00000008)
+#define IRQSTATEN_BGE		(0x00000004)
+#define IRQSTATEN_TC		(0x00000002)
+#define IRQSTATEN_CC		(0x00000001)
+
+#define PRSSTAT			0x0002e024
+#define PRSSTAT_CLSL		(0x00800000)
+#define PRSSTAT_WPSPL		(0x00080000)
+#define PRSSTAT_CDPL		(0x00040000)
+#define PRSSTAT_CINS		(0x00010000)
+#define PRSSTAT_BREN		(0x00000800)
+#define PRSSTAT_DLA		(0x00000004)
+#define PRSSTAT_CICHB		(0x00000002)
+#define PRSSTAT_CIDHB		(0x00000001)
+
+#define PROCTL			0x0002e028
+#define PROCTL_INIT		0x00000020
+#define PROCTL_DTW_4		0x00000002
+#define PROCTL_DTW_8		0x00000004
+
+#define CMDARG			0x0002e008
+
+#define XFERTYP			0x0002e00c
+#define XFERTYP_CMD(x)		((x & 0x3f) << 24)
+#define XFERTYP_CMDTYP_NORMAL	0x0
+#define XFERTYP_CMDTYP_SUSPEND	0x00400000
+#define XFERTYP_CMDTYP_RESUME	0x00800000
+#define XFERTYP_CMDTYP_ABORT	0x00c00000
+#define XFERTYP_DPSEL		0x00200000
+#define XFERTYP_CICEN		0x00100000
+#define XFERTYP_CCCEN		0x00080000
+#define XFERTYP_RSPTYP_NONE	0
+#define XFERTYP_RSPTYP_136	0x00010000
+#define XFERTYP_RSPTYP_48	0x00020000
+#define XFERTYP_RSPTYP_48_BUSY	0x00030000
+#define XFERTYP_MSBSEL		0x00000020
+#define XFERTYP_DTDSEL		0x00000010
+#define XFERTYP_AC12EN		0x00000004
+#define XFERTYP_BCEN		0x00000002
+#define XFERTYP_DMAEN		0x00000001
+
+#define CINS_TIMEOUT		1000
+
+#define DSADDR		0x2e004
+
+#define CMDRSP0		0x2e010
+#define CMDRSP1		0x2e014
+#define CMDRSP2		0x2e018
+#define CMDRSP3		0x2e01c
+
+#define DATPORT		0x2e020
+
+#define WML		0x2e044
+#define WML_WRITE	0x00010000
+
+#define BLKATTR		0x2e004
+#define BLKATTR_CNT(x)	((x & 0xffff) << 16)
+#define BLKATTR_SIZE(x)	(x & 0x1fff)
+#define MAX_BLK_CNT	0x7fff	/* so malloc will have enough room with 32M */
+
+
+#endif  /* __FSL_ESDHC_H__ */
diff --git a/include/asm-ppc/arch-mpc83xx/mmc.h b/include/asm-ppc/arch-mpc83xx/mmc.h
new file mode 100644
index 0000000..d5034f4
--- /dev/null
+++ b/include/asm-ppc/arch-mpc83xx/mmc.h
@@ -0,0 +1 @@
+/* Stub file to satisfy odd requirement for <arch/mmc.h> */
-- 
1.5.4.GIT




From skuribay at ruby.dti.ne.jp  Tue Apr 22 17:10:09 2008
From: skuribay at ruby.dti.ne.jp (Shinya Kuribayashi)
Date: Wed, 23 Apr 2008 00:10:09 +0900
Subject: [U-Boot-Users] [PATCH 1/2][MIPS] qemu-mips: Cleanup whiespaces,
 tab indentations, etc.
In-Reply-To: <1208798540-22251-2-git-send-email-plagnioj@jcrosoft.com>
References: <1208798540-22251-1-git-send-email-plagnioj@jcrosoft.com>
	<1208798540-22251-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <480DFFD1.50406@ruby.dti.ne.jp>

No functional change.

Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
---

 include/configs/qemu-mips.h |   65 +++++++++++++++++++++----------------------
 1 files changed, 32 insertions(+), 33 deletions(-)


diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index e164019..be00356 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -12,7 +12,7 @@
  *
  * 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
+ * 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
@@ -28,25 +28,25 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
-#define CONFIG_QEMU_MIPS        1
+#define CONFIG_MIPS32		1	/* MIPS32 CPU core */
+#define CONFIG_QEMU_MIPS	1
 #define CONFIG_MISC_INIT_R
 
 /*IP address is default used by Qemu*/
-#define CONFIG_IPADDR		10.0.2.15    	     /* Our IP address */
-#define CONFIG_SERVERIP		10.0.2.2	     /* Server IP address*/
+#define CONFIG_IPADDR		10.0.2.15	/* Our IP address */
+#define CONFIG_SERVERIP		10.0.2.2	/* Server IP address */
 
-#define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds	*/
+#define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds */
 
 #define CONFIG_BAUDRATE		115200
 
 /* valid baudrates */
 #define CFG_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
 
-#define	CONFIG_TIMESTAMP		/* Print image info with timestamp */
-#undef	CONFIG_BOOTARGS
+#define CONFIG_TIMESTAMP		/* Print image info with timestamp */
+#undef CONFIG_BOOTARGS
 
-#define	CONFIG_EXTRA_ENV_SETTINGS					\
+#define CONFIG_EXTRA_ENV_SETTINGS					\
 	"addmisc=setenv bootargs ${bootargs} "				\
 		"console=ttyS0,${baudrate} "				\
 		"panic=1\0"						\
@@ -56,7 +56,6 @@
 
 #define CONFIG_BOOTCOMMAND	"bootp;bootelf"
 
-
 /*
  * BOOTP options
  */
@@ -65,7 +64,6 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
-
 /*
  * Command line configuration.
  */
@@ -74,10 +72,10 @@
 #define CONFIG_CMD_ELF
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef  CONFIG_CMD_IMLS
-#undef  CONFIG_CMD_FLASH
-#undef  CONFIG_CMD_LOADB
-#undef  CONFIG_CMD_LOADS
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_FLASH
+#undef CONFIG_CMD_LOADB
+#undef CONFIG_CMD_LOADS
 #define CONFIG_CMD_DHCP
 
 #define CONFIG_DRIVER_NE2000
@@ -86,15 +84,15 @@
 #define CFG_NO_FLASH
 #define CFG_NS16550
 #define CFG_NS16550_SERIAL
-#define CFG_NS16550_REG_SIZE    1
-#define CFG_NS16550_CLK         115200
-#define CFG_NS16550_COM1        (0xb40003f8)
+#define CFG_NS16550_REG_SIZE	1
+#define CFG_NS16550_CLK		115200
+#define CFG_NS16550_COM1	(0xb40003f8)
 #define CONFIG_CONS_INDEX	1
 
 #define CONFIG_CMD_IDE
 #define CONFIG_DOS_PARTITION
 
-#define CFG_IDE_MAXBUS	2
+#define CFG_IDE_MAXBUS		2
 #define CFG_ATA_IDE0_OFFSET	(0x1f0)
 #define CFG_ATA_IDE1_OFFSET	(0x170)
 #define CFG_ATA_DATA_OFFSET	(0)
@@ -106,18 +104,18 @@
 /*
  * Miscellaneous configurable options
  */
-#define	CFG_LONGHELP				/* undef to save memory      */
+#define CFG_LONGHELP				/* undef to save memory */
 
-#define	CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt    */
+#define CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt */
 
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CFG_HUSH_PARSER
 #define CFG_PROMPT_HUSH_PS2	"> "
 
-#define	CFG_CBSIZE		256		/* Console I/O Buffer Size   */
-#define	CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)  /* Print Buffer Size */
-#define	CFG_MAXARGS		16		/* max number of command args*/
+#define CFG_CBSIZE		256		/* Console I/O Buffer Size */
+#define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)  /* Print Buffer Size */
+#define CFG_MAXARGS		16		/* max number of command args */
 
 #define CFG_MALLOC_LEN		128*1024
 
@@ -125,11 +123,11 @@
 
 #define CFG_MHZ			132
 
-#define CFG_HZ                  (CFG_MHZ * 1000000)
+#define CFG_HZ			(CFG_MHZ * 1000000)
 
-#define CFG_SDRAM_BASE		0x80000000     /* Cached addr */
+#define CFG_SDRAM_BASE		0x80000000	/* Cached addr */
 
-#define	CFG_LOAD_ADDR		0x81000000     /* default load address	*/
+#define CFG_LOAD_ADDR		0x81000000	/* default load address */
 
 #define CFG_MEMTEST_START	0x80100000
 #define CFG_MEMTEST_END		0x80800000
@@ -139,21 +137,22 @@
  */
 
 /* The following #defines are needed to get flash environment right */
-#define	CFG_MONITOR_BASE	TEXT_BASE
-#define	CFG_MONITOR_LEN		(192 << 10)
+#define CFG_MONITOR_BASE	TEXT_BASE
+#define CFG_MONITOR_LEN		(192 << 10)
 
 #define CFG_INIT_SP_OFFSET	0x400000
 
 /* We boot from this flash, selected with dip switch */
 #define CFG_FLASH_BASE		0xbfc00000
 
-#define	CFG_ENV_IS_NOWHERE	1
+#define CFG_ENV_IS_NOWHERE	1
 
-/* Address and size of Primary Environment Sector	*/
+/* Address and size of Primary Environment Sector */
 #define CFG_ENV_SIZE		0x10000
+
 #undef CONFIG_NET_MULTI
 
-#define MEM_SIZE 128
+#define MEM_SIZE		128
 
 #undef CONFIG_MEMSIZE_IN_BYTES
 
@@ -164,4 +163,4 @@
 #define CFG_ICACHE_SIZE		16384
 #define CFG_CACHELINE_SIZE	32
 
-#endif	/* __CONFIG_H */
+#endif /* __CONFIG_H */



From skuribay at ruby.dti.ne.jp  Tue Apr 22 17:11:47 2008
From: skuribay at ruby.dti.ne.jp (Shinya Kuribayashi)
Date: Wed, 23 Apr 2008 00:11:47 +0900
Subject: [U-Boot-Users] [PATCH 2/2][MIPS] qemu-mips.h: Add CFI support
In-Reply-To: <1208798540-22251-2-git-send-email-plagnioj@jcrosoft.com>
References: <1208798540-22251-1-git-send-email-plagnioj@jcrosoft.com>
	<1208798540-22251-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <480E0033.9030307@ruby.dti.ne.jp>

From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

CONFIG_ENV_OVERWRITE is also added.

This patch is originally created by Jean-Christophe PLAGNIOL-VILLARD.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
---

 include/configs/qemu-mips.h |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)


diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index be00356..46bfee7 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -72,8 +72,6 @@
 #define CONFIG_CMD_ELF
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef CONFIG_CMD_IMLS
-#undef CONFIG_CMD_FLASH
 #undef CONFIG_CMD_LOADB
 #undef CONFIG_CMD_LOADS
 #define CONFIG_CMD_DHCP
@@ -81,7 +79,6 @@
 #define CONFIG_DRIVER_NE2000
 #define CONFIG_DRIVER_NE2000_BASE	(0xb4000300)
 
-#define CFG_NO_FLASH
 #define CFG_NS16550
 #define CFG_NS16550_SERIAL
 #define CFG_NS16550_REG_SIZE	1
@@ -144,11 +141,19 @@
 
 /* We boot from this flash, selected with dip switch */
 #define CFG_FLASH_BASE		0xbfc00000
+#define CFG_MAX_FLASH_BANKS	1
+#define CFG_MAX_FLASH_SECT	128
+#define CFG_FLASH_CFI		1	/* Flash memory is CFI compliant */
+#define CFG_FLASH_CFI_DRIVER	1
+#define CFG_FLASH_USE_BUFFER_WRITE	1
 
-#define CFG_ENV_IS_NOWHERE	1
+#define CFG_ENV_IS_IN_FLASH	1
+#define CFG_ENV_ADDR		(CFG_FLASH_BASE + 0x40000)
 
 /* Address and size of Primary Environment Sector */
-#define CFG_ENV_SIZE		0x10000
+#define CFG_ENV_SIZE		0x8000
+
+#define CONFIG_ENV_OVERWRITE	1
 
 #undef CONFIG_NET_MULTI
 



From wd at denx.de  Tue Apr 22 17:28:58 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 17:28:58 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: Your message of "Tue, 22 Apr 2008 15:51:06 +0200."
	<200804221551.06813.sr@denx.de>
Message-ID: <20080422152858.6731A24AB5@gemini.denx.de>

In message <200804221551.06813.sr at denx.de> you wrote:
> The following changes since commit 5e3dca577b7c1bf58bd2b48449b18b7e7dcd8e04:
>   Anatolij Gustschin (1):
>         Fix crash on sequoia in ppc_4xx_eth_init
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Matthias Fuchs (9):
>       ppc4xx: Fix sys_get_info() for 405GP(r)
>       ppc4xx: Update bootlogo for APC405 boards
>       ppc4xx: Update FPGA image for APC405 boards
>       ppc4xx: Update esd's common LCD code for 405 boards
>       ppc4xx: update esd's common auto_update code for 405 boards
>       ppc4xx: Update APC405 board support
>       ppc4xx: Update APC405 configuration
>       ppc4xx: Remove unused APC405 strataflash driver
>       ppc4xx: Update CPU strapping for PMC440 boards
> 
> Stefan Roese (6):
>       ppc4xx: Add Glacier NAND booting target
>       ppc4xx: Adjust Canyonlands fixed DDR2 setup (NAND booting) to 512MB SODIMM
>       ppc4xx: Change Canyonlands to support booting from 2k page NAND devices
>       ppc4xx: Add dcache_enable() for 440
>       ppc4xx: Small coding style cleanup for the latest esd patches
>       ppc4xx: Fix Canyonlands and Glacier default environment for fdt usage
> 
>  Makefile                                     |    5 +-
>  board/amcc/canyonlands/bootstrap.c           |   13 +
>  board/amcc/canyonlands/init.S                |    1 +
>  board/amcc/canyonlands/u-boot-nand.lds       |    4 +-
>  board/esd/apc405/Makefile                    |    4 +-
>  board/esd/apc405/apc405.c                    |  360 ++-
>  board/esd/apc405/fpgadata.c                  | 4284 ++++++++++++--------------
>  board/esd/apc405/logo_640_480_24bpp.c        |  800 ++++--
>  board/esd/apc405/strataflash.c               |  789 -----
>  board/esd/common/auto_update.c               |  208 +-
>  board/esd/common/auto_update.h               |   15 +-
>  board/esd/common/lcd.c                       |  123 +-
>  board/esd/common/s1d13505_640_480_16bpp.h    |   65 +
>  board/esd/pmc440/cmd_pmc440.c                |   13 +-
>  cpu/ppc4xx/cache.S                           |    2 +
>  cpu/ppc4xx/speed.c                           |    2 +
>  include/configs/APC405.h                     |  346 ++-
>  include/configs/canyonlands.h                |   49 +-
>  nand_spl/board/amcc/canyonlands/config.mk    |    6 +-
>  nand_spl/board/amcc/canyonlands/ddr2_fixed.c |    8 +-
>  20 files changed, 3320 insertions(+), 3777 deletions(-)
>  delete mode 100644 board/esd/apc405/strataflash.c
>  create mode 100644 board/esd/common/s1d13505_640_480_16bpp.h

Done, 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: wd at denx.de
NEW GRAND UNIFIED THEORY DISCLAIMER: The Manufacturer May Technically
Be Entitled to Claim That This Product Is  Ten-Dimensional.  However,
the  Consumer Is Reminded That This Confers No Legal Rights Above and
Beyond Those Applicable to Three-Dimensional Objects, Since the Seven
New Dimensions Are "Rolled Up" into Such a  Small  "Area"  That  They
Cannot Be Detected.



From wd at denx.de  Tue Apr 22 17:32:02 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 17:32:02 +0200
Subject: [U-Boot-Users] [PATCH 1/2][MIPS] qemu-mips: Cleanup whiespaces,
	tab indentations, etc.
In-Reply-To: Your message of "Wed, 23 Apr 2008 00:10:09 +0900."
	<480DFFD1.50406@ruby.dti.ne.jp>
Message-ID: <20080422153202.9CDD324AB5@gemini.denx.de>

In message <480DFFD1.50406 at ruby.dti.ne.jp> you wrote:
> No functional change.
> 
> Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
> ---
> 
>  include/configs/qemu-mips.h |   65 +++++++++++++++++++++----------------------
>  1 files changed, 32 insertions(+), 33 deletions(-)
> 
> 
> diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
> index e164019..be00356 100644
> --- a/include/configs/qemu-mips.h
> +++ b/include/configs/qemu-mips.h
> @@ -12,7 +12,7 @@
>   *
>   * 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
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

Why are you changing this? It is a good old tradition of typesetters
to user wieder horizontal spacing after a full stop.

See for example the file COPYING which does this consequently.

Please leave this as is.

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: wd at denx.de
"...this does not mean that some of us should not want, in  a  rather
dispassionate sort of way, to put a bullet through csh's head."
                   - Larry Wall in <1992Aug6.221512.5963 at netlabs.com>



From skuribay at ruby.dti.ne.jp  Tue Apr 22 17:35:48 2008
From: skuribay at ruby.dti.ne.jp (Shinya Kuribayashi)
Date: Wed, 23 Apr 2008 00:35:48 +0900
Subject: [U-Boot-Users] [PATCH 1/2][MIPS] qemu-mips: Cleanup whiespaces,
 tab indentations, etc.
In-Reply-To: <20080422153202.9CDD324AB5@gemini.denx.de>
References: <20080422153202.9CDD324AB5@gemini.denx.de>
Message-ID: <480E05D4.70705@ruby.dti.ne.jp>

Wolfgang Denk wrote:
>> @@ -12,7 +12,7 @@
>>   *
>>   * 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
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> 
> Why are you changing this? It is a good old tradition of typesetters
> to user wieder horizontal spacing after a full stop.
> 
> See for example the file COPYING which does this consequently.
> 
> Please leave this as is.

Didn't know that, sorry. Patch revised.

================================>

[MIPS] qemu-mips: Cleanup whiespaces, tab indentations, etc.

No functional change.

Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
---

 include/configs/qemu-mips.h |   63 +++++++++++++++++++++----------------------
 1 files changed, 31 insertions(+), 32 deletions(-)


diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index e164019..c91525e 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -28,25 +28,25 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
-#define CONFIG_QEMU_MIPS        1
+#define CONFIG_MIPS32		1	/* MIPS32 CPU core */
+#define CONFIG_QEMU_MIPS	1
 #define CONFIG_MISC_INIT_R
 
 /*IP address is default used by Qemu*/
-#define CONFIG_IPADDR		10.0.2.15    	     /* Our IP address */
-#define CONFIG_SERVERIP		10.0.2.2	     /* Server IP address*/
+#define CONFIG_IPADDR		10.0.2.15	/* Our IP address */
+#define CONFIG_SERVERIP		10.0.2.2	/* Server IP address */
 
-#define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds	*/
+#define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds */
 
 #define CONFIG_BAUDRATE		115200
 
 /* valid baudrates */
 #define CFG_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
 
-#define	CONFIG_TIMESTAMP		/* Print image info with timestamp */
-#undef	CONFIG_BOOTARGS
+#define CONFIG_TIMESTAMP		/* Print image info with timestamp */
+#undef CONFIG_BOOTARGS
 
-#define	CONFIG_EXTRA_ENV_SETTINGS					\
+#define CONFIG_EXTRA_ENV_SETTINGS					\
 	"addmisc=setenv bootargs ${bootargs} "				\
 		"console=ttyS0,${baudrate} "				\
 		"panic=1\0"						\
@@ -56,7 +56,6 @@
 
 #define CONFIG_BOOTCOMMAND	"bootp;bootelf"
 
-
 /*
  * BOOTP options
  */
@@ -65,7 +64,6 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
-
 /*
  * Command line configuration.
  */
@@ -74,10 +72,10 @@
 #define CONFIG_CMD_ELF
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef  CONFIG_CMD_IMLS
-#undef  CONFIG_CMD_FLASH
-#undef  CONFIG_CMD_LOADB
-#undef  CONFIG_CMD_LOADS
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_FLASH
+#undef CONFIG_CMD_LOADB
+#undef CONFIG_CMD_LOADS
 #define CONFIG_CMD_DHCP
 
 #define CONFIG_DRIVER_NE2000
@@ -86,15 +84,15 @@
 #define CFG_NO_FLASH
 #define CFG_NS16550
 #define CFG_NS16550_SERIAL
-#define CFG_NS16550_REG_SIZE    1
-#define CFG_NS16550_CLK         115200
-#define CFG_NS16550_COM1        (0xb40003f8)
+#define CFG_NS16550_REG_SIZE	1
+#define CFG_NS16550_CLK		115200
+#define CFG_NS16550_COM1	(0xb40003f8)
 #define CONFIG_CONS_INDEX	1
 
 #define CONFIG_CMD_IDE
 #define CONFIG_DOS_PARTITION
 
-#define CFG_IDE_MAXBUS	2
+#define CFG_IDE_MAXBUS		2
 #define CFG_ATA_IDE0_OFFSET	(0x1f0)
 #define CFG_ATA_IDE1_OFFSET	(0x170)
 #define CFG_ATA_DATA_OFFSET	(0)
@@ -106,18 +104,18 @@
 /*
  * Miscellaneous configurable options
  */
-#define	CFG_LONGHELP				/* undef to save memory      */
+#define CFG_LONGHELP				/* undef to save memory */
 
-#define	CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt    */
+#define CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt */
 
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CFG_HUSH_PARSER
 #define CFG_PROMPT_HUSH_PS2	"> "
 
-#define	CFG_CBSIZE		256		/* Console I/O Buffer Size   */
-#define	CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)  /* Print Buffer Size */
-#define	CFG_MAXARGS		16		/* max number of command args*/
+#define CFG_CBSIZE		256		/* Console I/O Buffer Size */
+#define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)  /* Print Buffer Size */
+#define CFG_MAXARGS		16		/* max number of command args */
 
 #define CFG_MALLOC_LEN		128*1024
 
@@ -125,11 +123,11 @@
 
 #define CFG_MHZ			132
 
-#define CFG_HZ                  (CFG_MHZ * 1000000)
+#define CFG_HZ			(CFG_MHZ * 1000000)
 
-#define CFG_SDRAM_BASE		0x80000000     /* Cached addr */
+#define CFG_SDRAM_BASE		0x80000000	/* Cached addr */
 
-#define	CFG_LOAD_ADDR		0x81000000     /* default load address	*/
+#define CFG_LOAD_ADDR		0x81000000	/* default load address */
 
 #define CFG_MEMTEST_START	0x80100000
 #define CFG_MEMTEST_END		0x80800000
@@ -139,21 +137,22 @@
  */
 
 /* The following #defines are needed to get flash environment right */
-#define	CFG_MONITOR_BASE	TEXT_BASE
-#define	CFG_MONITOR_LEN		(192 << 10)
+#define CFG_MONITOR_BASE	TEXT_BASE
+#define CFG_MONITOR_LEN		(192 << 10)
 
 #define CFG_INIT_SP_OFFSET	0x400000
 
 /* We boot from this flash, selected with dip switch */
 #define CFG_FLASH_BASE		0xbfc00000
 
-#define	CFG_ENV_IS_NOWHERE	1
+#define CFG_ENV_IS_NOWHERE	1
 
-/* Address and size of Primary Environment Sector	*/
+/* Address and size of Primary Environment Sector */
 #define CFG_ENV_SIZE		0x10000
+
 #undef CONFIG_NET_MULTI
 
-#define MEM_SIZE 128
+#define MEM_SIZE		128
 
 #undef CONFIG_MEMSIZE_IN_BYTES
 
@@ -164,4 +163,4 @@
 #define CFG_ICACHE_SIZE		16384
 #define CFG_CACHELINE_SIZE	32
 
-#endif	/* __CONFIG_H */
+#endif /* __CONFIG_H */



From scottwood at freescale.com  Tue Apr 22 17:46:01 2008
From: scottwood at freescale.com (Scott Wood)
Date: Tue, 22 Apr 2008 10:46:01 -0500
Subject: [U-Boot-Users] mpc8313 nand setup
In-Reply-To: <04a801c8a43a$c10afb80$4320f280$@net>
References: <04a801c8a43a$c10afb80$4320f280$@net>
Message-ID: <20080422154601.GG15474@ld0162-tx32.am.freescale.net>

On Mon, Apr 21, 2008 at 11:36:02PM -0600, Daniel wrote:
> I am working on a MPC8313ERDB REVA4 board and need to work with a nand
> device using u-boot.  I am using u-boot version 1.3.2 and under the
> driver/mtd/nand directory there is a file called nand.c.  In this file it
> makes a call to a function called board_nand_init().  From what I can tell
> this function is suppose to be located another nand.c file located in
> board/freescale/mpc8313erdb but it seems to be missing.  I found this
> missing file on the website
> www.bitshrine.org/gpp/u-boot-1.1.6-mpc8313erdb-board.patch.  But I haven't
> been able to get the source code (nand.c) to compile it (unless I comment
> out all errors of course).  Any help would be greatly appreciated.

There were patches posted to this list a few weeks ago:

http://sourceforge.net/mailarchive/message.php?msg_id=20080324175302.GA1280%40ld0162-tx32.am.freescale.net
http://sourceforge.net/mailarchive/message.php?msg_id=20080324175304.GB1280%40ld0162-tx32.am.freescale.net

I'm not sure if there's any way to get an unmangled e-mail from
sourceforge's archives, though.

-Scott



From ayman at austin.rr.com  Tue Apr 22 18:11:43 2008
From: ayman at austin.rr.com (ayman at austin.rr.com)
Date: Tue, 22 Apr 2008 11:11:43 -0500
Subject: [U-Boot-Users] pci memory booting on ppc460
Message-ID: <20080422161140.GA20218@crust.elkhashab.com>

Hello, I saw a reference to PCI booting in the docs, but could
not find enough detail.  We would like to use PCI memory space
booting on an upcoming design with the PPC460EX.  Does Uboot
currently support that mode of booting?  Is it as easy as booting
from a flash?  We are developing our app with the canyonlands
board, but we won't be able to try the PCI boot until we have our
own board finished.

Thanks
-ame




From avorontsov at ru.mvista.com  Tue Apr 22 18:53:46 2008
From: avorontsov at ru.mvista.com (Anton Vorontsov)
Date: Tue, 22 Apr 2008 20:53:46 +0400
Subject: [U-Boot-Users] [PATCH] Add eSDHC driver
In-Reply-To: <1208876866-11251-1-git-send-email-afleming@freescale.com>
References: <1208876866-11251-1-git-send-email-afleming@freescale.com>
Message-ID: <20080422165346.GA12687@polina.dev.rtsoft.ru>

On Tue, Apr 22, 2008 at 10:07:46AM -0500, Andy Fleming wrote:
> This is the SD/MMC controller on several of Freescale's more recent parts

Cool. Is there Linux version pending? Does anybody working on it yet?

Thanks.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2



From kim.phillips at freescale.com  Tue Apr 22 19:28:21 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Tue, 22 Apr 2008 12:28:21 -0500
Subject: [U-Boot-Users] [PATCH] ppc: Revert patch 70431e8a that used
 _start instead of CFG_MONITOR_BASE
In-Reply-To: <040601c8a43c$b2c86650$185932f0$@Tjernlund@transmode.se>
References: <1207738602-23956-1-git-send-email-sr@denx.de>
	<20080410194502.13d37051.kim.phillips@freescale.com>
	<20080421160506.86caca50.kim.phillips@freescale.com>
	<040601c8a43c$b2c86650$185932f0$@Tjernlund@transmode.se>
Message-ID: <20080422122821.4759532f.kim.phillips@freescale.com>

On Tue, 22 Apr 2008 07:49:57 +0200
"Joakim Tjernlund" <Joakim.Tjernlund at transmode.se> wrote:

> > Currently WD's top of tree renders 83xx kaput.  When I revert this
> > revert plus Joakim's original 70431e8 commit, things are back to
> > normal.  I'm not going to pretend I know to fix it up correctly, so
> > does anyone have a problem with me sending two revert patches until
> > relocation is properly and comprehensively fixed?
> 
> Strange, I got a 8321 and it worked for me. Maybe a toolchain issue? Perhaps
> I got something extra in my board port, dunno what though.
> 
I just reconfirmed it using WD's TOT w/gcc version 4.1.2 20070925 (Red
Hat 4.1.2-27).

Kim



From biggerbadderben at gmail.com  Tue Apr 22 20:03:07 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Tue, 22 Apr 2008 11:03:07 -0700
Subject: [U-Boot-Users] Question about smc911x driver (16/32 Bit support)
In-Reply-To: <480DD799.50402@tqs.de>
References: <480DD799.50402@tqs.de>
Message-ID: <f8328f7c0804221103i7af61e05h3134aea07eb95ee4@mail.gmail.com>

Hi Jens,

On Tue, Apr 22, 2008 at 5:18 AM, Jens Gehrlein <sew_s at tqs.de> wrote:
> Hi,
>
>  in the source code there is a preprocessor directive
>  #error "SMC911X: Only 32-bit bus is supported".
>
>  We use a LAN9215i, which has a 16 Bit data interface only, connected to
>  an i.MX31.
>
>  The LAN9215 is in the driver's ID list.
>
>  According to the data sheet accesses have to be 2x16 Bit to build the
>  device's internal 32 Bit format.
>
>  What does this non-32-Bit exclusion exactly mean?
>  Will the driver work on our HW configuration?
>
This #error message was included, because if you look at the code
you'll see that the read/write accessors are 32-bit operations *(u32 *
).  These may or may not work on your configuration.  It should be
trivial to write accessors for a 16-bit bus, but nobody had hardware
to try it out on.  Please do so and submit a patch.

>  Confused,
>  Jens

regards,
Ben



From lrj at acm.org  Tue Apr 22 20:55:34 2008
From: lrj at acm.org (Larry Johnson)
Date: Tue, 22 Apr 2008 14:55:34 -0400
Subject: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
Message-ID: <480E34A6.6010509@acm.org>

Hi Stefan,

Currently, I can build "zImage" for Sequoia using the powerpc
architecture, and load it using U-Boot without a separate FDT binary.
Is this the best way to run a Linux from the powerpc tree?

Please excuse me, and send me a pointer, if this is already described
somewhere.

Best regards,
Larry



From grant.likely at secretlab.ca  Tue Apr 22 21:18:42 2008
From: grant.likely at secretlab.ca (Grant Likely)
Date: Tue, 22 Apr 2008 13:18:42 -0600
Subject: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
In-Reply-To: <480E34A6.6010509@acm.org>
References: <480E34A6.6010509@acm.org>
Message-ID: <fa686aa40804221218r3cef9c8bi38ba04438922fe2f@mail.gmail.com>

On Tue, Apr 22, 2008 at 12:55 PM, Larry Johnson <lrj at acm.org> wrote:

> Hi Stefan,
>
> Currently, I can build "zImage" for Sequoia using the powerpc
> architecture, and load it using U-Boot without a separate FDT binary.
> Is this the best way to run a Linux from the powerpc tree?


Sorry, I don't understand what you're asking.

There are two way to boot a Linux image from arch/powerpc.

1) build a uImage and get u-boot to pass a device tree blob (if your u-boot
had device tree support)
2) build a cuImage which wraps the device tree in the kernel image.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080422/528ed017/attachment.htm 

From matthias.fuchs at esd-electronics.com  Mon Apr 21 22:49:41 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 22:49:41 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Update bootlogo for APC405 boards
In-Reply-To: <20080421193019.1C40724764@gemini.denx.de>
References: <20080421193019.1C40724764@gemini.denx.de>
Message-ID: <200804212249.41985.matthias.fuchs@esd-electronics.com>

On Monday 21 April 2008 21:30:19 Wolfgang Denk wrote:
> In message <200804211346.06941.matthias.fuchs at esd-electronics.com> you 
wrote:
> > because of the lists size limit and because I did not find any
> > other suitable way to submit this patch, I am posting a link to the patch
> > file:
>
> I don't understand. Your posting was below the hard limit and got
> ACKed, and it was distributed over the list. Or am I missing
> something?
Sorry for sending it twice. I just saw one of my big patches rejected and 
therefore resubmitted them both. My fault.

Matthias



From wd at denx.de  Tue Apr 22 21:45:07 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 21:45:07 +0200
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: Your message of "Tue, 22 Apr 2008 11:11:43 CDT."
	<20080422161140.GA20218@crust.elkhashab.com>
Message-ID: <20080422194507.56BCF24AB5@gemini.denx.de>

In message <20080422161140.GA20218 at crust.elkhashab.com> you wrote:
> Hello, I saw a reference to PCI booting in the docs, but could
> not find enough detail.  We would like to use PCI memory space
> booting on an upcoming design with the PPC460EX.  Does Uboot
> currently support that mode of booting?  Is it as easy as booting

It has been done before. See for example the PN62 board which was the
first board where this was implemented - more than 5  years  ago  and
probably untested since.

> from a flash?  We are developing our app with the canyonlands
> board, but we won't be able to try the PCI boot until we have our
> own board finished.

Of course, adaptions will be necessary.

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: wd at denx.de
The sooner our happiness together begins, the longer it will last.
	-- Miramanee, "The Paradise Syndrome", stardate 4842.6



From wd at denx.de  Tue Apr 22 21:48:15 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 21:48:15 +0200
Subject: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
In-Reply-To: Your message of "Tue, 22 Apr 2008 14:55:34 EDT."
	<480E34A6.6010509@acm.org>
Message-ID: <20080422194815.5AAD424AB5@gemini.denx.de>

In message <480E34A6.6010509 at acm.org> you wrote:
> 
> Currently, I can build "zImage" for Sequoia using the powerpc
> architecture, and load it using U-Boot without a separate FDT binary.
> Is this the best way to run a Linux from the powerpc tree?

...build an uImage and a device 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: wd at denx.de
"The bad reputation UNIX has gotten is totally undeserved, laid on by
people who don't understand, who have not gotten in there  and  tried
anything."          -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore



From matthias.fuchs at esd-electronics.com  Mon Apr 21 23:02:30 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Mon, 21 Apr 2008 23:02:30 +0200
Subject: [U-Boot-Users] intended behavior of bootm
In-Reply-To: <20080421191922.6E38224764@gemini.denx.de>
References: <20080421191922.6E38224764@gemini.denx.de>
Message-ID: <200804212302.30762.matthias.fuchs@esd-electronics.com>

Thanks for Jerry's and your reply. I see that my expectation was
incorrect and I didn't take the words 'point of no return' that serious.

Now I have to find a (simple) solution to solve my problem:

Typically the 405 board boots from onboard flash. Because of historic
reason there is a kernel and a ramdisk image (not a multi image and nothing 
that is aware of any new image format). These images cannot be changed.
When one of these images either one of them or both is corrupted, U-Boot
should try to load both of them from a usb mass storage. So what's the best 
way to do so?

1) Make bootm fail when any image has a CRC error?
2) Add a new command to check images and decide on the result
3) ???

Any idea? I think the idea behind this is clear. When images A are not ok boot
images B.

good night
Matthias

On Monday 21 April 2008 21:19:22 Wolfgang Denk wrote:
> Dear Matthias,
>
> in message <200804211509.43558.matthias.fuchs at esd-electronics.com> you 
wrote:
> > I am wondering if bootm behaves correctly on CRC errors in kernel and/or
> > ramdisk images. This is what I observed:
>
> Most has already been said in previous replies, so here just a summary
>
> of the situation:
> > 3) Same loading as above. But I make the ramdisk CRC check fail (mw
> > 320000 12345678). I get:
> > ## Booting kernel from Legacy Image at 00200000 ...
> > ...
> > ## Loading init Ramdisk from Legacy Image at 00300000 ...
> > ...
> >    Verifying Checksum ... Bad Data CRC
> > <system reset>
> > U-Boot 1.3.2-00450-g77dd47f (Apr 21 2008 - 14:43:23)
> >
> > Hmm, I expected the same behavior as for a corrupted kernel image.
>
> This expectation is incorrect.
>
> > So what should be the correct behavior? I would like to get back to the
> > prompt on any CRC error. So is this a bug?
>
> No, it is not a bug. Kernel image and  ramdisk  image  get  processed
> sequentiually. As soon as you uncompress and copy the kernel image to
> it's  load  address (typically 0x0000 for PowerPC), it will overwrite
> the exception vectors used by U-Boot. The next interrupt (for example
> timer) would then kill kill you. That's why there is a  point  of  no
> return just before we start uncompressing / loading the kernel image.
>
> Any errors after this point can only be resolved by  a reset.
>
> That's intentional and documented. There are no intentions to change
> this behaviour.
>
> Best regards,
>
> Wolfgang Denk



-- 
-------------------------------------------------------------------------
Dipl.-Ing. Matthias Fuchs
Head of System Design

esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Phone: +49-511-37298-0 - Fax: +49-511-37298-68
Please visit our homepage http://www.esd.eu
Quality Products - Made in Germany
-------------------------------------------------------------------------
Gesch?ftsf?hrer: Klaus Detering, Dr. Werner Schulze
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
-------------------------------------------------------------------------



From dwh at ovro.caltech.edu  Tue Apr 22 20:47:02 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Tue, 22 Apr 2008 11:47:02 -0700
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <20080422161140.GA20218@crust.elkhashab.com>
References: <20080422161140.GA20218@crust.elkhashab.com>
Message-ID: <480E32A6.8080908@ovro.caltech.edu>

Hi Ame,

> Hello, I saw a reference to PCI booting in the docs, but could
> not find enough detail.  We would like to use PCI memory space
> booting on an upcoming design with the PPC460EX.  Does Uboot
> currently support that mode of booting?  Is it as easy as booting
> from a flash?  We are developing our app with the canyonlands
> board, but we won't be able to try the PCI boot until we have our
> own board finished.

U-Boot is a bootloader. What you are describing here
circumvents needing a bootloader.

I use an MPC8349EA Freescale processor, and it also
has an option to boot over PCI. However, I plan to use
U-Boot on Flash to boot the board. I'll tell you why ...
for my hardware anyway, your reasons may end up being similar.

If you want to boot your board over PCI, then the board
will most likely be a peripheral board (a host would need
to boot and setup bridges, so you would have a hard time
booting a host through a bridge that is not configured).
The host CPU would hold the image of the kernel that you were
planning to boot onto the PCI peripheral board. However,
your host would need to perform all of the tasks normally
performed by the bootloader; setup the memory map, memory
controllers, and peripherals that Linux expects to find
configured. Then even trickier, is to setup the kernel
boot command line arguments and device tree. My guess would
be that you would have to hardwire that info into your kernel
image, or add a small bootloader to the kernel image to
setup the arguments to the kernel proper.
There is also the issue that the host CPU is running an
OS with its MMU enabled, so the kernel image that it
can present to the board over the PCI bus is fragmented.
The only way to make this image linear would be to
preserve a chunk of memory on boot of the OS, and load
the kernel image there for the PCI board to boot from.

There's a lot of code in there that you would have to
maintain on your lonesome. For the price of a flash device,
I would recommend using U-Boot as the bootloader in
Flash on your board. The PCI interface can be used to transfer
a kernel image, and then that image can be booted by the
bootloader. Note that this transfer can account for the
fragmented image on the host by using scatter-gather
DMA into the linear address space of the DDR memory
on the board (since U-Boot is running with a flat
memory map).

Save yourself a lot of trouble, and no community support,
by doing things the standard way (and a good sign is, that
you're already asking questions).

Note that if your processor has the option that when
reset is deasserted, the core can remain in reset, make sure
you implement that feature (on the MPC8349EA its controlled
by the reset configuration words source pin strapping).
This allows you to enable the chip, including the PCI interface,
while the core is reset, and therefore does not try to boot.
The MPC8349EA has default windows over PCI that then allow
a host CPU to manipulate all the memory-mapped registers
visible to the PowerPC core. I've been using this feature of
the MPC8349EA processor to test my  board over PCI from an x86
host. The DDR controller can be enabled/disabled, the clocks
swept, and data patterns DMAed to/from PCI to confirm
the memory controller configuration prior to attempting
a U-Boot port.

Hope this helps.

Cheers,
Dave




From wd at denx.de  Tue Apr 22 22:49:23 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 22:49:23 +0200
Subject: [U-Boot-Users] intended behavior of bootm
In-Reply-To: Your message of "Mon, 21 Apr 2008 23:02:30 +0200."
	<200804212302.30762.matthias.fuchs@esd-electronics.com>
Message-ID: <20080422204923.D4AF124AB5@gemini.denx.de>

In message <200804212302.30762.matthias.fuchs at esd-electronics.com> you wrote:
> 
> Now I have to find a (simple) solution to solve my problem:
> 
> Typically the 405 board boots from onboard flash. Because of historic
> reason there is a kernel and a ramdisk image (not a multi image and nothing
> that is aware of any new image format). These images cannot be changed.
> When one of these images either one of them or both is corrupted, U-Boot
> should try to load both of them from a usb mass storage. So what's the best
> way to do so?

The key question here is your definition of "corrupted".

If reliability is an issue, you want to implement (1) support  for  a
hardware  watchdog combined with (2) support for a boot counter. Then
you set "bootlimit" to a reasonable value  and  "altbootcmd"  to  the
command required to load and boot from USB.

Such a setup will be very robust and handle even situations when  the
images  look  good  (checksums  are  OK  etc.)  but fail to work (for
example, because of buggy binaries or libraries were included, config
files got corrupted, etc.).

> 1) Make bootm fail when any image has a CRC error?

This is trivial to do. Remember that you can always use "imi" to check
images; something like

=> imi $kernel_addr && imi $ramdisk_addr && bootm $kernel_addr $ramdisk_addr

would do what you want.

The new image format allows for even fancier methods.

Or implement a boot counter and let the board reset on corrupt images
and then use "altbootcmd".

> 2) Add a new command to check images and decide on the result

Not needed. "iminfo" already does that.

> Any idea? I think the idea behind this is clear. When images A are not ok boot
> images B.

As mentioned above, the trick question is  how  you  define  when  an
image is OK.



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: wd at denx.de
What kind of love is that?  Not to be loved; never to have shown love.
	-- Commissioner Nancy Hedford, "Metamorphosis",
	   stardate 3219.8



From wd at denx.de  Tue Apr 22 22:53:07 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 22 Apr 2008 22:53:07 +0200
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: Your message of "Tue, 22 Apr 2008 11:47:02 PDT."
	<480E32A6.8080908@ovro.caltech.edu>
Message-ID: <20080422205307.B644E24AB5@gemini.denx.de>

In message <480E32A6.8080908 at ovro.caltech.edu> you wrote:
> 
...
> > from a flash?  We are developing our app with the canyonlands
> > board, but we won't be able to try the PCI boot until we have our
> > own board finished.
> 
> U-Boot is a bootloader. What you are describing here
> circumvents needing a bootloader.

This is not necessarily true. Ther emay be many reasons why you still
want to run a boot loader (like U-Boot) on  the  PCI  device's  local
processor.

> If you want to boot your board over PCI, then the board
> will most likely be a peripheral board (a host would need
> to boot and setup bridges, so you would have a hard time
> booting a host through a bridge that is not configured).
> The host CPU would hold the image of the kernel that you were
> planning to boot onto the PCI peripheral board. However,
> your host would need to perform all of the tasks normally
> performed by the bootloader; setup the memory map, memory
> controllers, and peripherals that Linux expects to find
> configured. Then even trickier, is to setup the kernel
> boot command line arguments and device tree. My guess would
> be that you would have to hardwire that info into your kernel
> image, or add a small bootloader to the kernel image to
> setup the arguments to the kernel proper.

You see? There is plenty of good reasons to have a well-known,
powerful boot loader available :-)

> Save yourself a lot of trouble, and no community support,

Who says "no community support"? This is a  perfectly  legal  way  of
using U-Boot, and we we can, we will help.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is easier to change the specification to fit the program than vice
versa.



From plagnioj at jcrosoft.com  Tue Apr 22 22:50:57 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 22 Apr 2008 22:50:57 +0200
Subject: [U-Boot-Users] [PATCH 1/2][MIPS] qemu-mips: Cleanup	whiespaces,
	tab indentations, etc.
In-Reply-To: <20080422153202.9CDD324AB5@gemini.denx.de>
References: <480DFFD1.50406@ruby.dti.ne.jp>
	<20080422153202.9CDD324AB5@gemini.denx.de>
Message-ID: <20080422205057.GD22850@game.jcrosoft.org>

On 17:32 Tue 22 Apr     , Wolfgang Denk wrote:
> In message <480DFFD1.50406 at ruby.dti.ne.jp> you wrote:
> > No functional change.
> > 
> > Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
> > ---
> > 
> >  include/configs/qemu-mips.h |   65 +++++++++++++++++++++----------------------
> >  1 files changed, 32 insertions(+), 33 deletions(-)
> > 
> > 
> > diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
> > index e164019..be00356 100644
> > --- a/include/configs/qemu-mips.h
> > +++ b/include/configs/qemu-mips.h
> > @@ -12,7 +12,7 @@
> >   *
> >   * 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

Please add the sof of the first author of the patch from who you
deriverd.

As example, I've done the same for the NE2000 fix.

Best Regards,
J.



From dwh at ovro.caltech.edu  Tue Apr 22 23:17:00 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Tue, 22 Apr 2008 14:17:00 -0700
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <20080422205307.B644E24AB5@gemini.denx.de>
References: <20080422205307.B644E24AB5@gemini.denx.de>
Message-ID: <480E55CC.4010807@ovro.caltech.edu>

Hi Wolfgang,

> This is not necessarily true. There may be many reasons
> why you still want to run a boot loader (like U-Boot) on
> the PCI device's local processor.

Fair enough.

>> If you want to boot your board over PCI, then the board
>> will most likely be a peripheral board (a host would need
>> to boot and setup bridges, so you would have a hard time
>> booting a host through a bridge that is not configured).
>> The host CPU would hold the image of the kernel that you were
>> planning to boot onto the PCI peripheral board. However,
>> your host would need to perform all of the tasks normally
>> performed by the bootloader; setup the memory map, memory
>> controllers, and peripherals that Linux expects to find
>> configured. Then even trickier, is to setup the kernel
>> boot command line arguments and device tree. My guess would
>> be that you would have to hardwire that info into your kernel
>> image, or add a small bootloader to the kernel image to
>> setup the arguments to the kernel proper.
> 
> You see? There is plenty of good reasons to have a well-known,
> powerful boot loader available :-)
> 
>> Save yourself a lot of trouble, and no community support,
> 
> Who says "no community support"? This is a  perfectly  legal  way  of
> using U-Boot, and we we can, we will help.

The 'no community support' referred to maintaining out-of-tree
host-side code that performed all the board-specific setup before
loading the kernel, i.e., with no U-boot interaction at all.
Sorry if that was misleading.

Ok, so given this is a perfectly legal way of booting
U-Boot, would you (Wolfgang) recommend it?

Lets take the MPC8349EA as the example here. The processor
reset configuration can be setup for PCI boot, however the
processor will come out of reset with PCI outbound translation
windows configured to fetch from PCI address 0 (I think).
A boot-sequencer EEPROM on the PowerPC would not help (for
setting up the outbound window), since it won't know the PCI
address of the U-Boot image (lets assume its an x86 running
Linux for example sake). So the x86 host would have to setup
the PCI outbound translation window to point to the U-Boot image.
But you have the issue, that the hosts MMU will be running, so
the linear U-Boot image that the host loaded into memory,
will in fact consist of 4K pages of physical addresses as
viewed over the PCI bus, i.e., the U-Boot image will be
fragmented. The PCI boot sequence from the perspective of
the PowerPC expects a linear sequence of addresses, and for
this particular example, that will not normally be the case.
The host could arrange for a block of its DDR to be reserved
(eg. using the mem= kernel argument on boot), and it could
load the U-Boot image to that, and then point the PowerPC to
boot from the PCI address that points to that window.

So, its not impossible, but it does seem like more work than
using Flash to boot the board. But of course there may be
reasons to want to boot over PCI ...

I guess once you do this, there isn't really much difference
between the U-Boot image that would have been programmed
to Flash versus the one fetched over PCI, since U-Boot
can still perform its stack-in-cache trick, setup DDR
etc.

Interesting ... if there is work done on this, I can test any
patches on the MPC8349EA.

Cheers,
Dave







From plagnioj at jcrosoft.com  Tue Apr 22 23:18:08 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 22 Apr 2008 23:18:08 +0200
Subject: [U-Boot-Users] Pull request at91
Message-ID: <20080422211808.GA10750@game.jcrosoft.org>

Hi,

as discuss with Peter
I take care of this patch

The following changes since commit 58c5376ba67767ee684069d43e7f747a5d9ae8ed:
  Wolfgang Denk (1):
        Merge branch 'master' of git://www.denx.de/git/u-boot-ppc4xx

are available in the git repository at:

  git://git.denx.de/u-boot-at91.git master

Dirk Behme (1):
      ARM: Davinci: Fix DM644x timer overflow handling and cleanup

 cpu/arm926ejs/davinci/timer.c |   70 +++++++++++++---------------------------

Best Regards,
J.



From Ken.Fuchs at bench.com  Wed Apr 23 00:31:24 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Tue, 22 Apr 2008 17:31:24 -0500
Subject: [U-Boot-Users] USB SUPPORT
In-Reply-To: <480D996A.2020007@gandalf.sssup.it>
Message-ID: <AA28F077645B324881335614E4F7C428034CD8@win-ex01.bench.com>

--- Introduction ---

This thread concerns possible problems with fs/fat/fat.c
(incorrect fatls output and inaccessible files via
fatload) even when recent "git" patches have been applied
to fat.c.  VFAT is enabled.

Michael Trimarchi wrote:

> Can you give an image of it?

(He is referring to the FAT32 image where "fatls usb 0:1 /"
resulted in a clearly garbled/incorrect directory listing.)

Rather than that particular image, I decided to write two
scripts that do most of the work building two other FAT32
images that trigger problems with "fatls usb 0:1 /".  Note
that one FAT32 image is made on XP/Cygwin (mkpen) and the
other on FLOSS/Linux ..err.. GNU/Linux (mklpen).  Note that
two FAT32 images they make do have exactly the same files and
file content, built in exactly the same order, but since the
filesystem code is different, the metadata will probably also
be different ... different inodes ... etc.

The attached mkpen is the XP/Cygwin build script and
u-boot-usb-bug.img.bz2 is a bzip2 compression of the
XP FAT32 image that demonstrates the problems (shown
below) when accessed by U-Boot's fatls.

The attached mklpen automates the whole process on a
Linux host, except you still need to enter the command
./mklpen and move the pen drive from host to target when
done...  It makes a slightly a different FAT32 image that
reveals the same issues with fat.c a bit faster.  The part
where it wipes out /dev/sda1 is commented out, so uncomment
at your risk and modify as needed for a SCSI host.

The middle of this message describes how the XP FAT32 image was
made.  The latter part of this message shows the list of files
via XP/Cygwin and a different list shown via U-Boot's fatls.

--- Pen drive used ---

A 128MB USB pen drive with the following partition table
is being used (only one pen drive was used in testing):

# fdisk -l /dev/sda

Disk /dev/sda: 131 MB, 131072512 bytes
8 heads, 32 sectors/track, 1000 cylinders
Units = cylinders of 256 * 512 = 131072 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        1000      127984    b  W95 FAT32
#

--- XP/Cygwin FAT32 image build procedure ---

(For FLOSS/Linux host, just use the attached mklpen script.)

1) On Linux do:

# dd if=/dev/zero of=/dev/sda1 bs=`echo "32 * 512" | bc`

This is an attempt to reduce the effect of a bad "link" to
unallocated space.  There is _no_ proof that this happens.
(Only null strings and null pointers can now be found here.)

2) On MS Windows XP or similar OS, format (mkfs) partition
   1 with a FAT32 filesystem.

Alternative) On Linux: # mkdosfs -F 32 /dev/sda1

Warning: Linux mkdosfs and XP make different FAT32 images.

3) In a Cygwin bash shell, run the mkpen script with
   cd set to /cygdrive/d (or e, f, g, etc. as appropriate):

#!/bin/bash
for char in 0 1 2 3 4 5 6 7 8 9 a b c d e f g h \
            i j k l m n o p q r s t u v w x y z ; do
        file=;
        for (( index=0 ; index < 8 ; index++ )) ; do
                file=${file}${char};
        done;
        echo "${file}" > ${file}.txt
done

Alternative) On Linux, run the same script.

Warning: Linux vfat fs and XP FAT32 fs code may produce
         different FAT32 images when running this script.

--- Note about building the FAT32 image with FLOSS ---

I also tested the FAT32 image that is built exclusively
via FLOSS tools (using the Linux alternatives in steps
2 & 3 or mklpen).  The result is shown at the end of this
message.

--- ls -lU output of USB pen drive root directory ---

$ cd /pen1
$ ls -lU
total 36
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 00000000.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 11111111.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 22222222.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 33333333.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 44444444.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 55555555.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 66666666.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 77777777.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 88888888.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 99999999.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 aaaaaaaa.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 bbbbbbbb.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 cccccccc.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 dddddddd.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 eeeeeeee.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 ffffffff.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 gggggggg.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 hhhhhhhh.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 iiiiiiii.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 jjjjjjjj.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 kkkkkkkk.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 llllllll.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 mmmmmmmm.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 nnnnnnnn.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 oooooooo.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 pppppppp.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 qqqqqqqq.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 rrrrrrrr.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 ssssssss.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 tttttttt.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 uuuuuuuu.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 vvvvvvvv.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 wwwwwwww.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 xxxxxxxx.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 yyyyyyyy.txt
-rw-r--r-- 1 fuchsk mkpasswd 9 Apr 22 13:38 zzzzzzzz.txt
$

--- U-Boot fatls output of the same directory ---

Hit any key to stop autoboot: 59 0
U-Boot> usb reset
usb reset
(Re)start USB...
USB:   scanning bus for devices...
      USB device not responding, giving up (status=20)
3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
U-Boot> fatls usb 0:1 /
fatls usb 0:1 /
        9   00000000.txt
        9   11111111.txt
        9   22222222.txt
        9   33333333.txt
        9   44444444.txt
        9   55555555.txt
        9   66666666.txt
        9   77777777.txt
        9   88888888.txt
        9   99999999.txt
        9   aaaaaaaa.txt
        9   bbbbbbbb.txt
        9   cccccccc.txt
        9   dddddddd.txt
        9   eeeeeeee.txt
        9   ffffffff.txt
        9   gggggggg.txt
        9   hhhhhhhh.txt
        9   iiiiiiii.txt
        9   jjjjjjjj.txt
        9   kkkkkkkk.txt
        9   llllllll.txt
        9   mmmmmmmm.txt
        9   nnnnnnnn.txt
        9   oooooooo.txt
        9   pppppppp.txt
        9   qqqqqqqq.txt
        9   rrrrrrrr.txt
        9   ssssssss.txt
        9   tttttttt.txt
        9   uuuuuuuu.txt
        9   vvvvvvvv.txt
        0   00000000.


33 file(s), 0 dir(s)

U-Boot> 

--- Comments ---

Notice that the last four files are not listed and "00000000."
is a non-existent file that is listed.  (There should be 36
files.)

--- U-Boot fatls output of FAT32 image built entirely on Linux ---

Hit any key to stop autoboot: 48 0
U-Boot> usb reset
usb reset
(Re)start USB...
USB:   scanning bus for devices...
      USB device not responding, giving up (status=20)
3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
U-Boot> fatls usb 0:1 /
fatls usb 0:1 /
        9   00000000.txt
        9   11111111.txt
        9   22222222.txt
        9   33333333.txt
        9   44444444.txt
        9   55555555.txt
        9   66666666.txt
        9   77777777.txt
        0   00000000.


9 file(s), 0 dir(s)

U-Boot> 

---

Sincerely,

Ken Fuchs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkpen
Type: application/octet-stream
Size: 228 bytes
Desc: mkpen
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080422/698e53c2/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-usb-bug.img.bz2
Type: application/octet-stream
Size: 1630 bytes
Desc: u-boot-usb-bug.img.bz2
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080422/698e53c2/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mklpen
Type: application/octet-stream
Size: 485 bytes
Desc: mklpen
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080422/698e53c2/attachment-0002.obj 

From ukmail01/srv/moog at moog.com  Wed Apr 23 00:31:33 2008
From: ukmail01/srv/moog at moog.com (ukmail01/srv/moog)
Date: Tue, 22 Apr 2008 23:31:33 +0100
Subject: [U-Boot-Users] Report to Recipient(s)
Message-ID: <OF8A7F6156.82C34815-ON80257433.007BBD58@moog.com>

Incident Information:-

Originator: u-boot-users-bounces at lists.sourceforge.net
Recipients: <trimarchi at gandalf.sssup.it>, u-boot-users at lists.sourceforge.net
Subject:    Re: [U-Boot-Users] USB SUPPORT

Generic Alert: Exception was 'Unscannable File' scanning attachment
'u-boot-usb-bug.img.bz2'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080422/e424a713/attachment.htm 

From shinya.kuribayashi at necel.com  Wed Apr 23 04:02:12 2008
From: shinya.kuribayashi at necel.com (Shinya Kuribayashi)
Date: Wed, 23 Apr 2008 11:02:12 +0900
Subject: [U-Boot-Users] [PATCH 1/2][MIPS] qemu-mips: Cleanup	whiespaces,
 tab indentations, etc.
In-Reply-To: <20080422205057.GD22850@game.jcrosoft.org>
References: <480DFFD1.50406@ruby.dti.ne.jp>	<20080422153202.9CDD324AB5@gemini.denx.de>
	<20080422205057.GD22850@game.jcrosoft.org>
Message-ID: <480E98A4.1090405@necel.com>

Jean-Christophe PLAGNIOL-VILLARD wrote:
> Please add the sof of the first author of the patch from who you
> deriverd.

Sorry for that. Patch revised.

================================>

[MIPS] qemu-mips.h: Cleanup whiespaces, tab indentations, etc.

No functional change.

This patch was originally submitted by Jean-Christophe PLAGNIOL-VILLARD.
Then I re-created from scratch, and changed more lines than the original.

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
---

 include/configs/qemu-mips.h |   65 +++++++++++++++++++++----------------------
 1 files changed, 32 insertions(+), 33 deletions(-)


diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index e164019..931eccc 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -22,31 +22,31 @@
  */
 
 /*
- * This file contains the configuration parameters for the dbau1x00 board.
+ * This file contains the configuration parameters for qemu-mips target.
  */
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#define CONFIG_MIPS32		1  /* MIPS32 CPU core	*/
-#define CONFIG_QEMU_MIPS        1
+#define CONFIG_MIPS32		1	/* MIPS32 CPU core */
+#define CONFIG_QEMU_MIPS	1
 #define CONFIG_MISC_INIT_R
 
 /*IP address is default used by Qemu*/
-#define CONFIG_IPADDR		10.0.2.15    	     /* Our IP address */
-#define CONFIG_SERVERIP		10.0.2.2	     /* Server IP address*/
+#define CONFIG_IPADDR		10.0.2.15	/* Our IP address */
+#define CONFIG_SERVERIP		10.0.2.2	/* Server IP address */
 
-#define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds	*/
+#define CONFIG_BOOTDELAY	10	/* autoboot after 10 seconds */
 
 #define CONFIG_BAUDRATE		115200
 
 /* valid baudrates */
 #define CFG_BAUDRATE_TABLE	{ 9600, 19200, 38400, 57600, 115200 }
 
-#define	CONFIG_TIMESTAMP		/* Print image info with timestamp */
-#undef	CONFIG_BOOTARGS
+#define CONFIG_TIMESTAMP		/* Print image info with timestamp */
+#undef CONFIG_BOOTARGS
 
-#define	CONFIG_EXTRA_ENV_SETTINGS					\
+#define CONFIG_EXTRA_ENV_SETTINGS					\
 	"addmisc=setenv bootargs ${bootargs} "				\
 		"console=ttyS0,${baudrate} "				\
 		"panic=1\0"						\
@@ -56,7 +56,6 @@
 
 #define CONFIG_BOOTCOMMAND	"bootp;bootelf"
 
-
 /*
  * BOOTP options
  */
@@ -65,7 +64,6 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
-
 /*
  * Command line configuration.
  */
@@ -74,10 +72,10 @@
 #define CONFIG_CMD_ELF
 #define CONFIG_CMD_FAT
 #define CONFIG_CMD_EXT2
-#undef  CONFIG_CMD_IMLS
-#undef  CONFIG_CMD_FLASH
-#undef  CONFIG_CMD_LOADB
-#undef  CONFIG_CMD_LOADS
+#undef CONFIG_CMD_IMLS
+#undef CONFIG_CMD_FLASH
+#undef CONFIG_CMD_LOADB
+#undef CONFIG_CMD_LOADS
 #define CONFIG_CMD_DHCP
 
 #define CONFIG_DRIVER_NE2000
@@ -86,15 +84,15 @@
 #define CFG_NO_FLASH
 #define CFG_NS16550
 #define CFG_NS16550_SERIAL
-#define CFG_NS16550_REG_SIZE    1
-#define CFG_NS16550_CLK         115200
-#define CFG_NS16550_COM1        (0xb40003f8)
+#define CFG_NS16550_REG_SIZE	1
+#define CFG_NS16550_CLK		115200
+#define CFG_NS16550_COM1	(0xb40003f8)
 #define CONFIG_CONS_INDEX	1
 
 #define CONFIG_CMD_IDE
 #define CONFIG_DOS_PARTITION
 
-#define CFG_IDE_MAXBUS	2
+#define CFG_IDE_MAXBUS		2
 #define CFG_ATA_IDE0_OFFSET	(0x1f0)
 #define CFG_ATA_IDE1_OFFSET	(0x170)
 #define CFG_ATA_DATA_OFFSET	(0)
@@ -106,18 +104,18 @@
 /*
  * Miscellaneous configurable options
  */
-#define	CFG_LONGHELP				/* undef to save memory      */
+#define CFG_LONGHELP				/* undef to save memory */
 
-#define	CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt    */
+#define CFG_PROMPT		"qemu-mips # "	/* Monitor Command Prompt */
 
 #define CONFIG_AUTO_COMPLETE
 #define CONFIG_CMDLINE_EDITING
 #define CFG_HUSH_PARSER
 #define CFG_PROMPT_HUSH_PS2	"> "
 
-#define	CFG_CBSIZE		256		/* Console I/O Buffer Size   */
-#define	CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)  /* Print Buffer Size */
-#define	CFG_MAXARGS		16		/* max number of command args*/
+#define CFG_CBSIZE		256		/* Console I/O Buffer Size */
+#define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16)  /* Print Buffer Size */
+#define CFG_MAXARGS		16		/* max number of command args */
 
 #define CFG_MALLOC_LEN		128*1024
 
@@ -125,11 +123,11 @@
 
 #define CFG_MHZ			132
 
-#define CFG_HZ                  (CFG_MHZ * 1000000)
+#define CFG_HZ			(CFG_MHZ * 1000000)
 
-#define CFG_SDRAM_BASE		0x80000000     /* Cached addr */
+#define CFG_SDRAM_BASE		0x80000000	/* Cached addr */
 
-#define	CFG_LOAD_ADDR		0x81000000     /* default load address	*/
+#define CFG_LOAD_ADDR		0x81000000	/* default load address */
 
 #define CFG_MEMTEST_START	0x80100000
 #define CFG_MEMTEST_END		0x80800000
@@ -139,21 +137,22 @@
  */
 
 /* The following #defines are needed to get flash environment right */
-#define	CFG_MONITOR_BASE	TEXT_BASE
-#define	CFG_MONITOR_LEN		(192 << 10)
+#define CFG_MONITOR_BASE	TEXT_BASE
+#define CFG_MONITOR_LEN		(192 << 10)
 
 #define CFG_INIT_SP_OFFSET	0x400000
 
 /* We boot from this flash, selected with dip switch */
 #define CFG_FLASH_BASE		0xbfc00000
 
-#define	CFG_ENV_IS_NOWHERE	1
+#define CFG_ENV_IS_NOWHERE	1
 
-/* Address and size of Primary Environment Sector	*/
+/* Address and size of Primary Environment Sector */
 #define CFG_ENV_SIZE		0x10000
+
 #undef CONFIG_NET_MULTI
 
-#define MEM_SIZE 128
+#define MEM_SIZE		128
 
 #undef CONFIG_MEMSIZE_IN_BYTES
 
@@ -164,4 +163,4 @@
 #define CFG_ICACHE_SIZE		16384
 #define CFG_CACHELINE_SIZE	32
 
-#endif	/* __CONFIG_H */
+#endif /* __CONFIG_H */

-- 
Shinya Kuribayashi
NEC Electronics



From pmeloy at shaw.ca  Tue Apr 22 03:09:32 2008
From: pmeloy at shaw.ca (p)
Date: Mon, 21 Apr 2008 18:09:32 -0700
Subject: [U-Boot-Users] How to set CPU speed to 266mhz s3c2410?
In-Reply-To: <1208785463.6654.34.camel@vader.jdub.homelinux.org>
References: <20080420222237.4AE5324657@gemini.denx.de>
	<1208779508.5965.371.camel@sauron>
	<Pine.LNX.4.64.0804211533140.27984@lnxricardw.se.axis.com>
	<1208785463.6654.34.camel@vader.jdub.homelinux.org>
Message-ID: <1208826572.19513.6.camel@rhodan.rho>

Sorry for the newb question but I've been googling like mad and can't
find any clues (or more likely, can't understand what I do find).

I'm looking at speed.c under /cpu/arm920t/s3c24xx and thinking this is
the business end of CPU speed setting. I've been greping the source to
see if I can track back to something calling them that I can understand,
but no luck.

Any kind soul out there able to tell me how?




From littelld at verizon.net  Wed Apr 23 05:11:29 2008
From: littelld at verizon.net (Dave Littell)
Date: Tue, 22 Apr 2008 22:11:29 -0500
Subject: [U-Boot-Users] PPC440EPx/sequoia TLB question...
Message-ID: <480EA8E1.4060207@verizon.net>

Hi all,

>From ?/board/amcc/sequoia/init.S:

/* TLB-entry for Internal Registers & OCM */
tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0, AC_R|AC_W|AC_X|SA_I )

Why is this memory region not marked Guarded?  It would seem to meet the
definition of ?non-well-behaved?.

Also the TLB entry for SDRAM marks it Guarded, but that?s one area I
would think wouldn't need to be Guarded.


Thanks,
Dave






From littelld at verizon.net  Wed Apr 23 05:33:08 2008
From: littelld at verizon.net (Dave Littell)
Date: Tue, 22 Apr 2008 22:33:08 -0500
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
Message-ID: <480EADF4.2020706@verizon.net>

Hi all,

I'm working on an AMCC PPC440EPx-based platform that's similar to the
Sequoia.  The board runs pretty well, but occasionally takes exceptions
both in U-Boot and while running Linux.  The exceptions vary from
Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and
DTLB Errors, to DSI, etc., which made us believe there's a problem with
SDRAM.  Sometimes there are simple hard lockups from which even the JTAG
can't regain control.  However, the SDRAM physical/electrical and DDR
Controller configurations have been investigated in detail (and some
corrections made) with no resulting improvement in the exception behavior.

We see problems primarily at 667 MHz but have noted some issues at 533
MHz as well.  Some boards seem particularly susceptible to this while
others rarely (if ever) exhibit the problem.

At this point all possibilities are on the table and I'm looking for any
input from anyone with experience (good, bad, or whatever) with this
processor and/or designs similar to the Sequoia.


Thanks very much,
Dave



From narendra.ka at lntemsys.com  Wed Apr 23 06:12:11 2008
From: narendra.ka at lntemsys.com (gforgcc)
Date: Tue, 22 Apr 2008 21:12:11 -0700 (PDT)
Subject: [U-Boot-Users]  Kernel hanging after lmb_end_of_DRAM() function.
Message-ID: <16830552.post@talk.nabble.com>


Hi geeks, 
i am trying to bring up the latest kernel on EP8248 target,
i am using U-boot-1.3.2 and linux-2.6.25-rc8, i started debugging using
BDI2000 which helped me to know atleast what is going wrong, i have added
some printk's in the kernel source but still i am not able to find where and
what exactly is going wrong, The first statement it is printing in the log
buffer is 
""Using Embedded Planet EP8248E machine description"" and thats it the next
message is 
Unable to handle kernel paging request for data at address 0xbfff0000
Faulting instruction address:0xc0012070 (This nearest address to this
address in System.map file is cacheable_memzero)
and tracing like this i came to know that in the file
arch/powerpc/mm/ppc_mmu_32.c , here in the function __init MMU_init_hw() and
in the line n_hpteg = total_memory / (PAGE_SIZE * 8); probably it is getting
problem because when i tried to print the variable total_memory it is
printing zero !!! :( :(  so probably i am thinking it is not able to find
some memory for Hash table :(
Please share your knowledge and skills and help me to resolve this issue..
thanks  :)
-- 
View this message in context: http://www.nabble.com/Kernel-hanging-after-lmb_end_of_DRAM%28%29-function.-tp16830552p16830552.html
Sent from the Uboot - Users mailing list archive at Nabble.com.




From vapier at gentoo.org  Wed Apr 23 07:39:03 2008
From: vapier at gentoo.org (Mike Frysinger)
Date: Wed, 23 Apr 2008 01:39:03 -0400
Subject: [U-Boot-Users] [PATCH v3] crc32: use uint32_t rather than
	unsigned long
In-Reply-To: <200803311102.01628.vapier@gentoo.org>
References: <1206908872-2141-1-git-send-email-vapier@gentoo.org>
	<200803302142.18994.vapier@gentoo.org>
	<200803311102.01628.vapier@gentoo.org>
Message-ID: <200804230139.03856.vapier@gentoo.org>

On Monday 31 March 2008, Mike Frysinger wrote:
> The envcrc.c does sizeof(unsigned long) when calculating the crc, but this
> is done with the build toolchain instead of the target toolchain, so if the
> build is a 64bit system but the target is 32bits, the size will obviously
> be wrong. This converts all unsigned long stuff related to crc32 to
> uint32_t types. Compile tested only: output of ./tools/envcrc when run on a
> 32bit build system matches that of a 64bit build system.

ping
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080423/ec2c46bc/attachment.pgp 

From Joakim.Tjernlund at transmode.se  Wed Apr 23 08:00:54 2008
From: Joakim.Tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 23 Apr 2008 08:00:54 +0200
Subject: [U-Boot-Users] [PATCH] ppc: Revert patch 70431e8a that used
	_start instead of CFG_MONITOR_BASE
In-Reply-To: <20080422122821.4759532f.kim.phillips@freescale.com>
References: <1207738602-23956-1-git-send-email-sr@denx.de>	<20080410194502.13d37051.kim.phillips@freescale.com>	<20080421160506.86caca50.kim.phillips@freescale.com>	<040601c8a43c$b2c86650$185932f0$@Tjernlund@transmode.se>
	<20080422122821.4759532f.kim.phillips@freescale.com>
Message-ID: <04e101c8a507$64c782d0$2e568870$@Tjernlund@transmode.se>

> -----Original Message-----
> From: Kim Phillips [mailto:kim.phillips at freescale.com]
> Sent: den 22 april 2008 19:28
> To: Joakim Tjernlund
> Cc: 'Stefan Roese'; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] [PATCH] ppc: Revert patch 70431e8a that used _start instead of
> CFG_MONITOR_BASE
> 
> On Tue, 22 Apr 2008 07:49:57 +0200
> "Joakim Tjernlund" <Joakim.Tjernlund at transmode.se> wrote:
> 
> > > Currently WD's top of tree renders 83xx kaput.  When I revert this
> > > revert plus Joakim's original 70431e8 commit, things are back to
> > > normal.  I'm not going to pretend I know to fix it up correctly, so
> > > does anyone have a problem with me sending two revert patches until
> > > relocation is properly and comprehensively fixed?
> >
> > Strange, I got a 8321 and it worked for me. Maybe a toolchain issue? Perhaps
> > I got something extra in my board port, dunno what though.
> >
> I just reconfirmed it using WD's TOT w/gcc version 4.1.2 20070925 (Red
> Hat 4.1.2-27).

Got gcc 3.4.6 here, so I guess there is some difference between them(or perhaps
ld). Can't help you, so do as you wish.

   Jocke




From sew_s at tqs.de  Wed Apr 23 08:37:16 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Wed, 23 Apr 2008 08:37:16 +0200
Subject: [U-Boot-Users] Question about smc911x driver (16/32 Bit support)
In-Reply-To: <f8328f7c0804221103i7af61e05h3134aea07eb95ee4@mail.gmail.com>
References: <480DD799.50402@tqs.de>
	<f8328f7c0804221103i7af61e05h3134aea07eb95ee4@mail.gmail.com>
Message-ID: <480ED91C.4010400@tqs.de>

Hi Ben,

Ben Warren schrieb:
> Hi Jens,
> 
> On Tue, Apr 22, 2008 at 5:18 AM, Jens Gehrlein <sew_s at tqs.de> wrote:
>> Hi,
>>
>>  in the source code there is a preprocessor directive
>>  #error "SMC911X: Only 32-bit bus is supported".
>>
>>  We use a LAN9215i, which has a 16 Bit data interface only, connected to
>>  an i.MX31.
>>
>>  The LAN9215 is in the driver's ID list.
>>
>>  According to the data sheet accesses have to be 2x16 Bit to build the
>>  device's internal 32 Bit format.
>>
>>  What does this non-32-Bit exclusion exactly mean?
>>  Will the driver work on our HW configuration?
>>
> This #error message was included, because if you look at the code
> you'll see that the read/write accessors are 32-bit operations *(u32 *
> ).  These may or may not work on your configuration.  It should be
> trivial to write accessors for a 16-bit bus, but nobody had hardware
> to try it out on.  Please do so and submit a patch.

Yes, it seems, that we just need two additional functions which split a 
32 Bit access into two 16 Bit accesses. That should be easy. I'm going 
to create a patch as soon as I get the HW. But first I want to test 
whether the processor splits itself automatically.

Thank you very much.

Best Regards,
Jens




From super.firetwister at googlemail.com  Wed Apr 23 08:54:20 2008
From: super.firetwister at googlemail.com (Markus Brunner)
Date: Wed, 23 Apr 2008 08:54:20 +0200
Subject: [U-Boot-Users] ppc4xx: gpio setup broken for ppc405ep
In-Reply-To: <6a6049b80803310433h6e237542te056fc755a0dcf2a@mail.gmail.com>
References: <6a6049b80803271104x598b47adta1dc97f9d13102c@mail.gmail.com>
	<200803311313.33224.sr@denx.de>
	<6a6049b80803310433h6e237542te056fc755a0dcf2a@mail.gmail.com>
Message-ID: <200804230854.22005.super.firetwister@gmail.com>

After some emails with John from AMCC here are the Results:

About the "random" tri-state select settings in the tables for alternate 
function for 440EP

> The values in the PPC440EP User's Manual (Revision 1.26 - March 20, 
> 2008) that's on the web look correct to me.
> Tables 29-6, 29-7 29-8 are 29-9 are all for alternate 1 signals. The
> GPIOn_TSRL/H can either be 0b00 or 0b01. This is what is in the manual.
> Tables 29-10, 29-11, 29-12 and 29-13 are all alternate 2 signals. 
> The GPIOn_TSRL/H can either be 0b00 or 0b10. This is what is in the 
> manual.
> Tables 29-14 is only contains alternate 3 signals.  The GPIOn_TSRL/H
> can either be 0b00 or 0b11. This is what is in the manual.
> 
> A setting of 0b00 means the settings in GPIOn_TCR control determine 
> whether a GPIO pin is tri-stated.
> A setting of 0b01 means the alternate 1 device attached internally 
> to the GPIO controller determine whether a GPIO pin is tri-stated.
> A setting of 0b10 means the alternate 2 device attached internally 
> to the GPIO controller determine whether a GPIO pin is tri-stated.
> A setting of 0b11 means the alternate 3 device attached internally 
> to the GPIO controller determine whether a GPIO pin is tri-stated.

I didn't get it at first, so in other words ...

> When the tri-state select bit field is set to 00 for a particular 
> GPIO signal, this just means the tri-state control for this signal 
> is controlled by the tri-state control register. If set to 01, 10 or
> 11, the alternate source for the signal is controlled by the 
> internal controller such as the UART or EBC.

The select registers just select the tri-state source. This can be consistent 
as for 405EX, but it can be random like for 440EP

And it can also be 00 all the time, like for 405EP

> The settings for GPIO0_TSRL in table 23-7 is correct. All the 
> GPIO0_TSRL bit fields are set to 0.

However my 405EP was working pretty well if I set the bitfields to 01 for alt 
function1.

The high/low addresses of the select registers of 405EP and the way they are 
assigned to the pins are like any other amcc processor. This means the 
current Users manual is wrong and will be updated.

> The original IBM 405EP manual made two errors. These two errors were
> self healing and have caused a confusing mess.
> 1. Table 23-1 assigned the high registers to low register addresses 
> and assigned the low registers to the high register addresses. The 
> lows and highs were exchanged.
> 2. Table 23-7 showed the high registers being configured when it 
> technically should have been the low registers.
> 
> Apparently a customer complained about the above two problems as it 
> confused them when using other PPC4XX parts. We fixed table 23-1 but
> we did not fix 23-7. Table 23-7 should use GPIO0_OSRL, GPIO0_TSRL, 
> and GPIO0_ISRL not GPIO0_OSRH, GPIO0_TSRH, and GPIO0_ISRH
> 
> I'll fix table 23-7 so that it uses GPIO0_OSRL, GPIO0_TSRL, and 
> GPIO0_ISRL. With this change the following register assignment makes
> sense and matches what is done on the 440EP/GR, 440EPx/GRx, 
> 405EX/EXr and 460EX/GT parts.
> 
> #define GPIO0_OR               (GPIO_BASE+0x0)
> #define GPIO0_TCR              (GPIO_BASE+0x4)
> #define GPIO0_OSRL             (GPIO_BASE+0x8)
> #define GPIO0_OSRH             (GPIO_BASE+0xC)
> #define GPIO0_TSRL            (GPIO_BASE+0x10)
> #define GPIO0_TSRH             (GPIO_BASE+0x14)
> #define GPIO0_ODR              (GPIO_BASE+0x18)
> #define GPIO0_IR               (GPIO_BASE+0x1C)
> #define GPIO0_RR1              (GPIO_BASE+0x20)
> #define GPIO0_RR2              (GPIO_BASE+0x24)
> #define GPIO0_ISR1L            (GPIO_BASE+0x30)
> #define GPIO0_ISR1H            (GPIO_BASE+0x34)
> #define GPIO0_ISR2L            (GPIO_BASE+0x38)
> #define GPIO0_ISR2H            (GPIO_BASE+0x3C)

So we've got to change something with the gpio setup.

Regards

Markus



From trimarchi at gandalf.sssup.it  Wed Apr 23 08:54:29 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Wed, 23 Apr 2008 08:54:29 +0200
Subject: [U-Boot-Users] USB SUPPORT
In-Reply-To: <AA28F077645B324881335614E4F7C428034CD8@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CD8@win-ex01.bench.com>
Message-ID: <480EDD25.3030809@gandalf.sssup.it>

Hi,
Ken.Fuchs at bench.com wrote:
> --- Introduction ---
>
> This thread concerns possible problems with fs/fat/fat.c
> (incorrect fatls output and inaccessible files via
> fatload) even when recent "git" patches have been applied
> to fat.c.  VFAT is enabled.
>
> Michael Trimarchi wrote:
>
>   
>> Can you give an image of it?
>>     
>
> Notice that the last four files are not listed and "00000000."
> is a non-existent file that is listed.  (There should be 36
> files.)
>
> --- U-Boot fatls output of FAT32 image built entirely on Linux ---
>
> Hit any key to stop autoboot: 48 0
> U-Boot> usb reset
> usb reset
> (Re)start USB...
> USB:   scanning bus for devices...
>       USB device not responding, giving up (status=20)
> 3 USB Device(s) found
>        scanning bus for storage devices... 1 Storage Device(s) found
> U-Boot> fatls usb 0:1 /
> fatls usb 0:1 /
>         9   00000000.txt
>         9   11111111.txt
>         9   22222222.txt
>         9   33333333.txt
>         9   44444444.txt
>         9   55555555.txt
>         9   66666666.txt
>         9   77777777.txt
>         0   00000000.
>
>
> 9 file(s), 0 dir(s)
>
> U-Boot> 
>
> ---
>
> Sincerely,
>
> Ken Fuchs
>   
Thank's...

Regards Michael






From plagnioj at jcrosoft.com  Wed Apr 23 08:49:30 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 23 Apr 2008 08:49:30 +0200
Subject: [U-Boot-Users] [PATCH v3] crc32: use uint32_t rather
	than	unsigned long
In-Reply-To: <200803311102.01628.vapier@gentoo.org>
References: <1206908872-2141-1-git-send-email-vapier@gentoo.org>
	<200803302142.18994.vapier@gentoo.org>
	<200803311102.01628.vapier@gentoo.org>
Message-ID: <20080423064930.GB10750@game.jcrosoft.org>

On 11:02 Mon 31 Mar     , Mike Frysinger wrote:
> The envcrc.c does sizeof(unsigned long) when calculating the crc, but this is
> done with the build toolchain instead of the target toolchain, so if the build
> is a 64bit system but the target is 32bits, the size will obviously be wrong. 
> This converts all unsigned long stuff related to crc32 to uint32_t types. 
> Compile tested only: output of ./tools/envcrc when run on a 32bit build system
> matches that of a 64bit build system.
> 
> Signed-off-by: Mike Frysinger <vapier at gentoo.org>
> ---
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>



From trimarchi at gandalf.sssup.it  Wed Apr 23 09:05:19 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Wed, 23 Apr 2008 09:05:19 +0200
Subject: [U-Boot-Users] How to set CPU speed to 266mhz s3c2410?
In-Reply-To: <1208826572.19513.6.camel@rhodan.rho>
References: <20080420222237.4AE5324657@gemini.denx.de>	<1208779508.5965.371.camel@sauron>	<Pine.LNX.4.64.0804211533140.27984@lnxricardw.se.axis.com>	<1208785463.6654.34.camel@vader.jdub.homelinux.org>
	<1208826572.19513.6.camel@rhodan.rho>
Message-ID: <480EDFAF.50007@gandalf.sssup.it>

Hi,

p wrote:
> Sorry for the newb question but I've been googling like mad and can't
> find any clues (or more likely, can't understand what I do find).
>
> I'm looking at speed.c under /cpu/arm920t/s3c24xx and thinking this is
> the business end of CPU speed setting. I've been greping the source to
> see if I can track back to something calling them that I can understand,
> but no luck.
>   
under your board/<boardname>/<boardfile>
Take for example the board/smdk2410/smdk2410.c and
change
#if FCLK_SPEED==0               /* Fout = 203MHz, Fin = 12MHz for Audio */
#define M_MDIV  0xC3
#define M_PDIV  0x4
#define M_SDIV  0x1

Regards Michael



From super.firetwister at googlemail.com  Wed Apr 23 09:12:34 2008
From: super.firetwister at googlemail.com (Markus Brunner)
Date: Wed, 23 Apr 2008 09:12:34 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx fixup ebc clock in FDT for 405GP/EP
Message-ID: <200804230912.35222.super.firetwister@gmail.com>

On ppc405EP and ppc405GP (at least) the ebc is directly attached to the plb and not to the opb. 
This patch will try to fixup /plb/ebc if /plb/opb/ebc doesn't exist.

Signed-off-by: Markus Brunner <super.firetwister at gmail.com>
---

diff --git a/cpu/ppc4xx/fdt.c b/cpu/ppc4xx/fdt.c
index afcb974..da27d0e 100644
--- a/cpu/ppc4xx/fdt.c
+++ b/cpu/ppc4xx/fdt.c
@@ -46,8 +46,14 @@ void ft_cpu_setup(void *blob, bd_t *bd)
                             bd->bi_intfreq, 1);
        do_fixup_by_path_u32(blob, "/plb", "clock-frequency", sys_info.freqPLB, 1);
        do_fixup_by_path_u32(blob, "/plb/opb", "clock-frequency", sys_info.freqOPB, 1);
-       do_fixup_by_path_u32(blob, "/plb/opb/ebc", "clock-frequency",
-                            sys_info.freqEBC, 1);
+
+       if ( fdt_path_offset(blob, "/plb/opb/ebc") >= 0 )
+               do_fixup_by_path_u32(blob, "/plb/opb/ebc",
+                       "clock-frequency", sys_info.freqEBC, 1);
+       else
+               do_fixup_by_path_u32(blob, "/plb/ebc",
+                       "clock-frequency", sys_info.freqEBC, 1);
+
        fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);

        /*



From Martin.Krause at tqs.de  Wed Apr 23 09:44:17 2008
From: Martin.Krause at tqs.de (Martin Krause)
Date: Wed, 23 Apr 2008 09:44:17 +0200
Subject: [U-Boot-Users] How to set CPU speed to 266mhz s3c2410?
In-Reply-To: <1208826572.19513.6.camel@rhodan.rho>
Message-ID: <47F3F98010FF784EBEE6526EAAB078D10635DF28@tq-mailsrv.tq-net.de>

Hi p,

u-boot-users-bounces at lists.sourceforge.net wrote on Tuesday, April 22,
2008 3:10 AM: 
> Sorry for the newb question but I've been googling like mad and can't
> find any clues (or more likely, can't understand what I do find).
> 
> I'm looking at speed.c under /cpu/arm920t/s3c24xx and thinking this is
> the business end of CPU speed setting. I've been greping the source to

No, in /cpu/arm920t/s3c24x0/speed.c are only functions to read the
clock configuration. The setting of the clocks is done in the 
board specific initilaisation code. For the SMDK2410 for example in
/board/smdk2410/smdk2410.c. The MPLL Clock (and thus the derived CPU
clock FCLK) is configured via the PLL divider values MDIV, PDIV and
SDIV. For a detailed description take a look into the S3C2410 datasheet
(search for the MPLL register in the chapter Clock & Power Management).

Regards,
Martin Krause

--
TQ-Systems GmbH
Muehlstrasse 2, Gut Delling, D-82229 Seefeld
Amtsgericht Muenchen, HRB 105 018, UST-IdNr. DE 811 607 913
Geschaeftsfuehrer: Dipl.-Ing. (FH) Detlef Schneider, Dipl.-Ing. (FH) Ruediger Stahl
http://www.tq-group.com



From trimarchi at gandalf.sssup.it  Wed Apr 23 10:14:04 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Wed, 23 Apr 2008 10:14:04 +0200
Subject: [U-Boot-Users] USB SUPPORT
In-Reply-To: <480EDD25.3030809@gandalf.sssup.it>
References: <AA28F077645B324881335614E4F7C428034CD8@win-ex01.bench.com>
	<480EDD25.3030809@gandalf.sssup.it>
Message-ID: <480EEFCC.3030009@gandalf.sssup.it>

Hi,

Can you try this one?

Revert my last one patch?
It change the test code, before the while. I use your script on a 
Compact Flash and it looks fine for me (under linux).

Regards Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vfat-check-name.patch
Type: text/x-patch
Size: 1059 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080423/dfcaf019/attachment.bin 

From sr at denx.de  Wed Apr 23 10:26:51 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 23 Apr 2008 10:26:51 +0200
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <480E55CC.4010807@ovro.caltech.edu>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<480E55CC.4010807@ovro.caltech.edu>
Message-ID: <200804231026.51751.sr@denx.de>

On Tuesday 22 April 2008, David Hawkins wrote:
> So, its not impossible, but it does seem like more work than
> using Flash to boot the board.

Full ACK from me. I would always recommend to use a small NOR FLASH with a 
full-blown U-Boot for booting from NOR with full DDR2 setup etc. All this 
will be hard to implement with all the restrictions for booting from PCI 
(even though I have never done this before, but I suspect that it will be 
quite as limited as booting from NAND).

> But of course there may be 
> reasons to want to boot over PCI ...

Yes, what is the main reason you want to do this? As mentioned above, I 
recommend to boot from a small NOR FLASH (512kB) and "wait" in U-Boot for the 
PCI host to provide the OS/application image via PCI.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From matthias.fuchs at esd-electronics.com  Wed Apr 23 10:43:06 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Wed, 23 Apr 2008 10:43:06 +0200
Subject: [U-Boot-Users] intended behavior of bootm
In-Reply-To: <20080422204923.D4AF124AB5@gemini.denx.de>
References: <20080422204923.D4AF124AB5@gemini.denx.de>
Message-ID: <200804231043.06717.matthias.fuchs@esd-electronics.com>

Hi Wolfgang,

thanks for your reply. That's the kind of thing I wanted to hear.
Now I will start playing around ;-)

Matthias

On Tuesday 22 April 2008 22:49, Wolfgang Denk wrote:
> In message <200804212302.30762.matthias.fuchs at esd-electronics.com> you wrote:
> > 
> > Now I have to find a (simple) solution to solve my problem:
> > 
> > Typically the 405 board boots from onboard flash. Because of historic
> > reason there is a kernel and a ramdisk image (not a multi image and nothing
> > that is aware of any new image format). These images cannot be changed.
> > When one of these images either one of them or both is corrupted, U-Boot
> > should try to load both of them from a usb mass storage. So what's the best
> > way to do so?
> 
> The key question here is your definition of "corrupted".
> 
> If reliability is an issue, you want to implement (1) support  for  a
> hardware  watchdog combined with (2) support for a boot counter. Then
> you set "bootlimit" to a reasonable value  and  "altbootcmd"  to  the
> command required to load and boot from USB.
> 
> Such a setup will be very robust and handle even situations when  the
> images  look  good  (checksums  are  OK  etc.)  but fail to work (for
> example, because of buggy binaries or libraries were included, config
> files got corrupted, etc.).
> 
> > 1) Make bootm fail when any image has a CRC error?
> 
> This is trivial to do. Remember that you can always use "imi" to check
> images; something like
> 
> => imi $kernel_addr && imi $ramdisk_addr && bootm $kernel_addr $ramdisk_addr
> 
> would do what you want.
> 
> The new image format allows for even fancier methods.
> 
> Or implement a boot counter and let the board reset on corrupt images
> and then use "altbootcmd".
> 
> > 2) Add a new command to check images and decide on the result
> 
> Not needed. "iminfo" already does that.
> 
> > Any idea? I think the idea behind this is clear. When images A are not ok boot
> > images B.
> 
> As mentioned above, the trick question is  how  you  define  when  an
> image is OK.
> 
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 



From mk at denx.de  Wed Apr 23 10:53:23 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Wed, 23 Apr 2008 10:53:23 +0200
Subject: [U-Boot-Users] [PATCH] USB: fix those pesky aliasing warnings
	caused by gcc-4.2
Message-ID: <87wsmpymt8.fsf@denx.de>


USB: fix those pesky aliasing warnings caused by gcc-4.2

Signed-off-by: Markus Klotzbuecher <mk at denx.de>
Signed-off-by: Detlev Zundel <dzu at denx.de>

---

 drivers/usb/usb_ohci.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)


diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c
index 5c201b3..d37a037 100644
--- a/drivers/usb/usb_ohci.c
+++ b/drivers/usb/usb_ohci.c
@@ -86,11 +86,11 @@
  * e.g. PCI controllers need this
  */
 #ifdef CFG_OHCI_SWAP_REG_ACCESS
-# define readl(a) __swap_32(*((vu_long *)(a)))
-# define writel(a, b) (*((vu_long *)(b)) = __swap_32((vu_long)a))
+# define readl(a) __swap_32(*((volatile u32 *)(a)))
+# define writel(a, b) (*((volatile u32 *)(b)) = __swap_32((volatile u32)a))
 #else
-# define readl(a) (*((vu_long *)(a)))
-# define writel(a, b) (*((vu_long *)(b)) = ((vu_long)a))
+# define readl(a) (*((volatile u32 *)(a)))
+# define writel(a, b) (*((volatile u32 *)(b)) = ((volatile u32)a))
 #endif /* CFG_OHCI_SWAP_REG_ACCESS */
 
 #define min_t(type,x,y) ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })


Best regards

Markus Klotzbuecher

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



From mk at denx.de  Wed Apr 23 10:57:33 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Wed, 23 Apr 2008 10:57:33 +0200
Subject: [U-Boot-Users] [PATCH] USB: remove a cpu bug workaround for an
	unsupported architecture
In-Reply-To: <87wsmpymt8.fsf@denx.de> ("Markus =?utf-8?Q?Klotzb=C3=BCcher?=
	=?utf-8?Q?=22's?= message of "Wed\, 23 Apr 2008 10\:53\:23 +0200")
References: <87wsmpymt8.fsf@denx.de>
Message-ID: <87lk35ymma.fsf@denx.de>


USB: remove a cpu bug workaround for an unsupported architecture.

Signed-off-by: Markus Klotzbuecher <mk at denx.de>

---

 drivers/usb/usb_ohci.c |   22 ++++------------------
 1 files changed, 4 insertions(+), 18 deletions(-)


diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c
index d37a037..ee0f2e4 100644
--- a/drivers/usb/usb_ohci.c
+++ b/drivers/usb/usb_ohci.c
@@ -138,28 +138,14 @@ int got_rhsc;
 /* device which was disconnected */
 struct usb_device *devgone;
 
-/*-------------------------------------------------------------------------*/
-
-/* AMD-756 (D2 rev) reports corrupt register contents in some cases.
- * The erratum (#4) description is incorrect.  AMD's workaround waits
- * till some bits (mostly reserved) are clear; ok for all revs.
- */
-#define OHCI_QUIRK_AMD756 0xabcd
-#define read_roothub(hc, register, mask) ({ \
-	u32 temp = readl (&hc->regs->roothub.register); \
-	if (hc->flags & OHCI_QUIRK_AMD756) \
-		while (temp & mask) \
-			temp = readl (&hc->regs->roothub.register); \
-	temp; })
-
-static u32 roothub_a (struct ohci *hc)
-	{ return read_roothub (hc, a, 0xfc0fe000); }
+static inline u32 roothub_a (struct ohci *hc)
+	{ return readl (&hc->regs->roothub.a); }
 static inline u32 roothub_b (struct ohci *hc)
 	{ return readl (&hc->regs->roothub.b); }
 static inline u32 roothub_status (struct ohci *hc)
 	{ return readl (&hc->regs->roothub.status); }
-static u32 roothub_portstatus (struct ohci *hc, int i)
-	{ return read_roothub (hc, portstatus [i], 0xffe0fce0); }
+static inline u32 roothub_portstatus (struct ohci *hc, int i)
+	{ return readl (&hc->regs->roothub.portstatus[i]); }
 
 /* forward declaration */
 static int hc_interrupt (void);


Best regards

     Markus

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



From vasiliy.leonenko at mail.ru  Wed Apr 23 11:42:21 2008
From: vasiliy.leonenko at mail.ru (Vasiliy Leoenenko)
Date: Wed, 23 Apr 2008 13:42:21 +0400
Subject: [U-Boot-Users] =?koi8-r?b?W1BBVENIXSBNMTggZmxhc2ggKFNpYmxleSkg?=
	=?koi8-r?b?c3VwcG9ydCAoYXR0ZW1wdCAyKQ==?=
In-Reply-To: <200804210902.38080.sr@denx.de>
References: <200804210902.38080.sr@denx.de>
Message-ID: <E1JobUb-000OPI-00.vasiliy-leonenko-mail-ru@f69.mail.ru>



Hi, Stefan

> Sorry, but I really forgot about this patch. Could you please resend this 
> patch against the current tot, since it doesn't apply cleanly anymore?

I prepared patch for u-boot version 1.3.2. Any comments and suggestions are welcome.
Code(included below) was verified on Mainstone II board with M18 flash chip.
Please don't forget to include it :)

Best regards,
Vasiliy

Signed-off-by: Vasiliy Leonenko <vasiliy.leonenko at mail.ru>
Signed-off-by: Alexey Korolev <akorolex at gmail.com>
====================================================
diff -aupNr a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
--- a/drivers/mtd/cfi_flash.c	2008-04-21 02:39:38.000000000 +0400
+++ b/drivers/mtd/cfi_flash.c	2008-04-22 16:26:29.000000000 +0400
@@ -77,6 +77,7 @@
 #define FLASH_CMD_PROTECT_CLEAR		0xD0
 #define FLASH_CMD_CLEAR_STATUS		0x50
 #define FLASH_CMD_WRITE_TO_BUFFER	0xE8
+#define FLASH_CMD_WRITE_BUFFER_PROG	0xE9
 #define FLASH_CMD_WRITE_BUFFER_CONFIRM	0xD0
 
 #define FLASH_STATUS_DONE		0x80
@@ -136,6 +137,7 @@
 #define CFI_CMDSET_MITSU_STANDARD	256
 #define CFI_CMDSET_MITSU_EXTENDED	257
 #define CFI_CMDSET_SST			258
+#define CFI_CMDSET_INTEL_PROG_REGIONS	512
 
 #ifdef CFG_FLASH_CFI_AMD_RESET /* needed for STM_ID_29W320DB on UC100 */
 # undef  FLASH_CMD_RESET
@@ -298,7 +300,7 @@ static inline void flash_unmap(flash_inf
 /*-----------------------------------------------------------------------
  * make a proper sized command based on the port and chip widths
  */
-static void flash_make_cmd (flash_info_t * info, uchar cmd, void *cmdbuf)
+static void flash_make_cmd (flash_info_t * info, ulong cmd, void *cmdbuf)
 {
 	int i;
 	uchar *cp = (uchar *) cmdbuf;
@@ -308,7 +310,8 @@ static void flash_make_cmd (flash_info_t
 #else
 	for (i = 1; i <= info->portwidth; i++)
 #endif
-		*cp++ = (i & (info->chipwidth - 1)) ? '\0' : cmd;
+		*cp++ = (i > info->chipwidth) ? '\0' : 
+				*((uchar *)&cmd + info->portwidth - i);
 }
 
 #ifdef DEBUG
@@ -422,7 +425,7 @@ static ulong flash_read_long (flash_info
  * Write a proper sized command to the correct address
  */
 static void flash_write_cmd (flash_info_t * info, flash_sect_t sect,
-			     uint offset, uchar cmd)
+			     uint offset, ulong cmd)
 {
 
 	void *addr;
@@ -605,6 +608,7 @@ static int flash_is_busy (flash_info_t *
 	int retval;
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
 		retval = !flash_isset (info, sect, 0, FLASH_STATUS_DONE);
@@ -664,6 +668,7 @@ static int flash_full_status_check (flas
 
 	retcode = flash_status_check (info, sector, tout, prompt);
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_EXTENDED:
 	case CFI_CMDSET_INTEL_STANDARD:
 		if ((retcode == ERR_OK)
@@ -792,6 +797,7 @@ static int flash_write_cfiword (flash_in
 	flag = disable_interrupts ();
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_EXTENDED:
 	case CFI_CMDSET_INTEL_STANDARD:
 		flash_write_cmd (info, 0, 0, FLASH_CMD_CLEAR_STATUS);
@@ -846,6 +852,7 @@ static int flash_write_cfibuffer (flash_
 	int flag = 0;
 	uint offset = 0;
 	unsigned int shift;
+	uchar write_cmd; 
 
 	switch (info->portwidth) {
 	case FLASH_CFI_8BIT:
@@ -900,10 +907,13 @@ static int flash_write_cfibuffer (flash_
 	sector = find_sector (info, dest);
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
+		write_cmd = (info->vendor == CFI_CMDSET_INTEL_PROG_REGIONS) ? 
+					FLASH_CMD_WRITE_BUFFER_PROG : FLASH_CMD_WRITE_TO_BUFFER;
 		flash_write_cmd (info, sector, 0, FLASH_CMD_CLEAR_STATUS);
-		flash_write_cmd (info, sector, 0, FLASH_CMD_WRITE_TO_BUFFER);
+		flash_write_cmd (info, sector, 0, write_cmd);
 		retcode = flash_status_check (info, sector,
 					      info->buffer_write_tout,
 					      "write to buffer");
@@ -911,7 +921,7 @@ static int flash_write_cfibuffer (flash_
 			/* reduce the number of loops by the width of
 			 * the port */
 			cnt = len >> shift;
-			flash_write_cmd (info, sector, 0, (uchar) cnt - 1);
+			flash_write_cmd (info, sector, 0, cnt - 1);
 			while (cnt-- > 0) {
 				switch (info->portwidth) {
 				case FLASH_CFI_8BIT:
@@ -1038,6 +1048,7 @@ int flash_erase (flash_info_t * info, in
 	for (sect = s_first; sect <= s_last; sect++) {
 		if (info->protect[sect] == 0) { /* not protected */
 			switch (info->vendor) {
+			case CFI_CMDSET_INTEL_PROG_REGIONS:
 			case CFI_CMDSET_INTEL_STANDARD:
 			case CFI_CMDSET_INTEL_EXTENDED:
 				flash_write_cmd (info, sect, 0,
@@ -1106,6 +1117,9 @@ void flash_print_info (flash_info_t * in
 			info->size >> 20, info->sector_count);
 	printf ("  ");
 	switch (info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
+			printf ("Intel Prog Regions");
+			break;
 		case CFI_CMDSET_INTEL_STANDARD:
 			printf ("Intel Standard");
 			break;
@@ -1496,6 +1510,7 @@ static void flash_read_jedec_ids (flash_
 	info->device_id2      = 0;
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
 		cmdset_intel_read_jedec_ids(info);
@@ -1550,6 +1565,7 @@ static int flash_detect_legacy(ulong bas
 		}
 
 		switch(info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
 		case CFI_CMDSET_INTEL_STANDARD:
 		case CFI_CMDSET_INTEL_EXTENDED:
 			info->cmd_reset = FLASH_CMD_RESET;
@@ -1745,6 +1761,7 @@ ulong flash_get_size (ulong base, int ba
 #endif
 
 		switch (info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
 		case CFI_CMDSET_INTEL_STANDARD:
 		case CFI_CMDSET_INTEL_EXTENDED:
 			cmdset_intel_init(info, &qry);
@@ -1822,6 +1839,7 @@ ulong flash_get_size (ulong base, int ba
 				 * supported devices (intel...)
 				 */
 				switch (info->vendor) {
+				case CFI_CMDSET_INTEL_PROG_REGIONS:
 				case CFI_CMDSET_INTEL_EXTENDED:
 				case CFI_CMDSET_INTEL_STANDARD:
 					info->protect[sect_cnt] =





From narendra.ka at lntemsys.com  Wed Apr 23 12:45:11 2008
From: narendra.ka at lntemsys.com (gforgcc)
Date: Wed, 23 Apr 2008 03:45:11 -0700 (PDT)
Subject: [U-Boot-Users]  Kernel hanging after lmb_end_of_DRAM() function
Message-ID: <16833978.post@talk.nabble.com>


Hi geeks,
i am trying to bring up the latest kernel on EP8248 target,
i am using U-boot-1.3.2 and linux-2.6.25-rc8, i started debugging using
BDI2000 which helped me to know atleast what is going wrong, i have added
some printk's in the kernel source but still i am not able to find where and
what exactly is going wrong, The first statement it is printing in the log
buffer is
""Using Embedded Planet EP8248E machine description"" and thats it the next
message is
Unable to handle kernel paging request for data at address 0xbfff0000
Faulting instruction address:0xc0012070 (This nearest address to this
address in System.map file is cacheable_memzero)
and tracing like this i came to know that in the file
arch/powerpc/mm/ppc_mmu_32.c , here in the function __init MMU_init_hw() and
in the line n_hpteg = total_memory / (PAGE_SIZE * 8); probably it is getting
problem because when i tried to print the variable total_memory it is
printing zero !!! :( :(  so probably i am thinking it is not able to find
some memory for Hash table :(
Please share your knowledge and skills and help me to resolve this issue..
thanks  :)
-- 
View this message in context: http://www.nabble.com/Kernel-hanging-after-lmb_end_of_DRAM%28%29-function-tp16833978p16833978.html
Sent from the Uboot - Users mailing list archive at Nabble.com.




From trimarchi at gandalf.sssup.it  Wed Apr 23 13:15:55 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Wed, 23 Apr 2008 13:15:55 +0200
Subject: [U-Boot-Users] USB SUPPORT & get_vfatname
In-Reply-To: <480EEFCC.3030009@gandalf.sssup.it>
References: <AA28F077645B324881335614E4F7C428034CD8@win-ex01.bench.com>
	<480EDD25.3030809@gandalf.sssup.it>
	<480EEFCC.3030009@gandalf.sssup.it>
Message-ID: <480F1A6B.6070207@gandalf.sssup.it>

Hi,

michael wrote:
> Hi,
>
> Can you try this one?
>
> Revert my last one patch?
> It change the test code, before the while. I use your script on a 
> Compact Flash and it looks fine for me (under linux).
>
> Regards Michael
>
> ------------------------------------------------------------------------
>
> Check if the entry is a valid dir_slot entry, otherwise it is a dentry and the
> name has to be taken by the get_name function
>
> Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>
>
> ---
>  fs/fat/fat.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 49c78ed..bc37cec 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int curclust, __u8 *cluster,
>  		while (slotptr2->id > 0x01) {
>  			slotptr2++;
>  		}
> +
>  		/* Save the real directory entry */
>  		realdent = (dir_entry*)slotptr2 + 1;
> +		if (slotptr2->attr != ATTR_VFAT) {
> +			get_name ((dir_entry *)realdent, l_name);
> +			goto out;
> +		}
> +
>  		while ((__u8*)slotptr2 >= get_vfatname_block) {
>  			slot2str(slotptr2, l_name, &idx);
>  			slotptr2--;
> @@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int curclust, __u8 *cluster,
>  	else if (*l_name == aRING) *l_name = '?';
>  	downcase(l_name);
>  
> +out:
>  	/* Return the real directory entry */
>  	memcpy(retdent, realdent, sizeof(dir_entry));
>  
>   
The scripts in this thread can be used to test the fat32 filesystem. I 
do some tests using Compact Flash
device and this patchs work for me. I would like to know if is a fat 
layer problem or usb layer problem.

Michael




From sr at denx.de  Wed Apr 23 14:42:29 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 23 Apr 2008 14:42:29 +0200
Subject: [U-Boot-Users] PPC440EPx/sequoia TLB question...
In-Reply-To: <480EA8E1.4060207@verizon.net>
References: <480EA8E1.4060207@verizon.net>
Message-ID: <200804231442.29687.sr@denx.de>

On Wednesday 23 April 2008, Dave Littell wrote:
> >From ?/board/amcc/sequoia/init.S:
>
> /* TLB-entry for Internal Registers & OCM */
> tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0, AC_R|AC_W|AC_X|SA_I )
>
> Why is this memory region not marked Guarded?  It would seem to meet the
> definition of ?non-well-behaved?.

Why do you think this is the case?

> Also the TLB entry for SDRAM marks it Guarded, but that?s one area I
> would think wouldn't need to be Guarded.

This could be a mistake. Should work without G bis set too. Please give it a 
try and send a patch to fix it, if it works fine.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Wed Apr 23 14:49:24 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 23 Apr 2008 14:49:24 +0200
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
In-Reply-To: <480EADF4.2020706@verizon.net>
References: <480EADF4.2020706@verizon.net>
Message-ID: <200804231449.24746.sr@denx.de>

On Wednesday 23 April 2008, Dave Littell wrote:
> I'm working on an AMCC PPC440EPx-based platform that's similar to the
> Sequoia.  The board runs pretty well, but occasionally takes exceptions
> both in U-Boot and while running Linux.  The exceptions vary from
> Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and
> DTLB Errors, to DSI, etc., which made us believe there's a problem with
> SDRAM.

Yes, this is my first idea too. Almost every time such "random" errors are 
seen, SDRAM setup/initialization is the cause for it.

> Sometimes there are simple hard lockups from which even the JTAG 
> can't regain control.  However, the SDRAM physical/electrical and DDR
> Controller configurations have been investigated in detail (and some
> corrections made) with no resulting improvement in the exception behavior.

Is the SDRAM termination similar to the one used on Sequoia too? Are you using 
soldered chips and not DIMM modules? Is ECC available?

> We see problems primarily at 667 MHz but have noted some issues at 533
> MHz as well.  Some boards seem particularly susceptible to this while
> others rarely (if ever) exhibit the problem.
>
> At this point all possibilities are on the table and I'm looking for any
> input from anyone with experience (good, bad, or whatever) with this
> processor and/or designs similar to the Sequoia.

If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will 
most likely find some references.

Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the 
440EPx CHIP 11 errata. I suggest you take a look at this too and see if this 
changes your behavior.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Wed Apr 23 15:12:03 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 23 Apr 2008 15:12:03 +0200
Subject: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
In-Reply-To: <fa686aa40804221218r3cef9c8bi38ba04438922fe2f@mail.gmail.com>
References: <480E34A6.6010509@acm.org>
	<fa686aa40804221218r3cef9c8bi38ba04438922fe2f@mail.gmail.com>
Message-ID: <200804231512.03751.sr@denx.de>

Hi Larry,

On Tuesday 22 April 2008, Grant Likely wrote:
> > Currently, I can build "zImage" for Sequoia using the powerpc
> > architecture, and load it using U-Boot without a separate FDT binary.
> > Is this the best way to run a Linux from the powerpc tree?
>
> Sorry, I don't understand what you're asking.
>
> There are two way to boot a Linux image from arch/powerpc.
>
> 1) build a uImage and get u-boot to pass a device tree blob (if your u-boot
> had device tree support)
> 2) build a cuImage which wraps the device tree in the kernel image.

Correct. Personally I prefer 1), since it makes the Linux ports easier. No 
bootwrapper is needed in this case. And all the "infrastructure" for fdt 
enabled U-Boot images for 4xx is available. Please take a look at 
sequoia.c/.h and search for CONFIG_OF_LIBFDT.

Just let me know if this is not clear or if you have additional questions.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From garyj at denx.de  Wed Apr 23 15:12:35 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Wed, 23 Apr 2008 15:12:35 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Add the Harris QUAD100HD AMCC
	405EP-based board.
Message-ID: <20080423151235.5c236344@peedub.jennejohn.org>


Add the Harris QUAD100HD AMCC 405EP-based board.

Signed-off-by: Gary Jennejohn <garyj at denx.de>
---
 MAINTAINERS                 |    4 +
 MAKEALL                     |    1 +
 Makefile                    |    3 +
 board/quad100hd/Makefile    |   51 ++
 board/quad100hd/config.mk   |   24 +
 board/quad100hd/flash.c     | 1097 +++++++++++++++++++++++++++++++++++++++++++
 board/quad100hd/nand.c      |  156 ++++++
 board/quad100hd/quad100hd.c |  113 +++++
 board/quad100hd/u-boot.lds  |  133 ++++++
 include/configs/quad100hd.h |  306 ++++++++++++
 10 files changed, 1888 insertions(+), 0 deletions(-)
 create mode 100644 board/quad100hd/Makefile
 create mode 100644 board/quad100hd/config.mk
 create mode 100644 board/quad100hd/flash.c
 create mode 100644 board/quad100hd/nand.c
 create mode 100644 board/quad100hd/quad100hd.c
 create mode 100644 board/quad100hd/u-boot.lds
 create mode 100644 include/configs/quad100hd.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d1782b4..3af55a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -204,6 +204,10 @@ Klaus Heydeck <heydeck at kieback-peter.de>
 	KUP4K			MPC855
 	KUP4X			MPC859
 
+Gary Jennejohn <garyj at denx.de>
+
+	quad100hd		PPC405EP
+
 Murray Jensen <Murray.Jensen at csiro.au>
 
 	cogent_mpc8xx		MPC8xx
diff --git a/MAKEALL b/MAKEALL
index 8241f45..31e4866 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -218,6 +218,7 @@ LIST_4xx="		\
 	PMC405		\
 	PMC440		\
 	PPChameleonEVB	\
+	quad100hd	\
 	rainier		\
 	sbc405		\
 	sc3		\
diff --git a/Makefile b/Makefile
index ab56831..8b3a7f0 100644
--- a/Makefile
+++ b/Makefile
@@ -1386,6 +1386,9 @@ PPChameleonEVB_HI_33_config:	unconfig
 		}
 	@$(MKCONFIG) -a $(call xtract_4xx,$@) ppc ppc4xx PPChameleonEVB dave
 
+quad100hd_config:	unconfig
+	@$(MKCONFIG) $(@:_config=) ppc ppc4xx quad100hd
+
 sbc405_config:	unconfig
 	@$(MKCONFIG) $(@:_config=) ppc ppc4xx sbc405
 
diff --git a/board/quad100hd/Makefile b/board/quad100hd/Makefile
new file mode 100644
index 0000000..1f79eae
--- /dev/null
+++ b/board/quad100hd/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2007
+# Stefan Roese, DENX Software Engineering, sr at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).a
+
+COBJS	= $(BOARD).o nand.o flash.o
+SOBJS   =
+
+SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+SOBJS	:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB):	$(OBJS) $(SOBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+	rm -f $(SOBJS) $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/quad100hd/config.mk b/board/quad100hd/config.mk
new file mode 100644
index 0000000..71c0476
--- /dev/null
+++ b/board/quad100hd/config.mk
@@ -0,0 +1,24 @@
+#
+# (C) Copyright 2000
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+TEXT_BASE = 0xFFF80000
diff --git a/board/quad100hd/flash.c b/board/quad100hd/flash.c
new file mode 100644
index 0000000..c3a034f
--- /dev/null
+++ b/board/quad100hd/flash.c
@@ -0,0 +1,1097 @@
+/*
+ * (C) Copyright 2000
+ * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/*
+ * Modified 4/5/2001
+ * Wait for completion of each sector erase command issued
+ * 4/5/2001
+ * Chris Hallinan - DS4.COM, Inc. - clh at net1plus.com
+ */
+
+#include <common.h>
+#include <ppc4xx.h>
+#include <asm/processor.h>
+
+flash_info_t flash_info[CFG_MAX_FLASH_BANKS];	/* info for FLASH chips        */
+
+#undef DEBUG
+#ifdef DEBUG
+#define DEBUGF(x...) printf(x)
+#else
+#define DEBUGF(x...)
+#endif				/* DEBUG */
+
+#ifdef FLASH_BASE1_PRELIM
+#define CFG_FLASH_CHAR_SIZE unsigned char
+#define CFG_FLASH_CHAR_ADDR0 (0x0555)
+#define CFG_FLASH_CHAR_ADDR1 (0x02aa)
+#endif
+/*-----------------------------------------------------------------------
+ * Functions
+ */
+static ulong flash_get_size(vu_long * addr, flash_info_t * info);
+static void flash_get_offsets(ulong base, flash_info_t * info);
+static int write_word(flash_info_t * info, ulong dest, ulong data);
+#ifdef FLASH_BASE1_PRELIM
+static int write_word_1(flash_info_t * info, ulong dest, ulong data);
+static int write_word_2(flash_info_t * info, ulong dest, ulong data);
+static int flash_erase_1(flash_info_t * info, int s_first, int s_last);
+static int flash_erase_2(flash_info_t * info, int s_first, int s_last);
+static ulong flash_get_size_1(vu_long * addr, flash_info_t * info);
+static ulong flash_get_size_2(vu_long * addr, flash_info_t * info);
+#endif
+
+unsigned long flash_init(void)
+{
+	unsigned long size_b0, size_b1=0;
+	int i;
+
+	/* Init: no FLASHes known */
+	for (i = 0; i < CFG_MAX_FLASH_BANKS; ++i) {
+		flash_info[i].flash_id = FLASH_UNKNOWN;
+	}
+
+	/* Static FLASH Bank configuration here - FIXME XXX */
+
+	size_b0 =
+	    flash_get_size((vu_long *) FLASH_BASE0_PRELIM, &flash_info[0]);
+
+	if (flash_info[0].flash_id == FLASH_UNKNOWN) {
+		printf("## Unknown FLASH on Bank 0 - Size = 0x%08lx = %ld MB\n",
+		       size_b0, size_b0 << 20);
+	}
+
+	if (size_b0) {
+		/* Setup offsets */
+		flash_get_offsets(FLASH_BASE0_PRELIM, &flash_info[0]);
+		/* Monitor protection ON by default */
+		(void)flash_protect(FLAG_PROTECT_SET,
+				    CFG_MONITOR_BASE,
+				    CFG_MONITOR_BASE + CFG_MONITOR_LEN - 1,
+				    &flash_info[0]);
+#ifdef CFG_ENV_IS_IN_FLASH
+		(void)flash_protect(FLAG_PROTECT_SET, CFG_ENV_ADDR,
+				    CFG_ENV_ADDR + CFG_ENV_SECT_SIZE - 1,
+				    &flash_info[0]);
+		(void)flash_protect(FLAG_PROTECT_SET, CFG_ENV_ADDR_REDUND,
+				    CFG_ENV_ADDR_REDUND + CFG_ENV_SECT_SIZE - 1,
+				    &flash_info[0]);
+#endif
+		/* Also protect sector containing initial power-up instruction */
+		/* (flash_protect() checks address range - other call ignored) */
+		(void)flash_protect(FLAG_PROTECT_SET,
+				    0xFFFFFFFC, 0xFFFFFFFF, &flash_info[0]);
+
+		flash_info[0].size = size_b0;
+	}
+#ifdef FLASH_BASE1_PRELIM
+	size_b1 =
+	    flash_get_size((vu_long *) FLASH_BASE1_PRELIM, &flash_info[1])*2;
+
+	if (flash_info[1].flash_id == FLASH_UNKNOWN) {
+		printf("## Unknown FLASH on Bank 1 - Size = 0x%08lx = %ld MB\n",
+		       size_b1, size_b1 << 20);
+	}
+
+	if (size_b1) {
+		/* Setup offsets */
+		flash_get_offsets(FLASH_BASE1_PRELIM, &flash_info[1]);
+		flash_info[1].size = size_b1;
+	}
+#endif
+	return (size_b0 + size_b1);
+}
+
+static void flash_get_offsets(ulong base, flash_info_t * info)
+{
+	int i;
+
+	/* set up sector start address table */
+	if (((info->flash_id & FLASH_VENDMASK) == FLASH_MAN_SST) ||
+	    (info->flash_id == FLASH_AM040)) {
+		for (i = 0; i < info->sector_count; i++)
+			info->start[i] = base + (i * 0x00010000);
+	} else if ((info->flash_id & FLASH_TYPEMASK) == FLASH_AMLV128U) {
+		for (i = 0; i < info->sector_count; i++) {
+			info->start[i] = base + (i * 0x00010000*2);
+		}
+	} else if ((info->flash_id & FLASH_TYPEMASK) == FLASH_S29GL128N ) {
+		for (i = 0; i < info->sector_count; i++) {
+			info->start[i] = base + (i * 0x00020000*2);
+		}
+	} else {
+		if (info->flash_id & FLASH_BTYPE) {
+			/* set sector offsets for bottom boot block type        */
+			info->start[0] = base + 0x00000000;
+			info->start[1] = base + 0x00004000;
+			info->start[2] = base + 0x00006000;
+			info->start[3] = base + 0x00008000;
+			for (i = 4; i < info->sector_count; i++) {
+				info->start[i] =
+				    base + (i * 0x00010000) - 0x00030000;
+			}
+		} else {
+			/* set sector offsets for top boot block type           */
+			i = info->sector_count - 1;
+			info->start[i--] = base + info->size - 0x00004000;
+			info->start[i--] = base + info->size - 0x00006000;
+			info->start[i--] = base + info->size - 0x00008000;
+			for (; i >= 0; i--) {
+				info->start[i] = base + i * 0x00010000;
+			}
+		}
+	}
+}
+
+
+void flash_print_info(flash_info_t * info)
+{
+	int i;
+	int k;
+	int size;
+	int erased;
+	volatile unsigned long *flash;
+
+	if (info->flash_id == FLASH_UNKNOWN) {
+		printf("missing or unknown FLASH type\n");
+		return;
+	}
+
+	switch (info->flash_id & FLASH_VENDMASK) {
+	case FLASH_MAN_AMD:
+		printf("AMD ");
+		break;
+	case FLASH_MAN_STM:
+		printf("STM ");
+		break;
+	case FLASH_MAN_FUJ:
+		printf("FUJITSU ");
+		break;
+	case FLASH_MAN_SST:
+		printf("SST ");
+		break;
+	default:
+		printf("Unknown Vendor ");
+		break;
+	}
+
+	switch (info->flash_id & FLASH_TYPEMASK) {
+	case FLASH_AM040:
+		printf("AM29F040 (512 Kbit, uniform sector size)\n");
+		break;
+	case FLASH_AM400B:
+		printf("AM29LV400B (4 Mbit, bottom boot sect)\n");
+		break;
+	case FLASH_AM400T:
+		printf("AM29LV400T (4 Mbit, top boot sector)\n");
+		break;
+	case FLASH_AM800B:
+		printf("AM29LV800B (8 Mbit, bottom boot sect)\n");
+		break;
+	case FLASH_AM800T:
+		printf("AM29LV800T (8 Mbit, top boot sector)\n");
+		break;
+	case FLASH_AMD016:
+		printf("AM29F016D (16 Mbit, uniform sector size)\n");
+		break;
+	case FLASH_AM160B:
+		printf("AM29LV160B (16 Mbit, bottom boot sect)\n");
+		break;
+	case FLASH_AM160T:
+		printf("AM29LV160T (16 Mbit, top boot sector)\n");
+		break;
+	case FLASH_AM320B:
+		printf("AM29LV320B (32 Mbit, bottom boot sect)\n");
+		break;
+	case FLASH_AM320T:
+		printf("AM29LV320T (32 Mbit, top boot sector)\n");
+		break;
+	case FLASH_AM033C:
+		printf("AM29LV033C (32 Mbit, top boot sector)\n");
+		break;
+	case FLASH_AMLV128U:
+		printf("AM29LV128U (128 Mbit * 2, top boot sector)\n");
+		break;
+	case FLASH_SST800A:
+		printf("SST39LF/VF800 (8 Mbit, uniform sector size)\n");
+		break;
+	case FLASH_SST160A:
+		printf("SST39LF/VF160 (16 Mbit, uniform sector size)\n");
+		break;
+	case FLASH_STMW320DT:
+		printf ("M29W320DT (32 M, top sector)\n");
+		break;
+	case FLASH_S29GL128N:
+		printf ("S29GL128N (256 Mbit, uniform sector size)\n");
+		break;
+	default:
+		printf("Unknown Chip Type\n");
+		break;
+	}
+
+	printf("  Size: %ld KB in %d Sectors\n",
+	       info->size >> 10, info->sector_count);
+
+	printf("  Sector Start Addresses:");
+	for (i = 0; i < info->sector_count; ++i) {
+		/*
+		 * Check if whole sector is erased
+		 */
+		if (i != (info->sector_count - 1))
+			size = info->start[i + 1] - info->start[i];
+		else
+			size = info->start[0] + info->size - info->start[i];
+		erased = 1;
+		flash = (volatile unsigned long *)info->start[i];
+		size = size >> 2;	/* divide by 4 for longword access */
+		for (k = 0; k < size; k++) {
+			if (*flash++ != 0xffffffff) {
+				erased = 0;
+				break;
+			}
+		}
+
+		if ((i % 5) == 0)
+			printf("\n   ");
+		printf(" %08lX%s%s",
+		       info->start[i],
+		       erased ? " E" : "  ", info->protect[i] ? "RO " : "   ");
+	}
+	printf("\n");
+	return;
+}
+
+
+/*
+ * The following code cannot be run from FLASH!
+ */
+#ifdef FLASH_BASE1_PRELIM
+static ulong flash_get_size(vu_long * addr, flash_info_t * info)
+{
+	if ((ulong)addr == FLASH_BASE1_PRELIM) {
+		return flash_get_size_2(addr, info);
+	} else {
+		return flash_get_size_1(addr, info);
+	}
+}
+
+static ulong flash_get_size_1(vu_long * addr, flash_info_t * info)
+#else
+static ulong flash_get_size(vu_long * addr, flash_info_t * info)
+#endif
+{
+	short i;
+	CFG_FLASH_WORD_SIZE value;
+	ulong base = (ulong) addr;
+	volatile CFG_FLASH_WORD_SIZE *addr2 = (CFG_FLASH_WORD_SIZE *) addr;
+
+	DEBUGF("FLASH ADDR: %08x\n", (unsigned)addr);
+
+	/* Write auto select command: read Manufacturer ID */
+	addr2[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00AA00AA;
+	addr2[CFG_FLASH_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x00550055;
+	addr2[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00900090;
+	udelay(1000);
+
+	value = addr2[0];
+	DEBUGF("FLASH MANUFACT: %x\n", value);
+
+	switch (value) {
+	case (CFG_FLASH_WORD_SIZE) AMD_MANUFACT:
+		info->flash_id = FLASH_MAN_AMD;
+		break;
+	case (CFG_FLASH_WORD_SIZE) FUJ_MANUFACT:
+		info->flash_id = FLASH_MAN_FUJ;
+		break;
+	case (CFG_FLASH_WORD_SIZE) SST_MANUFACT:
+		info->flash_id = FLASH_MAN_SST;
+		break;
+	case (CFG_FLASH_WORD_SIZE) STM_MANUFACT:
+		info->flash_id = FLASH_MAN_STM;
+		break;
+	default:
+		info->flash_id = FLASH_UNKNOWN;
+		info->sector_count = 0;
+		info->size = 0;
+		return 0;	/* no or unknown flash  */
+	}
+
+	value = addr2[1];	/* device ID            */
+	DEBUGF("\nFLASH DEVICEID: %x\n", value);
+
+	switch (value) {
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_LV040B:
+		info->flash_id += FLASH_AM040;
+		info->sector_count = 8;
+		info->size = 0x0080000;	/* => 512 ko */
+		break;
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_F040B:
+		info->flash_id += FLASH_AM040;
+		info->sector_count = 8;
+		info->size = 0x0080000;	/* => 512 ko */
+		break;
+
+	case (CFG_FLASH_WORD_SIZE) STM_ID_M29W040B:
+		info->flash_id += FLASH_AM040;
+		info->sector_count = 8;
+		info->size = 0x0080000;	/* => 512 ko */
+		break;
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_F016D:
+		info->flash_id += FLASH_AMD016;
+		info->sector_count = 32;
+		info->size = 0x00200000;
+		break;		/* => 2 MB              */
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_LV033C:
+		info->flash_id += FLASH_AMDLV033C;
+		info->sector_count = 64;
+		info->size = 0x00400000;
+		break;		/* => 4 MB              */
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_LV400T:
+		info->flash_id += FLASH_AM400T;
+		info->sector_count = 11;
+		info->size = 0x00080000;
+		break;		/* => 0.5 MB            */
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_LV400B:
+		info->flash_id += FLASH_AM400B;
+		info->sector_count = 11;
+		info->size = 0x00080000;
+		break;		/* => 0.5 MB            */
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_LV800T:
+		info->flash_id += FLASH_AM800T;
+		info->sector_count = 19;
+		info->size = 0x00100000;
+		break;		/* => 1 MB              */
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_LV800B:
+		info->flash_id += FLASH_AM800B;
+		info->sector_count = 19;
+		info->size = 0x00100000;
+		break;		/* => 1 MB              */
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_LV160T:
+		info->flash_id += FLASH_AM160T;
+		info->sector_count = 35;
+		info->size = 0x00200000;
+		break;		/* => 2 MB              */
+
+	case (CFG_FLASH_WORD_SIZE) AMD_ID_LV160B:
+		info->flash_id += FLASH_AM160B;
+		info->sector_count = 35;
+		info->size = 0x00200000;
+		break;		/* => 2 MB              */
+        case (CFG_FLASH_WORD_SIZE)AMD_ID_LV320T:
+                info->flash_id += FLASH_AM320T;
+                info->sector_count = 67;
+                info->size = 0x00400000;
+                break;                          /* => 4 MB              */
+
+        case (CFG_FLASH_WORD_SIZE)AMD_ID_LV320B:
+                info->flash_id += FLASH_AM320B;
+                info->sector_count = 67;
+                info->size = 0x00400000;
+                break;                          /* => 4 MB              */
+
+	default:
+		info->flash_id = FLASH_UNKNOWN;
+		return 0;	/* => no or unknown flash */
+	}
+
+	/* set up sector start address table */
+	if (((info->flash_id & FLASH_VENDMASK) == FLASH_MAN_SST) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_AM040) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_AMD016)) {
+		for (i = 0; i < info->sector_count; i++)
+			info->start[i] = base + (i * 0x00010000);
+	}
+	else if ((info->flash_id & FLASH_TYPEMASK) == FLASH_AMLV128U) {
+		for (i = 0; i < info->sector_count; i++)
+			info->start[i] = base + (i * 0x00010000 * 2);
+	} else {
+		if (info->flash_id & FLASH_BTYPE) {
+			/* set sector offsets for bottom boot block type        */
+			info->start[0] = base + 0x00000000;
+			info->start[1] = base + 0x00004000;
+			info->start[2] = base + 0x00006000;
+			info->start[3] = base + 0x00008000;
+			for (i = 4; i < info->sector_count; i++) {
+				info->start[i] =
+				    base + (i * 0x00010000) - 0x00030000;
+			}
+		} else {
+			/* set sector offsets for top boot block type           */
+			i = info->sector_count - 1;
+			info->start[i--] = base + info->size - 0x00004000;
+			info->start[i--] = base + info->size - 0x00006000;
+			info->start[i--] = base + info->size - 0x00008000;
+			for (; i >= 0; i--) {
+				info->start[i] = base + i * 0x00010000;
+			}
+		}
+	}
+
+	/* check for protected sectors */
+	for (i = 0; i < info->sector_count; i++) {
+		/* read sector protection at sector address, (A7 .. A0) = 0x02 */
+		/* D0 = 1 if protected */
+		addr2 = (volatile CFG_FLASH_WORD_SIZE *)(info->start[i]);
+
+		/* For AMD29033C flash we need to resend the command of *
+		 * reading flash protection for upper 8 Mb of flash     */
+		if (i == 32) {
+			addr2[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xAAAAAAAA;
+			addr2[CFG_FLASH_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x55555555;
+			addr2[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x90909090;
+		}
+
+		if ((info->flash_id & FLASH_VENDMASK) == FLASH_MAN_SST)
+			info->protect[i] = 0;
+		else
+			info->protect[i] = addr2[2] & 1;
+	}
+
+	/* issue bank reset to return to read mode */
+	addr2[0] = (CFG_FLASH_WORD_SIZE) 0x00F000F0;
+
+	return info->size;
+}
+
+static int wait_for_DQ7_1(flash_info_t * info, int sect)
+{
+	ulong start, now, last;
+	volatile CFG_FLASH_WORD_SIZE *addr =
+	    (CFG_FLASH_WORD_SIZE *) (info->start[sect]);
+
+	start = get_timer(0);
+	last = start;
+	while ((addr[0] & (CFG_FLASH_WORD_SIZE) 0x00800080) !=
+	       (CFG_FLASH_WORD_SIZE) 0x00800080) {
+		if ((now = get_timer(start)) > CFG_FLASH_ERASE_TOUT) {
+			printf("Timeout\n");
+			return -1;
+		}
+		/* show that we're waiting */
+		if ((now - last) > 1000) {	/* every second */
+			putc('.');
+			last = now;
+		}
+	}
+	return 0;
+}
+
+#ifdef FLASH_BASE1_PRELIM
+int flash_erase(flash_info_t * info, int s_first, int s_last)
+{
+	if (((info->flash_id & FLASH_TYPEMASK) == FLASH_AM320B) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_AM320T) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_AMLV128U) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_S29GL128N) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_STMW320DT)) {
+		return flash_erase_2(info, s_first, s_last);
+	} else {
+		return flash_erase_1(info, s_first, s_last);
+	}
+}
+
+static int flash_erase_1(flash_info_t * info, int s_first, int s_last)
+#else
+int flash_erase(flash_info_t * info, int s_first, int s_last)
+#endif
+{
+	volatile CFG_FLASH_WORD_SIZE *addr = (CFG_FLASH_WORD_SIZE *) (info->start[0]);
+	volatile CFG_FLASH_WORD_SIZE *addr2;
+	int flag, prot, sect, l_sect;
+	int i;
+
+	if ((s_first < 0) || (s_first > s_last)) {
+		if (info->flash_id == FLASH_UNKNOWN) {
+			printf("- missing\n");
+		} else {
+			printf("- no sectors to erase\n");
+		}
+		return 1;
+	}
+
+	if (info->flash_id == FLASH_UNKNOWN) {
+		printf("Can't erase unknown flash type - aborted\n");
+		return 1;
+	}
+
+	prot = 0;
+	for (sect = s_first; sect <= s_last; ++sect) {
+		if (info->protect[sect]) {
+			prot++;
+		}
+	}
+
+	if (prot) {
+		printf("- Warning: %d protected sectors will not be erased!\n",
+		       prot);
+	} else {
+		printf("\n");
+	}
+
+	l_sect = -1;
+
+	/* Disable interrupts which might cause a timeout here */
+	flag = disable_interrupts();
+
+	/* Start erase on unprotected sectors */
+	for (sect = s_first; sect <= s_last; sect++) {
+		if (info->protect[sect] == 0) {	/* not protected */
+			addr2 = (CFG_FLASH_WORD_SIZE *) (info->start[sect]);
+
+			if ((info->flash_id & FLASH_VENDMASK) == FLASH_MAN_SST) {
+				addr[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00AA00AA;
+				addr[CFG_FLASH_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x00550055;
+				addr[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00800080;
+				addr[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00AA00AA;
+				addr[CFG_FLASH_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x00550055;
+				addr2[0] = (CFG_FLASH_WORD_SIZE) 0x00500050;	/* block erase */
+				for (i = 0; i < 50; i++)
+					udelay(1000);	/* wait 1 ms */
+			} else {
+				addr[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00AA00AA;
+				addr[CFG_FLASH_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x00550055;
+				addr[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00800080;
+				addr[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00AA00AA;
+				addr[CFG_FLASH_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x00550055;
+				addr2[0] = (CFG_FLASH_WORD_SIZE) 0x00300030;	/* sector erase */
+			}
+			l_sect = sect;
+			/*
+			 * Wait for each sector to complete, it's more
+			 * reliable.  According to AMD Spec, you must
+			 * issue all erase commands within a specified
+			 * timeout.  This has been seen to fail, especially
+			 * if printf()s are included (for debug)!!
+			 */
+			wait_for_DQ7_1(info, sect);
+		}
+	}
+
+	/* re-enable interrupts if necessary */
+	if (flag)
+		enable_interrupts();
+
+	/* wait at least 80us - let's wait 1 ms */
+	udelay(1000);
+
+	/* reset to read mode */
+	addr = (CFG_FLASH_WORD_SIZE *) info->start[0];
+	addr[0] = (CFG_FLASH_WORD_SIZE) 0x00F000F0;	/* reset bank */
+
+	printf(" done\n");
+	return 0;
+}
+
+/*-----------------------------------------------------------------------
+ * Copy memory to flash, returns:
+ * 0 - OK
+ * 1 - write timeout
+ * 2 - Flash not erased
+ */
+int write_buff(flash_info_t * info, uchar * src, ulong addr, ulong cnt)
+{
+	ulong cp, wp, data;
+	int i, l, rc;
+
+	wp = (addr & ~3);	/* get lower word aligned address */
+
+	/*
+	 * handle unaligned start bytes
+	 */
+	if ((l = addr - wp) != 0) {
+		data = 0;
+		for (i = 0, cp = wp; i < l; ++i, ++cp) {
+			data = (data << 8) | (*(uchar *) cp);
+		}
+		for (; i < 4 && cnt > 0; ++i) {
+			data = (data << 8) | *src++;
+			--cnt;
+			++cp;
+		}
+		for (; cnt == 0 && i < 4; ++i, ++cp) {
+			data = (data << 8) | (*(uchar *) cp);
+		}
+
+		if ((rc = write_word(info, wp, data)) != 0) {
+			return rc;
+		}
+		wp += 4;
+	}
+
+	/*
+	 * handle word aligned part
+	 */
+	while (cnt >= 4) {
+		data = 0;
+		for (i = 0; i < 4; ++i) {
+			data = (data << 8) | *src++;
+		}
+		if ((rc = write_word(info, wp, data)) != 0) {
+			return rc;
+		}
+		wp += 4;
+		cnt -= 4;
+	}
+
+	if (cnt == 0) {
+		return 0;
+	}
+
+	/*
+	 * handle unaligned tail bytes
+	 */
+	data = 0;
+	for (i = 0, cp = wp; i < 4 && cnt > 0; ++i, ++cp) {
+		data = (data << 8) | *src++;
+		--cnt;
+	}
+	for (; i < 4; ++i, ++cp) {
+		data = (data << 8) | (*(uchar *) cp);
+	}
+
+	return (write_word(info, wp, data));
+}
+
+/*-----------------------------------------------------------------------
+ * Copy memory to flash, returns:
+ * 0 - OK
+ * 1 - write timeout
+ * 2 - Flash not erased
+ */
+#ifdef FLASH_BASE1_PRELIM
+static int write_word(flash_info_t * info, ulong dest, ulong data)
+{
+	if (((info->flash_id & FLASH_TYPEMASK) == FLASH_AM320B) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_AM320T) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_AMLV128U) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_S29GL128N) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_STMW320DT)) {
+		return write_word_2(info, dest, data);
+	} else {
+		return write_word_1(info, dest, data);
+	}
+}
+
+static int write_word_1(flash_info_t * info, ulong dest, ulong data)
+#else
+static int write_word(flash_info_t * info, ulong dest, ulong data)
+#endif
+{
+	volatile CFG_FLASH_WORD_SIZE *addr2 = (CFG_FLASH_WORD_SIZE *) (info->start[0]);
+	volatile CFG_FLASH_WORD_SIZE *dest2 = (CFG_FLASH_WORD_SIZE *) dest;
+	volatile CFG_FLASH_WORD_SIZE *data2 = (CFG_FLASH_WORD_SIZE *) & data;
+	ulong start;
+	int i;
+
+	/* Check if Flash is (sufficiently) erased */
+	if ((*((vu_long *)dest) & data) != data) {
+		return 2;
+	}
+
+	for (i = 0; i < 4 / sizeof(CFG_FLASH_WORD_SIZE); i++) {
+		int flag;
+
+		/* Disable interrupts which might cause a timeout here */
+		flag = disable_interrupts();
+
+		addr2[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00AA00AA;
+		addr2[CFG_FLASH_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x00550055;
+		addr2[CFG_FLASH_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x00A000A0;
+
+		dest2[i] = data2[i];
+
+		/* re-enable interrupts if necessary */
+		if (flag)
+			enable_interrupts();
+
+		/* data polling for D7 */
+		start = get_timer(0);
+		while ((dest2[i] & (CFG_FLASH_WORD_SIZE) 0x00800080) !=
+		       (data2[i] & (CFG_FLASH_WORD_SIZE) 0x00800080)) {
+
+			if (get_timer(start) > CFG_FLASH_WRITE_TOUT) {
+				return 1;
+			}
+		}
+	}
+
+	return 0;
+}
+
+#ifdef FLASH_BASE1_PRELIM
+
+/*
+ * The following code cannot be run from FLASH!
+ */
+static ulong flash_get_size_2(vu_long * addr, flash_info_t * info)
+{
+	short i;
+	CFG_FLASH_CHAR_SIZE value;
+	ulong base = (ulong) addr;
+	volatile CFG_FLASH_WORD_SIZE *addr2 = (CFG_FLASH_WORD_SIZE *) addr;
+
+	DEBUGF("FLASH ADDR: %08x\n", (unsigned)addr);
+
+	/* Write auto select command: read Manufacturer ID */
+	addr2[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xAAAAAAAA;
+	addr2[CFG_FLASH_CHAR_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x55555555;
+	addr2[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x90909090;
+	udelay(1000);
+
+	value = (CFG_FLASH_CHAR_SIZE)addr2[0];
+	DEBUGF("FLASH MANUFACT: %x\n", value);
+
+	switch (value) {
+	case (CFG_FLASH_CHAR_SIZE) AMD_MANUFACT:
+		info->flash_id = FLASH_MAN_AMD;
+		break;
+	case (CFG_FLASH_CHAR_SIZE) FUJ_MANUFACT:
+		info->flash_id = FLASH_MAN_FUJ;
+		break;
+	case (CFG_FLASH_CHAR_SIZE) SST_MANUFACT:
+		info->flash_id = FLASH_MAN_SST;
+		break;
+	case (CFG_FLASH_CHAR_SIZE) STM_MANUFACT:
+		info->flash_id = FLASH_MAN_STM;
+		break;
+	default:
+		info->flash_id = FLASH_UNKNOWN;
+		info->sector_count = 0;
+		info->size = 0;
+		return 0;		/* no or unknown flash */
+	}
+
+	value = (CFG_FLASH_CHAR_SIZE)addr2[2];	/* device ID */
+	DEBUGF("\nFLASH DEVICEID: %x\n", value);
+
+	switch (value) {
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_LV040B:
+		info->flash_id += FLASH_AM040;
+		info->sector_count = 8;
+		info->size = 0x0080000;	/* => 512 ko */
+		break;
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_F040B:
+		info->flash_id += FLASH_AM040;
+		info->sector_count = 8;
+		info->size = 0x0080000;	/* => 512 ko */
+		break;
+
+	case (CFG_FLASH_CHAR_SIZE) STM_ID_M29W040B:
+		info->flash_id += FLASH_AM040;
+		info->sector_count = 8;
+		info->size = 0x0080000;	/* => 512 ko */
+		break;
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_F016D:
+		info->flash_id += FLASH_AMD016;
+		info->sector_count = 32;
+		info->size = 0x00200000;
+		break;			/* => 2 MB */
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_LV033C:
+		info->flash_id += FLASH_AMDLV033C;
+		info->sector_count = 64;
+		info->size = 0x00400000;
+		break;			/* => 4 MB */
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_LV400T:
+		info->flash_id += FLASH_AM400T;
+		info->sector_count = 11;
+		info->size = 0x00080000;
+		break;			/* => 0.5 MB */
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_LV400B:
+		info->flash_id += FLASH_AM400B;
+		info->sector_count = 11;
+		info->size = 0x00080000;
+		break;			/* => 0.5 MB */
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_LV800T:
+		info->flash_id += FLASH_AM800T;
+		info->sector_count = 19;
+		info->size = 0x00100000;
+		break;			/* => 1 MB */
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_LV800B:
+		info->flash_id += FLASH_AM800B;
+		info->sector_count = 19;
+		info->size = 0x00100000;
+		break;			/* => 1 MB */
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_LV160T:
+		info->flash_id += FLASH_AM160T;
+		info->sector_count = 35;
+		info->size = 0x00200000;
+		break;			/* => 2 MB */
+
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_LV160B:
+		info->flash_id += FLASH_AM160B;
+		info->sector_count = 35;
+		info->size = 0x00200000;
+		break;			/* => 2 MB */
+	case (CFG_FLASH_CHAR_SIZE) AMD_ID_MIRROR:
+		if ((CFG_FLASH_CHAR_SIZE)addr2[0x1c] == (CFG_FLASH_CHAR_SIZE)AMD_ID_LV128U_2
+				&& (CFG_FLASH_CHAR_SIZE)addr2[0x1e] ==  (CFG_FLASH_CHAR_SIZE)AMD_ID_LV128U_3) {
+			info->flash_id += FLASH_AMLV128U;
+			info->sector_count = 256;
+			info->size = 0x01000000;
+		} else if ((CFG_FLASH_CHAR_SIZE)addr2[0x1c] == (CFG_FLASH_CHAR_SIZE)AMD_ID_GL128N_2
+				&& (CFG_FLASH_CHAR_SIZE)addr2[0x1e] ==  (CFG_FLASH_CHAR_SIZE)AMD_ID_GL128N_3 ) {
+			info->flash_id += FLASH_S29GL128N;
+			info->sector_count = 128;
+			info->size = 0x01000000;
+		}
+		else
+			info->flash_id = FLASH_UNKNOWN;
+		break;			/* => 2 MB */
+
+	default:
+		info->flash_id = FLASH_UNKNOWN;
+		return 0;		/* => no or unknown flash */
+	}
+
+	/* set up sector start address table */
+	if (((info->flash_id & FLASH_VENDMASK) == FLASH_MAN_SST) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_AM040) ||
+	    ((info->flash_id & FLASH_TYPEMASK) == FLASH_AMD016)) {
+		for (i = 0; i < info->sector_count; i++)
+			info->start[i] = base + (i * 0x00
010000);
+	} else if ((info->flash_id & FLASH_TYPEMASK) == FLASH_AMLV128U) {
+		for (i = 0; i < info->sector_count; i++)
+			info->start[i] = base + (i * 0x00010000);
+	} else if ((info->flash_id & FLASH_TYPEMASK) == FLASH_S29GL128N ) {
+		for (i = 0; i < info->sector_count; i++)
+			info->start[i] = base + (i * 0x00020000);
+	} else {
+		if (info->flash_id & FLASH_BTYPE) {
+			/* set sector offsets for bottom boot block type */
+			info->start[0] = base + 0x00000000;
+			info->start[1] = base + 0x00004000;
+			info->start[2] = base + 0x00006000;
+			info->start[3] = base + 0x00008000;
+			for (i = 4; i < info->sector_count; i++) {
+				info->start[i] =
+				    base + (i * 0x00010000) - 0x00030000;
+			}
+		} else {
+			/* set sector offsets for top boot block type */
+			i = info->sector_count - 1;
+			info->start[i--] = base + info->size - 0x00004000;
+			info->start[i--] = base + info->size - 0x00006000;
+			info->start[i--] = base + info->size - 0x00008000;
+			for (; i >= 0; i--) {
+				info->start[i] = base + i * 0x00010000;
+			}
+		}
+	}
+
+	/* check for protected sectors */
+	for (i = 0; i < info->sector_count; i++) {
+		/* read sector protection at sector address, (A7 .. A0) = 0x02 */
+		/* D0 = 1 if protected */
+		addr2 = (volatile CFG_FLASH_WORD_SIZE *)(info->start[i]);
+
+		/* For AMD29033C flash we need to resend the command of *
+		 * reading flash protection for upper 8 Mb of flash     */
+		if (i == 32) {
+			addr2[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xAAAAAAAA;
+			addr2[CFG_FLASH_CHAR_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x55555555;
+			addr2[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x90909090;
+		}
+
+		if ((info->flash_id & FLASH_VENDMASK) == FLASH_MAN_SST)
+			info->protect[i] = 0;
+		else
+			info->protect[i] = (CFG_FLASH_CHAR_SIZE)addr2[4] & 1;
+	}
+
+	/* issue bank reset to return to read mode */
+	addr2[0] = (CFG_FLASH_WORD_SIZE) 0xF0F0F0F0;
+	return info->size;
+}
+
+static int wait_for_DQ7_2(flash_info_t * info, int sect)
+{
+	ulong start, now, last;
+	volatile CFG_FLASH_WORD_SIZE *addr =
+	    (CFG_FLASH_WORD_SIZE *) (info->start[sect]);
+
+	start = get_timer(0);
+	last = start;
+	while (((CFG_FLASH_WORD_SIZE)addr[0] & (CFG_FLASH_WORD_SIZE) 0x80808080) !=
+	       (CFG_FLASH_WORD_SIZE) 0x80808080) {
+		if ((now = get_timer(start)) > CFG_FLASH_ERASE_TOUT) {
+			printf("Timeout\n");
+			return -1;
+		}
+		/* show that we're waiting */
+		if ((now - last) > 1000) { /* every second */
+			putc('.');
+			last = now;
+		}
+	}
+	return 0;
+}
+
+static int flash_erase_2(flash_info_t * info, int s_first, int s_last)
+{
+	volatile CFG_FLASH_WORD_SIZE *addr = (CFG_FLASH_WORD_SIZE *) (info->start[0]);
+	volatile CFG_FLASH_WORD_SIZE *addr2;
+	int flag, prot, sect, l_sect;
+	int i;
+
+	if ((s_first < 0) || (s_first > s_last)) {
+		if (info->flash_id == FLASH_UNKNOWN) {
+			printf("- missing\n");
+		} else {
+			printf("- no sectors to erase\n");
+		}
+		return 1;
+	}
+
+	if (info->flash_id == FLASH_UNKNOWN) {
+		printf("Can't erase unknown flash type - aborted\n");
+		return 1;
+	}
+
+	prot = 0;
+	for (sect = s_first; sect <= s_last; ++sect) {
+		if (info->protect[sect]) {
+			prot++;
+		}
+	}
+
+	if (prot) {
+		printf("- Warning: %d protected sectors will not be erased!\n",
+		       prot);
+	} else {
+		printf("\n");
+	}
+
+	l_sect = -1;
+
+	/* Disable interrupts which might cause a timeout here */
+	flag = disable_interrupts();
+
+	/* Start erase on unprotected sectors */
+	for (sect = s_first; sect <= s_last; sect++) {
+		if (info->protect[sect] == 0) {	/* not protected */
+			addr2 = (CFG_FLASH_WORD_SIZE *) (info->start[sect]);
+
+			if ((info->flash_id & FLASH_VENDMASK) == FLASH_MAN_SST) {
+				addr[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xAAAAAAAA;
+				addr[CFG_FLASH_CHAR_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x55555555;
+				addr[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x80808080;
+				addr[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xAAAAAAAA;
+				addr[CFG_FLASH_CHAR_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x55555555;
+				addr2[0] = (CFG_FLASH_WORD_SIZE) 0x50505050;	/* block erase */
+				for (i = 0; i < 50; i++)
+					udelay(1000);	/* wait 1 ms */
+			} else {
+				addr[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xAAAAAAAA;
+				addr[CFG_FLASH_CHAR_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x55555555;
+				addr[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0x80808080;
+				addr[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xAAAAAAAA;
+				addr[CFG_FLASH_CHAR_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x55555555;
+				addr2[0] = (CFG_FLASH_WORD_SIZE) 0x30303030;	/* sector erase */
+			}
+			l_sect = sect;
+			/*
+			 * Wait for each sector to complete, it's more
+			 * reliable.  According to AMD Spec, you must
+			 * issue all erase commands within a specified
+			 * timeout.  This has been seen to fail, especially
+			 * if printf()s are included (for debug)!!
+			 */
+			wait_for_DQ7_2(info, sect);
+		}
+	}
+
+	/* re-enable interrupts if necessary */
+	if (flag)
+		enable_interrupts();
+
+	/* wait at least 80us - let's wait 1 ms */
+	udelay(1000);
+
+	/* reset to read mode */
+	addr = (CFG_FLASH_WORD_SIZE *) info->start[0];
+	addr[0] = (CFG_FLASH_WORD_SIZE) 0xF0F0F0F0; /* reset bank */
+
+	printf(" done\n");
+	return 0;
+}
+
+static int write_word_2(flash_info_t * info, ulong dest, ulong data)
+{
+	volatile CFG_FLASH_WORD_SIZE *addr2 = (CFG_FLASH_WORD_SIZE *) (info->start[0]);
+	volatile CFG_FLASH_WORD_SIZE *dest2 = (CFG_FLASH_WORD_SIZE *) dest;
+	volatile CFG_FLASH_WORD_SIZE *data2 = (CFG_FLASH_WORD_SIZE *) & data;
+	ulong start;
+	int i;
+
+	/* Check if Flash is (sufficiently) erased */
+	if ((*((vu_long *)dest) & data) != data) {
+		return 2;
+	}
+
+	for (i = 0; i < 4 / sizeof(CFG_FLASH_WORD_SIZE); i++) {
+		int flag;
+
+		/* Disable interrupts which might cause a timeout here */
+		flag = disable_interrupts();
+
+		addr2[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xAAAAAAAA;
+		addr2[CFG_FLASH_CHAR_ADDR1] = (CFG_FLASH_WORD_SIZE) 0x55555555;
+		addr2[CFG_FLASH_CHAR_ADDR0] = (CFG_FLASH_WORD_SIZE) 0xA0A0A0A0;
+
+		dest2[i] = data2[i];
+
+		/* re-enable interrupts if necessary */
+		if (flag)
+			enable_interrupts();
+
+		/* data polling for D7 */
+		start = get_timer(0);
+		while ((dest2[i] & (CFG_FLASH_WORD_SIZE) 0x80808080) !=
+		       (data2[i] & (CFG_FLASH_WORD_SIZE) 0x80808080)) {
+
+			if (get_timer(start) > CFG_FLASH_WRITE_TOUT) {
+				return 1;
+			}
+		}
+	}
+
+	return 0;
+}
+
+#endif /* FLASH_BASE1_PRELIM */

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From garyj at denx.de  Wed Apr 23 15:12:58 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Wed, 23 Apr 2008 15:12:58 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Add the Harris QUAD100HD AMCC
	405EP-based board.
Message-ID: <20080423151258.7ac66064@peedub.jennejohn.org>


Add the Harris QUAD100HD AMCC 405EP-based board.

Signed-off-by: Gary Jennejohn <garyj at denx.de>
---
diff --git a/board/quad100hd/nand.c b/board/quad100hd/nand.c
new file mode 100644
index 0000000..964dd4b
--- /dev/null
+++ b/board/quad100hd/nand.c
@@ -0,0 +1,156 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de
+ *
+ * Based on board/icecube/ice_nand.c from PPCBoot (no copyright
+ * notice).
+ *
+ * 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 <common.h>
+#include <config.h>
+#if defined(CONFIG_CMD_NAND)
+#include <ppc405.h>
+#include <asm/io.h>
+#include <nand.h>
+
+#define _BITMASK(i) (((unsigned)0x80000000) >> (i))
+
+#define GPIO_OUT	1
+#define GPIO_IN		2
+#define GPIO_GPIO	4
+#define GPIO_ALT	8
+
+typedef struct quad100hd_gpio_regs {
+	volatile u32 gpio_or;
+	volatile u32 gpio_tcr;
+	volatile u32 gpio_osrh;
+	volatile u32 gpio_osrl;
+	volatile u32 gpio_tsrh;
+	volatile u32 gpio_tsrl;
+	volatile u32 gpio_odr;
+	volatile u32 gpio_ir;
+	volatile u32 gpio_rr;
+	volatile u32 gpio_isrh;
+	volatile u32 gpio_isrl;
+} quad100hd_gpio_t;
+
+static struct quad100hd_gpio_regs *quad100hd_gpio = NULL;
+
+static void inline set_gpio_dr(volatile u32 *reg_adr, int gpio, int set)
+{
+	
+	if (gpio > 15) {
+		++reg_adr;   /* point to osrl */
+		gpio -= 16;
+	}
+	gpio <<= 1;
+	if (set) {
+		*reg_adr &= ~_BITMASK(gpio);
+		*reg_adr |=  _BITMASK(gpio + 1);
+	} else {
+		*reg_adr &= ~(_BITMASK(gpio) | _BITMASK(gpio + 1));
+	}
+}
+
+static void inline set_gpio(quad100hd_gpio_t * gpio, int gpio_pin, int func)
+{
+
+	gpio->gpio_odr &= ~_BITMASK(gpio_pin);
+	if (func & GPIO_OUT)
+		gpio->gpio_tcr |= _BITMASK(gpio_pin);
+	else
+		gpio->gpio_tcr &= ~_BITMASK(gpio_pin);
+	set_gpio_dr(&gpio->gpio_osrh, gpio_pin, func & GPIO_ALT);
+	set_gpio_dr(&gpio->gpio_tsrh, gpio_pin, 0);
+}
+
+static int quad100hd_init_nand_gpio(void)
+{
+	quad100hd_gpio = (struct quad100hd_gpio_regs *) GPIO_BASE;
+			
+	set_gpio(quad100hd_gpio, CFG_NAND_CS, GPIO_ALT | GPIO_OUT);
+	set_gpio(quad100hd_gpio, CFG_NAND_ALE, GPIO_GPIO | GPIO_OUT);
+	set_gpio(quad100hd_gpio, CFG_NAND_CLE, GPIO_GPIO | GPIO_OUT);
+	set_gpio(quad100hd_gpio, CFG_NAND_CE, GPIO_GPIO | GPIO_OUT);
+	set_gpio(quad100hd_gpio, CFG_NAND_RDY, GPIO_GPIO | GPIO_IN);
+	
+	return 0;
+}
+
+/* 
+ *	hardware specific access to control-lines
+ */
+static void quad100hd_hwcontrol(struct mtd_info *mtd, int cmd)
+{
+	switch(cmd) {
+	case NAND_CTL_SETCLE:
+		quad100hd_gpio->gpio_or |= _BITMASK(CFG_NAND_CLE);
+		eieio();
+		break;
+	case NAND_CTL_CLRCLE:
+		quad100hd_gpio->gpio_or &= ~_BITMASK(CFG_NAND_CLE);
+		eieio();
+		break;
+
+	case NAND_CTL_SETALE:
+		quad100hd_gpio->gpio_or |= _BITMASK(CFG_NAND_ALE);
+		eieio();
+		break;
+	case NAND_CTL_CLRALE:
+		quad100hd_gpio->gpio_or &= ~_BITMASK(CFG_NAND_ALE);
+		eieio();
+		break;
+
+	case NAND_CTL_SETNCE:
+		quad100hd_gpio->gpio_or &= ~_BITMASK(CFG_NAND_CE);
+		eieio();
+		break;
+	case NAND_CTL_CLRNCE:
+		quad100hd_gpio->gpio_or |= _BITMASK(CFG_NAND_CE);
+		eieio();
+		break;
+	}
+}
+
+static int quad100hd_nand_ready(struct mtd_info *mtd)
+{
+	return (quad100hd_gpio->gpio_ir & _BITMASK(CFG_NAND_RDY) ? 1 : 0);
+}
+
+
+/*
+ * Main initialization routine
+ */
+int board_nand_init(struct nand_chip *nand)
+{
+	quad100hd_init_nand_gpio();
+
+	/* Set address of hardware control function */
+	nand->hwcontrol = quad100hd_hwcontrol;
+	nand->dev_ready = quad100hd_nand_ready;
+	nand->eccmode = NAND_ECC_SOFT;
+	/* 15 us command delay time */
+	nand->chip_delay =  20;
+
+	/* Return happy */
+	return 0;
+}
+#endif /* CONFIG_CMD_NAND */
diff --git a/board/quad100hd/quad100hd.c b/board/quad100hd/quad100hd.c
new file mode 100644
index 0000000..fbe9274
--- /dev/null
+++ b/board/quad100hd/quad100hd.c
@@ -0,0 +1,113 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
+ *
+ * Based in part on board/icecube/icecube.c from PPCBoot
+ * (C) Copyright 2003 Intrinsyc Software
+ *
+ * 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 <common.h>
+#include <command.h>
+#include <malloc.h>
+#include <environment.h>
+#include <logbuff.h>
+#include <post.h>
+
+#include <asm/processor.h>
+#include <asm/io.h>
+#include <asm/gpio.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_early_init_f(void)
+{
+	/* taken from ppcboot */
+	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
+	mtdcr(uicer, 0x00000000);	/* disable all ints */
+	mtdcr(uiccr, 0x00000000);
+	mtdcr(uicpr, 0xFFFF7FFE);	/* set int polarities */
+	mtdcr(uictr, 0x00000000);	/* set int trigger levels */
+	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
+	mtdcr(uicvcr, 0x00000001);	/* set vect base=0,INT0 highest priority */
+
+#define cpc0_srr (CNTRL_DCR_BASE+0x6)
+    	mtdcr (cpc0_srr, 0x00040000);   /* Hold PCI bridge in reset */
+
+	return 0;
+}
+
+/*
+ * Check Board Identity:
+ */
+int checkboard(void)
+{
+	char *s = getenv("serial#");
+#ifdef DISPLAY_BOARD_INFO
+	sys_info_t sysinfo;
+#endif
+
+	puts("Board: Quad100hd");
+
+	if (s != NULL) {
+		puts(", serial# ");
+		puts(s);
+	}
+	putc('\n');
+
+#ifdef DISPLAY_BOARD_INFO
+	/* taken from ppcboot */
+	get_sys_info (&sysinfo);
+
+	printf("\tVCO: %lu MHz\n", sysinfo.freqVCOMhz);
+	printf("\tCPU: %lu MHz\n", sysinfo.freqProcessor / 1000000);
+	printf("\tPLB: %lu MHz\n", sysinfo.freqPLB / 1000000);
+	printf("\tOPB: %lu MHz\n", sysinfo.freqOPB / 1000000);
+	printf("\tEPB: %lu MHz\n", sysinfo.freqPLB / (sysinfo.pllExtBusDiv *
+		1000000));
+	printf ("\tPCI: %lu MHz\n", sysinfo.freqPCI / 1000000);
+#endif
+
+	return (0);
+}
+
+/* taken from ppcboot */
+long int init_sdram_static_settings(void)
+{
+#define mtsdram0(reg, data)  mtdcr(memcfga,reg);mtdcr(memcfgd,data)
+	/* disable memcontroller so updates work */    	
+	mtsdram0( mem_mcopt1, 0x00A00000);
+	mtsdram0( mem_rtr   , 0x05f00000);
+	mtsdram0( mem_pmit  , 0x07C00000);
+	mtsdram0( mem_mb0cf , 0x00062001);
+	mtsdram0( mem_mb1cf , 0x00000000);
+	mtsdram0( mem_sdtr1 , 0x010b401a);
+	/* SDRAM have a power on delay,  500 micro should do */
+	udelay(500);
+	mtsdram0( mem_mcopt1, 0x00A00000|0x80000000);
+	udelay(500);
+
+	return (CFG_SDRAM_SIZE);
+}
+
+long int initdram(int board_type)
+{
+    	return init_sdram_static_settings();
+}
diff --git a/board/quad100hd/u-boot.lds b/board/quad100hd/u-boot.lds
new file mode 100644
index 0000000..195d91b
--- /dev/null
+++ b/board/quad100hd/u-boot.lds
@@ -0,0 +1,133 @@
+/*
+ * (C) Copyright 2000
+ * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+OUTPUT_ARCH(powerpc)
+SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/local/powerpc-any-elf/lib);
+/* Do we need any of these for elf?
+   __DYNAMIC = 0;    */
+SECTIONS
+{
+  .resetvec 0xFFFFFFFC :
+  {
+    *(.resetvec)
+  } = 0xffff
+
+  /* Read-only sections, merged into text segment: */
+  . = + SIZEOF_HEADERS;
+  .interp : { *(.interp) }
+  .hash          : { *(.hash)		}
+  .dynsym        : { *(.dynsym)		}
+  .dynstr        : { *(.dynstr)		}
+  .rel.text      : { *(.rel.text)		}
+  .rela.text     : { *(.rela.text) 	}
+  .rel.data      : { *(.rel.data)		}
+  .rela.data     : { *(.rela.data) 	}
+  .rel.rodata    : { *(.rel.rodata) 	}
+  .rela.rodata   : { *(.rela.rodata) 	}
+  .rel.got       : { *(.rel.got)		}
+  .rela.got      : { *(.rela.got)		}
+  .rel.ctors     : { *(.rel.ctors)	}
+  .rela.ctors    : { *(.rela.ctors)	}
+  .rel.dtors     : { *(.rel.dtors)	}
+  .rela.dtors    : { *(.rela.dtors)	}
+  .rel.bss       : { *(.rel.bss)		}
+  .rela.bss      : { *(.rela.bss)		}
+  .rel.plt       : { *(.rel.plt)		}
+  .rela.plt      : { *(.rela.plt)		}
+  .init          : { *(.init)	}
+  .plt : { *(.plt) }
+  .text      :
+  {
+    cpu/ppc4xx/start.o	(.text)
+
+    *(.text)
+    *(.fixup)
+    *(.got1)
+  }
+  _etext = .;
+  PROVIDE (etext = .);
+  .rodata    :
+  {
+    *(.rodata)
+    *(.rodata1)
+    *(.rodata.str1.4)
+  }
+  .fini      : { *(.fini)    } =0
+  .ctors     : { *(.ctors)   }
+  .dtors     : { *(.dtors)   }
+
+  /* Read-write section, merged into data segment: */
+  . = (. + 0x00FF) & 0xFFFFFF00;
+  _erotext = .;
+  PROVIDE (erotext = .);
+  .reloc   :
+  {
+    *(.got)
+    _GOT2_TABLE_ = .;
+    *(.got2)
+    _FIXUP_TABLE_ = .;
+    *(.fixup)
+  }
+  __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >>2;
+  __fixup_entries = (. - _FIXUP_TABLE_)>>2;
+
+  .data    :
+  {
+    *(.data)
+    *(.data1)
+    *(.sdata)
+    *(.sdata2)
+    *(.dynamic)
+    CONSTRUCTORS
+  }
+  _edata  =  .;
+  PROVIDE (edata = .);
+
+  . = .;
+  __u_boot_cmd_start = .;
+  .u_boot_cmd : { *(.u_boot_cmd) }
+  __u_boot_cmd_end = .;
+
+  . = .;
+  __start___ex_table = .;
+  __ex_table : { *(__ex_table) }
+  __stop___ex_table = .;
+
+  . = ALIGN(256);
+  __init_begin = .;
+  .text.init : { *(.text.init) }
+  .data.init : { *(.data.init) }
+  . = ALIGN(256);
+  __init_end = .;
+
+  __bss_start = .;
+  .bss (NOLOAD)       :
+  {
+   *(.sbss) *(.scommon)
+   *(.dynbss)
+   *(.bss)
+   *(COMMON)
+  }
+  _end = . ;
+  PROVIDE (end = .);
+}
diff --git a/include/configs/quad100hd.h b/include/configs/quad100hd.h
new file mode 100644
index 0000000..6f84878
--- /dev/null
+++ b/include/configs/quad100hd.h
@@ -0,0 +1,306 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/************************************************************************
+ * quad100hd.h - configuration for Quad100hd board
+ ***********************************************************************/
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*-----------------------------------------------------------------------
+ * High Level Configuration Options
+ *----------------------------------------------------------------------*/
+#define CONFIG_QUAD100HD	1		/* Board is Quad100hd	*/
+#define CONFIG_4xx		1		/* ... PPC4xx family	*/
+#define CONFIG_405EP		1		/* Specifc 405EP support*/
+
+#define CONFIG_SYS_CLK_FREQ     33333333 /* external frequency to pll   */
+
+#define CONFIG_BOARD_EARLY_INIT_F 1		/* Call board_early_init_f */
+
+#define PLLMR0_DEFAULT		PLLMR0_266_133_66 /* no PCI */
+#define PLLMR1_DEFAULT		PLLMR1_266_133_66 /* no PCI */
+
+#define CFG_ENV_IS_IN_EEPROM    1   /* use the EEPROM for environment vars */
+
+#define CONFIG_OVERWRITE_ETHADDR_ONCE	1
+
+#define CONFIG_NET_MULTI	1
+#define CONFIG_HAS_ETH1		1
+#define CONFIG_MII		1	/* MII PHY management		*/
+#define CONFIG_PHY_ADDR		0x01	/* PHY address			*/
+#define CFG_RX_ETH_BUFFER	16	/* Number of ethernet rx buffers & descriptors */
+#define CONFIG_PHY_RESET	1
+#define CONFIG_PHY_RESET_DELAY	300	/* PHY RESET recovery delay	*/
+
+/*
+ * Command line configuration.
+ */
+#include <config_cmd_default.h>
+
+#undef CONFIG_CMD_ASKENV
+#undef CONFIG_CMD_CACHE
+#define CONFIG_CMD_DHCP
+#undef CONFIG_CMD_DIAG
+#define CONFIG_CMD_EEPROM
+#undef CONFIG_CMD_ELF
+#define CONFIG_CMD_I2C
+#undef CONFIG_CMD_IRQ
+#define CONFIG_CMD_JFFS2
+#undef CONFIG_CMD_LOG
+#undef CONFIG_CMD_MII
+#define CONFIG_CMD_NAND
+#undef CONFIG_CMD_PING
+#define CONFIG_CMD_REGINFO
+
+#undef CONFIG_WATCHDOG			/* watchdog disabled		*/
+
+/*-----------------------------------------------------------------------
+ * SDRAM
+ *----------------------------------------------------------------------*/
+/*
+ * SDRAM configuration (please see cpu/ppc/sdram.[ch])
+ */
+#define CONFIG_SDRAM_BANK0  1
+#define CFG_SDRAM_SIZE      0x02000000      /* 32 MB */
+
+/* FIX! SDRAM timings used in datasheet */
+#define CFG_SDRAM_CL            3       /* CAS latency */
+#define CFG_SDRAM_tRP           20      /* PRECHARGE command period */
+#define CFG_SDRAM_tRC           66      /* ACTIVE-to-ACTIVE command period */
+#define CFG_SDRAM_tRCD          20      /* ACTIVE-to-READ delay */
+#define CFG_SDRAM_tRFC          66      /* Auto refresh period */
+
+/* 
+ * JFFS2
+ */
+#define CFG_JFFS2_FIRST_BANK    0
+#ifdef  CFG_KERNEL_IN_JFFS2
+#define CFG_JFFS2_FIRST_SECTOR  0   /* JFFS starts at block 0 */
+#else /* kernel not in JFFS */
+#define CFG_JFFS2_FIRST_SECTOR  8   /* block 0-7 is kernel (1MB = 8 sectors) */
+#endif
+#define CFG_JFFS2_NUM_BANKS     1
+
+/*-----------------------------------------------------------------------
+ * Serial Port
+ *----------------------------------------------------------------------*/
+#undef	CFG_EXT_SERIAL_CLOCK			/* external serial clock */
+#define CFG_BASE_BAUD		691200
+#define CONFIG_BAUDRATE		115200
+#define CONFIG_SERIAL_MULTI
+
+/* The following table includes the supported baudrates */
+#define CFG_BAUDRATE_TABLE	\
+	{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
+
+/*-----------------------------------------------------------------------
+ * Miscellaneous configurable options
+ *----------------------------------------------------------------------*/
+#define CFG_LONGHELP			/* undef to save memory		*/
+#define CFG_PROMPT	        "=> "	/* Monitor Command Prompt	*/
+#if defined(CONFIG_CMD_KGDB)
+#define CFG_CBSIZE	        1024	/* Console I/O Buffer Size	*/
+#else
+#define CFG_CBSIZE	        256	/* Console I/O Buffer Size	*/
+#endif
+#define CFG_PBSIZE              (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /* Print Buffer Size */
+#define CFG_MAXARGS	        16	/* max number of command args	*/
+#define CFG_BARGSIZE	        CFG_CBSIZE /* Boot Argument Buffer Size	*/
+
+#define CFG_MEMTEST_START	0x0400000 /* memtest works on		*/
+#define CFG_MEMTEST_END		0x0C00000 /* 4 ... 12 MB in DRAM	*/
+
+#define CFG_LOAD_ADDR		0x100000  /* default load address	*/
+#define CFG_EXTBDINFO		1	/* To use extended board_info (bd_t) */
+
+#define CFG_HZ		        1000	/* decrementer freq: 1 ms ticks	*/
+
+#define CONFIG_LOADS_ECHO	1	/* echo on for serial download	*/
+#define CFG_LOADS_BAUD_CHANGE	1	/* allow baudrate change	*/
+
+#define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
+#define CONFIG_LOOPW            1       /* enable loopw command         */
+#define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands      */
+#define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0 */
+#define CONFIG_VERSION_VARIABLE 1	/* include version env variable */
+
+/*-----------------------------------------------------------------------
+ * I2C
+ *----------------------------------------------------------------------*/
+#define CONFIG_HARD_I2C		1		/* I2C with hardware support	*/
+#undef	CONFIG_SOFT_I2C				/* I2C bit-banged		*/
+#define CFG_I2C_SPEED		400000		/* I2C speed and slave address	*/
+#define CFG_I2C_SLAVE		0x7F
+
+#define CFG_I2C_EEPROM_ADDR	0x50		/* base address */
+#define CFG_I2C_EEPROM_ADDR_LEN	2		/* bytes of address */
+
+#define CFG_EEPROM_PAGE_WRITE_BITS	5	/* 8 byte write page size */
+#define CFG_EEPROM_PAGE_WRITE_DELAY_MS	10	/* and takes up to 10 msec */
+#define CFG_EEPROM_SIZE			0x2000	
+
+/*-----------------------------------------------------------------------
+ * Start addresses for the final memory configuration
+ * (Set up by the startup code)
+ * Please note that CFG_SDRAM_BASE _must_ start at 0
+ */
+#define CFG_SDRAM_BASE		0x00000000
+#define CFG_FLASH_BASE		0xFFC00000
+#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Monitor	*/
+#define CFG_MALLOC_LEN		(128 * 1024)	/* Reserve 128 kB for malloc()	*/
+#define CFG_MONITOR_BASE	0xFFF80000
+
+/*
+ * For booting Linux, the board info and command line data
+ * have to be in the first 8 MB of memory, since this is
+ * the maximum mapped by the Linux kernel during initialization.
+ */
+#define CFG_BOOTMAPSZ		(8 << 20)	/* Initial Memory map for Linux */
+
+/*-----------------------------------------------------------------------
+ * FLASH organization
+ */
+#define CFG_FLASH_CFI			/* The flash is CFI compatible	*/
+
+#define CFG_FLASH_BANKS_LIST	{ CFG_FLASH_BASE }
+
+#define CFG_MAX_FLASH_BANKS	1	/* max number of memory banks	*/
+#define CFG_MAX_FLASH_SECT	128	/* max number of sectors on one chip */
+#define CFG_FLASH_WORD_SIZE	unsigned short
+#define CFG_FLASH_ADDR0		0x0555
+#define CFG_FLASH_ADDR1		0x02aa
+#define FLASH_BASE0_PRELIM	CFG_FLASH_BASE	/* FLASH bank #0	*/
+
+#define CFG_FLASH_ERASE_TOUT	120000	/* Timeout for Flash Erase (in ms) */
+#define CFG_FLASH_WRITE_TOUT	500	/* Timeout for Flash Write (in ms) */
+
+#define CFG_FLASH_USE_BUFFER_WRITE 1	/* use buffered writes (20x faster) */
+#define CFG_FLASH_INCREMENT      0       /* there is only one bank         */
+
+#define CFG_FLASH_EMPTY_INFO		/* print 'E' for empty sector on flinfo */
+#define CFG_FLASH_QUIET_TEST	1	/* don't warn upon unknown flash */
+
+#ifdef CFG_ENV_IS_IN_FLASH
+#define CFG_ENV_SECT_SIZE	0x10000	/* size of one complete sector	*/
+#define	CFG_ENV_SIZE		0x10000	/* Total Size of Environment Sector */
+#define CFG_ENV_OFFSET		0x00050000 /* Offset of Environment Sector  */
+#define CFG_ENV_ADDR		(CFG_FLASH_BASE + CFG_ENV_OFFSET)
+#endif
+
+#ifdef CFG_ENV_IS_IN_EEPROM
+#define CFG_ENV_SIZE		0x400		/* Size of Environment vars */
+#define CFG_ENV_OFFSET		0x00000000
+#define CFG_ENABLE_CRC_16	1       /* Intrinsyc formatting used crc16 */
+#endif
+
+/* from PPCBoot */
+/* NAND */
+#define CONFIG_NAND
+#ifdef CONFIG_NAND
+#define CFG_NAND_BASE   0x60000000
+#define SECTORSIZE	512
+#define ADDR_COLUMN	1
+#define ADDR_PAGE	2
+#define NAND_MAX_FLOORS	1
+#define NAND_MAX_CHIPS	1
+#define CFG_NAND_CS	10   /* our CS is GPIO10 */
+#define CFG_NAND_RDY	23   /* our RDY is GPIO23 */
+#define CFG_NAND_CE	24   /* our CE is GPIO24  */
+#define CFG_NAND_CLE	31   /* our CLE is GPIO31 */
+#define CFG_NAND_ALE	30   /* our ALE is GPIO30 */
+#define CFG_MAX_NAND_DEVICE	1
+#define ADDR_COLUMN_PAGE	3
+#define NAND_ChipID_UNKNOWN	0x00
+#endif
+
+/*-----------------------------------------------------------------------
+ * Definitions for initial stack pointer and data area (in data cache)
+ */
+/* use on chip memory (OCM) for temperary stack until sdram is tested */
+/* see ./cpu/ppc4xx/start.S */
+#define CFG_TEMP_STACK_OCM	1
+
+/* On Chip Memory location */
+#define CFG_OCM_DATA_ADDR	0xF8000000
+#define CFG_OCM_DATA_SIZE	0x1000
+#define CFG_INIT_RAM_ADDR	CFG_OCM_DATA_ADDR /* inside of OCM		*/
+#define CFG_INIT_RAM_END	CFG_OCM_DATA_SIZE /* End of used area in RAM	*/
+
+#define CFG_GBL_DATA_SIZE	128  /* size in bytes reserved for initial data */
+#define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
+#define CFG_INIT_SP_OFFSET      CFG_GBL_DATA_OFFSET
+
+/*-----------------------------------------------------------------------
+ * External Bus Controller (EBC) Setup
+ * Taken from PPCBoot board/icecube/icecube.h
+ */
+
+/* see ./cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/ndfc.c */
+#define CFG_EBC_PB0AP		0x04002480
+/* AMD NOR flash - this corresponds to FLASH_BASE so may be correct */
+#define CFG_EBC_PB0CR		0xFFC5A000
+#define CFG_EBC_PB1AP           0x04005480
+#define CFG_EBC_PB1CR           0x60018000
+#define CFG_EBC_PB2AP           0x00000000
+#define CFG_EBC_PB2CR           0x00000000
+#define CFG_EBC_PB3AP           0x00000000
+#define CFG_EBC_PB3CR           0x00000000
+#define CFG_EBC_PB4AP           0x00000000
+#define CFG_EBC_PB4CR           0x00000000
+
+/*-----------------------------------------------------------------------
+ * Definitions for GPIO setup (PPC405EP specific)
+ *
+ * Taken from PPCBoot board/icecube/icecube.h
+ */
+/* see ./cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/start.S */
+#define CFG_GPIO0_OSRH		0x55555550
+#define CFG_GPIO0_OSRL		0x00000110
+#define CFG_GPIO0_ISR1H		0x00000000
+#define CFG_GPIO0_ISR1L		0x15555445
+#define CFG_GPIO0_TSRH		0x00000000
+#define CFG_GPIO0_TSRL		0x00000000
+#define CFG_GPIO0_TCR		0xFFFF8014
+#define CFG_GPIO0_ODR		0x00000000
+
+#if defined(CONFIG_CMD_KGDB)
+#define CONFIG_KGDB_BAUDRATE	230400		/* speed to run kgdb serial port */
+#define CONFIG_KGDB_SER_INDEX	2		/* which serial port to use */
+#endif
+
+/* ENVIRONMENT VARS */
+
+#define CONFIG_IPADDR		192.168.1.67
+#define CONFIG_SERVERIP		192.168.1.50
+#define CONFIG_GATEWAYIP	192.168.1.1
+#define CONFIG_NETMASK		255.255.255.0
+#define CONFIG_ETHADDR 		00:01:02:03:04:05
+#define CONFIG_ETH1ADDR		00:01:02:03:04:06
+#define CONFIG_LOADADDR		300000
+#define CONFIG_BOOTDELAY	5	/* autoboot after 5 seconds */
+
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT	1
+
+#endif	/* __CONFIG_H */
-- 
1.5.5


---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From lilja.magnus at gmail.com  Wed Apr 23 15:35:16 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Wed, 23 Apr 2008 15:35:16 +0200
Subject: [U-Boot-Users] Question about smc911x driver (16/32 Bit support)
In-Reply-To: <480ED91C.4010400@tqs.de>
References: <480DD799.50402@tqs.de>
	<f8328f7c0804221103i7af61e05h3134aea07eb95ee4@mail.gmail.com>
	<480ED91C.4010400@tqs.de>
Message-ID: <59b21cf20804230635k4d424d88wb7f6fdc9b3e49298@mail.gmail.com>

Hi Jens,

On Wed, Apr 23, 2008 at 8:37 AM, Jens Gehrlein <sew_s at tqs.de> wrote:
>  >>  in the source code there is a preprocessor directive
>  >>  #error "SMC911X: Only 32-bit bus is supported".
>  >>
>  >>  We use a LAN9215i, which has a 16 Bit data interface only, connected to
>  >>  an i.MX31.
>  >>
>  >>  The LAN9215 is in the driver's ID list.
>  >>
>  >>  According to the data sheet accesses have to be 2x16 Bit to build the
>  >>  device's internal 32 Bit format.
>  >>
>  >>  What does this non-32-Bit exclusion exactly mean?
>  >>  Will the driver work on our HW configuration?
>  >>
>  > This #error message was included, because if you look at the code
>  > you'll see that the read/write accessors are 32-bit operations *(u32 *
>  > ).  These may or may not work on your configuration.  It should be
>  > trivial to write accessors for a 16-bit bus, but nobody had hardware
>  > to try it out on.  Please do so and submit a patch.
>
>  Yes, it seems, that we just need two additional functions which split a
>  32 Bit access into two 16 Bit accesses. That should be easy. I'm going
>  to create a patch as soon as I get the HW. But first I want to test
>  whether the processor splits itself automatically.

Well, the i.MX31 Litekit board has a 16-bit LAN9117 and that seems to
work with the 32-bit flag set in the config file.

/Magnus



From mike at terascala.com  Wed Apr 23 16:10:53 2008
From: mike at terascala.com (Mike Nuss)
Date: Wed, 23 Apr 2008 10:10:53 -0400
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
Message-ID: <2C7DE72B9BD00F44BAECA5B0CBB873950E03C6@hermes.terascala.com>

Stefan wrote:
> >
> > At this point all possibilities are on the table and I'm 
> looking for any
> > input from anyone with experience (good, bad, or whatever) with this
> > processor and/or designs similar to the Sequoia.
> 
> If you scan the U-Boot mailing list for 440EPx/Denali DDR2 
> problems, you will 
> most likely find some references.

I definitely recommend using the latest U-Boot with the SPD-based Denali
code, if you're using DIMM modules.

A smoking gun for us was the timing of the address clocking. Look at the
lines on a scope; you may find that the clock is hitting too soon (before
the address is stable). (If so, you'll need to delay the clock on your
board.)

Hope this helps,
Mike



From sr at denx.de  Wed Apr 23 16:25:29 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 23 Apr 2008 16:25:29 +0200
Subject: [U-Boot-Users] ppc4xx: gpio setup broken for ppc405ep
In-Reply-To: <200804230854.22005.super.firetwister@gmail.com>
References: <6a6049b80803271104x598b47adta1dc97f9d13102c@mail.gmail.com>
	<6a6049b80803310433h6e237542te056fc755a0dcf2a@mail.gmail.com>
	<200804230854.22005.super.firetwister@gmail.com>
Message-ID: <200804231625.30003.sr@denx.de>

On Wednesday 23 April 2008, Markus Brunner wrote:
> After some emails with John from AMCC here are the Results:
>
> About the "random" tri-state select settings in the tables for alternate
> function for 440EP

Thanks for the update here.

<snip>

> The high/low addresses of the select registers of 405EP and the way they
> are assigned to the pins are like any other amcc processor. This means the
> current Users manual is wrong and will be updated.

OK, thanks for contacting AMCC here.

<snip>

> So we've got to change something with the gpio setup.

Patches welcome. :)

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From ayman at austin.rr.com  Wed Apr 23 17:04:51 2008
From: ayman at austin.rr.com (ayman at austin.rr.com)
Date: Wed, 23 Apr 2008 10:04:51 -0500
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <200804231026.51751.sr@denx.de>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<480E55CC.4010807@ovro.caltech.edu> <200804231026.51751.sr@denx.de>
Message-ID: <20080423150448.GA8998@crust.elkhashab.com>

On Wed, Apr 23, 2008 at 10:26:51AM +0200, Stefan Roese wrote:

> Full ACK from me. I would always recommend to use a small NOR FLASH with a 
> full-blown U-Boot for booting from NOR with full DDR2 setup etc. All this 
> will be hard to implement with all the restrictions for booting from PCI 
> (even though I have never done this before, but I suspect that it will be 
> quite as limited as booting from NAND).
> 
> > But of course there may be 
> > reasons to want to boot over PCI ...
> 
> Yes, what is the main reason you want to do this? As mentioned above, I 
> recommend to boot from a small NOR FLASH (512kB) and "wait" in U-Boot for the 
> PCI host to provide the OS/application image via PCI.

Ok, here is what I want to do.  I have a board that has several PPC460s
on it.  Each has its own DDR2.  One of them is the master and boots up
normally today with uboot, launches linux, etc.  What I want to do is
have that master load the flash binary image into memory and then lock
that memory down (via whatever kernel calls are required).  Then I want
to configure each slaves PCI bar registers to be able to read from this
main memory and then tell them to go.  So my thought was that it would
appear to the slaves that they are just loading from a regular flash
and this image would contain uboot, kernel, root filesystem.  Basically
everything a flash normally would have.  It sounded reasonable at the
time.   The reason to avoid a flash on every one is so that we don't
have to reflash that many CPUs every time and because it will take up
more board space.  Thanks 

- ame



From giometti at enneenne.com  Wed Apr 23 16:43:25 2008
From: giometti at enneenne.com (Rodolfo Giometti)
Date: Wed, 23 Apr 2008 16:43:25 +0200
Subject: [U-Boot-Users] Pull request: u-boot-video
Message-ID: <E1JogBx-0001cu-AK@zaigor.enneenne.com>

The following changes since commit a49e0d177a0749614b316ec847fb623f09c82c07:
  Matthias Fuchs (1):
        video: Add missing free for logo memory

are available in the git repository at:

  git://git.denx.de/u-boot-video.git master




From dwh at ovro.caltech.edu  Wed Apr 23 18:18:15 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Wed, 23 Apr 2008 09:18:15 -0700
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <20080423150448.GA8998@crust.elkhashab.com>
References: <20080422205307.B644E24AB5@gemini.denx.de>	<480E55CC.4010807@ovro.caltech.edu>
	<200804231026.51751.sr@denx.de>
	<20080423150448.GA8998@crust.elkhashab.com>
Message-ID: <480F6147.4060406@ovro.caltech.edu>

Hi Ame,

>> Yes, what is the main reason you want to do this?
> 
> Ok, here is what I want to do.  I have a board that has several PPC460s
> on it.  Each has its own DDR2.  One of them is the master and boots up
> normally today with uboot, launches linux, etc.  What I want to do is
> have that master load the flash binary image into memory and then lock
> that memory down (via whatever kernel calls are required).  Then I want
> to configure each slaves PCI bar registers to be able to read from this
> main memory and then tell them to go.  So my thought was that it would
> appear to the slaves that they are just loading from a regular flash
> and this image would contain uboot, kernel, root filesystem.  Basically
> everything a flash normally would have.  It sounded reasonable at the
> time.   The reason to avoid a flash on every one is so that we don't
> have to reflash that many CPUs every time and because it will take up
> more board space.  Thanks 

Here's a few ideas then.

1) Use the main host to setup DDR on each of the targets,
    copy a U-Boot image to each target, and then enable the
    targets to boot from DDR.

    The target U-Boot versions would have to skip all DDR
    initialization, since they are running from DDR.

    I believe this code would come under ...

http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM

    Which contains the warning:

    'But it is difficult, unsupported, and fraught with peril.'

    Wolfgang and Stephan could probably comment more on this.

2) Configure an inbound translation window on the host to point
    a PCI window to its *flash*.

    Configure the outbound translation windows on the targets to
    point to the host inbound window.

    Each target would then boot from the same flash as the host.
    Assuming there was some I/O to distinguish the targets from the
    host, the code could determine what to do at runtime.

    This has the disadvantage that all boards are booting from
    potentially slower flash memory, but that may not matter.

3) Configure the host DDR memory such that the OS does not use
    all installed memory, eg. reserves enough memory for a U-Boot
    image.

    Setup the host inbound translation window to point to that
    linear DDR region, and have the host copy the image there.

    Setup the targets as in (2) and let them boot.

The nice thing about (2) and (3) is that the target processors are
effectively in the 'virgin' state that flash booting expects, so
the modifications to U-Boot required to support the booting scheme
would be minimal.

4) Another option would be to place SRAM on each of the other
    processors, and copy the U-Boot image there. That way flash
    on the targets is replaced with SRAM.

    However, this would require a hardware change, and is not
    much of an improvement.


As for the root filesystem, there's more to think about there :)

I will soon have a similar situation to yours. I'll have a master
CPU (an x86 host CPU in a compact PCI crate), and 15 to 20 boards
in peripheral slots (MPC8349EA processors). Each processor has
a gigabit ethernet port, so during development, I'll just use an
NFS mounted rootfs. However, once I deploy about 8 crates worth
of this hardware, I don't want to have lots of Gbe cables and
switches. At that point I plan to change to a scheme where I
create a virtual network interface over PCI. If there is
stuff that needs to be stored locally, then I'll setup a
RAM disk and rsync the contents from an NFS mount at boot time.
The only issue with this approach is whether a virtual network
over PCI driver exists. The MPC8349EA development kit comes with
a driver that sounds like it does some of this, so I'll start
with that.

The scheme I envisage is; the peripheral boards boot U-Boot, and
that U-Boot port has a 'terminal over PCI' and 'ethernet over PCI'
driver built in. Back on the host CPU, I can get to the terminals
via /dev/ttyPCI# nodes, and get to each board via ethernet
connections, where the slot numbers of the boards define unique
MAC addresses. The U-Boots on each board can then tftp a kernel
and boot. The kernel command line will use an NFS path that
comes back through the x86 host CPU.

None of this is implemented, but its only software ... right :)

Cheers,
Dave




From scottwood at freescale.com  Wed Apr 23 18:27:25 2008
From: scottwood at freescale.com (Scott Wood)
Date: Wed, 23 Apr 2008 11:27:25 -0500
Subject: [U-Boot-Users] Kernel hanging after lmb_end_of_DRAM() function.
In-Reply-To: <16830552.post@talk.nabble.com>
References: <16830552.post@talk.nabble.com>
Message-ID: <20080423162725.GA32077@ld0162-tx32.am.freescale.net>

On Tue, Apr 22, 2008 at 09:12:11PM -0700, gforgcc wrote:
> i am trying to bring up the latest kernel on EP8248 target,
> i am using U-boot-1.3.2 and linux-2.6.25-rc8, i started debugging using
> BDI2000 which helped me to know atleast what is going wrong, i have added
> some printk's in the kernel source but still i am not able to find where and
> what exactly is going wrong, The first statement it is printing in the log
> buffer is 
> ""Using Embedded Planet EP8248E machine description"" and thats it the next
> message is 
> Unable to handle kernel paging request for data at address 0xbfff0000
> Faulting instruction address:0xc0012070 (This nearest address to this
> address in System.map file is cacheable_memzero)
> and tracing like this i came to know that in the file
> arch/powerpc/mm/ppc_mmu_32.c , here in the function __init MMU_init_hw() and
> in the line n_hpteg = total_memory / (PAGE_SIZE * 8); probably it is getting
> problem because when i tried to print the variable total_memory it is
> printing zero !!! :( :(  so probably i am thinking it is not able to find
> some memory for Hash table :(

Are you using a device-tree-aware u-boot with uImage, or are you using
cuImage.pq2?  Do not use dtbImage.ep8248e; that's for PlanetCore.

ep8248e in mainline u-boot doesn't appear to be device-tree aware.

If you're using cuImage.pq2, do you get any output from the bootwrapper? 
Make sure you add /chosen/linux,stdout-path.  There may be other device
tree changes you need to make it work with u-boot as well.

-Scott



From biggerbadderben at gmail.com  Wed Apr 23 19:29:06 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Wed, 23 Apr 2008 10:29:06 -0700
Subject: [U-Boot-Users] Question about smc911x driver (16/32 Bit support)
In-Reply-To: <59b21cf20804230635k4d424d88wb7f6fdc9b3e49298@mail.gmail.com>
References: <480DD799.50402@tqs.de>
	<f8328f7c0804221103i7af61e05h3134aea07eb95ee4@mail.gmail.com>
	<480ED91C.4010400@tqs.de>
	<59b21cf20804230635k4d424d88wb7f6fdc9b3e49298@mail.gmail.com>
Message-ID: <f8328f7c0804231029v25e43b50y524f8bf3510fa891@mail.gmail.com>

Hi Magnus,

On Wed, Apr 23, 2008 at 6:35 AM, Magnus Lilja <lilja.magnus at gmail.com> wrote:
> Hi Jens,
>
>  On Wed, Apr 23, 2008 at 8:37 AM, Jens Gehrlein <sew_s at tqs.de> wrote:
>  >  >>  in the source code there is a preprocessor directive
>  >  >>  #error "SMC911X: Only 32-bit bus is supported".
>  >  >>
>  >  >>  We use a LAN9215i, which has a 16 Bit data interface only, connected to
>  >  >>  an i.MX31.
>  >  >>
>  >  >>  The LAN9215 is in the driver's ID list.
>  >  >>
>  >  >>  According to the data sheet accesses have to be 2x16 Bit to build the
>  >  >>  device's internal 32 Bit format.
>  >  >>
>  >  >>  What does this non-32-Bit exclusion exactly mean?
>  >  >>  Will the driver work on our HW configuration?
>  >  >>
>  >  > This #error message was included, because if you look at the code
>  >  > you'll see that the read/write accessors are 32-bit operations *(u32 *
>  >  > ).  These may or may not work on your configuration.  It should be
>  >  > trivial to write accessors for a 16-bit bus, but nobody had hardware
>  >  > to try it out on.  Please do so and submit a patch.
>  >
>  >  Yes, it seems, that we just need two additional functions which split a
>  >  32 Bit access into two 16 Bit accesses. That should be easy. I'm going
>  >  to create a patch as soon as I get the HW. But first I want to test
>  >  whether the processor splits itself automatically.
>
>  Well, the i.MX31 Litekit board has a 16-bit LAN9117 and that seems to
>  work with the 32-bit flag set in the config file.
>
That's good news.  I would prefer, though, to break this into two
16-bit accesses so we don't need to wonder what architectures it would
work on.  Would you be able to try something out, since you have
hardware?

regards,
Ben



From lilja.magnus at gmail.com  Wed Apr 23 19:53:36 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Wed, 23 Apr 2008 19:53:36 +0200
Subject: [U-Boot-Users] Question about smc911x driver (16/32 Bit support)
In-Reply-To: <f8328f7c0804231029v25e43b50y524f8bf3510fa891@mail.gmail.com>
References: <480DD799.50402@tqs.de>
	<f8328f7c0804221103i7af61e05h3134aea07eb95ee4@mail.gmail.com>
	<480ED91C.4010400@tqs.de>
	<59b21cf20804230635k4d424d88wb7f6fdc9b3e49298@mail.gmail.com>
	<f8328f7c0804231029v25e43b50y524f8bf3510fa891@mail.gmail.com>
Message-ID: <59b21cf20804231053j61f37043g72487f3c412d0e0d@mail.gmail.com>

Hi Ben,

>  >  Well, the i.MX31 Litekit board has a 16-bit LAN9117 and that seems to
>  >  work with the 32-bit flag set in the config file.
>  >
>  That's good news.  I would prefer, though, to break this into two
>  16-bit accesses so we don't need to wonder what architectures it would
>  work on.  Would you be able to try something out, since you have
>  hardware?

If someone publishes a patch I can certainly try it on the hardware.

Regards, Magnus



From Ken.Fuchs at bench.com  Wed Apr 23 20:01:10 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 23 Apr 2008 13:01:10 -0500
Subject: [U-Boot-Users] USB SUPPORT & get_vfatname
In-Reply-To: <480F1A6B.6070207@gandalf.sssup.it>
Message-ID: <AA28F077645B324881335614E4F7C428034CDB@win-ex01.bench.com>

Michael,

Sorry, your latest get_vfatname patch doesn't work either.

FAT16 works perfectly, so the USB code is probably _not_ at fault.  I see only problems with FAT32, but only for _some_ long collections of files.

Thus, there may still be a problem with fs/fat/fat.c.  Maybe there is something wrong with my copy of fat.c  I attached it;  Perhaps you can see a problem with it.

Sincerely,

Ken Fuchs

> -----Original Message-----
> From: michael [mailto:trimarchi at gandalf.sssup.it] 
> Sent: Wednesday, April 23, 2008 06:16
> To: michael
> Cc: Fuchs, Ken; u-boot-users at lists.sourceforge.net; Wolfgang Denk
> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> 
> 
> Hi,
> 
> michael wrote:
> > Hi,
> >
> > Can you try this one?
> >
> > Revert my last one patch?
> > It change the test code, before the while. I use your script on a 
> > Compact Flash and it looks fine for me (under linux).
> >
> > Regards Michael
> >
> > 
> --------------------------------------------------------------
> ----------
> >
> > Check if the entry is a valid dir_slot entry, otherwise it 
> is a dentry and the
> > name has to be taken by the get_name function
> >
> > Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>
> >
> > ---
> >  fs/fat/fat.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> > index 49c78ed..bc37cec 100644
> > --- a/fs/fat/fat.c
> > +++ b/fs/fat/fat.c
> > @@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int 
> curclust, __u8 *cluster,
> >  		while (slotptr2->id > 0x01) {
> >  			slotptr2++;
> >  		}
> > +
> >  		/* Save the real directory entry */
> >  		realdent = (dir_entry*)slotptr2 + 1;
> > +		if (slotptr2->attr != ATTR_VFAT) {
> > +			get_name ((dir_entry *)realdent, l_name);
> > +			goto out;
> > +		}
> > +
> >  		while ((__u8*)slotptr2 >= get_vfatname_block) {
> >  			slot2str(slotptr2, l_name, &idx);
> >  			slotptr2--;
> > @@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int 
> curclust, __u8 *cluster,
> >  	else if (*l_name == aRING) *l_name = '?';
> >  	downcase(l_name);
> >  
> > +out:
> >  	/* Return the real directory entry */
> >  	memcpy(retdent, realdent, sizeof(dir_entry));
> >  
> >   
> The scripts in this thread can be used to test the fat32 
> filesystem. I 
> do some tests using Compact Flash
> device and this patchs work for me. I would like to know if is a fat 
> layer problem or usb layer problem.
> 
> Michael
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fat.c
Type: application/octet-stream
Size: 24738 bytes
Desc: fat.c
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080423/2a4bffdc/attachment.obj 

From Ken.Fuchs at bench.com  Wed Apr 23 21:23:14 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 23 Apr 2008 14:23:14 -0500
Subject: [U-Boot-Users] [PATCH] Add eSDHC driver
In-Reply-To: <1208876866-11251-1-git-send-email-afleming@freescale.com>
Message-ID: <AA28F077645B324881335614E4F7C428034CDC@win-ex01.bench.com>

> Pierre Savary wrote:

> >Where could we find the driver that works with MMCv4 on at91sam9x?

Andy Fleming wrote:

> Pierre, I don't have a driver that works on at91sam9x, I'm 
> afraid.

Here's an MMC v2.x AT91SAM9260 patch for Atmel modified u-boot 1.1.5.
You will need to define GPIO pins for other AT91SAM9 processors, etc.

If you really need an MMC v4.x AT91SAM9 MCI driver for 1.1.5 fast, you
probably could cut and paste the v4.x code you need from Andy's MMC
driver
into the MMC v2.x MCI driver this patch provides.

BTW, if anyone knows why MMC 4 bit is disabled for AT91SAM9261 in the
MCI Linux driver, I'd like to hear the reasons why.

--- u-boot_at91sam9260_mmc.patch (AT91 MCI driver) ---

diff -burN u-boot-1.1.5/board/at91sam9260ek/at91sam9260ek.c
u-boot-1.1.5.klk/board/at91sam9260ek/at91sam9260ek.c
--- u-boot-1.1.5/board/at91sam9260ek/at91sam9260ek.c	2007-08-21
17:06:36.000000000 +0200
+++ u-boot-1.1.5.klk/board/at91sam9260ek/at91sam9260ek.c
2007-08-23 08:37:42.000000000 +0200
@@ -109,6 +109,24 @@
 }
 
 
+#ifdef CONFIG_MMC
+#if (CONFIG_COMMANDS & CFG_CMD_MMC)
+int AT91F_MMC_Hardware_Init(void)
+{
+	AT91C_BASE_PIOA->PIO_ASR = (1 << 8 );		/* periph A
select register */
+	AT91C_BASE_PIOA->PIO_BSR |= 0x3B;			/*
periph B select register */
+	AT91C_BASE_PIOA->PIO_PDR |= 0x13B;			/* PIO
disable register */
+	AT91C_BASE_PIOA->PIO_PPUDR |= 0x13B;		/* Pull up
disable register */
+
+	AT91C_BASE_PMC->PMC_PCER = (1 << 9);
+}
+#endif /* CONFIG_COMMANDS & CFG_CMD_MMC */
+#endif /* CONFIG_MMC */
+
+
+
+
+
 #ifdef CONFIG_DRIVER_ETHER
 #if (CONFIG_COMMANDS & CFG_CMD_NET)
 
diff -burN u-boot-1.1.5/common/cmd_nvedit.c
u-boot-1.1.5.klk/common/cmd_nvedit.c
--- u-boot-1.1.5/common/cmd_nvedit.c	2006-10-20 17:54:33.000000000
+0200
+++ u-boot-1.1.5.klk/common/cmd_nvedit.c	2007-08-23
09:26:18.000000000 +0200
@@ -530,6 +530,7 @@
 	return (-1);
 }
 
+#ifndef CFG_ENV_IS_NOWHERE
 #if defined(CFG_ENV_IS_IN_NVRAM) || defined(CFG_ENV_IS_IN_EEPROM) || \
     ((CONFIG_COMMANDS & (CFG_CMD_ENV|CFG_CMD_FLASH)) == \
       (CFG_CMD_ENV|CFG_CMD_FLASH)) || \
@@ -544,7 +545,7 @@
 	return (saveenv() ? 1 : 0);
 }
 
-
+#endif
 #endif
 
 
@@ -587,7 +588,7 @@
 	"setenv name\n"
 	"    - delete environment variable 'name'\n"
 );
-
+#ifndef CFG_ENV_IS_NOWHERE
 #if defined(CFG_ENV_IS_IN_NVRAM) || defined(CFG_ENV_IS_IN_EEPROM) || \
     ((CONFIG_COMMANDS & (CFG_CMD_ENV|CFG_CMD_FLASH)) == \
       (CFG_CMD_ENV|CFG_CMD_FLASH)) || \
@@ -600,6 +601,7 @@
 );
 
 #endif	/* CFG_CMD_ENV */
+#endif	
 
 #if (CONFIG_COMMANDS & CFG_CMD_ASKENV)
 
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/atmel_mci.c
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/atmel_mci.c
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/atmel_mci.c	1970-01-01
01:00:00.000000000 +0100
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/atmel_mci.c
2007-08-23 09:45:46.000000000 +0200
@@ -0,0 +1,572 @@
+/*
+ * Copyright (C) 2004-2006 Atmel Corporation
+ *
+ * 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 <common.h>
+
+#ifdef CONFIG_MMC
+
+#include <part.h>
+#include <mmc.h>
+
+#include <asm/io.h>
+#include <asm/errno.h>
+#include <asm/byteorder.h>
+//#include <asm/arch/clk.h>
+//#include <asm/arch/memory-map.h>
+#include <asm/arch/hardware.h>	//klk
+
+#include "atmel_mci.h"
+#undef DEBUG
+#ifdef DEBUG
+#define pr_debug(fmt, args...) printf(fmt, ##args)
+#else
+#define pr_debug(...) do { } while(0)
+#endif
+
+#ifndef CFG_MMC_CLK_OD
+#define CFG_MMC_CLK_OD		375000
+#endif
+
+#ifndef CFG_MMC_CLK_PP
+#define CFG_MMC_CLK_PP		20000000
+#endif
+
+#ifndef CFG_MMC_OP_COND
+#define CFG_MMC_OP_COND		0x00100000
+#endif
+
+#define MMC_DEFAULT_BLKLEN	512
+#define MMC_DEFAULT_RCA		1
+
+static unsigned int mmc_rca;
+static int mmc_card_is_sd;
+static block_dev_desc_t mmc_blkdev;
+
+block_dev_desc_t *mmc_get_dev(int dev)
+{
+	return &mmc_blkdev;
+}
+
+static void mci_set_mode(unsigned long hz, unsigned long blklen)
+{
+	unsigned long bus_hz;
+	unsigned long clkdiv;
+
+	// bus_hz = get_mci_clk_rate();
+	bus_hz = AT91C_MASTER_CLOCK;
+	clkdiv = (bus_hz / hz) / 2 - 1;
+
+	pr_debug("mmc: setting clock %lu Hz, block size %lu\n",
+		 hz, blklen);
+
+	if (clkdiv & ~255UL) {
+		clkdiv = 255;
+		pr_debug("mmc: clock %lu too low; setting CLKDIV to
255\n",
+			hz);
+	}
+
+	blklen &= 0xfffc;
+	mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
+			 | MMCI_BF(BLKLEN, blklen)
+			 | MMCI_BIT(RDPROOF)
+			 | MMCI_BIT(WRPROOF)));
+}
+
+#define RESP_NO_CRC	1
+#define R1		MMCI_BF(RSPTYP, 1)
+#define R2		MMCI_BF(RSPTYP, 2)
+#define R3		(R1 | RESP_NO_CRC)
+#define R6		R1
+#define NID		MMCI_BF(MAXLAT, 0)
+#define NCR		MMCI_BF(MAXLAT, 1)
+#define TRCMD_START	MMCI_BF(TRCMD, 1)
+#define TRDIR_READ	MMCI_BF(TRDIR, 1)
+#define TRTYP_BLOCK	MMCI_BF(TRTYP, 0)
+#define INIT_CMD	MMCI_BF(SPCMD, 1)
+#define OPEN_DRAIN	MMCI_BF(OPDCMD, 1)
+
+#define ERROR_FLAGS	(MMCI_BIT(DTOE)			\
+			 | MMCI_BIT(RDIRE)		\
+			 | MMCI_BIT(RENDE)		\
+			 | MMCI_BIT(RINDE)		\
+			 | MMCI_BIT(RTOE))
+
+static int
+mmc_cmd(unsigned long cmd, unsigned long arg,
+	void *resp, unsigned long flags)
+{
+	unsigned long *response = resp;
+	int i, response_words = 0;
+	unsigned long error_flags;
+	u32 status;
+
+	AT91F_MMC_Hardware_Init();
+	
+	pr_debug("mmc: CMD%lu 0x%lx (flags 0x%lx)\n",
+		 cmd, arg, flags);
+
+	error_flags = ERROR_FLAGS;
+	if (!(flags & RESP_NO_CRC))
+		error_flags |= MMCI_BIT(RCRCE);
+
+	flags &= ~MMCI_BF(CMDNB, ~0UL);
+
+	if (MMCI_BFEXT(RSPTYP, flags) == MMCI_RSPTYP_48_BIT_RESP)
+		response_words = 1;
+	else if (MMCI_BFEXT(RSPTYP, flags) == MMCI_RSPTYP_136_BIT_RESP)
+		response_words = 4;
+
+	mmci_writel(ARGR, arg);
+	mmci_writel(CMDR, cmd | flags);
+	do {
+		udelay(40);
+		status = mmci_readl(SR);
+	} while (!(status & MMCI_BIT(CMDRDY)));
+
+	pr_debug("mmc: status 0x%08lx\n", status);
+
+	if (status & ERROR_FLAGS) {
+		pr_debug("mmc: command %lu failed (status: 0x%08lx)\n",
+		       cmd, status);
+		return -EIO;
+	}
+
+	if (response_words)
+		pr_debug("mmc: response:");
+
+	for (i = 0; i < response_words; i++) {
+		response[i] = mmci_readl(RSPR);
+		pr_debug(" %08lx", response[i]);
+	}
+	pr_debug("\n");
+
+	return 0;
+}
+
+static int mmc_acmd(unsigned long cmd, unsigned long arg,
+		    void *resp, unsigned long flags)
+{
+	unsigned long aresp[4];
+	int ret;
+
+	/*
+	 * Seems like the APP_CMD part of an ACMD has 64 cycles max
+	 * latency even though the ACMD part doesn't. This isn't
+	 * entirely clear in the SD Card spec, but some cards refuse
+	 * to work if we attempt to use 5 cycles max latency here...
+	 */
+	ret = mmc_cmd(MMC_CMD_APP_CMD, 0, aresp,
+		      R1 | NCR | (flags & OPEN_DRAIN));
+	if (ret)
+		return ret;
+	if ((aresp[0] & (R1_ILLEGAL_COMMAND | R1_APP_CMD)) !=
R1_APP_CMD)
+		return -ENODEV;
+
+	ret = mmc_cmd(cmd, arg, resp, flags);
+	return ret;
+}
+
+static unsigned long
+mmc_bread(int dev, unsigned long start, lbaint_t blkcnt,
+	  unsigned long *buffer)
+{
+	int ret, i = 0;
+	unsigned long resp[4];
+	unsigned long card_status, data;
+	unsigned long wordcount;
+	u32 status;
+
+	if (blkcnt == 0)
+		return 0;
+
+	pr_debug("mmc_bread: dev %d, start %lx, blkcnt %lx\n",
+		 dev, start, blkcnt);
+
+	/* Put the device into Transfer state */
+	ret = mmc_cmd(MMC_CMD_SELECT_CARD, mmc_rca << 16, resp, R1 |
NCR);
+	if (ret) goto fail;
+
+	/* Set block length */
+	ret = mmc_cmd(MMC_CMD_SET_BLOCKLEN, mmc_blkdev.blksz, resp, R1 |
NCR);
+	if (ret) goto fail;
+
+	pr_debug("MCI_DTOR = %08lx\n", mmci_readl(DTOR));
+
+	for (i = 0; i < blkcnt; i++, start++) {
+		ret = mmc_cmd(MMC_CMD_READ_SINGLE_BLOCK,
+			      start * mmc_blkdev.blksz, resp,
+			      (R1 | NCR | TRCMD_START | TRDIR_READ
+			       | TRTYP_BLOCK));
+		if (ret) goto fail;
+
+		ret = -EIO;
+		wordcount = 0;
+		do {
+			do {
+				status = mmci_readl(SR);
+				if (status & (ERROR_FLAGS |
MMCI_BIT(OVRE)))
+					goto fail;
+			} while (!(status & MMCI_BIT(RXRDY)));
+
+			if (status & MMCI_BIT(RXRDY)) {
+				data = mmci_readl(RDR);
+				/* pr_debug("%x\n", data); */
+				*buffer++ = data;
+				wordcount++;
+			}
+		} while(wordcount < (mmc_blkdev.blksz / 4));
+
+		pr_debug("mmc: read %u words, waiting for BLKE\n",
wordcount);
+
+		do {
+			status = mmci_readl(SR);
+		} while (!(status & MMCI_BIT(BLKE)));
+
+		putc('.');
+	}
+
+out:
+	/* Put the device back into Standby state */
+	mmc_cmd(MMC_CMD_SELECT_CARD, 0, resp, NCR);
+	return i;
+
+fail:
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread failed, card status = %08x\n",
card_status);
+	goto out;
+}
+
+static void mmc_parse_cid(struct mmc_cid *cid, unsigned long *resp)
+{
+	cid->mid = resp[0] >> 24;
+	cid->oid = (resp[0] >> 8) & 0xffff;
+	cid->pnm[0] = resp[0];
+	cid->pnm[1] = resp[1] >> 24;
+	cid->pnm[2] = resp[1] >> 16;
+	cid->pnm[3] = resp[1] >> 8;
+	cid->pnm[4] = resp[1];
+	cid->pnm[5] = resp[2] >> 24;
+	cid->pnm[6] = 0;
+	cid->prv = resp[2] >> 16;
+	cid->psn = (resp[2] << 16) | (resp[3] >> 16);
+	cid->mdt = resp[3] >> 8;
+}
+
+static void sd_parse_cid(struct mmc_cid *cid, unsigned long *resp)
+{
+	cid->mid = resp[0] >> 24;
+	cid->oid = (resp[0] >> 8) & 0xffff;
+	cid->pnm[0] = resp[0];
+	cid->pnm[1] = resp[1] >> 24;
+	cid->pnm[2] = resp[1] >> 16;
+	cid->pnm[3] = resp[1] >> 8;
+	cid->pnm[4] = resp[1];
+	cid->pnm[5] = 0;
+	cid->pnm[6] = 0;
+	cid->prv = resp[2] >> 24;
+	cid->psn = (resp[2] << 8) | (resp[3] >> 24);
+	cid->mdt = (resp[3] >> 8) & 0x0fff;
+}
+
+static void mmc_dump_cid(const struct mmc_cid *cid)
+{
+	printf("Manufacturer ID:       %02lX\n", cid->mid);
+	printf("OEM/Application ID:    %04lX\n", cid->oid);
+	printf("Product name:          %s\n", cid->pnm);
+	printf("Product Revision:      %lu.%lu\n",
+	       cid->prv >> 4, cid->prv & 0x0f);
+	printf("Product Serial Number: %lu\n", cid->psn);
+	printf("Manufacturing Date:    %02lu/%02lu\n",
+	       cid->mdt >> 4, cid->mdt & 0x0f);
+}
+
+static void mmc_dump_csd(const struct mmc_csd *csd)
+{
+	unsigned long *csd_raw = (unsigned long *)csd;
+	pr_debug("CSD data: %08lx %08lx %08lx %08lx\n",
+	       csd_raw[0], csd_raw[1], csd_raw[2], csd_raw[3]);
+	pr_debug("CSD structure version:   1.%u\n", csd->csd_structure);
+	pr_debug("MMC System Spec version: %u\n", csd->spec_vers);
+	pr_debug("Card command classes:    %03x\n", csd->ccc);
+	pr_debug("Read block length:       %u\n", 1 <<
csd->read_bl_len);
+	if (csd->read_bl_partial)
+		puts("Supports partial reads\n");
+	else
+		puts("Does not support partial reads\n");
+	pr_debug("Write block length:      %u\n", 1 <<
csd->write_bl_len);
+	if (csd->write_bl_partial)
+		puts("Supports partial writes\n");
+	else
+		puts("Does not support partial writes\n");
+	if (csd->wp_grp_enable)
+		pr_debug("Supports group WP:      %u\n",
csd->wp_grp_size + 1);
+	else
+		puts("Does not support group WP\n");
+	pr_debug("Card capacity:		%u bytes\n",
+	       (csd->c_size + 1) * (1 << (csd->c_size_mult + 2)) *
+	       (1 << csd->read_bl_len));
+	pr_debug("File format:            %u/%u\n",
+	       csd->file_format_grp, csd->file_format);
+	puts("Write protection:        ");
+	if (csd->perm_write_protect)
+		puts(" permanent");
+	if (csd->tmp_write_protect)
+		puts(" temporary");
+	putc('\n');
+}
+
+static int mmc_idle_cards(void)
+{
+	int ret;
+
+	/* Reset and initialize all cards */
+	ret = mmc_cmd(MMC_CMD_GO_IDLE_STATE, 0, NULL, 0);
+	
+	if (ret)
+		return ret;
+	pr_debug(" ret: %i\n",ret);
+	/* Keep the bus idle for 74 clock cycles */
+	return mmc_cmd(0, 0, NULL, INIT_CMD);
+}
+
+static int sd_init_card(struct mmc_cid *cid, int verbose)
+{
+	unsigned long resp[4];
+	int i, ret = 0;
+
+	mmc_idle_cards();
+	for (i = 0; i < 1000; i++) {
+		ret = mmc_acmd(MMC_ACMD_SD_SEND_OP_COND,
CFG_MMC_OP_COND,
+			       resp, R3 | NID);
+		if (ret || (resp[0] & 0x80000000))
+			break;
+		ret = -ETIMEDOUT;
+	}
+
+	if (ret)
+		return ret;
+
+	ret = mmc_cmd(MMC_CMD_ALL_SEND_CID, 0, resp, R2 | NID);
+	if (ret)
+		return ret;
+	sd_parse_cid(cid, resp);
+	if (verbose)
+		mmc_dump_cid(cid);
+
+	/* Get RCA of the card that responded */
+	ret = mmc_cmd(MMC_CMD_SD_SEND_RELATIVE_ADDR, 0, resp, R6 | NCR);
+	if (ret)
+		return ret;
+
+	mmc_rca = resp[0] >> 16;
+	if (verbose)
+		pr_debug("SD Card detected (RCA %u)\n", mmc_rca);
+	mmc_card_is_sd = 1;
+	return 0;
+}
+
+static int mmc_init_card(struct mmc_cid *cid, int verbose)
+{
+	unsigned long resp[4];
+	int i, ret = 0;
+
+	mmc_idle_cards();
+
+	for (i = 0; i < 1000; i++) {
+		ret = mmc_cmd(MMC_CMD_SEND_OP_COND, CFG_MMC_OP_COND,
resp,
+			      R3 | NID | OPEN_DRAIN);
+		if (ret || (resp[0] & 0x80000000))
+		{
+			break;
+		}
+		ret = -ETIMEDOUT;
+	}
+	pr_debug("4\n");
+	pr_debug("ret : %i\n",ret);
+	if (ret)
+		return ret;
+	pr_debug("5\n");
+	/* Get CID of all cards. FIXME: Support more than one card */
+	ret = mmc_cmd(MMC_CMD_ALL_SEND_CID, 0, resp, R2 | NID |
OPEN_DRAIN);
+	if (ret)
+		return ret;
+	mmc_parse_cid(cid, resp);
+	if (verbose)
+		mmc_dump_cid(cid);
+
+	/* Set Relative Address of the card that responded */
+	ret = mmc_cmd(MMC_CMD_SET_RELATIVE_ADDR, mmc_rca << 16, resp,
+		      R1 | NCR | OPEN_DRAIN);
+	return ret;
+}
+
+static void mci_set_data_timeout(struct mmc_csd *csd)
+{
+	static const unsigned int dtomul_to_shift[] = {
+		0, 4, 7, 8, 10, 12, 16, 20,
+	};
+	static const unsigned int taac_exp[] = {
+		1, 10, 100, 1000, 10000, 100000, 1000000, 10000000,
+	};
+	static const unsigned int taac_mant[] = {
+		0,  10, 12, 13, 15, 60, 25, 30,
+		35, 40, 45, 50, 55, 60, 70, 80,
+	};
+	unsigned int timeout_ns, timeout_clks;
+	unsigned int e, m;
+	unsigned int dtocyc, dtomul;
+	unsigned int shift;
+	u32 dtor;
+
+	e = csd->taac & 0x07;
+	m = (csd->taac >> 3) & 0x0f;
+
+	timeout_ns = (taac_exp[e] * taac_mant[m] + 9) / 10;
+	timeout_clks = csd->nsac * 100;
+
+	timeout_clks += (((timeout_ns + 9) / 10)
+			 * ((CFG_MMC_CLK_PP + 99999) / 100000) + 9999) /
10000;
+	if (!mmc_card_is_sd)
+		timeout_clks *= 10;
+	else
+		timeout_clks *= 100;
+
+	dtocyc = timeout_clks;
+	dtomul = 0;
+	while (dtocyc > 15 && dtomul < 8) {
+		dtomul++;
+		shift = dtomul_to_shift[dtomul];
+		dtocyc = (timeout_clks + (1 << shift) - 1) >> shift;
+	}
+
+	if (dtomul >= 8) {
+		dtomul = 7;
+		dtocyc = 15;
+		puts("Warning: Using maximum data timeout\n");
+	}
+
+	dtor = (MMCI_BF(DTOMUL, dtomul)
+		| MMCI_BF(DTOCYC, dtocyc));
+	mmci_writel(DTOR, dtor);
+
+	pr_debug("mmc: Using %u cycles data timeout (DTOR=0x%x)\n",
+	       dtocyc << shift, dtor);
+}
+
+int mmc_init(int verbose)
+{
+	struct mmc_cid cid;
+	struct mmc_csd csd;
+	unsigned int max_blksz;
+	int ret,aux;
+	
+	AT91F_MMC_Hardware_Init();
+	
+	pr_debug("0\n");
+	/* Initialize controller */
+	mmci_writel(CR, MMCI_BIT(SWRST));
+	mmci_writel(CR, MMCI_BIT(MCIEN));
+	mmci_writel(DTOR, 0x5f);
+	mmci_writel(IDR, ~0UL);
+	mmci_writel(SDCR, 0x1);
+	mci_set_mode(CFG_MMC_CLK_OD, MMC_DEFAULT_BLKLEN);
+/* 	//mmci_writel(CR, MMCI_BIT(SWRST));
+	mmci_writel(CR, 0x00000001);
+	mmci_writel(DTOR, 0x0000007F);
+	mmci_writel(IDR, 0xFFFFFFFF);
+	mmci_writel(SDCR, 0x00000001);
+	//mci_set_mode(CFG_MMC_CLK_OD, MMC_DEFAULT_BLKLEN);
+	mmci_writel(MR, 0x02009B4A); */
+
+	pr_debug("1\n");
+	
+	mmc_card_is_sd = 0;
+
+	ret = sd_init_card(&cid, verbose);
+	if (ret) {
+		mmc_rca = MMC_DEFAULT_RCA;
+		ret = mmc_init_card(&cid, verbose);
+	}
+	pr_debug("6\n");
+	if (ret)
+		return ret;
+	pr_debug("7\n");
+	/* Get CSD from the card */
+	ret = mmc_cmd(MMC_CMD_SEND_CSD, mmc_rca << 16, &csd, R2 | NCR);
+	if (ret)
+		return ret;
+	if (verbose)
+		mmc_dump_csd(&csd);
+
+	mci_set_data_timeout(&csd);
+
+	/* Initialize the blockdev structure */
+	mmc_blkdev.if_type = IF_TYPE_MMC;
+	mmc_blkdev.part_type = PART_TYPE_DOS;
+	mmc_blkdev.block_read = mmc_bread;
+	sprintf((char *)mmc_blkdev.vendor,
+		"Man %02x%04x Snr %08x",
+		cid.mid, cid.oid, cid.psn);
+	strncpy((char *)mmc_blkdev.product, cid.pnm,
+		sizeof(mmc_blkdev.product));
+	sprintf((char *)mmc_blkdev.revision, "%x %x",
+		cid.prv >> 4, cid.prv & 0x0f);
+
+	/*
+	 * If we can't use 512 byte blocks, refuse to deal with the
+	 * card. Tons of code elsewhere seems to depend on this.
+	 */
+	max_blksz = 1 << csd.read_bl_len;
+	// if (max_blksz < 512 || (max_blksz > 512 &&
!csd.read_bl_partial)) {
+		// pr_debug("Card does not support 512 byte reads,
aborting.\n");
+		// return -ENODEV;
+	// }
+	mmc_blkdev.blksz = 512;
+	mmc_blkdev.lba = (csd.c_size + 1) * (1 << (csd.c_size_mult +
2));
+
+	mci_set_mode(CFG_MMC_CLK_PP, mmc_blkdev.blksz);
+
+#if 0
+	if (fat_register_device(&mmc_blkdev, 1))
+		pr_debug("Could not register MMC fat device\n");
+#else
+	init_part(&mmc_blkdev);
+#endif
+
+	return 0;
+}
+
+int mmc_read(ulong src, uchar *dst, int size)
+{
+	return -ENOSYS;
+}
+
+int mmc_write(uchar *src, ulong dst, int size)
+{
+	return -ENOSYS;
+}
+
+int mmc2info(ulong addr)
+{
+	return 0;
+}
+
+#endif /* CONFIG_MMC */
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/atmel_mci.h
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/atmel_mci.h
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/atmel_mci.h	1970-01-01
01:00:00.000000000 +0100
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/atmel_mci.h
2007-08-17 10:43:17.000000000 +0200
@@ -0,0 +1,201 @@
+/*
+ * Copyright (C) 2005-2006 Atmel Corporation
+ *
+ * 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
+ */
+#ifndef __CPU_AT32AP_ATMEL_MCI_H__
+#define __CPU_AT32AP_ATMEL_MCI_H__
+
+/* Atmel MultiMedia Card Interface (MCI) registers */
+#define MMCI_CR					0x0000
+#define MMCI_MR					0x0004
+#define MMCI_DTOR				0x0008
+#define MMCI_SDCR				0x000c
+#define MMCI_ARGR				0x0010
+#define MMCI_CMDR				0x0014
+#define MMCI_RSPR				0x0020
+#define MMCI_RSPR1				0x0024
+#define MMCI_RSPR2				0x0028
+#define MMCI_RSPR3				0x002c
+#define MMCI_RDR				0x0030
+#define MMCI_TDR				0x0034
+#define MMCI_SR					0x0040
+#define MMCI_IER				0x0044
+#define MMCI_IDR				0x0048
+#define MMCI_IMR				0x004c
+
+/* Bitfields in CR */
+#define MMCI_MCIEN_OFFSET			0
+#define MMCI_MCIEN_SIZE				1
+#define MMCI_MCIDIS_OFFSET			1
+#define MMCI_MCIDIS_SIZE			1
+#define MMCI_PWSEN_OFFSET			2
+#define MMCI_PWSEN_SIZE				1
+#define MMCI_PWSDIS_OFFSET			3
+#define MMCI_PWSDIS_SIZE			1
+#define MMCI_SWRST_OFFSET			7
+#define MMCI_SWRST_SIZE				1
+
+/* Bitfields in MR */
+#define MMCI_CLKDIV_OFFSET			0
+#define MMCI_CLKDIV_SIZE			8
+#define MMCI_PWSDIV_OFFSET			8
+#define MMCI_PWSDIV_SIZE			3
+#define MMCI_RDPROOF_OFFSET			11
+#define MMCI_RDPROOF_SIZE			1
+#define MMCI_WRPROOF_OFFSET			12
+#define MMCI_WRPROOF_SIZE			1
+#define MMCI_PDCPADV_OFFSET			14
+#define MMCI_PDCPADV_SIZE			1
+#define MMCI_PDCMODE_OFFSET			15
+#define MMCI_PDCMODE_SIZE			1
+#define MMCI_BLKLEN_OFFSET			16
+#define MMCI_BLKLEN_SIZE			16
+
+/* Bitfields in DTOR */
+#define MMCI_DTOCYC_OFFSET			0
+#define MMCI_DTOCYC_SIZE			4
+#define MMCI_DTOMUL_OFFSET			4
+#define MMCI_DTOMUL_SIZE			3
+
+/* Bitfields in SDCR */
+#define MMCI_SCDSEL_OFFSET			0
+#define MMCI_SCDSEL_SIZE			4
+#define MMCI_SCDBUS_OFFSET			7
+#define MMCI_SCDBUS_SIZE			1
+
+/* Bitfields in ARGR */
+#define MMCI_ARG_OFFSET				0
+#define MMCI_ARG_SIZE				32
+
+/* Bitfields in CMDR */
+#define MMCI_CMDNB_OFFSET			0
+#define MMCI_CMDNB_SIZE				6
+#define MMCI_RSPTYP_OFFSET			6
+#define MMCI_RSPTYP_SIZE			2
+#define MMCI_SPCMD_OFFSET			8
+#define MMCI_SPCMD_SIZE				3
+#define MMCI_OPDCMD_OFFSET			11
+#define MMCI_OPDCMD_SIZE			1
+#define MMCI_MAXLAT_OFFSET			12
+#define MMCI_MAXLAT_SIZE			1
+#define MMCI_TRCMD_OFFSET			16
+#define MMCI_TRCMD_SIZE				2
+#define MMCI_TRDIR_OFFSET			18
+#define MMCI_TRDIR_SIZE				1
+#define MMCI_TRTYP_OFFSET			19
+#define MMCI_TRTYP_SIZE				2
+
+/* Bitfields in RSPRx */
+#define MMCI_RSP_OFFSET				0
+#define MMCI_RSP_SIZE				32
+
+/* Bitfields in SR/IER/IDR/IMR */
+#define MMCI_CMDRDY_OFFSET			0
+#define MMCI_CMDRDY_SIZE			1
+#define MMCI_RXRDY_OFFSET			1
+#define MMCI_RXRDY_SIZE				1
+#define MMCI_TXRDY_OFFSET			2
+#define MMCI_TXRDY_SIZE				1
+#define MMCI_BLKE_OFFSET			3
+#define MMCI_BLKE_SIZE				1
+#define MMCI_DTIP_OFFSET			4
+#define MMCI_DTIP_SIZE				1
+#define MMCI_NOTBUSY_OFFSET			5
+#define MMCI_NOTBUSY_SIZE			1
+#define MMCI_ENDRX_OFFSET			6
+#define MMCI_ENDRX_SIZE				1
+#define MMCI_ENDTX_OFFSET			7
+#define MMCI_ENDTX_SIZE				1
+#define MMCI_RXBUFF_OFFSET			14
+#define MMCI_RXBUFF_SIZE			1
+#define MMCI_TXBUFE_OFFSET			15
+#define MMCI_TXBUFE_SIZE			1
+#define MMCI_RINDE_OFFSET			16
+#define MMCI_RINDE_SIZE				1
+#define MMCI_RDIRE_OFFSET			17
+#define MMCI_RDIRE_SIZE				1
+#define MMCI_RCRCE_OFFSET			18
+#define MMCI_RCRCE_SIZE				1
+#define MMCI_RENDE_OFFSET			19
+#define MMCI_RENDE_SIZE				1
+#define MMCI_RTOE_OFFSET			20
+#define MMCI_RTOE_SIZE				1
+#define MMCI_DCRCE_OFFSET			21
+#define MMCI_DCRCE_SIZE				1
+#define MMCI_DTOE_OFFSET			22
+#define MMCI_DTOE_SIZE				1
+#define MMCI_OVRE_OFFSET			30
+#define MMCI_OVRE_SIZE				1
+#define MMCI_UNRE_OFFSET			31
+#define MMCI_UNRE_SIZE				1
+
+/* Constants for DTOMUL */
+#define MMCI_DTOMUL_1_CYCLE			0
+#define MMCI_DTOMUL_16_CYCLES			1
+#define MMCI_DTOMUL_128_CYCLES			2
+#define MMCI_DTOMUL_256_CYCLES			3
+#define MMCI_DTOMUL_1024_CYCLES			4
+#define MMCI_DTOMUL_4096_CYCLES			5
+#define MMCI_DTOMUL_65536_CYCLES		6
+#define MMCI_DTOMUL_1048576_CYCLES		7
+
+/* Constants for RSPTYP */
+#define MMCI_RSPTYP_NO_RESP			0
+#define MMCI_RSPTYP_48_BIT_RESP			1
+#define MMCI_RSPTYP_136_BIT_RESP		2
+
+/* Constants for SPCMD */
+#define MMCI_SPCMD_NO_SPEC_CMD			0
+#define MMCI_SPCMD_INIT_CMD			1
+#define MMCI_SPCMD_SYNC_CMD			2
+#define MMCI_SPCMD_INT_CMD			4
+#define MMCI_SPCMD_INT_RESP			5
+
+/* Constants for TRCMD */
+#define MMCI_TRCMD_NO_TRANS			0
+#define MMCI_TRCMD_START_TRANS			1
+#define MMCI_TRCMD_STOP_TRANS			2
+
+/* Constants for TRTYP */
+#define MMCI_TRTYP_BLOCK			0
+#define MMCI_TRTYP_MULTI_BLOCK			1
+#define MMCI_TRTYP_STREAM			2
+
+/* Bit manipulation macros */
+#define MMCI_BIT(name)					\
+	(1 << MMCI_##name##_OFFSET)
+#define MMCI_BF(name,value)				\
+	(((value) & ((1 << MMCI_##name##_SIZE) - 1))	\
+	 << MMCI_##name##_OFFSET)
+#define MMCI_BFEXT(name,value)				\
+	(((value) >> MMCI_##name##_OFFSET)\
+	 & ((1 << MMCI_##name##_SIZE) - 1))
+#define MMCI_BFINS(name,value,old)			\
+	(((old) & ~(((1 << MMCI_##name##_SIZE) - 1)	\
+		    << MMCI_##name##_OFFSET))		\
+	 | MMCI_BF(name,value))
+
+/* Register access macros */
+#define mmci_readl(reg)					\
+	readl((void *)MMCI_BASE + MMCI_##reg)
+#define mmci_writel(reg,value)				\
+	writel((value), (void *)MMCI_BASE + MMCI_##reg)
+	
+#endif /* __CPU_AT32AP_ATMEL_MCI_H__ */
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/config.mk
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/config.mk
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/config.mk	2007-08-21
17:06:35.000000000 +0200
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/config.mk
2007-08-16 13:34:14.000000000 +0200
@@ -19,10 +19,10 @@
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
-#
+#PLATFORM_RELFLAGS += $(call cc-option,-msoft-float,)
 
 PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8
-PLATFORM_RELFLAGS += $(call cc-option,-msoft-float,)
+PLATFORM_RELFLAGS += $(call cc-option,)
 
 PLATFORM_CPPFLAGS += -march=armv5te
 PLATFORM_CPPFLAGS += $(call cc-option,-mtune=arm926ejs,)
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/Makefile
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/Makefile
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/Makefile	2007-08-21
17:06:36.000000000 +0200
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/Makefile	2007-08-23
09:14:21.000000000 +0200
@@ -26,8 +26,8 @@
 LIB	= lib$(SOC).a
 
 
-OBJS	= serial.o interrupts.o usb_ohci.o lcd.o ether.o spi.o
-SOBJS   = 
+OBJS	= serial.o interrupts.o usb_ohci.o ether.o spi.o
+SOBJS   = atmel_mci.o
 
 all:	.depend $(LIB)
 
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/spi.c
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/spi.c
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/spi.c	2007-08-21
17:06:35.000000000 +0200
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/spi.c	2007-08-23
10:36:47.000000000 +0200
@@ -184,6 +184,20 @@
 {
   unsigned int timeout;
   
+#ifdef CONFIG_AT91SAM9260EK
+  /* Configure PIO controllers to periph mode */
+  AT91F_PIO_CfgPeriph(AT91C_BASE_PIOA, // PIO controller base address
+		      ((unsigned int) AT91C_PA1_SPI0_MOSI) |
+		      ((unsigned int) AT91C_PA3_SPI0_NPCS0) |
+		      ((unsigned int) AT91C_PA0_SPI0_MISO) |
+		      ((unsigned int) AT91C_PA2_SPI0_SPCK), /*
Peripheral A */
+		      0); /* Peripheral B */
+  /* Configure PIO controllers to periph mode */
+  AT91F_PIO_CfgPeriph(AT91C_BASE_PIOC, /* PIO controller base address
*/
+		      0, /* Peripheral A */
+		      ((unsigned int) AT91C_PC11_SPI0_NPCS1)); /*
Peripheral B */
+#endif
+  
   pDesc->state = BUSY;
   
   /* Disable PDC TX and RX channels */
diff -burN u-boot-1.1.5/cpu/arm926ejs/config.mk
u-boot-1.1.5.klk/cpu/arm926ejs/config.mk
--- u-boot-1.1.5/cpu/arm926ejs/config.mk	2006-10-20
17:54:33.000000000 +0200
+++ u-boot-1.1.5.klk/cpu/arm926ejs/config.mk	2007-08-16
13:34:42.000000000 +0200
@@ -20,10 +20,10 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-	-msoft-float
-
+#
+#PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
+#	-msoft-float
+PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8
 PLATFORM_CPPFLAGS += -march=armv4
 #
========================================================================
=
 #
diff -burN u-boot-1.1.5/disk/part.c u-boot-1.1.5.klk/disk/part.c
--- u-boot-1.1.5/disk/part.c	2006-10-20 17:54:33.000000000 +0200
+++ u-boot-1.1.5.klk/disk/part.c	2007-08-23 08:29:56.000000000
+0200
@@ -36,6 +36,7 @@
 #if ((CONFIG_COMMANDS & CFG_CMD_IDE)	|| \
      (CONFIG_COMMANDS & CFG_CMD_SCSI)	|| \
      (CONFIG_COMMANDS & CFG_CMD_USB)	|| \
+	 (CONFIG_COMMANDS & CFG_CMD_MMC)	|| \
      defined(CONFIG_MMC) || \
      defined(CONFIG_SYSTEMACE) )
 
@@ -126,6 +127,8 @@
 #if ((CONFIG_COMMANDS & CFG_CMD_IDE)	|| \
      (CONFIG_COMMANDS & CFG_CMD_SCSI)	|| \
      (CONFIG_COMMANDS & CFG_CMD_USB)	|| \
+	 (CONFIG_COMMANDS & CFG_CMD_MMC)	|| \
+     defined(CONFIG_MMC) || \
      defined(CONFIG_SYSTEMACE)          )
 
 #if defined(CONFIG_MAC_PARTITION) || \
diff -burN u-boot-1.1.5/include/asm-arm/arch-at91sam926x/mmc.h
u-boot-1.1.5.klk/include/asm-arm/arch-at91sam926x/mmc.h
--- u-boot-1.1.5/include/asm-arm/arch-at91sam926x/mmc.h	1970-01-01
01:00:00.000000000 +0100
+++ u-boot-1.1.5.klk/include/asm-arm/arch-at91sam926x/mmc.h
2007-08-17 10:44:42.000000000 +0200
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2004-2006 Atmel Corporation
+ *
+ * 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
+ */
+#ifndef __ASM_AVR32_MMC_H
+#define __ASM_AVR32_MMC_H
+
+struct mmc_cid {
+	unsigned long psn;
+	unsigned short oid;
+	unsigned char mid;
+	unsigned char prv;
+	unsigned char mdt;
+	char pnm[7];
+};
+
+struct mmc_csd
+{
+	u8	csd_structure:2,
+		spec_vers:4,
+		rsvd1:2;
+	u8	taac;
+	u8	nsac;
+	u8	tran_speed;
+	u16	ccc:12,
+		read_bl_len:4;
+	u64	read_bl_partial:1,
+		write_blk_misalign:1,
+		read_blk_misalign:1,
+		dsr_imp:1,
+		rsvd2:2,
+		c_size:12,
+		vdd_r_curr_min:3,
+		vdd_r_curr_max:3,
+		vdd_w_curr_min:3,
+		vdd_w_curr_max:3,
+		c_size_mult:3,
+		sector_size:5,
+		erase_grp_size:5,
+		wp_grp_size:5,
+		wp_grp_enable:1,
+		default_ecc:2,
+		r2w_factor:3,
+		write_bl_len:4,
+		write_bl_partial:1,
+		rsvd3:5;
+	u8	file_format_grp:1,
+		copy:1,
+		perm_write_protect:1,
+		tmp_write_protect:1,
+		file_format:2,
+		ecc:2;
+	u8	crc:7;
+	u8	one:1;
+};
+
+/* MMC Command numbers */
+#define MMC_CMD_GO_IDLE_STATE		0
+#define MMC_CMD_SEND_OP_COND		1
+#define MMC_CMD_ALL_SEND_CID 		2
+#define MMC_CMD_SET_RELATIVE_ADDR	3
+#define MMC_CMD_SD_SEND_RELATIVE_ADDR	3
+#define MMC_CMD_SET_DSR			4
+#define MMC_CMD_SELECT_CARD		7
+#define MMC_CMD_SEND_CSD 		9
+#define MMC_CMD_SEND_CID 		10
+#define MMC_CMD_SEND_STATUS		13
+#define MMC_CMD_SET_BLOCKLEN		16
+#define MMC_CMD_READ_SINGLE_BLOCK	17
+#define MMC_CMD_READ_MULTIPLE_BLOCK	18
+#define MMC_CMD_WRITE_BLOCK		24
+#define MMC_CMD_APP_CMD			55
+
+#define MMC_ACMD_SD_SEND_OP_COND	41
+
+#define R1_ILLEGAL_COMMAND		(1 << 22)
+#define R1_APP_CMD			(1 << 5)
+
+#endif /* __ASM_AVR32_MMC_H */
diff -burN u-boot-1.1.5/include/configs/at91sam9260ek.h
u-boot-1.1.5.klk/include/configs/at91sam9260ek.h
--- u-boot-1.1.5/include/configs/at91sam9260ek.h	2007-08-21
17:06:36.000000000 +0200
+++ u-boot-1.1.5.klk/include/configs/at91sam9260ek.h	2007-08-23
10:51:43.000000000 +0200
@@ -88,6 +88,8 @@
                         CFG_CMD_FLASH | \
 			CFG_CMD_AUTOSCRIPT | \
                         CFG_CMD_NAND | \
+						CFG_CMD_MMC | \
+						CFG_CMD_EXT2 | \
                         CFG_CMD_FAT ) & \
 		      ~(CFG_CMD_BDI | \
 			CFG_CMD_IMLS | \
@@ -225,6 +227,7 @@
 #undef  CFG_ENV_IS_IN_FLASH
 #define	CFG_ENV_IS_IN_DATAFLASH         1
 #undef CFG_ENV_IS_IN_NAND              
+#undef CFG_ENV_IS_NOWHERE
 
 /*#define CONFIG_MTD_DEBUG		1
 #define CONFIG_MTD_DEBUG_VERBOSE	MTD_DEBUG_LEVEL3
@@ -241,6 +244,10 @@
 #define CFG_ENV_SIZE			0x4000  /* 0x8000 */
 #endif
 
+#ifdef CFG_ENV_IS_NOWHERE
+#define CFG_ENV_SIZE			0x4000
+#endif
+
 #ifdef CFG_ENV_IS_IN_FLASH
 #ifdef CONFIG_BOOTBINFUNC
 #define CFG_ENV_ADDR			(PHYS_FLASH_1 + 0x60000)  /*
after u-boot.bin */
@@ -257,6 +264,10 @@
 #define CONFIG_DOS_PARTITION	        1
 #define LITTLEENDIAN 			1
 
+/* MMC */
+#define CONFIG_MMC		1
+#define MMCI_BASE		0xFFFA8000
+
 #define CFG_LOAD_ADDR		0x23f00000  /* default load address */
 
 #ifdef CONFIG_BOOTBINFUNC



From avinashs36 at yahoo.com  Wed Apr 23 23:13:25 2008
From: avinashs36 at yahoo.com (Avinash Vijayvergia)
Date: Wed, 23 Apr 2008 14:13:25 -0700 (PDT)
Subject: [U-Boot-Users] how to make a standalone linux device
Message-ID: <508268.95016.qm@web39506.mail.mud.yahoo.com>

Hi

I am working on AT91SAM9260EK eval board from atmel. I have been using uboot to load an NFS root file system on a Linux server. I need to load the linux kernel to the dataflash to make it standalone product. Can someone help me with the "how to" for it? 

Thanks
Avinash




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080423/b74b5b1e/attachment.htm 

From andrewm at isoar.ca  Wed Apr 23 23:45:48 2008
From: andrewm at isoar.ca (Andrew E. Mileski)
Date: Wed, 23 Apr 2008 17:45:48 -0400
Subject: [U-Boot-Users] ppc440: EBC 32-bit bus width setting
Message-ID: <480FAE0C.7040407@isoar.ca>

This affects EBC_BXCR_BW_32BIT defined in include/ppc440.h

According to the AMCC 440EPx User Manual (v1.14), pg 591, figure 22-18,
BW (bits 17:18) should be 10 for a 32-bit bus width.  This is also
repeated for the NAND controller, section 23.4.5 on pg 600.

According to the IBM 440GX User's Manual (November 21, 2003), pg 1037,
figure 30-23, BW (bits 17:18) should be 11.  A rather old manual.

Can others help confirm the settings for these processors and other 440
family members.

Thanks.

-- 
Andrew E. Mileski



From galak at kernel.crashing.org  Wed Apr 23 23:58:04 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 23 Apr 2008 16:58:04 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] fsl_pci: Only modify registers if we have
	them
Message-ID: <Pine.LNX.4.64.0804231657230.13544@blarg.am.freescale.net>

pme_msg_det exists only on PCIe controllers only set it if we are a "bridge".

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

A fix for 1.3.3.

 drivers/pci/fsl_pci_init.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index 68e45e1..7dc33be 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -182,7 +182,8 @@ fsl_pci_init(struct pci_controller *hose)

 	/* Clear all error indications */

-	pci->pme_msg_det = 0xffffffff;
+	if (bridge)
+		pci->pme_msg_det = 0xffffffff;
 	pci->pedr = 0xffffffff;

 	pci_hose_read_config_word (hose, dev, PCI_DSR, &temp16);
-- 
1.5.4.1




From afleming at gmail.com  Thu Apr 24 00:35:08 2008
From: afleming at gmail.com (Andy Fleming)
Date: Wed, 23 Apr 2008 17:35:08 -0500
Subject: [U-Boot-Users] [PATCH] fsl_pci: Only modify registers if we
	have them
In-Reply-To: <Pine.LNX.4.64.0804231657230.13544@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804231657230.13544@blarg.am.freescale.net>
Message-ID: <2acbd3e40804231535p5373845g8b0ed063713883fe@mail.gmail.com>

On Wed, Apr 23, 2008 at 4:58 PM, Kumar Gala <galak at kernel.crashing.org> wrote:
> pme_msg_det exists only on PCIe controllers only set it if we are a "bridge".
>
>  Signed-off-by: Kumar Gala <galak at kernel.crashing.org>

Acked-by: Andy Fleming <afleming at freescale.com>

Though it'd be nice if you at least put a semicolon between
"controllers" and "only".  ;)



From ebretlif_1959 at InsuranceServiceofSarasota.com  Thu Apr 24 00:53:30 2008
From: ebretlif_1959 at InsuranceServiceofSarasota.com (Gay)
Date: Thu, 24 Apr 2008 01:53:30 +0300
Subject: [U-Boot-Users] A better orgasm awaits your right here
Message-ID: <1B9EC26A.1%ebretlif_1959@InsuranceServiceofSarasota.com>

You deserve only the best, get your brand new pecker here now http://www.naoigig.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080424/b92f7586/attachment.htm 

From Ken.Fuchs at bench.com  Thu Apr 24 01:32:53 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 23 Apr 2008 18:32:53 -0500
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
Message-ID: <AA28F077645B324881335614E4F7C428034CDD@win-ex01.bench.com>

Michael,

I copied all files in fs/fat from git repository u-boot-at91.  Made trivial changes to compile it with my code base.  Added your latest get_vfatname patch, but it had no effect on the issue.  fatls still
doesn't list filenames in some FAT32 filesystems, including the one
built via the Linux script I provided earlier in this thread.

Thus, there's no point in looking at the fat.c file I sent earlier
today.  The problem remains in the git fat.c code or possibly in
the USB stack code.  However, FAT16 has never failed, so the issue
is more likely to be with the FAT32 or vfat code. 

Sincerely,

Ken Fuchs

-----Original Message-----
From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Ken.Fuchs at bench.com
Sent: Wednesday, April 23, 2008 13:01
To: trimarchi at gandalf.sssup.it
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname


Michael,

Sorry, your latest get_vfatname patch doesn't work either.

FAT16 works perfectly, so the USB code is probably _not_ at fault.  I see only problems with FAT32, but only for _some_ long collections of files.

Thus, there may still be a problem with fs/fat/fat.c.  Maybe there is something wrong with my copy of fat.c  I attached it;  Perhaps you can see a problem with it.

Sincerely,

Ken Fuchs

> -----Original Message-----
> From: michael [mailto:trimarchi at gandalf.sssup.it] 
> Sent: Wednesday, April 23, 2008 06:16
> To: michael
> Cc: Fuchs, Ken; u-boot-users at lists.sourceforge.net; Wolfgang Denk
> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> 
> 
> Hi,
> 
> michael wrote:
> > Hi,
> >
> > Can you try this one?
> >
> > Revert my last one patch?
> > It change the test code, before the while. I use your script on a 
> > Compact Flash and it looks fine for me (under linux).
> >
> > Regards Michael
> >
> > 
> --------------------------------------------------------------
> ----------
> >
> > Check if the entry is a valid dir_slot entry, otherwise it 
> is a dentry and the
> > name has to be taken by the get_name function
> >
> > Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>
> >
> > ---
> >  fs/fat/fat.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> > index 49c78ed..bc37cec 100644
> > --- a/fs/fat/fat.c
> > +++ b/fs/fat/fat.c
> > @@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int 
> curclust, __u8 *cluster,
> >  		while (slotptr2->id > 0x01) {
> >  			slotptr2++;
> >  		}
> > +
> >  		/* Save the real directory entry */
> >  		realdent = (dir_entry*)slotptr2 + 1;
> > +		if (slotptr2->attr != ATTR_VFAT) {
> > +			get_name ((dir_entry *)realdent, l_name);
> > +			goto out;
> > +		}
> > +
> >  		while ((__u8*)slotptr2 >= get_vfatname_block) {
> >  			slot2str(slotptr2, l_name, &idx);
> >  			slotptr2--;
> > @@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int 
> curclust, __u8 *cluster,
> >  	else if (*l_name == aRING) *l_name = '?';
> >  	downcase(l_name);
> >  
> > +out:
> >  	/* Return the real directory entry */
> >  	memcpy(retdent, realdent, sizeof(dir_entry));
> >  
> >   
> The scripts in this thread can be used to test the fat32 
> filesystem. I 
> do some tests using Compact Flash
> device and this patchs work for me. I would like to know if is a fat 
> layer problem or usb layer problem.
> 
> Michael
> 
> 



From pmeloy at shaw.ca  Thu Apr 24 01:58:46 2008
From: pmeloy at shaw.ca (p)
Date: Wed, 23 Apr 2008 16:58:46 -0700
Subject: [U-Boot-Users] How to set CPU speed to 266mhz s3c2410?
In-Reply-To: <1208826572.19513.6.camel@rhodan.rho>
References: <20080420222237.4AE5324657@gemini.denx.de>
	<1208779508.5965.371.camel@sauron>
	<Pine.LNX.4.64.0804211533140.27984@lnxricardw.se.axis.com>
	<1208785463.6654.34.camel@vader.jdub.homelinux.org>
	<1208826572.19513.6.camel@rhodan.rho>
Message-ID: <1208995126.3322.1.camel@rhodan.rho>

Thanks very much for the responses. Once it was pointed out to me that
the CPU speed settings are in the board file I actually remembered
seeing them there before. Don't know why I got fixated on that speed.c.

I'm now zipping along at 266 mhz!


On Mon, 2008-04-21 at 18:09 -0700, p wrote:
> Sorry for the newb question but I've been googling like mad and can't
> find any clues (or more likely, can't understand what I do find).
> 
> I'm looking at speed.c under /cpu/arm920t/s3c24xx and thinking this is
> the business end




From j.holzman at genesysdesign.com.au  Thu Apr 24 03:06:44 2008
From: j.holzman at genesysdesign.com.au (Jared Holzman)
Date: Thu, 24 Apr 2008 11:06:44 +1000
Subject: [U-Boot-Users] TFTP block size is too high
Message-ID: <480FDD24.9090909@genesysdesign.com.au>

An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080424/a53244f4/attachment.htm 

From jwboyer at linux.vnet.ibm.com  Thu Apr 24 03:10:27 2008
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Wed, 23 Apr 2008 20:10:27 -0500
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
In-Reply-To: <200804231449.24746.sr@denx.de>
References: <480EADF4.2020706@verizon.net>  <200804231449.24746.sr@denx.de>
Message-ID: <1208999427.2946.8.camel@vader.jdub.homelinux.org>

On Wed, 2008-04-23 at 14:49 +0200, Stefan Roese wrote:
> On Wednesday 23 April 2008, Dave Littell wrote:
> > At this point all possibilities are on the table and I'm looking for any
> > input from anyone with experience (good, bad, or whatever) with this
> > processor and/or designs similar to the Sequoia.
> 
> If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will 
> most likely find some references.
> 
> Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the 
> 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this 
> changes your behavior.

Explain this a bit more please?  Is a kernel change needed here?

josh




From lrj at acm.org  Thu Apr 24 03:11:30 2008
From: lrj at acm.org (Larry Johnson)
Date: Wed, 23 Apr 2008 21:11:30 -0400
Subject: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
In-Reply-To: <200804231512.03751.sr@denx.de>
References: <480E34A6.6010509@acm.org>
	<fa686aa40804221218r3cef9c8bi38ba04438922fe2f@mail.gmail.com>
	<200804231512.03751.sr@denx.de>
Message-ID: <480FDE42.6040302@acm.org>

Stefan Roese wrote:
> Hi Larry,
> 
> On Tuesday 22 April 2008, Grant Likely wrote:
>>> Currently, I can build "zImage" for Sequoia using the powerpc
>>> architecture, and load it using U-Boot without a separate FDT binary.
>>> Is this the best way to run a Linux from the powerpc tree?
>> Sorry, I don't understand what you're asking.
>>
>> There are two way to boot a Linux image from arch/powerpc.
>>
>> 1) build a uImage and get u-boot to pass a device tree blob (if your u-boot
>> had device tree support)
>> 2) build a cuImage which wraps the device tree in the kernel image.
> 
> Correct. Personally I prefer 1), since it makes the Linux ports easier. No 
> bootwrapper is needed in this case. And all the "infrastructure" for fdt 
> enabled U-Boot images for 4xx is available. Please take a look at 
> sequoia.c/.h and search for CONFIG_OF_LIBFDT.
> 
> Just let me know if this is not clear or if you have additional questions.
> 
> Best regards,
> Stefan
> 
> =====================================================================
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
> =====================================================================

Thanks Stefan, Grant, and Wolfgang for your comments.  Method 2 is
working for me, as it turns out that files "cuImage.sequoia and "zImage"
are identical.

I'd prefer to use method one.  Here's an abbreviated listing of what I
get when I try.

<listing>
=> tftp 200000 sequoia/uImage
[...]
Bytes transferred = 1497002 (16d7aa hex)
=> tftp 1000000 sequoia/sequoia.dtb
[...]Bytes transferred = 6659 (1a03 hex)
=> run ramargs addmtd addip addide addtty; bootm 200000 ${ramdisk_addr} 1000000
## Booting kernel from Legacy Image at 00200000 ...
   Image Name:   Linux-2.6.25-rc8-01262-g80afde7
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1496938 Bytes =  1.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x1000000
## Loading init Ramdisk from Legacy Image at fc400000 ...
   Image Name:   sequoia Ramdisk Rev 006
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    19409859 Bytes = 18.5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Device Tree to 007fe000, end 007ffa02 ... OK
fdt_chosen: FDT_ERR_NOSPACE
ERROR: /chosen node create failed - must RESET the board to recover.

U-Boot 1.3.2-00497-g58c5376 (Apr 23 2008 - 16:24:13)
[...]
</listing>

The file "sequoia.dtb was created by 

$dtc dts/sequoia.dts -O dtb -o sequoia.dtb

Can anyone tell me what went wrong?

Best regards,
Larry




From littelld at verizon.net  Thu Apr 24 04:17:32 2008
From: littelld at verizon.net (Dave Littell)
Date: Wed, 23 Apr 2008 21:17:32 -0500
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
In-Reply-To: <200804231449.24746.sr@denx.de>
References: <480EADF4.2020706@verizon.net> <200804231449.24746.sr@denx.de>
Message-ID: <480FEDBC.2010401@verizon.net>

Stefan Roese wrote:
> On Wednesday 23 April 2008, Dave Littell wrote:
>> I'm working on an AMCC PPC440EPx-based platform that's similar to the
>> Sequoia.  The board runs pretty well, but occasionally takes exceptions
>> both in U-Boot and while running Linux.  The exceptions vary from
>> Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and
>> DTLB Errors, to DSI, etc., which made us believe there's a problem with
>> SDRAM.
> 
> Yes, this is my first idea too. Almost every time such "random" errors are 
> seen, SDRAM setup/initialization is the cause for it.
> 
>> Sometimes there are simple hard lockups from which even the JTAG 
>> can't regain control.  However, the SDRAM physical/electrical and DDR
>> Controller configurations have been investigated in detail (and some
>> corrections made) with no resulting improvement in the exception behavior.
> 
> Is the SDRAM termination similar to the one used on Sequoia too? Are you using 
> soldered chips and not DIMM modules? Is ECC available?
> 

Termination: very likely - they stayed very close to Sequoia, but I'll ask.

We're using soldered chips and there's no ECC.

>> We see problems primarily at 667 MHz but have noted some issues at 533
>> MHz as well.  Some boards seem particularly susceptible to this while
>> others rarely (if ever) exhibit the problem.
>>
>> At this point all possibilities are on the table and I'm looking for any
>> input from anyone with experience (good, bad, or whatever) with this
>> processor and/or designs similar to the Sequoia.
> 
> If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will 
> most likely find some references.
> 

Will do, thanks for the pointer.

> Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the 
> 440EPx CHIP 11 errata. I suggest you take a look at this too and see if this 
> changes your behavior.
> 

I remember this - PPC440EPx Revision A errata CHIP_11, right?


Thanks,
Dave



From grant.likely at secretlab.ca  Thu Apr 24 04:20:25 2008
From: grant.likely at secretlab.ca (Grant Likely)
Date: Wed, 23 Apr 2008 20:20:25 -0600
Subject: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
In-Reply-To: <480FDE42.6040302@acm.org>
References: <480E34A6.6010509@acm.org>
	<fa686aa40804221218r3cef9c8bi38ba04438922fe2f@mail.gmail.com>
	<200804231512.03751.sr@denx.de> <480FDE42.6040302@acm.org>
Message-ID: <fa686aa40804231920j4408ef4qbcb81efa05539a9b@mail.gmail.com>

On Wed, Apr 23, 2008 at 7:11 PM, Larry Johnson <lrj at acm.org> wrote:
>  Thanks Stefan, Grant, and Wolfgang for your comments.  Method 2 is
>  working for me, as it turns out that files "cuImage.sequoia and "zImage"
>  are identical.

That is because zImage is simply linked to the first target in the
image-y list (every target added to image-y is built when you do 'make
zImage')

>  fdt_chosen: FDT_ERR_NOSPACE
>  ERROR: /chosen node create failed - must RESET the board to recover.
>
>  U-Boot 1.3.2-00497-g58c5376 (Apr 23 2008 - 16:24:13)
>  [...]
>  </listing>
>
>  The file "sequoia.dtb was created by
>  $dtc dts/sequoia.dts -O dtb -o sequoia.dtb
>
>  Can anyone tell me what went wrong?

You're hitting a limitation of current u-boot.  It doesn't know how to
allocate more space in a device tree blob.  Try passing "-S 8192 -R
16" to dtc.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.



From littelld at verizon.net  Thu Apr 24 04:27:27 2008
From: littelld at verizon.net (Dave Littell)
Date: Wed, 23 Apr 2008 21:27:27 -0500
Subject: [U-Boot-Users] PPC440EPx/sequoia TLB question...
In-Reply-To: <200804231442.29687.sr@denx.de>
References: <480EA8E1.4060207@verizon.net> <200804231442.29687.sr@denx.de>
Message-ID: <480FF00F.4080900@verizon.net>

Stefan Roese wrote:
> On Wednesday 23 April 2008, Dave Littell wrote:
>> >From ?/board/amcc/sequoia/init.S:
>>
>> /* TLB-entry for Internal Registers & OCM */
>> tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0, AC_R|AC_W|AC_X|SA_I )
>>
>> Why is this memory region not marked Guarded?  It would seem to meet the
>> definition of ?non-well-behaved?.
> 
> Why do you think this is the case?
> 

Hi again, Stefan!

Well, there's registers in that address space, not unlike other
registers in other TLB entries (PCI, BCSR, etc.) that are marked
Guarded.  I would think the same rationale would apply to the internal
registers.

I need to go back and check the register settings for speculative
accesses.  I seem to remember that there's a 440EPx Errata (actually,
more than one) that has a workaround that turns off speculative
instruction fetches.  Data speculative accesses may have gotten squashed
in there as well, so it wouldn't matter what the TLB said if that's the
case.

>> Also the TLB entry for SDRAM marks it Guarded, but that?s one area I
>> would think wouldn't need to be Guarded.
> 
> This could be a mistake. Should work without G bis set too. Please give it a 
> try and send a patch to fix it, if it works fine.
> 

Hard to define "works fine" - this is the same 440EPx platform I'm
asking about over in the embedded Linux mailing list.  I'm pretty sure
the kernel doesn't flag SDRAM as Guarded, but I'll give it a try to see
how it goes.


Thanks,
Dave



From mshiokawa at miraclelinux.com  Thu Apr 24 04:53:48 2008
From: mshiokawa at miraclelinux.com (Makito SHIOKAWA)
Date: Thu, 24 Apr 2008 11:53:48 +0900
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
Message-ID: <480FF63C.2030407@miraclelinux.com>

Boot Image Fallback is a mechanism that enables a system to fallback to a
"known good" boot image in the event of catastrophic boot failure (i.e.
failure to boot, panic on boot, failure to initialize HW/SW). (CGL
Availability Requirements Definition V4.0: AVL.9.0). On system especially used
in telecommunication, 99.999% high availability is required. So, this function
is highly needed (like my customer requires).

This time, I'm thinking of implementing Boot Image Fallback on U-Boot as
follows (like a way GRUB does). So, I would appreciate any comments to this.


It uses new U-Boot command "bootmf" and fw_setenv.

* bootmf

It is a wrapper of "bootm", and it boots kernel with fallback enabled on
multiple kernel images.


Also, it uses new U-Boot environment variables as follows.

* imgaddr<N>

It holds physical address of flash partition that kernel image is written. <N>
is integer and becomes an entry of corresponding kernel image.

(ex.) imgaddr0=0xf8000000, imgaddr1=0xf8200000

* bootargs<N>

It holds kernel parameter of entry <N>.

(ex.) bootargs0=root=/dev/mtdblock1 , bootargs1=root=/dev/mtdblock3

* default

It holds default entry that "bootmf" tries to boot on default.

(ex.) default=1

* fallback

It holds list of fallback entry that "bootmf" tries to boot on next if it
fails to boot default entry.

(ex.) fallback=1 2


Now, I assume that circumstances are as follows. (In my case, Linux on
Freescale MPC8540.)

* There are three flash partitions "kernel-0", "kernel-1", "kernel-2" that
kernel images are written.

* Environment variables are set as follows.

bootcmd=bootmf
imgaddr0=0xf8000000 (physical address of "kernel-0")
imgaddr1=0xf8200000 (physical address of "kernel-1")
imgaddr2=0xf8400000 (physical address of "kernel-2")
bootargs0=root=/dev/mtdblock1 (rootfs of "kernel-0")
bootargs1=root=/dev/mtdblock3 (rootfs of "kernel-1")
bootargs2=root=/dev/mtdblock5 (rootfs of "kernel-2")
default=0
fallback=1 2

* "fw_setenv default 0" is written to /etc/rc.local.


Then it behaves as follows.

1. When U-Boot boots up, "bootmf" is executed and tries to boot default entry
in "default". Before booting kernel, "bootmf" sets corresponding fallback
entry in "fallback" to "default". ((ex.) When booting entry "0", "1" is set
and when booting entry "1", "2" is set.)

2. If kernel succeeds to boot, "default" is set to "0" by fw_setenv. So, next
time U-Boot boots up and "bootmf" is executed, entry "0" will be booted again.

3. If kernel fails to boot, "default" stays to fallback entry "1" because
fw_setenv won't be executed. So, next time U-Boot boots and "bootmf" is
executed, fallback entry "1" will be booted.


By this way, Boot Image Fallback on U-Boot can be realized. I recognize that
this needs to rewrite flash each time booting a kernel, but I think there
won't be so many reboots once stable system operation have started.

I'll write and send a prototype of "bootmf" if it is needed.


Best regards,

-- 
MIRACLE LINUX CORPORATION
Makito SHIOKAWA



From sr at denx.de  Thu Apr 24 06:31:45 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 06:31:45 +0200
Subject: [U-Boot-Users] Running Linux from ARCH=powerpc on Sequoia board
In-Reply-To: <fa686aa40804231920j4408ef4qbcb81efa05539a9b@mail.gmail.com>
References: <480E34A6.6010509@acm.org> <480FDE42.6040302@acm.org>
	<fa686aa40804231920j4408ef4qbcb81efa05539a9b@mail.gmail.com>
Message-ID: <200804240631.45463.sr@denx.de>

On Thursday 24 April 2008, Grant Likely wrote:
> >  fdt_chosen: FDT_ERR_NOSPACE
> >  ERROR: /chosen node create failed - must RESET the board to recover.
> >
> >  U-Boot 1.3.2-00497-g58c5376 (Apr 23 2008 - 16:24:13)
> >  [...]
> >  </listing>
> >
> >  The file "sequoia.dtb was created by
> >  $dtc dts/sequoia.dts -O dtb -o sequoia.dtb
> >
> >  Can anyone tell me what went wrong?
>
> You're hitting a limitation of current u-boot.  It doesn't know how to
> allocate more space in a device tree blob.  Try passing "-S 8192 -R
> 16" to dtc.

And don't forget "-b 0" for the boot CPU number.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Thu Apr 24 06:36:12 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 06:36:12 +0200
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
In-Reply-To: <1208999427.2946.8.camel@vader.jdub.homelinux.org>
References: <480EADF4.2020706@verizon.net> <200804231449.24746.sr@denx.de>
	<1208999427.2946.8.camel@vader.jdub.homelinux.org>
Message-ID: <200804240636.12349.sr@denx.de>

On Thursday 24 April 2008, Josh Boyer wrote:
> > Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the
> > 440EPx CHIP 11 errata. I suggest you take a look at this too and see if
> > this changes your behavior.
>
> Explain this a bit more please?  Is a kernel change needed here?

This depends. When the bootwrapper version is used then yes, the kernel should 
get changed. This is because the bootwrapper detects the SDRAM size from the 
DDR2 controller and passes it to Linux.

Without bootwrapper no changes are needed, since U-Boot already passes the 
corrected memory size to Linux (totalsize-4k currently).

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From matthias.fuchs at esd-electronics.com  Thu Apr 24 07:00:36 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Thu, 24 Apr 2008 07:00:36 +0200
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
In-Reply-To: <480FF63C.2030407@miraclelinux.com>
References: <480FF63C.2030407@miraclelinux.com>
Message-ID: <200804240700.36826.matthias.fuchs@esd-electronics.com>

Hi, 

take a look at Wolfgang's last posting from Tuesday on the 'intended behavior 
of bootm'. The bootlimit/altbootcmd function (in your case probably together 
with a hardware watchdog) could be the stuff you are (and I was) looking for.

Matthias

On Thursday 24 April 2008 04:53:48 Makito SHIOKAWA wrote:
> Boot Image Fallback is a mechanism that enables a system to fallback to a
> "known good" boot image in the event of catastrophic boot failure (i.e.
> failure to boot, panic on boot, failure to initialize HW/SW). (CGL
> Availability Requirements Definition V4.0: AVL.9.0). On system especially
> used in telecommunication, 99.999% high availability is required. So, this
> function is highly needed (like my customer requires).
>
> This time, I'm thinking of implementing Boot Image Fallback on U-Boot as
> follows (like a way GRUB does). So, I would appreciate any comments to
> this.
>
>
> It uses new U-Boot command "bootmf" and fw_setenv.
>
> * bootmf
>
> It is a wrapper of "bootm", and it boots kernel with fallback enabled on
> multiple kernel images.
>
>
> Also, it uses new U-Boot environment variables as follows.
>
> * imgaddr<N>
>
> It holds physical address of flash partition that kernel image is written.
> <N> is integer and becomes an entry of corresponding kernel image.
>
> (ex.) imgaddr0=0xf8000000, imgaddr1=0xf8200000
>
> * bootargs<N>
>
> It holds kernel parameter of entry <N>.
>
> (ex.) bootargs0=root=/dev/mtdblock1 , bootargs1=root=/dev/mtdblock3
>
> * default
>
> It holds default entry that "bootmf" tries to boot on default.
>
> (ex.) default=1
>
> * fallback
>
> It holds list of fallback entry that "bootmf" tries to boot on next if it
> fails to boot default entry.
>
> (ex.) fallback=1 2
>
>
> Now, I assume that circumstances are as follows. (In my case, Linux on
> Freescale MPC8540.)
>
> * There are three flash partitions "kernel-0", "kernel-1", "kernel-2" that
> kernel images are written.
>
> * Environment variables are set as follows.
>
> bootcmd=bootmf
> imgaddr0=0xf8000000 (physical address of "kernel-0")
> imgaddr1=0xf8200000 (physical address of "kernel-1")
> imgaddr2=0xf8400000 (physical address of "kernel-2")
> bootargs0=root=/dev/mtdblock1 (rootfs of "kernel-0")
> bootargs1=root=/dev/mtdblock3 (rootfs of "kernel-1")
> bootargs2=root=/dev/mtdblock5 (rootfs of "kernel-2")
> default=0
> fallback=1 2
>
> * "fw_setenv default 0" is written to /etc/rc.local.
>
>
> Then it behaves as follows.
>
> 1. When U-Boot boots up, "bootmf" is executed and tries to boot default
> entry in "default". Before booting kernel, "bootmf" sets corresponding
> fallback entry in "fallback" to "default". ((ex.) When booting entry "0",
> "1" is set and when booting entry "1", "2" is set.)
>
> 2. If kernel succeeds to boot, "default" is set to "0" by fw_setenv. So,
> next time U-Boot boots up and "bootmf" is executed, entry "0" will be
> booted again.
>
> 3. If kernel fails to boot, "default" stays to fallback entry "1" because
> fw_setenv won't be executed. So, next time U-Boot boots and "bootmf" is
> executed, fallback entry "1" will be booted.
>
>
> By this way, Boot Image Fallback on U-Boot can be realized. I recognize
> that this needs to rewrite flash each time booting a kernel, but I think
> there won't be so many reboots once stable system operation have started.
>
> I'll write and send a prototype of "bootmf" if it is needed.
>
>
> Best regards,
-- 
-------------------------------------------------------------------------
Dipl.-Ing. Matthias Fuchs
Head of System Design

esd electronic system design gmbh
Vahrenwalder Str. 207 - 30165 Hannover - GERMANY
Phone: +49-511-37298-0 - Fax: +49-511-37298-68
Please visit our homepage http://www.esd.eu
Quality Products - Made in Germany
-------------------------------------------------------------------------
Gesch?ftsf?hrer: Klaus Detering, Dr. Werner Schulze
Amtsgericht Hannover HRB 51373 - VAT-ID DE 115672832
-------------------------------------------------------------------------



From sr at denx.de  Thu Apr 24 07:19:57 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 07:19:57 +0200
Subject: [U-Boot-Users] ppc440: EBC 32-bit bus width setting
In-Reply-To: <480FAE0C.7040407@isoar.ca>
References: <480FAE0C.7040407@isoar.ca>
Message-ID: <200804240719.57720.sr@denx.de>

On Wednesday 23 April 2008, Andrew E. Mileski wrote:
> This affects EBC_BXCR_BW_32BIT defined in include/ppc440.h
>
> According to the AMCC 440EPx User Manual (v1.14), pg 591, figure 22-18,
> BW (bits 17:18) should be 10 for a 32-bit bus width.  This is also
> repeated for the NAND controller, section 23.4.5 on pg 600.
>
> According to the IBM 440GX User's Manual (November 21, 2003), pg 1037,
> figure 30-23, BW (bits 17:18) should be 11.  A rather old manual.
>
> Can others help confirm the settings for these processors and other 440
> family members.

I suspect that both manuals are correct and the register bit setting are 
incompatible. Best would be if you send a patch to fix this in U-Boot. 
Something like:

#if defined(CONFIG_440GX)
#define EBC_BXCR_BW_32BIT               0x00006000
#else
#define EBC_BXCR_BW_32BIT               0x00004000
#endif

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From Narendra.KA at Lntemsys.com  Thu Apr 24 07:31:39 2008
From: Narendra.KA at Lntemsys.com (Narendra KA)
Date: Thu, 24 Apr 2008 11:01:39 +0530
Subject: [U-Boot-Users] Kernel hanging after lmb_end_of_DRAM() function.
In-Reply-To: <20080423162725.GA32077@ld0162-tx32.am.freescale.net>
Message-ID: <OFAEDD8FEB.E7FAE664-ON65257435.001E5053-65257435.001DCF9D@lntemsys.com>

   Thanks for the reply scott, :)

i forgot to mention , yes i am using device tree aware u-boot but the 
problem is when i tried to build the u-boot source ( first i did ""make 
ep8248_config"" and then ""make"") it was giving undefined reference 
related to ft_board_setup() function so i altered the U-boot-1.3.2 source 
code... i added the below code to the following file board/ep8248/ep8248.c

#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
void ft_board_setup(void *blob, bd_t *bd)
{
        ft_cpu_setup(blob, bd);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */


and also added the below lines to the file include/configs/ep8248.h by 
looking into the corresponding .dts file in the kernel source....


/* pass open firmware flat tree */
#define CONFIG_OF_LIBFDT        1
#define CONFIG_OF_BOARD_SETUP   1

#define OF_CPU  "PowerPC,8248 at 0"
#define OF_SOC  "soc at f0000000"
#define OF_TBCLK        (bd->bi_busfreq / 4)
#define OF_STDOUT_PATH  "/soc at f0000000/serial at 11a80"

Now afte doing the above 2 alterations i was able to build the 
u-boot-1.3.2 source for ep8248e....

then i created the uImage with the latest kernel source linux-2.6.25-rc8 
and put that uImage to the target...also i created the ep8248e.dtb from 
the dtc (DEVICE TREE COMPILER) and put that to the target and passed this 
as an argument to the bootm 
I also cross checked in the U-boot environment for the fdt command ... it 
was present
this is what i have done till now 
Finally when it hanged I started debugging using BDI2000...so it was stuck 
as i said in my previous post
and how to use cuImage.pq2 ? also i dint get what is dtbImage.ep8248e ? is 
that same to ep8248e.dtb ??
Can you Please tell me how can i proceed further to get the Kernel up on 
the ep8248e target ?? 

Regards,
Naren





Scott Wood <scottwood at freescale.com> 
04/23/2008 09:57 PM

To
gforgcc <narendra.ka at lntemsys.com>
cc
u-boot-users at lists.sourceforge.net
Subject
Re: [U-Boot-Users]  Kernel hanging after lmb_end_of_DRAM() function.






On Tue, Apr 22, 2008 at 09:12:11PM -0700, gforgcc wrote:
> i am trying to bring up the latest kernel on EP8248 target,
> i am using U-boot-1.3.2 and linux-2.6.25-rc8, i started debugging using
> BDI2000 which helped me to know atleast what is going wrong, i have 
added
> some printk's in the kernel source but still i am not able to find where 
and
> what exactly is going wrong, The first statement it is printing in the 
log
> buffer is 
> ""Using Embedded Planet EP8248E machine description"" and thats it the 
next
> message is 
> Unable to handle kernel paging request for data at address 0xbfff0000
> Faulting instruction address:0xc0012070 (This nearest address to this
> address in System.map file is cacheable_memzero)
> and tracing like this i came to know that in the file
> arch/powerpc/mm/ppc_mmu_32.c , here in the function __init MMU_init_hw() 
and
> in the line n_hpteg = total_memory / (PAGE_SIZE * 8); probably it is 
getting
> problem because when i tried to print the variable total_memory it is
> printing zero !!! :( :(  so probably i am thinking it is not able to 
find
> some memory for Hash table :(

Are you using a device-tree-aware u-boot with uImage, or are you using
cuImage.pq2?  Do not use dtbImage.ep8248e; that's for PlanetCore.

ep8248e in mainline u-boot doesn't appear to be device-tree aware.

If you're using cuImage.pq2, do you get any output from the bootwrapper? 
Make sure you add /chosen/linux,stdout-path.  There may be other device
tree changes you need to make it work with u-boot as well.

-Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080424/e0e518f0/attachment.htm 

From sr at denx.de  Thu Apr 24 07:28:43 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 07:28:43 +0200
Subject: [U-Boot-Users] PPC440EPx/sequoia TLB question...
In-Reply-To: <480FF00F.4080900@verizon.net>
References: <480EA8E1.4060207@verizon.net> <200804231442.29687.sr@denx.de>
	<480FF00F.4080900@verizon.net>
Message-ID: <200804240728.44082.sr@denx.de>

On Thursday 24 April 2008, Dave Littell wrote:
> Well, there's registers in that address space, not unlike other
> registers in other TLB entries (PCI, BCSR, etc.) that are marked
> Guarded.  I would think the same rationale would apply to the internal
> registers.

We should probably split this up in multiple TLB entries then. SRAM without G 
set and registers with G set.

> I need to go back and check the register settings for speculative
> accesses.  I seem to remember that there's a 440EPx Errata (actually,
> more than one) that has a workaround that turns off speculative
> instruction fetches.  Data speculative accesses may have gotten squashed
> in there as well, so it wouldn't matter what the TLB said if that's the
> case.
>
> >> Also the TLB entry for SDRAM marks it Guarded, but that?s one area I
> >> would think wouldn't need to be Guarded.
> >
> > This could be a mistake. Should work without G bis set too. Please give
> > it a try and send a patch to fix it, if it works fine.
>
> Hard to define "works fine" - this is the same 440EPx platform I'm
> asking about over in the embedded Linux mailing list.  I'm pretty sure
> the kernel doesn't flag SDRAM as Guarded,

Yes, and the 4xx code to dynamically set the SDRAM TLB's in the SPD code 
doesn't set it either. So it really isn't needed.

> but I'll give it a try to see 
> how it goes.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Thu Apr 24 07:51:42 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 07:51:42 +0200
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <480F6147.4060406@ovro.caltech.edu>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<20080423150448.GA8998@crust.elkhashab.com>
	<480F6147.4060406@ovro.caltech.edu>
Message-ID: <200804240751.42742.sr@denx.de>

On Wednesday 23 April 2008, David Hawkins wrote:
> Here's a few ideas then.
>
> 1) Use the main host to setup DDR on each of the targets,
>     copy a U-Boot image to each target, and then enable the
>     targets to boot from DDR.

I don't see how this could be done. The SDRAM has to be setup by the CPU 
itself and can't be setup via another PCI host.

>     The target U-Boot versions would have to skip all DDR
>     initialization, since they are running from DDR.
>
>     I believe this code would come under ...
>
> http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarte
>dInRAM
>
>     Which contains the warning:
>
>     'But it is difficult, unsupported, and fraught with peril.'
>
>     Wolfgang and Stephan could probably comment more on this.
>
> 2) Configure an inbound translation window on the host to point
>     a PCI window to its *flash*.
>
>     Configure the outbound translation windows on the targets to
>     point to the host inbound window.

This is probably only possible from the CPU itself too. And where should the 
code come from to do this?

>     Each target would then boot from the same flash as the host.
>     Assuming there was some I/O to distinguish the targets from the
>     host, the code could determine what to do at runtime.
>
>     This has the disadvantage that all boards are booting from
>     potentially slower flash memory, but that may not matter.
>
> 3) Configure the host DDR memory such that the OS does not use
>     all installed memory, eg. reserves enough memory for a U-Boot
>     image.
>
>     Setup the host inbound translation window to point to that
>     linear DDR region, and have the host copy the image there.
>
>     Setup the targets as in (2) and let them boot.
>
> The nice thing about (2) and (3) is that the target processors are
> effectively in the 'virgin' state that flash booting expects, so
> the modifications to U-Boot required to support the booting scheme
> would be minimal.

I don't think this is possible. To configure the translation windows, code is 
needed on all PPC's.

> 4) Another option would be to place SRAM on each of the other
>     processors, and copy the U-Boot image there. That way flash
>     on the targets is replaced with SRAM.
>
>     However, this would require a hardware change, and is not
>     much of an improvement.

SRAM or FLASH, no big difference here. The only advantage is that there is no 
need to update all target FLASH's.

Another idea would be to put only one NOR FLASH for all target PPC's on the 
board. Then you "release" (put out of reset) all target PPC's from the host 
PPC in a sequential order. This way there should be no problem sharing the 
NOR FLASH.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From hs at denx.de  Thu Apr 24 06:26:53 2008
From: hs at denx.de (Heiko Schocher)
Date: Thu, 24 Apr 2008 06:26:53 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Add the Harris QUAD100HD AMCC
 405EP-based board.
In-Reply-To: <mailman.115528.1208956369.5026.u-boot-users@lists.sourceforge.net>
References: <mailman.115528.1208956369.5026.u-boot-users@lists.sourceforge.net>
Message-ID: <48100C0D.708@denx.de>

Hello Gary,

Gary Jennejohn <garyj at denx.de> wrote:

>
> Add the Harris QUAD100HD AMCC 405EP-based board.
>
> Signed-off-by: Gary Jennejohn <garyj at denx.de>
> ---
>  MAINTAINERS                 |    4 +
>  MAKEALL                     |    1 +
>  Makefile                    |    3 +
>  board/quad100hd/Makefile    |   51 ++
>  board/quad100hd/config.mk   |   24 +
>  board/quad100hd/flash.c     | 1097 +++++++++++++++++++++++++++++++++++++++++++
>   

Do you really need a boardspecific flash driver? Are these flashes not
CFI compatible?

bye
Heiko

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany 




From plagnioj at jcrosoft.com  Thu Apr 24 07:43:14 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 24 Apr 2008 07:43:14 +0200
Subject: [U-Boot-Users] [PATCH 1/1] NE2000: Fix regresssion introduced by
	e710185aae90 on non AX88796
In-Reply-To: <1209015794-9805-1-git-send-email-plagnioj@jcrosoft.com>
References: <20080422100238.BDB04247AF@gemini.denx.de>
	<1209015794-9805-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1209015794-9805-2-git-send-email-plagnioj@jcrosoft.com>

Move non-inlied functions into specific drivers file
Set get_prom as weak

Coding Style Cleanup

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Signed-off-by: Vlad Lungu <vlad at comsys.ro>
---
 drivers/net/Makefile      |    5 +-
 drivers/net/ax88796.c     |  156 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/net/ax88796.h     |  134 --------------------------------------
 drivers/net/ne2000.c      |   94 ++++++++++++++++++++++++++-
 drivers/net/ne2000.h      |   87 +-------------------------
 drivers/net/ne2000_base.h |    1 -
 6 files changed, 252 insertions(+), 225 deletions(-)
 create mode 100644 drivers/net/ax88796.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d5e413b..4131aad 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -42,7 +42,10 @@ COBJS-y += lan91c96.o
 COBJS-y += macb.o
 COBJS-y += mcffec.o
 COBJS-y += natsemi.o
-COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o
+ifeq ($(CONFIG_DRIVER_NE2000),y)
+COBJS-y += ne2000.o
+COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o
+endif
 COBJS-y += netarm_eth.o
 COBJS-y += netconsole.o
 COBJS-y += ns7520_eth.o
diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
new file mode 100644
index 0000000..39cd101
--- /dev/null
+++ b/drivers/net/ax88796.c
@@ -0,0 +1,156 @@
+/*
+ * (c) 2007 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
+ *
+ * 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 <common.h>
+#include "ax88796.h"
+
+/*
+ * Set 1 bit data
+ */
+static void ax88796_bitset(u32 bit)
+{
+	/* DATA1 */
+	if( bit )
+		EEDI_HIGH;
+	else
+		EEDI_LOW;
+
+	EECLK_LOW;
+	udelay(1000);
+	EECLK_HIGH;
+	udelay(1000);
+	EEDI_LOW;
+}
+
+/*
+ * Get 1 bit data
+ */
+static u8 ax88796_bitget(void)
+{
+	u8 bit;
+
+	EECLK_LOW;
+	udelay(1000);
+	/* DATA */
+	bit = EEDO;
+	EECLK_HIGH;
+	udelay(1000);
+
+	return bit;
+}
+
+/*
+ * Send COMMAND to EEPROM
+ */
+static void ax88796_eep_cmd(u8 cmd)
+{
+	ax88796_bitset(BIT_DUMMY);
+	switch(cmd){
+		case MAC_EEP_READ:
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			break;
+
+		case MAC_EEP_WRITE:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(1);
+			break;
+
+		case MAC_EEP_ERACE:
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			break;
+
+		case MAC_EEP_EWEN:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(0);
+			break;
+
+		case MAC_EEP_EWDS:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(0);
+			break;
+		default:
+			break;
+	}
+}
+
+static void ax88796_eep_setaddr(u16 addr)
+{
+	int i ;
+
+	for( i = 7 ; i >= 0 ; i-- )
+		ax88796_bitset(addr & (1 << i));
+}
+
+/*
+ * Get data from EEPROM
+ */
+static u16 ax88796_eep_getdata(void)
+{
+	ushort data = 0;
+	int i;
+
+	ax88796_bitget();	/* DUMMY */
+	for( i = 0 ; i < 16 ; i++ ){
+		data <<= 1;
+		data |= ax88796_bitget();
+	}
+	return data;
+}
+
+static void ax88796_mac_read(u8 *buff)
+{
+	int i ;
+	u16 data;
+	u16 addr = 0;
+
+	for( i = 0 ; i < 3; i++ )
+	{
+		EECS_HIGH;
+		EEDI_LOW;
+		udelay(1000);
+		/* READ COMMAND */
+		ax88796_eep_cmd(MAC_EEP_READ);
+		/* ADDRESS */
+		ax88796_eep_setaddr(addr++);
+		/* GET DATA */
+		data = ax88796_eep_getdata();
+		*buff++ = (uchar)(data & 0xff);
+		*buff++ = (uchar)((data >> 8) & 0xff);
+		EECLK_LOW;
+		EEDI_LOW;
+		EECS_LOW;
+	}
+}
+
+int get_prom(u8* mac_addr)
+{
+	u8 prom[32];
+	int i;
+
+	ax88796_mac_read(prom);
+	for (i = 0; i < 6; i++){
+		mac_addr[i] = prom[i];
+	}
+	return 1;
+}
diff --git a/drivers/net/ax88796.h b/drivers/net/ax88796.h
index 069ae80..aa342cb 100644
--- a/drivers/net/ax88796.h
+++ b/drivers/net/ax88796.h
@@ -79,139 +79,5 @@
 #endif
 
 
-/*
- * Set 1 bit data
- */
-static void ax88796_bitset(u32 bit)
-{
-	/* DATA1 */
-	if( bit )
-		EEDI_HIGH;
-	else
-		EEDI_LOW;
-
-	EECLK_LOW;
-	udelay(1000);
-	EECLK_HIGH;
-	udelay(1000);
-	EEDI_LOW;
-}
-
-/*
- * Get 1 bit data
- */
-static u8 ax88796_bitget(void)
-{
-	u8 bit;
-
-	EECLK_LOW;
-	udelay(1000);
-	/* DATA */
-	bit = EEDO;
-	EECLK_HIGH;
-	udelay(1000);
-
-	return bit;
-}
-
-/*
- * Send COMMAND to EEPROM
- */
-static void ax88796_eep_cmd(u8 cmd)
-{
-	ax88796_bitset(BIT_DUMMY);
-	switch(cmd){
-		case MAC_EEP_READ:
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			break;
-
-		case MAC_EEP_WRITE:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(1);
-			break;
-
-		case MAC_EEP_ERACE:
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			break;
-
-		case MAC_EEP_EWEN:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(0);
-			break;
-
-		case MAC_EEP_EWDS:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(0);
-			break;
-		default:
-			break;
-	}
-}
-
-static void ax88796_eep_setaddr(u16 addr)
-{
-	int i ;
-	for( i = 7 ; i >= 0 ; i-- )
-		ax88796_bitset(addr & (1 << i));
-}
-
-/*
- * Get data from EEPROM
- */
-static u16 ax88796_eep_getdata(void)
-{
-	ushort data = 0;
-	int i;
-
-	ax88796_bitget();	/* DUMMY */
-	for( i = 0 ; i < 16 ; i++ ){
-		data <<= 1;
-		data |= ax88796_bitget();
-	}
-	return data;
-}
-
-static void ax88796_mac_read(u8 *buff)
-{
-	int i ;
-	u16 data, addr = 0;
-
-	for( i = 0 ; i < 3; i++ )
-	{
-		EECS_HIGH;
-		EEDI_LOW;
-		udelay(1000);
-		/* READ COMMAND */
-		ax88796_eep_cmd(MAC_EEP_READ);
-		/* ADDRESS */
-		ax88796_eep_setaddr(addr++);
-		/* GET DATA */
-		data = ax88796_eep_getdata();
-		*buff++ = (uchar)(data & 0xff);
-		*buff++ = (uchar)((data >> 8) & 0xff);
-		EECLK_LOW;
-		EEDI_LOW;
-		EECS_LOW;
-	}
-}
-
-int get_prom(u8* mac_addr)
-{
-	u8 prom[32];
-	int i;
-
-	ax88796_mac_read(prom);
-	for (i = 0; i < 6; i++){
-		mac_addr[i] = prom[i];
-	}
-	return 1;
-}
 
 #endif /* __DRIVERS_AX88796L_H__ */
diff --git a/drivers/net/ne2000.c b/drivers/net/ne2000.c
index 568dad7..3f32693 100644
--- a/drivers/net/ne2000.c
+++ b/drivers/net/ne2000.c
@@ -126,6 +126,9 @@ dp83902a_init(void)
 {
 	dp83902a_priv_data_t *dp = &nic;
 	u8* base;
+#if defined(NE2000_BASIC_INIT)
+	int i;
+#endif
 
 	DEBUG_FUNCTION();
 
@@ -755,8 +758,6 @@ static hw_info_t hw_info[] = {
 
 #define NR_INFO		(sizeof(hw_info)/sizeof(hw_info_t))
 
-static hw_info_t default_info = { 0, 0, 0, 0, 0 };
-
 u8 dev_addr[6];
 
 #define PCNET_CMD	0x00
@@ -764,6 +765,93 @@ u8 dev_addr[6];
 #define PCNET_RESET	0x1f	/* Issue a read to reset, a write to clear. */
 #define PCNET_MISC	0x18	/* For IBM CCAE and Socket EA cards */
 
+static void pcnet_reset_8390(void)
+{
+	int i, r;
+
+	PRINTK("nic base is %lx\n", nic_base);
+
+	n2k_outb(E8390_NODMA + E8390_PAGE0+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+
+	n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
+
+	for (i = 0; i < 100; i++) {
+		if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
+			break;
+		PRINTK("got %x in reset\n", r);
+		udelay(100);
+	}
+	n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
+
+	if (i == 100)
+		printf("pcnet_reset_8390() did not complete.\n");
+} /* pcnet_reset_8390 */
+
+int get_prom(u8* mac_addr) __attribute__ ((weak, alias ("__get_prom")));
+int __get_prom(u8* mac_addr)
+{
+	u8 prom[32];
+	int i, j;
+	struct {
+		u_char value, offset;
+	} program_seq[] = {
+		{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
+		{0x48, EN0_DCFG},		/* Set byte-wide (0x48) access. */
+		{0x00, EN0_RCNTLO},		/* Clear the count regs. */
+		{0x00, EN0_RCNTHI},
+		{0x00, EN0_IMR},		/* Mask completion irq. */
+		{0xFF, EN0_ISR},
+		{E8390_RXOFF, EN0_RXCR},	/* 0x20 Set to monitor */
+		{E8390_TXOFF, EN0_TXCR},	/* 0x02 and loopback mode. */
+		{32, EN0_RCNTLO},
+		{0x00, EN0_RCNTHI},
+		{0x00, EN0_RSARLO},		/* DMA starting at 0x0000. */
+		{0x00, EN0_RSARHI},
+		{E8390_RREAD+E8390_START, E8390_CMD},
+	};
+
+	PRINTK ("trying to get MAC via prom reading\n");
+
+	pcnet_reset_8390 ();
+
+	mdelay (10);
+
+	for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
+		n2k_outb (program_seq[i].value, program_seq[i].offset);
+
+	PRINTK ("PROM:");
+	for (i = 0; i < 32; i++) {
+		prom[i] = n2k_inb (PCNET_DATAPORT);
+		PRINTK (" %02x", prom[i]);
+	}
+	PRINTK ("\n");
+	for (i = 0; i < NR_INFO; i++) {
+		if ((prom[0] == hw_info[i].a0) &&
+			(prom[2] == hw_info[i].a1) &&
+			(prom[4] == hw_info[i].a2)) {
+			PRINTK ("matched board %d\n", i);
+			break;
+		}
+	}
+	if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
+		PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
+		PRINTK ("MAC address is ");
+		for (j = 0; j < 6; j++) {
+			mac_addr[j] = prom[j << 1];
+			PRINTK ("%02x:", mac_addr[i]);
+		}
+		PRINTK ("\n");
+		return (i < NR_INFO) ? i : 0;
+	}
+	return 0;
+}
+
 u32 nic_base;
 
 /* U-boot specific routines */
@@ -790,7 +878,7 @@ void uboot_push_tx_done(int key, int val) {
 }
 
 int eth_init(bd_t *bd) {
-	static hw_info_t * r;
+	int r;
 	char ethaddr[20];
 
 	PRINTK("### eth_init\n");
diff --git a/drivers/net/ne2000.h b/drivers/net/ne2000.h
index 6049482..2cde6be 100644
--- a/drivers/net/ne2000.h
+++ b/drivers/net/ne2000.h
@@ -81,6 +81,7 @@ are GPL, so this is, of course, GPL.
 
 #define DP_DATA		0x10
 #define START_PG	0x50	/* First page of TX buffer */
+#define START_PG2	0x48
 #define STOP_PG		0x80	/* Last page +1 of RX ring */
 
 #define RX_START	0x50
@@ -90,90 +91,4 @@ are GPL, so this is, of course, GPL.
 #define DP_OUT(_b_, _o_, _d_)	*( (vu_char *) ((_b_)+(_o_))) = (_d_)
 #define DP_IN_DATA(_b_, _d_)	(_d_) = *( (vu_char *) ((_b_)))
 #define DP_OUT_DATA(_b_, _d_)	*( (vu_char *) ((_b_))) = (_d_)
-
-static void pcnet_reset_8390(void)
-{
-	int i, r;
-
-	PRINTK("nic base is %lx\n", nic_base);
-
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-
-	n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
-
-	for (i = 0; i < 100; i++) {
-		if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
-			break;
-		PRINTK("got %x in reset\n", r);
-		udelay(100);
-	}
-	n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
-
-	if (i == 100)
-		printf("pcnet_reset_8390() did not complete.\n");
-} /* pcnet_reset_8390 */
-
-int get_prom(u8* mac_addr)
-{
-	u8 prom[32];
-	int i, j;
-	struct {
-		u_char value, offset;
-	} program_seq[] = {
-		{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
-		{0x48,  EN0_DCFG},		/* Set byte-wide (0x48) access. */
-		{0x00,  EN0_RCNTLO},		/* Clear the count regs. */
-		{0x00,  EN0_RCNTHI},
-		{0x00,  EN0_IMR},		/* Mask completion irq. */
-		{0xFF,  EN0_ISR},
-		{E8390_RXOFF, EN0_RXCR},	/* 0x20  Set to monitor */
-		{E8390_TXOFF, EN0_TXCR},	/* 0x02  and loopback mode. */
-		{32,    EN0_RCNTLO},
-		{0x00,  EN0_RCNTHI},
-		{0x00,  EN0_RSARLO},		/* DMA starting at 0x0000. */
-		{0x00,  EN0_RSARHI},
-		{E8390_RREAD+E8390_START, E8390_CMD},
-	};
-
-	PRINTK ("trying to get MAC via prom reading\n");
-
-	pcnet_reset_8390 ();
-
-	mdelay (10);
-
-	for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
-		n2k_outb (program_seq[i].value, program_seq[i].offset);
-
-	PRINTK ("PROM:");
-	for (i = 0; i < 32; i++) {
-		prom[i] = n2k_inb (PCNET_DATAPORT);
-		PRINTK (" %02x", prom[i]);
-	}
-	PRINTK ("\n");
-	for (i = 0; i < NR_INFO; i++) {
-		if ((prom[0] == hw_info[i].a0) &&
-		    (prom[2] == hw_info[i].a1) &&
-		    (prom[4] == hw_info[i].a2)) {
-			PRINTK ("matched board %d\n", i);
-			break;
-		}
-	}
-	if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
-		PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
-		PRINTK ("MAC address is ");
-		for (j = 0; j < 6; j++) {
-			mac_addr[j] = prom[j << 1];
-			PRINTK ("%02x:", mac_addr[i]);
-		}
-		PRINTK ("\n");
-		return (i < NR_INFO) ? i : 0;
-	}
-	return NULL;
-}
 #endif /* __DRIVERS_NE2000_H__ */
diff --git a/drivers/net/ne2000_base.h b/drivers/net/ne2000_base.h
index 990d748..948b290 100644
--- a/drivers/net/ne2000_base.h
+++ b/drivers/net/ne2000_base.h
@@ -122,7 +122,6 @@ typedef struct dp83902a_priv_data {
 /*
  * Some forward declarations
  */
-int get_prom( u8* mac_addr);
 static void dp83902a_poll(void);
 
 /* ------------------------------------------------------------------------ */
-- 
1.5.4.5




From sr at denx.de  Thu Apr 24 08:02:46 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 08:02:46 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <48100C0D.708@denx.de>
References: <mailman.115528.1208956369.5026.u-boot-users@lists.sourceforge.net>
	<48100C0D.708@denx.de>
Message-ID: <200804240802.47301.sr@denx.de>

On Thursday 24 April 2008, Heiko Schocher wrote:
> > Add the Harris QUAD100HD AMCC 405EP-based board.
> >
> > Signed-off-by: Gary Jennejohn <garyj at denx.de>
> > ---
> >  MAINTAINERS                 |    4 +
> >  MAKEALL                     |    1 +
> >  Makefile                    |    3 +
> >  board/quad100hd/Makefile    |   51 ++
> >  board/quad100hd/config.mk   |   24 +
> >  board/quad100hd/flash.c     | 1097
> > +++++++++++++++++++++++++++++++++++++++++++
>
> Do you really need a boardspecific flash driver? Are these flashes not
> CFI compatible?

Yes, I had the some question in mind. Which FLASH chips are used on the board?

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From plagnioj at jcrosoft.com  Thu Apr 24 07:57:17 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 24 Apr 2008 07:57:17 +0200
Subject: [U-Boot-Users] [PATCH 1/1 V2] NE2000: Fix regresssion introduced by
	e710185aae90 on non AX88796
In-Reply-To: <1209016637-10264-1-git-send-email-plagnioj@jcrosoft.com>
References: <1209015794-9805-2-git-send-email-plagnioj@jcrosoft.com>
	<1209016637-10264-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1209016637-10264-2-git-send-email-plagnioj@jcrosoft.com>

Move non-inlied functions into specific drivers file
Set get_prom as weak

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
Signed-off-by: Vlad Lungu <vlad at comsys.ro>
---
Fix comment

 drivers/net/Makefile      |    5 +-
 drivers/net/ax88796.c     |  156 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/net/ax88796.h     |  136 ---------------------------------------
 drivers/net/ne2000.c      |   94 ++++++++++++++++++++++++++-
 drivers/net/ne2000.h      |   87 +-------------------------
 drivers/net/ne2000_base.h |    1 -
 6 files changed, 252 insertions(+), 227 deletions(-)
 create mode 100644 drivers/net/ax88796.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d5e413b..4131aad 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -42,7 +42,10 @@ COBJS-y += lan91c96.o
 COBJS-y += macb.o
 COBJS-y += mcffec.o
 COBJS-y += natsemi.o
-COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o
+ifeq ($(CONFIG_DRIVER_NE2000),y)
+COBJS-y += ne2000.o
+COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o
+endif
 COBJS-y += netarm_eth.o
 COBJS-y += netconsole.o
 COBJS-y += ns7520_eth.o
diff --git a/drivers/net/ax88796.c b/drivers/net/ax88796.c
new file mode 100644
index 0000000..39cd101
--- /dev/null
+++ b/drivers/net/ax88796.c
@@ -0,0 +1,156 @@
+/*
+ * (c) 2007 Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
+ *
+ * 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 <common.h>
+#include "ax88796.h"
+
+/*
+ * Set 1 bit data
+ */
+static void ax88796_bitset(u32 bit)
+{
+	/* DATA1 */
+	if( bit )
+		EEDI_HIGH;
+	else
+		EEDI_LOW;
+
+	EECLK_LOW;
+	udelay(1000);
+	EECLK_HIGH;
+	udelay(1000);
+	EEDI_LOW;
+}
+
+/*
+ * Get 1 bit data
+ */
+static u8 ax88796_bitget(void)
+{
+	u8 bit;
+
+	EECLK_LOW;
+	udelay(1000);
+	/* DATA */
+	bit = EEDO;
+	EECLK_HIGH;
+	udelay(1000);
+
+	return bit;
+}
+
+/*
+ * Send COMMAND to EEPROM
+ */
+static void ax88796_eep_cmd(u8 cmd)
+{
+	ax88796_bitset(BIT_DUMMY);
+	switch(cmd){
+		case MAC_EEP_READ:
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			break;
+
+		case MAC_EEP_WRITE:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(1);
+			break;
+
+		case MAC_EEP_ERACE:
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			ax88796_bitset(1);
+			break;
+
+		case MAC_EEP_EWEN:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(0);
+			break;
+
+		case MAC_EEP_EWDS:
+			ax88796_bitset(1);
+			ax88796_bitset(0);
+			ax88796_bitset(0);
+			break;
+		default:
+			break;
+	}
+}
+
+static void ax88796_eep_setaddr(u16 addr)
+{
+	int i ;
+
+	for( i = 7 ; i >= 0 ; i-- )
+		ax88796_bitset(addr & (1 << i));
+}
+
+/*
+ * Get data from EEPROM
+ */
+static u16 ax88796_eep_getdata(void)
+{
+	ushort data = 0;
+	int i;
+
+	ax88796_bitget();	/* DUMMY */
+	for( i = 0 ; i < 16 ; i++ ){
+		data <<= 1;
+		data |= ax88796_bitget();
+	}
+	return data;
+}
+
+static void ax88796_mac_read(u8 *buff)
+{
+	int i ;
+	u16 data;
+	u16 addr = 0;
+
+	for( i = 0 ; i < 3; i++ )
+	{
+		EECS_HIGH;
+		EEDI_LOW;
+		udelay(1000);
+		/* READ COMMAND */
+		ax88796_eep_cmd(MAC_EEP_READ);
+		/* ADDRESS */
+		ax88796_eep_setaddr(addr++);
+		/* GET DATA */
+		data = ax88796_eep_getdata();
+		*buff++ = (uchar)(data & 0xff);
+		*buff++ = (uchar)((data >> 8) & 0xff);
+		EECLK_LOW;
+		EEDI_LOW;
+		EECS_LOW;
+	}
+}
+
+int get_prom(u8* mac_addr)
+{
+	u8 prom[32];
+	int i;
+
+	ax88796_mac_read(prom);
+	for (i = 0; i < 6; i++){
+		mac_addr[i] = prom[i];
+	}
+	return 1;
+}
diff --git a/drivers/net/ax88796.h b/drivers/net/ax88796.h
index 0e6f8a2..43a1639 100644
--- a/drivers/net/ax88796.h
+++ b/drivers/net/ax88796.h
@@ -78,140 +78,4 @@
 #define DP_OUT_DATA(_b_, _d_)	*( (vu_short *) ((_b_)+ISA_OFFSET)) = (_d_)
 #endif
 
-
-/*
- * Set 1 bit data
- */
-static void ax88796_bitset(u32 bit)
-{
-	/* DATA1 */
-	if( bit )
-		EEDI_HIGH;
-	else
-		EEDI_LOW;
-
-	EECLK_LOW;
-	udelay(1000);
-	EECLK_HIGH;
-	udelay(1000);
-	EEDI_LOW;
-}
-
-/*
- * Get 1 bit data
- */
-static u8 ax88796_bitget(void)
-{
-	u8 bit;
-
-	EECLK_LOW;
-	udelay(1000);
-	/* DATA */
-	bit = EEDO;
-	EECLK_HIGH;
-	udelay(1000);
-
-	return bit;
-}
-
-/*
- * Send COMMAND to EEPROM
- */
-static void ax88796_eep_cmd(u8 cmd)
-{
-	ax88796_bitset(BIT_DUMMY);
-	switch(cmd){
-		case MAC_EEP_READ:
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			break;
-
-		case MAC_EEP_WRITE:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(1);
-			break;
-
-		case MAC_EEP_ERACE:
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			ax88796_bitset(1);
-			break;
-
-		case MAC_EEP_EWEN:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(0);
-			break;
-
-		case MAC_EEP_EWDS:
-			ax88796_bitset(1);
-			ax88796_bitset(0);
-			ax88796_bitset(0);
-			break;
-		default:
-			break;
-	}
-}
-
-static void ax88796_eep_setaddr(u16 addr)
-{
-	int i ;
-	for( i = 7 ; i >= 0 ; i-- )
-		ax88796_bitset(addr & (1 << i));
-}
-
-/*
- * Get data from EEPROM
- */
-static u16 ax88796_eep_getdata(void)
-{
-	ushort data = 0;
-	int i;
-
-	ax88796_bitget();	/* DUMMY */
-	for( i = 0 ; i < 16 ; i++ ){
-		data <<= 1;
-		data |= ax88796_bitget();
-	}
-	return data;
-}
-
-static void ax88796_mac_read(u8 *buff)
-{
-	int i ;
-	u16 data, addr = 0;
-
-	for( i = 0 ; i < 3; i++ )
-	{
-		EECS_HIGH;
-		EEDI_LOW;
-		udelay(1000);
-		/* READ COMMAND */
-		ax88796_eep_cmd(MAC_EEP_READ);
-		/* ADDRESS */
-		ax88796_eep_setaddr(addr++);
-		/* GET DATA */
-		data = ax88796_eep_getdata();
-		*buff++ = (uchar)(data & 0xff);
-		*buff++ = (uchar)((data >> 8) & 0xff);
-		EECLK_LOW;
-		EEDI_LOW;
-		EECS_LOW;
-	}
-}
-
-int get_prom(u8* mac_addr)
-{
-	u8 prom[32];
-	int i;
-
-	ax88796_mac_read(prom);
-	for (i = 0; i < 6; i++){
-		mac_addr[i] = prom[i];
-	}
-	return 1;
-}
-
 #endif /* __DRIVERS_AX88796L_H__ */
diff --git a/drivers/net/ne2000.c b/drivers/net/ne2000.c
index d09da78..2da57b6 100644
--- a/drivers/net/ne2000.c
+++ b/drivers/net/ne2000.c
@@ -126,6 +126,9 @@ dp83902a_init(void)
 {
 	dp83902a_priv_data_t *dp = &nic;
 	u8* base;
+#if defined(NE2000_BASIC_INIT)
+	int i;
+#endif
 
 	DEBUG_FUNCTION();
 
@@ -755,8 +758,6 @@ static hw_info_t hw_info[] = {
 
 #define NR_INFO		(sizeof(hw_info)/sizeof(hw_info_t))
 
-static hw_info_t default_info = { 0, 0, 0, 0, 0 };
-
 u8 dev_addr[6];
 
 #define PCNET_CMD	0x00
@@ -764,6 +765,93 @@ u8 dev_addr[6];
 #define PCNET_RESET	0x1f	/* Issue a read to reset, a write to clear. */
 #define PCNET_MISC	0x18	/* For IBM CCAE and Socket EA cards */
 
+static void pcnet_reset_8390(void)
+{
+	int i, r;
+
+	PRINTK("nic base is %lx\n", nic_base);
+
+	n2k_outb(E8390_NODMA + E8390_PAGE0+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+	PRINTK("cmd (at %lx) is %x\n", nic_base + E8390_CMD, n2k_inb(E8390_CMD));
+	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
+
+	n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
+
+	for (i = 0; i < 100; i++) {
+		if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
+			break;
+		PRINTK("got %x in reset\n", r);
+		udelay(100);
+	}
+	n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
+
+	if (i == 100)
+		printf("pcnet_reset_8390() did not complete.\n");
+} /* pcnet_reset_8390 */
+
+int get_prom(u8* mac_addr) __attribute__ ((weak, alias ("__get_prom")));
+int __get_prom(u8* mac_addr)
+{
+	u8 prom[32];
+	int i, j;
+	struct {
+		u_char value, offset;
+	} program_seq[] = {
+		{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
+		{0x48, EN0_DCFG},		/* Set byte-wide (0x48) access. */
+		{0x00, EN0_RCNTLO},		/* Clear the count regs. */
+		{0x00, EN0_RCNTHI},
+		{0x00, EN0_IMR},		/* Mask completion irq. */
+		{0xFF, EN0_ISR},
+		{E8390_RXOFF, EN0_RXCR},	/* 0x20 Set to monitor */
+		{E8390_TXOFF, EN0_TXCR},	/* 0x02 and loopback mode. */
+		{32, EN0_RCNTLO},
+		{0x00, EN0_RCNTHI},
+		{0x00, EN0_RSARLO},		/* DMA starting at 0x0000. */
+		{0x00, EN0_RSARHI},
+		{E8390_RREAD+E8390_START, E8390_CMD},
+	};
+
+	PRINTK ("trying to get MAC via prom reading\n");
+
+	pcnet_reset_8390 ();
+
+	mdelay (10);
+
+	for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
+		n2k_outb (program_seq[i].value, program_seq[i].offset);
+
+	PRINTK ("PROM:");
+	for (i = 0; i < 32; i++) {
+		prom[i] = n2k_inb (PCNET_DATAPORT);
+		PRINTK (" %02x", prom[i]);
+	}
+	PRINTK ("\n");
+	for (i = 0; i < NR_INFO; i++) {
+		if ((prom[0] == hw_info[i].a0) &&
+			(prom[2] == hw_info[i].a1) &&
+			(prom[4] == hw_info[i].a2)) {
+			PRINTK ("matched board %d\n", i);
+			break;
+		}
+	}
+	if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
+		PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
+		PRINTK ("MAC address is ");
+		for (j = 0; j < 6; j++) {
+			mac_addr[j] = prom[j << 1];
+			PRINTK ("%02x:", mac_addr[i]);
+		}
+		PRINTK ("\n");
+		return (i < NR_INFO) ? i : 0;
+	}
+	return 0;
+}
+
 u32 nic_base;
 
 /* U-boot specific routines */
@@ -790,7 +878,7 @@ void uboot_push_tx_done(int key, int val) {
 }
 
 int eth_init(bd_t *bd) {
-	static hw_info_t * r;
+	int r;
 	char ethaddr[20];
 
 	PRINTK("### eth_init\n");
diff --git a/drivers/net/ne2000.h b/drivers/net/ne2000.h
index 6049482..2cde6be 100644
--- a/drivers/net/ne2000.h
+++ b/drivers/net/ne2000.h
@@ -81,6 +81,7 @@ are GPL, so this is, of course, GPL.
 
 #define DP_DATA		0x10
 #define START_PG	0x50	/* First page of TX buffer */
+#define START_PG2	0x48
 #define STOP_PG		0x80	/* Last page +1 of RX ring */
 
 #define RX_START	0x50
@@ -90,90 +91,4 @@ are GPL, so this is, of course, GPL.
 #define DP_OUT(_b_, _o_, _d_)	*( (vu_char *) ((_b_)+(_o_))) = (_d_)
 #define DP_IN_DATA(_b_, _d_)	(_d_) = *( (vu_char *) ((_b_)))
 #define DP_OUT_DATA(_b_, _d_)	*( (vu_char *) ((_b_))) = (_d_)
-
-static void pcnet_reset_8390(void)
-{
-	int i, r;
-
-	PRINTK("nic base is %lx\n", nic_base);
-
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE1+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-	PRINTK("cmd (at %lx) is %x\n", nic_base+ E8390_CMD, n2k_inb(E8390_CMD));
-	n2k_outb(E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD);
-
-	n2k_outb(n2k_inb(PCNET_RESET), PCNET_RESET);
-
-	for (i = 0; i < 100; i++) {
-		if ((r = (n2k_inb(EN0_ISR) & ENISR_RESET)) != 0)
-			break;
-		PRINTK("got %x in reset\n", r);
-		udelay(100);
-	}
-	n2k_outb(ENISR_RESET, EN0_ISR); /* Ack intr. */
-
-	if (i == 100)
-		printf("pcnet_reset_8390() did not complete.\n");
-} /* pcnet_reset_8390 */
-
-int get_prom(u8* mac_addr)
-{
-	u8 prom[32];
-	int i, j;
-	struct {
-		u_char value, offset;
-	} program_seq[] = {
-		{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
-		{0x48,  EN0_DCFG},		/* Set byte-wide (0x48) access. */
-		{0x00,  EN0_RCNTLO},		/* Clear the count regs. */
-		{0x00,  EN0_RCNTHI},
-		{0x00,  EN0_IMR},		/* Mask completion irq. */
-		{0xFF,  EN0_ISR},
-		{E8390_RXOFF, EN0_RXCR},	/* 0x20  Set to monitor */
-		{E8390_TXOFF, EN0_TXCR},	/* 0x02  and loopback mode. */
-		{32,    EN0_RCNTLO},
-		{0x00,  EN0_RCNTHI},
-		{0x00,  EN0_RSARLO},		/* DMA starting at 0x0000. */
-		{0x00,  EN0_RSARHI},
-		{E8390_RREAD+E8390_START, E8390_CMD},
-	};
-
-	PRINTK ("trying to get MAC via prom reading\n");
-
-	pcnet_reset_8390 ();
-
-	mdelay (10);
-
-	for (i = 0; i < sizeof (program_seq) / sizeof (program_seq[0]); i++)
-		n2k_outb (program_seq[i].value, program_seq[i].offset);
-
-	PRINTK ("PROM:");
-	for (i = 0; i < 32; i++) {
-		prom[i] = n2k_inb (PCNET_DATAPORT);
-		PRINTK (" %02x", prom[i]);
-	}
-	PRINTK ("\n");
-	for (i = 0; i < NR_INFO; i++) {
-		if ((prom[0] == hw_info[i].a0) &&
-		    (prom[2] == hw_info[i].a1) &&
-		    (prom[4] == hw_info[i].a2)) {
-			PRINTK ("matched board %d\n", i);
-			break;
-		}
-	}
-	if ((i < NR_INFO) || ((prom[28] == 0x57) && (prom[30] == 0x57))) {
-		PRINTK ("on exit i is %d/%ld\n", i, NR_INFO);
-		PRINTK ("MAC address is ");
-		for (j = 0; j < 6; j++) {
-			mac_addr[j] = prom[j << 1];
-			PRINTK ("%02x:", mac_addr[i]);
-		}
-		PRINTK ("\n");
-		return (i < NR_INFO) ? i : 0;
-	}
-	return NULL;
-}
 #endif /* __DRIVERS_NE2000_H__ */
diff --git a/drivers/net/ne2000_base.h b/drivers/net/ne2000_base.h
index 990d748..948b290 100644
--- a/drivers/net/ne2000_base.h
+++ b/drivers/net/ne2000_base.h
@@ -122,7 +122,6 @@ typedef struct dp83902a_priv_data {
 /*
  * Some forward declarations
  */
-int get_prom( u8* mac_addr);
 static void dp83902a_poll(void);
 
 /* ------------------------------------------------------------------------ */
-- 
1.5.4.5




From pierre.savary at kerlink.fr  Thu Apr 24 08:24:45 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Thu, 24 Apr 2008 08:24:45 +0200
Subject: [U-Boot-Users] [PATCH] Add eSDHC driver
In-Reply-To: <AA28F077645B324881335614E4F7C428034CDC@win-ex01.bench.com>
References: <1208876866-11251-1-git-send-email-afleming@freescale.com>
	<AA28F077645B324881335614E4F7C428034CDC@win-ex01.bench.com>
Message-ID: <005501c8a5d3$e467ceb0$ad376c10$@savary@kerlink.fr>

Thanks for that... but it's my own patch ;)

Pierre


-----Message d'origine-----
De?: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] De la part de
Ken.Fuchs at bench.com
Envoy??: mercredi 23 avril 2008 21:23
??: pierre.savary at kerlink.fr
Cc?: u-boot-users at lists.sourceforge.net; afleming at freescale.com;
drzeus-mmc at drzeus.cx
Objet?: Re: [U-Boot-Users] [PATCH] Add eSDHC driver

> Pierre Savary wrote:

> >Where could we find the driver that works with MMCv4 on at91sam9x?

Andy Fleming wrote:

> Pierre, I don't have a driver that works on at91sam9x, I'm 
> afraid.

Here's an MMC v2.x AT91SAM9260 patch for Atmel modified u-boot 1.1.5.
You will need to define GPIO pins for other AT91SAM9 processors, etc.

If you really need an MMC v4.x AT91SAM9 MCI driver for 1.1.5 fast, you
probably could cut and paste the v4.x code you need from Andy's MMC
driver
into the MMC v2.x MCI driver this patch provides.

BTW, if anyone knows why MMC 4 bit is disabled for AT91SAM9261 in the
MCI Linux driver, I'd like to hear the reasons why.

--- u-boot_at91sam9260_mmc.patch (AT91 MCI driver) ---

diff -burN u-boot-1.1.5/board/at91sam9260ek/at91sam9260ek.c
u-boot-1.1.5.klk/board/at91sam9260ek/at91sam9260ek.c
--- u-boot-1.1.5/board/at91sam9260ek/at91sam9260ek.c	2007-08-21
17:06:36.000000000 +0200
+++ u-boot-1.1.5.klk/board/at91sam9260ek/at91sam9260ek.c
2007-08-23 08:37:42.000000000 +0200
@@ -109,6 +109,24 @@
 }
 
 
+#ifdef CONFIG_MMC
+#if (CONFIG_COMMANDS & CFG_CMD_MMC)
+int AT91F_MMC_Hardware_Init(void)
+{
+	AT91C_BASE_PIOA->PIO_ASR = (1 << 8 );		/* periph A
select register */
+	AT91C_BASE_PIOA->PIO_BSR |= 0x3B;			/*
periph B select register */
+	AT91C_BASE_PIOA->PIO_PDR |= 0x13B;			/* PIO
disable register */
+	AT91C_BASE_PIOA->PIO_PPUDR |= 0x13B;		/* Pull up
disable register */
+
+	AT91C_BASE_PMC->PMC_PCER = (1 << 9);
+}
+#endif /* CONFIG_COMMANDS & CFG_CMD_MMC */
+#endif /* CONFIG_MMC */
+
+
+
+
+
 #ifdef CONFIG_DRIVER_ETHER
 #if (CONFIG_COMMANDS & CFG_CMD_NET)
 
diff -burN u-boot-1.1.5/common/cmd_nvedit.c
u-boot-1.1.5.klk/common/cmd_nvedit.c
--- u-boot-1.1.5/common/cmd_nvedit.c	2006-10-20 17:54:33.000000000
+0200
+++ u-boot-1.1.5.klk/common/cmd_nvedit.c	2007-08-23
09:26:18.000000000 +0200
@@ -530,6 +530,7 @@
 	return (-1);
 }
 
+#ifndef CFG_ENV_IS_NOWHERE
 #if defined(CFG_ENV_IS_IN_NVRAM) || defined(CFG_ENV_IS_IN_EEPROM) || \
     ((CONFIG_COMMANDS & (CFG_CMD_ENV|CFG_CMD_FLASH)) == \
       (CFG_CMD_ENV|CFG_CMD_FLASH)) || \
@@ -544,7 +545,7 @@
 	return (saveenv() ? 1 : 0);
 }
 
-
+#endif
 #endif
 
 
@@ -587,7 +588,7 @@
 	"setenv name\n"
 	"    - delete environment variable 'name'\n"
 );
-
+#ifndef CFG_ENV_IS_NOWHERE
 #if defined(CFG_ENV_IS_IN_NVRAM) || defined(CFG_ENV_IS_IN_EEPROM) || \
     ((CONFIG_COMMANDS & (CFG_CMD_ENV|CFG_CMD_FLASH)) == \
       (CFG_CMD_ENV|CFG_CMD_FLASH)) || \
@@ -600,6 +601,7 @@
 );
 
 #endif	/* CFG_CMD_ENV */
+#endif	
 
 #if (CONFIG_COMMANDS & CFG_CMD_ASKENV)
 
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/atmel_mci.c
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/atmel_mci.c
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/atmel_mci.c	1970-01-01
01:00:00.000000000 +0100
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/atmel_mci.c
2007-08-23 09:45:46.000000000 +0200
@@ -0,0 +1,572 @@
+/*
+ * Copyright (C) 2004-2006 Atmel Corporation
+ *
+ * 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 <common.h>
+
+#ifdef CONFIG_MMC
+
+#include <part.h>
+#include <mmc.h>
+
+#include <asm/io.h>
+#include <asm/errno.h>
+#include <asm/byteorder.h>
+//#include <asm/arch/clk.h>
+//#include <asm/arch/memory-map.h>
+#include <asm/arch/hardware.h>	//klk
+
+#include "atmel_mci.h"
+#undef DEBUG
+#ifdef DEBUG
+#define pr_debug(fmt, args...) printf(fmt, ##args)
+#else
+#define pr_debug(...) do { } while(0)
+#endif
+
+#ifndef CFG_MMC_CLK_OD
+#define CFG_MMC_CLK_OD		375000
+#endif
+
+#ifndef CFG_MMC_CLK_PP
+#define CFG_MMC_CLK_PP		20000000
+#endif
+
+#ifndef CFG_MMC_OP_COND
+#define CFG_MMC_OP_COND		0x00100000
+#endif
+
+#define MMC_DEFAULT_BLKLEN	512
+#define MMC_DEFAULT_RCA		1
+
+static unsigned int mmc_rca;
+static int mmc_card_is_sd;
+static block_dev_desc_t mmc_blkdev;
+
+block_dev_desc_t *mmc_get_dev(int dev)
+{
+	return &mmc_blkdev;
+}
+
+static void mci_set_mode(unsigned long hz, unsigned long blklen)
+{
+	unsigned long bus_hz;
+	unsigned long clkdiv;
+
+	// bus_hz = get_mci_clk_rate();
+	bus_hz = AT91C_MASTER_CLOCK;
+	clkdiv = (bus_hz / hz) / 2 - 1;
+
+	pr_debug("mmc: setting clock %lu Hz, block size %lu\n",
+		 hz, blklen);
+
+	if (clkdiv & ~255UL) {
+		clkdiv = 255;
+		pr_debug("mmc: clock %lu too low; setting CLKDIV to
255\n",
+			hz);
+	}
+
+	blklen &= 0xfffc;
+	mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
+			 | MMCI_BF(BLKLEN, blklen)
+			 | MMCI_BIT(RDPROOF)
+			 | MMCI_BIT(WRPROOF)));
+}
+
+#define RESP_NO_CRC	1
+#define R1		MMCI_BF(RSPTYP, 1)
+#define R2		MMCI_BF(RSPTYP, 2)
+#define R3		(R1 | RESP_NO_CRC)
+#define R6		R1
+#define NID		MMCI_BF(MAXLAT, 0)
+#define NCR		MMCI_BF(MAXLAT, 1)
+#define TRCMD_START	MMCI_BF(TRCMD, 1)
+#define TRDIR_READ	MMCI_BF(TRDIR, 1)
+#define TRTYP_BLOCK	MMCI_BF(TRTYP, 0)
+#define INIT_CMD	MMCI_BF(SPCMD, 1)
+#define OPEN_DRAIN	MMCI_BF(OPDCMD, 1)
+
+#define ERROR_FLAGS	(MMCI_BIT(DTOE)			\
+			 | MMCI_BIT(RDIRE)		\
+			 | MMCI_BIT(RENDE)		\
+			 | MMCI_BIT(RINDE)		\
+			 | MMCI_BIT(RTOE))
+
+static int
+mmc_cmd(unsigned long cmd, unsigned long arg,
+	void *resp, unsigned long flags)
+{
+	unsigned long *response = resp;
+	int i, response_words = 0;
+	unsigned long error_flags;
+	u32 status;
+
+	AT91F_MMC_Hardware_Init();
+	
+	pr_debug("mmc: CMD%lu 0x%lx (flags 0x%lx)\n",
+		 cmd, arg, flags);
+
+	error_flags = ERROR_FLAGS;
+	if (!(flags & RESP_NO_CRC))
+		error_flags |= MMCI_BIT(RCRCE);
+
+	flags &= ~MMCI_BF(CMDNB, ~0UL);
+
+	if (MMCI_BFEXT(RSPTYP, flags) == MMCI_RSPTYP_48_BIT_RESP)
+		response_words = 1;
+	else if (MMCI_BFEXT(RSPTYP, flags) == MMCI_RSPTYP_136_BIT_RESP)
+		response_words = 4;
+
+	mmci_writel(ARGR, arg);
+	mmci_writel(CMDR, cmd | flags);
+	do {
+		udelay(40);
+		status = mmci_readl(SR);
+	} while (!(status & MMCI_BIT(CMDRDY)));
+
+	pr_debug("mmc: status 0x%08lx\n", status);
+
+	if (status & ERROR_FLAGS) {
+		pr_debug("mmc: command %lu failed (status: 0x%08lx)\n",
+		       cmd, status);
+		return -EIO;
+	}
+
+	if (response_words)
+		pr_debug("mmc: response:");
+
+	for (i = 0; i < response_words; i++) {
+		response[i] = mmci_readl(RSPR);
+		pr_debug(" %08lx", response[i]);
+	}
+	pr_debug("\n");
+
+	return 0;
+}
+
+static int mmc_acmd(unsigned long cmd, unsigned long arg,
+		    void *resp, unsigned long flags)
+{
+	unsigned long aresp[4];
+	int ret;
+
+	/*
+	 * Seems like the APP_CMD part of an ACMD has 64 cycles max
+	 * latency even though the ACMD part doesn't. This isn't
+	 * entirely clear in the SD Card spec, but some cards refuse
+	 * to work if we attempt to use 5 cycles max latency here...
+	 */
+	ret = mmc_cmd(MMC_CMD_APP_CMD, 0, aresp,
+		      R1 | NCR | (flags & OPEN_DRAIN));
+	if (ret)
+		return ret;
+	if ((aresp[0] & (R1_ILLEGAL_COMMAND | R1_APP_CMD)) !=
R1_APP_CMD)
+		return -ENODEV;
+
+	ret = mmc_cmd(cmd, arg, resp, flags);
+	return ret;
+}
+
+static unsigned long
+mmc_bread(int dev, unsigned long start, lbaint_t blkcnt,
+	  unsigned long *buffer)
+{
+	int ret, i = 0;
+	unsigned long resp[4];
+	unsigned long card_status, data;
+	unsigned long wordcount;
+	u32 status;
+
+	if (blkcnt == 0)
+		return 0;
+
+	pr_debug("mmc_bread: dev %d, start %lx, blkcnt %lx\n",
+		 dev, start, blkcnt);
+
+	/* Put the device into Transfer state */
+	ret = mmc_cmd(MMC_CMD_SELECT_CARD, mmc_rca << 16, resp, R1 |
NCR);
+	if (ret) goto fail;
+
+	/* Set block length */
+	ret = mmc_cmd(MMC_CMD_SET_BLOCKLEN, mmc_blkdev.blksz, resp, R1 |
NCR);
+	if (ret) goto fail;
+
+	pr_debug("MCI_DTOR = %08lx\n", mmci_readl(DTOR));
+
+	for (i = 0; i < blkcnt; i++, start++) {
+		ret = mmc_cmd(MMC_CMD_READ_SINGLE_BLOCK,
+			      start * mmc_blkdev.blksz, resp,
+			      (R1 | NCR | TRCMD_START | TRDIR_READ
+			       | TRTYP_BLOCK));
+		if (ret) goto fail;
+
+		ret = -EIO;
+		wordcount = 0;
+		do {
+			do {
+				status = mmci_readl(SR);
+				if (status & (ERROR_FLAGS |
MMCI_BIT(OVRE)))
+					goto fail;
+			} while (!(status & MMCI_BIT(RXRDY)));
+
+			if (status & MMCI_BIT(RXRDY)) {
+				data = mmci_readl(RDR);
+				/* pr_debug("%x\n", data); */
+				*buffer++ = data;
+				wordcount++;
+			}
+		} while(wordcount < (mmc_blkdev.blksz / 4));
+
+		pr_debug("mmc: read %u words, waiting for BLKE\n",
wordcount);
+
+		do {
+			status = mmci_readl(SR);
+		} while (!(status & MMCI_BIT(BLKE)));
+
+		putc('.');
+	}
+
+out:
+	/* Put the device back into Standby state */
+	mmc_cmd(MMC_CMD_SELECT_CARD, 0, resp, NCR);
+	return i;
+
+fail:
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread failed, card status = %08x\n",
card_status);
+	goto out;
+}
+
+static void mmc_parse_cid(struct mmc_cid *cid, unsigned long *resp)
+{
+	cid->mid = resp[0] >> 24;
+	cid->oid = (resp[0] >> 8) & 0xffff;
+	cid->pnm[0] = resp[0];
+	cid->pnm[1] = resp[1] >> 24;
+	cid->pnm[2] = resp[1] >> 16;
+	cid->pnm[3] = resp[1] >> 8;
+	cid->pnm[4] = resp[1];
+	cid->pnm[5] = resp[2] >> 24;
+	cid->pnm[6] = 0;
+	cid->prv = resp[2] >> 16;
+	cid->psn = (resp[2] << 16) | (resp[3] >> 16);
+	cid->mdt = resp[3] >> 8;
+}
+
+static void sd_parse_cid(struct mmc_cid *cid, unsigned long *resp)
+{
+	cid->mid = resp[0] >> 24;
+	cid->oid = (resp[0] >> 8) & 0xffff;
+	cid->pnm[0] = resp[0];
+	cid->pnm[1] = resp[1] >> 24;
+	cid->pnm[2] = resp[1] >> 16;
+	cid->pnm[3] = resp[1] >> 8;
+	cid->pnm[4] = resp[1];
+	cid->pnm[5] = 0;
+	cid->pnm[6] = 0;
+	cid->prv = resp[2] >> 24;
+	cid->psn = (resp[2] << 8) | (resp[3] >> 24);
+	cid->mdt = (resp[3] >> 8) & 0x0fff;
+}
+
+static void mmc_dump_cid(const struct mmc_cid *cid)
+{
+	printf("Manufacturer ID:       %02lX\n", cid->mid);
+	printf("OEM/Application ID:    %04lX\n", cid->oid);
+	printf("Product name:          %s\n", cid->pnm);
+	printf("Product Revision:      %lu.%lu\n",
+	       cid->prv >> 4, cid->prv & 0x0f);
+	printf("Product Serial Number: %lu\n", cid->psn);
+	printf("Manufacturing Date:    %02lu/%02lu\n",
+	       cid->mdt >> 4, cid->mdt & 0x0f);
+}
+
+static void mmc_dump_csd(const struct mmc_csd *csd)
+{
+	unsigned long *csd_raw = (unsigned long *)csd;
+	pr_debug("CSD data: %08lx %08lx %08lx %08lx\n",
+	       csd_raw[0], csd_raw[1], csd_raw[2], csd_raw[3]);
+	pr_debug("CSD structure version:   1.%u\n", csd->csd_structure);
+	pr_debug("MMC System Spec version: %u\n", csd->spec_vers);
+	pr_debug("Card command classes:    %03x\n", csd->ccc);
+	pr_debug("Read block length:       %u\n", 1 <<
csd->read_bl_len);
+	if (csd->read_bl_partial)
+		puts("Supports partial reads\n");
+	else
+		puts("Does not support partial reads\n");
+	pr_debug("Write block length:      %u\n", 1 <<
csd->write_bl_len);
+	if (csd->write_bl_partial)
+		puts("Supports partial writes\n");
+	else
+		puts("Does not support partial writes\n");
+	if (csd->wp_grp_enable)
+		pr_debug("Supports group WP:      %u\n",
csd->wp_grp_size + 1);
+	else
+		puts("Does not support group WP\n");
+	pr_debug("Card capacity:		%u bytes\n",
+	       (csd->c_size + 1) * (1 << (csd->c_size_mult + 2)) *
+	       (1 << csd->read_bl_len));
+	pr_debug("File format:            %u/%u\n",
+	       csd->file_format_grp, csd->file_format);
+	puts("Write protection:        ");
+	if (csd->perm_write_protect)
+		puts(" permanent");
+	if (csd->tmp_write_protect)
+		puts(" temporary");
+	putc('\n');
+}
+
+static int mmc_idle_cards(void)
+{
+	int ret;
+
+	/* Reset and initialize all cards */
+	ret = mmc_cmd(MMC_CMD_GO_IDLE_STATE, 0, NULL, 0);
+	
+	if (ret)
+		return ret;
+	pr_debug(" ret: %i\n",ret);
+	/* Keep the bus idle for 74 clock cycles */
+	return mmc_cmd(0, 0, NULL, INIT_CMD);
+}
+
+static int sd_init_card(struct mmc_cid *cid, int verbose)
+{
+	unsigned long resp[4];
+	int i, ret = 0;
+
+	mmc_idle_cards();
+	for (i = 0; i < 1000; i++) {
+		ret = mmc_acmd(MMC_ACMD_SD_SEND_OP_COND,
CFG_MMC_OP_COND,
+			       resp, R3 | NID);
+		if (ret || (resp[0] & 0x80000000))
+			break;
+		ret = -ETIMEDOUT;
+	}
+
+	if (ret)
+		return ret;
+
+	ret = mmc_cmd(MMC_CMD_ALL_SEND_CID, 0, resp, R2 | NID);
+	if (ret)
+		return ret;
+	sd_parse_cid(cid, resp);
+	if (verbose)
+		mmc_dump_cid(cid);
+
+	/* Get RCA of the card that responded */
+	ret = mmc_cmd(MMC_CMD_SD_SEND_RELATIVE_ADDR, 0, resp, R6 | NCR);
+	if (ret)
+		return ret;
+
+	mmc_rca = resp[0] >> 16;
+	if (verbose)
+		pr_debug("SD Card detected (RCA %u)\n", mmc_rca);
+	mmc_card_is_sd = 1;
+	return 0;
+}
+
+static int mmc_init_card(struct mmc_cid *cid, int verbose)
+{
+	unsigned long resp[4];
+	int i, ret = 0;
+
+	mmc_idle_cards();
+
+	for (i = 0; i < 1000; i++) {
+		ret = mmc_cmd(MMC_CMD_SEND_OP_COND, CFG_MMC_OP_COND,
resp,
+			      R3 | NID | OPEN_DRAIN);
+		if (ret || (resp[0] & 0x80000000))
+		{
+			break;
+		}
+		ret = -ETIMEDOUT;
+	}
+	pr_debug("4\n");
+	pr_debug("ret : %i\n",ret);
+	if (ret)
+		return ret;
+	pr_debug("5\n");
+	/* Get CID of all cards. FIXME: Support more than one card */
+	ret = mmc_cmd(MMC_CMD_ALL_SEND_CID, 0, resp, R2 | NID |
OPEN_DRAIN);
+	if (ret)
+		return ret;
+	mmc_parse_cid(cid, resp);
+	if (verbose)
+		mmc_dump_cid(cid);
+
+	/* Set Relative Address of the card that responded */
+	ret = mmc_cmd(MMC_CMD_SET_RELATIVE_ADDR, mmc_rca << 16, resp,
+		      R1 | NCR | OPEN_DRAIN);
+	return ret;
+}
+
+static void mci_set_data_timeout(struct mmc_csd *csd)
+{
+	static const unsigned int dtomul_to_shift[] = {
+		0, 4, 7, 8, 10, 12, 16, 20,
+	};
+	static const unsigned int taac_exp[] = {
+		1, 10, 100, 1000, 10000, 100000, 1000000, 10000000,
+	};
+	static const unsigned int taac_mant[] = {
+		0,  10, 12, 13, 15, 60, 25, 30,
+		35, 40, 45, 50, 55, 60, 70, 80,
+	};
+	unsigned int timeout_ns, timeout_clks;
+	unsigned int e, m;
+	unsigned int dtocyc, dtomul;
+	unsigned int shift;
+	u32 dtor;
+
+	e = csd->taac & 0x07;
+	m = (csd->taac >> 3) & 0x0f;
+
+	timeout_ns = (taac_exp[e] * taac_mant[m] + 9) / 10;
+	timeout_clks = csd->nsac * 100;
+
+	timeout_clks += (((timeout_ns + 9) / 10)
+			 * ((CFG_MMC_CLK_PP + 99999) / 100000) + 9999) /
10000;
+	if (!mmc_card_is_sd)
+		timeout_clks *= 10;
+	else
+		timeout_clks *= 100;
+
+	dtocyc = timeout_clks;
+	dtomul = 0;
+	while (dtocyc > 15 && dtomul < 8) {
+		dtomul++;
+		shift = dtomul_to_shift[dtomul];
+		dtocyc = (timeout_clks + (1 << shift) - 1) >> shift;
+	}
+
+	if (dtomul >= 8) {
+		dtomul = 7;
+		dtocyc = 15;
+		puts("Warning: Using maximum data timeout\n");
+	}
+
+	dtor = (MMCI_BF(DTOMUL, dtomul)
+		| MMCI_BF(DTOCYC, dtocyc));
+	mmci_writel(DTOR, dtor);
+
+	pr_debug("mmc: Using %u cycles data timeout (DTOR=0x%x)\n",
+	       dtocyc << shift, dtor);
+}
+
+int mmc_init(int verbose)
+{
+	struct mmc_cid cid;
+	struct mmc_csd csd;
+	unsigned int max_blksz;
+	int ret,aux;
+	
+	AT91F_MMC_Hardware_Init();
+	
+	pr_debug("0\n");
+	/* Initialize controller */
+	mmci_writel(CR, MMCI_BIT(SWRST));
+	mmci_writel(CR, MMCI_BIT(MCIEN));
+	mmci_writel(DTOR, 0x5f);
+	mmci_writel(IDR, ~0UL);
+	mmci_writel(SDCR, 0x1);
+	mci_set_mode(CFG_MMC_CLK_OD, MMC_DEFAULT_BLKLEN);
+/* 	//mmci_writel(CR, MMCI_BIT(SWRST));
+	mmci_writel(CR, 0x00000001);
+	mmci_writel(DTOR, 0x0000007F);
+	mmci_writel(IDR, 0xFFFFFFFF);
+	mmci_writel(SDCR, 0x00000001);
+	//mci_set_mode(CFG_MMC_CLK_OD, MMC_DEFAULT_BLKLEN);
+	mmci_writel(MR, 0x02009B4A); */
+
+	pr_debug("1\n");
+	
+	mmc_card_is_sd = 0;
+
+	ret = sd_init_card(&cid, verbose);
+	if (ret) {
+		mmc_rca = MMC_DEFAULT_RCA;
+		ret = mmc_init_card(&cid, verbose);
+	}
+	pr_debug("6\n");
+	if (ret)
+		return ret;
+	pr_debug("7\n");
+	/* Get CSD from the card */
+	ret = mmc_cmd(MMC_CMD_SEND_CSD, mmc_rca << 16, &csd, R2 | NCR);
+	if (ret)
+		return ret;
+	if (verbose)
+		mmc_dump_csd(&csd);
+
+	mci_set_data_timeout(&csd);
+
+	/* Initialize the blockdev structure */
+	mmc_blkdev.if_type = IF_TYPE_MMC;
+	mmc_blkdev.part_type = PART_TYPE_DOS;
+	mmc_blkdev.block_read = mmc_bread;
+	sprintf((char *)mmc_blkdev.vendor,
+		"Man %02x%04x Snr %08x",
+		cid.mid, cid.oid, cid.psn);
+	strncpy((char *)mmc_blkdev.product, cid.pnm,
+		sizeof(mmc_blkdev.product));
+	sprintf((char *)mmc_blkdev.revision, "%x %x",
+		cid.prv >> 4, cid.prv & 0x0f);
+
+	/*
+	 * If we can't use 512 byte blocks, refuse to deal with the
+	 * card. Tons of code elsewhere seems to depend on this.
+	 */
+	max_blksz = 1 << csd.read_bl_len;
+	// if (max_blksz < 512 || (max_blksz > 512 &&
!csd.read_bl_partial)) {
+		// pr_debug("Card does not support 512 byte reads,
aborting.\n");
+		// return -ENODEV;
+	// }
+	mmc_blkdev.blksz = 512;
+	mmc_blkdev.lba = (csd.c_size + 1) * (1 << (csd.c_size_mult +
2));
+
+	mci_set_mode(CFG_MMC_CLK_PP, mmc_blkdev.blksz);
+
+#if 0
+	if (fat_register_device(&mmc_blkdev, 1))
+		pr_debug("Could not register MMC fat device\n");
+#else
+	init_part(&mmc_blkdev);
+#endif
+
+	return 0;
+}
+
+int mmc_read(ulong src, uchar *dst, int size)
+{
+	return -ENOSYS;
+}
+
+int mmc_write(uchar *src, ulong dst, int size)
+{
+	return -ENOSYS;
+}
+
+int mmc2info(ulong addr)
+{
+	return 0;
+}
+
+#endif /* CONFIG_MMC */
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/atmel_mci.h
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/atmel_mci.h
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/atmel_mci.h	1970-01-01
01:00:00.000000000 +0100
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/atmel_mci.h
2007-08-17 10:43:17.000000000 +0200
@@ -0,0 +1,201 @@
+/*
+ * Copyright (C) 2005-2006 Atmel Corporation
+ *
+ * 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
+ */
+#ifndef __CPU_AT32AP_ATMEL_MCI_H__
+#define __CPU_AT32AP_ATMEL_MCI_H__
+
+/* Atmel MultiMedia Card Interface (MCI) registers */
+#define MMCI_CR					0x0000
+#define MMCI_MR					0x0004
+#define MMCI_DTOR				0x0008
+#define MMCI_SDCR				0x000c
+#define MMCI_ARGR				0x0010
+#define MMCI_CMDR				0x0014
+#define MMCI_RSPR				0x0020
+#define MMCI_RSPR1				0x0024
+#define MMCI_RSPR2				0x0028
+#define MMCI_RSPR3				0x002c
+#define MMCI_RDR				0x0030
+#define MMCI_TDR				0x0034
+#define MMCI_SR					0x0040
+#define MMCI_IER				0x0044
+#define MMCI_IDR				0x0048
+#define MMCI_IMR				0x004c
+
+/* Bitfields in CR */
+#define MMCI_MCIEN_OFFSET			0
+#define MMCI_MCIEN_SIZE				1
+#define MMCI_MCIDIS_OFFSET			1
+#define MMCI_MCIDIS_SIZE			1
+#define MMCI_PWSEN_OFFSET			2
+#define MMCI_PWSEN_SIZE				1
+#define MMCI_PWSDIS_OFFSET			3
+#define MMCI_PWSDIS_SIZE			1
+#define MMCI_SWRST_OFFSET			7
+#define MMCI_SWRST_SIZE				1
+
+/* Bitfields in MR */
+#define MMCI_CLKDIV_OFFSET			0
+#define MMCI_CLKDIV_SIZE			8
+#define MMCI_PWSDIV_OFFSET			8
+#define MMCI_PWSDIV_SIZE			3
+#define MMCI_RDPROOF_OFFSET			11
+#define MMCI_RDPROOF_SIZE			1
+#define MMCI_WRPROOF_OFFSET			12
+#define MMCI_WRPROOF_SIZE			1
+#define MMCI_PDCPADV_OFFSET			14
+#define MMCI_PDCPADV_SIZE			1
+#define MMCI_PDCMODE_OFFSET			15
+#define MMCI_PDCMODE_SIZE			1
+#define MMCI_BLKLEN_OFFSET			16
+#define MMCI_BLKLEN_SIZE			16
+
+/* Bitfields in DTOR */
+#define MMCI_DTOCYC_OFFSET			0
+#define MMCI_DTOCYC_SIZE			4
+#define MMCI_DTOMUL_OFFSET			4
+#define MMCI_DTOMUL_SIZE			3
+
+/* Bitfields in SDCR */
+#define MMCI_SCDSEL_OFFSET			0
+#define MMCI_SCDSEL_SIZE			4
+#define MMCI_SCDBUS_OFFSET			7
+#define MMCI_SCDBUS_SIZE			1
+
+/* Bitfields in ARGR */
+#define MMCI_ARG_OFFSET				0
+#define MMCI_ARG_SIZE				32
+
+/* Bitfields in CMDR */
+#define MMCI_CMDNB_OFFSET			0
+#define MMCI_CMDNB_SIZE				6
+#define MMCI_RSPTYP_OFFSET			6
+#define MMCI_RSPTYP_SIZE			2
+#define MMCI_SPCMD_OFFSET			8
+#define MMCI_SPCMD_SIZE				3
+#define MMCI_OPDCMD_OFFSET			11
+#define MMCI_OPDCMD_SIZE			1
+#define MMCI_MAXLAT_OFFSET			12
+#define MMCI_MAXLAT_SIZE			1
+#define MMCI_TRCMD_OFFSET			16
+#define MMCI_TRCMD_SIZE				2
+#define MMCI_TRDIR_OFFSET			18
+#define MMCI_TRDIR_SIZE				1
+#define MMCI_TRTYP_OFFSET			19
+#define MMCI_TRTYP_SIZE				2
+
+/* Bitfields in RSPRx */
+#define MMCI_RSP_OFFSET				0
+#define MMCI_RSP_SIZE				32
+
+/* Bitfields in SR/IER/IDR/IMR */
+#define MMCI_CMDRDY_OFFSET			0
+#define MMCI_CMDRDY_SIZE			1
+#define MMCI_RXRDY_OFFSET			1
+#define MMCI_RXRDY_SIZE				1
+#define MMCI_TXRDY_OFFSET			2
+#define MMCI_TXRDY_SIZE				1
+#define MMCI_BLKE_OFFSET			3
+#define MMCI_BLKE_SIZE				1
+#define MMCI_DTIP_OFFSET			4
+#define MMCI_DTIP_SIZE				1
+#define MMCI_NOTBUSY_OFFSET			5
+#define MMCI_NOTBUSY_SIZE			1
+#define MMCI_ENDRX_OFFSET			6
+#define MMCI_ENDRX_SIZE				1
+#define MMCI_ENDTX_OFFSET			7
+#define MMCI_ENDTX_SIZE				1
+#define MMCI_RXBUFF_OFFSET			14
+#define MMCI_RXBUFF_SIZE			1
+#define MMCI_TXBUFE_OFFSET			15
+#define MMCI_TXBUFE_SIZE			1
+#define MMCI_RINDE_OFFSET			16
+#define MMCI_RINDE_SIZE				1
+#define MMCI_RDIRE_OFFSET			17
+#define MMCI_RDIRE_SIZE				1
+#define MMCI_RCRCE_OFFSET			18
+#define MMCI_RCRCE_SIZE				1
+#define MMCI_RENDE_OFFSET			19
+#define MMCI_RENDE_SIZE				1
+#define MMCI_RTOE_OFFSET			20
+#define MMCI_RTOE_SIZE				1
+#define MMCI_DCRCE_OFFSET			21
+#define MMCI_DCRCE_SIZE				1
+#define MMCI_DTOE_OFFSET			22
+#define MMCI_DTOE_SIZE				1
+#define MMCI_OVRE_OFFSET			30
+#define MMCI_OVRE_SIZE				1
+#define MMCI_UNRE_OFFSET			31
+#define MMCI_UNRE_SIZE				1
+
+/* Constants for DTOMUL */
+#define MMCI_DTOMUL_1_CYCLE			0
+#define MMCI_DTOMUL_16_CYCLES			1
+#define MMCI_DTOMUL_128_CYCLES			2
+#define MMCI_DTOMUL_256_CYCLES			3
+#define MMCI_DTOMUL_1024_CYCLES			4
+#define MMCI_DTOMUL_4096_CYCLES			5
+#define MMCI_DTOMUL_65536_CYCLES		6
+#define MMCI_DTOMUL_1048576_CYCLES		7
+
+/* Constants for RSPTYP */
+#define MMCI_RSPTYP_NO_RESP			0
+#define MMCI_RSPTYP_48_BIT_RESP			1
+#define MMCI_RSPTYP_136_BIT_RESP		2
+
+/* Constants for SPCMD */
+#define MMCI_SPCMD_NO_SPEC_CMD			0
+#define MMCI_SPCMD_INIT_CMD			1
+#define MMCI_SPCMD_SYNC_CMD			2
+#define MMCI_SPCMD_INT_CMD			4
+#define MMCI_SPCMD_INT_RESP			5
+
+/* Constants for TRCMD */
+#define MMCI_TRCMD_NO_TRANS			0
+#define MMCI_TRCMD_START_TRANS			1
+#define MMCI_TRCMD_STOP_TRANS			2
+
+/* Constants for TRTYP */
+#define MMCI_TRTYP_BLOCK			0
+#define MMCI_TRTYP_MULTI_BLOCK			1
+#define MMCI_TRTYP_STREAM			2
+
+/* Bit manipulation macros */
+#define MMCI_BIT(name)					\
+	(1 << MMCI_##name##_OFFSET)
+#define MMCI_BF(name,value)				\
+	(((value) & ((1 << MMCI_##name##_SIZE) - 1))	\
+	 << MMCI_##name##_OFFSET)
+#define MMCI_BFEXT(name,value)				\
+	(((value) >> MMCI_##name##_OFFSET)\
+	 & ((1 << MMCI_##name##_SIZE) - 1))
+#define MMCI_BFINS(name,value,old)			\
+	(((old) & ~(((1 << MMCI_##name##_SIZE) - 1)	\
+		    << MMCI_##name##_OFFSET))		\
+	 | MMCI_BF(name,value))
+
+/* Register access macros */
+#define mmci_readl(reg)					\
+	readl((void *)MMCI_BASE + MMCI_##reg)
+#define mmci_writel(reg,value)				\
+	writel((value), (void *)MMCI_BASE + MMCI_##reg)
+	
+#endif /* __CPU_AT32AP_ATMEL_MCI_H__ */
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/config.mk
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/config.mk
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/config.mk	2007-08-21
17:06:35.000000000 +0200
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/config.mk
2007-08-16 13:34:14.000000000 +0200
@@ -19,10 +19,10 @@
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
-#
+#PLATFORM_RELFLAGS += $(call cc-option,-msoft-float,)
 
 PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8
-PLATFORM_RELFLAGS += $(call cc-option,-msoft-float,)
+PLATFORM_RELFLAGS += $(call cc-option,)
 
 PLATFORM_CPPFLAGS += -march=armv5te
 PLATFORM_CPPFLAGS += $(call cc-option,-mtune=arm926ejs,)
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/Makefile
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/Makefile
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/Makefile	2007-08-21
17:06:36.000000000 +0200
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/Makefile	2007-08-23
09:14:21.000000000 +0200
@@ -26,8 +26,8 @@
 LIB	= lib$(SOC).a
 
 
-OBJS	= serial.o interrupts.o usb_ohci.o lcd.o ether.o spi.o
-SOBJS   = 
+OBJS	= serial.o interrupts.o usb_ohci.o ether.o spi.o
+SOBJS   = atmel_mci.o
 
 all:	.depend $(LIB)
 
diff -burN u-boot-1.1.5/cpu/arm926ejs/at91sam926x/spi.c
u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/spi.c
--- u-boot-1.1.5/cpu/arm926ejs/at91sam926x/spi.c	2007-08-21
17:06:35.000000000 +0200
+++ u-boot-1.1.5.klk/cpu/arm926ejs/at91sam926x/spi.c	2007-08-23
10:36:47.000000000 +0200
@@ -184,6 +184,20 @@
 {
   unsigned int timeout;
   
+#ifdef CONFIG_AT91SAM9260EK
+  /* Configure PIO controllers to periph mode */
+  AT91F_PIO_CfgPeriph(AT91C_BASE_PIOA, // PIO controller base address
+		      ((unsigned int) AT91C_PA1_SPI0_MOSI) |
+		      ((unsigned int) AT91C_PA3_SPI0_NPCS0) |
+		      ((unsigned int) AT91C_PA0_SPI0_MISO) |
+		      ((unsigned int) AT91C_PA2_SPI0_SPCK), /*
Peripheral A */
+		      0); /* Peripheral B */
+  /* Configure PIO controllers to periph mode */
+  AT91F_PIO_CfgPeriph(AT91C_BASE_PIOC, /* PIO controller base address
*/
+		      0, /* Peripheral A */
+		      ((unsigned int) AT91C_PC11_SPI0_NPCS1)); /*
Peripheral B */
+#endif
+  
   pDesc->state = BUSY;
   
   /* Disable PDC TX and RX channels */
diff -burN u-boot-1.1.5/cpu/arm926ejs/config.mk
u-boot-1.1.5.klk/cpu/arm926ejs/config.mk
--- u-boot-1.1.5/cpu/arm926ejs/config.mk	2006-10-20
17:54:33.000000000 +0200
+++ u-boot-1.1.5.klk/cpu/arm926ejs/config.mk	2007-08-16
13:34:42.000000000 +0200
@@ -20,10 +20,10 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
-PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
-	-msoft-float
-
+#
+#PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8 \
+#	-msoft-float
+PLATFORM_RELFLAGS += -fno-strict-aliasing  -fno-common -ffixed-r8
 PLATFORM_CPPFLAGS += -march=armv4
 #
========================================================================
=
 #
diff -burN u-boot-1.1.5/disk/part.c u-boot-1.1.5.klk/disk/part.c
--- u-boot-1.1.5/disk/part.c	2006-10-20 17:54:33.000000000 +0200
+++ u-boot-1.1.5.klk/disk/part.c	2007-08-23 08:29:56.000000000
+0200
@@ -36,6 +36,7 @@
 #if ((CONFIG_COMMANDS & CFG_CMD_IDE)	|| \
      (CONFIG_COMMANDS & CFG_CMD_SCSI)	|| \
      (CONFIG_COMMANDS & CFG_CMD_USB)	|| \
+	 (CONFIG_COMMANDS & CFG_CMD_MMC)	|| \
      defined(CONFIG_MMC) || \
      defined(CONFIG_SYSTEMACE) )
 
@@ -126,6 +127,8 @@
 #if ((CONFIG_COMMANDS & CFG_CMD_IDE)	|| \
      (CONFIG_COMMANDS & CFG_CMD_SCSI)	|| \
      (CONFIG_COMMANDS & CFG_CMD_USB)	|| \
+	 (CONFIG_COMMANDS & CFG_CMD_MMC)	|| \
+     defined(CONFIG_MMC) || \
      defined(CONFIG_SYSTEMACE)          )
 
 #if defined(CONFIG_MAC_PARTITION) || \
diff -burN u-boot-1.1.5/include/asm-arm/arch-at91sam926x/mmc.h
u-boot-1.1.5.klk/include/asm-arm/arch-at91sam926x/mmc.h
--- u-boot-1.1.5/include/asm-arm/arch-at91sam926x/mmc.h	1970-01-01
01:00:00.000000000 +0100
+++ u-boot-1.1.5.klk/include/asm-arm/arch-at91sam926x/mmc.h
2007-08-17 10:44:42.000000000 +0200
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2004-2006 Atmel Corporation
+ *
+ * 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
+ */
+#ifndef __ASM_AVR32_MMC_H
+#define __ASM_AVR32_MMC_H
+
+struct mmc_cid {
+	unsigned long psn;
+	unsigned short oid;
+	unsigned char mid;
+	unsigned char prv;
+	unsigned char mdt;
+	char pnm[7];
+};
+
+struct mmc_csd
+{
+	u8	csd_structure:2,
+		spec_vers:4,
+		rsvd1:2;
+	u8	taac;
+	u8	nsac;
+	u8	tran_speed;
+	u16	ccc:12,
+		read_bl_len:4;
+	u64	read_bl_partial:1,
+		write_blk_misalign:1,
+		read_blk_misalign:1,
+		dsr_imp:1,
+		rsvd2:2,
+		c_size:12,
+		vdd_r_curr_min:3,
+		vdd_r_curr_max:3,
+		vdd_w_curr_min:3,
+		vdd_w_curr_max:3,
+		c_size_mult:3,
+		sector_size:5,
+		erase_grp_size:5,
+		wp_grp_size:5,
+		wp_grp_enable:1,
+		default_ecc:2,
+		r2w_factor:3,
+		write_bl_len:4,
+		write_bl_partial:1,
+		rsvd3:5;
+	u8	file_format_grp:1,
+		copy:1,
+		perm_write_protect:1,
+		tmp_write_protect:1,
+		file_format:2,
+		ecc:2;
+	u8	crc:7;
+	u8	one:1;
+};
+
+/* MMC Command numbers */
+#define MMC_CMD_GO_IDLE_STATE		0
+#define MMC_CMD_SEND_OP_COND		1
+#define MMC_CMD_ALL_SEND_CID 		2
+#define MMC_CMD_SET_RELATIVE_ADDR	3
+#define MMC_CMD_SD_SEND_RELATIVE_ADDR	3
+#define MMC_CMD_SET_DSR			4
+#define MMC_CMD_SELECT_CARD		7
+#define MMC_CMD_SEND_CSD 		9
+#define MMC_CMD_SEND_CID 		10
+#define MMC_CMD_SEND_STATUS		13
+#define MMC_CMD_SET_BLOCKLEN		16
+#define MMC_CMD_READ_SINGLE_BLOCK	17
+#define MMC_CMD_READ_MULTIPLE_BLOCK	18
+#define MMC_CMD_WRITE_BLOCK		24
+#define MMC_CMD_APP_CMD			55
+
+#define MMC_ACMD_SD_SEND_OP_COND	41
+
+#define R1_ILLEGAL_COMMAND		(1 << 22)
+#define R1_APP_CMD			(1 << 5)
+
+#endif /* __ASM_AVR32_MMC_H */
diff -burN u-boot-1.1.5/include/configs/at91sam9260ek.h
u-boot-1.1.5.klk/include/configs/at91sam9260ek.h
--- u-boot-1.1.5/include/configs/at91sam9260ek.h	2007-08-21
17:06:36.000000000 +0200
+++ u-boot-1.1.5.klk/include/configs/at91sam9260ek.h	2007-08-23
10:51:43.000000000 +0200
@@ -88,6 +88,8 @@
                         CFG_CMD_FLASH | \
 			CFG_CMD_AUTOSCRIPT | \
                         CFG_CMD_NAND | \
+						CFG_CMD_MMC | \
+						CFG_CMD_EXT2 | \
                         CFG_CMD_FAT ) & \
 		      ~(CFG_CMD_BDI | \
 			CFG_CMD_IMLS | \
@@ -225,6 +227,7 @@
 #undef  CFG_ENV_IS_IN_FLASH
 #define	CFG_ENV_IS_IN_DATAFLASH         1
 #undef CFG_ENV_IS_IN_NAND              
+#undef CFG_ENV_IS_NOWHERE
 
 /*#define CONFIG_MTD_DEBUG		1
 #define CONFIG_MTD_DEBUG_VERBOSE	MTD_DEBUG_LEVEL3
@@ -241,6 +244,10 @@
 #define CFG_ENV_SIZE			0x4000  /* 0x8000 */
 #endif
 
+#ifdef CFG_ENV_IS_NOWHERE
+#define CFG_ENV_SIZE			0x4000
+#endif
+
 #ifdef CFG_ENV_IS_IN_FLASH
 #ifdef CONFIG_BOOTBINFUNC
 #define CFG_ENV_ADDR			(PHYS_FLASH_1 + 0x60000)  /*
after u-boot.bin */
@@ -257,6 +264,10 @@
 #define CONFIG_DOS_PARTITION	        1
 #define LITTLEENDIAN 			1
 
+/* MMC */
+#define CONFIG_MMC		1
+#define MMCI_BASE		0xFFFA8000
+
 #define CFG_LOAD_ADDR		0x23f00000  /* default load address */
 
 #ifdef CONFIG_BOOTBINFUNC

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users




From sr at denx.de  Thu Apr 24 08:27:20 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 08:27:20 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <20080423151258.7ac66064@peedub.jennejohn.org>
References: <20080423151258.7ac66064@peedub.jennejohn.org>
Message-ID: <200804240827.20526.sr@denx.de>

On Wednesday 23 April 2008, Gary Jennejohn wrote:
> Add the Harris QUAD100HD AMCC 405EP-based board.

Please find some comments below.

<snip>

> Signed-off-by: Gary Jennejohn <garyj at denx.de>
> ---
> diff --git a/board/quad100hd/nand.c b/board/quad100hd/nand.c
> new file mode 100644
> index 0000000..964dd4b
> --- /dev/null
> +++ b/board/quad100hd/nand.c
> @@ -0,0 +1,156 @@
> +/*
> + * (C) Copyright 2008
> + * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de
> + *
> + * Based on board/icecube/ice_nand.c from PPCBoot (no copyright
> + * notice).
> + *
> + * 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 <common.h>
> +#include <config.h>
> +#if defined(CONFIG_CMD_NAND)
> +#include <ppc405.h>
> +#include <asm/io.h>
> +#include <nand.h>
> +
> +#define _BITMASK(i) (((unsigned)0x80000000) >> (i))
> +
> +#define GPIO_OUT	1
> +#define GPIO_IN		2
> +#define GPIO_GPIO	4
> +#define GPIO_ALT	8
> +
> +typedef struct quad100hd_gpio_regs {
> +	volatile u32 gpio_or;
> +	volatile u32 gpio_tcr;
> +	volatile u32 gpio_osrh;
> +	volatile u32 gpio_osrl;
> +	volatile u32 gpio_tsrh;
> +	volatile u32 gpio_tsrl;
> +	volatile u32 gpio_odr;
> +	volatile u32 gpio_ir;
> +	volatile u32 gpio_rr;
> +	volatile u32 gpio_isrh;
> +	volatile u32 gpio_isrl;
> +} quad100hd_gpio_t;
> +
> +static struct quad100hd_gpio_regs *quad100hd_gpio = NULL;
> +
> +static void inline set_gpio_dr(volatile u32 *reg_adr, int gpio, int set)
> +{

There is a function for this already available. Please take a look at 
gpio_write_bit() in cpu/ppc4xx/gpio.c.

> +
> +	if (gpio > 15) {
> +		++reg_adr;   /* point to osrl */
> +		gpio -= 16;
> +	}
> +	gpio <<= 1;
> +	if (set) {
> +		*reg_adr &= ~_BITMASK(gpio);

And don't access the GPIO registers via volatile pointers. Use the in/out_be32
() functions instead.

> +		*reg_adr |=  _BITMASK(gpio + 1);
> +	} else {
> +		*reg_adr &= ~(_BITMASK(gpio) | _BITMASK(gpio + 1));
> +	}
> +}
> +
> +static void inline set_gpio(quad100hd_gpio_t * gpio, int gpio_pin, int
> func) +{

This function is also already available: gpio_config(). Could be that this 
function needs some changes for 405EP since it has never been tested on this 
platform before.

> +	gpio->gpio_odr &= ~_BITMASK(gpio_pin);
> +	if (func & GPIO_OUT)
> +		gpio->gpio_tcr |= _BITMASK(gpio_pin);
> +	else
> +		gpio->gpio_tcr &= ~_BITMASK(gpio_pin);
> +	set_gpio_dr(&gpio->gpio_osrh, gpio_pin, func & GPIO_ALT);
> +	set_gpio_dr(&gpio->gpio_tsrh, gpio_pin, 0);
> +}
> +
> +static int quad100hd_init_nand_gpio(void)
> +{
> +	quad100hd_gpio = (struct quad100hd_gpio_regs *) GPIO_BASE;
> +
> +	set_gpio(quad100hd_gpio, CFG_NAND_CS, GPIO_ALT | GPIO_OUT);
> +	set_gpio(quad100hd_gpio, CFG_NAND_ALE, GPIO_GPIO | GPIO_OUT);
> +	set_gpio(quad100hd_gpio, CFG_NAND_CLE, GPIO_GPIO | GPIO_OUT);
> +	set_gpio(quad100hd_gpio, CFG_NAND_CE, GPIO_GPIO | GPIO_OUT);
> +	set_gpio(quad100hd_gpio, CFG_NAND_RDY, GPIO_GPIO | GPIO_IN);
> +
> +	return 0;
> +}
> +
> +/*
> + *	hardware specific access to control-lines
> + */
> +static void quad100hd_hwcontrol(struct mtd_info *mtd, int cmd)
> +{
> +	switch(cmd) {
> +	case NAND_CTL_SETCLE:
> +		quad100hd_gpio->gpio_or |= _BITMASK(CFG_NAND_CLE);
> +		eieio();

Please use this instead:

		gpio_write_bit(CFG_NAND_CLE, 1);

No need for the eieio() then.

> +		break;
> +	case NAND_CTL_CLRCLE:
> +		quad100hd_gpio->gpio_or &= ~_BITMASK(CFG_NAND_CLE);
> +		eieio();

		gpio_write_bit(CFG_NAND_CLE, 0);

> +		break;
> +
> +	case NAND_CTL_SETALE:
> +		quad100hd_gpio->gpio_or |= _BITMASK(CFG_NAND_ALE);
> +		eieio();

here too...

> +		break;
> +	case NAND_CTL_CLRALE:
> +		quad100hd_gpio->gpio_or &= ~_BITMASK(CFG_NAND_ALE);
> +		eieio();
> +		break;
> +
> +	case NAND_CTL_SETNCE:
> +		quad100hd_gpio->gpio_or &= ~_BITMASK(CFG_NAND_CE);
> +		eieio();
> +		break;
> +	case NAND_CTL_CLRNCE:
> +		quad100hd_gpio->gpio_or |= _BITMASK(CFG_NAND_CE);
> +		eieio();
> +		break;
> +	}
> +}
> +
> +static int quad100hd_nand_ready(struct mtd_info *mtd)
> +{
> +	return (quad100hd_gpio->gpio_ir & _BITMASK(CFG_NAND_RDY) ? 1 : 0);

gpio_read_in_bit()

> +}
> +
> +
> +/*
> + * Main initialization routine
> + */
> +int board_nand_init(struct nand_chip *nand)
> +{
> +	quad100hd_init_nand_gpio();
> +
> +	/* Set address of hardware control function */
> +	nand->hwcontrol = quad100hd_hwcontrol;
> +	nand->dev_ready = quad100hd_nand_ready;
> +	nand->eccmode = NAND_ECC_SOFT;
> +	/* 15 us command delay time */
> +	nand->chip_delay =  20;
> +
> +	/* Return happy */
> +	return 0;
> +}
> +#endif /* CONFIG_CMD_NAND */
> diff --git a/board/quad100hd/quad100hd.c b/board/quad100hd/quad100hd.c
> new file mode 100644
> index 0000000..fbe9274
> --- /dev/null
> +++ b/board/quad100hd/quad100hd.c
> @@ -0,0 +1,113 @@
> +/*
> + * (C) Copyright 2008
> + * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
> + *
> + * Based in part on board/icecube/icecube.c from PPCBoot
> + * (C) Copyright 2003 Intrinsyc Software
> + *
> + * 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 <common.h>
> +#include <command.h>
> +#include <malloc.h>
> +#include <environment.h>
> +#include <logbuff.h>
> +#include <post.h>
> +
> +#include <asm/processor.h>
> +#include <asm/io.h>
> +#include <asm/gpio.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +int board_early_init_f(void)
> +{
> +	/* taken from ppcboot */
> +	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
> +	mtdcr(uicer, 0x00000000);	/* disable all ints */
> +	mtdcr(uiccr, 0x00000000);
> +	mtdcr(uicpr, 0xFFFF7FFE);	/* set int polarities */
> +	mtdcr(uictr, 0x00000000);	/* set int trigger levels */
> +	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
> +	mtdcr(uicvcr, 0x00000001);	/* set vect base=0,INT0 highest priority */
> +
> +#define cpc0_srr (CNTRL_DCR_BASE+0x6)

Please don't put #defines in functions. And this is already defined:

CPC0_SRR.

> +    	mtdcr (cpc0_srr, 0x00040000);   /* Hold PCI bridge in reset */
> +
> +	return 0;
> +}
> +
> +/*
> + * Check Board Identity:
> + */
> +int checkboard(void)
> +{
> +	char *s = getenv("serial#");
> +#ifdef DISPLAY_BOARD_INFO
> +	sys_info_t sysinfo;
> +#endif
> +
> +	puts("Board: Quad100hd");
> +
> +	if (s != NULL) {
> +		puts(", serial# ");
> +		puts(s);
> +	}
> +	putc('\n');
> +
> +#ifdef DISPLAY_BOARD_INFO
> +	/* taken from ppcboot */
> +	get_sys_info (&sysinfo);
> +
> +	printf("\tVCO: %lu MHz\n", sysinfo.freqVCOMhz);
> +	printf("\tCPU: %lu MHz\n", sysinfo.freqProcessor / 1000000);
> +	printf("\tPLB: %lu MHz\n", sysinfo.freqPLB / 1000000);
> +	printf("\tOPB: %lu MHz\n", sysinfo.freqOPB / 1000000);
> +	printf("\tEPB: %lu MHz\n", sysinfo.freqPLB / (sysinfo.pllExtBusDiv *
> +		1000000));
> +	printf ("\tPCI: %lu MHz\n", sysinfo.freqPCI / 1000000);
> +#endif
> +
> +	return (0);
> +}
> +
> +/* taken from ppcboot */
> +long int init_sdram_static_settings(void)
> +{
> +#define mtsdram0(reg, data)  mtdcr(memcfga,reg);mtdcr(memcfgd,data)
> +	/* disable memcontroller so updates work */
> +	mtsdram0( mem_mcopt1, 0x00A00000);
> +	mtsdram0( mem_rtr   , 0x05f00000);
> +	mtsdram0( mem_pmit  , 0x07C00000);
> +	mtsdram0( mem_mb0cf , 0x00062001);
> +	mtsdram0( mem_mb1cf , 0x00000000);
> +	mtsdram0( mem_sdtr1 , 0x010b401a);
> +	/* SDRAM have a power on delay,  500 micro should do */
> +	udelay(500);
> +	mtsdram0( mem_mcopt1, 0x00A00000|0x80000000);
> +	udelay(500);
> +
> +	return (CFG_SDRAM_SIZE);
> +}

Is this fixed SDRAM init really needed? Did you take a look at 
cpu/ppc4xx/sdram.c. This should handle your setup probably too. You need to 
define:

#define CONFIG_SDRAM_BANK0      1       /* init onboard SDRAM bank 0 */

in you board config file for it.

<snip>

> diff --git a/include/configs/quad100hd.h b/include/configs/quad100hd.h
> new file mode 100644
> index 0000000..6f84878
> --- /dev/null
> +++ b/include/configs/quad100hd.h
> @@ -0,0 +1,306 @@
> +/*
> + * (C) Copyright 2008
> + * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +/************************************************************************
> + * quad100hd.h - configuration for Quad100hd board
> + ***********************************************************************/
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +/*-----------------------------------------------------------------------
> + * High Level Configuration Options
> + *----------------------------------------------------------------------*/
> +#define CONFIG_QUAD100HD	1		/* Board is Quad100hd	*/
> +#define CONFIG_4xx		1		/* ... PPC4xx family	*/
> +#define CONFIG_405EP		1		/* Specifc 405EP support*/
> +
> +#define CONFIG_SYS_CLK_FREQ     33333333 /* external frequency to pll   */
> +
> +#define CONFIG_BOARD_EARLY_INIT_F 1		/* Call board_early_init_f */
> +
> +#define PLLMR0_DEFAULT		PLLMR0_266_133_66 /* no PCI */
> +#define PLLMR1_DEFAULT		PLLMR1_266_133_66 /* no PCI */
> +
> +#define CFG_ENV_IS_IN_EEPROM    1   /* use the EEPROM for environment vars
> */ +
> +#define CONFIG_OVERWRITE_ETHADDR_ONCE	1
> +
> +#define CONFIG_NET_MULTI	1
> +#define CONFIG_HAS_ETH1		1
> +#define CONFIG_MII		1	/* MII PHY management		*/
> +#define CONFIG_PHY_ADDR		0x01	/* PHY address			*/
> +#define CFG_RX_ETH_BUFFER	16	/* Number of ethernet rx buffers &
> descriptors */ +#define CONFIG_PHY_RESET	1
> +#define CONFIG_PHY_RESET_DELAY	300	/* PHY RESET recovery delay	*/
> +
> +/*
> + * Command line configuration.
> + */
> +#include <config_cmd_default.h>
> +
> +#undef CONFIG_CMD_ASKENV
> +#undef CONFIG_CMD_CACHE
> +#define CONFIG_CMD_DHCP
> +#undef CONFIG_CMD_DIAG
> +#define CONFIG_CMD_EEPROM
> +#undef CONFIG_CMD_ELF
> +#define CONFIG_CMD_I2C
> +#undef CONFIG_CMD_IRQ
> +#define CONFIG_CMD_JFFS2
> +#undef CONFIG_CMD_LOG
> +#undef CONFIG_CMD_MII
> +#define CONFIG_CMD_NAND
> +#undef CONFIG_CMD_PING
> +#define CONFIG_CMD_REGINFO
> +
> +#undef CONFIG_WATCHDOG			/* watchdog disabled		*/
> +
> +/*-----------------------------------------------------------------------
> + * SDRAM
> + *----------------------------------------------------------------------*/
> +/*
> + * SDRAM configuration (please see cpu/ppc/sdram.[ch])
> + */
> +#define CONFIG_SDRAM_BANK0  1
> +#define CFG_SDRAM_SIZE      0x02000000      /* 32 MB */

So you are using the common SDRAM init code already. And some board specific 
code too. I'm not sure but it could be that you SDRAM is now initialized 
twice. Please double-check this.

> +/* FIX! SDRAM timings used in datasheet */
> +#define CFG_SDRAM_CL            3       /* CAS latency */
> +#define CFG_SDRAM_tRP           20      /* PRECHARGE command period */
> +#define CFG_SDRAM_tRC           66      /* ACTIVE-to-ACTIVE command period
> */ +#define CFG_SDRAM_tRCD          20      /* ACTIVE-to-READ delay */
> +#define CFG_SDRAM_tRFC          66      /* Auto refresh period */ +
> +/*
> + * JFFS2
> + */
> +#define CFG_JFFS2_FIRST_BANK    0
> +#ifdef  CFG_KERNEL_IN_JFFS2
> +#define CFG_JFFS2_FIRST_SECTOR  0   /* JFFS starts at block 0 */
> +#else /* kernel not in JFFS */
> +#define CFG_JFFS2_FIRST_SECTOR  8   /* block 0-7 is kernel (1MB = 8
> sectors) */ +#endif
> +#define CFG_JFFS2_NUM_BANKS     1
> +
> +/*-----------------------------------------------------------------------
> + * Serial Port
> + *----------------------------------------------------------------------*/
> +#undef	CFG_EXT_SERIAL_CLOCK			/* external serial clock */
> +#define CFG_BASE_BAUD		691200
> +#define CONFIG_BAUDRATE		115200
> +#define CONFIG_SERIAL_MULTI
> +
> +/* The following table includes the supported baudrates */
> +#define CFG_BAUDRATE_TABLE	\
> +	{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
> +
> +/*-----------------------------------------------------------------------
> + * Miscellaneous configurable options
> + *----------------------------------------------------------------------*/
> +#define CFG_LONGHELP			/* undef to save memory		*/
> +#define CFG_PROMPT	        "=> "	/* Monitor Command Prompt	*/
> +#if defined(CONFIG_CMD_KGDB)
> +#define CFG_CBSIZE	        1024	/* Console I/O Buffer Size	*/
> +#else
> +#define CFG_CBSIZE	        256	/* Console I/O Buffer Size	*/
> +#endif
> +#define CFG_PBSIZE              (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /*
> Print Buffer Size */ +#define CFG_MAXARGS	        16	/* max number of
> command args	*/
> +#define CFG_BARGSIZE	        CFG_CBSIZE /* Boot Argument Buffer Size	*/
> +
> +#define CFG_MEMTEST_START	0x0400000 /* memtest works on		*/
> +#define CFG_MEMTEST_END		0x0C00000 /* 4 ... 12 MB in DRAM	*/
> +
> +#define CFG_LOAD_ADDR		0x100000  /* default load address	*/
> +#define CFG_EXTBDINFO		1	/* To use extended board_info (bd_t) */
> +
> +#define CFG_HZ		        1000	/* decrementer freq: 1 ms ticks	*/
> +
> +#define CONFIG_LOADS_ECHO	1	/* echo on for serial download	*/
> +#define CFG_LOADS_BAUD_CHANGE	1	/* allow baudrate change	*/
> +
> +#define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
> +#define CONFIG_LOOPW            1       /* enable loopw command         */
> +#define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands      */
> +#define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0
> */ +#define CONFIG_VERSION_VARIABLE 1	/* include version env variable */ +
> +/*-----------------------------------------------------------------------
> + * I2C
> + *----------------------------------------------------------------------*/
> +#define CONFIG_HARD_I2C		1		/* I2C with hardware support	*/
> +#undef	CONFIG_SOFT_I2C				/* I2C bit-banged		*/
> +#define CFG_I2C_SPEED		400000		/* I2C speed and slave address	*/
> +#define CFG_I2C_SLAVE		0x7F
> +
> +#define CFG_I2C_EEPROM_ADDR	0x50		/* base address */
> +#define CFG_I2C_EEPROM_ADDR_LEN	2		/* bytes of address */
> +
> +#define CFG_EEPROM_PAGE_WRITE_BITS	5	/* 8 byte write page size */
> +#define CFG_EEPROM_PAGE_WRITE_DELAY_MS	10	/* and takes up to 10 msec */
> +#define CFG_EEPROM_SIZE			0x2000
> +
> +/*-----------------------------------------------------------------------
> + * Start addresses for the final memory configuration
> + * (Set up by the startup code)
> + * Please note that CFG_SDRAM_BASE _must_ start at 0
> + */
> +#define CFG_SDRAM_BASE		0x00000000
> +#define CFG_FLASH_BASE		0xFFC00000
> +#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Monitor	*/
> +#define CFG_MALLOC_LEN		(128 * 1024)	/* Reserve 128 kB for malloc()	*/
> +#define CFG_MONITOR_BASE	0xFFF80000
> +
> +/*
> + * For booting Linux, the board info and command line data
> + * have to be in the first 8 MB of memory, since this is
> + * the maximum mapped by the Linux kernel during initialization.
> + */
> +#define CFG_BOOTMAPSZ		(8 << 20)	/* Initial Memory map for Linux */
> +
> +/*-----------------------------------------------------------------------
> + * FLASH organization
> + */
> +#define CFG_FLASH_CFI			/* The flash is CFI compatible	*/

You are using the CFI driver *and* a board specific driver too. Why is this ?

> +#define CFG_FLASH_BANKS_LIST	{ CFG_FLASH_BASE }
> +
> +#define CFG_MAX_FLASH_BANKS	1	/* max number of memory banks	*/
> +#define CFG_MAX_FLASH_SECT	128	/* max number of sectors on one chip */
> +#define CFG_FLASH_WORD_SIZE	unsigned short
> +#define CFG_FLASH_ADDR0		0x0555
> +#define CFG_FLASH_ADDR1		0x02aa
> +#define FLASH_BASE0_PRELIM	CFG_FLASH_BASE	/* FLASH bank #0	*/
> +
> +#define CFG_FLASH_ERASE_TOUT	120000	/* Timeout for Flash Erase (in ms) */
> +#define CFG_FLASH_WRITE_TOUT	500	/* Timeout for Flash Write (in ms) */
> +
> +#define CFG_FLASH_USE_BUFFER_WRITE 1	/* use buffered writes (20x faster)
> */ +#define CFG_FLASH_INCREMENT      0       /* there is only one bank     
>    */ +
> +#define CFG_FLASH_EMPTY_INFO		/* print 'E' for empty sector on flinfo */
> +#define CFG_FLASH_QUIET_TEST	1	/* don't warn upon unknown flash */
> +
> +#ifdef CFG_ENV_IS_IN_FLASH
> +#define CFG_ENV_SECT_SIZE	0x10000	/* size of one complete sector	*/
> +#define	CFG_ENV_SIZE		0x10000	/* Total Size of Environment Sector */
> +#define CFG_ENV_OFFSET		0x00050000 /* Offset of Environment Sector  */
> +#define CFG_ENV_ADDR		(CFG_FLASH_BASE + CFG_ENV_OFFSET)
> +#endif
> +
> +#ifdef CFG_ENV_IS_IN_EEPROM
> +#define CFG_ENV_SIZE		0x400		/* Size of Environment vars */
> +#define CFG_ENV_OFFSET		0x00000000
> +#define CFG_ENABLE_CRC_16	1       /* Intrinsyc formatting used crc16 */
> +#endif
> +
> +/* from PPCBoot */
> +/* NAND */
> +#define CONFIG_NAND
> +#ifdef CONFIG_NAND
> +#define CFG_NAND_BASE   0x60000000
> +#define SECTORSIZE	512
> +#define ADDR_COLUMN	1
> +#define ADDR_PAGE	2
> +#define NAND_MAX_FLOORS	1
> +#define NAND_MAX_CHIPS	1
> +#define CFG_NAND_CS	10   /* our CS is GPIO10 */
> +#define CFG_NAND_RDY	23   /* our RDY is GPIO23 */
> +#define CFG_NAND_CE	24   /* our CE is GPIO24  */
> +#define CFG_NAND_CLE	31   /* our CLE is GPIO31 */
> +#define CFG_NAND_ALE	30   /* our ALE is GPIO30 */
> +#define CFG_MAX_NAND_DEVICE	1
> +#define ADDR_COLUMN_PAGE	3
> +#define NAND_ChipID_UNKNOWN	0x00

Some of those defines are not needed anymore. I suspect that the following 
defines can be removed:

> +#define SECTORSIZE	512
> +#define ADDR_COLUMN	1
> +#define ADDR_PAGE	2
> +#define NAND_MAX_FLOORS	1
> +#define NAND_MAX_CHIPS	1
> +#define ADDR_COLUMN_PAGE	3
> +#define NAND_ChipID_UNKNOWN	0x00

Please check if they are needed and remove them if not needed.

> +#endif
> +
> +/*-----------------------------------------------------------------------
> + * Definitions for initial stack pointer and data area (in data cache)
> + */
> +/* use on chip memory (OCM) for temperary stack until sdram is tested */
> +/* see ./cpu/ppc4xx/start.S */
> +#define CFG_TEMP_STACK_OCM	1
> +
> +/* On Chip Memory location */
> +#define CFG_OCM_DATA_ADDR	0xF8000000
> +#define CFG_OCM_DATA_SIZE	0x1000
> +#define CFG_INIT_RAM_ADDR	CFG_OCM_DATA_ADDR /* inside of OCM		*/
> +#define CFG_INIT_RAM_END	CFG_OCM_DATA_SIZE /* End of used area in RAM	*/
> +
> +#define CFG_GBL_DATA_SIZE	128  /* size in bytes reserved for initial data
> */ +#define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
> +#define CFG_INIT_SP_OFFSET      CFG_GBL_DATA_OFFSET
> +
> +/*-----------------------------------------------------------------------
> + * External Bus Controller (EBC) Setup
> + * Taken from PPCBoot board/icecube/icecube.h
> + */
> +
> +/* see ./cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/ndfc.c */
> +#define CFG_EBC_PB0AP		0x04002480
> +/* AMD NOR flash - this corresponds to FLASH_BASE so may be correct */
> +#define CFG_EBC_PB0CR		0xFFC5A000
> +#define CFG_EBC_PB1AP           0x04005480
> +#define CFG_EBC_PB1CR           0x60018000
> +#define CFG_EBC_PB2AP           0x00000000
> +#define CFG_EBC_PB2CR           0x00000000
> +#define CFG_EBC_PB3AP           0x00000000
> +#define CFG_EBC_PB3CR           0x00000000
> +#define CFG_EBC_PB4AP           0x00000000
> +#define CFG_EBC_PB4CR           0x00000000
> +
> +/*-----------------------------------------------------------------------
> + * Definitions for GPIO setup (PPC405EP specific)
> + *
> + * Taken from PPCBoot board/icecube/icecube.h
> + */
> +/* see ./cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/start.S */
> +#define CFG_GPIO0_OSRH		0x55555550
> +#define CFG_GPIO0_OSRL		0x00000110
> +#define CFG_GPIO0_ISR1H		0x00000000
> +#define CFG_GPIO0_ISR1L		0x15555445
> +#define CFG_GPIO0_TSRH		0x00000000
> +#define CFG_GPIO0_TSRL		0x00000000
> +#define CFG_GPIO0_TCR		0xFFFF8014
> +#define CFG_GPIO0_ODR		0x00000000
> +
> +#if defined(CONFIG_CMD_KGDB)
> +#define CONFIG_KGDB_BAUDRATE	230400		/* speed to run kgdb serial port */
> +#define CONFIG_KGDB_SER_INDEX	2		/* which serial port to use */
> +#endif
> +
> +/* ENVIRONMENT VARS */
> +
> +#define CONFIG_IPADDR		192.168.1.67
> +#define CONFIG_SERVERIP		192.168.1.50
> +#define CONFIG_GATEWAYIP	192.168.1.1
> +#define CONFIG_NETMASK		255.255.255.0
> +#define CONFIG_ETHADDR 		00:01:02:03:04:05
> +#define CONFIG_ETH1ADDR		00:01:02:03:04:06

Are you really sure that you want to provide default MAC-addresses? We usually 
don't do this.

> +#define CONFIG_LOADADDR		300000
> +#define CONFIG_BOOTDELAY	5	/* autoboot after 5 seconds */
> +
> +/* pass open firmware flat tree */
> +#define CONFIG_OF_LIBFDT	1
> +
> +#endif	/* __CONFIG_H */

Please fix the issues and resumbit.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From trimarchi at gandalf.sssup.it  Thu Apr 24 09:59:57 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 24 Apr 2008 09:59:57 +0200
Subject: [U-Boot-Users] USB SUPPORT & get_vfatname
In-Reply-To: <AA28F077645B324881335614E4F7C428034CDB@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CDB@win-ex01.bench.com>
Message-ID: <48103DFD.1050500@gandalf.sssup.it>

Ken.Fuchs at bench.com wrote:
Ok,

check your fat.h and your fsdata


typedef struct {
        __u8    fatbuf[FATBUFSIZE]; /* Current FAT buffer */
        int     fatsize;        /* Size of FAT in bits */
        __u16   fatlength;      /* Length of FAT in sectors */
        __u16   fat_sect;       /* Starting sector of the FAT */
        __u16   rootdir_sect;   /* Start sector of root directory */
        __u16   clust_size;     /* Size of clusters in sectors */
        short   data_begin;     /* The sector of the first cluster, can 
be negative */
        int     fatbufnum;      /* Used by get_fatent, init to -1 */
} fsdata;

The fatbuf is on the top?

Regards Michael



> Michael,
>
> Sorry, your latest get_vfatname patch doesn't work either.
>
> FAT16 works perfectly, so the USB code is probably _not_ at fault.  I see only problems with FAT32, but only for _some_ long collections of files.
>
> Thus, there may still be a problem with fs/fat/fat.c.  Maybe there is something wrong with my copy of fat.c  I attached it;  Perhaps you can see a problem with it.
>
> Sincerely,
>
> Ken Fuchs
>
>   
>> -----Original Message-----
>> From: michael [mailto:trimarchi at gandalf.sssup.it] 
>> Sent: Wednesday, April 23, 2008 06:16
>> To: michael
>> Cc: Fuchs, Ken; u-boot-users at lists.sourceforge.net; Wolfgang Denk
>> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
>>
>>
>> Hi,
>>
>> michael wrote:
>>     
>>> Hi,
>>>
>>> Can you try this one?
>>>
>>> Revert my last one patch?
>>> It change the test code, before the while. I use your script on a 
>>> Compact Flash and it looks fine for me (under linux).
>>>
>>> Regards Michael
>>>
>>>
>>>       
>> --------------------------------------------------------------
>> ----------
>>     
>>> Check if the entry is a valid dir_slot entry, otherwise it 
>>>       
>> is a dentry and the
>>     
>>> name has to be taken by the get_name function
>>>
>>> Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>
>>>
>>> ---
>>>  fs/fat/fat.c |    7 +++++++
>>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
>>> index 49c78ed..bc37cec 100644
>>> --- a/fs/fat/fat.c
>>> +++ b/fs/fat/fat.c
>>> @@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int 
>>>       
>> curclust, __u8 *cluster,
>>     
>>>  		while (slotptr2->id > 0x01) {
>>>  			slotptr2++;
>>>  		}
>>> +
>>>  		/* Save the real directory entry */
>>>  		realdent = (dir_entry*)slotptr2 + 1;
>>> +		if (slotptr2->attr != ATTR_VFAT) {
>>> +			get_name ((dir_entry *)realdent, l_name);
>>> +			goto out;
>>> +		}
>>> +
>>>  		while ((__u8*)slotptr2 >= get_vfatname_block) {
>>>  			slot2str(slotptr2, l_name, &idx);
>>>  			slotptr2--;
>>> @@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int 
>>>       
>> curclust, __u8 *cluster,
>>     
>>>  	else if (*l_name == aRING) *l_name = '?';
>>>  	downcase(l_name);
>>>  
>>> +out:
>>>  	/* Return the real directory entry */
>>>  	memcpy(retdent, realdent, sizeof(dir_entry));
>>>  
>>>   
>>>       
>> The scripts in this thread can be used to test the fat32 
>> filesystem. I 
>> do some tests using Compact Flash
>> device and this patchs work for me. I would like to know if is a fat 
>> layer problem or usb layer problem.
>>
>> Michael
>>
>>
>>     




From tur at semihalf.com  Thu Apr 24 11:01:09 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Thu, 24 Apr 2008 11:01:09 +0200
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
In-Reply-To: <480FF63C.2030407@miraclelinux.com>
References: <480FF63C.2030407@miraclelinux.com>
Message-ID: <48104C55.6020107@semihalf.com>

Makito SHIOKAWA wrote:
> Boot Image Fallback is a mechanism that enables a system to fallback to a
> "known good" boot image in the event of catastrophic boot failure (i.e.
> failure to boot, panic on boot, failure to initialize HW/SW). (CGL
> Availability Requirements Definition V4.0: AVL.9.0). On system especially used
> in telecommunication, 99.999% high availability is required. So, this function
> is highly needed (like my customer requires).
> 
> This time, I'm thinking of implementing Boot Image Fallback on U-Boot as
> follows (like a way GRUB does). So, I would appreciate any comments to this.
> 
> 
> It uses new U-Boot command "bootmf" and fw_setenv.
> 
> * bootmf
> 
> It is a wrapper of "bootm", and it boots kernel with fallback enabled on
> multiple kernel images.

Hello,

You might want to have a look an the new image format introduced
recently. It allows you to have multiple kernels (and ramdisks, and
other types of images) in one image file, and access these components in
elegant way. Have a look in doc/uImage.FIT/. In particular,
doc/uImage.FIT/command_syntax_extensions.txt describes new syntax that
you might find useful.

> 
> 
> Also, it uses new U-Boot environment variables as follows.
> 
> * imgaddr<N>
> 
> It holds physical address of flash partition that kernel image is written. <N>
> is integer and becomes an entry of corresponding kernel image.
> 
> (ex.) imgaddr0=0xf8000000, imgaddr1=0xf8200000

This is where you may want to consider the new syntax mentioned above.

> 
> * bootargs<N>
> 
> It holds kernel parameter of entry <N>.

And here too.

> 
> (ex.) bootargs0=root=/dev/mtdblock1 , bootargs1=root=/dev/mtdblock3
> 
> * default
> 
> It holds default entry that "bootmf" tries to boot on default.

Please check the "default booting configuration" feature of the new
image format, seems like it might be what you're looking for.

Regards,
Barlomiej



From jp-zerer'ev at ESTORE.CO.JP  Thu Apr 24 11:18:57 2008
From: jp-zerer'ev at ESTORE.CO.JP (kemalen)
Date: Thu, 24 Apr 2008 11:18:57 +0200
Subject: [U-Boot-Users] Fantastic cleavage pics
Message-ID: <F9174B85.F%jp-zerer'ev@ESTORE.CO.JP>

Fantastic sex guaranteed with your long hard rod http://www.poskeiajr.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080424/6db9347f/attachment.htm 

From matthias.fuchs at esd-electronics.com  Thu Apr 24 11:33:04 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Thu, 24 Apr 2008 11:33:04 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Add bootcount limit handling for APC405
	boards
Message-ID: <200804241133.04972.matthias.fuchs@esd-electronics.com>

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/apc405/apc405.c |    7 ++++++-
 include/configs/APC405.h  |   14 ++++++++++++--
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/board/esd/apc405/apc405.c b/board/esd/apc405/apc405.c
index b663184..2cb743e 100644
--- a/board/esd/apc405/apc405.c
+++ b/board/esd/apc405/apc405.c
@@ -385,11 +385,16 @@ int misc_init_r(void)
 	}
 	out_be16((u16 *)(FUJI_BASE + LCDBL_PWM), 0xff);
 
-	if (getenv("usb_self") == NULL) {
+	/*
+	 * fix environment for field updated units
+	 */
+	if (getenv("altbootcmd") == NULL) {
 		setenv("usb_load", CFG_USB_LOAD_COMMAND);
 		setenv("usbargs", CFG_USB_ARGS);
 		setenv("bootcmd", CONFIG_BOOTCOMMAND);
 		setenv("usb_self", CFG_USB_SELF_COMMAND);
+		setenv("bootlimit", CFG_BOOTLIMIT);
+		setenv("altbootcmd", CFG_ALT_BOOTCOMMAND);
 		saveenv();
 	}
 
diff --git a/include/configs/APC405.h b/include/configs/APC405.h
index 5b04888..3402db9 100644
--- a/include/configs/APC405.h
+++ b/include/configs/APC405.h
@@ -48,6 +48,7 @@
 
 #define CONFIG_BAUDRATE		115200
 #define CONFIG_BOOTDELAY	1	/* autoboot after 3 seconds	*/
+#define CONFIG_BOOTCOUNT_LIMIT	1
 
 #undef	CONFIG_BOOTARGS
 
@@ -57,6 +58,8 @@
 				"run ramargs addip addcon usbargs;"	\
 				"bootm 200000 300000"
 #define CFG_USB_ARGS		"setenv bootargs $(bootargs) usbboot=1"
+#define CFG_BOOTLIMIT		"3"
+#define CFG_ALT_BOOTCOMMAND	"run usb_self;reset"
 
 #define CONFIG_EXTRA_ENV_SETTINGS                                       \
         "hostname=abg405\0"                                             \
@@ -88,8 +91,10 @@
 	"usb_load="CFG_USB_LOAD_COMMAND"\0"				\
 	"usb_self="CFG_USB_SELF_COMMAND"\0"				\
 	"usbargs="CFG_USB_ARGS"\0"					\
+	"bootlimit="CFG_BOOTLIMIT"\0"					\
+	"altbootcmd="CFG_ALT_BOOTCOMMAND"\0"				\
         ""
-#define CONFIG_BOOTCOMMAND	"run flash_self;run usb_self"
+#define CONFIG_BOOTCOMMAND	"run flash_self;reset"
 
 #define CONFIG_ETHADDR		00:02:27:8e:00:00
 
@@ -414,7 +419,12 @@ extern int flash_banks;
 #define CFG_INIT_RAM_END	CFG_OCM_DATA_SIZE /* End of used area in RAM */
 #define CFG_GBL_DATA_SIZE	128 /* reserved bytes for initial data */
 #define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
-#define CFG_INIT_SP_OFFSET	CFG_GBL_DATA_OFFSET
+/* reserve some memory for BOOT limit info */
+#define CFG_INIT_SP_OFFSET	(CFG_GBL_DATA_OFFSET - 16)
+
+#ifdef CONFIG_BOOTCOUNT_LIMIT /* reserve 2 word for bootcount limit */
+#define CFG_BOOTCOUNT_ADDR (CFG_GBL_DATA_OFFSET - 8)
+#endif
 
 /*
  * Internal Definitions
-- 
1.5.3




From trimarchi at gandalf.sssup.it  Thu Apr 24 12:00:25 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 24 Apr 2008 12:00:25 +0200
Subject: [U-Boot-Users] [PATCH ARM 1/2] Ide support io function
Message-ID: <48105A39.4060503@gandalf.sssup.it>

Add arm readsw and writesw function for armv4 architecure.
Tested on a s3c2410 little endian machine.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-readsw-and-writesw-arm-function.patch
Type: text/x-patch
Size: 5415 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080424/c3862d9a/attachment.bin 

From trimarchi at gandalf.sssup.it  Thu Apr 24 12:00:33 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 24 Apr 2008 12:00:33 +0200
Subject: [U-Boot-Users] [PATCH ARM 2/2] Ide support. Ide registration
Message-ID: <48105A41.2020406@gandalf.sssup.it>

Add ide registration for arm system.

Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-ide-arm-registration.patch
Type: text/x-patch
Size: 618 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080424/77ced2da/attachment.bin 

From trimarchi at gandalf.sssup.it  Thu Apr 24 12:00:15 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 24 Apr 2008 12:00:15 +0200
Subject: [U-Boot-Users] [PATCH ARM 0/2] Ide support
Message-ID: <48105A2F.20502@gandalf.sssup.it>

Hi,

The following patches add support for the ide support on arm
system. Tested on a little endian machine s3c2410

Comments are welcomed.

Thanks,

Michael




From mshiokawa at miraclelinux.com  Thu Apr 24 11:59:05 2008
From: mshiokawa at miraclelinux.com (Makito SHIOKAWA)
Date: Thu, 24 Apr 2008 18:59:05 +0900
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
In-Reply-To: <200804240700.36826.matthias.fuchs@esd-electronics.com>
References: <480FF63C.2030407@miraclelinux.com>
	<200804240700.36826.matthias.fuchs@esd-electronics.com>
Message-ID: <481059E9.5090302@miraclelinux.com>

Hi,

Thank you for your reply.

 > take a look at Wolfgang's last posting from Tuesday on the 'intended behavior
 > of bootm'. The bootlimit/altbootcmd function (in your case probably together
 > with a hardware watchdog) could be the stuff you are (and I was) looking for.

This corresponds to CGL Availability Requirements Definition V4.0: AVL.9.1, 
whereas Boot Image Fallback is AVL.9.0.
(http://developer.osdl.org/dev/cgl/cgl40/cgl40-availability.pdf)
Boot Image Fallback must handle not only image CRC error before kernel boot, 
but a boot failure like kernel panic during kernel boot process (after image 
has successfully loaded). Also, it must fallback after power-on reset.

-- 
MIRACLE LINUX CORPORATION
Makito SHIOKAWA




From nethra_gmit at yahoo.co.in  Thu Apr 24 13:04:09 2008
From: nethra_gmit at yahoo.co.in (Nethra)
Date: Thu, 24 Apr 2008 04:04:09 -0700 (PDT)
Subject: [U-Boot-Users] Kernel hanging after lmb_end_of_DRAM() function
In-Reply-To: <16833978.post@talk.nabble.com>
References: <16833978.post@talk.nabble.com>
Message-ID: <16849884.post@talk.nabble.com>


U can refer to patch for ep8248 support here
                   http://patchwork.ozlabs.org/linuxppc/patch?id=15772

best wishes,
Nethra

>Hi geeks,
>i am trying to bring up the latest kernel on EP8248 target,
>i am using U-boot-1.3.2 and linux-2.6.25-rc8, i started debugging using
BDI2000 which helped me to >know atleast what is going wrong, i have added
some printk's in the kernel source but still i am not able >to find where
and what exactly is going wrong, The first statement it is printing in the
log buffer is
>""Using Embedded Planet EP8248E machine description"" and thats it the next
message is
>Unable to handle kernel paging request for data at address 0xbfff0000
Faulting instruction >address:0xc0012070 (This nearest address to this
address in System.map file is cacheable_memzero)
>and tracing like this i came to know that in the file
arch/powerpc/mm/ppc_mmu_32.c , here in the >function __init MMU_init_hw()
and in the line n_hpteg = total_memory / (PAGE_SIZE * 8); >probably it is
getting problem because when i tried to print the variable total_memory it
is printing >zero !!! :( :(  so probably i am thinking it is not able to
find some memory for Hash table :(
>Please share your knowledge and skills and help me to resolve this issue..
>thanks  :)

-- 
View this message in context: http://www.nabble.com/Kernel-hanging-after-lmb_end_of_DRAM%28%29-function-tp16833978p16849884.html
Sent from the Uboot - Users mailing list archive at Nabble.com.




From mshiokawa at miraclelinux.com  Thu Apr 24 13:16:44 2008
From: mshiokawa at miraclelinux.com (Makito SHIOKAWA)
Date: Thu, 24 Apr 2008 20:16:44 +0900
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
In-Reply-To: <48104C55.6020107@semihalf.com>
References: <480FF63C.2030407@miraclelinux.com> <48104C55.6020107@semihalf.com>
Message-ID: <48106C1C.2010205@miraclelinux.com>

Hi,

Thank you for your reply.

 > You might want to have a look an the new image format introduced
 > recently. It allows you to have multiple kernels (and ramdisks, and
 > other types of images) in one image file, and access these components in
 > elegant way. Have a look in doc/uImage.FIT/. In particular,
 > doc/uImage.FIT/command_syntax_extensions.txt describes new syntax that
 > you might find useful.

I'll check it if this can be a substitution.

-- 
MIRACLE LINUX CORPORATION
Makito SHIOKAWA



From wd at denx.de  Thu Apr 24 13:20:02 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 13:20:02 +0200
Subject: [U-Boot-Users] [PATCH v3] crc32: use uint32_t rather than
	unsigned long
In-Reply-To: Your message of "Wed, 23 Apr 2008 01:39:03 EDT."
	<200804230139.03856.vapier@gentoo.org>
Message-ID: <20080424112002.8533724AB1@gemini.denx.de>

In message <200804230139.03856.vapier at gentoo.org> you wrote:
> 
> On Monday 31 March 2008, Mike Frysinger wrote:
> > The envcrc.c does sizeof(unsigned long) when calculating the crc, but this
> > is done with the build toolchain instead of the target toolchain, so if the
> > build is a 64bit system but the target is 32bits, the size will obviously
> > be wrong. This converts all unsigned long stuff related to crc32 to
> > uint32_t types. Compile tested only: output of ./tools/envcrc when run on a
> > 32bit build system matches that of a 64bit build system.
> 
> ping
> -mike

Applied. Thanks for the patch, and thanks for the reminder.

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: wd at denx.de
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk abort,
Then the socket packet pocket has an error to report! - Ken Burchill?



From wd at denx.de  Thu Apr 24 13:33:29 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 13:33:29 +0200
Subject: [U-Boot-Users] [PATCH] USB: fix those pesky aliasing warnings
	caused by gcc-4.2
In-Reply-To: Your message of "Wed, 23 Apr 2008 10:53:23 +0200."
	<87wsmpymt8.fsf@denx.de>
Message-ID: <20080424113329.35FFD24AB1@gemini.denx.de>

In message <87wsmpymt8.fsf at denx.de> you wrote:
> 
> USB: fix those pesky aliasing warnings caused by gcc-4.2

Please do not duplicate the subject line, or it will end up twice in
the commit log.

And - GCC just prints the warnings, they are caused by coding issues
:-)

> Signed-off-by: Markus Klotzbuecher <mk at denx.de>
> Signed-off-by: Detlev Zundel <dzu at denx.de>
> 
> ---
> 
>  drivers/usb/usb_ohci.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)

Applied - thanks a lot!

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: wd at denx.de
"A complex system that works is invariably found to have evolved from
a simple system that worked."             - John Gall, _Systemantics_



From wd at denx.de  Thu Apr 24 13:37:03 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 13:37:03 +0200
Subject: [U-Boot-Users] [PATCH] USB: remove a cpu bug workaround for an
	unsupported architecture
In-Reply-To: Your message of "Wed, 23 Apr 2008 10:57:33 +0200."
	<87lk35ymma.fsf@denx.de>
Message-ID: <20080424113703.831C024AB1@gemini.denx.de>

In message <87lk35ymma.fsf at denx.de> you wrote:
> 
> USB: remove a cpu bug workaround for an unsupported architecture.
> 
> Signed-off-by: Markus Klotzbuecher <mk at denx.de>
> 
> ---
> 
>  drivers/usb/usb_ohci.c |   22 ++++------------------
>  1 files changed, 4 insertions(+), 18 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: wd at denx.de
Not one hundred percent efficient, of course ... but nothing ever is.
	-- Kirk, "Metamorphosis", stardate 3219.8



From wd at denx.de  Thu Apr 24 13:42:42 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 13:42:42 +0200
Subject: [U-Boot-Users] Kernel hanging after lmb_end_of_DRAM() function
In-Reply-To: Your message of "Wed, 23 Apr 2008 03:45:11 PDT."
	<16833978.post@talk.nabble.com>
Message-ID: <20080424114242.2BD0B24AB1@gemini.denx.de>

In message <16833978.post at talk.nabble.com> you wrote:
> 
> i am trying to bring up the latest kernel on EP8248 target,
...
> Please share your knowledge and skills and help me to resolve this issue..

I can't help with your Linux kernel problem, but I'm pretty sure that
it is off topic on this mailing list.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any technology distinguishable from magic is insufficiently advanced.



From plagnioj at jcrosoft.com  Thu Apr 24 07:57:16 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Thu, 24 Apr 2008 07:57:16 +0200
Subject: [U-Boot-Users] [PATCH 0/1 V2] NE2000: coding style cleanup
In-Reply-To: <1209015794-9805-2-git-send-email-plagnioj@jcrosoft.com>
References: <1209015794-9805-2-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1209016637-10264-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
---
Fix coding style in drivers/net/ax88796.h too

 drivers/net/ax88796.h     |   46 ++--
 drivers/net/ne2000.c      |  276 ++++++++++++----------
 drivers/net/ne2000.h      |   30 ++--
 drivers/net/ne2000_base.h |  567 +++++++++++++++++++++++----------------------
 4 files changed, 474 insertions(+), 445 deletions(-)
 rewrite drivers/net/ne2000_base.h (65%)

diff --git a/drivers/net/ax88796.h b/drivers/net/ax88796.h
index 069ae80..0e6f8a2 100644
--- a/drivers/net/ax88796.h
+++ b/drivers/net/ax88796.h
@@ -23,24 +23,24 @@
 #ifndef __DRIVERS_AX88796L_H__
 #define __DRIVERS_AX88796L_H__
 
-#define DP_DATA     (0x10 << 1)
-#define START_PG    0x40    /* First page of TX buffer */
-#define START_PG2   0x48
-#define STOP_PG     0x80    /* Last page +1 of RX ring */
-#define TX_PAGES    12
-#define RX_START    (START_PG+TX_PAGES)
-#define RX_END      STOP_PG
+#define DP_DATA		(0x10 << 1)
+#define START_PG	0x40	/* First page of TX buffer */
+#define START_PG2	0x48
+#define STOP_PG		0x80	/* Last page +1 of RX ring */
+#define TX_PAGES	12
+#define RX_START	(START_PG+TX_PAGES)
+#define RX_END		STOP_PG
 
 #define AX88796L_BASE_ADDRESS	CONFIG_DRIVER_NE2000_BASE
-#define AX88796L_BYTE_ACCESS    0x00001000
-#define AX88796L_OFFSET         0x00000400
-#define AX88796L_ADDRESS_BYTE   AX88796L_BASE_ADDRESS + \
+#define AX88796L_BYTE_ACCESS	0x00001000
+#define AX88796L_OFFSET		0x00000400
+#define AX88796L_ADDRESS_BYTE	AX88796L_BASE_ADDRESS + \
 		AX88796L_BYTE_ACCESS + AX88796L_OFFSET
-#define AX88796L_REG_MEMR       AX88796L_ADDRESS_BYTE + (0x14<<1)
-#define AX88796L_REG_CR         AX88796L_ADDRESS_BYTE + (0x00<<1)
+#define AX88796L_REG_MEMR	AX88796L_ADDRESS_BYTE + (0x14<<1)
+#define AX88796L_REG_CR		AX88796L_ADDRESS_BYTE + (0x00<<1)
 
 #define AX88796L_CR		(*(vu_short *)(AX88796L_REG_CR))
-#define AX88796L_MEMR	(*(vu_short *)(AX88796L_REG_MEMR))
+#define AX88796L_MEMR		(*(vu_short *)(AX88796L_REG_MEMR))
 
 #define EECS_HIGH		(AX88796L_MEMR |= 0x10)
 #define EECS_LOW		(AX88796L_MEMR &= 0xef)
@@ -53,7 +53,7 @@
 #define PAGE0_SET		(AX88796L_CR &= 0x3f)
 #define PAGE1_SET		(AX88796L_CR = (AX88796L_CR & 0x3f) | 0x40)
 
-#define BIT_DUMMY		0
+#define BIT_DUMMY	0
 #define MAC_EEP_READ	1
 #define MAC_EEP_WRITE	2
 #define MAC_EEP_ERACE	3
@@ -62,20 +62,20 @@
 
 /* R7780MP Specific code */
 #if defined(CONFIG_R7780MP)
-#define ISA_OFFSET  0x1400
-#define DP_IN(_b_, _o_, _d_)  (_d_) = \
+#define ISA_OFFSET	0x1400
+#define DP_IN(_b_, _o_, _d_)	(_d_) = \
 	*( (vu_short *) ((_b_) + ((_o_) * 2) + ISA_OFFSET))
 #define DP_OUT(_b_, _o_, _d_) \
 	*((vu_short *)((_b_) + ((_o_) * 2) + ISA_OFFSET)) = (_d_)
-#define DP_IN_DATA(_b_, _d_)  (_d_) = *( (vu_short *) ((_b_) + ISA_OFFSET))
-#define DP_OUT_DATA(_b_, _d_) *( (vu_short *) ((_b_)+ISA_OFFSET)) = (_d_)
+#define DP_IN_DATA(_b_, _d_)	(_d_) = *( (vu_short *) ((_b_) + ISA_OFFSET))
+#define DP_OUT_DATA(_b_, _d_)	*( (vu_short *) ((_b_)+ISA_OFFSET)) = (_d_)
 #else
 /* Please change for your target boards */
-#define ISA_OFFSET  0x0000
-#define DP_IN(_b_, _o_, _d_)  (_d_) = *( (vu_short *)((_b_)+(_o_ )+ISA_OFFSET))
-#define DP_OUT(_b_, _o_, _d_) *((vu_short *)((_b_)+(_o_)+ISA_OFFSET)) = (_d_)
-#define DP_IN_DATA(_b_, _d_)  (_d_) = *( (vu_short *) ((_b_)+ISA_OFFSET))
-#define DP_OUT_DATA(_b_, _d_) *( (vu_short *) ((_b_)+ISA_OFFSET)) = (_d_)
+#define ISA_OFFSET	0x0000
+#define DP_IN(_b_, _o_, _d_)	(_d_) = *( (vu_short *)((_b_)+(_o_ )+ISA_OFFSET))
+#define DP_OUT(_b_, _o_, _d_)	*((vu_short *)((_b_)+(_o_)+ISA_OFFSET)) = (_d_)
+#define DP_IN_DATA(_b_, _d_)	(_d_) = *( (vu_short *) ((_b_)+ISA_OFFSET))
+#define DP_OUT_DATA(_b_, _d_)	*( (vu_short *) ((_b_)+ISA_OFFSET)) = (_d_)
 #endif
 
 
diff --git a/drivers/net/ne2000.c b/drivers/net/ne2000.c
index 99baeea..d09da78 100644
--- a/drivers/net/ne2000.c
+++ b/drivers/net/ne2000.c
@@ -1,5 +1,5 @@
 /*
-Ported to U-Boot  by Christian Pellegrin <chri at ascensit.com>
+Ported to U-Boot by Christian Pellegrin <chri at ascensit.com>
 
 Based on sources from the Linux kernel (pcnet_cs.c, 8390.h) and
 eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2 wonderful world
@@ -57,13 +57,13 @@ and are covered by the appropriate copyright disclaimers included herein.
 ==========================================================================
 #####DESCRIPTIONBEGIN####
 
-Author(s):    gthomas
-Contributors: gthomas, jskov, rsandifo
-Date:	      2001-06-13
+Author(s):	gthomas
+Contributors:	gthomas, jskov, rsandifo
+Date:		2001-06-13
 Purpose:
 Description:
 
-FIXME:	      Will fail if pinged with large packets (1520 bytes)
+FIXME:		Will fail if pinged with large packets (1520 bytes)
 Add promisc config
 Add SNMP
 
@@ -77,24 +77,26 @@ Add SNMP
 #include <net.h>
 #include <malloc.h>
 
-#define mdelay(n)       udelay((n)*1000)
+#define mdelay(n)	udelay((n)*1000)
 /* forward definition of function used for the uboot interface */
 void uboot_push_packet_len(int len);
 void uboot_push_tx_done(int key, int val);
 
 /*
-  ------------------------------------------------------------------------
-  Debugging details
-
-  Set to perms of:
-  0 disables all debug output
-  1 for process debug output
-  2 for added data IO output: get_reg, put_reg
-  4 for packet allocation/free output
-  8 for only startup status, so we can tell we're installed OK
-*/
-/*#define DEBUG 0xf*/
+ * Debugging details
+ *
+ * Set to perms of:
+ * 0 disables all debug output
+ * 1 for process debug output
+ * 2 for added data IO output: get_reg, put_reg
+ * 4 for packet allocation/free output
+ * 8 for only startup status, so we can tell we're installed OK
+ */
+#if 0
+#define DEBUG 0xf
+#else
 #define DEBUG 0
+#endif
 
 #if DEBUG & 1
 #define DEBUG_FUNCTION() do { printf("%s\n", __FUNCTION__); } while (0)
@@ -128,27 +130,28 @@ dp83902a_init(void)
 	DEBUG_FUNCTION();
 
 	base = dp->base;
-	if (!base) return false;  /* No device found */
+	if (!base)
+		return false;	/* No device found */
 
 	DEBUG_LINE();
 
 #if defined(NE2000_BASIC_INIT)
 	/* AX88796L doesn't need */
 	/* Prepare ESA */
-	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE1);  /* Select page 1 */
+	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE1);	/* Select page 1 */
 	/* Use the address from the serial EEPROM */
 	for (i = 0; i < 6; i++)
 		DP_IN(base, DP_P1_PAR0+i, dp->esa[i]);
-	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE0);  /* Select page 0 */
+	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE0);	/* Select page 0 */
 
 	printf("NE2000 - %s ESA: %02x:%02x:%02x:%02x:%02x:%02x\n",
-	       "eeprom",
-	       dp->esa[0],
-	       dp->esa[1],
-	       dp->esa[2],
-	       dp->esa[3],
-	       dp->esa[4],
-	       dp->esa[5] );
+		"eeprom",
+		dp->esa[0],
+		dp->esa[1],
+		dp->esa[2],
+		dp->esa[3],
+		dp->esa[4],
+		dp->esa[5] );
 
 #endif	/* NE2000_BASIC_INIT */
 	return true;
@@ -162,7 +165,7 @@ dp83902a_stop(void)
 
 	DEBUG_FUNCTION();
 
-	DP_OUT(base, DP_CR, DP_CR_PAGE0 | DP_CR_NODMA | DP_CR_STOP);  /* Brutal */
+	DP_OUT(base, DP_CR, DP_CR_PAGE0 | DP_CR_NODMA | DP_CR_STOP);	/* Brutal */
 	DP_OUT(base, DP_ISR, 0xFF);		/* Clear any pending interrupts */
 	DP_OUT(base, DP_IMR, 0x00);		/* Disable all interrupts */
 
@@ -170,11 +173,11 @@ dp83902a_stop(void)
 }
 
 /*
-  This function is called to "start up" the interface.  It may be called
-  multiple times, even when the hardware is already running.  It will be
-  called whenever something "hardware oriented" changes and should leave
-  the hardware ready to send/receive packets.
-*/
+ * This function is called to "start up" the interface. It may be called
+ * multiple times, even when the hardware is already running. It will be
+ * called whenever something "hardware oriented" changes and should leave
+ * the hardware ready to send/receive packets.
+ */
 static void
 dp83902a_start(u8 * enaddr)
 {
@@ -196,16 +199,16 @@ dp83902a_start(u8 * enaddr)
 	dp->tx_started = false;
 	dp->running = true;
 	DP_OUT(base, DP_PSTART, dp->rx_buf_start); /* Receive ring start page */
-	DP_OUT(base, DP_BNDRY, dp->rx_buf_end-1); /* Receive ring boundary */
+	DP_OUT(base, DP_BNDRY, dp->rx_buf_end - 1); /* Receive ring boundary */
 	DP_OUT(base, DP_PSTOP, dp->rx_buf_end);	/* Receive ring end page */
-	dp->rx_next = dp->rx_buf_start-1;
+	dp->rx_next = dp->rx_buf_start - 1;
 	dp->running = true;
 	DP_OUT(base, DP_ISR, 0xFF);		/* Clear any pending interrupts */
 	DP_OUT(base, DP_IMR, DP_IMR_All);	/* Enable all interrupts */
-	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE1 | DP_CR_STOP);  /* Select page 1 */
-	DP_OUT(base, DP_P1_CURP, dp->rx_buf_start);   /* Current page - next free page for Rx */
+	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE1 | DP_CR_STOP);	/* Select page 1 */
+	DP_OUT(base, DP_P1_CURP, dp->rx_buf_start);	/* Current page - next free page for Rx */
 	dp->running = true;
-	for (i = 0;  i < ETHER_ADDR_LEN;  i++) {
+	for (i = 0; i < ETHER_ADDR_LEN; i++) {
 		/* FIXME */
 		/*((vu_short*)( base + ((DP_P1_PAR0 + i) * 2) +
 		 * 0x1400)) = enaddr[i];*/
@@ -214,15 +217,15 @@ dp83902a_start(u8 * enaddr)
 	/* Enable and start device */
 	DP_OUT(base, DP_CR, DP_CR_PAGE0 | DP_CR_NODMA | DP_CR_START);
 	DP_OUT(base, DP_TCR, DP_TCR_NORMAL); /* Normal transmit operations */
-	DP_OUT(base, DP_RCR, DP_RCR_AB);  /* Accept broadcast, no errors, no multicast */
+	DP_OUT(base, DP_RCR, DP_RCR_AB); /* Accept broadcast, no errors, no multicast */
 	dp->running = true;
 }
 
 /*
-  This routine is called to start the transmitter.  It is split out from the
-  data handling routine so it may be called either when data becomes first
-  available or when an Tx interrupt occurs
-*/
+ * This routine is called to start the transmitter. It is split out from the
+ * data handling routine so it may be called either when data becomes first
+ * available or when an Tx interrupt occurs
+ */
 
 static void
 dp83902a_start_xmit(int start_page, int len)
@@ -249,9 +252,9 @@ dp83902a_start_xmit(int start_page, int len)
 }
 
 /*
-  This routine is called to send data to the hardware.  It is known a-priori
-  that there is free buffer space (dp->tx_next).
-*/
+ * This routine is called to send data to the hardware. It is known a-priori
+ * that there is free buffer space (dp->tx_next).
+ */
 static void
 dp83902a_send(u8 *data, int total_len, u32 key)
 {
@@ -265,7 +268,8 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 	DEBUG_FUNCTION();
 
 	len = pkt_len = total_len;
-	if (pkt_len < IEEE_8023_MIN_FRAME) pkt_len = IEEE_8023_MIN_FRAME;
+	if (pkt_len < IEEE_8023_MIN_FRAME)
+		pkt_len = IEEE_8023_MIN_FRAME;
 
 	start_page = dp->tx_next;
 	if (dp->tx_next == dp->tx_buf1) {
@@ -284,17 +288,19 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 	printf("TX prep page %d len %d\n", start_page, pkt_len);
 #endif
 
-	DP_OUT(base, DP_ISR, DP_ISR_RDC);  /* Clear end of DMA */
+	DP_OUT(base, DP_ISR, DP_ISR_RDC);	/* Clear end of DMA */
 	{
-		/* Dummy read. The manual sez something slightly different, */
-		/* but the code is extended a bit to do what Hitachi's monitor */
-		/* does (i.e., also read data). */
+		/*
+		 * Dummy read. The manual sez something slightly different,
+		 * but the code is extended a bit to do what Hitachi's monitor
+		 * does (i.e., also read data).
+		 */
 
 		u16 tmp;
 		int len = 1;
 
-		DP_OUT(base, DP_RSAL, 0x100-len);
-		DP_OUT(base, DP_RSAH, (start_page-1) & 0xff);
+		DP_OUT(base, DP_RSAL, 0x100 - len);
+		DP_OUT(base, DP_RSAH, (start_page - 1) & 0xff);
 		DP_OUT(base, DP_RBCL, len);
 		DP_OUT(base, DP_RBCH, 0);
 		DP_OUT(base, DP_CR, DP_CR_PAGE0 | DP_CR_RDMA | DP_CR_START);
@@ -302,8 +308,10 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 	}
 
 #ifdef CYGHWR_NS_DP83902A_PLF_BROKEN_TX_DMA
-	/* Stall for a bit before continuing to work around random data */
-	/* corruption problems on some platforms. */
+	/*
+	 * Stall for a bit before continuing to work around random data
+	 * corruption problems on some platforms.
+	 */
 	CYGACC_CALL_IF_DELAY_US(1);
 #endif
 
@@ -336,16 +344,18 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 		printf("  + %d bytes of padding\n", pkt_len - total_len);
 #endif
 		/* Padding to 802.3 length was required */
-		for (i = total_len;  i < pkt_len;) {
+		for (i = total_len; i < pkt_len;) {
 			i++;
 			DP_OUT_DATA(dp->data, 0);
 		}
 	}
 
 #ifdef CYGHWR_NS_DP83902A_PLF_BROKEN_TX_DMA
-	/* After last data write, delay for a bit before accessing the */
-	/* device again, or we may get random data corruption in the last */
-	/* datum (on some platforms). */
+	/*
+	 * After last data write, delay for a bit before accessing the
+	 * device again, or we may get random data corruption in the last
+	 * datum (on some platforms).
+	 */
 	CYGACC_CALL_IF_DELAY_US(1);
 #endif
 
@@ -360,21 +370,21 @@ dp83902a_send(u8 *data, int total_len, u32 key)
 	/* Start transmit if not already going */
 	if (!dp->tx_started) {
 		if (start_page == dp->tx1) {
-			dp->tx_int = 1;  /* Expecting interrupt from BUF1 */
+			dp->tx_int = 1; /* Expecting interrupt from BUF1 */
 		} else {
-			dp->tx_int = 2;  /* Expecting interrupt from BUF2 */
+			dp->tx_int = 2; /* Expecting interrupt from BUF2 */
 		}
 		dp83902a_start_xmit(start_page, pkt_len);
 	}
 }
 
 /*
-  This function is called when a packet has been received.  It's job is
-  to prepare to unload the packet from the hardware.  Once the length of
-  the packet is known, the upper layer of the driver can be told.  When
-  the upper layer is ready to unload the packet, the internal function
-  'dp83902a_recv' will be called to actually fetch it from the hardware.
-*/
+ * This function is called when a packet has been received. It's job is
+ * to prepare to unload the packet from the hardware. Once the length of
+ * the packet is known, the upper layer of the driver can be told. When
+ * the upper layer is ready to unload the packet, the internal function
+ * 'dp83902a_recv' will be called to actually fetch it from the hardware.
+ */
 static void
 dp83902a_RxEvent(void)
 {
@@ -407,9 +417,9 @@ dp83902a_RxEvent(void)
 		DP_OUT(base, DP_RSAH, pkt);
 		if (dp->rx_next == pkt) {
 			if (cur == dp->rx_buf_start)
-				DP_OUT(base, DP_BNDRY, dp->rx_buf_end-1);
+				DP_OUT(base, DP_BNDRY, dp->rx_buf_end - 1);
 			else
-				DP_OUT(base, DP_BNDRY, cur-1); /* Update pointer */
+				DP_OUT(base, DP_BNDRY, cur - 1); /* Update pointer */
 			return;
 		}
 		dp->rx_next = pkt;
@@ -420,13 +430,13 @@ dp83902a_RxEvent(void)
 #endif
 
 		/* read header (get data size)*/
-		for (i = 0;  i < sizeof(rcv_hdr);) {
+		for (i = 0; i < sizeof(rcv_hdr);) {
 			DP_IN_DATA(dp->data, rcv_hdr[i++]);
 		}
 
 #if DEBUG & 5
 		printf("rx hdr %02x %02x %02x %02x\n",
-		       rcv_hdr[0], rcv_hdr[1], rcv_hdr[2], rcv_hdr[3]);
+			rcv_hdr[0], rcv_hdr[1], rcv_hdr[2], rcv_hdr[3]);
 #endif
 		len = ((rcv_hdr[3] << 8) | rcv_hdr[2]) - sizeof(rcv_hdr);
 
@@ -434,19 +444,19 @@ dp83902a_RxEvent(void)
 		uboot_push_packet_len(len);
 
 		if (rcv_hdr[1] == dp->rx_buf_start)
-			DP_OUT(base, DP_BNDRY, dp->rx_buf_end-1);
+			DP_OUT(base, DP_BNDRY, dp->rx_buf_end - 1);
 		else
-			DP_OUT(base, DP_BNDRY, rcv_hdr[1]-1); /* Update pointer */
+			DP_OUT(base, DP_BNDRY, rcv_hdr[1] - 1); /* Update pointer */
 	}
 }
 
 /*
-  This function is called as a result of the "eth_drv_recv()" call above.
-  It's job is to actually fetch data for a packet from the hardware once
-  memory buffers have been allocated for the packet.  Note that the buffers
-  may come in pieces, using a scatter-gather list.  This allows for more
-  efficient processing in the upper layers of the stack.
-*/
+ * This function is called as a result of the "eth_drv_recv()" call above.
+ * It's job is to actually fetch data for a packet from the hardware once
+ * memory buffers have been allocated for the packet. Note that the buffers
+ * may come in pieces, using a scatter-gather list. This allows for more
+ * efficient processing in the upper layers of the stack.
+ */
 static void
 dp83902a_recv(u8 *data, int len)
 {
@@ -478,7 +488,7 @@ dp83902a_recv(u8 *data, int len)
 #endif
 
 	saved = false;
-	for (i = 0;  i < 1;  i++) {
+	for (i = 0; i < 1; i++) {
 		if (data) {
 			mlen = len;
 #if DEBUG & 4
@@ -545,8 +555,10 @@ dp83902a_TxEvent(void)
 	uboot_push_tx_done(key, 0);
 }
 
-/* Read the tally counters to clear them.  Called in response to a CNT */
-/* interrupt. */
+/*
+ * Read the tally counters to clear them. Called in response to a CNT
+ * interrupt.
+ */
 static void
 dp83902a_ClearCounters(void)
 {
@@ -560,8 +572,10 @@ dp83902a_ClearCounters(void)
 	DP_OUT(base, DP_ISR, DP_ISR_CNT);
 }
 
-/* Deal with an overflow condition.  This code follows the procedure set */
-/* out in section 7.0 of the datasheet. */
+/*
+ * Deal with an overflow condition. This code follows the procedure set
+ * out in section 7.0 of the datasheet.
+ */
 static void
 dp83902a_Overflow(void)
 {
@@ -581,9 +595,11 @@ dp83902a_Overflow(void)
 	DP_OUT(base, DP_TCR, DP_TCR_LOCAL);
 	DP_OUT(base, DP_CR, DP_CR_START | DP_CR_NODMA);
 
-	/* Read in as many packets as we can and acknowledge any and receive */
-	/* interrupts.  Since the buffer has overflowed, a receive event of */
-	/* some kind will have occured. */
+	/*
+	 * Read in as many packets as we can and acknowledge any and receive
+	 * interrupts. Since the buffer has overflowed, a receive event of
+	 * some kind will have occured.
+	 */
 	dp83902a_RxEvent();
 	DP_OUT(base, DP_ISR, DP_ISR_RxP|DP_ISR_RxE);
 
@@ -591,8 +607,10 @@ dp83902a_Overflow(void)
 	DP_OUT(base, DP_ISR, DP_ISR_OFLW);
 	DP_OUT(base, DP_TCR, DP_TCR_NORMAL);
 
-	/* If a transmit command was issued, but no transmit event has occured, */
-	/* restart it here. */
+	/*
+	 * If a transmit command was issued, but no transmit event has occured,
+	 * restart it here.
+	 */
 	DP_IN(base, DP_ISR, isr);
 	if (dp->tx_started && !(isr & (DP_ISR_TxP|DP_ISR_TxE))) {
 		DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_TXPKT | DP_CR_START);
@@ -609,25 +627,33 @@ dp83902a_poll(void)
 	DP_OUT(base, DP_CR, DP_CR_NODMA | DP_CR_PAGE0 | DP_CR_START);
 	DP_IN(base, DP_ISR, isr);
 	while (0 != isr) {
-		/* The CNT interrupt triggers when the MSB of one of the error */
-		/* counters is set.  We don't much care about these counters, but */
-		/* we should read their values to reset them. */
+		/*
+		 * The CNT interrupt triggers when the MSB of one of the error
+		 * counters is set. We don't much care about these counters, but
+		 * we should read their values to reset them.
+		 */
 		if (isr & DP_ISR_CNT) {
 			dp83902a_ClearCounters();
 		}
-		/* Check for overflow.  It's a special case, since there's a */
-		/* particular procedure that must be followed to get back into */
-		/* a running state.a */
+		/*
+		 * Check for overflow. It's a special case, since there's a
+		 * particular procedure that must be followed to get back into
+		 * a running state.a
+		 */
 		if (isr & DP_ISR_OFLW) {
 			dp83902a_Overflow();
 		} else {
-			/* Other kinds of interrupts can be acknowledged simply by */
-			/* clearing the relevant bits of the ISR.  Do that now, then */
-			/* handle the interrupts we care about. */
-			DP_OUT(base, DP_ISR, isr);      /* Clear set bits */
+			/*
+			 * Other kinds of interrupts can be acknowledged simply by
+			 * clearing the relevant bits of the ISR. Do that now, then
+			 * handle the interrupts we care about.
+			 */
+			DP_OUT(base, DP_ISR, isr);	/* Clear set bits */
 			if (!dp->running) break;	/* Is this necessary? */
-			/* Check for tx_started on TX event since these may happen */
-			/* spuriously it seems. */
+			/*
+			 * Check for tx_started on TX event since these may happen
+			 * spuriously it seems.
+			 */
 			if (isr & (DP_ISR_TxP|DP_ISR_TxE) && dp->tx_started) {
 				dp83902a_TxEvent();
 			}
@@ -658,8 +684,8 @@ typedef struct hw_info_t {
 #define HAS_MII		0x40
 #define USE_SHMEM	0x80	/* autodetected */
 
-#define AM79C9XX_HOME_PHY	0x00006B90  /* HomePNA PHY */
-#define AM79C9XX_ETH_PHY	0x00006B70  /* 10baseT PHY */
+#define AM79C9XX_HOME_PHY	0x00006B90	/* HomePNA PHY */
+#define AM79C9XX_ETH_PHY	0x00006B70	/* 10baseT PHY */
 #define MII_PHYID_REV_MASK	0xfffffff0
 #define MII_PHYID_REG1		0x02
 #define MII_PHYID_REG2		0x03
@@ -669,7 +695,7 @@ static hw_info_t hw_info[] = {
 	{ /* Allied Telesis LA-PCM */ 0x0ff0, 0x00, 0x00, 0xf4, 0 },
 	{ /* APEX MultiCard */ 0x03f4, 0x00, 0x20, 0xe5, 0 },
 	{ /* ASANTE FriendlyNet */ 0x4910, 0x00, 0x00, 0x94,
-	  DELAY_OUTPUT | HAS_IBM_MISC },
+			DELAY_OUTPUT | HAS_IBM_MISC },
 	{ /* Danpex EN-6200P2 */ 0x0110, 0x00, 0x40, 0xc7, 0 },
 	{ /* DataTrek NetCard */ 0x0ff0, 0x00, 0x20, 0xe8, 0 },
 	{ /* Dayna CommuniCard E */ 0x0110, 0x00, 0x80, 0x19, 0 },
@@ -677,48 +703,48 @@ static hw_info_t hw_info[] = {
 	{ /* EP-210 Ethernet */ 0x0110, 0x00, 0x40, 0x33, 0 },
 	{ /* EP4000 Ethernet */ 0x01c0, 0x00, 0x00, 0xb4, 0 },
 	{ /* Epson EEN10B */ 0x0ff0, 0x00, 0x00, 0x48,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* ELECOM Laneed LD-CDWA */ 0xb8, 0x08, 0x00, 0x42, 0 },
 	{ /* Hypertec Ethernet */ 0x01c0, 0x00, 0x40, 0x4c, 0 },
 	{ /* IBM CCAE */ 0x0ff0, 0x08, 0x00, 0x5a,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* IBM CCAE */ 0x0ff0, 0x00, 0x04, 0xac,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* IBM CCAE */ 0x0ff0, 0x00, 0x06, 0x29,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* IBM FME */ 0x0374, 0x08, 0x00, 0x5a,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* IBM FME */ 0x0374, 0x00, 0x04, 0xac,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* Kansai KLA-PCM/T */ 0x0ff0, 0x00, 0x60, 0x87,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* NSC DP83903 */ 0x0374, 0x08, 0x00, 0x17,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* NSC DP83903 */ 0x0374, 0x00, 0xc0, 0xa8,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* NSC DP83903 */ 0x0374, 0x00, 0xa0, 0xb0,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* NSC DP83903 */ 0x0198, 0x00, 0x20, 0xe0,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* I-O DATA PCLA/T */ 0x0ff0, 0x00, 0xa0, 0xb0, 0 },
 	{ /* Katron PE-520 */ 0x0110, 0x00, 0x40, 0xf6, 0 },
 	{ /* Kingston KNE-PCM/x */ 0x0ff0, 0x00, 0xc0, 0xf0,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* Kingston KNE-PCM/x */ 0x0ff0, 0xe2, 0x0c, 0x0f,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* Kingston KNE-PC2 */ 0x0180, 0x00, 0xc0, 0xf0, 0 },
 	{ /* Maxtech PCN2000 */ 0x5000, 0x00, 0x00, 0xe8, 0 },
 	{ /* NDC Instant-Link */ 0x003a, 0x00, 0x80, 0xc6, 0 },
 	{ /* NE2000 Compatible */ 0x0ff0, 0x00, 0xa0, 0x0c, 0 },
 	{ /* Network General Sniffer */ 0x0ff0, 0x00, 0x00, 0x65,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* Panasonic VEL211 */ 0x0ff0, 0x00, 0x80, 0x45,
-	  HAS_MISC_REG | HAS_IBM_MISC },
+			HAS_MISC_REG | HAS_IBM_MISC },
 	{ /* PreMax PE-200 */ 0x07f0, 0x00, 0x20, 0xe0, 0 },
 	{ /* RPTI EP400 */ 0x0110, 0x00, 0x40, 0x95, 0 },
 	{ /* SCM Ethernet */ 0x0ff0, 0x00, 0x20, 0xcb, 0 },
 	{ /* Socket EA */ 0x4000, 0x00, 0xc0, 0x1b,
-	  DELAY_OUTPUT | HAS_MISC_REG | USE_BIG_BUF },
+			DELAY_OUTPUT | HAS_MISC_REG | USE_BIG_BUF },
 	{ /* Socket LP-E CF+ */ 0x01c0, 0x00, 0xc0, 0x1b, 0 },
 	{ /* SuperSocket RE450T */ 0x0110, 0x00, 0xe0, 0x98, 0 },
 	{ /* Volktek NPL-402CT */ 0x0060, 0x00, 0x40, 0x05, 0 },
@@ -744,11 +770,11 @@ u32 nic_base;
 static u8 *pbuf = NULL;
 
 static int pkey = -1;
-static int initialized=0;
+static int initialized = 0;
 
 void uboot_push_packet_len(int len) {
 	PRINTK("pushed len = %d\n", len);
-	if (len>=2000) {
+	if (len >= 2000) {
 		printf("NE2000: packet too big\n");
 		return;
 	}
@@ -779,7 +805,7 @@ int eth_init(bd_t *bd) {
 
 #ifdef CONFIG_DRIVER_NE2000_CCR
 	{
-		vu_char *p =  (vu_char *) CONFIG_DRIVER_NE2000_CCR;
+		vu_char *p = (vu_char *) CONFIG_DRIVER_NE2000_CCR;
 
 		PRINTK("CCR before is %x\n", *p);
 		*p = CONFIG_DRIVER_NE2000_VAL;
@@ -811,7 +837,7 @@ int eth_init(bd_t *bd) {
 		return -1;
 
 	dp83902a_start(dev_addr);
-	initialized=1;
+	initialized = 1;
 
 	return 0;
 }
@@ -821,7 +847,7 @@ void eth_halt() {
 	PRINTK("### eth_halt\n");
 	if(initialized)
 		dp83902a_stop();
-	initialized=0;
+	initialized = 0;
 }
 
 int eth_rx() {
diff --git a/drivers/net/ne2000.h b/drivers/net/ne2000.h
index d324a00..6049482 100644
--- a/drivers/net/ne2000.h
+++ b/drivers/net/ne2000.h
@@ -1,5 +1,5 @@
 /*
-Ported to U-Boot  by Christian Pellegrin <chri at ascensit.com>
+Ported to U-Boot by Christian Pellegrin <chri at ascensit.com>
 
 Based on sources from the Linux kernel (pcnet_cs.c, 8390.h) and
 eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2 wonderful world
@@ -7,9 +7,9 @@ are GPL, so this is, of course, GPL.
 
 ==========================================================================
 
-      dev/dp83902a.h
+	dev/dp83902a.h
 
-      National Semiconductor DP83902a ethernet chip
+	National Semiconductor DP83902a ethernet chip
 
 ==========================================================================
 ####ECOSGPLCOPYRIGHTBEGIN####
@@ -57,9 +57,9 @@ are GPL, so this is, of course, GPL.
 ==========================================================================
 #####DESCRIPTIONBEGIN####
 
- Author(s):    gthomas
- Contributors: gthomas, jskov
- Date:         2001-06-13
+ Author(s):	gthomas
+ Contributors:	gthomas, jskov
+ Date:		2001-06-13
  Purpose:
  Description:
 
@@ -79,17 +79,17 @@ are GPL, so this is, of course, GPL.
 /* Enable NE2000 basic init function */
 #define NE2000_BASIC_INIT
 
-#define DP_DATA     0x10
-#define START_PG    0x50    /* First page of TX buffer */
-#define STOP_PG     0x80    /* Last page +1 of RX ring */
+#define DP_DATA		0x10
+#define START_PG	0x50	/* First page of TX buffer */
+#define STOP_PG		0x80	/* Last page +1 of RX ring */
 
-#define RX_START    0x50
-#define RX_END      0x80
+#define RX_START	0x50
+#define RX_END		0x80
 
-#define DP_IN(_b_, _o_, _d_)  (_d_) = *( (vu_char *) ((_b_)+(_o_)))
-#define DP_OUT(_b_, _o_, _d_) *( (vu_char *) ((_b_)+(_o_))) = (_d_)
-#define DP_IN_DATA(_b_, _d_)  (_d_) = *( (vu_char *) ((_b_)))
-#define DP_OUT_DATA(_b_, _d_) *( (vu_char *) ((_b_))) = (_d_)
+#define DP_IN(_b_, _o_, _d_)	(_d_) = *( (vu_char *) ((_b_)+(_o_)))
+#define DP_OUT(_b_, _o_, _d_)	*( (vu_char *) ((_b_)+(_o_))) = (_d_)
+#define DP_IN_DATA(_b_, _d_)	(_d_) = *( (vu_char *) ((_b_)))
+#define DP_OUT_DATA(_b_, _d_)	*( (vu_char *) ((_b_))) = (_d_)
 
 static void pcnet_reset_8390(void)
 {
diff --git a/drivers/net/ne2000_base.h b/drivers/net/ne2000_base.h
dissimilarity index 65%
index 1badf62..990d748 100644
--- a/drivers/net/ne2000_base.h
+++ b/drivers/net/ne2000_base.h
@@ -1,282 +1,285 @@
-/*
-Ported to U-Boot  by Christian Pellegrin <chri at ascensit.com>
-
-Based on sources from the Linux kernel (pcnet_cs.c, 8390.h) and
-eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2 wonderful world
-are GPL, so this is, of course, GPL.
-
-
-==========================================================================
-
-      dev/dp83902a.h
-
-      National Semiconductor DP83902a ethernet chip
-
-==========================================================================
-####ECOSGPLCOPYRIGHTBEGIN####
- -------------------------------------------
- This file is part of eCos, the Embedded Configurable Operating System.
- Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
-
- eCos 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 or (at your option) any later version.
-
- eCos 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 eCos; if not, write to the Free Software Foundation, Inc.,
- 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
-
- As a special exception, if other files instantiate templates or use macros
- or inline functions from this file, or you compile this file and link it
- with other works to produce a work based on this file, this file does not
- by itself cause the resulting work to be covered by the GNU General Public
- License. However the source code for this file must still be made available
- in accordance with section (3) of the GNU General Public License.
-
- This exception does not invalidate any other reasons why a work based on
- this file might be covered by the GNU General Public License.
-
- Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
- at http://sources.redhat.com/ecos/ecos-license/
- -------------------------------------------
-####ECOSGPLCOPYRIGHTEND####
-####BSDCOPYRIGHTBEGIN####
-
- -------------------------------------------
-
- Portions of this software may have been derived from OpenBSD or other sources,
- and are covered by the appropriate copyright disclaimers included herein.
-
- -------------------------------------------
-
-####BSDCOPYRIGHTEND####
-==========================================================================
-#####DESCRIPTIONBEGIN####
-
- Author(s):    gthomas
- Contributors: gthomas, jskov
- Date:         2001-06-13
- Purpose:
- Description:
-
-####DESCRIPTIONEND####
-
-==========================================================================
-
-*/
-
-/*
- ------------------------------------------------------------------------
- Macros for accessing DP registers
- These can be overridden by the platform header
-*/
-
-#define bool int
-
-#define false 0
-#define true 1
-
-/* timeout for tx/rx in s */
-#define TOUT 5
-/* Ether MAC address size */
-#define ETHER_ADDR_LEN 6
-
-
-#define CYGHWR_NS_DP83902A_PLF_BROKEN_TX_DMA 1
-#define CYGACC_CALL_IF_DELAY_US(X) udelay(X)
-
-/* H/W infomation struct */
-typedef struct hw_info_t {
-    u32   offset;
-    u8  a0, a1, a2;
-    u32   flags;
-} hw_info_t;
-
-typedef struct dp83902a_priv_data {
-    u8* base;
-    u8* data;
-    u8* reset;
-    int tx_next;           /* First free Tx page */
-    int tx_int;            /* Expecting interrupt from this buffer */
-    int rx_next;           /* First free Rx page */
-    int tx1, tx2;          /* Page numbers for Tx buffers */
-    u32 tx1_key, tx2_key;   /* Used to ack when packet sent */
-    int tx1_len, tx2_len;
-    bool tx_started, running, hardwired_esa;
-    u8 esa[6];
-    void* plf_priv;
-
-    /* Buffer allocation */
-    int tx_buf1, tx_buf2;
-    int rx_buf_start, rx_buf_end;
-} dp83902a_priv_data_t;
-
-/*
- ------------------------------------------------------------------------
- Some forward declarations
-*/
-int get_prom( u8* mac_addr);
-static void dp83902a_poll(void);
-
-/* ------------------------------------------------------------------------ */
-/* Register offsets */
-
-#define DP_CR          0x00
-#define DP_CLDA0       0x01
-#define DP_PSTART      0x01             /* write */
-#define DP_CLDA1       0x02
-#define DP_PSTOP       0x02             /* write */
-#define DP_BNDRY       0x03
-#define DP_TSR         0x04
-#define DP_TPSR        0x04             /* write */
-#define DP_NCR         0x05
-#define DP_TBCL        0x05             /* write */
-#define DP_FIFO        0x06
-#define DP_TBCH        0x06             /* write */
-#define DP_ISR         0x07
-#define DP_CRDA0       0x08
-#define DP_RSAL        0x08             /* write */
-#define DP_CRDA1       0x09
-#define DP_RSAH        0x09             /* write */
-#define DP_RBCL        0x0a             /* write */
-#define DP_RBCH        0x0b             /* write */
-#define DP_RSR         0x0c
-#define DP_RCR         0x0c             /* write */
-#define DP_FER         0x0d
-#define DP_TCR         0x0d             /* write */
-#define DP_CER         0x0e
-#define DP_DCR         0x0e             /* write */
-#define DP_MISSED      0x0f
-#define DP_IMR         0x0f             /* write */
-#define DP_DATAPORT    0x10             /* "eprom" data port */
-
-#define DP_P1_CR       0x00
-#define DP_P1_PAR0     0x01
-#define DP_P1_PAR1     0x02
-#define DP_P1_PAR2     0x03
-#define DP_P1_PAR3     0x04
-#define DP_P1_PAR4     0x05
-#define DP_P1_PAR5     0x06
-#define DP_P1_CURP     0x07
-#define DP_P1_MAR0     0x08
-#define DP_P1_MAR1     0x09
-#define DP_P1_MAR2     0x0a
-#define DP_P1_MAR3     0x0b
-#define DP_P1_MAR4     0x0c
-#define DP_P1_MAR5     0x0d
-#define DP_P1_MAR6     0x0e
-#define DP_P1_MAR7     0x0f
-
-#define DP_P2_CR       0x00
-#define DP_P2_PSTART   0x01
-#define DP_P2_CLDA0    0x01             /* write */
-#define DP_P2_PSTOP    0x02
-#define DP_P2_CLDA1    0x02             /* write */
-#define DP_P2_RNPP     0x03
-#define DP_P2_TPSR     0x04
-#define DP_P2_LNPP     0x05
-#define DP_P2_ACH      0x06
-#define DP_P2_ACL      0x07
-#define DP_P2_RCR      0x0c
-#define DP_P2_TCR      0x0d
-#define DP_P2_DCR      0x0e
-#define DP_P2_IMR      0x0f
-
-/* Command register - common to all pages */
-
-#define DP_CR_STOP    0x01   /* Stop: software reset */
-#define DP_CR_START   0x02   /* Start: initialize device */
-#define DP_CR_TXPKT   0x04   /* Transmit packet */
-#define DP_CR_RDMA    0x08   /* Read DMA  (recv data from device) */
-#define DP_CR_WDMA    0x10   /* Write DMA (send data to device) */
-#define DP_CR_SEND    0x18   /* Send packet */
-#define DP_CR_NODMA   0x20   /* Remote (or no) DMA */
-#define DP_CR_PAGE0   0x00   /* Page select */
-#define DP_CR_PAGE1   0x40
-#define DP_CR_PAGE2   0x80
-#define DP_CR_PAGEMSK 0x3F   /* Used to mask out page bits */
-
-/* Data configuration register */
-
-#define DP_DCR_WTS    0x01   /* 1=16 bit word transfers */
-#define DP_DCR_BOS    0x02   /* 1=Little Endian */
-#define DP_DCR_LAS    0x04   /* 1=Single 32 bit DMA mode */
-#define DP_DCR_LS     0x08   /* 1=normal mode, 0=loopback */
-#define DP_DCR_ARM    0x10   /* 0=no send command (program I/O) */
-#define DP_DCR_FIFO_1 0x00   /* FIFO threshold */
-#define DP_DCR_FIFO_2 0x20
-#define DP_DCR_FIFO_4 0x40
-#define DP_DCR_FIFO_6 0x60
-
-#define DP_DCR_INIT   (DP_DCR_LS|DP_DCR_FIFO_4)
-
-/* Interrupt status register */
-
-#define DP_ISR_RxP    0x01   /* Packet received */
-#define DP_ISR_TxP    0x02   /* Packet transmitted */
-#define DP_ISR_RxE    0x04   /* Receive error */
-#define DP_ISR_TxE    0x08   /* Transmit error */
-#define DP_ISR_OFLW   0x10   /* Receive overflow */
-#define DP_ISR_CNT    0x20   /* Tally counters need emptying */
-#define DP_ISR_RDC    0x40   /* Remote DMA complete */
-#define DP_ISR_RESET  0x80   /* Device has reset (shutdown, error) */
-
-/* Interrupt mask register */
-
-#define DP_IMR_RxP    0x01   /* Packet received */
-#define DP_IMR_TxP    0x02   /* Packet transmitted */
-#define DP_IMR_RxE    0x04   /* Receive error */
-#define DP_IMR_TxE    0x08   /* Transmit error */
-#define DP_IMR_OFLW   0x10   /* Receive overflow */
-#define DP_IMR_CNT    0x20   /* Tall counters need emptying */
-#define DP_IMR_RDC    0x40   /* Remote DMA complete */
-
-#define DP_IMR_All    0x3F   /* Everything but remote DMA */
-
-/* Receiver control register */
-
-#define DP_RCR_SEP    0x01   /* Save bad(error) packets */
-#define DP_RCR_AR     0x02   /* Accept runt packets */
-#define DP_RCR_AB     0x04   /* Accept broadcast packets */
-#define DP_RCR_AM     0x08   /* Accept multicast packets */
-#define DP_RCR_PROM   0x10   /* Promiscuous mode */
-#define DP_RCR_MON    0x20   /* Monitor mode - 1=accept no packets */
-
-/* Receiver status register */
-
-#define DP_RSR_RxP    0x01   /* Packet received */
-#define DP_RSR_CRC    0x02   /* CRC error */
-#define DP_RSR_FRAME  0x04   /* Framing error */
-#define DP_RSR_FO     0x08   /* FIFO overrun */
-#define DP_RSR_MISS   0x10   /* Missed packet */
-#define DP_RSR_PHY    0x20   /* 0=pad match, 1=mad match */
-#define DP_RSR_DIS    0x40   /* Receiver disabled */
-#define DP_RSR_DFR    0x80   /* Receiver processing deferred */
-
-/* Transmitter control register */
-
-#define DP_TCR_NOCRC  0x01   /* 1=inhibit CRC */
-#define DP_TCR_NORMAL 0x00   /* Normal transmitter operation */
-#define DP_TCR_LOCAL  0x02   /* Internal NIC loopback */
-#define DP_TCR_INLOOP 0x04   /* Full internal loopback */
-#define DP_TCR_OUTLOOP 0x08  /* External loopback */
-#define DP_TCR_ATD    0x10   /* Auto transmit disable */
-#define DP_TCR_OFFSET 0x20   /* Collision offset adjust */
-
-/* Transmit status register */
-
-#define DP_TSR_TxP    0x01   /* Packet transmitted */
-#define DP_TSR_COL    0x04   /* Collision (at least one) */
-#define DP_TSR_ABT    0x08   /* Aborted because of too many collisions */
-#define DP_TSR_CRS    0x10   /* Lost carrier */
-#define DP_TSR_FU     0x20   /* FIFO underrun */
-#define DP_TSR_CDH    0x40   /* Collision Detect Heartbeat */
-#define DP_TSR_OWC    0x80   /* Collision outside normal window */
-
-#define IEEE_8023_MAX_FRAME         1518    /* Largest possible ethernet frame */
-#define IEEE_8023_MIN_FRAME           64    /* Smallest possible ethernet frame */
+/*
+Ported to U-Boot by Christian Pellegrin <chri at ascensit.com>
+
+Based on sources from the Linux kernel (pcnet_cs.c, 8390.h) and
+eCOS(if_dp83902a.c, if_dp83902a.h). Both of these 2 wonderful world
+are GPL, so this is, of course, GPL.
+
+
+==========================================================================
+
+	dev/dp83902a.h
+
+	National Semiconductor DP83902a ethernet chip
+
+==========================================================================
+####ECOSGPLCOPYRIGHTBEGIN####
+ -------------------------------------------
+ This file is part of eCos, the Embedded Configurable Operating System.
+ Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
+
+ eCos 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 or (at your option) any later version.
+
+ eCos 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 eCos; if not, write to the Free Software Foundation, Inc.,
+ 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+
+ As a special exception, if other files instantiate templates or use macros
+ or inline functions from this file, or you compile this file and link it
+ with other works to produce a work based on this file, this file does not
+ by itself cause the resulting work to be covered by the GNU General Public
+ License. However the source code for this file must still be made available
+ in accordance with section (3) of the GNU General Public License.
+
+ This exception does not invalidate any other reasons why a work based on
+ this file might be covered by the GNU General Public License.
+
+ Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
+ at http://sources.redhat.com/ecos/ecos-license/
+ -------------------------------------------
+####ECOSGPLCOPYRIGHTEND####
+####BSDCOPYRIGHTBEGIN####
+
+ -------------------------------------------
+
+ Portions of this software may have been derived from OpenBSD or other sources,
+ and are covered by the appropriate copyright disclaimers included herein.
+
+ -------------------------------------------
+
+####BSDCOPYRIGHTEND####
+==========================================================================
+#####DESCRIPTIONBEGIN####
+
+ Author(s):	gthomas
+ Contributors:	gthomas, jskov
+ Date:		2001-06-13
+ Purpose:
+ Description:
+
+####DESCRIPTIONEND####
+
+==========================================================================
+
+*/
+
+/*
+ ------------------------------------------------------------------------
+ Macros for accessing DP registers
+ These can be overridden by the platform header
+*/
+
+#ifndef __NE2000_BASE_H__
+#define __NE2000_BASE_H__
+
+#define bool int
+
+#define false 0
+#define true 1
+
+/* timeout for tx/rx in s */
+#define TOUT 5
+/* Ether MAC address size */
+#define ETHER_ADDR_LEN 6
+
+
+#define CYGHWR_NS_DP83902A_PLF_BROKEN_TX_DMA 1
+#define CYGACC_CALL_IF_DELAY_US(X) udelay(X)
+
+/* H/W infomation struct */
+typedef struct hw_info_t {
+	u32 offset;
+	u8 a0, a1, a2;
+	u32 flags;
+} hw_info_t;
+
+typedef struct dp83902a_priv_data {
+	u8* base;
+	u8* data;
+	u8* reset;
+	int tx_next;		/* First free Tx page */
+	int tx_int;		/* Expecting interrupt from this buffer */
+	int rx_next;		/* First free Rx page */
+	int tx1, tx2;		/* Page numbers for Tx buffers */
+	u32 tx1_key, tx2_key;	/* Used to ack when packet sent */
+	int tx1_len, tx2_len;
+	bool tx_started, running, hardwired_esa;
+	u8 esa[6];
+	void* plf_priv;
+
+	/* Buffer allocation */
+	int tx_buf1, tx_buf2;
+	int rx_buf_start, rx_buf_end;
+} dp83902a_priv_data_t;
+
+/*
+ * Some forward declarations
+ */
+int get_prom( u8* mac_addr);
+static void dp83902a_poll(void);
+
+/* ------------------------------------------------------------------------ */
+/* Register offsets */
+
+#define DP_CR		0x00
+#define DP_CLDA0	0x01
+#define DP_PSTART	0x01	/* write */
+#define DP_CLDA1	0x02
+#define DP_PSTOP	0x02	/* write */
+#define DP_BNDRY	0x03
+#define DP_TSR		0x04
+#define DP_TPSR		0x04	/* write */
+#define DP_NCR		0x05
+#define DP_TBCL		0x05	/* write */
+#define DP_FIFO		0x06
+#define DP_TBCH		0x06	/* write */
+#define DP_ISR		0x07
+#define DP_CRDA0	0x08
+#define DP_RSAL		0x08	/* write */
+#define DP_CRDA1	0x09
+#define DP_RSAH		0x09	/* write */
+#define DP_RBCL		0x0a	/* write */
+#define DP_RBCH		0x0b	/* write */
+#define DP_RSR		0x0c
+#define DP_RCR		0x0c	/* write */
+#define DP_FER		0x0d
+#define DP_TCR		0x0d	/* write */
+#define DP_CER		0x0e
+#define DP_DCR		0x0e	/* write */
+#define DP_MISSED	0x0f
+#define DP_IMR		0x0f	/* write */
+#define DP_DATAPORT	0x10	/* "eprom" data port */
+
+#define DP_P1_CR	0x00
+#define DP_P1_PAR0	0x01
+#define DP_P1_PAR1	0x02
+#define DP_P1_PAR2	0x03
+#define DP_P1_PAR3	0x04
+#define DP_P1_PAR4	0x05
+#define DP_P1_PAR5	0x06
+#define DP_P1_CURP	0x07
+#define DP_P1_MAR0	0x08
+#define DP_P1_MAR1	0x09
+#define DP_P1_MAR2	0x0a
+#define DP_P1_MAR3	0x0b
+#define DP_P1_MAR4	0x0c
+#define DP_P1_MAR5	0x0d
+#define DP_P1_MAR6	0x0e
+#define DP_P1_MAR7	0x0f
+
+#define DP_P2_CR	0x00
+#define DP_P2_PSTART	0x01
+#define DP_P2_CLDA0	0x01	/* write */
+#define DP_P2_PSTOP	0x02
+#define DP_P2_CLDA1	0x02	/* write */
+#define DP_P2_RNPP	0x03
+#define DP_P2_TPSR	0x04
+#define DP_P2_LNPP	0x05
+#define DP_P2_ACH	0x06
+#define DP_P2_ACL	0x07
+#define DP_P2_RCR	0x0c
+#define DP_P2_TCR	0x0d
+#define DP_P2_DCR	0x0e
+#define DP_P2_IMR	0x0f
+
+/* Command register - common to all pages */
+
+#define DP_CR_STOP	0x01	/* Stop: software reset */
+#define DP_CR_START	0x02	/* Start: initialize device */
+#define DP_CR_TXPKT	0x04	/* Transmit packet */
+#define DP_CR_RDMA	0x08	/* Read DMA (recv data from device) */
+#define DP_CR_WDMA	0x10	/* Write DMA (send data to device) */
+#define DP_CR_SEND	0x18	/* Send packet */
+#define DP_CR_NODMA	0x20	/* Remote (or no) DMA */
+#define DP_CR_PAGE0	0x00	/* Page select */
+#define DP_CR_PAGE1	0x40
+#define DP_CR_PAGE2	0x80
+#define DP_CR_PAGEMSK	0x3F	/* Used to mask out page bits */
+
+/* Data configuration register */
+
+#define DP_DCR_WTS	0x01	/* 1=16 bit word transfers */
+#define DP_DCR_BOS	0x02	/* 1=Little Endian */
+#define DP_DCR_LAS	0x04	/* 1=Single 32 bit DMA mode */
+#define DP_DCR_LS	0x08	/* 1=normal mode, 0=loopback */
+#define DP_DCR_ARM	0x10	/* 0=no send command (program I/O) */
+#define DP_DCR_FIFO_1	0x00	/* FIFO threshold */
+#define DP_DCR_FIFO_2	0x20
+#define DP_DCR_FIFO_4	0x40
+#define DP_DCR_FIFO_6	0x60
+
+#define DP_DCR_INIT	(DP_DCR_LS|DP_DCR_FIFO_4)
+
+/* Interrupt status register */
+
+#define DP_ISR_RxP	0x01	/* Packet received */
+#define DP_ISR_TxP	0x02	/* Packet transmitted */
+#define DP_ISR_RxE	0x04	/* Receive error */
+#define DP_ISR_TxE	0x08	/* Transmit error */
+#define DP_ISR_OFLW	0x10	/* Receive overflow */
+#define DP_ISR_CNT	0x20	/* Tally counters need emptying */
+#define DP_ISR_RDC	0x40	/* Remote DMA complete */
+#define DP_ISR_RESET	0x80	/* Device has reset (shutdown, error) */
+
+/* Interrupt mask register */
+
+#define DP_IMR_RxP	0x01	/* Packet received */
+#define DP_IMR_TxP	0x02	/* Packet transmitted */
+#define DP_IMR_RxE	0x04	/* Receive error */
+#define DP_IMR_TxE	0x08	/* Transmit error */
+#define DP_IMR_OFLW	0x10	/* Receive overflow */
+#define DP_IMR_CNT	0x20	/* Tall counters need emptying */
+#define DP_IMR_RDC	0x40	/* Remote DMA complete */
+
+#define DP_IMR_All	0x3F	/* Everything but remote DMA */
+
+/* Receiver control register */
+
+#define DP_RCR_SEP	0x01	/* Save bad(error) packets */
+#define DP_RCR_AR	0x02	/* Accept runt packets */
+#define DP_RCR_AB	0x04	/* Accept broadcast packets */
+#define DP_RCR_AM	0x08	/* Accept multicast packets */
+#define DP_RCR_PROM	0x10	/* Promiscuous mode */
+#define DP_RCR_MON	0x20	/* Monitor mode - 1=accept no packets */
+
+/* Receiver status register */
+
+#define DP_RSR_RxP	0x01	/* Packet received */
+#define DP_RSR_CRC	0x02	/* CRC error */
+#define DP_RSR_FRAME	0x04	/* Framing error */
+#define DP_RSR_FO	0x08	/* FIFO overrun */
+#define DP_RSR_MISS	0x10	/* Missed packet */
+#define DP_RSR_PHY	0x20	/* 0=pad match, 1=mad match */
+#define DP_RSR_DIS	0x40	/* Receiver disabled */
+#define DP_RSR_DFR	0x80	/* Receiver processing deferred */
+
+/* Transmitter control register */
+
+#define DP_TCR_NOCRC	0x01	/* 1=inhibit CRC */
+#define DP_TCR_NORMAL	0x00	/* Normal transmitter operation */
+#define DP_TCR_LOCAL	0x02	/* Internal NIC loopback */
+#define DP_TCR_INLOOP	0x04	/* Full internal loopback */
+#define DP_TCR_OUTLOOP	0x08	/* External loopback */
+#define DP_TCR_ATD	0x10	/* Auto transmit disable */
+#define DP_TCR_OFFSET	0x20	/* Collision offset adjust */
+
+/* Transmit status register */
+
+#define DP_TSR_TxP	0x01	/* Packet transmitted */
+#define DP_TSR_COL	0x04	/* Collision (at least one) */
+#define DP_TSR_ABT	0x08	/* Aborted because of too many collisions */
+#define DP_TSR_CRS	0x10	/* Lost carrier */
+#define DP_TSR_FU	0x20	/* FIFO underrun */
+#define DP_TSR_CDH	0x40	/* Collision Detect Heartbeat */
+#define DP_TSR_OWC	0x80	/* Collision outside normal window */
+
+#define IEEE_8023_MAX_FRAME	1518	/* Largest possible ethernet frame */
+#define IEEE_8023_MIN_FRAME	64	/* Smallest possible ethernet frame */
+#endif /* __NE2000_BASE_H__ */
-- 
1.5.4.5




From raj at semihalf.com  Thu Apr 24 13:52:23 2008
From: raj at semihalf.com (Rafal Jaworowski)
Date: Thu, 24 Apr 2008 13:52:23 +0200
Subject: [U-Boot-Users] TFTP block size is too high
In-Reply-To: <480FDD24.9090909@genesysdesign.com.au>
References: <480FDD24.9090909@genesysdesign.com.au>
Message-ID: <48107477.6090107@semihalf.com>

Jared Holzman wrote:
> Does anyone else have problems with the new default tftp block size of 1468 (set 
> in tftp.c) being too large? I was getting corruption of the d/led images until I 
> dropped it down to 1200. I'm afraid I don't have time to determine the real 
> maximum size before corruption occurs. Does someone else want to look into this?

What exactly is your set-up i.e. what version of U-Boot, architecture,
platform etc. are you running? I recall problems with MPC5121e that sound
familiar, which were caused by a bug/misconfiguration in the FEC driver, but
in this case we fixed the issue a couple of months ago. Maybe that's something
 of that sort..

kind regards,
Rafal



From jwboyer at gmail.com  Thu Apr 24 13:58:05 2008
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 24 Apr 2008 06:58:05 -0500
Subject: [U-Boot-Users] PPC440EPx/sequoia TLB question...
In-Reply-To: <200804240728.44082.sr@denx.de>
References: <480EA8E1.4060207@verizon.net> <200804231442.29687.sr@denx.de>
	<480FF00F.4080900@verizon.net>  <200804240728.44082.sr@denx.de>
Message-ID: <1209038285.2946.17.camel@vader.jdub.homelinux.org>

On Thu, 2008-04-24 at 07:28 +0200, Stefan Roese wrote:
> On Thursday 24 April 2008, Dave Littell wrote:
> > >> Also the TLB entry for SDRAM marks it Guarded, but that?s one area I
> > >> would think wouldn't need to be Guarded.
> > >
> > > This could be a mistake. Should work without G bis set too. Please give
> > > it a try and send a patch to fix it, if it works fine.
> >
> > Hard to define "works fine" - this is the same 440EPx platform I'm
> > asking about over in the embedded Linux mailing list.  I'm pretty sure
> > the kernel doesn't flag SDRAM as Guarded,
> 
> Yes, and the 4xx code to dynamically set the SDRAM TLB's in the SPD code 
> doesn't set it either. So it really isn't needed.

Actually, that's not true for kernel memory.  We pin 256MiB TLBs to
cover lowmem in AS0, and the Guarded bit is set.  We set it to prevent
speculative access to memory holes where the 256MiB TLB covers more
address space than there is physical DRAM.

josh




From jwboyer at linux.vnet.ibm.com  Thu Apr 24 14:00:06 2008
From: jwboyer at linux.vnet.ibm.com (Josh Boyer)
Date: Thu, 24 Apr 2008 07:00:06 -0500
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
In-Reply-To: <200804240636.12349.sr@denx.de>
References: <480EADF4.2020706@verizon.net> <200804231449.24746.sr@denx.de>
	<1208999427.2946.8.camel@vader.jdub.homelinux.org>
	<200804240636.12349.sr@denx.de>
Message-ID: <1209038406.2946.20.camel@vader.jdub.homelinux.org>

On Thu, 2008-04-24 at 06:36 +0200, Stefan Roese wrote:
> On Thursday 24 April 2008, Josh Boyer wrote:
> > > Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the
> > > 440EPx CHIP 11 errata. I suggest you take a look at this too and see if
> > > this changes your behavior.
> >
> > Explain this a bit more please?  Is a kernel change needed here?
> 
> This depends. When the bootwrapper version is used then yes, the kernel should 
> get changed. This is because the bootwrapper detects the SDRAM size from the 
> DDR2 controller and passes it to Linux.
> 
> Without bootwrapper no changes are needed, since U-Boot already passes the 
> corrected memory size to Linux (totalsize-4k currently).

Hm.  Given that AMCC ships the boards with an older U-Boot that requires
cuImages, I think we'll need to patch the wrapper.  Does 440GRx share
this same errata?  I would think so.

josh




From wd at denx.de  Thu Apr 24 14:16:04 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 14:16:04 +0200
Subject: [U-Boot-Users] Pull request: u-boot-video
In-Reply-To: Your message of "Wed, 23 Apr 2008 16:43:25 +0200."
	<E1JogBx-0001cu-AK@zaigor.enneenne.com>
Message-ID: <20080424121604.9D0A524AB3@gemini.denx.de>

In message <E1JogBx-0001cu-AK at zaigor.enneenne.com> you wrote:
> The following changes since commit a49e0d177a0749614b316ec847fb623f09c82c07:
>   Matthias Fuchs (1):
>         video: Add missing free for logo memory
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-video.git master

Done, 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: wd at denx.de
Is truth not truth for all?
	-- Natira, "For the World is Hollow and I have Touched
		   the Sky", stardate 5476.4.



From wd at denx.de  Thu Apr 24 14:22:41 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 14:22:41 +0200
Subject: [U-Boot-Users] [PATCH] fsl_pci: Only modify registers if we
	have them
In-Reply-To: Your message of "Wed, 23 Apr 2008 16:58:04 CDT."
	<Pine.LNX.4.64.0804231657230.13544@blarg.am.freescale.net>
Message-ID: <20080424122241.44AB224AB3@gemini.denx.de>

In message <Pine.LNX.4.64.0804231657230.13544 at blarg.am.freescale.net> you wrote:
> pme_msg_det exists only on PCIe controllers only set it if we are a "bridge".
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
> 
> A fix for 1.3.3.
> 
>  drivers/pci/fsl_pci_init.c |    3 ++-
>  1 files changed, 2 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: wd at denx.de
You're dead, Jim.
	-- McCoy, "Amok Time", stardate 3372.7



From garyj at denx.de  Thu Apr 24 14:28:00 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Thu, 24 Apr 2008 14:28:00 +0200
Subject: [U-Boot-Users] [PATCH 1/2] Add the Harris QUAD100HD AMCC
 405EP-based board.
In-Reply-To: <200804240802.47301.sr@denx.de>
References: <mailman.115528.1208956369.5026.u-boot-users@lists.sourceforge.net>
	<48100C0D.708@denx.de> <200804240802.47301.sr@denx.de>
Message-ID: <20080424142800.0f5d22cc@peedub.jennejohn.org>

On Thu, 24 Apr 2008 08:02:46 +0200
Stefan Roese <sr at denx.de> wrote:

> On Thursday 24 April 2008, Heiko Schocher wrote:
> > > Add the Harris QUAD100HD AMCC 405EP-based board.
> > >
> > > Signed-off-by: Gary Jennejohn <garyj at denx.de>
> > > ---
> > >  MAINTAINERS                 |    4 +
> > >  MAKEALL                     |    1 +
> > >  Makefile                    |    3 +
> > >  board/quad100hd/Makefile    |   51 ++
> > >  board/quad100hd/config.mk   |   24 +
> > >  board/quad100hd/flash.c     | 1097
> > > +++++++++++++++++++++++++++++++++++++++++++
> >
> > Do you really need a boardspecific flash driver? Are these flashes not
> > CFI compatible?
> 
> Yes, I had the some question in mind. Which FLASH chips are used on the board?
> 

As I told Stefan in a private mail, the board has a S29AL032D on-board.

I guess maybe I got a little confused, becasue the customer stated that
this board is based on the taihu, and taihu has its own flash.c.  As a
result I copied and used the flash.c from taihu.  I also partly based the
config file (quad100hd.h) on taihu.h.

I'll look into using the generic CFI driver.

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From galak at kernel.crashing.org  Thu Apr 24 14:40:51 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Thu, 24 Apr 2008 07:40:51 -0500
Subject: [U-Boot-Users] [PATCH v3] 85xx: Round up frequency calculations
	to get reasonable output
In-Reply-To: <2acbd3e40804211045i59d8f56nf9d4d224220252c9@mail.gmail.com>
References: <Pine.LNX.4.64.0804210927530.18126@blarg.am.freescale.net>
	<2acbd3e40804211045i59d8f56nf9d4d224220252c9@mail.gmail.com>
Message-ID: <F107A121-2060-4FF7-8BF9-597180D1FD1F@kernel.crashing.org>


On Apr 21, 2008, at 12:45 PM, Andy Fleming wrote:
> On Mon, Apr 21, 2008 at 9:28 AM, Kumar Gala  
> <galak at kernel.crashing.org> wrote:
>> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
>>
>> Introduced DIV_ROUND_UP and roundup taken from linux kernel.
>>
>> Signed-off-by: Dejan Minic <minic at freescale.com>
>> Signed-off-by: Srikanth Srinivasan  
>> <srikanth.srinivasan at freescale.com>
>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>
> Acked-by: Andy Fleming <afleming at freescale.com>
>
> Andy

Wolfgang,

reminder to apply this if its ok.

- k



From galak at kernel.crashing.org  Thu Apr 24 14:41:08 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Thu, 24 Apr 2008 07:41:08 -0500
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
In-Reply-To: <1208801067-307-1-git-send-email-afleming@freescale.com>
References: <1208801067-307-1-git-send-email-afleming@freescale.com>
Message-ID: <BABB963C-D453-4254-B8FD-5B1EAEC468B7@kernel.crashing.org>


On Apr 21, 2008, at 1:04 PM, Andy Fleming wrote:
> are available in the git repository at:
>
>  git://www.denx.de/git/u-boot-mpc85xx.git master
>
> Kumar Gala (1):
>      85xx: Fix size of cpu-release-addr property
>
> Timur Tabi (1):
>      Fix calculation of I2C clock for some 85xx chips
>
> cpu/mpc85xx/fdt.c            |    2 +-
> cpu/mpc85xx/speed.c          |   31 ++++++++++++++++++++++++++++++-
> include/asm-ppc/immap_85xx.h |    4 +++-
> 3 files changed, 34 insertions(+), 3 deletions(-)

Wolfgang,

reminder to pull this if its ok.

- k



From mshiokawa at miraclelinux.com  Thu Apr 24 14:42:15 2008
From: mshiokawa at miraclelinux.com (Makito SHIOKAWA)
Date: Thu, 24 Apr 2008 21:42:15 +0900
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
In-Reply-To: <48104C55.6020107@semihalf.com>
References: <480FF63C.2030407@miraclelinux.com> <48104C55.6020107@semihalf.com>
Message-ID: <48108027.7020605@miraclelinux.com>

> You might want to have a look an the new image format introduced
> recently. It allows you to have multiple kernels (and ramdisks, and
> other types of images) in one image file, and access these components in
> elegant way. Have a look in doc/uImage.FIT/. In particular,
> doc/uImage.FIT/command_syntax_extensions.txt describes new syntax that
> you might find useful.

I've read it but I'm afraid it's bit different from Boot Image Fallback.

Boot Image Fallback decides image to boot according to a order of images to 
boot and depending on previous boot has succeeded or not. So, this kind of 
mechanism is still needed.

 >> * default
 >>
 >> It holds default entry that "bootmf" tries to boot on default.
 >
 > Please check the "default booting configuration" feature of the new
 > image format, seems like it might be what you're looking for.

Also, on Boot Image Fallback, "default" changes dynamically but "default 
booting configuration" is embedded in ".its" and it's static.


Anyway thank you. By the way, is it able to define "bootargs" for each image 
entry on ".its"?


Regards,

-- 
/********************************
  * MIRACLE LINUX CORPORATION    *
  * Makito SHIOKAWA              *
  * <mshiokawa at miraclelinux.com> *
  ********************************/



From sr at denx.de  Thu Apr 24 15:07:57 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 15:07:57 +0200
Subject: [U-Boot-Users] PPC440EPx/sequoia TLB question...
In-Reply-To: <1209038285.2946.17.camel@vader.jdub.homelinux.org>
References: <480EA8E1.4060207@verizon.net> <200804240728.44082.sr@denx.de>
	<1209038285.2946.17.camel@vader.jdub.homelinux.org>
Message-ID: <200804241507.58057.sr@denx.de>

On Thursday 24 April 2008, Josh Boyer wrote:
> > > Hard to define "works fine" - this is the same 440EPx platform I'm
> > > asking about over in the embedded Linux mailing list.  I'm pretty sure
> > > the kernel doesn't flag SDRAM as Guarded,
> >
> > Yes, and the 4xx code to dynamically set the SDRAM TLB's in the SPD code
> > doesn't set it either. So it really isn't needed.
>
> Actually, that's not true for kernel memory.  We pin 256MiB TLBs to
> cover lowmem in AS0, and the Guarded bit is set.  We set it to prevent
> speculative access to memory holes where the 256MiB TLB covers more
> address space than there is physical DRAM.

I wasn't aware of this. Thanks for the explanation.

Best regards,
Stefan



From sr at denx.de  Thu Apr 24 15:06:17 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 15:06:17 +0200
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
In-Reply-To: <1209038406.2946.20.camel@vader.jdub.homelinux.org>
References: <480EADF4.2020706@verizon.net> <200804240636.12349.sr@denx.de>
	<1209038406.2946.20.camel@vader.jdub.homelinux.org>
Message-ID: <200804241506.17386.sr@denx.de>

On Thursday 24 April 2008, Josh Boyer wrote:
> > This depends. When the bootwrapper version is used then yes, the kernel
> > should get changed. This is because the bootwrapper detects the SDRAM
> > size from the DDR2 controller and passes it to Linux.
> >
> > Without bootwrapper no changes are needed, since U-Boot already passes
> > the corrected memory size to Linux (totalsize-4k currently).
>
> Hm.  Given that AMCC ships the boards with an older U-Boot that requires
> cuImages, I think we'll need to patch the wrapper.

Yes, this should be done too. I forgot about it since I usually don't use the 
wrapper.

> Does 440GRx share 
> this same errata?  I would think so.

Yep. Same problem on 440GRx.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Thu Apr 24 15:12:52 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 15:12:52 +0200
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
In-Reply-To: Your message of "Thu, 24 Apr 2008 18:59:05 +0900."
	<481059E9.5090302@miraclelinux.com>
Message-ID: <20080424131252.278D024AB1@gemini.denx.de>

In message <481059E9.5090302 at miraclelinux.com> you wrote:
> 
>  > of bootm'. The bootlimit/altbootcmd function (in your case probably together
>  > with a hardware watchdog) could be the stuff you are (and I was) looking for.
> 
> This corresponds to CGL Availability Requirements Definition V4.0: AVL.9.1, 
> whereas Boot Image Fallback is AVL.9.0.
> (http://developer.osdl.org/dev/cgl/cgl40/cgl40-availability.pdf)
> Boot Image Fallback must handle not only image CRC error before kernel boot, 
> but a boot failure like kernel panic during kernel boot process (after image 
> has successfully loaded). Also, it must fallback after power-on reset.

Actually it implements the features needed to handle all of this.

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: wd at denx.de
Every revolutionary idea - in science, politics, art, or  whatever  -
evokes three stages of reaction in a hearer:
  1. It is completely impossible - don't waste my time.
  2. It is possible, but it is not worth doing.
  3. I said it was a good idea all along.



From wd at denx.de  Thu Apr 24 15:23:03 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 15:23:03 +0200
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
In-Reply-To: Your message of "Thu, 24 Apr 2008 21:42:15 +0900."
	<48108027.7020605@miraclelinux.com>
Message-ID: <20080424132303.4887924AB1@gemini.denx.de>

In message <48108027.7020605 at miraclelinux.com> you wrote:
>
> I've read it but I'm afraid it's bit different from Boot Image Fallback.
> 
> Boot Image Fallback decides image to boot according to a order of images to 
> boot and depending on previous boot has succeeded or not. So, this kind of 
> mechanism is still needed.

Are you aware that U-Boot has scripting capabilities, to the extend of
being able to run shell scripts?

What you are asking for can be pretty easily implemented using a few
macro definitions utilizing the aforementioned features.

If you think something is missing, please point out which specific
feature you think is missing.

Please make sure to read the previous postings and the available
documentation on this topic.

> Also, on Boot Image Fallback, "default" changes dynamically but "default 
> booting configuration" is embedded in ".its" and it's static.

You can define boot commands, and change these definitions with each
boot you perform.

Don't look for a turn-key solution, instead look for building blocks
which you can easily put together.

> Anyway thank you. By the way, is it able to define "bootargs" for each image 
> entry on ".its"?

The "bootargs" variable normally gets built dynamically, and of cource
you can change the settings each time you build it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The one charm of marriage is that it makes a  life  of  deception  a
neccessity."                                            - Oscar Wilde



From wd at denx.de  Thu Apr 24 15:30:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 15:30:01 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
In-Reply-To: Your message of "Mon, 21 Apr 2008 13:04:27 CDT."
	<1208801067-307-1-git-send-email-afleming@freescale.com>
Message-ID: <20080424133001.218CB24AB1@gemini.denx.de>

In message <1208801067-307-1-git-send-email-afleming at freescale.com> you wrote:
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc85xx.git master
> 
> Kumar Gala (1):
>       85xx: Fix size of cpu-release-addr property
> 
> Timur Tabi (1):
>       Fix calculation of I2C clock for some 85xx chips
> 
>  cpu/mpc85xx/fdt.c            |    2 +-
>  cpu/mpc85xx/speed.c          |   31 ++++++++++++++++++++++++++++++-
>  include/asm-ppc/immap_85xx.h |    4 +++-
>  3 files changed, 34 insertions(+), 3 deletions(-)

Done, 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: wd at denx.de
The price of curiosity is a terminal experience.
                         - Terry Pratchett, _The Dark Side of the Sun_



From wd at denx.de  Thu Apr 24 15:31:08 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 15:31:08 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
In-Reply-To: Your message of "Thu, 24 Apr 2008 07:41:08 CDT."
	<BABB963C-D453-4254-B8FD-5B1EAEC468B7@kernel.crashing.org>
Message-ID: <20080424133108.ED4B524AB1@gemini.denx.de>

In message <BABB963C-D453-4254-B8FD-5B1EAEC468B7 at kernel.crashing.org> you wrote:
> 
> On Apr 21, 2008, at 1:04 PM, Andy Fleming wrote:
> > are available in the git repository at:
> >
> >  git://www.denx.de/git/u-boot-mpc85xx.git master
> >
> > Kumar Gala (1):
> >      85xx: Fix size of cpu-release-addr property
> >
> > Timur Tabi (1):
> >      Fix calculation of I2C clock for some 85xx chips
> >
> > cpu/mpc85xx/fdt.c            |    2 +-
> > cpu/mpc85xx/speed.c          |   31 ++++++++++++++++++++++++++++++-
> > include/asm-ppc/immap_85xx.h |    4 +++-
> > 3 files changed, 34 insertions(+), 3 deletions(-)
> 
> Wolfgang,
> 
> reminder to pull this if its ok.

That was less than 3 days ago. Sorry, I'm not that fast...

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: wd at denx.de
No journaling file system can recover your data if the disk dies.
                                 - Steve Rago in <D4Cw1p.L9E at plc.com>



From wd at denx.de  Thu Apr 24 15:33:05 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 15:33:05 +0200
Subject: [U-Boot-Users] [PATCH v3] 85xx: Round up frequency calculations
	to get reasonable output
In-Reply-To: Your message of "Thu, 24 Apr 2008 07:40:51 CDT."
	<F107A121-2060-4FF7-8BF9-597180D1FD1F@kernel.crashing.org>
Message-ID: <20080424133305.F3F6D24AB1@gemini.denx.de>

In message <F107A121-2060-4FF7-8BF9-597180D1FD1F at kernel.crashing.org> you wrote:
> 
> On Apr 21, 2008, at 12:45 PM, Andy Fleming wrote:
> > On Mon, Apr 21, 2008 at 9:28 AM, Kumar Gala  
> > <galak at kernel.crashing.org> wrote:
> >> eg. because of rounding error we can get 799Mhz instead of 800Mhz.
> >>
> >> Introduced DIV_ROUND_UP and roundup taken from linux kernel.
> >>
> >> Signed-off-by: Dejan Minic <minic at freescale.com>
> >> Signed-off-by: Srikanth Srinivasan  
> >> <srikanth.srinivasan at freescale.com>
> >> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> >
> > Acked-by: Andy Fleming <afleming at freescale.com>
> >
> > Andy
> 
> Wolfgang,
> 
> reminder to apply this if its ok.

Will do as fast as I can.

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: wd at denx.de
The Gates in my computer are AND, OR and NOT; they are not Bill.



From andre.schwarz at matrix-vision.de  Thu Apr 24 16:23:04 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 24 Apr 2008 16:23:04 +0200
Subject: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
In-Reply-To: <NPAblFOq.1208508046.5957230.tor@localhost>
References: <NPAblFOq.1208508046.5957230.tor@localhost>
Message-ID: <481097C8.1060607@matrix-vision.de>

Tor,

at last I could solve my "strange" behaviour.

Actually the PHY definitely uses both 2 bit definitions of Rx and Tx Skew at
"RGMII Skew Control Reg" 0x1c - which are set up by eeprom or strapping.

Due to noise or strapping resistor mismatch these setting are not always
like
I want them to be.

Setting bit 8 in "Extended PHY Control 1" @ 0x17 activates the delay lines.
Obviously your Skew values did match.

I'll send a patch to configure the delay.

Cheers,
Andre

Tor Krill schrieb:
> Hi,
>
> On 4/17/2008, "Andre Schwarz" <andre.schwarz at matrix-vision.de> wrote:
>
>   
>> Tor,
>>
>> after all my VSC8601 is up and running on MPC8343  :-)
>>
>> I'm sorry to say that I don't find this patch ok after going through the
>> manuals :
>>
>> Register 0x17 is a very coarse setting. If the capabilities of the PHY
>> should be taken into account and be configurable we should use the skew
>> control in extended register 0x1c. This should be definable -
>> CFG_VSC8601_SKEWFIX simply applies maximum skew ...
>>     
>
> Sure it certainly could have been done in a more configurable way. But
> you have to decide what you need. For us this was an apropriate level
> atm that scratched our itch. If we where to expose every setting from
> the start we still would not have been done  ;)
>
>   
>> After all changing the bits in register 0x17 _require_ a soft reset by
>> asserting bit 15 in register 0 before they are going to work.
>>
>> Obviously this patch has no effect at all.
>> Do you reset the PHY manually after this configuration ?
>>     
>
> According to our datasheet (dated july 2006) only changes of bit 12 in
> this register needs a software reset to take. We don't reset the phy
> after changing this and the change obviously work (we have tested and
> verified that it won't work without the change).
>
>   
>> This PHY definitely needs a proper setup function since there are quite
>> interesting registers which need read-modify-write.
>>
>> What do you think ?
>>     
>
> Perhaps a patch to improve what you find missing?
>
> /Tor
>
>   
>> Kim Phillips schrieb:
>>     
>>> On Mon, 31 Mar 2008 10:01:34 -0400
>>> Ben Warren <biggerbadderben at gmail.com> wrote:
>>>
>>>
>>>       
>>>> Tor Krill wrote:
>>>>
>>>>         
>>>>> Add phy_info for Vitesse VSC8601.
>>>>> Add config option, CFG_VSC8601_SKEWFIX, to enable RGMII skew timing compensation.
>>>>>
>>>>> Signed-off-by: Tor Krill <tor at excito.com>
>>>>>
>>>>>
>>>>>           
>>>> Acked-by: Ben Warren <biggerbadderben at gmail.com>
>>>>
>>>>         
>>> I don't have a Vitesse 8601, so technically I can't ack it, but I can:
>>>
>>> Reviewed-by: Kim Phillips <kim.phillips at freescale.com>
>>>
>>> minor nit: it would be nice if the following:
>>>
>>>
>>>       
>>>>> +#ifdef CFG_VSC8601_SKEWFIX
>>>>> +				{MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
>>>>> +#endif
>>>>>
>>>>>           
>>> were made to have spaces after commas, and flow onto a separate
>>> line so as to not be a 96 char line..
>>>
>>> Kim
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>>> _______________________________________________
>>> U-Boot-Users mailing list
>>> U-Boot-Users at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>>
>>>       
>>
>> MATRIX VISION GmbH, Talstra??e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
>> Gesch??ftsf??hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
>>     


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From zhanglei459 at gmail.com  Thu Apr 24 16:25:22 2008
From: zhanglei459 at gmail.com (zhanglei459)
Date: Thu, 24 Apr 2008 07:25:22 -0700 (PDT)
Subject: [U-Boot-Users]  Can u-boot support fujitsu video chip mb86297?
Message-ID: <16850729.post@talk.nabble.com>


Hi,all:
    I find there is a new video driver mb862xx.c in u-boot 1.3.2,can it
support mb86297?Thanks a lot!
-- 
View this message in context: http://www.nabble.com/Can-u-boot-support-fujitsu-video-chip-mb86297--tp16850729p16850729.html
Sent from the Uboot - Users mailing list archive at Nabble.com.




From sr at denx.de  Thu Apr 24 16:33:39 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 16:33:39 +0200
Subject: [U-Boot-Users] [PATCH] The patch adds new POST tests for the
	Lwmon5 board.
In-Reply-To: <1208874293-2123-2-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-2-git-send-email-wd@denx.de>
Message-ID: <200804241633.40096.sr@denx.de>

On Tuesday 22 April 2008, Wolfgang Denk wrote:
> From: Yuri Tikhonov <yur at pollux.denx.de>
>
> * External Watchdog test;
> * dsPIC tests;
> * FPGA test;
> * GDC test;
> * Sysmon tests.
>
> Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
> Signed-off-by: Yuri Tikhonov <yur at emcraft.com>

Already included in current U-Boot.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Thu Apr 24 16:34:01 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 16:34:01 +0200
Subject: [U-Boot-Users] [PATCH] Some fixes to dspic, fpga,
	and gdc post tests for lwmon5.
In-Reply-To: <1208874293-2123-4-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-3-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
Message-ID: <200804241634.01289.sr@denx.de>

On Tuesday 22 April 2008, Wolfgang Denk wrote:
> From: Yuri Tikhonov <yur at pollux.denx.de>
>
> Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
> Signed-off-by: Yuri Tikhonov <yur at emcraft.com>

Already included in current U-Boot.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Thu Apr 24 16:35:09 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 16:35:09 +0200
Subject: [U-Boot-Users] [PATCH] Add support for the lwmon5 board reset
	via GPIO58.
In-Reply-To: <1208874293-2123-5-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-4-git-send-email-wd@denx.de>
	<1208874293-2123-5-git-send-email-wd@denx.de>
Message-ID: <200804241635.09287.sr@denx.de>

On Tuesday 22 April 2008, Wolfgang Denk wrote:
> From: Yuri Tikhonov <yur at pollux.denx.de>
>
> Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
> Signed-off-by: Yuri Tikhonov <yur at emcraft.com>

Already included in current U-Boot.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From andre.schwarz at matrix-vision.de  Thu Apr 24 16:45:37 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Thu, 24 Apr 2008 16:45:37 +0200
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
Message-ID: <48109D11.9070508@matrix-vision.de>

The Vitesse VSC8601 RGMII PHY has internal delay for both Rx
and Tx clock lines. They are configured using 2 bits in extended
register 0x17.
Therefore CFG_VSC8601_SKEW_TX and CFG_VSC8601_SKEW_RX have
been introduced with valid values 0-3 giving 0.0, 1.4,1.7 and 2.0ns delay.

Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
--

 drivers/net/tsec.c |    6 ++++++
 drivers/net/tsec.h |    4 ++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 9d22aa3..06250ae 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -1277,6 +1277,12 @@ struct phy_info phy_info_VSC8601 = {
                 {MIIM_CONTROL, MIIM_CONTROL_INIT, &mii_cr_init},
 #ifdef CFG_VSC8601_SKEWFIX
                
{MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
+#if defined(CFG_VSC8601_SKEW_TX) && defined(CFG_VSC8601_SKEW_RX)
+                {MIIM_EXT_PAGE_ACCESS,1,NULL},
+#define VSC8101_SKEW    (CFG_VSC8601_SKEW_TX<<14)|(CFG_VSC8601_SKEW_RX<<12)
+                {MIIM_VSC8601_SKEW_CTRL,VSC8101_SKEW,NULL},
+                {MIIM_EXT_PAGE_ACCESS,0,NULL},
+#endif
 #endif
                 {miim_end,}
                  },
diff --git a/drivers/net/tsec.h b/drivers/net/tsec.h
index cfa7d1a..e8776b0 100644
--- a/drivers/net/tsec.h
+++ b/drivers/net/tsec.h
@@ -112,6 +112,8 @@
 #define MIIM_GBIT_CONTROL    0x9
 #define MIIM_GBIT_CONTROL_INIT    0xe00
 
+#define MIIM_EXT_PAGE_ACCESS    0x1f
+
 /* Broadcom BCM54xx -- taken from linux sungem_phy */
 #define MIIM_BCM54xx_AUXSTATUS            0x19
 #define MIIM_BCM54xx_AUXSTATUS_LINKMODE_MASK    0x0700
@@ -163,6 +165,8 @@
 /* Vitesse VSC8601 Extended PHY Control Register 1 */
 #define MIIM_VSC8601_EPHY_CON            0x17
 #define MIIM_VSC8601_EPHY_CON_INIT_SKEW    0x1120
+#define MIIM_VSC8601_SKEW_CTRL        0x1c
+#define MIIM_VSC8601_EPHY_CON_INIT_SKEW    0x1120
 
 /* 88E1011 PHY Status Register */
 #define MIIM_88E1011_PHY_STATUS         0x11


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From wd at denx.de  Thu Apr 24 16:45:17 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 16:45:17 +0200
Subject: [U-Boot-Users] [PATCH][RFC] lib_ppc: make the flush_cache
	stronger
In-Reply-To: Your message of "Tue, 15 Apr 2008 13:22:03 +0800."
	<1208236923.3656.15.camel@localhost.localdomain>
Message-ID: <20080424144517.5F17E24AB1@gemini.denx.de>

In message <1208236923.3656.15.camel at localhost.localdomain> you wrote:
> Current flush_cache code does
> 
> 1. clean the dcache with dcbst, but not invalidate dcache
> 2. invalidate icache
> 
> This patch use the dcbf instead of dcbst to have stronger
> semantic, clean the dcache and invalidate dcache.

On which processors did you test the changes? I have some unclear
memories of dcbf having problems on for example MPC8xx ?

> We have two options:
> 
> 1. Separate functions for them like linux kernel.
>    A. clean dcache (dcbst) for DMA_TO_DEVICE
>    B. invalidate dcache (dcbi) for DMA_FROM_DEVICE
>    C. flush dcache (dcbf) for DMA_BIDIRECTIONAL.
> 2. Make current flush_cache stronger semanctic.
>    use the dcbf instead of dcbst.
> 
> Which one is better? or you have better option?
> Please suggest.

We discussed this a bit on IRC; Kumar suggested to go for 1., and I
agree.

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: wd at denx.de
"I believe the use of noise to make  music  will  increase  until  we
reach  a  music  produced  through  the aid of electrical instruments
which will make available for musical purposes  any  and  all  sounds
that can be heard."                        - composer John Cage, 1937



From sr at denx.de  Thu Apr 24 16:36:35 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 16:36:35 +0200
Subject: [U-Boot-Users] [PATCH] Fix backlight in the lwmon5 POST.
In-Reply-To: <1208874293-2123-7-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-6-git-send-email-wd@denx.de>
	<1208874293-2123-7-git-send-email-wd@denx.de>
Message-ID: <200804241636.35396.sr@denx.de>

On Tuesday 22 April 2008, Wolfgang Denk wrote:
> From: Yuri Tikhonov <yur at pollux.denx.de>
>
> Backlight was switcehd on even when temperature was too low.
>
> Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
> Signed-off-by: Yuri Tikhonov <yur at emcraft.com>

Already included in current U-Boot.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Thu Apr 24 16:43:08 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 16:43:08 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 watchdog: limit trigger rate
In-Reply-To: <1208874293-2123-11-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-10-git-send-email-wd@denx.de>
	<1208874293-2123-11-git-send-email-wd@denx.de>
Message-ID: <200804241643.08145.sr@denx.de>

On Tuesday 22 April 2008, Wolfgang Denk wrote:
> From: Yuri Tikhonov <yur at emcraft.com>
>
> Limit the rate of h/w watch-dog triggering on the LWMON5 board by
> the CONFIG_WD_MAX_RATE value.
>
> Note that an earlier version of this patch which used microseconds
> instead of ticks dis not work. The problem was that we used
> usec2ticks() to convert microseconds into ticks. usec2ticks() uses
> get_tbclk(), which in turn calls get_sys_info(). It turns out that
> this function does a lot of prolonged operations (like divisions)
> which take too much time so we do not trigger the watchdog in time,
> and it resets the system.
>
> Signed-off-by: Yuri Tikhonov <yur at emcraft.com>

Applied to u-boot-ppc4xx repository. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From biggerbadderben at gmail.com  Thu Apr 24 16:54:06 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 24 Apr 2008 07:54:06 -0700
Subject: [U-Boot-Users] TFTP block size is too high
In-Reply-To: <480FDD24.9090909@genesysdesign.com.au>
References: <480FDD24.9090909@genesysdesign.com.au>
Message-ID: <f8328f7c0804240754l76794151u65a6663dcce5421c@mail.gmail.com>

Hi Jared,

On Wed, Apr 23, 2008 at 6:06 PM, Jared Holzman
<j.holzman at genesysdesign.com.au> wrote:
>
>  Does anyone else have problems with the new default tftp block size of 1468
> (set in tftp.c) being too large? I was getting corruption of the d/led
> images until I dropped it down to 1200. I'm afraid I don't have time to
> determine the real maximum size before corruption occurs. Does someone else
> want to look into this?
>
> --

The block size of 1468 assumes that your network can handle an MTU
size of 1500 bytes, which most can by default.  Is there a chance that
somebody's using PPPoE or VPN software or something like that that
would require a reduction of MTU size?

If I were you, the next thing I'd do would be to sniff the
transactions using Wireshark.  It's a fantastic tool that will quickly
help you decide where to focus your efforts.

regards,
Ben



From sr at denx.de  Thu Apr 24 16:50:49 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 16:50:49 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5: Fix register test logic to match
	the specific GDC h/w.
In-Reply-To: <1208874293-2123-8-git-send-email-wd@denx.de>
References: <1208874293-2123-1-git-send-email-wd@denx.de>
	<1208874293-2123-7-git-send-email-wd@denx.de>
	<1208874293-2123-8-git-send-email-wd@denx.de>
Message-ID: <200804241650.49795.sr@denx.de>

On Tuesday 22 April 2008, Wolfgang Denk wrote:
> From: Yuri Tikhonov <yur at pollux.denx.de>
>
> Signed-off-by: Dmitry Rakhchev <rda at emcraft.com>
> Signed-off-by: Yuri Tikhonov <yur at emcraft.com>

Already included in current U-Boot.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Thu Apr 24 16:56:39 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 16:56:39 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx fixup ebc clock in FDT for
	405GP/EP
In-Reply-To: <200804230912.35222.super.firetwister@gmail.com>
References: <200804230912.35222.super.firetwister@gmail.com>
Message-ID: <200804241656.39781.sr@denx.de>

On Wednesday 23 April 2008, Markus Brunner wrote:
> On ppc405EP and ppc405GP (at least) the ebc is directly attached to the plb
> and not to the opb. This patch will try to fixup /plb/ebc if /plb/opb/ebc
> doesn't exist.

This patch does not apply anymore. Please resubmit against the latest 
u-boot-ppc4xx repository.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Thu Apr 24 16:58:59 2008
From: sr at denx.de (Stefan Roese)
Date: Thu, 24 Apr 2008 16:58:59 +0200
Subject: [U-Boot-Users] [PATCH] 4xx: Add bootcount limit handling for
	APC405 boards
In-Reply-To: <200804241133.04972.matthias.fuchs@esd-electronics.com>
References: <200804241133.04972.matthias.fuchs@esd-electronics.com>
Message-ID: <200804241658.59648.sr@denx.de>

On Thursday 24 April 2008, Matthias Fuchs wrote:
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

This patch does not apply anymore. Please resubmit against the latest 
u-boot-ppc4xx repository.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Thu Apr 24 17:08:43 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 17:08:43 +0200
Subject: [U-Boot-Users] [PATCH 3/3] MX31ADS environment variable update,
	spi and rtc support
In-Reply-To: Your message of "Tue, 15 Apr 2008 13:33:11 +0200."
	<Pine.LNX.4.64.0804151330040.5159@axis700.grange>
Message-ID: <20080424150843.32C0B24AB3@gemini.denx.de>

In message <Pine.LNX.4.64.0804151330040.5159 at axis700.grange> you wrote:
> Update MX31ADS default environment to better match the flash layout and 
> the memory map, support SPI and RTC.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Fascinating, a totally parochial attitude.
	-- Spock, "Metamorphosis", stardate 3219.8



From wd at denx.de  Thu Apr 24 17:23:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Thu, 24 Apr 2008 17:23:13 +0200
Subject: [U-Boot-Users] [PATCH v2] Memory footprint optimizations
In-Reply-To: Your message of "Fri, 18 Apr 2008 12:39:23 +0200."
	<20080418103903.9139.17257.stgit@pollux.denx.de>
Message-ID: <20080424152313.151EB24AB3@gemini.denx.de>

In message <20080418103903.9139.17257.stgit at pollux.denx.de> you wrote:
> As suggested by Wolfgang Denk:
> - image printing functions:
>   - remove wrappers
>   - remove indentation prefix from functions' signatures
> - merge getenv_verify and getenv_autostart into one parametrized function
> 
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> 
>  board/siemens/common/fpga.c |    2 +-
>  common/cmd_autoscript.c     |    2 +-
>  common/cmd_bootm.c          |    4 ++-
>  common/cmd_ximg.c           |    2 +-
>  common/image.c              |   56 ++++++++++++++++++-------------------------
>  include/image.h             |    9 ++-----
>  tools/mkimage.c             |    6 ++---
>  7 files changed, 34 insertions(+), 47 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: wd at denx.de
"There was no difference between  the  behavior  of  a  god  and  the
operations of pure chance..."   - Thomas Pynchon, _Gravity's Rainbow_



From niklausgiger at gmx.ch  Thu Apr 24 17:59:41 2008
From: niklausgiger at gmx.ch (Niklaus Giger)
Date: Thu, 24 Apr 2008 17:59:41 +0200
Subject: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
Message-ID: <200804241759.41856.niklausgiger@gmx.ch>

Hi Dave

Dave Littell wrote:
> Hi all,
> 
> I'm working on an AMCC PPC440EPx-based platform that's similar to the
> Sequoia. ?The board runs pretty well, but occasionally takes exceptions
> both in U-Boot and while running Linux. ?The exceptions vary from
> Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and
> DTLB Errors, to DSI, etc., which made us believe there's a problem with
> SDRAM. ?Sometimes there are simple hard lockups from which even the JTAG
> can't regain control. ?However, the SDRAM physical/electrical and DDR
> Controller configurations have been investigated in detail (and some
> corrections made) with no resulting improvement in the exception behavior.
> 
> We see problems primarily at 667 MHz but have noted some issues at 533
> MHz as well. ?Some boards seem particularly susceptible to this while
> others rarely (if ever) exhibit the problem.
> 
> At this point all possibilities are on the table and I'm looking for any
> input from anyone with experience (good, bad, or whatever) with this
> processor and/or designs similar to the Sequoia.
> 
We at netstal.com have here a new PPC440EPx based board called HCU5,
which runs well u-boot and vxWorks 6.4. Last August I had also linux
running which compiled on a NFS root its own kernel for a weekend.

Our HW is stable (running at 667 MHz) and we never had exceptions, which we
could not explain after looking around for its case.

We had (and still have) problems getting our SW (about ?1 M LOC) correctly,
as the PPC440 has a lot of internal concurrency. We had a case were two
lines of C-Code which read some external HW-register were read in the
wrong order the loop was running twice or more times. Therefore we had
to look very carefully at how external devices were accessed and are using
memory barrier like in16/out16 a lot.

I have also seen JTAG lockups but could never figure out why.

Best regards

Niklaus



From agust at denx.de  Thu Apr 24 18:09:09 2008
From: agust at denx.de (Anatolij Gustschin)
Date: Thu, 24 Apr 2008 18:09:09 +0200
Subject: [U-Boot-Users] Can u-boot support fujitsu video chip mb86297?
In-Reply-To: <16850729.post@talk.nabble.com>
References: <16850729.post@talk.nabble.com>
Message-ID: <4810B0A5.3060709@denx.de>

Hi,

zhanglei459 wrote:
> Hi,all:
>     I find there is a new video driver mb862xx.c in u-boot 1.3.2,can it
> support mb86297?Thanks a lot!

no, this driver currently supports mb86295 and mb86276 chips only. If
the time permits, I will try to extend it to support mb86297 chip too.

Best regards,
Anatolij

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



From Ken.Fuchs at bench.com  Thu Apr 24 18:13:12 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Thu, 24 Apr 2008 11:13:12 -0500
Subject: [U-Boot-Users] USB SUPPORT & get_vfatname
In-Reply-To: <48103DFD.1050500@gandalf.sssup.it>
Message-ID: <AA28F077645B324881335614E4F7C428034CE2@win-ex01.bench.com>

My include/fat.h is identical to the fat.h in both
git repository u-boot and git repository u-boot-at91,
except that I put the CHECKCLUST() macro in fat.c
rather than fat.h.

Ken

> -----Original Message-----
> From: michael [mailto:trimarchi at gandalf.sssup.it] 
> Sent: Thursday, April 24, 2008 03:00
> To: Fuchs, Ken
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> 
> 
> Ken.Fuchs at bench.com wrote:
> Ok,
> 
> check your fat.h and your fsdata
> 
> 
> typedef struct {
>         __u8    fatbuf[FATBUFSIZE]; /* Current FAT buffer */
>         int     fatsize;        /* Size of FAT in bits */
>         __u16   fatlength;      /* Length of FAT in sectors */
>         __u16   fat_sect;       /* Starting sector of the FAT */
>         __u16   rootdir_sect;   /* Start sector of root directory */
>         __u16   clust_size;     /* Size of clusters in sectors */
>         short   data_begin;     /* The sector of the first 
> cluster, can 
> be negative */
>         int     fatbufnum;      /* Used by get_fatent, init to -1 */
> } fsdata;
> 
> The fatbuf is on the top?
> 
> Regards Michael
> 
> 
> 
> > Michael,
> >
> > Sorry, your latest get_vfatname patch doesn't work either.
> >
> > FAT16 works perfectly, so the USB code is probably _not_ at 
> fault.  I see only problems with FAT32, but only for _some_ 
> long collections of files.
> >
> > Thus, there may still be a problem with fs/fat/fat.c.  
> Maybe there is something wrong with my copy of fat.c  I 
> attached it;  Perhaps you can see a problem with it.
> >
> > Sincerely,
> >
> > Ken Fuchs
> >
> >   
> >> -----Original Message-----
> >> From: michael [mailto:trimarchi at gandalf.sssup.it] 
> >> Sent: Wednesday, April 23, 2008 06:16
> >> To: michael
> >> Cc: Fuchs, Ken; u-boot-users at lists.sourceforge.net; Wolfgang Denk
> >> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> >>
> >>
> >> Hi,
> >>
> >> michael wrote:
> >>     
> >>> Hi,
> >>>
> >>> Can you try this one?
> >>>
> >>> Revert my last one patch?
> >>> It change the test code, before the while. I use your script on a 
> >>> Compact Flash and it looks fine for me (under linux).
> >>>
> >>> Regards Michael
> >>>
> >>>
> >>>       
> >> --------------------------------------------------------------
> >> ----------
> >>     
> >>> Check if the entry is a valid dir_slot entry, otherwise it 
> >>>       
> >> is a dentry and the
> >>     
> >>> name has to be taken by the get_name function
> >>>
> >>> Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>
> >>>
> >>> ---
> >>>  fs/fat/fat.c |    7 +++++++
> >>>  1 files changed, 7 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> >>> index 49c78ed..bc37cec 100644
> >>> --- a/fs/fat/fat.c
> >>> +++ b/fs/fat/fat.c
> >>> @@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int 
> >>>       
> >> curclust, __u8 *cluster,
> >>     
> >>>  		while (slotptr2->id > 0x01) {
> >>>  			slotptr2++;
> >>>  		}
> >>> +
> >>>  		/* Save the real directory entry */
> >>>  		realdent = (dir_entry*)slotptr2 + 1;
> >>> +		if (slotptr2->attr != ATTR_VFAT) {
> >>> +			get_name ((dir_entry *)realdent, l_name);
> >>> +			goto out;
> >>> +		}
> >>> +
> >>>  		while ((__u8*)slotptr2 >= get_vfatname_block) {
> >>>  			slot2str(slotptr2, l_name, &idx);
> >>>  			slotptr2--;
> >>> @@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int 
> >>>       
> >> curclust, __u8 *cluster,
> >>     
> >>>  	else if (*l_name == aRING) *l_name = '?';
> >>>  	downcase(l_name);
> >>>  
> >>> +out:
> >>>  	/* Return the real directory entry */
> >>>  	memcpy(retdent, realdent, sizeof(dir_entry));
> >>>  
> >>>   
> >>>       
> >> The scripts in this thread can be used to test the fat32 
> >> filesystem. I 
> >> do some tests using Compact Flash
> >> device and this patchs work for me. I would like to know 
> if is a fat 
> >> layer problem or usb layer problem.
> >>
> >> Michael
> >>
> >>
> >>     
> 
> 



From ayman at elkhashab.com  Thu Apr 24 18:10:46 2008
From: ayman at elkhashab.com (Ayman M. El-Khashab)
Date: Thu, 24 Apr 2008 11:10:46 -0500
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <4810AD11.3010307@ovro.caltech.edu>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<20080423150448.GA8998@crust.elkhashab.com>
	<480F6147.4060406@ovro.caltech.edu> <200804240751.42742.sr@denx.de>
	<4810AD11.3010307@ovro.caltech.edu>
Message-ID: <20080424161043.GC7245@crust.elkhashab.com>

On Thu, Apr 24, 2008 at 08:53:53AM -0700, David Hawkins wrote:

> 
> Given that you don't think any of my suggestions are
> possible, I'll have to go download the ppc460 reference
> manual and convince myself :)
> 
> Ame, feel free to chime in if you think any of the ideas
> are possible.

So maybe I need to clarify some more.  The PPC460 data sheet
is not too clear on this yet.  However, here are my thoughts
on this.  Lets just take the simple case as an example.  We
have a plurality of 460s where a single one is the master.
Between the master and all the slaves is a PCI bridge.  The
slaves are hardwired to boot from pci bus memory -- according
to the datasheet that is at a fixed address.  So there does 
not appear to be any need to do anything to the slave upon
power up.  Now the master boots and then allocates a chunk
of contiguous memory using a kernel driver or whatever is
needed.  The image is just whatever the flash image would
normally contain (uboot + kernel + rootfs).  The address of
that chunk is then given to the pci bridge so that it can
perform inbound translation from the address that the PPC
slaves will use to the address where the image is physically
located.  Then the slaves are taken out of reset and begin
reading "flash" across the pci bus which really goes through
the bridge and is mapped to the DRAM on the master (or I 
guess it could be the flash on the master, but DRAM seemed
easier since it is already running).  

Ok, so how many holes does this approach have?

Thanks
- ame



From dwh at ovro.caltech.edu  Thu Apr 24 18:17:39 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Thu, 24 Apr 2008 09:17:39 -0700
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <4810AD11.3010307@ovro.caltech.edu>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<20080423150448.GA8998@crust.elkhashab.com>
	<480F6147.4060406@ovro.caltech.edu> <200804240751.42742.sr@denx.de>
	<4810AD11.3010307@ovro.caltech.edu>
Message-ID: <4810B2A3.8020208@ovro.caltech.edu>

Hi Ame,

> Given that you don't think any of my suggestions are
> possible, I'll have to go download the ppc460 reference
> manual and convince myself :)

There does not appear to be a 460EX User's Manual on
the AMCC web site. Anyone know where to get it?
I created an account just in case it was not visible
to guests, but no change.

The data sheet lists the 460EX is capable of operating
as an agent and can perform PCI boot. However, without
the user's manual, there's no way of figuring out how.

Cheers,
Dave



From dwh at ovro.caltech.edu  Thu Apr 24 17:53:53 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Thu, 24 Apr 2008 08:53:53 -0700
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <200804240751.42742.sr@denx.de>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<20080423150448.GA8998@crust.elkhashab.com>
	<480F6147.4060406@ovro.caltech.edu> <200804240751.42742.sr@denx.de>
Message-ID: <4810AD11.3010307@ovro.caltech.edu>

Hi Stefan,

>> Here's a few ideas then.

Sorry, all of the ideas were based on the MPC8349EA,
which I am currently using. I did not look at the
ppc460 documents, as I was just putting ideas 'out there'.

When the MPC8349EA is booted, you can enable the peripherals
while leaving the core in reset. The IMMRs are memory mapped
to PCI via a 1MB BAR, and there are several other BARs
setup to have 1MB windows. The IMMR registers can be accessed
to setup the memory map of the target processor, and setup
the inbound translation windows. I've been using this
technique to check out all of my hardware, and DMA over
PCI, DDR, and local buses.

Given that you don't think any of my suggestions are
possible, I'll have to go download the ppc460 reference
manual and convince myself :)

Ame, feel free to chime in if you think any of the ideas
are possible.

Cheers,
Dave



From dwh at ovro.caltech.edu  Thu Apr 24 18:39:46 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Thu, 24 Apr 2008 09:39:46 -0700
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <20080424161043.GC7245@crust.elkhashab.com>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<20080423150448.GA8998@crust.elkhashab.com>
	<480F6147.4060406@ovro.caltech.edu> <200804240751.42742.sr@denx.de>
	<4810AD11.3010307@ovro.caltech.edu>
	<20080424161043.GC7245@crust.elkhashab.com>
Message-ID: <4810B7D2.4050309@ovro.caltech.edu>

Hi Ame,

> So maybe I need to clarify some more.  The PPC460 data sheet
> is not too clear on this yet.  However, here are my thoughts
> on this.  Lets just take the simple case as an example.  We
> have a plurality of 460s where a single one is the master.
> Between the master and all the slaves is a PCI bridge.  The
> slaves are hardwired to boot from pci bus memory -- according
> to the datasheet that is at a fixed address.  So there does 
> not appear to be any need to do anything to the slave upon
> power up. 

Really? I didn't see a comment about the fixed address when
I parsed the data sheet. Where is that comment in
PP460EX_DS2063.pdf, rev 1.09 April 14, 2008?

> Now the master boots and then allocates a chunk
> of contiguous memory using a kernel driver or whatever is
> needed.  The image is just whatever the flash image would
> normally contain (uboot + kernel + rootfs). 

Or you could just have a u-boot image, and then use u-boot
to fetch the kernel and rootfs.

> The address of that chunk is then given to the pci bridge
> so that it can perform inbound translation from the address
> that the PPC slaves will use to the address where the image
> is physically located.  Then the slaves are taken out of reset
> and begin reading "flash" across the pci bus which really goes
> through the bridge and is mapped to the DRAM on the master (or I 
> guess it could be the flash on the master, but DRAM seemed
> easier since it is already running).  
> 
> Ok, so how many holes does this approach have?

This seems reasonable to me.

However, without the full users manual for the 460EX, and the
users manual for the pci bridge, I can't really comment more.

Cheers,
Dave




From trimarchi at gandalf.sssup.it  Thu Apr 24 19:01:07 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 24 Apr 2008 19:01:07 +0200
Subject: [U-Boot-Users] USB SUPPORT & get_vfatname
In-Reply-To: <AA28F077645B324881335614E4F7C428034CE2@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CE2@win-ex01.bench.com>
Message-ID: <4810BCD3.7000905@gandalf.sssup.it>

Hi,
Ken.Fuchs at bench.com wrote:
> My include/fat.h is identical to the fat.h in both
> git repository u-boot and git repository u-boot-at91,
> except that I put the CHECKCLUST() macro in fat.c
> rather than fat.h.
>
> Ken
>   

Can you put in debug the fat.c file?
Try to align the temp buffer in fat.c to 32 bit and send to the list
a log file during the fatls command.

To do the align just put the attribute keyword.

fat/fat.c:              __u8 tmpbuf[FS_BLOCK_SIZE] 
__attribute__((aligned(4)));
fat/fat.c:__u8   get_vfatname_block[MAX_CLUSTSIZE] 
__attribute__((aligned(4)));
fat/fat.c:__u8 get_dentfromdir_block[MAX_CLUSTSIZE] 
__attribute__((aligned(4)));
fat/fat.c:__u8 do_fat_read_block[MAX_CLUSTSIZE] 
__attribute__((aligned(4))); 

Your test in my CF card works without problem.

Regards Michael




From avinashs36 at yahoo.com  Thu Apr 24 20:18:20 2008
From: avinashs36 at yahoo.com (Avinash Vijayvergia)
Date: Thu, 24 Apr 2008 11:18:20 -0700 (PDT)
Subject: [U-Boot-Users] help for making a standalone linux device
Message-ID: <177357.53588.qm@web39504.mail.mud.yahoo.com>

Hi folks

I am working on AT91SAM9260EK board from atmel. I have been using uboot to load an root file system from a dev server. I need to put the rfs and uImage in a dataflash and enable autoboot from u-boot so that it can work as a standalone product. Can someone help me with it?

Thanks
Avinash




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080424/ea3d1152/attachment.htm 

From biggerbadderben at gmail.com  Thu Apr 24 20:41:27 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Thu, 24 Apr 2008 11:41:27 -0700
Subject: [U-Boot-Users] help for making a standalone linux device
In-Reply-To: <177357.53588.qm@web39504.mail.mud.yahoo.com>
References: <177357.53588.qm@web39504.mail.mud.yahoo.com>
Message-ID: <f8328f7c0804241141l1977b806qf9866cf640c3f008@mail.gmail.com>

On Thu, Apr 24, 2008 at 11:18 AM, Avinash Vijayvergia
<avinashs36 at yahoo.com> wrote:
>
> Hi folks
>
> I am working on AT91SAM9260EK board from atmel. I have been using uboot to
> load an root file system from a dev server. I need to put the rfs and uImage
> in a dataflash and enable autoboot from u-boot so that it can work as a
> standalone product. Can someone help me with it?
>
Read this:

http://www.denx.de/wiki/DULG/Manual

If you still have questions, ask away.

And please only ask once.

regards,
Ben



From kim.phillips at freescale.com  Thu Apr 24 21:10:31 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Thu, 24 Apr 2008 14:10:31 -0500
Subject: [U-Boot-Users] [PATCH] mpc83xx: bump default loadaddr over fdtaddr,
	to 0x500000
Message-ID: <20080424141031.404c31e3.kim.phillips@freescale.com>

this seems as a good compromise between human memory, typing,
and last but not least, to accommodate for current and future kernel bloat.

Signed-off-by: Kim Phillips <kim.phillips at freescale.com>
---
 include/configs/MPC8313ERDB.h |    2 +-
 include/configs/MPC8315ERDB.h |    2 +-
 include/configs/MPC8323ERDB.h |    2 +-
 include/configs/MPC832XEMDS.h |    2 +-
 include/configs/MPC8349EMDS.h |    2 +-
 include/configs/MPC8349ITX.h  |    2 +-
 include/configs/MPC8360EMDS.h |    2 +-
 include/configs/MPC837XEMDS.h |    2 +-
 include/configs/MPC837XERDB.h |    2 +-
 include/configs/sbc8349.h     |    2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h
index 9576fa5..6eec240 100644
--- a/include/configs/MPC8313ERDB.h
+++ b/include/configs/MPC8313ERDB.h
@@ -543,7 +543,7 @@
 #define CONFIG_UBOOTPATH	u-boot.bin	/* U-Boot image on TFTP server */
 #define CONFIG_FDTFILE		mpc8313erdb.dtb
 
-#define CONFIG_LOADADDR		200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR		500000	/* default location for tftp and bootm */
 #define CONFIG_BOOTDELAY	-1	/* -1 disables auto-boot */
 #define CONFIG_BAUDRATE		115200
 
diff --git a/include/configs/MPC8315ERDB.h b/include/configs/MPC8315ERDB.h
index 432fb31..e0a887c 100644
--- a/include/configs/MPC8315ERDB.h
+++ b/include/configs/MPC8315ERDB.h
@@ -531,7 +531,7 @@
 
 #define CONFIG_BAUDRATE 115200
 
-#define CONFIG_LOADADDR 200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR 500000	/* default location for tftp and bootm */
 
 #define CONFIG_BOOTDELAY 6	/* -1 disables auto-boot */
 #undef CONFIG_BOOTARGS		/* the boot command will set bootargs */
diff --git a/include/configs/MPC8323ERDB.h b/include/configs/MPC8323ERDB.h
index 92d7aa4..32f57ac 100644
--- a/include/configs/MPC8323ERDB.h
+++ b/include/configs/MPC8323ERDB.h
@@ -568,7 +568,7 @@
 #define CONFIG_UBOOTPATH	u-boot.bin	/* U-Boot image on TFTP server */
 #define CONFIG_FDTFILE		mpc832x_rdb.dtb
 
-#define CONFIG_LOADADDR		200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR		500000	/* default location for tftp and bootm */
 #define CONFIG_BOOTDELAY	-1	/* -1 disables auto-boot */
 #define CONFIG_BAUDRATE		115200
 
diff --git a/include/configs/MPC832XEMDS.h b/include/configs/MPC832XEMDS.h
index be2ab45..ddefa5e 100644
--- a/include/configs/MPC832XEMDS.h
+++ b/include/configs/MPC832XEMDS.h
@@ -572,7 +572,7 @@
 
 #define CONFIG_BAUDRATE	115200
 
-#define CONFIG_LOADADDR	200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR	500000	/* default location for tftp and bootm */
 
 #define CONFIG_BOOTDELAY 6 	/* -1 disables auto-boot */
 #undef  CONFIG_BOOTARGS		/* the boot command will set bootargs */
diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h
index 07fefec..364ffac 100644
--- a/include/configs/MPC8349EMDS.h
+++ b/include/configs/MPC8349EMDS.h
@@ -709,7 +709,7 @@
 #define CONFIG_GATEWAYIP	192.168.1.1
 #define CONFIG_NETMASK		255.255.255.0
 
-#define CONFIG_LOADADDR		200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR		500000	/* default location for tftp and bootm */
 
 #define CONFIG_BOOTDELAY	6	/* -1 disables auto-boot */
 #undef  CONFIG_BOOTARGS			/* the boot command will set bootargs */
diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h
index 6b8b74d..be8850a 100644
--- a/include/configs/MPC8349ITX.h
+++ b/include/configs/MPC8349ITX.h
@@ -474,7 +474,7 @@ boards, we say we have two, but don't display a message if we find only one. */
 #define CFG_PROMPT_HUSH_PS2 "> "
 
 #define CFG_LOAD_ADDR	0x2000000	/* default load address */
-#define CONFIG_LOADADDR	200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR	500000	/* default location for tftp and bootm */
 
 #ifdef CONFIG_MPC8349ITX
 #define CFG_PROMPT	"MPC8349E-mITX> "	/* Monitor Command Prompt */
diff --git a/include/configs/MPC8360EMDS.h b/include/configs/MPC8360EMDS.h
index 46451c4..983575e 100644
--- a/include/configs/MPC8360EMDS.h
+++ b/include/configs/MPC8360EMDS.h
@@ -605,7 +605,7 @@
 
 #define CONFIG_BAUDRATE 115200
 
-#define CONFIG_LOADADDR 200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR 500000	/* default location for tftp and bootm */
 
 #define CONFIG_BOOTDELAY 6	/* -1 disables auto-boot */
 #undef	CONFIG_BOOTARGS		/* the boot command will set bootargs */
diff --git a/include/configs/MPC837XEMDS.h b/include/configs/MPC837XEMDS.h
index 7fc0f7e..e92493a 100644
--- a/include/configs/MPC837XEMDS.h
+++ b/include/configs/MPC837XEMDS.h
@@ -595,7 +595,7 @@
 
 #define CONFIG_BAUDRATE 115200
 
-#define CONFIG_LOADADDR 200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR 500000	/* default location for tftp and bootm */
 
 #define CONFIG_BOOTDELAY 6	/* -1 disables auto-boot */
 #undef CONFIG_BOOTARGS		/* the boot command will set bootargs */
diff --git a/include/configs/MPC837XERDB.h b/include/configs/MPC837XERDB.h
index c698ff8..f7e6fd2 100644
--- a/include/configs/MPC837XERDB.h
+++ b/include/configs/MPC837XERDB.h
@@ -629,7 +629,7 @@
 #define CONFIG_UBOOTPATH	u-boot.bin	/* U-Boot image on TFTP server */
 #define CONFIG_FDTFILE		mpc8379_rdb.dtb
 
-#define CONFIG_LOADADDR		200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR		500000	/* default location for tftp and bootm */
 #define CONFIG_BOOTDELAY	-1	/* -1 disables auto-boot */
 #define CONFIG_BAUDRATE		115200
 
diff --git a/include/configs/sbc8349.h b/include/configs/sbc8349.h
index d00c22f..68b5521 100644
--- a/include/configs/sbc8349.h
+++ b/include/configs/sbc8349.h
@@ -662,7 +662,7 @@
 #define CONFIG_GATEWAYIP	192.168.1.1
 #define CONFIG_NETMASK		255.255.255.0
 
-#define CONFIG_LOADADDR		200000	/* default location for tftp and bootm */
+#define CONFIG_LOADADDR		500000	/* default location for tftp and bootm */
 
 #define CONFIG_BOOTDELAY	6	/* -1 disables auto-boot */
 #undef  CONFIG_BOOTARGS			/* the boot command will set bootargs */
-- 
1.5.5




From afilipi at applieddata.net  Thu Apr 24 20:37:41 2008
From: afilipi at applieddata.net (Adrian Filipi)
Date: Thu, 24 Apr 2008 14:37:41 -0400 (EDT)
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <AA28F077645B324881335614E4F7C428034CDD@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CDD@win-ex01.bench.com>
Message-ID: <alpine.DEB.1.10.0804241247140.6097@pmy.adscville>


 	FYI, I too have been seeing this problem.  It is 100% reproducible. 
It seems to be a FAT32 problem with media 256MB and smaller.

 	I have tried various media sizes between 64MB and 2GB, MMC/SD, USB 
and CF media types, different boards (PXA270, EP93xx and IMX31), and lastly 
both the 1.3.2 and the 1.2.0 releases.

 	The 64MB, 128MB and 256MB fails under *ALL* cases when using FAT32. 
All the other sises work with FAT32 and *all* of the media works fine with 
FAT16.

 	FYI, I use "mkfs.vfat -F 32" under linux to make the filesystems.

 	All fingers are pointing to the FAT32 code and not hardware 
dependent code.  It looks like a media size related problem.  This is also 
an old bug given that it's in the 1.2.0 sources.

 	Adrian
--
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com

On Wed, 23 Apr 2008, Ken.Fuchs at bench.com wrote:

> Michael,
>
> I copied all files in fs/fat from git repository u-boot-at91.  Made trivial changes to compile it with my code base.  Added your latest get_vfatname patch, but it had no effect on the issue.  fatls still
> doesn't list filenames in some FAT32 filesystems, including the one
> built via the Linux script I provided earlier in this thread.
>
> Thus, there's no point in looking at the fat.c file I sent earlier
> today.  The problem remains in the git fat.c code or possibly in
> the USB stack code.  However, FAT16 has never failed, so the issue
> is more likely to be with the FAT32 or vfat code.
>
> Sincerely,
>
> Ken Fuchs
>
> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of Ken.Fuchs at bench.com
> Sent: Wednesday, April 23, 2008 13:01
> To: trimarchi at gandalf.sssup.it
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
>
>
> Michael,
>
> Sorry, your latest get_vfatname patch doesn't work either.
>
> FAT16 works perfectly, so the USB code is probably _not_ at fault.  I see only problems with FAT32, but only for _some_ long collections of files.
>
> Thus, there may still be a problem with fs/fat/fat.c.  Maybe there is something wrong with my copy of fat.c  I attached it;  Perhaps you can see a problem with it.
>
> Sincerely,
>
> Ken Fuchs
>
>> -----Original Message-----
>> From: michael [mailto:trimarchi at gandalf.sssup.it]
>> Sent: Wednesday, April 23, 2008 06:16
>> To: michael
>> Cc: Fuchs, Ken; u-boot-users at lists.sourceforge.net; Wolfgang Denk
>> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
>>
>>
>> Hi,
>>
>> michael wrote:
>>> Hi,
>>>
>>> Can you try this one?
>>>
>>> Revert my last one patch?
>>> It change the test code, before the while. I use your script on a
>>> Compact Flash and it looks fine for me (under linux).
>>>
>>> Regards Michael
>>>
>>>
>> --------------------------------------------------------------
>> ----------
>>>
>>> Check if the entry is a valid dir_slot entry, otherwise it
>> is a dentry and the
>>> name has to be taken by the get_name function
>>>
>>> Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>
>>>
>>> ---
>>>  fs/fat/fat.c |    7 +++++++
>>>  1 files changed, 7 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
>>> index 49c78ed..bc37cec 100644
>>> --- a/fs/fat/fat.c
>>> +++ b/fs/fat/fat.c
>>> @@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int
>> curclust, __u8 *cluster,
>>>  		while (slotptr2->id > 0x01) {
>>>  			slotptr2++;
>>>  		}
>>> +
>>>  		/* Save the real directory entry */
>>>  		realdent = (dir_entry*)slotptr2 + 1;
>>> +		if (slotptr2->attr != ATTR_VFAT) {
>>> +			get_name ((dir_entry *)realdent, l_name);
>>> +			goto out;
>>> +		}
>>> +
>>>  		while ((__u8*)slotptr2 >= get_vfatname_block) {
>>>  			slot2str(slotptr2, l_name, &idx);
>>>  			slotptr2--;
>>> @@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int
>> curclust, __u8 *cluster,
>>>  	else if (*l_name == aRING) *l_name = '?';
>>>  	downcase(l_name);
>>>
>>> +out:
>>>  	/* Return the real directory entry */
>>>  	memcpy(retdent, realdent, sizeof(dir_entry));
>>>
>>>
>> The scripts in this thread can be used to test the fat32
>> filesystem. I
>> do some tests using Compact Flash
>> device and this patchs work for me. I would like to know if is a fat
>> layer problem or usb layer problem.
>>
>> Michael
>>
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>



From trimarchi at gandalf.sssup.it  Thu Apr 24 21:26:00 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 24 Apr 2008 21:26:00 +0200
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <alpine.DEB.1.10.0804241247140.6097@pmy.adscville>
References: <AA28F077645B324881335614E4F7C428034CDD@win-ex01.bench.com>
	<alpine.DEB.1.10.0804241247140.6097@pmy.adscville>
Message-ID: <4810DEC8.8030105@gandalf.sssup.it>

Hi,
I try my fix and old version of u-boot system. The only different is the 
align of the buffer. The hardware that I have is tested with the 32Mb, 
64Mb, 128Mb, 256Mb, and it works fine.
I try the scripts without any problem... but the tests doesn't cover all 
the possibility. Can you send me a dd of a compact flash of 64Mb that 
failed. I rewrite it and test and maybe
post a patch.

Regards Michael

Adrian Filipi wrote:
>
>     FYI, I too have been seeing this problem.  It is 100% 
> reproducible. It seems to be a FAT32 problem with media 256MB and 
> smaller.
>
>     I have tried various media sizes between 64MB and 2GB, MMC/SD, USB 
> and CF media types, different boards (PXA270, EP93xx and IMX31), and 
> lastly both the 1.3.2 and the 1.2.0 releases.
>
>     The 64MB, 128MB and 256MB fails under *ALL* cases when using 
> FAT32. All the other sises work with FAT32 and *all* of the media 
> works fine with FAT16.
>
>     FYI, I use "mkfs.vfat -F 32" under linux to make the filesystems.
>
>     All fingers are pointing to the FAT32 code and not hardware 
> dependent code.  It looks like a media size related problem.  This is 
> also an old bug given that it's in the 1.2.0 sources.
>
>     Adrian




From rmcguire at videopresence.com  Thu Apr 24 21:32:21 2008
From: rmcguire at videopresence.com (Russell McGuire)
Date: Thu, 24 Apr 2008 12:32:21 -0700
Subject: [U-Boot-Users] 83xx DDR2 667Mhz memory
In-Reply-To: <mailman.128014.1209064835.5026.u-boot-users@lists.sourceforge.net>
References: <mailman.128014.1209064835.5026.u-boot-users@lists.sourceforge.net>
Message-ID: <000001c8a641$eac1beb0$e505a8c0@absolutdaddy>

All,

Just curious if anyone has done any work with this near past.
I have had an 8360E board up for several months now and been happily working
away with different types of Kingston S0-DIMM DDR2 memory.

512MB, 1204MB, DDR2 533Mhz memory. All work well, with U-boot.
Using the SPD detectetion, things have just been automatically detected and
worked wonderful.

Yesterday I went down and purchased two additional sticks of 1024MB DDR2
Crucial 667Mhz memory, as 533Mhz is in short supply. SPD detect still works
in U-boot and everything is detected correctly. However, the u-boot will now
hang when it tries to transfer execution into RAM. At first I figured this
was a memory speed issue, since 667Mhz is not technically supported on the
8360E yet <Rev 2... I might be wrong on this?>, So I patched in a quick line
of code to force the spd detection to limit to 533Mhz.  Still doesn't work.

Any ideas? Again, same exact u-boot just different memory. SPD sees it all
just fine, just can't use the RAM after its setup. Currently using a
slightly older version of U-boot 1.3.0-dirty.

-Russ
 





From adrian.filipi at eurotech.com  Thu Apr 24 21:02:29 2008
From: adrian.filipi at eurotech.com (Adrian Filipi)
Date: Thu, 24 Apr 2008 15:02:29 -0400 (EDT)
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <4810DEC8.8030105@gandalf.sssup.it>
References: <AA28F077645B324881335614E4F7C428034CDD@win-ex01.bench.com>
	<alpine.DEB.1.10.0804241247140.6097@pmy.adscville>
	<4810DEC8.8030105@gandalf.sssup.it>
Message-ID: <alpine.DEB.1.10.0804241501150.7496@pmy.adscville>


 	The patch didn't improve my first few test cases.  CF and USB on 
an EP93xx board.

 	I'm sending you an image off-list.

 	Adrian
--
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com

On Thu, 24 Apr 2008, michael wrote:

> Hi,
> I try my fix and old version of u-boot system. The only different is the 
> align of the buffer. The hardware that I have is tested with the 32Mb, 64Mb, 
> 128Mb, 256Mb, and it works fine.
> I try the scripts without any problem... but the tests doesn't cover all the 
> possibility. Can you send me a dd of a compact flash of 64Mb that failed. I 
> rewrite it and test and maybe
> post a patch.
>
> Regards Michael
>
> Adrian Filipi wrote:
>>
>>     FYI, I too have been seeing this problem.  It is 100% reproducible. It 
>> seems to be a FAT32 problem with media 256MB and smaller.
>>
>>     I have tried various media sizes between 64MB and 2GB, MMC/SD, USB and 
>> CF media types, different boards (PXA270, EP93xx and IMX31), and lastly 
>> both the 1.3.2 and the 1.2.0 releases.
>>
>>     The 64MB, 128MB and 256MB fails under *ALL* cases when using FAT32. All 
>> the other sises work with FAT32 and *all* of the media works fine with 
>> FAT16.
>>
>>     FYI, I use "mkfs.vfat -F 32" under linux to make the filesystems.
>>
>>     All fingers are pointing to the FAT32 code and not hardware dependent 
>> code.  It looks like a media size related problem.  This is also an old bug 
>> given that it's in the 1.2.0 sources.
>>
>>     Adrian
>
>



From trimarchi at gandalf.sssup.it  Thu Apr 24 23:11:44 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Thu, 24 Apr 2008 23:11:44 +0200
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <alpine.DEB.1.10.0804241501150.7496@pmy.adscville>
References: <AA28F077645B324881335614E4F7C428034CDD@win-ex01.bench.com>
	<alpine.DEB.1.10.0804241247140.6097@pmy.adscville>
	<4810DEC8.8030105@gandalf.sssup.it>
	<alpine.DEB.1.10.0804241501150.7496@pmy.adscville>
Message-ID: <4810F790.1070603@gandalf.sssup.it>

Hi,
just to know! What is the log if you define the

USB_STOR_DEBUG

in the usb_storage.c

Can you send me the log?

Regards Michael

Adrian Filipi wrote:
>
>     The patch didn't improve my first few test cases.  CF and USB on 
> an EP93xx board.
>
>     I'm sending you an image off-list.
>
>     Adrian
> -- 
> Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
>
> On Thu, 24 Apr 2008, michael wrote:
>
>> Hi,
>> I try my fix and old version of u-boot system. The only different is 
>> the align of the buffer. The hardware that I have is tested with the 
>> 32Mb, 64Mb, 128Mb, 256Mb, and it works fine.
>> I try the scripts without any problem... but the tests doesn't cover 
>> all the possibility. Can you send me a dd of a compact flash of 64Mb 
>> that failed. I rewrite it and test and maybe
>> post a patch.
>>
>> Regards Michael
>>
>> Adrian Filipi wrote:
>>>
>>>     FYI, I too have been seeing this problem.  It is 100% 
>>> reproducible. It seems to be a FAT32 problem with media 256MB and 
>>> smaller.
>>>
>>>     I have tried various media sizes between 64MB and 2GB, MMC/SD, 
>>> USB and CF media types, different boards (PXA270, EP93xx and IMX31), 
>>> and lastly both the 1.3.2 and the 1.2.0 releases.
>>>
>>>     The 64MB, 128MB and 256MB fails under *ALL* cases when using 
>>> FAT32. All the other sises work with FAT32 and *all* of the media 
>>> works fine with FAT16.
>>>
>>>     FYI, I use "mkfs.vfat -F 32" under linux to make the filesystems.
>>>
>>>     All fingers are pointing to the FAT32 code and not hardware 
>>> dependent code.  It looks like a media size related problem.  This 
>>> is also an old bug given that it's in the 1.2.0 sources.
>>>
>>>     Adrian
>>
>>
>




From Ken.Fuchs at bench.com  Thu Apr 24 23:30:09 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Thu, 24 Apr 2008 16:30:09 -0500
Subject: [U-Boot-Users] USB SUPPORT & get_vfatname
In-Reply-To: <4810BCD3.7000905@gandalf.sssup.it>
Message-ID: <AA28F077645B324881335614E4F7C428034CE4@win-ex01.bench.com>

USB_STOR_DEBUG log:

Hit any key to stop autoboot:  0
U-Boot> usb reset
usb reset
(Re)start USB...
USB:   scanning bus for devices...
      USB device not responding, giving up (status=20)
3 USB Device(s) found
       scanning bus for storage devices... i=0
i=1


USB Mass Storage device detected
Transport: Bulk/Bulk/Bulk
Endpoints In 1 Out 2 Int 0
BBB_reset
BBB_reset result 0: status 0 reset
BBB_reset result 0: status 0 clearing IN endpoint
BBB_reset result 0: status 0 clearing OUT endpoint
BBB_reset done
 address 2
COMMAND phase
DATA phase
STATUS phase
inquiry returns 0
ISO Vers 2, Response Data 2
COMMAND phase
STATUS phase
FAILED
COMMAND phase
DATA phase
STATUS phase
Request Sense returned 06 28 00
COMMAND phase
STATUS phase
COMMAND phase
DATA phase
STATUS phase
Read Capacity returns: 0xe80300, 0x20000
Capacity = 0x3e801, blocksz = 0x200
 address 2
partype: 0

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk 0, blccnt 1 buffer 23edbbe4
read10: start 0 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 1, blccnt 1 buffer 23edbde4
partype: 2
i=2
i=3
1 Storage Device(s) found
U-Boot> fatls usb 0:1 /
fatls usb 0:1 /

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk 0, blccnt 1 buffer 23edbbc8
read10: start 0 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 1, blccnt 1 buffer 23edbdc8

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk 0, blccnt 1 buffer 23edb998
read10: start 0 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 1, blccnt 1 buffer 23edbb98

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk 20, blccnt 1 buffer 23eda540
read10: start 20 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 21, blccnt 1 buffer 23eda740

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk fa2, blccnt 1 buffer 23f3ad78
read10: start fa2 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk fa3, blccnt 1 buffer 23f3af78
        9   00000000.txt
        9   11111111.txt
        9   22222222.txt
        9   33333333.txt
        9   44444444.txt
        9   55555555.txt
        9   66666666.txt
        9   77777777.txt

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk fa3, blccnt 1 buffer 23f3ad78
read10: start fa3 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk fa4, blccnt 1 buffer 23f3af78
        0   00000000.


9 file(s), 0 dir(s)

U-Boot> 

> -----Original Message-----
> From: michael [mailto:trimarchi at gandalf.sssup.it] 
> Sent: Thursday, April 24, 2008 12:01
> To: Fuchs, Ken
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> 
> 
> Hi,
> Ken.Fuchs at bench.com wrote:
> > My include/fat.h is identical to the fat.h in both
> > git repository u-boot and git repository u-boot-at91,
> > except that I put the CHECKCLUST() macro in fat.c
> > rather than fat.h.
> >
> > Ken
> >   
> 
> Can you put in debug the fat.c file?
> Try to align the temp buffer in fat.c to 32 bit and send to the list
> a log file during the fatls command.
> 
> To do the align just put the attribute keyword.
> 
> fat/fat.c:              __u8 tmpbuf[FS_BLOCK_SIZE] 
> __attribute__((aligned(4)));
> fat/fat.c:__u8   get_vfatname_block[MAX_CLUSTSIZE] 
> __attribute__((aligned(4)));
> fat/fat.c:__u8 get_dentfromdir_block[MAX_CLUSTSIZE] 
> __attribute__((aligned(4)));
> fat/fat.c:__u8 do_fat_read_block[MAX_CLUSTSIZE] 
> __attribute__((aligned(4))); 
> 
> Your test in my CF card works without problem.
> 
> Regards Michael
> 
> 



From Ken.Fuchs at bench.com  Fri Apr 25 01:32:26 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Thu, 24 Apr 2008 18:32:26 -0500
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <alpine.DEB.1.10.0804241247140.6097@pmy.adscville>
Message-ID: <AA28F077645B324881335614E4F7C428034CE5@win-ex01.bench.com>

Thanks for reporting similar problems with U-Boot's FAT32
support.

Adrian Filipi wrote:

> It seems to be a FAT32 problem with media 256MB and smaller.

Thanks for this observation, but this may not be entirely true.
With larger FAT32 filesystems it seems to require more files
in the root directory, before a failure is observed.  For
example, my 1GB pen drive passed my 36 file test, so I created
a test with more files ...

Here's a script to put 1000 files 0.txt through 999.txt
onto the current directory:

#!/bin/bash
for (( number=0 ; number < 1000 ; number++ )) ; do
        echo "${number}" > ${number}.txt
done

--- Here's the output (using my 1GB pen drive) ---

Hit any key to stop autoboot: 58 0
U-Boot> usb reset
usb reset
(Re)start USB...
USB:   scanning bus for devices...
      USB device not responding, giving up (status=20)
3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
U-Boot> fatls usb 0:1 /
fatls usb 0:1 /
        3   92.txt
        3   93.txt
        3   94.txt
        3   95.txt
        3   96.txt
        3   97.txt
        3   98.txt
        3   99.txt
        4   100.txt
        4   101.txt
        4   102.txt
        4   103.txt
        4   104.txt
        4   105.txt
        4   106.txt
        4   107.txt
        4   108.txt
        4   109.txt
        4   110.txt
        4   111.txt
        4   112.txt
        4   113.txt
        4   114.txt
        4   115.txt
        4   116.txt
        4   117.txt
        4   118.txt
        4   119.txt
        4   120.txt
        4   121.txt
        4   122.txt
        4   123.txt
        4   124.txt
        4   125.txt
        4   126.txt
        4   127.txt
        2   0.txt
        2   1.txt
        2   2.txt
        2   3.txt
        2   4.txt
        2   5.txt
        2   6.txt
        2   7.txt
        2   8.txt
        2   9.txt
        3   10.txt
        3   11.txt
        3   12.txt
        3   13.txt
        3   14.txt
        3   15.txt
        3   16.txt
        3   17.txt
        3   18.txt
        3   19.txt
        3   20.txt
        3   21.txt
        3   22.txt
        3   23.txt
        3   24.txt
        3   25.txt
        3   26.txt
        3   27.txt
        3   28.txt
        3   29.txt
        3   30.txt
        3   31.txt
        3   32.txt
        3   33.txt
        3   34.txt
        3   35.txt
        3   36.txt
        3   37.txt
        3   38.txt
        3   39.txt
        3   40.txt
        3   41.txt
        3   42.txt
        3   43.txt
        3   44.txt
        3   45.txt
        3   46.txt
        3   47.txt
        3   48.txt
        3   49.txt
        3   50.txt
        3   51.txt
        3   52.txt
        3   53.txt
        3   54.txt
        3   55.txt
        3   56.txt
        3   57.txt
        3   58.txt
        3   59.txt
        3   60.txt
        3   61.txt
        3   62.txt
        3   63.txt
        3   64.txt
        3   65.txt
        3   66.txt
        3   67.txt
        3   68.txt
        3   69.txt
        3   70.txt
        3   71.txt
        3   72.txt
        3   73.txt
        3   74.txt
        3   75.txt
        3   76.txt
        3   77.txt
        3   78.txt
        3   79.txt
        3   80.txt
        3   81.txt
        3   82.txt
        3   83.txt
        3   84.txt
        3   85.txt
        3   86.txt
        3   87.txt
        3   88.txt
        3   89.txt
        3   90.txt
        3   91.txt
        0   0


129 file(s), 0 dir(s)

U-Boot> 

Organization of the 1GB pen drive:

# fdisk -l /dev/sda

Disk /dev/sda: 1037 MB, 1037615104 bytes
256 heads, 32 sectors/track, 247 cylinders
Units = cylinders of 8192 * 512 = 4194304 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         247     1011696    b  W95 FAT32
# 

------

> both the 1.3.2 and the 1.2.0 releases.

It is good to know that v1.3.2 has this FAT32 bug.
I can confirm that the bug is present in 1.1.5 as well.

>  	The 64MB, 128MB and 256MB fails under *ALL* cases when 
> using FAT32. 
> All the other sizes work with FAT32 and *all* of the media 
> works fine with FAT16.

I agree with this statement, except failures do occur on media
larger than 256MB.  It just takes more files on the root directory
before a failure is observed.

>  	FYI, I use "mkfs.vfat -F 32" under linux to make the 
> filesystems.

Since it makes scripts more readable I'll use mkfs.vfat in the
future.  Thanks.  BTW, mkfs.vfat and mkdosfs are the same file.

>  	All fingers are pointing to the FAT32 code and not hardware 
> dependent code.  It looks like a media size related problem.

I agree, since no failures have been observed on FAT16 and you
tested several targets.

Be sure to include the most recent vfat patch at the very end
(deeply quoted part) of this message.

--- FAT16 benchmark test with 1GB pen drive (512 files) ---

U-Boot> fatls usb 0:1 /
fatls usb 0:1 /

        2   0.txt
        2   1.txt
        2   2.txt
        2   3.txt
        2   4.txt
        2   5.txt
        2   6.txt
        2   7.txt
        2   8.txt
        2   9.txt
        3   10.txt
        3   11.txt
        3   12.txt
        3   13.txt
        3   14.txt
        3   15.txt

        3   16.txt
        3   17.txt
        3   18.txt
        3   19.txt
        3   20.txt
        3   21.txt
        3   22.txt
        3   23.txt
        3   24.txt
        3   25.txt
        3   26.txt
        3   27.txt
        3   28.txt
        3   29.txt
        3   30.txt
        3   31.txt

...

        4   480.txt
        4   481.txt
        4   482.txt
        4   483.txt
        4   484.txt
        4   485.txt
        4   486.txt
        4   487.txt
        4   488.txt
        4   489.txt
        4   490.txt
        4   491.txt
        4   492.txt
        4   493.txt
        4   494.txt
        4   495.txt

        4   496.txt
        4   497.txt
        4   498.txt
        4   499.txt
        4   500.txt
        4   501.txt
        4   502.txt
        4   503.txt
        4   504.txt
        4   505.txt
        4   506.txt
        4   507.txt
        4   508.txt
        4   509.txt
        4   510.txt
        4   511.txt

        0   0


513 file(s), 0 dir(s)

U-Boot> 

------

All 512 files are listed OK, but a blank line was added
every 16 files and there is a 513th file "0" that doesn't
exist.  All files on FAT16 are accessible, but there
may be a trivial non-existent file bug in FAT16 as well.

Just to be clear, my script that should put 1000 files
in /, could only put 512 of them on, since FAT16 has some
limitation of the number of files in a directory.

Sincerely,

Ken Fuchs

> -----Original Message-----
> From: afilipi at pmy.adscville [mailto:afilipi at pmy.adscville] On 
> Behalf Of Adrian Filipi
> Sent: Thursday, April 24, 2008 13:38
> To: Fuchs, Ken
> Cc: trimarchi at gandalf.sssup.it; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] FW: USB SUPPORT & get_vfatname
> 
> 
> 
>  	FYI, I too have been seeing this problem.  It is 100% 
> reproducible. 
> It seems to be a FAT32 problem with media 256MB and smaller.
> 
>  	I have tried various media sizes between 64MB and 2GB, 
> MMC/SD, USB 
> and CF media types, different boards (PXA270, EP93xx and 
> IMX31), and lastly 
> both the 1.3.2 and the 1.2.0 releases.
> 
>  	The 64MB, 128MB and 256MB fails under *ALL* cases when 
> using FAT32. 
> All the other sises work with FAT32 and *all* of the media 
> works fine with 
> FAT16.
> 
>  	FYI, I use "mkfs.vfat -F 32" under linux to make the 
> filesystems.
> 
>  	All fingers are pointing to the FAT32 code and not hardware 
> dependent code.  It looks like a media size related problem.  
> This is also 
> an old bug given that it's in the 1.2.0 sources.
> 
>  	Adrian
> --
> Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com
> 
> On Wed, 23 Apr 2008, Ken.Fuchs at bench.com wrote:
> 
> > Michael,
> >
> > I copied all files in fs/fat from git repository 
> u-boot-at91.  Made trivial changes to compile it with my code 
> base.  Added your latest get_vfatname patch, but it had no 
> effect on the issue.  fatls still
> > doesn't list filenames in some FAT32 filesystems, including the one
> > built via the Linux script I provided earlier in this thread.
> >
> > Thus, there's no point in looking at the fat.c file I sent earlier
> > today.  The problem remains in the git fat.c code or possibly in
> > the USB stack code.  However, FAT16 has never failed, so the issue
> > is more likely to be with the FAT32 or vfat code.
> >
> > Sincerely,
> >
> > Ken Fuchs
> >
> > -----Original Message-----
> > From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Ken.Fuchs at bench.com
> > Sent: Wednesday, April 23, 2008 13:01
> > To: trimarchi at gandalf.sssup.it
> > Cc: u-boot-users at lists.sourceforge.net
> > Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> >
> >
> > Michael,
> >
> > Sorry, your latest get_vfatname patch doesn't work either.
> >
> > FAT16 works perfectly, so the USB code is probably _not_ at 
> fault.  I see only problems with FAT32, but only for _some_ 
> long collections of files.
> >
> > Thus, there may still be a problem with fs/fat/fat.c.  
> Maybe there is something wrong with my copy of fat.c  I 
> attached it;  Perhaps you can see a problem with it.
> >
> > Sincerely,
> >
> > Ken Fuchs
> >
> >> -----Original Message-----
> >> From: michael [mailto:trimarchi at gandalf.sssup.it]
> >> Sent: Wednesday, April 23, 2008 06:16
> >> To: michael
> >> Cc: Fuchs, Ken; u-boot-users at lists.sourceforge.net; Wolfgang Denk
> >> Subject: Re: [U-Boot-Users] USB SUPPORT & get_vfatname
> >>
> >>
> >> Hi,
> >>
> >> michael wrote:
> >>> Hi,
> >>>
> >>> Can you try this one?
> >>>
> >>> Revert my last one patch?
> >>> It change the test code, before the while. I use your script on a
> >>> Compact Flash and it looks fine for me (under linux).
> >>>
> >>> Regards Michael
> >>>
> >>>
> >> --------------------------------------------------------------
> >> ----------
> >>>
> >>> Check if the entry is a valid dir_slot entry, otherwise it
> >> is a dentry and the
> >>> name has to be taken by the get_name function
> >>>
> >>> Signed-off-by: michael trimarchi <trimarchi at gandalf.sssup.it>
> >>>
> >>> ---
> >>>  fs/fat/fat.c |    7 +++++++
> >>>  1 files changed, 7 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> >>> index 49c78ed..bc37cec 100644
> >>> --- a/fs/fat/fat.c
> >>> +++ b/fs/fat/fat.c
> >>> @@ -473,8 +473,14 @@ get_vfatname(fsdata *mydata, int
> >> curclust, __u8 *cluster,
> >>>  		while (slotptr2->id > 0x01) {
> >>>  			slotptr2++;
> >>>  		}
> >>> +
> >>>  		/* Save the real directory entry */
> >>>  		realdent = (dir_entry*)slotptr2 + 1;
> >>> +		if (slotptr2->attr != ATTR_VFAT) {
> >>> +			get_name ((dir_entry *)realdent, l_name);
> >>> +			goto out;
> >>> +		}
> >>> +
> >>>  		while ((__u8*)slotptr2 >= get_vfatname_block) {
> >>>  			slot2str(slotptr2, l_name, &idx);
> >>>  			slotptr2--;
> >>> @@ -494,6 +500,7 @@ get_vfatname(fsdata *mydata, int
> >> curclust, __u8 *cluster,
> >>>  	else if (*l_name == aRING) *l_name = '?';
> >>>  	downcase(l_name);
> >>>
> >>> +out:
> >>>  	/* Return the real directory entry */
> >>>  	memcpy(retdent, realdent, sizeof(dir_entry));
> >>>
> >>>
> >> The scripts in this thread can be used to test the fat32
> >> filesystem. I
> >> do some tests using Compact Flash
> >> device and this patchs work for me. I would like to know 
> if is a fat
> >> layer problem or usb layer problem.
> >>
> >> Michael
> >>
> >>
> >
> > 
> --------------------------------------------------------------
> -----------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time 
> to save $100.
> > Use priority code J8TL2D2.
> > 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>



From littelld at verizon.net  Fri Apr 25 04:34:10 2008
From: littelld at verizon.net (Dave Littell)
Date: Thu, 24 Apr 2008 21:34:10 -0500
Subject: [U-Boot-Users] [PATCH] PPC440EPx/sequoia TLB question...
In-Reply-To: <200804231442.29687.sr@denx.de>
References: <480EA8E1.4060207@verizon.net> <200804231442.29687.sr@denx.de>
Message-ID: <48114322.40205@verizon.net>

Stefan Roese wrote:
> On Wednesday 23 April 2008, Dave Littell wrote:
>>> From ?/board/amcc/sequoia/init.S:
>> 
>> /* TLB-entry for Internal Registers & OCM */ tlbentry( 0xe0000000, 
>> SZ_16M, 0xe0000000, 0, AC_R|AC_W|AC_X|SA_I )
>> 
>> Why is this memory region not marked Guarded?  It would seem to 
>> meet the definition of ?non-well-behaved?.
> 
> Why do you think this is the case?
> 
>> Also the TLB entry for SDRAM marks it Guarded, but that?s one area 
>> I would think wouldn't need to be Guarded.
> 
> This could be a mistake. Should work without G bis set too. Please 
> give it a try and send a patch to fix it, if it works fine.
> 

Here goes:

Patch for AMCC Sequoia to remove the TLB Guarded attribute for SDRAM,
and add the Guarded attribute for Internal Registers & OCM.

(Sorry if the wrap monster mangles this - I can't seem to convince
Thunderbird to play nice.)

diff -purN u-boot-1.3.2_base/board/amcc/sequoia/init.S
u-boot-1.3.2/board/amcc/sequoia/init.S
--- u-boot-1.3.2_base/board/amcc/sequoia/init.S 2008-03-09
10:20:02.000000000 -0500
+++ u-boot-1.3.2/board/amcc/sequoia/init.S      2008-04-24
21:24:17.542281994 -0500
@@ -45,9 +45,9 @@ tlbtab:

        /* TLB-entry for DDR SDRAM (Up to 2GB) */
 #ifdef CONFIG_4xx_DCACHE
-       tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0,
AC_R|AC_W|AC_X|SA_G)
+       tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0,
AC_R|AC_W|AC_X)
 #else
-       tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0,
AC_R|AC_W|AC_X|SA_G|SA_I )
+       tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0,
AC_R|AC_W|AC_X|SA_I )
 #endif

        /* TLB-entry for EBC */
@@ -77,7 +77,7 @@ tlbtab:
        tlbentry( CFG_NAND_ADDR, SZ_1K, CFG_NAND_ADDR, 1,
AC_R|AC_W|AC_X|SA_G|SA_I )

        /* TLB-entry for Internal Registers & OCM */
-       tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0,  AC_R|AC_W|AC_X|SA_I )
+       tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0,
AC_R|AC_W|AC_X|SA_G|SA_I )

        /*TLB-entry PCI registers*/
        tlbentry( 0xEEC00000, SZ_1K, 0xEEC00000, 1,
AC_R|AC_W|AC_X|SA_G|SA_I )




From sr at denx.de  Fri Apr 25 07:31:56 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 07:31:56 +0200
Subject: [U-Boot-Users] [PATCH] PPC440EPx/sequoia TLB question...
In-Reply-To: <48114322.40205@verizon.net>
References: <480EA8E1.4060207@verizon.net> <200804231442.29687.sr@denx.de>
	<48114322.40205@verizon.net>
Message-ID: <200804250731.56808.sr@denx.de>

On Friday 25 April 2008, Dave Littell wrote:
> Patch for AMCC Sequoia to remove the TLB Guarded attribute for SDRAM,
> and add the Guarded attribute for Internal Registers & OCM.
>
> (Sorry if the wrap monster mangles this - I can't seem to convince
> Thunderbird to play nice.)

Yes, it's wrapped. Please take a look at this page:

http://kerneltrap.org/Linux/Email_Clients_and_Patches

Hope this helps.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From galak at kernel.crashing.org  Fri Apr 25 07:55:09 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 00:55:09 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] MPC8544DS: Removes the unknown flash message
	information
Message-ID: <Pine.LNX.4.64.0804250054340.32740@blarg.am.freescale.net>

From: Roy Zang <tie-fei.zang at freescale.com>

This patch removes the unknown flash message information:
'## Unknown FLASH on Bank 1 - Size = 0xdeadbeef = -286261248 MB'
This unknown flash message is caused by PromJet.
Some of the board user is unhappy with this information.

Signed-off-by: Roy Zang <tie-fei.zang at freescale.com>
Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
 include/configs/MPC8544DS.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/configs/MPC8544DS.h b/include/configs/MPC8544DS.h
index c83d9e2..ffe9e00 100644
--- a/include/configs/MPC8544DS.h
+++ b/include/configs/MPC8544DS.h
@@ -165,6 +165,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);

 #define CFG_FLASH_BANKS_LIST	{0xfe800000,CFG_FLASH_BASE}

+#define CFG_FLASH_QUIET_TEST
 #define CFG_MAX_FLASH_BANKS	2		/* number of banks */
 #define CFG_MAX_FLASH_SECT	128		/* sectors per device */
 #undef	CFG_FLASH_CHECKSUM
-- 
1.5.4.1




From sr at denx.de  Fri Apr 25 08:01:16 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 08:01:16 +0200
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <4810B2A3.8020208@ovro.caltech.edu>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<4810AD11.3010307@ovro.caltech.edu>
	<4810B2A3.8020208@ovro.caltech.edu>
Message-ID: <200804250801.16466.sr@denx.de>

Hi David,

On Thursday 24 April 2008, David Hawkins wrote:
> > Given that you don't think any of my suggestions are
> > possible, I'll have to go download the ppc460 reference
> > manual and convince myself :)
>
> There does not appear to be a 460EX User's Manual on
> the AMCC web site. Anyone know where to get it?
> I created an account just in case it was not visible
> to guests, but no change.

It's still preliminary, so you probably need to contact your AMCC 
distributor/FAE to get access to it.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From galak at kernel.crashing.org  Fri Apr 25 08:08:32 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 01:08:32 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] MPC8544DS: decode pcie3 end-point
	configuration correctly.
Message-ID: <Pine.LNX.4.64.0804250107530.1024@blarg.am.freescale.net>

From: Ed Swarthout <Ed.Swarthout at freescale.com>

Signed-off-by: Ed Swarthout <Ed.Swarthout at freescale.com>
Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
 board/freescale/mpc8544ds/mpc8544ds.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/board/freescale/mpc8544ds/mpc8544ds.c b/board/freescale/mpc8544ds/mpc8544ds.c
index 8107016..dd10af8 100644
--- a/board/freescale/mpc8544ds/mpc8544ds.c
+++ b/board/freescale/mpc8544ds/mpc8544ds.c
@@ -163,7 +163,7 @@ pci_init_board(void)
 	volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *) CFG_PCIE3_ADDR;
 	extern void fsl_pci_init(struct pci_controller *hose);
 	struct pci_controller *hose = &pcie3_hose;
-	int pcie_ep = (host_agent == 3);
+	int pcie_ep = (host_agent == 1);
 	int pcie_configured  = io_sel >= 1;

 	if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE)){
-- 
1.5.4.1




From sr at denx.de  Fri Apr 25 08:13:56 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 08:13:56 +0200
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <20080424161043.GC7245@crust.elkhashab.com>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<4810AD11.3010307@ovro.caltech.edu>
	<20080424161043.GC7245@crust.elkhashab.com>
Message-ID: <200804250813.56303.sr@denx.de>

On Thursday 24 April 2008, Ayman M. El-Khashab wrote:
> So maybe I need to clarify some more.  The PPC460 data sheet
> is not too clear on this yet.  However, here are my thoughts
> on this.  Lets just take the simple case as an example.  We
> have a plurality of 460s where a single one is the master.
> Between the master and all the slaves is a PCI bridge.  The
> slaves are hardwired to boot from pci bus memory -- according
> to the datasheet that is at a fixed address.  So there does
> not appear to be any need to do anything to the slave upon
> power up.  Now the master boots and then allocates a chunk
> of contiguous memory using a kernel driver or whatever is
> needed.  The image is just whatever the flash image would
> normally contain (uboot + kernel + rootfs).  The address of
> that chunk is then given to the pci bridge so that it can
> perform inbound translation from the address that the PPC
> slaves will use to the address where the image is physically
> located.  Then the slaves are taken out of reset and begin
> reading "flash" across the pci bus which really goes through
> the bridge and is mapped to the DRAM on the master (or I
> guess it could be the flash on the master, but DRAM seemed
> easier since it is already running).
>
> Ok, so how many holes does this approach have?

Sounds quite reasonable. The only thing I'm unsure here is the size of the PCI 
windows that is mapped upon PCI booting. The 460EX users manual doesn't 
mention anything about this, but from the 440EPx users manual this windows 
has the following size:

0xfffe.0000 - 0xffff.ffff -> 128kB

Not sure if this is the same on 460EX/GT. You should probably contact AMCC and 
ask about this.

If 128kB is correct, then this is a little short for a full-blown U-Boot 
image.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 25 08:35:28 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 08:35:28 +0200
Subject: [U-Boot-Users] [PATCH] M18 flash (Sibley) support (attempt 2)
In-Reply-To: <E1JobUb-000OPI-00.vasiliy-leonenko-mail-ru@f69.mail.ru>
References: <200804210902.38080.sr@denx.de>
	<E1JobUb-000OPI-00.vasiliy-leonenko-mail-ru@f69.mail.ru>
Message-ID: <200804250835.29033.sr@denx.de>

Hi Vasily,

On Wednesday 23 April 2008, Vasiliy Leoenenko wrote:
> > Sorry, but I really forgot about this patch. Could you please resend this
> > patch against the current tot, since it doesn't apply cleanly anymore?
>
> I prepared patch for u-boot version 1.3.2. Any comments and suggestions are
> welcome. Code(included below) was verified on Mainstone II board with M18
> flash chip. Please don't forget to include it :)

Unfortunately this breaks CFI support for "normal" AMD/Spansion FLASH equipped 
boards. On Sequoia with Spansion GL512 I get this after applying your patch:

U-Boot 1.3.2-01356-g8fa1348 (Apr 24 2008 - 17:05:55)

CPU:   AMCC PowerPC 440EPx Rev. A at 528 MHz (PLB=132, OPB=66, EBC=66 MHz)
       Security/Kasumi support
       Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
       Internal PCI arbiter enabled, PCI async ext clock used
       32 kB I-Cache 32 kB D-Cache
Board: Sequoia - AMCC PPC440EPx Evaluation Board, Rev. F, PCI=66 MHz
I2C:   ready
DTT:   1 is 29 C
DRAM:  256 MB
FLASH: CFI: Unknown command set 0x0
*** failed ***
### ERROR ### Please RESET the board ###

:-(

Please fix this and resubmit. Best would be if you could test it on a board 
with Spansion CFI FLASH's too.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Fri Apr 25 09:16:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:00 +0200
Subject: [U-Boot-Users] [PATCH] 85xx: Fix size of cpu-release-addr
	property
In-Reply-To: Your message of "Fri, 18 Apr 2008 11:29:01 CDT."
	<Pine.LNX.4.64.0804181128440.6860@blarg.am.freescale.net>
Message-ID: <20080425071600.9894A24AB1@gemini.denx.de>

In message <Pine.LNX.4.64.0804181128440.6860 at blarg.am.freescale.net> you wrote:
> The cpu-release-addr is defined as always being a 64-bit quanity regardless
> if we are running on a 32-bit or 64-bit machine.
> ---
>  cpu/mpc85xx/fdt.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Signed-off-by line  missing...

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: wd at denx.de
"If people are good only because they fear punishment, and  hope  for
reward, then we are a sorry lot indeed."            - Albert Einstein



From wd at denx.de  Fri Apr 25 09:16:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:00 +0200
Subject: [U-Boot-Users] [PATCH] i.MX31: Use symbolic names for Litekit
	membases.
In-Reply-To: Your message of "Sun, 20 Apr 2008 10:36:36 +0200."
	<480B0094.9040008@gmail.com>
Message-ID: <20080425071600.B854C24AB1@gemini.denx.de>

In message <480B0094.9040008 at gmail.com> you wrote:
> Use symbolic names instead of hard coded addresses for Litekit membases.
> 
> Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>

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: wd at denx.de
8) Use common sense in routing  cable.  Avoid  wrapping  coax  around
   sources  of  strong  electric  or magnetic fields. Do not wrap the
   cable  around  flourescent  light  ballasts  or  cyclotrons,   for
   example.
- Ethernet Headstart Product, Information and Installation Guide,
   Bell Technologies, pg. 11



From wd at denx.de  Fri Apr 25 09:16:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:00 +0200
Subject: [U-Boot-Users] [PATCH] i.MX31: Enable SPI and MC13783/RTC
	support for the Litekit board
In-Reply-To: Your message of "Sun, 20 Apr 2008 10:38:12 +0200."
	<480B00F4.6030406@gmail.com>
Message-ID: <20080425071600.C807A24AB6@gemini.denx.de>

In message <480B00F4.6030406 at gmail.com> you wrote:
> This patch enables SPI and MC13783/RTC support for the Litekit board.
> 
> Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
> ---
> 
>  board/imx31_litekit/imx31_litekit.c |   12 ++++++++++++
>  include/configs/imx31_litekit.h     |    8 ++++++++
>  2 files changed, 20 insertions(+), 0 deletions(-)

Does not apply:

Applying i.MX31: Enable SPI and MC13783/RTC support for the Litekit board
error: patch failed: board/imx31_litekit/imx31_litekit.c:52
error: board/imx31_litekit/imx31_litekit.c: patch does not apply
fatal: sha1 information is lacking or useless
(board/imx31_litekit/imx31_litekit.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.


Please rebase and resubmit.

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: wd at denx.de
The face of war has never changed.  Surely it is more logical to heal
than to kill.
	-- Surak of Vulcan, "The Savage Curtain", stardate 5906.5



From wd at denx.de  Fri Apr 25 09:16:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:00 +0200
Subject: [U-Boot-Users] [PATCH] i.MX31: Fix architecture numbers for ADS
	and Litekit boards
In-Reply-To: Your message of "Sun, 20 Apr 2008 10:35:03 +0200."
	<480B0037.2040305@gmail.com>
Message-ID: <20080425071600.D768124AB1@gemini.denx.de>

In message <480B0037.2040305 at gmail.com> you wrote:
> Correct the Linux architecture number for i.MX31 Litekit and ADS boards.
> 
> Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
> ---
> 
>  board/imx31_litekit/imx31_litekit.c |    2 +-
>  board/mx31ads/mx31ads.c             |    2 +-
>  2 files changed, 2 insertions(+), 2 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: wd at denx.de
Every living thing wants to survive.
	-- Spock, "The Ultimate Computer", stardate 4731.3



From wd at denx.de  Fri Apr 25 09:16:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:00 +0200
Subject: [U-Boot-Users] [PATCH] Fix show_boot_progress prototype
In-Reply-To: Your message of "Sat, 19 Apr 2008 17:59:20 +0200."
	<1208620760-23645-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080425071600.A8B2A24AB6@gemini.denx.de>

In message <1208620760-23645-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> in commit fad634071 "make show_boot_progress () weak."
> show_boot_progress is supposed to be declared as weak but declare as inline
> instead of.
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/include/common.h b/include/common.h
> index 8630780..eeb6686 100644

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: wd at denx.de
"What if" is a trademark of Hewlett Packard, so stop using it in your
sentences without permission, or risk being sued.



From wd at denx.de  Fri Apr 25 09:16:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:00 +0200
Subject: [U-Boot-Users] [PATCH] Added Am79C970A chip id to pcnet
In-Reply-To: Your message of "Wed, 10 Oct 2007 23:04:23 +0300."
	<470D3047.6020709@comsys.ro>
Message-ID: <20080425071600.E6E6824AB6@gemini.denx.de>

In message <470D3047.6020709 at comsys.ro> you wrote:
> Signed-off-by: Vlad Lungu <vlad at comsys.ro>
> ---
>  drivers/pcnet.c |    3 +++
>  1 files changed, 3 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: wd at denx.de
Quote from the Boss after overriding the decision of a task force  he
created  to  find  a  solution:  "I'm  sorry  if  I ever gave you the
impression your input would have any effect on my  decision  for  the
outcome of this project!"



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH] Added Am79C970A chip id to pcnet (fwd)
In-Reply-To: Your message of "Sun, 20 Apr 2008 09:49:56 EDT."
	<f8328f7c0804200649y2ffa9fd8gfdd7e003297bd8f@mail.gmail.com>
Message-ID: <20080425071601.0272724AB1@gemini.denx.de>

In message <f8328f7c0804200649y2ffa9fd8gfdd7e003297bd8f at mail.gmail.com> you wrote:
> 
> >  this patch is still on my "open" list. Can you please review and
> >  apply if it makes sense to you? Thanks.
> 
> I don't have access to my build machine right now, and this looks
> harmless.  Please pull directly.

Done, 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: wd at denx.de
Suffocating together ... would create heroic camaraderie.
	-- Khan Noonian Singh, "Space Seed", stardate 3142.8



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH] Fixed pcnet io_base
In-Reply-To: Your message of "Sun, 20 Apr 2008 10:02:08 EDT."
	<f8328f7c0804200702x40841be6k286dd6e335440692@mail.gmail.com>
Message-ID: <20080425071601.228EF24AB1@gemini.denx.de>

In message <f8328f7c0804200702x40841be6k286dd6e335440692 at mail.gmail.com> you wrote:
> 
> >  this patch is still on my "open" list. Can you please review and
> >  apply if it makes sense to you? Thanks.
> 
> This looks OK to me.  Assuming that pci_io_to_phys() is defined on all
> relevant architectures, I have no objections.  Unfortunately I can't
> run MAKEALL right now, so if it's not too much of a bother please pull
> directly.  We can always pull it out if there's a problem, I guess.

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: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law       - _Profiles of the Future_ (1962; rev. 1973)
                  ``Hazards of Prophecy: The Failure of Imagination''



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH] Fixed pcnet io_base
In-Reply-To: Your message of "Wed, 10 Oct 2007 23:02:09 +0300."
	<470D2FC1.3070906@comsys.ro>
Message-ID: <20080425071601.1326524AB6@gemini.denx.de>

In message <470D2FC1.3070906 at comsys.ro> you wrote:
> Bus and phys address are not always the same
> 
> Signed-off-by: Vlad Lungu <vlad at comsys.ro>
> ---
>  drivers/pcnet.c |    1 +
>  1 files changed, 1 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: wd at denx.de
"Data is a lot like humans: It is  born.  Matures.  Gets  married  to
other  data, divorced. Gets old. One thing that it doesn't do is die.
It has to be killed."                                 - Arthur Miller



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH 1/2][MIPS] qemu-mips: Cleanup whiespaces,
	tab indentations, etc.
In-Reply-To: Your message of "Wed, 23 Apr 2008 11:02:12 +0900."
	<480E98A4.1090405@necel.com>
Message-ID: <20080425071601.32C5B24AB6@gemini.denx.de>

In message <480E98A4.1090405 at necel.com> you wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> > Please add the sof of the first author of the patch from who you
> > deriverd.
> 
> Sorry for that. Patch revised.
> 
> ================================>
> 
> [MIPS] qemu-mips.h: Cleanup whiespaces, tab indentations, etc.
> 
> No functional change.
> 
> This patch was originally submitted by Jean-Christophe PLAGNIOL-VILLARD.
> Then I re-created from scratch, and changed more lines than the original.
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
> ---
> 
>  include/configs/qemu-mips.h |   65 +++++++++++++++++++++----------------------
>  1 files changed, 32 insertions(+), 33 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: wd at denx.de
If a train station is a place where a train stops,
                                           then what's a workstation?



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH v2 1/2] Add support for calulacting
	hashes with watchdog triggering
In-Reply-To: Your message of "Tue, 22 Apr 2008 12:27:56 +0200."
	<20080422102756.30118.38437.stgit@pollux.denx.de>
Message-ID: <20080425071601.42A8024AB1@gemini.denx.de>

In message <20080422102756.30118.38437.stgit at pollux.denx.de> you wrote:
> Implement watchodg-aware variants of hash calculation functions:
> - crc32_wd()
> - md5_wd()
> - sha1_csum_wd()
> The above functions calculate the hash of the input buffer in chunks,
> triggering the watchdog after processing each chunk. The chunk size is given
> as a function call parameter.
> 
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> 
>  include/common.h     |    1 +
>  include/sha1.h       |   11 +++++++++++
>  include/u-boot/md5.h |    8 ++++++++
>  lib_generic/crc32.c  |   27 +++++++++++++++++++++++++++
>  lib_generic/md5.c    |   36 ++++++++++++++++++++++++++++++++++++
>  lib_generic/sha1.c   |   33 +++++++++++++++++++++++++++++++++
>  6 files changed, 116 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: wd at denx.de
All easy problems have already been solved.



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH v2 2/2] Use watchdog-aware functions when
	calculating hashes of images
In-Reply-To: Your message of "Tue, 22 Apr 2008 12:28:02 +0200."
	<20080422102802.30118.26894.stgit@pollux.denx.de>
Message-ID: <20080425071601.525E524AB6@gemini.denx.de>

In message <20080422102802.30118.26894.stgit at pollux.denx.de> you wrote:
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> 
>  common/image.c      |   43 +++++++++----------------------------------
>  include/image.h     |   17 +++++++++++++++--
>  lib_generic/crc32.c |    1 +
>  lib_generic/md5.c   |    4 ++++
>  lib_generic/sha1.c  |    4 ++++
>  5 files changed, 33 insertions(+), 36 deletions(-)

Sorry, but this patch does not apply any more:

Applying Use watchdog-aware functions when calculating hashes of images
error: patch failed: common/image.c:156
error: common/image.c: patch does not apply
error: patch failed: lib_generic/crc32.c:12
error: lib_generic/crc32.c: patch does not apply
fatal: sha1 information is lacking or useless (common/image.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.

Please rebase and resubmit.

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: wd at denx.de
Perl itself is  usually  pretty  good  about  telling  you  what  you
shouldn't do. :-)     - Larry Wall in <11091 at jpl-devvax.JPL.NASA.GOV>



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [MIPS] doc/README.mips: Add MIPS notes
In-Reply-To: Your message of "Tue, 22 Apr 2008 22:47:27 +0900."
	<480DEC6F.9040508@ruby.dti.ne.jp>
Message-ID: <20080425071601.61C6624AB1@gemini.denx.de>

In message <480DEC6F.9040508 at ruby.dti.ne.jp> you wrote:
> This is for 1.3.3 release. Please review.
> 
> Thanks,
> 
>   Shinya
> 
> ================================>
> Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
> ---
> 
>  doc/README.mips |   58 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 58 insertions(+), 0 deletions(-)
>  create mode 100644 doc/README.mips

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: wd at denx.de
"Wagner's music is better than it sounds."               - Mark Twain



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH u-boot-at91] Add support for
	AT91SAM9263EK (again)
In-Reply-To: Your message of "Tue, 22 Apr 2008 15:48:33 +1000."
	<480D7C31.8070501@genesysdesign.com.au>
Message-ID: <20080425071601.A0D3D24AB1@gemini.denx.de>

In message <480D7C31.8070501 at genesysdesign.com.au> you wrote:
> Apologies for the previous patch, forgot to add the new files to it. No
> wonder it seemed so short.
> Here it is again

Signed-off-by line missing.

MAINTAINERS entry missing.

Patch corrupted because your mailer line-wrapped it.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is surely a great calamity for  a  human  being  to  have  no  ob-
sessions.                                                - Robert Bly



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH 0/1 V2] NE2000: coding style cleanup
In-Reply-To: Your message of "Thu, 24 Apr 2008 07:57:16 +0200."
	<1209016637-10264-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080425071601.80C2B24AB1@gemini.denx.de>

In message <1209016637-10264-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> ---
> Fix coding style in drivers/net/ax88796.h too
> 
>  drivers/net/ax88796.h     |   46 ++--
>  drivers/net/ne2000.c      |  276 ++++++++++++----------
>  drivers/net/ne2000.h      |   30 ++--
>  drivers/net/ne2000_base.h |  567 +++++++++++++++++++++++----------------------
>  4 files changed, 474 insertions(+), 445 deletions(-)
>  rewrite drivers/net/ne2000_base.h (65%)

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: wd at denx.de
It seems intuitively obvious to me, which  means  that  it  might  be
wrong.                                                 -- Chris Torek



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH 2/2][MIPS] qemu-mips.h: Add CFI support
In-Reply-To: Your message of "Wed, 23 Apr 2008 00:11:47 +0900."
	<480E0033.9030307@ruby.dti.ne.jp>
Message-ID: <20080425071601.716BB24AB6@gemini.denx.de>

In message <480E0033.9030307 at ruby.dti.ne.jp> you wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> CONFIG_ENV_OVERWRITE is also added.
> 
> This patch is originally created by Jean-Christophe PLAGNIOL-VILLARD.
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> Signed-off-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>
> ---
> 
>  include/configs/qemu-mips.h |   15 ++++++++++-----
>  1 files changed, 10 insertions(+), 5 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: wd at denx.de
I will also, for an appropriate fee, certify that  your  keyboard  is
object-oriented,  and  that  the bits on your hard disk are template-
compatible.            - Jeffrey S. Haemer in <411akr$3ga at cygnus.com>



From wd at denx.de  Fri Apr 25 09:16:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 09:16:01 +0200
Subject: [U-Boot-Users] [PATCH] lib_ppc: Revert "Make MPC83xx one step
	closer to full relocation."
In-Reply-To: Your message of "Mon, 21 Apr 2008 18:10:14 CDT."
	<20080421181014.7f664c62.kim.phillips@freescale.com>
Message-ID: <20080425071601.90BD524AB6@gemini.denx.de>

In message <20080421181014.7f664c62.kim.phillips at freescale.com> you wrote:
> This reverts commit 70431e8a7393b6b793f77957f95b999fc9a269b8 which has
> proven problematic getting right from the start at least on 83xx and
> 4xx.
> 
> Signed-off-by: Kim Phillips <kim.phillips at freescale.com>
> ---
>  cpu/mpc83xx/start.S |   11 ++++-------
>  lib_ppc/board.c     |    1 -
>  2 files changed, 4 insertions(+), 8 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: wd at denx.de
Bus error -- driver executed.



From wd at denx.de  Fri Apr 25 10:14:41 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 10:14:41 +0200
Subject: [U-Boot-Users] Pull request at91
In-Reply-To: Your message of "Tue, 22 Apr 2008 23:18:08 +0200."
	<20080422211808.GA10750@game.jcrosoft.org>
Message-ID: <20080425081441.2488B24AB5@gemini.denx.de>

In message <20080422211808.GA10750 at game.jcrosoft.org> you wrote:
> 
> The following changes since commit 58c5376ba67767ee684069d43e7f747a5d9ae8ed:
>   Wolfgang Denk (1):
>         Merge branch 'master' of git://www.denx.de/git/u-boot-ppc4xx
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-at91.git master
> 
> Dirk Behme (1):
>       ARM: Davinci: Fix DM644x timer overflow handling and cleanup
> 
>  cpu/arm926ejs/davinci/timer.c |   70 +++++++++++++---------------------------

Merged, 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: wd at denx.de
I am a computer. I am dumber than any human and smarter than any  ad-
ministrator.



From wd at denx.de  Fri Apr 25 10:39:08 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 10:39:08 +0200
Subject: [U-Boot-Users] [PATCH] MPC8544DS: Removes the unknown flash
	message information
In-Reply-To: Your message of "Fri, 25 Apr 2008 00:55:09 CDT."
	<Pine.LNX.4.64.0804250054340.32740@blarg.am.freescale.net>
Message-ID: <20080425083908.0FC1824AB5@gemini.denx.de>

In message <Pine.LNX.4.64.0804250054340.32740 at blarg.am.freescale.net> you wrote:
> From: Roy Zang <tie-fei.zang at freescale.com>
> 
> This patch removes the unknown flash message information:
> '## Unknown FLASH on Bank 1 - Size = 0xdeadbeef = -286261248 MB'
> This unknown flash message is caused by PromJet.
> Some of the board user is unhappy with this information.
> 
> Signed-off-by: Roy Zang <tie-fei.zang at freescale.com>
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>

Is it correct to assume that a 85xx pull request will follow soon?

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: wd at denx.de
I wish I had a bronze torc for every user who didn't read the manual.
                             - Terry Pratchett, _The Light Fantastic_



From nikam_research at ms.messung.com  Fri Apr 25 11:13:47 2008
From: nikam_research at ms.messung.com (nikam_research at ms.messung.com)
Date: Fri, 25 Apr 2008 14:43:47 +0530
Subject: [U-Boot-Users] u-boot on mpc852
Message-ID: <OF03CC1600.23DE933E-ON65257436.0032B387-65257436.0032B38E@messung.com>


Dear All,

Can I use u-boot boot loader on mpc852 (powerPC)?

I mean is already some patch is available ? ? ?

Please acknowledge, thank you ...

Kind Regards,
Vijay




Email Disclaimer:
---------------------------

This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Computer viruses can be transmitted via email.The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.




Using Symantec Hosted Mail Outbound Server



From kashiwagi at co-nss.co.jp  Fri Apr 25 11:32:34 2008
From: kashiwagi at co-nss.co.jp (Yoshio Kashiwagi)
Date: Fri, 25 Apr 2008 18:32:34 +0900
Subject: [U-Boot-Users] Xilinx PowerPC XPS_LL_TEMAC driver
Message-ID: <JF2008042518323445.35379812@co-nss.co.jp>

Hi All,

I am writing XPS_LL_TEMAC for Xilinx PowerPC.
Can anyone give me an advice on which I should correct this source?

Thanks in advance,

Yoshio Kashiwagi - Nissin Systems

/*
 *
 * xilinx_ll_temac.c ethernet driver for u-boot
 *
 * Author: Yoshio Kashiwagi kashiwagi at co-nss.co.jp
 *
 * Copyright (c) 2008 Nissin Systems Co.,Ltd.
 *
 * March 2008 created
 *
 * 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.
 *
*/
#include <config.h>
#include <common.h>
#include <net.h>
#include <malloc.h>
#include <asm/errno.h>
#include <asm/processor.h>

#define S_DMA_CTRL_BASEADDR XPAR_LLTEMAC_0_LLINK_CONNECTED_BASEADDR
#define XPS_LLTEMAC_BASEADDR    XPAR_LLTEMAC_0_BASEADDR

/* XPS_LL_TEMAC SDMA registers definition */

#define TX_NXTDESC_PTR      (S_DMA_CTRL_BASEADDR + 0x00)
#define TX_CURBUF_ADDR      (S_DMA_CTRL_BASEADDR + 0x04)
#define TX_CURBUF_LENGTH    (S_DMA_CTRL_BASEADDR + 0x08)
#define TX_CURDESC_PTR      (S_DMA_CTRL_BASEADDR + 0x0c)
#define TX_TAILDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x10)
#define TX_CHNL_CTRL        (S_DMA_CTRL_BASEADDR + 0x14)
#define TX_IRQ_REG      (S_DMA_CTRL_BASEADDR + 0x18)
#define TX_CHNL_STS     (S_DMA_CTRL_BASEADDR + 0x1c)

#define RX_NXTDESC_PTR      (S_DMA_CTRL_BASEADDR + 0x20)
#define RX_CURBUF_ADDR      (S_DMA_CTRL_BASEADDR + 0x24)
#define RX_CURBUF_LENGTH    (S_DMA_CTRL_BASEADDR + 0x28)
#define RX_CURDESC_PTR      (S_DMA_CTRL_BASEADDR + 0x2c)
#define RX_TAILDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x30)
#define RX_CHNL_CTRL        (S_DMA_CTRL_BASEADDR + 0x34)
#define RX_IRQ_REG      (S_DMA_CTRL_BASEADDR + 0x38)
#define RX_CHNL_STS     (S_DMA_CTRL_BASEADDR + 0x3c)

#define DMA_CONTROL_REG     (S_DMA_CTRL_BASEADDR + 0x40)

/* XPS_LL_TEMAC direct registers definition */

#define TEMAC_RAF0      (XPS_LLTEMAC_BASEADDR + 0x00)
#define TEMAC_TPF0      (XPS_LLTEMAC_BASEADDR + 0x04)
#define TEMAC_IFGP0     (XPS_LLTEMAC_BASEADDR + 0x08)
#define TEMAC_IS0       (XPS_LLTEMAC_BASEADDR + 0x0c)
#define TEMAC_IP0       (XPS_LLTEMAC_BASEADDR + 0x10)
#define TEMAC_IE0       (XPS_LLTEMAC_BASEADDR + 0x14)

#define TEMAC_MSW0      (XPS_LLTEMAC_BASEADDR + 0x20)
#define TEMAC_LSW0      (XPS_LLTEMAC_BASEADDR + 0x24)
#define TEMAC_CTL0      (XPS_LLTEMAC_BASEADDR + 0x28)
#define TEMAC_RDY0      (XPS_LLTEMAC_BASEADDR + 0x2c)

#define XTE_RSE_MIIM_RR_MASK      0x0002
#define XTE_RSE_MIIM_WR_MASK      0x0004
#define XTE_RSE_CFG_RR_MASK       0x0020
#define XTE_RSE_CFG_WR_MASK       0x0040

/* XPS_LL_TEMAC indirect registers offset definition */

#define RCW0    0x200
#define RCW1    0x240
#define TC  0x280
#define FCC 0x2c0
#define EMMC    0x300
#define PHYC    0x320
#define MC  0x340
#define UAW0    0x380
#define UAW1    0x384
#define MAW0    0x388
#define MAW1    0x38c
#define AFM 0x390
#define TIS 0x3a0
#define TIE 0x3a4
#define MIIMWD  0x3b0
#define MIIMAI  0x3b4

#define CNTLREG_WRITE_ENABLE_MASK   0x8000
#define CNTLREG_EMAC1SEL_MASK       0x0400
#define CNTLREG_ADDRESSCODE_MASK    0x03ff

#define MDIO_ENABLE_MASK    0x40
#define MDIO_CLOCK_DIV_MASK 0x3F
#define MDIO_CLOCK_DIV_100MHz   0x28

#define ETHER_MTU       1520
#define CACHE_LINE_SIZE     32

/* SDMA descriptor status bit definitions */

#define BDSTAT_ERROR_MASK       0x80
#define BDSTAT_INT_ON_END_MASK  0x40
#define BDSTAT_STOP_ON_END_MASK 0x20
#define BDSTAT_COMPLETED_MASK   0x10
#define BDSTAT_SOP_MASK         0x08
#define BDSTAT_EOP_MASK         0x04
#define BDSTAT_CHANBUSY_MASK    0x02
#define BDSTAT_CHANRESET_MASK   0x01

/* SDMA Buffer Descriptor */

typedef struct cdmac_bd_t {
    struct cdmac_bd_t *next_p;
    unsigned char *phys_buf_p;
    unsigned long buf_len;
    unsigned char stat;
    unsigned char app1_1;
    unsigned short app1_2;
    unsigned long app2;
    unsigned long app3;
    unsigned long app4;
    unsigned long app5;
} cdmac_bd __attribute((aligned(32))) ;

static cdmac_bd tx_bd;
static cdmac_bd rx_bd;
static unsigned char tx_buffer[ETHER_MTU] __attribute((aligned(32)));
static unsigned char rx_buffer[ETHER_MTU] __attribute((aligned(32)));

struct xps_ll_temac_private {
    int idx;
    unsigned char dev_addr[6];
};

static void flush_dcache_range(unsigned int addr, unsigned size)
{
    unsigned int end = addr & ~(CACHE_LINE_SIZE - 1);

    if(size) {
        while(addr < end) {
            __asm__ __volatile__("dcbf 0,%0; sync;" : : "r" (addr));
            addr += CACHE_LINE_SIZE;
        }
    }
}

static void invalidate_dcache_range(unsigned int addr, unsigned size)
{
    unsigned int end = addr & ~(CACHE_LINE_SIZE - 1);

    if(size) {
        while(addr < end) {
            __asm__ __volatile__("dcbi 0,%0; sync;" : : "r" (addr));
            addr += CACHE_LINE_SIZE;
        }
    }
}

static unsigned int xps_ll_temac_hostif_get(int emac, int phy_addr, int 
reg_addr)
{
    *(unsigned int *)TEMAC_LSW0 = phy_addr << 5 | reg_addr;
    *(unsigned int *)TEMAC_CTL0 = MIIMAI | emac << 10;

    while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_MIIM_RR_MASK)
);
    return *(unsigned int *)TEMAC_LSW0;
}

static void xps_ll_temac_indirect_set(int emac, int reg_offset, int reg_
data)
{
    *(unsigned int *)TEMAC_LSW0 = reg_data;
    *(unsigned int *)TEMAC_CTL0 = CNTLREG_WRITE_ENABLE_MASK | emac << 10 
| reg_offset;
    while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_CFG_WR_MASK))
;
}

static int xps_ll_temac_phy_ctrl(void)
{
    static int phy_addr = -1;
    static int link = 0;
    int i;
    unsigned int result;

    if(phy_addr == -1) {
        for(i = 0;i < 32;i++) {
            result = xps_ll_temac_hostif_get(0, i, 1);
            if((result & 0x0ffff) != 0x0ffff) {
                phy_addr = i;
                break;
            }
        }
    } else {
        result = xps_ll_temac_hostif_get(0, phy_addr, 1);
    }
    if((result & 0x24) != 0x24) {
        if(link) {
            link = 0;
            printf("Link down\n");
        }
        return 0;
    }
    if(link == 0) {
        link = 1;
    } else {
        return 1;
    }

    result = xps_ll_temac_hostif_get(0, phy_addr, 10);
    if((result & 0x0800) == 0x0800) {
        xps_ll_temac_indirect_set(0, EMMC, 0x80000000);
        printf("1000BASE-T/FD\n");
        return 1;
    }
    result = xps_ll_temac_hostif_get(0, phy_addr, 5);
    if((result & 0x0100) == 0x0100) {
        xps_ll_temac_indirect_set(0, EMMC, 0x40000000);
        printf("100BASE-T/FD\n");
    } else if((result & 0x0040) == 0x0040) {
        xps_ll_temac_indirect_set(0, EMMC, 0x00000000);
        printf("10BASE-T/FD\n");
    } else {
        printf("Half Duplex not supported\n");
    }
    return 1;
}

static void xps_ll_temac_bd_init(void)
{
    memset((void *)&tx_bd, 0, sizeof(cdmac_bd));
    memset((void *)&rx_bd, 0, sizeof(cdmac_bd));
    
    rx_bd.phys_buf_p = &rx_buffer[0];
    rx_bd.next_p = &rx_bd;
    rx_bd.buf_len = ETHER_MTU;
    flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
    *(unsigned int *)RX_CURDESC_PTR = (unsigned int)&rx_bd;
    *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;

    tx_bd.phys_buf_p = &tx_buffer[0];
    tx_bd.next_p = &tx_bd;
    flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
    *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
}

static int xps_ll_temac_send(unsigned char *buffer, int length)
{
    if(xps_ll_temac_phy_ctrl() == 0) return 0;

    memcpy(tx_buffer, buffer, length);
    flush_dcache_range((unsigned int)tx_buffer, length);

    tx_bd.stat = BDSTAT_SOP_MASK | BDSTAT_EOP_MASK | BDSTAT_STOP_ON_END_
MASK;
    tx_bd.buf_len = length;
    flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));

    *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
    *(unsigned int *)TX_TAILDESC_PTR = (unsigned int)&tx_bd; /* DMA 
start */

    do {
        invalidate_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
    } while(!((volatile int)tx_bd.stat & BDSTAT_COMPLETED_MASK));

    return length;
}

static int xps_ll_temac_recv(void)
{
    int length;

    invalidate_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
    if(!(rx_bd.stat & BDSTAT_COMPLETED_MASK)) return 0;

    length = rx_bd.app5;
    invalidate_dcache_range((unsigned int)rx_bd.phys_buf_p, length);

    rx_bd.buf_len = ETHER_MTU;
    rx_bd.stat = 0;
    rx_bd.app5 = 0;
    flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
    *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;

    if(length > 0) {
        NetReceive(rx_bd.phys_buf_p, length);
    }

    return length;
}

static int xps_ll_temac_addr_setup(struct xps_ll_temac_private * lp)
{
        char * env_p;
        char * end;
        int    i, val;

        env_p = getenv("ethaddr");
        if (env_p == NULL) {
                printf("cannot get enviroment for \"ethaddr\".\n");
                return -1;
        }

        for (i = 0; i < 6; i++) {
                lp->dev_addr[i] = env_p ? simple_strtoul(env_p, &end, 16)
 : 0;
                if (env_p) env_p = (*end) ? end + 1 : end;
        }

        /* set up unicast MAC address filter */
        val = lp->dev_addr[3] << 24 | lp->dev_addr[2] << 16 |
               lp->dev_addr[1] <<  8 | lp->dev_addr[0];
    xps_ll_temac_indirect_set(0, UAW0, val);
        val = lp->dev_addr[5] << 8 |  lp->dev_addr[4];
    xps_ll_temac_indirect_set(0, UAW1, val);

        return 0;
}

static void xps_ll_temac_init(struct eth_device *dev, bd_t *bis)
{
    struct xps_ll_temac_private *lp = (struct xps_ll_temac_private *)
dev->priv;

    xps_ll_temac_bd_init();
    xps_ll_temac_indirect_set(0, MC, MDIO_ENABLE_MASK | MDIO_CLOCK_DIV_
100MHz);
    
    xps_ll_temac_addr_setup(lp);
    xps_ll_temac_indirect_set(0, AFM, 0x00000000);  /* Promiscuos mode 
disable */
    xps_ll_temac_indirect_set(0, RCW1, 0x10000000); /* Enable Receiver *
/
    xps_ll_temac_indirect_set(0, TC, 0x10000000);   /* Enable 
Transmitter */

}

int eth_init(bd_t *bis)
{
    static int first = 1;
    struct eth_device *dev;
    struct xps_ll_temac_private *lp;
    int i;

    if(!first) return 0;
    first = 0;
        dev = (struct eth_device *) calloc(1, sizeof(struct eth_device))
;
        if (NULL == dev) return 0;

        lp = (struct xps_ll_temac_private *) calloc(1, sizeof(struct 
xps_ll_temac_private));
        if (lp == NULL) return 0;
    dev->priv = lp;
    sprintf(dev->name, "eth0");

    xps_ll_temac_init(dev, bis);

    printf("%s: Xilinx XPS LocalLink Tri-Mode Ether MAC #%d at 0x%08X.\
n",
        dev->name, 0, XPS_LLTEMAC_BASEADDR);

    for(i = 0;i < 3;i++) {      
        if(xps_ll_temac_phy_ctrl()) break;
        udelay(10000);      /* wait second */
    }
    return 1;
}

int eth_send(volatile void *packet, int length)
{
    return xps_ll_temac_send((unsigned char *)packet, length);
}

int eth_rx(void)
{
    return xps_ll_temac_recv();
}

void eth_halt(void)
{
}




From trimarchi at gandalf.sssup.it  Fri Apr 25 11:49:54 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Fri, 25 Apr 2008 11:49:54 +0200
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <AA28F077645B324881335614E4F7C428034CE5@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CE5@win-ex01.bench.com>
Message-ID: <4811A942.7010405@gandalf.sssup.it>

Hi,

confirm that the problem is in fat.c file and I will try to fix.


Michael




From matthias.fuchs at esd-electronics.com  Fri Apr 25 12:01:39 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Fri, 25 Apr 2008 12:01:39 +0200
Subject: [U-Boot-Users] [PATCH V2] ppc4xx: Add bootcount limit handling for
	APC405 boards
In-Reply-To: <200804241658.59648.sr@denx.de>
References: <200804241133.04972.matthias.fuchs@esd-electronics.com>
	<200804241658.59648.sr@denx.de>
Message-ID: <200804251201.39658.matthias.fuchs@esd-electronics.com>

Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>
---
 board/esd/apc405/apc405.c |    7 ++++++-
 include/configs/APC405.h  |   14 ++++++++++++--
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/board/esd/apc405/apc405.c b/board/esd/apc405/apc405.c
index b663184..2cb743e 100644
--- a/board/esd/apc405/apc405.c
+++ b/board/esd/apc405/apc405.c
@@ -385,11 +385,16 @@ int misc_init_r(void)
 	}
 	out_be16((u16 *)(FUJI_BASE + LCDBL_PWM), 0xff);
 
-	if (getenv("usb_self") == NULL) {
+	/*
+	 * fix environment for field updated units
+	 */
+	if (getenv("altbootcmd") == NULL) {
 		setenv("usb_load", CFG_USB_LOAD_COMMAND);
 		setenv("usbargs", CFG_USB_ARGS);
 		setenv("bootcmd", CONFIG_BOOTCOMMAND);
 		setenv("usb_self", CFG_USB_SELF_COMMAND);
+		setenv("bootlimit", CFG_BOOTLIMIT);
+		setenv("altbootcmd", CFG_ALT_BOOTCOMMAND);
 		saveenv();
 	}
 
diff --git a/include/configs/APC405.h b/include/configs/APC405.h
index e2ab39d..8ad33f1 100644
--- a/include/configs/APC405.h
+++ b/include/configs/APC405.h
@@ -48,6 +48,7 @@
 
 #define CONFIG_BAUDRATE		115200
 #define CONFIG_BOOTDELAY	1	/* autoboot after 3 seconds	*/
+#define CONFIG_BOOTCOUNT_LIMIT	1
 
 #undef	CONFIG_BOOTARGS
 
@@ -57,6 +58,8 @@
 				"run ramargs addip addcon usbargs;"	\
 				"bootm 200000 300000"
 #define CFG_USB_ARGS		"setenv bootargs $(bootargs) usbboot=1"
+#define CFG_BOOTLIMIT		"3"
+#define CFG_ALT_BOOTCOMMAND	"run usb_self;reset"
 
 #define CONFIG_EXTRA_ENV_SETTINGS                                       \
 	"hostname=abg405\0"                                             \
@@ -88,8 +91,10 @@
 	"usb_load="CFG_USB_LOAD_COMMAND"\0"				\
 	"usb_self="CFG_USB_SELF_COMMAND"\0"				\
 	"usbargs="CFG_USB_ARGS"\0"					\
+	"bootlimit="CFG_BOOTLIMIT"\0"					\
+	"altbootcmd="CFG_ALT_BOOTCOMMAND"\0"				\
 	""
-#define CONFIG_BOOTCOMMAND	"run flash_self;run usb_self"
+#define CONFIG_BOOTCOMMAND	"run flash_self;reset"
 
 #define CONFIG_ETHADDR		00:02:27:8e:00:00
 
@@ -414,7 +419,12 @@ extern int flash_banks;
 #define CFG_INIT_RAM_END	CFG_OCM_DATA_SIZE /* End of used area in RAM */
 #define CFG_GBL_DATA_SIZE	128 /* reserved bytes for initial data */
 #define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
-#define CFG_INIT_SP_OFFSET	CFG_GBL_DATA_OFFSET
+/* reserve some memory for BOOT limit info */
+#define CFG_INIT_SP_OFFSET	(CFG_GBL_DATA_OFFSET - 16)
+
+#ifdef CONFIG_BOOTCOUNT_LIMIT /* reserve 2 word for bootcount limit */
+#define CFG_BOOTCOUNT_ADDR (CFG_GBL_DATA_OFFSET - 8)
+#endif
 
 /*
  * Internal Definitions
-- 
1.5.3




From tur at semihalf.com  Fri Apr 25 12:09:33 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Fri, 25 Apr 2008 12:09:33 +0200
Subject: [U-Boot-Users] [PATCH v3 0/2] Calculate image hashes with watchdog
	triggering
In-Reply-To: <20080412111343.16495.21545.stgit@pollux.denx.de>
References: <20080412111343.16495.21545.stgit@pollux.denx.de>
Message-ID: <20080425100716.32281.23828.stgit@pollux.denx.de>

Hash calculation of an image can be a time consuming operation, with the
possibility of making the hardware watchdog (if present/enabled) expire in the
middle. Make image hash calculation use use watchdog-aware functions.
---
v3 of the patchset, rebased against current TOT (commit 04a5b03d), dropped one
patch already applied and added a patch changing crc32_wd prototype.

Bartlomiej Sieka (2):
      Use watchdog-aware functions when calculating hashes of images
      crc32: use uint32_t rather than unsigned long in watchdog-aware variant


 common/image.c      |   42 ++++++++----------------------------------
 include/image.h     |   17 +++++++++++++++--
 lib_generic/crc32.c |    4 +++-
 lib_generic/md5.c   |    4 ++++
 lib_generic/sha1.c  |    4 ++++
 5 files changed, 34 insertions(+), 37 deletions(-)



From tur at semihalf.com  Fri Apr 25 12:09:44 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Fri, 25 Apr 2008 12:09:44 +0200
Subject: [U-Boot-Users] [PATCH 1/2] crc32: use uint32_t rather than unsigned
	long in	watchdog-aware variant
In-Reply-To: <20080425100716.32281.23828.stgit@pollux.denx.de>
References: <20080425100716.32281.23828.stgit@pollux.denx.de>
Message-ID: <20080425100940.32281.20262.stgit@pollux.denx.de>

Propagate change introduced by "crc32: use uint32_t rather than unsigned
long", commit id 89cdab788f3716b335fefb60b836ebcf975aceab. While there,
change uint to uInt in crc32_wd prototype, to match convention already
present in the file.

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 lib_generic/crc32.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index 58cd22e..a7073c0 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -203,7 +203,8 @@ uint32_t ZEXPORT crc32_no_comp(uint32_t crc, const Bytef *buf, uInt len)
  * Calculate the crc32 checksum triggering the watchdog every 'chunk_sz' bytes
  * of input.
  */
-ulong crc32_wd (ulong crc, const unsigned char *buf, uint len, uint chunk_sz)
+uint32_t crc32_wd (uint32_t crc, const unsigned char *buf, uInt len,
+		uInt chunk_sz)
 {
 #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
 	const unsigned char *end, *curr;




From tur at semihalf.com  Fri Apr 25 12:10:09 2008
From: tur at semihalf.com (Bartlomiej Sieka)
Date: Fri, 25 Apr 2008 12:10:09 +0200
Subject: [U-Boot-Users] [PATCH v3 2/2] Use watchdog-aware functions when
	calculating hashes	of images
In-Reply-To: <20080425100716.32281.23828.stgit@pollux.denx.de>
References: <20080425100716.32281.23828.stgit@pollux.denx.de>
Message-ID: <20080425100950.32281.65923.stgit@pollux.denx.de>

Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
---

 common/image.c      |   42 ++++++++----------------------------------
 include/image.h     |   17 +++++++++++++++--
 lib_generic/crc32.c |    1 +
 lib_generic/md5.c   |    4 ++++
 lib_generic/sha1.c  |    4 ++++
 5 files changed, 32 insertions(+), 36 deletions(-)

diff --git a/common/image.c b/common/image.c
index 83e3593..4a024d4 100644
--- a/common/image.c
+++ b/common/image.c
@@ -156,6 +156,7 @@ static table_entry_t uimage_comp[] = {
 };
 
 uint32_t crc32 (uint32_t, const unsigned char *, uint);
+uint32_t crc32_wd (uint32_t, const unsigned char *, uint, uint);
 static void genimg_print_size (uint32_t size);
 #if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) || defined(USE_HOSTCC)
 static void genimg_print_time (time_t timestamp);
@@ -183,39 +184,11 @@ int image_check_dcrc (image_header_t *hdr)
 {
 	ulong data = image_get_data (hdr);
 	ulong len = image_get_data_size (hdr);
-	ulong dcrc = crc32 (0, (unsigned char *)data, len);
+	ulong dcrc = crc32_wd (0, (unsigned char *)data, len, CHUNKSZ_CRC32);
 
 	return (dcrc == image_get_dcrc (hdr));
 }
 
-#ifndef USE_HOSTCC
-int image_check_dcrc_wd (image_header_t *hdr, ulong chunksz)
-{
-	ulong dcrc = 0;
-	ulong len = image_get_data_size (hdr);
-	ulong data = image_get_data (hdr);
-
-#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
-	ulong cdata = data;
-	ulong edata = cdata + len;
-
-	while (cdata < edata) {
-		ulong chunk = edata - cdata;
-
-		if (chunk > chunksz)
-			chunk = chunksz;
-		dcrc = crc32 (dcrc, (unsigned char *)cdata, chunk);
-		cdata += chunk;
-
-		WATCHDOG_RESET ();
-	}
-#else
-	dcrc = crc32 (0, (unsigned char *)data, len);
-#endif
-
-	return (dcrc == image_get_dcrc (hdr));
-}
-#endif /* !USE_HOSTCC */
 
 /**
  * image_multi_count - get component (sub-image) count
@@ -416,7 +389,7 @@ static image_header_t* image_get_ramdisk (ulong rd_addr, uint8_t arch,
 
 	if (verify) {
 		puts("   Verifying Checksum ... ");
-		if (!image_check_dcrc_wd (rd_hdr, CHUNKSZ)) {
+		if (!image_check_dcrc (rd_hdr)) {
 			puts ("Bad Data CRC\n");
 			show_boot_progress (-12);
 			return NULL;
@@ -1923,15 +1896,16 @@ static int calculate_hash (const void *data, int data_len, const char *algo,
 			uint8_t *value, int *value_len)
 {
 	if (strcmp (algo, "crc32") == 0 ) {
-		*((uint32_t *)value) = crc32 (0, data, data_len);
+		*((uint32_t *)value) = crc32_wd (0, data, data_len,
+							CHUNKSZ_CRC32);
 		*((uint32_t *)value) = cpu_to_uimage (*((uint32_t *)value));
 		*value_len = 4;
 	} else if (strcmp (algo, "sha1") == 0 ) {
-		sha1_csum ((unsigned char *) data, data_len,
-				(unsigned char *) value);
+		sha1_csum_wd ((unsigned char *) data, data_len,
+				(unsigned char *) value, CHUNKSZ_SHA1);
 		*value_len = 20;
 	} else if (strcmp (algo, "md5") == 0 ) {
-		md5 ((unsigned char *)data, data_len, value);
+		md5_wd ((unsigned char *)data, data_len, value, CHUNKSZ_MD5);
 		*value_len = 16;
 	} else {
 		debug ("Unsupported hash alogrithm\n");
diff --git a/include/image.h b/include/image.h
index 4076484..664e51e 100644
--- a/include/image.h
+++ b/include/image.h
@@ -227,9 +227,23 @@ typedef struct bootm_headers {
 /*
  * Some systems (for example LWMON) have very short watchdog periods;
  * we must make sure to split long operations like memmove() or
- * crc32() into reasonable chunks.
+ * checksum calculations into reasonable chunks.
  */
+#ifndef CHUNKSZ
 #define CHUNKSZ (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_CRC32
+#define CHUNKSZ_CRC32 (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_MD5
+#define CHUNKSZ_MD5 (64 * 1024)
+#endif
+
+#ifndef CHUNKSZ_SHA1
+#define CHUNKSZ_SHA1 (64 * 1024)
+#endif
 
 #define uimage_to_cpu(x)		ntohl(x)
 #define cpu_to_uimage(x)		htonl(x)
@@ -363,7 +377,6 @@ static inline void image_set_name (image_header_t *hdr, const char *name)
 int image_check_hcrc (image_header_t *hdr);
 int image_check_dcrc (image_header_t *hdr);
 #ifndef USE_HOSTCC
-int image_check_dcrc_wd (image_header_t *hdr, ulong chunksize);
 int getenv_yesno (char *var);
 ulong getenv_bootm_low(void);
 ulong getenv_bootm_size(void);
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index a7073c0..336a6e5 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -14,6 +14,7 @@
 #include <stdint.h>
 #endif
 
+#include <watchdog.h>
 #include "zlib.h"
 
 #define local static
diff --git a/lib_generic/md5.c b/lib_generic/md5.c
index 20178b8..78ef475 100644
--- a/lib_generic/md5.c
+++ b/lib_generic/md5.c
@@ -25,6 +25,10 @@
    and to fit the cifs vfs by
    Steve French sfrench at us.ibm.com */
 
+#ifndef USE_HOSTCC
+#include <common.h>
+#endif /* USE_HOSTCC */
+#include <watchdog.h>
 #include <linux/types.h>
 #include <linux/string.h>
 #include <u-boot/md5.h>
diff --git a/lib_generic/sha1.c b/lib_generic/sha1.c
index 6950659..c8ef4d2 100644
--- a/lib_generic/sha1.c
+++ b/lib_generic/sha1.c
@@ -29,6 +29,10 @@
 #define _CRT_SECURE_NO_DEPRECATE 1
 #endif
 
+#ifndef USE_HOSTCC
+#include <common.h>
+#endif /* USE_HOSTCC */
+#include <watchdog.h>
 #include <linux/string.h>
 #include "sha1.h"
 




From r63238 at freescale.com  Fri Apr 25 12:23:32 2008
From: r63238 at freescale.com (Dave Liu)
Date: Fri, 25 Apr 2008 18:23:32 +0800
Subject: [U-Boot-Users] [PATCH] mpc83xx: bump default loadaddr over
	fdtaddr, to	0x500000
In-Reply-To: <20080424141031.404c31e3.kim.phillips@freescale.com>
References: <20080424141031.404c31e3.kim.phillips@freescale.com>
Message-ID: <1209119012.3656.0.camel@localhost.localdomain>

On Fri, 2008-04-25 at 03:10 +0800, Phillips Kim wrote:
> this seems as a good compromise between human memory, typing,
> and last but not least, to accommodate for current and future kernel
> bloat.
> 
> Signed-off-by: Kim Phillips <kim.phillips at freescale.com>

Acked-by: Dave Liu <daveliu at freescale.com>




From r63238 at freescale.com  Fri Apr 25 12:28:04 2008
From: r63238 at freescale.com (Dave Liu)
Date: Fri, 25 Apr 2008 18:28:04 +0800
Subject: [U-Boot-Users] [PATCH][RFC] lib_ppc: make the flush_cache
	stronger
In-Reply-To: <20080424144517.5F17E24AB1@gemini.denx.de>
References: <20080424144517.5F17E24AB1@gemini.denx.de>
Message-ID: <1209119284.3656.5.camel@localhost.localdomain>

> > Current flush_cache code does
> >
> > 1. clean the dcache with dcbst, but not invalidate dcache
> > 2. invalidate icache
> >
> > This patch use the dcbf instead of dcbst to have stronger
> > semantic, clean the dcache and invalidate dcache.
> 
> On which processors did you test the changes? I have some unclear
> memories of dcbf having problems on for example MPC8xx ?

on 83xx parts.
I remember the 601 processor not support the dcbf.

> > We have two options:
> >
> > 1. Separate functions for them like linux kernel.
> >    A. clean dcache (dcbst) for DMA_TO_DEVICE
> >    B. invalidate dcache (dcbi) for DMA_FROM_DEVICE
> >    C. flush dcache (dcbf) for DMA_BIDIRECTIONAL.
> > 2. Make current flush_cache stronger semanctic.
> >    use the dcbf instead of dcbst.
> >
> > Which one is better? or you have better option?
> > Please suggest.
> 
> We discussed this a bit on IRC; Kumar suggested to go for 1., and I
> agree.

Where is the IRC? Could you point it to me?

Thanks,
Dave




From mshiokawa at miraclelinux.com  Fri Apr 25 12:45:52 2008
From: mshiokawa at miraclelinux.com (Makito SHIOKAWA)
Date: Fri, 25 Apr 2008 19:45:52 +0900
Subject: [U-Boot-Users] [RFC] Implementing Boot Image Fallback on U-Boot
In-Reply-To: <20080424132303.4887924AB1@gemini.denx.de>
References: <20080424132303.4887924AB1@gemini.denx.de>
Message-ID: <4811B660.7020901@miraclelinux.com>

Hi,

Thank you for your reply.

> Are you aware that U-Boot has scripting capabilities, to the extend of
> being able to run shell scripts?

What I was thinking as "boomf" is like a patch bellow (It is for U-Boot 1.1.4 
and just a prototype). I knew about scripting, but I thought it was difficult 
to do this processing by a script (especially error checks). Also, I didn't 
think it's a good way to set corresponding long script to "bootcmd" (U-Boot 
environment area is limited).

But, is it better to do this processing by a script? (Or, is there more proper 
way to do same kind of things?)

> What you are asking for can be pretty easily implemented using a few
> macro definitions utilizing the aforementioned features.

Is it able to do without using all of the elements (new command, new 
environment variable, fw_setenv) I wrote in the first mail?
I'll check documents and sources over again, but I would appreciate if you can 
give me some keywords of those features ...


Best regards,

---
  common/Makefile     |    2
  common/cmd_bootmf.c |  256 +++++++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 257 insertions(+), 1 deletion(-)

--- a/common/Makefile
+++ b/common/Makefile
@@ -29,7 +29,7 @@ AOBJS	=

  COBJS	= main.o ACEX1K.o altera.o bedbug.o circbuf.o \
  	  cmd_ace.o cmd_autoscript.o \
-	  cmd_bdinfo.o cmd_bedbug.o cmd_bmp.o cmd_boot.o cmd_bootm.o \
+	  cmd_bdinfo.o cmd_bedbug.o cmd_bmp.o cmd_boot.o cmd_bootm.o cmd_bootmf.o \
  	  cmd_cache.o cmd_console.o \
  	  cmd_date.o cmd_dcr.o cmd_diag.o cmd_display.o cmd_doc.o cmd_dtt.o \
  	  cmd_eeprom.o cmd_elf.o cmd_ext2.o \
--- /dev/null
+++ b/common/cmd_bootmf.c
@@ -0,0 +1,256 @@
+/*
+ * (C) Copyright 2008
+ * Makito SHIOKAWA, MIRACLE LINUX CORPORATION, mshiokawa at miraclelinux.com
+ *
+ * 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 <common.h>
+#include <command.h>
+
+extern int do_bootm (cmd_tbl_t *, int, int, char *[]);
+
+/*
+ * Codes are taken from GRUB
+ */
+
+#define MAXINT 0x7FFFFFFF
+#define MAX_FALLBACK_ENTRIES 8
+
+static int default_entry;
+static int fallback_entryno;
+static int fallback_entries[MAX_FALLBACK_ENTRIES];
+static int current_entryno;
+
+static int tolower (int c)
+{
+	if (c >= 'A' && c <= 'Z')
+		return (c + ('a' - 'A'));
+	
+	return c;
+}
+
+static int safe_parse_maxint (char **str_ptr, int *myint_ptr)
+{
+	char *ptr = *str_ptr;
+	int myint = 0;
+	int mult = 10, found = 0;
+
+	/*
+	 *  Is this a hex number?
+	 */
+	if (*ptr == '0' && tolower (*(ptr + 1)) == 'x')
+	{
+		ptr += 2;
+		mult = 16;
+	}
+	
+	while (1)
+	{
+		/* A bit tricky. This below makes use of the equivalence:
+		   (A >= B && A <= C) <=> ((A - B) <= (C - B))
+		   when C > B and A is unsigned.  */
+		unsigned int digit;
+		
+		digit = tolower (*ptr) - '0';
+		if (digit > 9)
+		{
+			digit -= 'a' - '0';
+			if (mult == 10 || digit > 5)
+				break;
+			digit += 10;
+		}
+		
+		found = 1;
+		if (myint > ((MAXINT - digit) / mult))
+		{
+			return 0;
+		}
+		myint = (myint * mult) + digit;
+		ptr++;
+	}
+	
+	if (!found)
+	{
+		return 0;
+	}
+	
+	*str_ptr = ptr;
+	*myint_ptr = myint;
+	
+	return 1;
+}
+
+static int default_func (char *arg)
+{
+	if (! safe_parse_maxint (&arg, &default_entry))
+		return 1;
+
+	return 0;
+}
+
+/* Find the next word from CMDLINE and return the pointer. If
+   AFTER_EQUAL is non-zero, assume that the character `=' is treated as
+   a space. Caution: this assumption is for backward compatibility.  */
+static char *skip_to (int after_equal, char *cmdline)
+{
+	/* Skip until we hit whitespace, or maybe an equal sign. */
+	while (*cmdline && *cmdline != ' ' && *cmdline != '\t' &&
+	      ! (after_equal && *cmdline == '='))
+		cmdline ++;
+	
+	/* Skip whitespace, and maybe equal signs. */
+	while (*cmdline == ' ' || *cmdline == '\t' ||
+	      (after_equal && *cmdline == '='))
+		cmdline ++;
+
+	return cmdline;
+}
+
+static int fallback_func (char *arg)
+{
+	int i = 0;
+	
+	while (*arg)
+	{
+		int entry;
+		int j;
+		
+		if (! safe_parse_maxint (&arg, &entry))
+			return 1;
+		
+		/* Remove duplications to prevent infinite looping.  */
+		for (j = 0; j < i; j++)
+			if (entry == fallback_entries[j])
+				break;
+		if (j != i)
+			continue;
+		
+		fallback_entries[i++] = entry;
+		if (i == MAX_FALLBACK_ENTRIES)
+			break;
+		
+		arg = skip_to (0, arg);
+	}
+	
+	if (i < MAX_FALLBACK_ENTRIES)
+		fallback_entries[i] = -1;
+	
+	fallback_entryno = (i == 0) ? -1 : 0;
+	
+	return 0;
+}
+
+static int savedefault_func (void)
+{
+	int entryno;
+	int i;
+	int index = 0;
+	char buf[16];
+	
+	for (i = 0; i < MAX_FALLBACK_ENTRIES; i++)
+	{
+		if (fallback_entries[i] < 0)
+			break;
+		if (fallback_entries[i] == current_entryno)
+		{
+			index = i + 1;
+			break;
+		}
+	}
+	
+	if (index >= MAX_FALLBACK_ENTRIES || fallback_entries[index] < 0)
+	{
+		/* This is the last.  */
+		return 1;
+	}
+	
+	entryno = fallback_entries[index];
+	
+	sprintf(buf, "%d", entryno);
+	setenv("default", buf);
+	saveenv();
+	
+	return 0;
+}
+
+/*
+ * TODO: Add error check
+ */
+
+int do_bootmf (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+	char *s;
+	
+	default_entry = 0;
+	fallback_entryno = -1;
+	fallback_entries[0] = -1;
+	current_entryno = 0;
+	
+	if ((s = getenv("default")) != NULL)
+		default_func(s);
+	
+	if ((s = getenv("fallback")) != NULL)
+		fallback_func(s);
+	
+	while (1) {
+		char buf[16];
+		char *local_args[2];
+		ulong addr;
+		int rcode = 0;
+		
+		if (!current_entryno)
+			current_entryno = default_entry;
+		
+		savedefault_func();
+		
+		sprintf(buf, "imgaddr%d", current_entryno);
+		if ((s = getenv(buf)) != NULL)
+			addr = simple_strtoul(s, NULL, 16);
+		else
+			break;
+		
+		sprintf(buf, "bootargs%d", current_entryno);
+		if ((s = getenv(buf)) != NULL)
+			setenv("bootargs", s);
+		else
+			break;
+		
+		load_addr = addr;
+		local_args[0] = argv[0];
+		local_args[1] = NULL;
+		rcode = do_bootm (cmdtp, 0, 1, local_args);
+		if (rcode) {
+			if (fallback_entryno >= 0) {
+				current_entryno = fallback_entries[fallback_entryno];
+				fallback_entryno++;
+				if (fallback_entryno >= MAX_FALLBACK_ENTRIES
+				   || fallback_entries[fallback_entryno] < 0)
+					fallback_entryno = -1;
+			} else
+				break;
+		} else
+			break;
+	}
+	
+	return 1;
+}
+
+U_BOOT_CMD(
+	bootmf, 1, 1, do_bootmf,
+	"bootmf - boot application image from memory with fallback enabled\n",
+	NULL
+);

-- 
MIRACLE LINUX CORPORATION
Makito SHIOKAWA



From wd at denx.de  Fri Apr 25 12:48:04 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 12:48:04 +0200
Subject: [U-Boot-Users] [PATCH] lib_generic/crc32.c: fix compile problem
Message-ID: <1209120484-24819-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 lib_generic/crc32.c |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index 58cd22e..32e72f9 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -151,10 +151,7 @@ const uint32_t * ZEXPORT get_crc_table()
 #define DO8(buf)  DO4(buf); DO4(buf);
 
 /* ========================================================================= */
-uint32_t ZEXPORT crc32(crc, buf, len)
-    uint32_t crc;
-    const Bytef *buf;
-    uInt len;
+uint32_t ZEXPORT crc32 (uint32_t crc, const Bytef *buf, uInt len)
 {
 #ifdef DYNAMIC_CRC_TABLE
     if (crc_table_empty)
@@ -203,7 +200,9 @@ uint32_t ZEXPORT crc32_no_comp(uint32_t crc, const Bytef *buf, uInt len)
  * Calculate the crc32 checksum triggering the watchdog every 'chunk_sz' bytes
  * of input.
  */
-ulong crc32_wd (ulong crc, const unsigned char *buf, uint len, uint chunk_sz)
+uint32_t ZEXPORT crc32_wd (uint32_t crc,
+			   const unsigned char *buf,
+			   uInt len, uInt chunk_sz)
 {
 #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
 	const unsigned char *end, *curr;
-- 
1.5.4.2




From wd at denx.de  Fri Apr 25 12:48:12 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 12:48:12 +0200
Subject: [U-Boot-Users] [PATCH] lib_generic/crc32.c: add missing #include
	<watchdog.h>
Message-ID: <1209120492-24848-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 lib_generic/crc32.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c
index 32e72f9..73070de 100644
--- a/lib_generic/crc32.c
+++ b/lib_generic/crc32.c
@@ -13,6 +13,7 @@
 #else
 #include <stdint.h>
 #endif
+#include <watchdog.h>
 
 #include "zlib.h"
 
-- 
1.5.4.2




From wd at denx.de  Fri Apr 25 12:48:21 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 12:48:21 +0200
Subject: [U-Boot-Users] [PATCH] USB: fix more GCC 4.2.x aliasing warnings
Message-ID: <1209120501-24880-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
Acked-by: Markus Klotzbuecher <mk at denx.de>
---
 cpu/arm920t/s3c24x0/usb_ohci.c |    4 ++--
 cpu/mpc5xxx/usb_ohci.c         |    4 ++--
 cpu/ppc4xx/usb_ohci.c          |    4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/cpu/arm920t/s3c24x0/usb_ohci.c b/cpu/arm920t/s3c24x0/usb_ohci.c
index 4075f2e..96e43d0 100644
--- a/cpu/arm920t/s3c24x0/usb_ohci.c
+++ b/cpu/arm920t/s3c24x0/usb_ohci.c
@@ -58,8 +58,8 @@
 #define	OHCI_CONTROL_INIT \
 	(OHCI_CTRL_CBSR & 0x3) | OHCI_CTRL_IE | OHCI_CTRL_PLE
 
-#define readl(a) (*((vu_long *)(a)))
-#define writel(a, b) (*((vu_long *)(b)) = ((vu_long)a))
+#define readl(a) (*((volatile u32 *)(a)))
+#define writel(a, b) (*((volatile u32 *)(b)) = ((volatile u32)a))
 
 #define min_t(type,x,y) ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
 
diff --git a/cpu/mpc5xxx/usb_ohci.c b/cpu/mpc5xxx/usb_ohci.c
index c774da3..2ad12b2 100644
--- a/cpu/mpc5xxx/usb_ohci.c
+++ b/cpu/mpc5xxx/usb_ohci.c
@@ -56,8 +56,8 @@
 #define OHCI_CONTROL_INIT \
 	(OHCI_CTRL_CBSR & 0x3) | OHCI_CTRL_IE | OHCI_CTRL_PLE
 
-#define readl(a) (*((vu_long *)(a)))
-#define writel(a, b) (*((vu_long *)(b)) = ((vu_long)a))
+#define readl(a) (*((volatile u32 *)(a)))
+#define writel(a, b) (*((volatile u32 *)(b)) = ((volatile u32)a))
 
 #define min_t(type,x,y) ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
 
diff --git a/cpu/ppc4xx/usb_ohci.c b/cpu/ppc4xx/usb_ohci.c
index c71a6a9..7dbb288 100644
--- a/cpu/ppc4xx/usb_ohci.c
+++ b/cpu/ppc4xx/usb_ohci.c
@@ -56,8 +56,8 @@
 #define OHCI_CONTROL_INIT \
 	(OHCI_CTRL_CBSR & 0x3) | OHCI_CTRL_IE | OHCI_CTRL_PLE
 
-#define readl(a) (*((vu_long *)(a)))
-#define writel(a, b) (*((vu_long *)(b)) = ((vu_long)a))
+#define readl(a) (*((volatile u32 *)(a)))
+#define writel(a, b) (*((volatile u32 *)(b)) = ((volatile u32)a))
 
 #define min_t(type,x,y) ({ type __x = (x); type __y = (y); __x < __y ? __x: __y; })
 
-- 
1.5.4.2




From wd at denx.de  Fri Apr 25 12:54:17 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 12:54:17 +0200
Subject: [U-Boot-Users] u-boot on mpc852
In-Reply-To: Your message of "Fri, 25 Apr 2008 14:43:47 +0530."
	<OF03CC1600.23DE933E-ON65257436.0032B387-65257436.0032B38E@messung.com>
Message-ID: <20080425105417.E087A24AB1@gemini.denx.de>

In message <OF03CC1600.23DE933E-ON65257436.0032B387-65257436.0032B38E at messung.com> you wrote:
> 
> Can I use u-boot boot loader on mpc852 (powerPC)?

Yes, of course you can. MPC8xx is well supported.

> I mean is already some patch is available ? ? ?

Patch? Patch for what?

You will probably have to port U-Boot to your custome hardware,
though.

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: wd at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie



From wd at denx.de  Fri Apr 25 13:15:48 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 13:15:48 +0200
Subject: [U-Boot-Users] [PATCH][RFC] lib_ppc: make the flush_cache
	stronger
In-Reply-To: Your message of "Fri, 25 Apr 2008 18:28:04 +0800."
	<1209119284.3656.5.camel@localhost.localdomain>
Message-ID: <20080425111548.E399E24AB5@gemini.denx.de>

In message <1209119284.3656.5.camel at localhost.localdomain> you wrote:
>
> > On which processors did you test the changes? I have some unclear
> > memories of dcbf having problems on for example MPC8xx ?
> 
> on 83xx parts.
> I remember the 601 processor not support the dcbf.

OK, so cannot use the patch you suggested.

> > > We have two options:
> > >
> > > 1. Separate functions for them like linux kernel.
> > >    A. clean dcache (dcbst) for DMA_TO_DEVICE
> > >    B. invalidate dcache (dcbi) for DMA_FROM_DEVICE
> > >    C. flush dcache (dcbf) for DMA_BIDIRECTIONAL.
> > > 2. Make current flush_cache stronger semanctic.
> > >    use the dcbf instead of dcbst.
> > >
> > > Which one is better? or you have better option?
> > > Please suggest.
> > 
> > We discussed this a bit on IRC; Kumar suggested to go for 1., and I
> > agree.
> 
> Where is the IRC? Could you point it to me?

That's #u-boot at irc.freenode.org

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: wd at denx.de
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt



From wd at denx.de  Fri Apr 25 13:13:28 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 13:13:28 +0200
Subject: [U-Boot-Users] [PATCH v3 2/2] Use watchdog-aware functions when
	calculating hashes of images
In-Reply-To: Your message of "Fri, 25 Apr 2008 12:10:09 +0200."
	<20080425100950.32281.65923.stgit@pollux.denx.de>
Message-ID: <20080425111328.F342724AB5@gemini.denx.de>

In message <20080425100950.32281.65923.stgit at pollux.denx.de> you wrote:
> Signed-off-by: Bartlomiej Sieka <tur at semihalf.com>
> ---
> 
>  common/image.c      |   42 ++++++++----------------------------------
>  include/image.h     |   17 +++++++++++++++--
>  lib_generic/crc32.c |    1 +
>  lib_generic/md5.c   |    4 ++++
>  lib_generic/sha1.c  |    4 ++++
>  5 files changed, 32 insertions(+), 36 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: wd at denx.de
The flow chart is a most thoroughly oversold piece of  program  docu-
mentation.              -- Frederick Brooks, "The Mythical Man Month"



From sew_s at tqs.de  Fri Apr 25 13:22:56 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Fri, 25 Apr 2008 13:22:56 +0200
Subject: [U-Boot-Users] Question about smc911x driver (16/32 Bit support)
In-Reply-To: <59b21cf20804231053j61f37043g72487f3c412d0e0d@mail.gmail.com>
References: <480DD799.50402@tqs.de>	
	<f8328f7c0804221103i7af61e05h3134aea07eb95ee4@mail.gmail.com>	
	<480ED91C.4010400@tqs.de>	
	<59b21cf20804230635k4d424d88wb7f6fdc9b3e49298@mail.gmail.com>	
	<f8328f7c0804231029v25e43b50y524f8bf3510fa891@mail.gmail.com>
	<59b21cf20804231053j61f37043g72487f3c412d0e0d@mail.gmail.com>
Message-ID: <4811BF10.8080700@tqs.de>

Hi Magnus, Ben,

Magnus Lilja schrieb:
> Hi Ben,
> 
>>  >  Well, the i.MX31 Litekit board has a 16-bit LAN9117 and that seems to
>>  >  work with the 32-bit flag set in the config file.
>>  >
>>  That's good news.  I would prefer, though, to break this into two
>>  16-bit accesses so we don't need to wonder what architectures it would
>>  work on.  Would you be able to try something out, since you have
>>  hardware?
> 
> If someone publishes a patch I can certainly try it on the hardware.

I already prepared the patch, but currently I can't test it, and I'm not 
sure if I did it right. Please be patient.
Meanwhile, I report successful execution of the current driver yesterday 
on our HW developer's board with 16 bit port size. The i.MX31 splits the 
32 bit word (I knew that from PowerPC, but wasn't sure of ARM).

Regards,
Jens




From sr at denx.de  Fri Apr 25 13:38:25 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 13:38:25 +0200
Subject: [U-Boot-Users] [PATCH V2] ppc4xx: Add bootcount limit handling
	for APC405 boards
In-Reply-To: <200804251201.39658.matthias.fuchs@esd-electronics.com>
References: <200804241133.04972.matthias.fuchs@esd-electronics.com>
	<200804241658.59648.sr@denx.de>
	<200804251201.39658.matthias.fuchs@esd-electronics.com>
Message-ID: <200804251338.25833.sr@denx.de>

On Friday 25 April 2008, Matthias Fuchs wrote:
> Signed-off-by: Matthias Fuchs <matthias.fuchs at esd-electronics.com>

Applied to u-boot-ppc4xx. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 25 13:40:07 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 13:40:07 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: <200804221551.06813.sr@denx.de>
References: <20070423123237.295A13535D2@atlas.denx.de>
	<200804181702.21886.sr@denx.de> <200804221551.06813.sr@denx.de>
Message-ID: <200804251340.07270.sr@denx.de>

The following changes since commit 58c5376ba67767ee684069d43e7f747a5d9ae8ed:
  Wolfgang Denk (1):
        Merge branch 'master' of git://www.denx.de/git/u-boot-ppc4xx

are available in the git repository at:

  git://www.denx.de/git/u-boot-ppc4xx.git master

Matthias Fuchs (1):
      ppc4xx: Add bootcount limit handling for APC405 boards

Stefan Roese (1):
      ppc4xx: Pass PCIe root-complex/endpoint configuration to Linux via the fdt

 board/esd/apc405/apc405.c  |    7 ++++++-
 cpu/ppc4xx/fdt.c           |   42 ++++++++++++++++++++++++++++++++++++++++++
 include/asm-ppc/4xx_pcie.h |    5 ++++-
 include/configs/APC405.h   |   14 ++++++++++++--
 4 files changed, 64 insertions(+), 4 deletions(-)



From garyj at denx.de  Fri Apr 25 14:40:01 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Fri, 25 Apr 2008 14:40:01 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Add the Harris QUAD100HD AMCC
 405EP-based board.
In-Reply-To: <200804240827.20526.sr@denx.de>
References: <20080423151258.7ac66064@peedub.jennejohn.org>
	<200804240827.20526.sr@denx.de>
Message-ID: <20080425144001.0cdb8f4e@peedub.jennejohn.org>

On Thu, 24 Apr 2008 08:27:20 +0200
Stefan Roese <sr at denx.de> wrote:

> > +#define CONFIG_IPADDR		192.168.1.67
> > +#define CONFIG_SERVERIP		192.168.1.50
> > +#define CONFIG_GATEWAYIP	192.168.1.1
> > +#define CONFIG_NETMASK		255.255.255.0
> > +#define CONFIG_ETHADDR 		00:01:02:03:04:05
> > +#define CONFIG_ETH1ADDR		00:01:02:03:04:06
> 
> Are you really sure that you want to provide default MAC-addresses? We usually 
> don't do this.
> 

The customer had CONFIG_ETHADDR set in PPCBoot.  I added CONFIG_ETH1ADDR
analog to that, since I have CONFIG_NET_MULTI defined in quad100hd.h.

I personally don't care either way and have no problem with removing them.
Don't know what the customer would have to say about that.

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From ayman at elkhashab.com  Fri Apr 25 14:41:02 2008
From: ayman at elkhashab.com (Ayman El-Khashab)
Date: Fri, 25 Apr 2008 07:41:02 -0500
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <200804250813.56303.sr@denx.de>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<4810AD11.3010307@ovro.caltech.edu>
	<20080424161043.GC7245@crust.elkhashab.com>
	<200804250813.56303.sr@denx.de>
Message-ID: <4811D15E.4080208@elkhashab.com>

Stefan Roese wrote:
> On Thursday 24 April 2008, Ayman M. El-Khashab wrote:
>   
>> So maybe I need to clarify some more.  The PPC460 data sheet
>> is not too clear on this yet.  However, here are my thoughts
>> on this.  Lets just take the simple case as an example.  We
>> have a plurality of 460s where a single one is the master.
>> Between the master and all the slaves is a PCI bridge.  The
>> slaves are hardwired to boot from pci bus memory -- according
>> to the datasheet that is at a fixed address.  So there does
>> not appear to be any need to do anything to the slave upon
>> power up.  Now the master boots and then allocates a chunk
>> of contiguous memory using a kernel driver or whatever is
>> needed.  The image is just whatever the flash image would
>> normally contain (uboot + kernel + rootfs).  The address of
>> that chunk is then given to the pci bridge so that it can
>> perform inbound translation from the address that the PPC
>> slaves will use to the address where the image is physically
>> located.  Then the slaves are taken out of reset and begin
>> reading "flash" across the pci bus which really goes through
>> the bridge and is mapped to the DRAM on the master (or I
>> guess it could be the flash on the master, but DRAM seemed
>> easier since it is already running).
>>
>> Ok, so how many holes does this approach have?
>>     
>
> Sounds quite reasonable. The only thing I'm unsure here is the size of the PCI 
> windows that is mapped upon PCI booting. 

Thanks for all your help ...

I thought the answer to both questions was in footnote 3 on page 8 of 
the data sheet.  At least that was
my interpretation of the following statement:  "3. When the optional 
boot from PCI Memory is selected, the
PCI Boot ROM address space begins at 0000 000C FF00 0000 (16 MB)."

I interpreted that to mean the address was not something that needed to 
be configured in any sort of
bar register and that the address it fetched was fixed.  So the only 
thing that was required was to
configure the inbound translation on the bridge. 

- ame




From sr at denx.de  Fri Apr 25 14:45:38 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 14:45:38 +0200
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <4811D15E.4080208@elkhashab.com>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<200804250813.56303.sr@denx.de> <4811D15E.4080208@elkhashab.com>
Message-ID: <200804251445.38814.sr@denx.de>

On Friday 25 April 2008, Ayman El-Khashab wrote:
> > Sounds quite reasonable. The only thing I'm unsure here is the size of
> > the PCI windows that is mapped upon PCI booting.
>
> Thanks for all your help ...
>
> I thought the answer to both questions was in footnote 3 on page 8 of
> the data sheet.  At least that was
> my interpretation of the following statement:  "3. When the optional
> boot from PCI Memory is selected, the
> PCI Boot ROM address space begins at 0000 000C FF00 0000 (16 MB)."

Ah, I didn't notice this.

> I interpreted that to mean the address was not something that needed to
> be configured in any sort of
> bar register and that the address it fetched was fixed.  So the only
> thing that was required was to
> configure the inbound translation on the bridge.

You could be right here.

Good luck with this PCI booting stuff. Please keep us informed on the 
progress.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From galak at kernel.crashing.org  Fri Apr 25 14:52:20 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 07:52:20 -0500
Subject: [U-Boot-Users] [PATCH] MPC8544DS: Removes the unknown flash
	message information
In-Reply-To: <20080425083908.0FC1824AB5@gemini.denx.de>
References: <20080425083908.0FC1824AB5@gemini.denx.de>
Message-ID: <79369D8F-3184-4D04-8FCA-1575F7B5EA59@kernel.crashing.org>


On Apr 25, 2008, at 3:39 AM, Wolfgang Denk wrote:
> In message <Pine.LNX. 
> 4.64.0804250054340.32740 at blarg.am.freescale.net> you wrote:
>> From: Roy Zang <tie-fei.zang at freescale.com>
>>
>> This patch removes the unknown flash message information:
>> '## Unknown FLASH on Bank 1 - Size = 0xdeadbeef = -286261248 MB'
>> This unknown flash message is caused by PromJet.
>> Some of the board user is unhappy with this information.
>>
>> Signed-off-by: Roy Zang <tie-fei.zang at freescale.com>
>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>
> Is it correct to assume that a 85xx pull request will follow soon?

hopefully but that depends on Andy be awake today :)

- k



From galak at kernel.crashing.org  Fri Apr 25 14:53:03 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 07:53:03 -0500
Subject: [U-Boot-Users] [PATCH] 85xx: Fix size of cpu-release-addr
	property
In-Reply-To: <20080425071600.9894A24AB1@gemini.denx.de>
References: <20080425071600.9894A24AB1@gemini.denx.de>
Message-ID: <DCD54745-A286-4E15-93FE-C71CD00AED37@kernel.crashing.org>


On Apr 25, 2008, at 2:16 AM, Wolfgang Denk wrote:
> In message <Pine.LNX.4.64.0804181128440.6860 at blarg.am.freescale.net>  
> you wrote:
>> The cpu-release-addr is defined as always being a 64-bit quanity  
>> regardless
>> if we are running on a 32-bit or 64-bit machine.
>> ---
>> cpu/mpc85xx/fdt.c |    2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Signed-off-by line  missing...

oops (should have had it).  This got into the tree how do you want to  
deal with it?

- k



From galak at kernel.crashing.org  Fri Apr 25 15:01:26 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 08:01:26 -0500
Subject: [U-Boot-Users] [PATCH][RFC] lib_ppc: make the flush_cache
	stronger
In-Reply-To: <1209119284.3656.5.camel@localhost.localdomain>
References: <20080424144517.5F17E24AB1@gemini.denx.de>
	<1209119284.3656.5.camel@localhost.localdomain>
Message-ID: <EE7D20F7-6F04-4138-9E11-955D77574BFC@kernel.crashing.org>

>> We discussed this a bit on IRC; Kumar suggested to go for 1., and I
>> agree.
>
> Where is the IRC? Could you point it to me?

same server (irc.freenode.net) as #mklinux, but the channel is #u-boot

- k




From galak at kernel.crashing.org  Fri Apr 25 15:02:04 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 08:02:04 -0500
Subject: [U-Boot-Users] [PATCH][RFC] lib_ppc: make the flush_cache
	stronger
In-Reply-To: <20080425111548.E399E24AB5@gemini.denx.de>
References: <20080425111548.E399E24AB5@gemini.denx.de>
Message-ID: <A4E9E5BB-50C7-493D-B6B3-0B43101A53A8@kernel.crashing.org>


On Apr 25, 2008, at 6:15 AM, Wolfgang Denk wrote:
> In message <1209119284.3656.5.camel at localhost.localdomain> you wrote:
>>
>>> On which processors did you test the changes? I have some unclear
>>> memories of dcbf having problems on for example MPC8xx ?
>>
>> on 83xx parts.
>> I remember the 601 processor not support the dcbf.
>
> OK, so cannot use the patch you suggested.

u-boot doesn't support any 601 systems and we should keep it that way.

- k




From sr at denx.de  Fri Apr 25 15:53:51 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 15:53:51 +0200
Subject: [U-Boot-Users] [PATCH V2] cfi-flash: Add
	CFG_FLASH_AUTOPROTECT_LIST
In-Reply-To: <200804210923.18006.matthias.fuchs@esd-electronics.com>
References: <20080420234539.708B6248A6@gemini.denx.de>
	<200804210923.18006.matthias.fuchs@esd-electronics.com>
Message-ID: <200804251553.51138.sr@denx.de>

On Monday 21 April 2008, Matthias Fuchs wrote:
> let me summarize: let's take my initial patch that I posted on Friday.
> At least two people will be satisfied :-)

OK.

I applied the first version to the u-boot-cfi-flash repository.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Fri Apr 25 15:55:58 2008
From: sr at denx.de (Stefan Roese)
Date: Fri, 25 Apr 2008 15:55:58 +0200
Subject: [U-Boot-Users] [cfi-flash] Please pull
	git://www.denx.de/git/u-boot-cfi-flash.git
In-Reply-To: <200804120902.15311.sr@denx.de>
References: <20070423123237.295A13535D2@atlas.denx.de>
	<200804111649.37273.sr@denx.de> <200804120902.15311.sr@denx.de>
Message-ID: <200804251555.58837.sr@denx.de>

The following changes since commit d0d91ae3acb4f29d1a2a3a766747478ed54e2848:
  Stefan Roese (1):
        ppc4xx: Remove double defines in lwmon5.h

are available in the git repository at:

  git://www.denx.de/git/u-boot-cfi-flash.git master

Matthias Fuchs (1):
      cfi-flash: Add CFG_FLASH_AUTOPROTECT_LIST

 drivers/mtd/cfi_flash.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)



From kim.phillips at freescale.com  Fri Apr 25 16:45:52 2008
From: kim.phillips at freescale.com (Kim Phillips)
Date: Fri, 25 Apr 2008 09:45:52 -0500
Subject: [U-Boot-Users] Please pull u-boot-mpc83xx.git
Message-ID: <20080425094552.d8399e46.kim.phillips@freescale.com>

for some minor fixes:

The following changes since commit d0d91ae3acb4f29d1a2a3a766747478ed54e2848:
  Stefan Roese (1):
        ppc4xx: Remove double defines in lwmon5.h

are available in the git repository at:

  git://www.denx.de/git/u-boot-mpc83xx.git

Dave Liu (2):
      mpc83xx: remove the unused CPM's stuff
      mpc83xx: clean up the readme for 83xx boards

Kim Phillips (1):
      mpc83xx: bump loadaddr over fdtaddr to 0x500000

 cpu/mpc83xx/fdt.c             |    8 --------
 doc/README.mpc8313erdb        |    4 ++--
 doc/README.mpc8315erdb        |    2 +-
 doc/README.mpc837xemds        |    2 +-
 doc/README.mpc837xerdb        |   13 ++++++-------
 include/configs/MPC8313ERDB.h |    2 +-
 include/configs/MPC8315ERDB.h |    2 +-
 include/configs/MPC8323ERDB.h |    2 +-
 include/configs/MPC832XEMDS.h |    2 +-
 include/configs/MPC8349EMDS.h |    2 +-
 include/configs/MPC8349ITX.h  |    2 +-
 include/configs/MPC8360EMDS.h |    2 +-
 include/configs/MPC837XEMDS.h |    2 +-
 include/configs/MPC837XERDB.h |    2 +-
 include/configs/sbc8349.h     |    2 +-
 15 files changed, 20 insertions(+), 29 deletions(-)

Thanks,

Kim



From Ken.Fuchs at bench.com  Fri Apr 25 17:14:37 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 25 Apr 2008 10:14:37 -0500
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <4811A942.7010405@gandalf.sssup.it>
Message-ID: <AA28F077645B324881335614E4F7C428034CE7@win-ex01.bench.com>

Michael Trimarchi wrote:

> confirm that the problem is in fat.c file and I will try to fix.

It has been confirmed that fatls does _not_ list
all files on FAT32 filesystems.

There are _no_ reports of fatls failing to list
all files on FAT16 filesystems.  (There may be
an unrelated bug caused by all 512 directory
entries of FAT16 being used.)

What additional information is needed to confirm
that the problem is in fat.c?

What is your response to the debug log you requested?
It was sent to the ml almost 18 hours ago and is
also quoted below.

Sincerely,

Ken Fuchs

------

USB_STOR_DEBUG log:

Hit any key to stop autoboot:  0
U-Boot> usb reset
usb reset
(Re)start USB...
USB:   scanning bus for devices...
      USB device not responding, giving up (status=20)
3 USB Device(s) found
       scanning bus for storage devices... i=0
i=1


USB Mass Storage device detected
Transport: Bulk/Bulk/Bulk
Endpoints In 1 Out 2 Int 0
BBB_reset
BBB_reset result 0: status 0 reset
BBB_reset result 0: status 0 clearing IN endpoint
BBB_reset result 0: status 0 clearing OUT endpoint
BBB_reset done
 address 2
COMMAND phase
DATA phase
STATUS phase
inquiry returns 0
ISO Vers 2, Response Data 2
COMMAND phase
STATUS phase
FAILED
COMMAND phase
DATA phase
STATUS phase
Request Sense returned 06 28 00
COMMAND phase
STATUS phase
COMMAND phase
DATA phase
STATUS phase
Read Capacity returns: 0xe80300, 0x20000
Capacity = 0x3e801, blocksz = 0x200
 address 2
partype: 0

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk 0, blccnt 1 buffer 23edbbe4
read10: start 0 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 1, blccnt 1 buffer 23edbde4
partype: 2
i=2
i=3
1 Storage Device(s) found
U-Boot> fatls usb 0:1 /
fatls usb 0:1 /

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk 0, blccnt 1 buffer 23edbbc8
read10: start 0 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 1, blccnt 1 buffer 23edbdc8

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk 0, blccnt 1 buffer 23edb998
read10: start 0 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 1, blccnt 1 buffer 23edbb98

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk 20, blccnt 1 buffer 23eda540
read10: start 20 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk 21, blccnt 1 buffer 23eda740

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk fa2, blccnt 1 buffer 23f3ad78
read10: start fa2 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk fa3, blccnt 1 buffer 23f3af78
        9   00000000.txt
        9   11111111.txt
        9   22222222.txt
        9   33333333.txt
        9   44444444.txt
        9   55555555.txt
        9   66666666.txt
        9   77777777.txt

usb_read: dev 0
COMMAND phase
STATUS phase

usb_read: dev 0 startblk fa3, blccnt 1 buffer 23f3ad78
read10: start fa3 blocks 1
COMMAND phase
DATA phase
STATUS phase
usb_read: end startblk fa4, blccnt 1 buffer 23f3af78
        0   00000000.


9 file(s), 0 dir(s)

U-Boot> 



From kashiwagi at co-nss.co.jp  Fri Apr 25 17:14:12 2008
From: kashiwagi at co-nss.co.jp (Yoshio Kashiwagi)
Date: Sat, 26 Apr 2008 00:14:12 +0900
Subject: [U-Boot-Users] Xilinx PowerPC XPS_LL_TEMAC driver
In-Reply-To: <JF2008042518323445.35379812@co-nss.co.jp>
References: <JF2008042518323445.35379812@co-nss.co.jp>
Message-ID: <JT200804260014123.1442531@co-nss.co.jp>

Hi,

Although I included cache control in this source at the post at this
ML, I found the bug in cache control. I'll correct those bugs.
# However, this code is also checking normal operation by EDK10.1 design.

Best Regards,

Yoshio Kashiwagi - Nissin Systems

> Hi All,
> 
> I am writing XPS_LL_TEMAC for Xilinx PowerPC.
> Can anyone give me an advice on which I should correct this source?
> 
> Thanks in advance,
> 
> Yoshio Kashiwagi - Nissin Systems
> 
> /*
>  *
>  * xilinx_ll_temac.c ethernet driver for u-boot
>  *
>  * Author: Yoshio Kashiwagi kashiwagi at co-nss.co.jp
>  *
>  * Copyright (c) 2008 Nissin Systems Co.,Ltd.
>  *
>  * March 2008 created
>  *
>  * 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.
>  *
> */
> #include <config.h>
> #include <common.h>
> #include <net.h>
> #include <malloc.h>
> #include <asm/errno.h>
> #include <asm/processor.h>
> 
> #define S_DMA_CTRL_BASEADDR XPAR_LLTEMAC_0_LLINK_CONNECTED_BASEADDR
> #define XPS_LLTEMAC_BASEADDR    XPAR_LLTEMAC_0_BASEADDR
> 
> /* XPS_LL_TEMAC SDMA registers definition */
> 
> #define TX_NXTDESC_PTR      (S_DMA_CTRL_BASEADDR + 0x00)
> #define TX_CURBUF_ADDR      (S_DMA_CTRL_BASEADDR + 0x04)
> #define TX_CURBUF_LENGTH    (S_DMA_CTRL_BASEADDR + 0x08)
> #define TX_CURDESC_PTR      (S_DMA_CTRL_BASEADDR + 0x0c)
> #define TX_TAILDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x10)
> #define TX_CHNL_CTRL        (S_DMA_CTRL_BASEADDR + 0x14)
> #define TX_IRQ_REG      (S_DMA_CTRL_BASEADDR + 0x18)
> #define TX_CHNL_STS     (S_DMA_CTRL_BASEADDR + 0x1c)
> 
> #define RX_NXTDESC_PTR      (S_DMA_CTRL_BASEADDR + 0x20)
> #define RX_CURBUF_ADDR      (S_DMA_CTRL_BASEADDR + 0x24)
> #define RX_CURBUF_LENGTH    (S_DMA_CTRL_BASEADDR + 0x28)
> #define RX_CURDESC_PTR      (S_DMA_CTRL_BASEADDR + 0x2c)
> #define RX_TAILDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x30)
> #define RX_CHNL_CTRL        (S_DMA_CTRL_BASEADDR + 0x34)
> #define RX_IRQ_REG      (S_DMA_CTRL_BASEADDR + 0x38)
> #define RX_CHNL_STS     (S_DMA_CTRL_BASEADDR + 0x3c)
> 
> #define DMA_CONTROL_REG     (S_DMA_CTRL_BASEADDR + 0x40)
> 
> /* XPS_LL_TEMAC direct registers definition */
> 
> #define TEMAC_RAF0      (XPS_LLTEMAC_BASEADDR + 0x00)
> #define TEMAC_TPF0      (XPS_LLTEMAC_BASEADDR + 0x04)
> #define TEMAC_IFGP0     (XPS_LLTEMAC_BASEADDR + 0x08)
> #define TEMAC_IS0       (XPS_LLTEMAC_BASEADDR + 0x0c)
> #define TEMAC_IP0       (XPS_LLTEMAC_BASEADDR + 0x10)
> #define TEMAC_IE0       (XPS_LLTEMAC_BASEADDR + 0x14)
> 
> #define TEMAC_MSW0      (XPS_LLTEMAC_BASEADDR + 0x20)
> #define TEMAC_LSW0      (XPS_LLTEMAC_BASEADDR + 0x24)
> #define TEMAC_CTL0      (XPS_LLTEMAC_BASEADDR + 0x28)
> #define TEMAC_RDY0      (XPS_LLTEMAC_BASEADDR + 0x2c)
> 
> #define XTE_RSE_MIIM_RR_MASK      0x0002
> #define XTE_RSE_MIIM_WR_MASK      0x0004
> #define XTE_RSE_CFG_RR_MASK       0x0020
> #define XTE_RSE_CFG_WR_MASK       0x0040
> 
> /* XPS_LL_TEMAC indirect registers offset definition */
> 
> #define RCW0    0x200
> #define RCW1    0x240
> #define TC  0x280
> #define FCC 0x2c0
> #define EMMC    0x300
> #define PHYC    0x320
> #define MC  0x340
> #define UAW0    0x380
> #define UAW1    0x384
> #define MAW0    0x388
> #define MAW1    0x38c
> #define AFM 0x390
> #define TIS 0x3a0
> #define TIE 0x3a4
> #define MIIMWD  0x3b0
> #define MIIMAI  0x3b4
> 
> #define CNTLREG_WRITE_ENABLE_MASK   0x8000
> #define CNTLREG_EMAC1SEL_MASK       0x0400
> #define CNTLREG_ADDRESSCODE_MASK    0x03ff
> 
> #define MDIO_ENABLE_MASK    0x40
> #define MDIO_CLOCK_DIV_MASK 0x3F
> #define MDIO_CLOCK_DIV_100MHz   0x28
> 
> #define ETHER_MTU       1520
> #define CACHE_LINE_SIZE     32
> 
> /* SDMA descriptor status bit definitions */
> 
> #define BDSTAT_ERROR_MASK       0x80
> #define BDSTAT_INT_ON_END_MASK  0x40
> #define BDSTAT_STOP_ON_END_MASK 0x20
> #define BDSTAT_COMPLETED_MASK   0x10
> #define BDSTAT_SOP_MASK         0x08
> #define BDSTAT_EOP_MASK         0x04
> #define BDSTAT_CHANBUSY_MASK    0x02
> #define BDSTAT_CHANRESET_MASK   0x01
> 
> /* SDMA Buffer Descriptor */
> 
> typedef struct cdmac_bd_t {
>     struct cdmac_bd_t *next_p;
>     unsigned char *phys_buf_p;
>     unsigned long buf_len;
>     unsigned char stat;
>     unsigned char app1_1;
>     unsigned short app1_2;
>     unsigned long app2;
>     unsigned long app3;
>     unsigned long app4;
>     unsigned long app5;
> } cdmac_bd __attribute((aligned(32))) ;
> 
> static cdmac_bd tx_bd;
> static cdmac_bd rx_bd;
> static unsigned char tx_buffer[ETHER_MTU] __attribute((aligned(32)));
> static unsigned char rx_buffer[ETHER_MTU] __attribute((aligned(32)));
> 
> struct xps_ll_temac_private {
>     int idx;
>     unsigned char dev_addr[6];
> };
> 
> static void flush_dcache_range(unsigned int addr, unsigned size)
> {
>     unsigned int end = addr & ~(CACHE_LINE_SIZE - 1);
> 
>     if(size) {
>         while(addr < end) {
>             __asm__ __volatile__("dcbf 0,%0; sync;" : : "r" (addr));
>             addr += CACHE_LINE_SIZE;
>         }
>     }
> }
> 
> static void invalidate_dcache_range(unsigned int addr, unsigned size)
> {
>     unsigned int end = addr & ~(CACHE_LINE_SIZE - 1);
> 
>     if(size) {
>         while(addr < end) {
>             __asm__ __volatile__("dcbi 0,%0; sync;" : : "r" (addr));
>             addr += CACHE_LINE_SIZE;
>         }
>     }
> }
> 
> static unsigned int xps_ll_temac_hostif_get(int emac, int phy_addr, 
int 
> reg_addr)
> {
>     *(unsigned int *)TEMAC_LSW0 = phy_addr << 5 | reg_addr;
>     *(unsigned int *)TEMAC_CTL0 = MIIMAI | emac << 10;
> 
>     while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_MIIM_RR_
MASK)
> );
>     return *(unsigned int *)TEMAC_LSW0;
> }
> 
> static void xps_ll_temac_indirect_set(int emac, int reg_offset, int 
reg_
> data)
> {
>     *(unsigned int *)TEMAC_LSW0 = reg_data;
>     *(unsigned int *)TEMAC_CTL0 = CNTLREG_WRITE_ENABLE_MASK | emac << 
10 
> | reg_offset;
>     while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_CFG_WR_
MASK))
> ;
> }
> 
> static int xps_ll_temac_phy_ctrl(void)
> {
>     static int phy_addr = -1;
>     static int link = 0;
>     int i;
>     unsigned int result;
> 
>     if(phy_addr == -1) {
>         for(i = 0;i < 32;i++) {
>             result = xps_ll_temac_hostif_get(0, i, 1);
>             if((result & 0x0ffff) != 0x0ffff) {
>                 phy_addr = i;
>                 break;
>             }
>         }
>     } else {
>         result = xps_ll_temac_hostif_get(0, phy_addr, 1);
>     }
>     if((result & 0x24) != 0x24) {
>         if(link) {
>             link = 0;
>             printf("Link down\n");
>         }
>         return 0;
>     }
>     if(link == 0) {
>         link = 1;
>     } else {
>         return 1;
>     }
> 
>     result = xps_ll_temac_hostif_get(0, phy_addr, 10);
>     if((result & 0x0800) == 0x0800) {
>         xps_ll_temac_indirect_set(0, EMMC, 0x80000000);
>         printf("1000BASE-T/FD\n");
>         return 1;
>     }
>     result = xps_ll_temac_hostif_get(0, phy_addr, 5);
>     if((result & 0x0100) == 0x0100) {
>         xps_ll_temac_indirect_set(0, EMMC, 0x40000000);
>         printf("100BASE-T/FD\n");
>     } else if((result & 0x0040) == 0x0040) {
>         xps_ll_temac_indirect_set(0, EMMC, 0x00000000);
>         printf("10BASE-T/FD\n");
>     } else {
>         printf("Half Duplex not supported\n");
>     }
>     return 1;
> }
> 
> static void xps_ll_temac_bd_init(void)
> {
>     memset((void *)&tx_bd, 0, sizeof(cdmac_bd));
>     memset((void *)&rx_bd, 0, sizeof(cdmac_bd));
>     
>     rx_bd.phys_buf_p = &rx_buffer[0];
>     rx_bd.next_p = &rx_bd;
>     rx_bd.buf_len = ETHER_MTU;
>     flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
>     *(unsigned int *)RX_CURDESC_PTR = (unsigned int)&rx_bd;
>     *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;
> 
>     tx_bd.phys_buf_p = &tx_buffer[0];
>     tx_bd.next_p = &tx_bd;
>     flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
>     *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
> }
> 
> static int xps_ll_temac_send(unsigned char *buffer, int length)
> {
>     if(xps_ll_temac_phy_ctrl() == 0) return 0;
> 
>     memcpy(tx_buffer, buffer, length);
>     flush_dcache_range((unsigned int)tx_buffer, length);
> 
>     tx_bd.stat = BDSTAT_SOP_MASK | BDSTAT_EOP_MASK | BDSTAT_STOP_ON_
END_
> MASK;
>     tx_bd.buf_len = length;
>     flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
> 
>     *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
>     *(unsigned int *)TX_TAILDESC_PTR = (unsigned int)&tx_bd; /* DMA 
> start */
> 
>     do {
>         invalidate_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd))
;
>     } while(!((volatile int)tx_bd.stat & BDSTAT_COMPLETED_MASK));
> 
>     return length;
> }
> 
> static int xps_ll_temac_recv(void)
> {
>     int length;
> 
>     invalidate_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
>     if(!(rx_bd.stat & BDSTAT_COMPLETED_MASK)) return 0;
> 
>     length = rx_bd.app5;
>     invalidate_dcache_range((unsigned int)rx_bd.phys_buf_p, length);
> 
>     rx_bd.buf_len = ETHER_MTU;
>     rx_bd.stat = 0;
>     rx_bd.app5 = 0;
>     flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
>     *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;
> 
>     if(length > 0) {
>         NetReceive(rx_bd.phys_buf_p, length);
>     }
> 
>     return length;
> }
> 
> static int xps_ll_temac_addr_setup(struct xps_ll_temac_private * lp)
> {
>         char * env_p;
>         char * end;
>         int    i, val;
> 
>         env_p = getenv("ethaddr");
>         if (env_p == NULL) {
>                 printf("cannot get enviroment for \"ethaddr\".\n");
>                 return -1;
>         }
> 
>         for (i = 0; i < 6; i++) {
>                 lp->dev_addr[i] = env_p ? simple_strtoul(env_p, &end, 
16)
>  : 0;
>                 if (env_p) env_p = (*end) ? end + 1 : end;
>         }
> 
>         /* set up unicast MAC address filter */
>         val = lp->dev_addr[3] << 24 | lp->dev_addr[2] << 16 |
>                lp->dev_addr[1] <<  8 | lp->dev_addr[0];
>     xps_ll_temac_indirect_set(0, UAW0, val);
>         val = lp->dev_addr[5] << 8 |  lp->dev_addr[4];
>     xps_ll_temac_indirect_set(0, UAW1, val);
> 
>         return 0;
> }
> 
> static void xps_ll_temac_init(struct eth_device *dev, bd_t *bis)
> {
>     struct xps_ll_temac_private *lp = (struct xps_ll_temac_private *)
> dev->priv;
> 
>     xps_ll_temac_bd_init();
>     xps_ll_temac_indirect_set(0, MC, MDIO_ENABLE_MASK | MDIO_CLOCK_
DIV_
> 100MHz);
>     
>     xps_ll_temac_addr_setup(lp);
>     xps_ll_temac_indirect_set(0, AFM, 0x00000000);  /* Promiscuos mode 
> disable */
>     xps_ll_temac_indirect_set(0, RCW1, 0x10000000); /* Enable Receiver 
*
> /
>     xps_ll_temac_indirect_set(0, TC, 0x10000000);   /* Enable 
> Transmitter */
> 
> }
> 
> int eth_init(bd_t *bis)
> {
>     static int first = 1;
>     struct eth_device *dev;
>     struct xps_ll_temac_private *lp;
>     int i;
> 
>     if(!first) return 0;
>     first = 0;
>         dev = (struct eth_device *) calloc(1, sizeof(struct eth_device)
)
> ;
>         if (NULL == dev) return 0;
> 
>         lp = (struct xps_ll_temac_private *) calloc(1, sizeof(struct 
> xps_ll_temac_private));
>         if (lp == NULL) return 0;
>     dev->priv = lp;
>     sprintf(dev->name, "eth0");
> 
>     xps_ll_temac_init(dev, bis);
> 
>     printf("%s: Xilinx XPS LocalLink Tri-Mode Ether MAC #%d at 0x%08X.
\
> n",
>         dev->name, 0, XPS_LLTEMAC_BASEADDR);
> 
>     for(i = 0;i < 3;i++) {      
>         if(xps_ll_temac_phy_ctrl()) break;
>         udelay(10000);      /* wait second */
>     }
>     return 1;
> }
> 
> int eth_send(volatile void *packet, int length)
> {
>     return xps_ll_temac_send((unsigned char *)packet, length);
> }
> 
> int eth_rx(void)
> {
>     return xps_ll_temac_recv();
> }
> 
> void eth_halt(void)
> {
> }
> 
> 
> ----------------------------------------------------------------------
---
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100.
 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
? 4?1????????????
------------------------------------------------------------------
????
??????????? ??????

?      ? ?600-8482 ??????????????? ??????
TEL 075-344-7977 FAX 075-344-7887
????? ?101-0024 ????????????1?? ???????
TEL 03-5825-2081 FAX 03-5821-1259
E-Mail kashiwagi at co-nss.co.jp HTTP http://www.co-nss.co.jp/
------------------------------------------------------------------




From ayman at elkhashab.com  Fri Apr 25 17:26:40 2008
From: ayman at elkhashab.com (Ayman M. El-Khashab)
Date: Fri, 25 Apr 2008 10:26:40 -0500
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <200804251445.38814.sr@denx.de>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<200804250813.56303.sr@denx.de> <4811D15E.4080208@elkhashab.com>
	<200804251445.38814.sr@denx.de>
Message-ID: <20080425152640.GB4325@crust.elkhashab.com>


On Fri, Apr 25, 2008 at 02:45:38PM +0200, Stefan Roese wrote:
> 
> Good luck with this PCI booting stuff. Please keep us informed on the 
> progress.
> 

We'll contribute back what we find on this approach.  We won't be able
to try it until aug/sep since that is when the assembled boards will be
in house.

Thanks again



From dzu at denx.de  Fri Apr 25 17:26:36 2008
From: dzu at denx.de (Detlev Zundel)
Date: Fri, 25 Apr 2008 17:26:36 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <20080425144001.0cdb8f4e@peedub.jennejohn.org> (Gary Jennejohn's
	message of "Fri, 25 Apr 2008 14:40:01 +0200")
References: <20080423151258.7ac66064@peedub.jennejohn.org>
	<200804240827.20526.sr@denx.de>
	<20080425144001.0cdb8f4e@peedub.jennejohn.org>
Message-ID: <m2iqy6ymz7.fsf@ohwell.denx.de>

Hi Gary,

> On Thu, 24 Apr 2008 08:27:20 +0200
> Stefan Roese <sr at denx.de> wrote:
>
>> > +#define CONFIG_IPADDR		192.168.1.67
>> > +#define CONFIG_SERVERIP		192.168.1.50
>> > +#define CONFIG_GATEWAYIP	192.168.1.1
>> > +#define CONFIG_NETMASK		255.255.255.0
>> > +#define CONFIG_ETHADDR 		00:01:02:03:04:05
>> > +#define CONFIG_ETH1ADDR		00:01:02:03:04:06
>> 
>> Are you really sure that you want to provide default MAC-addresses? We usually 
>> don't do this.
>> 
>
> The customer had CONFIG_ETHADDR set in PPCBoot.  I added CONFIG_ETH1ADDR
> analog to that, since I have CONFIG_NET_MULTI defined in quad100hd.h.
>
> I personally don't care either way and have no problem with removing them.
> Don't know what the customer would have to say about that.

Mac addresses (not that those are worth of that title) should not go
into stock U-Boot source.  This only calls for lots of trouble as
discussed n+1 times.  The customer will have to assign correct addresses
anyway, so there is no reason to set a bad example in source others will
copy from.

Cheers
  Detlev

-- 
A GNU manual  should give a  good introduction to a beginner reading
through from the start, and should also provide all the details that
hackers want.                       --- GNU Coding Standards
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From lilja.magnus at gmail.com  Fri Apr 25 17:35:47 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Fri, 25 Apr 2008 17:35:47 +0200
Subject: [U-Boot-Users] [PATCH] i.MX31: Enable SPI and MC13783/RTC
	support for the Litekit board
In-Reply-To: <20080425071600.C807A24AB6@gemini.denx.de>
References: <480B00F4.6030406@gmail.com>
	<20080425071600.C807A24AB6@gemini.denx.de>
Message-ID: <59b21cf20804250835j348da9f2i2a24fd7dad84a9d3@mail.gmail.com>

On Fri, Apr 25, 2008 at 9:16 AM, Wolfgang Denk <wd at denx.de> wrote:
> In message <480B00F4.6030406 at gmail.com> you wrote:
>  > This patch enables SPI and MC13783/RTC support for the Litekit board.
>  >
>  > Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
>  > ---
>  >
>  >  board/imx31_litekit/imx31_litekit.c |   12 ++++++++++++
>  >  include/configs/imx31_litekit.h     |    8 ++++++++
>  >  2 files changed, 20 insertions(+), 0 deletions(-)
>
>  Does not apply:
>
>  Applying i.MX31: Enable SPI and MC13783/RTC support for the Litekit board
>  error: patch failed: board/imx31_litekit/imx31_litekit.c:52
>  error: board/imx31_litekit/imx31_litekit.c: patch does not apply
>  fatal: sha1 information is lacking or useless
>  (board/imx31_litekit/imx31_litekit.c).
>  Repository lacks necessary blobs to fall back on 3-way merge.
>  Cannot fall back to three-way merge.
>  Patch failed at 0001.
>
>
>  Please rebase and resubmit.

Wolfgang,


It applies nicely to your currently published U-Boot-tree (after the
refresh you did earlier today). So perhaps you could try again.


It was my fault it didn't apply earlier (the patch required that one
of my other patches had been applied), I'm still learning my way
around git/stgit and how things are merged.


Thanks, Magnus Lilja



From trimarchi at gandalf.sssup.it  Fri Apr 25 17:45:22 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Fri, 25 Apr 2008 17:45:22 +0200
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <AA28F077645B324881335614E4F7C428034CE7@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CE7@win-ex01.bench.com>
Message-ID: <4811FC92.4080401@gandalf.sssup.it>

Hi,
Ken.Fuchs at bench.com wrote:
> Michael Trimarchi wrote:
>
>   
>> confirm that the problem is in fat.c file and I will try to fix.
>>     
>
> It has been confirmed that fatls does _not_ list
> all files on FAT32 filesystems.
>
> There are _no_ reports of fatls failing to list
> all files on FAT16 filesystems.  (There may be
> an unrelated bug caused by all 512 directory
> entries of FAT16 being used.)
>
> What additional information is needed to confirm
> that the problem is in fat.c?
>
>   
The problem is related to how fat.c manage the root directory. As 
reported by
microsoft
in "FAT32, the root directory can be of variable size and is a cluster 
chain, just like any other directory is.
The first cluster of the root directory on a FAT32 volume is stored in 
BPB_RootClus. Unlike other directories,
the root directory itself on any FAT type does not have any date or time 
stamps, does not have a file name
(other than the implied file name ?\?), and does not contain ?.? and 
?..? files as the first two directory entries in the directory.
The only other special aspect of the root directory is that it is the 
only directory on the FAT volume for
which it is valid to have a file that has only the ATTR_VOLUME_ID 
attribute bit set (see below)."
> What is your response to the debug log you requested?
> It was sent to the ml almost 18 hours ago and is
> also quoted below.
>   
In my spare time a try to change the do_fat_read to support the chaining.

Regards Michael




From trimarchi at gandalf.sssup.it  Fri Apr 25 17:52:22 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Fri, 25 Apr 2008 17:52:22 +0200
Subject: [U-Boot-Users] ide arm support
Message-ID: <4811FE36.60101@gandalf.sssup.it>

Hi,

when do you have spare time can you give some feedback about arm ide patch?

Regards Michael




From niklausgiger at gmx.ch  Fri Apr 25 18:01:28 2008
From: niklausgiger at gmx.ch (Niklaus Giger)
Date: Fri, 25 Apr 2008 18:01:28 +0200
Subject: [U-Boot-Users] ppc4xx: Unable to clone git repository from denx
Message-ID: <200804251801.28858.niklausgiger@gmx.ch>

Hi

I wanted to get Stefan's git and got the following error:
> $ git clone http://www.denx.de/git/u-boot-ppc4xx.git/ work 
<...>
> Getting pack list for http://www.denx.de/u-boot.git/
> error: Unable to find f616ab96cc773d1719761d511a8649c9aa6eb473 under
> http://www.denx.de/git/u-boot-ppc4xx.git Cannot obtain needed blob
> f616ab96cc773d1719761d511a8649c9aa6eb473 while processing commit
> 60bbcad0e2e7007a36a1cb42c664b0662ae0c9f1.

It would be nice if this error could be fixed. But I will go home for the weekend
in a few minutes.

Best regards

Niklaus



From garyj at denx.de  Fri Apr 25 18:04:12 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Fri, 25 Apr 2008 18:04:12 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC 405EP-based
	board.
Message-ID: <20080425180412.1eee9b27@peedub.jennejohn.org>


Handle Stefan's comments.  This has the added benefit of making the
patch considerably smaller.

Signed-off-by: Gary Jennejohn <garyj at denx.de>
---
 MAINTAINERS                 |    4 +
 MAKEALL                     |    1 +
 Makefile                    |    3 +
 board/quad100hd/Makefile    |   51 ++++++++
 board/quad100hd/config.mk   |   24 ++++
 board/quad100hd/nand.c      |   79 +++++++++++
 board/quad100hd/quad100hd.c |   93 +++++++++++++
 board/quad100hd/u-boot.lds  |  133 +++++++++++++++++++
 include/configs/quad100hd.h |  299 +++++++++++++++++++++++++++++++++++++++++++
 9 files changed, 687 insertions(+), 0 deletions(-)
 create mode 100644 board/quad100hd/Makefile
 create mode 100644 board/quad100hd/config.mk
 create mode 100644 board/quad100hd/nand.c
 create mode 100644 board/quad100hd/quad100hd.c
 create mode 100644 board/quad100hd/u-boot.lds
 create mode 100644 include/configs/quad100hd.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d1782b4..3af55a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -204,6 +204,10 @@ Klaus Heydeck <heydeck at kieback-peter.de>
 	KUP4K			MPC855
 	KUP4X			MPC859
 
+Gary Jennejohn <garyj at denx.de>
+
+	quad100hd		PPC405EP
+
 Murray Jensen <Murray.Jensen at csiro.au>
 
 	cogent_mpc8xx		MPC8xx
diff --git a/MAKEALL b/MAKEALL
index 38911ed..471f6f7 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -218,6 +218,7 @@ LIST_4xx="		\
 	PMC405		\
 	PMC440		\
 	PPChameleonEVB	\
+	quad100hd	\
 	rainier		\
 	sbc405		\
 	sc3		\
diff --git a/Makefile b/Makefile
index 86e44d0..f49f114 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,9 @@ PPChameleonEVB_HI_33_config:	unconfig
 		}
 	@$(MKCONFIG) -a $(call xtract_4xx,$@) ppc ppc4xx PPChameleonEVB dave
 
+quad100hd_config:	unconfig
+	@$(MKCONFIG) $(@:_config=) ppc ppc4xx quad100hd
+
 sbc405_config:	unconfig
 	@$(MKCONFIG) $(@:_config=) ppc ppc4xx sbc405
 
diff --git a/board/quad100hd/Makefile b/board/quad100hd/Makefile
new file mode 100644
index 0000000..252ad5a
--- /dev/null
+++ b/board/quad100hd/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2007
+# Stefan Roese, DENX Software Engineering, sr at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).a
+
+COBJS	= $(BOARD).o nand.o
+SOBJS   =
+
+SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+SOBJS	:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB):	$(OBJS) $(SOBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+	rm -f $(SOBJS) $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/quad100hd/config.mk b/board/quad100hd/config.mk
new file mode 100644
index 0000000..71c0476
--- /dev/null
+++ b/board/quad100hd/config.mk
@@ -0,0 +1,24 @@
+#
+# (C) Copyright 2000
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+TEXT_BASE = 0xFFF80000
diff --git a/board/quad100hd/nand.c b/board/quad100hd/nand.c
new file mode 100644
index 0000000..86d5cc3
--- /dev/null
+++ b/board/quad100hd/nand.c
@@ -0,0 +1,79 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <config.h>
+#if defined(CONFIG_CMD_NAND)
+#include <asm/gpio.h>
+#include <nand.h>
+
+/* 
+ *	hardware specific access to control-lines
+ */
+static void quad100hd_hwcontrol(struct mtd_info *mtd, int cmd)
+{
+	switch(cmd) {
+	case NAND_CTL_SETCLE:
+		gpio_write_bit(CFG_NAND_CLE, 1);
+		break;
+	case NAND_CTL_CLRCLE:
+		gpio_write_bit(CFG_NAND_CLE, 0);
+		break;
+
+	case NAND_CTL_SETALE:
+		gpio_write_bit(CFG_NAND_ALE, 1);
+		break;
+	case NAND_CTL_CLRALE:
+		gpio_write_bit(CFG_NAND_ALE, 0);
+		break;
+
+	case NAND_CTL_SETNCE:
+		gpio_write_bit(CFG_NAND_CE, 0);
+		break;
+	case NAND_CTL_CLRNCE:
+		gpio_write_bit(CFG_NAND_CE, 1);
+		break;
+	}
+}
+
+static int quad100hd_nand_ready(struct mtd_info *mtd)
+{
+	return gpio_read_in_bit(CFG_NAND_RDY);
+}
+
+/*
+ * Main initialization routine
+ */
+int board_nand_init(struct nand_chip *nand)
+{
+	/* Set address of hardware control function */
+	nand->hwcontrol = quad100hd_hwcontrol;
+	nand->dev_ready = quad100hd_nand_ready;
+	nand->eccmode = NAND_ECC_SOFT;
+	/* 15 us command delay time */
+	nand->chip_delay =  20;
+
+	/* Return happy */
+	return 0;
+}
+#endif /* CONFIG_CMD_NAND */
diff --git a/board/quad100hd/quad100hd.c b/board/quad100hd/quad100hd.c
new file mode 100644
index 0000000..52cceee
--- /dev/null
+++ b/board/quad100hd/quad100hd.c
@@ -0,0 +1,93 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
+ *
+ * Based in part on board/icecube/icecube.c from PPCBoot
+ * (C) Copyright 2003 Intrinsyc Software
+ *
+ * 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 <common.h>
+#include <command.h>
+#include <malloc.h>
+#include <environment.h>
+#include <logbuff.h>
+#include <post.h>
+
+#include <asm/processor.h>
+#include <asm/io.h>
+#include <asm/gpio.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_early_init_f(void)
+{
+	/* taken from PPCBoot */
+	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
+	mtdcr(uicer, 0x00000000);	/* disable all ints */
+	mtdcr(uiccr, 0x00000000);
+	mtdcr(uicpr, 0xFFFF7FFE);	/* set int polarities */
+	mtdcr(uictr, 0x00000000);	/* set int trigger levels */
+	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
+	mtdcr(uicvcr, 0x00000001);	/* set vect base=0,INT0 highest priority */
+
+    	mtdcr (CPC0_SRR, 0x00040000);   /* Hold PCI bridge in reset */
+
+	return 0;
+}
+
+/*
+ * Check Board Identity:
+ */
+int checkboard(void)
+{
+	char *s = getenv("serial#");
+#ifdef DISPLAY_BOARD_INFO
+	sys_info_t sysinfo;
+#endif
+
+	puts("Board: Quad100hd");
+
+	if (s != NULL) {
+		puts(", serial# ");
+		puts(s);
+	}
+	putc('\n');
+
+#ifdef DISPLAY_BOARD_INFO
+	/* taken from ppcboot */
+	get_sys_info (&sysinfo);
+
+	printf("\tVCO: %lu MHz\n", sysinfo.freqVCOMhz);
+	printf("\tCPU: %lu MHz\n", sysinfo.freqProcessor / 1000000);
+	printf("\tPLB: %lu MHz\n", sysinfo.freqPLB / 1000000);
+	printf("\tOPB: %lu MHz\n", sysinfo.freqOPB / 1000000);
+	printf("\tEPB: %lu MHz\n", sysinfo.freqPLB / (sysinfo.pllExtBusDiv *
+		1000000));
+	printf ("\tPCI: %lu MHz\n", sysinfo.freqPCI / 1000000);
+#endif
+
+	return (0);
+}
+
+long int initdram(int board_type)
+{
+	return (CFG_SDRAM_SIZE);
+}
diff --git a/board/quad100hd/u-boot.lds b/board/quad100hd/u-boot.lds
new file mode 100644
index 0000000..195d91b
--- /dev/null
+++ b/board/quad100hd/u-boot.lds
@@ -0,0 +1,133 @@
+/*
+ * (C) Copyright 2000
+ * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+OUTPUT_ARCH(powerpc)
+SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/local/powerpc-any-elf/lib);
+/* Do we need any of these for elf?
+   __DYNAMIC = 0;    */
+SECTIONS
+{
+  .resetvec 0xFFFFFFFC :
+  {
+    *(.resetvec)
+  } = 0xffff
+
+  /* Read-only sections, merged into text segment: */
+  . = + SIZEOF_HEADERS;
+  .interp : { *(.interp) }
+  .hash          : { *(.hash)		}
+  .dynsym        : { *(.dynsym)		}
+  .dynstr        : { *(.dynstr)		}
+  .rel.text      : { *(.rel.text)		}
+  .rela.text     : { *(.rela.text) 	}
+  .rel.data      : { *(.rel.data)		}
+  .rela.data     : { *(.rela.data) 	}
+  .rel.rodata    : { *(.rel.rodata) 	}
+  .rela.rodata   : { *(.rela.rodata) 	}
+  .rel.got       : { *(.rel.got)		}
+  .rela.got      : { *(.rela.got)		}
+  .rel.ctors     : { *(.rel.ctors)	}
+  .rela.ctors    : { *(.rela.ctors)	}
+  .rel.dtors     : { *(.rel.dtors)	}
+  .rela.dtors    : { *(.rela.dtors)	}
+  .rel.bss       : { *(.rel.bss)		}
+  .rela.bss      : { *(.rela.bss)		}
+  .rel.plt       : { *(.rel.plt)		}
+  .rela.plt      : { *(.rela.plt)		}
+  .init          : { *(.init)	}
+  .plt : { *(.plt) }
+  .text      :
+  {
+    cpu/ppc4xx/start.o	(.text)
+
+    *(.text)
+    *(.fixup)
+    *(.got1)
+  }
+  _etext = .;
+  PROVIDE (etext = .);
+  .rodata    :
+  {
+    *(.rodata)
+    *(.rodata1)
+    *(.rodata.str1.4)
+  }
+  .fini      : { *(.fini)    } =0
+  .ctors     : { *(.ctors)   }
+  .dtors     : { *(.dtors)   }
+
+  /* Read-write section, merged into data segment: */
+  . = (. + 0x00FF) & 0xFFFFFF00;
+  _erotext = .;
+  PROVIDE (erotext = .);
+  .reloc   :
+  {
+    *(.got)
+    _GOT2_TABLE_ = .;
+    *(.got2)
+    _FIXUP_TABLE_ = .;
+    *(.fixup)
+  }
+  __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >>2;
+  __fixup_entries = (. - _FIXUP_TABLE_)>>2;
+
+  .data    :
+  {
+    *(.data)
+    *(.data1)
+    *(.sdata)
+    *(.sdata2)
+    *(.dynamic)
+    CONSTRUCTORS
+  }
+  _edata  =  .;
+  PROVIDE (edata = .);
+
+  . = .;
+  __u_boot_cmd_start = .;
+  .u_boot_cmd : { *(.u_boot_cmd) }
+  __u_boot_cmd_end = .;
+
+  . = .;
+  __start___ex_table = .;
+  __ex_table : { *(__ex_table) }
+  __stop___ex_table = .;
+
+  . = ALIGN(256);
+  __init_begin = .;
+  .text.init : { *(.text.init) }
+  .data.init : { *(.data.init) }
+  . = ALIGN(256);
+  __init_end = .;
+
+  __bss_start = .;
+  .bss (NOLOAD)       :
+  {
+   *(.sbss) *(.scommon)
+   *(.dynbss)
+   *(.bss)
+   *(COMMON)
+  }
+  _end = . ;
+  PROVIDE (end = .);
+}
diff --git a/include/configs/quad100hd.h b/include/configs/quad100hd.h
new file mode 100644
index 0000000..89504fd
--- /dev/null
+++ b/include/configs/quad100hd.h
@@ -0,0 +1,299 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/************************************************************************
+ * quad100hd.h - configuration for Quad100hd board
+ ***********************************************************************/
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*-----------------------------------------------------------------------
+ * High Level Configuration Options
+ *----------------------------------------------------------------------*/
+#define CONFIG_QUAD100HD	1		/* Board is Quad100hd	*/
+#define CONFIG_4xx		1		/* ... PPC4xx family	*/
+#define CONFIG_405EP		1		/* Specifc 405EP support*/
+
+#define CONFIG_SYS_CLK_FREQ     33333333 /* external frequency to pll   */
+
+#define CONFIG_BOARD_EARLY_INIT_F 1		/* Call board_early_init_f */
+
+#define PLLMR0_DEFAULT		PLLMR0_266_133_66 /* no PCI */
+#define PLLMR1_DEFAULT		PLLMR1_266_133_66 /* no PCI */
+
+#define CFG_ENV_IS_IN_EEPROM    1   /* use the EEPROM for environment vars */
+
+#define CONFIG_OVERWRITE_ETHADDR_ONCE	1
+
+#define CONFIG_NET_MULTI	1
+#define CONFIG_HAS_ETH1		1
+#define CONFIG_MII		1	/* MII PHY management		*/
+#define CONFIG_PHY_ADDR		0x01	/* PHY address			*/
+#define CFG_RX_ETH_BUFFER	16	/* Number of ethernet rx buffers & descriptors */
+#define CONFIG_PHY_RESET	1
+#define CONFIG_PHY_RESET_DELAY	300	/* PHY RESET recovery delay	*/
+
+/*
+ * Command line configuration.
+ */
+#include <config_cmd_default.h>
+
+#undef CONFIG_CMD_ASKENV
+#undef CONFIG_CMD_CACHE
+#define CONFIG_CMD_DHCP
+#undef CONFIG_CMD_DIAG
+#define CONFIG_CMD_EEPROM
+#undef CONFIG_CMD_ELF
+#define CONFIG_CMD_I2C
+#undef CONFIG_CMD_IRQ
+#define CONFIG_CMD_JFFS2
+#undef CONFIG_CMD_LOG
+#undef CONFIG_CMD_MII
+#define CONFIG_CMD_NAND
+#undef CONFIG_CMD_PING
+#define CONFIG_CMD_REGINFO
+
+#undef CONFIG_WATCHDOG			/* watchdog disabled		*/
+
+/*-----------------------------------------------------------------------
+ * SDRAM
+ *----------------------------------------------------------------------*/
+/*
+ * SDRAM configuration (please see cpu/ppc/sdram.[ch])
+ */
+#define CONFIG_SDRAM_BANK0  1
+#define CFG_SDRAM_SIZE      0x02000000      /* 32 MB */
+
+/* FIX! SDRAM timings used in datasheet */
+#define CFG_SDRAM_CL            3       /* CAS latency */
+#define CFG_SDRAM_tRP           20      /* PRECHARGE command period */
+#define CFG_SDRAM_tRC           66      /* ACTIVE-to-ACTIVE command period */
+#define CFG_SDRAM_tRCD          20      /* ACTIVE-to-READ delay */
+#define CFG_SDRAM_tRFC          66      /* Auto refresh period */
+
+/* 
+ * JFFS2
+ */
+#define CFG_JFFS2_FIRST_BANK    0
+#ifdef  CFG_KERNEL_IN_JFFS2
+#define CFG_JFFS2_FIRST_SECTOR  0   /* JFFS starts at block 0 */
+#else /* kernel not in JFFS */
+#define CFG_JFFS2_FIRST_SECTOR  8   /* block 0-7 is kernel (1MB = 8 sectors) */
+#endif
+#define CFG_JFFS2_NUM_BANKS     1
+
+/*-----------------------------------------------------------------------
+ * Serial Port
+ *----------------------------------------------------------------------*/
+#undef	CFG_EXT_SERIAL_CLOCK			/* external serial clock */
+#define CFG_BASE_BAUD		691200
+#define CONFIG_BAUDRATE		115200
+#define CONFIG_SERIAL_MULTI
+
+/* The following table includes the supported baudrates */
+#define CFG_BAUDRATE_TABLE	\
+	{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
+
+/*-----------------------------------------------------------------------
+ * Miscellaneous configurable options
+ *----------------------------------------------------------------------*/
+#define CFG_LONGHELP			/* undef to save memory		*/
+#define CFG_PROMPT	        "=> "	/* Monitor Command Prompt	*/
+#if defined(CONFIG_CMD_KGDB)
+#define CFG_CBSIZE	        1024	/* Console I/O Buffer Size	*/
+#else
+#define CFG_CBSIZE	        256	/* Console I/O Buffer Size	*/
+#endif
+#define CFG_PBSIZE              (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /* Print Buffer Size */
+#define CFG_MAXARGS	        16	/* max number of command args	*/
+#define CFG_BARGSIZE	        CFG_CBSIZE /* Boot Argument Buffer Size	*/
+
+#define CFG_MEMTEST_START	0x0400000 /* memtest works on		*/
+#define CFG_MEMTEST_END		0x0C00000 /* 4 ... 12 MB in DRAM	*/
+
+#define CFG_LOAD_ADDR		0x100000  /* default load address	*/
+#define CFG_EXTBDINFO		1	/* To use extended board_info (bd_t) */
+
+#define CFG_HZ		        1000	/* decrementer freq: 1 ms ticks	*/
+
+#define CONFIG_LOADS_ECHO	1	/* echo on for serial download	*/
+#define CFG_LOADS_BAUD_CHANGE	1	/* allow baudrate change	*/
+
+#define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
+#define CONFIG_LOOPW            1       /* enable loopw command         */
+#define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands      */
+#define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0 */
+#define CONFIG_VERSION_VARIABLE 1	/* include version env variable */
+
+/*-----------------------------------------------------------------------
+ * I2C
+ *----------------------------------------------------------------------*/
+#define CONFIG_HARD_I2C		1		/* I2C with hardware support	*/
+#undef	CONFIG_SOFT_I2C				/* I2C bit-banged		*/
+#define CFG_I2C_SPEED		400000		/* I2C speed and slave address	*/
+#define CFG_I2C_SLAVE		0x7F
+
+#define CFG_I2C_EEPROM_ADDR	0x50		/* base address */
+#define CFG_I2C_EEPROM_ADDR_LEN	2		/* bytes of address */
+
+#define CFG_EEPROM_PAGE_WRITE_BITS	5	/* 8 byte write page size */
+#define CFG_EEPROM_PAGE_WRITE_DELAY_MS	10	/* and takes up to 10 msec */
+#define CFG_EEPROM_SIZE			0x2000	
+
+/*-----------------------------------------------------------------------
+ * Start addresses for the final memory configuration
+ * (Set up by the startup code)
+ * Please note that CFG_SDRAM_BASE _must_ start at 0
+ */
+#define CFG_SDRAM_BASE		0x00000000
+#define CFG_FLASH_BASE		0xFFC00000
+#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Monitor	*/
+#define CFG_MALLOC_LEN		(128 * 1024)	/* Reserve 128 kB for malloc()	*/
+#define CFG_MONITOR_BASE	0xFFF80000
+
+/*
+ * For booting Linux, the board info and command line data
+ * have to be in the first 8 MB of memory, since this is
+ * the maximum mapped by the Linux kernel during initialization.
+ */
+#define CFG_BOOTMAPSZ		(8 << 20)	/* Initial Memory map for Linux */
+
+/*-----------------------------------------------------------------------
+ * FLASH organization
+ */
+#define CFG_FLASH_CFI			/* The flash is CFI compatible	*/
+#define	CFG_FLASH_CFI_DRIVER
+
+#define CFG_FLASH_BANKS_LIST	{ CFG_FLASH_BASE }
+
+#define CFG_MAX_FLASH_BANKS	1	/* max number of memory banks	*/
+#define CFG_MAX_FLASH_SECT	128	/* max number of sectors on one chip */
+#define CFG_FLASH_WORD_SIZE	unsigned short
+#define CFG_FLASH_ADDR0		0x0555
+#define CFG_FLASH_ADDR1		0x02aa
+#define FLASH_BASE0_PRELIM	CFG_FLASH_BASE	/* FLASH bank #0	*/
+
+#define CFG_FLASH_ERASE_TOUT	120000	/* Timeout for Flash Erase (in ms) */
+#define CFG_FLASH_WRITE_TOUT	500	/* Timeout for Flash Write (in ms) */
+
+#define CFG_FLASH_USE_BUFFER_WRITE 1	/* use buffered writes (20x faster) */
+#define CFG_FLASH_INCREMENT      0       /* there is only one bank         */
+
+#define CFG_FLASH_EMPTY_INFO		/* print 'E' for empty sector on flinfo */
+#define CFG_FLASH_QUIET_TEST	1	/* don't warn upon unknown flash */
+
+#ifdef CFG_ENV_IS_IN_FLASH
+#define CFG_ENV_SECT_SIZE	0x10000	/* size of one complete sector	*/
+#define	CFG_ENV_SIZE		0x10000	/* Total Size of Environment Sector */
+#define CFG_ENV_OFFSET		0x00050000 /* Offset of Environment Sector  */
+#define CFG_ENV_ADDR		(CFG_FLASH_BASE + CFG_ENV_OFFSET)
+#endif
+
+#ifdef CFG_ENV_IS_IN_EEPROM
+#define CFG_ENV_SIZE		0x400		/* Size of Environment vars */
+#define CFG_ENV_OFFSET		0x00000000
+#define CFG_ENABLE_CRC_16	1       /* Intrinsyc formatting used crc16 */
+#endif
+
+/* partly from PPCBoot */
+/* NAND */
+#define CONFIG_NAND
+#ifdef CONFIG_NAND
+#define CFG_NAND_BASE   0x60000000
+#define CFG_NAND_CS	10   /* our CS is GPIO10 */
+#define CFG_NAND_RDY	23   /* our RDY is GPIO23 */
+#define CFG_NAND_CE	24   /* our CE is GPIO24  */
+#define CFG_NAND_CLE	31   /* our CLE is GPIO31 */
+#define CFG_NAND_ALE	30   /* our ALE is GPIO30 */
+#define NAND_MAX_CHIPS	1
+#define CFG_MAX_NAND_DEVICE	1
+#endif
+
+/*-----------------------------------------------------------------------
+ * Definitions for initial stack pointer and data area (in data cache)
+ */
+/* use on chip memory (OCM) for temperary stack until sdram is tested */
+/* see ./cpu/ppc4xx/start.S */
+#define CFG_TEMP_STACK_OCM	1
+
+/* On Chip Memory location */
+#define CFG_OCM_DATA_ADDR	0xF8000000
+#define CFG_OCM_DATA_SIZE	0x1000
+#define CFG_INIT_RAM_ADDR	CFG_OCM_DATA_ADDR /* inside of OCM		*/
+#define CFG_INIT_RAM_END	CFG_OCM_DATA_SIZE /* End of used area in RAM	*/
+
+#define CFG_GBL_DATA_SIZE	128  /* size in bytes reserved for initial data */
+#define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
+#define CFG_INIT_SP_OFFSET      CFG_GBL_DATA_OFFSET
+
+/*-----------------------------------------------------------------------
+ * External Bus Controller (EBC) Setup
+ * Taken from PPCBoot board/icecube/icecube.h
+ */
+
+/* see ./cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/ndfc.c */
+#define CFG_EBC_PB0AP		0x04002480
+/* AMD NOR flash - this corresponds to FLASH_BASE so may be correct */
+#define CFG_EBC_PB0CR		0xFFC5A000
+#define CFG_EBC_PB1AP           0x04005480
+#define CFG_EBC_PB1CR           0x60018000
+#define CFG_EBC_PB2AP           0x00000000
+#define CFG_EBC_PB2CR           0x00000000
+#define CFG_EBC_PB3AP           0x00000000
+#define CFG_EBC_PB3CR           0x00000000
+#define CFG_EBC_PB4AP           0x00000000
+#define CFG_EBC_PB4CR           0x00000000
+
+/*-----------------------------------------------------------------------
+ * Definitions for GPIO setup (PPC405EP specific)
+ *
+ * Taken in part from PPCBoot board/icecube/icecube.h
+ */
+/* see ./cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/start.S */
+#define CFG_GPIO0_OSRH		0x55555550
+#define CFG_GPIO0_OSRL		0x00000110
+#define CFG_GPIO0_ISR1H		0x00000000
+#define CFG_GPIO0_ISR1L		0x15555445
+#define CFG_GPIO0_TSRH		0x00000000
+#define CFG_GPIO0_TSRL		0x00000000
+#define CFG_GPIO0_TCR		0xFFFF8097
+#define CFG_GPIO0_ODR		0x00000000
+
+#if defined(CONFIG_CMD_KGDB)
+#define CONFIG_KGDB_BAUDRATE	230400		/* speed to run kgdb serial port */
+#define CONFIG_KGDB_SER_INDEX	2		/* which serial port to use */
+#endif
+
+/* ENVIRONMENT VARS */
+
+#define CONFIG_IPADDR		192.168.1.67
+#define CONFIG_SERVERIP		192.168.1.50
+#define CONFIG_GATEWAYIP	192.168.1.1
+#define CONFIG_NETMASK		255.255.255.0
+#define CONFIG_LOADADDR		300000
+#define CONFIG_BOOTDELAY	5	/* autoboot after 5 seconds */
+
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT	1
+
+#endif	/* __CONFIG_H */
-- 
1.5.5


---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From dwh at ovro.caltech.edu  Fri Apr 25 18:25:46 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Fri, 25 Apr 2008 09:25:46 -0700
Subject: [U-Boot-Users] pci memory booting on ppc460
In-Reply-To: <200804250801.16466.sr@denx.de>
References: <20080422205307.B644E24AB5@gemini.denx.de>
	<4810AD11.3010307@ovro.caltech.edu>
	<4810B2A3.8020208@ovro.caltech.edu> <200804250801.16466.sr@denx.de>
Message-ID: <4812060A.9060602@ovro.caltech.edu>

Hi Stefan,

>> There does not appear to be a 460EX User's Manual on
>> the AMCC web site. Anyone know where to get it?
>> I created an account just in case it was not visible
>> to guests, but no change.
> 
> It's still preliminary, so you probably need to contact
> your AMCC distributor/FAE to get access to it.

It sounds like Ame has things under control, so
I won't try getting the manual.

Ame, good luck with your board bring-up.

If your hardware guys are still working on the board,
make sure they connect all the JTAG connections on those
processors!

Thanks,
Dave



From nettihw1954 at ALLELECTRICSUPPLY.COM  Fri Apr 25 18:58:18 2008
From: nettihw1954 at ALLELECTRICSUPPLY.COM (Mona)
Date: Fri, 25 Apr 2008 18:58:18 +0200
Subject: [U-Boot-Users] Buy today and receive it next week
Message-ID: <5718B01F.C%nettihw1954@ALLELECTRICSUPPLY.COM>

New and improved, herbal forumlas guaranteed to work or your money back http://www.laaleu.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080425/3d12a2c4/attachment.htm 

From dzu at denx.de  Fri Apr 25 19:19:46 2008
From: dzu at denx.de (Detlev Zundel)
Date: Fri, 25 Apr 2008 19:19:46 +0200
Subject: [U-Boot-Users] ppc4xx: Unable to clone git repository from denx
In-Reply-To: <200804251801.28858.niklausgiger@gmx.ch> (Niklaus Giger's message
	of "Fri, 25 Apr 2008 18:01:28 +0200")
References: <200804251801.28858.niklausgiger@gmx.ch>
Message-ID: <m263u5zwb1.fsf@ohwell.denx.de>

Hi Niklaus,

> Hi
>
> I wanted to get Stefan's git and got the following error:
>> $ git clone http://www.denx.de/git/u-boot-ppc4xx.git/ work 
> <...>
>> Getting pack list for http://www.denx.de/u-boot.git/
>> error: Unable to find f616ab96cc773d1719761d511a8649c9aa6eb473 under
>> http://www.denx.de/git/u-boot-ppc4xx.git Cannot obtain needed blob
>> f616ab96cc773d1719761d511a8649c9aa6eb473 while processing commit
>> 60bbcad0e2e7007a36a1cb42c664b0662ae0c9f1.
>
> It would be nice if this error could be fixed. But I will go home for the weekend
> in a few minutes.

Hm.  It seems like its not easy to transparently support both
www.denx.de and git.denx.de accesses over http.

Please try

git clone http://git.denx.de/u-boot-ppc4xx

This works for me.  I'll see what I can do to support the old URL.

Cheers and have a nice weekend
  Detlev

-- 
Helena ist verh?ltnism??ig leicht zu besetzen.  Eine Frau, zarteste Jugend
mit sinnlicher Reife verbindend;  ?u?erst intelligent,  indes von durchaus
weiblicher Denkart; phlegmatisch, aber sensibel; un?bertrefflich sch?n und
dabei von sehr pers?nlichem Charme - mehr wird da nicht verlangt.
                                               -- Peter Hacks
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

-- 
``The number of UNIX installations has grown to 10,
with more expected.''     Unix Programmers Manual -- 1972
The number of UNIX variants has grown to dozens,
with more expected.                               -- 2001
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From brjerome.1 at gmail.com  Fri Apr 25 19:48:38 2008
From: brjerome.1 at gmail.com (Norman)
Date: Fri, 25 Apr 2008 17:48:38 +0000 (UTC)
Subject: [U-Boot-Users] bootargs for partitioned nand flash
References: <OF59F26445.61F7D04D-ON48257125.002C708D-48257125.002CF471@applera.com>
	<20060302092625.9A01C3535EA@atlas.denx.de>
Message-ID: <loom.20080425T174055-651@post.gmane.org>

Wolfgang Denk <wd <at> denx.de> writes:

> 
> In message <OF59F26445.61F7D04D-ON48257125.002C708D-48257125.002CF471 <at>
applera.com> you wrote:

> 
> Also note that a cramfs may fail  to  work  in  case  there  are  bad
> sectors in your NAND device.
> 

Wolfgang, this might be an off topic here.  I have a client requirement to have
a  RFS like cramfs or squashfs on NAND.  If I use the u-boot nand write command
to write the cramfs to a MTD partition.  How does nand write treat a bad block?
 I am thinking that if nand write skip to the next block, then I might be able
to modify nand read...  Or is there a better way?

Thanks,
Norman




From adrian.filipi at eurotech.com  Fri Apr 25 19:16:09 2008
From: adrian.filipi at eurotech.com (Adrian Filipi)
Date: Fri, 25 Apr 2008 13:16:09 -0400 (EDT)
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <4811FC92.4080401@gandalf.sssup.it>
References: <AA28F077645B324881335614E4F7C428034CE7@win-ex01.bench.com>
	<4811FC92.4080401@gandalf.sssup.it>
Message-ID: <alpine.DEB.1.10.0804251308480.12475@pmy.adscville>


 	It looks like fat.c is not handling the case where the 
sectors/cluster is 1, and the rood directory spans multiple clusters.

 	In my case I was getting garbage directoy info after the invalid 
fat error.  The attached patch stops the code from rolling past the end of 
cluster.

 	It looks like a loop to walk the allocation chain is neccessary. 
I think get_contents() does all the right work, but it of course starts 
with a directory entry, which we don't have yet for /.  A little 
refactoring might do the trick.

 	Adrian
--
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com

On Fri, 25 Apr 2008, michael wrote:

> Hi,
> Ken.Fuchs at bench.com wrote:
>> Michael Trimarchi wrote:
>>
>> 
>>> confirm that the problem is in fat.c file and I will try to fix.
>>> 
>> 
>> It has been confirmed that fatls does _not_ list
>> all files on FAT32 filesystems.
>> 
>> There are _no_ reports of fatls failing to list
>> all files on FAT16 filesystems.  (There may be
>> an unrelated bug caused by all 512 directory
>> entries of FAT16 being used.)
>> 
>> What additional information is needed to confirm
>> that the problem is in fat.c?
>>
>> 
> The problem is related to how fat.c manage the root directory. As reported by
> microsoft
> in "FAT32, the root directory can be of variable size and is a cluster chain, 
> just like any other directory is.
> The first cluster of the root directory on a FAT32 volume is stored in 
> BPB_RootClus. Unlike other directories,
> the root directory itself on any FAT type does not have any date or time 
> stamps, does not have a file name
> (other than the implied file name ?\?), and does not contain ?.? and ?..? 
> files as the first two directory entries in the directory.
> The only other special aspect of the root directory is that it is the only 
> directory on the FAT volume for
> which it is valid to have a file that has only the ATTR_VOLUME_ID attribute 
> bit set (see below)."
>> What is your response to the debug log you requested?
>> It was sent to the ml almost 18 hours ago and is
>> also quoted below.
>> 
> In my spare time a try to change the do_fat_read to support the chaining.
>
> Regards Michael
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fat.c.diff
Type: text/x-diff
Size: 1090 bytes
Desc: 
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080425/b9877796/attachment.diff 

From Ken.Fuchs at bench.com  Fri Apr 25 20:16:52 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 25 Apr 2008 13:16:52 -0500
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <4811FC92.4080401@gandalf.sssup.it>
Message-ID: <AA28F077645B324881335614E4F7C428034CE8@win-ex01.bench.com>

Michael Trimarchi wrote:

> In my spare time a try to change the do_fat_read to support 
> the chaining.

Thank you.  Please let me know of anything I can do to help.

Does this mean you are now able to duplicate the problem?

The "Microsoft Extensible Firmware Initiative FAT32 File System
Specification" white paper you quoted seems like a good reference
document for FAT32.  Is there anything better?

BTW, in working with partitions <= 32MB, I have used FAT12,
but fs/fat/fat.c clearly doesn't support FAT12 properly.
FAT12 can be useful for NOR flash devices which are often
small enough for all four primary partitions to be <= 32MB.
Is anyone else (trying to) use FAT12 via U-Boot?
My work-around for this problem has simply been force
partitions <= 32MB to contain FAT16 whenever U-Boot needs
to read file from them.

Sincerely,

Ken Fuchs

> -----Original Message-----
> From: michael [mailto:trimarchi at gandalf.sssup.it] 
> Sent: Friday, April 25, 2008 10:45
> To: Fuchs, Ken
> Cc: afilipi at applieddata.net; u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] FW: USB SUPPORT & get_vfatname
> 
> 
> Hi,
> Ken.Fuchs at bench.com wrote:
> > Michael Trimarchi wrote:
> >
> >   
> >> confirm that the problem is in fat.c file and I will try to fix.
> >>     
> >
> > It has been confirmed that fatls does _not_ list
> > all files on FAT32 filesystems.
> >
> > There are _no_ reports of fatls failing to list
> > all files on FAT16 filesystems.  (There may be
> > an unrelated bug caused by all 512 directory
> > entries of FAT16 being used.)
> >
> > What additional information is needed to confirm
> > that the problem is in fat.c?
> >
> >   
> The problem is related to how fat.c manage the root directory. As 
> reported by
> microsoft
> in "FAT32, the root directory can be of variable size and is 
> a cluster 
> chain, just like any other directory is.
> The first cluster of the root directory on a FAT32 volume is 
> stored in 
> BPB_RootClus. Unlike other directories,
> the root directory itself on any FAT type does not have any 
> date or time 
> stamps, does not have a file name
> (other than the implied file name "\"), and does not contain "." and 
> ".." files as the first two directory entries in the directory.
> The only other special aspect of the root directory is that it is the 
> only directory on the FAT volume for
> which it is valid to have a file that has only the ATTR_VOLUME_ID 
> attribute bit set (see below)."
> > What is your response to the debug log you requested?
> > It was sent to the ml almost 18 hours ago and is
> > also quoted below.
> >   
> In my spare time a try to change the do_fat_read to support 
> the chaining.
> 
> Regards Michael
> 
> 



From galak at kernel.crashing.org  Fri Apr 25 21:06:55 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 14:06:55 -0500
Subject: [U-Boot-Users] [PATCH] MPC8544DS: Removes the unknown flash
	message information
In-Reply-To: <79369D8F-3184-4D04-8FCA-1575F7B5EA59@kernel.crashing.org>
References: <20080425083908.0FC1824AB5@gemini.denx.de>
	<79369D8F-3184-4D04-8FCA-1575F7B5EA59@kernel.crashing.org>
Message-ID: <AEB08773-D707-4888-9A95-7ADD77234F54@kernel.crashing.org>


On Apr 25, 2008, at 7:52 AM, Kumar Gala wrote:
>
> On Apr 25, 2008, at 3:39 AM, Wolfgang Denk wrote:
>> In message <Pine.LNX.
>> 4.64.0804250054340.32740 at blarg.am.freescale.net> you wrote:
>>> From: Roy Zang <tie-fei.zang at freescale.com>
>>>
>>> This patch removes the unknown flash message information:
>>> '## Unknown FLASH on Bank 1 - Size = 0xdeadbeef = -286261248 MB'
>>> This unknown flash message is caused by PromJet.
>>> Some of the board user is unhappy with this information.
>>>
>>> Signed-off-by: Roy Zang <tie-fei.zang at freescale.com>
>>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>>
>> Is it correct to assume that a 85xx pull request will follow soon?
>
> hopefully but that depends on Andy be awake today :)

as predicted Andy's not around today.  Feel free to apply the two  
patches.

- k



From Ken.Fuchs at bench.com  Fri Apr 25 21:28:03 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Fri, 25 Apr 2008 14:28:03 -0500
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <alpine.DEB.1.10.0804251308480.12475@pmy.adscville>
Message-ID: <AA28F077645B324881335614E4F7C428034CE9@win-ex01.bench.com>

Adrian Filipi wrote:

>  	It looks like fat.c is not handling the case where the 
> sectors/cluster is 1, and the rood directory spans multiple clusters.
> 
>  	In my case I was getting garbage directory info after 
> the invalid fat error.  The attached patch stops the code
> from rolling past the end of cluster.

I was also getting these garbage directory entries which appeared
to be file nodes being interpreted as directory nodes.

I can confirm that Adrian's patch fixes this particular problem
for FAT32.  Now, on FAT32, whatever files are displayed by fatls
are also readable by fatload.  As Adrian mentions below, the files
not displayed by fatls are completely inaccessible to the current
fat.c with or without Adrian's patch.

FAT16 also suffered from this "garbage" problem when there were
512 files, but the patch also fixes this.  (If there is a volume
name, it should use one of the root directory entries, leaving
only 511 directory entries for files; otherwise, the lack/presence
of a volume name probably has no effect on FAT16.)

>  	It looks like a loop to walk the allocation chain is 
> necessary.  I think get_contents() does all the right work,
> but it of course starts with a directory entry, which we don't
> have yet for /.  A little refactoring might do the trick.

Of course this only applies to FAT32.  Adrian's patch appears to
have fixed the only issue with FAT16 that I'm aware of.

Time permitting, I will try to fix this remaining problem myself.
Adrian, thanks for your insight into the problem and a potential
solution.

Sincerely,

Ken Fuchs



From gerald.vanbaren at ge.com  Fri Apr 25 22:41:35 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Fri, 25 Apr 2008 16:41:35 -0400
Subject: [U-Boot-Users] 83xx DDR2 667Mhz memory
In-Reply-To: <000001c8a641$eac1beb0$e505a8c0@absolutdaddy>
References: <mailman.128014.1209064835.5026.u-boot-users@lists.sourceforge.net>
	<000001c8a641$eac1beb0$e505a8c0@absolutdaddy>
Message-ID: <481241FF.1060907@ge.com>

Russell McGuire wrote:
> All,
> 
> Just curious if anyone has done any work with this near past.
> I have had an 8360E board up for several months now and been happily working
> away with different types of Kingston S0-DIMM DDR2 memory.
> 
> 512MB, 1204MB, DDR2 533Mhz memory. All work well, with U-boot.
> Using the SPD detectetion, things have just been automatically detected and
> worked wonderful.
> 
> Yesterday I went down and purchased two additional sticks of 1024MB DDR2
> Crucial 667Mhz memory, as 533Mhz is in short supply. SPD detect still works
> in U-boot and everything is detected correctly. However, the u-boot will now
> hang when it tries to transfer execution into RAM. At first I figured this
> was a memory speed issue, since 667Mhz is not technically supported on the
> 8360E yet <Rev 2... I might be wrong on this?>, So I patched in a quick line
> of code to force the spd detection to limit to 533Mhz.  Still doesn't work.
> 
> Any ideas? Again, same exact u-boot just different memory. SPD sees it all
> just fine, just can't use the RAM after its setup. Currently using a
> slightly older version of U-boot 1.3.0-dirty.
> 
> -Russ

Hi Russ,

Any luck?  I would be suspicious that the number of clocks changed (e.g. 
CL latencies) and the current code did not pick the changes out of the 
SPD fields properly.  I would dump the two SPDs and compare them.  If 
you can get datasheets on the RAM chips that are on the boards, that may 
also be helpful to compare.

Quite often, faster parts have longer latencies.  My SPD decoding is 
knowledge getting a little rusty, but my recollection is that the memory 
controller configuration values and the SPD definitions did not clearly 
map 1:1 (had to massage SPD values to figure out/guess controller 
register values).

HTH,
gvb

P.S., as an added, free, bonus, here is a little diatribe on memory 
speed...  It is slightly dated, obviously, but still valid.

Today we have PowerPCs running at 400-800MHz (and above) with the system 
bus running at 100MHz (and above). However, the systems which are 
running 100MHz on the system/memory bus have typically 18 clock cycles 
latency...

     100MHz / 18 = 5.56MHz

In the IBM PC-XT, created in 1981, the system bus was 4.77MHz!
In the IBM PC-At, created in 1984, the system bus was 8MHz (originally 6MHz)

25 years after the debut of the PC-XT, we are clocking like mad but have 
basically the same data rates on our system bus!

Disclaimers:
     * Bus width has increased from 2 bytes to 16 bytes, with resulting 
linear scaling of data throughput.
     * Pipelining on the memory bus can use many of the latency clock 
cycles to queue up reads and writes, with resulting increases in 
throughput. However...
           o The average pipelining success rate is much less than 100%.
           o I/O typically doesn't support pipelining.
     * IIRC, the IBM-XT could access memory mapped ISA boards with zero 
wait states. Accessing I/O ports (in/out instructions) inserted wait 
states.



From wd at denx.de  Fri Apr 25 23:44:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 23:44:54 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: Your message of "Fri, 25 Apr 2008 14:40:01 +0200."
	<20080425144001.0cdb8f4e@peedub.jennejohn.org>
Message-ID: <20080425214454.AD47F24AB1@gemini.denx.de>

Hello Gary,

in message <20080425144001.0cdb8f4e at peedub.jennejohn.org> you wrote:
> 
> > > +#define CONFIG_IPADDR		192.168.1.67
> > > +#define CONFIG_SERVERIP		192.168.1.50
> > > +#define CONFIG_GATEWAYIP	192.168.1.1
> > > +#define CONFIG_NETMASK		255.255.255.0
> > > +#define CONFIG_ETHADDR 		00:01:02:03:04:05
> > > +#define CONFIG_ETH1ADDR		00:01:02:03:04:06
> > 
> > Are you really sure that you want to provide default MAC-addresses? We usually 
> > don't do this.
> 
> The customer had CONFIG_ETHADDR set in PPCBoot.  I added CONFIG_ETH1ADDR
> analog to that, since I have CONFIG_NET_MULTI defined in quad100hd.h.
> 
> I personally don't care either way and have no problem with removing them.
> Don't know what the customer would have to say about that.

Please remove this stuff from the board conig file. It has  no  place
there.  Not  to  mention that the used MAC addresses are owned by the
3Com corporation, and we have no permission to use these.

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: wd at denx.de
"There are some good people in it, but the orchestra as  a  whole  is
equivalent to a gang bent on destruction."      - John Cage, composer



From wd at denx.de  Fri Apr 25 23:48:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 23:48:00 +0200
Subject: [U-Boot-Users] [PATCH] 85xx: Fix size of cpu-release-addr
	property
In-Reply-To: Your message of "Fri, 25 Apr 2008 07:53:03 CDT."
	<DCD54745-A286-4E15-93FE-C71CD00AED37@kernel.crashing.org>
Message-ID: <20080425214800.C9D8E24AB1@gemini.denx.de>

In message <DCD54745-A286-4E15-93FE-C71CD00AED37 at kernel.crashing.org> you wrote:
> 
> > Signed-off-by line  missing...
> 
> oops (should have had it).  This got into the tree how do you want to  
> deal with it?

Oops. Well, that cannot be changed. Maybe you can post the S-o-b ,
just for the record :-)

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: wd at denx.de
Digital computers are themselves more complex than most things people
build: They have very large numbers of states. This makes conceiving,
describing, and testing them hard. Software systems  have  orders-of-
magnitude more states than computers do.           - Fred Brooks, Jr.



From wd at denx.de  Fri Apr 25 23:51:25 2008
From: wd at denx.de (Wolfgang Denk)
Date: Fri, 25 Apr 2008 23:51:25 +0200
Subject: [U-Boot-Users] ide arm support
In-Reply-To: Your message of "Fri, 25 Apr 2008 17:52:22 +0200."
	<4811FE36.60101@gandalf.sssup.it>
Message-ID: <20080425215125.1BE2124764@gemini.denx.de>

Dear Michael,

in message <4811FE36.60101 at gandalf.sssup.it> you wrote:
> 
> when do you have spare time can you give some feedback about arm ide patch?

Note: you addressed this question to the Mailing  List,  not  to  any
specific person.

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: wd at denx.de
In theory, there is no difference between  theory  and  practice.  In
practice, however, there is.



From galak at kernel.crashing.org  Fri Apr 25 23:55:27 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 16:55:27 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx: Fix size of cpu-release-addr property
Message-ID: <Pine.LNX.4.64.0804251655110.10396@blarg.am.freescale.net>

The cpu-release-addr is defined as always being a 64-bit quanity regardless
if we are running on a 32-bit or 64-bit machine.

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

posted with S-o-b just so we have a record.

- k
A
 cpu/mpc85xx/fdt.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cpu/mpc85xx/fdt.c b/cpu/mpc85xx/fdt.c
index bde6d1e..bb87740 100644
--- a/cpu/mpc85xx/fdt.c
+++ b/cpu/mpc85xx/fdt.c
@@ -52,7 +52,7 @@ void ft_fixup_cpu(void *blob, u64 memory_limit)
 			if (*reg == id) {
 				fdt_setprop_string(blob, off, "status", "okay");
 			} else {
-				u32 val = *reg * SIZE_BOOT_ENTRY + spin_tbl_addr;
+				u64 val = *reg * SIZE_BOOT_ENTRY + spin_tbl_addr;
 				val = cpu_to_fdt32(val);
 				fdt_setprop_string(blob, off, "status",
 								"disabled");
-- 
1.5.4.1




From galak at kernel.crashing.org  Fri Apr 25 23:59:36 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Fri, 25 Apr 2008 16:59:36 -0500
Subject: [U-Boot-Users] [PATCH] 85xx: Fix size of cpu-release-addr
	property
In-Reply-To: <20080425214800.C9D8E24AB1@gemini.denx.de>
References: <20080425214800.C9D8E24AB1@gemini.denx.de>
Message-ID: <01776DAA-925F-4389-A762-1BD23597ABE7@kernel.crashing.org>


On Apr 25, 2008, at 4:48 PM, Wolfgang Denk wrote:
> In message <DCD54745-A286-4E15-93FE- 
> C71CD00AED37 at kernel.crashing.org> you wrote:
>>
>>> Signed-off-by line  missing...
>>
>> oops (should have had it).  This got into the tree how do you want to
>> deal with it?
>
> Oops. Well, that cannot be changed. Maybe you can post the S-o-b ,
> just for the record :-)

done.

- k



From wd at denx.de  Sat Apr 26 00:06:32 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sat, 26 Apr 2008 00:06:32 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: Your message of "Fri, 25 Apr 2008 13:40:07 +0200."
	<200804251340.07270.sr@denx.de>
Message-ID: <20080425220632.2017A24AB5@gemini.denx.de>

In message <200804251340.07270.sr at denx.de> you wrote:
> The following changes since commit 58c5376ba67767ee684069d43e7f747a5d9ae8ed:
>   Wolfgang Denk (1):
>         Merge branch 'master' of git://www.denx.de/git/u-boot-ppc4xx
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Matthias Fuchs (1):
>       ppc4xx: Add bootcount limit handling for APC405 boards
> 
> Stefan Roese (1):
>       ppc4xx: Pass PCIe root-complex/endpoint configuration to Linux via the fdt

done, 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: wd at denx.de
Some programming languages manage to  absorb  change,  but  withstand
progress.          -- Epigrams in Programming, ACM SIGPLAN Sept. 1982



From wd at denx.de  Sat Apr 26 00:07:03 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sat, 26 Apr 2008 00:07:03 +0200
Subject: [U-Boot-Users] [cfi-flash] Please pull
	git://www.denx.de/git/u-boot-cfi-flash.git
In-Reply-To: Your message of "Fri, 25 Apr 2008 15:55:58 +0200."
	<200804251555.58837.sr@denx.de>
Message-ID: <20080425220703.DAB5124AB5@gemini.denx.de>

In message <200804251555.58837.sr at denx.de> you wrote:
> The following changes since commit d0d91ae3acb4f29d1a2a3a766747478ed54e2848:
>   Stefan Roese (1):
>         ppc4xx: Remove double defines in lwmon5.h
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-cfi-flash.git master
> 
> Matthias Fuchs (1):
>       cfi-flash: Add CFG_FLASH_AUTOPROTECT_LIST
> 
>  drivers/mtd/cfi_flash.c |   17 +++++++++++++++++
>  1 files changed, 17 insertions(+), 0 deletions(-)

Done, 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: wd at denx.de
He had quite a powerful intellect, but it  was  as  powerful  like  a
locomotive,  and  ran on rails and was therefore almost impossible to
steer.                          - Terry Pratchett, _Lords and Ladies_



From wd at denx.de  Sat Apr 26 00:07:42 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sat, 26 Apr 2008 00:07:42 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc83xx.git
In-Reply-To: Your message of "Fri, 25 Apr 2008 09:45:52 CDT."
	<20080425094552.d8399e46.kim.phillips@freescale.com>
Message-ID: <20080425220742.0A8F724AB5@gemini.denx.de>

In message <20080425094552.d8399e46.kim.phillips at freescale.com> you wrote:
> for some minor fixes:
> 
> The following changes since commit d0d91ae3acb4f29d1a2a3a766747478ed54e2848:
>   Stefan Roese (1):
>         ppc4xx: Remove double defines in lwmon5.h
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc83xx.git
> 
> Dave Liu (2):
>       mpc83xx: remove the unused CPM's stuff
>       mpc83xx: clean up the readme for 83xx boards
> 
> Kim Phillips (1):
>       mpc83xx: bump loadaddr over fdtaddr to 0x500000
> 
>  cpu/mpc83xx/fdt.c             |    8 --------
>  doc/README.mpc8313erdb        |    4 ++--
>  doc/README.mpc8315erdb        |    2 +-
>  doc/README.mpc837xemds        |    2 +-
>  doc/README.mpc837xerdb        |   13 ++++++-------
>  include/configs/MPC8313ERDB.h |    2 +-
>  include/configs/MPC8315ERDB.h |    2 +-
>  include/configs/MPC8323ERDB.h |    2 +-
>  include/configs/MPC832XEMDS.h |    2 +-
>  include/configs/MPC8349EMDS.h |    2 +-
>  include/configs/MPC8349ITX.h  |    2 +-
>  include/configs/MPC8360EMDS.h |    2 +-
>  include/configs/MPC837XEMDS.h |    2 +-
>  include/configs/MPC837XERDB.h |    2 +-
>  include/configs/sbc8349.h     |    2 +-
>  15 files changed, 20 insertions(+), 29 deletions(-)

Done, 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: wd at denx.de
Witch!  Witch!  They'll burn ya!
	-- Hag, "Tomorrow is Yesterday", stardate unknown



From wd at denx.de  Sat Apr 26 00:23:21 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sat, 26 Apr 2008 00:23:21 +0200
Subject: [U-Boot-Users] [PATCH] MPC8544DS: Removes the unknown flash
	message information
In-Reply-To: Your message of "Fri, 25 Apr 2008 00:55:09 CDT."
	<Pine.LNX.4.64.0804250054340.32740@blarg.am.freescale.net>
Message-ID: <20080425222321.565E924AB5@gemini.denx.de>

In message <Pine.LNX.4.64.0804250054340.32740 at blarg.am.freescale.net> you wrote:
> From: Roy Zang <tie-fei.zang at freescale.com>
> 
> This patch removes the unknown flash message information:
> '## Unknown FLASH on Bank 1 - Size = 0xdeadbeef = -286261248 MB'
> This unknown flash message is caused by PromJet.
> Some of the board user is unhappy with this information.
> 
> Signed-off-by: Roy Zang <tie-fei.zang at freescale.com>
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>

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: wd at denx.de
Heavier than air flying machines are impossible.
                    -- Lord Kelvin, President, Royal Society, c. 1895



From wd at denx.de  Sat Apr 26 00:25:47 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sat, 26 Apr 2008 00:25:47 +0200
Subject: [U-Boot-Users] [PATCH] MPC8544DS: decode pcie3 end-point
	configuration correctly.
In-Reply-To: Your message of "Fri, 25 Apr 2008 01:08:32 CDT."
	<Pine.LNX.4.64.0804250107530.1024@blarg.am.freescale.net>
Message-ID: <20080425222547.25C3A24764@gemini.denx.de>

In message <Pine.LNX.4.64.0804250107530.1024 at blarg.am.freescale.net> you wrote:
> From: Ed Swarthout <Ed.Swarthout at freescale.com>
> 
> Signed-off-by: Ed Swarthout <Ed.Swarthout at freescale.com>
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
>  board/freescale/mpc8544ds/mpc8544ds.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Was hei?t Windows auf Indianisch? - "Wei?er  Mann,  der  auf  Sanduhr
wartet!"



From wd at denx.de  Sat Apr 26 00:27:09 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sat, 26 Apr 2008 00:27:09 +0200
Subject: [U-Boot-Users] [PATCH] i.MX31: Enable SPI and MC13783/RTC
	support for the Litekit board
In-Reply-To: Your message of "Sun, 20 Apr 2008 10:38:12 +0200."
	<480B00F4.6030406@gmail.com>
Message-ID: <20080425222709.3565224AB5@gemini.denx.de>

In message <480B00F4.6030406 at gmail.com> you wrote:
> This patch enables SPI and MC13783/RTC support for the Litekit board.
> 
> Signed-off-by: Magnus Lilja <lilja.magnus at gmail.com>
> ---
> 
>  board/imx31_litekit/imx31_litekit.c |   12 ++++++++++++
>  include/configs/imx31_litekit.h     |    8 ++++++++
>  2 files changed, 20 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: wd at denx.de
God made machine language; all the rest is the work of man.



From wd at denx.de  Sat Apr 26 01:57:16 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sat, 26 Apr 2008 01:57:16 +0200
Subject: [U-Boot-Users] 1.3.3-rc1 - release status
Message-ID: <20080425235716.3419D24AB5@gemini.denx.de>

Hello,

I decided to tag the current versionof U-Boot as "rc1".

At the moment, I have the following patches still maked as open on my
list:

 7972  04/03 Guennadi Liakhove  [U-Boot-Users] [PATCH] minor cs8900 driver clean up
 7997  04/03 Guennadi Liakhove  [U-Boot-Users] [PATCH v2] net: make ARP timeout configurable
 8038  04/04 michael            Re: [PATCH] get_vfatname
 8212  04/09 Andre Schwarz      [U-Boot-Users] [PATCH] add MPC8343 based board mvBlueLYNX-M7 aka mvblm7
 8950  04/24 Jean-Christophe P  [U-Boot-Users] [PATCH 1/1 V2] NE2000: Fix regresssion introduced by e710185aae90 on non
 8956  04/24 michael            [U-Boot-Users] [PATCH ARM 1/2] Ide support io function
 8957  04/24 michael            [U-Boot-Users] [PATCH ARM 2/2] Ide support. Ide registration
 8958  04/24 michael            [U-Boot-Users] [PATCH ARM 0/2] Ide support
 8984  04/24 Andre Schwarz      Re: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
 8989  04/24 Andre Schwarz      [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY

My understanding is as follows:

8038 - is not clear yet, discussions still going on; wait for solution

8212 - new code, will go into next release

7972, 7997, 8950, 8984, 8989 - network code; Ben - please comment?

8956, 8957, 8958 - new code (for next release); ARM code (for ARM custodian).


Please let me know if I'm missing somethign....

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: wd at denx.de
If it went on at this rate, in several billion  years  he'd  be  rich
beyond his wildest dreams!            - Terry Pratchett, _Soul Music_



From littelld at verizon.net  Sat Apr 26 03:54:51 2008
From: littelld at verizon.net (Dave Littell)
Date: Fri, 25 Apr 2008 20:54:51 -0500
Subject: [U-Boot-Users] PPC440EPx/sequoia TLB question...
In-Reply-To: <200804231442.29687.sr@denx.de>
References: <480EA8E1.4060207@verizon.net> <200804231442.29687.sr@denx.de>
Message-ID: <48128B6B.8090909@verizon.net>

Stefan Roese wrote:
> On Wednesday 23 April 2008, Dave Littell wrote:
>> >From ?/board/amcc/sequoia/init.S:
>>
>> /* TLB-entry for Internal Registers & OCM */
>> tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0, AC_R|AC_W|AC_X|SA_I )
>>
>> Why is this memory region not marked Guarded?  It would seem to meet the
>> definition of ?non-well-behaved?.
> 
> Why do you think this is the case?
> 
>> Also the TLB entry for SDRAM marks it Guarded, but that?s one area I
>> would think wouldn't need to be Guarded.
> 
> This could be a mistake. Should work without G bis set too. Please give it a 
> try and send a patch to fix it, if it works fine.
> 

Here goes (again):

Patch for AMCC Sequoia to remove the TLB Guarded attribute for SDRAM,
and add the Guarded attribute for Internal Registers & OCM.

diff -purN u-boot-1.3.2_base/board/amcc/sequoia/init.S u-boot-1.3.2/board/amcc/sequoia/init.S
--- u-boot-1.3.2_base/board/amcc/sequoia/init.S 2008-03-09 10:20:02.000000000 -0500
+++ u-boot-1.3.2/board/amcc/sequoia/init.S      2008-04-24 21:24:17.542281994 -0500
@@ -45,9 +45,9 @@ tlbtab:

        /* TLB-entry for DDR SDRAM (Up to 2GB) */
 #ifdef CONFIG_4xx_DCACHE
-       tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0, AC_R|AC_W|AC_X|SA_G)
+       tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0, AC_R|AC_W|AC_X)
 #else
-       tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0, AC_R|AC_W|AC_X|SA_G|SA_I )
+       tlbentry( CFG_SDRAM_BASE, SZ_256M, CFG_SDRAM_BASE, 0, AC_R|AC_W|AC_X|SA_I )
 #endif

        /* TLB-entry for EBC */
@@ -77,7 +77,7 @@ tlbtab:
        tlbentry( CFG_NAND_ADDR, SZ_1K, CFG_NAND_ADDR, 1, AC_R|AC_W|AC_X|SA_G|SA_I )

        /* TLB-entry for Internal Registers & OCM */
-       tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0,  AC_R|AC_W|AC_X|SA_I )
+       tlbentry( 0xe0000000, SZ_16M, 0xe0000000, 0,  AC_R|AC_W|AC_X|SA_G|SA_I )

        /*TLB-entry PCI registers*/
        tlbentry( 0xEEC00000, SZ_1K, 0xEEC00000, 1,  AC_R|AC_W|AC_X|SA_G|SA_I )


I sure hope this is better (from a line-wrapping perspective).


Dave



From biggerbadderben at gmail.com  Sat Apr 26 04:47:59 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Fri, 25 Apr 2008 19:47:59 -0700
Subject: [U-Boot-Users] 1.3.3-rc1 - release status
In-Reply-To: <20080425235716.3419D24AB5@gemini.denx.de>
References: <20080425235716.3419D24AB5@gemini.denx.de>
Message-ID: <f8328f7c0804251947u4c59c1bcn6beb220c75f6adb9@mail.gmail.com>

Hi Wolfgang,

On Fri, Apr 25, 2008 at 4:57 PM, Wolfgang Denk <wd at denx.de> wrote:
> Hello,
>
>  I decided to tag the current versionof U-Boot as "rc1".
>
>  At the moment, I have the following patches still maked as open on my
>  list:
>
>   7972  04/03 Guennadi Liakhove  [U-Boot-Users] [PATCH] minor cs8900 driver clean up
>   7997  04/03 Guennadi Liakhove  [U-Boot-Users] [PATCH v2] net: make ARP timeout configurable
>   8038  04/04 michael            Re: [PATCH] get_vfatname
>   8212  04/09 Andre Schwarz      [U-Boot-Users] [PATCH] add MPC8343 based board mvBlueLYNX-M7 aka mvblm7
>   8950  04/24 Jean-Christophe P  [U-Boot-Users] [PATCH 1/1 V2] NE2000: Fix regresssion introduced by e710185aae90 on non
>   8956  04/24 michael            [U-Boot-Users] [PATCH ARM 1/2] Ide support io function
>   8957  04/24 michael            [U-Boot-Users] [PATCH ARM 2/2] Ide support. Ide registration
>   8958  04/24 michael            [U-Boot-Users] [PATCH ARM 0/2] Ide support
>   8984  04/24 Andre Schwarz      Re: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
>   8989  04/24 Andre Schwarz      [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
>
>  My understanding is as follows:
>
>  8038 - is not clear yet, discussions still going on; wait for solution
>
>  8212 - new code, will go into next release
>
>  7972, 7997, 8950, 8984, 8989 - network code; Ben - please comment?
>
I'll look them over ASAP.

regards,
Ben



From kashiwagi at co-nss.co.jp  Sat Apr 26 04:59:20 2008
From: kashiwagi at co-nss.co.jp (Yoshio Kashiwagi)
Date: Sat, 26 Apr 2008 11:59:20 +0900
Subject: [U-Boot-Users] Xilinx PowerPC XPS_LL_TEMAC driver
In-Reply-To: <JT200804260014123.1442531@co-nss.co.jp>
References: <JF2008042518323445.35379812@co-nss.co.jp>
	<JT200804260014123.1442531@co-nss.co.jp>
Message-ID: <JN200804261159205.13431171@co-nss.co.jp>

Hi,

I corrected some faults and checked normal operation by EDK10.1.

Best Regards,

Yoshio Kashiwagi - Nissin Systems

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d5e413b..a11238b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -63,6 +63,7 @@ COBJS-y += uli526x.o
 COBJS-y += vsc7385.o
 COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
 COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
+COBJS-$(CONFIG_XILINX_LL_TEMAC)) += xilinx_ll_temac.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.
c
new file mode 100644
index 0000000..2f75ebc
--- /dev/null
+++ b/drivers/net/xilinx_ll_temac.c
@@ -0,0 +1,371 @@
+/*
+ *
+ * Xilinx xps_ll_temac ethernet driver for u-boot
+ *
+ * Author: Yoshio Kashiwagi kashiwagi at co-nss.co.jp
+ *
+ * Copyright (c) 2008 Nissin Systems Co.,Ltd.
+ *
+ * March 2008 created
+ *
+ * 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.
+ *
+*/
+#include <config.h>
+#include <common.h>
+#include <net.h>
+#include <malloc.h>
+#include <asm/errno.h>
+#include <asm/processor.h>
+
+#define S_DMA_CTRL_BASEADDR    XPAR_LLTEMAC_0_LLINK_CONNECTED_BASEADDR
+#define XPS_LLTEMAC_BASEADDR   XPAR_LLTEMAC_0_BASEADDR
+
+/* XPS_LL_TEMAC SDMA registers definition */
+
+#define TX_NXTDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x00)
+#define TX_CURBUF_ADDR     (S_DMA_CTRL_BASEADDR + 0x04)
+#define TX_CURBUF_LENGTH   (S_DMA_CTRL_BASEADDR + 0x08)
+#define TX_CURDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x0c)
+#define TX_TAILDESC_PTR        (S_DMA_CTRL_BASEADDR + 0x10)
+#define TX_CHNL_CTRL       (S_DMA_CTRL_BASEADDR + 0x14)
+#define TX_IRQ_REG     (S_DMA_CTRL_BASEADDR + 0x18)
+#define TX_CHNL_STS        (S_DMA_CTRL_BASEADDR + 0x1c)
+
+#define RX_NXTDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x20)
+#define RX_CURBUF_ADDR     (S_DMA_CTRL_BASEADDR + 0x24)
+#define RX_CURBUF_LENGTH   (S_DMA_CTRL_BASEADDR + 0x28)
+#define RX_CURDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x2c)
+#define RX_TAILDESC_PTR        (S_DMA_CTRL_BASEADDR + 0x30)
+#define RX_CHNL_CTRL       (S_DMA_CTRL_BASEADDR + 0x34)
+#define RX_IRQ_REG     (S_DMA_CTRL_BASEADDR + 0x38)
+#define RX_CHNL_STS        (S_DMA_CTRL_BASEADDR + 0x3c)
+
+#define DMA_CONTROL_REG        (S_DMA_CTRL_BASEADDR + 0x40)
+
+/* XPS_LL_TEMAC direct registers definition */
+
+#define TEMAC_RAF0     (XPS_LLTEMAC_BASEADDR + 0x00)
+#define TEMAC_TPF0     (XPS_LLTEMAC_BASEADDR + 0x04)
+#define TEMAC_IFGP0        (XPS_LLTEMAC_BASEADDR + 0x08)
+#define TEMAC_IS0      (XPS_LLTEMAC_BASEADDR + 0x0c)
+#define TEMAC_IP0      (XPS_LLTEMAC_BASEADDR + 0x10)
+#define TEMAC_IE0      (XPS_LLTEMAC_BASEADDR + 0x14)
+
+#define TEMAC_MSW0     (XPS_LLTEMAC_BASEADDR + 0x20)
+#define TEMAC_LSW0     (XPS_LLTEMAC_BASEADDR + 0x24)
+#define TEMAC_CTL0     (XPS_LLTEMAC_BASEADDR + 0x28)
+#define TEMAC_RDY0     (XPS_LLTEMAC_BASEADDR + 0x2c)
+
+#define XTE_RSE_MIIM_RR_MASK      0x0002
+#define XTE_RSE_MIIM_WR_MASK      0x0004
+#define XTE_RSE_CFG_RR_MASK       0x0020
+#define XTE_RSE_CFG_WR_MASK       0x0040
+
+/* XPS_LL_TEMAC indirect registers offset definition */
+
+#define RCW0   0x200
+#define RCW1   0x240
+#define TC 0x280
+#define FCC    0x2c0
+#define EMMC   0x300
+#define PHYC   0x320
+#define MC 0x340
+#define UAW0   0x380
+#define UAW1   0x384
+#define MAW0   0x388
+#define MAW1   0x38c
+#define AFM    0x390
+#define TIS    0x3a0
+#define TIE    0x3a4
+#define MIIMWD 0x3b0
+#define MIIMAI 0x3b4
+
+#define CNTLREG_WRITE_ENABLE_MASK  0x8000
+#define CNTLREG_EMAC1SEL_MASK      0x0400
+#define CNTLREG_ADDRESSCODE_MASK   0x03ff
+
+#define MDIO_ENABLE_MASK   0x40
+#define MDIO_CLOCK_DIV_MASK    0x3F
+#define MDIO_CLOCK_DIV_100MHz  0x28
+
+#define ETHER_MTU      1520
+#define CACHE_LINE_SIZE        32
+
+/* SDMA descriptor status bit definitions */
+
+#define BDSTAT_ERROR_MASK       0x80
+#define BDSTAT_INT_ON_END_MASK  0x40
+#define BDSTAT_STOP_ON_END_MASK 0x20
+#define BDSTAT_COMPLETED_MASK   0x10
+#define BDSTAT_SOP_MASK         0x08
+#define BDSTAT_EOP_MASK         0x04
+#define BDSTAT_CHANBUSY_MASK    0x02
+#define BDSTAT_CHANRESET_MASK   0x01
+
+/* SDMA Buffer Descriptor */
+
+typedef struct cdmac_bd_t {
+   struct cdmac_bd_t *next_p;
+   unsigned char *phys_buf_p;
+   unsigned long buf_len;
+   unsigned char stat;
+   unsigned char app1_1;
+   unsigned short app1_2;
+   unsigned long app2;
+   unsigned long app3;
+   unsigned long app4;
+   unsigned long app5;
+} cdmac_bd __attribute((aligned(32))) ;
+
+static cdmac_bd    tx_bd;
+static cdmac_bd    rx_bd;
+static unsigned char tx_buffer[ETHER_MTU] __attribute((aligned(32)));
+static unsigned char rx_buffer[ETHER_MTU] __attribute((aligned(32)));
+
+struct xps_ll_temac_private {
+   int idx;
+   unsigned char dev_addr[6];
+};
+
+static void flush_dcache_range(unsigned int addr, unsigned size)
+{
+   unsigned int end = addr + size;
+
+   if(size) {
+       addr = addr & ~(CACHE_LINE_SIZE - 1);
+       while(addr < end) {
+           __asm__ __volatile__("dcbf 0,%0; sync;" : : "r" (addr));
+           addr += CACHE_LINE_SIZE;
+       }
+   }
+}
+
+static void invalidate_dcache_range(unsigned int addr, unsigned size)
+{
+   unsigned int end = addr + size;
+
+   if(size) {
+       addr = addr & ~(CACHE_LINE_SIZE - 1);
+       while(addr < end) {
+           __asm__ __volatile__("dcbi 0,%0; sync;" : : "r" (addr));
+           addr += CACHE_LINE_SIZE;
+       }
+   }
+}
+
+static unsigned int xps_ll_temac_hostif_get(int emac, int phy_addr, int 
reg_addr)
+{
+   *(unsigned int *)TEMAC_LSW0 = phy_addr << 5 | reg_addr;
+   *(unsigned int *)TEMAC_CTL0 = MIIMAI | emac << 10;
+
+   while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_MIIM_RR_MASK)
);
+   return *(unsigned int *)TEMAC_LSW0;
+}
+
+static void xps_ll_temac_indirect_set(int emac, int reg_offset, int 
reg_data)
+{
+   *(unsigned int *)TEMAC_LSW0 = reg_data;
+   *(unsigned int *)TEMAC_CTL0 = CNTLREG_WRITE_ENABLE_MASK | emac << 10 
| reg_offset;
+   while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_CFG_WR_MASK))
;
+}
+
+static int xps_ll_temac_phy_ctrl(void)
+{
+   static int phy_addr = -1;
+   static int link = 0;
+   int i;
+   unsigned int result;
+
+   if(phy_addr == -1) {
+       for(i = 0;i < 32;i++) {
+           result = xps_ll_temac_hostif_get(0, i, 1);
+           if((result & 0x0ffff) != 0x0ffff) {
+               phy_addr = i;
+               break;
+           }
+       }
+   } else {
+       result = xps_ll_temac_hostif_get(0, phy_addr, 1);
+   }
+   if((result & 0x24) != 0x24) {
+       if(link) {
+           link = 0;
+           printf("Link down\n");
+       }
+       return 0;
+   }
+   if(link == 0) {
+       link = 1;
+   } else {
+       return 1;
+   }
+
+   result = xps_ll_temac_hostif_get(0, phy_addr, 10);
+   if((result & 0x0800) == 0x0800) {
+       xps_ll_temac_indirect_set(0, EMMC, 0x80000000);
+       printf("1000BASE-T/FD\n");
+       return 1;
+   }
+   result = xps_ll_temac_hostif_get(0, phy_addr, 5);
+   if((result & 0x0100) == 0x0100) {
+       xps_ll_temac_indirect_set(0, EMMC, 0x40000000);
+       printf("100BASE-T/FD\n");
+   } else if((result & 0x0040) == 0x0040) {
+       xps_ll_temac_indirect_set(0, EMMC, 0x00000000);
+       printf("10BASE-T/FD\n");
+   } else {
+       printf("Half Duplex not supported\n");
+   }
+   return 1;
+}
+
+static void xps_ll_temac_bd_init(void)
+{
+   memset((void *)&tx_bd, 0, sizeof(cdmac_bd));
+   memset((void *)&rx_bd, 0, sizeof(cdmac_bd));
+   
+   rx_bd.phys_buf_p = &rx_buffer[0];
+   rx_bd.next_p = &rx_bd;
+   rx_bd.buf_len = ETHER_MTU;
+   flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
+   *(unsigned int *)RX_CURDESC_PTR = (unsigned int)&rx_bd;
+   *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;
+
+   tx_bd.phys_buf_p = &tx_buffer[0];
+   tx_bd.next_p = &tx_bd;
+   flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
+   *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
+}
+
+static int xps_ll_temac_send(unsigned char *buffer, int length)
+{
+   if(xps_ll_temac_phy_ctrl() == 0) return 0;
+
+   memcpy(tx_buffer, buffer, length);
+   flush_dcache_range((unsigned int)tx_buffer, length);
+
+   tx_bd.stat = BDSTAT_SOP_MASK | BDSTAT_EOP_MASK | BDSTAT_STOP_ON_END_
MASK;
+   tx_bd.buf_len = length;
+   flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
+
+   *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
+   *(unsigned int *)TX_TAILDESC_PTR = (unsigned int)&tx_bd; /* DMA 
start */
+
+   do {
+       invalidate_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
+   } while(!((volatile int)tx_bd.stat & BDSTAT_COMPLETED_MASK));
+
+   return length;
+}
+
+static int xps_ll_temac_recv(void)
+{
+   int length;
+
+   invalidate_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
+   if(!(rx_bd.stat & BDSTAT_COMPLETED_MASK)) return 0;
+
+   length = rx_bd.app5;
+   invalidate_dcache_range((unsigned int)rx_bd.phys_buf_p, length);
+
+   rx_bd.buf_len = ETHER_MTU;
+   rx_bd.stat = 0;
+   rx_bd.app5 = 0;
+   flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
+   *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;
+
+   if(length > 0) {
+       NetReceive(rx_bd.phys_buf_p, length);
+   }
+
+   return length;
+}
+
+static int xps_ll_temac_addr_setup(struct xps_ll_temac_private * lp)
+{
+        char * env_p;
+        char * end;
+        int    i, val;
+
+        env_p = getenv("ethaddr");
+        if (env_p == NULL) {
+                printf("cannot get enviroment for \"ethaddr\".\n");
+                return -1;
+        }
+
+        for (i = 0; i < 6; i++) {
+                lp->dev_addr[i] = env_p ? simple_strtoul(env_p, &end, 
16) : 0;
+                if (env_p) env_p = (*end) ? end + 1 : end;
+        }
+
+        /* set up unicast MAC address filter */
+        val = lp->dev_addr[3] << 24 | lp->dev_addr[2] << 16 |
+               lp->dev_addr[1] <<  8 | lp->dev_addr[0];
+   xps_ll_temac_indirect_set(0, UAW0, val);
+        val = lp->dev_addr[5] << 8 |  lp->dev_addr[4];
+   xps_ll_temac_indirect_set(0, UAW1, val);
+
+        return 0;
+}
+
+static void xps_ll_temac_init(struct eth_device *dev, bd_t *bis)
+{
+   struct xps_ll_temac_private *lp = (struct xps_ll_temac_private *)
dev->priv;
+
+   xps_ll_temac_bd_init();
+   xps_ll_temac_indirect_set(0, MC, MDIO_ENABLE_MASK | MDIO_CLOCK_DIV_
100MHz);
+   
+   xps_ll_temac_addr_setup(lp);
+   xps_ll_temac_indirect_set(0, AFM, 0x00000000);  /* Promiscuos mode 
disable */
+   xps_ll_temac_indirect_set(0, RCW1, 0x10000000); /* Enable Receiver *
/
+   xps_ll_temac_indirect_set(0, TC, 0x10000000);   /* Enable 
Transmitter */
+
+}
+
+int eth_init(bd_t *bis)
+{
+   static int first = 1;
+   struct eth_device *dev;
+   struct xps_ll_temac_private *lp;
+   int i;
+
+   if(!first) return 0;
+   first = 0;
+        dev = (struct eth_device *) calloc(1, sizeof(struct eth_device))
;
+        if (NULL == dev) return 0;
+
+        lp = (struct xps_ll_temac_private *) calloc(1, sizeof(struct 
xps_ll_temac_private));
+        if (lp == NULL) return 0;
+   dev->priv = lp;
+   sprintf(dev->name, "eth0");
+
+   xps_ll_temac_init(dev, bis);
+
+   printf("%s: Xilinx XPS LocalLink Tri-Mode Ether MAC #%d at 0x%08X.\
n",
+       dev->name, 0, XPS_LLTEMAC_BASEADDR);
+
+   for(i = 0;i < 3;i++) {      
+       if(xps_ll_temac_phy_ctrl()) break;
+       udelay(10000);      /* wait second */
+   }
+   return 1;
+}
+
+int eth_send(volatile void *packet, int length)
+{
+   return xps_ll_temac_send((unsigned char *)packet, length);
+}
+
+int eth_rx(void)
+{
+   return xps_ll_temac_recv();
+}
+
+void eth_halt(void)
+{
+}
+




From sr at denx.de  Sat Apr 26 08:22:02 2008
From: sr at denx.de (Stefan Roese)
Date: Sat, 26 Apr 2008 08:22:02 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <20080425180412.1eee9b27@peedub.jennejohn.org>
References: <20080425180412.1eee9b27@peedub.jennejohn.org>
Message-ID: <200804260822.02142.sr@denx.de>

Hi Gary,

On Friday 25 April 2008, Gary Jennejohn wrote:
> Handle Stefan's comments.  This has the added benefit of making the
> patch considerably smaller.

Looks much better now. Just some minor issues (nitpicking) left. See comments 
below.

> diff --git a/board/quad100hd/quad100hd.c b/board/quad100hd/quad100hd.c
> new file mode 100644
> index 0000000..52cceee
> --- /dev/null
> +++ b/board/quad100hd/quad100hd.c
> @@ -0,0 +1,93 @@
> +/*
> + * (C) Copyright 2008
> + * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
> + *
> + * Based in part on board/icecube/icecube.c from PPCBoot
> + * (C) Copyright 2003 Intrinsyc Software
> + *
> + * 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 <common.h>
> +#include <command.h>
> +#include <malloc.h>
> +#include <environment.h>
> +#include <logbuff.h>
> +#include <post.h>
> +
> +#include <asm/processor.h>
> +#include <asm/io.h>
> +#include <asm/gpio.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +int board_early_init_f(void)
> +{
> +	/* taken from PPCBoot */
> +	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
> +	mtdcr(uicer, 0x00000000);	/* disable all ints */
> +	mtdcr(uiccr, 0x00000000);
> +	mtdcr(uicpr, 0xFFFF7FFE);	/* set int polarities */
> +	mtdcr(uictr, 0x00000000);	/* set int trigger levels */
> +	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
> +	mtdcr(uicvcr, 0x00000001);	/* set vect base=0,INT0 highest priority */
> +
> +    	mtdcr (CPC0_SRR, 0x00040000);   /* Hold PCI bridge in reset */

Please use only one coding style in one file. So either:

	func();

or

	func ();

Since this file mostly consists of the func() style I suggest you switch to 
this one completely.

> +	return 0;
> +}
> +
> +/*
> + * Check Board Identity:
> + */
> +int checkboard(void)
> +{
> +	char *s = getenv("serial#");
> +#ifdef DISPLAY_BOARD_INFO
> +	sys_info_t sysinfo;
> +#endif
> +
> +	puts("Board: Quad100hd");
> +
> +	if (s != NULL) {
> +		puts(", serial# ");
> +		puts(s);
> +	}
> +	putc('\n');
> +
> +#ifdef DISPLAY_BOARD_INFO
> +	/* taken from ppcboot */
> +	get_sys_info (&sysinfo);

Again.

> +	printf("\tVCO: %lu MHz\n", sysinfo.freqVCOMhz);
> +	printf("\tCPU: %lu MHz\n", sysinfo.freqProcessor / 1000000);
> +	printf("\tPLB: %lu MHz\n", sysinfo.freqPLB / 1000000);
> +	printf("\tOPB: %lu MHz\n", sysinfo.freqOPB / 1000000);
> +	printf("\tEPB: %lu MHz\n", sysinfo.freqPLB / (sysinfo.pllExtBusDiv *
> +		1000000));
> +	printf ("\tPCI: %lu MHz\n", sysinfo.freqPCI / 1000000);

Again.

> +#endif
> +
> +	return (0);
> +}
> +
> +long int initdram(int board_type)
> +{
> +	return (CFG_SDRAM_SIZE);
> +}

<snip>

> diff --git a/include/configs/quad100hd.h b/include/configs/quad100hd.h
> new file mode 100644
> index 0000000..89504fd
> --- /dev/null
> +++ b/include/configs/quad100hd.h
> @@ -0,0 +1,299 @@
> +/*
> + * (C) Copyright 2008
> + * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +/************************************************************************
> + * quad100hd.h - configuration for Quad100hd board
> + ***********************************************************************/
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +/*-----------------------------------------------------------------------
> + * High Level Configuration Options
> + *----------------------------------------------------------------------*/
> +#define CONFIG_QUAD100HD	1		/* Board is Quad100hd	*/
> +#define CONFIG_4xx		1		/* ... PPC4xx family	*/
> +#define CONFIG_405EP		1		/* Specifc 405EP support*/
> +
> +#define CONFIG_SYS_CLK_FREQ     33333333 /* external frequency to pll   */
> +
> +#define CONFIG_BOARD_EARLY_INIT_F 1		/* Call board_early_init_f */
> +
> +#define PLLMR0_DEFAULT		PLLMR0_266_133_66 /* no PCI */
> +#define PLLMR1_DEFAULT		PLLMR1_266_133_66 /* no PCI */
> +
> +#define CFG_ENV_IS_IN_EEPROM    1   /* use the EEPROM for environment vars
> */ +
> +#define CONFIG_OVERWRITE_ETHADDR_ONCE	1

After you removed the default MAC addresses, I suggest that you remove this 
define too.

> +#define CONFIG_NET_MULTI	1
> +#define CONFIG_HAS_ETH1		1
> +#define CONFIG_MII		1	/* MII PHY management		*/
> +#define CONFIG_PHY_ADDR		0x01	/* PHY address			*/
> +#define CFG_RX_ETH_BUFFER	16	/* Number of ethernet rx buffers &
> descriptors */ +#define CONFIG_PHY_RESET	1
> +#define CONFIG_PHY_RESET_DELAY	300	/* PHY RESET recovery delay	*/
> +
> +/*
> + * Command line configuration.
> + */
> +#include <config_cmd_default.h>
> +
> +#undef CONFIG_CMD_ASKENV
> +#undef CONFIG_CMD_CACHE
> +#define CONFIG_CMD_DHCP
> +#undef CONFIG_CMD_DIAG
> +#define CONFIG_CMD_EEPROM
> +#undef CONFIG_CMD_ELF
> +#define CONFIG_CMD_I2C
> +#undef CONFIG_CMD_IRQ
> +#define CONFIG_CMD_JFFS2
> +#undef CONFIG_CMD_LOG
> +#undef CONFIG_CMD_MII
> +#define CONFIG_CMD_NAND
> +#undef CONFIG_CMD_PING
> +#define CONFIG_CMD_REGINFO
> +
> +#undef CONFIG_WATCHDOG			/* watchdog disabled		*/
> +
> +/*-----------------------------------------------------------------------
> + * SDRAM
> + *----------------------------------------------------------------------*/
> +/*
> + * SDRAM configuration (please see cpu/ppc/sdram.[ch])
> + */
> +#define CONFIG_SDRAM_BANK0  1
> +#define CFG_SDRAM_SIZE      0x02000000      /* 32 MB */
> +
> +/* FIX! SDRAM timings used in datasheet */
> +#define CFG_SDRAM_CL            3       /* CAS latency */
> +#define CFG_SDRAM_tRP           20      /* PRECHARGE command period */
> +#define CFG_SDRAM_tRC           66      /* ACTIVE-to-ACTIVE command period
> */ +#define CFG_SDRAM_tRCD          20      /* ACTIVE-to-READ delay */
> +#define CFG_SDRAM_tRFC          66      /* Auto refresh period */ +
> +/*
> + * JFFS2
> + */
> +#define CFG_JFFS2_FIRST_BANK    0
> +#ifdef  CFG_KERNEL_IN_JFFS2
> +#define CFG_JFFS2_FIRST_SECTOR  0   /* JFFS starts at block 0 */
> +#else /* kernel not in JFFS */
> +#define CFG_JFFS2_FIRST_SECTOR  8   /* block 0-7 is kernel (1MB = 8
> sectors) */ +#endif
> +#define CFG_JFFS2_NUM_BANKS     1
> +
> +/*-----------------------------------------------------------------------
> + * Serial Port
> + *----------------------------------------------------------------------*/
> +#undef	CFG_EXT_SERIAL_CLOCK			/* external serial clock */
> +#define CFG_BASE_BAUD		691200
> +#define CONFIG_BAUDRATE		115200
> +#define CONFIG_SERIAL_MULTI
> +
> +/* The following table includes the supported baudrates */
> +#define CFG_BAUDRATE_TABLE	\
> +	{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
> +
> +/*-----------------------------------------------------------------------
> + * Miscellaneous configurable options
> + *----------------------------------------------------------------------*/
> +#define CFG_LONGHELP			/* undef to save memory		*/
> +#define CFG_PROMPT	        "=> "	/* Monitor Command Prompt	*/
> +#if defined(CONFIG_CMD_KGDB)
> +#define CFG_CBSIZE	        1024	/* Console I/O Buffer Size	*/
> +#else
> +#define CFG_CBSIZE	        256	/* Console I/O Buffer Size	*/
> +#endif
> +#define CFG_PBSIZE              (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /*
> Print Buffer Size */ +#define CFG_MAXARGS	        16	/* max number of
> command args	*/
> +#define CFG_BARGSIZE	        CFG_CBSIZE /* Boot Argument Buffer Size	*/
> +
> +#define CFG_MEMTEST_START	0x0400000 /* memtest works on		*/
> +#define CFG_MEMTEST_END		0x0C00000 /* 4 ... 12 MB in DRAM	*/
> +
> +#define CFG_LOAD_ADDR		0x100000  /* default load address	*/
> +#define CFG_EXTBDINFO		1	/* To use extended board_info (bd_t) */
> +
> +#define CFG_HZ		        1000	/* decrementer freq: 1 ms ticks	*/
> +
> +#define CONFIG_LOADS_ECHO	1	/* echo on for serial download	*/
> +#define CFG_LOADS_BAUD_CHANGE	1	/* allow baudrate change	*/
> +
> +#define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
> +#define CONFIG_LOOPW            1       /* enable loopw command         */
> +#define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands      */
> +#define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0
> */ +#define CONFIG_VERSION_VARIABLE 1	/* include version env variable */ +
> +/*-----------------------------------------------------------------------
> + * I2C
> + *----------------------------------------------------------------------*/
> +#define CONFIG_HARD_I2C		1		/* I2C with hardware support	*/
> +#undef	CONFIG_SOFT_I2C				/* I2C bit-banged		*/
> +#define CFG_I2C_SPEED		400000		/* I2C speed and slave address	*/
> +#define CFG_I2C_SLAVE		0x7F
> +
> +#define CFG_I2C_EEPROM_ADDR	0x50		/* base address */
> +#define CFG_I2C_EEPROM_ADDR_LEN	2		/* bytes of address */
> +
> +#define CFG_EEPROM_PAGE_WRITE_BITS	5	/* 8 byte write page size */
> +#define CFG_EEPROM_PAGE_WRITE_DELAY_MS	10	/* and takes up to 10 msec */
> +#define CFG_EEPROM_SIZE			0x2000
> +
> +/*-----------------------------------------------------------------------
> + * Start addresses for the final memory configuration
> + * (Set up by the startup code)
> + * Please note that CFG_SDRAM_BASE _must_ start at 0
> + */
> +#define CFG_SDRAM_BASE		0x00000000
> +#define CFG_FLASH_BASE		0xFFC00000
> +#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Monitor	*/
> +#define CFG_MALLOC_LEN		(128 * 1024)	/* Reserve 128 kB for malloc()	*/
> +#define CFG_MONITOR_BASE	0xFFF80000

CFG_MONITOR_BASE at 0xfff80000 makes me think that the U-Boot image has a size 
of 512k. But CFG_MONITOR_LEN is 256k. Which one is correct? I would think 
that 256k should be enough for this image.

> +/*
> + * For booting Linux, the board info and command line data
> + * have to be in the first 8 MB of memory, since this is
> + * the maximum mapped by the Linux kernel during initialization.
> + */
> +#define CFG_BOOTMAPSZ		(8 << 20)	/* Initial Memory map for Linux */
> +
> +/*-----------------------------------------------------------------------
> + * FLASH organization
> + */
> +#define CFG_FLASH_CFI			/* The flash is CFI compatible	*/
> +#define	CFG_FLASH_CFI_DRIVER
> +
> +#define CFG_FLASH_BANKS_LIST	{ CFG_FLASH_BASE }
> +
> +#define CFG_MAX_FLASH_BANKS	1	/* max number of memory banks	*/
> +#define CFG_MAX_FLASH_SECT	128	/* max number of sectors on one chip */

Starting here

> +#define CFG_FLASH_WORD_SIZE	unsigned short
> +#define CFG_FLASH_ADDR0		0x0555
> +#define CFG_FLASH_ADDR1		0x02aa
> +#define FLASH_BASE0_PRELIM	CFG_FLASH_BASE	/* FLASH bank #0	*/

till here. These defines are most likely not needed for the CFI driver. Please 
remove them.

Please fix and resubmit. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Sat Apr 26 09:43:33 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sat, 26 Apr 2008 09:43:33 +0200
Subject: [U-Boot-Users] Xilinx PowerPC XPS_LL_TEMAC driver
In-Reply-To: Your message of "Sat, 26 Apr 2008 11:59:20 +0900."
	<JN200804261159205.13431171@co-nss.co.jp>
Message-ID: <20080426074333.CF697248C6@gemini.denx.de>

In message <JN200804261159205.13431171 at co-nss.co.jp> you wrote:
> 
> I corrected some faults and checked normal operation by EDK10.1.
> 
> Best Regards,
> 
> Yoshio Kashiwagi - Nissin Systems

If this is supposed to be a patch submission, then please
don't forget to add your Signed-off-by line


> diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.
> c
^^^^^^^^^^^^^
> new file mode 100644
> index 0000000..2f75ebc
> --- /dev/null
> +++ b/drivers/net/xilinx_ll_temac.c
> @@ -0,0 +1,371 @@
> +/*
> + *
> + * Xilinx xps_ll_temac ethernet driver for u-boot
> + *
> + * Author: Yoshio Kashiwagi kashiwagi at co-nss.co.jp
> + *
> + * Copyright (c) 2008 Nissin Systems Co.,Ltd.
> + *
> + * March 2008 created
> + *
> + * 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
^^^^^^^^^^^^^

Patch was corrupted by your mailer (line wrapping).

...
> +/* SDMA Buffer Descriptor */
> +
> +typedef struct cdmac_bd_t {
> +   struct cdmac_bd_t *next_p;
> +   unsigned char *phys_buf_p;
> +   unsigned long buf_len;
> +   unsigned char stat;
> +   unsigned char app1_1;
> +   unsigned short app1_2;
> +   unsigned long app2;
> +   unsigned long app3;
> +   unsigned long app4;
> +   unsigned long app5;
> +} cdmac_bd __attribute((aligned(32))) ;

Indentation by TAB please (here and everywhere - please heed the
Coding Style requirements, see
http://www.denx.de/wiki/UBoot/CodingStyle

Please cleanup, fix your mailer, add a s-o-b line and resubmit.

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: wd at denx.de
There are two kinds of people, those who do the work  and  those  who
take  the  credit.  Try  to  be  in  the  first  group; there is less
competition there.                                    - Indira Gandhi



From trimarchi at gandalf.sssup.it  Sat Apr 26 10:04:52 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Sat, 26 Apr 2008 10:04:52 +0200
Subject: [U-Boot-Users] ide arm support
In-Reply-To: <20080425215125.1BE2124764@gemini.denx.de>
References: <20080425215125.1BE2124764@gemini.denx.de>
Message-ID: <4812E224.40506@gandalf.sssup.it>

Hi,

Wolfgang Denk wrote:
>
> Note: you addressed this question to the Mailing  List,  not  to  any
> specific person.
>
> Best regards,
>
> Wolfgang Denk
>

I'm sorry.

regards Michael



From achzende1955 at DenaliCapital.com  Sat Apr 26 11:19:03 2008
From: achzende1955 at DenaliCapital.com (Harrell)
Date: Sat, 26 Apr 2008 11:19:03 +0200
Subject: [U-Boot-Users] Juicy wieners get the dates
Message-ID: <E91B5228.1%achzende1955@DenaliCapital.com>

Trap her with your d\ck and slay her with all your might and will. http://www.poweieil.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080426/24f3853e/attachment.htm 

From garyj at denx.de  Sat Apr 26 12:18:02 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Sat, 26 Apr 2008 12:18:02 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <200804260822.02142.sr@denx.de>
References: <20080425180412.1eee9b27@peedub.jennejohn.org>
	<200804260822.02142.sr@denx.de>
Message-ID: <20080426121802.2c80657e@peedub.jennejohn.org>

On Sat, 26 Apr 2008 08:22:02 +0200
Stefan Roese <sr at denx.de> wrote:

Hi Stefan,

> Looks much better now. Just some minor issues (nitpicking) left. See comments 
> below.
> 
> > +	/* taken from PPCBoot */
> > +	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
> > +	mtdcr(uicer, 0x00000000);	/* disable all ints */
> > +	mtdcr(uiccr, 0x00000000);
> > +	mtdcr(uicpr, 0xFFFF7FFE);	/* set int polarities */
> > +	mtdcr(uictr, 0x00000000);	/* set int trigger levels */
> > +	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
> > +	mtdcr(uicvcr, 0x00000001);	/* set vect base=0,INT0 highest priority */
> > +
> > +    	mtdcr (CPC0_SRR, 0x00040000);   /* Hold PCI bridge in reset */
> 
> Please use only one coding style in one file. So either:
> 
> 	func();
> 
> or
> 
> 	func ();
> 
> Since this file mostly consists of the func() style I suggest you switch to 
> this one completely.
> 

Ah yes.  I copied parts of this from PPCBoot and failed to notice the
different formatting in the various places.  Thanks!

> > +#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Monitor	*/
> > +#define CFG_MALLOC_LEN		(128 * 1024)	/* Reserve 128 kB for malloc()	*/
> > +#define CFG_MONITOR_BASE	0xFFF80000
> 
> CFG_MONITOR_BASE at 0xfff80000 makes me think that the U-Boot image has a size 
> of 512k. But CFG_MONITOR_LEN is 256k. Which one is correct? I would think 
> that 256k should be enough for this image.
> 

That's a valid point.  Actually u-boot.bin is 512kB in length, but only
because there's a reset vector at 0xFFFFFFFC.  u-boot itself is really
only 256kB in size.

So now I wonder - what's correct?  If CFG_MONITOR_LEN applies to RAM,
which it seems to since it only really affects TOTAL_MALLOC_LEN, then
256kB is correct and no change is required.

> Starting here
> 
> > +#define CFG_FLASH_WORD_SIZE	unsigned short
> > +#define CFG_FLASH_ADDR0		0x0555
> > +#define CFG_FLASH_ADDR1		0x02aa
> > +#define FLASH_BASE0_PRELIM	CFG_FLASH_BASE	/* FLASH bank #0	*/
> 
> till here. These defines are most likely not needed for the CFI driver. Please 
> remove them.
> 

OK, I'll look into it.

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From wg at grandegger.com  Sat Apr 26 15:11:50 2008
From: wg at grandegger.com (Wolfgang Grandegger)
Date: Sat, 26 Apr 2008 15:11:50 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD
 AMCC	405EP-based board.
In-Reply-To: <200804260822.02142.sr@denx.de>
References: <20080425180412.1eee9b27@peedub.jennejohn.org>
	<200804260822.02142.sr@denx.de>
Message-ID: <48132A16.9010707@grandegger.com>

Hi Stefan,

Stefan Roese wrote:
> Hi Gary,
> 
> Please use only one coding style in one file. So either:
> 
> 	func();
> 
> or
> 
> 	func ();
> 
> Since this file mostly consists of the func() style I suggest you switch to 
> this one completely.

Do we really have the choice?

Wolfgang.



From trimarchi at gandalf.sssup.it  Sat Apr 26 17:38:37 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Sat, 26 Apr 2008 17:38:37 +0200
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <AA28F077645B324881335614E4F7C428034CE9@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CE9@win-ex01.bench.com>
Message-ID: <48134C7D.3030801@gandalf.sssup.it>

Hi,
> Time permitting, I will try to fix this remaining problem myself.
> Adrian, thanks for your insight into the problem and a potential
> solution.
>
> Sincerely,
>
> Ken Fuchs
>
>   
I think that is more simple to rewrite that code. It contains
duplication and errors. I start to rewrite it in my spare time and so
I hope that you will fix the remain problems.

Regards Michael




From galak at kernel.crashing.org  Sat Apr 26 18:44:44 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Sat, 26 Apr 2008 11:44:44 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] post: Fix building with O=
Message-ID: <Pine.LNX.4.64.0804261144090.865@blarg.am.freescale.net>


Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

A fix for 1.3.3

- k

 post/Makefile              |    6 +++---
 post/board/lwmon5/Makefile |    2 +-
 post/cpu/ppc4xx/Makefile   |    2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/post/Makefile b/post/Makefile
index c737729..a402e6a 100644
--- a/post/Makefile
+++ b/post/Makefile
@@ -22,7 +22,7 @@
 #

 include $(TOPDIR)/config.mk
-include $(TOPDIR)/include/autoconf.mk
+include $(OBJTREE)/include/autoconf.mk

 LIB				= libpost.a
 GPLIB-$(CONFIG_HAS_POST)	+= libgenpost.a
@@ -38,8 +38,8 @@ SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d cpu/$(CPU) ]; then echo \
 SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d board/$(BOARD) ]; then echo \
 			    "board/$(BOARD)/libpost$(BOARD).a"; fi)

-GPLIB	:= $(GPLIB-y)
-SPLIB	:= $(SPLIB-y)
+GPLIB	:= $(addprefix $(obj),$(GPLIB-y))
+SPLIB	:= $(addprefix $(obj),$(SPLIB-y))
 COBJS	:= $(COBJS-y)
 SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS))
diff --git a/post/board/lwmon5/Makefile b/post/board/lwmon5/Makefile
index 3cb6426..4e95515 100644
--- a/post/board/lwmon5/Makefile
+++ b/post/board/lwmon5/Makefile
@@ -20,7 +20,7 @@
 # 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)/include/autoconf.mk
+include $(OBJTREE)/include/autoconf.mk

 LIB	= libpostlwmon5.a

diff --git a/post/cpu/ppc4xx/Makefile b/post/cpu/ppc4xx/Makefile
index 7b13413..87ecd7c 100644
--- a/post/cpu/ppc4xx/Makefile
+++ b/post/cpu/ppc4xx/Makefile
@@ -20,7 +20,7 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-include $(TOPDIR)/include/autoconf.mk
+include $(OBJTREE)/include/autoconf.mk

 LIB	= libpostppc4xx.a

-- 
1.5.4.1




From plagnioj at jcrosoft.com  Sat Apr 26 20:40:17 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 26 Apr 2008 20:40:17 +0200
Subject: [U-Boot-Users] [RFC] AT91 reorganisation
Message-ID: <20080426184017.GA8123@game.jcrosoft.org>

Hi,

	I've plan to join the at91sam9 and at91rm9200 in
	only one arch at91 like done in linux.

	I hope this could be done for the next release.

Best Regards,
J.



From ulf.samuelsson at atmel.com  Sat Apr 26 21:18:14 2008
From: ulf.samuelsson at atmel.com (Ulf Samuelsson)
Date: Sat, 26 Apr 2008 21:18:14 +0200
Subject: [U-Boot-Users] [RFC] AT91 reorganisation
References: <20080426184017.GA8123@game.jcrosoft.org>
Message-ID: <012701c8a7d2$52929cd0$020514ac@atmel.com>



> Hi,
> 
> I've plan to join the at91sam9 and at91rm9200 in
> only one arch at91 like done in linux.
> 
> I hope this could be done for the next release.
> 
> Best Regards,
> J.
>

You are aware that they are using two different CPU cores.
Also, some stuff should maybe be common with avr32.

Best Regards
Ulf Samuelsson




From plagnioj at jcrosoft.com  Sat Apr 26 21:40:09 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sat, 26 Apr 2008 21:40:09 +0200
Subject: [U-Boot-Users] [RFC] AT91 reorganisation
In-Reply-To: <012701c8a7d2$52929cd0$020514ac@atmel.com>
References: <20080426184017.GA8123@game.jcrosoft.org>
	<012701c8a7d2$52929cd0$020514ac@atmel.com>
Message-ID: <20080426194009.GB8123@game.jcrosoft.org>

On 21:18 Sat 26 Apr     , Ulf Samuelsson wrote:
> 
> 
> > Hi,
> > 
> > I've plan to join the at91sam9 and at91rm9200 in
> > only one arch at91 like done in linux.
> > 
> > I hope this could be done for the next release.
> > 
> > Best Regards,
> > J.
> >
> 
> You are aware that they are using two different CPU cores.
> Also, some stuff should maybe be common with avr32.
Yes, I'm aware of that they are using two different CPU cores.

But they share a lot part, with avr32 too.

I think it will be good to factorize the code.

Best Regards,
J.



From felix at embedded-sol.com  Sat Apr 26 23:06:04 2008
From: felix at embedded-sol.com (Felix Radensky)
Date: Sun, 27 Apr 2008 00:06:04 +0300
Subject: [U-Boot-Users] Problems with 1.3.3-rc1 on i.MX31ADS
Message-ID: <1209243964.4426.19.camel@felix.lan>

Hi,

I've installed 1.3.3-rc1 on i.MX31ADS evaluation board
and encountered several problems

1. loadaddr environment variable (as reported by printenv)
   is defined as

	loadaddr=(0x80000000 + 0x800000)

   This results in image loaded at address 0x0, and boot gets stuck.
   Redefining loadaddr as 0x80800000 fixes the problem.

2. dhcp command is undefined, only bootp is available.

Thanks for adding i.mx31 support to u-boot. 
Hopefully i.mx27 support will follow soon.
 
Felix.




From kashiwagi at co-nss.co.jp  Sat Apr 26 23:48:24 2008
From: kashiwagi at co-nss.co.jp (Yoshio Kashiwagi)
Date: Sun, 27 Apr 2008 06:48:24 +0900
Subject: [U-Boot-Users] [PATCH] Xilinx PowerPC XPS_LL_TEMAC driver
Message-ID: <JY200804270648243.3171031@co-nss.co.jp>


Signed-off-by: Yoshio Kashiwagi <kashiwagi at co-nss.co.jp>
---
 drivers/net/Makefile          |    1 +
 drivers/net/xilinx_ll_temac.c |  371 ++++++++++++++++++++++++++++++++++
+++++++
 2 files changed, 372 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/xilinx_ll_temac.c

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d5e413b..a11238b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -63,6 +63,7 @@ COBJS-y += uli526x.o
 COBJS-y += vsc7385.o
 COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
 COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
+COBJS-$(CONFIG_XILINX_LL_TEMAC)) += xilinx_ll_temac.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.
c
new file mode 100644
index 0000000..2f75ebc
--- /dev/null
+++ b/drivers/net/xilinx_ll_temac.c
@@ -0,0 +1,371 @@
+/*
+ *
+ * Xilinx xps_ll_temac ethernet driver for u-boot
+ *
+ * Author: Yoshio Kashiwagi kashiwagi at co-nss.co.jp
+ *
+ * Copyright (c) 2008 Nissin Systems Co.,Ltd.
+ *
+ * March 2008 created
+ *
+ * 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.
+ *
+*/
+#include <config.h>
+#include <common.h>
+#include <net.h>
+#include <malloc.h>
+#include <asm/errno.h>
+#include <asm/processor.h>
+
+#define S_DMA_CTRL_BASEADDR    XPAR_LLTEMAC_0_LLINK_CONNECTED_BASEADDR
+#define XPS_LLTEMAC_BASEADDR   XPAR_LLTEMAC_0_BASEADDR
+
+/* XPS_LL_TEMAC SDMA registers definition */
+
+#define TX_NXTDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x00)
+#define TX_CURBUF_ADDR     (S_DMA_CTRL_BASEADDR + 0x04)
+#define TX_CURBUF_LENGTH   (S_DMA_CTRL_BASEADDR + 0x08)
+#define TX_CURDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x0c)
+#define TX_TAILDESC_PTR        (S_DMA_CTRL_BASEADDR + 0x10)
+#define TX_CHNL_CTRL       (S_DMA_CTRL_BASEADDR + 0x14)
+#define TX_IRQ_REG     (S_DMA_CTRL_BASEADDR + 0x18)
+#define TX_CHNL_STS        (S_DMA_CTRL_BASEADDR + 0x1c)
+
+#define RX_NXTDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x20)
+#define RX_CURBUF_ADDR     (S_DMA_CTRL_BASEADDR + 0x24)
+#define RX_CURBUF_LENGTH   (S_DMA_CTRL_BASEADDR + 0x28)
+#define RX_CURDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x2c)
+#define RX_TAILDESC_PTR        (S_DMA_CTRL_BASEADDR + 0x30)
+#define RX_CHNL_CTRL       (S_DMA_CTRL_BASEADDR + 0x34)
+#define RX_IRQ_REG     (S_DMA_CTRL_BASEADDR + 0x38)
+#define RX_CHNL_STS        (S_DMA_CTRL_BASEADDR + 0x3c)
+
+#define DMA_CONTROL_REG        (S_DMA_CTRL_BASEADDR + 0x40)
+
+/* XPS_LL_TEMAC direct registers definition */
+
+#define TEMAC_RAF0     (XPS_LLTEMAC_BASEADDR + 0x00)
+#define TEMAC_TPF0     (XPS_LLTEMAC_BASEADDR + 0x04)
+#define TEMAC_IFGP0        (XPS_LLTEMAC_BASEADDR + 0x08)
+#define TEMAC_IS0      (XPS_LLTEMAC_BASEADDR + 0x0c)
+#define TEMAC_IP0      (XPS_LLTEMAC_BASEADDR + 0x10)
+#define TEMAC_IE0      (XPS_LLTEMAC_BASEADDR + 0x14)
+
+#define TEMAC_MSW0     (XPS_LLTEMAC_BASEADDR + 0x20)
+#define TEMAC_LSW0     (XPS_LLTEMAC_BASEADDR + 0x24)
+#define TEMAC_CTL0     (XPS_LLTEMAC_BASEADDR + 0x28)
+#define TEMAC_RDY0     (XPS_LLTEMAC_BASEADDR + 0x2c)
+
+#define XTE_RSE_MIIM_RR_MASK      0x0002
+#define XTE_RSE_MIIM_WR_MASK      0x0004
+#define XTE_RSE_CFG_RR_MASK       0x0020
+#define XTE_RSE_CFG_WR_MASK       0x0040
+
+/* XPS_LL_TEMAC indirect registers offset definition */
+
+#define RCW0   0x200
+#define RCW1   0x240
+#define TC 0x280
+#define FCC    0x2c0
+#define EMMC   0x300
+#define PHYC   0x320
+#define MC 0x340
+#define UAW0   0x380
+#define UAW1   0x384
+#define MAW0   0x388
+#define MAW1   0x38c
+#define AFM    0x390
+#define TIS    0x3a0
+#define TIE    0x3a4
+#define MIIMWD 0x3b0
+#define MIIMAI 0x3b4
+
+#define CNTLREG_WRITE_ENABLE_MASK  0x8000
+#define CNTLREG_EMAC1SEL_MASK      0x0400
+#define CNTLREG_ADDRESSCODE_MASK   0x03ff
+
+#define MDIO_ENABLE_MASK   0x40
+#define MDIO_CLOCK_DIV_MASK    0x3F
+#define MDIO_CLOCK_DIV_100MHz  0x28
+
+#define ETHER_MTU      1520
+#define CACHE_LINE_SIZE        32
+
+/* SDMA descriptor status bit definitions */
+
+#define BDSTAT_ERROR_MASK       0x80
+#define BDSTAT_INT_ON_END_MASK  0x40
+#define BDSTAT_STOP_ON_END_MASK 0x20
+#define BDSTAT_COMPLETED_MASK   0x10
+#define BDSTAT_SOP_MASK         0x08
+#define BDSTAT_EOP_MASK         0x04
+#define BDSTAT_CHANBUSY_MASK    0x02
+#define BDSTAT_CHANRESET_MASK   0x01
+
+/* SDMA Buffer Descriptor */
+
+typedef struct cdmac_bd_t {
+   struct cdmac_bd_t *next_p;
+   unsigned char *phys_buf_p;
+   unsigned long buf_len;
+   unsigned char stat;
+   unsigned char app1_1;
+   unsigned short app1_2;
+   unsigned long app2;
+   unsigned long app3;
+   unsigned long app4;
+   unsigned long app5;
+} cdmac_bd __attribute((aligned(32))) ;
+
+static cdmac_bd    tx_bd;
+static cdmac_bd    rx_bd;
+static unsigned char tx_buffer[ETHER_MTU] __attribute((aligned(32)));
+static unsigned char rx_buffer[ETHER_MTU] __attribute((aligned(32)));
+
+struct xps_ll_temac_private {
+   int idx;
+   unsigned char dev_addr[6];
+};
+
+static void flush_dcache_range(unsigned int addr, unsigned size)
+{
+   unsigned int end = addr + size;
+
+   if(size) {
+       addr = addr & ~(CACHE_LINE_SIZE - 1);
+       while(addr < end) {
+           __asm__ __volatile__("dcbf 0,%0; sync;" : : "r" (addr));
+           addr += CACHE_LINE_SIZE;
+       }
+   }
+}
+
+static void invalidate_dcache_range(unsigned int addr, unsigned size)
+{
+   unsigned int end = addr + size;
+
+   if(size) {
+       addr = addr & ~(CACHE_LINE_SIZE - 1);
+       while(addr < end) {
+           __asm__ __volatile__("dcbi 0,%0; sync;" : : "r" (addr));
+           addr += CACHE_LINE_SIZE;
+       }
+   }
+}
+
+static unsigned int xps_ll_temac_hostif_get(int emac, int phy_addr, int 
reg_addr)
+{
+   *(unsigned int *)TEMAC_LSW0 = phy_addr << 5 | reg_addr;
+   *(unsigned int *)TEMAC_CTL0 = MIIMAI | emac << 10;
+
+   while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_MIIM_RR_MASK)
);
+   return *(unsigned int *)TEMAC_LSW0;
+}
+
+static void xps_ll_temac_indirect_set(int emac, int reg_offset, int 
reg_data)
+{
+   *(unsigned int *)TEMAC_LSW0 = reg_data;
+   *(unsigned int *)TEMAC_CTL0 = CNTLREG_WRITE_ENABLE_MASK | emac << 10 
| reg_offset;
+   while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_CFG_WR_MASK))
;
+}
+
+static int xps_ll_temac_phy_ctrl(void)
+{
+   static int phy_addr = -1;
+   static int link = 0;
+   int i;
+   unsigned int result;
+
+   if(phy_addr == -1) {
+       for(i = 0;i < 32;i++) {
+           result = xps_ll_temac_hostif_get(0, i, 1);
+           if((result & 0x0ffff) != 0x0ffff) {
+               phy_addr = i;
+               break;
+           }
+       }
+   } else {
+       result = xps_ll_temac_hostif_get(0, phy_addr, 1);
+   }
+   if((result & 0x24) != 0x24) {
+       if(link) {
+           link = 0;
+           printf("Link down\n");
+       }
+       return 0;
+   }
+   if(link == 0) {
+       link = 1;
+   } else {
+       return 1;
+   }
+
+   result = xps_ll_temac_hostif_get(0, phy_addr, 10);
+   if((result & 0x0800) == 0x0800) {
+       xps_ll_temac_indirect_set(0, EMMC, 0x80000000);
+       printf("1000BASE-T/FD\n");
+       return 1;
+   }
+   result = xps_ll_temac_hostif_get(0, phy_addr, 5);
+   if((result & 0x0100) == 0x0100) {
+       xps_ll_temac_indirect_set(0, EMMC, 0x40000000);
+       printf("100BASE-T/FD\n");
+   } else if((result & 0x0040) == 0x0040) {
+       xps_ll_temac_indirect_set(0, EMMC, 0x00000000);
+       printf("10BASE-T/FD\n");
+   } else {
+       printf("Half Duplex not supported\n");
+   }
+   return 1;
+}
+
+static void xps_ll_temac_bd_init(void)
+{
+   memset((void *)&tx_bd, 0, sizeof(cdmac_bd));
+   memset((void *)&rx_bd, 0, sizeof(cdmac_bd));
+   
+   rx_bd.phys_buf_p = &rx_buffer[0];
+   rx_bd.next_p = &rx_bd;
+   rx_bd.buf_len = ETHER_MTU;
+   flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
+   *(unsigned int *)RX_CURDESC_PTR = (unsigned int)&rx_bd;
+   *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;
+
+   tx_bd.phys_buf_p = &tx_buffer[0];
+   tx_bd.next_p = &tx_bd;
+   flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
+   *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
+}
+
+static int xps_ll_temac_send(unsigned char *buffer, int length)
+{
+   if(xps_ll_temac_phy_ctrl() == 0) return 0;
+
+   memcpy(tx_buffer, buffer, length);
+   flush_dcache_range((unsigned int)tx_buffer, length);
+
+   tx_bd.stat = BDSTAT_SOP_MASK | BDSTAT_EOP_MASK | BDSTAT_STOP_ON_END_
MASK;
+   tx_bd.buf_len = length;
+   flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
+
+   *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
+   *(unsigned int *)TX_TAILDESC_PTR = (unsigned int)&tx_bd; /* DMA 
start */
+
+   do {
+       invalidate_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
+   } while(!((volatile int)tx_bd.stat & BDSTAT_COMPLETED_MASK));
+
+   return length;
+}
+
+static int xps_ll_temac_recv(void)
+{
+   int length;
+
+   invalidate_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
+   if(!(rx_bd.stat & BDSTAT_COMPLETED_MASK)) return 0;
+
+   length = rx_bd.app5;
+   invalidate_dcache_range((unsigned int)rx_bd.phys_buf_p, length);
+
+   rx_bd.buf_len = ETHER_MTU;
+   rx_bd.stat = 0;
+   rx_bd.app5 = 0;
+   flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
+   *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;
+
+   if(length > 0) {
+       NetReceive(rx_bd.phys_buf_p, length);
+   }
+
+   return length;
+}
+
+static int xps_ll_temac_addr_setup(struct xps_ll_temac_private * lp)
+{
+        char * env_p;
+        char * end;
+        int    i, val;
+
+        env_p = getenv("ethaddr");
+        if (env_p == NULL) {
+                printf("cannot get enviroment for \"ethaddr\".\n");
+                return -1;
+        }
+
+        for (i = 0; i < 6; i++) {
+                lp->dev_addr[i] = env_p ? simple_strtoul(env_p, &end, 
16) : 0;
+                if (env_p) env_p = (*end) ? end + 1 : end;
+        }
+
+        /* set up unicast MAC address filter */
+        val = lp->dev_addr[3] << 24 | lp->dev_addr[2] << 16 |
+               lp->dev_addr[1] <<  8 | lp->dev_addr[0];
+   xps_ll_temac_indirect_set(0, UAW0, val);
+        val = lp->dev_addr[5] << 8 |  lp->dev_addr[4];
+   xps_ll_temac_indirect_set(0, UAW1, val);
+
+        return 0;
+}
+
+static void xps_ll_temac_init(struct eth_device *dev, bd_t *bis)
+{
+   struct xps_ll_temac_private *lp = (struct xps_ll_temac_private *)
dev->priv;
+
+   xps_ll_temac_bd_init();
+   xps_ll_temac_indirect_set(0, MC, MDIO_ENABLE_MASK | MDIO_CLOCK_DIV_
100MHz);
+   
+   xps_ll_temac_addr_setup(lp);
+   xps_ll_temac_indirect_set(0, AFM, 0x00000000);  /* Promiscuos mode 
disable */
+   xps_ll_temac_indirect_set(0, RCW1, 0x10000000); /* Enable Receiver *
/
+   xps_ll_temac_indirect_set(0, TC, 0x10000000);   /* Enable 
Transmitter */
+
+}
+
+int eth_init(bd_t *bis)
+{
+   static int first = 1;
+   struct eth_device *dev;
+   struct xps_ll_temac_private *lp;
+   int i;
+
+   if(!first) return 0;
+   first = 0;
+        dev = (struct eth_device *) calloc(1, sizeof(struct eth_device))
;
+        if (NULL == dev) return 0;
+
+        lp = (struct xps_ll_temac_private *) calloc(1, sizeof(struct 
xps_ll_temac_private));
+        if (lp == NULL) return 0;
+   dev->priv = lp;
+   sprintf(dev->name, "eth0");
+
+   xps_ll_temac_init(dev, bis);
+
+   printf("%s: Xilinx XPS LocalLink Tri-Mode Ether MAC #%d at 0x%08X.\
n",
+       dev->name, 0, XPS_LLTEMAC_BASEADDR);
+
+   for(i = 0;i < 3;i++) {      
+       if(xps_ll_temac_phy_ctrl()) break;
+       udelay(10000);      /* wait second */
+   }
+   return 1;
+}
+
+int eth_send(volatile void *packet, int length)
+{
+   return xps_ll_temac_send((unsigned char *)packet, length);
+}
+
+int eth_rx(void)
+{
+   return xps_ll_temac_recv();
+}
+
+void eth_halt(void)
+{
+}
+
-- 
1.5.3.3





From danrz at comcast.net  Sun Apr 27 04:36:07 2008
From: danrz at comcast.net (Daniel)
Date: Sat, 26 Apr 2008 20:36:07 -0600
Subject: [U-Boot-Users] Nand patch for MPC8313ERDB on U-boot 1.3.2
Message-ID: <003601c8a80f$7336dbd0$59a49370$@net>

Hi All,

I am working on a MPC8313ERDB REVA4 board and need to work with a nand
device using u-boot.  Are there any patches available to get nand working on
u-boot 1.3.2?  And if so where can I find it.  

 

Thanks

-Daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080426/4bc52ab7/attachment.htm 

From plagnioj at jcrosoft.com  Sun Apr 27 11:19:35 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Sun, 27 Apr 2008 11:19:35 +0200
Subject: [U-Boot-Users] [PATCH] Xilinx PowerPC XPS_LL_TEMAC driver
In-Reply-To: <JY200804270648243.3171031@co-nss.co.jp>
References: <JY200804270648243.3171031@co-nss.co.jp>
Message-ID: <20080427091935.GA31252@game.jcrosoft.org>

On 06:48 Sun 27 Apr     , Yoshio Kashiwagi wrote:
> 
> Signed-off-by: Yoshio Kashiwagi <kashiwagi at co-nss.co.jp>
> ---
>  drivers/net/Makefile          |    1 +
>  drivers/net/xilinx_ll_temac.c |  371 ++++++++++++++++++++++++++++++++++
> +++++++
>  2 files changed, 372 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/net/xilinx_ll_temac.c
> 
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index d5e413b..a11238b 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -63,6 +63,7 @@ COBJS-y += uli526x.o
>  COBJS-y += vsc7385.o
>  COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
>  COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
> +COBJS-$(CONFIG_XILINX_LL_TEMAC)) += xilinx_ll_temac.o
                                  ^
Please remove, it will never compile

use tab for indentation not space
and your patch is line wrapped

Best Regards,
J.



From akaahnav at Banquetzal.com.gt  Sun Apr 27 13:25:11 2008
From: akaahnav at Banquetzal.com.gt (Fassett)
Date: Sun, 27 Apr 2008 07:25:11 -0400
Subject: [U-Boot-Users] Improved formula, size increase at a shorter time
Message-ID: <1BA8D01F.B%akaahnav@Banquetzal.com.gt>

Give her multiple orgasms every night by hitting her spot http://www.Leinahel.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080427/35458cd5/attachment.htm 

From trimarchi at gandalf.sssup.it  Sun Apr 27 13:26:32 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Sun, 27 Apr 2008 13:26:32 +0200
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <AA28F077645B324881335614E4F7C428034CE9@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CE9@win-ex01.bench.com>
Message-ID: <481462E8.6010706@gandalf.sssup.it>

Hi,

I prepare a new versione of fat support to test in user space, with some 
modification of the
function. So before to post a patch in u-boot mailing list, we can 
adjust the library.

I send an archive that contains a first step in this direction

Regards Michael

Ken.Fuchs at bench.com wrote:
> Adrian Filipi wrote:
>
>   
>>  	It looks like fat.c is not handling the case where the 
>> sectors/cluster is 1, and the rood directory spans multiple clusters.
>>
>>  	In my case I was getting garbage directory info after 
>> the invalid fat error.  The attached patch stops the code
>> from rolling past the end of cluster.
>>     
>
> I was also getting these garbage directory entries which appeared
> to be file nodes being interpreted as directory nodes.
>
> I can confirm that Adrian's patch fixes this particular problem
> for FAT32.  Now, on FAT32, whatever files are displayed by fatls
> are also readable by fatload.  As Adrian mentions below, the files
> not displayed by fatls are completely inaccessible to the current
> fat.c with or without Adrian's patch.
>
> FAT16 also suffered from this "garbage" problem when there were
> 512 files, but the patch also fixes this.  (If there is a volume
> name, it should use one of the root directory entries, leaving
> only 511 directory entries for files; otherwise, the lack/presence
> of a volume name probably has no effect on FAT16.)
>
>   
>>  	It looks like a loop to walk the allocation chain is 
>> necessary.  I think get_contents() does all the right work,
>> but it of course starts with a directory entry, which we don't
>> have yet for /.  A little refactoring might do the trick.
>>     
>
> Of course this only applies to FAT32.  Adrian's patch appears to
> have fixed the only issue with FAT16 that I'm aware of.
>
> Time permitting, I will try to fix this remaining problem myself.
> Adrian, thanks for your insight into the problem and a potential
> solution.
>
> Sincerely,
>
> Ken Fuchs
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: user-uboot-fat.gz
Type: application/x-gzip
Size: 14528 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080427/52f91187/attachment.bin 

From sr at denx.de  Sun Apr 27 14:01:45 2008
From: sr at denx.de (Stefan Roese)
Date: Sun, 27 Apr 2008 14:01:45 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <20080426121802.2c80657e@peedub.jennejohn.org>
References: <20080425180412.1eee9b27@peedub.jennejohn.org>
	<200804260822.02142.sr@denx.de>
	<20080426121802.2c80657e@peedub.jennejohn.org>
Message-ID: <200804271401.45781.sr@denx.de>

On Saturday 26 April 2008, Gary Jennejohn wrote:
> > > +#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Monitor	*/
> > > +#define CFG_MALLOC_LEN		(128 * 1024)	/* Reserve 128 kB for malloc()	*/
> > > +#define CFG_MONITOR_BASE	0xFFF80000
> >
> > CFG_MONITOR_BASE at 0xfff80000 makes me think that the U-Boot image has a
> > size of 512k. But CFG_MONITOR_LEN is 256k. Which one is correct? I would
> > think that 256k should be enough for this image.
>
> That's a valid point.  Actually u-boot.bin is 512kB in length, but only
> because there's a reset vector at 0xFFFFFFFC.  u-boot itself is really
> only 256kB in size.
>
> So now I wonder - what's correct?  If CFG_MONITOR_LEN applies to RAM,
> which it seems to since it only really affects TOTAL_MALLOC_LEN, then
> 256kB is correct and no change is required.

I would change the image size to 256k to safe some space in FLASH. For this 
you have to change TEXT_BASE (in config.mk in your board directory) to 
0xfffc0000. And CFG_MONITOR_BASE too. Or even better:

#define CFG_MONITOR_BASE        (TEXT_BASE)

> > Starting here
> >
> > > +#define CFG_FLASH_WORD_SIZE	unsigned short
> > > +#define CFG_FLASH_ADDR0		0x0555
> > > +#define CFG_FLASH_ADDR1		0x02aa
> > > +#define FLASH_BASE0_PRELIM	CFG_FLASH_BASE	/* FLASH bank #0	*/
> >
> > till here. These defines are most likely not needed for the CFI driver.
> > Please remove them.
>
> OK, I'll look into it.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Sun Apr 27 14:07:39 2008
From: sr at denx.de (Stefan Roese)
Date: Sun, 27 Apr 2008 14:07:39 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <48132A16.9010707@grandegger.com>
References: <20080425180412.1eee9b27@peedub.jennejohn.org>
	<200804260822.02142.sr@denx.de> <48132A16.9010707@grandegger.com>
Message-ID: <200804271407.39875.sr@denx.de>

Hi Wolfgang,

On Saturday 26 April 2008, Wolfgang Grandegger wrote:
> > Please use only one coding style in one file. So either:
> >
> > 	func();
> >
> > or
> >
> > 	func ();
> >
> > Since this file mostly consists of the func() style I suggest you switch
> > to this one completely.
>
> Do we really have the choice?

I definitely think so. I am aware of the coding style rule set be Wolfgang to 
use the "func ()" style. But I never use this style in the files I write from 
scratch. This is because I am also doing a lot of Linux development, and here 
the "func()" style is required/preferred. And if you take a look at the code 
posted by other developers, most of it uses the "func()" style. It definitely 
seems to be more common nowadays. At least from my experience.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From monstr at seznam.cz  Sun Apr 27 14:32:07 2008
From: monstr at seznam.cz (Michal Simek)
Date: Sun, 27 Apr 2008 14:32:07 +0200
Subject: [U-Boot-Users] [PATCH] Xilinx PowerPC XPS_LL_TEMAC driver
In-Reply-To: <JY200804270648243.3171031@co-nss.co.jp>
References: <JY200804270648243.3171031@co-nss.co.jp>
Message-ID: <48147247.3030200@seznam.cz>

Hi Yoshio,

my description is in patch

> Signed-off-by: Yoshio Kashiwagi <kashiwagi at co-nss.co.jp>
> ---
>  drivers/net/Makefile          |    1 +
>  drivers/net/xilinx_ll_temac.c |  371 ++++++++++++++++++++++++++++++++++
> +++++++
>  2 files changed, 372 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/net/xilinx_ll_temac.c
> 
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index d5e413b..a11238b 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -63,6 +63,7 @@ COBJS-y += uli526x.o
>  COBJS-y += vsc7385.o
>  COBJS-$(CONFIG_XILINX_EMAC) += xilinx_emac.o
>  COBJS-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
> +COBJS-$(CONFIG_XILINX_LL_TEMAC)) += xilinx_ll_temac.o
                                 ^^
two brackets.


>  COBJS  := $(COBJS-y)
>  SRCS   := $(COBJS:.o=.c)
> diff --git a/drivers/net/xilinx_ll_temac.c b/drivers/net/xilinx_ll_temac.
> c
> new file mode 100644
> index 0000000..2f75ebc
> --- /dev/null
> +++ b/drivers/net/xilinx_ll_temac.c
> @@ -0,0 +1,371 @@
> +/*
> + *
> + * Xilinx xps_ll_temac ethernet driver for u-boot
> + *
> + * Author: Yoshio Kashiwagi kashiwagi at co-nss.co.jp
> + *
> + * Copyright (c) 2008 Nissin Systems Co.,Ltd.
> + *
> + * March 2008 created
> + *
> + * 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.
> + *
> +*/
> +#include <config.h>
> +#include <common.h>
> +#include <net.h>
> +#include <malloc.h>
> +#include <asm/errno.h>

you don't use values from errno.h. You can remove it. Microblaze cpu don't have
this header too.

> +#include <asm/processor.h>
> +
> +#define S_DMA_CTRL_BASEADDR    XPAR_LLTEMAC_0_LLINK_CONNECTED_BASEADDR
> +#define XPS_LLTEMAC_BASEADDR   XPAR_LLTEMAC_0_BASEADDR
> +
> +/* XPS_LL_TEMAC SDMA registers definition */
> +
> +#define TX_NXTDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x00)
> +#define TX_CURBUF_ADDR     (S_DMA_CTRL_BASEADDR + 0x04)
> +#define TX_CURBUF_LENGTH   (S_DMA_CTRL_BASEADDR + 0x08)
> +#define TX_CURDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x0c)
> +#define TX_TAILDESC_PTR        (S_DMA_CTRL_BASEADDR + 0x10)
> +#define TX_CHNL_CTRL       (S_DMA_CTRL_BASEADDR + 0x14)
> +#define TX_IRQ_REG     (S_DMA_CTRL_BASEADDR + 0x18)
> +#define TX_CHNL_STS        (S_DMA_CTRL_BASEADDR + 0x1c)
> +
> +#define RX_NXTDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x20)
> +#define RX_CURBUF_ADDR     (S_DMA_CTRL_BASEADDR + 0x24)
> +#define RX_CURBUF_LENGTH   (S_DMA_CTRL_BASEADDR + 0x28)
> +#define RX_CURDESC_PTR     (S_DMA_CTRL_BASEADDR + 0x2c)
> +#define RX_TAILDESC_PTR        (S_DMA_CTRL_BASEADDR + 0x30)
> +#define RX_CHNL_CTRL       (S_DMA_CTRL_BASEADDR + 0x34)
> +#define RX_IRQ_REG     (S_DMA_CTRL_BASEADDR + 0x38)
> +#define RX_CHNL_STS        (S_DMA_CTRL_BASEADDR + 0x3c)
> +
> +#define DMA_CONTROL_REG        (S_DMA_CTRL_BASEADDR + 0x40)
> +
> +/* XPS_LL_TEMAC direct registers definition */
> +
> +#define TEMAC_RAF0     (XPS_LLTEMAC_BASEADDR + 0x00)
> +#define TEMAC_TPF0     (XPS_LLTEMAC_BASEADDR + 0x04)
> +#define TEMAC_IFGP0        (XPS_LLTEMAC_BASEADDR + 0x08)
> +#define TEMAC_IS0      (XPS_LLTEMAC_BASEADDR + 0x0c)
> +#define TEMAC_IP0      (XPS_LLTEMAC_BASEADDR + 0x10)
> +#define TEMAC_IE0      (XPS_LLTEMAC_BASEADDR + 0x14)
> +
> +#define TEMAC_MSW0     (XPS_LLTEMAC_BASEADDR + 0x20)
> +#define TEMAC_LSW0     (XPS_LLTEMAC_BASEADDR + 0x24)
> +#define TEMAC_CTL0     (XPS_LLTEMAC_BASEADDR + 0x28)
> +#define TEMAC_RDY0     (XPS_LLTEMAC_BASEADDR + 0x2c)
> +
> +#define XTE_RSE_MIIM_RR_MASK      0x0002
> +#define XTE_RSE_MIIM_WR_MASK      0x0004
> +#define XTE_RSE_CFG_RR_MASK       0x0020
> +#define XTE_RSE_CFG_WR_MASK       0x0040
> +
> +/* XPS_LL_TEMAC indirect registers offset definition */
> +
> +#define RCW0   0x200
> +#define RCW1   0x240
> +#define TC 0x280
> +#define FCC    0x2c0
> +#define EMMC   0x300
> +#define PHYC   0x320
> +#define MC 0x340
> +#define UAW0   0x380
> +#define UAW1   0x384
> +#define MAW0   0x388
> +#define MAW1   0x38c
> +#define AFM    0x390
> +#define TIS    0x3a0
> +#define TIE    0x3a4
> +#define MIIMWD 0x3b0
> +#define MIIMAI 0x3b4
> +
> +#define CNTLREG_WRITE_ENABLE_MASK  0x8000
> +#define CNTLREG_EMAC1SEL_MASK      0x0400
> +#define CNTLREG_ADDRESSCODE_MASK   0x03ff
> +
> +#define MDIO_ENABLE_MASK   0x40
> +#define MDIO_CLOCK_DIV_MASK    0x3F
> +#define MDIO_CLOCK_DIV_100MHz  0x28
> +
> +#define ETHER_MTU      1520
> +#define CACHE_LINE_SIZE        32
> +
> +/* SDMA descriptor status bit definitions */
> +
> +#define BDSTAT_ERROR_MASK       0x80
> +#define BDSTAT_INT_ON_END_MASK  0x40
> +#define BDSTAT_STOP_ON_END_MASK 0x20
> +#define BDSTAT_COMPLETED_MASK   0x10
> +#define BDSTAT_SOP_MASK         0x08
> +#define BDSTAT_EOP_MASK         0x04
> +#define BDSTAT_CHANBUSY_MASK    0x02
> +#define BDSTAT_CHANRESET_MASK   0x01
> +
> +/* SDMA Buffer Descriptor */
> +
> +typedef struct cdmac_bd_t {
> +   struct cdmac_bd_t *next_p;
> +   unsigned char *phys_buf_p;
> +   unsigned long buf_len;
> +   unsigned char stat;
> +   unsigned char app1_1;
> +   unsigned short app1_2;
> +   unsigned long app2;
> +   unsigned long app3;
> +   unsigned long app4;
> +   unsigned long app5;
> +} cdmac_bd __attribute((aligned(32))) ;
> +
> +static cdmac_bd    tx_bd;
> +static cdmac_bd    rx_bd;
> +static unsigned char tx_buffer[ETHER_MTU] __attribute((aligned(32)));
> +static unsigned char rx_buffer[ETHER_MTU] __attribute((aligned(32)));
> +
> +struct xps_ll_temac_private {
> +   int idx;
> +   unsigned char dev_addr[6];
> +};
> +
> +static void flush_dcache_range(unsigned int addr, unsigned size)
> +{
> +   unsigned int end = addr + size;
> +
> +   if(size) {
> +       addr = addr & ~(CACHE_LINE_SIZE - 1);
> +       while(addr < end) {
> +           __asm__ __volatile__("dcbf 0,%0; sync;" : : "r" (addr));
> +           addr += CACHE_LINE_SIZE;
> +       }
> +   }
> +}

Your previous set of patches was better than this style. You can't add assembler
code to c code which is not in ppc specific folder. Please use macros for it.

> +static void invalidate_dcache_range(unsigned int addr, unsigned size)
> +{
> +   unsigned int end = addr + size;
> +
> +   if(size) {
> +       addr = addr & ~(CACHE_LINE_SIZE - 1);
> +       while(addr < end) {
> +           __asm__ __volatile__("dcbi 0,%0; sync;" : : "r" (addr));
> +           addr += CACHE_LINE_SIZE;
> +       }
> +   }
> +}
> +
> +static unsigned int xps_ll_temac_hostif_get(int emac, int phy_addr, int 
> reg_addr)
> +{
> +   *(unsigned int *)TEMAC_LSW0 = phy_addr << 5 | reg_addr;
> +   *(unsigned int *)TEMAC_CTL0 = MIIMAI | emac << 10;
> +
> +   while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_MIIM_RR_MASK)
> );
> +   return *(unsigned int *)TEMAC_LSW0;
> +}
> +
> +static void xps_ll_temac_indirect_set(int emac, int reg_offset, int 
> reg_data)
> +{
> +   *(unsigned int *)TEMAC_LSW0 = reg_data;
> +   *(unsigned int *)TEMAC_CTL0 = CNTLREG_WRITE_ENABLE_MASK | emac << 10 
> | reg_offset;
> +   while(! (*(volatile unsigned int *)TEMAC_RDY0 & XTE_RSE_CFG_WR_MASK))
> ;
> +}
> +
> +static int xps_ll_temac_phy_ctrl(void)
> +{
> +   static int phy_addr = -1;
> +   static int link = 0;
> +   int i;
> +   unsigned int result;
> +
> +   if(phy_addr == -1) {
> +       for(i = 0;i < 32;i++) {
> +           result = xps_ll_temac_hostif_get(0, i, 1);
> +           if((result & 0x0ffff) != 0x0ffff) {
> +               phy_addr = i;
> +               break;
> +           }
> +       }
> +   } else {
> +       result = xps_ll_temac_hostif_get(0, phy_addr, 1);
> +   }
> +   if((result & 0x24) != 0x24) {
> +       if(link) {
> +           link = 0;
> +           printf("Link down\n");
> +       }
> +       return 0;
> +   }
> +   if(link == 0) {
> +       link = 1;
> +   } else {
> +       return 1;
> +   }
> +
> +   result = xps_ll_temac_hostif_get(0, phy_addr, 10);
> +   if((result & 0x0800) == 0x0800) {
> +       xps_ll_temac_indirect_set(0, EMMC, 0x80000000);
> +       printf("1000BASE-T/FD\n");
> +       return 1;
> +   }
> +   result = xps_ll_temac_hostif_get(0, phy_addr, 5);
> +   if((result & 0x0100) == 0x0100) {
> +       xps_ll_temac_indirect_set(0, EMMC, 0x40000000);
> +       printf("100BASE-T/FD\n");
> +   } else if((result & 0x0040) == 0x0040) {
> +       xps_ll_temac_indirect_set(0, EMMC, 0x00000000);
> +       printf("10BASE-T/FD\n");
> +   } else {
> +       printf("Half Duplex not supported\n");
> +   }
> +   return 1;
> +}
> +
> +static void xps_ll_temac_bd_init(void)
> +{
> +   memset((void *)&tx_bd, 0, sizeof(cdmac_bd));
> +   memset((void *)&rx_bd, 0, sizeof(cdmac_bd));
> +   
> +   rx_bd.phys_buf_p = &rx_buffer[0];
> +   rx_bd.next_p = &rx_bd;
> +   rx_bd.buf_len = ETHER_MTU;
> +   flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
> +   *(unsigned int *)RX_CURDESC_PTR = (unsigned int)&rx_bd;
> +   *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;
> +
> +   tx_bd.phys_buf_p = &tx_buffer[0];
> +   tx_bd.next_p = &tx_bd;
> +   flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
> +   *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
> +}
> +
> +static int xps_ll_temac_send(unsigned char *buffer, int length)
> +{
> +   if(xps_ll_temac_phy_ctrl() == 0) return 0;
> +
> +   memcpy(tx_buffer, buffer, length);
> +   flush_dcache_range((unsigned int)tx_buffer, length);
> +
> +   tx_bd.stat = BDSTAT_SOP_MASK | BDSTAT_EOP_MASK | BDSTAT_STOP_ON_END_
> MASK;
> +   tx_bd.buf_len = length;
> +   flush_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
> +
> +   *(unsigned int *)TX_CURDESC_PTR = (unsigned int)&tx_bd;
> +   *(unsigned int *)TX_TAILDESC_PTR = (unsigned int)&tx_bd; /* DMA 
> start */
> +
> +   do {
> +       invalidate_dcache_range((unsigned int)&tx_bd, sizeof(cdmac_bd));
> +   } while(!((volatile int)tx_bd.stat & BDSTAT_COMPLETED_MASK));
> +
> +   return length;
> +}
> +
> +static int xps_ll_temac_recv(void)
> +{
> +   int length;
> +
> +   invalidate_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
> +   if(!(rx_bd.stat & BDSTAT_COMPLETED_MASK)) return 0;
> +
> +   length = rx_bd.app5;
> +   invalidate_dcache_range((unsigned int)rx_bd.phys_buf_p, length);
> +
> +   rx_bd.buf_len = ETHER_MTU;
> +   rx_bd.stat = 0;
> +   rx_bd.app5 = 0;
> +   flush_dcache_range((unsigned int)&rx_bd, sizeof(cdmac_bd));
> +   *(unsigned int *)RX_TAILDESC_PTR = (unsigned int)&rx_bd;
> +
> +   if(length > 0) {
> +       NetReceive(rx_bd.phys_buf_p, length);
> +   }
> +
> +   return length;
> +}
> +
> +static int xps_ll_temac_addr_setup(struct xps_ll_temac_private * lp)
> +{
> +        char * env_p;
> +        char * end;
> +        int    i, val;
> +
> +        env_p = getenv("ethaddr");
> +        if (env_p == NULL) {
> +                printf("cannot get enviroment for \"ethaddr\".\n");
> +                return -1;
> +        }
> +
> +        for (i = 0; i < 6; i++) {
> +                lp->dev_addr[i] = env_p ? simple_strtoul(env_p, &end, 
> 16) : 0;
> +                if (env_p) env_p = (*end) ? end + 1 : end;
> +        }
> +
> +        /* set up unicast MAC address filter */
> +        val = lp->dev_addr[3] << 24 | lp->dev_addr[2] << 16 |
> +               lp->dev_addr[1] <<  8 | lp->dev_addr[0];
> +   xps_ll_temac_indirect_set(0, UAW0, val);
> +        val = lp->dev_addr[5] << 8 |  lp->dev_addr[4];
> +   xps_ll_temac_indirect_set(0, UAW1, val);
> +
> +        return 0;
> +}
> +
> +static void xps_ll_temac_init(struct eth_device *dev, bd_t *bis)
> +{
> +   struct xps_ll_temac_private *lp = (struct xps_ll_temac_private *)
> dev->priv;
> +
> +   xps_ll_temac_bd_init();
> +   xps_ll_temac_indirect_set(0, MC, MDIO_ENABLE_MASK | MDIO_CLOCK_DIV_
> 100MHz);
> +   
> +   xps_ll_temac_addr_setup(lp);
> +   xps_ll_temac_indirect_set(0, AFM, 0x00000000);  /* Promiscuos mode 
> disable */
> +   xps_ll_temac_indirect_set(0, RCW1, 0x10000000); /* Enable Receiver *
> /
> +   xps_ll_temac_indirect_set(0, TC, 0x10000000);   /* Enable 
> Transmitter */
> +
> +}
> +
> +int eth_init(bd_t *bis)
> +{
> +   static int first = 1;
> +   struct eth_device *dev;
> +   struct xps_ll_temac_private *lp;
> +   int i;
> +
> +   if(!first) return 0;
> +   first = 0;
> +        dev = (struct eth_device *) calloc(1, sizeof(struct eth_device))
> ;
> +        if (NULL == dev) return 0;
> +
> +        lp = (struct xps_ll_temac_private *) calloc(1, sizeof(struct 
> xps_ll_temac_private));
> +        if (lp == NULL) return 0;
> +   dev->priv = lp;
> +   sprintf(dev->name, "eth0");
> +
> +   xps_ll_temac_init(dev, bis);
> +
> +   printf("%s: Xilinx XPS LocalLink Tri-Mode Ether MAC #%d at 0x%08X.\
> n",
> +       dev->name, 0, XPS_LLTEMAC_BASEADDR);
> +
> +   for(i = 0;i < 3;i++) {      
> +       if(xps_ll_temac_phy_ctrl()) break;
> +       udelay(10000);      /* wait second */
> +   }
> +   return 1;
> +}
> +
> +int eth_send(volatile void *packet, int length)
> +{
> +   return xps_ll_temac_send((unsigned char *)packet, length);
> +}
> +
> +int eth_rx(void)
> +{
> +   return xps_ll_temac_recv();
> +}
> +
> +void eth_halt(void)
> +{
> +}
> +

BTW. Good work. Please clean it and resubmit.
I check it again.

Regards,
Michal Simek



From lg at denx.de  Sun Apr 27 22:14:39 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Sun, 27 Apr 2008 22:14:39 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] mx31ads: fix loadaddr environment variable
	define
In-Reply-To: <1209243964.4426.19.camel@felix.lan>
References: <1209243964.4426.19.camel@felix.lan>
Message-ID: <Pine.LNX.4.64.0804272210370.6246@axis700.grange>

Arithmetic expressions do not get evaluated under stringification.
Thanks to Felix Radensky for reporting.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

On Sun, 27 Apr 2008, Felix Radensky wrote:

> I've installed 1.3.3-rc1 on i.MX31ADS evaluation board
> and encountered several problems
> 
> 1. loadaddr environment variable (as reported by printenv)
>    is defined as
> 
> 	loadaddr=(0x80000000 + 0x800000)
> 
>    This results in image loaded at address 0x0, and boot gets stuck.
>    Redefining loadaddr as 0x80800000 fixes the problem.

Thanks for reporting, patch below. Feel free to add your Acked- or 
Tested-by.

> 2. dhcp command is undefined, only bootp is available.

It wasn't needed in the environment the configuration has been programmed 
for. Patches are welcome:-)

Thanks
Guennadi

 include/configs/mx31ads.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index 5286e1f..301afd5 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -87,7 +87,7 @@
 #define CONFIG_NETMASK		255.255.255.0
 #define CONFIG_IPADDR		192.168.23.168
 #define CONFIG_SERVERIP		192.168.23.2
-#define CONFIG_LOADADDR		(CSD0_BASE + 0x800000)	/* loadaddr env var */
+#define CONFIG_LOADADDR		0x80800000	/* loadaddr env var */
 
 #define	CONFIG_EXTRA_ENV_SETTINGS					\
 	"netdev=eth0\0"							\
-- 
1.5.4


> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 

---
Guennadi Liakhovetski



From wd at denx.de  Sun Apr 27 23:37:09 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 27 Apr 2008 23:37:09 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: Your message of "Sat, 26 Apr 2008 15:11:50 +0200."
	<48132A16.9010707@grandegger.com>
Message-ID: <20080427213709.23E9124764@gemini.denx.de>

In message <48132A16.9010707 at grandegger.com> you wrote:
> 
> > Since this file mostly consists of the func() style I suggest you switch to 
> > this one completely.
> 
> Do we really have the choice?

The README says:

    All contributions to U-Boot should conform to the Linux kernel
    coding style; see the file "Documentation/CodingStyle" and the script
    "scripts/Lindent" in your Linux kernel source directory.  In sources
    originating from U-Boot a style corresponding to "Lindent -pcs" (adding
    spaces before parameters to function calls) is actually used.

    Source files originating from a different project (for example the
    MTD subsystem) are generally exempt from these guidelines and are not
    reformated to ease subsequent migration to newer versions of those
    sources.


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: wd at denx.de
Change is the essential process of all existence.
	-- Spock, "Let That Be Your Last Battlefield",
	   stardate 5730.2



From wd at denx.de  Sun Apr 27 23:39:52 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 27 Apr 2008 23:39:52 +0200
Subject: [U-Boot-Users] FW: USB SUPPORT & get_vfatname
In-Reply-To: Your message of "Sun, 27 Apr 2008 13:26:32 +0200."
	<481462E8.6010706@gandalf.sssup.it>
Message-ID: <20080427213952.5B78A24764@gemini.denx.de>

In message <481462E8.6010706 at gandalf.sssup.it> you wrote:
> 
> I prepare a new versione of fat support to test in user space, with some 
> modification of the
> function. So before to post a patch in u-boot mailing list, we can 
> adjust the library.
> 
> I send an archive that contains a first step in this direction

Please don;t do that.

Please ALWAYS send proper patches, inlined, and plain text.

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: wd at denx.de
I have yet to add the ESP-driver to the kernel to read  the  mind  of
the user...                                       - Linus Torvalds in
      <Pine.LNX.3.91.960426110644.24860I-100000 at linux.cs.Helsinki.FI>



From wd at denx.de  Sun Apr 27 23:41:31 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 27 Apr 2008 23:41:31 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: Your message of "Sun, 27 Apr 2008 14:07:39 +0200."
	<200804271407.39875.sr@denx.de>
Message-ID: <20080427214131.9BA7424764@gemini.denx.de>

In message <200804271407.39875.sr at denx.de> you wrote:
> 
> I definitely think so. I am aware of the coding style rule set be Wolfgang to 

You are definitely wrong.

> use the "func ()" style. But I never use this style in the files I write from 

You mean you intentionally ignore the rules?

That's not nice.

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: wd at denx.de
miracle:  an  extremely  outstanding  or  unusual  event,  thing,  or
accomplishment.                                - Webster's Dictionary



From wd at denx.de  Sun Apr 27 23:44:42 2008
From: wd at denx.de (Wolfgang Denk)
Date: Sun, 27 Apr 2008 23:44:42 +0200
Subject: [U-Boot-Users] [PATCH] mx31ads: fix loadaddr environment
	variable define
In-Reply-To: Your message of "Sun, 27 Apr 2008 22:14:39 +0200."
	<Pine.LNX.4.64.0804272210370.6246@axis700.grange>
Message-ID: <20080427214442.804C724764@gemini.denx.de>

In message <Pine.LNX.4.64.0804272210370.6246 at axis700.grange> you wrote:
>
> > 2. dhcp command is undefined, only bootp is available.
> 
> It wasn't needed in the environment the configuration has been programmed 
> for. Patches are welcome:-)

Please add it. It's default...

> Thanks
> Guennadi
> 
>  include/configs/mx31ads.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
> index 5286e1f..301afd5 100644
> --- a/include/configs/mx31ads.h
> +++ b/include/configs/mx31ads.h
> @@ -87,7 +87,7 @@
>  #define CONFIG_NETMASK		255.255.255.0
>  #define CONFIG_IPADDR		192.168.23.168
>  #define CONFIG_SERVERIP		192.168.23.2
> -#define CONFIG_LOADADDR		(CSD0_BASE + 0x800000)	/* loadaddr env var */
> +#define CONFIG_LOADADDR		0x80800000	/* loadaddr env var */

And while we are at it: Please remove all these default network
settings. I don't like these at all.

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: wd at denx.de
The further the spiritual evolution of  mankind  advances,  the  more
certain  it seems to me that the path to genuine religiosity does not
lie through the fear of life, and the fear of death, and blind faith,
but through striving after rational knowledge.      - Albert Einstein



From trimarchi at gandalf.sssup.it  Mon Apr 28 00:05:18 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Mon, 28 Apr 2008 00:05:18 +0200
Subject: [U-Boot-Users] FW: USB SUPPORT & get_vfatname
In-Reply-To: <20080427213952.5B78A24764@gemini.denx.de>
References: <20080427213952.5B78A24764@gemini.denx.de>
Message-ID: <4814F89E.2050101@gandalf.sssup.it>

Hi,
Wolfgang Denk wrote:
>
> Please don;t do that.
>
> Please ALWAYS send proper patches, inlined, and plain text.
>
> Best regards,
>
> Wolfgang Denk
>
>   
You are right. I try to fix this problem. I don't send a patch but
a user space version to help who want to fix fat32 problem on
u-boot. I don't send any more archive on the mailing list.

Regards
Michael




From lg at denx.de  Mon Apr 28 00:25:32 2008
From: lg at denx.de (Guennadi Liakhovetski)
Date: Mon, 28 Apr 2008 00:25:32 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH v2] mx31ads: fix loadaddr environment
	variable define
In-Reply-To: <20080427214442.804C724764@gemini.denx.de>
References: <20080427214442.804C724764@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804280014100.6246@axis700.grange>

Arithmetic expressions do not get evaluated under stringification. Remove 
default network configuration, add DHCP command support. Thanks to Felix 
Radensky for reporting.

Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

---

On Sun, 27 Apr 2008, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0804272210370.6246 at axis700.grange> you wrote:
> >
> > > 2. dhcp command is undefined, only bootp is available.
> > 
> > It wasn't needed in the environment the configuration has been programmed 
> > for. Patches are welcome:-)
> 
> Please add it. It's default...

Hm, but it isn't in

#include <config_cmd_default.h>

?

> > diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
> > index 5286e1f..301afd5 100644
> > --- a/include/configs/mx31ads.h
> > +++ b/include/configs/mx31ads.h
> > @@ -87,7 +87,7 @@
> >  #define CONFIG_NETMASK		255.255.255.0
> >  #define CONFIG_IPADDR		192.168.23.168
> >  #define CONFIG_SERVERIP		192.168.23.2
> > -#define CONFIG_LOADADDR		(CSD0_BASE + 0x800000)	/* loadaddr env var */
> > +#define CONFIG_LOADADDR		0x80800000	/* loadaddr env var */
> 
> And while we are at it: Please remove all these default network
> settings. I don't like these at all.

Is this one better?

diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index 5286e1f..7614b95 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -79,15 +79,13 @@
 #include <config_cmd_default.h>
 
 #define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
 #define CONFIG_CMD_SPI
 #define CONFIG_CMD_DATE
 
 #define CONFIG_BOOTDELAY	3
 
-#define CONFIG_NETMASK		255.255.255.0
-#define CONFIG_IPADDR		192.168.23.168
-#define CONFIG_SERVERIP		192.168.23.2
-#define CONFIG_LOADADDR		(CSD0_BASE + 0x800000)	/* loadaddr env var */
+#define CONFIG_LOADADDR		0x80800000	/* loadaddr env var */
 
 #define	CONFIG_EXTRA_ENV_SETTINGS					\
 	"netdev=eth0\0"							\



From wd at denx.de  Mon Apr 28 00:55:18 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 00:55:18 +0200
Subject: [U-Boot-Users] [PATCH] post: Fix building with O=
In-Reply-To: Your message of "Sat, 26 Apr 2008 11:44:44 CDT."
	<Pine.LNX.4.64.0804261144090.865@blarg.am.freescale.net>
Message-ID: <20080427225518.53790247AF@gemini.denx.de>

In message <Pine.LNX.4.64.0804261144090.865 at blarg.am.freescale.net> you wrote:
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
> 
> A fix for 1.3.3
> 
> - k
> 
>  post/Makefile              |    6 +++---
>  post/board/lwmon5/Makefile |    2 +-
>  post/cpu/ppc4xx/Makefile   |    2 +-
>  3 files changed, 5 insertions(+), 5 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: wd at denx.de
When a man sits with a pretty girl for  an  hour,  it  seems  like  a
minute.  But let him sit on a hot stove for a minute -- and it's lon-
ger than any hour. That's relativity.              -- Albert Einstein



From niklausgiger at gmx.ch  Mon Apr 28 07:30:10 2008
From: niklausgiger at gmx.ch (Niklaus Giger)
Date: Mon, 28 Apr 2008 07:30:10 +0200
Subject: [U-Boot-Users] ppc4xx: Unable to clone git repository from denx
In-Reply-To: <m263u5zwb1.fsf@ohwell.denx.de>
References: <200804251801.28858.niklausgiger@gmx.ch>
	<m263u5zwb1.fsf@ohwell.denx.de>
Message-ID: <200804280730.11006.niklausgiger@gmx.ch>

Am Freitag 25 April 2008 19:19:46 schrieb Detlev Zundel:
> Hi Niklaus,
> 
> > Hi
> >
> > I wanted to get Stefan's git and got the following error:
> >> $ git clone http://www.denx.de/git/u-boot-ppc4xx.git/ work 
> > <...>
> >> Getting pack list for http://www.denx.de/u-boot.git/
> >> error: Unable to find f616ab96cc773d1719761d511a8649c9aa6eb473 under
> >> http://www.denx.de/git/u-boot-ppc4xx.git Cannot obtain needed blob
> >> f616ab96cc773d1719761d511a8649c9aa6eb473 while processing commit
> >> 60bbcad0e2e7007a36a1cb42c664b0662ae0c9f1.
> >
> > It would be nice if this error could be fixed. But I will go home for the weekend
> > in a few minutes.
> 
> Hm.  It seems like its not easy to transparently support both
> www.denx.de and git.denx.de accesses over http.
> 
> Please try
> 
> git clone http://git.denx.de/u-boot-ppc4xx
Trying this new URL gives me here:
$ git clone http://git.denx.de/u-boot-ppc4xx
Initialized empty Git repository in /home/ng/u-boot/u-boot-ppc4xx/.git/
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
But ping does work:
$ ping git.denx.de
PING theia.denx.de (85.214.87.163) 56(84) bytes of data.
64 bytes from theia.denx.de (85.214.87.163): icmp_seq=1 ttl=53 time=29.4 ms

The old URL still has the same error as mentioned above.

> This works for me.  I'll see what I can do to support the old URL.
It's no big deal to change the URL. A clear error message would be nice.

Best regards

Niklaus



From raajesh.n at indiatimes.com  Mon Apr 28 08:37:19 2008
From: raajesh.n at indiatimes.com (raajesh.n at indiatimes.com)
Date: Mon, 28 Apr 2008 12:07:19 +0530 (IST)
Subject: [U-Boot-Users] Newbie in U-Boot, Some Queries
Message-ID: <253166975.210981209364639412.JavaMail.root@mbv4.indiatimes.com>


HI ,

I am newbie to U-Boot, I have a customized  board with u-boot with it, I have seen through top level makefile of  U-Boot.Below stated is what I have observed from makefile.

 1. First initialization of processor (ARM922t in my case) is done in CPU folder with Startup.S where this assembly routine will call low_level_init code for initialization of RAM of customized board.

 2. Further I have observed rest all code which are required for boot-up is made as library and compiled at once.

 I would like to know how the code flow of U-Boot takes place , which are all the files which will be called in sequence while boot operation takes place, as far I have seen the code, Startup.S is one which starts first clearing Stack & PC which will further calls low_level_Init, I am unable to know how U-Boot works further from this place.

I would request U-Boot users to share there knowledge in explaining me how the code flow of U-Boot takes place, which will help me in finishing my project where RAM & Flash is changed.


Best Regards,
Rajesh



From super.firetwister at googlemail.com  Mon Apr 28 08:47:47 2008
From: super.firetwister at googlemail.com (Markus Brunner)
Date: Mon, 28 Apr 2008 08:47:47 +0200
Subject: [U-Boot-Users] [PATCH][resend] ppc4xx fixup ebc clock in FDT for
	405GP/EP
Message-ID: <200804280847.48012.super.firetwister@gmail.com>

On ppc405EP and ppc405GP (at least) the ebc is directly attached to the plb and not to the opb. 
This patch will try to fixup /plb/ebc if /plb/opb/ebc doesn't exist.

Signed-off-by: Markus Brunner <super.firetwister at gmail.com>
---
This time against latest u-boot-ppc4xx repository

diff --git a/cpu/ppc4xx/fdt.c b/cpu/ppc4xx/fdt.c
index 1f4d6f2..02dece0 100644
--- a/cpu/ppc4xx/fdt.c
+++ b/cpu/ppc4xx/fdt.c
@@ -83,8 +83,14 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 			     bd->bi_intfreq, 1);
 	do_fixup_by_path_u32(blob, "/plb", "clock-frequency", sys_info.freqPLB, 1);
 	do_fixup_by_path_u32(blob, "/plb/opb", "clock-frequency", sys_info.freqOPB, 1);
-	do_fixup_by_path_u32(blob, "/plb/opb/ebc", "clock-frequency",
-			     sys_info.freqEBC, 1);
+
+	if (fdt_path_offset(blob, "/plb/opb/ebc") >= 0)
+		do_fixup_by_path_u32(blob, "/plb/opb/ebc", "clock-frequency",
+			sys_info.freqEBC, 1);
+	else
+		do_fixup_by_path_u32(blob, "/plb/ebc", "clock-frequency",
+			sys_info.freqEBC, 1);
+
 	fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
 
 	/*



From galak at kernel.crashing.org  Mon Apr 28 09:24:04 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Mon, 28 Apr 2008 02:24:04 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx: Additional fixes and cleanup of MP code
Message-ID: <Pine.LNX.4.64.0804280223420.4305@blarg.am.freescale.net>

* adjust __spin_table alignment to match ePAPR v0.94 spec
* loop over all cpus when determing who is up.  This fixes an issue if
  the "boot cpu" isn't core0.  The "boot cpu" will already be in the
  cpu_up_mask so there is no harm
* Added some protection in the code to ensure proper behavior.  These
  changes are explicitly needed but don't hurt:
  - Added eieio to ensure the "hot word" of the table is written after
    all other table updates have occurred.
  - Added isync to ensure we don't prefetch loading of table entries
    until we a released

These issues we raised by Dave Liu.

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

For 1.3.3

 cpu/mpc85xx/mp.c      |    6 +++++-
 cpu/mpc85xx/release.S |    3 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
index e733f7b..a527cf3 100644
--- a/cpu/mpc85xx/mp.c
+++ b/cpu/mpc85xx/mp.c
@@ -103,6 +103,10 @@ int cpu_release(int nr, int argc, char *argv[])
 	}

 	table[BOOT_ENTRY_ADDR_UPPER] = (u32)(boot_addr >> 32);
+
+	/* ensure all table updates complete before final address write */
+	eieio();
+
 	table[BOOT_ENTRY_ADDR_LOWER] = (u32)(boot_addr & 0xffffffff);

 	return 0;
@@ -153,7 +157,7 @@ static void pq3_mp_up(unsigned long bootpg)
 	/* wait for everyone */
 	while (timeout) {
 		int i;
-		for (i = 1; i < CONFIG_NR_CPUS; i++) {
+		for (i = 0; i < CONFIG_NR_CPUS; i++) {
 			if (table[i * NUM_BOOT_ENTRY + BOOT_ENTRY_ADDR_LOWER])
 				cpu_up_mask |= (1 << i);
 		};
diff --git a/cpu/mpc85xx/release.S b/cpu/mpc85xx/release.S
index 3b7366f..a47edae 100644
--- a/cpu/mpc85xx/release.S
+++ b/cpu/mpc85xx/release.S
@@ -114,6 +114,7 @@ __secondary_start_page:
 	lwz	r4,ENTRY_ADDR_LOWER(r10)
 	andi.	r11,r4,1
 	bne	2b
+	isync

 	/* get the upper bits of the addr */
 	lwz	r11,ENTRY_ADDR_UPPER(r10)
@@ -169,7 +170,7 @@ __secondary_start_page:
 	mtspr	SPRN_SRR1,r13
 	rfi

-	.align 3
+	.align L1_CACHE_SHIFT
 	.globl __spin_table
 __spin_table:
 	.space CONFIG_NR_CPUS*ENTRY_SIZE
-- 
1.5.4.1




From iwamatsu at nigauri.org  Mon Apr 28 10:00:42 2008
From: iwamatsu at nigauri.org (Nobuhiro Iwamatsu)
Date: Mon, 28 Apr 2008 17:00:42 +0900
Subject: [U-Boot-Users] [PATCH][RFC] pci: Remove CONFIG_PCI_SKIP_HOST_BRIDGE
 and Add check PCI class of host bridge (Re: PCI stopped working on MPC8343)
In-Reply-To: <200804181657.16177.sr@denx.de>
References: <480883E6.5000304@matrix-vision.de> <4808AD5C.8080202@acm.org>
	<200804181657.16177.sr@denx.de>
Message-ID: <20080428170042.386ac2d6.iwamatsu@nigauri.org>

Hi, all.

Sorry for the delay.

On Fri, 18 Apr 2008 16:57:15 +0200
Stefan Roese <sr at denx.de> wrote:

> > The patch changes the behavior of the code _unless_
> > CONFIG_PCI_SKIP_HOST_BRIDGE is defined.  Defining that switch in the
> > Korat configuration fixes the problem.  The MPC8323ERDB configuration
> > has also been patched to add the switch, so maybe this is is the cause
> > of your problem as well.
> >
> > I was going to submit the patch for Korat, but then decided I'd first
> > like to ask Nobuhiro and the group whether it might not be better to
> > change the occurrences of
> >
> > #if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
> >
> > in "drivers/pci/pci.c" to
> >
> > #if !defined(CONFIG_PCI_NO_SKIP_HOST_BRIDGE)
> >
> > That would allow those boards that need to patch to specify it
> > explicity, while leaving the default functionality unchanged.
> >
> > Comments?
> 
> Yes, I totally agree. Patches should *not* change the default behavior. We 
> should change it as you suggested. Sorry, I must have missed this.
> 
> Nobuhiro, could you please send a new patch to fix this problem?

Thank you for your check.
It has troubled you with my patch. 

I rewirte new patch . Could you please check this patch and confirming the work?

Best regards,
 Nobuhiro 
-- 
Nobuhiro Iwamatsu

---
Remove CONFIG_PCI_SKIP_HOST_BRIDGE from drivers/pci/pci.c.
Add check PCI class of host bridge(CPU to PCI bridge).

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu at nigauri.org>
---
 drivers/pci/pci.c |   20 ++++++++------------
 1 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7944b66..129a6c9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -425,14 +425,15 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)
 	     dev <  PCI_BDF(bus,PCI_MAX_PCI_DEVICES-1,PCI_MAX_PCI_FUNCTIONS-1);
 	     dev += PCI_BDF(0,0,1))
 	{
-
-	/* Bus 0 is not necessarily PCI bridge. */
-#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
+		/* Read class register */
+		pci_hose_read_config_word(hose, dev, PCI_CLASS_DEVICE, &class);
 		/* Skip our host bridge */
-		if ( dev == PCI_BDF(hose->first_busno,0,0) ) {
-#if defined(CONFIG_PCI_CONFIG_HOST_BRIDGE)              /* don't skip host bridge */
+		if ( (dev == PCI_BDF(hose->first_busno,0,0)) &&
+			(class == 0x0600)) { /* CPU to PCI bridge */
+#if defined(CONFIG_PCI_CONFIG_HOST_BRIDGE) /* don't skip host bridge */
 			/*
-			 * Only skip hostbridge configuration if "pciconfighost" is not set
+			 * Only skip hostbridge configuration if 
+			 * "pciconfighost" is not set
 			 */
 			if (getenv("pciconfighost") == NULL) {
 				continue; /* Skip our host bridge */
@@ -441,8 +442,6 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)
 			continue; /* Skip our host bridge */
 #endif /* CONFIG_PCI_CONFIG_HOST_BRIDGE */
 		}
-#endif /* CONFIG_PCI_SKIP_HOST_BRIDGE */
-
 		if (PCI_FUNC(dev) && !found_multi)
 			continue;
 
@@ -477,11 +476,8 @@ int pci_hose_scan_bus(struct pci_controller *hose, int bus)
 				hose->fixup_irq(hose, dev);
 
 #ifdef CONFIG_PCI_SCAN_SHOW
-#if defined(CONFIG_PCI_SKIP_HOST_BRIDGE)
 			/* Skip our host bridge */
-			if ( dev != PCI_BDF(hose->first_busno,0,0) )
-#endif
-			{
+			if( class != 0x0600 ) { /* CPU to PCI bridge */
 			    unsigned char int_line;
 
 			    pci_hose_read_config_byte(hose, dev, PCI_INTERRUPT_LINE,
-- 
1.5.5




From felix at embedded-sol.com  Mon Apr 28 10:10:23 2008
From: felix at embedded-sol.com (Felix Radensky)
Date: Mon, 28 Apr 2008 11:10:23 +0300
Subject: [U-Boot-Users] [PATCH v2] mx31ads: fix loadaddr environment
	variable define
In-Reply-To: <Pine.LNX.4.64.0804280014100.6246@axis700.grange>
References: <20080427214442.804C724764@gemini.denx.de>
	<Pine.LNX.4.64.0804280014100.6246@axis700.grange>
Message-ID: <1209370223.3101.7.camel@felix.lan>

Hi, 

I've verified that both problems I've reported are fixed by this
patch. Thanks a lot !

I'm sorry for not reporting this in the first place, but it
looks like ^C cannot be used to interrupt some blocking operations,
like, e.g. sending BOOTP requests.

Another problem I've noticed is that I had to manually set
ethaddr environment variable in order for DHCP/BOOTP to work.
In Redboot this worked out of the box.

Felix.
 
On Mon, 2008-04-28 at 00:25 +0200, Guennadi Liakhovetski wrote:
> Arithmetic expressions do not get evaluated under stringification. Remove 
> default network configuration, add DHCP command support. Thanks to Felix 
> Radensky for reporting.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>
> 
> ---
> 
> On Sun, 27 Apr 2008, Wolfgang Denk wrote:
> 
> > In message <Pine.LNX.4.64.0804272210370.6246 at axis700.grange> you wrote:
> > >
> > > > 2. dhcp command is undefined, only bootp is available.
> > > 
> > > It wasn't needed in the environment the configuration has been programmed 
> > > for. Patches are welcome:-)
> > 
> > Please add it. It's default...
> 
> Hm, but it isn't in
> 
> #include <config_cmd_default.h>
> 
> ?
> 
> > > diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
> > > index 5286e1f..301afd5 100644
> > > --- a/include/configs/mx31ads.h
> > > +++ b/include/configs/mx31ads.h
> > > @@ -87,7 +87,7 @@
> > >  #define CONFIG_NETMASK		255.255.255.0
> > >  #define CONFIG_IPADDR		192.168.23.168
> > >  #define CONFIG_SERVERIP		192.168.23.2
> > > -#define CONFIG_LOADADDR		(CSD0_BASE + 0x800000)	/* loadaddr env var */
> > > +#define CONFIG_LOADADDR		0x80800000	/* loadaddr env var */
> > 
> > And while we are at it: Please remove all these default network
> > settings. I don't like these at all.
> 
> Is this one better?
> 
> diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
> index 5286e1f..7614b95 100644
> --- a/include/configs/mx31ads.h
> +++ b/include/configs/mx31ads.h
> @@ -79,15 +79,13 @@
>  #include <config_cmd_default.h>
>  
>  #define CONFIG_CMD_PING
> +#define CONFIG_CMD_DHCP
>  #define CONFIG_CMD_SPI
>  #define CONFIG_CMD_DATE
>  
>  #define CONFIG_BOOTDELAY	3
>  
> -#define CONFIG_NETMASK		255.255.255.0
> -#define CONFIG_IPADDR		192.168.23.168
> -#define CONFIG_SERVERIP		192.168.23.2
> -#define CONFIG_LOADADDR		(CSD0_BASE + 0x800000)	/* loadaddr env var */
> +#define CONFIG_LOADADDR		0x80800000	/* loadaddr env var */
>  
>  #define	CONFIG_EXTRA_ENV_SETTINGS					\
>  	"netdev=eth0\0"							\




From miloody at gmail.com  Mon Apr 28 10:22:11 2008
From: miloody at gmail.com (loody mil)
Date: Mon, 28 Apr 2008 16:22:11 +0800
Subject: [U-Boot-Users] how to make a core uboot?
Message-ID: <3a665c760804280122k722847f4r62591478d9ba6117@mail.gmail.com>

Dear all:
I get an arm platform from my friend and it is not in the list of boards in
include folder.
I intend to make a pure uboot, without including any driver but only basic
cpu setting and uboot commands supported. But I cannot see any config option
in Makefile.
I know I may choose any config in boards and truncate those things I don't
need at all.
But I send this mail and want to know is there already a config option or
some fast way I can meet my requirement?
appreciate your help,
miloody
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080428/146fe379/attachment.htm 

From gerickson at nuovations.com  Mon Apr 28 10:53:07 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Mon, 28 Apr 2008 01:53:07 -0700
Subject: [U-Boot-Users] [PATCH] PPC405EX(r) ECC and SDRAM Initialization
	Clean-ups
Message-ID: <C43ADE83.EDBC%gerickson@nuovations.com>

The primary goal of this patch is to unify some of the low-level SDRAM and
ECC initialization code for the PPC4xx processors that use a common DDR2
SDRAM controller.

In particular, in the case of the 405EX[r], it must initialize SDRAM before
a primordial stack is available since OCM doesn't exist and the data cache
doesn't work for such a purpose. As a consequence, the ECC (and SDRAM)
initialization code must be stack-free.

This patch creates such a stack-free ecc_init() routine that should,
nonetheless, still be compatible from a C runtime environment.

In addition, the patch cleans-up the Kilauea and Makalu SDRAM initialization
code by polling SDRAM0_MCSTAT[MIC] as recommended by AMCC AN2131 rather than
just waiting some arbitrary period of time. Also, the final controller
initialization is generalized by ORing in SDRAM_MCOPT2_DCEN_ENABLE rather
than just slamming 0x28000000 into the register. This is to make way for a
future patch that uses CFG_SDRAM0_* values for boards that use such
low-level initialization so they might share this SDRAM init code. Finally,
while neither Kilauea nor Makalu have ECC memory, code is added to init.S
for each to demonstrate how ecc_init() would be called if it were available
as a reference.

Signed-off-by: Grant Erickson <gerickson at nuovations.com>

---
 board/amcc/kilauea/init.S |   53
+++++++++++++++++++++++++++++++++++++++------
 board/amcc/makalu/init.S  |   53
+++++++++++++++++++++++++++++++++++++++------
 cpu/ppc4xx/Makefile       |    1 +
 cpu/ppc4xx/sdram.c        |   47 +++------------------------------------
 4 files changed, 97 insertions(+), 57 deletions(-)

diff --git a/board/amcc/kilauea/init.S b/board/amcc/kilauea/init.S
index 053fe19..7603fcf 100644
--- a/board/amcc/kilauea/init.S
+++ b/board/amcc/kilauea/init.S
@@ -36,6 +36,10 @@
     ori     r4,r4,value at l    ;    \
     mtdcr   memcfgd,r4    ;
 
+#if defined(CONFIG_SDRAM_ECC)
+    .extern    ecc_init
+#endif /* defined(CONFIG_SDRAM_ECC) */
+
     .globl  ext_bus_cntlr_init
 ext_bus_cntlr_init:
 #if !defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SPL)
@@ -126,12 +130,19 @@ ext_bus_cntlr_init:
     /* SDRAM0_MCOPT2 (0X21) Start initialization */
     mtsdram_as(SDRAM_MCOPT2, 0x20000000);
 
-    /* Step 5 */
-    lis     r3,0x1    /* 400000 =  wait 100ms */
-    mtctr   r3
+    /*
+     * Step 5: Poll SDRAM0_MCSTAT[MIC] for assertion to indicate the
+     * completion of initialization.
+     */
 
-pll_wait:
-    bdnz    pll_wait
+    li      r4,SDRAM_MCSTAT
+    lis    r2,SDRAM_MCSTAT_MIC_COMP at h
+    ori    r2,r2,SDRAM_MCSTAT_MIC_COMP at l
+0:    mtdcr   memcfga,r4
+    mfdcr   r3,memcfgd
+    clrrwi    r3,r3,31        // Clear all bits except MCSTAT[MIC].
+    cmpw    cr7,r3,r2        // Check if MCSTAT[MIC] = 1.
+    bne+    cr7,0b            // No, not ready yet, keep polling.
 
     /* Step 6 */
 
@@ -147,8 +158,36 @@ pll_wait:
     /* SDRAM_RFDC */
     mtsdram_as(SDRAM_RFDC, 0x00000209);
 
-    /* Enable memory controller */
-    mtsdram_as(SDRAM_MCOPT2, 0x28000000);
+    /*
+     * Enable Controller by SDRAM0_MCOPT2[DCEN] = 1:
+     *
+     *   mcopt2 = mfsdram(SDRAM_MCOPT2)
+     */
+
+    li    r4,SDRAM_MCOPT2
+    mtdcr    memcfga,r4
+    mfdcr    r3,memcfgd
+
+    /*
+     *   mtsdram(SDRAM_MCOPT2, mcopt2 | SDRAM_MCOPT2_DCEN_ENABLE)
+     */
+
+    mtdcr    memcfga,r4
+    oris    r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at h
+    ori    r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at l
+    mtdcr    memcfgd,r3
+
+#if defined(CONFIG_SDRAM_ECC)
+    mflr    r13
+    lis    r3,CFG_SDRAM_BASE at h
+    ori    r3,r3,CFG_SDRAM_BASE at l
+    lis    r4,(CFG_MBYTES_SDRAM << 20)@h
+    ori    r4,r4,(CFG_MBYTES_SDRAM << 20)@l
+    bl    ecc_init
+    mtlr    r13
+#endif /* defined(CONFIG_SDRAM_ECC) */
 #endif /* #ifndef CONFIG_NAND_U_BOOT */
+    
+    /* SDRAM is now ready for use. Return to the caller. */
 
     blr
diff --git a/board/amcc/makalu/init.S b/board/amcc/makalu/init.S
index 5e9a5e0..c40d8d1 100644
--- a/board/amcc/makalu/init.S
+++ b/board/amcc/makalu/init.S
@@ -36,6 +36,10 @@
     ori     r4,r4,value at l    ;    \
     mtdcr   memcfgd,r4    ;
 
+#if defined(CONFIG_SDRAM_ECC)
+    .extern    ecc_init
+#endif /* defined(CONFIG_SDRAM_ECC) */
+
     .globl  ext_bus_cntlr_init
 ext_bus_cntlr_init:
 
@@ -121,12 +125,19 @@ ext_bus_cntlr_init:
     /* SDRAM0_MCOPT2 (0X21) Start initialization */
     mtsdram_as(SDRAM_MCOPT2, 0x20000000);
 
-    /* Step 5 */
-    lis     r3,0x1    /* 400000 =  wait 100ms */
-    mtctr   r3
+    /*
+     * Step 5: Poll SDRAM0_MCSTAT[MIC] for assertion to indicate the
+     * completion of initialization.
+     */
 
-pll_wait:
-    bdnz    pll_wait
+    li      r4,SDRAM_MCSTAT
+    lis    r2,SDRAM_MCSTAT_MIC_COMP at h
+    ori    r2,r2,SDRAM_MCSTAT_MIC_COMP at l
+0:    mtdcr   memcfga,r4
+    mfdcr   r3,memcfgd
+    clrrwi    r3,r3,31        // Clear all bits except MCSTAT[MIC].
+    cmpw    cr7,r3,r2        // Check if MCSTAT[MIC] = 1.
+    bne+    cr7,0b            // No, not ready yet, keep polling.
 
     /* Step 6 */
 
@@ -142,7 +153,35 @@ pll_wait:
     /* SDRAM_RFDC */
     mtsdram_as(SDRAM_RFDC, 0x00000209);
 
-    /* Enable memory controller */
-    mtsdram_as(SDRAM_MCOPT2, 0x28000000);
+    /*
+     * Enable Controller by SDRAM0_MCOPT2[DCEN] = 1:
+     *
+     *   mcopt2 = mfsdram(SDRAM_MCOPT2)
+     */
+
+    li    r4,SDRAM_MCOPT2
+    mtdcr    memcfga,r4
+    mfdcr    r3,memcfgd
+
+    /*
+     *   mtsdram(SDRAM_MCOPT2, mcopt2 | SDRAM_MCOPT2_DCEN_ENABLE)
+     */
+
+    mtdcr    memcfga,r4
+    oris    r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at h
+    ori    r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at l
+    mtdcr    memcfgd,r3
+
+#if defined(CONFIG_SDRAM_ECC)
+    mflr    r13
+    lis    r3,CFG_SDRAM_BASE at h
+    ori    r3,r3,CFG_SDRAM_BASE at l
+    lis    r4,(CFG_MBYTES_SDRAM << 20)@h
+    ori    r4,r4,(CFG_MBYTES_SDRAM << 20)@l
+    bl    ecc_init
+    mtlr    r13
+#endif /* defined(CONFIG_SDRAM_ECC) */
+    
+    /* SDRAM is now ready for use. Return to the caller. */
 
     blr
diff --git a/cpu/ppc4xx/Makefile b/cpu/ppc4xx/Makefile
index 178c5c6..f1e7ad2 100644
--- a/cpu/ppc4xx/Makefile
+++ b/cpu/ppc4xx/Makefile
@@ -31,6 +31,7 @@ START    += start.o
 SOBJS    := cache.o
 SOBJS    += dcr.o
 SOBJS    += kgdb.o
+SOBJS    += ecc.o
 
 COBJS    := 40x_spd_sdram.o
 COBJS    += 44x_spd_ddr.o
diff --git a/cpu/ppc4xx/sdram.c b/cpu/ppc4xx/sdram.c
index 2724d91..66d9ae8 100644
--- a/cpu/ppc4xx/sdram.c
+++ b/cpu/ppc4xx/sdram.c
@@ -32,6 +32,10 @@
 #include <asm/processor.h>
 #include "sdram.h"
 
+#if defined(CONFIG_SDRAM_ECC)
+extern void ecc_init(volatile ulong * const start, ulong size);
+#endif
+
 #ifdef CONFIG_SDRAM_BANK0
 
 #ifndef CONFIG_440
@@ -332,49 +336,6 @@ static void sdram_tr1_set(int ram_address, int*
tr1_value)
     *tr1_value = (first_good + last_bad) / 2;
 }
 
-#ifdef CONFIG_SDRAM_ECC
-static void ecc_init(ulong start, ulong size)
-{
-    ulong    current_addr;        /* current byte address */
-    ulong    end_addr;        /* end of memory region */
-    ulong    addr_inc;        /* address skip between writes */
-    ulong    cfg0_reg;        /* for restoring ECC state */
-
-    /*
-     * TODO: Enable dcache before running this test (speedup)
-     */
-
-    mfsdram(mem_cfg0, cfg0_reg);
-    mtsdram(mem_cfg0, (cfg0_reg & ~SDRAM_CFG0_MEMCHK) |
SDRAM_CFG0_MEMCHK_GEN);
-
-    /*
-     * look at geometry of SDRAM (data width) to determine whether we
-     * can skip words when writing
-     */
-    if ((cfg0_reg & SDRAM_CFG0_DRAMWDTH) == SDRAM_CFG0_DRAMWDTH_32)
-        addr_inc = 4;
-    else
-        addr_inc = 8;
-
-    current_addr = start;
-    end_addr = start + size;
-
-    while (current_addr < end_addr) {
-        *((ulong *)current_addr) = 0x00000000;
-        current_addr += addr_inc;
-    }
-
-    /*
-     * TODO: Flush dcache and disable it again
-     */
-
-    /*
-     * Enable ecc checking and parity errors
-     */
-    mtsdram(mem_cfg0, (cfg0_reg & ~SDRAM_CFG0_MEMCHK) |
SDRAM_CFG0_MEMCHK_CHK);
-}
-#endif
-
 /*
  * Autodetect onboard DDR SDRAM on 440 platforms
  *






From Steven.Wang at spansion.com  Mon Apr 28 11:00:41 2008
From: Steven.Wang at spansion.com (Wang, Steven)
Date: Mon, 28 Apr 2008 17:00:41 +0800
Subject: [U-Boot-Users] usb host tty driver issue
Message-ID: <A4C6FC160E79CE418F09D45C555A44795F44C8@cnsuzexmbpf1.spansion.com>

Hi Guys,

 

I am porting usb host tty device driver on uboot. I just use usb
usb_bulk_msg to communicate with modem. I met the following problems.

Could you please help me for the following issue? Thanks in advance.

 

When I use usb usb_bulk_msg to connect one USB modem, send one AT
command (e.g. AT) to Modem, and can receive a responding message, e.g.,
OK and so on.

But When I want to use usb usb_bulk_msg to receive the RING command from
modem without sending any AT command to modem, I could not receive any
data from modem, even NAK, STALL cannot be received. Then program
timeout. But if I send ATA, the can answer the incoming call.

I do not know how to receive the data from modem, when host did not send
AT command to modem.

 

 

Thanks & Best regards,

Steven Wang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080428/c8d95619/attachment.htm 

From wd at denx.de  Mon Apr 28 11:06:37 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 11:06:37 +0200
Subject: [U-Boot-Users] [PATCH] katmai: fix section overlap problem
Message-ID: <1209373597-4204-1-git-send-email-wd@denx.de>

Since we didn't want to remove features from the configuration, we
decided to increase the U-Boot image size (add one flash sector).

Also changed the default environment definition to make it
independent of such changes.

Signed-off-by: Wolfgang Denk <wd at denx.de>
Acked-by: Stefan Roese <sr at denx.de>
---
 board/amcc/katmai/config.mk |    2 +-
 include/configs/katmai.h    |    8 ++++++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/board/amcc/katmai/config.mk b/board/amcc/katmai/config.mk
index 115c1ae..c512b53 100644
--- a/board/amcc/katmai/config.mk
+++ b/board/amcc/katmai/config.mk
@@ -25,7 +25,7 @@
 # AMCC 440SPe Evaluation (Katmai) board
 #
 
-TEXT_BASE = 0xfffc0000
+TEXT_BASE = 0xFFFA0000
 
 PLATFORM_CPPFLAGS += -DCONFIG_440=1
 
diff --git a/include/configs/katmai.h b/include/configs/katmai.h
index 21b2604..122b700 100644
--- a/include/configs/katmai.h
+++ b/include/configs/katmai.h
@@ -178,6 +178,9 @@
 
 #undef	CONFIG_BOOTARGS
 
+#define xstr(s) str(s)
+#define str(s) #s
+
 #define	CONFIG_EXTRA_ENV_SETTINGS					\
 	"netdev=eth0\0"							\
 	"hostname=katmai\0"						\
@@ -206,8 +209,9 @@
 	"ramdisk_addr=fff20000\0"					\
 	"initrd_high=30000000\0"					\
 	"load=tftp 200000 katmai/u-boot.bin\0"				\
-	"update=protect off fffc0000 ffffffff;era fffc0000 ffffffff;"	\
-		"cp.b ${fileaddr} fffc0000 ${filesize};"		\
+	"update=protect off " xstr(CFG_MONITOR_BASE) " FFFFFFFF;"	\
+		"era " xstr(CFG_MONITOR_BASE) " FFFFFFFF;"		\
+		"cp.b ${fileaddr} " xstr(CFG_MONITOR_BASE) " ${filesize};" \
 		"setenv filesize;saveenv\0"				\
 	"upd=run load update\0"						\
 	"kozio=bootm ffc60000\0"					\
-- 
1.5.4.2




From wd at denx.de  Mon Apr 28 11:07:35 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 11:07:35 +0200
Subject: [U-Boot-Users] [PATCH] 85xx: Additional fixes and cleanup of MP
	code
In-Reply-To: Your message of "Mon, 28 Apr 2008 02:24:04 CDT."
	<Pine.LNX.4.64.0804280223420.4305@blarg.am.freescale.net>
Message-ID: <20080428090735.DF375247B4@gemini.denx.de>

In message <Pine.LNX.4.64.0804280223420.4305 at blarg.am.freescale.net> you wrote:
> * adjust __spin_table alignment to match ePAPR v0.94 spec
> * loop over all cpus when determing who is up.  This fixes an issue if
>   the "boot cpu" isn't core0.  The "boot cpu" will already be in the
>   cpu_up_mask so there is no harm
> * Added some protection in the code to ensure proper behavior.  These
>   changes are explicitly needed but don't hurt:
>   - Added eieio to ensure the "hot word" of the table is written after
>     all other table updates have occurred.
>   - Added isync to ensure we don't prefetch loading of table entries
>     until we a released
> 
> These issues we raised by Dave Liu.
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>

Will Andy send a pull request or shall I apply directly?

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: wd at denx.de
The management question ... is not _whether_ to build a pilot  system
and  throw  it away. You _will_ do that. The only question is whether
to plan in advance to build a throwaway, or to promise to deliver the
throwaway to customers.       - Fred Brooks, "The Mythical Man Month"



From wd at denx.de  Mon Apr 28 11:10:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 11:10:55 +0200
Subject: [U-Boot-Users] [PATCH v2] mx31ads: fix loadaddr environment
	variable define
In-Reply-To: Your message of "Mon, 28 Apr 2008 00:25:32 +0200."
	<Pine.LNX.4.64.0804280014100.6246@axis700.grange>
Message-ID: <20080428091055.0E511247B4@gemini.denx.de>

In message <Pine.LNX.4.64.0804280014100.6246 at axis700.grange> you wrote:
> Arithmetic expressions do not get evaluated under stringification. Remove 
> default network configuration, add DHCP command support. Thanks to Felix 
> Radensky for reporting.
> 
> Signed-off-by: Guennadi Liakhovetski <lg at denx.de>

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
PROGRAM - n.  A magic spell cast over a computer  allowing it to turn
one's input into error messages.
v. tr. - To engage in a pastime similar to banging one's head against
a wall, but with fewer opportunities for reward.



From XinFan at ge.com  Mon Apr 28 11:22:56 2008
From: XinFan at ge.com (Fan, Xin (GE Healthcare))
Date: Mon, 28 Apr 2008 17:22:56 +0800
Subject: [U-Boot-Users] BDI2000 stop debug in board.c for ARM
Message-ID: <755D602ED9F76B41914BE6E9944931B202C32EDA@SHAMLVEM01.e2k.ad.ge.com>

When I debug the board SMDK2410 using the BDI2000, I got an error puzzle
me a lot.
 
Debug in start.s is okay, when get into the file board.c following
instruction in " for (init_fnc_ptr = init_sequence; *init_fnc_ptr;
++init_fnc_ptr) {" cycle, there is an notification appear in the ddd
debugger. "Further execution is probably impossible."  And then uboot go
back to "monitor_flash_len = _bss_start - _armboot_start; "
 
I don't know why. Can anybody tell me what happen here?
Thanks a lot,
 
Fan
 
.......
 gd = (gd_t*)(_armboot_start - CFG_MALLOC_LEN - sizeof(gd_t));
 /* compiler optimization barrier needed for GCC >= 3.4 */
 __asm__ __volatile__("": : :"memory");
 
 memset ((void*)gd, 0, sizeof (gd_t));
 gd->bd = (bd_t*)((char*)gd - sizeof(bd_t));
 memset (gd->bd, 0, sizeof (bd_t));
 
 monitor_flash_len = _bss_start - _armboot_start;
 
 for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
  if ((*init_fnc_ptr)() != 0) {
   hang ();
  }
 }
 
.......
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080428/472d3d45/attachment.htm 

From garyj at denx.de  Mon Apr 28 11:32:29 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Mon, 28 Apr 2008 11:32:29 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <200804271401.45781.sr@denx.de>
References: <20080425180412.1eee9b27@peedub.jennejohn.org>
	<200804260822.02142.sr@denx.de>
	<20080426121802.2c80657e@peedub.jennejohn.org>
	<200804271401.45781.sr@denx.de>
Message-ID: <20080428113229.6510c91c@peedub.jennejohn.org>

On Sun, 27 Apr 2008 14:01:45 +0200
Stefan Roese <sr at denx.de> wrote:

> On Saturday 26 April 2008, Gary Jennejohn wrote:
> > > > +#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Monitor	*/
> > > > +#define CFG_MALLOC_LEN		(128 * 1024)	/* Reserve 128 kB for malloc()	*/
> > > > +#define CFG_MONITOR_BASE	0xFFF80000
> > >
> > > CFG_MONITOR_BASE at 0xfff80000 makes me think that the U-Boot image has a
> > > size of 512k. But CFG_MONITOR_LEN is 256k. Which one is correct? I would
> > > think that 256k should be enough for this image.
> >
> > That's a valid point.  Actually u-boot.bin is 512kB in length, but only
> > because there's a reset vector at 0xFFFFFFFC.  u-boot itself is really
> > only 256kB in size.
> >
> > So now I wonder - what's correct?  If CFG_MONITOR_LEN applies to RAM,
> > which it seems to since it only really affects TOTAL_MALLOC_LEN, then
> > 256kB is correct and no change is required.
> 
> I would change the image size to 256k to safe some space in FLASH. For this 
> you have to change TEXT_BASE (in config.mk in your board directory) to 
> 0xfffc0000. And CFG_MONITOR_BASE too. Or even better:
> 
> #define CFG_MONITOR_BASE        (TEXT_BASE)
> 

Well, I took these values from PPCBoot, as used by the customer, and I
see no technical reason to change these values with which the customer
is obviously satisfied.

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From wd at denx.de  Mon Apr 28 11:33:37 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 11:33:37 +0200
Subject: [U-Boot-Users] [PATCH] MPC8323ERDB: fix implicit declaration of
	function 'mac_read_from_eeprom'
Message-ID: <1209375217-4716-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 include/common.h |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/common.h b/include/common.h
index f12e3bd..a6c966c 100644
--- a/include/common.h
+++ b/include/common.h
@@ -214,9 +214,7 @@ int	checkdram     (void);
 char *	strmhz(char *buf, long hz);
 int	last_stage_init(void);
 extern ulong monitor_flash_len;
-#ifdef CFG_ID_EEPROM
 int mac_read_from_eeprom(void);
-#endif
 
 /* common/flash.c */
 void flash_perror (int);
-- 
1.5.4.2




From sr at denx.de  Mon Apr 28 11:37:14 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 28 Apr 2008 11:37:14 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix compile warning of hcu4 board
Message-ID: <1209375434-2552-1-git-send-email-sr@denx.de>

Signed-off-by: Stefan Roese <sr at denx.de>
---
 include/asm-ppc/4xx_pcie.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/asm-ppc/4xx_pcie.h b/include/asm-ppc/4xx_pcie.h
index 5398696..a7cf1e8 100644
--- a/include/asm-ppc/4xx_pcie.h
+++ b/include/asm-ppc/4xx_pcie.h
@@ -12,6 +12,7 @@
 #define __4XX_PCIE_H
 
 #include <ppc4xx.h>
+#include <pci.h>
 
 #define DCRN_SDR0_CFGADDR	0x00e
 #define DCRN_SDR0_CFGDATA	0x00f
-- 
1.5.5.1




From garyj at denx.de  Mon Apr 28 11:40:27 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Mon, 28 Apr 2008 11:40:27 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
 405EP-based board.
In-Reply-To: <200804271407.39875.sr@denx.de>
References: <20080425180412.1eee9b27@peedub.jennejohn.org>
	<200804260822.02142.sr@denx.de> <48132A16.9010707@grandegger.com>
	<200804271407.39875.sr@denx.de>
Message-ID: <20080428114027.1236c138@peedub.jennejohn.org>

On Sun, 27 Apr 2008 14:07:39 +0200
Stefan Roese <sr at denx.de> wrote:

> On Saturday 26 April 2008, Wolfgang Grandegger wrote:
> > > Please use only one coding style in one file. So either:
> > >
> > > 	func();
> > >
> > > or
> > >
> > > 	func ();
> > >
> > > Since this file mostly consists of the func() style I suggest you switch
> > > to this one completely.
> >
> > Do we really have the choice?
> 
> I definitely think so. I am aware of the coding style rule set be Wolfgang to 
> use the "func ()" style. But I never use this style in the files I write from 
> scratch. This is because I am also doing a lot of Linux development, and here 
> the "func()" style is required/preferred. And if you take a look at the code 
> posted by other developers, most of it uses the "func()" style. It definitely 
> seems to be more common nowadays. At least from my experience.
> 

So now I'm totally confused!  As Wolfgang Denk wrote in his followup:

The README says:

    All contributions to U-Boot should conform to the Linux kernel
    coding style; see the file "Documentation/CodingStyle" and the script
    "scripts/Lindent" in your Linux kernel source directory.  In sources
    originating from U-Boot a style corresponding to "Lindent -pcs" (adding
    spaces before parameters to function calls) is actually used.

The Linux coding style, as you pointed out,  is to _not_ use spaces
between the function name and the first brace, i.e. "foo()" and not
"foo ()".

So WTF?

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From sr at denx.de  Mon Apr 28 11:40:37 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 28 Apr 2008 11:40:37 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <20080428113229.6510c91c@peedub.jennejohn.org>
References: <20080425180412.1eee9b27@peedub.jennejohn.org>
	<200804271401.45781.sr@denx.de>
	<20080428113229.6510c91c@peedub.jennejohn.org>
Message-ID: <200804281140.37760.sr@denx.de>

On Monday 28 April 2008, Gary Jennejohn wrote:
> > I would change the image size to 256k to safe some space in FLASH. For
> > this you have to change TEXT_BASE (in config.mk in your board directory)
> > to 0xfffc0000. And CFG_MONITOR_BASE too. Or even better:
> >
> > #define CFG_MONITOR_BASE        (TEXT_BASE)
>
> Well, I took these values from PPCBoot, as used by the customer, and I
> see no technical reason to change these values with which the customer
> is obviously satisfied.

The customer would "safe" 256k of FLASH memory this way. Perhaps the customer 
was/is not aware of this.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Mon Apr 28 11:45:33 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 28 Apr 2008 11:45:33 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: <20080427214131.9BA7424764@gemini.denx.de>
References: <20080427214131.9BA7424764@gemini.denx.de>
Message-ID: <200804281145.33533.sr@denx.de>

On Sunday 27 April 2008, Wolfgang Denk wrote:
> In message <200804271407.39875.sr at denx.de> you wrote:
> > I definitely think so. I am aware of the coding style rule set be
> > Wolfgang to
>
> You are definitely wrong.
>
> > use the "func ()" style. But I never use this style in the files I write
> > from
>
> You mean you intentionally ignore the rules?

If you put it this way then yes, I have to admit that I am guilty. But it was 
my understanding that this was known to you. You must have noticed that 
_most_ U-Boot contributors (not only myself) are writing their code in the 
Linux style (func()). Probably since this is the most common style in the 
OpenSource community nowadays. At least from my experience.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From andreas at schweigstill.de  Mon Apr 28 11:51:29 2008
From: andreas at schweigstill.de (Andreas Schweigstill)
Date: Mon, 28 Apr 2008 11:51:29 +0200
Subject: [U-Boot-Users] how to make a core uboot?
In-Reply-To: <3a665c760804280122k722847f4r62591478d9ba6117@mail.gmail.com>
References: <3a665c760804280122k722847f4r62591478d9ba6117@mail.gmail.com>
Message-ID: <48159E21.70205@schweigstill.de>

Hello!

loody mil schrieb:
> I intend to make a pure uboot, without including any driver but only 
> basic cpu setting and uboot commands supported. But I cannot see any 
> config option in Makefile.

If you need a really minimalistic bootloader U-Boot will not be the
first choice. The smallest possible U-Boot will be around 100KByte in
size and contain much more than just basic CPU initialisation.

> I know I may choose any config in boards and truncate those things I 
> don't need at all.

That's the right way if you want to use U-Boot.

> But I send this mail and want to know is there already a config option 
> or some fast way I can meet my requirement?

Nobody knows what are you requirements. If you need a really
minimalistic bootloader you should take a look at some sample
initialization code from the processor manufacturer.

On certain platforms (e.g. Atmel AT91) even U-Boot will just be used as
a second or third level bootloader. The basic CPU setup has been done
before starting U-Boot.

With best regards
Andreas Schweigstill

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/



From wd at denx.de  Mon Apr 28 12:05:42 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 12:05:42 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
	405EP-based board.
In-Reply-To: Your message of "Mon, 28 Apr 2008 11:32:29 +0200."
	<20080428113229.6510c91c@peedub.jennejohn.org>
Message-ID: <20080428100542.0ABEE247AF@gemini.denx.de>

In message <20080428113229.6510c91c at peedub.jennejohn.org> you wrote:
> 
> > I would change the image size to 256k to safe some space in FLASH. For this 
> > you have to change TEXT_BASE (in config.mk in your board directory) to 
> > 0xfffc0000. And CFG_MONITOR_BASE too. Or even better:
> > 
> > #define CFG_MONITOR_BASE        (TEXT_BASE)
> > 
> 
> Well, I took these values from PPCBoot, as used by the customer, and I
> see no technical reason to change these values with which the customer
> is obviously satisfied.

The reason to change this is that it makes maintenance in the future
much easier.

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: wd at denx.de
There is nothing in this world constant but inconstancy.      - Swift



From wd at denx.de  Mon Apr 28 12:10:03 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 12:10:03 +0200
Subject: [U-Boot-Users] [PATCH] NAND: fix some strict-aliasing compiler
	warnings
Message-ID: <1209377403-5488-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 common/cmd_nand.c |   19 ++++++++++---------
 common/env_nand.c |    2 +-
 include/nand.h    |    8 ++++----
 3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 7b1f830..f8fce0e 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -93,7 +93,7 @@ static inline int str2long(char *p, ulong *num)
 }
 
 static int
-arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, ulong *size)
+arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, size_t *size)
 {
 	int idx = nand_curr_device;
 #if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_JFFS2_CMDLINE)
@@ -136,7 +136,7 @@ arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, ulong *size)
 	}
 
 	if (argc >= 2) {
-		if (!(str2long(argv[1], size))) {
+		if (!(str2long(argv[1], (ulong *)size))) {
 			printf("'%s' is not a number\n", argv[1]);
 			return -1;
 		}
@@ -158,7 +158,8 @@ out:
 int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 {
 	int i, dev, ret;
-	ulong addr, off, size;
+	ulong addr, off;
+	size_t size;
 	char *cmd, *s;
 	nand_info_t *nand;
 #ifdef CFG_NAND_QUIET
@@ -350,10 +351,10 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 		} else if (s != NULL && !strcmp(s, ".oob")) {
 			/* read out-of-band data */
 			if (read)
-				ret = nand->read_oob(nand, off, size, (size_t *) &size,
+				ret = nand->read_oob(nand, off, size, &size,
 						     (u_char *) addr);
 			else
-				ret = nand->write_oob(nand, off, size, (size_t *) &size,
+				ret = nand->write_oob(nand, off, size, &size,
 						      (u_char *) addr);
 		} else {
 			if (read)
@@ -481,7 +482,7 @@ static int nand_load_image(cmd_tbl_t *cmdtp, nand_info_t *nand,
 {
 	int r;
 	char *ep, *s;
-	ulong cnt;
+	size_t cnt;
 	image_header_t *hdr;
 	int jffs2 = 0;
 #if defined(CONFIG_FIT)
@@ -851,11 +852,11 @@ int do_nand (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 				/* read out-of-band data */
 				if (cmd & NANDRW_READ) {
 					ret = nand_read_oob (nand_dev_desc + curr_device,
-							     off, size, (size_t *) & total,
+							     off, size, &total,
 							     (u_char *) addr);
 				} else {
 					ret = nand_write_oob (nand_dev_desc + curr_device,
-							      off, size, (size_t *) & total,
+							      off, size, &total,
 							      (u_char *) addr);
 				}
 				return ret;
@@ -891,7 +892,7 @@ int do_nand (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 
 			ret = nand_legacy_rw (nand_dev_desc + curr_device,
 					      cmd, off, size,
-					      (size_t *) & total,
+					      &total,
 					      (u_char *) addr);
 
 			printf (" %d bytes %s: %s\n", total,
diff --git a/common/env_nand.c b/common/env_nand.c
index ce0a251..b6a5b4a 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -154,7 +154,7 @@ int env_init(void)
 #ifdef CFG_ENV_OFFSET_REDUND
 int saveenv(void)
 {
-	ulong total;
+	size_t total;
 	int ret = 0;
 
 	env_ptr->flags++;
diff --git a/include/nand.h b/include/nand.h
index 3c0752e..247d346 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -34,22 +34,22 @@ extern int nand_curr_device;
 extern nand_info_t nand_info[];
 extern void nand_init(void);
 
-static inline int nand_read(nand_info_t *info, ulong ofs, ulong *len, u_char *buf)
+static inline int nand_read(nand_info_t *info, off_t ofs, size_t *len, u_char *buf)
 {
 	return info->read(info, ofs, *len, (size_t *)len, buf);
 }
 
-static inline int nand_write(nand_info_t *info, ulong ofs, ulong *len, u_char *buf)
+static inline int nand_write(nand_info_t *info, off_t ofs, size_t *len, u_char *buf)
 {
 	return info->write(info, ofs, *len, (size_t *)len, buf);
 }
 
-static inline int nand_block_isbad(nand_info_t *info, ulong ofs)
+static inline int nand_block_isbad(nand_info_t *info, off_t ofs)
 {
 	return info->block_isbad(info, ofs);
 }
 
-static inline int nand_erase(nand_info_t *info, ulong off, ulong size)
+static inline int nand_erase(nand_info_t *info, off_t off, size_t size)
 {
 	struct erase_info instr;
 
-- 
1.5.4.2




From wd at denx.de  Mon Apr 28 12:22:41 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 12:22:41 +0200
Subject: [U-Boot-Users] [PATCH 2/2] Support for LinkStation / KuroBox HD
	and HG PPC models
In-Reply-To: Your message of "Mon, 31 Mar 2008 01:32:15 +0200."
	<Pine.LNX.4.64.0803310112130.6825@axis700.grange>
Message-ID: <20080428102241.A83D0247AF@gemini.denx.de>

In message <Pine.LNX.4.64.0803310112130.6825 at axis700.grange> you wrote:
> This patch is based on the port by Mihai Georgian (see linkstation.c for 
> Copyright information) and implements support for LinkStation / KuroBox HD 
> and HG PPC models from Buffalo Technology, whereby HD is deactivated at 
> the moment, pending network driver fixing.

The code throws a lot of compiler warnings:

===== LOG/linkstation_HGLAN =====
hwctl.c: In function 'miconCntl_SendUart':
hwctl.c:30: warning: pointer targets in passing argument 1 of 'out_8' differ in signedness
rtl8169.c: In function 'rtl_recv':
rtl8169.c:438: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast
rtl8169.c: In function 'rtl_send':
rtl8169.c:484: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast
rtl8169.c: In function 'rtl8169_hw_start':
rtl8169.c:582: warning: passing argument 2 of 'out_le32' makes integer from pointer without a cast
rtl8169.c:583: warning: passing argument 2 of 'out_le32' makes integer from pointer without a cast
rtl8169.c: In function 'rtl8169_init_ring':
rtl8169.c:628: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast
cmd_ide.c: In function 'ide_read':
cmd_ide.c:1267: warning: integer constant is too large for 'long' type
cmd_ide.c:1321: warning: right shift count >= width of type
cmd_ide.c:1322: warning: right shift count >= width of type
cmd_ide.c: In function 'ide_write':
cmd_ide.c:1386: warning: integer constant is too large for 'long' type
cmd_ide.c:1411: warning: right shift count >= width of type
cmd_ide.c:1412: warning: right shift count >= width of type


Also, ther eis no entry for this board in the MAINTAINERS file.


Please fix. Thanks in advance.

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: wd at denx.de
In the beginning there was nothing.
And the Lord said "Let There Be Light!"
And still there was nothing, but at least now you could see it.



From wd at denx.de  Mon Apr 28 12:49:51 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 12:49:51 +0200
Subject: [U-Boot-Users] [PATCH] pcnet.c: fix a merge issue
Message-ID: <1209379791-5979-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 drivers/net/pcnet.c |   54 ---------------------------------------------------
 1 files changed, 0 insertions(+), 54 deletions(-)

diff --git a/drivers/net/pcnet.c b/drivers/net/pcnet.c
index 386fa50..aa04e8f 100644
--- a/drivers/net/pcnet.c
+++ b/drivers/net/pcnet.c
@@ -169,7 +169,6 @@ static struct pci_device_id supported[] = {
 
 int pcnet_initialize (bd_t * bis)
 {
-<<<<<<< HEAD:drivers/net/pcnet.c
 	pci_dev_t devbusfn;
 	struct eth_device *dev;
 	u16 command, status;
@@ -232,59 +231,6 @@ int pcnet_initialize (bd_t * bis)
 		dev->recv = pcnet_recv;
 
 		eth_register (dev);
-=======
-    pci_dev_t devbusfn;
-    struct eth_device* dev;
-    u16 command, status;
-    int dev_nr = 0;
-
-    PCNET_DEBUG1("\npcnet_initialize...\n");
-
-    for (dev_nr = 0; ; dev_nr++) {
-
-	/*
-	 * Find the PCnet PCI device(s).
-	 */
-	if ((devbusfn = pci_find_devices(supported, dev_nr)) < 0) {
-	    break;
-	}
-
-	/*
-	 * Allocate and pre-fill the device structure.
-	 */
-	dev = (struct eth_device*) malloc(sizeof *dev);
-	dev->priv = (void *)devbusfn;
-	sprintf(dev->name, "pcnet#%d", dev_nr);
-
-	/*
-	 * Setup the PCI device.
-	 */
-	pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0, (unsigned int *)&dev->iobase);
-	dev->iobase=pci_io_to_phys(devbusfn,dev->iobase);
-	dev->iobase &= ~0xf;
-
-	PCNET_DEBUG1("%s: devbusfn=0x%x iobase=0x%x: ",
-	       dev->name, devbusfn, dev->iobase);
-
-	command = PCI_COMMAND_IO | PCI_COMMAND_MASTER;
-	pci_write_config_word(devbusfn, PCI_COMMAND, command);
-	pci_read_config_word(devbusfn, PCI_COMMAND, &status);
-	if ((status & command) != command) {
-	    printf("%s: Couldn't enable IO access or Bus Mastering\n",
-		   dev->name);
-	    free(dev);
-	    continue;
-	}
-
-	pci_write_config_byte(devbusfn, PCI_LATENCY_TIMER, 0x40);
-
-	/*
-	 * Probe the PCnet chip.
-	 */
-	if (pcnet_probe(dev, bis, dev_nr) < 0) {
-	    free(dev);
-	    continue;
->>>>>>> Fixed pcnet io_base:drivers/net/pcnet.c
 	}
 
 	udelay (10 * 1000);
-- 
1.5.4.2




From shenzhenshanhudao at 126.com  Mon Apr 28 12:57:32 2008
From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=)
Date: Mon, 28 Apr 2008 18:57:32 +0800
Subject: [U-Boot-Users] (no subject)
Message-ID: <E1JqR31-00043F-V9@mail.sourceforge.net>

???????????/???????
    
    ?????2008????????????????????????? 
?
?????????????????? ????????????
    
    ??????????????????????????????

?????????????????????????????????

????????????????????????????????

?????????????????????????????????

????????????????????????????????????

                    ???0755-81153047?
?
                    ???0755-81172940?
?
                    ???15817477278?
?
                    ????????
?
                    ?????shenzhenshanhudao at 126.com 

                    ?????http://541012091.qzone.qq.c

           ???
                                                           ???



                        ?  ?  ? ? ?  ?



From garyj at denx.de  Mon Apr 28 13:11:12 2008
From: garyj at denx.de (Gary Jennejohn)
Date: Mon, 28 Apr 2008 13:11:12 +0200
Subject: [U-Boot-Users] [PATCH V2] Add the Harris QUAD100HD AMCC
 405EP-based board.
In-Reply-To: <20080428100542.0ABEE247AF@gemini.denx.de>
References: <20080428113229.6510c91c@peedub.jennejohn.org>
	<20080428100542.0ABEE247AF@gemini.denx.de>
Message-ID: <20080428131112.62f2221c@peedub.jennejohn.org>

On Mon, 28 Apr 2008 12:05:42 +0200
Wolfgang Denk <wd at denx.de> wrote:

> In message <20080428113229.6510c91c at peedub.jennejohn.org> you wrote:
> > 
> > > I would change the image size to 256k to safe some space in FLASH. For this 
> > > you have to change TEXT_BASE (in config.mk in your board directory) to 
> > > 0xfffc0000. And CFG_MONITOR_BASE too. Or even better:
> > > 
> > > #define CFG_MONITOR_BASE        (TEXT_BASE)
> > > 
> > 
> > Well, I took these values from PPCBoot, as used by the customer, and I
> > see no technical reason to change these values with which the customer
> > is obviously satisfied.
> 
> The reason to change this is that it makes maintenance in the future
> much easier.
> 

Well, OK.  If it makes everyone happy and I can _finally_ get these
patches into the tree then I'll do it.

---
Gary Jennejohn
*********************************************************************
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
*********************************************************************



From trimarchi at gandalf.sssup.it  Mon Apr 28 13:02:30 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Mon, 28 Apr 2008 13:02:30 +0200
Subject: [U-Boot-Users] [PATCH ARM/IXP465 1/3] Add support for the ixp465
	processor
Message-ID: <4815AEC6.8060704@gandalf.sssup.it>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: basic-ixp465-processor-support.patch
Type: text/x-patch
Size: 6108 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080428/39839d7c/attachment.bin 

From trimarchi at gandalf.sssup.it  Mon Apr 28 13:02:36 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Mon, 28 Apr 2008 13:02:36 +0200
Subject: [U-Boot-Users] [PATCH ARM/IXP465 2/3] Add the new include file for
	cpu support
Message-ID: <4815AECC.9010102@gandalf.sssup.it>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-include-ixp465-support.patch
Type: text/x-patch
Size: 24549 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080428/682608d1/attachment.bin 

From trimarchi at gandalf.sssup.it  Mon Apr 28 13:02:42 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Mon, 28 Apr 2008 13:02:42 +0200
Subject: [U-Boot-Users] [PATCH ARM/IXP465 3/3] Add support for the ixdp465
	evaluation board
Message-ID: <4815AED2.7040708@gandalf.sssup.it>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-ixdp465-basic-board-support.patch
Type: text/x-patch
Size: 18768 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080428/aa7cf769/attachment.bin 

From trimarchi at gandalf.sssup.it  Mon Apr 28 13:02:24 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Mon, 28 Apr 2008 13:02:24 +0200
Subject: [U-Boot-Users] [PATCH ARM/IXP465 0/3] IXP465 support
Message-ID: <4815AEC0.6000705@gandalf.sssup.it>

Hi,

The following patches add basic support for the IXP465 processor and
the IXDP465 board.

Comments are welcomed.

Thanks,

Michael




From zhukov at tst.spb.su  Mon Apr 28 13:32:48 2008
From: zhukov at tst.spb.su (Zhukov)
Date: Mon, 28 Apr 2008 15:32:48 +0400
Subject: [U-Boot-Users] --- at91, Nand
Message-ID: <1752253171.20080428153248@tst.spb.su>

In at91rm9200dk, for Nand support,
- can the pin PC7 be used instead of PC1 (the custom board made this
way)?

I change PC1 to PC7 within u-boot everywhere, it won't work:
I see SMWE strobe (pin PC3) drops down and never rises, the system
hangs...

Best regards,
Andrew




From wd at denx.de  Mon Apr 28 13:58:39 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 13:58:39 +0200
Subject: [U-Boot-Users] [PATCH ARM/IXP465 1/3] Add support for the
	ixp465 processor
In-Reply-To: Your message of "Mon, 28 Apr 2008 13:02:30 +0200."
	<4815AEC6.8060704@gandalf.sssup.it>
Message-ID: <20080428115839.15824247B4@gemini.denx.de>

In message <4815AEC6.8060704 at gandalf.sssup.it> you wrote:
> 
> This patch add basic support to the ixp465 cpu.
...
> diff --git a/cpu/ixp/start.S b/cpu/ixp/start.S
> index 757cfaa..af718b0 100644
> --- a/cpu/ixp/start.S
> +++ b/cpu/ixp/start.S
> @@ -29,7 +29,8 @@
>  
>  #include <config.h>
>  #include <version.h>
> -#include <asm/arch/ixp425.h>
> +
> +#include <asm/arch/hardware.h>
>  
>  #define MMU_Control_M  0x001    /* Enable MMU */
>  #define MMU_Control_A  0x002    /* Enable address alignment faults */
> @@ -158,6 +159,16 @@ reset:
>  	ldr     r2, =IXP425_EXP_CS0
--------------------^^^^^^^^^^^^^^^^

Seems there is IXP425 specific stuff here. Please verify that this is
correct. If it is correct, then probably the name should be changed.

> +#ifdef CONFIG_IXP465
...
> +#ifdef CONFIG_IXP425
...
> +#ifdef CONFIG_IXP465
...
> +#ifdef CONFIG_IXP465
...
> +#else
...
> +#ifdef CONFIG_IXP465
...
> +#ifdef CONFIG_IXP465
...
> +#else

That's a pretty mess of #ifdef's.

Maybe we should split this into separate source files?


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: wd at denx.de
If you hear an onion ring, answer it.



From DZIMA-raluciss at Medford.k12.nj.us  Mon Apr 28 14:02:48 2008
From: DZIMA-raluciss at Medford.k12.nj.us (Dockham)
Date: Mon, 28 Apr 2008 14:02:48 +0200
Subject: [U-Boot-Users] Professor steals girl's underwear
Message-ID: <BD025581.0%DZIMA-raluciss@Medford.k12.nj.us>

Get a super duper discount here now when you purchase, limited period only! http://www.oiguenae.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080428/2084f55b/attachment.htm 

From gary.jennejohn at freenet.de  Mon Apr 28 14:04:32 2008
From: gary.jennejohn at freenet.de (Gary Jennejohn)
Date: Mon, 28 Apr 2008 14:04:32 +0200
Subject: [U-Boot-Users] [PATCH V3] Add the Harris QUAD100HD AMCC 405EP-based
	board.
Message-ID: <20080428140432.261ea55e@peedub.jennejohn.org>


Handle the last round of comments from Stefan in this third (V3) patch.

Signed-off-by: Gary Jennejohn <garyj at denx.de>
---
 MAINTAINERS                 |    4 +
 MAKEALL                     |    1 +
 Makefile                    |    3 +
 board/quad100hd/Makefile    |   51 ++++++++
 board/quad100hd/config.mk   |   24 ++++
 board/quad100hd/nand.c      |   79 ++++++++++++
 board/quad100hd/quad100hd.c |   93 ++++++++++++++
 board/quad100hd/u-boot.lds  |  133 +++++++++++++++++++
 include/configs/quad100hd.h |  293 +++++++++++++++++++++++++++++++++++++++++++
 9 files changed, 681 insertions(+), 0 deletions(-)
 create mode 100644 board/quad100hd/Makefile
 create mode 100644 board/quad100hd/config.mk
 create mode 100644 board/quad100hd/nand.c
 create mode 100644 board/quad100hd/quad100hd.c
 create mode 100644 board/quad100hd/u-boot.lds
 create mode 100644 include/configs/quad100hd.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d1782b4..3af55a3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -204,6 +204,10 @@ Klaus Heydeck <heydeck at kieback-peter.de>
 	KUP4K			MPC855
 	KUP4X			MPC859
 
+Gary Jennejohn <garyj at denx.de>
+
+	quad100hd		PPC405EP
+
 Murray Jensen <Murray.Jensen at csiro.au>
 
 	cogent_mpc8xx		MPC8xx
diff --git a/MAKEALL b/MAKEALL
index 38911ed..471f6f7 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -218,6 +218,7 @@ LIST_4xx="		\
 	PMC405		\
 	PMC440		\
 	PPChameleonEVB	\
+	quad100hd	\
 	rainier		\
 	sbc405		\
 	sc3		\
diff --git a/Makefile b/Makefile
index 4688a26..9a017a7 100644
--- a/Makefile
+++ b/Makefile
@@ -1381,6 +1381,9 @@ PPChameleonEVB_HI_33_config:	unconfig
 		}
 	@$(MKCONFIG) -a $(call xtract_4xx,$@) ppc ppc4xx PPChameleonEVB dave
 
+quad100hd_config:	unconfig
+	@$(MKCONFIG) $(@:_config=) ppc ppc4xx quad100hd
+
 sbc405_config:	unconfig
 	@$(MKCONFIG) $(@:_config=) ppc ppc4xx sbc405
 
diff --git a/board/quad100hd/Makefile b/board/quad100hd/Makefile
new file mode 100644
index 0000000..252ad5a
--- /dev/null
+++ b/board/quad100hd/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2007
+# Stefan Roese, DENX Software Engineering, sr at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).a
+
+COBJS	= $(BOARD).o nand.o
+SOBJS   =
+
+SRCS	:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS))
+SOBJS	:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB):	$(OBJS) $(SOBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+	rm -f $(SOBJS) $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/quad100hd/config.mk b/board/quad100hd/config.mk
new file mode 100644
index 0000000..1bdf5e4
--- /dev/null
+++ b/board/quad100hd/config.mk
@@ -0,0 +1,24 @@
+#
+# (C) Copyright 2000
+# Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+TEXT_BASE = 0xFFFC0000
diff --git a/board/quad100hd/nand.c b/board/quad100hd/nand.c
new file mode 100644
index 0000000..86d5cc3
--- /dev/null
+++ b/board/quad100hd/nand.c
@@ -0,0 +1,79 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <config.h>
+#if defined(CONFIG_CMD_NAND)
+#include <asm/gpio.h>
+#include <nand.h>
+
+/* 
+ *	hardware specific access to control-lines
+ */
+static void quad100hd_hwcontrol(struct mtd_info *mtd, int cmd)
+{
+	switch(cmd) {
+	case NAND_CTL_SETCLE:
+		gpio_write_bit(CFG_NAND_CLE, 1);
+		break;
+	case NAND_CTL_CLRCLE:
+		gpio_write_bit(CFG_NAND_CLE, 0);
+		break;
+
+	case NAND_CTL_SETALE:
+		gpio_write_bit(CFG_NAND_ALE, 1);
+		break;
+	case NAND_CTL_CLRALE:
+		gpio_write_bit(CFG_NAND_ALE, 0);
+		break;
+
+	case NAND_CTL_SETNCE:
+		gpio_write_bit(CFG_NAND_CE, 0);
+		break;
+	case NAND_CTL_CLRNCE:
+		gpio_write_bit(CFG_NAND_CE, 1);
+		break;
+	}
+}
+
+static int quad100hd_nand_ready(struct mtd_info *mtd)
+{
+	return gpio_read_in_bit(CFG_NAND_RDY);
+}
+
+/*
+ * Main initialization routine
+ */
+int board_nand_init(struct nand_chip *nand)
+{
+	/* Set address of hardware control function */
+	nand->hwcontrol = quad100hd_hwcontrol;
+	nand->dev_ready = quad100hd_nand_ready;
+	nand->eccmode = NAND_ECC_SOFT;
+	/* 15 us command delay time */
+	nand->chip_delay =  20;
+
+	/* Return happy */
+	return 0;
+}
+#endif /* CONFIG_CMD_NAND */
diff --git a/board/quad100hd/quad100hd.c b/board/quad100hd/quad100hd.c
new file mode 100644
index 0000000..9d2ddd1
--- /dev/null
+++ b/board/quad100hd/quad100hd.c
@@ -0,0 +1,93 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
+ *
+ * Based in part on board/icecube/icecube.c from PPCBoot
+ * (C) Copyright 2003 Intrinsyc Software
+ *
+ * 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 <common.h>
+#include <command.h>
+#include <malloc.h>
+#include <environment.h>
+#include <logbuff.h>
+#include <post.h>
+
+#include <asm/processor.h>
+#include <asm/io.h>
+#include <asm/gpio.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_early_init_f(void)
+{
+	/* taken from PPCBoot */
+	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
+	mtdcr(uicer, 0x00000000);	/* disable all ints */
+	mtdcr(uiccr, 0x00000000);
+	mtdcr(uicpr, 0xFFFF7FFE);	/* set int polarities */
+	mtdcr(uictr, 0x00000000);	/* set int trigger levels */
+	mtdcr(uicsr, 0xFFFFFFFF);	/* clear all ints */
+	mtdcr(uicvcr, 0x00000001);	/* set vect base=0,INT0 highest priority */
+
+    	mtdcr(CPC0_SRR, 0x00040000);   /* Hold PCI bridge in reset */
+
+	return 0;
+}
+
+/*
+ * Check Board Identity:
+ */
+int checkboard(void)
+{
+	char *s = getenv("serial#");
+#ifdef DISPLAY_BOARD_INFO
+	sys_info_t sysinfo;
+#endif
+
+	puts("Board: Quad100hd");
+
+	if (s != NULL) {
+		puts(", serial# ");
+		puts(s);
+	}
+	putc('\n');
+
+#ifdef DISPLAY_BOARD_INFO
+	/* taken from ppcboot */
+	get_sys_info(&sysinfo);
+
+	printf("\tVCO: %lu MHz\n", sysinfo.freqVCOMhz);
+	printf("\tCPU: %lu MHz\n", sysinfo.freqProcessor / 1000000);
+	printf("\tPLB: %lu MHz\n", sysinfo.freqPLB / 1000000);
+	printf("\tOPB: %lu MHz\n", sysinfo.freqOPB / 1000000);
+	printf("\tEPB: %lu MHz\n", sysinfo.freqPLB / (sysinfo.pllExtBusDiv *
+		1000000));
+	printf("\tPCI: %lu MHz\n", sysinfo.freqPCI / 1000000);
+#endif
+
+	return 0;
+}
+
+long int initdram(int board_type)
+{
+	return CFG_SDRAM_SIZE;
+}
diff --git a/board/quad100hd/u-boot.lds b/board/quad100hd/u-boot.lds
new file mode 100644
index 0000000..195d91b
--- /dev/null
+++ b/board/quad100hd/u-boot.lds
@@ -0,0 +1,133 @@
+/*
+ * (C) Copyright 2000
+ * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+OUTPUT_ARCH(powerpc)
+SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/usr/local/powerpc-any-elf/lib);
+/* Do we need any of these for elf?
+   __DYNAMIC = 0;    */
+SECTIONS
+{
+  .resetvec 0xFFFFFFFC :
+  {
+    *(.resetvec)
+  } = 0xffff
+
+  /* Read-only sections, merged into text segment: */
+  . = + SIZEOF_HEADERS;
+  .interp : { *(.interp) }
+  .hash          : { *(.hash)		}
+  .dynsym        : { *(.dynsym)		}
+  .dynstr        : { *(.dynstr)		}
+  .rel.text      : { *(.rel.text)		}
+  .rela.text     : { *(.rela.text) 	}
+  .rel.data      : { *(.rel.data)		}
+  .rela.data     : { *(.rela.data) 	}
+  .rel.rodata    : { *(.rel.rodata) 	}
+  .rela.rodata   : { *(.rela.rodata) 	}
+  .rel.got       : { *(.rel.got)		}
+  .rela.got      : { *(.rela.got)		}
+  .rel.ctors     : { *(.rel.ctors)	}
+  .rela.ctors    : { *(.rela.ctors)	}
+  .rel.dtors     : { *(.rel.dtors)	}
+  .rela.dtors    : { *(.rela.dtors)	}
+  .rel.bss       : { *(.rel.bss)		}
+  .rela.bss      : { *(.rela.bss)		}
+  .rel.plt       : { *(.rel.plt)		}
+  .rela.plt      : { *(.rela.plt)		}
+  .init          : { *(.init)	}
+  .plt : { *(.plt) }
+  .text      :
+  {
+    cpu/ppc4xx/start.o	(.text)
+
+    *(.text)
+    *(.fixup)
+    *(.got1)
+  }
+  _etext = .;
+  PROVIDE (etext = .);
+  .rodata    :
+  {
+    *(.rodata)
+    *(.rodata1)
+    *(.rodata.str1.4)
+  }
+  .fini      : { *(.fini)    } =0
+  .ctors     : { *(.ctors)   }
+  .dtors     : { *(.dtors)   }
+
+  /* Read-write section, merged into data segment: */
+  . = (. + 0x00FF) & 0xFFFFFF00;
+  _erotext = .;
+  PROVIDE (erotext = .);
+  .reloc   :
+  {
+    *(.got)
+    _GOT2_TABLE_ = .;
+    *(.got2)
+    _FIXUP_TABLE_ = .;
+    *(.fixup)
+  }
+  __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >>2;
+  __fixup_entries = (. - _FIXUP_TABLE_)>>2;
+
+  .data    :
+  {
+    *(.data)
+    *(.data1)
+    *(.sdata)
+    *(.sdata2)
+    *(.dynamic)
+    CONSTRUCTORS
+  }
+  _edata  =  .;
+  PROVIDE (edata = .);
+
+  . = .;
+  __u_boot_cmd_start = .;
+  .u_boot_cmd : { *(.u_boot_cmd) }
+  __u_boot_cmd_end = .;
+
+  . = .;
+  __start___ex_table = .;
+  __ex_table : { *(__ex_table) }
+  __stop___ex_table = .;
+
+  . = ALIGN(256);
+  __init_begin = .;
+  .text.init : { *(.text.init) }
+  .data.init : { *(.data.init) }
+  . = ALIGN(256);
+  __init_end = .;
+
+  __bss_start = .;
+  .bss (NOLOAD)       :
+  {
+   *(.sbss) *(.scommon)
+   *(.dynbss)
+   *(.bss)
+   *(COMMON)
+  }
+  _end = . ;
+  PROVIDE (end = .);
+}
diff --git a/include/configs/quad100hd.h b/include/configs/quad100hd.h
new file mode 100644
index 0000000..b2a7030
--- /dev/null
+++ b/include/configs/quad100hd.h
@@ -0,0 +1,293 @@
+/*
+ * (C) Copyright 2008
+ * Gary Jennejohn, DENX Software Engineering GmbH, garyj at denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	 See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+/************************************************************************
+ * quad100hd.h - configuration for Quad100hd board
+ ***********************************************************************/
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/*-----------------------------------------------------------------------
+ * High Level Configuration Options
+ *----------------------------------------------------------------------*/
+#define CONFIG_QUAD100HD	1		/* Board is Quad100hd	*/
+#define CONFIG_4xx		1		/* ... PPC4xx family	*/
+#define CONFIG_405EP		1		/* Specifc 405EP support*/
+
+#define CONFIG_SYS_CLK_FREQ     33333333 /* external frequency to pll   */
+
+#define CONFIG_BOARD_EARLY_INIT_F 1		/* Call board_early_init_f */
+
+#define PLLMR0_DEFAULT		PLLMR0_266_133_66 /* no PCI */
+#define PLLMR1_DEFAULT		PLLMR1_266_133_66 /* no PCI */
+
+#define CFG_ENV_IS_IN_EEPROM    1   /* use the EEPROM for environment vars */
+
+#define CONFIG_NET_MULTI	1
+#define CONFIG_HAS_ETH1		1
+#define CONFIG_MII		1	/* MII PHY management		*/
+#define CONFIG_PHY_ADDR		0x01	/* PHY address			*/
+#define CFG_RX_ETH_BUFFER	16	/* Number of ethernet rx buffers & descriptors */
+#define CONFIG_PHY_RESET	1
+#define CONFIG_PHY_RESET_DELAY	300	/* PHY RESET recovery delay	*/
+
+/*
+ * Command line configuration.
+ */
+#include <config_cmd_default.h>
+
+#undef CONFIG_CMD_ASKENV
+#undef CONFIG_CMD_CACHE
+#define CONFIG_CMD_DHCP
+#undef CONFIG_CMD_DIAG
+#define CONFIG_CMD_EEPROM
+#undef CONFIG_CMD_ELF
+#define CONFIG_CMD_I2C
+#undef CONFIG_CMD_IRQ
+#define CONFIG_CMD_JFFS2
+#undef CONFIG_CMD_LOG
+#undef CONFIG_CMD_MII
+#define CONFIG_CMD_NAND
+#undef CONFIG_CMD_PING
+#define CONFIG_CMD_REGINFO
+
+#undef CONFIG_WATCHDOG			/* watchdog disabled		*/
+
+/*-----------------------------------------------------------------------
+ * SDRAM
+ *----------------------------------------------------------------------*/
+/*
+ * SDRAM configuration (please see cpu/ppc/sdram.[ch])
+ */
+#define CONFIG_SDRAM_BANK0  1
+#define CFG_SDRAM_SIZE      0x02000000      /* 32 MB */
+
+/* FIX! SDRAM timings used in datasheet */
+#define CFG_SDRAM_CL            3       /* CAS latency */
+#define CFG_SDRAM_tRP           20      /* PRECHARGE command period */
+#define CFG_SDRAM_tRC           66      /* ACTIVE-to-ACTIVE command period */
+#define CFG_SDRAM_tRCD          20      /* ACTIVE-to-READ delay */
+#define CFG_SDRAM_tRFC          66      /* Auto refresh period */
+
+/* 
+ * JFFS2
+ */
+#define CFG_JFFS2_FIRST_BANK    0
+#ifdef  CFG_KERNEL_IN_JFFS2
+#define CFG_JFFS2_FIRST_SECTOR  0   /* JFFS starts at block 0 */
+#else /* kernel not in JFFS */
+#define CFG_JFFS2_FIRST_SECTOR  8   /* block 0-7 is kernel (1MB = 8 sectors) */
+#endif
+#define CFG_JFFS2_NUM_BANKS     1
+
+/*-----------------------------------------------------------------------
+ * Serial Port
+ *----------------------------------------------------------------------*/
+#undef	CFG_EXT_SERIAL_CLOCK			/* external serial clock */
+#define CFG_BASE_BAUD		691200
+#define CONFIG_BAUDRATE		115200
+#define CONFIG_SERIAL_MULTI
+
+/* The following table includes the supported baudrates */
+#define CFG_BAUDRATE_TABLE	\
+	{300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
+
+/*-----------------------------------------------------------------------
+ * Miscellaneous configurable options
+ *----------------------------------------------------------------------*/
+#define CFG_LONGHELP			/* undef to save memory		*/
+#define CFG_PROMPT	        "=> "	/* Monitor Command Prompt	*/
+#if defined(CONFIG_CMD_KGDB)
+#define CFG_CBSIZE	        1024	/* Console I/O Buffer Size	*/
+#else
+#define CFG_CBSIZE	        256	/* Console I/O Buffer Size	*/
+#endif
+#define CFG_PBSIZE              (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /* Print Buffer Size */
+#define CFG_MAXARGS	        16	/* max number of command args	*/
+#define CFG_BARGSIZE	        CFG_CBSIZE /* Boot Argument Buffer Size	*/
+
+#define CFG_MEMTEST_START	0x0400000 /* memtest works on		*/
+#define CFG_MEMTEST_END		0x0C00000 /* 4 ... 12 MB in DRAM	*/
+
+#define CFG_LOAD_ADDR		0x100000  /* default load address	*/
+#define CFG_EXTBDINFO		1	/* To use extended board_info (bd_t) */
+
+#define CFG_HZ		        1000	/* decrementer freq: 1 ms ticks	*/
+
+#define CONFIG_LOADS_ECHO	1	/* echo on for serial download	*/
+#define CFG_LOADS_BAUD_CHANGE	1	/* allow baudrate change	*/
+
+#define CONFIG_CMDLINE_EDITING	1	/* add command line history	*/
+#define CONFIG_LOOPW            1       /* enable loopw command         */
+#define CONFIG_MX_CYCLIC        1       /* enable mdc/mwc commands      */
+#define CONFIG_ZERO_BOOTDELAY_CHECK	/* check for keypress on bootdelay==0 */
+#define CONFIG_VERSION_VARIABLE 1	/* include version env variable */
+
+/*-----------------------------------------------------------------------
+ * I2C
+ *----------------------------------------------------------------------*/
+#define CONFIG_HARD_I2C		1		/* I2C with hardware support	*/
+#undef	CONFIG_SOFT_I2C				/* I2C bit-banged		*/
+#define CFG_I2C_SPEED		400000		/* I2C speed and slave address	*/
+#define CFG_I2C_SLAVE		0x7F
+
+#define CFG_I2C_EEPROM_ADDR	0x50		/* base address */
+#define CFG_I2C_EEPROM_ADDR_LEN	2		/* bytes of address */
+
+#define CFG_EEPROM_PAGE_WRITE_BITS	5	/* 8 byte write page size */
+#define CFG_EEPROM_PAGE_WRITE_DELAY_MS	10	/* and takes up to 10 msec */
+#define CFG_EEPROM_SIZE			0x2000	
+
+/*-----------------------------------------------------------------------
+ * Start addresses for the final memory configuration
+ * (Set up by the startup code)
+ * Please note that CFG_SDRAM_BASE _must_ start at 0
+ */
+#define CFG_SDRAM_BASE		0x00000000
+#define CFG_FLASH_BASE		0xFFC00000
+#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Monitor	*/
+#define CFG_MALLOC_LEN		(128 * 1024)	/* Reserve 128 kB for malloc()	*/
+#define CFG_MONITOR_BASE	(TEXT_BASE)
+
+/*
+ * For booting Linux, the board info and command line data
+ * have to be in the first 8 MB of memory, since this is
+ * the maximum mapped by the Linux kernel during initialization.
+ */
+#define CFG_BOOTMAPSZ		(8 << 20)	/* Initial Memory map for Linux */
+
+/*-----------------------------------------------------------------------
+ * FLASH organization
+ */
+#define CFG_FLASH_CFI			/* The flash is CFI compatible	*/
+#define	CFG_FLASH_CFI_DRIVER
+
+#define CFG_FLASH_BANKS_LIST	{ CFG_FLASH_BASE }
+
+#define CFG_MAX_FLASH_BANKS	1	/* max number of memory banks	*/
+#define CFG_MAX_FLASH_SECT	128	/* max number of sectors on one chip */
+
+#define CFG_FLASH_ERASE_TOUT	120000	/* Timeout for Flash Erase (in ms) */
+#define CFG_FLASH_WRITE_TOUT	500	/* Timeout for Flash Write (in ms) */
+
+#define CFG_FLASH_USE_BUFFER_WRITE 1	/* use buffered writes (20x faster) */
+#define CFG_FLASH_INCREMENT      0       /* there is only one bank         */
+
+#define CFG_FLASH_EMPTY_INFO		/* print 'E' for empty sector on flinfo */
+#define CFG_FLASH_QUIET_TEST	1	/* don't warn upon unknown flash */
+
+#ifdef CFG_ENV_IS_IN_FLASH
+#define CFG_ENV_SECT_SIZE	0x10000	/* size of one complete sector	*/
+#define	CFG_ENV_SIZE		0x10000	/* Total Size of Environment Sector */
+#define CFG_ENV_OFFSET		0x00050000 /* Offset of Environment Sector  */
+#define CFG_ENV_ADDR		(CFG_FLASH_BASE + CFG_ENV_OFFSET)
+#endif
+
+#ifdef CFG_ENV_IS_IN_EEPROM
+#define CFG_ENV_SIZE		0x400		/* Size of Environment vars */
+#define CFG_ENV_OFFSET		0x00000000
+#define CFG_ENABLE_CRC_16	1       /* Intrinsyc formatting used crc16 */
+#endif
+
+/* partly from PPCBoot */
+/* NAND */
+#define CONFIG_NAND
+#ifdef CONFIG_NAND
+#define CFG_NAND_BASE   0x60000000
+#define CFG_NAND_CS	10   /* our CS is GPIO10 */
+#define CFG_NAND_RDY	23   /* our RDY is GPIO23 */
+#define CFG_NAND_CE	24   /* our CE is GPIO24  */
+#define CFG_NAND_CLE	31   /* our CLE is GPIO31 */
+#define CFG_NAND_ALE	30   /* our ALE is GPIO30 */
+#define NAND_MAX_CHIPS	1
+#define CFG_MAX_NAND_DEVICE	1
+#endif
+
+/*-----------------------------------------------------------------------
+ * Definitions for initial stack pointer and data area (in data cache)
+ */
+/* use on chip memory (OCM) for temperary stack until sdram is tested */
+/* see ./cpu/ppc4xx/start.S */
+#define CFG_TEMP_STACK_OCM	1
+
+/* On Chip Memory location */
+#define CFG_OCM_DATA_ADDR	0xF8000000
+#define CFG_OCM_DATA_SIZE	0x1000
+#define CFG_INIT_RAM_ADDR	CFG_OCM_DATA_ADDR /* inside of OCM		*/
+#define CFG_INIT_RAM_END	CFG_OCM_DATA_SIZE /* End of used area in RAM	*/
+
+#define CFG_GBL_DATA_SIZE	128  /* size in bytes reserved for initial data */
+#define CFG_GBL_DATA_OFFSET	(CFG_INIT_RAM_END - CFG_GBL_DATA_SIZE)
+#define CFG_INIT_SP_OFFSET      CFG_GBL_DATA_OFFSET
+
+/*-----------------------------------------------------------------------
+ * External Bus Controller (EBC) Setup
+ * Taken from PPCBoot board/icecube/icecube.h
+ */
+
+/* see ./cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/ndfc.c */
+#define CFG_EBC_PB0AP		0x04002480
+/* AMD NOR flash - this corresponds to FLASH_BASE so may be correct */
+#define CFG_EBC_PB0CR		0xFFC5A000
+#define CFG_EBC_PB1AP           0x04005480
+#define CFG_EBC_PB1CR           0x60018000
+#define CFG_EBC_PB2AP           0x00000000
+#define CFG_EBC_PB2CR           0x00000000
+#define CFG_EBC_PB3AP           0x00000000
+#define CFG_EBC_PB3CR           0x00000000
+#define CFG_EBC_PB4AP           0x00000000
+#define CFG_EBC_PB4CR           0x00000000
+
+/*-----------------------------------------------------------------------
+ * Definitions for GPIO setup (PPC405EP specific)
+ *
+ * Taken in part from PPCBoot board/icecube/icecube.h
+ */
+/* see ./cpu/ppc4xx/cpu_init.c ./cpu/ppc4xx/start.S */
+#define CFG_GPIO0_OSRH		0x55555550
+#define CFG_GPIO0_OSRL		0x00000110
+#define CFG_GPIO0_ISR1H		0x00000000
+#define CFG_GPIO0_ISR1L		0x15555445
+#define CFG_GPIO0_TSRH		0x00000000
+#define CFG_GPIO0_TSRL		0x00000000
+#define CFG_GPIO0_TCR		0xFFFF8097
+#define CFG_GPIO0_ODR		0x00000000
+
+#if defined(CONFIG_CMD_KGDB)
+#define CONFIG_KGDB_BAUDRATE	230400		/* speed to run kgdb serial port */
+#define CONFIG_KGDB_SER_INDEX	2		/* which serial port to use */
+#endif
+
+/* ENVIRONMENT VARS */
+
+#define CONFIG_IPADDR		192.168.1.67
+#define CONFIG_SERVERIP		192.168.1.50
+#define CONFIG_GATEWAYIP	192.168.1.1
+#define CONFIG_NETMASK		255.255.255.0
+#define CONFIG_LOADADDR		300000
+#define CONFIG_BOOTDELAY	5	/* autoboot after 5 seconds */
+
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT	1
+
+#endif	/* __CONFIG_H */
-- 
1.5.5


---
Gary Jennejohn



From wd at denx.de  Mon Apr 28 14:07:56 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 14:07:56 +0200
Subject: [U-Boot-Users] [PATCH ARM/IXP465 3/3] Add support for the
	ixdp465 evaluation board
In-Reply-To: Your message of "Mon, 28 Apr 2008 13:02:42 +0200."
	<4815AED2.7040708@gandalf.sssup.it>
Message-ID: <20080428120756.41C40248A6@gemini.denx.de>

In message <4815AED2.7040708 at gandalf.sssup.it> you wrote:
>
> Add support for the ixdp465 evaluation board
> 
> Signed-off-by: Michael Trimarchi <michael at evidence.eu.com>
> 
> ---
>  Makefile                      |    3 +
>  board/ixdp465/Makefile        |   47 ++++++++
>  board/ixdp465/config.mk       |    3 +
>  board/ixdp465/ixdp465.c       |   62 ++++++++++
>  board/ixdp465/lowlevel_init.S |  129 +++++++++++++++++++++
>  board/ixdp465/u-boot.lds      |   57 +++++++++
>  include/configs/ixdp465.h     |  251 +++++++++++++++++++++++++++++++++++++++++
>  7 files changed, 552 insertions(+), 0 deletions(-)
>  create mode 100644 board/ixdp465/Makefile
>  create mode 100644 board/ixdp465/config.mk
>  create mode 100644 board/ixdp465/ixdp465.c
>  create mode 100644 board/ixdp465/lowlevel_init.S
>  create mode 100644 board/ixdp465/u-boot.lds
>  create mode 100644 include/configs/ixdp465.h

Entries in README, MAINTAINERS and MAKEALL missing.

> --- /dev/null
> +++ b/board/ixdp465/Makefile
...
> +include $(TOPDIR)/config.mk
> +
> +LIB	= lib$(BOARD).a
> +
> +OBJS	:= ixdp465.o
> +SOBJS := lowlevel_init.o
> +
> +$(LIB):	$(OBJS) $(SOBJS)
> +	$(AR) crv $@ $^
> +
> +clean:
> +	rm -f $(SOBJS) $(OBJS)
> +
> +distclean:	clean
> +	rm -f $(LIB) core *.bak .depend

Support for out-of-tree builds is missing completely.

> diff --git a/board/ixdp465/config.mk b/board/ixdp465/config.mk
> new file mode 100644
> index 0000000..dbfec9c
> --- /dev/null
> +++ b/board/ixdp465/config.mk
> @@ -0,0 +1,3 @@
> +TEXT_BASE = 0x01600000
> +# include NPE ethernet driver
> +BOARDLIBS = $(obj)cpu/ixp/npe/libnpe.a
> diff --git a/board/ixdp465/ixdp465.c b/board/ixdp465/ixdp465.c
> new file mode 100644
> index 0000000..c90841c


> diff --git a/include/configs/ixdp465.h b/include/configs/ixdp465.h
> new file mode 100644
> index 0000000..06a4166
> --- /dev/null
> +++ b/include/configs/ixdp465.h
...
> +/*#define CONFIG_ETHADDR	08:00:3e:26:0a:5b*/
> +#define CONFIG_NETMASK		255.255.255.0
> +#define CONFIG_IPADDR		10.30.3.204
> +#define CONFIG_SERVERIP		10.30.3.72

Please omit such network config data from thje config file; they are
almost always wrong and a PITA to the end user.

> +#define CONFIG_EXTRA_ENV_SETTINGS		\
> +	"ethaddr=00:02:b3:01:01:01\0"		\
> +	"eth1addr=00:02:b3:02:02:02\0"

Never do this.

Also, the MAC addresses above belong  to  the  Intel  Corporation;  I
doubt you have permissions to use these on your boards.

> +#define CONFIG_NR_DRAM_BANKS    1          /* we have 2 banks of DRAM */
> +#define PHYS_SDRAM_1            0x00000000 /* SDRAM Bank #1 */
> +#define PHYS_SDRAM_1_SIZE       0x08000000 /* 128 MB */

Please avoid hard-wired RAM sizes. Try to auto-adjust like most other
boards are doing.

> +#define PHYS_FLASH_1            0x50000000 /* Flash Bank #1 */
> +#define PHYS_FLASH_SIZE         0x02000000 /* 32 MB */
> +#define PHYS_FLASH_BANK_SIZE    0x02000000 /* 32 MB Banks */
> +#define PHYS_FLASH_SECT_SIZE    0x00020000 /* 128 KB sectors (x1) */

Ditto here.

> +#define CFG_DRAM_BASE           0x00000000
> +#define CFG_DRAM_SIZE           0x08000000

Is this SDRAM or DRAM ? Seems to be a bit redundant here...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Any time things appear to be going better, you have overlooked  some-
thing.



From andreas at schweigstill.de  Mon Apr 28 14:26:01 2008
From: andreas at schweigstill.de (Andreas Schweigstill)
Date: Mon, 28 Apr 2008 14:26:01 +0200
Subject: [U-Boot-Users] --- at91, Nand
In-Reply-To: <1752253171.20080428153248@tst.spb.su>
References: <1752253171.20080428153248@tst.spb.su>
Message-ID: <4815C259.3080706@schweigstill.de>

Hello!

Zhukov schrieb:
> I change PC1 to PC7 within u-boot everywhere, it won't work:
> I see SMWE strobe (pin PC3) drops down and never rises, the system
> hangs...

Are you also using PC6 for any purpose? Do you (accidentally) configure
it as an output? Or do you either use it as an input or don't enable an
internal or external pull-up resistor?

You should check the signal level on PC6 in order to find out if you
hit erratum "NWAIT activity depend on use of PC6".

With best regards
Andreas Schweigstill

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/



From g.liakhovetski at gmx.de  Mon Apr 28 14:35:57 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 28 Apr 2008 14:35:57 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] LinkStation: fix compiler warning,
	add a maintainer
In-Reply-To: <20080428102241.A83D0247AF@gemini.denx.de>
References: <20080428102241.A83D0247AF@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804281413440.7897@axis700.grange>

out_8 wants a pointer to an unsigned as the first argument. Add a 
maintainer for Linkstation boards.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

---

On Mon, 28 Apr 2008, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0803310112130.6825 at axis700.grange> you wrote:
> > This patch is based on the port by Mihai Georgian (see linkstation.c for 
> > Copyright information) and implements support for LinkStation / KuroBox HD 
> > and HG PPC models from Buffalo Technology, whereby HD is deactivated at 
> > the moment, pending network driver fixing.
> 
> The code throws a lot of compiler warnings:
> 
> ===== LOG/linkstation_HGLAN =====
> hwctl.c: In function 'miconCntl_SendUart':
> hwctl.c:30: warning: pointer targets in passing argument 1 of 'out_8' differ in signedness

Patch below.

diff --git a/board/linkstation/hwctl.c b/board/linkstation/hwctl.c
index 9db128a..2e5b5c8 100644
--- a/board/linkstation/hwctl.c
+++ b/board/linkstation/hwctl.c
@@ -27,7 +27,7 @@
 /*--------------------------------------------------------------*/
 static inline void miconCntl_SendUart(unsigned char dat)
 {
-	out_8((char *)AVR_PORT, dat);
+	out_8((unsigned char *)AVR_PORT, dat);
 	mdelay(1);
 }
 
diff --git a/MAINTAINERS b/MAINTAINERS
index d1782b4..58f833c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -408,6 +408,10 @@ John Zhan <zhanz at sinovee.com>
 
 	svm_sc8xx		MPC8xx
 
+Guennadi Liakhovetski <g.liakhovetski at gmx.de>
+
+	linkstation		MPC8241
+
 -------------------------------------------------------------------------
 
 Unknown / orphaned boards:



From g.liakhovetski at gmx.de  Mon Apr 28 14:36:06 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 28 Apr 2008 14:36:06 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] IDE: fix compiler warnings
In-Reply-To: <20080428102241.A83D0247AF@gemini.denx.de>
References: <20080428102241.A83D0247AF@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804281425590.7897@axis700.grange>

The IDE driver can use 32-bit addresses in LBA mode, in which case it 
spits multiple warnings during compilation. Fix them.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

---

On Mon, 28 Apr 2008, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0803310112130.6825 at axis700.grange> you wrote:
> > This patch is based on the port by Mihai Georgian (see linkstation.c for 
> > Copyright information) and implements support for LinkStation / KuroBox HD 
> > and HG PPC models from Buffalo Technology, whereby HD is deactivated at 
> > the moment, pending network driver fixing.
> 
> The code throws a lot of compiler warnings:
> 
> ===== LOG/linkstation_HGLAN =====
> cmd_ide.c: In function 'ide_read':
> cmd_ide.c:1267: warning: integer constant is too large for 'long' type
> cmd_ide.c:1321: warning: right shift count >= width of type
> cmd_ide.c:1322: warning: right shift count >= width of type
> cmd_ide.c: In function 'ide_write':
> cmd_ide.c:1386: warning: integer constant is too large for 'long' type
> cmd_ide.c:1411: warning: right shift count >= width of type
> cmd_ide.c:1412: warning: right shift count >= width of type

I think, these have been there for a while, in any case, patch below. 
Haven't found an IDE custodian.

diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 8ace970..a3ba353 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -1264,7 +1264,7 @@ ulong ide_read (int device, lbaint_t blknr, ulong blkcnt, void *buffer)
 #ifdef CONFIG_LBA48
 	unsigned char lba48 = 0;
 
-	if (blknr & 0x0000fffff0000000) {
+	if (blknr & 0x0000fffff0000000ULL) {
 		/* more than 28 bits used, use 48bit mode */
 		lba48 = 1;
 	}
@@ -1318,8 +1318,13 @@ ulong ide_read (int device, lbaint_t blknr, ulong blkcnt, void *buffer)
 			/* write high bits */
 			ide_outb (device, ATA_SECT_CNT, 0);
 			ide_outb (device, ATA_LBA_LOW,	(blknr >> 24) & 0xFF);
+#ifdef CFG_64BIT_LBA
 			ide_outb (device, ATA_LBA_MID,	(blknr >> 32) & 0xFF);
 			ide_outb (device, ATA_LBA_HIGH, (blknr >> 40) & 0xFF);
+#else
+			ide_outb (device, ATA_LBA_MID,	0);
+			ide_outb (device, ATA_LBA_HIGH, 0);
+#endif
 		}
 #endif
 		ide_outb (device, ATA_SECT_CNT, 1);
@@ -1383,7 +1388,7 @@ ulong ide_write (int device, lbaint_t blknr, ulong blkcnt, void *buffer)
 #ifdef CONFIG_LBA48
 	unsigned char lba48 = 0;
 
-	if (blknr & 0x0000fffff0000000) {
+	if (blknr & 0x0000fffff0000000ULL) {
 		/* more than 28 bits used, use 48bit mode */
 		lba48 = 1;
 	}
@@ -1408,8 +1413,13 @@ ulong ide_write (int device, lbaint_t blknr, ulong blkcnt, void *buffer)
 			/* write high bits */
 			ide_outb (device, ATA_SECT_CNT, 0);
 			ide_outb (device, ATA_LBA_LOW,	(blknr >> 24) & 0xFF);
+#ifdef CFG_64BIT_LBA
 			ide_outb (device, ATA_LBA_MID,	(blknr >> 32) & 0xFF);
 			ide_outb (device, ATA_LBA_HIGH, (blknr >> 40) & 0xFF);
+#else
+			ide_outb (device, ATA_LBA_MID,	0);
+			ide_outb (device, ATA_LBA_HIGH, 0);
+#endif
 		}
 #endif
 		ide_outb (device, ATA_SECT_CNT, 1);



From g.liakhovetski at gmx.de  Mon Apr 28 14:37:14 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Mon, 28 Apr 2008 14:37:14 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] rtl8169: fix compiler warnings
In-Reply-To: <20080428102241.A83D0247AF@gemini.denx.de>
References: <20080428102241.A83D0247AF@gemini.denx.de>
Message-ID: <Pine.LNX.4.64.0804281420130.7897@axis700.grange>

Fix multiple compiler warnings related to argument type mismatch.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

---

On Mon, 28 Apr 2008, Wolfgang Denk wrote:

> In message <Pine.LNX.4.64.0803310112130.6825 at axis700.grange> you wrote:
> > This patch is based on the port by Mihai Georgian (see linkstation.c for 
> > Copyright information) and implements support for LinkStation / KuroBox HD 
> > and HG PPC models from Buffalo Technology, whereby HD is deactivated at 
> > the moment, pending network driver fixing.
> 
> The code throws a lot of compiler warnings:
> 
> ===== LOG/linkstation_HGLAN =====
> rtl8169.c: In function 'rtl_recv':
> rtl8169.c:438: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast
> rtl8169.c: In function 'rtl_send':
> rtl8169.c:484: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast
> rtl8169.c: In function 'rtl8169_hw_start':
> rtl8169.c:582: warning: passing argument 2 of 'out_le32' makes integer from pointer without a cast
> rtl8169.c:583: warning: passing argument 2 of 'out_le32' makes integer from pointer without a cast
> rtl8169.c: In function 'rtl8169_init_ring':
> rtl8169.c:628: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast

Patch below.

diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index d39ac7c..6c4c9ff 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -435,7 +435,7 @@ static int rtl_recv(struct eth_device *dev)
 				tpc->RxDescArray[cur_rx].status =
 					cpu_to_le32(OWNbit + RX_BUF_SIZE);
 			tpc->RxDescArray[cur_rx].buf_addr =
-				cpu_to_le32(tpc->RxBufferRing[cur_rx]);
+				cpu_to_le32((unsigned long)tpc->RxBufferRing[cur_rx]);
 		} else {
 			puts("Error Rx");
 		}
@@ -481,7 +481,7 @@ static int rtl_send(struct eth_device *dev, volatile void *packet, int length)
 	while (len < ETH_ZLEN)
 		ptxb[len++] = '\0';
 
-	tpc->TxDescArray[entry].buf_addr = cpu_to_le32(ptxb);
+	tpc->TxDescArray[entry].buf_addr = cpu_to_le32((unsigned long)ptxb);
 	if (entry != (NUM_TX_DESC - 1)) {
 		tpc->TxDescArray[entry].status =
 			cpu_to_le32((OWNbit | FSbit | LSbit) |
@@ -579,8 +579,8 @@ static void rtl8169_hw_start(struct eth_device *dev)
 
 	tpc->cur_rx = 0;
 
-	RTL_W32(TxDescStartAddr, tpc->TxDescArray);
-	RTL_W32(RxDescStartAddr, tpc->RxDescArray);
+	RTL_W32(TxDescStartAddr, (unsigned long)tpc->TxDescArray);
+	RTL_W32(RxDescStartAddr, (unsigned long)tpc->RxDescArray);
 	RTL_W8(Cfg9346, Cfg9346_Lock);
 	udelay(10);
 
@@ -625,7 +625,7 @@ static void rtl8169_init_ring(struct eth_device *dev)
 
 		tpc->RxBufferRing[i] = &rxb[i * RX_BUF_SIZE];
 		tpc->RxDescArray[i].buf_addr =
-			cpu_to_le32(tpc->RxBufferRing[i]);
+			cpu_to_le32((unsigned long)tpc->RxBufferRing[i]);
 	}
 
 #ifdef DEBUG_RTL8169



From wd at denx.de  Mon Apr 28 14:56:17 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 14:56:17 +0200
Subject: [U-Boot-Users] [PATCH] cmd_nand.c: fix "differ in signedness"
	problem
Message-ID: <1209387377-7069-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 common/cmd_nand.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index f8fce0e..1a3c1df 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -840,12 +840,13 @@ int do_nand (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
 
 		if (strncmp (argv[1], "read", 4) == 0 ||
 		    strncmp (argv[1], "write", 5) == 0) {
-			ulong addr = simple_strtoul (argv[2], NULL, 16);
-			ulong off = simple_strtoul (argv[3], NULL, 16);
-			ulong size = simple_strtoul (argv[4], NULL, 16);
-			int cmd = (strncmp (argv[1], "read", 4) == 0) ?
-				NANDRW_READ : NANDRW_WRITE;
-			int ret, total;
+			ulong	addr = simple_strtoul (argv[2], NULL, 16);
+			off_t	off  = simple_strtoul (argv[3], NULL, 16);
+			size_t	size = simple_strtoul (argv[4], NULL, 16);
+			int	cmd = (strncmp (argv[1], "read", 4) == 0) ?
+					NANDRW_READ : NANDRW_WRITE;
+			size_t total;
+			int ret;
 			char *cmdtail = strchr (argv[1], '.');
 
 			if (cmdtail && !strncmp (cmdtail, ".oob", 2)) {
-- 
1.5.4.2




From trimarchi at gandalf.sssup.it  Mon Apr 28 16:38:52 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Mon, 28 Apr 2008 16:38:52 +0200
Subject: [U-Boot-Users] [PATCH ARM/IXP465 3/3] Add support for the
 ixdp465 evaluation board
In-Reply-To: <20080428120756.41C40248A6@gemini.denx.de>
References: <20080428120756.41C40248A6@gemini.denx.de>
Message-ID: <4815E17C.5030409@gandalf.sssup.it>

Hi
> Ditto here.
>
>   
>> +#define CFG_DRAM_BASE           0x00000000
>> +#define CFG_DRAM_SIZE           0x08000000
>>     
>
> Is this SDRAM or DRAM ? Seems to be a bit redundant here...
>
>
> Best regards,
>
> Wolfgang Denk
>
>   
Ok for all

Regards Michael




From sr at denx.de  Mon Apr 28 17:29:34 2008
From: sr at denx.de (Stefan Roese)
Date: Mon, 28 Apr 2008 17:29:34 +0200
Subject: [U-Boot-Users] [PATCH] PPC405EX(r) ECC and SDRAM Initialization
	Clean-ups
In-Reply-To: <C43ADE83.EDBC%gerickson@nuovations.com>
References: <C43ADE83.EDBC%gerickson@nuovations.com>
Message-ID: <200804281729.34880.sr@denx.de>

On Monday 28 April 2008, Grant Erickson wrote:
> The primary goal of this patch is to unify some of the low-level SDRAM and
> ECC initialization code for the PPC4xx processors that use a common DDR2
> SDRAM controller.
>
> In particular, in the case of the 405EX[r], it must initialize SDRAM before
> a primordial stack is available since OCM doesn't exist and the data cache
> doesn't work for such a purpose. As a consequence, the ECC (and SDRAM)
> initialization code must be stack-free.

We need to investigate here, why exactly the init-RAM in d-cache is currently 
not working on 405EX. Any ideas on this are very welcome. I'll try to dig 
into this in the a few days too.

> This patch creates such a stack-free ecc_init() routine that should,
> nonetheless, still be compatible from a C runtime environment.
>
> In addition, the patch cleans-up the Kilauea and Makalu SDRAM
> initialization code by polling SDRAM0_MCSTAT[MIC] as recommended by AMCC
> AN2131 rather than just waiting some arbitrary period of time. Also, the
> final controller initialization is generalized by ORing in
> SDRAM_MCOPT2_DCEN_ENABLE rather than just slamming 0x28000000 into the
> register. This is to make way for a future patch that uses CFG_SDRAM0_*
> values for boards that use such low-level initialization so they might
> share this SDRAM init code. Finally, while neither Kilauea nor Makalu have
> ECC memory, code is added to init.S for each to demonstrate how ecc_init()
> would be called if it were available as a reference.
>
> Signed-off-by: Grant Erickson <gerickson at nuovations.com>
>
> ---
>  board/amcc/kilauea/init.S |   53
> +++++++++++++++++++++++++++++++++++++++------

The patch is line-wrapped. Please use git-send-email is possible.

>  board/amcc/makalu/init.S  |   53
> +++++++++++++++++++++++++++++++++++++++------
>  cpu/ppc4xx/Makefile       |    1 +
>  cpu/ppc4xx/sdram.c        |   47 +++------------------------------------
>  4 files changed, 97 insertions(+), 57 deletions(-)

The ECC code seems to be missing.

I'll wait with further review until the missing ECC code is included. :)

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From scottwood at freescale.com  Mon Apr 28 17:48:10 2008
From: scottwood at freescale.com (Scott Wood)
Date: Mon, 28 Apr 2008 10:48:10 -0500
Subject: [U-Boot-Users] Kernel hanging after lmb_end_of_DRAM() function.
In-Reply-To: <OFAEDD8FEB.E7FAE664-ON65257435.001E5053-65257435.001DCF9D@lntemsys.com>
References: <20080423162725.GA32077@ld0162-tx32.am.freescale.net>
	<OFAEDD8FEB.E7FAE664-ON65257435.001E5053-65257435.001DCF9D@lntemsys.com>
Message-ID: <20080428154810.GC9849@ld0162-tx32.am.freescale.net>

On Thu, Apr 24, 2008 at 11:01:39AM +0530, Narendra KA wrote:
>    Thanks for the reply scott, :)
> 
> i forgot to mention , yes i am using device tree aware u-boot but the 
> problem is when i tried to build the u-boot source ( first i did ""make 
> ep8248_config"" and then ""make"") it was giving undefined reference 
> related to ft_board_setup() function so i altered the U-boot-1.3.2 source 
> code... i added the below code to the following file board/ep8248/ep8248.c
> 
> #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
> void ft_board_setup(void *blob, bd_t *bd)
> {
>         ft_cpu_setup(blob, bd);
> }
> #endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */

The 8260 ft_cpu_setup() seems a bit deficient -- most pertinently, it's
not calling fdt_fixup_memory(), but it's also missing brg frequency setup
and maybe some other things.  Look at other_cpu_setup() functions (e.g.
8xx, 83xx, 85xx) for an example of what to do.

> #define OF_CPU  "PowerPC,8248 at 0"
> #define OF_SOC  "soc at f0000000"
> #define OF_TBCLK        (bd->bi_busfreq / 4)
> #define OF_STDOUT_PATH  "/soc at f0000000/serial at 11a80"

These hardcoded things shouldn't be needed anymore.

> and how to use cuImage.pq2 ?

You'd need to change the makefile to tell it to build that target for
this board.  I recommend fixing u-boot, though, if you're already
inclined to go down that path.

> also i dint get what is dtbImage.ep8248e ? is 
> that same to ep8248e.dtb ??

No, that's an image for the PlanetCore bootloader.  If you don't have it,
you probably built with 'make uImage' rather than 'make zImage'.

-Scott



From frannk_m1 at yahoo.com  Mon Apr 28 18:31:25 2008
From: frannk_m1 at yahoo.com (Frank)
Date: Mon, 28 Apr 2008 09:31:25 -0700 (PDT)
Subject: [U-Boot-Users] Newbie in U-Boot, Some Queries
In-Reply-To: <253166975.210981209364639412.JavaMail.root@mbv4.indiatimes.com>
Message-ID: <848468.11935.qm@web32205.mail.mud.yahoo.com>


--- raajesh.n at indiatimes.com wrote:

> 
> HI ,
> 
> I am newbie to U-Boot, I have a customized  board with u-boot
> with it, I have seen through top level makefile of 
> U-Boot.Below stated is what I have observed from makefile.
> 
>  1. First initialization of processor (ARM922t in my case) is
> done in CPU folder with Startup.S where this assembly routine
> will call low_level_init code for initialization of RAM of
> customized board.
> 
>  2. Further I have observed rest all code which are required
> for boot-up is made as library and compiled at once.
> 
>  I would like to know how the code flow of U-Boot takes place
> , which are all the files which will be called in sequence
> while boot operation takes place, as far I have seen the code,
> Startup.S is one which starts first clearing Stack & PC which
> will further calls low_level_Init, I am unable to know how
> U-Boot works further from this place.
> 
> I would request U-Boot users to share there knowledge in
> explaining me how the code flow of U-Boot takes place, which
> will help me in finishing my project where RAM & Flash is
> changed.
> 
> 
> Best Regards,
> Rajesh
> 
cscope is your friend...


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ



From galak at kernel.crashing.org  Mon Apr 28 18:57:38 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Mon, 28 Apr 2008 11:57:38 -0500
Subject: [U-Boot-Users] [PATCH] 85xx: Additional fixes and cleanup of MP
	code
In-Reply-To: <20080428090735.DF375247B4@gemini.denx.de>
References: <20080428090735.DF375247B4@gemini.denx.de>
Message-ID: <25E1357A-0296-4AF5-8D6A-27B24C664549@kernel.crashing.org>


On Apr 28, 2008, at 4:07 AM, Wolfgang Denk wrote:
> In message <Pine.LNX.4.64.0804280223420.4305 at blarg.am.freescale.net>  
> you wrote:
>> * adjust __spin_table alignment to match ePAPR v0.94 spec
>> * loop over all cpus when determing who is up.  This fixes an issue  
>> if
>>  the "boot cpu" isn't core0.  The "boot cpu" will already be in the
>>  cpu_up_mask so there is no harm
>> * Added some protection in the code to ensure proper behavior.  These
>>  changes are explicitly needed but don't hurt:
>>  - Added eieio to ensure the "hot word" of the table is written after
>>    all other table updates have occurred.
>>  - Added isync to ensure we don't prefetch loading of table entries
>>    until we a released
>>
>> These issues we raised by Dave Liu.
>>
>> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
>
> Will Andy send a pull request or shall I apply directly?

just apply directly.

- k



From gerickson at nuovations.com  Mon Apr 28 18:53:56 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Mon, 28 Apr 2008 09:53:56 -0700
Subject: [U-Boot-Users] [PATCH v2] PPC405EX(r) ECC and SDRAM Initialization
	Clean-ups
In-Reply-To: <1209401636-9846-1-git-send-email-gerickson@nuovations.com>
References: <1209401636-9846-1-git-send-email-gerickson@nuovations.com>
Message-ID: <1209401636-9846-2-git-send-email-gerickson@nuovations.com>

---
 board/amcc/kilauea/init.S |   53 +++++++++++--
 board/amcc/makalu/init.S  |   53 +++++++++++--
 cpu/ppc4xx/Makefile       |    1 +
 cpu/ppc4xx/ecc.S          |  195 +++++++++++++++++++++++++++++++++++++++++++++
 cpu/ppc4xx/sdram.c        |   47 +----------
 5 files changed, 292 insertions(+), 57 deletions(-)

diff --git a/board/amcc/kilauea/init.S b/board/amcc/kilauea/init.S
index 053fe19..7603fcf 100644
--- a/board/amcc/kilauea/init.S
+++ b/board/amcc/kilauea/init.S
@@ -36,6 +36,10 @@
 	ori     r4,r4,value at l	;	\
 	mtdcr   memcfgd,r4	;
 
+#if defined(CONFIG_SDRAM_ECC)
+	.extern	ecc_init
+#endif /* defined(CONFIG_SDRAM_ECC) */
+
 	.globl  ext_bus_cntlr_init
 ext_bus_cntlr_init:
 #if !defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SPL)
@@ -126,12 +130,19 @@ ext_bus_cntlr_init:
 	/* SDRAM0_MCOPT2 (0X21) Start initialization */
 	mtsdram_as(SDRAM_MCOPT2, 0x20000000);
 
-	/* Step 5 */
-	lis     r3,0x1	/* 400000 =  wait 100ms */
-	mtctr   r3
+	/*
+	 * Step 5: Poll SDRAM0_MCSTAT[MIC] for assertion to indicate the
+	 * completion of initialization.
+	 */
 
-pll_wait:
-	bdnz	pll_wait
+	li      r4,SDRAM_MCSTAT
+	lis	r2,SDRAM_MCSTAT_MIC_COMP at h
+	ori	r2,r2,SDRAM_MCSTAT_MIC_COMP at l
+0:	mtdcr   memcfga,r4
+	mfdcr   r3,memcfgd
+	clrrwi	r3,r3,31		// Clear all bits except MCSTAT[MIC].
+	cmpw	cr7,r3,r2		// Check if MCSTAT[MIC] = 1.
+	bne+	cr7,0b			// No, not ready yet, keep polling.
 
 	/* Step 6 */
 
@@ -147,8 +158,36 @@ pll_wait:
 	/* SDRAM_RFDC */
 	mtsdram_as(SDRAM_RFDC, 0x00000209);
 
-	/* Enable memory controller */
-	mtsdram_as(SDRAM_MCOPT2, 0x28000000);
+	/*
+	 * Enable Controller by SDRAM0_MCOPT2[DCEN] = 1:
+	 *
+	 *   mcopt2 = mfsdram(SDRAM_MCOPT2)
+	 */
+
+	li	r4,SDRAM_MCOPT2
+	mtdcr	memcfga,r4
+	mfdcr	r3,memcfgd
+
+	/*
+	 *   mtsdram(SDRAM_MCOPT2, mcopt2 | SDRAM_MCOPT2_DCEN_ENABLE)
+	 */
+
+	mtdcr	memcfga,r4
+	oris	r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at h
+	ori	r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at l
+	mtdcr	memcfgd,r3
+
+#if defined(CONFIG_SDRAM_ECC)
+	mflr	r13
+	lis	r3,CFG_SDRAM_BASE at h
+	ori	r3,r3,CFG_SDRAM_BASE at l
+	lis	r4,(CFG_MBYTES_SDRAM << 20)@h
+	ori	r4,r4,(CFG_MBYTES_SDRAM << 20)@l
+	bl	ecc_init
+	mtlr	r13
+#endif /* defined(CONFIG_SDRAM_ECC) */
 #endif /* #ifndef CONFIG_NAND_U_BOOT */
+	
+	/* SDRAM is now ready for use. Return to the caller. */
 
 	blr
diff --git a/board/amcc/makalu/init.S b/board/amcc/makalu/init.S
index 5e9a5e0..c40d8d1 100644
--- a/board/amcc/makalu/init.S
+++ b/board/amcc/makalu/init.S
@@ -36,6 +36,10 @@
 	ori     r4,r4,value at l	;	\
 	mtdcr   memcfgd,r4	;
 
+#if defined(CONFIG_SDRAM_ECC)
+	.extern	ecc_init
+#endif /* defined(CONFIG_SDRAM_ECC) */
+
 	.globl  ext_bus_cntlr_init
 ext_bus_cntlr_init:
 
@@ -121,12 +125,19 @@ ext_bus_cntlr_init:
 	/* SDRAM0_MCOPT2 (0X21) Start initialization */
 	mtsdram_as(SDRAM_MCOPT2, 0x20000000);
 
-	/* Step 5 */
-	lis     r3,0x1	/* 400000 =  wait 100ms */
-	mtctr   r3
+	/*
+	 * Step 5: Poll SDRAM0_MCSTAT[MIC] for assertion to indicate the
+	 * completion of initialization.
+	 */
 
-pll_wait:
-	bdnz	pll_wait
+	li      r4,SDRAM_MCSTAT
+	lis	r2,SDRAM_MCSTAT_MIC_COMP at h
+	ori	r2,r2,SDRAM_MCSTAT_MIC_COMP at l
+0:	mtdcr   memcfga,r4
+	mfdcr   r3,memcfgd
+	clrrwi	r3,r3,31		// Clear all bits except MCSTAT[MIC].
+	cmpw	cr7,r3,r2		// Check if MCSTAT[MIC] = 1.
+	bne+	cr7,0b			// No, not ready yet, keep polling.
 
 	/* Step 6 */
 
@@ -142,7 +153,35 @@ pll_wait:
 	/* SDRAM_RFDC */
 	mtsdram_as(SDRAM_RFDC, 0x00000209);
 
-	/* Enable memory controller */
-	mtsdram_as(SDRAM_MCOPT2, 0x28000000);
+	/*
+	 * Enable Controller by SDRAM0_MCOPT2[DCEN] = 1:
+	 *
+	 *   mcopt2 = mfsdram(SDRAM_MCOPT2)
+	 */
+
+	li	r4,SDRAM_MCOPT2
+	mtdcr	memcfga,r4
+	mfdcr	r3,memcfgd
+
+	/*
+	 *   mtsdram(SDRAM_MCOPT2, mcopt2 | SDRAM_MCOPT2_DCEN_ENABLE)
+	 */
+
+	mtdcr	memcfga,r4
+	oris	r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at h
+	ori	r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at l
+	mtdcr	memcfgd,r3
+
+#if defined(CONFIG_SDRAM_ECC)
+	mflr	r13
+	lis	r3,CFG_SDRAM_BASE at h
+	ori	r3,r3,CFG_SDRAM_BASE at l
+	lis	r4,(CFG_MBYTES_SDRAM << 20)@h
+	ori	r4,r4,(CFG_MBYTES_SDRAM << 20)@l
+	bl	ecc_init
+	mtlr	r13
+#endif /* defined(CONFIG_SDRAM_ECC) */
+	
+	/* SDRAM is now ready for use. Return to the caller. */
 
 	blr
diff --git a/cpu/ppc4xx/Makefile b/cpu/ppc4xx/Makefile
index 178c5c6..f1e7ad2 100644
--- a/cpu/ppc4xx/Makefile
+++ b/cpu/ppc4xx/Makefile
@@ -31,6 +31,7 @@ START	+= start.o
 SOBJS	:= cache.o
 SOBJS	+= dcr.o
 SOBJS	+= kgdb.o
+SOBJS	+= ecc.o
 
 COBJS	:= 40x_spd_sdram.o
 COBJS	+= 44x_spd_ddr.o
diff --git a/cpu/ppc4xx/ecc.S b/cpu/ppc4xx/ecc.S
new file mode 100644
index 0000000..f56d246
--- /dev/null
+++ b/cpu/ppc4xx/ecc.S
@@ -0,0 +1,195 @@
+/*
+ *    Copyright (c) 2008 Nuovation System Designs, LLC
+ *      Grant Erickson <gerickson at nuovations.com>
+ *
+ *    Copyright (c) 2007 DENX Software Engineering, GmbH
+ *      Stefan Roese <sr at denx.de>
+ *
+ *    See file CREDITS for list of people who contributed to this
+ *    project.
+ *
+ *    This program is free software; you can redistribute it and/or
+ *    modify it under the terms of the GNU General Public License as
+ *    published by the Free Software Foundation; either version 2 of
+ *    the License, or (at your option) any later version.
+ *
+ *    This program is distributed in the hope that it will abe 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
+ *
+ *    Description:
+ *      This file implements ECC initialization for PowerPC processors
+ *      using the SDRAM DDR2 controller, including the 405EX(r),
+ *      440SP(E), 460EX and 460GT.
+ *
+ *      The implementation is in assembler since processors such as
+ *      the 405EX(r) need to initialize their SDRAM controller and ECC
+ *      prior to the availability of a primordial stack since they
+ *      have neither On-chip Memory (OCM) nor can they use the data
+ *      cache for such a use.
+ */
+
+#include <config.h>
+#include <ppc4xx.h>
+
+#include <ppc_asm.tmpl>
+#include <ppc_defs.h>
+
+#if !defined(CFG_SDRAM_ECC_PATTERN)
+#define	CFG_SDRAM_ECC_PATTERN	0x00000000
+#endif /* !defined(CFG_SDRAM_ECC_PATTERN) */
+
+
+/*
+ *  void ecc_init()
+ *
+ *  Description:
+ *    This routine initializes a range of SDRAM ECC memory with known
+ *    data and enabled ECC generation and checking.
+ *
+ *  Input(s):
+ *    start - A pointer to the start of memory covered by ECC requiring
+ *            initialization.
+ *    size  - The size, in bytes, of the memory covered by ECC requiring
+ *            initialization.
+ *
+ *  Output(s):
+ *    start - A pointer to the start of memory covered by ECC with
+ *            CFG_SDRAM_ECC_PATTERN written to all locations and ECC
+ *            data primed.
+ *
+ *  Returns:
+ *    N/A   
+ *
+ */	
+	.globl  ecc_init
+ecc_init:
+#if defined(CONFIG_SDRAM_ECC)
+	/*
+	 *   volatile ulong * const end = (volatile ulong * const)((ptrdiff_t)start + size)
+	 */
+	
+	add     r8,r3,r4
+
+	/*
+	 *   if (start >= end) {
+	 *       return;
+	 *   }
+	 */
+	  
+	cmplw   cr7,r3,r8
+	bge-    cr7,3f
+
+	/*
+	 * Read the current Memory Controller Options 1 (SDRAM0_MCOPT1)
+	 * value:
+	 *
+	 *   mcopt1 = mfsdram(SDRAM0_MCOPT1)
+	 */
+
+	li      r0,SDRAM_MCOPT1
+	mtdcr   memcfga,r0
+	mfdcr   r9,memcfgd
+
+	/*
+	 * Enable ECC generation without checking or reporting:
+	 *
+	 *   mtsdram(SDRAM_MCOPT1, ((mcopt1 & ~SDRAM_MCOPT1_MCHK_MASK) |
+	 *                          SDRAM_MCOPT1_MCHK_GEN));
+	 */
+	
+	mtdcr   memcfga,r0
+	lis     r0,(~SDRAM_MCOPT1_MCHK_MASK)@h
+	ori     r0,r0,(~SDRAM_MCOPT1_MCHK_MASK)@l
+	and     r7,r9,r0
+	oris    r0,r7,SDRAM_MCOPT1_MCHK_GEN at h
+	ori     r0,r0,SDRAM_MCOPT1_MCHK_GEN at l
+	mtdcr   memcfgd,r0
+
+#if defined(CONFIG_440)
+	/*
+	 * Look at the geometry of SDRAM (data width) to determine whether we
+	 * can skip words when writing:
+	 *
+	 *   if ((mcopt1 & DMWD_MASK) != DMWD_32) {
+	 *       increment = sizeof (u64);
+	 *   }
+	 */
+
+	lis     r0,SDRAM_MCOPT1_DMWD_MASK at h
+	ori     r0,r0,SDRAM_MCOPT1_DMWD_MASK at l
+	lis	r5,SDRAM_MCOPT1_DMWD_32 at h
+	ori	r5,r5,SDRAM_MCOPT1_DMWD_32 at l
+	and     r9,r9,r0
+	cmplw	cr7,r9,r5
+	beq	cr7,0f
+	li	r10,8
+#endif /* defined(CONFIG_440) */
+
+	/*
+	 *   increment = sizeof (u32);
+	 */
+
+0:	li	r10,4
+
+	/*
+	 *   const ulong pattern = CFG_SDRAM_ECC_PATTERN;
+	 */
+
+	lis     r0,CFG_SDRAM_ECC_PATTERN at h
+	ori     r0,r0,CFG_SDRAM_ECC_PATTERN at l
+	
+	/*
+	 *   volatile ulong * current = start;
+	 */
+
+	mr      r11,r3
+
+	/*
+	 *   while (current < end) {
+	 *       *current = pattern;
+	 *
+	 *       current = (volatile ulong *)((ptrdiff_t)current + increment);
+	 *   }
+	 */
+
+1:	stw     r0,0(r11)
+	add     r11,r11,r10
+	cmplw   cr7,r8,r11
+	bgt+    cr7,1b
+
+	/*
+	 *   while (*(volatile ulong *)((ptrdiff_t)current - increment) != pattern);
+	 */
+
+2:	subf    r9,r10,r11
+	lwz     r9,0(r9)
+	cmpw    cr7,r9,r0
+	bne+    cr7,2b
+
+	/*
+	 * Enable ECC generation with checking and no reporting at this
+	 * time:
+	 *
+	 *   mtsdram(SDRAM_MCOPT1, (mcopt1 & ~MCHK_MASK) | MCHK_CHK);
+	 */
+
+	li      r0,SDRAM_MCOPT1
+	mtdcr   memcfga,r0
+	oris    r0,r7,SDRAM_MCOPT1_MCHK_CHK at h
+	ori     r0,r0,SDRAM_MCOPT1_MCHK_CHK at l
+	mtdcr   memcfgd,r0
+
+	/*
+	 * ECC is now initialized, return to the caller.
+	 */
+#endif /* defined(CONFIG_SDRAM_ECC) */
+
+3:	blr
+
diff --git a/cpu/ppc4xx/sdram.c b/cpu/ppc4xx/sdram.c
index 2724d91..66d9ae8 100644
--- a/cpu/ppc4xx/sdram.c
+++ b/cpu/ppc4xx/sdram.c
@@ -32,6 +32,10 @@
 #include <asm/processor.h>
 #include "sdram.h"
 
+#if defined(CONFIG_SDRAM_ECC)
+extern void ecc_init(volatile ulong * const start, ulong size);
+#endif
+
 #ifdef CONFIG_SDRAM_BANK0
 
 #ifndef CONFIG_440
@@ -332,49 +336,6 @@ static void sdram_tr1_set(int ram_address, int* tr1_value)
 	*tr1_value = (first_good + last_bad) / 2;
 }
 
-#ifdef CONFIG_SDRAM_ECC
-static void ecc_init(ulong start, ulong size)
-{
-	ulong	current_addr;		/* current byte address */
-	ulong	end_addr;		/* end of memory region */
-	ulong	addr_inc;		/* address skip between writes */
-	ulong	cfg0_reg;		/* for restoring ECC state */
-
-	/*
-	 * TODO: Enable dcache before running this test (speedup)
-	 */
-
-	mfsdram(mem_cfg0, cfg0_reg);
-	mtsdram(mem_cfg0, (cfg0_reg & ~SDRAM_CFG0_MEMCHK) | SDRAM_CFG0_MEMCHK_GEN);
-
-	/*
-	 * look at geometry of SDRAM (data width) to determine whether we
-	 * can skip words when writing
-	 */
-	if ((cfg0_reg & SDRAM_CFG0_DRAMWDTH) == SDRAM_CFG0_DRAMWDTH_32)
-		addr_inc = 4;
-	else
-		addr_inc = 8;
-
-	current_addr = start;
-	end_addr = start + size;
-
-	while (current_addr < end_addr) {
-		*((ulong *)current_addr) = 0x00000000;
-		current_addr += addr_inc;
-	}
-
-	/*
-	 * TODO: Flush dcache and disable it again
-	 */
-
-	/*
-	 * Enable ecc checking and parity errors
-	 */
-	mtsdram(mem_cfg0, (cfg0_reg & ~SDRAM_CFG0_MEMCHK) | SDRAM_CFG0_MEMCHK_CHK);
-}
-#endif
-
 /*
  * Autodetect onboard DDR SDRAM on 440 platforms
  *



From gerickson at nuovations.com  Mon Apr 28 18:53:55 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Mon, 28 Apr 2008 09:53:55 -0700
Subject: [U-Boot-Users] [PATCH v2] PPC405EX(r) ECC and SDRAM Initialization
	Clean-ups
Message-ID: <1209401636-9846-1-git-send-email-gerickson@nuovations.com>

The primary goal of these changes is to unify some of the low-level
SDRAM and ECC initialization code for the PPC4xx processors that use a
common DDR2 SDRAM controller.

In particular, in the case of the 405EX[r], it must initialize SDRAM
before a primordial stack is available since OCM doesn't exist and the
data cache does not work for such a purpose. As a consequence, the ECC
(and SDRAM) initialization code must be stack-free.

This change creates such a stack-free ecc_init() routine that should,
nonetheless, still be compatiable from a C runtime environment.

In addition, the change cleans-up the Kilauea and Makalu SDRAM
initialization code by polling SDRAM0_MCSTAT[MIC} as recommended by
the AMCC AN2131 rather than just waiting some arbitrary period of
time. Also, the final controller initialization is generalized by
ORing in SDRAM_MCOPT2_DCEN_ENBALE rather than just slamming 0x28000000
into the register. This is to make way for a future patch that uses
CFG_SDRAM0_* values for boards that use such low-level initialization
so they might share this SDRAM init code. Finally, while niether
Kilauea nor Makalu have ECC memory, code is added to init.S for each
to demonstrate how ecc_init() would be called if it were available as
a reference.

Signed-off-by: Grant Erickson <gerickson at nuovations.com>

---
 board/amcc/kilauea/init.S |   53 +++++++++++--
 board/amcc/makalu/init.S  |   53 +++++++++++--
 cpu/ppc4xx/Makefile       |    1 +
 cpu/ppc4xx/ecc.S          |  195 +++++++++++++++++++++++++++++++++++++++++++++
 cpu/ppc4xx/sdram.c        |   47 +----------
 5 files changed, 292 insertions(+), 57 deletions(-)

diff --git a/board/amcc/kilauea/init.S b/board/amcc/kilauea/init.S
index 053fe19..7603fcf 100644
--- a/board/amcc/kilauea/init.S
+++ b/board/amcc/kilauea/init.S
@@ -36,6 +36,10 @@
 	ori     r4,r4,value at l	;	\
 	mtdcr   memcfgd,r4	;
 
+#if defined(CONFIG_SDRAM_ECC)
+	.extern	ecc_init
+#endif /* defined(CONFIG_SDRAM_ECC) */
+
 	.globl  ext_bus_cntlr_init
 ext_bus_cntlr_init:
 #if !defined(CONFIG_NAND_U_BOOT) || defined(CONFIG_NAND_SPL)
@@ -126,12 +130,19 @@ ext_bus_cntlr_init:
 	/* SDRAM0_MCOPT2 (0X21) Start initialization */
 	mtsdram_as(SDRAM_MCOPT2, 0x20000000);
 
-	/* Step 5 */
-	lis     r3,0x1	/* 400000 =  wait 100ms */
-	mtctr   r3
+	/*
+	 * Step 5: Poll SDRAM0_MCSTAT[MIC] for assertion to indicate the
+	 * completion of initialization.
+	 */
 
-pll_wait:
-	bdnz	pll_wait
+	li      r4,SDRAM_MCSTAT
+	lis	r2,SDRAM_MCSTAT_MIC_COMP at h
+	ori	r2,r2,SDRAM_MCSTAT_MIC_COMP at l
+0:	mtdcr   memcfga,r4
+	mfdcr   r3,memcfgd
+	clrrwi	r3,r3,31		// Clear all bits except MCSTAT[MIC].
+	cmpw	cr7,r3,r2		// Check if MCSTAT[MIC] = 1.
+	bne+	cr7,0b			// No, not ready yet, keep polling.
 
 	/* Step 6 */
 
@@ -147,8 +158,36 @@ pll_wait:
 	/* SDRAM_RFDC */
 	mtsdram_as(SDRAM_RFDC, 0x00000209);
 
-	/* Enable memory controller */
-	mtsdram_as(SDRAM_MCOPT2, 0x28000000);
+	/*
+	 * Enable Controller by SDRAM0_MCOPT2[DCEN] = 1:
+	 *
+	 *   mcopt2 = mfsdram(SDRAM_MCOPT2)
+	 */
+
+	li	r4,SDRAM_MCOPT2
+	mtdcr	memcfga,r4
+	mfdcr	r3,memcfgd
+
+	/*
+	 *   mtsdram(SDRAM_MCOPT2, mcopt2 | SDRAM_MCOPT2_DCEN_ENABLE)
+	 */
+
+	mtdcr	memcfga,r4
+	oris	r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at h
+	ori	r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at l
+	mtdcr	memcfgd,r3
+
+#if defined(CONFIG_SDRAM_ECC)
+	mflr	r13
+	lis	r3,CFG_SDRAM_BASE at h
+	ori	r3,r3,CFG_SDRAM_BASE at l
+	lis	r4,(CFG_MBYTES_SDRAM << 20)@h
+	ori	r4,r4,(CFG_MBYTES_SDRAM << 20)@l
+	bl	ecc_init
+	mtlr	r13
+#endif /* defined(CONFIG_SDRAM_ECC) */
 #endif /* #ifndef CONFIG_NAND_U_BOOT */
+	
+	/* SDRAM is now ready for use. Return to the caller. */
 
 	blr
diff --git a/board/amcc/makalu/init.S b/board/amcc/makalu/init.S
index 5e9a5e0..c40d8d1 100644
--- a/board/amcc/makalu/init.S
+++ b/board/amcc/makalu/init.S
@@ -36,6 +36,10 @@
 	ori     r4,r4,value at l	;	\
 	mtdcr   memcfgd,r4	;
 
+#if defined(CONFIG_SDRAM_ECC)
+	.extern	ecc_init
+#endif /* defined(CONFIG_SDRAM_ECC) */
+
 	.globl  ext_bus_cntlr_init
 ext_bus_cntlr_init:
 
@@ -121,12 +125,19 @@ ext_bus_cntlr_init:
 	/* SDRAM0_MCOPT2 (0X21) Start initialization */
 	mtsdram_as(SDRAM_MCOPT2, 0x20000000);
 
-	/* Step 5 */
-	lis     r3,0x1	/* 400000 =  wait 100ms */
-	mtctr   r3
+	/*
+	 * Step 5: Poll SDRAM0_MCSTAT[MIC] for assertion to indicate the
+	 * completion of initialization.
+	 */
 
-pll_wait:
-	bdnz	pll_wait
+	li      r4,SDRAM_MCSTAT
+	lis	r2,SDRAM_MCSTAT_MIC_COMP at h
+	ori	r2,r2,SDRAM_MCSTAT_MIC_COMP at l
+0:	mtdcr   memcfga,r4
+	mfdcr   r3,memcfgd
+	clrrwi	r3,r3,31		// Clear all bits except MCSTAT[MIC].
+	cmpw	cr7,r3,r2		// Check if MCSTAT[MIC] = 1.
+	bne+	cr7,0b			// No, not ready yet, keep polling.
 
 	/* Step 6 */
 
@@ -142,7 +153,35 @@ pll_wait:
 	/* SDRAM_RFDC */
 	mtsdram_as(SDRAM_RFDC, 0x00000209);
 
-	/* Enable memory controller */
-	mtsdram_as(SDRAM_MCOPT2, 0x28000000);
+	/*
+	 * Enable Controller by SDRAM0_MCOPT2[DCEN] = 1:
+	 *
+	 *   mcopt2 = mfsdram(SDRAM_MCOPT2)
+	 */
+
+	li	r4,SDRAM_MCOPT2
+	mtdcr	memcfga,r4
+	mfdcr	r3,memcfgd
+
+	/*
+	 *   mtsdram(SDRAM_MCOPT2, mcopt2 | SDRAM_MCOPT2_DCEN_ENABLE)
+	 */
+
+	mtdcr	memcfga,r4
+	oris	r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at h
+	ori	r3,r3,SDRAM_MCOPT2_DCEN_ENABLE at l
+	mtdcr	memcfgd,r3
+
+#if defined(CONFIG_SDRAM_ECC)
+	mflr	r13
+	lis	r3,CFG_SDRAM_BASE at h
+	ori	r3,r3,CFG_SDRAM_BASE at l
+	lis	r4,(CFG_MBYTES_SDRAM << 20)@h
+	ori	r4,r4,(CFG_MBYTES_SDRAM << 20)@l
+	bl	ecc_init
+	mtlr	r13
+#endif /* defined(CONFIG_SDRAM_ECC) */
+	
+	/* SDRAM is now ready for use. Return to the caller. */
 
 	blr
diff --git a/cpu/ppc4xx/Makefile b/cpu/ppc4xx/Makefile
index 178c5c6..f1e7ad2 100644
--- a/cpu/ppc4xx/Makefile
+++ b/cpu/ppc4xx/Makefile
@@ -31,6 +31,7 @@ START	+= start.o
 SOBJS	:= cache.o
 SOBJS	+= dcr.o
 SOBJS	+= kgdb.o
+SOBJS	+= ecc.o
 
 COBJS	:= 40x_spd_sdram.o
 COBJS	+= 44x_spd_ddr.o
diff --git a/cpu/ppc4xx/ecc.S b/cpu/ppc4xx/ecc.S
new file mode 100644
index 0000000..f56d246
--- /dev/null
+++ b/cpu/ppc4xx/ecc.S
@@ -0,0 +1,195 @@
+/*
+ *    Copyright (c) 2008 Nuovation System Designs, LLC
+ *      Grant Erickson <gerickson at nuovations.com>
+ *
+ *    Copyright (c) 2007 DENX Software Engineering, GmbH
+ *      Stefan Roese <sr at denx.de>
+ *
+ *    See file CREDITS for list of people who contributed to this
+ *    project.
+ *
+ *    This program is free software; you can redistribute it and/or
+ *    modify it under the terms of the GNU General Public License as
+ *    published by the Free Software Foundation; either version 2 of
+ *    the License, or (at your option) any later version.
+ *
+ *    This program is distributed in the hope that it will abe 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
+ *
+ *    Description:
+ *      This file implements ECC initialization for PowerPC processors
+ *      using the SDRAM DDR2 controller, including the 405EX(r),
+ *      440SP(E), 460EX and 460GT.
+ *
+ *      The implementation is in assembler since processors such as
+ *      the 405EX(r) need to initialize their SDRAM controller and ECC
+ *      prior to the availability of a primordial stack since they
+ *      have neither On-chip Memory (OCM) nor can they use the data
+ *      cache for such a use.
+ */
+
+#include <config.h>
+#include <ppc4xx.h>
+
+#include <ppc_asm.tmpl>
+#include <ppc_defs.h>
+
+#if !defined(CFG_SDRAM_ECC_PATTERN)
+#define	CFG_SDRAM_ECC_PATTERN	0x00000000
+#endif /* !defined(CFG_SDRAM_ECC_PATTERN) */
+
+
+/*
+ *  void ecc_init()
+ *
+ *  Description:
+ *    This routine initializes a range of SDRAM ECC memory with known
+ *    data and enabled ECC generation and checking.
+ *
+ *  Input(s):
+ *    start - A pointer to the start of memory covered by ECC requiring
+ *            initialization.
+ *    size  - The size, in bytes, of the memory covered by ECC requiring
+ *            initialization.
+ *
+ *  Output(s):
+ *    start - A pointer to the start of memory covered by ECC with
+ *            CFG_SDRAM_ECC_PATTERN written to all locations and ECC
+ *            data primed.
+ *
+ *  Returns:
+ *    N/A   
+ *
+ */	
+	.globl  ecc_init
+ecc_init:
+#if defined(CONFIG_SDRAM_ECC)
+	/*
+	 *   volatile ulong * const end = (volatile ulong * const)((ptrdiff_t)start + size)
+	 */
+	
+	add     r8,r3,r4
+
+	/*
+	 *   if (start >= end) {
+	 *       return;
+	 *   }
+	 */
+	  
+	cmplw   cr7,r3,r8
+	bge-    cr7,3f
+
+	/*
+	 * Read the current Memory Controller Options 1 (SDRAM0_MCOPT1)
+	 * value:
+	 *
+	 *   mcopt1 = mfsdram(SDRAM0_MCOPT1)
+	 */
+
+	li      r0,SDRAM_MCOPT1
+	mtdcr   memcfga,r0
+	mfdcr   r9,memcfgd
+
+	/*
+	 * Enable ECC generation without checking or reporting:
+	 *
+	 *   mtsdram(SDRAM_MCOPT1, ((mcopt1 & ~SDRAM_MCOPT1_MCHK_MASK) |
+	 *                          SDRAM_MCOPT1_MCHK_GEN));
+	 */
+	
+	mtdcr   memcfga,r0
+	lis     r0,(~SDRAM_MCOPT1_MCHK_MASK)@h
+	ori     r0,r0,(~SDRAM_MCOPT1_MCHK_MASK)@l
+	and     r7,r9,r0
+	oris    r0,r7,SDRAM_MCOPT1_MCHK_GEN at h
+	ori     r0,r0,SDRAM_MCOPT1_MCHK_GEN at l
+	mtdcr   memcfgd,r0
+
+#if defined(CONFIG_440)
+	/*
+	 * Look at the geometry of SDRAM (data width) to determine whether we
+	 * can skip words when writing:
+	 *
+	 *   if ((mcopt1 & DMWD_MASK) != DMWD_32) {
+	 *       increment = sizeof (u64);
+	 *   }
+	 */
+
+	lis     r0,SDRAM_MCOPT1_DMWD_MASK at h
+	ori     r0,r0,SDRAM_MCOPT1_DMWD_MASK at l
+	lis	r5,SDRAM_MCOPT1_DMWD_32 at h
+	ori	r5,r5,SDRAM_MCOPT1_DMWD_32 at l
+	and     r9,r9,r0
+	cmplw	cr7,r9,r5
+	beq	cr7,0f
+	li	r10,8
+#endif /* defined(CONFIG_440) */
+
+	/*
+	 *   increment = sizeof (u32);
+	 */
+
+0:	li	r10,4
+
+	/*
+	 *   const ulong pattern = CFG_SDRAM_ECC_PATTERN;
+	 */
+
+	lis     r0,CFG_SDRAM_ECC_PATTERN at h
+	ori     r0,r0,CFG_SDRAM_ECC_PATTERN at l
+	
+	/*
+	 *   volatile ulong * current = start;
+	 */
+
+	mr      r11,r3
+
+	/*
+	 *   while (current < end) {
+	 *       *current = pattern;
+	 *
+	 *       current = (volatile ulong *)((ptrdiff_t)current + increment);
+	 *   }
+	 */
+
+1:	stw     r0,0(r11)
+	add     r11,r11,r10
+	cmplw   cr7,r8,r11
+	bgt+    cr7,1b
+
+	/*
+	 *   while (*(volatile ulong *)((ptrdiff_t)current - increment) != pattern);
+	 */
+
+2:	subf    r9,r10,r11
+	lwz     r9,0(r9)
+	cmpw    cr7,r9,r0
+	bne+    cr7,2b
+
+	/*
+	 * Enable ECC generation with checking and no reporting at this
+	 * time:
+	 *
+	 *   mtsdram(SDRAM_MCOPT1, (mcopt1 & ~MCHK_MASK) | MCHK_CHK);
+	 */
+
+	li      r0,SDRAM_MCOPT1
+	mtdcr   memcfga,r0
+	oris    r0,r7,SDRAM_MCOPT1_MCHK_CHK at h
+	ori     r0,r0,SDRAM_MCOPT1_MCHK_CHK at l
+	mtdcr   memcfgd,r0
+
+	/*
+	 * ECC is now initialized, return to the caller.
+	 */
+#endif /* defined(CONFIG_SDRAM_ECC) */
+
+3:	blr
+
diff --git a/cpu/ppc4xx/sdram.c b/cpu/ppc4xx/sdram.c
index 2724d91..66d9ae8 100644
--- a/cpu/ppc4xx/sdram.c
+++ b/cpu/ppc4xx/sdram.c
@@ -32,6 +32,10 @@
 #include <asm/processor.h>
 #include "sdram.h"
 
+#if defined(CONFIG_SDRAM_ECC)
+extern void ecc_init(volatile ulong * const start, ulong size);
+#endif
+
 #ifdef CONFIG_SDRAM_BANK0
 
 #ifndef CONFIG_440
@@ -332,49 +336,6 @@ static void sdram_tr1_set(int ram_address, int* tr1_value)
 	*tr1_value = (first_good + last_bad) / 2;
 }
 
-#ifdef CONFIG_SDRAM_ECC
-static void ecc_init(ulong start, ulong size)
-{
-	ulong	current_addr;		/* current byte address */
-	ulong	end_addr;		/* end of memory region */
-	ulong	addr_inc;		/* address skip between writes */
-	ulong	cfg0_reg;		/* for restoring ECC state */
-
-	/*
-	 * TODO: Enable dcache before running this test (speedup)
-	 */
-
-	mfsdram(mem_cfg0, cfg0_reg);
-	mtsdram(mem_cfg0, (cfg0_reg & ~SDRAM_CFG0_MEMCHK) | SDRAM_CFG0_MEMCHK_GEN);
-
-	/*
-	 * look at geometry of SDRAM (data width) to determine whether we
-	 * can skip words when writing
-	 */
-	if ((cfg0_reg & SDRAM_CFG0_DRAMWDTH) == SDRAM_CFG0_DRAMWDTH_32)
-		addr_inc = 4;
-	else
-		addr_inc = 8;
-
-	current_addr = start;
-	end_addr = start + size;
-
-	while (current_addr < end_addr) {
-		*((ulong *)current_addr) = 0x00000000;
-		current_addr += addr_inc;
-	}
-
-	/*
-	 * TODO: Flush dcache and disable it again
-	 */
-
-	/*
-	 * Enable ecc checking and parity errors
-	 */
-	mtsdram(mem_cfg0, (cfg0_reg & ~SDRAM_CFG0_MEMCHK) | SDRAM_CFG0_MEMCHK_CHK);
-}
-#endif
-
 /*
  * Autodetect onboard DDR SDRAM on 440 platforms
  *




From scottwood at freescale.com  Mon Apr 28 20:35:25 2008
From: scottwood at freescale.com (Scott Wood)
Date: Mon, 28 Apr 2008 13:35:25 -0500
Subject: [U-Boot-Users] Nand patch for MPC8313ERDB on U-boot 1.3.2
In-Reply-To: <003601c8a80f$7336dbd0$59a49370$@net>
References: <003601c8a80f$7336dbd0$59a49370$@net>
Message-ID: <20080428183525.GA13922@ld0162-tx32.am.freescale.net>

On Sat, Apr 26, 2008 at 08:36:07PM -0600, Daniel wrote:
> I am working on a MPC8313ERDB REVA4 board and need to work with a nand
> device using u-boot.  Are there any patches available to get nand working on
> u-boot 1.3.2?  And if so where can I find it.  

Patches were posted within the past couple months against the
mtd-2.6.22.1 branch of the u-boot nand repository.

-Scott



From wd at denx.de  Mon Apr 28 20:43:17 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 20:43:17 +0200
Subject: [U-Boot-Users] [PATCH] LinkStation: fix compiler warning,
	add a maintainer
In-Reply-To: Your message of "Mon, 28 Apr 2008 14:35:57 +0200."
	<Pine.LNX.4.64.0804281413440.7897@axis700.grange>
Message-ID: <20080428184317.6DF63247AF@gemini.denx.de>

In message <Pine.LNX.4.64.0804281413440.7897 at axis700.grange> you wrote:
> out_8 wants a pointer to an unsigned as the first argument. Add a 
> maintainer for Linkstation boards.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The heart is not a logical organ.
	-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4



From wd at denx.de  Mon Apr 28 20:43:29 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 20:43:29 +0200
Subject: [U-Boot-Users] [PATCH] IDE: fix compiler warnings
In-Reply-To: Your message of "Mon, 28 Apr 2008 14:36:06 +0200."
	<Pine.LNX.4.64.0804281425590.7897@axis700.grange>
Message-ID: <20080428184329.A1314247AF@gemini.denx.de>

In message <Pine.LNX.4.64.0804281425590.7897 at axis700.grange> you wrote:
> The IDE driver can use 32-bit addresses in LBA mode, in which case it 
> spits multiple warnings during compilation. Fix them.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
On a clear disk you can seek forever.



From wd at denx.de  Mon Apr 28 20:43:48 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 20:43:48 +0200
Subject: [U-Boot-Users] [PATCH] rtl8169: fix compiler warnings
In-Reply-To: Your message of "Mon, 28 Apr 2008 14:37:14 +0200."
	<Pine.LNX.4.64.0804281420130.7897@axis700.grange>
Message-ID: <20080428184348.D2FE6247AF@gemini.denx.de>

In message <Pine.LNX.4.64.0804281420130.7897 at axis700.grange> you wrote:
> Fix multiple compiler warnings related to argument type mismatch.
> 
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski at gmx.de>

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
CAUTION:  The Mass of This Product Contains the Energy Equivalent  of
85 Million Tons of TNT per Net Ounce of Weight.



From scottwood at freescale.com  Mon Apr 28 20:52:44 2008
From: scottwood at freescale.com (Scott Wood)
Date: Mon, 28 Apr 2008 13:52:44 -0500
Subject: [U-Boot-Users] Kernel hanging after lmb_end_of_DRAM() function
In-Reply-To: <20080424114242.2BD0B24AB1@gemini.denx.de>
References: <16833978.post@talk.nabble.com>
	<20080424114242.2BD0B24AB1@gemini.denx.de>
Message-ID: <20080428185244.GB14562@ld0162-tx32.am.freescale.net>

On Thu, Apr 24, 2008 at 01:42:42PM +0200, Wolfgang Denk wrote:
> In message <16833978.post at talk.nabble.com> you wrote:
> > 
> > i am trying to bring up the latest kernel on EP8248 target,
> ...
> > Please share your knowledge and skills and help me to resolve this issue..
> 
> I can't help with your Linux kernel problem, but I'm pretty sure that
> it is off topic on this mailing list.

As it turns out, it wasn't off-topic -- the problem is u-boot's fdt
setup for 8260-ish chips.

-Scott



From wd at denx.de  Mon Apr 28 21:05:29 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 21:05:29 +0200
Subject: [U-Boot-Users] Kernel hanging after lmb_end_of_DRAM() function
In-Reply-To: Your message of "Mon, 28 Apr 2008 13:52:44 CDT."
	<20080428185244.GB14562@ld0162-tx32.am.freescale.net>
Message-ID: <20080428190529.CC2D1247B4@gemini.denx.de>

In message <20080428185244.GB14562 at ld0162-tx32.am.freescale.net> you wrote:
>
> As it turns out, it wasn't off-topic -- the problem is u-boot's fdt
> setup for 8260-ish chips.

ACK. I stand corrected.

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: wd at denx.de
Without facts, the decision cannot be made logically. You  must  rely
on your human intuition.
	-- Spock, "Assignment: Earth", stardate unknown



From onyxtape at hotmail.com  Mon Apr 28 21:10:21 2008
From: onyxtape at hotmail.com (onyxtape)
Date: Mon, 28 Apr 2008 12:10:21 -0700 (PDT)
Subject: [U-Boot-Users]  Running uC/OS-II on top of u-boot
Message-ID: <16945849.post@talk.nabble.com>


Hello all,

We have a PowerPC 440 EP (from a AMCC Yosemite evaluation kit) and we are in
the process of evaluating OSes for it. The industrial strength ones (like
vxWorks) are too much feature-wise and money-wise, so we're hoping to try
out uC/OS-II. 

If someone has tried to do this before, I have a few questions:

- How do you configure it to run on top of u-boot? What commands are used?

- Can the porting layer of uC/OS-II use some of the u-boot functions for PCI
and ethernet access?

- Are there any existing instructions on how to build (or create a makefile)
uC/OS-II using the compilers supplied by the ELDK? I keep getting a failure
to "find entry symbol _start", even if I include the gcc libraries,
crtbegin.o, etc. 

I appreciate any help that I can get with my questions. Thanks!
-- 
View this message in context: http://www.nabble.com/Running-uC-OS-II-on-top-of-u-boot-tp16945849p16945849.html
Sent from the Uboot - Users mailing list archive at Nabble.com.




From Ken.Fuchs at bench.com  Mon Apr 28 21:24:39 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Mon, 28 Apr 2008 14:24:39 -0500
Subject: [U-Boot-Users] how to make a core uboot? (Comments about AT91
	BMS)
In-Reply-To: <48159E21.70205@schweigstill.de>
Message-ID: <AA28F077645B324881335614E4F7C428034CEF@win-ex01.bench.com>

Andreas Schweigstill wrote:

> On certain platforms (e.g. Atmel AT91) even U-Boot will just 
> be used as a second or third level bootloader. The basic CPU
> setup has been done before starting U-Boot.

Qualification: The following is true for all AT91SAM9 processors.
It probably also applies to AT91CAP9 processors.  I'm not sure it
applies to other AT91 processors though.

This is only true of Atmel AT91 processors with BMS set to 1.
Execution starts in the Atmel AT91's internal ROM.  The ROM
loads code from a SPI NOR flash (Dataflash) into internal SRAM
or external SDRAM.  (If the SRAM step is skipped, U-Boot would
be the second stage bootloader.)  With an SRAM bootloader stage
(AT91Bootstrap) as the second stage bootloader, that would
make U-Boot the third stage bootloader.

With BMS=0, execution of AT91 processors will start with the
EBI chip select 0 device, usually (EBI) NOR flash.  The AT91's
internal ROM is completely bypassed.

It just happens that official U-Boot for AT91 uses the AT91's
internal ROM to boot via SPI NOR flash.  There is a patch by
Rubini to Atmel's U-Boot 1.1.5 version that runs U-Boot from
an AT91SAM9263-EK board with BMS=0.  It is technically a two
stage bootloader with AT91Bootstrap code being loaded into
SRAM and U-Boot loaded into SDRAM by AT91Bootstrap.

Does the new AT91 code in U-Boot handle BMS=0 properly?

If so, ignore the following paragraph:

I've not heard of a single stage U-Boot for Atmel AT91, but
it is just as easy to do as any other single stage U-Boot
for any other processor.  It should be easier to do than a
U-Boot port to a new architecture.

Sincerely,

Ken Fuchs

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net 
> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf 
> Of Andreas Schweigstill
> Sent: Monday, April 28, 2008 04:51
> To: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] how to make a core uboot?
> 
> 
> Hello!
> 
> loody mil schrieb:
> > I intend to make a pure uboot, without including any driver 
> but only 
> > basic cpu setting and uboot commands supported. But I 
> cannot see any 
> > config option in Makefile.
> 
> If you need a really minimalistic bootloader U-Boot will not be the
> first choice. The smallest possible U-Boot will be around 100KByte in
> size and contain much more than just basic CPU initialisation.
> 
> > I know I may choose any config in boards and truncate those 
> things I 
> > don't need at all.
> 
> That's the right way if you want to use U-Boot.
> 
> > But I send this mail and want to know is there already a 
> config option 
> > or some fast way I can meet my requirement?
> 
> Nobody knows what are you requirements. If you need a really
> minimalistic bootloader you should take a look at some sample
> initialization code from the processor manufacturer.
> 
> On certain platforms (e.g. Atmel AT91) even U-Boot will just 
> be used as
> a second or third level bootloader. The basic CPU setup has been done
> before starting U-Boot.
> 
> With best regards
> Andreas Schweigstill
> 
> -- 
> Dipl.-Phys. Andreas Schweigstill
> Schweigstill IT | Embedded Systems
> Schauenburgerstra?e 116, D-24118 Kiel, Germany
> Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
> Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to 
> save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java
.sun.com/javaone
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users



From lee.nipper at freescale.com  Mon Apr 28 21:59:55 2008
From: lee.nipper at freescale.com (Lee Nipper)
Date: Mon, 28 Apr 2008 14:59:55 -0500
Subject: [U-Boot-Users] [PATCH] mpc83xx: system performance settings for
	MPC8349EMDS.
Message-ID: <1209412795.18638.2.camel@al08linux99>

These same settings are used on MPC8349ITX, and improve performance on MPC8349EMDS.

Signed-off-by: Lee Nipper <lee.nipper at freescale.com>
---
 include/configs/MPC8349EMDS.h |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/include/configs/MPC8349EMDS.h b/include/configs/MPC8349EMDS.h
index 07fefec..ed76b99 100644
--- a/include/configs/MPC8349EMDS.h
+++ b/include/configs/MPC8349EMDS.h
@@ -602,6 +602,16 @@
 	HRCWH_TSEC2M_IN_GMII )
 #endif
 
+/*
+ * System performance
+ */
+#define CFG_ACR_PIPE_DEP	3	/* Arbiter pipeline depth (0-3) */
+#define CFG_ACR_RPTCNT		3	/* Arbiter repeat count (0-7) */
+#define CFG_SPCR_TSEC1EP	3	/* TSEC1 emergency priority (0-3) */
+#define CFG_SPCR_TSEC2EP	3	/* TSEC2 emergency priority (0-3) */
+#define CFG_SCCR_TSEC1CM	1	/* TSEC1 clock mode (0-3) */
+#define CFG_SCCR_TSEC2CM	1	/* TSEC2 & I2C0 clock mode (0-3) */
+
 /* System IO Config */
 #define CFG_SICRH SICRH_TSOBI1
 #define CFG_SICRL SICRL_LDP_A
-- 
1.5.5





From wd at denx.de  Mon Apr 28 22:03:46 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 22:03:46 +0200
Subject: [U-Boot-Users] [PATCH] jffs2_1pass.c: fix incompatible pointer type
	warning
Message-ID: <1209413026-11545-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 fs/jffs2/jffs2_1pass.c |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
index 69f53ea..a330438 100644
--- a/fs/jffs2/jffs2_1pass.c
+++ b/fs/jffs2/jffs2_1pass.c
@@ -185,11 +185,7 @@ static int read_nand_cached(u32 off, u32 size, u_char *buf)
 {
 	struct mtdids *id = current_part->dev->id;
 	u32 bytes_read = 0;
-#if defined(CFG_NAND_LEGACY)
 	size_t retlen;
-#else
-	ulong retlen;
-#endif
 	int cpy_bytes;
 
 	while (bytes_read < size) {
-- 
1.5.4.2




From stuart.wood at labxtechnologies.com  Mon Apr 28 22:38:03 2008
From: stuart.wood at labxtechnologies.com (Stuart Wood)
Date: Mon, 28 Apr 2008 16:38:03 -0400
Subject: [U-Boot-Users] Status of the Yaffs patches?
Message-ID: <c13b1cfc0804281338v4331e1b2tdbbbd5e5e6e259b9@mail.gmail.com>

Hi All,

Can anyone give me an update on the status of integrating YAFFS binary
image reading and writing into U-Boot?

-- 
Stuart Wood

Lab X Technologies, LLC



From wd at denx.de  Mon Apr 28 22:41:39 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 22:41:39 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification
In-Reply-To: Your message of "Tue, 01 Apr 2008 09:56:46 +0200."
	<20080401075646.145810@gmx.net>
Message-ID: <20080428204139.0B1AE248A6@gemini.denx.de>

In message <20080401075646.145810 at gmx.net> you wrote:
> 
> sorry but it's the first time for me. 
> let's try again.
> 
> we modified the specification for the lwmon5 board dspic POST.
> Additionally I have add defines for the temperature- and voltagevalues.
> 
> Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> ---
>  post/board/lwmon5/sysmon.c |   39 ++++++++++++++++++++++++++++++---------
>  1 files changed, 30 insertions(+), 9 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: wd at denx.de
Committee, n.:  A group of men who individually can do nothing but as
a group decide that nothing can be done.                 - Fred Allen



From afleming at gmail.com  Mon Apr 28 23:21:02 2008
From: afleming at gmail.com (Andy Fleming)
Date: Mon, 28 Apr 2008 16:21:02 -0500
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
In-Reply-To: <48109D11.9070508@matrix-vision.de>
References: <48109D11.9070508@matrix-vision.de>
Message-ID: <2acbd3e40804281421q642a20d2j9b3357472a499244@mail.gmail.com>

On Thu, Apr 24, 2008 at 9:45 AM, Andre Schwarz
<andre.schwarz at matrix-vision.de> wrote:

>  {MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
>  +#if defined(CFG_VSC8601_SKEW_TX) && defined(CFG_VSC8601_SKEW_RX)
>  +                {MIIM_EXT_PAGE_ACCESS,1,NULL},
>  +#define VSC8101_SKEW    (CFG_VSC8601_SKEW_TX<<14)|(CFG_VSC8601_SKEW_RX<<12)
>  +                {MIIM_VSC8601_SKEW_CTRL,VSC8101_SKEW,NULL},
>  +                {MIIM_EXT_PAGE_ACCESS,0,NULL},
>  +#endif
>   #endif


I'm not sure this is the best solution to this.  It seems like it
wouldn't scale well.  Either we need to set a bit somewhere that the
phy driver can read (and thereby determine how to configure the skew),
or we need to set the value to write in the board config file.  I'm
partial to the first solution, as it encapsulates the information
inside the code that deals with it.

[...]

>   /* Broadcom BCM54xx -- taken from linux sungem_phy */
>   #define MIIM_BCM54xx_AUXSTATUS            0x19
>   #define MIIM_BCM54xx_AUXSTATUS_LINKMODE_MASK    0x0700
>  @@ -163,6 +165,8 @@
>   /* Vitesse VSC8601 Extended PHY Control Register 1 */
>   #define MIIM_VSC8601_EPHY_CON            0x17
>   #define MIIM_VSC8601_EPHY_CON_INIT_SKEW    0x1120
>  +#define MIIM_VSC8601_SKEW_CTRL        0x1c
>  +#define MIIM_VSC8601_EPHY_CON_INIT_SKEW    0x1120

Am I crazy, or did you just doubly define MIIM_VSC8601_EPHY_CON_INIT_SKEW?



From wd at denx.de  Mon Apr 28 23:22:38 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 23:22:38 +0200
Subject: [U-Boot-Users] [PATCH v2] PPC405EX(r) ECC and SDRAM
	Initialization Clean-ups
In-Reply-To: Your message of "Mon, 28 Apr 2008 09:53:56 PDT."
	<1209401636-9846-2-git-send-email-gerickson@nuovations.com>
Message-ID: <20080428212239.09304247B4@gemini.denx.de>

In message <1209401636-9846-2-git-send-email-gerickson at nuovations.com> you wrote:
> ---
>  board/amcc/kilauea/init.S |   53 +++++++++++--
>  board/amcc/makalu/init.S  |   53 +++++++++++--
>  cpu/ppc4xx/Makefile       |    1 +
>  cpu/ppc4xx/ecc.S          |  195 +++++++++++++++++++++++++++++++++++++++++++++
>  cpu/ppc4xx/sdram.c        |   47 +----------
>  5 files changed, 292 insertions(+), 57 deletions(-)

There are a couple of problems with your posting:

- there is no signed-off-by line
- there is no explanation what you're actually trying to
  add or to fix.
- there are coding style violations: C++ comments, trailing white
  space, ...
- the code contains way too many empty lines / vertical white space.
- even in pseudo code, the Coding style requirements apply; i. e.
  instead of
  	+       /*
	+        *   if (start >= end) {
	+        *       return;
	+        *   }   
	+        */
  please write
  	+       /*
	+        *   if (start >= end)
	+        *       return;
	+        */
  etc.

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: wd at denx.de
Your own mileage may vary.



From wd at denx.de  Mon Apr 28 23:27:41 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 23:27:41 +0200
Subject: [U-Boot-Users] [PATCH v2] PPC405EX(r) ECC and SDRAM
	Initialization Clean-ups
In-Reply-To: Your message of "Mon, 28 Apr 2008 09:53:55 PDT."
	<1209401636-9846-1-git-send-email-gerickson@nuovations.com>
Message-ID: <20080428212741.B6CE0248A6@gemini.denx.de>

In message <1209401636-9846-1-git-send-email-gerickson at nuovations.com> you wrote:
> The primary goal of these changes is to unify some of the low-level
> SDRAM and ECC initialization code for the PPC4xx processors that use a
> common DDR2 SDRAM controller.
> 
> In particular, in the case of the 405EX[r], it must initialize SDRAM
> before a primordial stack is available since OCM doesn't exist and the
> data cache does not work for such a purpose. As a consequence, the ECC
> (and SDRAM) initialization code must be stack-free.

Stefan already asked this... I would also like to understand why the
data cache cannot be used for initial RAM as we do on so many other
systems?

I hesitate to throw away good C code in favour of hard to read,  hard
to maintain assembly, especially if this also breaks with some of the
U-Boot design principles.

> ---
>  board/amcc/kilauea/init.S |   53 +++++++++++--
>  board/amcc/makalu/init.S  |   53 +++++++++++--
>  cpu/ppc4xx/Makefile       |    1 +
>  cpu/ppc4xx/ecc.S          |  195 +++++++++++++++++++++++++++++++++++++++++++++
>  cpu/ppc4xx/sdram.c        |   47 +----------
>  5 files changed, 292 insertions(+), 57 deletions(-)

There are coding style violations: C++ comments, trailing white space,
indentation not consequently by TABs.

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: wd at denx.de
Chapter 1 -- The story so  far:
In the beginning the Universe was created. This has  made  a  lot  of
people very angry and been widely regarded as a bad move.



From wd at denx.de  Mon Apr 28 23:34:20 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 23:34:20 +0200
Subject: [U-Boot-Users] Running uC/OS-II on top of u-boot
In-Reply-To: Your message of "Mon, 28 Apr 2008 12:10:21 PDT."
	<16945849.post@talk.nabble.com>
Message-ID: <20080428213420.50E30247B4@gemini.denx.de>

In message <16945849.post at talk.nabble.com> you wrote:
> 
> We have a PowerPC 440 EP (from a AMCC Yosemite evaluation kit) and we are in
> the process of evaluating OSes for it. The industrial strength ones (like
> vxWorks) are too much feature-wise and money-wise, so we're hoping to try
> out uC/OS-II. 

Why not using a feature-rich, money-efficient solution like Linux? One
of the big advantages is that you get a running system completely for
free and out of the box...

> - Can the porting layer of uC/OS-II use some of the u-boot functions for PCI
> and ethernet access?

It can, if you use the GPL2 based "Open Source Licensing" model of
uC/OS-II.

> - Are there any existing instructions on how to build (or create a makefile)
> uC/OS-II using the compilers supplied by the ELDK? I keep getting a failure
> to "find entry symbol _start", even if I include the gcc libraries,
> crtbegin.o, etc. 

Well, that's starting to be off topic here...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
He'd been wrong, there _was_ a light at the end of the tunnel, and it
was a flamethrower.                         - Terry Pratchett, _Mort_



From wd at denx.de  Mon Apr 28 23:37:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 23:37:01 +0200
Subject: [U-Boot-Users] how to make a core uboot? (Comments about AT91
	BMS)
In-Reply-To: Your message of "Mon, 28 Apr 2008 14:24:39 CDT."
	<AA28F077645B324881335614E4F7C428034CEF@win-ex01.bench.com>
Message-ID: <20080428213701.F2703248A6@gemini.denx.de>

In message <AA28F077645B324881335614E4F7C428034CEF at win-ex01.bench.com> you wrote:
> 
> It just happens that official U-Boot for AT91 uses the AT91's
> internal ROM to boot via SPI NOR flash.  There is a patch by

Define "official".

To me it means what's in mainline. And here we support booting from
NOR flash.

> I've not heard of a single stage U-Boot for Atmel AT91, but
> it is just as easy to do as any other single stage U-Boot
> for any other processor.  It should be easier to do than a
> U-Boot port to a new architecture.

You may just want to use plain standard mainline code.

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: wd at denx.de
As of 1992, they're called European Economic Community fries.



From wd at denx.de  Mon Apr 28 23:44:42 2008
From: wd at denx.de (Wolfgang Denk)
Date: Mon, 28 Apr 2008 23:44:42 +0200
Subject: [U-Boot-Users] Status of the Yaffs patches?
In-Reply-To: Your message of "Mon, 28 Apr 2008 16:38:03 EDT."
	<c13b1cfc0804281338v4331e1b2tdbbbd5e5e6e259b9@mail.gmail.com>
Message-ID: <20080428214442.21BE3248A6@gemini.denx.de>

In message <c13b1cfc0804281338v4331e1b2tdbbbd5e5e6e259b9 at mail.gmail.com> you wrote:
> 
> Can anyone give me an update on the status of integrating YAFFS binary
> image reading and writing into U-Boot?

I think they got lost, most probably because  the  patches  were  not
posted inline but just as a reference to some URI.

If you're interested to get this into mainline, please rebase and
repost (inline!) for the next merge window.

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: wd at denx.de
"...this does not mean that some of us should not want, in  a  rather
dispassionate sort of way, to put a bullet through csh's head."
                   - Larry Wall in <1992Aug6.221512.5963 at netlabs.com>



From gerickson at nuovations.com  Mon Apr 28 23:47:32 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Mon, 28 Apr 2008 14:47:32 -0700
Subject: [U-Boot-Users] [PATCH v2] PPC405EX(r) ECC and SDRAM
	Initialization Clean-ups
In-Reply-To: <20080428212741.B6CE0248A6@gemini.denx.de>
Message-ID: <C43B9404.EDFD%gerickson@nuovations.com>

On 4/28/08 2:27 PM, Wolfgang Denk wrote:
> In message <1209401636-9846-1-git-send-email-gerickson at nuovations.com> you
> wrote:
>> The primary goal of these changes is to unify some of the low-level
>> SDRAM and ECC initialization code for the PPC4xx processors that use a
>> common DDR2 SDRAM controller.
>> 
>> In particular, in the case of the 405EX[r], it must initialize SDRAM
>> before a primordial stack is available since OCM doesn't exist and the
>> data cache does not work for such a purpose. As a consequence, the ECC
>> (and SDRAM) initialization code must be stack-free.
> 
> Stefan already asked this... I would also like to understand why the
> data cache cannot be used for initial RAM as we do on so many other
> systems?

Agreed. The changes were based on the comments in the Kilauea and Makalu
board ports indicating that this had been attempted--twice--and didn't work.

I am escalating with AMCC to find out if this is a processor errata, board
issue or just a programming issue that needs to be investigated further.

> I hesitate to throw away good C code in favour of hard to read,  hard
> to maintain assembly, especially if this also breaks with some of the
> U-Boot design principles.

Again, agreed wholeheartedly though I have to remark that I made a
particular effort to make the assembly as readable and as generalized as
possible.

Regards,

Grant





From dwh at ovro.caltech.edu  Mon Apr 28 23:16:59 2008
From: dwh at ovro.caltech.edu (David Hawkins)
Date: Mon, 28 Apr 2008 14:16:59 -0700
Subject: [U-Boot-Users] Running uC/OS-II on top of u-boot
In-Reply-To: <16945849.post@talk.nabble.com>
References: <16945849.post@talk.nabble.com>
Message-ID: <48163ECB.2090700@ovro.caltech.edu>

Hi,

> We have a PowerPC 440 EP (from a AMCC Yosemite evaluation kit)
> and we are in the process of evaluating OSes for it. The
> industrial strength ones (like vxWorks) are too much
> feature-wise and money-wise, so we're hoping to try out uC/OS-II. 
> 
> If someone has tried to do this before, I have a few questions:
> 
> - How do you configure it to run on top of u-boot? What commands are used?
> 
> - Can the porting layer of uC/OS-II use some of the u-boot functions for PCI
> and ethernet access?
> 
> - Are there any existing instructions on how to build (or create a makefile)
> uC/OS-II using the compilers supplied by the ELDK? I keep getting a failure
> to "find entry symbol _start", even if I include the gcc libraries,
> crtbegin.o, etc. 
> 
> I appreciate any help that I can get with my questions. Thanks!

I have a Yosemite board, but haven't tried running uCOS-II
on it.

I would suggest creating a uCOS-II port that starts out life
as a U-Boot stand-alone application.

This way U-Boot sets up the processor, so your uCOS-II port
doesn't have to deal with that.

In the U-Boot stand-alone application, you would create the
first uCOS-II task and initialize it. The other tasks
would be in the same image loaded by U-Boot.

You might even get away with using U-Boots console routines,
however, since they're polled, you might want to create your
own. If you do use them, you might want to use a mutex to
protect the console routine use in multiple tasks.

This scheme is analogous to starting uCOS-II from DOS in
the Labrosse book. It should be possible to exit from uCOS-II
back to the U-Boot console too.

Cheers,
Dave



From kenneth at southpole.se  Tue Apr 29 00:59:47 2008
From: kenneth at southpole.se (kenneth johansson)
Date: Tue, 29 Apr 2008 00:59:47 +0200
Subject: [U-Boot-Users] [PATCH v2] PPC405EX(r) ECC and SDRAM
	Initialization Clean-ups
In-Reply-To: <C43B9404.EDFD%gerickson@nuovations.com>
References: <C43B9404.EDFD%gerickson@nuovations.com>
Message-ID: <1209423587.8866.15.camel@duo>

On Mon, 2008-04-28 at 14:47 -0700, Grant Erickson wrote:
> On 4/28/08 2:27 PM, Wolfgang Denk wrote:
> > In message <1209401636-9846-1-git-send-email-gerickson at nuovations.com> you
> > wrote:
> >> The primary goal of these changes is to unify some of the low-level
> >> SDRAM and ECC initialization code for the PPC4xx processors that use a
> >> common DDR2 SDRAM controller.
> >> 
> >> In particular, in the case of the 405EX[r], it must initialize SDRAM
> >> before a primordial stack is available since OCM doesn't exist and the
> >> data cache does not work for such a purpose. As a consequence, the ECC
> >> (and SDRAM) initialization code must be stack-free.
> > 
> > Stefan already asked this... I would also like to understand why the
> > data cache cannot be used for initial RAM as we do on so many other
> > systems?
> 
> Agreed. The changes were based on the comments in the Kilauea and Makalu
> board ports indicating that this had been attempted--twice--and didn't work.
> 
> I am escalating with AMCC to find out if this is a processor errata, board
> issue or just a programming issue that needs to be investigated further.

The cache trick works fine on 405CR/405GP. Is the cache redesigned for
405EX. Why would they still call it a 405 if the core was redesigned?







From sr at denx.de  Tue Apr 29 07:08:00 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 07:08:00 +0200
Subject: [U-Boot-Users] Status of the Yaffs patches?
In-Reply-To: <20080428214442.21BE3248A6@gemini.denx.de>
References: <20080428214442.21BE3248A6@gemini.denx.de>
Message-ID: <200804290708.00897.sr@denx.de>

On Monday 28 April 2008, Wolfgang Denk wrote:
> > Can anyone give me an update on the status of integrating YAFFS binary
> > image reading and writing into U-Boot?
>
> I think they got lost, most probably because  the  patches  were  not
> posted inline but just as a reference to some URI.

I'm not sure if that's what Stuart is referring to. YAFFS "binary images" can 
be read and written without problems with the current code (since years). You 
need to use the ".jffs2/.i" option for skipping bad blocks.

But if you are referring to the YAFFS filesystem support in U-Boot, then the 
work Wolfgang is referring to is currently available in the mtd-2.6.22.1 
branch of the u-boot-nand-flash repository. I have to admit that I'm not sure 
if the YAFFS support has already been integrated though. Unfortunately this 
branch still has some problems and I didn't get enough feedback/patches to 
fix those problems. So we can't merge this stuff into mainline yet.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From iws at ovro.caltech.edu  Tue Apr 29 07:25:54 2008
From: iws at ovro.caltech.edu (Ira Snyder)
Date: Mon, 28 Apr 2008 22:25:54 -0700
Subject: [U-Boot-Users] [PATCH] PPC-44x: Add Open Firmware support to AMCC
	Yosemite
Message-ID: <20080429052554.GA19941@ovro.caltech.edu>

Hello U-Boot users,

This is my first patch, so any suggestions would be welcome.

I have an AMCC Yosemite board, which I recently updated to use the
recent ARCH=powerpc work from mainline Linux. Without this patch, trying
to boot from a uImage does not work. The kernel panics while trying to
parse the device tree blob. Note that a cuImage works fine previous to
this patch.

Also, I noticed that when I started booting with a uImage and dtb, that
eth0 had a MAC address of 00:00:00:00:00:00. Adding
#define CONFIG_HAS_ETH0 1 fixed this issue, by setting the MAC address
via the eth0addr variable in U-Boot.

I tested the following setups:
1) Old ARCH=ppc 2.6.13 kernel
2) New ARCH=powerpc 2.6.26rc0 kernel (cuImage)
3) New ARCH=powerpc 2.6.26rc0 kernel (uImage + dtb)

I ran MAKEALL both with and without the patch. The only changes in output
were a ~20kB increase in image size for the yellowstone and yosemite boards.

Thanks for all of the great work.
Ira

--

>From d76d560b1f61126c63320cec18d5b436f4bb10c0 Mon Sep 17 00:00:00 2001
From: Ira W. Snyder <iws at ovro.caltech.edu>
Date: Sat, 26 Apr 2008 16:06:26 -0700
Subject: [PATCH] PPC-44x: Add Open Firmware support to AMCC Yosemite

Add support for booting with a device tree blob. This is needed to boot
ARCH=powerpc kernels. Also add support for setting the eth0 mac address
via the eth0addr variable.

Signed-off-by: Ira W. Snyder <iws at ovro.caltech.edu>
---
 board/amcc/yosemite/yosemite.c |   11 +++++++++++
 include/configs/yosemite.h     |    9 +++++++++
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/board/amcc/yosemite/yosemite.c b/board/amcc/yosemite/yosemite.c
index 6ec922a..fa610c3 100644
--- a/board/amcc/yosemite/yosemite.c
+++ b/board/amcc/yosemite/yosemite.c
@@ -26,6 +26,9 @@
 #include <asm/processor.h>
 #include <asm/io.h>
 #include <spd_sdram.h>
+#if defined(CONFIG_OF_LIBFDT)
+	#include <libfdt.h>
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -554,3 +557,11 @@ void board_reset(void)
 	/* give reset to BCSR */
 	*(unsigned char *)(CFG_BCSR_BASE | 0x06) = 0x09;
 }
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+	ft_cpu_setup(blob, bd);
+
+}
+#endif
diff --git a/include/configs/yosemite.h b/include/configs/yosemite.h
index c9323f6..7dcd4e6 100644
--- a/include/configs/yosemite.h
+++ b/include/configs/yosemite.h
@@ -141,6 +141,14 @@
 
 
 /*-----------------------------------------------------------------------
+ * Open Firmware (Linux-2.6.26+)
+ *----------------------------------------------------------------------*/
+
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT	1
+#define CONFIG_OF_BOARD_SETUP	1
+
+/*-----------------------------------------------------------------------
  * I2C
  *----------------------------------------------------------------------*/
 #define CONFIG_HARD_I2C		1	    /* I2C with hardware support	*/
@@ -227,6 +235,7 @@
 #define CONFIG_MII		1	/* MII PHY management		*/
 #define CONFIG_NET_MULTI        1	/* required for netconsole      */
 #define CONFIG_PHY1_ADDR        3
+#define CONFIG_HAS_ETH0		1	/* add support for "eth0addr"	*/
 #define CONFIG_HAS_ETH1		1	/* add support for "eth1addr"	*/
 #define CONFIG_PHY_ADDR		1	/* PHY address, See schematics	*/
 
-- 
1.5.4.3




From biggerbadderben at gmail.com  Tue Apr 29 07:38:12 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Mon, 28 Apr 2008 22:38:12 -0700
Subject: [U-Boot-Users] 1.3.3-rc1 - release status
In-Reply-To: <20080425235716.3419D24AB5@gemini.denx.de>
References: <20080425235716.3419D24AB5@gemini.denx.de>
Message-ID: <4816B444.1020105@gmail.com>

Wolfgang Denk wrote:
> Hello,
>
> I decided to tag the current versionof U-Boot as "rc1".
>
> At the moment, I have the following patches still maked as open on my
> list:
>
>  7972  04/03 Guennadi Liakhove  [U-Boot-Users] [PATCH] minor cs8900 driver clean up
>  7997  04/03 Guennadi Liakhove  [U-Boot-Users] [PATCH v2] net: make ARP timeout configurable
>  8038  04/04 michael            Re: [PATCH] get_vfatname
>  8212  04/09 Andre Schwarz      [U-Boot-Users] [PATCH] add MPC8343 based board mvBlueLYNX-M7 aka mvblm7
>  8950  04/24 Jean-Christophe P  [U-Boot-Users] [PATCH 1/1 V2] NE2000: Fix regresssion introduced by e710185aae90 on non
>  8956  04/24 michael            [U-Boot-Users] [PATCH ARM 1/2] Ide support io function
>  8957  04/24 michael            [U-Boot-Users] [PATCH ARM 2/2] Ide support. Ide registration
>  8958  04/24 michael            [U-Boot-Users] [PATCH ARM 0/2] Ide support
>  8984  04/24 Andre Schwarz      Re: [U-Boot-Users] [PATCH] Add Vitesse 8601 support to TSEC driver
>  8989  04/24 Andre Schwarz      [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
>
> My understanding is as follows:
>
> 8038 - is not clear yet, discussions still going on; wait for solution
>
> 8212 - new code, will go into next release
>
> 7972, 7997, 8950, 8984, 8989 - network code; Ben - please comment?
>
>   
7972, 7997 and 8950 are in net tree - pull request coming soon.
8989 was NAK'ed by Andy Fleming, I can't find a patch for 8984, 
although  commit 2d934ea51f276522b532f870a820e844ff480b5b implements the 
origin of this thread.


regards,
Ben



From biggerbadderben at gmail.com  Tue Apr 29 07:42:14 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Mon, 28 Apr 2008 22:42:14 -0700
Subject: [U-Boot-Users] Pull request - net
Message-ID: <4816B536.6040400@gmail.com>

Wolfgang,

The following changes since commit dd5748bcd669f46aeb6686c1b341323843738ccc:
  Guennadi Liakhovetski (1):
        rtl8169: fix compiler warnings

are available in the git repository at:

  git://www.denx.de/git/u-boot-net.git master

Guennadi Liakhovetski (2):
      minor cs8900 driver clean up
      net: make ARP timeout configurable

Jean-Christophe PLAGNIOL-VILLARD (1):
      NE2000: Fix regresssion introduced by e710185aae90 on non AX88796

 README                    |    4 +
 drivers/net/Makefile      |    5 +-
 drivers/net/ax88796.c     |  156 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/net/ax88796.h     |  136 ---------------------------------------
 drivers/net/cs8900.c      |   15 ++--
 drivers/net/cs8900.h      |    1 -
 drivers/net/ne2000.c      |   94 ++++++++++++++++++++++++++-
 drivers/net/ne2000.h      |   87 +-------------------------
 drivers/net/ne2000_base.h |    1 -
 net/net.c                 |   23 +++++--
 10 files changed, 280 insertions(+), 242 deletions(-)
 create mode 100644 drivers/net/ax88796.c


regards,
Ben




From sr at denx.de  Tue Apr 29 07:46:03 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 07:46:03 +0200
Subject: [U-Boot-Users] [PATCH][resend] ppc4xx fixup ebc clock in FDT
	for 405GP/EP
In-Reply-To: <200804280847.48012.super.firetwister@gmail.com>
References: <200804280847.48012.super.firetwister@gmail.com>
Message-ID: <200804290746.03323.sr@denx.de>

On Monday 28 April 2008, Markus Brunner wrote:
> On ppc405EP and ppc405GP (at least) the ebc is directly attached to the plb
> and not to the opb. This patch will try to fixup /plb/ebc if /plb/opb/ebc
> doesn't exist.

Applied to u-boot-ppc4xx repository. Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 29 07:54:33 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 07:54:33 +0200
Subject: [U-Boot-Users] PPC440EPx/sequoia TLB question...
In-Reply-To: <48128B6B.8090909@verizon.net>
References: <480EA8E1.4060207@verizon.net> <200804231442.29687.sr@denx.de>
	<48128B6B.8090909@verizon.net>
Message-ID: <200804290754.33134.sr@denx.de>

On Saturday 26 April 2008, Dave Littell wrote:
> Here goes (again):
>
> Patch for AMCC Sequoia to remove the TLB Guarded attribute for SDRAM,
> and add the Guarded attribute for Internal Registers & OCM.

I still have a few issues with this patch:

- Signed-off-by line missing
- Please use a descriptive subject for this patch, something like:
  "[PATCH] ppc4xx: Fix guarded bit in some Sequoia TLB entries"
- Comments that should not be part of the commit text should go
  below the "---" line in the email. Please take a look at other
  patches sent to the list on how exactly this should be done.
- And best would be to create two separate TLB entries, one for
  internal SRAM (OCM) with G cleared and one for internal registers
  with G set

I strongly suggest to work with the git tools to create and send patches. This 
makes life a lot easier for all of us.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From onyxtape at hotmail.com  Tue Apr 29 08:24:22 2008
From: onyxtape at hotmail.com (M C)
Date: Tue, 29 Apr 2008 06:24:22 +0000
Subject: [U-Boot-Users] Running uC/OS-II on top of u-boot
In-Reply-To: <20080428213420.50E30247B4@gemini.denx.de>
References: Your message of  <20080428213420.50E30247B4@gemini.denx.de>
Message-ID: <BAY118-W511551AF68516CE9C052DCCFD90@phx.gbl>


> To: onyxtape at hotmail.com
> CC: u-boot-users at lists.sourceforge.net
> From: wd at denx.de
> Subject: Re: [U-Boot-Users] Running uC/OS-II on top of u-boot
> Date: Mon, 28 Apr 2008 23:34:20 +0200
>
> In message  you wrote:
>>
>> We have a PowerPC 440 EP (from a AMCC Yosemite evaluation kit) and we are in
>> the process of evaluating OSes for it. The industrial strength ones (like
>> vxWorks) are too much feature-wise and money-wise, so we're hoping to try
>> out uC/OS-II.
>
> Why not using a feature-rich, money-efficient solution like Linux? One
> of the big advantages is that you get a running system completely for
> free and out of the box...

The software has to eventually undergo certification, and uC/OS-II should be a smaller codebase to certify than Linux.

>
>> - Can the porting layer of uC/OS-II use some of the u-boot functions for PCI
>> and ethernet access?
>
> It can, if you use the GPL2 based "Open Source Licensing" model of
> uC/OS-II.
>
>> - Are there any existing instructions on how to build (or create a makefile)
>> uC/OS-II using the compilers supplied by the ELDK? I keep getting a failure
>> to "find entry symbol _start", even if I include the gcc libraries,
>> crtbegin.o, etc.
>
> Well, that's starting to be off topic here...
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> He'd been wrong, there _was_ a light at the end of the tunnel, and it
> was a flamethrower. - Terry Pratchett, _Mort_

_________________________________________________________________
Back to work after baby?how do you know when you?re ready?
http://lifestyle.msn.com/familyandparenting/articleNW.aspx?cp-documentid=5797498&ocid=T067MSN40A0701A


From onyxtape at hotmail.com  Tue Apr 29 08:25:47 2008
From: onyxtape at hotmail.com (M C)
Date: Tue, 29 Apr 2008 06:25:47 +0000
Subject: [U-Boot-Users] Running uC/OS-II on top of u-boot
In-Reply-To: <48163ECB.2090700@ovro.caltech.edu>
References: <16945849.post@talk.nabble.com> <48163ECB.2090700@ovro.caltech.edu>
Message-ID: <BAY118-W56F3256B572DA7D6FC2140CFD90@phx.gbl>


I'll try to stub out some of the porting functions and run the OS as a basic standalone app. Thanks!

> Date: Mon, 28 Apr 2008 14:16:59 -0700
> From: dwh at ovro.caltech.edu
> To: onyxtape at hotmail.com
> CC: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Running uC/OS-II on top of u-boot
>
> Hi,
>
>> We have a PowerPC 440 EP (from a AMCC Yosemite evaluation kit)
>> and we are in the process of evaluating OSes for it. The
>> industrial strength ones (like vxWorks) are too much
>> feature-wise and money-wise, so we're hoping to try out uC/OS-II.
>>
>> If someone has tried to do this before, I have a few questions:
>>
>> - How do you configure it to run on top of u-boot? What commands are used?
>>
>> - Can the porting layer of uC/OS-II use some of the u-boot functions for PCI
>> and ethernet access?
>>
>> - Are there any existing instructions on how to build (or create a makefile)
>> uC/OS-II using the compilers supplied by the ELDK? I keep getting a failure
>> to "find entry symbol _start", even if I include the gcc libraries,
>> crtbegin.o, etc.
>>
>> I appreciate any help that I can get with my questions. Thanks!
>
> I have a Yosemite board, but haven't tried running uCOS-II
> on it.
>
> I would suggest creating a uCOS-II port that starts out life
> as a U-Boot stand-alone application.
>
> This way U-Boot sets up the processor, so your uCOS-II port
> doesn't have to deal with that.
>
> In the U-Boot stand-alone application, you would create the
> first uCOS-II task and initialize it. The other tasks
> would be in the same image loaded by U-Boot.
>
> You might even get away with using U-Boots console routines,
> however, since they're polled, you might want to create your
> own. If you do use them, you might want to use a mutex to
> protect the console routine use in multiple tasks.
>
> This scheme is analogous to starting uCOS-II from DOS in
> the Labrosse book. It should be possible to exit from uCOS-II
> back to the U-Boot console too.
>
> Cheers,
> Dave

_________________________________________________________________
In a rush? Get real-time answers with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_realtime_042008


From andre.schwarz at matrix-vision.de  Tue Apr 29 08:58:26 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Tue, 29 Apr 2008 08:58:26 +0200
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
In-Reply-To: <2acbd3e40804281421q642a20d2j9b3357472a499244@mail.gmail.com>
References: <48109D11.9070508@matrix-vision.de>
	<2acbd3e40804281421q642a20d2j9b3357472a499244@mail.gmail.com>
Message-ID: <4816C712.3000806@matrix-vision.de>

Andy,

thanks for your comments.


Andy Fleming schrieb:
> On Thu, Apr 24, 2008 at 9:45 AM, Andre Schwarz
> <andre.schwarz at matrix-vision.de> wrote:
>
>   
>>  {MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
>>  +#if defined(CFG_VSC8601_SKEW_TX) && defined(CFG_VSC8601_SKEW_RX)
>>  +                {MIIM_EXT_PAGE_ACCESS,1,NULL},
>>  +#define VSC8101_SKEW    (CFG_VSC8601_SKEW_TX<<14)|(CFG_VSC8601_SKEW_RX<<12)
>>  +                {MIIM_VSC8601_SKEW_CTRL,VSC8101_SKEW,NULL},
>>  +                {MIIM_EXT_PAGE_ACCESS,0,NULL},
>>  +#endif
>>   #endif
>>     
>
>
> I'm not sure this is the best solution to this.  It seems like it
> wouldn't scale well.  Either we need to set a bit somewhere that the
> phy driver can read (and thereby determine how to configure the skew),
> or we need to set the value to write in the board config file.  I'm
> partial to the first solution, as it encapsulates the information
> inside the code that deals with it.
>
> [...]
>
>   
I don't understand "scale well". What should be scalable ?

Of course using a function would be better.
I silently assumed that the other bits are set to zero which is true
after reset.
There are only two other bits : Packet size and 10M preamble mode.
Both should be left untouched, i.e. "0".

>>   /* Broadcom BCM54xx -- taken from linux sungem_phy */
>>   #define MIIM_BCM54xx_AUXSTATUS            0x19
>>   #define MIIM_BCM54xx_AUXSTATUS_LINKMODE_MASK    0x0700
>>  @@ -163,6 +165,8 @@
>>   /* Vitesse VSC8601 Extended PHY Control Register 1 */
>>   #define MIIM_VSC8601_EPHY_CON            0x17
>>   #define MIIM_VSC8601_EPHY_CON_INIT_SKEW    0x1120
>>  +#define MIIM_VSC8601_SKEW_CTRL        0x1c
>>  +#define MIIM_VSC8601_EPHY_CON_INIT_SKEW    0x1120
>>     
>
> Am I crazy, or did you just doubly define MIIM_VSC8601_EPHY_CON_INIT_SKEW?
>   
This obviously is a mistake - sorry.



regards,
Andre

MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From wd at denx.de  Tue Apr 29 09:27:23 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 09:27:23 +0200
Subject: [U-Boot-Users] Running uC/OS-II on top of u-boot
In-Reply-To: Your message of "Tue, 29 Apr 2008 06:24:22 -0000."
	<BAY118-W511551AF68516CE9C052DCCFD90@phx.gbl>
Message-ID: <20080429072723.F2C7C24681@gemini.denx.de>

In message <BAY118-W511551AF68516CE9C052DCCFD90 at phx.gbl> you wrote:
> 
> > Why not using a feature-rich, money-efficient solution like Linux? One
> > of the big advantages is that you get a running system completely for
> > free and out of the box...
> 
> The software has to eventually undergo certification, and uC/OS-II should
> be a smaller codebase to certify than Linux.

The code base may be smaller, but the cost may or may not be smaller.
There are some interesting activities going on. Please check out  the
information about the "Safety Critical Linux" project run by the Open
Source      Automation      Development      Lab     (OSADL),     see
http://www.osadl.org/Safety-Critical-Linux.safety-critical-linux.0.html
There is a real chance to establish an "Open  Certification  Process"
in  a  not  to  far future, so Linux might still be a better long-tem
investment.

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: wd at denx.de
The light at the end of the tunnel is usually a "No Exit" sign.



From Steven.Wang at spansion.com  Tue Apr 29 10:46:06 2008
From: Steven.Wang at spansion.com (Wang, Steven)
Date: Tue, 29 Apr 2008 16:46:06 +0800
Subject: [U-Boot-Users] issue for usb host bulk receiving RING from usb modem
In-Reply-To: <A4C6FC160E79CE418F09D45C555A44795F44C8@cnsuzexmbpf1.spansion.com>
References: <A4C6FC160E79CE418F09D45C555A44795F44C8@cnsuzexmbpf1.spansion.com>
Message-ID: <A4C6FC160E79CE418F09D45C555A44795F44D8@cnsuzexmbpf1.spansion.com>

 

Hi Guys,

 

I am porting usb host tty device driver on uboot. I just use usb
usb_bulk_msg to communicate with modem. I met the following problems.

Could you please help me resolve the following issue? Thanks in advance.

 

When I use usb usb_bulk_msg to connect one USB modem, send one AT
command (e.g. AT) to Modem, and can receive a responding message, e.g.,
OK and so on.

But When I want to use usb usb_bulk_msg to receive the RING command from
modem without sending any AT command to modem, I could not receive any
data from modem, even NAK, STALL cannot be received. Then program
timeout. But if I send ATA, the can answer the incoming call.

I do not know how to receive the data from modem, when host did not send
AT command to modem.

 

Even I use usb_submit_int_msg, I only receive NULL.

 

WHY?

 

 

Thanks & Best regards,

Steven Wang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080429/b9fc9f6e/attachment.htm 

From stelian at popies.net  Tue Apr 29 11:02:28 2008
From: stelian at popies.net (Stelian Pop)
Date: Tue, 29 Apr 2008 11:02:28 +0200
Subject: [U-Boot-Users] [RFC] AT91 reorganisation
In-Reply-To: <20080426184017.GA8123@game.jcrosoft.org>
References: <20080426184017.GA8123@game.jcrosoft.org>
Message-ID: <1209459748.8879.0.camel@galileo>


Le samedi 26 avril 2008 ? 20:40 +0200, Jean-Christophe PLAGNIOL-VILLARD
a ?crit :
> Hi,
> 
> 	I've plan to join the at91sam9 and at91rm9200 in
> 	only one arch at91 like done in linux.
> 
> 	I hope this could be done for the next release.

As I said before, this would be nice, and I'm all for it.

-- 
Stelian Pop <stelian at popies.net>




From stelian at popies.net  Tue Apr 29 11:29:30 2008
From: stelian at popies.net (Stelian Pop)
Date: Tue, 29 Apr 2008 11:29:30 +0200
Subject: [U-Boot-Users] [RFC] AT91 reorganisation
In-Reply-To: <012701c8a7d2$52929cd0$020514ac@atmel.com>
References: <20080426184017.GA8123@game.jcrosoft.org>
	<012701c8a7d2$52929cd0$020514ac@atmel.com>
Message-ID: <1209461370.8879.9.camel@galileo>


Le samedi 26 avril 2008 ? 21:18 +0200, Ulf Samuelsson a ?crit :
> 
> > Hi,
> > 
> > I've plan to join the at91sam9 and at91rm9200 in
> > only one arch at91 like done in linux.
> > 
> > I hope this could be done for the next release.
> > 
> > Best Regards,
> > J.
> >
> 
> You are aware that they are using two different CPU cores.

Indeed, but some of the peripherals are common.

> Also, some stuff should maybe be common with avr32.

Those are essentially drivers (like net/macb.c, serial/atmel_usart.c),
and are already shared between at91 and avr32.

-- 
Stelian Pop <stelian at popies.net>




From sr at denx.de  Tue Apr 29 11:42:52 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 11:42:52 +0200
Subject: [U-Boot-Users] [PATCH v2] PPC405EX(r) ECC and SDRAM
	Initialization Clean-ups
In-Reply-To: <1209423587.8866.15.camel@duo>
References: <C43B9404.EDFD%gerickson@nuovations.com>
	<1209423587.8866.15.camel@duo>
Message-ID: <200804291142.53005.sr@denx.de>

On Tuesday 29 April 2008, kenneth johansson wrote:
> > > Stefan already asked this... I would also like to understand why the
> > > data cache cannot be used for initial RAM as we do on so many other
> > > systems?
> >
> > Agreed. The changes were based on the comments in the Kilauea and Makalu
> > board ports indicating that this had been attempted--twice--and didn't
> > work.
> >
> > I am escalating with AMCC to find out if this is a processor errata,
> > board issue or just a programming issue that needs to be investigated
> > further.
>
> The cache trick works fine on 405CR/405GP. Is the cache redesigned for
> 405EX. Why would they still call it a 405 if the core was redesigned?

I already sent an update to Grant privately on this. Here again:

The main problem is that the board crashes with an exception (0x200: Data 
machine check) when init RAM in dcache is used. This happens upon calling 
trap_init() in board_init_r(). The exception must be pending and 
is "activated" upon the trap_init() call. Either Grant (or somebody else?) 
will look into this, or I will try to look into is (again) in a few days.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sr at denx.de  Tue Apr 29 11:56:29 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 11:56:29 +0200
Subject: [U-Boot-Users] [PATCH] PPC-44x: Add Open Firmware support to
	AMCC Yosemite
In-Reply-To: <20080429052554.GA19941@ovro.caltech.edu>
References: <20080429052554.GA19941@ovro.caltech.edu>
Message-ID: <200804291156.29688.sr@denx.de>

Hi Ira,

On Tuesday 29 April 2008, Ira Snyder wrote:
> This is my first patch, so any suggestions would be welcome.

Thanks for your contribution. Its actually quite good for the first time. :)

> I have an AMCC Yosemite board, which I recently updated to use the
> recent ARCH=powerpc work from mainline Linux. Without this patch, trying
> to boot from a uImage does not work. The kernel panics while trying to
> parse the device tree blob. Note that a cuImage works fine previous to
> this patch.
>
> Also, I noticed that when I started booting with a uImage and dtb, that
> eth0 had a MAC address of 00:00:00:00:00:00. Adding
> #define CONFIG_HAS_ETH0 1 fixed this issue, by setting the MAC address
> via the eth0addr variable in U-Boot.

This should be "ethaddr" instead of "eth0addr".

> I tested the following setups:
> 1) Old ARCH=ppc 2.6.13 kernel
> 2) New ARCH=powerpc 2.6.26rc0 kernel (cuImage)
> 3) New ARCH=powerpc 2.6.26rc0 kernel (uImage + dtb)
>
> I ran MAKEALL both with and without the patch. The only changes in output
> were a ~20kB increase in image size for the yellowstone and yosemite
> boards.

Thanks. Please find some comments below.

> Thanks for all of the great work.
> Ira
>
> --
>
> From d76d560b1f61126c63320cec18d5b436f4bb10c0 Mon Sep 17 00:00:00 2001
> From: Ira W. Snyder <iws at ovro.caltech.edu>
> Date: Sat, 26 Apr 2008 16:06:26 -0700
> Subject: [PATCH] PPC-44x: Add Open Firmware support to AMCC Yosemite

I find the subject a little misleading. "Open Firmware" support sounds a 
little too much. How about:

"ppc4xx: Add device tree support to AMCC Yosemite"

> Add support for booting with a device tree blob. This is needed to boot
> ARCH=powerpc kernels. Also add support for setting the eth0 mac address
> via the eth0addr variable.

"ethaddr".

> Signed-off-by: Ira W. Snyder <iws at ovro.caltech.edu>
> ---
>  board/amcc/yosemite/yosemite.c |   11 +++++++++++
>  include/configs/yosemite.h     |    9 +++++++++
>  2 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/board/amcc/yosemite/yosemite.c
> b/board/amcc/yosemite/yosemite.c index 6ec922a..fa610c3 100644
> --- a/board/amcc/yosemite/yosemite.c
> +++ b/board/amcc/yosemite/yosemite.c
> @@ -26,6 +26,9 @@
>  #include <asm/processor.h>
>  #include <asm/io.h>
>  #include <spd_sdram.h>
> +#if defined(CONFIG_OF_LIBFDT)
> +	#include <libfdt.h>
> +#endif

Please add this header unconditionally (without indentation).

>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -554,3 +557,11 @@ void board_reset(void)
>  	/* give reset to BCSR */
>  	*(unsigned char *)(CFG_BCSR_BASE | 0x06) = 0x09;
>  }
> +
> +#if defined(CONFIG_OF_BOARD_SETUP)
> +void ft_board_setup(void *blob, bd_t *bd)
> +{
> +	ft_cpu_setup(blob, bd);
> +

Why didn't you add the NOR FLASH mapping fixup as done on Sequoia etc? Please 
add it here.

> +}
> +#endif
> diff --git a/include/configs/yosemite.h b/include/configs/yosemite.h
> index c9323f6..7dcd4e6 100644
> --- a/include/configs/yosemite.h
> +++ b/include/configs/yosemite.h
> @@ -141,6 +141,14 @@
>
>
>  /*-----------------------------------------------------------------------
> + * Open Firmware (Linux-2.6.26+)

I would prefer "Device tree support" here too.

> + *----------------------------------------------------------------------*/
> +
> +/* pass open firmware flat tree */
> +#define CONFIG_OF_LIBFDT	1
> +#define CONFIG_OF_BOARD_SETUP	1
> +
> +/*-----------------------------------------------------------------------
>   * I2C
>   *----------------------------------------------------------------------*/
>  #define CONFIG_HARD_I2C		1	    /* I2C with hardware support	*/
> @@ -227,6 +235,7 @@
>  #define CONFIG_MII		1	/* MII PHY management		*/
>  #define CONFIG_NET_MULTI        1	/* required for netconsole      */
>  #define CONFIG_PHY1_ADDR        3
> +#define CONFIG_HAS_ETH0		1	/* add support for "eth0addr"	*/
>  #define CONFIG_HAS_ETH1		1	/* add support for "eth1addr"	*/
>  #define CONFIG_PHY_ADDR		1	/* PHY address, See schematics	*/

Please address the issues above and resend.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From sew_s at tqs.de  Tue Apr 29 12:15:35 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Tue, 29 Apr 2008 12:15:35 +0200
Subject: [U-Boot-Users] [PATCH] net: add 16 bit support for smc911x
Message-ID: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>

Hi Ben, Magnus,

here is my patch to enable 2x16 bit accesses to the LAN9x1x.
I still not have a HW, so may I ask you to test it and, if applicable,
fix the code?

Best Regards,
Jens

---

 drivers/net/smc911x.c |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)


diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index d22c889..841a64d 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -30,6 +30,8 @@
 #include <net.h>
 #include <miiphy.h>
 
+#define CONFIG_DRIVER_SMC911X_16_BIT 1
+
 #ifdef CONFIG_DRIVER_SMC911X_32_BIT
 static inline u32 reg_read(u32 addr)
 {
@@ -39,8 +41,21 @@ static inline void reg_write(u32 addr, u32 val)
 {
 	*(volatile u32*)addr = val;
 }
+#elif CONFIG_DRIVER_SMC911X_16_BIT
+static inline u32 reg_read(u32 addr)
+{
+	u32 val_lo = (u32)(*(volatile u16*)addr);
+	u32 val_hi = (u32)(*(volatile u16*)(addr | 2));
+
+	return (val_hi << 16) | val_lo;
+}
+static inline void reg_write(u32 addr, u32 val)
+{
+	*(volatile u16*)addr = (u16)val;
+	*(volatile u16*)(addr | 2) = (u16)(val >> 16);
+}
 #else
-#error "SMC911X: Only 32-bit bus is supported"
+#error "SMC911X: undefined buswidth"
 #endif
 
 #define mdelay(n)       udelay((n)*1000)




From wd at denx.de  Tue Apr 29 13:13:27 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 13:13:27 +0200
Subject: [U-Boot-Users] [PATCH] POST: fix Makefiles for mpc8xx, lwmon,
	and netta POSTs.
Message-ID: <1209467607-21234-1-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at emcraft.com>

Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 post/board/lwmon/Makefile |    4 ++--
 post/board/netta/Makefile |    4 ++--
 post/cpu/mpc8xx/Makefile  |    5 +++--
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/post/board/lwmon/Makefile b/post/board/lwmon/Makefile
index 899b0dc..d2932be 100644
--- a/post/board/lwmon/Makefile
+++ b/post/board/lwmon/Makefile
@@ -20,10 +20,10 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
+include $(OBJTREE)/include/autoconf.mk
 
 LIB	= libpostlwmon.a
 
-COBJS	= sysmon.o
+COBJS-$(CONFIG_HAS_POST)	+= sysmon.o
 
 include $(TOPDIR)/post/rules.mk
diff --git a/post/board/netta/Makefile b/post/board/netta/Makefile
index 60c7790..8a8578f 100644
--- a/post/board/netta/Makefile
+++ b/post/board/netta/Makefile
@@ -20,10 +20,10 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
-
+include $(OBJTREE)/include/autoconf.mk
 
 LIB	= libpostnetta.a
 
-COBJS	= codec.o dsp.o
+COBJS-$(CONFIG_HAS_POST)	+= codec.o dsp.o
 
 include $(TOPDIR)/post/rules.mk
diff --git a/post/cpu/mpc8xx/Makefile b/post/cpu/mpc8xx/Makefile
index f871cba..162924f 100644
--- a/post/cpu/mpc8xx/Makefile
+++ b/post/cpu/mpc8xx/Makefile
@@ -20,10 +20,11 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 #
+include $(OBJTREE)/include/autoconf.mk
 
 LIB	= libpostmpc8xx.a
 
-AOBJS	= cache_8xx.o
-COBJS	= cache.o ether.o spr.o uart.o usb.o watchdog.o
+AOBJS-$(CONFIG_HAS_POST)	+= cache_8xx.o
+COBJS-$(CONFIG_HAS_POST)	+= cache.o ether.o spr.o uart.o usb.o watchdog.o
 
 include $(TOPDIR)/post/rules.mk
-- 
1.5.4.2




From trimarchi at gandalf.sssup.it  Tue Apr 29 13:31:07 2008
From: trimarchi at gandalf.sssup.it (michael)
Date: Tue, 29 Apr 2008 13:31:07 +0200
Subject: [U-Boot-Users] [PATCH ARM/IXP465 1/3] Add support for the
 ixp465 processor
In-Reply-To: <20080428115839.15824247B4@gemini.denx.de>
References: <20080428115839.15824247B4@gemini.denx.de>
Message-ID: <481706FB.4070800@gandalf.sssup.it>

Hi,
thanks for your comment.

Wolfgang Denk wrote:
> In message <4815AEC6.8060704 at gandalf.sssup.it> you wrote:
>   
>> This patch add basic support to the ixp465 cpu.
>>     
> ...
>   
>> diff --git a/cpu/ixp/start.S b/cpu/ixp/start.S
>> index 757cfaa..af718b0 100644
>> --- a/cpu/ixp/start.S
>> +++ b/cpu/ixp/start.S
>> @@ -29,7 +29,8 @@
>>  
>>  #include <config.h>
>>  #include <version.h>
>> -#include <asm/arch/ixp425.h>
>> +
>> +#include <asm/arch/hardware.h>
>>  
>>  #define MMU_Control_M  0x001    /* Enable MMU */
>>  #define MMU_Control_A  0x002    /* Enable address alignment faults */
>> @@ -158,6 +159,16 @@ reset:
>>  	ldr     r2, =IXP425_EXP_CS0
>>     
> --------------------^^^^^^^^^^^^^^^^
>
> Seems there is IXP425 specific stuff here. Please verify that this is
> correct. If it is correct, then probably the name should be changed.
>
>   
I think about to merge the two includes file. Maybe I take it from linux 
and use that one.
There a lot of information shared. In linux the name is for example 
IXP4XX_ ...
What do you think about it?
>> +#ifdef CONFIG_IXP465
> ...
>   
>> +#ifdef CONFIG_IXP465
>>     
> ...
>   
>> +#else
>>     
>
> That's a pretty mess of #ifdef's.
>
> Maybe we should split this into separate source files?
>
>   
I try to write just one ifdef, and duplicate a little bit the code. Is 
good for you?
> Best regards,
>
> Wolfgang Denk
>
>   
Michael



From sr at denx.de  Tue Apr 29 13:58:12 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 13:58:12 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Change ECC initialization on lwmon5
	to use clean_dcache_range()
Message-ID: <1209470292-32316-1-git-send-email-sr@denx.de>

As it seems the "old" ECC initialization routine by using dflush() didn't
write all lines in the dcache back to memory on lwmon5. This could lead
to ECC error upon Linux booting. This patch changes the program_ecc()
routine to now use clean_dcache_range() instead of dflush().
clean_dcache_range() uses dcbst which is exactly what we want in this
case.

Since dflush() is known is cause problems, this routine will be
removed completely and replaced by clean_dcache_range() with an
additional patch.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 board/lwmon5/sdram.c |   13 ++++++++++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/board/lwmon5/sdram.c b/board/lwmon5/sdram.c
index 7c3cf49..36b5100 100644
--- a/board/lwmon5/sdram.c
+++ b/board/lwmon5/sdram.c
@@ -34,6 +34,7 @@
 #include <asm/processor.h>
 #include <asm/mmu.h>
 #include <asm/io.h>
+#include <asm/cache.h>
 #include <ppc440.h>
 #include <watchdog.h>
 
@@ -59,7 +60,6 @@
 extern int denali_wait_for_dlllock(void);
 extern void denali_core_search_data_eye(void);
 extern void dcbz_area(u32 start_address, u32 num_bytes);
-extern void dflush(void);
 
 static u32 is_ecc_enabled(void)
 {
@@ -106,6 +106,7 @@ static void program_ecc(u32 start_address,
 {
 	u32 val;
 	u32 current_addr = start_address;
+	u32 size;
 	int bytes_remaining;
 
 	sync();
@@ -123,12 +124,18 @@ static void program_ecc(u32 start_address,
 	 * watchdog.
 	 */
 	while (bytes_remaining > 0) {
-		dcbz_area(current_addr, min((64 << 20), bytes_remaining));
+		size = min((64 << 20), bytes_remaining);
+
+		/* Write zero's to SDRAM */
+		dcbz_area(current_addr, size);
+
+		/* Write modified dcache lines back to memory */
+		clean_dcache_range(current_addr, current_addr + size);
+
 		current_addr += 64 << 20;
 		bytes_remaining -= 64 << 20;
 		WATCHDOG_RESET();
 	}
-	dflush();
 
 	sync();
 	wait_ddr_idle();
-- 
1.5.5.1




From sr at denx.de  Tue Apr 29 14:00:04 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 14:00:04 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Completely remove bogus dflush()
Message-ID: <1209470404-32454-1-git-send-email-sr@denx.de>

Since the current dflush() implementation is know to have some problems
(as seem on lwmon5 ECC init) this patch removes it completely and replaces
it by using clean_dcache_range().

Tested on Katmai with ECC DIMM.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 board/netstal/hcu5/sdram.c   |    6 +++---
 cpu/ppc4xx/44x_spd_ddr2.c    |    5 +++--
 cpu/ppc4xx/denali_spd_ddr2.c |    4 ++--
 cpu/ppc4xx/start.S           |   29 -----------------------------
 4 files changed, 8 insertions(+), 36 deletions(-)

diff --git a/board/netstal/hcu5/sdram.c b/board/netstal/hcu5/sdram.c
index 0b16b50..6b1b53a 100644
--- a/board/netstal/hcu5/sdram.c
+++ b/board/netstal/hcu5/sdram.c
@@ -34,11 +34,11 @@
 #include <asm/processor.h>
 #include <asm/io.h>
 #include <asm/mmu.h>
+#include <asm/cache.h>
 #include <ppc440.h>
 
 void hcu_led_set(u32 value);
 void dcbz_area(u32 start_address, u32 num_bytes);
-void dflush(void);
 
 #define DDR_DCR_BASE 0x10
 #define ddrcfga  (DDR_DCR_BASE+0x0)   /* DDR configuration address reg */
@@ -185,14 +185,14 @@ static void program_ecc(unsigned long start_address, unsigned long num_bytes)
 #endif
 
 	sync();
-	eieio();
 
 	puts(str);
 
 	/* ECC bit set method for cached memory */
 	/* Fast method, no noticeable delay */
 	dcbz_area(start_address, num_bytes);
-	dflush();
+	/* Write modified dcache lines back to memory */
+	clean_dcache_range(start_address, start_address + num_bytes);
 	blank_string(strlen(str));
 
 	/* Clear error status */
diff --git a/cpu/ppc4xx/44x_spd_ddr2.c b/cpu/ppc4xx/44x_spd_ddr2.c
index 9e722b9..5b5de48 100644
--- a/cpu/ppc4xx/44x_spd_ddr2.c
+++ b/cpu/ppc4xx/44x_spd_ddr2.c
@@ -40,6 +40,7 @@
 #include <asm/io.h>
 #include <asm/processor.h>
 #include <asm/mmu.h>
+#include <asm/cache.h>
 
 #if defined(CONFIG_SPD_EEPROM) &&				\
 	(defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
@@ -237,7 +238,6 @@ static void	DQS_calibration_process(void);
 static void ppc440sp_sdram_register_dump(void);
 int do_reset (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[]);
 void dcbz_area(u32 start_address, u32 num_bytes);
-void dflush(void);
 
 static u32 mfdcr_any(u32 dcr)
 {
@@ -2355,7 +2355,8 @@ static void program_ecc_addr(unsigned long start_address,
 		} else {
 			/* ECC bit set method for cached memory */
 			dcbz_area(start_address, num_bytes);
-			dflush();
+			/* Write modified dcache lines back to memory */
+			clean_dcache_range(start_address, start_address + num_bytes);
 		}
 
 		blank_string(strlen(str));
diff --git a/cpu/ppc4xx/denali_spd_ddr2.c b/cpu/ppc4xx/denali_spd_ddr2.c
index e20c9eb..acf0f49 100644
--- a/cpu/ppc4xx/denali_spd_ddr2.c
+++ b/cpu/ppc4xx/denali_spd_ddr2.c
@@ -92,7 +92,6 @@
 extern int denali_wait_for_dlllock(void);
 extern void denali_core_search_data_eye(void);
 extern void dcbz_area(u32 start_address, u32 num_bytes);
-extern void dflush(void);
 
 /*
  * Board-specific Platform code can reimplement spd_ddr_init_hang () if needed
@@ -1201,7 +1200,8 @@ long int initdram(int board_type)
 #else
 #error Please define CFG_MEM_TOP_HIDE (see README) in your board config file
 #endif
-	dflush();
+	/* Write modified dcache lines back to memory */
+	clean_dcache_range(CFG_SDRAM_BASE, CFG_SDRAM_BASE + dram_size - CFG_MEM_TOP_HIDE);
 	debug("Completed\n");
 	sync();
 	remove_tlb(CFG_SDRAM_BASE, dram_size);
diff --git a/cpu/ppc4xx/start.S b/cpu/ppc4xx/start.S
index 8d2777d..a513b45 100644
--- a/cpu/ppc4xx/start.S
+++ b/cpu/ppc4xx/start.S
@@ -1675,35 +1675,6 @@ trap_reloc:
 	sync
 	blr
 	function_epilog(dcbz_area)
-
-/*----------------------------------------------------------------------------+
-| dflush.  Assume 32K at vector address is cachable.
-+----------------------------------------------------------------------------*/
-	function_prolog(dflush)
-	mfmsr	r9
-	rlwinm	r8,r9,0,15,13
-	rlwinm	r8,r8,0,17,15
-	mtmsr	r8
-	mfspr	r8,dvlim
-	addi	r3,r0,0x0000
-	mtspr	dvlim,r3
-	mfspr	r3,ivpr
-	addi	r4,r0,1024
-	mtctr	r4
-..dflush_loop:
-	lwz	r6,0x0(r3)
-	addi	r3,r3,32
-	bdnz	..dflush_loop
-	addi	r3,r3,-32
-	mtctr	r4
-..ag:	dcbf	r0,r3
-	addi	r3,r3,-32
-	bdnz	..ag
-	mtspr	dvlim,r8
-	sync
-	mtmsr	r9
-	blr
-	function_epilog(dflush)
 #endif /* CONFIG_440 */
 #endif /* CONFIG_NAND_SPL */
 
-- 
1.5.5.1




From genine-alleril at BintGroup.com  Tue Apr 29 14:03:17 2008
From: genine-alleril at BintGroup.com (Ihle)
Date: Tue, 29 Apr 2008 15:03:17 +0300
Subject: [U-Boot-Users] Top 10 ways on how to increase sex drive
Message-ID: <303DFB13.B%genine-alleril@BintGroup.com>

Your girlfriend will thank you for taking our new herbal drugs http://www.delpot.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080429/e496d77c/attachment.htm 

From sr at denx.de  Tue Apr 29 14:12:40 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 14:12:40 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Katmai CFG_MONITOR_LEN
Message-ID: <1209471160-4453-1-git-send-email-sr@denx.de>

Signed-off-by: Stefan Roese <sr at denx.de>
---
 include/configs/katmai.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/katmai.h b/include/configs/katmai.h
index 122b700..aad28fb 100644
--- a/include/configs/katmai.h
+++ b/include/configs/katmai.h
@@ -48,7 +48,7 @@
  * Base addresses -- Note these are effective addresses where the
  * actual resources get mapped (not physical addresses)
  *----------------------------------------------------------------------*/
-#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Mon */
+#define CFG_MONITOR_LEN		(384 * 1024)	/* Reserve 384 kB for Mon */
 #define CFG_MALLOC_LEN		(512 * 1024)	/* Reserve 512 kB for malloc */
 
 #define CFG_SDRAM_BASE		0x00000000	/* _must_ be 0		*/
-- 
1.5.5.1




From vasiliy.leonenko at mail.ru  Tue Apr 29 14:14:30 2008
From: vasiliy.leonenko at mail.ru (Vasiliy Leoenenko)
Date: Tue, 29 Apr 2008 16:14:30 +0400
Subject: [U-Boot-Users] =?koi8-r?b?W1BBVENIXSBNMTggZmxhc2ggKFNpYmxleSkg?=
	=?koi8-r?b?c3VwcG9ydCAoYXR0ZW1wdCAyKQ==?=
In-Reply-To: <200804250835.29033.sr@denx.de>
References: <200804250835.29033.sr@denx.de>
Message-ID: <E1Jqoj8-000FYw-00.vasiliy-leonenko-mail-ru@f185.mail.ru>


Hi Stefan

> Unfortunately this breaks CFI support for "normal" AMD/Spansion FLASH equipped
> boards. On Sequoia with Spansion GL512 I get this after applying your patch:
> 
> Please fix this and resubmit. Best would be if you could test it on a board
> with Spansion CFI FLASH's too.

I investigated the reproted issue and I think I've corrected it. The issue caused by my incorect conversion of cmd value in flash_make_cmd function.
So we improved the procedure of conversion. I think it will be better to sent two patches:
The first patch adds support of long commands and fixes conversion issues.
The second patch adds M18 family command set support. 

Patches were tested on Mainstone II board and two flashes:
M18 portwidth=16 chipwidth=16
P30 portwidth=32 chipwidth=16
Also I tested in simulation the conversion algorithms to make sure that it works fine. 
Unforunately I have no abiliy to test my patch on different borads and width Spansion CFI flash.


The next two messages will contain patches. 

Best regards
Vasiliy




From vasiliy.leonenko at mail.ru  Tue Apr 29 14:15:41 2008
From: vasiliy.leonenko at mail.ru (Vasiliy Leoenenko)
Date: Tue, 29 Apr 2008 16:15:41 +0400
Subject: [U-Boot-Users] =?koi8-r?b?W1BBVENIXSBNMTggZmxhc2ggKFNpYmxleSkg?=
	=?koi8-r?b?c3VwcG9ydCAoYXR0ZW1wdCAyKQ==?=
In-Reply-To: <200804250835.29033.sr@denx.de>
References: <200804250835.29033.sr@denx.de>
Message-ID: <E1JqokH-000IQ6-00.vasiliy-leonenko-mail-ru@f128.mail.ru>


The first patch (support of long commands):

===================================================
diff -aupNr a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
--- a/drivers/mtd/cfi_flash.c	2008-04-21 02:39:38.000000000 +0400
+++ b/drivers/mtd/cfi_flash.c	2008-04-29 15:57:51.000000000 +0400
@@ -298,17 +298,29 @@ static inline void flash_unmap(flash_inf
 /*-----------------------------------------------------------------------
  * make a proper sized command based on the port and chip widths
  */
-static void flash_make_cmd (flash_info_t * info, uchar cmd, void *cmdbuf)
+static void flash_make_cmd (flash_info_t * info, ulong cmd, void *cmdbuf)
 {
 	int i;
+	int cpofft;
 	uchar *cp = (uchar *) cmdbuf;
+	uchar cp_val;
 
 #if defined(__LITTLE_ENDIAN) || defined(CFG_WRITE_SWAPPED_DATA)
-	for (i = info->portwidth; i > 0; i--)
+	for (i = sizeof(cfiword_t); i > 0; i--)
+	{
+		cpofft=(i-1);
 #else
-	for (i = 1; i <= info->portwidth; i++)
-#endif
-		*cp++ = (i & (info->chipwidth - 1)) ? '\0' : cmd;
+	for (i = 1; i <= sizeof(cfiword_t); i++)
+	{
+		cpofft=(sizeof(cfiword_t)-i);
+#endif
+		if( cpofft%info->chipwidth >= sizeof(ulong) || cpofft>=info->portwidth)
+			cp_val = 0x00;
+		else
+			cp_val = *((uchar*)&cmd + cpofft%info->chipwidth);
+			
+		cp[i-1] = cp_val;		
+	}
 }
 
 #ifdef DEBUG
@@ -422,7 +434,7 @@ static ulong flash_read_long (flash_info
  * Write a proper sized command to the correct address
  */
 static void flash_write_cmd (flash_info_t * info, flash_sect_t sect,
-			     uint offset, uchar cmd)
+			     uint offset, ulong cmd)
 {
 
 	void *addr;
@@ -911,7 +923,7 @@ static int flash_write_cfibuffer (flash_
 			/* reduce the number of loops by the width of
 			 * the port */
 			cnt = len >> shift;
-			flash_write_cmd (info, sector, 0, (uchar) cnt - 1);
+			flash_write_cmd (info, sector, 0, cnt - 1);
 			while (cnt-- > 0) {
 				switch (info->portwidth) {
 				case FLASH_CFI_8BIT:






From vasiliy.leonenko at mail.ru  Tue Apr 29 14:16:27 2008
From: vasiliy.leonenko at mail.ru (Vasiliy Leoenenko)
Date: Tue, 29 Apr 2008 16:16:27 +0400
Subject: [U-Boot-Users] =?koi8-r?b?W1BBVENIXSBNMTggZmxhc2ggKFNpYmxleSkg?=
	=?koi8-r?b?c3VwcG9ydCAoYXR0ZW1wdCAyKQ==?=
In-Reply-To: <200804250835.29033.sr@denx.de>
References: <200804250835.29033.sr@denx.de>
Message-ID: <E1Jqol1-000N3c-00.vasiliy-leonenko-mail-ru@f60.mail.ru>


The second patch (M18 family command set support)
================================================================
diff -aupNr a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
--- a/drivers/mtd/cfi_flash.c	2008-04-29 15:57:51.000000000 +0400
+++ b/drivers/mtd/cfi_flash.c	2008-04-29 15:59:04.000000000 +0400
@@ -76,7 +76,9 @@
 #define FLASH_CMD_PROTECT_SET		0x01
 #define FLASH_CMD_PROTECT_CLEAR		0xD0
 #define FLASH_CMD_CLEAR_STATUS		0x50
+#define FLASH_CMD_READ_STATUS		0x70
 #define FLASH_CMD_WRITE_TO_BUFFER	0xE8
+#define FLASH_CMD_WRITE_BUFFER_PROG	0xE9
 #define FLASH_CMD_WRITE_BUFFER_CONFIRM	0xD0
 
 #define FLASH_STATUS_DONE		0x80
@@ -136,6 +138,7 @@
 #define CFI_CMDSET_MITSU_STANDARD	256
 #define CFI_CMDSET_MITSU_EXTENDED	257
 #define CFI_CMDSET_SST			258
+#define CFI_CMDSET_INTEL_PROG_REGIONS	512
 
 #ifdef CFG_FLASH_CFI_AMD_RESET /* needed for STM_ID_29W320DB on UC100 */
 # undef  FLASH_CMD_RESET
@@ -617,6 +620,7 @@ static int flash_is_busy (flash_info_t *
 	int retval;
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
 		retval = !flash_isset (info, sect, 0, FLASH_STATUS_DONE);
@@ -676,6 +680,7 @@ static int flash_full_status_check (flas
 
 	retcode = flash_status_check (info, sector, tout, prompt);
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_EXTENDED:
 	case CFI_CMDSET_INTEL_STANDARD:
 		if ((retcode == ERR_OK)
@@ -804,6 +809,7 @@ static int flash_write_cfiword (flash_in
 	flag = disable_interrupts ();
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_EXTENDED:
 	case CFI_CMDSET_INTEL_STANDARD:
 		flash_write_cmd (info, 0, 0, FLASH_CMD_CLEAR_STATUS);
@@ -858,6 +864,7 @@ static int flash_write_cfibuffer (flash_
 	int flag = 0;
 	uint offset = 0;
 	unsigned int shift;
+	uchar write_cmd;
 
 	switch (info->portwidth) {
 	case FLASH_CFI_8BIT:
@@ -912,10 +919,14 @@ static int flash_write_cfibuffer (flash_
 	sector = find_sector (info, dest);
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
+		write_cmd = (info->vendor == CFI_CMDSET_INTEL_PROG_REGIONS) ? 
+					FLASH_CMD_WRITE_BUFFER_PROG : FLASH_CMD_WRITE_TO_BUFFER;
 		flash_write_cmd (info, sector, 0, FLASH_CMD_CLEAR_STATUS);
-		flash_write_cmd (info, sector, 0, FLASH_CMD_WRITE_TO_BUFFER);
+		flash_write_cmd (info, sector, 0, FLASH_CMD_READ_STATUS);
+		flash_write_cmd (info, sector, 0, write_cmd);
 		retcode = flash_status_check (info, sector,
 					      info->buffer_write_tout,
 					      "write to buffer");
@@ -1050,6 +1061,7 @@ int flash_erase (flash_info_t * info, in
 	for (sect = s_first; sect <= s_last; sect++) {
 		if (info->protect[sect] == 0) { /* not protected */
 			switch (info->vendor) {
+			case CFI_CMDSET_INTEL_PROG_REGIONS:
 			case CFI_CMDSET_INTEL_STANDARD:
 			case CFI_CMDSET_INTEL_EXTENDED:
 				flash_write_cmd (info, sect, 0,
@@ -1118,6 +1130,9 @@ void flash_print_info (flash_info_t * in
 			info->size >> 20, info->sector_count);
 	printf ("  ");
 	switch (info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
+			printf ("Intel Prog Regions");
+			break;
 		case CFI_CMDSET_INTEL_STANDARD:
 			printf ("Intel Standard");
 			break;
@@ -1508,6 +1523,7 @@ static void flash_read_jedec_ids (flash_
 	info->device_id2      = 0;
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
 		cmdset_intel_read_jedec_ids(info);
@@ -1562,6 +1578,7 @@ static int flash_detect_legacy(ulong bas
 		}
 
 		switch(info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
 		case CFI_CMDSET_INTEL_STANDARD:
 		case CFI_CMDSET_INTEL_EXTENDED:
 			info->cmd_reset = FLASH_CMD_RESET;
@@ -1757,6 +1774,7 @@ ulong flash_get_size (ulong base, int ba
 #endif
 
 		switch (info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
 		case CFI_CMDSET_INTEL_STANDARD:
 		case CFI_CMDSET_INTEL_EXTENDED:
 			cmdset_intel_init(info, &qry);
@@ -1834,6 +1852,7 @@ ulong flash_get_size (ulong base, int ba
 				 * supported devices (intel...)
 				 */
 				switch (info->vendor) {
+				case CFI_CMDSET_INTEL_PROG_REGIONS:
 				case CFI_CMDSET_INTEL_EXTENDED:
 				case CFI_CMDSET_INTEL_STANDARD:
 					info->protect[sect_cnt] =





From sr at denx.de  Tue Apr 29 14:43:17 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 14:43:17 +0200
Subject: [U-Boot-Users] [PATCH] M18 flash (Sibley) support (attempt 2)
In-Reply-To: <E1JqokH-000IQ6-00.vasiliy-leonenko-mail-ru@f128.mail.ru>
References: <200804250835.29033.sr@denx.de>
	<E1JqokH-000IQ6-00.vasiliy-leonenko-mail-ru@f128.mail.ru>
Message-ID: <200804291443.17219.sr@denx.de>

On Tuesday 29 April 2008, Vasiliy Leoenenko wrote:
> The first patch (support of long commands):

I like the idea of splitting this patch up in two separate patches/emails. But 
please provide a descriptive subject and a short description that can will be 
added to the git repository as commit text for each patch. And don't forget 
your Signed-off-by line.

Please take a look at other patches on the list how this should be done. Best 
would be if you could use the git tools to create (and send) the patches.

Thanks.

Some further remarks below:

> ===================================================
> diff -aupNr a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
> --- a/drivers/mtd/cfi_flash.c	2008-04-21 02:39:38.000000000 +0400
> +++ b/drivers/mtd/cfi_flash.c	2008-04-29 15:57:51.000000000 +0400
> @@ -298,17 +298,29 @@ static inline void flash_unmap(flash_inf
>  /*-----------------------------------------------------------------------
>   * make a proper sized command based on the port and chip widths
>   */
> -static void flash_make_cmd (flash_info_t * info, uchar cmd, void *cmdbuf)
> +static void flash_make_cmd (flash_info_t * info, ulong cmd, void *cmdbuf)
>  {
>  	int i;
> +	int cpofft;
>  	uchar *cp = (uchar *) cmdbuf;
> +	uchar cp_val;
>
>  #if defined(__LITTLE_ENDIAN) || defined(CFG_WRITE_SWAPPED_DATA)
> -	for (i = info->portwidth; i > 0; i--)
> +	for (i = sizeof(cfiword_t); i > 0; i--)
> +	{

+	for (i = sizeof(cfiword_t); i > 0; i--) {

The code down below has some coding style issues too. Please 

> +		cpofft=(i-1);

+		cpofft = i - 1;

The code down below has some coding style issues too. Please try to be more 
careful here.

And the resulting code looks like this:

#if defined(__LITTLE_ENDIAN) || defined(CFG_WRITE_SWAPPED_DATA)
	for (i = sizeof(cfiword_t); i > 0; i--)
	{
		cpofft=(i-1);
#else
	for (i = 1; i <= sizeof(cfiword_t); i++)
	{
		cpofft=(sizeof(cfiword_t)-i);
#endif
		if( cpofft%info->chipwidth >= sizeof(ulong) || cpofft>=info->portwidth)
			cp_val = 0x00;
		else
			cp_val = *((uchar*)&cmd + cpofft%info->chipwidth);
			
		cp[i-1] = cp_val;		
	}


Apart from the coding-style issues, this is getting quite complex and unclear. 
At least to me. Are you sure that this can't be written differently to make 
it easier to understand? 

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From wd at denx.de  Tue Apr 29 14:50:30 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 14:50:30 +0200
Subject: [U-Boot-Users] [PATCH] ppc flush_cache: add watch-dog triggering
	into the loops.
Message-ID: <1209473430-22441-1-git-send-email-wd@denx.de>

From: Yuri Tikhonov <yur at emcraft.com>

Some boards (e.g. lwmon5) need rather a frequent watch-dog
kicking. Since the time it takes for the flush_cache() function
to complete its job depends on the size of data being flushed, one
may encounter watch-dog resets on such boards when, for example,
download big files over ethernet.

Signed-off-by: Yuri Tikhonov <yur at emcraft.com>
---
 lib_ppc/cache.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/lib_ppc/cache.c b/lib_ppc/cache.c
index 27e1a82..5bfb220 100644
--- a/lib_ppc/cache.c
+++ b/lib_ppc/cache.c
@@ -23,6 +23,7 @@
 
 #include <common.h>
 #include <asm/cache.h>
+#include <watchdog.h>
 
 void flush_cache (ulong start_addr, ulong size)
 {
@@ -35,6 +36,7 @@ void flush_cache (ulong start_addr, ulong size)
 		     addr < end_addr;
 		     addr += CFG_CACHELINE_SIZE) {
 			asm ("dcbst 0,%0": :"r" (addr));
+			WATCHDOG_RESET();
 		}
 		asm ("sync");	/* Wait for all dcbst to complete on bus */
 
@@ -42,6 +44,7 @@ void flush_cache (ulong start_addr, ulong size)
 		     addr < end_addr;
 		     addr += CFG_CACHELINE_SIZE) {
 			asm ("icbi 0,%0": :"r" (addr));
+			WATCHDOG_RESET();
 		}
 	}
 	asm ("sync");		/* Always flush prefetch queue in any case */
-- 
1.5.4.2




From stuart.wood at labxtechnologies.com  Tue Apr 29 14:54:47 2008
From: stuart.wood at labxtechnologies.com (Stuart Wood)
Date: Tue, 29 Apr 2008 08:54:47 -0400
Subject: [U-Boot-Users] Status of the Yaffs patches?
In-Reply-To: <200804290708.00897.sr@denx.de>
References: <20080428214442.21BE3248A6@gemini.denx.de>
	<200804290708.00897.sr@denx.de>
Message-ID: <c13b1cfc0804290554w40b7b2efr2821757f9c62dce7@mail.gmail.com>

Thanks,

I'll look into it. but I will need to do quite a bit of work to bring
our u-boot up to the current release. We're about 2 years old and
running on an EP9302 Arm processor. I'm not sure what we're built off
from, so extracting our work will take some time. I very much want to
move to YAFFS since we only have NAND flash storage.

Stuart

On Tue, Apr 29, 2008 at 1:08 AM, Stefan Roese <sr at denx.de> wrote:
> On Monday 28 April 2008, Wolfgang Denk wrote:
>  > > Can anyone give me an update on the status of integrating YAFFS binary
>  > > image reading and writing into U-Boot?
>  >
>  > I think they got lost, most probably because  the  patches  were  not
>  > posted inline but just as a reference to some URI.
>
>  I'm not sure if that's what Stuart is referring to. YAFFS "binary images" can
>  be read and written without problems with the current code (since years). You
>  need to use the ".jffs2/.i" option for skipping bad blocks.
>
>  But if you are referring to the YAFFS filesystem support in U-Boot, then the
>  work Wolfgang is referring to is currently available in the mtd-2.6.22.1
>  branch of the u-boot-nand-flash repository. I have to admit that I'm not sure
>  if the YAFFS support has already been integrated though. Unfortunately this
>  branch still has some problems and I didn't get enough feedback/patches to
>  fix those problems. So we can't merge this stuff into mainline yet.
>
>  Best regards,
>  Stefan
>
>  =====================================================================
>
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
>  HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>  Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
>  =====================================================================
>



From plagnioj at jcrosoft.com  Tue Apr 29 15:02:55 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Tue, 29 Apr 2008 15:02:55 +0200
Subject: [U-Boot-Users] [PATCH] M18 flash (Sibley) support (attempt 2)
In-Reply-To: <E1Jqoj8-000FYw-00.vasiliy-leonenko-mail-ru@f185.mail.ru>
References: <200804250835.29033.sr@denx.de>
	<E1Jqoj8-000FYw-00.vasiliy-leonenko-mail-ru@f185.mail.ru>
Message-ID: <20080429130255.GA6355@game.jcrosoft.org>

On 16:14 Tue 29 Apr     , Vasiliy Leoenenko wrote:
> 
> Hi Stefan
> 
> > Unfortunately this breaks CFI support for "normal" AMD/Spansion FLASH equipped
> > boards. On Sequoia with Spansion GL512 I get this after applying your patch:
> > 
> > Please fix this and resubmit. Best would be if you could test it on a board
> > with Spansion CFI FLASH's too.
> 
> I investigated the reproted issue and I think I've corrected it. The issue caused by my incorect conversion of cmd value in flash_make_cmd function.
> So we improved the procedure of conversion. I think it will be better to sent two patches:
> The first patch adds support of long commands and fixes conversion issues.
> The second patch adds M18 family command set support. 
> 
> Patches were tested on Mainstone II board and two flashes:
> M18 portwidth=16 chipwidth=16
> P30 portwidth=32 chipwidth=16
> Also I tested in simulation the conversion algorithms to make sure that it works fine. 
> Unforunately I have no abiliy to test my patch on different borads and width Spansion CFI flash.

You could test it on qemu_mips which use an amd cfi flash or with few
modif in qemu an intel falsh

Best Regards,
J.



From galak at kernel.crashing.org  Tue Apr 29 15:28:24 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 29 Apr 2008 08:28:24 -0500
Subject: [U-Boot-Users] [PATCH] ppc flush_cache: add watch-dog
	triggering into the loops.
In-Reply-To: <1209473430-22441-1-git-send-email-wd@denx.de>
References: <1209473430-22441-1-git-send-email-wd@denx.de>
Message-ID: <DD1539F4-3992-4D8E-92D1-8C53826FDB06@kernel.crashing.org>


On Apr 29, 2008, at 7:50 AM, Wolfgang Denk wrote:
> From: Yuri Tikhonov <yur at emcraft.com>
>
> Some boards (e.g. lwmon5) need rather a frequent watch-dog
> kicking. Since the time it takes for the flush_cache() function
> to complete its job depends on the size of data being flushed, one
> may encounter watch-dog resets on such boards when, for example,
> download big files over ethernet.

is this because the size argument being passed to flush_cache is well  
beyond the size of the cache itself?

- k




From william.juul at tandberg.com  Tue Apr 29 15:27:47 2008
From: william.juul at tandberg.com (William Juul)
Date: Tue, 29 Apr 2008 15:27:47 +0200
Subject: [U-Boot-Users] Status of the Yaffs patches?
In-Reply-To: <c13b1cfc0804290554w40b7b2efr2821757f9c62dce7@mail.gmail.com>
References: <20080428214442.21BE3248A6@gemini.denx.de>	
	<200804290708.00897.sr@denx.de>
	<c13b1cfc0804290554w40b7b2efr2821757f9c62dce7@mail.gmail.com>
Message-ID: <48172253.3000006@tandberg.com>

The branch Stefan is referring to should contain a working yaffs 
implementation. We have had yaffs working on two boards (ARM and PPC) 
for more than 6 months now.

The outstanding issues on the branch is with respect to the MTD 
implementation (which we ported from current Linux at that time).

We have started to work out (some of) the problems. As we understood, 
the biggest obstacle were missing implementation of read/write.i/jffs. 
We are sending a patch for that to the mailing list now.

Other known issues with our MTD-port is missing commands for lock/unlock 
  and lack of implementation/testing for OneNand.

We would really like for this to go into mainline U-boot, but we need 
help from other developers as well as we do not have necessary HW.

Best regards
William


Stuart Wood wrote:
> Thanks,
> 
> I'll look into it. but I will need to do quite a bit of work to bring
> our u-boot up to the current release. We're about 2 years old and
> running on an EP9302 Arm processor. I'm not sure what we're built off
> from, so extracting our work will take some time. I very much want to
> move to YAFFS since we only have NAND flash storage.
> 
> Stuart
> 
> On Tue, Apr 29, 2008 at 1:08 AM, Stefan Roese <sr at denx.de> wrote:
>> On Monday 28 April 2008, Wolfgang Denk wrote:
>>  > > Can anyone give me an update on the status of integrating YAFFS binary
>>  > > image reading and writing into U-Boot?
>>  >
>>  > I think they got lost, most probably because  the  patches  were  not
>>  > posted inline but just as a reference to some URI.
>>
>>  I'm not sure if that's what Stuart is referring to. YAFFS "binary images" can
>>  be read and written without problems with the current code (since years). You
>>  need to use the ".jffs2/.i" option for skipping bad blocks.
>>
>>  But if you are referring to the YAFFS filesystem support in U-Boot, then the
>>  work Wolfgang is referring to is currently available in the mtd-2.6.22.1
>>  branch of the u-boot-nand-flash repository. I have to admit that I'm not sure
>>  if the YAFFS support has already been integrated though. Unfortunately this
>>  branch still has some problems and I didn't get enough feedback/patches to
>>  fix those problems. So we can't merge this stuff into mainline yet.
>>
>>  Best regards,
>>  Stefan
>>
>>  =====================================================================
>>
>> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
>>  HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>>  Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
>>  =====================================================================
>>




From wd at denx.de  Tue Apr 29 15:37:27 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 15:37:27 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Katmai CFG_MONITOR_LEN
In-Reply-To: Your message of "Tue, 29 Apr 2008 14:12:40 +0200."
	<1209471160-4453-1-git-send-email-sr@denx.de>
Message-ID: <20080429133727.B753624681@gemini.denx.de>

In message <1209471160-4453-1-git-send-email-sr at denx.de> you wrote:
> Signed-off-by: Stefan Roese <sr at denx.de>
...
> -#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Mon */
> +#define CFG_MONITOR_LEN		(384 * 1024)	/* Reserve 384 kB for Mon */

Hm... maybe we should become defensive and use

#define CFG_MONITOR_LEN (0xFFFFFFFF - CFG_MONITOR_BASE + 1)

instead?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's certainly  convenient  the  way  the  crime  (or  condition)  of
stupidity   carries   with   it  its  own  punishment,  automatically
admisistered without remorse, pity, or prejudice. :-)
         -- Tom Christiansen in <559seq$ag1$1 at csnews.cs.colorado.edu>



From wd at denx.de  Tue Apr 29 15:43:18 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 15:43:18 +0200
Subject: [U-Boot-Users] =?koi8-r?b?W1BBVENIXSBNMTggZmxhc2ggKFNpYmxleSkg?=
	=?koi8-r?b?c3VwcG9ydCAoYXR0ZW1wdCAyKQ==?=
In-Reply-To: Your message of "Tue, 29 Apr 2008 16:15:41 +0400."
	<E1JqokH-000IQ6-00.vasiliy-leonenko-mail-ru@f128.mail.ru>
Message-ID: <20080429134318.D801424681@gemini.denx.de>

In message <E1JqokH-000IQ6-00.vasiliy-leonenko-mail-ru at f128.mail.ru> you wrote:
> 
> The first patch (support of long commands):

That's not exactly a good commit message.

And your signed-off-by line is missing.

And the coding style is broken. There are trailing white spaces,
and...

>  #if defined(__LITTLE_ENDIAN) || defined(CFG_WRITE_SWAPPED_DATA)
> -	for (i = info->portwidth; i > 0; i--)
> +	for (i = sizeof(cfiword_t); i > 0; i--)
> +	{

... bad brace style here and elsewhere.

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: wd at denx.de
"You know, after a woman's raised a family and so on,  she  wants  to
start living her own life."   "Whose life she's _been_ living, then?"
                                  - Terry Pratchett, _Witches Abroad_



From wd at denx.de  Tue Apr 29 15:47:13 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 15:47:13 +0200
Subject: [U-Boot-Users] [PATCH] ppc flush_cache: add watch-dog
	triggering into the loops.
In-Reply-To: Your message of "Tue, 29 Apr 2008 08:28:24 CDT."
	<DD1539F4-3992-4D8E-92D1-8C53826FDB06@kernel.crashing.org>
Message-ID: <20080429134714.0C51824681@gemini.denx.de>

Dear Kumar,

in message <DD1539F4-3992-4D8E-92D1-8C53826FDB06 at kernel.crashing.org> you wrote:
> 
> > Some boards (e.g. lwmon5) need rather a frequent watch-dog
> > kicking. Since the time it takes for the flush_cache() function
> > to complete its job depends on the size of data being flushed, one
> > may encounter watch-dog resets on such boards when, for example,
> > download big files over ethernet.
> 
> is this because the size argument being passed to flush_cache is well  
> beyond the size of the cache itself?

Yes - the thing is that after a TFTP download flush_cache() is called
for the size of the downloaded filr; this may be 8 or 32 MiB or  more
;-)

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: wd at denx.de
Severe culture shock results when experts from another protocol suite
[...] try to read OSI documents. The term "osified" is used to  refer
to  such  documents. [...] Any relationship to the word "ossified" is
purely intentional.                                - Marshall T. Rose



From sr at denx.de  Tue Apr 29 15:59:27 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 15:59:27 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix Katmai CFG_MONITOR_LEN
In-Reply-To: <20080429133727.B753624681@gemini.denx.de>
References: <20080429133727.B753624681@gemini.denx.de>
Message-ID: <200804291559.27948.sr@denx.de>

On Tuesday 29 April 2008, Wolfgang Denk wrote:
> In message <1209471160-4453-1-git-send-email-sr at denx.de> you wrote:
> > Signed-off-by: Stefan Roese <sr at denx.de>
>
> ...
>
> > -#define CFG_MONITOR_LEN		(256 * 1024)	/* Reserve 256 kB for Mon */
> > +#define CFG_MONITOR_LEN		(384 * 1024)	/* Reserve 384 kB for Mon */
>
> Hm... maybe we should become defensive and use
>
> #define CFG_MONITOR_LEN (0xFFFFFFFF - CFG_MONITOR_BASE + 1)
>
> instead?

Yep, even better. I'll make the necessary changes.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================



From galak at kernel.crashing.org  Tue Apr 29 16:04:24 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 29 Apr 2008 09:04:24 -0500
Subject: [U-Boot-Users] [PATCH] ppc flush_cache: add watch-dog
	triggering into the loops.
In-Reply-To: <20080429134714.0C51824681@gemini.denx.de>
References: <20080429134714.0C51824681@gemini.denx.de>
Message-ID: <8AF9326F-636B-44B5-A39B-CB470E0CED2A@kernel.crashing.org>


On Apr 29, 2008, at 8:47 AM, Wolfgang Denk wrote:
> Dear Kumar,
>
> in message  
> <DD1539F4-3992-4D8E-92D1-8C53826FDB06 at kernel.crashing.org> you wrote:
>>
>>> Some boards (e.g. lwmon5) need rather a frequent watch-dog
>>> kicking. Since the time it takes for the flush_cache() function
>>> to complete its job depends on the size of data being flushed, one
>>> may encounter watch-dog resets on such boards when, for example,
>>> download big files over ethernet.
>>
>> is this because the size argument being passed to flush_cache is well
>> beyond the size of the cache itself?
>
> Yes - the thing is that after a TFTP download flush_cache() is called
> for the size of the downloaded filr; this may be 8 or 32 MiB or  more
> ;-)

Seems like we should have a max flush size that is know to flush the  
whole cache.

Something like:

void flush_cache (ulong start_addr, ulong size)
{
#ifndef CONFIG_5xx
         ulong addr, end_addr;
	size = MIN(MAX_CACHE_SIZE_TO_FLUSH, size);
	end_addr = start_addr + size;
...

oh well.

- k



From afleming at gmail.com  Tue Apr 29 16:34:31 2008
From: afleming at gmail.com (Andy Fleming)
Date: Tue, 29 Apr 2008 09:34:31 -0500
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
In-Reply-To: <4816C712.3000806@matrix-vision.de>
References: <48109D11.9070508@matrix-vision.de>
	<2acbd3e40804281421q642a20d2j9b3357472a499244@mail.gmail.com>
	<4816C712.3000806@matrix-vision.de>
Message-ID: <2acbd3e40804290734l315c57fevd9ba1ddfc5445da8@mail.gmail.com>

On Tue, Apr 29, 2008 at 1:58 AM, Andre Schwarz
<andre.schwarz at matrix-vision.de> wrote:
> Andy,
>
>  thanks for your comments.
>
>
>  Andy Fleming schrieb:
>
> > On Thu, Apr 24, 2008 at 9:45 AM, Andre Schwarz
>  > <andre.schwarz at matrix-vision.de> wrote:
>  >
>  >
>  >>  {MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
>  >>  +#if defined(CFG_VSC8601_SKEW_TX) && defined(CFG_VSC8601_SKEW_RX)
>  >>  +                {MIIM_EXT_PAGE_ACCESS,1,NULL},
>  >>  +#define VSC8101_SKEW    (CFG_VSC8601_SKEW_TX<<14)|(CFG_VSC8601_SKEW_RX<<12)
>  >>  +                {MIIM_VSC8601_SKEW_CTRL,VSC8101_SKEW,NULL},
>  >>  +                {MIIM_EXT_PAGE_ACCESS,0,NULL},
>  >>  +#endif
>  >>   #endif
>  >>
>  >
>  >
>  > I'm not sure this is the best solution to this.  It seems like it
>  > wouldn't scale well.  Either we need to set a bit somewhere that the
>  > phy driver can read (and thereby determine how to configure the skew),
>  > or we need to set the value to write in the board config file.  I'm
>  > partial to the first solution, as it encapsulates the information
>  > inside the code that deals with it.
>  >
>  > [...]
>  >
>  >
>  I don't understand "scale well". What should be scalable ?
>
>  Of course using a function would be better.
>  I silently assumed that the other bits are set to zero which is true
>  after reset.
>  There are only two other bits : Packet size and 10M preamble mode.
>  Both should be left untouched, i.e. "0".
>


Sorry, I should have been more explicit.  In this case I'm referring
to how well the solution scales as we deal with more configuration
options.  Your solution isn't a terrible example of this, but #ifdefs
that seem straightforward when there is one of them quickly can become
unmanageable.  I'll admit, though, this is the sort of problem that is
best solved by rearchitecting the PHY code in tsec.c, which is, I
believe, under way by Ben.

In light of the fact that the #ifdefs here are feature-based, and that
the PHY code is probably changing soon, anyway, I'd be ok with letting
this patch through (with the duplicate #define removed, of course).

Andy



From vasiliy.leonenko at mail.ru  Tue Apr 29 16:39:43 2008
From: vasiliy.leonenko at mail.ru (Vasiliy Leoenenko)
Date: Tue, 29 Apr 2008 18:39:43 +0400
Subject: [U-Boot-Users] =?koi8-r?b?W1BBVENIXSBNMTggZmxhc2ggKFNpYmxleSkg?=
	=?koi8-r?b?c3VwcG9ydCAoYXR0ZW1wdCAyKQ==?=
In-Reply-To: <20080429134318.D801424681@gemini.denx.de>
References: <20080429134318.D801424681@gemini.denx.de>
Message-ID: <E1Jqqzf-000DSg-00.vasiliy-leonenko-mail-ru@f171.mail.ru>

Hi, Wolfgang

Sorry for codding-style issues in previous sent patches.
Next two messages will contain patches with corrected codding-style, descriptions and signed-off lines to commit.

Best regards
Vasiliy





From vasiliy.leonenko at mail.ru  Tue Apr 29 16:40:22 2008
From: vasiliy.leonenko at mail.ru (Vasiliy Leoenenko)
Date: Tue, 29 Apr 2008 18:40:22 +0400
Subject: [U-Boot-Users] =?koi8-r?b?W1BBVENIXSBNMTggZmxhc2ggKFNpYmxleSkg?=
	=?koi8-r?b?c3VwcG9ydCAoYXR0ZW1wdCAyKQ==?=
In-Reply-To: <20080429134318.D801424681@gemini.denx.de>
References: <20080429134318.D801424681@gemini.denx.de>
Message-ID: <E1Jqr0I-0007D5-00.vasiliy-leonenko-mail-ru@f156.mail.ru>

cfi_flash: enable M18 flash chips family support.

Added new command set ID. Buffered write command processing is changed in order to support M18 flash chips family.

Signed-off-by: Alexey Korolev <akorolev at infradead.org>
Signed-off-by: Vasiliy Leonenko <vasiliy.leonenko at mail.ru>
==============================================================
diff -aupNr a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
--- a/drivers/mtd/cfi_flash.c	2008-04-29 17:32:47.000000000 +0400
+++ b/drivers/mtd/cfi_flash.c	2008-04-29 17:32:59.000000000 +0400
@@ -76,7 +76,9 @@
 #define FLASH_CMD_PROTECT_SET		0x01
 #define FLASH_CMD_PROTECT_CLEAR		0xD0
 #define FLASH_CMD_CLEAR_STATUS		0x50
+#define FLASH_CMD_READ_STATUS		0x70
 #define FLASH_CMD_WRITE_TO_BUFFER	0xE8
+#define FLASH_CMD_WRITE_BUFFER_PROG	0xE9
 #define FLASH_CMD_WRITE_BUFFER_CONFIRM	0xD0
 
 #define FLASH_STATUS_DONE		0x80
@@ -136,6 +138,7 @@
 #define CFI_CMDSET_MITSU_STANDARD	256
 #define CFI_CMDSET_MITSU_EXTENDED	257
 #define CFI_CMDSET_SST			258
+#define CFI_CMDSET_INTEL_PROG_REGIONS	512
 
 #ifdef CFG_FLASH_CFI_AMD_RESET /* needed for STM_ID_29W320DB on UC100 */
 # undef  FLASH_CMD_RESET
@@ -620,6 +623,7 @@ static int flash_is_busy (flash_info_t *
 	int retval;
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
 		retval = !flash_isset (info, sect, 0, FLASH_STATUS_DONE);
@@ -679,6 +683,7 @@ static int flash_full_status_check (flas
 
 	retcode = flash_status_check (info, sector, tout, prompt);
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_EXTENDED:
 	case CFI_CMDSET_INTEL_STANDARD:
 		if ((retcode == ERR_OK)
@@ -807,6 +812,7 @@ static int flash_write_cfiword (flash_in
 	flag = disable_interrupts ();
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_EXTENDED:
 	case CFI_CMDSET_INTEL_STANDARD:
 		flash_write_cmd (info, 0, 0, FLASH_CMD_CLEAR_STATUS);
@@ -861,6 +867,7 @@ static int flash_write_cfibuffer (flash_
 	int flag = 0;
 	uint offset = 0;
 	unsigned int shift;
+	uchar write_cmd;
 
 	switch (info->portwidth) {
 	case FLASH_CFI_8BIT:
@@ -915,10 +922,14 @@ static int flash_write_cfibuffer (flash_
 	sector = find_sector (info, dest);
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
+		write_cmd = (info->vendor == CFI_CMDSET_INTEL_PROG_REGIONS) ? 
+					FLASH_CMD_WRITE_BUFFER_PROG : FLASH_CMD_WRITE_TO_BUFFER;
 		flash_write_cmd (info, sector, 0, FLASH_CMD_CLEAR_STATUS);
-		flash_write_cmd (info, sector, 0, FLASH_CMD_WRITE_TO_BUFFER);
+		flash_write_cmd (info, sector, 0, FLASH_CMD_READ_STATUS);
+		flash_write_cmd (info, sector, 0, write_cmd);
 		retcode = flash_status_check (info, sector,
 					      info->buffer_write_tout,
 					      "write to buffer");
@@ -1053,6 +1064,7 @@ int flash_erase (flash_info_t * info, in
 	for (sect = s_first; sect <= s_last; sect++) {
 		if (info->protect[sect] == 0) { /* not protected */
 			switch (info->vendor) {
+			case CFI_CMDSET_INTEL_PROG_REGIONS:
 			case CFI_CMDSET_INTEL_STANDARD:
 			case CFI_CMDSET_INTEL_EXTENDED:
 				flash_write_cmd (info, sect, 0,
@@ -1121,6 +1133,9 @@ void flash_print_info (flash_info_t * in
 			info->size >> 20, info->sector_count);
 	printf ("  ");
 	switch (info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
+			printf ("Intel Prog Regions");
+			break;
 		case CFI_CMDSET_INTEL_STANDARD:
 			printf ("Intel Standard");
 			break;
@@ -1511,6 +1526,7 @@ static void flash_read_jedec_ids (flash_
 	info->device_id2      = 0;
 
 	switch (info->vendor) {
+	case CFI_CMDSET_INTEL_PROG_REGIONS:
 	case CFI_CMDSET_INTEL_STANDARD:
 	case CFI_CMDSET_INTEL_EXTENDED:
 		cmdset_intel_read_jedec_ids(info);
@@ -1565,6 +1581,7 @@ static int flash_detect_legacy(ulong bas
 		}
 
 		switch(info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
 		case CFI_CMDSET_INTEL_STANDARD:
 		case CFI_CMDSET_INTEL_EXTENDED:
 			info->cmd_reset = FLASH_CMD_RESET;
@@ -1760,6 +1777,7 @@ ulong flash_get_size (ulong base, int ba
 #endif
 
 		switch (info->vendor) {
+		case CFI_CMDSET_INTEL_PROG_REGIONS:
 		case CFI_CMDSET_INTEL_STANDARD:
 		case CFI_CMDSET_INTEL_EXTENDED:
 			cmdset_intel_init(info, &qry);
@@ -1837,6 +1855,7 @@ ulong flash_get_size (ulong base, int ba
 				 * supported devices (intel...)
 				 */
 				switch (info->vendor) {
+				case CFI_CMDSET_INTEL_PROG_REGIONS:
 				case CFI_CMDSET_INTEL_EXTENDED:
 				case CFI_CMDSET_INTEL_STANDARD:
 					info->protect[sect_cnt] =






From vasiliy.leonenko at mail.ru  Tue Apr 29 16:40:06 2008
From: vasiliy.leonenko at mail.ru (Vasiliy Leoenenko)
Date: Tue, 29 Apr 2008 18:40:06 +0400
Subject: [U-Boot-Users] =?koi8-r?b?W1BBVENIXSBNMTggZmxhc2ggKFNpYmxleSkg?=
	=?koi8-r?b?c3VwcG9ydCAoYXR0ZW1wdCAyKQ==?=
In-Reply-To: <20080429134318.D801424681@gemini.denx.de>
References: <20080429134318.D801424681@gemini.denx.de>
Message-ID: <E1Jqr02-00064t-00.vasiliy-leonenko-mail-ru@f122.mail.ru>


cfi_flash: support of long cmd in U-boot.

Some NOR flash chips needs support of commands with length grether than max value size of uchar.
For example all M18 family chips use 0x1ff command in buffered write mode as value of program loops count.

Signed-off-by: Alexey Korolev <akorolev at infradead.org>
Signed-off-by: Vasiliy Leonenko <vasiliy.leonenko at mail.ru>
======================================================
diff -aupNr a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
--- a/drivers/mtd/cfi_flash.c	2008-04-21 02:39:38.000000000 +0400
+++ b/drivers/mtd/cfi_flash.c	2008-04-29 17:29:07.000000000 +0400
@@ -298,17 +298,32 @@ static inline void flash_unmap(flash_inf
 /*-----------------------------------------------------------------------
  * make a proper sized command based on the port and chip widths
  */
-static void flash_make_cmd (flash_info_t * info, uchar cmd, void *cmdbuf)
+static void flash_make_cmd (flash_info_t * info, ulong cmd, void *cmdbuf)
 {
 	int i;
+	int cword_offset;
+	int perchip_offset;
 	uchar *cp = (uchar *) cmdbuf;
+	uchar val;
 
 #if defined(__LITTLE_ENDIAN) || defined(CFG_WRITE_SWAPPED_DATA)
-	for (i = info->portwidth; i > 0; i--)
+	for (i = sizeof(cfiword_t); i > 0; i--){
+		cword_offset = i - 1;
 #else
-	for (i = 1; i <= info->portwidth; i++)
+	for (i = 1; i <= sizeof(cfiword_t); i++){
+		cword_offset = sizeof(cfiword_t) - i;
 #endif
-		*cp++ = (i & (info->chipwidth - 1)) ? '\0' : cmd;
+		perchip_offset = cword_offset % info->chipwidth;
+
+		/* If current offset inside one chip is over command size or 
+		   current offset is over portwidth fill data by 0x00 */
+		if(perchip_offset >= sizeof(ulong) || cword_offset >= info->portwidth)
+			val = 0x00;
+		else
+			val = *((uchar*)&cmd + perchip_offset);
+			
+		cp[i - 1] = val;		
+	}
 }
 
 #ifdef DEBUG
@@ -422,7 +437,7 @@ static ulong flash_read_long (flash_info
  * Write a proper sized command to the correct address
  */
 static void flash_write_cmd (flash_info_t * info, flash_sect_t sect,
-			     uint offset, uchar cmd)
+			     uint offset, ulong cmd)
 {
 
 	void *addr;
@@ -911,7 +926,7 @@ static int flash_write_cfibuffer (flash_
 			/* reduce the number of loops by the width of
 			 * the port */
 			cnt = len >> shift;
-			flash_write_cmd (info, sector, 0, (uchar) cnt - 1);
+			flash_write_cmd (info, sector, 0, cnt - 1);
 			while (cnt-- > 0) {
 				switch (info->portwidth) {
 				case FLASH_CFI_8BIT:







From biggerbadderben at gmail.com  Tue Apr 29 16:43:10 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Tue, 29 Apr 2008 07:43:10 -0700
Subject: [U-Boot-Users] [PATCH] net: add 16 bit support for smc911x
In-Reply-To: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>
References: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>
Message-ID: <481733FE.2070502@gmail.com>

Hi Jens,

Jens Gehrlein wrote:
> Hi Ben, Magnus,
>
> here is my patch to enable 2x16 bit accesses to the LAN9x1x.
> I still not have a HW, so may I ask you to test it and, if applicable,
> fix the code?
>
> Best Regards,
> Jens
>
> ---
>
>  drivers/net/smc911x.c |   17 ++++++++++++++++-
>  1 files changed, 16 insertions(+), 1 deletions(-)
>
>
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index d22c889..841a64d 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -30,6 +30,8 @@
>  #include <net.h>
>  #include <miiphy.h>
>  
> +#define CONFIG_DRIVER_SMC911X_16_BIT 1
> +
>  #ifdef CONFIG_DRIVER_SMC911X_32_BIT
>  static inline u32 reg_read(u32 addr)
>  {
> @@ -39,8 +41,21 @@ static inline void reg_write(u32 addr, u32 val)
>  {
>  	*(volatile u32*)addr = val;
>  }
> +#elif CONFIG_DRIVER_SMC911X_16_BIT
> +static inline u32 reg_read(u32 addr)
> +{
> +	u32 val_lo = (u32)(*(volatile u16*)addr);
> +	u32 val_hi = (u32)(*(volatile u16*)(addr | 2));
> +
>   
This won't work.  Presumably addr will already be a multiple of 2, so 
the bit-wise OR will make val_lo and val_hi identical.  Here's how I'd 
do it:

    volatile u16 *addr_16 = (u16 *)addr;
    return ((*addr_16 & 0x0000ffff) | (*(addr_16 + 1) << 16));

Of course, this could be done as a 1-liner with  castings, but it 
becomes even more unreadable that way.  The mask here might be 
unnecessary too.
> +	return (val_hi << 16) | val_lo;
> +}
> +static inline void reg_write(u32 addr, u32 val)
> +{
> +	*(volatile u16*)addr = (u16)val;
> +	*(volatile u16*)(addr | 2) = (u16)(val >> 16);
>   
Same problem here with the bitwise OR.  Second line should be:
    *(volatile u16*)(addr + 2) = (u16)(val >> 16);
> +}
>  #else
> -#error "SMC911X: Only 32-bit bus is supported"
> +#error "SMC911X: undefined buswidth"
>  #endif
>  
>  #define mdelay(n)       udelay((n)*1000)
>
>   
Thanks for doing this!  Hopefully Magnus will get a chance to try on 
real hardware and we can put this issue to rest.

regards,
Ben



From afleming at freescale.com  Tue Apr 29 16:44:50 2008
From: afleming at freescale.com (Andy Fleming)
Date: Tue, 29 Apr 2008 09:44:50 -0500
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
Message-ID: <1209480290-19438-1-git-send-email-afleming@freescale.com>

are available in the git repository at:

  git://www.denx.de/git/u-boot-mpc85xx.git master

Kumar Gala (1):
      85xx: Additional fixes and cleanup of MP code

 cpu/mpc85xx/mp.c      |    6 +++++-
 cpu/mpc85xx/release.S |    3 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)



From andre.schwarz at matrix-vision.de  Tue Apr 29 16:45:58 2008
From: andre.schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Tue, 29 Apr 2008 16:45:58 +0200
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
In-Reply-To: <2acbd3e40804290734l315c57fevd9ba1ddfc5445da8@mail.gmail.com>
References: <48109D11.9070508@matrix-vision.de>	
	<2acbd3e40804281421q642a20d2j9b3357472a499244@mail.gmail.com>	
	<4816C712.3000806@matrix-vision.de>
	<2acbd3e40804290734l315c57fevd9ba1ddfc5445da8@mail.gmail.com>
Message-ID: <481734A6.6060704@matrix-vision.de>

Andy,

it's no problem to re-send a "more suitable" patch as soon as Ben has 
finished the re-work. I'll wait for him and send an updated version to 
the list.


Cheers,
Andr?

Andy Fleming schrieb:
> On Tue, Apr 29, 2008 at 1:58 AM, Andre Schwarz
> <andre.schwarz at matrix-vision.de> wrote:
>> Andy,
>>
>>  thanks for your comments.
>>
>>
>>  Andy Fleming schrieb:
>>
>>> On Thu, Apr 24, 2008 at 9:45 AM, Andre Schwarz
>>  > <andre.schwarz at matrix-vision.de> wrote:
>>  >
>>  >
>>  >>  {MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
>>  >>  +#if defined(CFG_VSC8601_SKEW_TX) && defined(CFG_VSC8601_SKEW_RX)
>>  >>  +                {MIIM_EXT_PAGE_ACCESS,1,NULL},
>>  >>  +#define VSC8101_SKEW    (CFG_VSC8601_SKEW_TX<<14)|(CFG_VSC8601_SKEW_RX<<12)
>>  >>  +                {MIIM_VSC8601_SKEW_CTRL,VSC8101_SKEW,NULL},
>>  >>  +                {MIIM_EXT_PAGE_ACCESS,0,NULL},
>>  >>  +#endif
>>  >>   #endif
>>  >>
>>  >
>>  >
>>  > I'm not sure this is the best solution to this.  It seems like it
>>  > wouldn't scale well.  Either we need to set a bit somewhere that the
>>  > phy driver can read (and thereby determine how to configure the skew),
>>  > or we need to set the value to write in the board config file.  I'm
>>  > partial to the first solution, as it encapsulates the information
>>  > inside the code that deals with it.
>>  >
>>  > [...]
>>  >
>>  >
>>  I don't understand "scale well". What should be scalable ?
>>
>>  Of course using a function would be better.
>>  I silently assumed that the other bits are set to zero which is true
>>  after reset.
>>  There are only two other bits : Packet size and 10M preamble mode.
>>  Both should be left untouched, i.e. "0".
>>
> 
> 
> Sorry, I should have been more explicit.  In this case I'm referring
> to how well the solution scales as we deal with more configuration
> options.  Your solution isn't a terrible example of this, but #ifdefs
> that seem straightforward when there is one of them quickly can become
> unmanageable.  I'll admit, though, this is the sort of problem that is
> best solved by rearchitecting the PHY code in tsec.c, which is, I
> believe, under way by Ben.
> 
> In light of the fact that the #ifdefs here are feature-based, and that
> the PHY code is probably changing soon, anyway, I'd be ok with letting
> this patch through (with the duplicate #define removed, of course).
> 
> Andy


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From wd at denx.de  Tue Apr 29 16:59:44 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 16:59:44 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
In-Reply-To: Your message of "Tue, 29 Apr 2008 09:44:50 CDT."
	<1209480290-19438-1-git-send-email-afleming@freescale.com>
Message-ID: <20080429145944.DFD6C247B4@gemini.denx.de>

In message <1209480290-19438-1-git-send-email-afleming at freescale.com> you wrote:
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc85xx.git master
> 
> Kumar Gala (1):
>       85xx: Additional fixes and cleanup of MP code
> 
>  cpu/mpc85xx/mp.c      |    6 +++++-
>  cpu/mpc85xx/release.S |    3 ++-
>  2 files changed, 7 insertions(+), 2 deletions(-)

Done. 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: wd at denx.de
Sex is like air.  It's only a big deal if you can't get any.



From lilja.magnus at gmail.com  Tue Apr 29 16:59:25 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Tue, 29 Apr 2008 16:59:25 +0200
Subject: [U-Boot-Users] [PATCH] net: add 16 bit support for smc911x
In-Reply-To: <481733FE.2070502@gmail.com>
References: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>
	<481733FE.2070502@gmail.com>
Message-ID: <59b21cf20804290759ic399c82qc16aa3888c2e7b6c@mail.gmail.com>

>  Thanks for doing this!  Hopefully Magnus will get a chance to try on
>  real hardware and we can put this issue to rest.


I'll try it later this week, definitely not today though.


/Magnus



From agust at denx.de  Tue Apr 29 17:03:48 2008
From: agust at denx.de (Anatolij Gustschin)
Date: Tue, 29 Apr 2008 17:03:48 +0200
Subject: [U-Boot-Users] [PATCH] M18 flash (Sibley) support (attempt 2)
In-Reply-To: <E1Jqr02-00064t-00.vasiliy-leonenko-mail-ru@f122.mail.ru>
References: <20080429134318.D801424681@gemini.denx.de>
	<E1Jqr02-00064t-00.vasiliy-leonenko-mail-ru@f122.mail.ru>
Message-ID: <481738D4.7090207@denx.de>

Hi Vasiliy,

Vasiliy Leoenenko wrote:
> cfi_flash: support of long cmd in U-boot.
> 
> Some NOR flash chips needs support of commands with length grether than max value size of uchar.
> For example all M18 family chips use 0x1ff command in buffered write mode as value of program loops count.

Unfortunately this patch still breaks CFI support on sequoia board:

U-Boot 1.3.3-rc1-00021-g0e715a7-dirty (Apr 29 2008 - 16:55:18)

CPU:   AMCC PowerPC 440EPx Rev. A at 330 MHz (PLB=132, OPB=66, EBC=66 MHz)
       Security/Kasumi support
       Bootstrap Option B - Boot ROM Location EBC (16 bits)
       Internal PCI arbiter enabled, PCI async ext clock used
       32 kB I-Cache 32 kB D-Cache
Board: Sequoia - AMCC PPC440EPx Evaluation Board, Rev. F, PCI=33 MHz
I2C:   ready
DTT:   1 is 36 C
DRAM:  256 MB
FLASH: CFI: Unknown command set 0x0
*** failed ***
### ERROR ### Please RESET the board ###


Best regards,
Anatolij

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



From zhukov at tst.spb.su  Tue Apr 29 17:16:33 2008
From: zhukov at tst.spb.su (Zhukov)
Date: Tue, 29 Apr 2008 19:16:33 +0400
Subject: [U-Boot-Users] --- <md 40000000> command for at91rm9200
Message-ID: <1709339937.20080429191633@tst.spb.su>

Hello people,

Does anybody know what should happen on "md 30000000" or "md 30000000"
in at91rm9200? Should it hangs, or show random values or show the same as
"md 20000000"? (We hang).

-- 
Best regards,
Andrew




From galak at kernel.crashing.org  Tue Apr 29 17:18:34 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 29 Apr 2008 10:18:34 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] Update .gitignore for zlib.h
Message-ID: <Pine.LNX.4.64.0804291018180.16447@blarg.am.freescale.net>

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
 tools/.gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/.gitignore b/tools/.gitignore
index 979f2da..df3500d 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -15,3 +15,4 @@
 /fdt_strerror.c
 /fdt_wip.c
 /libfdt_internal.h
+/zlib.h
-- 
1.5.4.1




From wd at denx.de  Tue Apr 29 17:25:30 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 17:25:30 +0200
Subject: [U-Boot-Users] MPC8610HPCD build warnings
Message-ID: <20080429152530.6A726247B4@gemini.denx.de>

To whom it may concern...

...the MPC8610HPCD board is throwing a couple of warnings for net.c -
note that this is the only (PowerPC) board  that  does  this,  so  it
seems to be some special feature of this board:

Configuring for MPC8610HPCD board...
net.c: In function 'PingHandler':
net.c:770: warning: passing argument 1 of 'NetReadIP' discards qualifiers from pointer target type
net.c: In function 'NetSetIP':
net.c:1694: warning: passing argument 1 of 'NetCopyIP' discards qualifiers from pointer target type
net.c:1695: warning: passing argument 1 of 'NetCopyIP' discards qualifiers from pointer target type
net.c: In function 'PingSend':
net.c:736: warning: passing argument 1 of 'NetCopyIP' discards qualifiers from pointer target type
net.c:737: warning: passing argument 1 of 'NetCopyIP' discards qualifiers from pointer target type


Unfortunately the board is not even listed in the  MAINTAINERS  file,
so I don't know who should take care of this...

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: wd at denx.de
A wise person makes his  own  decisions,  a  weak  one  obeys  public
opinion.                                           -- Chinese proverb



From galak at kernel.crashing.org  Tue Apr 29 17:28:34 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 29 Apr 2008 10:28:34 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx/86xx: Rename DDR init address and init
 extended address register
Message-ID: <Pine.LNX.4.64.0804291027120.25109@blarg.am.freescale.net>

Rename init_addr and init_ext_addr to match the docs between
85xx and 86xx.  Both now use 'init_addr' and 'init_ext_addr'.

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

Can you guys ack and decide who will actually apply this.

- k

 include/asm-ppc/immap_85xx.h |    4 ++--
 include/asm-ppc/immap_86xx.h |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/immap_85xx.h
index 813be5f..2d07625 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -106,8 +106,8 @@ typedef struct ccsr_ddr {
 	char	res6[4];
 	uint	sdram_clk_cntl;		/* 0x2130 - DDR SDRAM Clock Control */
 	char	res7[20];
-	uint	init_address;		/* 0x2148 - DDR training initialization address */
-	uint	init_ext_address;	/* 0x214C - DDR training initialization extended address */
+	uint	init_addr;		/* 0x2148 - DDR training initialization address */
+	uint	init_ext_addr;		/* 0x214C - DDR training initialization extended address */
 	char	res8_1[16];
 	uint	timing_cfg_4;		/* 0x2160 - DDR SDRAM Timing Configuration Register 4 */
 	uint	timing_cfg_5;		/* 0x2164 - DDR SDRAM Timing Configuration Register 5 */
diff --git a/include/asm-ppc/immap_86xx.h b/include/asm-ppc/immap_86xx.h
index fd4aa54..0b78c94 100644
--- a/include/asm-ppc/immap_86xx.h
+++ b/include/asm-ppc/immap_86xx.h
@@ -126,7 +126,7 @@ typedef struct ccsr_ddr {
 	uint    sdram_ocd_cntl;		/* 0x2140 - DDR SDRAM OCD Control */
 	uint    sdram_ocd_status;	/* 0x2144 - DDR SDRAM OCD Status */
 	uint    init_addr;		/* 0x2148 - DDR training initialzation address */
-	uint    init_addr_ext;		/* 0x214C - DDR training initialzation extended address */
+	uint    init_ext_addr;		/* 0x214C - DDR training initialzation extended address */
 	char    res10[2728];
 	uint    ip_rev1;		/* 0x2BF8 - DDR IP Block Revision 1 */
 	uint    ip_rev2;		/* 0x2BFC - DDR IP Block Revision 2 */
-- 
1.5.4.1




From galak at kernel.crashing.org  Tue Apr 29 17:27:08 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 29 Apr 2008 10:27:08 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx/86xx: Rename ext_refrec to timing_cfg_3
	to match docs
Message-ID: <Pine.LNX.4.64.0804291026080.25109@blarg.am.freescale.net>

All the 85xx and 86xx UM describe the register as timing_cfg_3
not as ext_refrec.

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---

Can you guys ack and decide who will actually apply this.

- k

 board/freescale/mpc8610hpcd/mpc8610hpcd.c |    2 +-
 board/freescale/mpc8641hpcn/mpc8641hpcn.c |    2 +-
 board/sbc8548/sbc8548.c                   |    2 +-
 board/sbc8641d/sbc8641d.c                 |    4 ++--
 cpu/mpc85xx/spd_sdram.c                   |    4 ++--
 cpu/mpc86xx/spd_sdram.c                   |    4 ++--
 include/asm-ppc/immap_85xx.h              |    2 +-
 include/asm-ppc/immap_86xx.h              |    2 +-
 include/configs/MPC8610HPCD.h             |    2 +-
 include/configs/sbc8641d.h                |    2 +-
 10 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd.c b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
index d9a740e..3a855b5 100644
--- a/board/freescale/mpc8610hpcd/mpc8610hpcd.c
+++ b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
@@ -192,7 +192,7 @@ long int fixed_sdram(void)
 	ddr->cs0_bnds = 0x0000001f;
 	ddr->cs0_config = 0x80010202;

-	ddr->ext_refrec = 0x00000000;
+	ddr->timing_cfg_3 = 0x00000000;
 	ddr->timing_cfg_0 = 0x00260802;
 	ddr->timing_cfg_1 = 0x3935d322;
 	ddr->timing_cfg_2 = 0x14904cc8;
diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
index 31e7d67..bb1f927 100644
--- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c
+++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c
@@ -130,7 +130,7 @@ fixed_sdram(void)

 	ddr->cs0_bnds = CFG_DDR_CS0_BNDS;
 	ddr->cs0_config = CFG_DDR_CS0_CONFIG;
-	ddr->ext_refrec = CFG_DDR_EXT_REFRESH;
+	ddr->timing_cfg_3 = CFG_DDR_TIMING_3;
 	ddr->timing_cfg_0 = CFG_DDR_TIMING_0;
 	ddr->timing_cfg_1 = CFG_DDR_TIMING_1;
 	ddr->timing_cfg_2 = CFG_DDR_TIMING_2;
diff --git a/board/sbc8548/sbc8548.c b/board/sbc8548/sbc8548.c
index 8a6ced3..46496da 100644
--- a/board/sbc8548/sbc8548.c
+++ b/board/sbc8548/sbc8548.c
@@ -299,7 +299,7 @@ long int fixed_sdram (void)
 	ddr->cs1_config		= 0x80010101;
 	ddr->cs2_config		= 0x00000000;
 	ddr->cs3_config		= 0x00000000;
-	ddr->ext_refrec		= 0x00000000;
+	ddr->timing_cfg_3		= 0x00000000;
 	ddr->timing_cfg_0	= 0x00220802;
 	ddr->timing_cfg_1	= 0x38377322;
 	ddr->timing_cfg_2	= 0x0fa044C7;
diff --git a/board/sbc8641d/sbc8641d.c b/board/sbc8641d/sbc8641d.c
index b3dd9c8..519f332 100644
--- a/board/sbc8641d/sbc8641d.c
+++ b/board/sbc8641d/sbc8641d.c
@@ -135,7 +135,7 @@ long int fixed_sdram (void)
 	ddr->cs1_config = CFG_DDR_CS1_CONFIG;
 	ddr->cs2_config = CFG_DDR_CS2_CONFIG;
 	ddr->cs3_config = CFG_DDR_CS3_CONFIG;
-	ddr->ext_refrec = CFG_DDR_EXT_REFRESH;
+	ddr->timing_cfg_3 = CFG_DDR_TIMING_3;
 	ddr->timing_cfg_0 = CFG_DDR_TIMING_0;
 	ddr->timing_cfg_1 = CFG_DDR_TIMING_1;
 	ddr->timing_cfg_2 = CFG_DDR_TIMING_2;
@@ -166,7 +166,7 @@ long int fixed_sdram (void)
 	ddr->cs1_config = CFG_DDR2_CS1_CONFIG;
 	ddr->cs2_config = CFG_DDR2_CS2_CONFIG;
 	ddr->cs3_config = CFG_DDR2_CS3_CONFIG;
-	ddr->ext_refrec = CFG_DDR2_EXT_REFRESH;
+	ddr->timing_cfg_3 = CFG_DDR2_EXT_REFRESH;
 	ddr->timing_cfg_0 = CFG_DDR2_TIMING_0;
 	ddr->timing_cfg_1 = CFG_DDR2_TIMING_1;
 	ddr->timing_cfg_2 = CFG_DDR2_TIMING_2;
diff --git a/cpu/mpc85xx/spd_sdram.c b/cpu/mpc85xx/spd_sdram.c
index 435458a..e3a8249 100644
--- a/cpu/mpc85xx/spd_sdram.c
+++ b/cpu/mpc85xx/spd_sdram.c
@@ -610,8 +610,8 @@ spd_sdram(void)
 	/*
 	 * Sneak in some Extended Refresh Recovery.
 	 */
-	ddr->ext_refrec = (trfc_high << 16);
-	debug("DDR: ext_refrec = 0x%08x\n", ddr->ext_refrec);
+	ddr->timing_cfg_3 = (trfc_high << 16);
+	debug("DDR: timing_cfg_3 = 0x%08x\n", ddr->timing_cfg_3);

 	ddr->timing_cfg_1 =
 	    (0
diff --git a/cpu/mpc86xx/spd_sdram.c b/cpu/mpc86xx/spd_sdram.c
index 60a7818..8485841 100644
--- a/cpu/mpc86xx/spd_sdram.c
+++ b/cpu/mpc86xx/spd_sdram.c
@@ -644,8 +644,8 @@ spd_init(unsigned char i2c_address, unsigned int ddr_num,
 	/*
 	 * Sneak in some Extended Refresh Recovery.
 	 */
-	ddr->ext_refrec = (trfc_high << 16);
-	debug("DDR: ext_refrec = 0x%08x\n", ddr->ext_refrec);
+	ddr->timing_cfg_3 = (trfc_high << 16);
+	debug("DDR: timing_cfg_3 = 0x%08x\n", ddr->timing_cfg_3);

 	ddr->timing_cfg_1 =
 	    (0
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/immap_85xx.h
index dc6e278..813be5f 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -92,7 +92,7 @@ typedef struct ccsr_ddr {
 	uint	cs2_config_2;		/* 0x20c8 - DDR Chip Select Configuration 2 */
 	uint	cs3_config_2;		/* 0x20cc - DDR Chip Select Configuration 2 */
 	char	res5[48];
-	uint	ext_refrec;		/* 0x2100 - DDR SDRAM Extended Refresh Recovery */
+	uint	timing_cfg_3;		/* 0x2100 - DDR SDRAM Timing Configuration Register 3 */
 	uint	timing_cfg_0;		/* 0x2104 - DDR SDRAM Timing Configuration Register 0 */
 	uint	timing_cfg_1;		/* 0x2108 - DDR SDRAM Timing Configuration Register 1 */
 	uint	timing_cfg_2;		/* 0x210c - DDR SDRAM Timing Configuration Register 2 */
diff --git a/include/asm-ppc/immap_86xx.h b/include/asm-ppc/immap_86xx.h
index 7526061..fd4aa54 100644
--- a/include/asm-ppc/immap_86xx.h
+++ b/include/asm-ppc/immap_86xx.h
@@ -109,7 +109,7 @@ typedef struct ccsr_ddr {
 	uint	cs4_config;		/* 0x2090 - DDR Chip Select Configuration */
 	uint	cs5_config;		/* 0x2094 - DDR Chip Select Configuration */
 	char	res7[104];
-	uint    ext_refrec;             /* 0x2100 - DDR SDRAM extended refresh recovery */
+	uint	timing_cfg_3;		/* 0x2100 - DDR SDRAM Timing Configuration Register 3 */
 	uint	timing_cfg_0;		/* 0x2104 - DDR SDRAM Timing Configuration Register 0 */
 	uint	timing_cfg_1;		/* 0x2108 - DDR SDRAM Timing Configuration Register 1 */
 	uint	timing_cfg_2;		/* 0x210c - DDR SDRAM Timing Configuration Register 2 */
diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h
index 9e70198..585411c 100644
--- a/include/configs/MPC8610HPCD.h
+++ b/include/configs/MPC8610HPCD.h
@@ -114,7 +114,7 @@
 #if 0 /* TODO */
 #define CFG_DDR_CS0_BNDS	0x0000000F
 #define CFG_DDR_CS0_CONFIG	0x80010202	/* Enable, no interleaving */
-#define CFG_DDR_EXT_REFRESH	0x00000000
+#define CFG_DDR_TIMING_3	0x00000000
 #define CFG_DDR_TIMING_0	0x00260802
 #define CFG_DDR_TIMING_1	0x3935d322
 #define CFG_DDR_TIMING_2	0x14904cc8
diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h
index 18cedff..20da73e 100644
--- a/include/configs/sbc8641d.h
+++ b/include/configs/sbc8641d.h
@@ -136,7 +136,7 @@
     #define CFG_DDR_CS1_CONFIG	0x00000000
     #define CFG_DDR_CS2_CONFIG	0x00000000
     #define CFG_DDR_CS3_CONFIG	0x00000000
-    #define CFG_DDR_EXT_REFRESH 0x00000000
+    #define CFG_DDR_TIMING_3 0x00000000
     #define CFG_DDR_TIMING_0	0x00220802
     #define CFG_DDR_TIMING_1	0x38377322
     #define CFG_DDR_TIMING_2	0x002040c7
-- 
1.5.4.1




From jdl at freescale.com  Tue Apr 29 17:45:14 2008
From: jdl at freescale.com (Jon Loeliger)
Date: Tue, 29 Apr 2008 10:45:14 -0500
Subject: [U-Boot-Users] [PATCH] 85xx/86xx: Rename ext_refrec to
 timing_cfg_3 to match docs
In-Reply-To: <Pine.LNX.4.64.0804291026080.25109@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804291026080.25109@blarg.am.freescale.net>
Message-ID: <4817428A.7040806@freescale.com>

Kumar Gala wrote:
> All the 85xx and 86xx UM describe the register as timing_cfg_3
> not as ext_refrec.
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
> 
> Can you guys ack and decide who will actually apply this.
> 
> - k
> 
>  board/freescale/mpc8610hpcd/mpc8610hpcd.c |    2 +-
>  board/freescale/mpc8641hpcn/mpc8641hpcn.c |    2 +-
>  board/sbc8548/sbc8548.c                   |    2 +-
>  board/sbc8641d/sbc8641d.c                 |    4 ++--
>  cpu/mpc85xx/spd_sdram.c                   |    4 ++--
>  cpu/mpc86xx/spd_sdram.c                   |    4 ++--
>  include/asm-ppc/immap_85xx.h              |    2 +-
>  include/asm-ppc/immap_86xx.h              |    2 +-
>  include/configs/MPC8610HPCD.h             |    2 +-
>  include/configs/sbc8641d.h                |    2 +-
>  10 files changed, 13 insertions(+), 13 deletions(-)
> 

Ack.  Andy, Please pick this up!

Thanks,
jdl



From jdl at freescale.com  Tue Apr 29 17:46:04 2008
From: jdl at freescale.com (Jon Loeliger)
Date: Tue, 29 Apr 2008 10:46:04 -0500
Subject: [U-Boot-Users] [PATCH] 85xx/86xx: Rename DDR init address and
 init extended address register
In-Reply-To: <Pine.LNX.4.64.0804291027120.25109@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804291027120.25109@blarg.am.freescale.net>
Message-ID: <481742BC.9040901@freescale.com>

Kumar Gala wrote:
> Rename init_addr and init_ext_addr to match the docs between
> 85xx and 86xx.  Both now use 'init_addr' and 'init_ext_addr'.
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
> 
> Can you guys ack and decide who will actually apply this.
> 
> - k
> 
>  include/asm-ppc/immap_85xx.h |    4 ++--
>  include/asm-ppc/immap_86xx.h |    2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 

Ack.

Andy, you've got me two-to-one on this,
so if you would, please pick this up!

Thanks,
jdl



From afleming at freescale.com  Tue Apr 29 18:48:57 2008
From: afleming at freescale.com (Andy Fleming)
Date: Tue, 29 Apr 2008 11:48:57 -0500
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
Message-ID: <1209487737-20612-1-git-send-email-afleming@freescale.com>

are available in the git repository at:

  git://www.denx.de/git/u-boot-mpc85xx.git master

Kumar Gala (3):
      85xx: Additional fixes and cleanup of MP code
      85xx/86xx: Rename DDR init address and init extended address register
      85xx/86xx: Rename ext_refrec to timing_cfg_3 to match docs

You've already got the MP one, but the other two were just submitted.

 board/freescale/mpc8610hpcd/mpc8610hpcd.c |    2 +-
 board/freescale/mpc8641hpcn/mpc8641hpcn.c |    2 +-
 board/sbc8548/sbc8548.c                   |    2 +-
 board/sbc8641d/sbc8641d.c                 |    4 ++--
 cpu/mpc85xx/mp.c                          |    6 +++++-
 cpu/mpc85xx/release.S                     |    3 ++-
 cpu/mpc85xx/spd_sdram.c                   |    4 ++--
 cpu/mpc86xx/spd_sdram.c                   |    4 ++--
 include/asm-ppc/immap_85xx.h              |    6 +++---
 include/asm-ppc/immap_86xx.h              |    4 ++--
 include/configs/MPC8610HPCD.h             |    2 +-
 include/configs/sbc8641d.h                |    2 +-
 12 files changed, 23 insertions(+), 18 deletions(-)



From codehero at gmail.com  Tue Apr 29 18:57:06 2008
From: codehero at gmail.com (Dave Bender)
Date: Tue, 29 Apr 2008 16:57:06 +0000 (UTC)
Subject: [U-Boot-Users] AT91SAM9260 + DP83848 phy
Message-ID: <loom.20080429T165256-27@post.gmane.org>

Dear list,
  I am currently working on a custom board, trying to get the National DP83848
Phy to work properly with the AT91SAM9260 in u-boot 1.2.0; Everything goes fine
(reset is ok, can read phy id) until I read the link status bit. The link status
bit is never set, so I never get a good connection.

I have tried the following:

-Bit banged the MDIO directly to the via the parallel port as per National's
suggestion. The link status bit went high in this case, so I do not believe
there are any wiring faults in our board.

Does anybody know of a u-boot driver for the phy with the AT91SAM9260? Has
anyone had any success with this combination?

Thanks,

Dave




From skuribay at ruby.dti.ne.jp  Tue Apr 29 19:02:54 2008
From: skuribay at ruby.dti.ne.jp (Shinya Kuribayashi)
Date: Wed, 30 Apr 2008 02:02:54 +0900
Subject: [U-Boot-Users] [PATCH] Update .gitignore for zlib.h
In-Reply-To: <Pine.LNX.4.64.0804291018180.16447@blarg.am.freescale.net>
References: <Pine.LNX.4.64.0804291018180.16447@blarg.am.freescale.net>
Message-ID: <481754BE.3090102@ruby.dti.ne.jp>

Kumar Gala wrote:
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
>  tools/.gitignore |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Acked-by: Shinya Kuribayashi <skuribay at ruby.dti.ne.jp>




From biggerbadderben at gmail.com  Tue Apr 29 19:04:18 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Tue, 29 Apr 2008 10:04:18 -0700
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
In-Reply-To: <481734A6.6060704@matrix-vision.de>
References: <48109D11.9070508@matrix-vision.de>		<2acbd3e40804281421q642a20d2j9b3357472a499244@mail.gmail.com>		<4816C712.3000806@matrix-vision.de>	<2acbd3e40804290734l315c57fevd9ba1ddfc5445da8@mail.gmail.com>
	<481734A6.6060704@matrix-vision.de>
Message-ID: <48175512.8000207@gmail.com>

Andr? Schwarz wrote:
> Andy,
>
> it's no problem to re-send a "more suitable" patch as soon as Ben has 
> finished the re-work. I'll wait for him and send an updated version to 
> the list.
>
>
>   
It's better to get this in now if you don't mind.

regards,
Ben



From codehero at gmail.com  Tue Apr 29 19:10:19 2008
From: codehero at gmail.com (Dave Bender)
Date: Tue, 29 Apr 2008 17:10:19 +0000 (UTC)
Subject: [U-Boot-Users] AT91SAM9260 + DP83848 phy
Message-ID: <loom.20080429T170952-934@post.gmane.org>

  Dear list,
  I am currently working on a custom board, trying to get the National DP83848
Phy to work properly with the AT91SAM9260 in u-boot 1.2.0; Everything goes fine
(reset is ok, can read phy id) until I read the link status bit. The link status
bit is never set, so I never get a good connection.

I have tried the following:

-Bit banged the MDIO directly to the via the parallel port as per National's
suggestion. The link status bit went high in this case, so I do not believe
there are any wiring faults in our board.

Does anybody know of a u-boot driver for the phy with the AT91SAM9260? Has
anyone had any success with this combination?

Thanks,

Dave




From sr at denx.de  Tue Apr 29 19:14:08 2008
From: sr at denx.de (Stefan Roese)
Date: Tue, 29 Apr 2008 19:14:08 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
Message-ID: <200804291914.09012.sr@denx.de>

The following changes since commit dd5748bcd669f46aeb6686c1b341323843738ccc:
  Guennadi Liakhovetski (1):
        rtl8169: fix compiler warnings

are available in the git repository at:

  git://www.denx.de/git/u-boot-ppc4xx.git master

Markus Brunner (1):
      ppc4xx: Fixup ebc clock in FDT for 405GP/EP

Stefan Roese (5):
      ppc4xx: Change ECC initialization on lwmon5 to use clean_dcache_range()
      ppc4xx: Complete remove bogus dflush()
      ppc4xx: Fix Katmai CFG_MONITOR_LEN
      ppc4xx: Fix compilation warning in denali_spd_ddr2.c
      ppc4xx: Fix CFG_MONITOR_LEN on Katmai failsave this time

 board/lwmon5/sdram.c         |   13 ++++++++++---
 board/netstal/hcu5/sdram.c   |    6 +++---
 cpu/ppc4xx/44x_spd_ddr2.c    |    5 +++--
 cpu/ppc4xx/denali_spd_ddr2.c |    5 +++--
 cpu/ppc4xx/fdt.c             |   10 ++++++++--
 cpu/ppc4xx/start.S           |   29 -----------------------------
 include/configs/katmai.h     |    8 ++++----
 7 files changed, 31 insertions(+), 45 deletions(-)



From andre.schwarz at matrix-vision.de  Tue Apr 29 19:16:28 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Tue, 29 Apr 2008 19:16:28 +0200
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
In-Reply-To: <48175512.8000207@gmail.com>
References: <48109D11.9070508@matrix-vision.de>		<2acbd3e40804281421q642a20d2j9b3357472a499244@mail.gmail.com>		<4816C712.3000806@matrix-vision.de>	<2acbd3e40804290734l315c57fevd9ba1ddfc5445da8@mail.gmail.com>
	<481734A6.6060704@matrix-vision.de> <48175512.8000207@gmail.com>
Message-ID: <481757EC.8080008@matrix-vision.de>

Ben Warren schrieb:
> Andr? Schwarz wrote:
>> Andy,
>>
>> it's no problem to re-send a "more suitable" patch as soon as Ben has
>> finished the re-work. I'll wait for him and send an updated version
>> to the list.
>>
>>
>>   
> It's better to get this in now if you don't mind.
>
> regards,
> Ben
I don't mind and will send it a a new patch.


Cheers,
Andre

MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From andre.schwarz at matrix-vision.de  Tue Apr 29 19:18:32 2008
From: andre.schwarz at matrix-vision.de (Andre Schwarz)
Date: Tue, 29 Apr 2008 19:18:32 +0200
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY -
	2nd try
Message-ID: <48175868.5090501@matrix-vision.de>

The Vitesse VSC8601 RGMII PHY has internal delay for both Rx
and Tx clock lines. They are configured using 2 bits in extended
register 0x17.
Therefore CFG_VSC8601_SKEW_TX and CFG_VSC8601_SKEW_RX have
been introduced with valid values 0-3 giving 0.0, 1.4,1.7 and 2.0ns delay.

Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>
--



 drivers/net/tsec.c |    6 ++++++
 drivers/net/tsec.h |    3 +++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 9d22aa3..06250ae 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -1277,6 +1277,12 @@ struct phy_info phy_info_VSC8601 = {
                 {MIIM_CONTROL, MIIM_CONTROL_INIT, &mii_cr_init},
 #ifdef CFG_VSC8601_SKEWFIX
               
 {MIIM_VSC8601_EPHY_CON,MIIM_VSC8601_EPHY_CON_INIT_SKEW,NULL},
+#if defined(CFG_VSC8601_SKEW_TX) && defined(CFG_VSC8601_SKEW_RX)
+                {MIIM_EXT_PAGE_ACCESS,1,NULL},
+#define VSC8101_SKEW    (CFG_VSC8601_SKEW_TX<<14)|(CFG_VSC8601_SKEW_RX<<12)
+                {MIIM_VSC8601_SKEW_CTRL,VSC8101_SKEW,NULL},
+                {MIIM_EXT_PAGE_ACCESS,0,NULL},
+#endif
 #endif
                 {miim_end,}
                  },
diff --git a/drivers/net/tsec.h b/drivers/net/tsec.h
index cfa7d1a..213a809 100644
--- a/drivers/net/tsec.h
+++ b/drivers/net/tsec.h
@@ -112,6 +112,8 @@
 #define MIIM_GBIT_CONTROL    0x9
 #define MIIM_GBIT_CONTROL_INIT    0xe00
 
+#define MIIM_EXT_PAGE_ACCESS    0x1f
+
 /* Broadcom BCM54xx -- taken from linux sungem_phy */
 #define MIIM_BCM54xx_AUXSTATUS            0x19
 #define MIIM_BCM54xx_AUXSTATUS_LINKMODE_MASK    0x0700
@@ -163,6 +165,7 @@
 /* Vitesse VSC8601 Extended PHY Control Register 1 */
 #define MIIM_VSC8601_EPHY_CON            0x17
 #define MIIM_VSC8601_EPHY_CON_INIT_SKEW    0x1120
+#define MIIM_VSC8601_SKEW_CTRL        0x1c
 
 /* 88E1011 PHY Status Register */
 #define MIIM_88E1011_PHY_STATUS         0x11


MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From biggerbadderben at gmail.com  Tue Apr 29 19:23:15 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Tue, 29 Apr 2008 10:23:15 -0700
Subject: [U-Boot-Users] [PATCH] net: add 16 bit support for smc911x
In-Reply-To: <59b21cf20804290759ic399c82qc16aa3888c2e7b6c@mail.gmail.com>
References: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>	
	<481733FE.2070502@gmail.com>
	<59b21cf20804290759ic399c82qc16aa3888c2e7b6c@mail.gmail.com>
Message-ID: <48175983.6040307@gmail.com>

Magnus Lilja wrote:
>>  Thanks for doing this!  Hopefully Magnus will get a chance to try on
>>  real hardware and we can put this issue to rest.
>>     
>
>
> I'll try it later this week, definitely not today though.
>
>
> /Magnus
>
>   
Cool!  Thanks Magnus.

regards,
Ben



From ceggers at gmx.de  Tue Apr 29 19:37:40 2008
From: ceggers at gmx.de (Christian Eggers)
Date: Tue, 29 Apr 2008 19:37:40 +0200
Subject: [U-Boot-Users] Setting processor endianess for USB modules
Message-ID: <48177904.16185.58C770@ceggers.gmx.de>

Hello,

I've recognized that a lot of USB code in U-Boot uses the macros
swap_16() and swap_32() which are defined in usb.h. The behaviour
of the macros is controlled by the define LITTLEENDIAN.

Is there a good reason NOT to use the macros provided in
asm/byteorder.h (as in the appropriate code in Linux-2.4 )? 

I think that switching to these functions might be useful in order
to eliminate the need to use the LITTLEENDIAN define for
specifying the byteorder. It seems that LITTLEENDIAN is not
used outside the USB code.

regards

Christian Eggers




From galak at kernel.crashing.org  Tue Apr 29 19:54:59 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Tue, 29 Apr 2008 12:54:59 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] 85xx: Add -mno-spe to e500/85xx builds
Message-ID: <Pine.LNX.4.64.0804291254420.31384@blarg.am.freescale.net>

Newer gcc's might be configured to enable autovectorization by default.
If we happen to build with one of those compilers we will get SPE
instructions in random code.

-mno-spe disables the compiler for automatically generating SPE
instructions without our knowledge.

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
 cpu/mpc85xx/config.mk |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/cpu/mpc85xx/config.mk b/cpu/mpc85xx/config.mk
index f6df702..9e574a2 100644
--- a/cpu/mpc85xx/config.mk
+++ b/cpu/mpc85xx/config.mk
@@ -25,3 +25,4 @@ PLATFORM_RELFLAGS += -fPIC -ffixed-r14 -meabi

 PLATFORM_CPPFLAGS += -DCONFIG_MPC85xx -DCONFIG_E500 -ffixed-r2 \
 			-Wa,-me500 -msoft-float -mno-string
+PLATFORM_CPPFLAGS +=$(call cc-option,-mno-spe)
-- 
1.5.4.1




From wd at denx.de  Tue Apr 29 20:01:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 20:01:50 +0200
Subject: [U-Boot-Users] --- <md 40000000> command for at91rm9200
In-Reply-To: Your message of "Tue, 29 Apr 2008 19:16:33 +0400."
	<1709339937.20080429191633@tst.spb.su>
Message-ID: <20080429180150.12674247B4@gemini.denx.de>

In message <1709339937.20080429191633 at tst.spb.su> you wrote:
> 
> Does anybody know what should happen on "md 30000000" or "md 30000000"
> in at91rm9200? Should it hangs, or show random values or show the same as
> "md 20000000"? (We hang).

This obviously depends on your memory map. Nobody can help you
without knowing exactly which hardware you are using and how you
configured it.

Best regards,

Wolfgang Denk

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



From wd at denx.de  Tue Apr 29 20:03:09 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 20:03:09 +0200
Subject: [U-Boot-Users] [PATCH] Update .gitignore for zlib.h
In-Reply-To: Your message of "Tue, 29 Apr 2008 10:18:34 CDT."
	<Pine.LNX.4.64.0804291018180.16447@blarg.am.freescale.net>
Message-ID: <20080429180309.41118247B4@gemini.denx.de>

In message <Pine.LNX.4.64.0804291018180.16447 at blarg.am.freescale.net> you wrote:
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
>  tools/.gitignore |    1 +
>  1 files changed, 1 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: wd at denx.de
"355/113 -- Not the famous irrational number PI,  but  an  incredible
simulation!"



From wd at denx.de  Tue Apr 29 20:05:31 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 20:05:31 +0200
Subject: [U-Boot-Users] Please pull u-boot-mpc85xx.git
In-Reply-To: Your message of "Tue, 29 Apr 2008 11:48:57 CDT."
	<1209487737-20612-1-git-send-email-afleming@freescale.com>
Message-ID: <20080429180531.BD1D5247B4@gemini.denx.de>

In message <1209487737-20612-1-git-send-email-afleming at freescale.com> you wrote:
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-mpc85xx.git master
> 
> Kumar Gala (3):
>       85xx: Additional fixes and cleanup of MP code
>       85xx/86xx: Rename DDR init address and init extended address register
>       85xx/86xx: Rename ext_refrec to timing_cfg_3 to match docs
> 
> You've already got the MP one, but the other two were just submitted.
> 
>  board/freescale/mpc8610hpcd/mpc8610hpcd.c |    2 +-
>  board/freescale/mpc8641hpcn/mpc8641hpcn.c |    2 +-
>  board/sbc8548/sbc8548.c                   |    2 +-
>  board/sbc8641d/sbc8641d.c                 |    4 ++--
>  cpu/mpc85xx/mp.c                          |    6 +++++-
>  cpu/mpc85xx/release.S                     |    3 ++-
>  cpu/mpc85xx/spd_sdram.c                   |    4 ++--
>  cpu/mpc86xx/spd_sdram.c                   |    4 ++--
>  include/asm-ppc/immap_85xx.h              |    6 +++---
>  include/asm-ppc/immap_86xx.h              |    4 ++--
>  include/configs/MPC8610HPCD.h             |    2 +-
>  include/configs/sbc8641d.h                |    2 +-
>  12 files changed, 23 insertions(+), 18 deletions(-)

Done, 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: wd at denx.de
Witch!  Witch!  They'll burn ya!
	-- Hag, "Tomorrow is Yesterday", stardate unknown



From wd at denx.de  Tue Apr 29 20:07:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 20:07:00 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
In-Reply-To: Your message of "Tue, 29 Apr 2008 19:14:08 +0200."
	<200804291914.09012.sr@denx.de>
Message-ID: <20080429180700.E29CA247B4@gemini.denx.de>

In message <200804291914.09012.sr at denx.de> you wrote:
> The following changes since commit dd5748bcd669f46aeb6686c1b341323843738ccc:
>   Guennadi Liakhovetski (1):
>         rtl8169: fix compiler warnings
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Markus Brunner (1):
>       ppc4xx: Fixup ebc clock in FDT for 405GP/EP
> 
> Stefan Roese (5):
>       ppc4xx: Change ECC initialization on lwmon5 to use clean_dcache_range()
>       ppc4xx: Complete remove bogus dflush()
>       ppc4xx: Fix Katmai CFG_MONITOR_LEN
>       ppc4xx: Fix compilation warning in denali_spd_ddr2.c
>       ppc4xx: Fix CFG_MONITOR_LEN on Katmai failsave this time
> 
>  board/lwmon5/sdram.c         |   13 ++++++++++---
>  board/netstal/hcu5/sdram.c   |    6 +++---
>  cpu/ppc4xx/44x_spd_ddr2.c    |    5 +++--
>  cpu/ppc4xx/denali_spd_ddr2.c |    5 +++--
>  cpu/ppc4xx/fdt.c             |   10 ++++++++--
>  cpu/ppc4xx/start.S           |   29 -----------------------------
>  include/configs/katmai.h     |    8 ++++----
>  7 files changed, 31 insertions(+), 45 deletions(-)

Done, 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: wd at denx.de
Drawing on my fine command of language, I said nothing.



From wd at denx.de  Tue Apr 29 20:09:00 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 20:09:00 +0200
Subject: [U-Boot-Users] [PATCH] 85xx: Add -mno-spe to e500/85xx builds
In-Reply-To: Your message of "Tue, 29 Apr 2008 12:54:59 CDT."
	<Pine.LNX.4.64.0804291254420.31384@blarg.am.freescale.net>
Message-ID: <20080429180900.EA0AD247B4@gemini.denx.de>

In message <Pine.LNX.4.64.0804291254420.31384 at blarg.am.freescale.net> you wrote:
> Newer gcc's might be configured to enable autovectorization by default.
> If we happen to build with one of those compilers we will get SPE
> instructions in random code.
> 
> -mno-spe disables the compiler for automatically generating SPE
> instructions without our knowledge.
> 
> Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
> ---
>  cpu/mpc85xx/config.mk |    1 +
>  1 files changed, 1 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: wd at denx.de
The universe is all a spin-off of the Big Bang.



From iws at ovro.caltech.edu  Tue Apr 29 20:18:54 2008
From: iws at ovro.caltech.edu (Ira Snyder)
Date: Tue, 29 Apr 2008 11:18:54 -0700
Subject: [U-Boot-Users] [PATCH] ppc4xx: Add device tree support to AMCC
	Yosemite
In-Reply-To: <200804291156.29688.sr@denx.de>
References: <20080429052554.GA19941@ovro.caltech.edu>
	<200804291156.29688.sr@denx.de>
Message-ID: <20080429181854.GB19941@ovro.caltech.edu>

Hello Stefan, U-Boot users

I have made the changes that Stefan requested:
* Include headers unconditionally
* Change "eth0addr" to "ethaddr"
* Change "Open Firmware support" to "device tree support"
* Add NOR flash mapping fixup from Sequoia

I have re-tested the same three setups I tested earlier:
1) Old ARCH=ppc 2.6.13 kernel
2) New ARCH=powerpc 2.6.26rc0 kernel (cuImage)
3) New ARCH=powerpc 2.6.26rc0 kernel (uImage + dtb)

I did not test the NOR flash mapping fixup, as I do not have any NOR
flash to test with. It is an exact copy of the Sequoia code, so I hope
it is correct.

Thanks for the comments.
Ira


>From d2775a95e00d5647583763614cdf4c03a53d39c3 Mon Sep 17 00:00:00 2001
From: Ira W. Snyder <iws at ovro.caltech.edu>
Date: Sat, 26 Apr 2008 16:06:26 -0700
Subject: [PATCH] ppc4xx: Add device tree support to AMCC Yosemite

Add support for booting with a device tree blob. This is needed to boot
ARCH=powerpc kernels. Also add support for setting the eth0 mac address
via the ethaddr variable.

Signed-off-by: Ira W. Snyder <iws at ovro.caltech.edu>
---
 board/amcc/yosemite/yosemite.c |   23 +++++++++++++++++++++++
 include/configs/yosemite.h     |    9 +++++++++
 2 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/board/amcc/yosemite/yosemite.c b/board/amcc/yosemite/yosemite.c
index 6ec922a..212fab8 100644
--- a/board/amcc/yosemite/yosemite.c
+++ b/board/amcc/yosemite/yosemite.c
@@ -26,6 +26,8 @@
 #include <asm/processor.h>
 #include <asm/io.h>
 #include <spd_sdram.h>
+#include <libfdt.h>
+#include <fdt_support.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -554,3 +556,24 @@ void board_reset(void)
 	/* give reset to BCSR */
 	*(unsigned char *)(CFG_BCSR_BASE | 0x06) = 0x09;
 }
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+	u32 val[4];
+	int rc;
+
+	ft_cpu_setup(blob, bd);
+
+	/* Fixup NOR mapping */
+	val[0] = 0;				/* chip select number */
+	val[1] = 0;				/* always 0 */
+	val[2] = gd->bd->bi_flashstart;
+	val[3] = gd->bd->bi_flashsize;
+	rc = fdt_find_and_setprop(blob, "/plb/opb/ebc", "ranges",
+				  val, sizeof(val), 1);
+	if (rc)
+		printf("Unable to update property NOR mapping, err=%s\n",
+		       fdt_strerror(rc));
+}
+#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/include/configs/yosemite.h b/include/configs/yosemite.h
index c9323f6..3bd115a 100644
--- a/include/configs/yosemite.h
+++ b/include/configs/yosemite.h
@@ -141,6 +141,14 @@
 
 
 /*-----------------------------------------------------------------------
+ * Device tree support (Linux-2.6.26+)
+ *----------------------------------------------------------------------*/
+
+/* pass open firmware flat tree */
+#define CONFIG_OF_LIBFDT	1
+#define CONFIG_OF_BOARD_SETUP	1
+
+/*-----------------------------------------------------------------------
  * I2C
  *----------------------------------------------------------------------*/
 #define CONFIG_HARD_I2C		1	    /* I2C with hardware support	*/
@@ -227,6 +235,7 @@
 #define CONFIG_MII		1	/* MII PHY management		*/
 #define CONFIG_NET_MULTI        1	/* required for netconsole      */
 #define CONFIG_PHY1_ADDR        3
+#define CONFIG_HAS_ETH0		1	/* add support for "ethaddr"	*/
 #define CONFIG_HAS_ETH1		1	/* add support for "eth1addr"	*/
 #define CONFIG_PHY_ADDR		1	/* PHY address, See schematics	*/
 
-- 
1.5.4.3




From afleming at gmail.com  Tue Apr 29 21:40:53 2008
From: afleming at gmail.com (Andy Fleming)
Date: Tue, 29 Apr 2008 14:40:53 -0500
Subject: [U-Boot-Users] [PATCH] add config options for VSC8601 RGMII PHY
	- 2nd try
In-Reply-To: <48175868.5090501@matrix-vision.de>
References: <48175868.5090501@matrix-vision.de>
Message-ID: <2acbd3e40804291240r59abceb3xf5b73b1a86499952@mail.gmail.com>

On Tue, Apr 29, 2008 at 12:18 PM, Andre Schwarz
<andre.schwarz at matrix-vision.de> wrote:
> The Vitesse VSC8601 RGMII PHY has internal delay for both Rx
>  and Tx clock lines. They are configured using 2 bits in extended
>  register 0x17.
>  Therefore CFG_VSC8601_SKEW_TX and CFG_VSC8601_SKEW_RX have
>  been introduced with valid values 0-3 giving 0.0, 1.4,1.7 and 2.0ns delay.
>
>  Signed-off-by: Andre Schwarz <andre.schwarz at matrix-vision.de>

Acked-by: Andy Fleming <afleming at freescale.com>



From Ken.Fuchs at bench.com  Tue Apr 29 21:45:34 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Tue, 29 Apr 2008 14:45:34 -0500
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <005501c8a5d3$e467ceb0$ad376c10$@savary@kerlink.fr>
Message-ID: <AA28F077645B324881335614E4F7C428034CF6@win-ex01.bench.com>

I posted the following patch under a different subject line:
Re: [U-Boot-Users] [PATCH] Add eSDHC driver

> > --- u-boot_at91sam9260_mmc.patch (AT91 MCI driver) ---

Pierre Savary wrote:

> Thanks for that... but it's my own patch ;)
> 
> Pierre

===========================================================

Pierre, I hope you like this patch better. :)

The following MMC v4 patch is for u-boot-1.1.5_atmel_1.2.
To the AT91SAM9261 MCI device driver it adds support for
MMC v4.x chips (MoviNAND in particular).
  
The u-boot_at91sam9260_mmc.patch, previously send to this
thread 23 April 2008 must be applied to
u-boot-1.1.5_atmel_1.2, prior to applying the patch below.

The patch includes lines "/* Ignore */".  These are
simply place holders for code that was not relevant
to the MCI driver or MMC code. 

The patch is actually of four individual source files.
Please let me know of any serious problems applying the
patch.  It should apply cleanly, but I didn't verify this.

The MCI MMC v4 features contained in this patch work perfectly
on our AT91SAM9261 board, except that I never got MMC 4 bit
bus working (that code is omitted from this patch).  Anyone
know why the AT91SAM9261-EK doesn't appear to support 4 bit MMC?

This patch may not work on AT91SAM9261-EK, since we modified
the AT91SAM9261-EK board definitions rather than creating a
new configuration and files for our board.

Sincerely,

Ken Fuchs

u-boot-at91sam9261-mmc-v4.patch
===============================

svn diff -r21 cpu/arm926ejs/at91sam926x/atmel_mci.c
Index: cpu/arm926ejs/at91sam926x/atmel_mci.c
===================================================================
--- cpu/arm926ejs/at91sam926x/atmel_mci.c	(revision 21)
+++ cpu/arm926ejs/at91sam926x/atmel_mci.c	(working copy)
@@ -1,4 +1,8 @@
 /*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Added MMC v4.x (MoviNAND) support
+ *
  * Copyright (C) 2004-2006 Atmel Corporation
  *
  * See file CREDITS for list of people who contributed to this
@@ -34,21 +38,43 @@
 #include <asm/arch/hardware.h>	//klk
 
 #include "atmel_mci.h"
-#undef DEBUG
+
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
+#if     0
+#define DEBUG
+#else   /* 0 */
+#undef  DEBUG   /* kf - was #undef */
+#endif  /* 0 */
+
 #ifdef DEBUG
 #define pr_debug(fmt, args...) printf(fmt, ##args)
 #else
 #define pr_debug(...) do { } while(0)
 #endif
 
+#undef  CFG_MMC_CLK_OD
+#define CFG_MMC_CLK_OD		375000
+
 #ifndef CFG_MMC_CLK_OD
 #define CFG_MMC_CLK_OD		375000
 #endif
 
+#undef  CFG_MMC_CLK_PP
+#define CFG_MMC_CLK_PP		20000000
+
 #ifndef CFG_MMC_CLK_PP
 #define CFG_MMC_CLK_PP		20000000
 #endif
 
+#undef  CFG_MMC_OP_COND
+#define CFG_MMC_OP_COND		0x80ff8000
+/*                              0x80ff8080 works with 30+ sec. power
off req */
+/*                              0x00800000 works better, but write
forever?  */
+/*                              0x00100000 works with 30+ sec. power
off req */
+
 #ifndef CFG_MMC_OP_COND
 #define CFG_MMC_OP_COND		0x00100000
 #endif
@@ -74,8 +100,13 @@
 	bus_hz = AT91C_MASTER_CLOCK;
 	clkdiv = (bus_hz / hz) / 2 - 1;
 
+#if     1
+	printf("mmc: setting clock %lu Hz, block size %lu\n",
+		 hz, blklen);
+#else   /* 1 */
 	pr_debug("mmc: setting clock %lu Hz, block size %lu\n",
 		 hz, blklen);
+#endif  /* 1 */
 
 	if (clkdiv & ~255UL) {
 		clkdiv = 255;
@@ -84,10 +115,17 @@
 	}
 
 	blklen &= 0xfffc;
+
+#if     1   /* AT91SAM9261 does not have RDPROOF and WRPROOF fields. */
 	mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
+			 | MMCI_BF(BLKLEN, blklen)));
+#else   /* 1 */
+	mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
 			 | MMCI_BF(BLKLEN, blklen)
 			 | MMCI_BIT(RDPROOF)
 			 | MMCI_BIT(WRPROOF)));
+#endif  /* 1 */
+
 }
 
 #define RESP_NO_CRC	1
@@ -99,6 +137,7 @@
 #define NCR		MMCI_BF(MAXLAT, 1)
 #define TRCMD_START	MMCI_BF(TRCMD, 1)
 #define TRDIR_READ	MMCI_BF(TRDIR, 1)
+#define TRDIR_WRITE	MMCI_BF(TRDIR, 0)
 #define TRTYP_BLOCK	MMCI_BF(TRTYP, 0)
 #define INIT_CMD	MMCI_BF(SPCMD, 1)
 #define OPEN_DRAIN	MMCI_BF(OPDCMD, 1)
@@ -109,6 +148,20 @@
 			 | MMCI_BIT(RINDE)		\
 			 | MMCI_BIT(RTOE))
 
+#if     0
+#define DEBUG
+#else   /* 0 */
+#undef  DEBUG   /* kf - was #undef */
+#endif  /* 0 */
+
+#undef pr_debug
+
+#ifdef DEBUG
+#define pr_debug(fmt, args...) printf(fmt, ##args)
+#else
+#define pr_debug(...) do { } while(0)
+#endif
+
 static int
 mmc_cmd(unsigned long cmd, unsigned long arg,
 	void *resp, unsigned long flags)
@@ -117,7 +170,9 @@
 	int i, response_words = 0;
 	unsigned long error_flags;
 	u32 status;
-
+#if     1
+	pr_debug("mmc_cmd: entry\n");
+#endif  /* 1 */
 	AT91F_MMC_Hardware_Init();
 	
 	pr_debug("mmc: CMD%lu 0x%lx (flags 0x%lx)\n",
@@ -161,12 +216,28 @@
 	return 0;
 }
 
+#if     0
+#define DEBUG
+#else   /* 0 */
+#undef  DEBUG   /* kf - was #undef */
+#endif  /* 0 */
+
+#undef pr_debug
+
+#ifdef DEBUG
+#define pr_debug(fmt, args...) printf(fmt, ##args)
+#else
+#define pr_debug(...) do { } while(0)
+#endif
+
 static int mmc_acmd(unsigned long cmd, unsigned long arg,
 		    void *resp, unsigned long flags)
 {
 	unsigned long aresp[4];
 	int ret;
 
+	pr_debug("mmc_acmd: entry\n");
+
 	/*
 	 * Seems like the APP_CMD part of an ACMD has 64 cycles max
 	 * latency even though the ACMD part doesn't. This isn't
@@ -184,7 +255,16 @@
 	return ret;
 }
 
-static unsigned long
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
+unsigned long
 mmc_bread(int dev, unsigned long start, lbaint_t blkcnt,
 	  unsigned long *buffer)
 {
@@ -193,7 +273,14 @@
 	unsigned long card_status, data;
 	unsigned long wordcount;
 	u32 status;
+	unsigned long *bufaddr;
 
+	pr_debug("mmc_bread: entry\n");
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread ret = %d, card status = %08x\n", ret,
card_status);
+
+	bufaddr = buffer;
+
 	if (blkcnt == 0)
 		return 0;
 
@@ -202,10 +289,16 @@
 
 	/* Put the device into Transfer state */
 	ret = mmc_cmd(MMC_CMD_SELECT_CARD, mmc_rca << 16, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread ret = %d, card status = %08x\n",
+		 ret, card_status);
 	if (ret) goto fail;
 
 	/* Set block length */
 	ret = mmc_cmd(MMC_CMD_SET_BLOCKLEN, mmc_blkdev.blksz, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread ret = %d, card status = %08x\n",
+		 ret, card_status);
 	if (ret) goto fail;
 
 	pr_debug("MCI_DTOR = %08lx\n", mmci_readl(DTOR));
@@ -228,7 +321,6 @@
 
 			if (status & MMCI_BIT(RXRDY)) {
 				data = mmci_readl(RDR);
-				/* pr_debug("%x\n", data); */
 				*buffer++ = data;
 				wordcount++;
 			}
@@ -240,12 +332,68 @@
 			status = mmci_readl(SR);
 		} while (!(status & MMCI_BIT(BLKE)));
 
-		putc('.');
+		mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16,
+			&card_status, R1 | NCR);
+		pr_debug("mmc: bread ret = %d, card status = %08x\n",
+			ret, card_status);
+
+		if (i % 0x800 == 0x7ff) {
+		        putc('.');  /* Display '.', after each MB
xfer'ed */ 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+               }
+
+#if     0
+		buffer = bufaddr;
+		wordcount = 0;
+		do {
+		        if (wordcount % 8 == 0) {
+			        pr_debug("\n%06lx:", 4 * wordcount);
+			}
+			pr_debug(" %08lx", *buffer++);
+			wordcount++;
+		} while (4 * wordcount < mmc_blkdev.blksz);
+		pr_debug("\n");
+#endif  /* 0 */
+
 	}
 
 out:
 	/* Put the device back into Standby state */
 	mmc_cmd(MMC_CMD_SELECT_CARD, 0, resp, NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread ret = %d, card status = %08x\n", ret,
card_status);
+	if (i >= 0x7ff) {
+	         putc('\n');
+	}
 	return i;
 
 fail:
@@ -254,8 +402,329 @@
 	goto out;
 }
 
+unsigned long
+mmc_bwrite(int dev, unsigned long start, lbaint_t blkcnt,
+	  unsigned long *buffer)
+{
+	int ret, i = 0;
+	unsigned long resp[4];
+	unsigned long card_status, data;
+	unsigned long wordcount;
+	u32 status;
+	unsigned long *bufaddr;
+
+	pr_debug("mmc_bwrite: entry\n");
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("en mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+
+	bufaddr = buffer;
+
+	if (blkcnt == 0)
+		return 0;
+
+	pr_debug("mmc_bwrite: dev %d, start %lx, blkcnt %lx\n",
+		 dev, start, blkcnt);
+
+	/* Put the device into Transfer state */
+	ret = mmc_cmd(MMC_CMD_SELECT_CARD, mmc_rca << 16, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("sc mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (ret) goto fail;
+
+	/* Set block length */
+	ret = mmc_cmd(MMC_CMD_SET_BLOCKLEN, mmc_blkdev.blksz, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("bl mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (ret) goto fail;
+
+	pr_debug("MCI_DTOR = %08lx\n", mmci_readl(DTOR));
+
+	for (i = 0; i < blkcnt; i++, start++) {
+		ret = mmc_cmd(MMC_CMD_WRITE_BLOCK,
+			      start * mmc_blkdev.blksz, resp,
+			      (R1 | NCR | TRCMD_START | TRDIR_WRITE
+			       | TRTYP_BLOCK));
+		if (ret) goto fail;
+
+		ret = -EIO;
+		wordcount = 0;
+		do {
+			do {
+				status = mmci_readl(SR);
+				if (status & (ERROR_FLAGS |
MMCI_BIT(UNRE)))
+					goto fail;
+			} while (!(status & MMCI_BIT(TXRDY)));
+
+			if (status & MMCI_BIT(TXRDY)) {
+			        data = *buffer++;
+				mmci_writel(TDR, data);
+				wordcount++;
+			}
+		} while(wordcount < (mmc_blkdev.blksz / 4));
+
+		pr_debug("mmc: write %u words, waiting for BLKE\n",
wordcount);
+
+		do {
+			status = mmci_readl(SR);
+		} while (!(status & MMCI_BIT(BLKE)));
+
+		do {
+		        mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16,
+				&card_status, R1 | NCR);
+			if ((card_status & 0x00000100) != 0x00000100) {
+#if     0
+			        printf("lp mmc: bwrite ret = %d, ",
ret);
+				printf("card status = %08x\n",
card_status);
+#endif  /* 0 */
+			} else {
+			        pr_debug("lp mmc: bwrite ret = %d, ",
ret);
+				pr_debug("card status = %08x\n",
card_status);
+			}
+		} while ((card_status & 0x00000100) != 0x00000100);
+
+		if (i % 0x800 == 0x7ff) {
+		         putc('.');  /* Display '.', after each MB
xfer'ed */ 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+		}
+
+#if     0
+		ret = mmc_cmd(MMC_CMD_STOP_TRANSMISSION,
+			      0, resp,
+			      R1 | NCR);
+		mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16,
+			&card_status, R1 | NCR);
+		pr_debug("st mmc: bwrite ret = %d, card status =
%08x\n",
+			 ret, card_status);
+		if (ret) goto fail;
+#endif  /* 0 */
+
+	}
+
+out:
+#if     0
+	ret = mmc_cmd(MMC_CMD_STOP_TRANSMISSION,
+		      0, resp,
+		      R1 | NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("st mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (ret) goto fail;
+#endif  /* 0 */
+
+	/* Put the device back into Standby state */
+	mmc_cmd(MMC_CMD_SELECT_CARD, 0, resp, NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("dc mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (i >= 0x7ff) {
+	         putc('\n');
+	}
+	return i;
+
+fail:
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("fa mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	goto out;
+}
+
+   /* Hangs - did not attempt to debug */
+/* MMC Multiple Block Write - mmc_mbwrite() */
+unsigned long
+mmc_mbwrite(int dev, unsigned long start, lbaint_t blkcnt,
+	  unsigned long *buffer)
+{
+	int ret, i = 0;
+	unsigned long resp[4];
+	unsigned long card_status, data;
+	unsigned long wordcount;
+	u32 status;
+	unsigned long *bufaddr;
+
+	pr_debug("mmc_bwrite: entry\n");
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("en mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+
+	bufaddr = buffer;
+
+	if (blkcnt == 0)
+		return 0;
+
+	if (blkcnt > 0xffff) {  /* Exceeds length supported by MoviNAND.
*/
+	        return -1;
+	}
+
+	pr_debug("mmc_mbwrite: dev %d, start %lx, blkcnt %lx\n",
+		 dev, start, blkcnt);
+
+	/* Put the device into Transfer state */
+	ret = mmc_cmd(MMC_CMD_SELECT_CARD, mmc_rca << 16, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("sc mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+	if (ret) goto fail;
+
+	/* Set block length */
+	ret = mmc_cmd(MMC_CMD_SET_BLOCKLEN, mmc_blkdev.blksz, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("bl mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+	if (ret) goto fail;
+
+	pr_debug("MCI_DTOR = %08lx\n", mmci_readl(DTOR));
+
+	ret = mmc_cmd(MMC_CMD_SET_BLOCK_COUNT,
+		      blkcnt, resp,
+		      R1 | NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("bc mmc: mbwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (ret) goto fail;
+
+	ret = mmc_cmd(MMC_CMD_WRITE_MULTIPLE_BLOCK,
+		      start * mmc_blkdev.blksz, resp,
+		      (R1 | NCR | TRCMD_START | TRDIR_WRITE |
TRTYP_BLOCK));
+	if (ret) goto fail;
+
+	for (i = 0; i < blkcnt; i++, start++) {
+
+		ret = -EIO;
+		wordcount = 0;
+		do {
+			do {
+				status = mmci_readl(SR);
+				if (status & (ERROR_FLAGS |
MMCI_BIT(UNRE)))
+					goto fail;
+			} while (!(status & MMCI_BIT(TXRDY)));
+
+			if (status & MMCI_BIT(TXRDY)) {
+			        data = *buffer++;
+				mmci_writel(TDR, data);
+				wordcount++;
+			}
+		} while(wordcount < (mmc_blkdev.blksz / 4));
+
+#if     1
+		pr_debug("mmc: write %u words, waiting for BLKE\n",
wordcount);
+
+		do {
+			status = mmci_readl(SR);
+		} while (!(status & MMCI_BIT(BLKE)));
+#endif  /* 0 */
+
+		do {
+		        mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16,
+				&card_status, R1 | NCR);
+			if ((card_status & 0x00000100) != 0x00000100) {
+#if     0
+			        printf("lp mmc: mbwrite ret = %d, ",
ret);
+				printf("card status = %08x\n",
card_status);
+#endif  /* 0 */
+			} else {
+			        pr_debug("lp mmc: mbwrite ret = %d, ",
ret);
+				pr_debug("card status = %08x\n",
card_status);
+			}
+		} while ((card_status & 0x00000100) != 0x00000100);
+
+		if (i % 0x800 == 0x7ff) {
+		         putc('.');  /* Display '.', after each MB
xfer'ed */ 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+		}
+	}
+
+out:
+#if     0
+	ret = mmc_cmd(MMC_CMD_STOP_TRANSMISSION,
+		      0, resp,
+		      R1 | NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("st mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+	if (ret) goto fail;
+#endif  /* 0 */
+
+	/* Put the device back into Standby state */
+	mmc_cmd(MMC_CMD_SELECT_CARD, 0, resp, NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("dc mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+	if (i >= 0x7ff) {
+	         putc('\n');
+	}
+	return i;
+
+fail:
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("fa mmc: mbwrite failed, card status = %08x\n",
card_status);
+	goto out;
+}
+
 static void mmc_parse_cid(struct mmc_cid *cid, unsigned long *resp)
 {
+	pr_debug("mmc_parse_cid: entry\n");
+
 	cid->mid = resp[0] >> 24;
 	cid->oid = (resp[0] >> 8) & 0xffff;
 	cid->pnm[0] = resp[0];
@@ -272,6 +741,8 @@
 
 static void sd_parse_cid(struct mmc_cid *cid, unsigned long *resp)
 {
+	pr_debug("sd_parse_cid: entry\n");
+
 	cid->mid = resp[0] >> 24;
 	cid->oid = (resp[0] >> 8) & 0xffff;
 	cid->pnm[0] = resp[0];
@@ -288,6 +759,8 @@
 
 static void mmc_dump_cid(const struct mmc_cid *cid)
 {
+	pr_debug("mmc_dump_cid: entry\n");
+
 	printf("Manufacturer ID:       %02lX\n", cid->mid);
 	printf("OEM/Application ID:    %04lX\n", cid->oid);
 	printf("Product name:          %s\n", cid->pnm);
@@ -301,6 +774,9 @@
 static void mmc_dump_csd(const struct mmc_csd *csd)
 {
 	unsigned long *csd_raw = (unsigned long *)csd;
+
+	pr_debug("mmc_dump_csd: entry\n");
+
 	pr_debug("CSD data: %08lx %08lx %08lx %08lx\n",
 	       csd_raw[0], csd_raw[1], csd_raw[2], csd_raw[3]);
 	pr_debug("CSD structure version:   1.%u\n", csd->csd_structure);
@@ -337,6 +813,8 @@
 {
 	int ret;
 
+	pr_debug("mmc_idle_cards: entry\n");
+
 	/* Reset and initialize all cards */
 	ret = mmc_cmd(MMC_CMD_GO_IDLE_STATE, 0, NULL, 0);
 	
@@ -352,6 +830,8 @@
 	unsigned long resp[4];
 	int i, ret = 0;
 
+	pr_debug("sd_init_card: entry\n");
+
 	mmc_idle_cards();
 	for (i = 0; i < 1000; i++) {
 		ret = mmc_acmd(MMC_ACMD_SD_SEND_OP_COND,
CFG_MMC_OP_COND,
@@ -387,10 +867,40 @@
 {
 	unsigned long resp[4];
 	int i, ret = 0;
+	u32 status;
 
+	pr_debug("mmc_init_card: entry\n");
+
 	mmc_idle_cards();
 
+	/* MoviNAND initialization */
 	for (i = 0; i < 1000; i++) {
+	        mmci_writel(ARGR, 0xFFFFFFFF);
+		mmci_writel(CMDR, 0x0018113F);
+		do {
+		        status = mmci_readl(SR);
+		} while (!(status & MMCI_BIT(CMDRDY)));
+	}
+        /* Getting the OCR value seems to prevent marginal chips from
*/
+        /* working at all, whereas they would work fine after waiting
*/
+        /* a full minute or more with the power off prior to booting.
*/
+        /* Our marginal chips have date codes 0716 and 0728.
*/
+#if     0   
+	for (i = 0; i < 1000; i++) {
+	  /* Request OCR value to determine chip's supported volt. */
+		ret = mmc_cmd(MMC_CMD_SEND_OP_COND, 0, resp,
+			      R3 | NID | OPEN_DRAIN);
+		if (ret || (resp[0] & 0x80000000))
+		{
+			break;
+		}
+		ret = -ETIMEDOUT;
+	}
+	if (ret) {
+		return ret;
+	}
+#endif  /* 0 */
+	for (i = 0; i < 1000; i++) {
 		ret = mmc_cmd(MMC_CMD_SEND_OP_COND, CFG_MMC_OP_COND,
resp,
 			      R3 | NID | OPEN_DRAIN);
 		if (ret || (resp[0] & 0x80000000))
@@ -399,13 +909,35 @@
 		}
 		ret = -ETIMEDOUT;
 	}
+        pr_debug("Step 4: ret = 0x%lx\n", ret);
+	pr_debug("MMC_CMD_SEND_OP_COND = 0x%lx\n",
MMC_CMD_SEND_OP_COND);
+        pr_debug("CFG_MMC_OP_COND = 0x%lx\n", CFG_MMC_OP_COND);
+        pr_debug("resp[0] = 0x%lx\n", resp[0]);
+        pr_debug("resp[1] = 0x%lx\n", resp[1]);
+        pr_debug("resp[2] = 0x%lx\n", resp[2]);
+        pr_debug("resp[3] = 0x%lx\n", resp[3]);
+        pr_debug("R3 = 0x%lx\n", R3);
+        pr_debug("NID = 0x%lx\n", NID);
+        pr_debug("OPEN_DRAIN = 0x%lx\n", OPEN_DRAIN);
+
 	pr_debug("4\n");
 	pr_debug("ret : %i\n",ret);
+
+	pr_debug("MCI_MR = 0x%08lx\n", mmci_readl(MR));
+	pr_debug("MCI_DTOR = 0x%08lx\n", mmci_readl(DTOR));
+	pr_debug("MCI_SDCR = 0x%08lx\n", mmci_readl(SDCR));
+	pr_debug("MCI_ARGR = 0x%08lx\n", mmci_readl(ARGR));
+	/* RSPR */
+	/* RDR */
+	pr_debug("MCI_SR = 0x%08lx\n", mmci_readl(SR));
+	pr_debug("MCI_IMR = 0x%08lx\n", mmci_readl(IMR));
+
 	if (ret)
 		return ret;
 	pr_debug("5\n");
 	/* Get CID of all cards. FIXME: Support more than one card */
 	ret = mmc_cmd(MMC_CMD_ALL_SEND_CID, 0, resp, R2 | NID |
OPEN_DRAIN);
+	pr_debug("ALL_SEND_CID ret: 0x%08lx\n", ret);
 	if (ret)
 		return ret;
 	mmc_parse_cid(cid, resp);
@@ -415,6 +947,7 @@
 	/* Set Relative Address of the card that responded */
 	ret = mmc_cmd(MMC_CMD_SET_RELATIVE_ADDR, mmc_rca << 16, resp,
 		      R1 | NCR | OPEN_DRAIN);
+	pr_debug("SET_RELATIVE_ADDR ret: 0x%08lx\n", ret);
 	return ret;
 }
 
@@ -471,23 +1004,42 @@
 	       dtocyc << shift, dtor);
 }
 
+#define DEFAULT_SECTOR_SIZE 512
+
 int mmc_init(int verbose)
 {
 	struct mmc_cid cid;
 	struct mmc_csd csd;
 	unsigned int max_blksz;
 	int ret,aux;
+	unsigned char buffer[DEFAULT_SECTOR_SIZE];
 	
+	pr_debug("mmc_init: entry\n");
+	pr_debug("mmc_init: verbose = 0x%08lx\n", verbose);
+
 	AT91F_MMC_Hardware_Init();
 	
 	pr_debug("0\n");
 	/* Initialize controller */
 	mmci_writel(CR, MMCI_BIT(SWRST));
 	mmci_writel(CR, MMCI_BIT(MCIEN));
+
+	pr_debug("MCI_MR = 0x%08lx\n", mmci_readl(MR));
+	pr_debug("MCI_DTOR = 0x%08lx\n", mmci_readl(DTOR));
+	pr_debug("MCI_SDCR = 0x%08lx\n", mmci_readl(SDCR));
+	pr_debug("MCI_ARGR = 0x%08lx\n", mmci_readl(ARGR));
+	/* RSPR */
+	/* RDR */
+	pr_debug("MCI_SR = 0x%08lx\n", mmci_readl(SR));
+	pr_debug("MCI_IMR = 0x%08lx\n", mmci_readl(IMR));
+
 	mmci_writel(DTOR, 0x5f);
 	mmci_writel(IDR, ~0UL);
 	mmci_writel(SDCR, 0x1);
 	mci_set_mode(CFG_MMC_CLK_OD, MMC_DEFAULT_BLKLEN);
+#if     0
+	mmci_writel(MR, 0x02009B4A);
+#endif  /* 0 */
 /* 	//mmci_writel(CR, MMCI_BIT(SWRST));
 	mmci_writel(CR, 0x00000001);
 	mmci_writel(DTOR, 0x0000007F);
@@ -502,6 +1054,7 @@
 
 	ret = sd_init_card(&cid, verbose);
 	if (ret) {
+	  	pr_debug("Not SDCard, try MMC\n");
 		mmc_rca = MMC_DEFAULT_RCA;
 		ret = mmc_init_card(&cid, verbose);
 	}
@@ -545,6 +1098,20 @@
 	mci_set_mode(CFG_MMC_CLK_PP, mmc_blkdev.blksz);
 
 #if 0
+	mmc_bread(mmc_blkdev.dev, 1024, 1, (ulong *)buffer);
+        buffer[0] = 0x00; buffer[1] = 0x11;
+        buffer[2] = 0x22; buffer[3] = 0x33;
+        buffer[4] = 0x44; buffer[5] = 0x55;
+        buffer[6] = 0x66; buffer[7] = 0x77;
+        buffer[504] = 0x88; buffer[505] = 0x99;
+        buffer[506] = 0xaa; buffer[507] = 0xbb;
+        buffer[508] = 0xcc; buffer[509] = 0xdd;
+        buffer[510] = 0xee; buffer[511] = 0xff;
+	mmc_bwrite(mmc_blkdev.dev, 1024, 1, (ulong *)buffer); 
+	mmc_bread(mmc_blkdev.dev, 1024, 1, (ulong *)buffer);
+#endif  /* 0 */
+
+#if 0
 	if (fat_register_device(&mmc_blkdev, 1))
 		pr_debug("Could not register MMC fat device\n");
 #else
@@ -556,16 +1123,22 @@
 
 int mmc_read(ulong src, uchar *dst, int size)
 {
+	pr_debug("mmc_read: entry\n");
+
 	return -ENOSYS;
 }
 
 int mmc_write(uchar *src, ulong dst, int size)
 {
+	pr_debug("mmc_write: entry\n");
+
 	return -ENOSYS;
 }
 
 int mmc2info(ulong addr)
 {
+	pr_debug("mmc2info: entry\n");
+
 	return 0;
 }
 
svn diff -r21 include/asm-arm/arch-at91sam926x/mmc.h
Index: include/asm-arm/arch-at91sam926x/mmc.h
===================================================================
--- include/asm-arm/arch-at91sam926x/mmc.h	(revision 0)
+++ include/asm-arm/arch-at91sam926x/mmc.h	(revision 50)
@@ -0,0 +1,103 @@
+/*
+ * (C) Copyright 2007
+ * Benchmark Electronics, Inc.
+ * Added MMC v4.x (MoviNAND) support
+ *
+ * Copyright (C) 2004-2006 Atmel Corporation
+ *
+ * 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
+ */
+#ifndef __ASM_AT91SAM926X_MMC_H
+#define __ASM_AT91SAM926X_MMC_H
+
+struct mmc_cid {
+	unsigned long psn;
+	unsigned short oid;
+	unsigned char mid;
+	unsigned char prv;
+	unsigned char mdt;
+	char pnm[7];
+};
+
+struct mmc_csd
+{
+	u8	csd_structure:2,
+		spec_vers:4,
+		rsvd1:2;
+	u8	taac;
+	u8	nsac;
+	u8	tran_speed;
+	u16	ccc:12,
+		read_bl_len:4;
+	u64	read_bl_partial:1,
+		write_blk_misalign:1,
+		read_blk_misalign:1,
+		dsr_imp:1,
+		rsvd2:2,
+		c_size:12,
+		vdd_r_curr_min:3,
+		vdd_r_curr_max:3,
+		vdd_w_curr_min:3,
+		vdd_w_curr_max:3,
+		c_size_mult:3,
+		sector_size:5,
+		erase_grp_size:5,
+		wp_grp_size:5,
+		wp_grp_enable:1,
+		default_ecc:2,
+		r2w_factor:3,
+		write_bl_len:4,
+		write_bl_partial:1,
+		rsvd3:5;
+	u8	file_format_grp:1,
+		copy:1,
+		perm_write_protect:1,
+		tmp_write_protect:1,
+		file_format:2,
+		ecc:2;
+	u8	crc:7;
+	u8	one:1;
+};
+
+/* MMC Command numbers */
+#define MMC_CMD_GO_IDLE_STATE		0
+#define MMC_CMD_SEND_OP_COND		1
+#define MMC_CMD_ALL_SEND_CID 		2
+#define MMC_CMD_SET_RELATIVE_ADDR	3
+#define MMC_CMD_SD_SEND_RELATIVE_ADDR	3
+#define MMC_CMD_SET_DSR			4
+#define MMC_CMD_SELECT_CARD		7
+#define MMC_CMD_SEND_CSD 		9
+#define MMC_CMD_SEND_CID 		10
+#define MMC_CMD_STOP_TRANSMISSION	12
+#define MMC_CMD_SEND_STATUS		13
+#define MMC_CMD_SET_BLOCKLEN		16
+#define MMC_CMD_READ_SINGLE_BLOCK	17
+#define MMC_CMD_READ_MULTIPLE_BLOCK	18
+#define MMC_CMD_SET_BLOCK_COUNT		23
+#define MMC_CMD_WRITE_BLOCK		24
+#define MMC_CMD_WRITE_MULTIPLE_BLOCK	25
+#define MMC_CMD_APP_CMD			55
+
+#define MMC_ACMD_SD_SEND_OP_COND	41
+
+#define R1_ILLEGAL_COMMAND		(1 << 22)
+#define R1_APP_CMD			(1 << 5)
+
+#endif /* __ASM_AT91SAM926X_MMC_H */

svn diff -r21 include/configs/at91sam9261ek.h
Index: include/configs/at91sam9261ek.h
===================================================================
--- include/configs/at91sam9261ek.h	(revision 21)
+++ include/configs/at91sam9261ek.h	(working copy)
@@ -1,4 +1,8 @@
 /*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Added MMC v4.x (MoviNAND) support
+ *
  * (C) Copyright 2005
  * M. Amine SAYA ATMEL Rousset, France.
  *
@@ -95,18 +99,24 @@
 /* SPI */
 #define CONFIG_SPI
 
+/* kf - define hush (from busy box) command line interface & options */
+#define CFG_HUSH_PARSER
+#define CFG_PROMPT_HUSH_PS2     "> "
+#define CFG_AUTO_COMPLETE
+#define CONFIG_CMDLINE_EDITING
+
 #define CONFIG_COMMANDS		\
 		       ((CONFIG_CMD_DFL	| \
                         CFG_CMD_NET | \
                         CFG_CMD_ENV | \
                         CFG_CMD_USB | \
                         CFG_CMD_FLASH | \
-			CFG_CMD_NAND | \
+                        CFG_CMD_MMC | \
+                        CFG_CMD_EXT2 | \
+                        CFG_CMD_FAT | \
 			CFG_CMD_AUTOSCRIPT | \
-                        CFG_CMD_FAT | \
                         CFG_CMD_NFS | \
                         CFG_CMD_SPI | \
-                        CFG_CMD_U | \
 			CFG_CMD_IMI | \
                         CFG_CMD_PING ) & \
 		      ~(CFG_CMD_BDI | \
@@ -296,8 +306,12 @@
 #define CFG_FLASH_ERASE_TOUT		(2*CFG_HZ) /* Timeout for Flash
Erase */
 #define CFG_FLASH_WRITE_TOUT		(2*CFG_HZ) /* Timeout for Flash
Write */
 
+#undef  CFG_ENV_IS_IN_FLASH
 #define	CFG_ENV_IS_IN_DATAFLASH         1
-#undef  CFG_ENV_IS_IN_FLASH
+#if     0
+#undef  CFG_ENV_IS_IN_NAND
+#endif  /* 0 - kf */
+#undef  CFG_ENV_IS_NOWHERE
 
 #ifdef CFG_ENV_IS_IN_DATAFLASH
 #define CFG_ENV_OFFSET			0x4000
@@ -305,6 +319,10 @@
 #define CFG_ENV_SIZE			0x4000  /* 0x8000 */
 #endif
 
+#ifdef CFG_ENV_IS_NOWHERE
+#define CFG_ENV_SIZE			0x4000
+#endif
+
 #ifdef CFG_ENV_IS_IN_FLASH
 #ifdef CONFIG_BOOTBINFUNC
 #define CFG_ENV_ADDR			(PHYS_FLASH_1 + 0x60000)  /*
after u-boot.bin */
@@ -316,6 +334,9 @@
 #endif
 
 /* Add LCD stuff */
+/* Ignore */
+/* Ignore */
+
 #if 0  /* No LCD */
 #define  CONFIG_LCD
 /* #undef  CONFIG_LCD_LOGO */
@@ -333,8 +354,21 @@
 #define CONFIG_DOS_PARTITION	        1
 #define LITTLEENDIAN 			1
 
-#define CFG_LOAD_ADDR		0x23f00000  /* default load address */
+/* Add FAT filesystem configuration, other than CFG_CMD_FAT */
+#define CONFIG_SUPPORT_VFAT
 
+/* MMC */
+#define CONFIG_MMC		1
+#define MMCI_BASE		0xFFFA8000  /* (void *)AT91C_BASE_MCI */
+/* MMC - kf - slow down speed for debug from 20000000 Hz down to ...
*/
+/* However, tweaking this value here causes all code to be compiled,
*/
+/* so we shall change the value only where needed - in atmel_mci.c.
*/
+#define CFG_MMC_CLK_PP          20000000
+
+#define CFG_LOAD_ADDR		0x23f00000  /* default load address   */
+
+#define CFG_BOOTM_LEN           0x02100000  /* 33MB uncompressed max.
*/
+
 #ifdef CONFIG_BOOTBINFUNC
 #define CFG_BOOT_SIZE		0x00 /* 0 KBytes */
 #define CFG_U_BOOT_BASE		PHYS_FLASH_1

svn diff -r21 board/at91sam9261ek/at91sam9261ek.c
Index: board/at91sam9261ek/at91sam9261ek.c
===================================================================
--- board/at91sam9261ek/at91sam9261ek.c	(revision 21)
+++ board/at91sam9261ek/at91sam9261ek.c	(working copy)
@@ -1,4 +1,8 @@
 /*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Added specific AT91SAM9261 board support
+ *
  * (C) Copyright 2005
  * M. Amine SAYA ATMEL Rousset, France.
  * Added AT91SAM9261EK support.
@@ -28,12 +32,19 @@
 
 #include <common.h>
 #include <asm/arch/hardware.h>
+#include <asm/arch-at91sam926x/at91sam9261.h>
 
 #include <net.h>
 
 extern void AT91F_Spi1Init (void);
 extern void gpio_init(void);
 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
 /*
------------------------------------------------------------------------
- */
 /*
  * Miscelaneous platform dependent initialisations
@@ -107,7 +118,8 @@
   *AT91C_PMC_PCER |= 1 << AT91C_ID_US0;	/* enable clock */
 #endif
   
-#ifdef CONFIG_USART1
+#if     1
+  /* #ifdef CONFIG_USART1 */
   *AT91C_PIOB_PDR = AT91C_PC12_TXD1 | AT91C_PC13_RXD1;
   *AT91C_PMC_PCER |= 1 << AT91C_ID_US1;	/* enable clock */
 #endif
@@ -118,6 +130,41 @@
 #endif
 }
 
+#ifdef CONFIG_MMC
+#if (CONFIG_COMMANDS & CFG_CMD_MMC)
+int AT91F_MMC_Hardware_Init(void)
+{
+#if     0
+	printf("AT91F_MMC_Hardware_Init: entry\n");
+#endif  /* 0 */
+
+        AT91F_PIO_CfgPeriph(AT91C_BASE_PIOA,
+			    0,                   /*  <- Peripheral A */
+			    (AT91C_PA0_MCDA0 |    /*  MMC NAND MCDA0  */
+			     AT91C_PA1_MCCDA |    /*  MMC NAND MCCDA  */
+			     AT91C_PA2_MCCK  |    /*  MMC NAND MCCK   */
+			     AT91C_PA4_MCDA1 |    /*  MMC NAND MCDA1  */
+			     AT91C_PA5_MCDA2 |    /*  MMC NAND MCDA2  */
+			     AT91C_PA6_MCDA3 |    /*  MMC NAND MCDA3  */
+			     0));                 /*  <- Peripheral B */
+
+#if     1
+	/* Pull up disable register */
+	AT91C_BASE_PIOA->PIO_PPUDR |=
+	        AT91C_PA0_MCDA0 |    /*  MMC NAND MCDA0  */
+	        AT91C_PA1_MCCDA |    /*  MMC NAND MCCDA  */
+	        AT91C_PA2_MCCK  |    /*  MMC NAND MCCK   */
+	        AT91C_PA4_MCDA1 |    /*  MMC NAND MCDA1  */
+	        AT91C_PA5_MCDA2 |    /*  MMC NAND MCDA2  */
+	        AT91C_PA6_MCDA3;     /*  MMC NAND MCDA3  */
+#endif  /* 0 */
+
+	AT91C_BASE_PMC->PMC_PCER = (1 << AT91C_ID_MCI);
+}
+#endif /* CONFIG_COMMANDS & CFG_CMD_MMC */
+#endif /* CONFIG_MMC */
+
+
 int dram_init (void)
 {
   DECLARE_GLOBAL_DATA_PTR;
@@ -148,5 +195,35 @@
 
   gpio_init();
 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
   return 0;
 }



From g.liakhovetski at gmx.de  Tue Apr 29 22:10:14 2008
From: g.liakhovetski at gmx.de (Guennadi Liakhovetski)
Date: Tue, 29 Apr 2008 22:10:14 +0200 (CEST)
Subject: [U-Boot-Users] [PATCH] net: add 16 bit support for smc911x
In-Reply-To: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>
References: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>
Message-ID: <Pine.LNX.4.64.0804292208520.8498@axis700.grange>

On Tue, 29 Apr 2008, Jens Gehrlein wrote:

> Hi Ben, Magnus,
> 
> here is my patch to enable 2x16 bit accesses to the LAN9x1x.
> I still not have a HW, so may I ask you to test it and, if applicable,
> fix the code?
> 
> Best Regards,
> Jens
> 
> ---
> 
>  drivers/net/smc911x.c |   17 ++++++++++++++++-
>  1 files changed, 16 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index d22c889..841a64d 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -30,6 +30,8 @@
>  #include <net.h>
>  #include <miiphy.h>
>  
> +#define CONFIG_DRIVER_SMC911X_16_BIT 1
> +

Looks like an obvious thing - you'll remove this define from the patch for 
final submission, right?

Thanks
Guennadi
---
Guennadi Liakhovetski



From adrian.filipi at eurotech.com  Tue Apr 29 22:20:09 2008
From: adrian.filipi at eurotech.com (Adrian Filipi)
Date: Tue, 29 Apr 2008 16:20:09 -0400 (EDT)
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <AA28F077645B324881335614E4F7C428034CF6@win-ex01.bench.com>
References: <AA28F077645B324881335614E4F7C428034CF6@win-ex01.bench.com>
Message-ID: <alpine.DEB.1.10.0804291604250.32753@pmy.adscville>

hi folks,

 	I've come across a case on one of our PXA250 boards where the 
flash was getting corrupted when using the 1.3.2 version of cfi_flash.c, 
while the 1.2.0 version worked just fine.

 	Here's what happens:

 	1. Reprogram uboot.
 	2. Compare uboot in flash against uboot in DRAM.
 	3. Either run "reset" or press the reset button.
 	4. Compare the flash and DRAM, as well as a new copy
 	   of uboot re-read from CF for good measure.

 	At this point the low byte in the word at offset 0x554 has switched 
from a 0x30 to a 0x10.  This is the only change in the flash.  The new 
value is always the same.

 	I narrowed down the source of the problem to the loss of the 
volatile qualifier on the addr pointer in flash_write_cmd().  Adding the 
qualifier gets rid of the corruption.  In the older 1.2.0 sources, addr was 
declared as "volatile cfiptr_t addr;".

 	Has anyone else seen this?  It seems like the safe thing to do is 
to restore the qualifier in general.

 	Below is a diff, of the change for the 1.3.2. sources:

diff -u -r1.1.1.2.2.2 cfi_flash.c
--- cfi_flash.c	23 Apr 2008 17:02:47 -0000	1.1.1.2.2.2
+++ cfi_flash.c	29 Apr 2008 18:55:47 -0000
@@ -464,7 +464,7 @@
  			     uint offset, uchar cmd)
  {

-	void *addr;
+	void *volatile addr;
  	cfiword_t cword;

  	addr = flash_map (info, sect, offset);

 	Adrian
--
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com




From gerickson at nuovations.com  Tue Apr 29 22:39:44 2008
From: gerickson at nuovations.com (Grant Erickson)
Date: Tue, 29 Apr 2008 13:39:44 -0700
Subject: [U-Boot-Users] Using Data Cache for the Primordial Stack on the
 405EX[r] (was Re: [PATCH v2] PPC405EX(r) ECC and SDRAM Initialization
 Clean-ups)
In-Reply-To: <200804291142.53005.sr@denx.de>
Message-ID: <C43CD5A0.EE76%gerickson@nuovations.com>

On 4/29/08 2:42 AM, Stefan Roese wrote:
> On Tuesday 29 April 2008, kenneth johansson wrote:
>>>> Stefan already asked this... I would also like to understand why the
>>>> data cache cannot be used for initial RAM as we do on so many other
>>>> systems?
>>> 
>>> Agreed. The changes were based on the comments in the Kilauea and Makalu
>>> board ports indicating that this had been attempted--twice--and didn't
>>> work.
>>> 
>>> I am escalating with AMCC to find out if this is a processor errata,
>>> board issue or just a programming issue that needs to be investigated
>>> further.
>> 
>> The cache trick works fine on 405CR/405GP. Is the cache redesigned for
>> 405EX. Why would they still call it a 405 if the core was redesigned?
> 
> I already sent an update to Grant privately on this. Here again:
> 
> The main problem is that the board crashes with an exception (0x200: Data
> machine check) when init RAM in dcache is used. This happens upon calling
> trap_init() in board_init_r(). The exception must be pending and
> is "activated" upon the trap_init() call. Either Grant (or somebody else?)
> will look into this, or I will try to look into is (again) in a few days.
> 
> Thanks.
> 
> Best regards,
> Stefan

For those following this thread, here are the result of my investigations
today:

When using the Haleakala board and configuring include/configs/kilauea.h as
follows:

    #define CFG_SDRAM_BASE          0x00000000
    #define CFG_INIT_DCACHE_CS      3
    #define CFG_INIT_RAM_ADDR       (CFG_SDRAM_BASE + (1 << 30))

I find the following results while tracking the various exception-related
registers:

    1) At _start + 0:
    
          MSR           :  0x0000 0000
          ESR (0x3D4)   :  0x0000 0000
          DEAR (0x3D5)  :  0x0000 0000
          SRR0 (0x01A)  :  0x0000 0700
          SRR1 (0x01B)  :  0x0000 0000
          SRR2 (0x3DE)  :  0xFFFA 8678 (NfsStart + 0x2c)
          SRR3 (0x3DF)  :  0x0000 0000
          MCSR (0x23C)  :  0x0000 0000
          MCAR (0x23D)  :  0x0000 0000
          MCSRR0 (0x23A):  0x0000 0000
          MCSRR1 (0x23B):  0x0000 0000

          EBC0_BEAR     :  0x0000 0000
          EBC0_BESR     :  0x0000 0000

    
    2) After both invalidate_icache() and invalidate_dcache() have run:
    
          <same>
    
    3) After a NOP ext_bus_cntlr_init() has run:
    
          <same>
       
    4) After PBxAP and PBxCR have been set-up for the desired EBC region:
    
          <same>

    5) After the data cacheability has been set for this range:

          MSR           :  0x0000 0000
          ESR (0x3D4)   :  0x0000 0000
          DEAR (0x3D5)  :  0x0000 0000
          SRR0 (0x01A)  :  0x0000 0700
          SRR1 (0x01B)  :  0x0000 0000
          SRR2 (0x3DE)  :  0xFFFA 8678 (NfsStart + 0x2c)
          SRR3 (0x3DF)  :  0x0000 0000
          MCSR (0x23C)  :  0x0000 0000
          MCAR (0x23D)  :  0x0000 0000
          MCSRR0 (0x23A):  0x0000 0000
          MCSRR1 (0x23B):  0x0000 0000

          EBC0_BEAR     :  0x0000 0000
        * EBC0_BESR     :  0x4000 0000 PERR=1

    5) Immediately after the following instruction runs:
    
           lis  r1,CFG_INIT_RAM_ADDR at h
    
          MSR           :  0x0000 0000
          ESR (0x3D4)   :  0x0000 0000
          DEAR (0x3D5)  :  0x0000 0000
          SRR0 (0x01A)  :  0x0000 0700
          SRR1 (0x01B)  :  0x0000 0000
          SRR2 (0x3DE)  :  0xFFFA 8678 (NfsStart + 0x2c)
          SRR3 (0x3DF)  :  0x0000 0000
        * MCSR (0x23C)  :  0xA000 0000 MCS = 1, DPLBE = 1
          MCAR (0x23D)  :  0x0000 0000
          MCSRR0 (0x23A):  0x0000 0000
          MCSRR1 (0x23B):  0x0000 0000

          EBC0_BEAR     :  0x0000 0000
          EBC0_BESR     :  0x4000 0000 PERR=1

However, the overall operation does appear to be working in terms of priming
the primordial stack with known values:

    (gdb) info registers r2
    r2             0x40000fc4

    (gdb) print /x *$r2
    $1 = 0xdeaddead

    (gdb) x /64xw 0x40000FC0
    0x40000fc0:    0x00000000    0xdeaddead    0xdeaddead    0xdeaddead
    0x40000fd0:    0xdeaddead    0xdeaddead    0xdeaddead    0xdeaddead
    0x40000fe0:    0xdeaddead    0xdeaddead    0xdeaddead    0xdeaddead
    0x40000ff0:    0xdeaddead    0xdeaddead    0xdeaddead    0xdeaddead
    0x40001000:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001010:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001020:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001030:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001040:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001050:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001060:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001070:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001080:    0x00000000    0x00000000    0x00000000    0x00000000
    0x40001090:    0x00000000    0x00000000    0x00000000    0x00000000
    0x400010a0:    0x00000000    0x00000000    0x00000000    0x00000000
    0x400010b0:    0x00000000    0x00000000    0x00000000    0x00000000

Other Experiments Tried:

    Changing:

        #define CFG_INIT_DCACHE_CS      3

    to 4, 5, 6, or 7 doesn't seem to make any difference except I then
    also seem to get BOTH IPLBE=1 and DPLBE=1 in MCSR for 4, 5, 6 or 7.

While this seems to work OK on older 405 variants, is there something new or
different about the PLB to OPB to EBC bridges in the 405EX[r] relative to
those older 405 variants that cause this CFG_INIT_DCACHE_CS primordial stack
trick to raise an exception where the others before it did not?

Regards,

Grant





From wd at denx.de  Tue Apr 29 22:43:48 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 22:43:48 +0200
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: Your message of "Tue, 29 Apr 2008 16:20:09 EDT."
	<alpine.DEB.1.10.0804291604250.32753@pmy.adscville>
Message-ID: <20080429204348.1ED4C247B4@gemini.denx.de>

In message <alpine.DEB.1.10.0804291604250.32753 at pmy.adscville> you wrote:
> 
>  	I narrowed down the source of the problem to the loss of the 
> volatile qualifier on the addr pointer in flash_write_cmd().  Adding the 
> qualifier gets rid of the corruption.  In the older 1.2.0 sources, addr was 
> declared as "volatile cfiptr_t addr;".

The volatile should not be needed - the CFI driver should use correct
accessor macros instead. See
Documentation/volatile-considered-harmful.txt in your Linux kernel
source 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: wd at denx.de
No one wants war.
	-- Kirk, "Errand of Mercy", stardate 3201.7



From r.schwebel at pengutronix.de  Tue Apr 29 22:55:54 2008
From: r.schwebel at pengutronix.de (Robert Schwebel)
Date: Tue, 29 Apr 2008 22:55:54 +0200
Subject: [U-Boot-Users] Problems with 1.3.3-rc1 on i.MX31ADS
In-Reply-To: <1209243964.4426.19.camel@felix.lan>
References: <1209243964.4426.19.camel@felix.lan>
Message-ID: <20080429205554.GE13814@pengutronix.de>

On Sun, Apr 27, 2008 at 12:06:04AM +0300, Felix Radensky wrote:
> Thanks for adding i.mx31 support to u-boot. Hopefully i.mx27 support
> will follow soon.

i.MX27 is supported in u-boot-v2.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9




From adrian.filipi at eurotech.com  Tue Apr 29 23:10:40 2008
From: adrian.filipi at eurotech.com (Adrian Filipi)
Date: Tue, 29 Apr 2008 17:10:40 -0400 (EDT)
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <20080429204348.1ED4C247B4@gemini.denx.de>
References: <20080429204348.1ED4C247B4@gemini.denx.de>
Message-ID: <alpine.DEB.1.10.0804291703010.13610@pmy.adscville>


 	Sure, reducing the reliance on volatile is a good idea, but I'm at 
a loss for anything better to do.

 	I'm seeing a real problem that is only fixed by qualifying the 
container of the pointer as volatile, i.e. "void *volatile".  "volatile 
void *" has no effect as expected given that the read/write accessors are 
used now.

 	The old data type was essentially "volatile void *volatile addr" 
and the new type is simply "void *addr".  I seem to need at least "void 
*volatile addr" for things to work.

 	Note, I'm only seeing this problem on our PXA250 boards.

 	Adrian
--
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com

On Tue, 29 Apr 2008, Wolfgang Denk wrote:

> In message <alpine.DEB.1.10.0804291604250.32753 at pmy.adscville> you wrote:
>>
>>  	I narrowed down the source of the problem to the loss of the
>> volatile qualifier on the addr pointer in flash_write_cmd().  Adding the
>> qualifier gets rid of the corruption.  In the older 1.2.0 sources, addr was
>> declared as "volatile cfiptr_t addr;".
>
> The volatile should not be needed - the CFI driver should use correct
> accessor macros instead. See
> Documentation/volatile-considered-harmful.txt in your Linux kernel
> source tree...
>
> Best regards,
>
> Wolfgang Denk
>
>



From gerald.vanbaren at ge.com  Tue Apr 29 23:16:49 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Tue, 29 Apr 2008 17:16:49 -0400
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <alpine.DEB.1.10.0804291703010.13610@pmy.adscville>
References: <20080429204348.1ED4C247B4@gemini.denx.de>
	<alpine.DEB.1.10.0804291703010.13610@pmy.adscville>
Message-ID: <48179041.6080008@ge.com>

Adrian Filipi wrote:
> On Tue, 29 Apr 2008, Wolfgang Denk wrote:
> 
>> In message <alpine.DEB.1.10.0804291604250.32753 at pmy.adscville> you wrote:
>>>  	I narrowed down the source of the problem to the loss of the
>>> volatile qualifier on the addr pointer in flash_write_cmd().  Adding the
>>> qualifier gets rid of the corruption.  In the older 1.2.0 sources, addr was
>>> declared as "volatile cfiptr_t addr;".
>> The volatile should not be needed - the CFI driver should use correct
>> accessor macros instead. See
>> Documentation/volatile-considered-harmful.txt in your Linux kernel
>> source tree...
>>
>> Best regards,
>>
>> Wolfgang Denk
> 
>  	Sure, reducing the reliance on volatile is a good idea, but I'm at 
> a loss for anything better to do.
> 
>  	I'm seeing a real problem that is only fixed by qualifying the 
> container of the pointer as volatile, i.e. "void *volatile".  "volatile 
> void *" has no effect as expected given that the read/write accessors are 
> used now.
> 
>  	The old data type was essentially "volatile void *volatile addr" 
> and the new type is simply "void *addr".  I seem to need at least "void 
> *volatile addr" for things to work.
> 
>  	Note, I'm only seeing this problem on our PXA250 boards.
> 
>  	Adrian

Hi Adrian,

Please bottom post.

It may be useful to disassemble cfi_flash.o file (objdump -S) and see 
what the two different configurations of flash_write_cmd() get turned 
into in assembly.

Best regards,
gvb



From wd at denx.de  Tue Apr 29 23:43:51 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 23:43:51 +0200
Subject: [U-Boot-Users] Pull request - net
In-Reply-To: Your message of "Mon, 28 Apr 2008 22:42:14 PDT."
	<4816B536.6040400@gmail.com>
Message-ID: <20080429214351.66F5324681@gemini.denx.de>

In message <4816B536.6040400 at gmail.com> you wrote:
> Wolfgang,
> 
> The following changes since commit dd5748bcd669f46aeb6686c1b341323843738ccc:
>   Guennadi Liakhovetski (1):
>         rtl8169: fix compiler warnings
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-net.git master
> 
> Guennadi Liakhovetski (2):
>       minor cs8900 driver clean up
>       net: make ARP timeout configurable
> 
> Jean-Christophe PLAGNIOL-VILLARD (1):
>       NE2000: Fix regresssion introduced by e710185aae90 on non AX88796
> 
>  README                    |    4 +
>  drivers/net/Makefile      |    5 +-
>  drivers/net/ax88796.c     |  156 +++++++++++++++++++++++++++++++++++++++++++++
>  drivers/net/ax88796.h     |  136 ---------------------------------------
>  drivers/net/cs8900.c      |   15 ++--
>  drivers/net/cs8900.h      |    1 -
>  drivers/net/ne2000.c      |   94 ++++++++++++++++++++++++++-
>  drivers/net/ne2000.h      |   87 +-------------------------
>  drivers/net/ne2000_base.h |    1 -
>  net/net.c                 |   23 +++++--
>  10 files changed, 280 insertions(+), 242 deletions(-)
>  create mode 100644 drivers/net/ax88796.c

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: wd at denx.de
Live long and prosper.
	-- Spock, "Amok Time", stardate 3372.7



From wd at denx.de  Tue Apr 29 23:49:26 2008
From: wd at denx.de (Wolfgang Denk)
Date: Tue, 29 Apr 2008 23:49:26 +0200
Subject: [U-Boot-Users] 1.3.3-rc2 - release status
Message-ID: <20080429214926.744C624681@gemini.denx.de>

Hello,

U-Boot v1.3.3-rc2 has just been released.

PowerPC seems to be in a pretty good state now;  other  architectures
still  need a lot of testing / fixing. For example, on ARM we see the
following conflicts:

Configuring for kb9202 board...
start.S: Assembler messages:
start.S:205: Error: invalid constant -- `sub r0,r0,#(0x0200+128*1024)'
start.S:378: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
start.S:379: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
start.S:384: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
start.S:385: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
start.S:390: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
start.S:391: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
start.S:396: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
start.S:397: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
start.S:402: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
start.S:403: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
start.S:427: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
start.S:428: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
start.S:433: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
start.S:434: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
make[1]: *** [start.o] Error 1


Configuring for netstar board...
arm-linux-ld: cannot find -lgeneric
make[1]: *** [eeprom.srec] Error 1


Configuring for voiceblue board...
arm-linux-ld: cannot find -lgeneric
make[1]: *** [eeprom.srec] Error 1


Configuring for apollon board...
onenand_base.c:25: error: static declaration of 'memcpy' follows non-static declaration
/home/wd/git/u-boot/master/include/linux/string.h:70: error: previous declaration of 'memcpy' was here
make[1]: *** [onenand_base.o] Error 1


Configuring for adsvix board...
start.S:183:1: warning: "ICMR" redefined
In file included from start.S:33:
/home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:935:1: warning: this is the location of the previous definition
start.S:187:1: warning: "RCSR" redefined
/home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:1602:1: warning: this is the location of the previous definition
start.S:191:1: warning: "OSMR3" redefined
/home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:869:1: warning: this is the location of the previous definition
start.S:192:1: warning: "OSCR" redefined
/home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:870:1: warning: this is the location of the previous definition
start.S:193:1: warning: "OWER" redefined
/home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:872:1: warning: this is the location of the previous definition
start.S:194:1: warning: "OIER" redefined
/home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:873:1: warning: this is the location of the previous definition
start.S:207:1: warning: "CCCR" redefined
/home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:1770:1: warning: this is the location of the previous definition
pcmcia.c:39:2: warning: #warning "Board will only supply 5V, wait for next HW spin for selectable power"
pxa_pcmcia.c: In function 'pcmcia_on':
pxa_pcmcia.c:39: warning: operation on 'i' may be undefined
cmd_ide.c: In function '__ide_outb':
cmd_ide.c:828: warning: implicit declaration of function 'outb'
cmd_ide.c: In function '__ide_inb':
cmd_ide.c:837: warning: implicit declaration of function 'inb'
common/libcommon.a(cmd_ide.o): In function `__ide_outb':
/home/wd/git/u-boot/master/common/cmd_ide.c:828: undefined reference to `outb'
common/libcommon.a(cmd_ide.o): In function `__ide_inb':
/home/wd/git/u-boot/master/common/cmd_ide.c:837: undefined reference to `inb'
make: *** [u-boot] Error 1


Configuring for actux4 board...
actux4.c: In function 'board_init':
actux4.c:83: warning: left shift count >= width of type
actux4.c:83: warning: left shift count >= width of type


Configuring for davinci_schmoogie board...
env_nand.c: In function 'saveenv':
env_nand.c:200: warning: passing argument 3 of 'nand_write' from incompatible pointer type
env_nand.c: In function 'env_relocate_spec':
env_nand.c:275: warning: passing argument 3 of 'nand_read' from incompatible pointer type



Board maintainers / custodians - please help!


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_



From info at fuarlar.us  Wed Apr 30 02:50:11 2008
From: info at fuarlar.us (=?iso-8859-9?B?T2t5YW51cyBGdWFyY/1s/Ws=?=)
Date: Wed, 30 Apr 2008 03:50:11 +0300
Subject: [U-Boot-Users] =?iso-8859-9?q?=D6zel_Stand_Tasar=FDmlar=FDn=FDz_H?=
	=?iso-8859-9?q?akk=FDnda?=
Message-ID: <0c36cb2b528f8d6ac833e8c3393e3785@fuarlar.us>








 .headerTop { background-color:#FFFFFF; border-top:0px solid #000000; border-bottom:1px solid #FFFFFF; text-align:center; }
 .adminText { font-size:10px; color:#FFFFFF; line-height:200%; font-family:verdana; text-decoration:none; }
 .headerBar { background-color:#FFFFFF; border-top:0px solid #333333; border-bottom:10px solid #FFFFFF; }
 .title { font-size:20px; font-weight:bold; color:#CC6600; font-family:arial; line-height:110%; }
 .subTitle { font-size:11px; font-weight:normal; color:#666666; font-style:italic; font-family:arial; }
 td { font-size:12px; color:#000000; line-height:150%; font-family:trebuchet ms; }
 .sideColumn { background-color:#FFFFFF; border-left:1px dashed #CCCCCC; text-align:left; }
 .sideColumnText { font-size:11px; font-weight:normal; color:#999999; font-family:arial; line-height:150%; }
 .sideColumnTitle { font-size:15px; font-weight:bold; color:#333333; font-family:arial; line-height:150%; }
 .footerRow { background-color:#FFFFCC; border-top:10px solid #FFFFFF; }
 .footerText { font-size:10px; color:#FFFFFF; line-height:100%; font-family:verdana; }
 a { color:#FF6600; color:#FF6600; color:#FF6600; }











  
    www.okyanusfuar.com.tr 
  

   






  
 










S&#304;Z HAYAL ED&#304;N, B&#304;Z TASARLAYALIM! 

Kat?ld???n?z fuarlarda farkl? olun..! 

Fuarlar, firmalar i&ccedil;in yeni pazarlara ula?ma, mevcut pazardaki g&uuml;c&uuml;n&uuml; ve pay?n? artt?rma amac?yla yap?lan en etkin pazarlama y&ouml;ntemidir. Bu ama&ccedil;la yer ald???n?z fuarlarda firman?z?n fark edilmesi, 100'lerce firma aras?ndan ay?rtedilmesi i&ccedil;in kendinize ait stand?n?z?n olmas? &ccedil;ok &ouml;nemlidir. Okyanus Fuarc?l?k , firman?za &ouml;zel tasar?mlar? hayata ge&ccedil;iriyor... 

  Firmam?zda, Avrupa'da da en yayg?n olarak kullan?lan MERO S?STEM Standlar ve AH?AP TASARIM  Standlar mevcuttur. 

  Firman?z?n kat?laca?? fuarlar i&ccedil;in, fuar &ouml;ncesi &ccedil;al??malar aras?nda en fazla zaman alan &ccedil;al??malar olan &Ouml;ZEL STAND TASARIMLARINIZ konusunda, firmam?zdan stand &ccedil;izimi ve teklif alman?z? rica eder, &ccedil;al??malar?n?zda ba?ar?lar dileriz. 

Sayg?lar?m?zla, 
 


  
    TASARIMLARIMIZDAN &Ouml;RNEKLER  
  

 











  
     
        Siz hayal edin, biz tasarlayal&#305;m 
         
  

  
                                                                 






        
          
            
              
                  
                    
                        
                          

                            Yapt&#305;rmay&#305; planlad&#305;&#287;&#305;n&#305;z &ouml;zel stand&#305;n&#305;z ile ilgili sizinle irtibata ge&ccedil;memiz i&ccedil;in l&uuml;tfen a&#351;a&#287;&#305;daki formu doldurunuz. 

                             
 
                        

                     
                  

                
                 
          

          
            
              
                
                   &#304;leti&#351;im Formu  
                

                
                   Firma ad&#305; 
                   
                    
                   
                

                
                   Yetkili Ad&#305;  
                   
                    
                   
                

                
                   Sehir 
                   
                    
                   
                  

                            
                   Telefon  
                   
                    
                   
                

                
                   e-mail 
                   
                    
                   
                

                
                   Web Adresi 
                   
                    
                   
                
 
                  A&ccedil;&#305;klama 
                   
                    
 
                  

                
                    
                   

                          
                          
                   
                

             
          

          
              
          

        
     
  


 



  
    
      Okyanus Fuarc&#305;l&#305;k A.&#350;. 
 
    

    
      Meridyen &#304;&#351; Merkezi 

        Ali R&#305;za G&uuml;rcan Cad. No:1/540 

        Merter &#304;STANBUL/TURKEY 

        Tel:


 0212 483 25 61 pbx 

Faks: 0212 483 41 59 

        info at okyanusfuar.com.tr          
    

   




 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20080430/02abf515/attachment.htm 

From Bruce_Leonard at selinc.com  Wed Apr 30 03:53:24 2008
From: Bruce_Leonard at selinc.com (Bruce_Leonard at selinc.com)
Date: Tue, 29 Apr 2008 18:53:24 -0700
Subject: [U-Boot-Users] 83xx DDR2 667Mhz memory
In-Reply-To: <000001c8a641$eac1beb0$e505a8c0@absolutdaddy>
Message-ID: <OF7987C686.A230C7C7-ON8825743B.00099DD3-8825743B.000A6222@selinc.com>

> 
> Any ideas? Again, same exact u-boot just different memory. SPD sees it 
all
> just fine, just can't use the RAM after its setup. Currently using a
> slightly older version of U-boot 1.3.0-dirty.
> 
> -Russ
> 

Hi Russ,

I don't know what the current state is (I'm running a slightly older 
version than you), but we ran into a problem with the 83xx SPD code being 
able to recognize faster DDR2 memories.  There was a whole series of 
nested if/else if statements figuring out if it was DDR400, DDR333, etc., 
and then figuring out effective data rates and CAS latencies from that. 
What we ran into was that (at the time) it would only figure out upto 
DDR400 and we're using 533.  Since we're only using the one speed of RAM 
for this release of the product we just hardcoded values into registers 
and decided to look at fixing SPD later.  Don't know if anyone else has 
yet.  Know it doesn't help you much, but it gives you some place to look 
:(.

Bruce



From admin at mycareer.com.au  Wed Apr 30 07:09:29 2008
From: admin at mycareer.com.au (admin at mycareer.com.au)
Date: Wed, 30 Apr 2008 08:09:29 +0300
Subject: [U-Boot-Users] Don't Miss This Offer! Make 10% comission.
Message-ID: <865114164.20071104112058@mycareer.com.au>

Welcome to the WPP Group!
We are very glad that you wish to join our team, will be delighted to have you work with us 
The position of "Representative" provides support filling the transactions of our customers.
We deal exclusively with private clients,- that have special requirements for high speed of receiving funds for their business . 
This way we can offer a new kind of financial and banking service to our clients - and we
would like you to work as an "Representative".(part-time job 2-3 hours a day except holidays)
At first your work would be very basic, yet meticulous -you will make transfers for our clients to suit their needs. Our managers will assist you during the trial period and explain everything you will need to know.  We offer an extremely competitive graduated salary: for the first month you will receive up to $3500 AUD for your work the next month your salary will be increased if you do your work accurately and on time. Now you are only one step away from successful career. 
 
If you meet all requirements - don't hesitate to get more information on this great position called "Fund Operator".
Reply to: brilliant.deal at gmail.com with  subject "Interested" " Job Offer" to receive full information on this great position. Limited time offer, don't wait! And Good luck.
 
Thank you in advance,
Jennifer Mellea HR Manager.
WPP Finance.Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.gif
Type: image/gif
Size: 5361 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080430/ea8f088f/attachment.gif 

From sew_s at tqs.de  Wed Apr 30 07:20:52 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Wed, 30 Apr 2008 07:20:52 +0200
Subject: [U-Boot-Users] [PATCH] net: add 16 bit support for smc911x
In-Reply-To: <Pine.LNX.4.64.0804292208520.8498@axis700.grange>
References: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>
	<Pine.LNX.4.64.0804292208520.8498@axis700.grange>
Message-ID: <481801B4.10500@tqs.de>

Guennadi Liakhovetski schrieb:
> On Tue, 29 Apr 2008, Jens Gehrlein wrote:
> 
>> Hi Ben, Magnus,
>>
>> here is my patch to enable 2x16 bit accesses to the LAN9x1x.
>> I still not have a HW, so may I ask you to test it and, if applicable,
>> fix the code?
>>
>> Best Regards,
>> Jens
>>
>> ---
>>
>>  drivers/net/smc911x.c |   17 ++++++++++++++++-
>>  1 files changed, 16 insertions(+), 1 deletions(-)
>>
>>
>> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
>> index d22c889..841a64d 100644
>> --- a/drivers/net/smc911x.c
>> +++ b/drivers/net/smc911x.c
>> @@ -30,6 +30,8 @@
>>  #include <net.h>
>>  #include <miiphy.h>
>>  
>> +#define CONFIG_DRIVER_SMC911X_16_BIT 1
>> +
> 
> Looks like an obvious thing - you'll remove this define from the patch for 
> final submission, right?

Oh, ah. You're right. I inserted this to do a compile test and to 
inspect the generated assembler code. This define should be later moved 
to the board specific header file.

Sorry.

Well spotted. Thank you.

Magnus, are you going to fix the code as proposed by Ben and Guennadi or 
  should I resubmit the patch?

Best Regards,
Jens



From biggerbadderben at gmail.com  Wed Apr 30 08:11:28 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Tue, 29 Apr 2008 23:11:28 -0700
Subject: [U-Boot-Users] [PATCH] net: add 16 bit support for smc911x
In-Reply-To: <481801B4.10500@tqs.de>
References: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>	<Pine.LNX.4.64.0804292208520.8498@axis700.grange>
	<481801B4.10500@tqs.de>
Message-ID: <48180D90.5080705@gmail.com>

Hi Jens,

Jens Gehrlein wrote:
> Guennadi Liakhovetski schrieb:
>   
>> On Tue, 29 Apr 2008, Jens Gehrlein wrote:
>>
>>     
>>> Hi Ben, Magnus,
>>>
>>> here is my patch to enable 2x16 bit accesses to the LAN9x1x.
>>> I still not have a HW, so may I ask you to test it and, if applicable,
>>> fix the code?
>>>
>>> Best Regards,
>>> Jens
>>>
>>> ---
>>>
>>>  drivers/net/smc911x.c |   17 ++++++++++++++++-
>>>  1 files changed, 16 insertions(+), 1 deletions(-)
>>>
>>>
>>> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
>>> index d22c889..841a64d 100644
>>> --- a/drivers/net/smc911x.c
>>> +++ b/drivers/net/smc911x.c
>>> @@ -30,6 +30,8 @@
>>>  #include <net.h>
>>>  #include <miiphy.h>
>>>  
>>> +#define CONFIG_DRIVER_SMC911X_16_BIT 1
>>> +
>>>       
>> Looks like an obvious thing - you'll remove this define from the patch for 
>> final submission, right?
>>     
>
> Oh, ah. You're right. I inserted this to do a compile test and to 
> inspect the generated assembler code. This define should be later moved 
> to the board specific header file.
>
> Sorry.
>
> Well spotted. Thank you.
>
> Magnus, are you going to fix the code as proposed by Ben and Guennadi or 
>   should I resubmit the patch?
>   
Ultimately, somebody needs to submit a patch.  Since Magnus won't try it 
til later this week, it would be best if you post a patch incorporating 
changes.  Then if it works, we're ready to go.

regards,
Ben



From felix at embedded-sol.com  Wed Apr 30 08:52:01 2008
From: felix at embedded-sol.com (Felix Radensky)
Date: Wed, 30 Apr 2008 09:52:01 +0300
Subject: [U-Boot-Users] Problems with 1.3.3-rc1 on i.MX31ADS
In-Reply-To: <20080429205554.GE13814@pengutronix.de>
References: <1209243964.4426.19.camel@felix.lan>
	<20080429205554.GE13814@pengutronix.de>
Message-ID: <1209538321.11420.2.camel@felix.lan>

Hi, Robert,

Thanks for the info. What are the plans u-boot-v2 ?
Is going to become u-boot mainline in the near future ?
How difficult do you think would be to port i.mx27 code
to u-boot 1.3.

Thanks.

Felix.

On Tue, 2008-04-29 at 22:55 +0200, Robert Schwebel wrote:
> On Sun, Apr 27, 2008 at 12:06:04AM +0300, Felix Radensky wrote:
> > Thanks for adding i.mx31 support to u-boot. Hopefully i.mx27 support
> > will follow soon.
> 
> i.MX27 is supported in u-boot-v2.
> 
> Robert




From sr at denx.de  Wed Apr 30 14:52:09 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 30 Apr 2008 14:52:09 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Adapt Canyonlands fixed DDR2 setup
	to new DIMM module
Message-ID: <1209559929-32734-1-git-send-email-sr@denx.de>

This patch changes the Canyonlands/Glacier fixed DDR2 controller setup
used for NAND booting to match the values needed for the new 512MB
DIMM modules shipped with the productions boards:

Crucial: CT6464AC667.8FB

Signed-off-by: Stefan Roese <sr at denx.de>
---
 nand_spl/board/amcc/canyonlands/ddr2_fixed.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/nand_spl/board/amcc/canyonlands/ddr2_fixed.c b/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
index 79f3b0f..9010fca 100644
--- a/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
+++ b/nand_spl/board/amcc/canyonlands/ddr2_fixed.c
@@ -49,20 +49,21 @@ long int initdram(int board_type)
 	 * enabled. This will only work for the same memory
 	 * configuration as used here:
 	 *
-	 * Crucial CT6464AC53E.4FE - 512MB SO-DIMM
+	 * Crucial CT6464AC667.8FB - 512MB SO-DIMM
 	 *
 	 */
 	mtsdram(SDRAM_MCOPT2, 0x00000000);
-	mtsdram(SDRAM_MCOPT1, 0x05322000);
+	mtsdram(SDRAM_MCOPT1, 0x05122000);
 	mtsdram(SDRAM_MODT0, 0x01000000);
-	mtsdram(SDRAM_CODT, 0x00800021);
+	mtsdram(SDRAM_CODT, 0x02800021);
 	mtsdram(SDRAM_WRDTR, 0x82000823);
 	mtsdram(SDRAM_CLKTR, 0x40000000);
 	mtsdram(SDRAM_MB0CF, 0x00000201);
+	mtsdram(SDRAM_MB1CF, 0x00000201);
 	mtsdram(SDRAM_RTR, 0x06180000);
 	mtsdram(SDRAM_SDTR1, 0x80201000);
 	mtsdram(SDRAM_SDTR2, 0x42103243);
-	mtsdram(SDRAM_SDTR3, 0x0A0D0D1A);
+	mtsdram(SDRAM_SDTR3, 0x0A0D0D16);
 	mtsdram(SDRAM_MMODE, 0x00000632);
 	mtsdram(SDRAM_MEMODE, 0x00000040);
 	mtsdram(SDRAM_INITPLR0, 0xB5380000);
@@ -86,7 +87,8 @@ long int initdram(int board_type)
 
 	wait_init_complete();
 
-	mtdcr(SDRAM_R0BAS, 0x0000F000);		/* MQ0_B0BAS */
+	mtdcr(SDRAM_R0BAS, 0x0000F800);		/* MQ0_B0BAS */
+	mtdcr(SDRAM_R1BAS, 0x0400F800);		/* MQ0_B1BAS */
 
 	mtsdram(SDRAM_RDCC, 0x40000000);
 	mtsdram(SDRAM_RQDC, 0x80000038);
-- 
1.5.5.1




From peter.pearse at arm.com  Wed Apr 30 10:50:20 2008
From: peter.pearse at arm.com (Peter Pearse)
Date: Wed, 30 Apr 2008 09:50:20 +0100
Subject: [U-Boot-Users] FW:  1.3.3-rc2 - release status
Message-ID: <000101c8aa9f$38ae5410$3a4d010a@Emea.Arm.com>

 

> -----Original Message-----
> From: Peter Pearse [mailto:peter.pearse at arm.com] 
> Sent: 30 April 2008 09:50
> To: 'Wolfgang Denk'
> Subject: RE: [U-Boot-Users] 1.3.3-rc2 - release status
> 
>  
> 
> > -----Original Message-----
> > From: u-boot-users-bounces at lists.sourceforge.net
> > [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf Of 
> > Wolfgang Denk
> > Sent: 29 April 2008 22:49
> > To: u-boot-users at lists.sourceforge.net
> > Subject: [U-Boot-Users] 1.3.3-rc2 - release status
> > 
> > Hello,
> > 
> > U-Boot v1.3.3-rc2 has just been released.
> > 
> > PowerPC seems to be in a pretty good state now;  other 
> architectures 
> > still  need a lot of testing / fixing. For example, on ARM 
> we see the 
> > following conflicts:
> > 
> 
> --- snip ---
> > 
> > 
> > Configuring for netstar board...
> > arm-linux-ld: cannot find -lgeneric
> > make[1]: *** [eeprom.srec] Error 1
> > 
> > 
> > Configuring for voiceblue board...
> > arm-linux-ld: cannot find -lgeneric
> > make[1]: *** [eeprom.srec] Error 1
> > 
> 
> Wolfgang
> 
> 	I dont see the netstar or voiceblue failures with my 
> installations of 
> 
> arm-linux-gcc (GCC) 4.0.0 (DENX ELDK 4.0 4.0.0)
> 
> arm-linux-gcc (GCC) 3.4.2 (release) (CodeSourcery ARM Q3 2004)
> 
> , using the code obtained with git clone 
> git://www.denx.de/git/u-boot.git.
> 
> 
> Regards
> 
> Peter





From mk at denx.de  Wed Apr 30 10:34:11 2008
From: mk at denx.de (Markus =?utf-8?Q?Klotzb=C3=BCcher?=)
Date: Wed, 30 Apr 2008 10:34:11 +0200
Subject: [U-Boot-Users] Setting processor endianess for USB modules
In-Reply-To: <48177904.16185.58C770@ceggers.gmx.de> (Christian Eggers's
	message of "Tue\, 29 Apr 2008 19\:37\:40 +0200")
References: <48177904.16185.58C770@ceggers.gmx.de>
Message-ID: <878wyvvj0c.fsf@denx.de>

Dear Christian,

"Christian Eggers" <ceggers at gmx.de> writes:

> I've recognized that a lot of USB code in U-Boot uses the macros
> swap_16() and swap_32() which are defined in usb.h. The behaviour
> of the macros is controlled by the define LITTLEENDIAN.
>
> Is there a good reason NOT to use the macros provided in
> asm/byteorder.h (as in the appropriate code in Linux-2.4 )? 

Largely not. But be carefull. Besides big and little endian CPUs we also
have controllers that operate in big or little endian (see
CFG_OHCI_BE_CONTROLLER), and then there are PCI controllers whose
registers need to be accessed as little endian
(CFG_OHCI_SWAP_REG_ACCESS).

But your right, there is no real for LITTLEENDIAN.

> I think that switching to these functions might be useful in order
> to eliminate the need to use the LITTLEENDIAN define for
> specifying the byteorder. It seems that LITTLEENDIAN is not
> used outside the USB code.

Right. Patches cleaning this up are more than welcome! Please note that
cleaning up USB drivers under the cpu/ directory is a waste of time
though. Boards using these drivers should be converted to use the
generic infrastructure in drivers/usb/ instead.

Best regards

Markus Klotzbuecher

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



From Sascha.Laue at gmx.biz  Wed Apr 30 15:16:35 2008
From: Sascha.Laue at gmx.biz (Sascha Laue)
Date: Wed, 30 Apr 2008 15:16:35 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification
Message-ID: <20080430131635.311880@gmx.net>

Hello Wolfgang,

I've found this merge-merge-error.

best regards
Sascha Laue

From: Sascha Laue <sascha.laue at liebherr.com>
Date: Wed, 30 Apr 2008 12:27:21 +0200
Subject: [PATCH] fix manual merge error in lwmon5 posttest.

Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
---
 post/board/lwmon5/sysmon.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
index 793f670..23cb709 100644
--- a/post/board/lwmon5/sysmon.c
+++ b/post/board/lwmon5/sysmon.c
@@ -132,7 +132,7 @@ static sysmon_table_t sysmon_table[] =

        {
        "+ 5 V", "V", &sysmon_dspic, NULL, NULL,
-       100, 1000, 0, 0xFFFF, 0xFFFF,
+       100, 1000, -0x8000, 0x7FFF, 0xFFFF,
        VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0,
        VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0,
        REG_VOLTAGE_5V,
@@ -140,7 +140,7 @@ static sysmon_table_t sysmon_table[] =

        {
        "+ 5 V standby", "V", &sysmon_dspic, NULL, NULL,
-       100, 1000, 0, 0xFFFF, 0xFFFF,
+       100, 1000, -0x8000, 0x7FFF, 0xFFFF,
        VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX, 0,
        VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX, 0,
        REG_VOLTAGE_5V_STANDBY,
--
1.5.2.4


-------- Original-Nachricht --------
> Datum: Mon, 28 Apr 2008 22:41:39 +0200
> Von: Wolfgang Denk <wd at denx.de>
> An: "Sascha Laue" <Sascha.Laue at gmx.biz>
> CC: marcel.brasch at liebherr.com, u-boot-users at lists.sourceforge.net, mk at denx.de
> Betreff: Re: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification

> In message <20080401075646.145810 at gmx.net> you wrote:
> >
> > sorry but it's the first time for me.
> > let's try again.
> >
> > we modified the specification for the lwmon5 board dspic POST.
> > Additionally I have add defines for the temperature- and voltagevalues.
> >
> > Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> > ---
> >  post/board/lwmon5/sysmon.c |   39
> ++++++++++++++++++++++++++++++---------
> >  1 files changed, 30 insertions(+), 9 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: wd at denx.de
> Committee, n.:  A group of men who individually can do nothing but as
> a group decide that nothing can be done.                 - Fred Allen



From wd at denx.de  Wed Apr 30 15:21:07 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 15:21:07 +0200
Subject: [U-Boot-Users] FW: 1.3.3-rc2 - release status
In-Reply-To: Your message of "Wed, 30 Apr 2008 09:50:20 BST."
	<000101c8aa9f$38ae5410$3a4d010a@Emea.Arm.com>
Message-ID: <20080430132107.57DE824681@gemini.denx.de>

In message <000101c8aa9f$38ae5410$3a4d010a at Emea.Arm.com> you wrote:
>  
> > Configuring for netstar board...
> > arm-linux-ld: cannot find -lgeneric
> > make[1]: *** [eeprom.srec] Error 1
> > 
> > Configuring for voiceblue board...
> > arm-linux-ld: cannot find -lgeneric
> > make[1]: *** [eeprom.srec] Error 1
...
> 	I dont see the netstar or voiceblue failures with my 
> installations of 
> 
> arm-linux-gcc (GCC) 4.0.0 (DENX ELDK 4.0 4.0.0)
> arm-linux-gcc (GCC) 3.4.2 (release) (CodeSourcery ARM Q3 2004)
> 
> , using the code obtained with git clone 
> git://www.denx.de/git/u-boot.git.

You probably didn't try running something like

	JOBS='-j4' ./MAKEALL netstar

on a SMP machine.

It turns out that the failing boards have (somewhat suspicious)
dependencies on other libraries which are not taken care of in the
Makefiles.

I'm working on a patch.

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: wd at denx.de
Drun'? 'm not drun'! You woudn' dare call m' drun' if I was sober!
                                     - Terry Pratchett, _Men at Arms_



From j.holzman at genesysdesign.com.au  Wed Apr 30 10:44:58 2008
From: j.holzman at genesysdesign.com.au (Jared Holzman)
Date: Wed, 30 Apr 2008 18:44:58 +1000
Subject: [U-Boot-Users] [PATCH 1/1] Added preliminary support for the
	AT91SAM9263-EK. The following has been tested:
Message-ID: <12095450983375-git-send-email-j.holzman@genesysdesign.com.au>

diff --git a/Makefile b/Makefile
index 4688a26..36feb00 100644
--- a/Makefile
+++ b/Makefile
@@ -2347,6 +2347,9 @@ at91cap9adk_config	:	unconfig
 at91sam9260ek_config	:	unconfig
 	@$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9260ek atmel at91sam9
 
+at91sam9263ek_config	:	unconfig
+	@$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9263ek atmel at91sam9
+
 ########################################################################
 ## ARM Integrator boards - see doc/README-integrator for more info.
 integratorap_config	\
diff --git a/board/atmel/at91sam9263ek/Makefile b/board/atmel/at91sam9263ek/Makefile
new file mode 100644
index 0000000..ca87a4c
--- /dev/null
+++ b/board/atmel/at91sam9263ek/Makefile
@@ -0,0 +1,53 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, wd <at> denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB	= $(obj)lib$(BOARD).a
+
+COBJS-y	+= at91sam9263ek.o
+COBJS-y	+= led.o
+COBJS-y	+= partition.o
+COBJS-$(CONFIG_CMD_NAND) += nand.o
+
+SRCS	:= $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS	:= $(addprefix $(obj),$(COBJS-y))
+SOBJS	:= $(addprefix $(obj),$(SOBJS))
+
+$(LIB):	$(obj).depend $(OBJS) $(SOBJS)
+	$(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+	rm -f $(SOBJS) $(OBJS)
+
+distclean:	clean
+	rm -f $(LIB) core *.bak .depend
+
+#########################################################################
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#########################################################################
diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c b/board/atmel/at91sam9263ek/at91sam9263ek.c
new file mode 100644
index 0000000..b047209
--- /dev/null
+++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
@@ -0,0 +1,230 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop <stelian.pop <at> leadtechdesign.com>
+ * Lead Tech Design <www.leadtechdesign.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/arch/at91sam9263.h>
+#include <asm/arch/at91sam9263_matrix.h>
+#include <asm/arch/at91sam926x_mc.h>
+#include <asm/arch/at91_pmc.h>
+#include <asm/arch/at91_rstc.h>
+#include <asm/arch/gpio.h>
+#include <asm/arch/io.h>
+#if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_MACB)
+#include <net.h>
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* ------------------------------------------------------------------------- */
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+
+static void at91sam9263ek_serial_hw_init(void)
+{
+#ifdef CONFIG_USART0
+	at91_set_A_periph(AT91_PIN_PA26, 1);		/* TXD0 */
+	at91_set_A_periph(AT91_PIN_PA27, 0);		/* RXD0 */
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US0);
+#endif
+
+#ifdef CONFIG_USART1
+	at91_set_A_periph(AT91_PIN_PD0, 1);		/* TXD1 */
+	at91_set_A_periph(AT91_PIN_PD1, 0);		/* RXD1 */
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US1);
+#endif
+
+#ifdef CONFIG_USART2
+	at91_set_A_periph(AT91_PIN_PD2, 1);		/* TXD2 */
+	at91_set_A_periph(AT91_PIN_PD3, 0);		/* RXD2 */
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_US2);
+#endif
+
+#ifdef CONFIG_USART3	/* DBGU */
+	at91_set_A_periph(AT91_PIN_PC30, 0);		/* DRXD */
+	at91_set_A_periph(AT91_PIN_PC31, 1);		/* DTXD */
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91_ID_SYS);
+#endif
+}
+
+#ifdef CONFIG_CMD_NAND
+static void at91sam9263ek_nand_hw_init(void)
+{
+	unsigned long csa;
+
+	/* Enable CS3 */
+	csa = at91_sys_read(AT91_MATRIX_CSA);
+	at91_sys_write(AT91_MATRIX_CSA,
+		       csa | AT91_MATRIX_CS3A_SMC_SMARTMEDIA);
+
+	/* Configure SMC CS3 for NAND/SmartMedia */
+	at91_sys_write(AT91_SMC_SETUP(3),
+		       AT91_SMC_NWESETUP_(0) | AT91_SMC_NCS_WRSETUP_(0) |
+		       AT91_SMC_NRDSETUP_(0) | AT91_SMC_NCS_RDSETUP_(0));
+	at91_sys_write(AT91_SMC_PULSE(3),
+		       AT91_SMC_NWEPULSE_(3) | AT91_SMC_NCS_WRPULSE_(3) |
+		       AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3));
+	at91_sys_write(AT91_SMC_CYCLE(3),
+		       AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5));
+	at91_sys_write(AT91_SMC_MODE(3),
+		       AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
+		       AT91_SMC_EXNWMODE_DISABLE |
+		       AT91_SMC_DBW_8 | AT91_SMC_TDF_(2));
+
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOA);
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOCDE);
+
+	/* Configure RDY/BSY */
+	at91_set_gpio_input(AT91_PIN_PA22, 1);
+
+	/* Enable NandFlash */
+	at91_set_gpio_output(AT91_PIN_PD15, 1);
+}
+#endif
+
+#ifdef CONFIG_HAS_DATAFLASH
+static void at91sam9263ek_spi_hw_init(void)
+{
+	at91_set_B_periph(AT91_PIN_PA5, 0);	/* SPI0_NPCS0 */
+	at91_set_B_periph(AT91_PIN_PA3, 0);	/* SPI0_NPCS1 */
+
+	at91_set_B_periph(AT91_PIN_PA0, 0);	/* SPI0_MISO */
+	at91_set_B_periph(AT91_PIN_PA1, 0);	/* SPI0_MOSI */
+	at91_set_B_periph(AT91_PIN_PA2, 0);	/* SPI0_SPCK */
+
+	/* Enable clock */
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_SPI0);
+}
+#endif
+
+#ifdef CONFIG_MACB
+static void at91sam9263ek_macb_hw_init(void)
+{
+	/* Enable clock */
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_EMAC);
+
+	/*
+	 * Disable pull-up on:
+	 *	RXDV (PC25) => PHY normal mode (not Test mode)
+	 * 	RX0 (PE25) => PHY ADDR0
+	 *	RX1 (PE26) => PHY ADDR1
+	 *
+	 * PHY has internal pull-down
+	 */
+	writel(pin_to_mask(AT91_PIN_PC25),
+	       pin_to_controller(AT91_PIN_PC0) + PIO_PUDR);
+	writel(pin_to_mask(AT91_PIN_PE25) |
+	       pin_to_mask(AT91_PIN_PE26),
+	       pin_to_controller(AT91_PIN_PE0) + PIO_PUDR);
+
+	/* Need to reset PHY -> 500ms reset */
+	at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
+				     AT91_RSTC_ERSTL | (0x0D << 8) |
+				     AT91_RSTC_URSTEN);
+
+	at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_EXTRST);
+
+	/* Wait for end hardware reset */
+	while (!(at91_sys_read(AT91_RSTC_SR) & AT91_RSTC_NRSTL));
+
+	/* Restore NRST value */
+	/*at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
+				     AT91_RSTC_ERSTL | (0x0 << 8) |
+				     AT91_RSTC_URSTEN);*/
+
+	/* Re-enable pull-up */
+	writel(pin_to_mask(AT91_PIN_PC25),
+	       pin_to_controller(AT91_PIN_PC0) + PIO_PUER);
+	writel(pin_to_mask(AT91_PIN_PE25) |
+	       pin_to_mask(AT91_PIN_PE26),
+	       pin_to_controller(AT91_PIN_PE0) + PIO_PUER);
+
+	at91_set_A_periph(AT91_PIN_PE21, 0);	/* ETXCK_EREFCK */
+	at91_set_B_periph(AT91_PIN_PC25, 0);	/* ERXDV */
+	at91_set_A_periph(AT91_PIN_PE25, 0);	/* ERX0 */
+	at91_set_A_periph(AT91_PIN_PE26, 0);	/* ERX1 */
+	at91_set_A_periph(AT91_PIN_PE27, 0);	/* ERXER */
+	at91_set_A_periph(AT91_PIN_PE28, 0);	/* ETXEN */
+	at91_set_A_periph(AT91_PIN_PE23, 0);	/* ETX0 */
+	at91_set_A_periph(AT91_PIN_PE24, 0);	/* ETX1 */
+	at91_set_A_periph(AT91_PIN_PE30, 0);	/* EMDIO */
+	at91_set_A_periph(AT91_PIN_PE29, 0);	/* EMDC */
+
+#ifndef CONFIG_RMII
+	at91_set_A_periph(AT91_PIN_PE22, 0);	/* ECRS */
+	at91_set_B_periph(AT91_PIN_PC26, 0);	/* ECOL */
+	at91_set_B_periph(AT91_PIN_PC22, 0);	/* ERX2 */
+	at91_set_B_periph(AT91_PIN_PC23, 0);	/* ERX3 */
+	at91_set_B_periph(AT91_PIN_PC27, 0);	/* ERXCK */
+	at91_set_B_periph(AT91_PIN_PC20, 0);	/* ETX2 */
+	at91_set_B_periph(AT91_PIN_PC21, 0);	/* ETX3 */
+	at91_set_B_periph(AT91_PIN_PC24, 0);	/* ETXER */
+#endif
+
+}
+#endif
+
+int board_init(void)
+{
+	/* Enable Ctrlc */
+	console_init_f();
+
+	/* arch number of at91sam9263EK-Board */
+	gd->bd->bi_arch_number = MACH_TYPE_AT91SAM9263EK;
+	/* adress of boot parameters */
+	gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
+
+	at91sam9263ek_serial_hw_init();
+#ifdef CONFIG_CMD_NAND
+	at91sam9263ek_nand_hw_init();
+#endif
+#ifdef CONFIG_HAS_DATAFLASH
+	at91sam9263ek_spi_hw_init();
+#endif
+#ifdef CONFIG_MACB
+	at91sam9263ek_macb_hw_init();
+#endif
+
+	return 0;
+}
+
+int dram_init(void)
+{
+	gd->bd->bi_dram[0].start = PHYS_SDRAM;
+	gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
+	return 0;
+}
+
+#ifdef CONFIG_RESET_PHY_R
+void reset_phy(void)
+{
+#ifdef CONFIG_MACB
+	/*
+	 * Initialize ethernet HW addr prior to starting Linux,
+	 * needed for nfsroot
+	 */
+	eth_init(gd->bd);
+#endif
+}
+#endif
diff --git a/board/atmel/at91sam9263ek/config.mk b/board/atmel/at91sam9263ek/config.mk
new file mode 100644
index 0000000..ff2cfd1
--- /dev/null
+++ b/board/atmel/at91sam9263ek/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x23f00000
diff --git a/board/atmel/at91sam9263ek/led.c b/board/atmel/at91sam9263ek/led.c
new file mode 100644
index 0000000..2a71d61
--- /dev/null
+++ b/board/atmel/at91sam9263ek/led.c
@@ -0,0 +1,78 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop <stelian.pop <at> leadtechdesign.com>
+ * Lead Tech Design <www.leadtechdesign.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/arch/at91sam9263.h>
+#include <asm/arch/at91_pmc.h>
+#include <asm/arch/gpio.h>
+#include <asm/arch/io.h>
+
+#define	POWER_LED	AT91_PIN_PB7	/* this is the power led */
+#define	USER1_LED	AT91_PIN_PB8	/* this is the user led 1 */
+#define USER2_LED	AT91_PIN_PC29	/* this is the user led 2 */
+
+void power_LED_on(void)
+{
+	at91_set_gpio_value(POWER_LED, 1);
+}
+
+void power_LED_off(void)
+{
+	at91_set_gpio_value(POWER_LED, 0);
+}
+
+void user1_LED_on(void)
+{
+	at91_set_gpio_value(USER1_LED, 0);
+}
+
+void user1_LED_off(void)
+{
+	at91_set_gpio_value(USER1_LED, 1);
+}
+
+void user2_LED_on(void)
+{
+	at91_set_gpio_value(USER2_LED, 0);
+}
+
+void user2_LED_off(void)
+{
+	at91_set_gpio_value(USER2_LED, 1);
+}
+
+void coloured_LED_init(void)
+{
+	/* Enable clock */
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOB);
+	at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9263_ID_PIOCDE);
+
+	at91_set_gpio_output(POWER_LED, 1);
+	at91_set_gpio_output(USER1_LED, 1);
+	at91_set_gpio_output(USER2_LED, 1);
+
+	at91_set_gpio_value(POWER_LED, 0);
+	at91_set_gpio_value(USER1_LED, 1);
+	at91_set_gpio_value(USER2_LED, 1);
+}
diff --git a/board/atmel/at91sam9263ek/nand.c b/board/atmel/at91sam9263ek/nand.c
new file mode 100644
index 0000000..8c5b4b1
--- /dev/null
+++ b/board/atmel/at91sam9263ek/nand.c
@@ -0,0 +1,76 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop <stelian.pop <at> leadtechdesign.com>
+ * Lead Tech Design <www.leadtechdesign.com>
+ *
+ * (C) Copyright 2006 ATMEL Rousset, Lacressonniere Nicolas
+ *
+ * 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 <common.h>
+#include <asm/arch/at91sam9263.h>
+#include <asm/arch/gpio.h>
+#include <asm/arch/at91_pio.h>
+
+#include <nand.h>
+
+/*
+ *	hardware specific access to control-lines
+ */
+#define	MASK_ALE	(1 << 21)	/* our ALE is AD21 */
+#define	MASK_CLE	(1 << 22)	/* our CLE is AD22 */
+
+static void at91sam9263ek_nand_hwcontrol(struct mtd_info *mtd, int cmd)
+{
+	struct nand_chip *this = mtd->priv;
+	ulong IO_ADDR_W = (ulong) this->IO_ADDR_W;
+
+	IO_ADDR_W &= ~(MASK_ALE|MASK_CLE);
+	switch (cmd) {
+	case NAND_CTL_SETCLE:
+		IO_ADDR_W |= MASK_CLE;
+		break;
+	case NAND_CTL_SETALE:
+		IO_ADDR_W |= MASK_ALE;
+		break;
+	case NAND_CTL_CLRNCE:
+		at91_set_gpio_value(AT91_PIN_PD15, 1);
+		break;
+	case NAND_CTL_SETNCE:
+		at91_set_gpio_value(AT91_PIN_PD15, 0);
+		break;
+	}
+	this->IO_ADDR_W = (void *) IO_ADDR_W;
+}
+
+static int at91sam9263ek_nand_ready(struct mtd_info *mtd)
+{
+	return at91_get_gpio_value(AT91_PIN_PA22);
+}
+
+int board_nand_init(struct nand_chip *nand)
+{
+	nand->eccmode = NAND_ECC_SOFT;
+	nand->hwcontrol = at91sam9263ek_nand_hwcontrol;
+	nand->dev_ready = at91sam9263ek_nand_ready;
+	nand->chip_delay = 20;
+
+	return 0;
+}
diff --git a/board/atmel/at91sam9263ek/partition.c b/board/atmel/at91sam9263ek/partition.c
new file mode 100644
index 0000000..389fb2c
--- /dev/null
+++ b/board/atmel/at91sam9263ek/partition.c
@@ -0,0 +1,38 @@
+/*
+ *
+ * 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 <common.h>
+#include <config.h>
+#include <asm/hardware.h>
+#include <dataflash.h>
+
+AT91S_DATAFLASH_INFO dataflash_info[CFG_MAX_DATAFLASH_BANKS];
+
+struct dataflash_addr cs[CFG_MAX_DATAFLASH_BANKS] = {
+	{CFG_DATAFLASH_LOGIC_ADDR_CS0, 0},	/* Logical adress, CS */
+	{CFG_DATAFLASH_LOGIC_ADDR_CS1, 1}
+};
+
+/*define the area offsets*/
+dataflash_protect_t area_list[NB_DATAFLASH_AREA] = {
+	{0x00000000, 0x000041FF, FLAG_PROTECT_SET,   0, "Bootstrap"},
+	{0x00004200, 0x000083FF, FLAG_PROTECT_CLEAR, 0, "Environment"},
+	{0x00008400, 0x00041FFF, FLAG_PROTECT_SET,   0, "U-Boot"},
+	{0x00042000, 0x00251FFF, FLAG_PROTECT_CLEAR, 0,	"Kernel"},
+	{0x00252000, 0xFFFFFFFF, FLAG_PROTECT_CLEAR, 0,	"FS"},
+};
diff --git a/board/atmel/at91sam9263ek/u-boot.lds b/board/atmel/at91sam9263ek/u-boot.lds
new file mode 100644
index 0000000..05a6d83
--- /dev/null
+++ b/board/atmel/at91sam9263ek/u-boot.lds
@@ -0,0 +1,57 @@
+/*
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, <gj <at> denx.de>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+/*OUTPUT_FORMAT("elf32-arm", "elf32-arm", "elf32-arm")*/
+OUTPUT_ARCH(arm)
+ENTRY(_start)
+SECTIONS
+{
+	. = 0x00000000;
+
+	. = ALIGN(4);
+	.text :
+	{
+	  cpu/arm926ejs/start.o	(.text)
+	  *(.text)
+	}
+
+	. = ALIGN(4);
+	.rodata : { *(.rodata) }
+
+	. = ALIGN(4);
+	.data : { *(.data) }
+
+	. = ALIGN(4);
+	.got : { *(.got) }
+
+	. = .;
+	__u_boot_cmd_start = .;
+	.u_boot_cmd : { *(.u_boot_cmd) }
+	__u_boot_cmd_end = .;
+
+	. = ALIGN(4);
+	__bss_start = .;
+	.bss : { *(.bss) }
+	_end = .;
+}
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 703784e..499c7da 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -417,13 +417,13 @@ static int macb_init(struct eth_device *netdev, bd_t *bd)
 
 	/* choose RMII or MII mode. This depends on the board */
 #ifdef CONFIG_RMII
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined (CONFIG_AT91SAM9263)
 	macb_writel(macb, USRIO, MACB_BIT(RMII) | MACB_BIT(CLKEN));
 #else
 	macb_writel(macb, USRIO, 0);
 #endif
 #else
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined (CONFIG_AT91SAM9263)
 	macb_writel(macb, USRIO, MACB_BIT(CLKEN));
 #else
 	macb_writel(macb, USRIO, MACB_BIT(MII));
diff --git a/include/asm-arm/arch-at91sam9/at91sam9263.h b/include/asm-arm/arch-at91sam9/at91sam9263.h
new file mode 100644
index 0000000..f91a357
--- /dev/null
+++ b/include/asm-arm/arch-at91sam9/at91sam9263.h
@@ -0,0 +1,120 @@
+/*
+ * include/asm-arm/arch-at91/at91sam9263.h
+ *
+ * (C) 2006 Andrew Victor
+ *
+ * Common definitions.
+ * Based on AT91SAM9263 datasheet revision A (Preliminary).
+ *
+ * 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.
+ */
+
+#ifndef AT91SAM9263_H
+#define AT91SAM9263_H
+
+/*
+ * Peripheral identifiers/interrupts.
+ */
+#define AT91_ID_FIQ		0	/* Advanced Interrupt Controller (FIQ) */
+#define AT91_ID_SYS		1	/* System Peripherals */
+#define AT91SAM9263_ID_PIOA	2	/* Parallel IO Controller A */
+#define AT91SAM9263_ID_PIOB	3	/* Parallel IO Controller B */
+#define AT91SAM9263_ID_PIOCDE	4	/* Parallel IO Controller C */
+#define AT91SAM9263_ID_US0	7	/* USART 0 */
+#define AT91SAM9263_ID_US1	8	/* USART 1 */
+#define AT91SAM9263_ID_US2	9	/* USART 2 */
+#define AT91SAM9263_ID_MCI0	10	/* Multimedia Card Interface */
+#define AT91SAM9263_ID_MCI1	11	/* Multimedia Card Interface */
+#define AT91SAM9263_ID_CAN	12	/* CAN Controller */
+#define AT91SAM9263_ID_TWI	13	/* Two-Wire Interface */
+#define AT91SAM9263_ID_SPI0	14	/* Serial Peripheral Interface 0 */
+#define AT91SAM9263_ID_SPI1	15	/* Serial Peripheral Interface 1 */
+#define AT91SAM9263_ID_SSC0	16	/* Serial Synchronous Controller 0 */
+#define AT91SAM9263_ID_SSC1	17	/* Serial Synchronous Controller 1 */
+#define AT91SAM9263_ID_AC97	18	/* AC 97 Controller */
+#define AT91SAM9263_ID_TC012	19	/* Timer Counter 0, 1 and 2 */
+#define AT91SAM9263_ID_PWMC	20	/* PWM Controller */
+#define AT91SAM9263_ID_EMAC	21	/* Ethernet */
+#define AT91SAM9263_ID_2DGE	23	/* 2D Graphics Engine */
+#define AT91SAM9263_ID_UDP	24	/* USB Device Port */
+#define AT91SAM9263_ID_ISI	25	/* Image Sensor Interface */
+#define AT91SAM9263_ID_LCDC	26	/* LCD Controller */
+#define AT91SAM9263_ID_DMA	27	/* DMA Controller */
+#define AT91SAM9263_ID_UHP	29	/* USB Host Controller */
+#define AT91SAM9263_ID_IRQ0	30	/* External IRQ 0 */
+#define AT91SAM9263_ID_IRQ1	31	/* External IRQ 1 */
+
+/*
+ * User Peripheral physical base addresses.
+ */
+#define AT91SAM9263_BASE_UDP		0xfff78000
+#define AT91SAM9263_BASE_TC012		0xfff7C000
+#define AT91SAM9263_BASE_MCI0		0xfff80000
+#define AT91SAM9263_BASE_MCI1		0xfff84000
+#define AT91SAM9263_BASE_TWI		0xfff88000
+#define AT91SAM9263_BASE_US0		0xfff8c000
+#define AT91SAM9263_BASE_US1		0xfff90000
+#define AT91SAM9263_BASE_US2		0xfff94000
+#define AT91SAM9263_BASE_SSC0		0xfff98000
+#define AT91SAM9263_BASE_SSC1		0xfff9c000
+#define AT91SAM9263_BASE_AC97		0xfffa0000
+#define AT91SAM9263_BASE_SPI0		0xfffa4000
+#define AT91SAM9263_BASE_SPI1		0xfffa8000
+#define AT91SAM9263_BASE_CAN0		0xfffac000
+#define AT91SAM9263_BASE_PWMC		0xfffb8000
+#define AT91SAM9263_BASE_EMAC		0xfffbc000
+#define AT91SAM9263_BASE_ISI		0xfffc4000
+#define AT91SAM9263_BASE_2DGE		0xfffc8000
+#define AT91_BASE_SYS			0xffffc000
+
+/*
+ * System Peripherals (offset from AT91_BASE_SYS)
+ */
+#define AT91_ECC	(0xffffe000 - AT91_BASE_SYS)
+#define AT91_SDRAMC	(0xffffe200 - AT91_BASE_SYS)
+#define AT91_SMC	(0xffffe400 - AT91_BASE_SYS)
+#define AT91_ECC1	(0xffffe600 - AT91_BASE_SYS)
+#define AT91_SDRAMC1	(0xffffe800 - AT91_BASE_SYS)
+#define AT91_SMC1	(0xffffea00 - AT91_BASE_SYS)
+#define AT91_MATRIX	(0xffffec00 - AT91_BASE_SYS)
+#define AT91_CCFG	(0xffffed10 - AT91_BASE_SYS)
+#define AT91_DBGU	(0xffffee00 - AT91_BASE_SYS)
+#define AT91_AIC	(0xfffff000 - AT91_BASE_SYS)
+#define AT91_PIOA	(0xfffff200 - AT91_BASE_SYS)
+#define AT91_PIOB	(0xfffff400 - AT91_BASE_SYS)
+#define AT91_PIOC	(0xfffff600 - AT91_BASE_SYS)
+#define AT91_PIOD	(0xfffff800 - AT91_BASE_SYS)
+#define AT91_PIOE	(0xfffffa00 - AT91_BASE_SYS)
+#define AT91_PMC	(0xfffffc00 - AT91_BASE_SYS)
+#define AT91_RSTC	(0xfffffd00 - AT91_BASE_SYS)
+#define AT91_SHDWC	(0xfffffd10 - AT91_BASE_SYS)
+#define AT91_RTT	(0xfffffd20 - AT91_BASE_SYS)
+#define AT91_PIT	(0xfffffd30 - AT91_BASE_SYS)
+#define AT91_WDT	(0xfffffd40 - AT91_BASE_SYS)
+#define AT91_RTT1	(0xfffffd50 - AT91_BASE_SYS)
+#define AT91_GPBR	(0xfffffd60 - AT91_BASE_SYS)
+
+#define AT91_USART0	AT91SAM9263_BASE_US0
+#define AT91_USART1	AT91SAM9263_BASE_US1
+#define AT91_USART2	AT91SAM9263_BASE_US2
+
+/*
+ * Internal Memory.
+ */
+#define AT91SAM9263_ROM_BASE	0x00400000	/* Internal ROM base address */
+#define AT91SAM9263_ROM_SIZE	SZ_128K		/* Internal ROM size (128Kb) */
+
+#define AT91SAM9263_SRAM0_BASE	0x00500000	/* Internal SRAM 0 base address */
+#define AT91SAM9263_SRAM0_SIZE	SZ_16K		/* Internal SRAM 0 size (16Kb) */
+#define AT91SAM9263_SRAM1_BASE	0x00300000	/* Internal SRAM 1 base address */
+#define AT91SAM9263_SRAM1_SIZE	SZ_80K		/* Internal SRAM 1 size (80Kb) */
+
+#define AT91SAM9263_UHP_BASE	0x00A00000	/* USB Host controller */
+
+#define AT91SAM9XE_FLASH_BASE	0x00200000	/* Internal FLASH base address */
+#define AT91SAM9XE_SRAM_BASE	0x00300000	/* Internal SRAM base address */
+
+#endif
diff --git a/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h b/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h
new file mode 100644
index 0000000..c90f01a
--- /dev/null
+++ b/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h
@@ -0,0 +1,88 @@
+/*
+ * include/asm-arm/arch-at91/at91sam9260_matrix.h
+ *
+ * Memory Controllers (MATRIX, EBI) - System peripherals registers.
+ * Based on AT91SAM9260 datasheet revision B.
+ *
+ * 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.
+ */
+
+#ifndef AT91SAM9260_MATRIX_H
+#define AT91SAM9260_MATRIX_H
+
+#define AT91_MATRIX_MCFG0	(AT91_MATRIX + 0x00)	/* Master Configuration Register 0 */
+#define AT91_MATRIX_MCFG1	(AT91_MATRIX + 0x04)	/* Master Configuration Register 1 */
+#define AT91_MATRIX_MCFG2	(AT91_MATRIX + 0x08)	/* Master Configuration Register 2 */
+#define AT91_MATRIX_MCFG3	(AT91_MATRIX + 0x0C)	/* Master Configuration Register 3 */
+#define AT91_MATRIX_MCFG4	(AT91_MATRIX + 0x10)	/* Master Configuration Register 4 */
+#define AT91_MATRIX_MCFG5	(AT91_MATRIX + 0x14)	/* Master Configuration Register 5 */
+#define		AT91_MATRIX_ULBT		(7 << 0)	/* Undefined Length Burst Type */
+#define			AT91_MATRIX_ULBT_INFINITE	(0 << 0)
+#define			AT91_MATRIX_ULBT_SINGLE		(1 << 0)
+#define			AT91_MATRIX_ULBT_FOUR		(2 << 0)
+#define			AT91_MATRIX_ULBT_EIGHT		(3 << 0)
+#define			AT91_MATRIX_ULBT_SIXTEEN	(4 << 0)
+
+#define AT91_MATRIX_SCFG0	(AT91_MATRIX + 0x40)	/* Slave Configuration Register 0 */
+#define AT91_MATRIX_SCFG1	(AT91_MATRIX + 0x44)	/* Slave Configuration Register 1 */
+#define AT91_MATRIX_SCFG2	(AT91_MATRIX + 0x48)	/* Slave Configuration Register 2 */
+#define AT91_MATRIX_SCFG3	(AT91_MATRIX + 0x4C)	/* Slave Configuration Register 3 */
+#define AT91_MATRIX_SCFG4	(AT91_MATRIX + 0x50)	/* Slave Configuration Register 4 */
+#define		AT91_MATRIX_SLOT_CYCLE		(0xff <<  0)	/* Maximum Number of Allowed Cycles for a Burst */
+#define		AT91_MATRIX_DEFMSTR_TYPE	(3    << 16)	/* Default Master Type */
+#define			AT91_MATRIX_DEFMSTR_TYPE_NONE	(0 << 16)
+#define			AT91_MATRIX_DEFMSTR_TYPE_LAST	(1 << 16)
+#define			AT91_MATRIX_DEFMSTR_TYPE_FIXED	(2 << 16)
+#define		AT91_MATRIX_FIXED_DEFMSTR	(7    << 18)	/* Fixed Index of Default Master */
+#define		AT91_MATRIX_ARBT		(3    << 24)	/* Arbitration Type */
+#define			AT91_MATRIX_ARBT_ROUND_ROBIN	(0 << 24)
+#define			AT91_MATRIX_ARBT_FIXED_PRIORITY	(1 << 24)
+
+#define AT91_MATRIX_PRAS0	(AT91_MATRIX + 0x80)	/* Priority Register A for Slave 0 */
+#define AT91_MATRIX_PRAS1	(AT91_MATRIX + 0x88)	/* Priority Register A for Slave 1 */
+#define AT91_MATRIX_PRAS2	(AT91_MATRIX + 0x90)	/* Priority Register A for Slave 2 */
+#define AT91_MATRIX_PRAS3	(AT91_MATRIX + 0x98)	/* Priority Register A for Slave 3 */
+#define AT91_MATRIX_PRAS4	(AT91_MATRIX + 0xA0)	/* Priority Register A for Slave 4 */
+#define		AT91_MATRIX_M0PR		(3 << 0)	/* Master 0 Priority */
+#define		AT91_MATRIX_M1PR		(3 << 4)	/* Master 1 Priority */
+#define		AT91_MATRIX_M2PR		(3 << 8)	/* Master 2 Priority */
+#define		AT91_MATRIX_M3PR		(3 << 12)	/* Master 3 Priority */
+#define		AT91_MATRIX_M4PR		(3 << 16)	/* Master 4 Priority */
+#define		AT91_MATRIX_M5PR		(3 << 20)	/* Master 5 Priority */
+
+#define AT91_MATRIX_MRCR	(AT91_MATRIX + 0x100)	/* Master Remap Control Register */
+#define		AT91_MATRIX_RCB0		(1 << 0)	/* Remap Command for AHB Master 0 (ARM926EJ-S Instruction Master) */
+#define		AT91_MATRIX_RCB1		(1 << 1)	/* Remap Command for AHB Master 1 (ARM926EJ-S Data Master) */
+
+#define AT91_MATRIX_CSA	(AT91_MATRIX + 0x120)	/* EBI0 Chip Select Assignment Register */
+#define		AT91_MATRIX_CS1A		(1 << 1)	/* Chip Select 1 Assignment */
+#define			AT91_MATRIX_CS1A_SMC		(0 << 1)
+#define			AT91_MATRIX_CS1A_SDRAMC		(1 << 1)
+#define		AT91_MATRIX_CS3A		(1 << 3)	/* Chip Select 3 Assignment */
+#define			AT91_MATRIX_CS3A_SMC		(0 << 3)
+#define			AT91_MATRIX_CS3A_SMC_SMARTMEDIA	(1 << 3)
+#define		AT91_MATRIX_CS4A		(1 << 4)	/* Chip Select 4 Assignment */
+#define			AT91_MATRIX_CS4A_SMC		(0 << 4)
+#define			AT91_MATRIX_CS4A_SMC_CF1	(1 << 4)
+#define		AT91_MATRIX_CS5A		(1 << 5)	/* Chip Select 5 Assignment */
+#define			AT91_MATRIX_CS5A_SMC		(0 << 5)
+#define			AT91_MATRIX_CS5A_SMC_CF2	(1 << 5)
+#define		AT91_MATRIX_DBPUC		(1 << 8)	/* Data Bus Pull-up Configuration */
+#define		AT91_MATRIX_VDDIOMSEL		(1 << 16)	/* Memory voltage selection */
+#define			AT91_MATRIX_VDDIOMSEL_1_8V	(0 << 16)
+#define			AT91_MATRIX_VDDIOMSEL_3_3V	(1 << 16)
+#define AT91_MATRIX_EBI1_CSA	(AT91_MATRIX + 0x124)	/* EBI1 Chip Select Assignment Register */
+#define		AT91_MATRIX_EBI1_CS1A		(1 << 1)	/* Chip Select 1 Assignment */
+#define			AT91_MATRIX_EBI1_CS1A_SMC		(0 << 1)
+#define			AT91_MATRIX_EBI1_CS1A_SDRAMC		(1 << 1)
+#define		AT91_MATRIX_EBI1_CS2A		(1 << 3)	/* Chip Select 3 Assignment */
+#define			AT91_MATRIX_EBI1_CS2A_SMC		(0 << 3)
+#define			AT91_MATRIX_EBI1_CS2A_SMC_SMARTMEDIA	(1 << 3)
+#define		AT91_MATRIX_EBI1_DBPUC		(1 << 8)	/* Data Bus Pull-up Configuration */
+#define		AT91_MATRIX_EBI1_VDDIOMSEL		(1 << 16)	/* Memory voltage selection */
+#define			AT91_MATRIX_EBI1_VDDIOMSEL_1_8V	(0 << 16)
+#define			AT91_MATRIX_EBI1_VDDIOMSEL_3_3V	(1 << 16)
+#endif
diff --git a/include/asm-arm/arch-at91sam9/at91sam9263_mc.h b/include/asm-arm/arch-at91sam9/at91sam9263_mc.h
new file mode 100644
index 0000000..041138f
--- /dev/null
+++ b/include/asm-arm/arch-at91sam9/at91sam9263_mc.h
@@ -0,0 +1,140 @@
+/*
+ * include/asm-arm/arch-at91/at91sam926x_mc.h
+ *
+ * Memory Controllers (SMC, SDRAMC) - System peripherals registers.
+ * Based on AT91SAM9261 datasheet revision D.
+ *
+ * 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.
+ */
+
+#ifndef AT91SAM926x_MC_H
+#define AT91SAM926x_MC_H
+
+/* SDRAM Controller (SDRAMC) registers */
+#define AT91_SDRAMC_MR		(AT91_SDRAMC + 0x00)	/* SDRAM Controller Mode Register */
+#define		AT91_SDRAMC_MODE	(0xf << 0)		/* Command Mode */
+#define			AT91_SDRAMC_MODE_NORMAL		0
+#define			AT91_SDRAMC_MODE_NOP		1
+#define			AT91_SDRAMC_MODE_PRECHARGE	2
+#define			AT91_SDRAMC_MODE_LMR		3
+#define			AT91_SDRAMC_MODE_REFRESH	4
+#define			AT91_SDRAMC_MODE_EXT_LMR	5
+#define			AT91_SDRAMC_MODE_DEEP		6
+
+#define AT91_SDRAMC_TR		(AT91_SDRAMC + 0x04)	/* SDRAM Controller Refresh Timer Register */
+#define		AT91_SDRAMC_COUNT	(0xfff << 0)		/* Refresh Timer Counter */
+
+#define AT91_SDRAMC_CR		(AT91_SDRAMC + 0x08)	/* SDRAM Controller Configuration Register */
+#define		AT91_SDRAMC_NC		(3 << 0)		/* Number of Column Bits */
+#define			AT91_SDRAMC_NC_8	(0 << 0)
+#define			AT91_SDRAMC_NC_9	(1 << 0)
+#define			AT91_SDRAMC_NC_10	(2 << 0)
+#define			AT91_SDRAMC_NC_11	(3 << 0)
+#define		AT91_SDRAMC_NR		(3 << 2)		/* Number of Row Bits */
+#define			AT91_SDRAMC_NR_11	(0 << 2)
+#define			AT91_SDRAMC_NR_12	(1 << 2)
+#define			AT91_SDRAMC_NR_13	(2 << 2)
+#define		AT91_SDRAMC_NB		(1 << 4)		/* Number of Banks */
+#define			AT91_SDRAMC_NB_2	(0 << 4)
+#define			AT91_SDRAMC_NB_4	(1 << 4)
+#define		AT91_SDRAMC_CAS		(3 << 5)		/* CAS Latency */
+#define			AT91_SDRAMC_CAS_1	(1 << 5)
+#define			AT91_SDRAMC_CAS_2	(2 << 5)
+#define			AT91_SDRAMC_CAS_3	(3 << 5)
+#define		AT91_SDRAMC_DBW		(1 << 7)		/* Data Bus Width */
+#define			AT91_SDRAMC_DBW_32	(0 << 7)
+#define			AT91_SDRAMC_DBW_16	(1 << 7)
+#define		AT91_SDRAMC_TWR		(0xf <<  8)		/* Write Recovery Delay */
+#define		AT91_SDRAMC_TRC		(0xf << 12)		/* Row Cycle Delay */
+#define		AT91_SDRAMC_TRP		(0xf << 16)		/* Row Precharge Delay */
+#define		AT91_SDRAMC_TRCD	(0xf << 20)		/* Row to Column Delay */
+#define		AT91_SDRAMC_TRAS	(0xf << 24)		/* Active to Precharge Delay */
+#define		AT91_SDRAMC_TXSR	(0xf << 28)		/* Exit Self Refresh to Active Delay */
+
+#define AT91_SDRAMC_LPR		(AT91_SDRAMC + 0x10)	/* SDRAM Controller Low Power Register */
+#define		AT91_SDRAMC_LPCB		(3 << 0)	/* Low-power Configurations */
+#define			AT91_SDRAMC_LPCB_DISABLE		0
+#define			AT91_SDRAMC_LPCB_SELF_REFRESH		1
+#define			AT91_SDRAMC_LPCB_POWER_DOWN		2
+#define			AT91_SDRAMC_LPCB_DEEP_POWER_DOWN	3
+#define		AT91_SDRAMC_PASR		(7 << 4)	/* Partial Array Self Refresh */
+#define		AT91_SDRAMC_TCSR		(3 << 8)	/* Temperature Compensated Self Refresh */
+#define		AT91_SDRAMC_DS			(3 << 10)	/* Drive Strenght */
+#define		AT91_SDRAMC_TIMEOUT		(3 << 12)	/* Time to define when Low Power Mode is enabled */
+#define			AT91_SDRAMC_TIMEOUT_0_CLK_CYCLES	(0 << 12)
+#define			AT91_SDRAMC_TIMEOUT_64_CLK_CYCLES	(1 << 12)
+#define			AT91_SDRAMC_TIMEOUT_128_CLK_CYCLES	(2 << 12)
+
+#define AT91_SDRAMC_IER		(AT91_SDRAMC + 0x14)	/* SDRAM Controller Interrupt Enable Register */
+#define AT91_SDRAMC_IDR		(AT91_SDRAMC + 0x18)	/* SDRAM Controller Interrupt Disable Register */
+#define AT91_SDRAMC_IMR		(AT91_SDRAMC + 0x1C)	/* SDRAM Controller Interrupt Mask Register */
+#define AT91_SDRAMC_ISR		(AT91_SDRAMC + 0x20)	/* SDRAM Controller Interrupt Status Register */
+#define		AT91_SDRAMC_RES		(1 << 0)		/* Refresh Error Status */
+
+#define AT91_SDRAMC_MDR		(AT91_SDRAMC + 0x24)	/* SDRAM Memory Device Register */
+#define		AT91_SDRAMC_MD		(3 << 0)		/* Memory Device Type */
+#define			AT91_SDRAMC_MD_SDRAM		0
+#define			AT91_SDRAMC_MD_LOW_POWER_SDRAM	1
+
+/* Static Memory Controller (SMC) registers */
+#define AT91_SMC_SETUP(n)	(AT91_SMC + 0x00 + ((n)*0x10))	/* Setup Register for CS n */
+#define		AT91_SMC_NWESETUP	(0x3f << 0)			/* NWE Setup Length */
+#define			AT91_SMC_NWESETUP_(x)	((x) << 0)
+#define		AT91_SMC_NCS_WRSETUP	(0x3f << 8)			/* NCS Setup Length in Write Access */
+#define			AT91_SMC_NCS_WRSETUP_(x)	((x) << 8)
+#define		AT91_SMC_NRDSETUP	(0x3f << 16)			/* NRD Setup Length */
+#define			AT91_SMC_NRDSETUP_(x)	((x) << 16)
+#define		AT91_SMC_NCS_RDSETUP	(0x3f << 24)			/* NCS Setup Length in Read Access */
+#define			AT91_SMC_NCS_RDSETUP_(x)	((x) << 24)
+
+#define AT91_SMC_PULSE(n)	(AT91_SMC + 0x04 + ((n)*0x10))	/* Pulse Register for CS n */
+#define		AT91_SMC_NWEPULSE	(0x7f <<  0)			/* NWE Pulse Length */
+#define			AT91_SMC_NWEPULSE_(x)	((x) << 0)
+#define		AT91_SMC_NCS_WRPULSE	(0x7f <<  8)			/* NCS Pulse Length in Write Access */
+#define			AT91_SMC_NCS_WRPULSE_(x)((x) << 8)
+#define		AT91_SMC_NRDPULSE	(0x7f << 16)			/* NRD Pulse Length */
+#define			AT91_SMC_NRDPULSE_(x)	((x) << 16)
+#define		AT91_SMC_NCS_RDPULSE	(0x7f << 24)			/* NCS Pulse Length in Read Access */
+#define			AT91_SMC_NCS_RDPULSE_(x)((x) << 24)
+
+#define AT91_SMC_CYCLE(n)	(AT91_SMC + 0x08 + ((n)*0x10))	/* Cycle Register for CS n */
+#define		AT91_SMC_NWECYCLE	(0x1ff << 0 )			/* Total Write Cycle Length */
+#define			AT91_SMC_NWECYCLE_(x)	((x) << 0)
+#define		AT91_SMC_NRDCYCLE	(0x1ff << 16)			/* Total Read Cycle Length */
+#define			AT91_SMC_NRDCYCLE_(x)	((x) << 16)
+
+#define AT91_SMC_MODE(n)	(AT91_SMC + 0x0c + ((n)*0x10))	/* Mode Register for CS n */
+#define		AT91_SMC_READMODE	(1 <<  0)			/* Read Mode */
+#define		AT91_SMC_WRITEMODE	(1 <<  1)			/* Write Mode */
+#define		AT91_SMC_EXNWMODE	(3 <<  4)			/* NWAIT Mode */
+#define			AT91_SMC_EXNWMODE_DISABLE	(0 << 4)
+#define			AT91_SMC_EXNWMODE_FROZEN	(2 << 4)
+#define			AT91_SMC_EXNWMODE_READY		(3 << 4)
+#define		AT91_SMC_BAT		(1 <<  8)			/* Byte Access Type */
+#define			AT91_SMC_BAT_SELECT		(0 << 8)
+#define			AT91_SMC_BAT_WRITE		(1 << 8)
+#define		AT91_SMC_DBW		(3 << 12)			/* Data Bus Width */
+#define			AT91_SMC_DBW_8			(0 << 12)
+#define			AT91_SMC_DBW_16			(1 << 12)
+#define			AT91_SMC_DBW_32			(2 << 12)
+#define		AT91_SMC_TDF		(0xf << 16)			/* Data Float Time. */
+#define			AT91_SMC_TDF_(x)		((x) << 16)
+#define		AT91_SMC_TDFMODE	(1 << 20)			/* TDF Optimization - Enabled */
+#define		AT91_SMC_PMEN		(1 << 24)			/* Page Mode Enabled */
+#define		AT91_SMC_PS		(3 << 28)			/* Page Size */
+#define			AT91_SMC_PS_4			(0 << 28)
+#define			AT91_SMC_PS_8			(1 << 28)
+#define			AT91_SMC_PS_16			(2 << 28)
+#define			AT91_SMC_PS_32			(3 << 28)
+
+#if defined(AT91_SMC1)		/* The AT91SAM9263 has 2 Static Memory contollers */
+#define AT91_SMC1_SETUP(n)	(AT91_SMC1 + 0x00 + ((n)*0x10))	/* Setup Register for CS n */
+#define AT91_SMC1_PULSE(n)	(AT91_SMC1 + 0x04 + ((n)*0x10))	/* Pulse Register for CS n */
+#define AT91_SMC1_CYCLE(n)	(AT91_SMC1 + 0x08 + ((n)*0x10))	/* Cycle Register for CS n */
+#define AT91_SMC1_MODE(n)	(AT91_SMC1 + 0x0c + ((n)*0x10))	/* Mode Register for CS n */
+#endif
+
+#endif
diff --git a/include/asm-arm/arch-at91sam9/hardware.h b/include/asm-arm/arch-at91sam9/hardware.h
index 80b334f..4f9f2a8 100644
--- a/include/asm-arm/arch-at91sam9/hardware.h
+++ b/include/asm-arm/arch-at91sam9/hardware.h
@@ -28,6 +28,10 @@
 #include <asm/arch/at91sam9261.h>
 #elif defined(CONFIG_AT91SAM9263)
 #include <asm/arch/at91sam9263.h>
+#define AT91_BASE_EMAC	AT91SAM9263_BASE_EMAC
+#define AT91_BASE_SPI	AT91SAM9263_BASE_SPI0
+#define AT91_ID_UHP	AT91SAM9263_ID_UHP
+#define AT91_PMC_UHP	AT91SAM926x_PMC_UHP
 #elif defined(CONFIG_AT91SAM9RL)
 #include <asm/arch/at91sam9rl.h>
 #elif defined(CONFIG_AT91CAP9)
diff --git a/include/asm-i386/arch b/include/asm-i386/arch
new file mode 100644
index 0000000..3fab653
--- /dev/null
+++ b/include/asm-i386/arch
@@ -0,0 +1 @@
+arch-i386
\ No newline at end of file
diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
new file mode 100644
index 0000000..3ae9846
--- /dev/null
+++ b/include/configs/at91sam9263ek.h
@@ -0,0 +1,205 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop <stelian.pop <at> leadtechdesign.com>
+ * Lead Tech Design <www.leadtechdesign.com>
+ *
+ * Configuation settings for the AT91SAM9260EK board.
+ *
+ * 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
+ */
+
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+/* ARM asynchronous clock */
+#define	CRYSTAL_16_36766MHZ	1
+
+#ifdef CRYSTAL_16_36766MHZ
+
+#define AT91_MAIN_CLOCK	199919000	/* from 16.367 MHz crystal (16367000 / 14 * 171) */
+#define AT91_MASTER_CLOCK	(199919000/2)	/* peripheral clock (AT91C_MAIN_CLOCK / 2) */
+
+#endif
+
+#ifdef CRYSTAL_18_432MHZ
+
+#define AT91_MAIN_CLOCK	198656000	/* from 16.367 MHz crystal (16367000 / 5 * 61) */
+#define AT91_MASTER_CLOCK	(198656000/2)	/* peripheral clock (AT91C_MAIN_CLOCK / 2) */
+
+#endif/* ARM asynchronous clock */
+
+#define CFG_HZ			1000000		/* 1us resolution */
+
+#define AT91_SLOW_CLOCK		32768	/* slow clock */
+
+#define CONFIG_ARM926EJS	1	/* This is an ARM926EJS Core	*/
+#define CONFIG_AT91SAM9263	1	/* It's an Atmel AT91SAM9263 SoC*/
+#define CONFIG_AT91SAM9263EK	1	/* on an AT91SAM9263EK Board	*/
+#undef CONFIG_USE_IRQ			/* we don't need IRQ/FIQ stuff	*/
+
+#define CONFIG_CMDLINE_TAG	1	/* enable passing of ATAGs	*/
+#define CONFIG_SETUP_MEMORY_TAGS 1
+#define CONFIG_INITRD_TAG	1
+
+#define CONFIG_SKIP_LOWLEVEL_INIT
+#define CONFIG_SKIP_RELOCATE_UBOOT
+
+/*
+ * Hardware drivers
+ */
+#define CONFIG_ATMEL_USART	1
+#undef CONFIG_USART0
+#undef CONFIG_USART1
+#undef CONFIG_USART2
+#define CONFIG_USART3		1	/* USART 3 is DBGU */
+
+#define CONFIG_BOOTDELAY	3
+#define CONFIG_BOOTARGS		"console=ttyS0,115200 " \
+				"root=/dev/mtdblock0 rw rootfstype=jffs2"
+
+/* #define CONFIG_ENV_OVERWRITE	1 */
+
+/*
+ * BOOTP options
+ */
+#define CONFIG_BOOTP_BOOTFILESIZE	1
+#define CONFIG_BOOTP_BOOTPATH		1
+#define CONFIG_BOOTP_GATEWAY		1
+#define CONFIG_BOOTP_HOSTNAME		1
+
+/*
+ * Command line configuration.
+ */
+#include <config_cmd_default.h>
+#undef CONFIG_CMD_BDI
+#undef CONFIG_CMD_IMI
+#undef CONFIG_CMD_AUTOSCRIPT
+#undef CONFIG_CMD_FPGA
+#undef CONFIG_CMD_LOADS
+#undef CONFIG_CMD_IMLS
+
+#define CONFIG_CMD_PING		1
+#define CONFIG_CMD_DHCP		1
+#define CONFIG_CMD_NAND		1
+#define CONFIG_CMD_USB		1
+
+/* SDRAM */
+#define CONFIG_NR_DRAM_BANKS		1
+#define PHYS_SDRAM			0x20000000
+#define PHYS_SDRAM_SIZE			0x04000000	/* 64 megs */
+
+/* DataFlash */
+#define CONFIG_HAS_DATAFLASH		1
+#define CFG_SPI_WRITE_TOUT		(5*CFG_HZ)
+#define CFG_MAX_DATAFLASH_BANKS		2
+#define CFG_DATAFLASH_LOGIC_ADDR_CS0	0xC0000000	/* CS0 */
+#define CFG_DATAFLASH_LOGIC_ADDR_CS1	0xD0000000	/* CS1 */
+#define AT91_SPI_CLK			33000000
+#define DATAFLASH_TCSS			(0x1a << 16)
+#define DATAFLASH_TCHS			(0x1 << 24)
+
+/* NAND flash */
+#define NAND_MAX_CHIPS			1
+#define CFG_MAX_NAND_DEVICE		1
+#define CFG_NAND_BASE			0x40000000
+
+/* NOR flash - no real flash on this board */
+#define CFG_NO_FLASH			1
+
+/* Ethernet */
+#define CONFIG_MACB			1
+#define CONFIG_RMII			1
+#define CONFIG_NET_MULTI		1
+#define CONFIG_NET_RETRY_COUNT		20
+#define CONFIG_RESET_PHY_R		1
+
+/* USB */
+#define CONFIG_USB_OHCI_NEW		1
+#define LITTLEENDIAN			1
+#define CONFIG_DOS_PARTITION		1
+#define CFG_USB_OHCI_CPU_INIT		1
+#define CFG_USB_OHCI_REGS_BASE		0x00a00000	/* AT91SAM9260_UHP_BASE */
+#define CFG_USB_OHCI_SLOT_NAME		"at91sam9263"
+#define CFG_USB_OHCI_MAX_ROOT_PORTS	2
+#define CONFIG_USB_STORAGE		1
+
+#define CFG_LOAD_ADDR			0x22000000	/* load address */
+
+#define CFG_MEMTEST_START		PHYS_SDRAM
+#define CFG_MEMTEST_END			0x23e00000
+
+#undef CFG_USE_DATAFLASH_CS0
+#undef CFG_USE_DATAFLASH_CS1
+#define CFG_USE_NANDFLASH		1
+
+#ifdef CFG_USE_DATAFLASH_CS0
+
+/* bootstrap + u-boot + env + linux in dataflash on CS0 */
+#define CFG_ENV_IS_IN_DATAFLASH	1
+#define CFG_MONITOR_BASE	(CFG_DATAFLASH_LOGIC_ADDR_CS0 + 0x8400)
+#define CFG_ENV_OFFSET		0x4200
+#define CFG_ENV_ADDR		(CFG_DATAFLASH_LOGIC_ADDR_CS0 + CFG_ENV_OFFSET)
+#define CFG_ENV_SIZE		0x4200
+#define CONFIG_BOOTCOMMAND	"cp.b 0xC003DE00 0x22000000 0x200040; bootm"
+
+#elif CFG_USE_DATAFLASH_CS1
+
+/* bootstrap + u-boot + env + linux in dataflash on CS1 */
+#define CFG_ENV_IS_IN_DATAFLASH	1
+#define CFG_MONITOR_BASE	(CFG_DATAFLASH_LOGIC_ADDR_CS1 + 0x8400)
+#define CFG_ENV_OFFSET		0x4200
+#define CFG_ENV_ADDR		(CFG_DATAFLASH_LOGIC_ADDR_CS1 + CFG_ENV_OFFSET)
+#define CFG_ENV_SIZE		0x4200
+#define CONFIG_BOOTCOMMAND	"cp.b 0xD003DE00 0x22000000 0x200040; bootm"
+
+#else /* CFG_USE_NANDFLASH */
+
+/* bootstrap + u-boot + env + linux in nandflash */
+#define CFG_ENV_IS_IN_NAND	1
+#define CFG_ENV_OFFSET		0x60000
+#define CFG_ENV_OFFSET_REDUND	0x80000
+#define CFG_ENV_SIZE		0x20000		/* 1 sector = 128 kB */
+#define CONFIG_BOOTCOMMAND	"nand read 0x22000000 0xA0000 0x200000; bootm"
+
+#endif
+
+#define CONFIG_BAUDRATE		115200
+#define CFG_BAUDRATE_TABLE	{115200 , 19200, 38400, 57600, 9600 }
+
+#define CFG_PROMPT		"U-Boot> "
+#define CFG_CBSIZE		256
+#define CFG_MAXARGS		16
+#define CFG_PBSIZE		(CFG_CBSIZE + sizeof(CFG_PROMPT) + 16)
+#define CFG_LONGHELP		1
+#define CONFIG_CMDLINE_EDITING	1
+
+#define ROUND(A, B)		(((A) + (B)) & ~((B) - 1))
+/*
+ * Size of malloc() pool
+ */
+#define CFG_MALLOC_LEN		ROUND(3 * CFG_ENV_SIZE + 128*1024, 0x1000)
+#define CFG_GBL_DATA_SIZE	128	/* 128 bytes for initial data */
+
+#define CONFIG_STACKSIZE	(32*1024)	/* regular stack */
+
+#ifdef CONFIG_USE_IRQ
+#error CONFIG_USE_IRQ not supported
+#endif
+
+#endif
diff --git a/net/eth.c b/net/eth.c
index c4f24c6..e532f8c 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -288,7 +288,7 @@ int eth_initialize(bd_t *bis)
 #if defined(CONFIG_FSLDMAFEC)
 	mcdmafec_initialize(bis);
 #endif
-#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260)
+#if defined(CONFIG_AT91CAP9) || defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9263)
 	at91sam9_eth_initialize(bis);
 #endif
 
-- 
1.5.2.2




From sr at denx.de  Wed Apr 30 10:50:34 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 30 Apr 2008 10:50:34 +0200
Subject: [U-Boot-Users] [PATCH] ppc4xx: Fix problem with DIMMs with 8 banks
	in 44x_spd_ddr2.c
Message-ID: <1209545434-30840-1-git-send-email-sr@denx.de>

This patch fixes a problem with DIMMs that have 8 banks. Now the
MCIF0_MBxCF register will be setup correctly for this setup too.

This was noticed with the 512MB DIMM on Canyonlands/Glacier.

Signed-off-by: Stefan Roese <sr at denx.de>
---
 cpu/ppc4xx/44x_spd_ddr2.c |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/cpu/ppc4xx/44x_spd_ddr2.c b/cpu/ppc4xx/44x_spd_ddr2.c
index 5b5de48..ec76b71 100644
--- a/cpu/ppc4xx/44x_spd_ddr2.c
+++ b/cpu/ppc4xx/44x_spd_ddr2.c
@@ -1,7 +1,10 @@
 /*
  * cpu/ppc4xx/44x_spd_ddr2.c
  * This SPD SDRAM detection code supports AMCC PPC44x cpu's with a
- * DDR2 controller (non Denali Core). Those are 440SP/SPe.
+ * DDR2 controller (non Denali Core). Those currently are:
+ *
+ * 405:		405EX
+ * 440/460:	440SP/440SPe/460EX/460GT
  *
  * (C) Copyright 2007-2008
  * Stefan Roese, DENX Software Engineering, sr at denx.de.
@@ -2078,7 +2081,7 @@ static void program_bxcf(unsigned long *dimm_populated,
 				if (num_banks == 4)
 					ind = 0;
 				else
-					ind = 5;
+					ind = 5 << 8;
 				switch (num_col_addr) {
 				case 0x08:
 					mode |= (SDRAM_BXCF_M_AM_0 + ind);
-- 
1.5.5.1




From Sascha.Laue at gmx.biz  Wed Apr 30 15:23:38 2008
From: Sascha.Laue at gmx.biz (Sascha Laue)
Date: Wed, 30 Apr 2008 15:23:38 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification
Message-ID: <20080430132338.311900@gmx.net>

Hello Wolfgang,

i found another problem with the sysmon POST.
We have to add an offset to the voltage thresholds.

best regards,
Sascha Laue

From: Sascha Laue <sascha.laue at liebherr.com>
Date: Wed, 30 Apr 2008 13:32:17 +0200
Subject: [PATCH] fix an offset error in lwmon5 sysmon0 post.

---
 post/board/lwmon5/sysmon.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
index 23cb709..e9c9624 100644
--- a/post/board/lwmon5/sysmon.c
+++ b/post/board/lwmon5/sysmon.c
@@ -133,16 +133,16 @@ static sysmon_table_t sysmon_table[] =
        {
        "+ 5 V", "V", &sysmon_dspic, NULL, NULL,
        100, 1000, -0x8000, 0x7FFF, 0xFFFF,
-       VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0,
-       VOLTAGE_5V_MIN, VOLTAGE_5V_MAX, 0,
+       0x8000 + VOLTAGE_5V_MIN, 0x8000 + VOLTAGE_5V_MAX, 0,
+       0x8000 + VOLTAGE_5V_MIN, 0x8000 + VOLTAGE_5V_MAX, 0,
        REG_VOLTAGE_5V,
        },

        {
        "+ 5 V standby", "V", &sysmon_dspic, NULL, NULL,
        100, 1000, -0x8000, 0x7FFF, 0xFFFF,
-       VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX, 0,
-       VOLTAGE_5V_STANDBY_MIN, VOLTAGE_5V_STANDBY_MAX, 0,
+       0x8000 + VOLTAGE_5V_STANDBY_MIN, 0x8000 + VOLTAGE_5V_STANDBY_MAX, 0,
+       0x8000 + VOLTAGE_5V_STANDBY_MIN, 0x8000 + VOLTAGE_5V_STANDBY_MAX, 0,
        REG_VOLTAGE_5V_STANDBY,
        },
 };
--
1.5.2.4


-------- Original-Nachricht --------
> Datum: Mon, 28 Apr 2008 22:41:39 +0200
> Von: Wolfgang Denk <wd at denx.de>
> An: "Sascha Laue" <Sascha.Laue at gmx.biz>
> CC: marcel.brasch at liebherr.com, u-boot-users at lists.sourceforge.net, mk at denx.de
> Betreff: Re: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification

> In message <20080401075646.145810 at gmx.net> you wrote:
> >
> > sorry but it's the first time for me.
> > let's try again.
> >
> > we modified the specification for the lwmon5 board dspic POST.
> > Additionally I have add defines for the temperature- and voltagevalues.
> >
> > Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> > ---
> >  post/board/lwmon5/sysmon.c |   39
> ++++++++++++++++++++++++++++++---------
> >  1 files changed, 30 insertions(+), 9 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: wd at denx.de
> Committee, n.:  A group of men who individually can do nothing but as
> a group decide that nothing can be done.                 - Fred Allen



From sew_s at tqs.de  Wed Apr 30 14:34:49 2008
From: sew_s at tqs.de (Jens Gehrlein)
Date: Wed, 30 Apr 2008 14:34:49 +0200
Subject: [U-Boot-Users] [PATCH v2] smc911x: add 16 bit support
Message-ID: <20080430123139.27253.49891.stgit@tq-sewsrv-4.tq-net.de>

Incorporated Ben's, Magnus's and Guennadi's proposals.
Thank you for reviewing.

Signed-off-by: Jens Gehrlein <sew_s at tqs.de>
---

 drivers/net/smc911x.c |   19 +++++++++++++++++--
 1 files changed, 17 insertions(+), 2 deletions(-)


diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index d22c889..bd82cf7 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -30,6 +30,10 @@
 #include <net.h>
 #include <miiphy.h>
 
+#if defined (CONFIG_DRIVER_SMC911X_32_BIT) && defined (CONFIG_DRIVER_SMC911X_16_BIT)
+#error "SMC911X: Only one of CONFIG_DRIVER_SMC911X_32_BIT and CONFIG_DRIVER_SMC911X_16_BIT shall be set"
+#endif
+
 #ifdef CONFIG_DRIVER_SMC911X_32_BIT
 static inline u32 reg_read(u32 addr)
 {
@@ -39,9 +43,20 @@ static inline void reg_write(u32 addr, u32 val)
 {
 	*(volatile u32*)addr = val;
 }
+#elif CONFIG_DRIVER_SMC911X_16_BIT
+static inline u32 reg_read(u32 addr)
+{
+	volatile u16 *addr_16 = (u16 *)addr;
+	return ((*addr_16 & 0x0000ffff) | (*(addr_16 + 1) << 16));
+}
+static inline void reg_write(u32 addr, u32 val)
+{
+	*(volatile u16*)addr = (u16)val;
+	*(volatile u16*)(addr + 2) = (u16)(val >> 16);
+}
 #else
-#error "SMC911X: Only 32-bit bus is supported"
-#endif
+#error "SMC911X: undefined buswidth"
+#endif /* CONFIG_DRIVER_SMC911X_16_BIT */
 
 #define mdelay(n)       udelay((n)*1000)
 




From agust at denx.de  Wed Apr 30 13:34:40 2008
From: agust at denx.de (Anatolij Gustschin)
Date: Wed, 30 Apr 2008 13:34:40 +0200
Subject: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c for
	MPC8610HPCD board
In-Reply-To: <20080429152530.6A726247B4@gemini.denx.de>
References: <20080429152530.6A726247B4@gemini.denx.de>
Message-ID: <1209555280-23311-1-git-send-email-agust@denx.de>

MPC8610HPCD board adds -O2 gcc option to PLATFORM_CPPFLAGS
causing overriding default -Os option. New gcc (ver. 4.2.2)
produces warnings while compiling net/net.c file with -O2
option. The patch is an attempt to fix this.

Signed-off-by: Anatolij Gustschin <agust at denx.de>
---
 include/net.h |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/net.h b/include/net.h
index f6decdc..9a2f03f 100644
--- a/include/net.h
+++ b/include/net.h
@@ -412,10 +412,10 @@ extern void	print_IPaddr (IPaddr_t);
  * footprint in our tests.
  */
 /* return IP *in network byteorder* */
-static inline IPaddr_t NetReadIP(void *from)
+static inline IPaddr_t NetReadIP(volatile void *from)
 {
 	IPaddr_t ip;
-	memcpy((void*)&ip, from, sizeof(ip));
+	memcpy((void*)&ip, (void*)from, sizeof(ip));
 	return ip;
 }
 
@@ -434,9 +434,9 @@ static inline void NetWriteIP(void *to, IPaddr_t ip)
 }
 
 /* copy IP */
-static inline void NetCopyIP(void *to, void *from)
+static inline void NetCopyIP(volatile void *to, void *from)
 {
-	memcpy(to, from, sizeof(IPaddr_t));
+	memcpy((void*)to, from, sizeof(IPaddr_t));
 }
 
 /* copy ulong */
-- 
1.5.3.3




From sr at denx.de  Wed Apr 30 15:50:39 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 30 Apr 2008 15:50:39 +0200
Subject: [U-Boot-Users] [PATCH] RTC: Fix month offset by one problem in
	M41T62 RTC driver
Message-ID: <1209563439-23442-1-git-send-email-sr@denx.de>

This patch fixes a problem with the month being read and written
incorrectly (offset by one). This only gets visible by also using
the Linux driver (rtc-m41t80).

Tested on AMCC Canyonlands.

Signed-off-by: Stefan Roese <sr at denx.de>
---
Wolfgang, could you please apply this for 1.3.3?
Thanks.


 drivers/rtc/m41t62.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/m41t62.c b/drivers/rtc/m41t62.c
index cf2a957..89d4ccd 100644
--- a/drivers/rtc/m41t62.c
+++ b/drivers/rtc/m41t62.c
@@ -81,7 +81,7 @@ int rtc_get(struct rtc_time *tm)
 	tm->tm_hour = BCD2BIN(buf[M41T62_REG_HOUR] & 0x3f);
 	tm->tm_mday = BCD2BIN(buf[M41T62_REG_DAY] & 0x3f);
 	tm->tm_wday = buf[M41T62_REG_WDAY] & 0x07;
-	tm->tm_mon = BCD2BIN(buf[M41T62_REG_MON] & 0x1f) - 1;
+	tm->tm_mon = BCD2BIN(buf[M41T62_REG_MON] & 0x1f);
 
 	/* assume 20YY not 19YY, and ignore the Century Bit */
 	/* U-Boot needs to add 1900 here */
@@ -119,7 +119,7 @@ void rtc_set(struct rtc_time *tm)
 	buf[M41T62_REG_DAY] =
 		BIN2BCD(tm->tm_mday) | (buf[M41T62_REG_DAY] & ~0x3f);
 	buf[M41T62_REG_MON] =
-		BIN2BCD(tm->tm_mon + 1) | (buf[M41T62_REG_MON] & ~0x1f);
+		BIN2BCD(tm->tm_mon) | (buf[M41T62_REG_MON] & ~0x1f);
 	/* assume 20YY not 19YY */
 	buf[M41T62_REG_YEAR] = BIN2BCD(tm->tm_year % 100);
 
-- 
1.5.5.1




From sr at denx.de  Wed Apr 30 16:14:48 2008
From: sr at denx.de (Stefan Roese)
Date: Wed, 30 Apr 2008 16:14:48 +0200
Subject: [U-Boot-Users] [ppc4xx] Please pull
	git://www.denx.de/git/u-boot-ppc4xx.git
Message-ID: <200804301614.48961.sr@denx.de>

The following changes since commit 76617299358ebba260ecc02d33e8e75d8d13dd3b:
  Wolfgang Denk (1):
        Prepare v1.3.3-rc2, again.

are available in the git repository at:

  git://www.denx.de/git/u-boot-ppc4xx.git master

Stefan Roese (2):
      ppc4xx: Fix problem with DIMMs with 8 banks in 44x_spd_ddr2.c
      ppc4xx: Adapt Canyonlands fixed DDR2 setup to new DIMM module

 cpu/ppc4xx/44x_spd_ddr2.c                    |    7 +++++--
 nand_spl/board/amcc/canyonlands/ddr2_fixed.c |   12 +++++++-----
 2 files changed, 12 insertions(+), 7 deletions(-)



From pierre.savary at kerlink.fr  Wed Apr 30 16:20:05 2008
From: pierre.savary at kerlink.fr (Pierre Savary)
Date: Wed, 30 Apr 2008 16:20:05 +0200
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <AA28F077645B324881335614E4F7C428034CF6@win-ex01.bench.com>
References: <005501c8a5d3$e467ceb0$ad376c10$@savary@kerlink.fr>
	<AA28F077645B324881335614E4F7C428034CF6@win-ex01.bench.com>
Message-ID: <001701c8aacd$49ba68b0$dd2f3a10$@savary@kerlink.fr>

Hi Ken,
Thanks a lot for your patch. I will test it next week. Have you ever tested
your U-Boot with 4GB or 8GB moviNAND?
Thanks in advance

Pierre

-----Message d'origine-----
De?: u-boot-users-bounces at lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] De la part de
Ken.Fuchs at bench.com
Envoy??: mardi 29 avril 2008 21:46
??: pierre.savary at kerlink.fr
Cc?: u-boot-users at lists.sourceforge.net; afleming at freescale.com;
abo at kerlink.fr; drzeus-mmc at drzeus.cx
Objet?: Re: [U-Boot-Users] drivers MMCplus for at91sam9x

I posted the following patch under a different subject line:
Re: [U-Boot-Users] [PATCH] Add eSDHC driver

> > --- u-boot_at91sam9260_mmc.patch (AT91 MCI driver) ---

Pierre Savary wrote:

> Thanks for that... but it's my own patch ;)
> 
> Pierre

===========================================================

Pierre, I hope you like this patch better. :)

The following MMC v4 patch is for u-boot-1.1.5_atmel_1.2.
To the AT91SAM9261 MCI device driver it adds support for
MMC v4.x chips (MoviNAND in particular).
  
The u-boot_at91sam9260_mmc.patch, previously send to this
thread 23 April 2008 must be applied to
u-boot-1.1.5_atmel_1.2, prior to applying the patch below.

The patch includes lines "/* Ignore */".  These are
simply place holders for code that was not relevant
to the MCI driver or MMC code. 

The patch is actually of four individual source files.
Please let me know of any serious problems applying the
patch.  It should apply cleanly, but I didn't verify this.

The MCI MMC v4 features contained in this patch work perfectly
on our AT91SAM9261 board, except that I never got MMC 4 bit
bus working (that code is omitted from this patch).  Anyone
know why the AT91SAM9261-EK doesn't appear to support 4 bit MMC?

This patch may not work on AT91SAM9261-EK, since we modified
the AT91SAM9261-EK board definitions rather than creating a
new configuration and files for our board.

Sincerely,

Ken Fuchs

u-boot-at91sam9261-mmc-v4.patch
===============================

svn diff -r21 cpu/arm926ejs/at91sam926x/atmel_mci.c
Index: cpu/arm926ejs/at91sam926x/atmel_mci.c
===================================================================
--- cpu/arm926ejs/at91sam926x/atmel_mci.c	(revision 21)
+++ cpu/arm926ejs/at91sam926x/atmel_mci.c	(working copy)
@@ -1,4 +1,8 @@
 /*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Added MMC v4.x (MoviNAND) support
+ *
  * Copyright (C) 2004-2006 Atmel Corporation
  *
  * See file CREDITS for list of people who contributed to this
@@ -34,21 +38,43 @@
 #include <asm/arch/hardware.h>	//klk
 
 #include "atmel_mci.h"
-#undef DEBUG
+
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
+#if     0
+#define DEBUG
+#else   /* 0 */
+#undef  DEBUG   /* kf - was #undef */
+#endif  /* 0 */
+
 #ifdef DEBUG
 #define pr_debug(fmt, args...) printf(fmt, ##args)
 #else
 #define pr_debug(...) do { } while(0)
 #endif
 
+#undef  CFG_MMC_CLK_OD
+#define CFG_MMC_CLK_OD		375000
+
 #ifndef CFG_MMC_CLK_OD
 #define CFG_MMC_CLK_OD		375000
 #endif
 
+#undef  CFG_MMC_CLK_PP
+#define CFG_MMC_CLK_PP		20000000
+
 #ifndef CFG_MMC_CLK_PP
 #define CFG_MMC_CLK_PP		20000000
 #endif
 
+#undef  CFG_MMC_OP_COND
+#define CFG_MMC_OP_COND		0x80ff8000
+/*                              0x80ff8080 works with 30+ sec. power
off req */
+/*                              0x00800000 works better, but write
forever?  */
+/*                              0x00100000 works with 30+ sec. power
off req */
+
 #ifndef CFG_MMC_OP_COND
 #define CFG_MMC_OP_COND		0x00100000
 #endif
@@ -74,8 +100,13 @@
 	bus_hz = AT91C_MASTER_CLOCK;
 	clkdiv = (bus_hz / hz) / 2 - 1;
 
+#if     1
+	printf("mmc: setting clock %lu Hz, block size %lu\n",
+		 hz, blklen);
+#else   /* 1 */
 	pr_debug("mmc: setting clock %lu Hz, block size %lu\n",
 		 hz, blklen);
+#endif  /* 1 */
 
 	if (clkdiv & ~255UL) {
 		clkdiv = 255;
@@ -84,10 +115,17 @@
 	}
 
 	blklen &= 0xfffc;
+
+#if     1   /* AT91SAM9261 does not have RDPROOF and WRPROOF fields. */
 	mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
+			 | MMCI_BF(BLKLEN, blklen)));
+#else   /* 1 */
+	mmci_writel(MR, (MMCI_BF(CLKDIV, clkdiv)
 			 | MMCI_BF(BLKLEN, blklen)
 			 | MMCI_BIT(RDPROOF)
 			 | MMCI_BIT(WRPROOF)));
+#endif  /* 1 */
+
 }
 
 #define RESP_NO_CRC	1
@@ -99,6 +137,7 @@
 #define NCR		MMCI_BF(MAXLAT, 1)
 #define TRCMD_START	MMCI_BF(TRCMD, 1)
 #define TRDIR_READ	MMCI_BF(TRDIR, 1)
+#define TRDIR_WRITE	MMCI_BF(TRDIR, 0)
 #define TRTYP_BLOCK	MMCI_BF(TRTYP, 0)
 #define INIT_CMD	MMCI_BF(SPCMD, 1)
 #define OPEN_DRAIN	MMCI_BF(OPDCMD, 1)
@@ -109,6 +148,20 @@
 			 | MMCI_BIT(RINDE)		\
 			 | MMCI_BIT(RTOE))
 
+#if     0
+#define DEBUG
+#else   /* 0 */
+#undef  DEBUG   /* kf - was #undef */
+#endif  /* 0 */
+
+#undef pr_debug
+
+#ifdef DEBUG
+#define pr_debug(fmt, args...) printf(fmt, ##args)
+#else
+#define pr_debug(...) do { } while(0)
+#endif
+
 static int
 mmc_cmd(unsigned long cmd, unsigned long arg,
 	void *resp, unsigned long flags)
@@ -117,7 +170,9 @@
 	int i, response_words = 0;
 	unsigned long error_flags;
 	u32 status;
-
+#if     1
+	pr_debug("mmc_cmd: entry\n");
+#endif  /* 1 */
 	AT91F_MMC_Hardware_Init();
 	
 	pr_debug("mmc: CMD%lu 0x%lx (flags 0x%lx)\n",
@@ -161,12 +216,28 @@
 	return 0;
 }
 
+#if     0
+#define DEBUG
+#else   /* 0 */
+#undef  DEBUG   /* kf - was #undef */
+#endif  /* 0 */
+
+#undef pr_debug
+
+#ifdef DEBUG
+#define pr_debug(fmt, args...) printf(fmt, ##args)
+#else
+#define pr_debug(...) do { } while(0)
+#endif
+
 static int mmc_acmd(unsigned long cmd, unsigned long arg,
 		    void *resp, unsigned long flags)
 {
 	unsigned long aresp[4];
 	int ret;
 
+	pr_debug("mmc_acmd: entry\n");
+
 	/*
 	 * Seems like the APP_CMD part of an ACMD has 64 cycles max
 	 * latency even though the ACMD part doesn't. This isn't
@@ -184,7 +255,16 @@
 	return ret;
 }
 
-static unsigned long
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
+unsigned long
 mmc_bread(int dev, unsigned long start, lbaint_t blkcnt,
 	  unsigned long *buffer)
 {
@@ -193,7 +273,14 @@
 	unsigned long card_status, data;
 	unsigned long wordcount;
 	u32 status;
+	unsigned long *bufaddr;
 
+	pr_debug("mmc_bread: entry\n");
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread ret = %d, card status = %08x\n", ret,
card_status);
+
+	bufaddr = buffer;
+
 	if (blkcnt == 0)
 		return 0;
 
@@ -202,10 +289,16 @@
 
 	/* Put the device into Transfer state */
 	ret = mmc_cmd(MMC_CMD_SELECT_CARD, mmc_rca << 16, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread ret = %d, card status = %08x\n",
+		 ret, card_status);
 	if (ret) goto fail;
 
 	/* Set block length */
 	ret = mmc_cmd(MMC_CMD_SET_BLOCKLEN, mmc_blkdev.blksz, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread ret = %d, card status = %08x\n",
+		 ret, card_status);
 	if (ret) goto fail;
 
 	pr_debug("MCI_DTOR = %08lx\n", mmci_readl(DTOR));
@@ -228,7 +321,6 @@
 
 			if (status & MMCI_BIT(RXRDY)) {
 				data = mmci_readl(RDR);
-				/* pr_debug("%x\n", data); */
 				*buffer++ = data;
 				wordcount++;
 			}
@@ -240,12 +332,68 @@
 			status = mmci_readl(SR);
 		} while (!(status & MMCI_BIT(BLKE)));
 
-		putc('.');
+		mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16,
+			&card_status, R1 | NCR);
+		pr_debug("mmc: bread ret = %d, card status = %08x\n",
+			ret, card_status);
+
+		if (i % 0x800 == 0x7ff) {
+		        putc('.');  /* Display '.', after each MB
xfer'ed */ 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+               }
+
+#if     0
+		buffer = bufaddr;
+		wordcount = 0;
+		do {
+		        if (wordcount % 8 == 0) {
+			        pr_debug("\n%06lx:", 4 * wordcount);
+			}
+			pr_debug(" %08lx", *buffer++);
+			wordcount++;
+		} while (4 * wordcount < mmc_blkdev.blksz);
+		pr_debug("\n");
+#endif  /* 0 */
+
 	}
 
 out:
 	/* Put the device back into Standby state */
 	mmc_cmd(MMC_CMD_SELECT_CARD, 0, resp, NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("mmc: bread ret = %d, card status = %08x\n", ret,
card_status);
+	if (i >= 0x7ff) {
+	         putc('\n');
+	}
 	return i;
 
 fail:
@@ -254,8 +402,329 @@
 	goto out;
 }
 
+unsigned long
+mmc_bwrite(int dev, unsigned long start, lbaint_t blkcnt,
+	  unsigned long *buffer)
+{
+	int ret, i = 0;
+	unsigned long resp[4];
+	unsigned long card_status, data;
+	unsigned long wordcount;
+	u32 status;
+	unsigned long *bufaddr;
+
+	pr_debug("mmc_bwrite: entry\n");
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("en mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+
+	bufaddr = buffer;
+
+	if (blkcnt == 0)
+		return 0;
+
+	pr_debug("mmc_bwrite: dev %d, start %lx, blkcnt %lx\n",
+		 dev, start, blkcnt);
+
+	/* Put the device into Transfer state */
+	ret = mmc_cmd(MMC_CMD_SELECT_CARD, mmc_rca << 16, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("sc mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (ret) goto fail;
+
+	/* Set block length */
+	ret = mmc_cmd(MMC_CMD_SET_BLOCKLEN, mmc_blkdev.blksz, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("bl mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (ret) goto fail;
+
+	pr_debug("MCI_DTOR = %08lx\n", mmci_readl(DTOR));
+
+	for (i = 0; i < blkcnt; i++, start++) {
+		ret = mmc_cmd(MMC_CMD_WRITE_BLOCK,
+			      start * mmc_blkdev.blksz, resp,
+			      (R1 | NCR | TRCMD_START | TRDIR_WRITE
+			       | TRTYP_BLOCK));
+		if (ret) goto fail;
+
+		ret = -EIO;
+		wordcount = 0;
+		do {
+			do {
+				status = mmci_readl(SR);
+				if (status & (ERROR_FLAGS |
MMCI_BIT(UNRE)))
+					goto fail;
+			} while (!(status & MMCI_BIT(TXRDY)));
+
+			if (status & MMCI_BIT(TXRDY)) {
+			        data = *buffer++;
+				mmci_writel(TDR, data);
+				wordcount++;
+			}
+		} while(wordcount < (mmc_blkdev.blksz / 4));
+
+		pr_debug("mmc: write %u words, waiting for BLKE\n",
wordcount);
+
+		do {
+			status = mmci_readl(SR);
+		} while (!(status & MMCI_BIT(BLKE)));
+
+		do {
+		        mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16,
+				&card_status, R1 | NCR);
+			if ((card_status & 0x00000100) != 0x00000100) {
+#if     0
+			        printf("lp mmc: bwrite ret = %d, ",
ret);
+				printf("card status = %08x\n",
card_status);
+#endif  /* 0 */
+			} else {
+			        pr_debug("lp mmc: bwrite ret = %d, ",
ret);
+				pr_debug("card status = %08x\n",
card_status);
+			}
+		} while ((card_status & 0x00000100) != 0x00000100);
+
+		if (i % 0x800 == 0x7ff) {
+		         putc('.');  /* Display '.', after each MB
xfer'ed */ 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+		}
+
+#if     0
+		ret = mmc_cmd(MMC_CMD_STOP_TRANSMISSION,
+			      0, resp,
+			      R1 | NCR);
+		mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16,
+			&card_status, R1 | NCR);
+		pr_debug("st mmc: bwrite ret = %d, card status =
%08x\n",
+			 ret, card_status);
+		if (ret) goto fail;
+#endif  /* 0 */
+
+	}
+
+out:
+#if     0
+	ret = mmc_cmd(MMC_CMD_STOP_TRANSMISSION,
+		      0, resp,
+		      R1 | NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("st mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (ret) goto fail;
+#endif  /* 0 */
+
+	/* Put the device back into Standby state */
+	mmc_cmd(MMC_CMD_SELECT_CARD, 0, resp, NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("dc mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (i >= 0x7ff) {
+	         putc('\n');
+	}
+	return i;
+
+fail:
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("fa mmc: bwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	goto out;
+}
+
+   /* Hangs - did not attempt to debug */
+/* MMC Multiple Block Write - mmc_mbwrite() */
+unsigned long
+mmc_mbwrite(int dev, unsigned long start, lbaint_t blkcnt,
+	  unsigned long *buffer)
+{
+	int ret, i = 0;
+	unsigned long resp[4];
+	unsigned long card_status, data;
+	unsigned long wordcount;
+	u32 status;
+	unsigned long *bufaddr;
+
+	pr_debug("mmc_bwrite: entry\n");
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("en mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+
+	bufaddr = buffer;
+
+	if (blkcnt == 0)
+		return 0;
+
+	if (blkcnt > 0xffff) {  /* Exceeds length supported by MoviNAND.
*/
+	        return -1;
+	}
+
+	pr_debug("mmc_mbwrite: dev %d, start %lx, blkcnt %lx\n",
+		 dev, start, blkcnt);
+
+	/* Put the device into Transfer state */
+	ret = mmc_cmd(MMC_CMD_SELECT_CARD, mmc_rca << 16, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("sc mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+	if (ret) goto fail;
+
+	/* Set block length */
+	ret = mmc_cmd(MMC_CMD_SET_BLOCKLEN, mmc_blkdev.blksz, resp, R1 |
NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("bl mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+	if (ret) goto fail;
+
+	pr_debug("MCI_DTOR = %08lx\n", mmci_readl(DTOR));
+
+	ret = mmc_cmd(MMC_CMD_SET_BLOCK_COUNT,
+		      blkcnt, resp,
+		      R1 | NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("bc mmc: mbwrite ret = %d, card status = %08x\n",
+		 ret, card_status);
+	if (ret) goto fail;
+
+	ret = mmc_cmd(MMC_CMD_WRITE_MULTIPLE_BLOCK,
+		      start * mmc_blkdev.blksz, resp,
+		      (R1 | NCR | TRCMD_START | TRDIR_WRITE |
TRTYP_BLOCK));
+	if (ret) goto fail;
+
+	for (i = 0; i < blkcnt; i++, start++) {
+
+		ret = -EIO;
+		wordcount = 0;
+		do {
+			do {
+				status = mmci_readl(SR);
+				if (status & (ERROR_FLAGS |
MMCI_BIT(UNRE)))
+					goto fail;
+			} while (!(status & MMCI_BIT(TXRDY)));
+
+			if (status & MMCI_BIT(TXRDY)) {
+			        data = *buffer++;
+				mmci_writel(TDR, data);
+				wordcount++;
+			}
+		} while(wordcount < (mmc_blkdev.blksz / 4));
+
+#if     1
+		pr_debug("mmc: write %u words, waiting for BLKE\n",
wordcount);
+
+		do {
+			status = mmci_readl(SR);
+		} while (!(status & MMCI_BIT(BLKE)));
+#endif  /* 0 */
+
+		do {
+		        mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16,
+				&card_status, R1 | NCR);
+			if ((card_status & 0x00000100) != 0x00000100) {
+#if     0
+			        printf("lp mmc: mbwrite ret = %d, ",
ret);
+				printf("card status = %08x\n",
card_status);
+#endif  /* 0 */
+			} else {
+			        pr_debug("lp mmc: mbwrite ret = %d, ",
ret);
+				pr_debug("card status = %08x\n",
card_status);
+			}
+		} while ((card_status & 0x00000100) != 0x00000100);
+
+		if (i % 0x800 == 0x7ff) {
+		         putc('.');  /* Display '.', after each MB
xfer'ed */ 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+		}
+	}
+
+out:
+#if     0
+	ret = mmc_cmd(MMC_CMD_STOP_TRANSMISSION,
+		      0, resp,
+		      R1 | NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("st mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+	if (ret) goto fail;
+#endif  /* 0 */
+
+	/* Put the device back into Standby state */
+	mmc_cmd(MMC_CMD_SELECT_CARD, 0, resp, NCR);
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("dc mmc: mbwrite ret = %d, card status = %08x\n",
+	       ret, card_status);
+	if (i >= 0x7ff) {
+	         putc('\n');
+	}
+	return i;
+
+fail:
+	mmc_cmd(MMC_CMD_SEND_STATUS, mmc_rca << 16, &card_status, R1 |
NCR);
+	pr_debug("fa mmc: mbwrite failed, card status = %08x\n",
card_status);
+	goto out;
+}
+
 static void mmc_parse_cid(struct mmc_cid *cid, unsigned long *resp)
 {
+	pr_debug("mmc_parse_cid: entry\n");
+
 	cid->mid = resp[0] >> 24;
 	cid->oid = (resp[0] >> 8) & 0xffff;
 	cid->pnm[0] = resp[0];
@@ -272,6 +741,8 @@
 
 static void sd_parse_cid(struct mmc_cid *cid, unsigned long *resp)
 {
+	pr_debug("sd_parse_cid: entry\n");
+
 	cid->mid = resp[0] >> 24;
 	cid->oid = (resp[0] >> 8) & 0xffff;
 	cid->pnm[0] = resp[0];
@@ -288,6 +759,8 @@
 
 static void mmc_dump_cid(const struct mmc_cid *cid)
 {
+	pr_debug("mmc_dump_cid: entry\n");
+
 	printf("Manufacturer ID:       %02lX\n", cid->mid);
 	printf("OEM/Application ID:    %04lX\n", cid->oid);
 	printf("Product name:          %s\n", cid->pnm);
@@ -301,6 +774,9 @@
 static void mmc_dump_csd(const struct mmc_csd *csd)
 {
 	unsigned long *csd_raw = (unsigned long *)csd;
+
+	pr_debug("mmc_dump_csd: entry\n");
+
 	pr_debug("CSD data: %08lx %08lx %08lx %08lx\n",
 	       csd_raw[0], csd_raw[1], csd_raw[2], csd_raw[3]);
 	pr_debug("CSD structure version:   1.%u\n", csd->csd_structure);
@@ -337,6 +813,8 @@
 {
 	int ret;
 
+	pr_debug("mmc_idle_cards: entry\n");
+
 	/* Reset and initialize all cards */
 	ret = mmc_cmd(MMC_CMD_GO_IDLE_STATE, 0, NULL, 0);
 	
@@ -352,6 +830,8 @@
 	unsigned long resp[4];
 	int i, ret = 0;
 
+	pr_debug("sd_init_card: entry\n");
+
 	mmc_idle_cards();
 	for (i = 0; i < 1000; i++) {
 		ret = mmc_acmd(MMC_ACMD_SD_SEND_OP_COND,
CFG_MMC_OP_COND,
@@ -387,10 +867,40 @@
 {
 	unsigned long resp[4];
 	int i, ret = 0;
+	u32 status;
 
+	pr_debug("mmc_init_card: entry\n");
+
 	mmc_idle_cards();
 
+	/* MoviNAND initialization */
 	for (i = 0; i < 1000; i++) {
+	        mmci_writel(ARGR, 0xFFFFFFFF);
+		mmci_writel(CMDR, 0x0018113F);
+		do {
+		        status = mmci_readl(SR);
+		} while (!(status & MMCI_BIT(CMDRDY)));
+	}
+        /* Getting the OCR value seems to prevent marginal chips from
*/
+        /* working at all, whereas they would work fine after waiting
*/
+        /* a full minute or more with the power off prior to booting.
*/
+        /* Our marginal chips have date codes 0716 and 0728.
*/
+#if     0   
+	for (i = 0; i < 1000; i++) {
+	  /* Request OCR value to determine chip's supported volt. */
+		ret = mmc_cmd(MMC_CMD_SEND_OP_COND, 0, resp,
+			      R3 | NID | OPEN_DRAIN);
+		if (ret || (resp[0] & 0x80000000))
+		{
+			break;
+		}
+		ret = -ETIMEDOUT;
+	}
+	if (ret) {
+		return ret;
+	}
+#endif  /* 0 */
+	for (i = 0; i < 1000; i++) {
 		ret = mmc_cmd(MMC_CMD_SEND_OP_COND, CFG_MMC_OP_COND,
resp,
 			      R3 | NID | OPEN_DRAIN);
 		if (ret || (resp[0] & 0x80000000))
@@ -399,13 +909,35 @@
 		}
 		ret = -ETIMEDOUT;
 	}
+        pr_debug("Step 4: ret = 0x%lx\n", ret);
+	pr_debug("MMC_CMD_SEND_OP_COND = 0x%lx\n",
MMC_CMD_SEND_OP_COND);
+        pr_debug("CFG_MMC_OP_COND = 0x%lx\n", CFG_MMC_OP_COND);
+        pr_debug("resp[0] = 0x%lx\n", resp[0]);
+        pr_debug("resp[1] = 0x%lx\n", resp[1]);
+        pr_debug("resp[2] = 0x%lx\n", resp[2]);
+        pr_debug("resp[3] = 0x%lx\n", resp[3]);
+        pr_debug("R3 = 0x%lx\n", R3);
+        pr_debug("NID = 0x%lx\n", NID);
+        pr_debug("OPEN_DRAIN = 0x%lx\n", OPEN_DRAIN);
+
 	pr_debug("4\n");
 	pr_debug("ret : %i\n",ret);
+
+	pr_debug("MCI_MR = 0x%08lx\n", mmci_readl(MR));
+	pr_debug("MCI_DTOR = 0x%08lx\n", mmci_readl(DTOR));
+	pr_debug("MCI_SDCR = 0x%08lx\n", mmci_readl(SDCR));
+	pr_debug("MCI_ARGR = 0x%08lx\n", mmci_readl(ARGR));
+	/* RSPR */
+	/* RDR */
+	pr_debug("MCI_SR = 0x%08lx\n", mmci_readl(SR));
+	pr_debug("MCI_IMR = 0x%08lx\n", mmci_readl(IMR));
+
 	if (ret)
 		return ret;
 	pr_debug("5\n");
 	/* Get CID of all cards. FIXME: Support more than one card */
 	ret = mmc_cmd(MMC_CMD_ALL_SEND_CID, 0, resp, R2 | NID |
OPEN_DRAIN);
+	pr_debug("ALL_SEND_CID ret: 0x%08lx\n", ret);
 	if (ret)
 		return ret;
 	mmc_parse_cid(cid, resp);
@@ -415,6 +947,7 @@
 	/* Set Relative Address of the card that responded */
 	ret = mmc_cmd(MMC_CMD_SET_RELATIVE_ADDR, mmc_rca << 16, resp,
 		      R1 | NCR | OPEN_DRAIN);
+	pr_debug("SET_RELATIVE_ADDR ret: 0x%08lx\n", ret);
 	return ret;
 }
 
@@ -471,23 +1004,42 @@
 	       dtocyc << shift, dtor);
 }
 
+#define DEFAULT_SECTOR_SIZE 512
+
 int mmc_init(int verbose)
 {
 	struct mmc_cid cid;
 	struct mmc_csd csd;
 	unsigned int max_blksz;
 	int ret,aux;
+	unsigned char buffer[DEFAULT_SECTOR_SIZE];
 	
+	pr_debug("mmc_init: entry\n");
+	pr_debug("mmc_init: verbose = 0x%08lx\n", verbose);
+
 	AT91F_MMC_Hardware_Init();
 	
 	pr_debug("0\n");
 	/* Initialize controller */
 	mmci_writel(CR, MMCI_BIT(SWRST));
 	mmci_writel(CR, MMCI_BIT(MCIEN));
+
+	pr_debug("MCI_MR = 0x%08lx\n", mmci_readl(MR));
+	pr_debug("MCI_DTOR = 0x%08lx\n", mmci_readl(DTOR));
+	pr_debug("MCI_SDCR = 0x%08lx\n", mmci_readl(SDCR));
+	pr_debug("MCI_ARGR = 0x%08lx\n", mmci_readl(ARGR));
+	/* RSPR */
+	/* RDR */
+	pr_debug("MCI_SR = 0x%08lx\n", mmci_readl(SR));
+	pr_debug("MCI_IMR = 0x%08lx\n", mmci_readl(IMR));
+
 	mmci_writel(DTOR, 0x5f);
 	mmci_writel(IDR, ~0UL);
 	mmci_writel(SDCR, 0x1);
 	mci_set_mode(CFG_MMC_CLK_OD, MMC_DEFAULT_BLKLEN);
+#if     0
+	mmci_writel(MR, 0x02009B4A);
+#endif  /* 0 */
 /* 	//mmci_writel(CR, MMCI_BIT(SWRST));
 	mmci_writel(CR, 0x00000001);
 	mmci_writel(DTOR, 0x0000007F);
@@ -502,6 +1054,7 @@
 
 	ret = sd_init_card(&cid, verbose);
 	if (ret) {
+	  	pr_debug("Not SDCard, try MMC\n");
 		mmc_rca = MMC_DEFAULT_RCA;
 		ret = mmc_init_card(&cid, verbose);
 	}
@@ -545,6 +1098,20 @@
 	mci_set_mode(CFG_MMC_CLK_PP, mmc_blkdev.blksz);
 
 #if 0
+	mmc_bread(mmc_blkdev.dev, 1024, 1, (ulong *)buffer);
+        buffer[0] = 0x00; buffer[1] = 0x11;
+        buffer[2] = 0x22; buffer[3] = 0x33;
+        buffer[4] = 0x44; buffer[5] = 0x55;
+        buffer[6] = 0x66; buffer[7] = 0x77;
+        buffer[504] = 0x88; buffer[505] = 0x99;
+        buffer[506] = 0xaa; buffer[507] = 0xbb;
+        buffer[508] = 0xcc; buffer[509] = 0xdd;
+        buffer[510] = 0xee; buffer[511] = 0xff;
+	mmc_bwrite(mmc_blkdev.dev, 1024, 1, (ulong *)buffer); 
+	mmc_bread(mmc_blkdev.dev, 1024, 1, (ulong *)buffer);
+#endif  /* 0 */
+
+#if 0
 	if (fat_register_device(&mmc_blkdev, 1))
 		pr_debug("Could not register MMC fat device\n");
 #else
@@ -556,16 +1123,22 @@
 
 int mmc_read(ulong src, uchar *dst, int size)
 {
+	pr_debug("mmc_read: entry\n");
+
 	return -ENOSYS;
 }
 
 int mmc_write(uchar *src, ulong dst, int size)
 {
+	pr_debug("mmc_write: entry\n");
+
 	return -ENOSYS;
 }
 
 int mmc2info(ulong addr)
 {
+	pr_debug("mmc2info: entry\n");
+
 	return 0;
 }
 
svn diff -r21 include/asm-arm/arch-at91sam926x/mmc.h
Index: include/asm-arm/arch-at91sam926x/mmc.h
===================================================================
--- include/asm-arm/arch-at91sam926x/mmc.h	(revision 0)
+++ include/asm-arm/arch-at91sam926x/mmc.h	(revision 50)
@@ -0,0 +1,103 @@
+/*
+ * (C) Copyright 2007
+ * Benchmark Electronics, Inc.
+ * Added MMC v4.x (MoviNAND) support
+ *
+ * Copyright (C) 2004-2006 Atmel Corporation
+ *
+ * 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
+ */
+#ifndef __ASM_AT91SAM926X_MMC_H
+#define __ASM_AT91SAM926X_MMC_H
+
+struct mmc_cid {
+	unsigned long psn;
+	unsigned short oid;
+	unsigned char mid;
+	unsigned char prv;
+	unsigned char mdt;
+	char pnm[7];
+};
+
+struct mmc_csd
+{
+	u8	csd_structure:2,
+		spec_vers:4,
+		rsvd1:2;
+	u8	taac;
+	u8	nsac;
+	u8	tran_speed;
+	u16	ccc:12,
+		read_bl_len:4;
+	u64	read_bl_partial:1,
+		write_blk_misalign:1,
+		read_blk_misalign:1,
+		dsr_imp:1,
+		rsvd2:2,
+		c_size:12,
+		vdd_r_curr_min:3,
+		vdd_r_curr_max:3,
+		vdd_w_curr_min:3,
+		vdd_w_curr_max:3,
+		c_size_mult:3,
+		sector_size:5,
+		erase_grp_size:5,
+		wp_grp_size:5,
+		wp_grp_enable:1,
+		default_ecc:2,
+		r2w_factor:3,
+		write_bl_len:4,
+		write_bl_partial:1,
+		rsvd3:5;
+	u8	file_format_grp:1,
+		copy:1,
+		perm_write_protect:1,
+		tmp_write_protect:1,
+		file_format:2,
+		ecc:2;
+	u8	crc:7;
+	u8	one:1;
+};
+
+/* MMC Command numbers */
+#define MMC_CMD_GO_IDLE_STATE		0
+#define MMC_CMD_SEND_OP_COND		1
+#define MMC_CMD_ALL_SEND_CID 		2
+#define MMC_CMD_SET_RELATIVE_ADDR	3
+#define MMC_CMD_SD_SEND_RELATIVE_ADDR	3
+#define MMC_CMD_SET_DSR			4
+#define MMC_CMD_SELECT_CARD		7
+#define MMC_CMD_SEND_CSD 		9
+#define MMC_CMD_SEND_CID 		10
+#define MMC_CMD_STOP_TRANSMISSION	12
+#define MMC_CMD_SEND_STATUS		13
+#define MMC_CMD_SET_BLOCKLEN		16
+#define MMC_CMD_READ_SINGLE_BLOCK	17
+#define MMC_CMD_READ_MULTIPLE_BLOCK	18
+#define MMC_CMD_SET_BLOCK_COUNT		23
+#define MMC_CMD_WRITE_BLOCK		24
+#define MMC_CMD_WRITE_MULTIPLE_BLOCK	25
+#define MMC_CMD_APP_CMD			55
+
+#define MMC_ACMD_SD_SEND_OP_COND	41
+
+#define R1_ILLEGAL_COMMAND		(1 << 22)
+#define R1_APP_CMD			(1 << 5)
+
+#endif /* __ASM_AT91SAM926X_MMC_H */

svn diff -r21 include/configs/at91sam9261ek.h
Index: include/configs/at91sam9261ek.h
===================================================================
--- include/configs/at91sam9261ek.h	(revision 21)
+++ include/configs/at91sam9261ek.h	(working copy)
@@ -1,4 +1,8 @@
 /*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Added MMC v4.x (MoviNAND) support
+ *
  * (C) Copyright 2005
  * M. Amine SAYA ATMEL Rousset, France.
  *
@@ -95,18 +99,24 @@
 /* SPI */
 #define CONFIG_SPI
 
+/* kf - define hush (from busy box) command line interface & options */
+#define CFG_HUSH_PARSER
+#define CFG_PROMPT_HUSH_PS2     "> "
+#define CFG_AUTO_COMPLETE
+#define CONFIG_CMDLINE_EDITING
+
 #define CONFIG_COMMANDS		\
 		       ((CONFIG_CMD_DFL	| \
                         CFG_CMD_NET | \
                         CFG_CMD_ENV | \
                         CFG_CMD_USB | \
                         CFG_CMD_FLASH | \
-			CFG_CMD_NAND | \
+                        CFG_CMD_MMC | \
+                        CFG_CMD_EXT2 | \
+                        CFG_CMD_FAT | \
 			CFG_CMD_AUTOSCRIPT | \
-                        CFG_CMD_FAT | \
                         CFG_CMD_NFS | \
                         CFG_CMD_SPI | \
-                        CFG_CMD_U | \
 			CFG_CMD_IMI | \
                         CFG_CMD_PING ) & \
 		      ~(CFG_CMD_BDI | \
@@ -296,8 +306,12 @@
 #define CFG_FLASH_ERASE_TOUT		(2*CFG_HZ) /* Timeout for Flash
Erase */
 #define CFG_FLASH_WRITE_TOUT		(2*CFG_HZ) /* Timeout for Flash
Write */
 
+#undef  CFG_ENV_IS_IN_FLASH
 #define	CFG_ENV_IS_IN_DATAFLASH         1
-#undef  CFG_ENV_IS_IN_FLASH
+#if     0
+#undef  CFG_ENV_IS_IN_NAND
+#endif  /* 0 - kf */
+#undef  CFG_ENV_IS_NOWHERE
 
 #ifdef CFG_ENV_IS_IN_DATAFLASH
 #define CFG_ENV_OFFSET			0x4000
@@ -305,6 +319,10 @@
 #define CFG_ENV_SIZE			0x4000  /* 0x8000 */
 #endif
 
+#ifdef CFG_ENV_IS_NOWHERE
+#define CFG_ENV_SIZE			0x4000
+#endif
+
 #ifdef CFG_ENV_IS_IN_FLASH
 #ifdef CONFIG_BOOTBINFUNC
 #define CFG_ENV_ADDR			(PHYS_FLASH_1 + 0x60000)  /*
after u-boot.bin */
@@ -316,6 +334,9 @@
 #endif
 
 /* Add LCD stuff */
+/* Ignore */
+/* Ignore */
+
 #if 0  /* No LCD */
 #define  CONFIG_LCD
 /* #undef  CONFIG_LCD_LOGO */
@@ -333,8 +354,21 @@
 #define CONFIG_DOS_PARTITION	        1
 #define LITTLEENDIAN 			1
 
-#define CFG_LOAD_ADDR		0x23f00000  /* default load address */
+/* Add FAT filesystem configuration, other than CFG_CMD_FAT */
+#define CONFIG_SUPPORT_VFAT
 
+/* MMC */
+#define CONFIG_MMC		1
+#define MMCI_BASE		0xFFFA8000  /* (void *)AT91C_BASE_MCI */
+/* MMC - kf - slow down speed for debug from 20000000 Hz down to ...
*/
+/* However, tweaking this value here causes all code to be compiled,
*/
+/* so we shall change the value only where needed - in atmel_mci.c.
*/
+#define CFG_MMC_CLK_PP          20000000
+
+#define CFG_LOAD_ADDR		0x23f00000  /* default load address   */
+
+#define CFG_BOOTM_LEN           0x02100000  /* 33MB uncompressed max.
*/
+
 #ifdef CONFIG_BOOTBINFUNC
 #define CFG_BOOT_SIZE		0x00 /* 0 KBytes */
 #define CFG_U_BOOT_BASE		PHYS_FLASH_1

svn diff -r21 board/at91sam9261ek/at91sam9261ek.c
Index: board/at91sam9261ek/at91sam9261ek.c
===================================================================
--- board/at91sam9261ek/at91sam9261ek.c	(revision 21)
+++ board/at91sam9261ek/at91sam9261ek.c	(working copy)
@@ -1,4 +1,8 @@
 /*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Added specific AT91SAM9261 board support
+ *
  * (C) Copyright 2005
  * M. Amine SAYA ATMEL Rousset, France.
  * Added AT91SAM9261EK support.
@@ -28,12 +32,19 @@
 
 #include <common.h>
 #include <asm/arch/hardware.h>
+#include <asm/arch-at91sam926x/at91sam9261.h>
 
 #include <net.h>
 
 extern void AT91F_Spi1Init (void);
 extern void gpio_init(void);
 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
 /*
------------------------------------------------------------------------
- */
 /*
  * Miscelaneous platform dependent initialisations
@@ -107,7 +118,8 @@
   *AT91C_PMC_PCER |= 1 << AT91C_ID_US0;	/* enable clock */
 #endif
   
-#ifdef CONFIG_USART1
+#if     1
+  /* #ifdef CONFIG_USART1 */
   *AT91C_PIOB_PDR = AT91C_PC12_TXD1 | AT91C_PC13_RXD1;
   *AT91C_PMC_PCER |= 1 << AT91C_ID_US1;	/* enable clock */
 #endif
@@ -118,6 +130,41 @@
 #endif
 }
 
+#ifdef CONFIG_MMC
+#if (CONFIG_COMMANDS & CFG_CMD_MMC)
+int AT91F_MMC_Hardware_Init(void)
+{
+#if     0
+	printf("AT91F_MMC_Hardware_Init: entry\n");
+#endif  /* 0 */
+
+        AT91F_PIO_CfgPeriph(AT91C_BASE_PIOA,
+			    0,                   /*  <- Peripheral A */
+			    (AT91C_PA0_MCDA0 |    /*  MMC NAND MCDA0  */
+			     AT91C_PA1_MCCDA |    /*  MMC NAND MCCDA  */
+			     AT91C_PA2_MCCK  |    /*  MMC NAND MCCK   */
+			     AT91C_PA4_MCDA1 |    /*  MMC NAND MCDA1  */
+			     AT91C_PA5_MCDA2 |    /*  MMC NAND MCDA2  */
+			     AT91C_PA6_MCDA3 |    /*  MMC NAND MCDA3  */
+			     0));                 /*  <- Peripheral B */
+
+#if     1
+	/* Pull up disable register */
+	AT91C_BASE_PIOA->PIO_PPUDR |=
+	        AT91C_PA0_MCDA0 |    /*  MMC NAND MCDA0  */
+	        AT91C_PA1_MCCDA |    /*  MMC NAND MCCDA  */
+	        AT91C_PA2_MCCK  |    /*  MMC NAND MCCK   */
+	        AT91C_PA4_MCDA1 |    /*  MMC NAND MCDA1  */
+	        AT91C_PA5_MCDA2 |    /*  MMC NAND MCDA2  */
+	        AT91C_PA6_MCDA3;     /*  MMC NAND MCDA3  */
+#endif  /* 0 */
+
+	AT91C_BASE_PMC->PMC_PCER = (1 << AT91C_ID_MCI);
+}
+#endif /* CONFIG_COMMANDS & CFG_CMD_MMC */
+#endif /* CONFIG_MMC */
+
+
 int dram_init (void)
 {
   DECLARE_GLOBAL_DATA_PTR;
@@ -148,5 +195,35 @@
 
   gpio_init();
 
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+/* Ignore */
+
   return 0;
 }

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users




From galak at kernel.crashing.org  Wed Apr 30 16:24:17 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 30 Apr 2008 09:24:17 -0500
Subject: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c
	for MPC8610HPCD board
In-Reply-To: <1209555280-23311-1-git-send-email-agust@denx.de>
References: <20080429152530.6A726247B4@gemini.denx.de>
	<1209555280-23311-1-git-send-email-agust@denx.de>
Message-ID: <227D16F0-1807-4731-B0D2-E8D7ACDB86C5@kernel.crashing.org>


On Apr 30, 2008, at 6:34 AM, Anatolij Gustschin wrote:
> MPC8610HPCD board adds -O2 gcc option to PLATFORM_CPPFLAGS
> causing overriding default -Os option. New gcc (ver. 4.2.2)
> produces warnings while compiling net/net.c file with -O2
> option. The patch is an attempt to fix this.

nothing against this patch, but should we change MPC8610HPCD to use - 
Os like everyone else?

- k



From lilja.magnus at gmail.com  Wed Apr 30 10:12:26 2008
From: lilja.magnus at gmail.com (Magnus Lilja)
Date: Wed, 30 Apr 2008 10:12:26 +0200
Subject: [U-Boot-Users] [PATCH] net: add 16 bit support for smc911x
In-Reply-To: <48180D90.5080705@gmail.com>
References: <20080429100913.23049.90329.stgit@tq-sewsrv-4.tq-net.de>
	<Pine.LNX.4.64.0804292208520.8498@axis700.grange>
	<481801B4.10500@tqs.de> <48180D90.5080705@gmail.com>
Message-ID: <59b21cf20804300112q7b05fef4udbf7b3bb07298938@mail.gmail.com>

Hi all

>  > Magnus, are you going to fix the code as proposed by Ben and Guennadi or
>  >   should I resubmit the patch?
>  >
>  Ultimately, somebody needs to submit a patch.  Since Magnus won't try it
>  til later this week, it would be best if you post a patch incorporating
>  changes.  Then if it works, we're ready to go.

May I suggest adding something like this to the smc911x.c-patch as well:

#if defined(CONFIG_DRIVER_SMC911X_32_BIT) &&
defined(CONFIG_DRIVER_SMC911X_16_BIT)
#error "SMC911X: Only one of CONFIG_DRIVER_SMC911X_32_BIT and
CONFIG_DRIVER_SMC911X_16_BIT shall be set"
#endif

(but with the correct line wrapping, the above is written directly in
gmail and I don't know how gmail will mangle the code)

Just in case someone accidentally defines both in the config file.


Also, I tested the patch with Ben's modifications and it seems to work
on the i.MX31 Litekit board. Tried both ping and tftp file transfer
with the 16 bit option (and 32 bit option).


Regards, Magnus



From wd at denx.de  Wed Apr 30 09:49:20 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 09:49:20 +0200
Subject: [U-Boot-Users] 1.3.3-rc2 - release status
In-Reply-To: Your message of "Wed, 30 Apr 2008 09:36:46 +0200."
	<200804300936.47258.matthias.fuchs@esd-electronics.com>
Message-ID: <20080430074920.E358324681@gemini.denx.de>

In message <200804300936.47258.matthias.fuchs at esd-electronics.com> you wrote:
> 
> I noticed some warnings when compiling recent U-Boot source for some 4xx bo> ards 
> with gcc 4.0.0 or 4.2.2. Perhaps somebody has a clue on how to get rid of t> hese:

That's your host GCC. WHich distro is this?

I didn't see such warnigns yet...

> gcc -g -Wall -pedantic -idirafter /data/home/matthias/git/u-boot/u-boot/inc> lude -idirafter /data/home/matthias/git/u-boot/u-boot/include2 -idirafter /> data/home/matthias/git/u-boot/u-boot/include -DTEXT_BASE=0xFFFA0000 -DUSE> _HOSTCC -O -c -o md5.o md5.c
> md5.c: In function ???MD5Update???:
> md5.c:95: warning: implicit declaration of function ???memmove??> ?
> md5.c:95: warning: incompatible implicit declaration of built-in function > ???memmove???
> md5.c:98: warning: incompatible implicit declaration of built-in function > ???memmove???
> md5.c:107: warning: incompatible implicit declaration of built-in function > ???memmove???
> md5.c:116: warning: incompatible implicit declaration of built-in function > ???memmove???

I smell some header file incompatibitilies -  eventually  this  is  a
distro issue.

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: wd at denx.de
"A fractal is by definition a set for which the Hausdorff Besicovitch
dimension strictly exceeds the topological dimension."
- Mandelbrot, _The Fractal Geometry of Nature_



From agust at denx.de  Wed Apr 30 16:39:26 2008
From: agust at denx.de (Anatolij Gustschin)
Date: Wed, 30 Apr 2008 16:39:26 +0200
Subject: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c
 for MPC8610HPCD board
In-Reply-To: <227D16F0-1807-4731-B0D2-E8D7ACDB86C5@kernel.crashing.org>
References: <20080429152530.6A726247B4@gemini.denx.de>
	<1209555280-23311-1-git-send-email-agust@denx.de>
	<227D16F0-1807-4731-B0D2-E8D7ACDB86C5@kernel.crashing.org>
Message-ID: <4818849E.4050205@denx.de>

Kumar Gala wrote:
> 
> On Apr 30, 2008, at 6:34 AM, Anatolij Gustschin wrote:
>> MPC8610HPCD board adds -O2 gcc option to PLATFORM_CPPFLAGS
>> causing overriding default -Os option. New gcc (ver. 4.2.2)
>> produces warnings while compiling net/net.c file with -O2
>> option. The patch is an attempt to fix this.
> 
> nothing against this patch, but should we change MPC8610HPCD to use -Os
> like everyone else?

if there is no special reason for using -O2 with MPC8610HPCD,
then it should be changed to use -Os.

Anatolij



From gerald.vanbaren at ge.com  Wed Apr 30 16:43:16 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Wed, 30 Apr 2008 10:43:16 -0400
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <alpine.DEB.1.10.0804300949360.13610@pmy.adscville>
References: <20080429204348.1ED4C247B4@gemini.denx.de>
	<alpine.DEB.1.10.0804291703010.13610@pmy.adscville>
	<48179041.6080008@ge.com>
	<alpine.DEB.1.10.0804300949360.13610@pmy.adscville>
Message-ID: <48188584.3060109@ge.com>

Adrian Filipi wrote:
> On Tue, 29 Apr 2008, Jerry Van Baren wrote:
> 
>> Adrian Filipi wrote:
>>> On Tue, 29 Apr 2008, Wolfgang Denk wrote:
>>>
>>>> In message <alpine.DEB.1.10.0804291604250.32753 at pmy.adscville> you 
>>>> wrote:
>>>>>      I narrowed down the source of the problem to the loss of the
>>>>> volatile qualifier on the addr pointer in flash_write_cmd().  
>>>>> Adding the
>>>>> qualifier gets rid of the corruption.  In the older 1.2.0 sources, 
>>>>> addr was
>>>>> declared as "volatile cfiptr_t addr;".
>>>> The volatile should not be needed - the CFI driver should use correct
>>>> accessor macros instead. See
>>>> Documentation/volatile-considered-harmful.txt in your Linux kernel
>>>> source tree...
>>>>
>>>> Best regards,
>>>>
>>>> Wolfgang Denk
>>>
>>>      Sure, reducing the reliance on volatile is a good idea, but I'm 
>>> at a loss for anything better to do.
>>>
>>>      I'm seeing a real problem that is only fixed by qualifying the 
>>> container of the pointer as volatile, i.e. "void *volatile".  
>>> "volatile void *" has no effect as expected given that the read/write 
>>> accessors are used now.
>>>
>>>      The old data type was essentially "volatile void *volatile addr" 
>>> and the new type is simply "void *addr".  I seem to need at least 
>>> "void *volatile addr" for things to work.
>>>
>>>      Note, I'm only seeing this problem on our PXA250 boards.
>>>
>>>      Adrian
>>
>> Hi Adrian,
>>
>> Please bottom post.
>>
>> It may be useful to disassemble cfi_flash.o file (objdump -S) and see 
>> what the two different configurations of flash_write_cmd() get turned 
>> into in assembly.
>>
>> Best regards,
>> gvb
>>
> 
>     I've attached the assembler output as well as the diff to the 
> version with volatile added.  I don't see anything incriminating.
> Instead of using a register, the variable is read from its location on 
> the stack.
> 
>     I'm having a hard time seeing how flash could get corrupted by this 
> code.  It's happening during initialization.
> 
>     Adrian

I'm not an ARMexpert, but if that were a PowerPC CPU, I would *strongly* 
suspect that the bus interface unit is rearranging the bus operations 
going to memory (e.g. moving a read ahead of a write or re-ordering the 
writes).  The result is that the write command/data sequence to the 
flash gets buggered by the re-ordering.

Per my theory, by putting in the "volatile", you force extra reads on 
the bus which forces the bus interface unit to flush out the flash write 
sequence in the right order.  The fix is totally unrelated the the 
problem, other than as an unrecognized side effect it "fixes" the problem.

The solution in the PowerPC world is to add a "eieio" or "sync" 
instruction[1] appropriately[2], which prevents the bus interface unit 
from reordering the memory operations.

Your task is to dig into the PXA250 manual to (a) figure out what syncs 
you need and (b) figure out why the bus interface is doing you in. 
Alternatively, (c) show that I don't know what I'm talking about. 
Obviously, (a) gets you the best results, so lets root for that. ;-)

HTH,
gvb

[1] Sync is a big hammer, eieio is a medium size hammer.  Don't use 
both, PPC people will know you don't know what you are doing.  ;-)

[2] The flash command sequence order is critical (e.g. the 55s and AAs). 
  The actual data sequence is not critical.  The observed problem is in 
flash_write_cmd() that is writing the command sequence.  Hmmmmm.



From matthias.fuchs at esd-electronics.com  Wed Apr 30 09:36:46 2008
From: matthias.fuchs at esd-electronics.com (Matthias Fuchs)
Date: Wed, 30 Apr 2008 09:36:46 +0200
Subject: [U-Boot-Users] 1.3.3-rc2 - release status
In-Reply-To: <20080429214926.744C624681@gemini.denx.de>
References: <20080429214926.744C624681@gemini.denx.de>
Message-ID: <200804300936.47258.matthias.fuchs@esd-electronics.com>

Hi, 

I noticed some warnings when compiling recent U-Boot source for some 4xx boards 
with gcc 4.0.0 or 4.2.2. Perhaps somebody has a clue on how to get rid of these:

gcc -g -Wall -pedantic -idirafter /data/home/matthias/git/u-boot/u-boot/include -idirafter /data/home/matthias/git/u-boot/u-boot/include2 -idirafter /data/home/matthias/git/u-boot/u-boot/include -DTEXT_BASE=0xFFFA0000 -DUSE_HOSTCC -O -c -o md5.o md5.c
md5.c: In function ?MD5Update?:
md5.c:95: warning: implicit declaration of function ?memmove?
md5.c:95: warning: incompatible implicit declaration of built-in function ?memmove?
md5.c:98: warning: incompatible implicit declaration of built-in function ?memmove?
md5.c:107: warning: incompatible implicit declaration of built-in function ?memmove?
md5.c:116: warning: incompatible implicit declaration of built-in function ?memmove?
md5.c: In function ?MD5Final?:
md5.c:143: warning: implicit declaration of function ?memset?
md5.c:143: warning: incompatible implicit declaration of built-in function ?memset?
md5.c:151: warning: incompatible implicit declaration of built-in function ?memset?
md5.c:161: warning: incompatible implicit declaration of built-in function ?memmove?
md5.c:162: warning: incompatible implicit declaration of built-in function ?memset?
gcc -g -Wall -pedantic -idirafter /data/home/matthias/git/u-boot/u-boot/include -idirafter /data/home/matthias/git/u-boot/u-boot/include2 -idirafter /data/home/matthias/git/u-boot/u-boot/include -DTEXT_BASE=0xFFFA0000 -DUSE_HOSTCC -O -c -o sha1.o sha1.c
sha1.c: In function ?sha1_update?:
sha1.c:249: warning: implicit declaration of function ?memcpy?
sha1.c:249: warning: incompatible implicit declaration of built-in function ?memcpy?
sha1.c:263: warning: incompatible implicit declaration of built-in function ?memcpy?
sha1.c: In function ?sha1_hmac?:
sha1.c:360: warning: implicit declaration of function ?memset?
sha1.c:360: warning: incompatible implicit declaration of built-in function ?memset?


Matthias

On Tuesday 29 April 2008 23:49, Wolfgang Denk wrote:
> Hello,
> 
> U-Boot v1.3.3-rc2 has just been released.
> 
> PowerPC seems to be in a pretty good state now;  other  architectures
> still  need a lot of testing / fixing. For example, on ARM we see the
> following conflicts:
> 
> Configuring for kb9202 board...
> start.S: Assembler messages:
> start.S:205: Error: invalid constant -- `sub r0,r0,#(0x0200+128*1024)'
> start.S:378: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
> start.S:379: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
> start.S:384: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
> start.S:385: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
> start.S:390: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
> start.S:391: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
> start.S:396: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
> start.S:397: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
> start.S:402: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
> start.S:403: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
> start.S:427: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
> start.S:428: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
> start.S:433: Error: invalid constant -- `sub r13,r13,#((32*1024)+(0x0200+128*1024))'
> start.S:434: Error: invalid constant -- `sub r2,r2,#((32*1024)+(0x0200+128*1024))'
> make[1]: *** [start.o] Error 1
> 
> 
> Configuring for netstar board...
> arm-linux-ld: cannot find -lgeneric
> make[1]: *** [eeprom.srec] Error 1
> 
> 
> Configuring for voiceblue board...
> arm-linux-ld: cannot find -lgeneric
> make[1]: *** [eeprom.srec] Error 1
> 
> 
> Configuring for apollon board...
> onenand_base.c:25: error: static declaration of 'memcpy' follows non-static declaration
> /home/wd/git/u-boot/master/include/linux/string.h:70: error: previous declaration of 'memcpy' was here
> make[1]: *** [onenand_base.o] Error 1
> 
> 
> Configuring for adsvix board...
> start.S:183:1: warning: "ICMR" redefined
> In file included from start.S:33:
> /home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:935:1: warning: this is the location of the previous definition
> start.S:187:1: warning: "RCSR" redefined
> /home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:1602:1: warning: this is the location of the previous definition
> start.S:191:1: warning: "OSMR3" redefined
> /home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:869:1: warning: this is the location of the previous definition
> start.S:192:1: warning: "OSCR" redefined
> /home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:870:1: warning: this is the location of the previous definition
> start.S:193:1: warning: "OWER" redefined
> /home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:872:1: warning: this is the location of the previous definition
> start.S:194:1: warning: "OIER" redefined
> /home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:873:1: warning: this is the location of the previous definition
> start.S:207:1: warning: "CCCR" redefined
> /home/wd/git/u-boot/master/include/asm/arch/pxa-regs.h:1770:1: warning: this is the location of the previous definition
> pcmcia.c:39:2: warning: #warning "Board will only supply 5V, wait for next HW spin for selectable power"
> pxa_pcmcia.c: In function 'pcmcia_on':
> pxa_pcmcia.c:39: warning: operation on 'i' may be undefined
> cmd_ide.c: In function '__ide_outb':
> cmd_ide.c:828: warning: implicit declaration of function 'outb'
> cmd_ide.c: In function '__ide_inb':
> cmd_ide.c:837: warning: implicit declaration of function 'inb'
> common/libcommon.a(cmd_ide.o): In function `__ide_outb':
> /home/wd/git/u-boot/master/common/cmd_ide.c:828: undefined reference to `outb'
> common/libcommon.a(cmd_ide.o): In function `__ide_inb':
> /home/wd/git/u-boot/master/common/cmd_ide.c:837: undefined reference to `inb'
> make: *** [u-boot] Error 1
> 
> 
> Configuring for actux4 board...
> actux4.c: In function 'board_init':
> actux4.c:83: warning: left shift count >= width of type
> actux4.c:83: warning: left shift count >= width of type
> 
> 
> Configuring for davinci_schmoogie board...
> env_nand.c: In function 'saveenv':
> env_nand.c:200: warning: passing argument 3 of 'nand_write' from incompatible pointer type
> env_nand.c: In function 'env_relocate_spec':
> env_nand.c:275: warning: passing argument 3 of 'nand_read' from incompatible pointer type
> 
> 
> 
> Board maintainers / custodians - please help!
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 



From joakim.tjernlund at transmode.se  Wed Apr 30 17:11:09 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 30 Apr 2008 17:11:09 +0200
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <48188584.3060109@ge.com>
References: <20080429204348.1ED4C247B4@gemini.denx.de>
	<alpine.DEB.1.10.0804291703010.13610@pmy.adscville>
	<48179041.6080008@ge.com>
	<alpine.DEB.1.10.0804300949360.13610@pmy.adscville>
	<48188584.3060109@ge.com>
Message-ID: <1209568270.16926.32.camel@gentoo-jocke.transmode.se>


> 
> [1] Sync is a big hammer, eieio is a medium size hammer.  Don't use 
> both, PPC people will know you don't know what you are doing.  ;-)

Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
SOC drivers are encouraged to use them. What a waste :(

 Jocke



From timur at freescale.com  Wed Apr 30 17:13:20 2008
From: timur at freescale.com (Timur Tabi)
Date: Wed, 30 Apr 2008 10:13:20 -0500
Subject: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c
 for MPC8610HPCD board
In-Reply-To: <227D16F0-1807-4731-B0D2-E8D7ACDB86C5@kernel.crashing.org>
References: <20080429152530.6A726247B4@gemini.denx.de>	<1209555280-23311-1-git-send-email-agust@denx.de>
	<227D16F0-1807-4731-B0D2-E8D7ACDB86C5@kernel.crashing.org>
Message-ID: <48188C90.8080409@freescale.com>

Kumar Gala wrote:

> nothing against this patch, but should we change MPC8610HPCD to use - 
> Os like everyone else?

Beats me.  git-blame points to Jon, so he'll have to tell you where the original
config.mk came from.

I dropped the -O2 and it still builds fine, but we don't have any 8610's
currently to test it on.

-- 
Timur Tabi
Linux kernel developer at Freescale



From wd at denx.de  Wed Apr 30 17:26:49 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 17:26:49 +0200
Subject: [U-Boot-Users] [PATCH] Makefile: fix parallel builds
Message-ID: <1209569209-10099-1-git-send-email-wd@denx.de>

This problem shows up with parallel builds only; it results in
somewhat cryptic error messages like

	$ JOBS=-j6 MAKEALL netstar
	Configuring for netstar board...
	arm-linux-ld: cannot find -lgeneric
	make[1]: *** [eeprom.srec] Error 1

A few boards (like netstar and voiceblue) need some libraries for
building; however, the board Makefile does not contain any such
dependencies which may cause problems with parallel builds. Adding
such dependencies is difficult as we would also have to provide build
rules, which already exist in the respective library Makefiles.

To solve this, we make sure that all libraries get built before the
board code.

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 Makefile |   14 ++++++++++----
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 10324d2..ac0a17f 100644
--- a/Makefile
+++ b/Makefile
@@ -201,7 +201,6 @@ OBJS := $(addprefix $(obj),$(OBJS))
 LIBS  = lib_generic/libgeneric.a
 LIBS += $(shell if [ -f board/$(VENDOR)/common/Makefile ]; then echo \
 	"board/$(VENDOR)/common/lib$(VENDOR).a"; fi)
-LIBS += board/$(BOARDDIR)/lib$(BOARD).a
 LIBS += cpu/$(CPU)/lib$(CPU).a
 ifdef SOC
 LIBS += cpu/$(CPU)/$(SOC)/lib$(SOC).a
@@ -248,6 +247,9 @@ LIBS += post/libpost.a
 LIBS := $(addprefix $(obj),$(LIBS))
 .PHONY : $(LIBS) $(VERSION_FILE)
 
+LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a
+LIBBOARD := $(addprefix $(obj),$(LIBBOARD))
+
 # Add GCC lib
 PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc
 
@@ -270,7 +272,7 @@ U_BOOT_ONENAND = $(obj)u-boot-onenand.bin
 endif
 
 __OBJS := $(subst $(obj),,$(OBJS))
-__LIBS := $(subst $(obj),,$(LIBS))
+__LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD))
 
 #########################################################################
 #########################################################################
@@ -313,8 +315,9 @@ $(obj)u-boot.sha1:	$(obj)u-boot.bin
 $(obj)u-boot.dis:	$(obj)u-boot
 		$(OBJDUMP) -d $< > $@
 
-$(obj)u-boot:		depend $(SUBDIRS) $(OBJS) $(LIBS) $(LDSCRIPT)
-		UNDEF_SYM=`$(OBJDUMP) -x $(LIBS) |sed  -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
+$(obj)u-boot:		depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT)
+		UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \
+		sed  -n -e 's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
 		cd $(LNDIR) && $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
 			--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
 			-Map u-boot.map -o u-boot
@@ -325,6 +328,9 @@ $(OBJS):	depend $(obj)include/autoconf.mk
 $(LIBS):	depend $(obj)include/autoconf.mk
 		$(MAKE) -C $(dir $(subst $(obj),,$@))
 
+$(LIBBOARD):	depend $(LIBS) $(obj)include/autoconf.mk
+		$(MAKE) -C $(dir $(subst $(obj),,$@))
+
 $(SUBDIRS):	depend $(obj)include/autoconf.mk
 		$(MAKE) -C $@ all
 
-- 
1.5.4.2




From vivek.trivedi at wipro.com  Wed Apr 30 17:34:33 2008
From: vivek.trivedi at wipro.com (vivek.trivedi at wipro.com)
Date: Wed, 30 Apr 2008 21:04:33 +0530
Subject: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
Message-ID: <47230CE166B64744B0120173E4C2161E04D531CF@BLR-EC-MBX01.wipro.com>

Hi,
We are using MPC8349E based board in big endian mode. It is working fine
with U-Boot 1.1.3 .
Now due to some reason we have to configure 8349E in little endian mode.
I have modified RCW, HID2 and MSR registers for this and built the
U-Boot with -mlittle-endian(gcc 3.4.3) and -EL (ld option ).
 
Now code is starting properly in Start.S but it is jumping to alignment
vector(0x600) whenever it hits a branch instruction(b , bl).
Then it stops at 0x63F in alignment exception vector handler.
 
Has any one tried configuring U-Boot for MPC8349E in little endian mode
...?
We have also tried to build U-Boot with -mstrict-align option, but it
has not helped us.
Are we missing any alignment option in gcc for compiling U-Boot.
 
Any help will be appreciated.
 
 
Thanks,
Vivek Trivedi
 



From joakim.tjernlund at transmode.se  Wed Apr 30 17:34:56 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 30 Apr 2008 17:34:56 +0200
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <20080430152141.GE23545@ld0162-tx32.am.freescale.net>
References: <20080429204348.1ED4C247B4@gemini.denx.de>
	<alpine.DEB.1.10.0804291703010.13610@pmy.adscville>
	<48179041.6080008@ge.com>
	<alpine.DEB.1.10.0804300949360.13610@pmy.adscville>
	<48188584.3060109@ge.com>
	<1209568270.16926.32.camel@gentoo-jocke.transmode.se>
	<20080430152141.GE23545@ld0162-tx32.am.freescale.net>
Message-ID: <1209569696.16926.53.camel@gentoo-jocke.transmode.se>


On Wed, 2008-04-30 at 10:21 -0500, Scott Wood wrote:
> On Wed, Apr 30, 2008 at 05:11:09PM +0200, Joakim Tjernlund wrote:
> > Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
> > SOC drivers are encouraged to use them. What a waste :(
> 
> sync is needed in some of the cases, to sync I/O accesses with DMA buffer
> accesses.  Ideally, we could trust the driver writers to put
> synchronization in where needed, but it seems Linux has too much x86
> heritage for that.

Perhaps, is sync needed in this case for non-smp too? or is eieio
enough?
Anyway, just have a look at ucc_geth and you will see that
most such accesses are just about getting the endian right.

> 
> There should at least be raw alternatives, though...

There need be a get-the-endian-right-but-no-sync. After all
2.4 managed well without using the in/out be() functions.

 Jocke
> 
> -Scott
> 
> 



From gerald.vanbaren at ge.com  Wed Apr 30 17:35:41 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Wed, 30 Apr 2008 11:35:41 -0400
Subject: [U-Boot-Users] PPC sync/eieio (was cfi_flash.c and lost
 volatile qualifier)
In-Reply-To: <1209568270.16926.32.camel@gentoo-jocke.transmode.se>
References: <20080429204348.1ED4C247B4@gemini.denx.de>	
	<alpine.DEB.1.10.0804291703010.13610@pmy.adscville>	
	<48179041.6080008@ge.com>	
	<alpine.DEB.1.10.0804300949360.13610@pmy.adscville>	
	<48188584.3060109@ge.com>
	<1209568270.16926.32.camel@gentoo-jocke.transmode.se>
Message-ID: <481891CD.7010907@ge.com>

Joakim Tjernlund wrote:
>> [1] Sync is a big hammer, eieio is a medium size hammer.  Don't use 
>> both, PPC people will know you don't know what you are doing.  ;-)
> 
> Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
> SOC drivers are encouraged to use them. What a waste :(
> 
>  Jocke

Well, I was a little terse because I was cross-applying PPC instructions 
in a ARM discussion.  Personally, I prefer to use sync vs. eieio.  The 
size of the hammer isn't that different, I don't believe.  The advantage 
of sync is that it flushes the read/write operation out on the bus 
*now*.  When I'm writing to hardware to control the hardware, *now* is 
what I want.

The eieio merely guarantees the preceding operations will go out on the 
bus before following bus operations.  The preceding operations could be 
hung up in the bus interface unit *indefinitely* if no "following" bus 
operations occur.  This is an unlikely occurrence, but could be the 
result of running out of cache in a tight loop.

For instance, if you do a write to a hardware register, a eieio, and 
then wait in a tight loop until time goes by (reading the decrementer 
register) followed by another write, the write1/delay/write2 sequence 
could actually be delay/write1/write2.  Note that the order of the 
writes on the bus is correct per the eieio, but it isn't what the 
hardware *needed*.

Illustration - what you did in code and intended to occur:
   write1 (eieio)
   delay
   write2 (eieio)

What actually may happen on the bus:
   delay
   write1 (eieio)
   write2 (eieio)

By using a sync, you guarantee the write isn't delayed:
   write1 (sync)
   delay
   write2 (sync)

Disclaimer: the above explanation is from my fertile imagination.  It 
may or may not happen and *will* happen differently on different PPC 
processors.  For instance, the eieio instruction is actually a NOP in 
the 603e core because it doesn't reorder bus operations, but it *does* 
have a BIU that can buffer and delay the bus operations, causing the 
above timing problem.

I contend using the "sync" instruction will always work correctly and 
the "eieio" instruction is at best a false economy and at worst a lot of 
very difficult, mysterious bugs to find, so I'm in agreement with the 
linux in_bex/out_bex recommendation.

Side note: I don't know if I communicated it properly, but when you see 
"eieio ; sync" or "sync ; eieio", you know the author of that code 
doesn't understand sync and eieio.  "isync ; sync" is occasionally a 
valid combination, but I don't believe it is necessary other than when 
called for by the Users Manual in conjunction with writing to special 
purpose registers.

Best regards,
gvb



From wd at denx.de  Wed Apr 30 17:38:30 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 17:38:30 +0200
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: Your message of "Wed, 30 Apr 2008 10:43:16 EDT."
	<48188584.3060109@ge.com>
Message-ID: <20080430153830.3CC7024681@gemini.denx.de>

In message <48188584.3060109 at ge.com> you wrote:
>
> The solution in the PowerPC world is to add a "eieio" or "sync" 
> instruction[1] appropriately[2], which prevents the bus interface unit 
> from reordering the memory operations.

No, the solution for ALL architectures  is  to  use  the  appropriate
accessor  macros which take care of such things (and probably contain
calls like sync or similar).

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: wd at denx.de
Unix: Some say the learning curve is steep,  but  you  only  have  to
climb it once.                                      - Karl Lehenbauer



From wd at denx.de  Wed Apr 30 17:41:18 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 17:41:18 +0200
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: Your message of "Wed, 30 Apr 2008 17:34:56 +0200."
	<1209569696.16926.53.camel@gentoo-jocke.transmode.se>
Message-ID: <20080430154118.3578F24681@gemini.denx.de>

In message <1209569696.16926.53.camel at gentoo-jocke.transmode.se> you wrote:
> 
> There need be a get-the-endian-right-but-no-sync. After all
> 2.4 managed well without using the in/out be() functions.

Yes, but try building it with a recent version of  GCC  and  run  the
code  on  some  PPC  systems.  There  may  be some nasty surprises. I
remember that we had to fix a couple of drivers  in  our  old  2.4.25
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: wd at denx.de
As a general rule, the freedom of any people can  be  judged  by  the
volume of their laughter.



From wd at denx.de  Wed Apr 30 17:45:23 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 17:45:23 +0200
Subject: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian
	mode
In-Reply-To: Your message of "Wed, 30 Apr 2008 21:04:33 +0530."
	<47230CE166B64744B0120173E4C2161E04D531CF@BLR-EC-MBX01.wipro.com>
Message-ID: <20080430154523.13BA824681@gemini.denx.de>

In message <47230CE166B64744B0120173E4C2161E04D531CF at BLR-EC-MBX01.wipro.com> you wrote:
>
> We are using MPC8349E based board in big endian mode. It is working fine
> with U-Boot 1.1.3 .

Yes. Big endian is the natural byte order for PowerPC.

> Now due to some reason we have to configure 8349E in little endian mode.

Don't. You're on the road to trouble. Stop now.

Figure out what "some reason" is, and how to  solve  it  differently,
i. e. in a sane way.

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: wd at denx.de
You see things; and you say ``Why?'' But I dream  things  that  never
were; and I say ``Why not?''
       - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1



From wd at denx.de  Wed Apr 30 17:47:26 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 17:47:26 +0200
Subject: [U-Boot-Users] [PATCH] cmd_nand.c: fix another 'incompatible
	pointer type' warning.
Message-ID: <1209570446-10418-1-git-send-email-wd@denx.de>

Signed-off-by: Wolfgang Denk <wd at denx.de>
---
 common/cmd_nand.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 1a3c1df..37eb41b 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -110,7 +110,7 @@ arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, size_t *size
 			}
 			*off = part->offset;
 			if (argc >= 2) {
-				if (!(str2long(argv[1], size))) {
+				if (!(str2long(argv[1], (ulong *)size))) {
 					printf("'%s' is not a number\n", argv[1]);
 					return -1;
 				}
-- 
1.5.4.2




From gerald.vanbaren at ge.com  Wed Apr 30 17:51:48 2008
From: gerald.vanbaren at ge.com (Jerry Van Baren)
Date: Wed, 30 Apr 2008 11:51:48 -0400
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <20080430153830.3CC7024681@gemini.denx.de>
References: <20080430153830.3CC7024681@gemini.denx.de>
Message-ID: <48189594.30004@ge.com>

Wolfgang Denk wrote:
> In message <48188584.3060109 at ge.com> you wrote:
>> The solution in the PowerPC world is to add a "eieio" or "sync" 
>> instruction[1] appropriately[2], which prevents the bus interface unit 
>> from reordering the memory operations.
> 
> No, the solution for ALL architectures  is  to  use  the  appropriate
> accessor  macros which take care of such things (and probably contain
> calls like sync or similar).
> 
> Best regards,
> 
> Wolfgang Denk

Agreed.

If my theory is correct, Adrian has turned up a problem with the ARM 
configuration that apparently only shows up for the PXA250.  Or I'm 
blowing smoke - nothing to see, move along.

The hairs on the back of my neck say it is a sync/bus interface unit 
problem.

I don't know if it is significant, not being very intimately familiar 
with ARM (and, in particular, the PXA250), but my quick grep turns up 
./include/asm-arm/io.h and a quick browsing shows no syncs.  The hairs 
on the back of my neck are starting to ache.  ;-)

static inline void sync(void)
{
}

#define __arch_getb(a)                  (*(volatile unsigned char *)(a))

gvb




From dirk.behme at googlemail.com  Wed Apr 30 18:02:59 2008
From: dirk.behme at googlemail.com (dirk.behme at googlemail.com)
Date: Wed, 30 Apr 2008 18:02:59 +0200
Subject: [U-Boot-Users] [PATCH] Fix warning in env_nand.c if compiled for
	DaVinci Schmoogie
Message-ID: <1209571379-20209-1-git-send-email-dirk.behme@gmail.com>

Fix warnings

nv_nand.c: In function 'saveenv':
env_nand.c:200: warning: passing argument 3 of 'nand_write' from incompatible pointer type
env_nand.c: In function 'env_relocate_spec':
env_nand.c:275: warning: passing argument 3 of 'nand_read' from incompatible pointer type

if compiled for davinci_schmoogie_config.

Signed-off-by: Dirk Behme <dirk.behme at gmail.com>

Index: uboot_davinci/common/env_nand.c
===================================================================
--- uboot_davinci.orig/common/env_nand.c
+++ uboot_davinci/common/env_nand.c
@@ -102,7 +102,7 @@ uchar env_get_char_spec (int index)
 int env_init(void)
 {
 #if defined(ENV_IS_EMBEDDED)
-	ulong total;
+	size_t total;
 	int crc1_ok = 0, crc2_ok = 0;
 	env_t *tmp_env1, *tmp_env2;
 
@@ -188,7 +188,7 @@ int saveenv(void)
 #else /* ! CFG_ENV_OFFSET_REDUND */
 int saveenv(void)
 {
-	ulong total;
+	size_t total;
 	int ret = 0;
 
 	puts ("Erasing Nand...");
@@ -268,7 +268,7 @@ void env_relocate_spec (void)
 void env_relocate_spec (void)
 {
 #if !defined(ENV_IS_EMBEDDED)
-	ulong total;
+	size_t total;
 	int ret;
 
 	total = CFG_ENV_SIZE;



From scottwood at freescale.com  Wed Apr 30 18:02:19 2008
From: scottwood at freescale.com (Scott Wood)
Date: Wed, 30 Apr 2008 11:02:19 -0500
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <1209569696.16926.53.camel@gentoo-jocke.transmode.se>
References: <20080429204348.1ED4C247B4@gemini.denx.de>
	<alpine.DEB.1.10.0804291703010.13610@pmy.adscville>
	<48179041.6080008@ge.com>
	<alpine.DEB.1.10.0804300949360.13610@pmy.adscville>
	<48188584.3060109@ge.com>
	<1209568270.16926.32.camel@gentoo-jocke.transmode.se>
	<20080430152141.GE23545@ld0162-tx32.am.freescale.net>
	<1209569696.16926.53.camel@gentoo-jocke.transmode.se>
Message-ID: <20080430160219.GB23995@ld0162-tx32.am.freescale.net>

On Wed, Apr 30, 2008 at 05:34:56PM +0200, Joakim Tjernlund wrote:
> 
> On Wed, 2008-04-30 at 10:21 -0500, Scott Wood wrote:
> > On Wed, Apr 30, 2008 at 05:11:09PM +0200, Joakim Tjernlund wrote:
> > > Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
> > > SOC drivers are encouraged to use them. What a waste :(
> > 
> > sync is needed in some of the cases, to sync I/O accesses with DMA buffer
> > accesses.  Ideally, we could trust the driver writers to put
> > synchronization in where needed, but it seems Linux has too much x86
> > heritage for that.
> 
> Perhaps, is sync needed in this case for non-smp too? or is eieio
> enough?

Yes, sync is needed -- eieio doesn't order between stores to cacheable
memory and stores to cache-inhibited memory.

> Anyway, just have a look at ucc_geth 

Do I have to? :-)

> and you will see that most such accesses are just about getting the
> endian right.

If you mean the descriptor accesses, ordering is relevant there as well.

> > There should at least be raw alternatives, though...
> 
> There need be a get-the-endian-right-but-no-sync.

Agreed.  There's cpu_to_be32, etc., but that doesn't fit well with
load/store endian-swapping instructions.

> After all 2.4 managed well without using the in/out be() functions.

I see in/out_be32() in 2.4...  and the significant chunks of code that
use volatile pointers instead, I wouldn't consider to be managing "well";
they just happen to work most of the time.

-Scott



From joakim.tjernlund at transmode.se  Wed Apr 30 18:11:38 2008
From: joakim.tjernlund at transmode.se (Joakim Tjernlund)
Date: Wed, 30 Apr 2008 18:11:38 +0200
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <20080430160219.GB23995@ld0162-tx32.am.freescale.net>
References: <20080429204348.1ED4C247B4@gemini.denx.de>
	<alpine.DEB.1.10.0804291703010.13610@pmy.adscville>
	<48179041.6080008@ge.com>
	<alpine.DEB.1.10.0804300949360.13610@pmy.adscville>
	<48188584.3060109@ge.com>
	<1209568270.16926.32.camel@gentoo-jocke.transmode.se>
	<20080430152141.GE23545@ld0162-tx32.am.freescale.net>
	<1209569696.16926.53.camel@gentoo-jocke.transmode.se>
	<20080430160219.GB23995@ld0162-tx32.am.freescale.net>
Message-ID: <1209571898.16926.58.camel@gentoo-jocke.transmode.se>


On Wed, 2008-04-30 at 11:02 -0500, Scott Wood wrote:
> On Wed, Apr 30, 2008 at 05:34:56PM +0200, Joakim Tjernlund wrote:
> > 
> > On Wed, 2008-04-30 at 10:21 -0500, Scott Wood wrote:
> > > On Wed, Apr 30, 2008 at 05:11:09PM +0200, Joakim Tjernlund wrote:
> > > > Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
> > > > SOC drivers are encouraged to use them. What a waste :(
> > > 
> > > sync is needed in some of the cases, to sync I/O accesses with DMA buffer
> > > accesses.  Ideally, we could trust the driver writers to put
> > > synchronization in where needed, but it seems Linux has too much x86
> > > heritage for that.
> > 
> > Perhaps, is sync needed in this case for non-smp too? or is eieio
> > enough?
> 
> Yes, sync is needed -- eieio doesn't order between stores to cacheable
> memory and stores to cache-inhibited memory.

OK, thanks

> 
> > Anyway, just have a look at ucc_geth 
> 
> Do I have to? :-)

Yes, it needs a little love here and there :)
Especially Timur, his little "rename the tx/rx clock" trick
costed me a few days :)

 Jocke



From ksi at koi8.net  Wed Apr 30 18:16:39 2008
From: ksi at koi8.net (ksi at koi8.net)
Date: Wed, 30 Apr 2008 09:16:39 -0700 (PDT)
Subject: [U-Boot-Users] [PATCH] Fix warning in env_nand.c if compiled
 for DaVinci Schmoogie
In-Reply-To: <1209571379-20209-1-git-send-email-dirk.behme@gmail.com>
References: <1209571379-20209-1-git-send-email-dirk.behme@gmail.com>
Message-ID: <Pine.LNX.4.64ksi.0804300915290.28911@home-gw.koi8.net>

On Wed, 30 Apr 2008, dirk.behme at googlemail.com wrote:

Ack by: Sergey Kubushyn <ksi at koi8.net>

P.S. Dirk, you were faster than me :)

> Fix warnings
>
> nv_nand.c: In function 'saveenv':
> env_nand.c:200: warning: passing argument 3 of 'nand_write' from
> incompatible pointer type
> env_nand.c: In function 'env_relocate_spec':
> env_nand.c:275: warning: passing argument 3 of 'nand_read' from
> incompatible pointer type
>
> if compiled for davinci_schmoogie_config.
>
> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>
>
> Index: uboot_davinci/common/env_nand.c
> ===================================================================
> --- uboot_davinci.orig/common/env_nand.c
> +++ uboot_davinci/common/env_nand.c
> @@ -102,7 +102,7 @@ uchar env_get_char_spec (int index)
> int env_init(void)
> {
> #if defined(ENV_IS_EMBEDDED)
> -	ulong total;
> +	size_t total;
> 	int crc1_ok = 0, crc2_ok = 0;
> 	env_t *tmp_env1, *tmp_env2;
>
> @@ -188,7 +188,7 @@ int saveenv(void)
> #else /* ! CFG_ENV_OFFSET_REDUND */
> int saveenv(void)
> {
> -	ulong total;
> +	size_t total;
> 	int ret = 0;
>
> 	puts ("Erasing Nand...");
> @@ -268,7 +268,7 @@ void env_relocate_spec (void)
> void env_relocate_spec (void)
> {
> #if !defined(ENV_IS_EMBEDDED)
> -	ulong total;
> +	size_t total;
> 	int ret;
>
> 	total = CFG_ENV_SIZE;
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
> avaone
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************



From Ken.Fuchs at bench.com  Wed Apr 30 18:25:43 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 30 Apr 2008 11:25:43 -0500
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <001701c8aacd$49ba68b0$dd2f3a10$@savary@kerlink.fr>
Message-ID: <AA28F077645B324881335614E4F7C428034CF8@win-ex01.bench.com>

Pierre Savary wrote:

> Thanks a lot for your patch. I will test it next week.

Sorry, that patch was manually constructed.  I forgot about 
include/asm-arm/arch-at91sam926x/at91sam9261.h which includes
the pin definitions used by the MCI controller.  An ancillary
patch for this file is appended below.  Of course it is useful
only for AT91SAM9261 based boards.

Note that Atmel used different conventions for defining
AT91SAM9261 and AT91SAM9260/AT91SAM9263 hardware (at least
for GPIO pin) definitions.  This will cause problems in
applying the previously posted u-boot-at91sam9261-mmc-v4.patch
for boards not based on the AT91SAM9261 (i.e.
AT91SAM9260/AT91SAM9263).

Note that I added the MMC v4.x code without access to the spec.
All I had was a MoviNAND manual, which assumes access to the
MMC v4.x spec.  (Note that the final CMD1 arg. is the correct
and recommended value for MoviNAND chips by their field eng.)
The patch included a lot of commented out (/* */ & '#if 0')
code used to help me understand MMC v4.x, at least well enough
to get the MoviNAND working reliably.

I never did get multi-block read or write working; The code
for it is included in the previous sent patch.  As I mentioned
before, I also didn't get 4 bit MMC working, but the code for
that is _not_ included in the patch anyway.

The Linux MMC code enables 4 bit for AT91SAM9260/AT91SAM9263
and only 1 bit for AT91SAM9261.  Does anyone know why?
I'd really like to get 4 bit transfers working on the 9261
via U-Boot.

I may try to put together a better patch using an earlier
version of my U-Boot code as a basis.  I'm not so sure my
previously sent patch will apply as cleanly as I had thought.

> Have you ever tested your U-Boot with 4GB or 8GB moviNAND?

No.

Sincerely,

Ken Fuchs

u-boot-at9261-mci-gpio-pins.patch
=================================

svn diff -r21 
Index: include/asm-arm/arch-at91sam926x/at91sam9261.h
===================================================================
--- include/asm-arm/arch-at91sam926x/at91sam9261.h	(revision 21)
+++ include/asm-arm/arch-at91sam926x/at91sam9261.h	(working copy)
@@ -17,6 +17,10 @@
  * Generated           : AT91 SW Application Group  03/30/2005
(17:05:06)
  * 
  *
------------------------------------------------------------------------
----
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Added numerous GPIO pin definitions for custom AT91SAM9261 board.
+ *
 */
 #ifndef AT91SAM9261_H
 #define AT91SAM9261_H
@@ -1330,8 +1334,10 @@
 /*
************************************************************************
***** */
 #define AT91C_PIO_PA0        ((unsigned int) 1 <<  0) /* Pin Controlled
by PA0 */
 #define AT91C_PA0_MISO0    ((unsigned int) AT91C_PIO_PA0) /*  SPI0
Master In Slave */
+#define AT91C_PA0_MCDA0    ((unsigned int) AT91C_PIO_PA0) /*  MMC NAND
MCDA0 */
 #define AT91C_PIO_PA1        ((unsigned int) 1 <<  1) /* Pin Controlled
by PA1 */
 #define AT91C_PA1_MOSI0    ((unsigned int) AT91C_PIO_PA1) /*  SPI0
Master Out Slave */
+#define AT91C_PA1_MCCDA    ((unsigned int) AT91C_PIO_PA1) /*  MMC NAND
MCCDA */
 #define AT91C_PIO_PA10       ((unsigned int) 1 << 10) /* Pin Controlled
by PA10 */
 #define AT91C_PA10_DTXD     ((unsigned int) AT91C_PIO_PA10) /*  DBGU
Debug Transmit Data */
 #define AT91C_PA10_LFON    ((unsigned int) AT91C_PIO_PA10)
@@ -1346,6 +1352,7 @@
 #define AT91C_PA16_NPCS15  ((unsigned int) AT91C_PIO_PA16) /* GPIO:
SPI1 CS5 */
 #define AT91C_PIO_PA2        ((unsigned int) 1 <<  2) /* Pin Controlled
by PA2 */
 #define AT91C_PA2_SPCK0    ((unsigned int) AT91C_PIO_PA2) /*  SPI0
Serial Clock */
+#define AT91C_PA2_MCCK     ((unsigned int) AT91C_PIO_PA2) /*  MMC NAND
MCCK  */
 #define AT91C_PIO_PA23       ((unsigned int) 1 << 23) /* Pin Controlled
by PA23 */
 #define AT91C_PA23_NPCS14  ((unsigned int) AT91C_PIO_PA23) /* GPIO:
SPI1 CS4 */
 #define AT91C_PIO_PA24       ((unsigned int) 1 << 24) /* Pin Controlled
by PA24 */
@@ -1358,10 +1365,13 @@
 #define AT91C_PA3_NPCS00   ((unsigned int) AT91C_PIO_PA3) /*  SPI0
Peripheral Chip Select 0 */
 #define AT91C_PIO_PA4        ((unsigned int) 1 <<  4) /* Pin Controlled
by PA4 */
 #define AT91C_PA4_NPCS01   ((unsigned int) AT91C_PIO_PA4) /*  SPI0
Peripheral Chip Select 1 */
+#define AT91C_PA4_MCDA1    ((unsigned int) AT91C_PIO_PA4) /*  MMC NAND
MCDA1 */
 #define AT91C_PIO_PA5        ((unsigned int) 1 <<  5) /* Pin Controlled
by PA5 */
 #define AT91C_PA5_NPCS02   ((unsigned int) AT91C_PIO_PA5) /*  SPI0
Peripheral Chip Select 2 */
+#define AT91C_PA5_MCDA2    ((unsigned int) AT91C_PIO_PA5) /*  MMC NAND
MCDA2 */
 #define AT91C_PIO_PA6        ((unsigned int) 1 <<  6) /* Pin Controlled
by PA6 */
 #define AT91C_PA6_NPCS03   ((unsigned int) AT91C_PIO_PA6) /*  SPI0
Peripheral Chip Select 3 */
+#define AT91C_PA6_MCDA3    ((unsigned int) AT91C_PIO_PA6) /*  MMC NAND
MCDA3 */
 #define AT91C_PIO_PA9        ((unsigned int) 1 <<  9) /* Pin Controlled
by PA9  */
 #define AT91C_PA9_DRXD     ((unsigned int) AT91C_PIO_PA9) /*  DBGU
Debug Receive Data */
 #define AT91C_PIO_PB0        ((unsigned int) 1 <<  0) /* Pin Controlled
by PB0 */



From scottwood at freescale.com  Wed Apr 30 17:38:02 2008
From: scottwood at freescale.com (Scott Wood)
Date: Wed, 30 Apr 2008 10:38:02 -0500
Subject: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c
	for MPC8610HPCD board
In-Reply-To: <1209555280-23311-1-git-send-email-agust@denx.de>
References: <20080429152530.6A726247B4@gemini.denx.de>
	<1209555280-23311-1-git-send-email-agust@denx.de>
Message-ID: <20080430153802.GA23818@ld0162-tx32.am.freescale.net>

On Wed, Apr 30, 2008 at 01:34:40PM +0200, Anatolij Gustschin wrote:
> diff --git a/include/net.h b/include/net.h
> index f6decdc..9a2f03f 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -412,10 +412,10 @@ extern void	print_IPaddr (IPaddr_t);
>   * footprint in our tests.
>   */
>  /* return IP *in network byteorder* */
> -static inline IPaddr_t NetReadIP(void *from)
> +static inline IPaddr_t NetReadIP(volatile void *from)
>  {
>  	IPaddr_t ip;
> -	memcpy((void*)&ip, from, sizeof(ip));
> +	memcpy((void*)&ip, (void*)from, sizeof(ip));
>  	return ip;
>  }
>  

Maybe we should remove the volatile from the callers instead?

-Scott



From Tsi-Chung.Liew at freescale.com  Wed Apr 30 19:10:23 2008
From: Tsi-Chung.Liew at freescale.com (Tsi-Chung Liew)
Date: Wed, 30 Apr 2008 12:10:23 -0500
Subject: [U-Boot-Users] [PATCH] ColdFire: Get information from the correct
	GCC
Message-ID: <1209575423-1244-1-git-send-email-Tsi-Chung.Liew@freescale.com>

From: TsiChung Liew <Tsi-Chung.Liew at freescale.com>

Signed-off-by: Kurt Mahan <kmahan at freescale.com>
Signed-off-by: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
---
 cpu/mcf5227x/config.mk   |    2 +-
 cpu/mcf523x/config.mk    |    2 +-
 cpu/mcf52x2/config.mk    |    2 +-
 cpu/mcf532x/config.mk    |    2 +-
 cpu/mcf5445x/config.mk   |    2 +-
 cpu/mcf547x_8x/config.mk |    2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/cpu/mcf5227x/config.mk b/cpu/mcf5227x/config.mk
index 8d60fd6..2e50696 100644
--- a/cpu/mcf5227x/config.mk
+++ b/cpu/mcf5227x/config.mk
@@ -24,7 +24,7 @@
 #
 
 PLATFORM_RELFLAGS += -ffixed-d7 -msep-data
-ifeq ($(findstring 4.2,$(shell $(CC) --version)),4.2)
+ifeq ($(findstring 4.2,$(shell $(CROSS_COMPILE)gcc --version)),4.2)
 PLATFORM_CPPFLAGS += -mcpu=5208 -fPIC
 else
 PLATFORM_CPPFLAGS += -m5307 -fPIC
diff --git a/cpu/mcf523x/config.mk b/cpu/mcf523x/config.mk
index 93645a3..73fb08d 100644
--- a/cpu/mcf523x/config.mk
+++ b/cpu/mcf523x/config.mk
@@ -24,7 +24,7 @@
 #
 
 PLATFORM_RELFLAGS += -ffixed-d7 -msep-data
-ifeq ($(findstring 4.2,$(shell $(CC) --version)),4.2)
+ifeq ($(findstring 4.2,$(shell $(CROSS_COMPILE)gcc --version)),4.2)
 PLATFORM_CPPFLAGS += -mcpu=5235 -fPIC
 else
 PLATFORM_CPPFLAGS += -m5307 -fPIC
diff --git a/cpu/mcf52x2/config.mk b/cpu/mcf52x2/config.mk
index 650e340..be360f8 100644
--- a/cpu/mcf52x2/config.mk
+++ b/cpu/mcf52x2/config.mk
@@ -34,7 +34,7 @@ is5275:=$(shell grep CONFIG_M5275 $(TOPDIR)/include/$(cfg))
 is5282:=$(shell grep CONFIG_M5282 $(TOPDIR)/include/$(cfg))
 
 
-ifeq ($(findstring 4.2,$(shell $(CC) --version)),4.2)
+ifeq ($(findstring 4.2,$(shell $(CROSS_COMPILE)gcc --version)),4.2)
 
 ifneq (,$(findstring CONFIG_M5249,$(is5249)))
 PLATFORM_CPPFLAGS += -mcpu=5249
diff --git a/cpu/mcf532x/config.mk b/cpu/mcf532x/config.mk
index 16a0bc3..e4a3cf9 100644
--- a/cpu/mcf532x/config.mk
+++ b/cpu/mcf532x/config.mk
@@ -24,7 +24,7 @@
 #
 
 PLATFORM_RELFLAGS += -ffixed-d7 -msep-data
-ifeq ($(findstring 4.2,$(shell $(CC) --version)),4.2)
+ifeq ($(findstring 4.2,$(shell $(CROSS_COMPILE)gcc --version)),4.2)
 PLATFORM_CPPFLAGS += -mcpu=5329 -fPIC
 else
 PLATFORM_CPPFLAGS += -m5307 -fPIC
diff --git a/cpu/mcf5445x/config.mk b/cpu/mcf5445x/config.mk
index 88433f2..a85d0f9 100644
--- a/cpu/mcf5445x/config.mk
+++ b/cpu/mcf5445x/config.mk
@@ -24,7 +24,7 @@
 #
 
 PLATFORM_RELFLAGS += -ffixed-d7 -msep-data
-ifeq ($(findstring 4.2,$(shell $(CC) --version)),4.2)
+ifeq ($(findstring 4.2,$(shell $(CROSS_COMPILE)gcc --version)),4.2)
 PLATFORM_CPPFLAGS += -mcpu=54455 -fPIC
 else
 PLATFORM_CPPFLAGS += -m5407 -fPIC
diff --git a/cpu/mcf547x_8x/config.mk b/cpu/mcf547x_8x/config.mk
index e5f4385..eb6b50b 100644
--- a/cpu/mcf547x_8x/config.mk
+++ b/cpu/mcf547x_8x/config.mk
@@ -24,7 +24,7 @@
 #
 
 PLATFORM_RELFLAGS += -ffixed-d7 -msep-data
-ifeq ($(findstring 4.2,$(shell $(CC) --version)),4.2)
+ifeq ($(findstring 4.2,$(shell $(CROSS_COMPILE)gcc --version)),4.2)
 PLATFORM_CPPFLAGS += -mcpu=5485 -fPIC
 else
 PLATFORM_CPPFLAGS += -m5407 -fPIC
-- 
1.5.4.1




From Tsi-Chung.Liew at freescale.com  Wed Apr 30 19:10:47 2008
From: Tsi-Chung.Liew at freescale.com (Tsi-Chung Liew)
Date: Wed, 30 Apr 2008 12:10:47 -0500
Subject: [U-Boot-Users] [PATCH] ColdFire: Fix compilation issue caused by
	new changes in fsl_i2c.c
Message-ID: <1209575447-1266-1-git-send-email-Tsi-Chung.Liew@freescale.com>

From: TsiChung Liew <Tsi-Chung.Liew at freescale.com>

Signed-off-by: Luigi Comio Mantellini <luigi.mantellini at idf-hit.com>
Signed-off-by: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
---
 include/asm-m68k/global_data.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/include/asm-m68k/global_data.h b/include/asm-m68k/global_data.h
index 958736e..c897f2b 100644
--- a/include/asm-m68k/global_data.h
+++ b/include/asm-m68k/global_data.h
@@ -47,6 +47,10 @@ typedef	struct	global_data {
 	unsigned long	vco_clk;
 	unsigned long	flb_clk;
 #endif
+#ifdef CONFIG_FSL_I2C
+	unsigned long	i2c1_clk;
+	unsigned long	i2c2_clk;
+#endif
 	unsigned long	ram_size;	/* RAM size */
 	unsigned long	reloc_off;	/* Relocation Offset */
 	unsigned long	reset_status;	/* reset status register at boot	*/
-- 
1.5.4.1




From Tsi-Chung.Liew at freescale.com  Wed Apr 30 19:11:19 2008
From: Tsi-Chung.Liew at freescale.com (Tsi-Chung Liew)
Date: Wed, 30 Apr 2008 12:11:19 -0500
Subject: [U-Boot-Users] [PATCH] ColdFire: Fix ethernet hang issue for
	mcf547x_8x
Message-ID: <1209575479-1286-1-git-send-email-Tsi-Chung.Liew@freescale.com>

From: TsiChung Liew <Tsi-Chung.Liew at freescale.com>

The ethernet hang is caused by receiving buffer in DRAM is not
yet ready due to access cycles require longer time in DRAM.
Relocate DMA buffer descriptors from DRAM to internal SRAM.

Signed-off-by: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
---
 drivers/net/fsl_mcdmafec.c |   22 +++++++++++++++++++++-
 include/configs/M5475EVB.h |    1 +
 include/configs/M5485EVB.h |    1 +
 3 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/drivers/net/fsl_mcdmafec.c b/drivers/net/fsl_mcdmafec.c
index 0c876f3..2ef91f2 100644
--- a/drivers/net/fsl_mcdmafec.c
+++ b/drivers/net/fsl_mcdmafec.c
@@ -95,7 +95,11 @@ struct fec_info_dma fec_info[] = {
 	 0,			/* duplex and speed */
 	 0,			/* phy name */
 	 0,			/* phy name init */
+#ifdef CFG_DMA_USE_INTSRAM
+	 DBUF_LENGTH,		/* RX BD */
+#else
 	 0,			/* RX BD */
+#endif
 	 0,			/* TX BD */
 	 0,			/* rx Index */
 	 0,			/* tx Index */
@@ -164,7 +168,8 @@ static void dbg_fec_regs(struct eth_device *dev)
 }
 #endif
 
-static void set_fec_duplex_speed(volatile fecdma_t * fecp, bd_t * bd, int dup_spd)
+static void set_fec_duplex_speed(volatile fecdma_t * fecp, bd_t * bd,
+				 int dup_spd)
 {
 	if ((dup_spd >> 16) == FULL) {
 		/* Set maximum frame length */
@@ -513,6 +518,9 @@ int mcdmafec_initialize(bd_t * bis)
 {
 	struct eth_device *dev;
 	int i;
+#ifdef CFG_DMA_USE_INTSRAM
+	u32 tmp = CFG_INTSRAM + 0x2000;
+#endif
 
 	for (i = 0; i < sizeof(fec_info) / sizeof(fec_info[0]); i++) {
 
@@ -533,6 +541,17 @@ int mcdmafec_initialize(bd_t * bis)
 		dev->recv = fec_recv;
 
 		/* setup Receive and Transmit buffer descriptor */
+#ifdef CFG_DMA_USE_INTSRAM
+		fec_info[i].rxbd = (int)fec_info[i].rxbd + tmp;
+		tmp = fec_info[i].rxbd;
+		fec_info[i].txbd =
+		    (int)fec_info[i].txbd + tmp + (PKTBUFSRX * sizeof(cbd_t));
+		tmp = fec_info[i].txbd;
+		fec_info[i].txbuf =
+		    (int)fec_info[i].txbuf + tmp +
+		    (CFG_TX_ETH_BUFFER * sizeof(cbd_t));
+		tmp = fec_info[i].txbuf;
+#else
 		fec_info[i].rxbd =
 		    (cbd_t *) memalign(CFG_CACHELINE_SIZE,
 				       (PKTBUFSRX * sizeof(cbd_t)));
@@ -541,6 +560,7 @@ int mcdmafec_initialize(bd_t * bis)
 				       (CFG_TX_ETH_BUFFER * sizeof(cbd_t)));
 		fec_info[i].txbuf =
 		    (char *)memalign(CFG_CACHELINE_SIZE, DBUF_LENGTH);
+#endif
 
 #ifdef ET_DEBUG
 		printf("rxbd %x txbd %x\n",
diff --git a/include/configs/M5475EVB.h b/include/configs/M5475EVB.h
index 6bb4619..fea7551 100644
--- a/include/configs/M5475EVB.h
+++ b/include/configs/M5475EVB.h
@@ -72,6 +72,7 @@
 #	define CONFIG_MII_INIT		1
 #	define CONFIG_HAS_ETH1
 
+#	define CFG_DMA_USE_INTSRAM	1
 #	define CFG_DISCOVER_PHY
 #	define CFG_RX_ETH_BUFFER	32
 #	define CFG_TX_ETH_BUFFER	48
diff --git a/include/configs/M5485EVB.h b/include/configs/M5485EVB.h
index cba51c8..454d0a2 100644
--- a/include/configs/M5485EVB.h
+++ b/include/configs/M5485EVB.h
@@ -72,6 +72,7 @@
 #	define CONFIG_MII_INIT		1
 #	define CONFIG_HAS_ETH1
 
+#	define CFG_DMA_USE_INTSRAM	1
 #	define CFG_DISCOVER_PHY
 #	define CFG_RX_ETH_BUFFER	32
 #	define CFG_TX_ETH_BUFFER	48
-- 
1.5.4.1




From Andre.Schwarz at matrix-vision.de  Wed Apr 30 19:08:05 2008
From: Andre.Schwarz at matrix-vision.de (=?ISO-8859-1?Q?Andr=E9_Schwarz?=)
Date: Wed, 30 Apr 2008 19:08:05 +0200
Subject: [U-Boot-Users] Memory Size issue @ MPC83xx
Message-ID: <4818A775.9020009@matrix-vision.de>

All,

my MPC8343 based system is running fine, but I'm not able to use more 
than 256MB of memory.

Is this a general or known issue ?

I'm not quite sure where the problem is since u-boot *seems* to be 
running fine.

Situation :

- 2 Micron 16-Bit (2 GBits each) chips soldered down on the board giving 
512MByte total.
- Connected to CS0 @ 32-Bit memory bus.
- memory size defined and recognized correctly
- set up CS0_BNDS for 512MB
- set up BAT0 + BAT7 for mapping (a single BAT is limited to 256MB).
- configure cpu to use high BATs by setting HBE bit in CFG_HID2.
- dtb memory size set up correctly and "mtest" works all day from 16M to 
500M ....

Booting a 2.6.25 kernel crashes during dtb parsing.
Limiting memory size to 256MB and skipping BAT7 gives a running system.

At first glance this looks like a topic for the linuxppc list.
But it *could* also be a u-boot related issue ...


Any help is welcome !


regards,
Andr? Schwarz

MATRIX VISION GmbH, Talstra?e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Gesch?ftsf?hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner



From dzu at denx.de  Wed Apr 30 19:31:57 2008
From: dzu at denx.de (Detlev Zundel)
Date: Wed, 30 Apr 2008 19:31:57 +0200
Subject: [U-Boot-Users] bootargs for partitioned nand flash
In-Reply-To: <loom.20080425T174055-651@post.gmane.org> (Norman's message of
	"Fri, 25 Apr 2008 17:48:38 +0000 (UTC)")
References: <OF59F26445.61F7D04D-ON48257125.002C708D-48257125.002CF471@applera.com>
	<20060302092625.9A01C3535EA@atlas.denx.de>
	<loom.20080425T174055-651@post.gmane.org>
Message-ID: <m2prs7xn8y.fsf@ohwell.denx.de>

Hi Norman,

> Wolfgang Denk <wd <at> denx.de> writes:
>
>> 
>> In message <OF59F26445.61F7D04D-ON48257125.002C708D-48257125.002CF471 <at>
> applera.com> you wrote:
>
>> 
>> Also note that a cramfs may fail  to  work  in  case  there  are  bad
>> sectors in your NAND device.
>> 
>
> Wolfgang, this might be an off topic here.  I have a client requirement to have
> a  RFS like cramfs or squashfs on NAND.

Check the available documentation on NAND devices.  I found this
application note to be a real eye opener[1].  Especially the section
"NAND Flash is Not a Hard Drive" is a must read.  Maybe you reconsider
the requirement.

> If I use the u-boot nand write command to write the cramfs to a MTD
> partition.  How does nand write treat a bad block?

What part of this section from doc/README.nand is not clear to you?

   nand write.jffs2 addr ofs|partition size
      Like `write', but blocks that are marked bad are skipped and the
      data is written to the next block instead. This allows writing a
      JFFS2 image, as long as the image is short enough to fit even
      after skipping the bad blocks. Compact images, such as those
      produced by mkfs.jffs2 should work well, but loading an image
      copied from another flash is going to be trouble if there are any
      bad block

> I am thinking that if nand write skip to the next block, then I might
> be able to modify nand read...  Or is there a better way?

What does the block layer of MTD in linux do?  This is a much more
interesting question.  As far as I can see, this layer will not be able
to handle any bad blocks.

Unless I don't see a very clever solution, putting such a filesystem on
a flaky substrate like NAND really needs another layer handling the
shuffling around - UBI comes to mind here, but I do not have any
experiences with it (yet).

Cheers
  Detlev

[1] http://download.micron.com/pdf/technotes/nand/tn2917.pdf

-- 
These days, even the most pure and abstract mathematics is in danger
to be applied.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de



From jdl at freescale.com  Wed Apr 30 20:13:26 2008
From: jdl at freescale.com (Jon Loeliger)
Date: Wed, 30 Apr 2008 13:13:26 -0500
Subject: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c
 for MPC8610HPCD board
In-Reply-To: <48188C90.8080409@freescale.com>
References: <20080429152530.6A726247B4@gemini.denx.de>	<1209555280-23311-1-git-send-email-agust@denx.de>
	<227D16F0-1807-4731-B0D2-E8D7ACDB86C5@kernel.crashing.org>
	<48188C90.8080409@freescale.com>
Message-ID: <4818B6C6.20701@freescale.com>

Timur Tabi wrote:
> Kumar Gala wrote:
> 
>> nothing against this patch, but should we change MPC8610HPCD to use - 
>> Os like everyone else?
> 
> Beats me.  git-blame points to Jon, so he'll have to tell you where the original
> config.mk came from.

Bah.  There is, let's see.... exactly one commit for that file:

    % git log board/freescale/mpc8610hpcd/config.mk
    commit 3dd2db53ceb0dff80f25c2a07f83f29b907b403e
    Author: Jon Loeliger <jdl at freescale.com>
    Date:   Tue Oct 16 13:54:01 2007 -0500

        Initial mpc8610hpcd board files.

        Signed-off-by: Ed Swarthout <Ed.Swarthout at freescale.com>
        Signed-off-by: Mahesh Jade <mahesh.jade at freescale.com>
        Signed-off-by: Jason Jin <Jason.jin at freescale.com>
        Signed-off-by: Jon Loeliger <jdl at freescale.com>

So, I'm guessing, it came from the Ed.  That is, it came that way
from the Day One.  So there.

jdl



From scottwood at freescale.com  Wed Apr 30 17:21:41 2008
From: scottwood at freescale.com (Scott Wood)
Date: Wed, 30 Apr 2008 10:21:41 -0500
Subject: [U-Boot-Users] cfi_flash.c and lost volatile qualifier
In-Reply-To: <1209568270.16926.32.camel@gentoo-jocke.transmode.se>
References: <20080429204348.1ED4C247B4@gemini.denx.de>
	<alpine.DEB.1.10.0804291703010.13610@pmy.adscville>
	<48179041.6080008@ge.com>
	<alpine.DEB.1.10.0804300949360.13610@pmy.adscville>
	<48188584.3060109@ge.com>
	<1209568270.16926.32.camel@gentoo-jocke.transmode.se>
Message-ID: <20080430152141.GE23545@ld0162-tx32.am.freescale.net>

On Wed, Apr 30, 2008 at 05:11:09PM +0200, Joakim Tjernlund wrote:
> Yet the in_bex()/out_bex() functions in PowerPC linux uses sync and all
> SOC drivers are encouraged to use them. What a waste :(

sync is needed in some of the cases, to sync I/O accesses with DMA buffer
accesses.  Ideally, we could trust the driver writers to put
synchronization in where needed, but it seems Linux has too much x86
heritage for that.

There should at least be raw alternatives, though...

-Scott



From timur at freescale.com  Wed Apr 30 21:19:08 2008
From: timur at freescale.com (Timur Tabi)
Date: Wed, 30 Apr 2008 14:19:08 -0500
Subject: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c
 for MPC8610HPCD board
In-Reply-To: <4818B6C6.20701@freescale.com>
References: <20080429152530.6A726247B4@gemini.denx.de>	<1209555280-23311-1-git-send-email-agust@denx.de>
	<227D16F0-1807-4731-B0D2-E8D7ACDB86C5@kernel.crashing.org>
	<48188C90.8080409@freescale.com> <4818B6C6.20701@freescale.com>
Message-ID: <4818C62C.9050009@freescale.com>

Jon Loeliger wrote:

> So, I'm guessing, it came from the Ed.  That is, it came that way
> from the Day One.  So there.

I just tested it without -O2, and it works fine.  So the -O2 should be removed.

-- 
Timur Tabi
Linux kernel developer at Freescale



From timur at freescale.com  Wed Apr 30 21:54:16 2008
From: timur at freescale.com (Timur Tabi)
Date: Wed, 30 Apr 2008 14:54:16 -0500
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some
 86xx chips
In-Reply-To: <1208800273.28914.27.camel@ld0161-tx32>
References: <20080418041413.E011A248A0@gemini.denx.de>
	<1208800273.28914.27.camel@ld0161-tx32>
Message-ID: <4818CE68.3040901@freescale.com>

Wolfgang, I think you forgot this one.

Jon Loeliger wrote:
> On Fri, 2008-04-18 at 06:14 +0200, Wolfgang Denk wrote:
>> In message <1207325771-1374-1-git-send-email-timur at freescale.com> you wrote:
>>> Some 86xx chips use CCB as the base clock for the I2C, and others used CCB/2.
>>> There is no pattern that can be used to determine which chips use which
>>> frequency, so the only way to determine is to look up the actual SOC
>>> designation and use the right value for that SOC.
>>>
>>> Signed-off-by: Timur Tabi <timur at freescale.com>
>> Will this goin through the 86xx custodian repo, or should I pull this
>> directly?
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
> 
> Please pick this up directly.
> 
> Thanks,
> jdl
> 
> 
> 


-- 
Timur Tabi
Linux kernel developer at Freescale



From wd at denx.de  Wed Apr 30 21:56:59 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 21:56:59 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification
In-Reply-To: Your message of "Wed, 30 Apr 2008 15:16:35 +0200."
	<20080430131635.311880@gmx.net>
Message-ID: <20080430195659.84C2524681@gemini.denx.de>

In message <20080430131635.311880 at gmx.net> you wrote:
> Hello Wolfgang,
> 
> I've found this merge-merge-error.
> 
> best regards
> Sascha Laue
> 
> From: Sascha Laue <sascha.laue at liebherr.com>
> Date: Wed, 30 Apr 2008 12:27:21 +0200
> Subject: [PATCH] fix manual merge error in lwmon5 posttest.
> 
> Signed-off-by: Sascha Laue <sascha.laue at liebherr.com>
> ---
>  post/board/lwmon5/sysmon.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)

Applied, manually - your patch is white-space corrupted and does not
apply:

Applying lwmon5: fix manual merge error in POST
error: patch failed: post/board/lwmon5/sysmon.c:132
error: post/board/lwmon5/sysmon.c: patch does not apply
Using index info to reconstruct a base tree...
error: patch failed: post/board/lwmon5/sysmon.c:132
error: post/board/lwmon5/sysmon.c: patch does not apply
Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Cannot fall back to three-way merge.
Patch failed at 0001.


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: wd at denx.de
The human mind treats a new idea the way the body  treats  a  strange
protein - it rejects it.                                 - P. Medawar



From Leonid at a-k-a.net  Wed Apr 30 22:02:34 2008
From: Leonid at a-k-a.net (Leonid)
Date: Wed, 30 Apr 2008 13:02:34 -0700
Subject: [U-Boot-Users] BDI2000 with ppc440epx.
Message-ID: <406A31B117F2734987636D6CCC93EE3C0364A9BE@ehost011-3.exch011.intermedia.net>

Hi:

I have some problem with AMCC PPC440epx CPU when it boots from NAND.

I am using sequoia.cfg file. If I do "reset halt" on BDI and then "go",
CPU doesn't boot. If I do "reset run" it boots OK. 

That points on some potential problem in .cfg file. OK, I removed entire
[INIT] section, but situation didn't change.

Moreover, when I set breakpoint to the function which surely is invoked
and do "reset run", I don't hit breakpoint (CPU boots till the end).

Do you have any idea what I may be doing wrong?

Thanks,

Leonid. 



From wd at denx.de  Wed Apr 30 22:18:10 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:18:10 +0200
Subject: [U-Boot-Users] [PATCH 1/1] Added preliminary support for the
	AT91SAM9263-EK. The following has been tested:
In-Reply-To: Your message of "Wed, 30 Apr 2008 18:44:58 +1000."
	<12095450983375-git-send-email-j.holzman@genesysdesign.com.au>
Message-ID: <20080430201810.9F7E224681@gemini.denx.de>

In message <12095450983375-git-send-email-j.holzman at genesysdesign.com.au> you wrote:

Commit message missing.

Signed-off-by line missing.

> diff --git a/board/atmel/at91sam9263ek/Makefile b/board/atmel/at91sam9263ek/Makefile
> new file mode 100644
> index 0000000..ca87a4c
> --- /dev/null
> +++ b/board/atmel/at91sam9263ek/Makefile
> @@ -0,0 +1,53 @@
> +#
> +# (C) Copyright 2003-2008
> +# Wolfgang Denk, DENX Software Engineering, wd <at> denx.de.
> +#
> +# See file CREDITS for list of people who contributed to this
> +# project.

Please add your own Copyright message!

> diff --git a/board/atmel/at91sam9263ek/at91sam9263ek.c b/board/atmel/at91sam9263ek/at91sam9263ek.c
> new file mode 100644
> index 0000000..b047209
> --- /dev/null
> +++ b/board/atmel/at91sam9263ek/at91sam9263ek.c
> @@ -0,0 +1,230 @@
> +/*
> + * (C) Copyright 2007-2008
> + * Stelian Pop <stelian.pop <at> leadtechdesign.com>
> + * Lead Tech Design <www.leadtechdesign.com>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.

Ditto.

> diff --git a/board/atmel/at91sam9263ek/led.c b/board/atmel/at91sam9263ek/led.c
> new file mode 100644
> index 0000000..2a71d61
> --- /dev/null
> +++ b/board/atmel/at91sam9263ek/led.c
> @@ -0,0 +1,78 @@
> +/*
> + * (C) Copyright 2007-2008
> + * Stelian Pop <stelian.pop <at> leadtechdesign.com>
> + * Lead Tech Design <www.leadtechdesign.com>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.

Ditto.

...
> +void power_LED_on(void)
> +{
> +	at91_set_gpio_value(POWER_LED, 1);
> +}
> +
> +void power_LED_off(void)
> +{
> +	at91_set_gpio_value(POWER_LED, 0);
> +}
> +
> +void user1_LED_on(void)
> +{
> +	at91_set_gpio_value(USER1_LED, 0);
> +}
..


This whole board/atmel/*/led.c stuff is a terrible mess and needs a
major cleanup one day.

Anybody volunteering? 

> diff --git a/board/atmel/at91sam9263ek/nand.c b/board/atmel/at91sam9263ek/nand.c
> new file mode 100644
> index 0000000..8c5b4b1
> --- /dev/null
> +++ b/board/atmel/at91sam9263ek/nand.c
> @@ -0,0 +1,76 @@
> +/*
> + * (C) Copyright 2007-2008
> + * Stelian Pop <stelian.pop <at> leadtechdesign.com>
> + * Lead Tech Design <www.leadtechdesign.com>
> + *
> + * (C) Copyright 2006 ATMEL Rousset, Lacressonniere Nicolas

Copyright entry...

> diff --git a/board/atmel/at91sam9263ek/partition.c b/board/atmel/at91sam9263ek/partition.c
> new file mode 100644
> index 0000000..389fb2c
> --- /dev/null
> +++ b/board/atmel/at91sam9263ek/partition.c
> @@ -0,0 +1,38 @@
> +/*
> + *
> + * 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.

Ditto.

> diff --git a/board/atmel/at91sam9263ek/u-boot.lds b/board/atmel/at91sam9263ek/u-boot.lds
> new file mode 100644
> index 0000000..05a6d83
> --- /dev/null
> +++ b/board/atmel/at91sam9263ek/u-boot.lds
> @@ -0,0 +1,57 @@
> +/*
> + * (C) Copyright 2002
> + * Gary Jennejohn, DENX Software Engineering, <gj <at> denx.de>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.

Ditto.

> diff --git a/include/asm-arm/arch-at91sam9/at91sam9263.h b/include/asm-arm/arch-at91sam9/at91sam9263.h
> new file mode 100644
> index 0000000..f91a357
> --- /dev/null
> +++ b/include/asm-arm/arch-at91sam9/at91sam9263.h
> @@ -0,0 +1,120 @@
> +/*
> + * include/asm-arm/arch-at91/at91sam9263.h
> + *
> + * (C) 2006 Andrew Victor

Hm. The Linux kernel has a file that's looking suspiciously similar,
but it reads:

	(C) 2007 Atmel Corporation.

Which one is correct?

> diff --git a/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h b/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h
> new file mode 100644
> index 0000000..c90f01a
> --- /dev/null
> +++ b/include/asm-arm/arch-at91sam9/at91sam9263_matrix.h
> @@ -0,0 +1,88 @@
> +/*
> + * include/asm-arm/arch-at91/at91sam9260_matrix.h
> + *
> + * Memory Controllers (MATRIX, EBI) - System peripherals registers.
> + * Based on AT91SAM9260 datasheet revision B.

Here the Linux file has

	Copyright (C) 2006 Atmel Corporation.

> diff --git a/include/asm-arm/arch-at91sam9/at91sam9263_mc.h b/include/asm-arm/arch-at91sam9/at91sam9263_mc.h
> new file mode 100644
> index 0000000..041138f
> --- /dev/null
> +++ b/include/asm-arm/arch-at91sam9/at91sam9263_mc.h
> @@ -0,0 +1,140 @@
> +/*
> + * include/asm-arm/arch-at91/at91sam926x_mc.h
> + *
> + * Memory Controllers (SMC, SDRAMC) - System peripherals registers.
> + * Based on AT91SAM9261 datasheet revision D.

Copyright ?

> diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h
> new file mode 100644
> index 0000000..3ae9846
> --- /dev/null
> +++ b/include/configs/at91sam9263ek.h
> @@ -0,0 +1,205 @@
> +/*
> + * (C) Copyright 2007-2008
> + * Stelian Pop <stelian.pop <at> leadtechdesign.com>
> + * Lead Tech Design <www.leadtechdesign.com>

Ditto ?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Change is the essential process of all existence.
	-- Spock, "Let That Be Your Last Battlefield",
	   stardate 5730.2



From adrian.filipi at eurotech.com  Wed Apr 30 22:27:02 2008
From: adrian.filipi at eurotech.com (Adrian Filipi)
Date: Wed, 30 Apr 2008 16:27:02 -0400 (EDT)
Subject: [U-Boot-Users] FW:  USB SUPPORT & get_vfatname
In-Reply-To: <alpine.DEB.1.10.0804251308480.12475@pmy.adscville>
References: <AA28F077645B324881335614E4F7C428034CE7@win-ex01.bench.com>
	<4811FC92.4080401@gandalf.sssup.it>
	<alpine.DEB.1.10.0804251308480.12475@pmy.adscville>
Message-ID: <alpine.DEB.1.10.0804301624360.13610@pmy.adscville>

On Fri, 25 Apr 2008, Adrian Filipi wrote:

>
> 	It looks like fat.c is not handling the case where the 
> sectors/cluster is 1, and the rood directory spans multiple clusters.
>
> 	In my case I was getting garbage directoy info after the invalid fat 
> error.  The attached patch stops the code from rolling past the end of 
> cluster.
>
> 	It looks like a loop to walk the allocation chain is neccessary. I 
> think get_contents() does all the right work, but it of course starts with a 
> directory entry, which we don't have yet for /.  A little refactoring might 
> do the trick.
>
> 	Adrian
> --
> Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com

 	FYI, my patch may have prevented walking off the end of a cluster 
on FAT32, but it has its own problems with larger directories on FAT16.

 	As such, I don't recommend using it.

 	Adrian
--
Linux Software Engineer | EuroTech, Inc. | www.eurotech-inc.com





From wd at denx.de  Wed Apr 30 22:29:28 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:29:28 +0200
Subject: [U-Boot-Users] [PATCH] lwmon5 dspic POST spezification
In-Reply-To: Your message of "Wed, 30 Apr 2008 15:23:38 +0200."
	<20080430132338.311900@gmx.net>
Message-ID: <20080430202928.DE01324681@gemini.denx.de>

In message <20080430132338.311900 at gmx.net> you wrote:
> Hello Wolfgang,
> 
> i found another problem with the sysmon POST.
> We have to add an offset to the voltage thresholds.
> 
> best regards,
> Sascha Laue
> 
> From: Sascha Laue <sascha.laue at liebherr.com>
> Date: Wed, 30 Apr 2008 13:32:17 +0200
> Subject: [PATCH] fix an offset error in lwmon5 sysmon0 post.
> 
> ---
>  post/board/lwmon5/sysmon.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)

Applied, manually again.

Please pay a bit more attention how to submit patches:

- comments that are not intended for the commit message belong *below*
  the '---' line
- this patch was again white space corrupted.

I *strongly* recommend to use 'git-send-email' to send patches.

The tools you are using are obviously inadequate.

Thanks in advance.

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: wd at denx.de
Alles Gescheite ist schon gedacht worden, man mu? nur versuchen,
es noch einmal zu denken.          -- Goethe, Maximen und Reflexionen



From wd at denx.de  Wed Apr 30 22:31:12 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:31:12 +0200
Subject: [U-Boot-Users] [PATCH] Fix warnings while compiling net/net.c
	for MPC8610HPCD board
In-Reply-To: Your message of "Wed, 30 Apr 2008 13:34:40 +0200."
	<1209555280-23311-1-git-send-email-agust@denx.de>
Message-ID: <20080430203112.2987D24681@gemini.denx.de>

In message <1209555280-23311-1-git-send-email-agust at denx.de> you wrote:
> MPC8610HPCD board adds -O2 gcc option to PLATFORM_CPPFLAGS
> causing overriding default -Os option. New gcc (ver. 4.2.2)
> produces warnings while compiling net/net.c file with -O2
> option. The patch is an attempt to fix this.
> 
> Signed-off-by: Anatolij Gustschin <agust at denx.de>
> ---
>  include/net.h |    8 ++++----
>  1 files changed, 4 insertions(+), 4 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: wd at denx.de
######## This message was made from 100% recycled electrons. ########



From Ken.Fuchs at bench.com  Wed Apr 30 22:31:33 2008
From: Ken.Fuchs at bench.com (Ken.Fuchs at bench.com)
Date: Wed, 30 Apr 2008 15:31:33 -0500
Subject: [U-Boot-Users] drivers MMCplus for at91sam9x
In-Reply-To: <001701c8aacd$49ba68b0$dd2f3a10$@savary@kerlink.fr>
Message-ID: <AA28F077645B324881335614E4F7C428034CFA@win-ex01.bench.com>

Pierre Savary wrote:

> Thanks a lot for your patch. I will test it next week.

I found it useful to modify common/cmd_mmc.c drastically
to facilitate easier testing of the AT91SAM9 MCI driver.
It replaces mmcinit with "mmc init" and adds raw read
("mmc read") and write ("mmc write") functions.
To use it, just apply the (ancillary) patch below.

Sincerely,

Ken Fuchs

------

u-boot-at91sam9261-cmd-mmc-for-testing.patch
============================================

svn diff -r21 common/cmd_mmc.c
Index: common/cmd_mmc.c
===================================================================
--- common/cmd_mmc.c	(revision 21)
+++ common/cmd_mmc.c	(working copy)
@@ -1,4 +1,8 @@
 /*
+ * (C) Copyright 2007-2008
+ * Benchmark Electronics, Inc.
+ * Split mmcinit into mmc init, mmc read and mmc write
+ *
  * (C) Copyright 2003
  * Kyle Harris, kharris at nexus-tech.net
  *
@@ -28,19 +32,100 @@
 
 #include <mmc.h>
 
+static unsigned int subcmd;
+static unsigned int bstart;
+static unsigned int noblocks;
+static unsigned int address;
+
 int do_mmc (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
-	if (mmc_init (1) != 0) {
-		printf ("No MMC card found\n");
-		return 1;
+        unsigned int compblocks;
+
+	if ((flag & CMD_FLAG_REPEAT) == 0) {
+	        if (argc >= 2) {
+		        if ((argv[1][0] == 'I' && argv[1][1] == 'N'
+			     && argv[1][2] == 'I' && argv[1][3] == 'T')
||
+			    (argv[1][0] == 'i' && argv[1][1] == 'n'
+			     && argv[1][2] == 'i' && argv[1][3] == 't'))
{
+			        subcmd = 0; /* init */
+			} else if ((argv[1][0] == 'R') ||
+			    (argv[1][0] == 'r')) {
+			        subcmd = 1; /* block read */
+			} else if ((argv[1][0] == 'W') ||
+			    (argv[1][0] == 'w')) {
+			        subcmd = 2; /* block write */
+			} else if ((argv[1][0] == 'M') ||
+			    (argv[1][0] == 'm')) {
+			        subcmd = 3; /* multiple block write */
+			} else {
+			        printf("Subcommand must be ");
+				printf("init, r[ead] or w[rite]\n");
+				return 1;
+			}
+		}
+		if (argc >= 3) {
+			bstart = simple_strtoul(argv[2], NULL, 16);
+		}
+		if (argc >= 4) {
+			noblocks = simple_strtoul(argv[3], NULL, 16);
+		}
+		if (argc >= 5) {
+			address = simple_strtoul(argv[4], NULL, 16);
+		}
 	}
-	return 0;
+	switch (subcmd) {
+	case 0:
+	        if (mmc_init(1) != 0) {
+		        printf ("No MMC card found\n");
+			return 1;
+		}
+		return 0;
+		break;
+	case 1:
+	        compblocks = mmc_bread(0, bstart, noblocks, (ulong
*)address);
+	        if (compblocks < noblocks) {
+		        printf("Error reading block#: 0x%08lx\n",
+			       bstart + compblocks);
+		}
+		break;
+	case 2:
+	        compblocks =
+		        mmc_bwrite(0, bstart, noblocks, (ulong
*)address);
+	        if (compblocks < noblocks) {
+		        printf("Error writing block#: 0x%08lx\n",
+			       bstart + compblocks);
+		}
+		break;
+	case 3:
+	        compblocks =
+		        mmc_mbwrite(0, bstart, noblocks, (ulong
*)address);
+	        if (compblocks < noblocks) {
+		        printf("Error writing block#: 0x%08lx\n",
+			       bstart + compblocks);
+		}
+		break;
+	}
 }
 
 U_BOOT_CMD(
-	mmcinit,	1,	0,	do_mmc,
-	"mmcinit - init mmc card\n",
-	NULL
+	mmc,	5,	1,	do_mmc,
+	"mmc     - init, read & write to the MMC NAND device\n",
+	"\n\nmmc init - initialize the MMC NAND device\n"
+	"\nmmc r <block#> <#blocks> <address> - block read MMC NAND
blocks\n"
+	"        <block#>   - starting block # (hexidecimal) to read\n"
+	"        <#blocks>  - no. of (512) blocks (hexidecimal) to
read\n"
+        "        <address>   - SDRAM/SRAM address (hex.) for read
data\n"
+	"\nmmc w <block#> <#blocks> <address> - block write MMC NAND
blocks\n"
+	"        <block#>   - starting block # (hexidecimal) to write\n"
+	"        <#blocks>  - no. of (512) blocks (hexidecimal) to
write\n"
+        "        <address>   - SDRAM/SRAM address (hex.) of data to
write\n"
+#if     0   /* Not working yet, so documentation is removed. */
+	"\nmmc m <block#> <#blocks> <address> - multiple block write
mode\n"
+	"        <block#>   - starting block # (hexidecimal) to write\n"
+	"        <#blocks>  - no. of (512) blocks (hexidecimal) to
write\n"
+        "        <address>   - SDRAM/SRAM address (hex.) of data to
write\n"
+#endif  /* 0 */
+        "\nA period (.) is displayed after each full MB is read or
written.\n"
 );
 
 #endif	/* CFG_CMD_MMC */



From wd at denx.de  Wed Apr 30 22:34:55 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:34:55 +0200
Subject: [U-Boot-Users] [PATCH] Fix warning in env_nand.c if compiled
	for DaVinci Schmoogie
In-Reply-To: Your message of "Wed, 30 Apr 2008 18:02:59 +0200."
	<1209571379-20209-1-git-send-email-dirk.behme@gmail.com>
Message-ID: <20080430203455.2E98724681@gemini.denx.de>

In message <1209571379-20209-1-git-send-email-dirk.behme at gmail.com> you wrote:
> Fix warnings
> 
> nv_nand.c: In function 'saveenv':
> env_nand.c:200: warning: passing argument 3 of 'nand_write' from incompatible pointer type
> env_nand.c: In function 'env_relocate_spec':
> env_nand.c:275: warning: passing argument 3 of 'nand_read' from incompatible pointer type
> 
> if compiled for davinci_schmoogie_config.
> 
> Signed-off-by: Dirk Behme <dirk.behme at gmail.com>

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: wd at denx.de
A morsel of genuine history is a  thing  so  rare  as  to  be  always
valuable.                                          - Thomas Jefferson



From wd at denx.de  Wed Apr 30 22:36:03 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:36:03 +0200
Subject: [U-Boot-Users] [PATCH] ColdFire: Get information from the
	correct GCC
In-Reply-To: Your message of "Wed, 30 Apr 2008 12:10:23 CDT."
	<1209575423-1244-1-git-send-email-Tsi-Chung.Liew@freescale.com>
Message-ID: <20080430203603.585F024681@gemini.denx.de>

In message <1209575423-1244-1-git-send-email-Tsi-Chung.Liew at freescale.com> you wrote:
> From: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
> 
> Signed-off-by: Kurt Mahan <kmahan at freescale.com>
> Signed-off-by: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
> ---
>  cpu/mcf5227x/config.mk   |    2 +-
>  cpu/mcf523x/config.mk    |    2 +-
>  cpu/mcf52x2/config.mk    |    2 +-
>  cpu/mcf532x/config.mk    |    2 +-
>  cpu/mcf5445x/config.mk   |    2 +-
>  cpu/mcf547x_8x/config.mk |    2 +-
>  6 files changed, 6 insertions(+), 6 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: wd at denx.de
Wenn das dann in die Hose geht, nehme ich es auf meine Kappe.
                                         -- Rudi V?ller, 15. Nov 2003



From wd at denx.de  Wed Apr 30 22:37:50 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:37:50 +0200
Subject: [U-Boot-Users] [PATCH] ColdFire: Fix compilation issue caused
	by new changes in fsl_i2c.c
In-Reply-To: Your message of "Wed, 30 Apr 2008 12:10:47 CDT."
	<1209575447-1266-1-git-send-email-Tsi-Chung.Liew@freescale.com>
Message-ID: <20080430203750.9A23224681@gemini.denx.de>

In message <1209575447-1266-1-git-send-email-Tsi-Chung.Liew at freescale.com> you wrote:
> From: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
> 
> Signed-off-by: Luigi Comio Mantellini <luigi.mantellini at idf-hit.com>
> Signed-off-by: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
> ---
>  include/asm-m68k/global_data.h |    4 ++++
>  1 files changed, 4 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: wd at denx.de
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
                                                      -- Isaac Asimov



From wd at denx.de  Wed Apr 30 22:39:01 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:39:01 +0200
Subject: [U-Boot-Users] [PATCH] ColdFire: Fix ethernet hang issue for
	mcf547x_8x
In-Reply-To: Your message of "Wed, 30 Apr 2008 12:11:19 CDT."
	<1209575479-1286-1-git-send-email-Tsi-Chung.Liew@freescale.com>
Message-ID: <20080430203901.8976F24681@gemini.denx.de>

In message <1209575479-1286-1-git-send-email-Tsi-Chung.Liew at freescale.com> you wrote:
> From: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
> 
> The ethernet hang is caused by receiving buffer in DRAM is not
> yet ready due to access cycles require longer time in DRAM.
> Relocate DMA buffer descriptors from DRAM to internal SRAM.
> 
> Signed-off-by: TsiChung Liew <Tsi-Chung.Liew at freescale.com>
> ---
>  drivers/net/fsl_mcdmafec.c |   22 +++++++++++++++++++++-
>  include/configs/M5475EVB.h |    1 +
>  include/configs/M5485EVB.h |    1 +
>  3 files changed, 23 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: wd at denx.de
A dog always bit deepest on the veterinary hand.
                                    - Terry Pratchett, _Wyrd Sisters_



From plagnioj at jcrosoft.com  Wed Apr 30 22:29:08 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 30 Apr 2008 22:29:08 +0200
Subject: [U-Boot-Users] [PATCH] env_nand: fix incompatible pointer type on
	nand_{read, write}
In-Reply-To: <20080429214926.744C624681@gemini.denx.de>
References: <20080429214926.744C624681@gemini.denx.de>
Message-ID: <1209587348-15402-1-git-send-email-plagnioj@jcrosoft.com>

env_nand.c: In function 'saveenv':
env_nand.c:200: warning: passing argument 3 of 'nand_write' from incompatible pointer type
env_nand.c: In function 'env_relocate_spec':
env_nand.c:275: warning: passing argument 3 of 'nand_read' from incompatible pointer type

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/common/env_nand.c b/common/env_nand.c
index 0dddddf..d8874a6 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -188,7 +188,7 @@ int saveenv(void)
 #else /* ! CFG_ENV_OFFSET_REDUND */
 int saveenv(void)
 {
-	ulong total;
+	size_t total;
 	int ret = 0;
 
 	puts ("Erasing Nand...");
@@ -268,12 +268,12 @@ void env_relocate_spec (void)
 void env_relocate_spec (void)
 {
 #if !defined(ENV_IS_EMBEDDED)
-	ulong total;
+	size_t total;
 	int ret;
 
 	total = CFG_ENV_SIZE;
 	ret = nand_read(&nand_info[0], CFG_ENV_OFFSET, &total, (u_char*)env_ptr);
-  	if (ret || total != CFG_ENV_SIZE)
+	if (ret || total != CFG_ENV_SIZE)
 		return use_default();
 
 	if (crc32(0, env_ptr->data, ENV_SIZE) != env_ptr->crc)
-- 
1.5.4.5




From wd at denx.de  Wed Apr 30 22:43:48 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:43:48 +0200
Subject: [U-Boot-Users] Memory Size issue @ MPC83xx
In-Reply-To: Your message of "Wed, 30 Apr 2008 19:08:05 +0200."
	<4818A775.9020009@matrix-vision.de>
Message-ID: <20080430204348.93ACF24681@gemini.denx.de>

In message <4818A775.9020009 at matrix-vision.de> you wrote:
> 
> my MPC8343 based system is running fine, but I'm not able to use more
> than 256MB of memory.
> 
> Is this a general or known issue ?

You may want to search for CONFIG_VERY_BIG_RAM and
CONFIG_MAX_MEM_MAPPED, see for example "lib_ppc/board.c".


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: wd at denx.de
Do you suppose the reason the ends of the `Intel Inside'  logo  don't
match up is that it was drawn on a Pentium?



From plagnioj at jcrosoft.com  Wed Apr 30 22:38:17 2008
From: plagnioj at jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
Date: Wed, 30 Apr 2008 22:38:17 +0200
Subject: [U-Boot-Users] [PATCH] cmd_nand: fix warning: str2long ncompatible
	pointer type
In-Reply-To: <1209587348-15402-1-git-send-email-plagnioj@jcrosoft.com>
References: <1209587348-15402-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <1209587897-25440-1-git-send-email-plagnioj@jcrosoft.com>

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 1a3c1df..37eb41b 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -110,7 +110,7 @@ arg_off_size(int argc, char *argv[], nand_info_t *nand, ulong *off, size_t *size
 			}
 			*off = part->offset;
 			if (argc >= 2) {
-				if (!(str2long(argv[1], size))) {
+				if (!(str2long(argv[1], (ulong *)size))) {
 					printf("'%s' is not a number\n", argv[1]);
 					return -1;
 				}
-- 
1.5.4.5




From wd at denx.de  Wed Apr 30 22:52:52 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:52:52 +0200
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some
	86xx chips
In-Reply-To: Your message of "Fri, 04 Apr 2008 11:16:11 CDT."
	<1207325771-1374-1-git-send-email-timur@freescale.com>
Message-ID: <20080430205252.5998424681@gemini.denx.de>

In message <1207325771-1374-1-git-send-email-timur at freescale.com> you wrote:
> Some 86xx chips use CCB as the base clock for the I2C, and others used CCB/2.
> There is no pattern that can be used to determine which chips use which
> frequency, so the only way to determine is to look up the actual SOC
> designation and use the right value for that SOC.
> 
> Signed-off-by: Timur Tabi <timur at freescale.com>
> ---
> 
> Yes, this is ugly and stupid, but the only alternative is to update each
> board configuration file with another CONFIG_ option.  And yes, this does
> mean that as new 86xx variants are announced, cpu/mpc86xx/speed.c may need
> to be updated.
> 
>  cpu/mpc86xx/speed.c |   14 +++++++++++++-
>  1 files changed, 13 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: wd at denx.de
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.



From wd at denx.de  Wed Apr 30 22:53:36 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:53:36 +0200
Subject: [U-Boot-Users] [PATCH] Fix calculation of I2C clock for some
	86xx chips
In-Reply-To: Your message of "Wed, 30 Apr 2008 14:54:16 CDT."
	<4818CE68.3040901@freescale.com>
Message-ID: <20080430205336.83FBB24681@gemini.denx.de>

In message <4818CE68.3040901 at freescale.com> you wrote:
> Wolfgang, I think you forgot this one.

Indeed. I missed that there were actually two very similar messages.

Thanks for pointing out.

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: wd at denx.de
"Don't think; let the machine do it for you!"        - E. C. Berkeley



From r.schwebel at pengutronix.de  Wed Apr 30 22:55:15 2008
From: r.schwebel at pengutronix.de (Robert Schwebel)
Date: Wed, 30 Apr 2008 22:55:15 +0200
Subject: [U-Boot-Users] Problems with 1.3.3-rc1 on i.MX31ADS
In-Reply-To: <1209538321.11420.2.camel@felix.lan>
References: <1209243964.4426.19.camel@felix.lan>
	<20080429205554.GE13814@pengutronix.de>
	<1209538321.11420.2.camel@felix.lan>
Message-ID: <20080430205515.GL13814@pengutronix.de>

On Wed, Apr 30, 2008 at 09:52:01AM +0300, Felix Radensky wrote:
> Thanks for the info. What are the plans u-boot-v2?

World domination, as usual :)

> Is going to become u-boot mainline in the near future?

Nope. It is a technology project which follows a "u-boot, done right"
concept. So over the time, things may inspire each other, but there is
no direct link. v2 tries to combine the good user experience from
u-boot-v1 with a sane internal software design.

> How difficult do you think would be to port i.mx27 code to u-boot 1.3.

Oh, that's not sooo bad. It's just that if there is already a v2 port,
why would you want to do that?

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9




From wd at denx.de  Wed Apr 30 22:56:56 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:56:56 +0200
Subject: [U-Boot-Users] [PATCH] env_nand: fix incompatible pointer type
	on nand_{read, write}
In-Reply-To: Your message of "Wed, 30 Apr 2008 22:29:08 +0200."
	<1209587348-15402-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080430205656.06FC224681@gemini.denx.de>

In message <1209587348-15402-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> env_nand.c: In function 'saveenv':
> env_nand.c:200: warning: passing argument 3 of 'nand_write' from incompatible pointer type
> env_nand.c: In function 'env_relocate_spec':
> env_nand.c:275: warning: passing argument 3 of 'nand_read' from incompatible pointer type
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>

That was already fixed before.

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: wd at denx.de
CAUTION:  The Mass of This Product Contains the Energy Equivalent  of
85 Million Tons of TNT per Net Ounce of Weight.



From wd at denx.de  Wed Apr 30 22:59:03 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 22:59:03 +0200
Subject: [U-Boot-Users] [PATCH] cmd_nand: fix warning: str2long
	ncompatible pointer type
In-Reply-To: Your message of "Wed, 30 Apr 2008 22:38:17 +0200."
	<1209587897-25440-1-git-send-email-plagnioj@jcrosoft.com>
Message-ID: <20080430205903.8197A24681@gemini.denx.de>

In message <1209587897-25440-1-git-send-email-plagnioj at jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
> 
> diff --git a/common/cmd_nand.c b/common/cmd_nand.c

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: wd at denx.de
There are bugs and then there are bugs.  And then there are bugs.
                                                    - Karl Lehenbauer



From biggerbadderben at gmail.com  Wed Apr 30 23:26:31 2008
From: biggerbadderben at gmail.com (Ben Warren)
Date: Wed, 30 Apr 2008 14:26:31 -0700
Subject: [U-Boot-Users] [PATCH v2] smc911x: add 16 bit support
In-Reply-To: <20080430123139.27253.49891.stgit@tq-sewsrv-4.tq-net.de>
References: <20080430123139.27253.49891.stgit@tq-sewsrv-4.tq-net.de>
Message-ID: <f8328f7c0804301426q1b3a0f54ief2c78722ce1419@mail.gmail.com>

Hi Jens,

On Wed, Apr 30, 2008 at 5:34 AM, Jens Gehrlein <sew_s at tqs.de> wrote:
> Incorporated Ben's, Magnus's and Guennadi's proposals.
>  Thank you for reviewing.
>

Almost there.  This comment needs to go below the '---' line so that
it doesn't become part of the commit message.  Also, please add a
meaningful comment here (above your SOB line).  The patch title
contains all the useful information, so you may want to just copy it,
but there needs to be something.
>  Signed-off-by: Jens Gehrlein <sew_s at tqs.de>
>  ---
>
>   drivers/net/smc911x.c |   19 +++++++++++++++++--
>   1 files changed, 17 insertions(+), 2 deletions(-)
>
>
>  diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
>  index d22c889..bd82cf7 100644
>  --- a/drivers/net/smc911x.c
>  +++ b/drivers/net/smc911x.c
>  @@ -30,6 +30,10 @@
>   #include <net.h>
>   #include <miiphy.h>
>
>  +#if defined (CONFIG_DRIVER_SMC911X_32_BIT) && defined (CONFIG_DRIVER_SMC911X_16_BIT)
>  +#error "SMC911X: Only one of CONFIG_DRIVER_SMC911X_32_BIT and CONFIG_DRIVER_SMC911X_16_BIT shall be set"

Both of these lines are too long.  I suggest:

+#if defined (CONFIG_DRIVER_SMC911X_32_BIT) && \
+        defined (CONFIG_DRIVER_SMC911X_16_BIT)
+#error "SMC911X: Only one of CONFIG_DRIVER_SMC911X_32_BIT and \
+        CONFIG_DRIVER_SMC911X_16_BIT shall be set"

NOTE: I wrote this in gmail's web interface, so don't cut & paste - do it right!

>  +#endif
>  +
>   #ifdef CONFIG_DRIVER_SMC911X_32_BIT
>   static inline u32 reg_read(u32 addr)
>   {
>  @@ -39,9 +43,20 @@ static inline void reg_write(u32 addr, u32 val)
>   {
>         *(volatile u32*)addr = val;
>   }
>  +#elif CONFIG_DRIVER_SMC911X_16_BIT
>  +static inline u32 reg_read(u32 addr)
>  +{
>  +       volatile u16 *addr_16 = (u16 *)addr;
>  +       return ((*addr_16 & 0x0000ffff) | (*(addr_16 + 1) << 16));
>  +}
>  +static inline void reg_write(u32 addr, u32 val)
>  +{
>  +       *(volatile u16*)addr = (u16)val;
>  +       *(volatile u16*)(addr + 2) = (u16)(val >> 16);
>  +}
>   #else
>  -#error "SMC911X: Only 32-bit bus is supported"
>  -#endif
>  +#error "SMC911X: undefined buswidth"
s/buswidth/bus\ width/
>  +#endif /* CONFIG_DRIVER_SMC911X_16_BIT */
>
>   #define mdelay(n)       udelay((n)*1000)
>

Also, would you mind putting an entry into the README file for this
driver?  There's already one there for the SMC91111 driver, so this
should be really fast.

Thanks for your help!

regards,
Ben



From galak at kernel.crashing.org  Wed Apr 30 23:24:35 2008
From: galak at kernel.crashing.org (Kumar Gala)
Date: Wed, 30 Apr 2008 16:24:35 -0500 (CDT)
Subject: [U-Boot-Users] [PATCH] MPC8610HPCD: Drop -O2 from the build flags
Message-ID: <Pine.LNX.4.64.0804301624140.10418@blarg.am.freescale.net>

Make the flags use -Os like all other boards

Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
 board/freescale/mpc8610hpcd/config.mk |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/board/freescale/mpc8610hpcd/config.mk b/board/freescale/mpc8610hpcd/config.mk
index 64ac4dc..99e7bd4 100644
--- a/board/freescale/mpc8610hpcd/config.mk
+++ b/board/freescale/mpc8610hpcd/config.mk
@@ -22,4 +22,4 @@
 TEXT_BASE = 0xfff00000

 PLATFORM_CPPFLAGS += -DCONFIG_MPC86xx=1
-PLATFORM_CPPFLAGS += -DCONFIG_MPC8610=1 -maltivec -mabi=altivec -msoft-float -O2
+PLATFORM_CPPFLAGS += -DCONFIG_MPC8610=1 -maltivec -mabi=altivec -msoft-float
-- 
1.5.4.1




From wd at denx.de  Wed Apr 30 23:31:54 2008
From: wd at denx.de (Wolfgang Denk)
Date: Wed, 30 Apr 2008 23:31:54 +0200
Subject: [U-Boot-Users] [PATCH v2] smc911x: add 16 bit support
In-Reply-To: Your message of "Wed, 30 Apr 2008 14:26:31 PDT."
	<f8328f7c0804301426q1b3a0f54ief2c78722ce1419@mail.gmail.com>
Message-ID: <20080430213154.947AF24681@gemini.denx.de>

In message <f8328f7c0804301426q1b3a0f54ief2c78722ce1419 at mail.gmail.com> you wrote:
>
> Almost there.  This comment needs to go below the '---' line so that
> it doesn't become part of the commit message.  Also, please add a

That's correct.

> meaningful comment here (above your SOB line).  The patch title
> contains all the useful information, so you may want to just copy it,
> but there needs to be something.

No, please don't, or the line will end up twice in the commit message.

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: wd at denx.de
Quote from the Boss... "I didn't say it was your fault.  I said I was
going to blame it on you."