[U-Boot] [PATCH] kirkwood_nand: allow usage of NAND_ECC_SOFT_BCH

2013-01-16 Thread Holger Brunck
From: Gerlando Falauto gerlando.fala...@keymile.com

If CONFIG_NAND_ECC_BCH is set use 4-bit error correction code instead of
the 1-bit error correction code on the NAND device.

Signed-off-by: Gerlando Falauto gerlando.fala...@keymile.com
Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Valentin Longchamp valentin.longch...@keymile.com
cc: Prafulla Wadaskar prafu...@marvell.com
---
 drivers/mtd/nand/kirkwood_nand.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/kirkwood_nand.c b/drivers/mtd/nand/kirkwood_nand.c
index bdab5aa..0a99a10 100644
--- a/drivers/mtd/nand/kirkwood_nand.c
+++ b/drivers/mtd/nand/kirkwood_nand.c
@@ -74,7 +74,11 @@ void kw_nand_select_chip(struct mtd_info *mtd, int chip)
 int board_nand_init(struct nand_chip *nand)
 {
nand-options = NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING;
+#if defined(CONFIG_NAND_ECC_BCH)
+   nand-ecc.mode = NAND_ECC_SOFT_BCH;
+#else
nand-ecc.mode = NAND_ECC_SOFT;
+#endif
nand-cmd_ctrl = kw_nand_hwcontrol;
nand-chip_delay = 40;
nand-select_chip = kw_nand_select_chip;
-- 
1.7.1

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


[U-Boot] [PATCH 2/3] arm/km: use CONFIG_NAND_ECC_BCH

2013-01-16 Thread Holger Brunck
Switch from 1-bit ecc to 4-bit ecc.

Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Valentin Longchamp valentin.longch...@keymile.com
cc: Prafulla Wadaskar prafu...@marvell.com
---
 include/configs/km/km_arm.h |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index cbf7bc3..766d76e 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -50,6 +50,9 @@
 
 #define CONFIG_MACH_TYPE   MACH_TYPE_KM_KIRKWOOD
 
+#define CONFIG_NAND_ECC_BCH
+#define CONFIG_BCH
+
 /* include common defines/options for all Keymile boards */
 #include keymile-common.h
 
-- 
1.7.1

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


[U-Boot] [PATCH 3/3] arm/km: add support for kmsuv31 board

2013-01-16 Thread Holger Brunck
This board is from a u-boot point of view a mixture between kmnusa and
a standard km_kirkwood board. We have our u-boot environment in the spi
NOR flash, but we have a direct connection between the kirkwood and the
piggy. A FPGA is connected via the PCIe interface. So we only have to
select the specific features in the board setup.

Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Valentin Longchamp valentin.longch...@keymile.com
cc: Prafulla Wadaskar prafu...@marvell.com
---
 boards.cfg|1 +
 include/configs/km_kirkwood.h |8 
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index e4b0d44..19c36a3 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -162,6 +162,7 @@ lsxhlarm arm926ejs   lsxl   
 buffalo
 km_kirkwood  arm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_KIRKWOOD
 km_kirkwood_pci  arm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_KIRKWOOD_PCI
 kmnusa   arm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_NUSA
+kmsuv31  arm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_SUV31
 mgcoge3unarm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_MGCOGE3UN
 kmcoge5unarm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_COGE5UN
 portl2   arm arm926ejs   km_arm  
keymilekirkwoodkm_kirkwood:KM_PORTL2
diff --git a/include/configs/km_kirkwood.h b/include/configs/km_kirkwood.h
index 762cc10..83bb7aa 100644
--- a/include/configs/km_kirkwood.h
+++ b/include/configs/km_kirkwood.h
@@ -98,6 +98,14 @@
 #define KM_IVM_BUS pca9544a:70:9 /* I2C2 (Mux-Port 1)*/
 #define CONFIG_KM_PIGGY4_88E6061
 
+/* KM_SUV31 */
+#elif defined(CONFIG_KM_SUV31)
+#define KM_IVM_BUS pca9547:70:9  /* I2C2 (Mux-Port 1)*/
+#define CONFIG_IDENT_STRING\nKeymile SUV31
+#define CONFIG_HOSTNAMEkmsuv31
+#define CONFIG_KM_ENV_IS_IN_SPI_NOR
+#define CONFIG_KM_FPGA_CONFIG
+
 #else
 #error (Board unsupported)
 #endif
-- 
1.7.1

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


[U-Boot] [PATCH 1/3] arm/km: rename BOARD_LATE_INIT to CONFIG_BOARD_LATE_INIT

2013-01-16 Thread Holger Brunck
commit 9660e442 cosmetic: s/BOARD_LATE_INIT/CONFIG_BOARD_LATE_INIT
removes BOARD_LATE_INIT and uses CONFIG_BOARD_LATE_INIT instead.
Therefore we have to use this define.

Signed-off-by: Holger Brunck holger.bru...@keymile.com
cc: Valentin Longchamp valentin.longch...@keymile.com
cc: Prafulla Wadaskar prafu...@marvell.com
---
 include/configs/km/km_arm.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index 549278d..cbf7bc3 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -320,6 +320,6 @@ int get_scl(void);
 #define CONFIG_CMD_DIAG
 
 /* we do the whole PCIe FPGA config stuff here */
-#defineBOARD_LATE_INIT
+#defineCONFIG_BOARD_LATE_INIT
 
 #endif /* _CONFIG_KM_ARM_H */
-- 
1.7.1

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


[U-Boot] [RFC PATCH 1/2] Initial net6.h

2013-01-16 Thread Chris Packham
From: Chris Packham chris.pack...@alliedtelesis.co.nz

Has the definition of an IPv6 address and IPv6 header. It may make sense
to separate the v4 support from net.h (or to include this in net.h).

Cc: Joe Hershberger joe.hershber...@gmail.com
Signed-off-by: Chris Packham chris.pack...@alliedtelesis.co.nz
---
 include/net6.h | 43 +++
 1 file changed, 43 insertions(+)
 create mode 100644 include/net6.h

diff --git a/include/net6.h b/include/net6.h
new file mode 100644
index 000..2ef7405
--- /dev/null
+++ b/include/net6.h
@@ -0,0 +1,43 @@
+/**
+ * Simple IPv6 network layer implementation.
+ *
+ * Based and/or adapted from the IPv4 network layer in net.[hc]
+ *
+ * (C) Copyright 2013 Allied Telesis Labs NZ
+ *
+ * This file is released under the terms of GPL v2 and any later version.
+ * See the file COPYING in the root directory of the source tree for details.
+ */
+
+typedef union ip6addr_t {
+   __u8u6_addr8[16];
+   __u16   u6_addr16[8];
+   __u32   u6_addr32[4];
+} IP6addr_t;
+
+/**
+ * struct ipv6hdr - Internet Protocol V6 (IPv6) header.
+ *
+ * IPv6 packet header as defined in RFC .
+ *
+ * BEWARE, it is incorrect. The first 4 bits of flow_lbl
+ * are glued to priority now, forming class.
+ */
+struct ip6_hdr {
+#if defined(__LITTLE_ENDIAN_BITFIELD)
+   __u8priority:4,
+   version:4;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+   __u8version:4,
+   priority:4;
+#else
+#error  Please fix asm/byteorder.h
+#endif
+   __u8flow_lbl[3];
+   __u16   payload_len;
+   __u8nexthdr;
+   __u8hop_limit;
+   IP6addr_t   saddr;
+   IP6addr_t   daddr;
+};
+
-- 
1.7.12.rc2.16.g034161a


#
Scanned by MailMarshal - M86 Security's comprehensive email content security 
solution. 
#
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [RFC PATCH 0/2] Initial IPv6 support

2013-01-16 Thread Chris Packham
Here's something simple to get started. IP6addr_t is added as a typedef
(for consistency with IPaddr_t). I ended up borrowing and adapting the
vsprintf code from Linux.

Here is an example of the printf formatting

With this code

  IP6addr_t addr6 = {.u6_addr16[0] = 0x3ffe,
 .u6_addr16[1] = 0x1234,
 .u6_addr16[7] = 0x0001};
  IPaddr_t addr4 = 0x7f01;

  printf(addr6=%pi6\n, addr6);
  printf(addr6=%pI6\n, addr6);
  printf(addr6=%pI6c\n, addr6);
  printf(addr=%pI4\n, addr4);

We get the output

  addr6=3ffe12340001
  addr6=3ffe:1234::::::0001
  addr6=3ffe:1234::1
  addr4=127.0.0.1

My work so far on this has raised a few questions:

1) Presumably the majority of the actual V6 code would be included by a
config option (CONFIG_IPV6). How far should I take that? Should the
vsprintf code be conditional?

2) Our current out of tree code parallels net.c and net.h. Should I
continue this for the final version or integrate it into net.[ch]. 

3) rxhand_f currently takes an IPaddr_t. I haven't looked at the usage
of this yet but to support V6 this may need to be a new union or a void
*.

(note on my split personality, I use a gmail account to post to the
u-boot mailing list but since this work is being done as part of my
$dayjob the author and s-o-b are using my work email address)


#
Scanned by MailMarshal - M86 Security's comprehensive email content security 
solution. 
#
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [RFC PATCH 2/2] lib/vsprintf.c: add IPv6 compressed format %pI6c

2013-01-16 Thread Chris Packham
From: Chris Packham chris.pack...@alliedtelesis.co.nz

Add support for human friendly IPv6 address representations as
specified in
http://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-00

This code has been adapted from Linux kernel with minimal modification.

Cc: Joe Hershberger joe.hershber...@gmail.com
Signed-off-by: Chris Packham chris.pack...@alliedtelesis.co.nz
---
 lib/vsprintf.c | 148 +
 1 file changed, 128 insertions(+), 20 deletions(-)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 3c432f8..ae992dc 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -23,6 +23,7 @@
 #endif
 
 #include div64.h
+#include net6.h
 #define noinline __attribute__((noinline))
 
 /* some reluctance to put this into a new limits.h, so it is here */
@@ -276,6 +277,7 @@ static noinline char *put_dec(char *buf, u64 num)
 #define LEFT   16  /* left justified */
 #define SMALL  32  /* Must be 32 == 0x20 */
 #define SPECIAL64  /* 0x */
+#define COMPRESSED 128 /* use compressed format */
 
 #ifdef CONFIG_SYS_VSNPRINTF
 /*
@@ -430,12 +432,112 @@ static char *mac_address_string(char *buf, char *end, u8 
*addr, int field_width,
  flags  ~SPECIAL);
 }
 
-static char *ip6_addr_string(char *buf, char *end, u8 *addr, int field_width,
-int precision, int flags)
+static char *ip4_string(char *p, u8 *addr)
+{
+   char temp[3];   /* hold each IP quad in reverse order */
+   int i, digits;
+
+   for (i = 0; i  4; i++) {
+   digits = put_dec_trunc(temp, addr[i]) - temp;
+   /* reverse the digits in the quad */
+   while (digits--)
+   *p++ = temp[digits];
+   if (i != 3)
+   *p++ = '.';
+   }
+   *p = '\0';
+
+   return p;
+}
+
+static char *ip6_compressed_string(char *p, u8 *addr)
+{
+   int i, j, range;
+   unsigned char zerolength[8];
+   int longest = 1;
+   int colonpos = -1;
+   u16 word;
+   u8 hi, lo;
+   int needcolon = 0;
+   int useIPv4;
+   IP6addr_t in6;
+
+   memcpy(in6, addr, sizeof(IP6addr_t));
+
+/* TODO: v4 mapped detection. Might be overkill for a bootloader */
+#if 0
+   useIPv4 = ipv6_addr_v4mapped(in6) || ipv6_addr_is_isatap(in6);
+#else
+   useIPv4 = 0;
+#endif
+
+   memset(zerolength, 0, sizeof(zerolength));
+
+   if (useIPv4)
+   range = 6;
+   else
+   range = 8;
+
+   /* find position of longest 0 run */
+   for (i = 0; i  range; i++) {
+   for (j = i; j  range; j++) {
+   if (in6.u6_addr16[j] != 0)
+   break;
+   zerolength[i]++;
+   }
+   }
+   for (i = 0; i  range; i++) {
+   if (zerolength[i]  longest) {
+   longest = zerolength[i];
+   colonpos = i;
+   }
+   }
+   if (longest == 1)   /* don't compress a single 0 */
+   colonpos = -1;
+
+   /* emit address */
+   for (i = 0; i  range; i++) {
+   if (i == colonpos) {
+   if (needcolon || i == 0)
+   *p++ = ':';
+   *p++ = ':';
+   needcolon = 0;
+   i += longest - 1;
+   continue;
+   }
+   if (needcolon) {
+   *p++ = ':';
+   needcolon = 0;
+   }
+   /* hex u16 without leading 0s */
+   word = ntohs(in6.u6_addr16[i]);
+   hi = word  8;
+   lo = word  0xff;
+   if (hi) {
+   if (hi  0x0f)
+   p = pack_hex_byte(p, hi);
+   else
+   *p++ = hex_asc_lo(hi);
+   p = pack_hex_byte(p, lo);
+   } else if (lo  0x0f)
+   p = pack_hex_byte(p, lo);
+   else
+   *p++ = hex_asc_lo(lo);
+   needcolon = 1;
+   }
+
+   if (useIPv4) {
+   if (needcolon)
+   *p++ = ':';
+   p = ip4_string(p, in6.u6_addr8[12]);
+   }
+   *p = '\0';
+
+   return p;
+}
+
+static char *ip6_string(char *p, u8 *addr, int flags)
 {
-   /* (8 * 4 hex digits), 7 colons and trailing zero */
-   char ip6_addr[8 * 5];
-   char *p = ip6_addr;
int i;
 
for (i = 0; i  8; i++) {
@@ -446,6 +548,19 @@ static char *ip6_addr_string(char *buf, char *end, u8 
*addr, int field_width,
}
*p = '\0';
 
+   return p;
+}
+
+static char *ip6_addr_string(char *buf, char *end, u8 *addr, int field_width,
+int precision, int flags)
+{
+   char 

[U-Boot] [GIT PULL] u-boot-mips/master

2013-01-16 Thread Daniel Schwierzeck
Hi Tom,

The following changes since commit 3a9d879f6f64585b819af728b53be0a05037fe0d:

  Prepare v2013.01 (2013-01-15 14:47:42 -0700)

are available in the git repository at:

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

for you to fetch changes up to 54b08efcf2f4ff532ce99c53f341a59c193331a5:

  README.mips: update known issues and TODOs (2013-01-16 10:52:08 +0100)


Daniel Schwierzeck (3):
  MIPS: qemu-mips: update and fix example usage in README
  README.qemu-mips: move README file from board to doc directory
  README.mips: update known issues and TODOs

Gabor Juhos (6):
  MIPS: bootm.c: use debug macro to print debug message
  MIPS: bootm.c: separate linux jump code
  MIPS: bootm.c: separate environment initialization
  MIPS: bootm.c: add support for 'prep' and 'go' subcommands
  MIPS: qemu-mips: fix a typo in README
  MIPS: qemu-mips: add '-M mips' switch to the example usage command

 arch/mips/lib/bootm.c  | 51
+++
 doc/README.mips| 11 ++-
 board/qemu-mips/README = doc/README.qemu-mips | 30
++
 3 files changed, 63 insertions(+), 29 deletions(-)
 rename board/qemu-mips/README = doc/README.qemu-mips (88%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATH v3 1/2] sf: Add status register reading support

2013-01-16 Thread Jagan Teki
Hi Simon,

On Fri, Jan 11, 2013 at 9:29 PM, Simon Glass s...@chromium.org wrote:
 Hi Jagan,

 On Fri, Jan 11, 2013 at 7:51 AM, Jagan Teki jagannadh.t...@gmail.com wrote:
 Hi Simon,

 On Fri, Jan 11, 2013 at 7:52 AM, Simon Glass s...@chromium.org wrote:
 Hi Jagannadha

 On Thu, Jan 3, 2013 at 6:51 AM, Jagannadha Sutradharudu Teki
 jagannadh.t...@gmail.com wrote:
 This patch provides support to read a flash status register.

 Status register contains a control bits used to verify
 the progress of flash program and erase operations.

 User need to get the data through spi_flash_cmd_read_status()
 based on their usage.

 Do you have a console command for this, and the control register also?

 There is no sf command for status register read.

 Usage is based on the user code, see how I am using this function on
 Quad Enable bit setting.
 http://patchwork.ozlabs.org/patch/207454/

 Please tell me if you still unclear.

 Yes, but do you think such a command might be useful? Or is it better
 to have commands for each individual feature? I am thinking of locking
 of part of the flash and anything else that the status register
 provides

I don't think so.

The status and config registers read and write functionalities are
used based on the usage level
in flash programming (flash reads/writes). so these special features
are valid in those cases.

User can use these features by calling a respective register function
calls with respective their need.

Thanks,
Jagan.


 Regards,
 Simon


 Thanks,
 Jagan.


 Regards,
 Simon


 Signed-off-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
 ---
 Changes in v3:
 improved coding style

  drivers/mtd/spi/spi_flash.c  |8 
  drivers/mtd/spi/spi_flash_internal.h |3 +++
  2 files changed, 11 insertions(+), 0 deletions(-)

 diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
 index 9e8939c..0f05b91 100644
 --- a/drivers/mtd/spi/spi_flash.c
 +++ b/drivers/mtd/spi/spi_flash.c
 @@ -264,6 +264,14 @@ int spi_flash_cmd_write_status(struct spi_flash 
 *flash, u8 sr)
 return 0;
  }

 +int spi_flash_cmd_read_status(struct spi_flash *flash, void *data)
 +{
 +   u8 cmd;
 +
 +   cmd = CMD_READ_STATUS;
 +   return spi_flash_read_common(flash, cmd, sizeof(cmd), (void 
 *)data, 1);
 +}
 +
  /*
   * The following table holds all device probe functions
   *
 diff --git a/drivers/mtd/spi/spi_flash_internal.h 
 b/drivers/mtd/spi/spi_flash_internal.h
 index 141cfa8..8232595 100644
 --- a/drivers/mtd/spi/spi_flash_internal.h
 +++ b/drivers/mtd/spi/spi_flash_internal.h
 @@ -77,6 +77,9 @@ static inline int spi_flash_cmd_write_disable(struct 
 spi_flash *flash)
  /* Program the status register. */
  int spi_flash_cmd_write_status(struct spi_flash *flash, u8 sr);

 +/* Read the status register */
 +int spi_flash_cmd_read_status(struct spi_flash *flash, void *data);
 +
  /*
   * Same as spi_flash_cmd_read() except it also claims/releases the SPI
   * bus. Used as common part of the -read() operation.
 --
 1.7.0.4

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


Re: [U-Boot] [RFC PATCH 0/2] Initial IPv6 support

2013-01-16 Thread Chris Packham
On 01/16/2013 11:01 PM, Chris Packham wrote:

snip

 #
 Scanned by MailMarshal - M86 Security's comprehensive email content security 
 solution. 
 #

Ick. Where did that come from?

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


Re: [U-Boot] Flash Not Erased Problem with M29W128GL

2013-01-16 Thread Angelo Dureghello
Dear Ramesh,

i am running last u-boot (pulled yesterday) on a coldfire m5307
and a SST 16bit flash, erasing works fine.

From your debug trace seems the correct erasing command (0x30) is
sent.

But the function you mentioned detect that flash is not erased.

Are you using a 16bit port for data connection to the flash ?

First check i would do is an erase test.
 
Try to erase some sectors with erase command, something like

# erase 4 4

Then dump the memory, (to be sure also with BDM eventually), to see
if it has really been erased.


Also, these are some settings i am using in my config, maybe they can 
be useful:

/*
 * Start addresses for the final memory configuration
 * (Set up by the startup code)
 * Please note that CONFIG_SYS_SDRAM_BASE _must_ start at 0
 */
#define CONFIG_SYS_SDRAM_BASE   0x
#define CONFIG_SYS_SDRAM_SIZE   16  /* in MB */
#define CONFIG_SYS_FLASH_BASE   0xffc0
#define CONFIG_SYS_TEXT_BASE0xffc0
#define CONFIG_SYS_MAX_FLASH_BANKS  1
#define CONFIG_SYS_MAX_FLASH_SECT   1024
#define CONFIG_SYS_FLASH_ERASE_TOUT 1000


/*
 * CFI FLASH driver setup
 */
#define CONFIG_SYS_FLASH_CFI
#define CONFIG_FLASH_CFI_DRIVER
#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE

...


Let us know if you find something.

Regards,
Angelo

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


Re: [U-Boot] Function prototype conflicts with standalone apps

2013-01-16 Thread Chris Packham
Hi Albert,

On 01/16/2013 08:25 PM, Albert ARIBAUD (U-Boot) wrote:
 Hi Chris,
 
 On Wed, 16 Jan 2013 17:23:58 +1300, Chris Packham
 judge.pack...@gmail.com wrote:
 
 Hi,

 I've just run into something porting an existing out of tree board to
 u-boot 2012.10 but I think it points to a generic issue for standalone
 applications.

 Consider the following change

 diff --git a/examples/standalone/hello_world.c
 b/examples/standalone/hello_world.c
 index 067c390..d2e6a77 100644
 --- a/examples/standalone/hello_world.c
 +++ b/examples/standalone/hello_world.c
 @@ -24,7 +24,7 @@
  #include common.h
  #include exports.h

 -int hello_world (int argc, char * const argv[])
 +int net_init (int argc, char * const argv[])
  {
 int i;

 Because I'm not linking with the u-boot object file, I should be able to
 use any function name I like in my application as long as it isn't one of
 the functions in exports.h (at least in theory). Unfortunately I end up
 with the following compiler error

   hello_world.c:27: error: conflicting types for ‘net_init’
   uboot/include/net.h:489: error: previous declaration of ‘net_init’ was
 here
   make[1]: *** [hello_world.o] Error 1

 If I replace #include common.h in my app with the first hunk of includes
 from the top of common.h  then I can compile just fine.

 I was wondering if it made sense to people to have standalone applications
 define something like __STANDALONE__ either via CPPFLAGS or in the source
 itself and use the presence of that to exclude the majority of common.h
 when used in standalone applications. Or alternatively move the required
 bits to exports.h.
 
 (long rant ahead. Short answer after end of rant)

Short response: Yep I can live with that by making some changes to my
standalone application. I just thought it might be cleaner if a minimal
set of definitions were provided.

 [RANT]
 
 Code writers indeed have a right to name any function or other object
 any way they choose... within the constraints of the situation.
 
 Some of these constraints stem from the tools -- you just cannot put an
 ampersand in a C object name, for instance -- and some stem from the
 'agreement' entered into when using a library -- precisely, the
 agreement on the name and semantics of such and such object names.
 
 Here, by including exports.h, you enter an agreement in which
 the object name 'net_init' receives a specific meaning. What you want
 is to benefit from the agreement without abiding by it.
 
 Now this can be changed, technically, as most things are, and a new
 kind of agreement could be devised with fine-grain control on which
 object names would or would not be defined. The question is, *should*
 this be done?
 
 Would you, analogously, suggest that Linux app developers be able to
 opt out of defining fopen() when they #include stdio.h because they
 feel they have a right to define 'char* fopen(float F)' in their code if
 they so please? And that it should be done so for just about any
 kernel-exported symbol? I suspect not.

Actually this is my point. The symbols aren't exported. They're just in
the header file. The kernel solution for this is using __KERNEL__ and
filtering the exported headers to remove the kernel internals not needed
by userland. If for some reason I did define a different fopen I'd get a
link error whether I included stdio or not.

 So why ask this from U-Boot?
 
 [/RANT]
 
 I personally will NAK such a suggestion. I don't see the point in
 adding complexity just to solve a naming conflict between a framework,
 de facto standard, name and a freely-modifiable application name. Just
 rename the application function -- that'll be all the better since that
 will also remove potential misunderstanding for readers of your code.
 
 Thanks,
 Chris
 
 Amicalement,
 

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


[U-Boot] [PATCH] Remove unused CONFIG_SYS_I2C_BUS[_SELECT]

2013-01-16 Thread Michael Jones
CONFIG_SYS_I2C_BUS and CONFIG_SYS_I2C_BUS_SELECT don't appear anywhere
outside of config files.

Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
As far as I can tell, these CONFIG options never have existed outside of these
config files - looking at omap3_beagle.h as an example, these lines were
inserted with the creation of that file, and at that point in time there was
also no occurence of them elsewhere. Can't we get rid of them?

 include/configs/am3517_crane.h |2 --
 include/configs/am3517_evm.h   |2 --
 include/configs/cm_t35.h   |2 --
 include/configs/devkit8000.h   |2 --
 include/configs/dig297.h   |2 --
 include/configs/igep00x0.h |2 --
 include/configs/mcx.h  |1 -
 include/configs/omap3_beagle.h |2 --
 include/configs/omap3_evm_common.h |2 --
 include/configs/omap3_logic.h  |2 --
 include/configs/omap3_mvblx.h  |2 --
 include/configs/omap3_pandora.h|2 --
 include/configs/omap3_sdp3430.h|2 --
 include/configs/omap3_zoom1.h  |2 --
 include/configs/omap3_zoom2.h  |2 --
 include/configs/omap4_common.h |2 --
 include/configs/tam3517-common.h   |2 --
 include/configs/tricorder.h|2 --
 18 files changed, 0 insertions(+), 35 deletions(-)

diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index e1ad1e5..bf9d63e 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -156,8 +156,6 @@
 #define CONFIG_HARD_I2C1
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_I2C_SLAVE   1
-#define CONFIG_SYS_I2C_BUS 0
-#define CONFIG_SYS_I2C_BUS_SELECT  1
 #define CONFIG_DRIVER_OMAP34XX_I2C 1
 
 #undef CONFIG_CMD_NET
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index ba15325..17fe88d 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -150,8 +150,6 @@
 #define CONFIG_HARD_I2C1
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_I2C_SLAVE   1
-#define CONFIG_SYS_I2C_BUS 0
-#define CONFIG_SYS_I2C_BUS_SELECT  1
 #define CONFIG_DRIVER_OMAP34XX_I2C 1
 
 #undef CONFIG_CMD_NET
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 7d07215..943b658 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -157,8 +157,6 @@
 #define CONFIG_HARD_I2C
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_I2C_SLAVE   1
-#define CONFIG_SYS_I2C_BUS 0
-#define CONFIG_SYS_I2C_BUS_SELECT  1
 #define CONFIG_DRIVER_OMAP34XX_I2C
 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 83a8b5d..d926f74 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -108,8 +108,6 @@
 #define CONFIG_HARD_I2C1
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_I2C_SLAVE   1
-#define CONFIG_SYS_I2C_BUS 0
-#define CONFIG_SYS_I2C_BUS_SELECT  1
 #define CONFIG_DRIVER_OMAP34XX_I2C 1
 
 /* TWL4030 */
diff --git a/include/configs/dig297.h b/include/configs/dig297.h
index 721b91c..e68654f 100644
--- a/include/configs/dig297.h
+++ b/include/configs/dig297.h
@@ -141,8 +141,6 @@
 #define CONFIG_HARD_I2C
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_I2C_SLAVE   1
-#define CONFIG_SYS_I2C_BUS 0
-#define CONFIG_SYS_I2C_BUS_SELECT  1
 #define CONFIG_DRIVER_OMAP34XX_I2C 1
 
 /*
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index f8131b1..e59f41e 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -129,8 +129,6 @@
 #define CONFIG_HARD_I2C1
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_I2C_SLAVE   1
-#define CONFIG_SYS_I2C_BUS 0
-#define CONFIG_SYS_I2C_BUS_SELECT  1
 #define CONFIG_DRIVER_OMAP34XX_I2C 1
 
 /*
diff --git a/include/configs/mcx.h b/include/configs/mcx.h
index 185faa7..1f09947 100644
--- a/include/configs/mcx.h
+++ b/include/configs/mcx.h
@@ -151,7 +151,6 @@
 #define CONFIG_HARD_I2C
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_I2C_SLAVE   1
-#define CONFIG_SYS_I2C_BUS 0
 #define CONFIG_DRIVER_OMAP34XX_I2C
 
 /* RTC */
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index d0daa45..59255c4 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -178,8 +178,6 @@
 #define CONFIG_HARD_I2C1
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_I2C_SLAVE   1
-#define CONFIG_SYS_I2C_BUS 0
-#define CONFIG_SYS_I2C_BUS_SELECT  1
 #define CONFIG_I2C_MULTI_BUS   1
 

Re: [U-Boot] [STATUS] v2013.01 released

2013-01-16 Thread Benoît Thébaudeau
Dear Tom Rini,

On Tuesday, January 15, 2013 11:17:28 PM, Tom Rini wrote:
 U-Boot v2013.01 has been released and uploaded to git.  I expect to
 see
 it on the ftp server soon.

Thanks for the release. It has however not yet reached the FTP server, and I
also don't see the 2013.01-rc versions there. Has there been any issue with the
FTP server since 2012.10?

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


Re: [U-Boot] configure USB Host1 in U-Boot of iMx53

2013-01-16 Thread Stefano Babic
On 16/01/2013 11:49, Sarvesh Gupta wrote:
 
 Dear All,
 
 I have added the USB host controller driver into our Mx53 loco board's u-boot 
 and also made some changes in mx53_loco.h and mx53_loco.c.
 
 Below is the complete log what I am getting on serial console:
 
 
 
 U-Boot 2009.08-dirty (Jan 15 2013 - 12:32:20)
 CPU:   Freescale i.MX53 family 2.1V at 800 MHz
 mx53 pll1: 800MHz
 mx53 pll2: 400MHz
 mx53 pll3: 216MHz
 mx53 pll4: 455MHz

This ML is intended for U-Boot mainline. However, you are using a
version provided and modified by the manufacturer. Ask your support for
this, or use u-boot mainline (v2013.01) to post your questions on this
mailing list.

Best regards,
Stefano Babic

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


Re: [U-Boot] configure USB Host1 in U-Boot of iMx53

2013-01-16 Thread Fabio Estevam
Sarvesh,

On Wed, Jan 16, 2013 at 9:24 AM, Stefano Babic sba...@denx.de wrote:

 This ML is intended for U-Boot mainline. However, you are using a
 version provided and modified by the manufacturer. Ask your support for
 this, or use u-boot mainline (v2013.01) to post your questions on this
 mailing list.

USB host works by default on mx53loco. As Stefano suggested, please
switch to U-boot version 2013.01.

Regards,

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


Re: [U-Boot] [PATCH] Remove unused CONFIG_SYS_I2C_BUS[_SELECT]

2013-01-16 Thread Igor Grinberg
On 01/16/13 12:44, Michael Jones wrote:
 CONFIG_SYS_I2C_BUS and CONFIG_SYS_I2C_BUS_SELECT don't appear anywhere
 outside of config files.
 
 Signed-off-by: Michael Jones michael.jo...@matrix-vision.de

Thanks for the patch!

Acked-by: Igor Grinberg grinb...@compulab.co.il

 ---
 As far as I can tell, these CONFIG options never have existed outside of these
 config files - looking at omap3_beagle.h as an example, these lines were
 inserted with the creation of that file, and at that point in time there was
 also no occurence of them elsewhere. Can't we get rid of them?

Yes we can and should ;-)


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


[U-Boot] [PATCH 1/2] MIPS: use inline directive for __in*s functions

2013-01-16 Thread Gabor Juhos
All other IO accessor functions are using the
'inline' directive. Use that also for the __in*s
to make it consistent with the other variants.

Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com

---
NOTE: checkpatch.pl throwns an error for the patch:

  0001-MIPS-use-inline-directive-for-__in-s-functions.patch:24: ERROR: open 
brace '{' following function declarations go on the next line
  total: 1 errors, 0 warnings, 8 lines checked

However that error is already present if the
'arch/mips/include/asm/io.h' file is checked
with checkpatch.pl. The cleanup should be
done in a separare patch.
---
 arch/mips/include/asm/io.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 80eab75..50466f2 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -268,7 +268,7 @@ __OUT1(s##c_p) __OUT2(m) : : r (__ioswab##w(value)), ir 
(port), r (mips_io
SLOW_DOWN_IO; }
 
 #define __IN1(t,s) \
-extern __inline__ t __in##s(unsigned int port) { t _v;
+extern inline t __in##s(unsigned int port) { t _v;
 
 /*
  * Required nops will be inserted by the assembler
-- 
1.7.10

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


[U-Boot] [PATCH 2/2] MIPS: convert IO port accessor functions to 'static inline'

2013-01-16 Thread Gabor Juhos
The currently used 'extern inline' directive causes
the following compiler warnings if CONFIG_SWAP_IO_SPACE
is defined:

  .../include/asm/io.h:345:1: warning: '__fswab32' is static but used in 
inline function '__outlc_p' which is not static [enabled by default]
  .../include/asm/io.h:345:1: warning: '__fswab32' is static but used in 
inline function '__outl_p' which is not static [enabled by default]
  .../include/asm/io.h:345:1: warning: '__fswab32' is static but used in 
inline function '__outlc' which is not static [enabled by default]
  .../include/asm/io.h:345:1: warning: '__fswab32' is static but used in 
inline function '__outl' which is not static [enabled by default]
  .../include/asm/io.h:344:1: warning: '__fswab16' is static but used in 
inline function '__outwc_p' which is not static [enabled by default]
  .../include/asm/io.h:344:1: warning: '__fswab16' is static but used in 
inline function '__outw_p' which is not static [enabled by default]
  .../include/asm/io.h:344:1: warning: '__fswab16' is static but used in 
inline function '__outwc' which is not static [enabled by default]
  .../include/asm/io.h:344:1: warning: '__fswab16' is static but used in 
inline function '__outw' which is not static [enabled by default]
  .../include/asm/io.h:341:1: warning: '__fswab32' is static but used in 
inline function '__inlc_p' which is not static [enabled by default]
  .../include/asm/io.h:341:1: warning: '__fswab32' is static but used in 
inline function '__inl_p' which is not static [enabled by default]
  .../include/asm/io.h:341:1: warning: '__fswab32' is static but used in 
inline function '__inlc' which is not static [enabled by default]
  .../include/asm/io.h:341:1: warning: '__fswab32' is static but used in 
inline function '__inl' which is not static [enabled by default]
  .../include/asm/io.h:340:1: warning: '__fswab16' is static but used in 
inline function '__inwc_p' which is not static [enabled by default]
  .../include/asm/io.h:340:1: warning: '__fswab16' is static but used in 
inline function '__inw_p' which is not static [enabled by default]
  .../include/asm/io.h:340:1: warning: '__fswab16' is static but used in 
inline function '__inwc' which is not static [enabled by default]
  .../include/asm/io.h:340:1: warning: '__fswab16' is static but used in 
inline function '__inw' which is not static [enabled by default]

Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com

---
NOTE: checkpatch.pl throwns some errors/warnings for the patch:

  0002-MIPS-convert-IO-port-accessor-functions-to-static-in.patch:42: ERROR: 
open brace '{' following function declarations go on the next line
  0002-MIPS-convert-IO-port-accessor-functions-to-static-in.patch:51: ERROR: 
open brace '{' following function declarations go on the next line
  0002-MIPS-convert-IO-port-accessor-functions-to-static-in.patch:60: WARNING: 
line over 80 characters
  0002-MIPS-convert-IO-port-accessor-functions-to-static-in.patch:60: ERROR: 
foo * bar should be foo *bar
  0002-MIPS-convert-IO-port-accessor-functions-to-static-in.patch:60: ERROR: 
open brace '{' following function declarations go on the next line
  0002-MIPS-convert-IO-port-accessor-functions-to-static-in.patch:69: WARNING: 
line over 80 characters
  0002-MIPS-convert-IO-port-accessor-functions-to-static-in.patch:69: ERROR: 
foo * bar should be foo *bar
  0002-MIPS-convert-IO-port-accessor-functions-to-static-in.patch:69: ERROR: 
open brace '{' following function declarations go on the next line

However those errors are already present if the
'arch/mips/include/asm/io.h' file is checked
with checkpatch.pl. The cleanup should be done
in a separare patch.
---
 arch/mips/include/asm/io.h |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 50466f2..3864c80 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -254,7 +254,7 @@ out:
  */
 
 #define __OUT1(s) \
-extern inline void __out##s(unsigned int value, unsigned int port) {
+static inline void __out##s(unsigned int value, unsigned int port) {
 
 #define __OUT2(m) \
 __asm__ __volatile__ (s #m \t%0,%1(%2)
@@ -268,7 +268,7 @@ __OUT1(s##c_p) __OUT2(m) : : r (__ioswab##w(value)), ir 
(port), r (mips_io
SLOW_DOWN_IO; }
 
 #define __IN1(t,s) \
-extern inline t __in##s(unsigned int port) { t _v;
+static inline t __in##s(unsigned int port) { t _v;
 
 /*
  * Required nops will be inserted by the assembler
@@ -283,7 +283,7 @@ __IN1(t,s##_p) __IN2(m) : =r (_v) : i (0), r 
(mips_io_port_base+port)); SL
 __IN1(t,s##c_p) __IN2(m) : =r (_v) : ir (port), r (mips_io_port_base)); 
SLOW_DOWN_IO; return __ioswab##w(_v); }
 
 #define __INS1(s) \
-extern inline void __ins##s(unsigned int port, void * addr, unsigned long 
count) {
+static inline void __ins##s(unsigned int port, void * addr, unsigned long 
count) {
 
 #define __INS2(m) \
 if (count) \
@@ -311,7 +311,7 

Re: [U-Boot] [STATUS] v2013.01 released

2013-01-16 Thread Tom Rini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/16/2013 05:59 AM, Benoît Thébaudeau wrote:
 Dear Tom Rini,
 
 On Tuesday, January 15, 2013 11:17:28 PM, Tom Rini wrote:
 U-Boot v2013.01 has been released and uploaded to git.  I expect
  to see it on the ftp server soon.
 
 Thanks for the release. It has however not yet reached the FTP 
 server, and I also don't see the 2013.01-rc versions there. Has 
 there been any issue with the FTP server since 2012.10?

It's not automatic for things to be made for the FTP server (I don't
have access myself, even).

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ9qOYAAoJENk4IS6UOR1Wgs8P/1ib8Wp7y4aSEFIod+TCTawj
n6vemg11XbOvJ0JRs1HsNYq40+EOCoObgmc3sZIModCkOACbPTzycz7sQORKMeXR
SBpo5gsbYZznywiL8HQTLdGjVr5IfLK2i4d2GuEQbJlKVNyPOJ5EiElkYFegqVWZ
wvA+qbnlhKW+3cMHXJaAFOEMy9Ytr7qIqaqGhXC4C0wMiQlwDDCR4MaqMo0TF1bs
BfNVIwYwdcfKESR83/Lkyy12zFj8g+ISz4hJAZDalFGCK91eqPUx7UUIELcJs7cm
/vxBlub2QWnPQmW6x1COdVmCSt/Wk3v8rOHjqONEBXF3AKExiOpxbx+IXBt8ewBC
cfuY9TEyuQyPjdh3XOvHHECUyFbSR2Vq1KIwsktle9gERdqUv0g1L4yLReS/HB36
T04D4T0BfheKb//mHEQlk9g4ooaSsTcoSi+3EIH1Qc16UQTp3z5ZwF9UmSEkWf/e
elEMdpQu1CPFJH3xW3fjphkXSnt/CH7YOD+rXSCZv4H0dot5TWOtTXA1i+DH6cfq
7SNsX2dDrFjx3BslfEaJR/6fVAIceMob0com+AahGGLfMsQ8KiBGdVBG5m7mvEId
QevAnOshjh8jL+k/17YhFGZMCDT1u8JaSkJH84KRfwazDhGVy9lnsNJGMrgOkbj5
EO1cd8tlocPM+m+LY7ym
=Apch
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Function prototype conflicts with standalone apps

2013-01-16 Thread Albert ARIBAUD
Hi Chris,

On Wed, 16 Jan 2013 23:16:07 +1300, Chris Packham
judge.pack...@gmail.com wrote:

 Hi Albert,
 
 On 01/16/2013 08:25 PM, Albert ARIBAUD (U-Boot) wrote:
  Hi Chris,
  
  On Wed, 16 Jan 2013 17:23:58 +1300, Chris Packham
  judge.pack...@gmail.com wrote:
  
  Hi,
 
  I've just run into something porting an existing out of tree board to
  u-boot 2012.10 but I think it points to a generic issue for standalone
  applications.
 
  Consider the following change
 
  diff --git a/examples/standalone/hello_world.c
  b/examples/standalone/hello_world.c
  index 067c390..d2e6a77 100644
  --- a/examples/standalone/hello_world.c
  +++ b/examples/standalone/hello_world.c
  @@ -24,7 +24,7 @@
   #include common.h
   #include exports.h
 
  -int hello_world (int argc, char * const argv[])
  +int net_init (int argc, char * const argv[])
   {
  int i;
 
  Because I'm not linking with the u-boot object file, I should be able to
  use any function name I like in my application as long as it isn't one of
  the functions in exports.h (at least in theory). Unfortunately I end up
  with the following compiler error
 
hello_world.c:27: error: conflicting types for ‘net_init’
uboot/include/net.h:489: error: previous declaration of ‘net_init’ was
  here
make[1]: *** [hello_world.o] Error 1
 
  If I replace #include common.h in my app with the first hunk of includes
  from the top of common.h  then I can compile just fine.
 
  I was wondering if it made sense to people to have standalone applications
  define something like __STANDALONE__ either via CPPFLAGS or in the source
  itself and use the presence of that to exclude the majority of common.h
  when used in standalone applications. Or alternatively move the required
  bits to exports.h.
  
  (long rant ahead. Short answer after end of rant)
 
 Short response: Yep I can live with that by making some changes to my
 standalone application. I just thought it might be cleaner if a minimal
 set of definitions were provided.
 
  [RANT]
  
  Code writers indeed have a right to name any function or other object
  any way they choose... within the constraints of the situation.
  
  Some of these constraints stem from the tools -- you just cannot put an
  ampersand in a C object name, for instance -- and some stem from the
  'agreement' entered into when using a library -- precisely, the
  agreement on the name and semantics of such and such object names.
  
  Here, by including exports.h, you enter an agreement in which
  the object name 'net_init' receives a specific meaning. What you want
  is to benefit from the agreement without abiding by it.
  
  Now this can be changed, technically, as most things are, and a new
  kind of agreement could be devised with fine-grain control on which
  object names would or would not be defined. The question is, *should*
  this be done?
  
  Would you, analogously, suggest that Linux app developers be able to
  opt out of defining fopen() when they #include stdio.h because they
  feel they have a right to define 'char* fopen(float F)' in their code if
  they so please? And that it should be done so for just about any
  kernel-exported symbol? I suspect not.
 
 Actually this is my point. The symbols aren't exported. They're just in
 the header file. The kernel solution for this is using __KERNEL__ and
 filtering the exported headers to remove the kernel internals not needed
 by userland. If for some reason I did define a different fopen I'd get a
 link error whether I included stdio or not.

Ok, so I misunderstood your objective -- my bad. It is not a problem of
wanting to use a function which is part of the API; it's a problem of
having to pull in non-API function declarations along with the API ones.

I still think it's a bad idea to use a homonym of an existing U-Boot
function, but at least you should not be prevented from doing so if
the function is not actually in the API.

But also I still dislike the solution you are suggestiong, because I
think that the actual problem is not properly stated. Re-reading the
common.h and exports.h header files, IIUC the actual problem is that
exports.h depends on some types from common.h but common.h also defines
some internal U-Boot functions. The problem is that common.h is needed
for different and incompatible purposes: (public) API on the one hand,
internal declarations on the other hand.

Thus, I'd rather have common.h simply split into a header file
with basic types needed by both public API and internal code and a
header file defining some internal U-Boot functions, possibly
#including the shared basic types header file, with no conditional
involved. New header file names to be chosen wisely.

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


[U-Boot] [PATCH] MIPS: start{, 64}.S: fill branch delay slots with NOP instructions

2013-01-16 Thread Gabor Juhos
The romReserved and romExcHandle handlers are
accessed by a branch instruction however the
delay slots of those instructions are not filled.

Because the start.S uses the 'noreorder' directive,
the assembler will not fill the delay slots either,
and leads to the following assembly code:

  056c romReserved:
   56c:   1000b   56c romReserved

  0570 romExcHandle:
   570:   1000b   570 romExcHandle

In the resulting code, the second branch instruction
is placed into the delay slot of the first branch
instruction, which is not allowed on the MIPS
architecture.

Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
---
 arch/mips/cpu/mips32/start.S |2 ++
 arch/mips/cpu/mips64/start.S |1 +
 2 files changed, 3 insertions(+)

diff --git a/arch/mips/cpu/mips32/start.S b/arch/mips/cpu/mips32/start.S
index 9c1b2f7..22a9c1b 100644
--- a/arch/mips/cpu/mips32/start.S
+++ b/arch/mips/cpu/mips32/start.S
@@ -380,6 +380,8 @@ in_ram:
/* Exception handlers */
 romReserved:
b   romReserved
+nop
 
 romExcHandle:
b   romExcHandle
+nop
diff --git a/arch/mips/cpu/mips64/start.S b/arch/mips/cpu/mips64/start.S
index 2b8d531..bc7e41e 100644
--- a/arch/mips/cpu/mips64/start.S
+++ b/arch/mips/cpu/mips64/start.S
@@ -259,3 +259,4 @@ in_ram:
/* Exception handlers */
 romReserved:
b   romReserved
+nop
-- 
1.7.10

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


[U-Boot] [PATCH] MIPS: board.c: fix monitor length calculations

2013-01-16 Thread Gabor Juhos
The current code uses the CONFIG_SYS_MONITOR_BASE
constant to calculate the size of the reserved
memory for U-Boot. The constant is also used
explicitly to calcualte the value of the
monitor_flash_len variable.

However this leads to miscalculated values if
CONFIG_SYS_TEXT_BASE != CONFIG_SYS_MONITOR_BASE.

Use the linked address of the _start symbol in
the calculations to fix the miscalculated values.

Also print the calculated monitor length if
debug is enabled.

Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Daniel Schwierzeck daniel.schwierz...@googlemail.com
---
 arch/mips/include/asm/u-boot-mips.h |1 +
 arch/mips/lib/board.c   |5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/u-boot-mips.h 
b/arch/mips/include/asm/u-boot-mips.h
index 6f26dfa..4421696 100644
--- a/arch/mips/include/asm/u-boot-mips.h
+++ b/arch/mips/include/asm/u-boot-mips.h
@@ -5,6 +5,7 @@
  * Copyright (C) 2003 Wolfgang Denk, DENX Software Engineering, w...@denx.de
  */
 
+extern ulong _start;
 extern ulong uboot_end_data;
 extern ulong uboot_end;
 
diff --git a/arch/mips/lib/board.c b/arch/mips/lib/board.c
index d79e183..5c4d0eb 100644
--- a/arch/mips/lib/board.c
+++ b/arch/mips/lib/board.c
@@ -143,7 +143,7 @@ void board_init_f(ulong bootflag)
gd_t gd_data, *id;
bd_t *bd;
init_fnc_t **init_fnc_ptr;
-   ulong addr, addr_sp, len = (ulong)uboot_end - CONFIG_SYS_MONITOR_BASE;
+   ulong addr, addr_sp, len = (ulong)uboot_end - (ulong)_start;
ulong *s;
 
/* Pointer is writable since we allocated a register for it.
@@ -261,7 +261,8 @@ void board_init_r(gd_t *id, ulong dest_addr)
 
gd-reloc_off = dest_addr - CONFIG_SYS_MONITOR_BASE;
 
-   monitor_flash_len = (ulong)uboot_end_data - dest_addr;
+   monitor_flash_len = (ulong)uboot_end_data - (ulong)_start;
+   debug(Monitor flash len: %08lX\n, monitor_flash_len);
 
serial_initialize();
 
-- 
1.7.10

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


Re: [U-Boot] [u-boot-release] [PATCH 1/3] powerpc/p5040: enable NAND boot support

2013-01-16 Thread Timur Tabi
Shaohui Xie wrote:
 Signed-off-by: Shaohui Xie shaohui@freescale.com
 ---

These patches only add one line each, and each depends on the previous
anyway.  They should be merged into one patch.

  boards.cfg |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/boards.cfg b/boards.cfg
 index e4b0d44..8cf4936 100644
 --- a/boards.cfg
 +++ b/boards.cfg
 @@ -855,6 +855,7 @@ P5020DS_SECURE_BOOT  powerpc mpc85xx 
 corenet_ds  freesca
  P5020DS_SPIFLASH  powerpc mpc85xx corenet_ds  
 freescale  -   
 P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
  P5020DS_SRIO_PCIE_BOOT  powerpc mpc85xx corenet_ds  
 freescale  -   
 P5020DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF8
  P5040DS  powerpc mpc85xx corenet_ds  
 freescale
 +P5040DS_NAND  powerpc mpc85xx corenet_ds  
 freescale  -   P5040DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
  BSC9131RDB_SPIFLASH  powerpc mpc85xx bsc9131rdb  
 freescale  -   BSC9131RDB:BSC9131RDB,SPIFLASH
  stxgp3   powerpc mpc85xx stxgp3  stx
  stxssa   powerpc mpc85xx stxssa  stx 
-   stxssa
 


-- 
Timur Tabi
Linux kernel developer at Freescale

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


[U-Boot] U-Boot Graphics Library?

2013-01-16 Thread Simon Glass
Hi,

We are currently using a very rudimentary graphics features attached
to U-Boot. It can only display bitmap images. We use this in Chromium
to composite a display for the various screens we need to display in
U-Boot. Unfortunately the graphics screens get quite large when using
multiple languages since they are pre-rendered.

Is there any interest in a simply graphics library in U-Boot, that can
display things on the screen? We already have bitmap support, but
could perhaps add outline font support (e.g. freetype) as well. This
might allow display of simple boot menus or booting information. A
board could create a structure containing a list of things to display
(text, bitmaps) and pass it to the graphics library for rendering
using existing functions and the new font support.

If we do this, rather than re-invent the wheel, does anyone have any
suggestions on a very small and simple existing library that we could
bring in to do this?

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


[U-Boot] Flash Not Erased for M29W128GL

2013-01-16 Thread Ramesh K Khokhani
Hi Friends,

I am having problem with 16MB M29W128GL Flash. I am getting Flash Not Erased 
when i try to use saveenv command at u-boot command prompt.

I have tried manually Byte by Byte wise writing to NOR Flash location so for 
that i have use following command and getting 2 same byte write on consecutive 
location.

And when i have try to write word using mw.w then it writes correct.

Before use command:

- md 0x5

0005:    
00050010:    
00050020:    
00050030:    
00050040:    
00050050:    
00050060:    
00050070:    
00050080:    
00050090:    
000500a0:    
000500b0:    
000500c0:    
000500d0:    
000500e0:    
000500f0:    

After use command: (Here i have try to write 0x12 on 0x5 location but it 
writes two same bytes on 0x5  0x50001)

- mw.b 0x?50?aaa 0xaa

- mw.b 0x50554 0x55

- mw.b 0x50aaa 0xa0

- mw.b 0x5 0x12

- md 0x5

0005: 1212   
00050010:    
00050020:    
00050030:    
00050040:    
00050050:    
00050060:    
00050070:    
00050080:    
00050090:    
000500a0:    
000500b0:    
000500c0:    
000500d0:    
000500e0:    
000500f0:    

When try to write word using mw.w then it writes correct:

- md? ?w.w 0x50?aaa 0xaa

- mw.w 0x50554 0x55

- mw.w 0x50aaa ??xa0? ?

- mw.w 0x500?10 0x1234

- md 5

0005: 1212   
00050010: 1234   .4..
00050020:    
00050030:    
00050040:    
00050050:    
00050060:    
00050070:    
00050080:    
00050090:    
000500a0:    
000500b0:    
000500c0:    
000500d0:    
000500e0:    
000500f0:    


So what may be problem?

Internally it uses following command (8bit x b bit). Is it problem? it should 
be 16bit x 8 bit?

fwc addr 00040aaa cmd aa aa 8bit x 8 bit
fwc addr 00040554 cmd 55 55 8bit x 8 bit
fwc addr 00040aaa cmd a0 a0 8bit x 8 bit


Thanks  Warm Regards,

Ramesh Khokhani
Senior Software Engineer

[X]

...

 ramesh.khokh...@igatepatni.com

~~Disclaimer~~~
Information contained and transmitted by this e-mail is confidential and 
proprietary to iGATE and its affiliates and is intended for use only by the 
recipient. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution, copying or use of this e-mail is strictly 
prohibited and you are requested to delete this e-mail immediately 

Re: [U-Boot] Flash Not Erased for M29W128GL

2013-01-16 Thread Fabio Estevam
On Wed, Jan 16, 2013 at 2:23 PM, Ramesh K Khokhani
ramesh.khokh...@igate.com wrote:
 Hi Friends,

 I am having problem with 16MB M29W128GL Flash. I am getting Flash Not Erased 
 when i try to use saveenv command at u-boot command prompt.

You forgot to mention which board and U-boot version you are using.

Regards,

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


Re: [U-Boot] Flash Not Erased for M29W128GL

2013-01-16 Thread Ramesh K Khokhani
Hi Fabio,

Thanks for replaying me.

We have our custom board which uses MCF5329 Coldfire freescale's processor and 
16MB M29W128GL NOR Flash.

We have one M5329EVB evaluation board which has same processor but 2MB LHF00F31 
NOR Flash (16bit x 16bit). For this evaluation board we have LTIB packege 
provided by freescale and which has u-boot-2011.09 version.


Thanks  Warm Regards,

Ramesh Khokhani
Senior Software Engineer


...
 ramesh.khokh...@igatepatni.com

From: Fabio Estevam [feste...@gmail.com]
Sent: Wednesday, January 16, 2013 10:07 PM
To: Ramesh K Khokhani
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Flash Not Erased for M29W128GL

On Wed, Jan 16, 2013 at 2:23 PM, Ramesh K Khokhani
ramesh.khokh...@igate.com wrote:
 Hi Friends,

 I am having problem with 16MB M29W128GL Flash. I am getting Flash Not Erased 
 when i try to use saveenv command at u-boot command prompt.

You forgot to mention which board and U-boot version you are using.

Regards,

Fabio Estevam

~~Disclaimer~~~
Information contained and transmitted by this e-mail is confidential and 
proprietary to iGATE and its affiliates and is intended for use only by the 
recipient. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution, copying or use of this e-mail is strictly 
prohibited and you are requested to delete this e-mail immediately and notify 
the originator or mailad...@igate.com mailto:mailad...@igate.com. iGATE does 
not enter into any agreement with any party by e-mail. Any views expressed by 
an individual do not necessarily reflect the view of iGATE. iGATE is not 
responsible for the consequences of any actions taken on the basis of 
information provided, through this email. The contents of an attachment to this 
e-mail may contain software viruses, which could damage your own computer 
system. While iGATE has taken every reasonable precaution to minimise this 
risk, we cannot accept liability for any damage which you sustain as a result of
  software viruses. You should carry out your own virus checks before opening 
an attachment. To know more about iGATE please visit www.igate.com 
http://www.igate.com.


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


[U-Boot] FW: Flash Not Erased for M29W128GL

2013-01-16 Thread Ramesh K Khokhani

Hi Fabio,

Thanks for replaying me.

We have our custom board which uses MCF5329 Coldfire freescale's processor and 
16MB M29W128GL NOR Flash.

We have one M5329EVB evaluation board which has same processor but 2MB LHF00F31 
NOR Flash (16bit x 16bit). For this evaluation board we have LTIB packege 
provided by freescale and which has u-boot-2011.09 version.

This LTIB package we are using with some CFI CONFIG parameter changes. i.e. 
sector size, env offset add etc.

Thanks  Warm Regards,

Ramesh Khokhani
Senior Software Engineer


...
 ramesh.khokh...@igatepatni.com

From: Fabio Estevam [feste...@gmail.com]
Sent: Wednesday, January 16, 2013 10:07 PM
To: Ramesh K Khokhani
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Flash Not Erased for M29W128GL

On Wed, Jan 16, 2013 at 2:23 PM, Ramesh K Khokhani
ramesh.khokh...@igate.com wrote:
 Hi Friends,

 I am having problem with 16MB M29W128GL Flash. I am getting Flash Not Erased 
 when i try to use saveenv command at u-boot command prompt.

You forgot to mention which board and U-boot version you are using.

Regards,

Fabio Estevam

~~Disclaimer~~~
Information contained and transmitted by this e-mail is confidential and 
proprietary to iGATE and its affiliates and is intended for use only by the 
recipient. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution, copying or use of this e-mail is strictly 
prohibited and you are requested to delete this e-mail immediately and notify 
the originator or mailad...@igate.com mailto:mailad...@igate.com. iGATE does 
not enter into any agreement with any party by e-mail. Any views expressed by 
an individual do not necessarily reflect the view of iGATE. iGATE is not 
responsible for the consequences of any actions taken on the basis of 
information provided, through this email. The contents of an attachment to this 
e-mail may contain software viruses, which could damage your own computer 
system. While iGATE has taken every reasonable precaution to minimise this 
risk, we cannot accept liability for any damage which you sustain as a result of
  software viruses. You should carry out your own virus checks before opening 
an attachment. To know more about iGATE please visit www.igate.com 
http://www.igate.com.


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

~~Disclaimer~~~
Information contained and transmitted by this e-mail is confidential and 
proprietary to iGATE and its affiliates and is intended for use only by the 
recipient. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution, copying or use of this e-mail is strictly 
prohibited and you are requested to delete this e-mail immediately and notify 
the originator or mailad...@igate.com mailto:mailad...@igate.com. iGATE does 
not enter into any agreement with any party by e-mail. Any views expressed by 
an individual do not necessarily reflect the view of iGATE. iGATE is not 
responsible for the consequences of any actions taken on the basis of 
information provided, through this email. The contents of an attachment to this 
e-mail may contain software viruses, which could damage your own computer 
system. While iGATE has taken every reasonable precaution to minimise this 
risk, we cannot accept liability for any damage which you sustain as a result of
  software viruses. You should carry out your own virus checks before opening 
an attachment. To know more about iGATE please visit www.igate.com 
http://www.igate.com.


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


[U-Boot] [PATCH v3 00/10] Add Marvell Dove and SolidRun CuBox

2013-01-16 Thread Sebastian Hesselbarth
This patch set add support for the Marvell Dove 88AP510 SoC and
the SolidRun CuBox board based on that SoC. The patch set is divided
into the four following sections:

(1) Patches 1-5:
Add support for the Dove SoC and related drivers. Where possible
drivers from Marvell Kirkwood are reused (mvsata, mvgbe), or
forked to allow more generic usage (SPI, GPIO). The SDHCI driver
is different and a new driver is added for it. The forked drivers
can also be reused on Kirkwood but that would have required patching
existing boards.

(2) Patches 6-8:
Allow mvgbe to use the phylib API, add support for 88E1310 PHY and
allow Dove to use the driver.

(3) Patch 9
Add the SolidRun CuBox as the first board based on Marvell Dove SoC.

(4) Patch 10
Add support for different UART boot mode found on Dove.

Changelog:
v1-v2:
- respect review comments by Luka Perkov
- fix commenting styles and typos
- add MAINTAINERS entry
- also update kwboot.1 manpage

v2-v3:
- integrate kwboot patch from Daniel Stodden
- rebase on release v2013.01

Sebastian Hesselbarth (10):
  ARM: dove: add support for Marvell Dove SoC
  GPIO: add gpio driver for Orion SoCs
  MMC: sdhci: Add support for dove sdhci
  SPI: Add Orion SPI driver
  block: mvsata: add dove include
  NET: phy: add 88E1310 PHY initialization
  NET: mvgbe: add phylib support
  NET: mvgbe: add support for Dove
  Boards: Add support for SolidRun CuBox
  tools: Add support for Dove to kwboot

 MAINTAINERS |4 +
 arch/arm/cpu/armv7/dove/Makefile|   49 +
 arch/arm/cpu/armv7/dove/cpu.c   |  266 ++
 arch/arm/cpu/armv7/dove/dram.c  |  118 
 arch/arm/cpu/armv7/dove/lowlevel_init.S |   83 
 arch/arm/cpu/armv7/dove/mpp.c   |  318 +++
 arch/arm/cpu/armv7/dove/timer.c |  176 +
 arch/arm/cpu/armv7/dove/usb.c   |  101 ++
 arch/arm/include/asm/arch-dove/config.h |  153 +++
 arch/arm/include/asm/arch-dove/cpu.h|  204 
 arch/arm/include/asm/arch-dove/dove.h   |   93 +
 arch/arm/include/asm/arch-dove/gpio.h   |   35 
 arch/arm/include/asm/arch-dove/mpp.h|  283 +++
 board/solidrun/cubox/Makefile   |   45 +
 board/solidrun/cubox/cubox.c|  141 ++
 board/solidrun/cubox/kwbimage.cfg   |   76 
 boards.cfg  |1 +
 doc/kwboot.1|   13 +-
 drivers/block/mvsata_ide.c  |2 +
 drivers/gpio/Makefile   |1 +
 drivers/gpio/orion_gpio.c   |  167 
 drivers/mmc/Makefile|1 +
 drivers/mmc/dove_sdhci.c|  101 ++
 drivers/net/mvgbe.c |   70 ++-
 drivers/net/mvgbe.h |7 +
 drivers/net/phy/marvell.c   |   48 +
 drivers/spi/Makefile|1 +
 drivers/spi/orion_spi.c |  217 +
 include/configs/cubox.h |  175 +
 include/orion_gpio.h|   64 +++
 tools/Makefile  |2 +
 tools/kwboot.c  |   25 ++-
 32 files changed, 3027 insertions(+), 13 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/dove/Makefile
 create mode 100644 arch/arm/cpu/armv7/dove/cpu.c
 create mode 100644 arch/arm/cpu/armv7/dove/dram.c
 create mode 100644 arch/arm/cpu/armv7/dove/lowlevel_init.S
 create mode 100644 arch/arm/cpu/armv7/dove/mpp.c
 create mode 100644 arch/arm/cpu/armv7/dove/timer.c
 create mode 100644 arch/arm/cpu/armv7/dove/usb.c
 create mode 100644 arch/arm/include/asm/arch-dove/config.h
 create mode 100644 arch/arm/include/asm/arch-dove/cpu.h
 create mode 100644 arch/arm/include/asm/arch-dove/dove.h
 create mode 100644 arch/arm/include/asm/arch-dove/gpio.h
 create mode 100644 arch/arm/include/asm/arch-dove/mpp.h
 create mode 100644 board/solidrun/cubox/Makefile
 create mode 100644 board/solidrun/cubox/cubox.c
 create mode 100644 board/solidrun/cubox/kwbimage.cfg
 create mode 100644 drivers/gpio/orion_gpio.c
 create mode 100644 drivers/mmc/dove_sdhci.c
 create mode 100644 drivers/spi/orion_spi.c
 create mode 100644 include/configs/cubox.h
 create mode 100644 include/orion_gpio.h

---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
-- 
1.7.10.4

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


[U-Boot] [PATCH v3 09/10] Boards: Add support for SolidRun CuBox

2013-01-16 Thread Sebastian Hesselbarth
With latest support for Marvell Dove SoC, add the SolidRun CuBox as
the very first board with that SoC.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
---
 MAINTAINERS   |4 +
 board/solidrun/cubox/Makefile |   45 ++
 board/solidrun/cubox/cubox.c  |  141 ++
 board/solidrun/cubox/kwbimage.cfg |   76 
 boards.cfg|1 +
 include/configs/cubox.h   |  175 +
 6 files changed, 442 insertions(+)
 create mode 100644 board/solidrun/cubox/Makefile
 create mode 100644 board/solidrun/cubox/cubox.c
 create mode 100644 board/solidrun/cubox/kwbimage.cfg
 create mode 100644 include/configs/cubox.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 28c052d..6fc8618 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -684,6 +684,10 @@ Stefan Herbrechtsmeier ste...@code.herbrechtsmeier.net
 
dns325  ARM926EJS (Kirkwood SoC)
 
+Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+
+   cubox   ARM ARMV7 (Dove SoC)
+
 Vaibhav Hiremath hvaib...@ti.com
 
am3517_evm  ARM ARMV7 (AM35x SoC)
diff --git a/board/solidrun/cubox/Makefile b/board/solidrun/cubox/Makefile
new file mode 100644
index 000..c771d72
--- /dev/null
+++ b/board/solidrun/cubox/Makefile
@@ -0,0 +1,45 @@
+#
+# SolidRun CuBox Makefile
+#
+# Sebastian Hesselbarth sebastian.hesselba...@gmail.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., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := cubox.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/solidrun/cubox/cubox.c b/board/solidrun/cubox/cubox.c
new file mode 100644
index 000..70c016f
--- /dev/null
+++ b/board/solidrun/cubox/cubox.c
@@ -0,0 +1,141 @@
+/*
+ * SolidRun CuBox board support
+ *
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include miiphy.h
+#include asm/arch/cpu.h
+#include asm/arch/dove.h
+#include asm/arch/mpp.h
+#include orion_gpio.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static u16 mpp_config[] = {
+   MPP0_GPIO,
+   MPP1_GPIO, /* USB power enable */
+   MPP2_GPIO, /* USB over-current indication */
+   MPP3_GPIO, /* micro button beneath eSATA port */
+   MPP4_GPIO,
+   MPP5_GPIO,
+   MPP6_GPIO,
+   MPP7_GPIO,
+
+   MPP8_GPIO,
+   MPP9_GPIO,
+   MPP10_GPIO,
+   MPP11_GPIO,
+   MPP12_GPIO, /* SDIO0 card detect */
+   MPP13_AUDIO1_EXTCLK, /* Si5351a audio clock output */
+   MPP14_GPIO,
+   MPP15_GPIO,
+
+   MPP16_GPIO,
+   

[U-Boot] [PATCH v3 08/10] NET: mvgbe: add support for Dove

2013-01-16 Thread Sebastian Hesselbarth
Marvell Dove also uses mvgbe as ethernet driver, therefore add support
for Dove to reuse the current driver.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
---
 drivers/net/mvgbe.c |2 ++
 drivers/net/mvgbe.h |7 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
index 192c989..590ea0b 100644
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
@@ -43,6 +43,8 @@
 #include asm/arch/kirkwood.h
 #elif defined(CONFIG_ORION5X)
 #include asm/arch/orion5x.h
+#elif defined(CONFIG_DOVE)
+#include asm/arch/dove.h
 #endif
 
 #include mvgbe.h
diff --git a/drivers/net/mvgbe.h b/drivers/net/mvgbe.h
index d8a5429..7f5d98f 100644
--- a/drivers/net/mvgbe.h
+++ b/drivers/net/mvgbe.h
@@ -308,10 +308,17 @@
 #define EBAR_TARGET_GUNIT  0x0007
 
 /* Window attrib */
+#if defined(CONFIG_DOVE)
+#define EBAR_DRAM_CS0  0x
+#define EBAR_DRAM_CS1  0x
+#define EBAR_DRAM_CS2  0x
+#define EBAR_DRAM_CS3  0x
+#else
 #define EBAR_DRAM_CS0  0x0E00
 #define EBAR_DRAM_CS1  0x0D00
 #define EBAR_DRAM_CS2  0x0B00
 #define EBAR_DRAM_CS3  0x0700
+#endif
 
 /* DRAM Target interface */
 #define EBAR_DRAM_NO_CACHE_COHERENCY   0x
-- 
1.7.10.4

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


[U-Boot] [PATCH v3 05/10] block: mvsata: add dove include

2013-01-16 Thread Sebastian Hesselbarth
Dove SoC also uses mvsata, therefore add a SoC specific include to
allow to reuse the mvsata ide driver.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
--
 drivers/block/mvsata_ide.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/block/mvsata_ide.c b/drivers/block/mvsata_ide.c
index a88d0f7..9918f80 100644
--- a/drivers/block/mvsata_ide.c
+++ b/drivers/block/mvsata_ide.c
@@ -29,6 +29,8 @@
 #include asm/arch/orion5x.h
 #elif defined(CONFIG_KIRKWOOD)
 #include asm/arch/kirkwood.h
+#elif defined(CONFIG_DOVE)
+#include asm/arch/dove.h
 #endif
 
 /* SATA port registers */
-- 
1.7.10.4

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


[U-Boot] [PATCH v3 06/10] NET: phy: add 88E1310 PHY initialization

2013-01-16 Thread Sebastian Hesselbarth
This adds PHY initialization for Marvell Alaska 88E1310 PHY.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
---
 drivers/net/phy/marvell.c |   48 +
 1 file changed, 48 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 4b27198..1205166 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -89,6 +89,12 @@
 
 #define MIIM_88E1149_PHY_PAGE  29
 
+/* 88E1310 PHY defines */
+#define MIIM_88E1310_PHY_LED_CTRL  16
+#define MIIM_88E1310_PHY_IRQ_EN18
+#define MIIM_88E1310_PHY_RGMII_CTRL21
+#define MIIM_88E1310_PHY_PAGE  22
+
 /* Marvell 88E1011S */
 static int m88e1011s_config(struct phy_device *phydev)
 {
@@ -394,6 +400,37 @@ static int m88e1149_config(struct phy_device *phydev)
return 0;
 }
 
+/* Marvell 88E1310 */
+static int m88e1310_config(struct phy_device *phydev)
+{
+   u16 reg;
+
+   /* LED link and activity */
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_PAGE, 0x0003);
+   reg = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_LED_CTRL);
+   reg = (reg  ~0xf) | 0x1;
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_LED_CTRL, reg);
+
+   /* Set LED2/INT to INT mode, low active */
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_PAGE, 0x0003);
+   reg = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_IRQ_EN);
+   reg = (reg  0x77ff) | 0x0880;
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_IRQ_EN, reg);
+
+   /* Set RGMII delay */
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_PAGE, 0x0002);
+   reg = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_RGMII_CTRL);
+   reg |= 0x0030;
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_RGMII_CTRL, reg);
+
+   /* Ensure to return to page 0 */
+   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_88E1310_PHY_PAGE, 0x);
+
+   genphy_config_aneg(phydev);
+   phy_reset(phydev);
+
+   return 0;
+}
 
 static struct phy_driver M88E1011S_driver = {
.name = Marvell 88E1011S,
@@ -465,8 +502,19 @@ static struct phy_driver M88E1149S_driver = {
.shutdown = genphy_shutdown,
 };
 
+static struct phy_driver M88E1310_driver = {
+   .name = Marvell 88E1310,
+   .uid = 0x01410e90,
+   .mask = 0xff0,
+   .features = PHY_GBIT_FEATURES,
+   .config = m88e1310_config,
+   .startup = m88e1011s_startup,
+   .shutdown = genphy_shutdown,
+};
+
 int phy_marvell_init(void)
 {
+   phy_register(M88E1310_driver);
phy_register(M88E1149S_driver);
phy_register(M88E1145_driver);
phy_register(M88E1121R_driver);
-- 
1.7.10.4

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


[U-Boot] [PATCH v3 04/10] SPI: Add Orion SPI driver

2013-01-16 Thread Sebastian Hesselbarth
This adds an SPI driver found on Marvell Orion SoCs. This driver is
taken from kirkwood_spi but removes mpp configuration as dove has
dedicated spi pins. To have a common driver for orion5x, kirkwood,
and dove, mpp configuration should be handled in some cpu/board-specific
setup.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
---
 drivers/spi/Makefile|1 +
 drivers/spi/orion_spi.c |  217 +++
 2 files changed, 218 insertions(+)
 create mode 100644 drivers/spi/orion_spi.c

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 824d357..624bb72 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -35,6 +35,7 @@ COBJS-$(CONFIG_CF_SPI) += cf_spi.o
 COBJS-$(CONFIG_CF_QSPI) += cf_qspi.o
 COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
 COBJS-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
+COBJS-$(CONFIG_ORION_SPI) += orion_spi.o
 COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
 COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
 COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
diff --git a/drivers/spi/orion_spi.c b/drivers/spi/orion_spi.c
new file mode 100644
index 000..8a50531
--- /dev/null
+++ b/drivers/spi/orion_spi.c
@@ -0,0 +1,217 @@
+/*
+ * Marvell Orion SoCs common spi driver
+ *
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+ * based on kirkwood_spi.c written by
+ *  Prafulla Wadaskar prafu...@marvell.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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include malloc.h
+#include spi.h
+#include asm/io.h
+#include asm/arch/config.h
+
+/* SPI Registers on orion SOC */
+struct orionspi_registers {
+   u32 ctrl;   /* 0x00 */
+   u32 cfg;/* 0x04 */
+   u32 dout;   /* 0x08 */
+   u32 din;/* 0x0c */
+   u32 irq_cause;  /* 0x10 */
+   u32 irq_mask;   /* 0x14 */
+};
+
+#define ORIONSPI_CLKPRESCL_MASK0x1f
+#define ORIONSPI_CLKPRESCL_MIN 0x12
+#define ORIONSPI_CSN_ACT   1 /* Activates serial memory interface */
+#define ORIONSPI_SMEMRDY   (1  1) /* SerMem Data xfer ready */
+#define ORIONSPI_IRQUNMASK 1 /* unmask SPI interrupt */
+#define ORIONSPI_IRQMASK   0 /* mask SPI interrupt */
+#define ORIONSPI_SMEMRDIRQ 1 /* SerMem data xfer ready irq */
+#define ORIONSPI_XFERLEN_1BYTE 0
+#define ORIONSPI_XFERLEN_2BYTE (1  5)
+#define ORIONSPI_XFERLEN_MASK  (1  5)
+#define ORIONSPI_ADRLEN_1BYTE  0
+#define ORIONSPI_ADRLEN_2BYTE  (1  8)
+#define ORIONSPI_ADRLEN_3BYTE  (2  8)
+#define ORIONSPI_ADRLEN_4BYTE  (3  8)
+#define ORIONSPI_ADRLEN_MASK   (3  8)
+#define ORIONSPI_TIMEOUT   1
+
+static struct orionspi_registers *spireg =
+   (struct orionspi_registers *)ORION_SPI_BASE;
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+   unsigned int max_hz, unsigned int mode)
+{
+   struct spi_slave *slave;
+   u32 data;
+   u32 kwspi_mpp_config[] = { 0, 0 };
+
+   if (!spi_cs_is_valid(bus, cs))
+   return NULL;
+
+   slave = malloc(sizeof(struct spi_slave));
+   if (!slave)
+   return NULL;
+
+   slave-bus = bus;
+   slave-cs = cs;
+
+   writel(~ORIONSPI_CSN_ACT | ORIONSPI_SMEMRDY, spireg-ctrl);
+
+   /* calculate spi clock prescaller using max_hz */
+   data = ((CONFIG_SYS_TCLK / 2) / max_hz) + 0x10;
+   data = data  ORIONSPI_CLKPRESCL_MIN ? ORIONSPI_CLKPRESCL_MIN : data;
+   data = data  ORIONSPI_CLKPRESCL_MASK ? ORIONSPI_CLKPRESCL_MASK : data;
+
+   /* program spi clock prescaller using max_hz */
+   writel(ORIONSPI_ADRLEN_3BYTE | data, spireg-cfg);
+   debug(data = 0x%08x\n, data);
+
+   writel(ORIONSPI_SMEMRDIRQ, spireg-irq_cause);
+   writel(ORIONSPI_IRQMASK, spireg-irq_mask);
+
+   return slave;
+}
+
+void spi_free_slave(struct spi_slave *slave)
+{
+   

[U-Boot] [PATCH v3 07/10] NET: mvgbe: add phylib support

2013-01-16 Thread Sebastian Hesselbarth
This add phylib support to the Marvell GBE driver.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
---
 drivers/net/mvgbe.c |   68 ---
 1 file changed, 64 insertions(+), 4 deletions(-)

diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
index 47bf27c..192c989 100644
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
@@ -52,7 +52,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define MV_PHY_ADR_REQUEST 0xee
 #define MVGBE_SMI_REG (((struct mvgbe_registers *)MVGBE0_BASE)-smi)
 
-#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+#if defined(CONFIG_PHYLIB) || defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
 /*
  * smi_reg_read - miiphy_read callback function.
  *
@@ -184,6 +184,24 @@ static int smi_reg_write(const char *devname, u8 phy_adr, 
u8 reg_ofs, u16 data)
 }
 #endif
 
+#if defined(CONFIG_PHYLIB)
+int mvgbe_phy_read(struct mii_dev *bus, int phyAddr, int devAddr, int regAddr)
+{
+   u16 data;
+   int ret;
+   ret = smi_reg_read(bus-name, phyAddr, regAddr, data);
+   if (ret)
+   return ret;
+   return data;
+}
+
+int mvgbe_phy_write(struct mii_dev *bus, int phyAddr, int devAddr, int regAddr,
+   u16 data)
+{
+   return smi_reg_write(bus-name, phyAddr, regAddr, data);
+}
+#endif
+
 /* Stop and checks all queues */
 static void stop_queue(u32 * qreg)
 {
@@ -467,8 +485,9 @@ static int mvgbe_init(struct eth_device *dev)
/* Enable port Rx. */
MVGBE_REG_WR(regs-rqc, (1  RXUQ));
 
-#if (defined (CONFIG_MII) || defined (CONFIG_CMD_MII)) \
- defined (CONFIG_SYS_FAULT_ECHO_LINK_DOWN)
+#if (defined(CONFIG_MII) || defined(CONFIG_CMD_MII))   \
+!defined(CONFIG_PHYLIB) \
+defined(CONFIG_SYS_FAULT_ECHO_LINK_DOWN)
/* Wait up to 5s for the link status */
for (i = 0; i  5; i++) {
u16 phyadr;
@@ -647,6 +666,45 @@ static int mvgbe_recv(struct eth_device *dev)
return 0;
 }
 
+#if defined(CONFIG_PHYLIB)
+int mvgbe_phylib_init(struct eth_device *dev, int phyid)
+{
+   struct mii_dev *bus;
+   struct phy_device *phydev;
+   int ret;
+
+   bus = mdio_alloc();
+   if (!bus) {
+   printf(mdio_alloc failed\n);
+   return -ENOMEM;
+   }
+   bus-read = mvgbe_phy_read;
+   bus-write = mvgbe_phy_write;
+   sprintf(bus-name, dev-name);
+
+   ret = mdio_register(bus);
+   if (ret) {
+   printf(mdio_register failed\n);
+   free(bus);
+   return -ENOMEM;
+   }
+
+   /* Set phy address of the port */
+   mvgbe_phy_write(bus, MV_PHY_ADR_REQUEST, 0, MV_PHY_ADR_REQUEST, phyid);
+
+   phydev = phy_connect(bus, phyid, dev, PHY_INTERFACE_MODE_RGMII);
+   if (!phydev) {
+   printf(phy_connect failed\n);
+   return -ENODEV;
+   }
+
+   phy_config(phydev);
+   phy_startup(phydev);
+
+   return 0;
+}
+#endif
+
 int mvgbe_initialize(bd_t *bis)
 {
struct mvgbe_device *dmvgbe;
@@ -729,7 +787,9 @@ error1:
 
eth_register(dev);
 
-#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+#if defined(CONFIG_PHYLIB)
+   mvgbe_phylib_init(dev, PHY_BASE_ADR + devnum);
+#elif defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
miiphy_register(dev-name, smi_reg_read, smi_reg_write);
/* Set phy address of the port */
miiphy_write(dev-name, MV_PHY_ADR_REQUEST,
-- 
1.7.10.4

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


[U-Boot] [PATCH v3 02/10] GPIO: add gpio driver for Orion SoCs

2013-01-16 Thread Sebastian Hesselbarth
This adds a gpio driver for Marvell Orion SoCs, i.e. orion5x, kirkwood,
dove. This is based on kw_gpio but as gpio capabilities depend heavily
on the mpp configuration for dove, it allows to set gpi/gpo capabilities
from mpp. This should be compatible with the current kw_gpio and porting
mpp of kirkwood and orion5x is appreciated.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
---
 drivers/gpio/Makefile |1 +
 drivers/gpio/orion_gpio.c |  167 +
 include/orion_gpio.h  |   64 +
 3 files changed, 232 insertions(+)
 create mode 100644 drivers/gpio/orion_gpio.c
 create mode 100644 include/orion_gpio.h

diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 2d97b4f..b0ad2b5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -27,6 +27,7 @@ LIB   := $(obj)libgpio.o
 
 COBJS-$(CONFIG_AT91_GPIO)  += at91_gpio.o
 COBJS-$(CONFIG_INTEL_ICH6_GPIO)+= intel_ich6_gpio.o
+COBJS-$(CONFIG_ORION_GPIO) += orion_gpio.o
 COBJS-$(CONFIG_KIRKWOOD_GPIO)  += kw_gpio.o
 COBJS-$(CONFIG_MARVELL_GPIO)   += mvgpio.o
 COBJS-$(CONFIG_MARVELL_MFP)+= mvmfp.o
diff --git a/drivers/gpio/orion_gpio.c b/drivers/gpio/orion_gpio.c
new file mode 100644
index 000..209354d
--- /dev/null
+++ b/drivers/gpio/orion_gpio.c
@@ -0,0 +1,167 @@
+/*
+ * Marvell Orion SoC GPIO handling.
+ *
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+ *
+ * Based on (mostly copied from) plat-orion based Linux 2.6 kernel driver.
+ * Removed orion_gpiochip struct and kernel level irq handling.
+ * Dieter Kiermaier dk-arm-li...@gmx.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., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+#include common.h
+#include asm/bitops.h
+#include asm/io.h
+#include asm/arch/gpio.h
+#include orion_gpio.h
+
+static unsigned long gpio_valid_input[BITS_TO_LONGS(GPIO_MAX)];
+static unsigned long gpio_valid_output[BITS_TO_LONGS(GPIO_MAX)];
+
+void __set_direction(unsigned pin, int input)
+{
+   u32 base = GPIO_BASE(pin);
+   u32 u;
+
+   u = readl(GPIO_IO_CONF(base));
+   if (input)
+   u |= 1  (pin  31);
+   else
+   u = ~(1  (pin  31));
+   writel(u, GPIO_IO_CONF(base));
+
+   u = readl(GPIO_IO_CONF(base));
+}
+
+void __set_level(unsigned pin, int high)
+{
+   u32 base = GPIO_BASE(pin);
+   u32 u;
+
+   u = readl(GPIO_OUT(base));
+   if (high)
+   u |= 1  (pin  31);
+   else
+   u = ~(1  (pin  31));
+   writel(u, GPIO_OUT(base));
+}
+
+void __set_blinking(unsigned pin, int blink)
+{
+   u32 base = GPIO_BASE(pin);
+   u32 u;
+
+   u = readl(GPIO_BLINK_EN(base));
+   if (blink)
+   u |= 1  (pin  31);
+   else
+   u = ~(1  (pin  31));
+   writel(u, GPIO_BLINK_EN(base));
+}
+
+int orion_gpio_is_valid(unsigned pin, int mode)
+{
+   if (pin  GPIO_MAX) {
+   if ((mode  GPIO_INPUT_OK) 
+   !test_bit(pin, gpio_valid_input))
+   goto err_out;
+
+   if ((mode  GPIO_OUTPUT_OK) 
+   !test_bit(pin, gpio_valid_output))
+   goto err_out;
+   return 0;
+   }
+
+err_out:
+   printf(%s: invalid GPIO %d/%d\n, __func__, pin, GPIO_MAX);
+   return 1;
+}
+
+void orion_gpio_set_valid(unsigned pin, int mode)
+{
+   if (mode  GPIO_INPUT_OK)
+   __set_bit(pin, gpio_valid_input);
+   else
+   __clear_bit(pin, gpio_valid_input);
+   if (mode  GPIO_OUTPUT_OK)
+   __set_bit(pin, gpio_valid_output);
+   else
+   __clear_bit(pin, gpio_valid_output);
+}
+
+/*
+ * GENERIC_GPIO primitives.
+ */
+int orion_gpio_direction_input(unsigned pin)
+{
+   if (orion_gpio_is_valid(pin, GPIO_INPUT_OK) != 0)
+   return 

[U-Boot] [PATCH v3 10/10] tools: Add support for Dove to kwboot

2013-01-16 Thread Sebastian Hesselbarth
On Dove kwboot can also be used to boot an u-boot image into RAM.
In contrast to Kirkwood, Dove does not support the UART boot mode
sequence but requires the UART boot mode to be selected through
strap pins. The SolidRun CuBox has a push button to allow uart
boot mode but fails on the boot sequence sent by kwboot.

This patch adds another cmdline option to allow to send a boot
image without the boot sequence and adds support for Dove.

Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Daniel Stodden daniel.stod...@gmail.com
---
Cc: u-boot@lists.denx.de
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Rabeeh Khoury rab...@solid-run.com
Cc: Albert Aribaud albert.u.b...@aribaud.net
Cc: Prafulla Wadaskar prafu...@marvell.com
Cc: Andy Fleming aflem...@gmail.com
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Daniel Stodden daniel.stod...@gmail.com
Cc: Luka Perkov l...@openwrt.org
---
 doc/kwboot.1   |   13 ++---
 tools/Makefile |2 ++
 tools/kwboot.c |   25 +++--
 3 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/doc/kwboot.1 b/doc/kwboot.1
index 25fe69a..ab4551b 100644
--- a/doc/kwboot.1
+++ b/doc/kwboot.1
@@ -1,17 +1,18 @@
-.TH KWBOOT 1 2012-05-19
+.TH KWBOOT 1 2013-01-16
 
 .SH NAME
-kwboot \- Boot Marvell Kirkwood SoCs over a serial link.
+kwboot \- Boot Marvell Kirkwood/Dove SoCs over a serial link.
 .SH SYNOPSIS
 .B kwboot
 .RB [ -b \fIimage\fP ]
+.RB [ -n ]
 .RB [ -p ]
 .RB [ -t ]
 .RB [ -B \fIbaudrate\fP ]
 .RB \fITTY\fP
 .SH DESCRIPTION
 
-The \fBmkimage\fP program boots boards based on Marvell's Kirkwood
+The \fBmkimage\fP program boots boards based on Marvell's Kirkwood/Dove
 platform over their integrated UART. Boot image files will typically
 contain a second stage boot loader, such as U-Boot. The image file
 must conform to Marvell's BootROM firmware image format
@@ -68,6 +69,12 @@ If standard I/O streams connect to a console, this mode will 
terminate
 after receiving 'ctrl-\\' followed by 'c' from console input.
 
 .TP
+.BI \-u
+Disables the UART boot mode sequence for platforms that do not support
+it (e.g. Dove). Usually, the UART boot mode must be selected by pressing
+a push button on power-up.
+
+.TP
 .BI \-B \fIbaudrate\fP
 Adjust the baud rate on \fITTY\fP. Default rate is 115200.
 
diff --git a/tools/Makefile b/tools/Makefile
index 686840a..4816812 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -72,6 +72,7 @@ BIN_FILES-$(CONFIG_SMDK5250) += mksmdk5250spl$(SFX)
 BIN_FILES-$(CONFIG_MX28) += mxsboot$(SFX)
 BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
 BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
+BIN_FILES-$(CONFIG_DOVE) += kwboot$(SFX)
 BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX)
 
 # Source files which exist outside the tools directory
@@ -103,6 +104,7 @@ OBJ_FILES-$(CONFIG_NETCONSOLE) += ncb.o
 NOPED_OBJ_FILES-y += os_support.o
 OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o
 NOPED_OBJ_FILES-y += ublimage.o
+OBJ_FILES-$(CONFIG_DOVE) += kwboot.o
 OBJ_FILES-$(CONFIG_KIRKWOOD) += kwboot.o
 
 # Don't build by default
diff --git a/tools/kwboot.c b/tools/kwboot.c
index e773f01..1e4edb6 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -37,6 +37,10 @@ static unsigned char kwboot_msg_boot[] = {
0xBB, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77
 };
 
+static unsigned char kwboot_msg_none[] = {
+   0x00
+};
+
 #define KWBOOT_MSG_REQ_DELAY   10 /* ms */
 #define KWBOOT_MSG_RSP_TIMEO   50 /* ms */
 
@@ -268,17 +272,21 @@ kwboot_bootmsg(int tty, void *msg)
int rc;
char c;
 
-   kwboot_printv(Sending boot message. Please reboot the target...);
+   kwboot_printv(msg != kwboot_msg_none
+ ? Sending boot message. Please reboot the target...
+ : Sensing target. Please reboot target into UART mode...);
 
do {
rc = tcflush(tty, TCIOFLUSH);
if (rc)
break;
 
-   rc = kwboot_tty_send(tty, msg, 8);
-   if (rc) {
-   usleep(KWBOOT_MSG_REQ_DELAY * 1000);
-   continue;
+   if (msg != kwboot_msg_none) {
+   rc = kwboot_tty_send(tty, msg, 8);
+   if (rc) {
+   usleep(KWBOOT_MSG_REQ_DELAY * 1000);
+   continue;
+   }
}
 
rc = kwboot_tty_recv(tty, c, 1, KWBOOT_MSG_RSP_TIMEO);
@@ -607,6 +615,7 @@ kwboot_usage(FILE *stream, char *progname)
fprintf(stream,   -b image: boot image\n);
fprintf(stream,   -p: patch image to type 0x69 (uart boot)\n);
fprintf(stream, \n);
+   fprintf(stream,   -n: don't send boot message\n);
fprintf(stream,   -t: mini terminal\n);
fprintf(stream, \n);
fprintf(stream,   -B baud: set baud rate\n);
@@ -636,7 +645,7 @@ main(int argc, char **argv)
kwboot_verbose = isatty(STDOUT_FILENO);
 
   

Re: [U-Boot] U-Boot Graphics Library?

2013-01-16 Thread Wolfgang Denk
Dear Simon Glass,

In message capnjgz12pss6sonsumu-vrrxwxs04zb+grqqguknw2dtzbu...@mail.gmail.com 
you wrote:
 
 We are currently using a very rudimentary graphics features attached
 to U-Boot. It can only display bitmap images. We use this in Chromium
 to composite a display for the various screens we need to display in
 U-Boot. Unfortunately the graphics screens get quite large when using
 multiple languages since they are pre-rendered.
 
 Is there any interest in a simply graphics library in U-Boot, that can
 display things on the screen? We already have bitmap support, but
 could perhaps add outline font support (e.g. freetype) as well. This
 might allow display of simple boot menus or booting information. A
 board could create a structure containing a list of things to display
 (text, bitmaps) and pass it to the graphics library for rendering
 using existing functions and the new font support.

This sounds like a nice feature.  Initially.  Then I start wondering
if this really belongs into a boot loader.  Instead of doing fancy
graphics stuff, we should IMO rather focus on booting the OS of your
choice really fast, and let this do the fancy GUIs.  Or?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Go to Heaven for the climate, Hell for the company.- Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [STATUS] v2013.01 released

2013-01-16 Thread Wolfgang Denk
Dear Tom,

In message 50f6a399.1080...@ti.com you wrote:

 It's not automatic for things to be made for the FTP server (I don't
 have access myself, even).

Done now.

Sorry for the delay.

Tom - please feel free to drop me an explicit reminder after each -rc
or full release. Thanks.

Best regards,

Wolfgang Denk

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


Re: [U-Boot] [PATCH 00/12] cmd_sf: Add support for read and write instructions

2013-01-16 Thread Langer Thomas (LQDE RD ST PON SW)
Hello Jagan,

Jagan Teki wrote on 2013-01-16:

 Hi Thomas,
 
 On Thu, Jan 10, 2013 at 8:03 PM, Langer Thomas (LQDE RD ST PON SW)
 thomas.lan...@lantiq.com wrote:
 Hello Jagan,
 
 All these patches are added a support for read and write instruction
 for programming/reading SPI flash.
 
 I have written some weeks ago that I would really appreciate the
 support of dual and quad IO accesses for serial flashes. I just  think,
 this is not an acceptable way to do this.
 
 
 First of all thank you very much for your comments.
 
 It is important to know for all, who do not know the details on the hardware
 requirements of this feature, that these new transfers require a special SPI
 controller! A standard SPI hardware, which is being used on most (maybe all)
 existing boards, cannot use the dual or quad IO features at all!
 
 I am some how unclear about your  concern.
 
 Basically I have added this code that is purely specific to mtd flash
 layer, means
 the entire code is alters the functionalists of flash parts(stmicro,
 spansion, winbond..etc).
 
 whether the respective SOC SPI/QSPI controller driver can support
 these transfer or not, may be
 we couldn't take care at this point of time.
 
 Please comment if I am wrong with my analyses.

You are right, the MTD/SF layer does not know this. But in your board config 
you are
able to set a compile option to enable this feature.

It is an important rule for U-Boot, that new code must be added in a way that 
the code
size is not increased as long as the feature is disabled!

See here (Note 4): http://www.denx.de/wiki/view/U-Boot/Patches#Notes
In the current form, your patches increase the code size for all boards with 
serial flash!

 
 
 And in addition, I still haven't seen any change, which indicates the 
 required
 transfer mode to the SPI layer! How do you tell your SPI driver, which part
 of the transfer should be done in dual or quad mode?
 
 I don't think so, but the SPI/QSPI controller  driver should aware
 respective read/write/erase instructions
 transfer changes those are trying to pass from mtd flash. .
 
 Suppose if the flash used QUAD PP , then the respective h/w SPI/QSPI
 controller must have a support to do the QUAD PP transfers (by adding
 QUAD_PP command transfer).
 
 I think this job is specific to respective h/w driver, they need to
 add these transfers support.
 currently I have used a zynq qspi controller for testing these
 instruction by adding respective
 instructions are this driver.
 
 http://git.xilinx.com/?p=u-boot-
 xlnx.git;a=blob;f=drivers/spi/zynq_qspi.c;h=642241d0fc25d04c06ecbeb5d01ba
 0 6108307c62;hb=master
 

I don't think, this is a good idea! You are mixing the SPI driver with details 
of the flashes!
What happens, if you connect something, which is not a flash, to this SPI 
controller?
And then try to send data, which is detected as qpp or any other quad/dual io 
instruction?
I assume, this will not work!

I would expect the SPI as transparent interface. The SPI driver should provide 
an interface
to specify the use of 1/2/4 signals for a transfer or part of it.
And the flash driver then should use this extended interface to specify the 
required parts,
as it is his job!

For example, with your driver, it would be difficult to support the Macronix 
MX25L12835F,
which allows to enable their QPI mode, which then expects some command, with 
the
same opcode as in None-QPI mode, have to be send in parallel.
And Macronix is also known to use different opcodes than others for some 
instructions.
Does this mean, for supporting this flash, you would have to extend your SPI 
driver first?

I don't expect something like this to be accepted, either in u-boot nor in the 
kernel.
Your driver has some complex handling inside for things, which are only valid 
for
serial flashes! Please don't do this!

Please define and use a clear interface, where the flash driver can tell the 
spi driver,
what kind of transfer should be used (1/2/4) for which phase 
(command/address/data).
In u-boot, I would use the flags argument of the spi_xfer function for this.

I would assume, you will get more flexibility, as your spi driver will get 
smaller and less
complex and it does not need to be changed, if some other flash type should be 
supported.
This will then be part of the specific flash driver! (you see??)

 
 
 Read and Write instruction are implemented as a command line
 arguments for 'sf write' , 'sf read' and 'sf update' commands.
 
 Currently I have added below instructions those are commonly available
 on all flash types.
 pp - Page Program (existing one)
 qpp - Quad-input Page Program
 afr - Array Fast Read (existing one)
 asr - Array Slow Read
 dofr - Dual Output Fast Read
 qofr - Quad Output Fast Read
 diofr - Dual IO Fast Read
 qiofr - Quad IO Fast Read
 
 I have tested mostly of the instruction on real h/w.
 
 This entire implementation will change the current sf framework little
 bit but I thought these changes are worth to add.
 
 This means, 

Re: [U-Boot] [STATUS] v2013.01 released

2013-01-16 Thread Wolfgang Denk
Dear Tom,

In message 20130115221728.GA16104@bill-the-cat you wrote:
 
 U-Boot v2013.01 has been released and uploaded to git.  I expect to see
 it on the ftp server soon.

It's on the FTP server now, and the web page has een updated with the
statistics and release schedule, too.

 The merge window is now open until February 9th and the next release,
 v2013.04 is scheduled for release on April 15th 2013 (the wiki is a bit
 off right now).

No more so :-)

 We'll wait for Wolfgang to run the stats tool, but until then, looking
 over the git log I see:
 - Lots of cleanups everywhere, once again.
 - A big serial cleanup
 - Initial support for running sparse on our codebase
 - Environment cleanups and support for value validation.
 - Further clean-ups and enhancements to our SPL framework and another
   platform now implements support for direct booting of Linux (and
   bypassing full U-Boot).
 - Improved support for a number of platforms on almost all arches that
   we support.

OK, here is the usual statistics summary:

Changes since v2012.10:

  - Processed 1173 csets from 153 developers
  - 30 employers found
  - A total of 86969 lines added, 50126 removed (delta 36843)

Developers with the most changesets
Marek Vasut132 (11.3%)
Simon Glass 93 (7.9%)
Fabio Estevam   58 (4.9%)
Benoît Thébaudeau   50 (4.3%)
Joe Hershberger 42 (3.6%)
Stephen Warren  42 (3.6%)
Rajeshwari Shinde   39 (3.3%)
Lukasz Majewski 39 (3.3%)
Gabe Black  36 (3.1%)
York Sun31 (2.6%)
...

Developers with the most changed lines
Ilya Yanok14700 (11.8%)
Wolfgang Denk 8 (8.9%)
Marek Vasut   10108 (8.1%)
Stefan Roese   9109 (7.3%)
York Sun   5137 (4.1%)
Rajeshwari Shinde  3953 (3.2%)
Albert ARIBAUD 3512 (2.8%)
Simon Glass3002 (2.4%)
Alison Wang2966 (2.4%)
Joe Hershberger2832 (2.3%)
...

Developers with the most lines removed
Wolfgang Denk 11086 (22.1%)
Stefan Roese  7902 (15.8%)
Albert ARIBAUD2113 (4.2%)
Tom Rini  1714 (3.4%)
Paul Gortmaker1539 (3.1%)
Marek Vasut624 (1.2%)
Jens Scharsig (BuS Elektronik)  623 (1.2%)
Holger Brunck   45 (0.1%)
Thomas Chou 40 (0.1%)
Jason Jin   37 (0.1%)
...

Developers with the most signoffs (total 571)
Simon Glass124 (21.7%)
Andy Fleming83 (14.5%)
Minkyu Kang 81 (14.2%)
kyungmin Park   64 (11.2%)
Tom Warren  51 (8.9%)
Tom Rini41 (7.2%)
Anatolij Gustschin   9 (1.6%)
Andreas Bießmann 7 (1.2%)
Stefan Reinauer  7 (1.2%)
Kim Phillips 6 (1.1%)
...

Developers with the most reviews (total 23)
Benoît Thébaudeau9 (39.1%)
Marek Vasut  6 (26.1%)
Tom Rini 2 (8.7%)
Kim Phillips 2 (8.7%)
Lukasz Majewski  2 (8.7%)
Doug Anderson1 (4.3%)
Stephen Warren   1 (4.3%)

Developers with the most test credits (total 44)
Simon Glass 16 (36.4%)
Stephen Warren   8 (18.2%)
Holger Brunck4 (9.1%)
Stefano Babic3 (6.8%)
Marek Vasut  1 (2.3%)
Lukasz Majewski  1 (2.3%)
Andy Fleming 1 (2.3%)
Andreas Bießmann 1 (2.3%)
Stefan Reinauer  1 (2.3%)
Stefan Roese 1 (2.3%)
...

Developers who gave the most tested-by credits (total 44)
Allen Martin12 (27.3%)
Stephen Warren  10 (22.7%)
Stefan Roese 4 (9.1%)
Andy Fleming 3 (6.8%)
Simon Glass  2 (4.5%)
Joe Hershberger  2 (4.5%)
Benoît Thébaudeau2 (4.5%)
Marek Vasut  1 (2.3%)
Lukasz Majewski  1 (2.3%)
Andreas Bießmann 1 (2.3%)
...

Developers with the most report credits (total 5)
Benoît Thébaudeau1 (20.0%)
Dirk Behme   1 (20.0%)
Luka Perkov  1 (20.0%)
Robert Nelson1 (20.0%)
Henrik Nordström 1 (20.0%)

Developers who gave the most report credits (total 5)
Fabio Estevam2 (40.0%)
Stephen Warren   1 (20.0%)
Joe Hershberger  1 (20.0%)
Anatolij Gustschin   1 (20.0%)

Top changeset contributors by employer
(Unknown)  196 (16.7%)
Freescale  190 (16.2%)
Google, Inc.   186 (15.9%)
DENX Software Engineering  172 (14.7%)
Samsung127 (10.8%)
NVidia  57 (4.9%)
ADVANSEE50 (4.3%)
National Instruments42 (3.6%)
Texas Instruments   38 (3.2%)
Boundary Devices27 (2.3%)
...

Top 

Re: [U-Boot] Function prototype conflicts with standalone apps

2013-01-16 Thread Chris Packham
On Thu, Jan 17, 2013 at 1:57 AM, Albert ARIBAUD
albert.u.b...@aribaud.netwrote:

 Hi Chris,

 On Wed, 16 Jan 2013 23:16:07 +1300, Chris Packham
 judge.pack...@gmail.com wrote:

  Hi Albert,
 
  On 01/16/2013 08:25 PM, Albert ARIBAUD (U-Boot) wrote:
   Hi Chris,
  
   On Wed, 16 Jan 2013 17:23:58 +1300, Chris Packham
   judge.pack...@gmail.com wrote:
  
   Hi,
  
   I've just run into something porting an existing out of tree board to
   u-boot 2012.10 but I think it points to a generic issue for standalone
   applications.
  
   Consider the following change
  
   diff --git a/examples/standalone/hello_world.c
   b/examples/standalone/hello_world.c
   index 067c390..d2e6a77 100644
   --- a/examples/standalone/hello_world.c
   +++ b/examples/standalone/hello_world.c
   @@ -24,7 +24,7 @@
#include common.h
#include exports.h
  
   -int hello_world (int argc, char * const argv[])
   +int net_init (int argc, char * const argv[])
{
   int i;
  
   Because I'm not linking with the u-boot object file, I should be able
 to
   use any function name I like in my application as long as it isn't
 one of
   the functions in exports.h (at least in theory). Unfortunately I end
 up
   with the following compiler error
  
 hello_world.c:27: error: conflicting types for ‘net_init’
 uboot/include/net.h:489: error: previous declaration of ‘net_init’
 was
   here
 make[1]: *** [hello_world.o] Error 1
  
   If I replace #include common.h in my app with the first hunk of
 includes
   from the top of common.h  then I can compile just fine.
  
   I was wondering if it made sense to people to have standalone
 applications
   define something like __STANDALONE__ either via CPPFLAGS or in the
 source
   itself and use the presence of that to exclude the majority of
 common.h
   when used in standalone applications. Or alternatively move the
 required
   bits to exports.h.
  
   (long rant ahead. Short answer after end of rant)
 
  Short response: Yep I can live with that by making some changes to my
  standalone application. I just thought it might be cleaner if a minimal
  set of definitions were provided.
 
   [RANT]
  
   Code writers indeed have a right to name any function or other object
   any way they choose... within the constraints of the situation.
  
   Some of these constraints stem from the tools -- you just cannot put an
   ampersand in a C object name, for instance -- and some stem from the
   'agreement' entered into when using a library -- precisely, the
   agreement on the name and semantics of such and such object names.
  
   Here, by including exports.h, you enter an agreement in which
   the object name 'net_init' receives a specific meaning. What you want
   is to benefit from the agreement without abiding by it.
  
   Now this can be changed, technically, as most things are, and a new
   kind of agreement could be devised with fine-grain control on which
   object names would or would not be defined. The question is, *should*
   this be done?
  
   Would you, analogously, suggest that Linux app developers be able to
   opt out of defining fopen() when they #include stdio.h because they
   feel they have a right to define 'char* fopen(float F)' in their code
 if
   they so please? And that it should be done so for just about any
   kernel-exported symbol? I suspect not.
 
  Actually this is my point. The symbols aren't exported. They're just in
  the header file. The kernel solution for this is using __KERNEL__ and
  filtering the exported headers to remove the kernel internals not needed
  by userland. If for some reason I did define a different fopen I'd get a
  link error whether I included stdio or not.

 Ok, so I misunderstood your objective -- my bad. It is not a problem of
 wanting to use a function which is part of the API; it's a problem of
 having to pull in non-API function declarations along with the API ones.

 I still think it's a bad idea to use a homonym of an existing U-Boot
 function, but at least you should not be prevented from doing so if
 the function is not actually in the API.

 But also I still dislike the solution you are suggestiong, because I
 think that the actual problem is not properly stated. Re-reading the
 common.h and exports.h header files, IIUC the actual problem is that
 exports.h depends on some types from common.h but common.h also defines
 some internal U-Boot functions. The problem is that common.h is needed
 for different and incompatible purposes: (public) API on the one hand,
 internal declarations on the other hand.

 Thus, I'd rather have common.h simply split into a header file
 with basic types needed by both public API and internal code and a
 header file defining some internal U-Boot functions, possibly
 #including the shared basic types header file, with no conditional
 involved. New header file names to be chosen wisely.


So perhaps a variation on the patch I sent earlier in this thread. Instead
of moving definitions into 

Re: [U-Boot] [PATCH 1/3] powerpc/p5040: enable NAND boot support

2013-01-16 Thread Scott Wood

On 01/15/2013 08:39:38 PM, Shaohui Xie wrote:

Signed-off-by: Shaohui Xie shaohui@freescale.com
---
 boards.cfg |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index e4b0d44..8cf4936 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -855,6 +855,7 @@ P5020DS_SECURE_BOOT  powerpc  
mpc85xx corenet_ds  freesca
 P5020DS_SPIFLASH	 powerpc mpc85xx  
corenet_ds  freescale  -
P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8
 P5020DS_SRIO_PCIE_BOOT  powerpc mpc85xx  
corenet_ds  freescale  -
P5020DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF8
 P5040DS  powerpc mpc85xx  
corenet_ds  freescale
+P5040DS_NAND		 powerpc mpc85xx  
corenet_ds  freescale  -
P5040DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8
 BSC9131RDB_SPIFLASH  powerpc mpc85xx  
bsc9131rdb  freescale  -
BSC9131RDB:BSC9131RDB,SPIFLASH
 stxgp3   powerpc mpc85xx  
stxgp3  stx
 stxssa   powerpc mpc85xx  
stxssa  stx-   stxssa


This needs more explanation.  What sort of image am I supposed to get  
when I build P5040DS_NAND?  Where is the PBI?


What is the long-term plan for fixing the problem of the environment  
not being available until after relocation?  With SPL we could use  
CONFIG_NAND_ENV_DST (which has some issues, but they're fixable).


It would also be nice to include instructions for configuring the board  
to boot from NAND in a README (Freescale's user manuals often do not  
make this clear, especially for soft configuration).  Also please  
provide a built-in command (or script in the default environment) to  
soft-boot into NAND (or if it already exists, please document it).


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


[U-Boot] [PATCH 0/7] Add support for NVIDIA Tegra114 SoC

2013-01-16 Thread Tom Warren
This patch series adds basic (boot to cmd prompt) support for Tegra114.
This is based on the Tegra30 SPL, which inits the AVP (ARM7TDMI boot proc)
first, then control is passed to the CPU (A15 quad cluster).
It is based on current u-boot-tegra/next.

Future patches will add support/drivers for I2C, SPI, MMC, USB, etc.
The Dalmore (E1611) T114 board is supported initially.

Tom Warren (7):
  Tegra114: Add arch-tegra114 include files
  Tegra114: Add AVP (arm720t) files
  Tegra114: Add CPU (armv7) files
  Tegra114: Add common CPU (shared) files
  Tegra114: Dalmore: Add DT files
  Tegra114: Add generic Tegra114 build support
  Tegra114: Add/enable Dalmore build (T114 reference board)

 arch/arm/cpu/arm720t/tegra-common/cpu.c|   23 +-
 arch/arm/cpu/arm720t/tegra-common/cpu.h|   13 +-
 arch/arm/cpu/arm720t/tegra114/Makefile |   42 +
 arch/arm/cpu/arm720t/tegra114/config.mk|   19 +
 arch/arm/cpu/arm720t/tegra114/cpu.c|  328 ++
 arch/arm/cpu/armv7/tegra114/Makefile   |   40 +
 arch/arm/cpu/armv7/tegra114/config.mk  |   19 +
 arch/arm/cpu/tegra-common/ap.c |8 +-
 arch/arm/cpu/tegra-common/board.c  |   23 +-
 arch/arm/cpu/tegra114-common/Makefile  |   41 +
 arch/arm/cpu/tegra114-common/clock.c   | 1150 
 arch/arm/cpu/tegra114-common/funcmux.c |   63 ++
 arch/arm/cpu/tegra114-common/pinmux.c  |  506 +
 arch/arm/dts/tegra114.dtsi |5 +
 arch/arm/include/asm/arch-tegra/clk_rst.h  |   61 +-
 arch/arm/include/asm/arch-tegra/gp_padctrl.h   |1 +
 arch/arm/include/asm/arch-tegra/pmc.h  |   12 +
 arch/arm/include/asm/arch-tegra/tegra.h|3 +-
 arch/arm/include/asm/arch-tegra114/clock-tables.h  |  402 +++
 arch/arm/include/asm/arch-tegra114/clock.h |   24 +
 arch/arm/include/asm/arch-tegra114/flow.h  |   35 +
 arch/arm/include/asm/arch-tegra114/funcmux.h   |   31 +
 arch/arm/include/asm/arch-tegra114/gp_padctrl.h|   59 +
 arch/arm/include/asm/arch-tegra114/gpio.h  |  304 ++
 arch/arm/include/asm/arch-tegra114/hardware.h  |   22 +
 arch/arm/include/asm/arch-tegra114/pinmux.h|  618 +++
 arch/arm/include/asm/arch-tegra114/pmu.h   |   23 +
 arch/arm/include/asm/arch-tegra114/spl.h   |   22 +
 arch/arm/include/asm/arch-tegra114/tegra.h |   26 +
 board/nvidia/common/board.c|2 +-
 board/nvidia/dalmore/Makefile  |   44 +
 board/nvidia/dalmore/dalmore.c |   39 +
 board/nvidia/dalmore/pinmux-config-dalmore.h   |  249 +
 board/nvidia/dts/tegra114-dalmore.dts  |   13 +
 boards.cfg |1 +
 include/configs/dalmore.h  |   50 +
 include/configs/tegra114-common.h  |   89 ++
 37 files changed, 4360 insertions(+), 39 deletions(-)
 create mode 100644 arch/arm/cpu/arm720t/tegra114/Makefile
 create mode 100644 arch/arm/cpu/arm720t/tegra114/config.mk
 create mode 100644 arch/arm/cpu/arm720t/tegra114/cpu.c
 create mode 100644 arch/arm/cpu/armv7/tegra114/Makefile
 create mode 100644 arch/arm/cpu/armv7/tegra114/config.mk
 create mode 100644 arch/arm/cpu/tegra114-common/Makefile
 create mode 100644 arch/arm/cpu/tegra114-common/clock.c
 create mode 100644 arch/arm/cpu/tegra114-common/funcmux.c
 create mode 100644 arch/arm/cpu/tegra114-common/pinmux.c
 create mode 100644 arch/arm/dts/tegra114.dtsi
 create mode 100644 arch/arm/include/asm/arch-tegra114/clock-tables.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/clock.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/flow.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/funcmux.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/gp_padctrl.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/gpio.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/hardware.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/pinmux.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/spl.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/tegra.h
 create mode 100644 board/nvidia/dalmore/Makefile
 create mode 100644 board/nvidia/dalmore/dalmore.c
 create mode 100644 board/nvidia/dalmore/pinmux-config-dalmore.h
 create mode 100644 board/nvidia/dts/tegra114-dalmore.dts
 create mode 100644 include/configs/dalmore.h
 create mode 100644 include/configs/tegra114-common.h

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


[U-Boot] [PATCH 2/7] Tegra114: Add AVP (arm720t) files

2013-01-16 Thread Tom Warren
This provides SPL support for T114 boards - AVP early init, plus
CPU (A15) init/jump to main U-Boot.

Signed-off-by: Tom Warren twar...@nvidia.com
---
 arch/arm/cpu/arm720t/tegra-common/cpu.c |   23 ++-
 arch/arm/cpu/arm720t/tegra-common/cpu.h |   13 +-
 arch/arm/cpu/arm720t/tegra114/Makefile  |   42 
 arch/arm/cpu/arm720t/tegra114/config.mk |   19 ++
 arch/arm/cpu/arm720t/tegra114/cpu.c |  328 +++
 5 files changed, 411 insertions(+), 14 deletions(-)
 create mode 100644 arch/arm/cpu/arm720t/tegra114/Makefile
 create mode 100644 arch/arm/cpu/arm720t/tegra114/config.mk
 create mode 100644 arch/arm/cpu/arm720t/tegra114/cpu.c

diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c 
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index 693d584..846163c 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -40,7 +40,7 @@ enum tegra_family_t get_family(void)
chip_id = reg  8;
chip_id = 0xff;
debug(  tegra_get_family: chip_id = %x\n, chip_id);
-   if (chip_id == 0x30)
+   if (chip_id = 0x30)
return TEGRA_FAMILY_T3x;
else
return TEGRA_FAMILY_T2x;
@@ -56,6 +56,7 @@ int get_num_cpus(void)
  */
 struct clk_pll_table tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
/* T20: 1 GHz */
+   /*  n,  m, p, cpcon */
{{ 1000, 13, 0, 12},/* OSC 13M */
 { 625,  12, 0, 8}, /* OSC 19.2M */
 { 1000, 12, 0, 12},/* OSC 12M */
@@ -76,11 +77,11 @@ struct clk_pll_table 
tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
 { 700, 13, 0, 8},
},
 
-   /* TEGRA_SOC2_SLOW: 312 MHz */
-   {{ 312, 13, 0, 12}, /* OSC 13M */
-{ 260, 16, 0, 8},  /* OSC 19.2M */
-{ 312, 12, 0, 12}, /* OSC 12M */
-{ 312, 26, 0, 12}, /* OSC 26M */
+   /* T114: 1.4 GHz */
+   {{ 862, 8, 0, 8},
+{ 583, 8, 0, 4},
+{ 696, 12, 0, 8},
+{ 700, 13, 0, 8},
},
 };
 
@@ -166,8 +167,8 @@ void init_pllx(void)
sel = tegra_pll_x_table[chip_type][osc];
pllx_set_rate(pll, sel-n, sel-m, sel-p, sel-cpcon);
 
-   /* adjust PLLP_out1-4 on T30 */
-   if (chip_type == TEGRA_SOC_T30) {
+   /* adjust PLLP_out1-4 on T30/T114 */
+   if (chip_type = TEGRA_SOC_T30) {
debug(  init_pllx: adjusting PLLP out freqs\n);
adjust_pllp_out_freqs();
}
@@ -203,7 +204,7 @@ void enable_cpu_clock(int enable)
 */
clk = readl(clkrst-crc_clk_cpu_cmplx);
clk |= 1  CPU1_CLK_STP_SHIFT;
-#if defined(CONFIG_TEGRA30)
+#if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)
clk |= 1  CPU2_CLK_STP_SHIFT;
clk |= 1  CPU3_CLK_STP_SHIFT;
 #endif
@@ -308,7 +309,7 @@ void clock_enable_coresight(int enable)
 * Clock divider request for 204MHz would setup CSITE clock as
 * 144MHz for PLLP base 216MHz and 204MHz for PLLP base 408MHz
 */
-   if (tegra_get_chip_type() == TEGRA_SOC_T30)
+   if (tegra_get_chip_type() = TEGRA_SOC_T30)
src = CLK_DIVIDER(NVBL_PLLP_KHZ, 204000);
else
src = CLK_DIVIDER(NVBL_PLLP_KHZ, 144000);
@@ -318,7 +319,7 @@ void clock_enable_coresight(int enable)
rst = CORESIGHT_UNLOCK;
writel(rst, CSITE_CPU_DBG0_LAR);
writel(rst, CSITE_CPU_DBG1_LAR);
-#if defined(CONFIG_TEGRA30)
+#if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)
writel(rst, CSITE_CPU_DBG2_LAR);
writel(rst, CSITE_CPU_DBG3_LAR);
 #endif
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.h 
b/arch/arm/cpu/arm720t/tegra-common/cpu.h
index 3e2ea3a..45b346d 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.h
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.h
@@ -22,14 +22,21 @@
  */
 #include asm/types.h
 
+#ifndef TRUE
+#define TRUE   1
+#endif
+#ifndef FALSE
+#define FALSE  0
+#endif
+
 /* Stabilization delays, in usec */
 #define PLL_STABILIZATION_DELAY (300)
 #define IO_STABILIZATION_DELAY (1000)
 
-#if defined(CONFIG_TEGRA30)
-#define NVBL_PLLP_KHZ  (408000)
-#else  /* Tegra20 */
+#if defined(CONFIG_TEGRA20)
 #define NVBL_PLLP_KHZ  (216000)
+#else  /* Tegra30/Tegra114 */
+#define NVBL_PLLP_KHZ  (408000)
 #endif
 
 #define PLLX_ENABLED   (1  30)
diff --git a/arch/arm/cpu/arm720t/tegra114/Makefile 
b/arch/arm/cpu/arm720t/tegra114/Makefile
new file mode 100644
index 000..157d85a
--- /dev/null
+++ b/arch/arm/cpu/arm720t/tegra114/Makefile
@@ -0,0 +1,42 @@
+#
+# Copyright (c) 2010-2012, NVIDIA CORPORATION.  All rights reserved.
+#
+# (C) Copyright 2000-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software 

[U-Boot] [PATCH 3/7] Tegra114: Add CPU (armv7) files

2013-01-16 Thread Tom Warren
These files are for code that runs on the CPU (A15) on T114 boards.
At this time, there is no A15-specific code here.
As T114-specific run-time code is added, it'll go here.

Signed-off-by: Tom Warren twar...@nvidia.com
---
 arch/arm/cpu/armv7/tegra114/Makefile  |   40 +
 arch/arm/cpu/armv7/tegra114/config.mk |   19 +++
 2 files changed, 59 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/tegra114/Makefile
 create mode 100644 arch/arm/cpu/armv7/tegra114/config.mk

diff --git a/arch/arm/cpu/armv7/tegra114/Makefile 
b/arch/arm/cpu/armv7/tegra114/Makefile
new file mode 100644
index 000..04adb52
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra114/Makefile
@@ -0,0 +1,40 @@
+#
+# Copyright (c) 2010-2012, NVIDIA CORPORATION.  All rights reserved.
+#
+# (C) Copyright 2000-2003
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope 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, see http://www.gnu.org/licenses/.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(SOC).o
+
+COBJS  := $(COBJS-y)
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+all:   $(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/armv7/tegra114/config.mk 
b/arch/arm/cpu/armv7/tegra114/config.mk
new file mode 100644
index 000..35ed364
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra114/config.mk
@@ -0,0 +1,19 @@
+#
+# Copyright (c) 2010-2012, NVIDIA CORPORATION.  All rights reserved.
+#
+# (C) Copyright 2002
+# Gary Jennejohn, DENX Software Engineering, ga...@denx.de
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope 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, see http://www.gnu.org/licenses/.
+#
+CONFIG_ARCH_DEVICE_TREE := tegra114
-- 
1.7.0.4

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


[U-Boot] [PATCH 1/7] Tegra114: Add arch-tegra114 include files

2013-01-16 Thread Tom Warren
Common Tegra files are in arch-tegra, shared between T20/T30/T114.
Tegra114-specific headers are in arch-tegra114. Note that some of
these will be filled in as more T114 support is added (drivers,
WB/LP0 support, etc.).

Signed-off-by: Tom Warren twar...@nvidia.com
---
 arch/arm/include/asm/arch-tegra/clk_rst.h |   61 ++-
 arch/arm/include/asm/arch-tegra/gp_padctrl.h  |1 +
 arch/arm/include/asm/arch-tegra/pmc.h |   12 +
 arch/arm/include/asm/arch-tegra/tegra.h   |3 +-
 arch/arm/include/asm/arch-tegra114/clock-tables.h |  402 +
 arch/arm/include/asm/arch-tegra114/clock.h|   24 +
 arch/arm/include/asm/arch-tegra114/flow.h |   35 ++
 arch/arm/include/asm/arch-tegra114/funcmux.h  |   31 +
 arch/arm/include/asm/arch-tegra114/gp_padctrl.h   |   59 ++
 arch/arm/include/asm/arch-tegra114/gpio.h |  304 ++
 arch/arm/include/asm/arch-tegra114/hardware.h |   22 +
 arch/arm/include/asm/arch-tegra114/pinmux.h   |  618 +
 arch/arm/include/asm/arch-tegra114/pmu.h  |   23 +
 arch/arm/include/asm/arch-tegra114/spl.h  |   22 +
 arch/arm/include/asm/arch-tegra114/tegra.h|   26 +
 15 files changed, 1637 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-tegra114/clock-tables.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/clock.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/flow.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/funcmux.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/gp_padctrl.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/gpio.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/hardware.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/pinmux.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/spl.h
 create mode 100644 arch/arm/include/asm/arch-tegra114/tegra.h

diff --git a/arch/arm/include/asm/arch-tegra/clk_rst.h 
b/arch/arm/include/asm/arch-tegra/clk_rst.h
index 6a6e507..f3aa3ed 100644
--- a/arch/arm/include/asm/arch-tegra/clk_rst.h
+++ b/arch/arm/include/asm/arch-tegra/clk_rst.h
@@ -121,16 +121,43 @@ struct clk_rst_ctlr {
uint crc_clk_cpug_cmplx;/* _CLK_CPUG_CMPLX_0,   0x378 */
uint crc_clk_cpulp_cmplx;   /* _CLK_CPULP_CMPLX_0,  0x37C */
uint crc_cpu_softrst_ctrl;  /* _CPU_SOFTRST_CTRL_0, 0x380 */
-   uint crc_reserved33[11];/* _reserved_33,0x384-3ac */
+   uint crc_cpu_softrst_ctrl1; /* _CPU_SOFTRST_CTR1L_0,0x384 */
+   uint crc_cpu_softrst_ctrl2; /* _CPU_SOFTRST_CTRL2_0,0x388 */
+   uint crc_reserved33[9]; /* _reserved_33,0x38c-3ac */
uint crc_clk_src_vw[TEGRA_CLK_SOURCES_VW]; /* _G3D2_0..., 0x3b0-0x42c */
/* _RST_DEV_V/W_SET_0 0x430 ~ 0x43c */
struct clk_set_clr crc_rst_dev_ex_vw[TEGRA_CLK_REGS_VW];
/* _CLK_ENB_V/W_CLR_0 0x440 ~ 0x44c */
struct clk_set_clr crc_clk_enb_ex_vw[TEGRA_CLK_REGS_VW];
-   uint crc_reserved40[12];/* _reserved_40,0x450-47C */
-   uint crc_pll_cfg0;  /* _PLL_CFG0_0, 0x480 */
-   uint crc_pll_cfg1;  /* _PLL_CFG1_0, 0x484 */
-   uint crc_pll_cfg2;  /* _PLL_CFG2_0, 0x488 */
+   /* Additional (T114) registers */
+   uint crc_rst_cpug_cmplx_set;/* _RST_CPUG_CMPLX_SET_0,  0x450 */
+   uint crc_rst_cpug_cmplx_clr;/* _RST_CPUG_CMPLX_CLR_0,  0x454 */
+   uint crc_rst_cpulp_cmplx_set;   /* _RST_CPULP_CMPLX_SET_0, 0x458 */
+   uint crc_rst_cpulp_cmplx_clr;   /* _RST_CPULP_CMPLX_CLR_0, 0x45C */
+   uint crc_clk_cpug_cmplx_set;/* _CLK_CPUG_CMPLX_SET_0,  0x460 */
+   uint crc_clk_cpug_cmplx_clr;/* _CLK_CPUG_CMPLX_CLR_0,  0x464 */
+   uint crc_clk_cpulp_cmplx_set;   /* _CLK_CPULP_CMPLX_SET_0, 0x468 */
+   uint crc_clk_cpulp_cmplx_clr;   /* _CLK_CPULP_CMPLX_CLR_0, 0x46C */
+   uint crc_cpu_cmplx_status;  /* _CPU_CMPLX_STATUS_0,0x470 */
+   uint crc_reserved40[1]; /* _reserved_40,0x474 */
+   uint crc_intstatus; /* __INTSTATUS_0,   0x478 */
+   uint crc_intmask;   /* __INTMASK_0, 0x47C */
+   uint crc_utmip_pll_cfg0;/* _UTMIP_PLL_CFG0_0,   0x480 */
+   uint crc_utmip_pll_cfg1;/* _UTMIP_PLL_CFG1_0,   0x484 */
+   uint crc_utmip_pll_cfg2;/* _UTMIP_PLL_CFG2_0,   0x488 */
+
+   uint crc_plle_aux;  /* _PLLE_AUX_0, 0x48C */
+   uint crc_sata_pll_cfg0; /* _SATA_PLL_CFG0_0,0x490 */
+   uint crc_sata_pll_cfg1; /* _SATA_PLL_CFG1_0,0x494 */
+   uint crc_pcie_pll_cfg0; /* _PCIE_PLL_CFG0_0,0x498 */
+
+   uint crc_prog_audio_dly_clk;/* _PROG_AUDIO_DLY_CLK_0, 0x49C */
+   uint crc_audio_sync_clk_i2s0;   /* _AUDIO_SYNC_CLK_I2S0_0, 0x4A0 */
+ 

[U-Boot] [PATCH 5/7] Tegra114: Dalmore: Add DT files

2013-01-16 Thread Tom Warren
These are stripped down for bringup, They'll be filled out later
to match-up with the kernel DT contents, and/or as devices are
brought up (mmc, usb, spi, etc.).

Signed-off-by: Tom Warren twar...@nvidia.com
---
 arch/arm/dts/tegra114.dtsi|5 +
 board/nvidia/dts/tegra114-dalmore.dts |   13 +
 2 files changed, 18 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/dts/tegra114.dtsi
 create mode 100644 board/nvidia/dts/tegra114-dalmore.dts

diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
new file mode 100644
index 000..d06cd12
--- /dev/null
+++ b/arch/arm/dts/tegra114.dtsi
@@ -0,0 +1,5 @@
+/include/ skeleton.dtsi
+
+/ {
+   compatible = nvidia,tegra114;
+};
diff --git a/board/nvidia/dts/tegra114-dalmore.dts 
b/board/nvidia/dts/tegra114-dalmore.dts
new file mode 100644
index 000..d108001
--- /dev/null
+++ b/board/nvidia/dts/tegra114-dalmore.dts
@@ -0,0 +1,13 @@
+/dts-v1/;
+
+/include/ ARCH_CPU_DTS
+
+/ {
+   model = NVIDIA Dalmore;
+   compatible = nvidia,dalmore, nvidia,tegra114;
+
+   memory {
+   device_type = memory;
+   reg = 0x8000 0x4000;
+   };
+};
-- 
1.7.0.4

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


[U-Boot] [PATCH 7/7] Tegra114: Add/enable Dalmore build (T114 reference board)

2013-01-16 Thread Tom Warren
This build is stripped down. It boots to the command prompt.
GPIO is the only peripheral supported. Others TBD.

Signed-off-by: Tom Warren twar...@nvidia.com
---
 board/nvidia/dalmore/Makefile|   44 +
 board/nvidia/dalmore/dalmore.c   |   39 
 board/nvidia/dalmore/pinmux-config-dalmore.h |  249 ++
 boards.cfg   |1 +
 include/configs/dalmore.h|   50 +
 include/configs/tegra114-common.h|   89 +
 6 files changed, 472 insertions(+), 0 deletions(-)
 create mode 100644 board/nvidia/dalmore/Makefile
 create mode 100644 board/nvidia/dalmore/dalmore.c
 create mode 100644 board/nvidia/dalmore/pinmux-config-dalmore.h
 create mode 100644 include/configs/dalmore.h
 create mode 100644 include/configs/tegra114-common.h

diff --git a/board/nvidia/dalmore/Makefile b/board/nvidia/dalmore/Makefile
new file mode 100644
index 000..913f1ce
--- /dev/null
+++ b/board/nvidia/dalmore/Makefile
@@ -0,0 +1,44 @@
+#
+#  (C) Copyright 2010-2012
+#  NVIDIA Corporation www.nvidia.com
+#
+#
+#  See file CREDITS for list of people who contributed to this
+#  project.
+#
+#  This program is free software; you can redistribute it and/or
+#  modify it under the terms of the GNU General Public License as
+#  published by the Free Software Foundation; either version 2 of
+#  the License, or (at your option) any later version.
+#
+#  This program is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+#  GNU General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with this program; if not, write to the Free Software
+#  Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+#  MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS  := $(BOARD).o
+
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
new file mode 100644
index 000..f17c891
--- /dev/null
+++ b/board/nvidia/dalmore/dalmore.c
@@ -0,0 +1,39 @@
+/*
+ *  (C) Copyright 2010-2012
+ *  NVIDIA Corporation www.nvidia.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/pinmux.h
+#include pinmux-config-dalmore.h
+
+/*
+ * Routine: pinmux_init
+ * Description: Do individual peripheral pinmux configs
+ */
+void pinmux_init(void)
+{
+   pinmux_config_table(tegra3_pinmux_common,
+   ARRAY_SIZE(tegra3_pinmux_common));
+
+   pinmux_config_table(unused_pins_lowpower,
+   ARRAY_SIZE(unused_pins_lowpower));
+}
diff --git a/board/nvidia/dalmore/pinmux-config-dalmore.h 
b/board/nvidia/dalmore/pinmux-config-dalmore.h
new file mode 100644
index 000..d29a56a
--- /dev/null
+++ b/board/nvidia/dalmore/pinmux-config-dalmore.h
@@ -0,0 +1,249 @@
+/*
+ * Copyright (c) 2010-2012, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef _PINMUX_CONFIG_DALMORE_H_
+#define _PINMUX_CONFIG_DALMORE_H_
+
+#define DEFAULT_PINMUX(_pingroup, _mux, _pull, _tri, _io)   \
+   {   

[U-Boot] [PATCH 6/7] Tegra114: Add generic Tegra114 build support

2013-01-16 Thread Tom Warren
This patch adds basic Tegra114 (T114) build support - no specific
board is targeted.

Signed-off-by: Tom Warren twar...@nvidia.com
---
 board/nvidia/common/board.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index a4af539..e986fcf 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -196,7 +196,7 @@ void gpio_early_init(void) __attribute__((weak, 
alias(__gpio_early_init)));
 
 int board_early_init_f(void)
 {
-#if defined(CONFIG_TEGRA30)
+#if !defined(CONFIG_TEGRA20)
pinmux_init();
 #endif
board_init_uart_f();
-- 
1.7.0.4

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


Re: [U-Boot] U-Boot Graphics Library?

2013-01-16 Thread Simon Glass
Hi Wolfgang,

On Wed, Jan 16, 2013 at 11:46 AM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon Glass,

 In message 
 capnjgz12pss6sonsumu-vrrxwxs04zb+grqqguknw2dtzbu...@mail.gmail.com you 
 wrote:

 We are currently using a very rudimentary graphics features attached
 to U-Boot. It can only display bitmap images. We use this in Chromium
 to composite a display for the various screens we need to display in
 U-Boot. Unfortunately the graphics screens get quite large when using
 multiple languages since they are pre-rendered.

 Is there any interest in a simply graphics library in U-Boot, that can
 display things on the screen? We already have bitmap support, but
 could perhaps add outline font support (e.g. freetype) as well. This
 might allow display of simple boot menus or booting information. A
 board could create a structure containing a list of things to display
 (text, bitmaps) and pass it to the graphics library for rendering
 using existing functions and the new font support.

 This sounds like a nice feature.  Initially.  Then I start wondering
 if this really belongs into a boot loader.  Instead of doing fancy
 graphics stuff, we should IMO rather focus on booting the OS of your
 choice really fast, and let this do the fancy GUIs.  Or?


The problem is that a major purpose of the GUIs is to allow installing
an OS from a USB stick/SD card, since the OS may have become corrupted
and unbootable. We have looked at keeping around a separate OS image
for this (e.g. in an available disk partition), but so far that hasn't
proved practical since that itself can be fairly easily overwritten
and we then have a doorstop.

The less fancy, the better, but consumers have certain expectations
that force us to make some efforts...there is already a single font in
U-Boot, but it's not good enough for multi-language pretty displays
unfortunately.

Regards,
Simon

 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 Go to Heaven for the climate, Hell for the company.- Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] mtd: resync with Linux-3.7.1

2013-01-16 Thread Scott Wood

On 01/14/2013 07:46:50 AM, Sergey Lapin wrote:

This patch is essentially an update of u-boot MTD subsystem to
the state of Linux-3.7.1 with exclusion of some bits:

- the update is concentrated on NAND, no onenand or CFI/NOR/SPI
flashes interfaces are updated EXCEPT for API changes.

- new large NAND chips support is there, though some updates
have got in Linux-3.8.-rc1, (which will follow on top of this patch).

To produce this update I used tag v3.7.1 of linux-stable repository.

The update was made using application of relevant patches,
with changes relevant to U-Boot-only stuff sticked together
to keep bisectability. Then all changes were grouped together
to this patch.

Signed-off-by: Sergey Lapin sla...@ossfans.org
---


Applying: mtd: resync with Linux-3.7.1
/home/scott/fsl/git/u-boot/upstream/.git/rebase-apply/patch:4292: space  
before tab in indent.

chip-ecc.strength =
/home/scott/fsl/git/u-boot/upstream/.git/rebase-apply/patch:835: new  
blank line at EOF.

+
/home/scott/fsl/git/u-boot/upstream/.git/rebase-apply/patch:6011: new  
blank line at EOF.

+
/home/scott/fsl/git/u-boot/upstream/.git/rebase-apply/patch:7970: new  
blank line at EOF.

+
warning: 4 lines add whitespace errors.

Are these whitespace errors in Linux?

I tried booting on P2020RDB-PC_NAND, and got this:


L2:512 KB already enabled, moving to 0xf8f8
NAND:  BUG: failure at nand_base.c:3214/nand_scan_tail()!
BUG!
### ERROR ### Please RESET the board ###


It boots fine without this patch.  nand_base.c:3214 is complaining about
missing ecc.strength.  You need to update existing U-Boot drivers for  
new

API so that nothing breaks.  Ask maintainers of particular drivers for
help if necessary.

You'll probably need to go through the various NAND patches between 3.0
and 3.7.1 looking for API changes, and make sure that they're all
accounted for, beyond just making things build.

diff --git a/board/ait/cam_enc_4xx/cam_enc_4xx.c  
b/board/ait/cam_enc_4xx/cam_enc_4xx.c

index 32b28f9..2a0c31c 100644
--- a/board/ait/cam_enc_4xx/cam_enc_4xx.c
+++ b/board/ait/cam_enc_4xx/cam_enc_4xx.c
@@ -120,7 +120,7 @@ int board_eth_init(bd_t *bis)
 #ifdef CONFIG_NAND_DAVINCI
 static int
 davinci_std_read_page_syndrome(struct mtd_info *mtd, struct  
nand_chip *chip,

-  uint8_t *buf, int page)
+   uint8_t *buf, int oob_required, int  
page)

 {
struct nand_chip *this = mtd-priv;
int i, eccsize = chip-ecc.size;
@@ -167,8 +167,9 @@ davinci_std_read_page_syndrome(struct mtd_info  
*mtd, struct nand_chip *chip,

return 0;
 }


We really should not be having NAND driver code (stuff that interacts
with the NAND API; not hardware setup) outside of drivers/mtd/nand.


diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 543c845..99f39fc 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -25,7 +25,9 @@ include $(TOPDIR)/config.mk

 LIB:= $(obj)libmtd.o

-COBJS-$(CONFIG_MTD_DEVICE) += mtdcore.o
+ifneq (,$(findstring  
y,$(CONFIG_MTD_DEVICE)$(CONFIG_CMD_NAND)$(CONFIG_CMD_ONENAND)))

+COBJS-y += mtdcore.o
+endif


Please just require users of CONFIG_CMD_NAND or CONFIG_CMD_ONENAND to
also select CONFIG_MTD_DEVICE, if it's not going to be practical to do
without it -- and remove the #ifdef CONFIG_MTD_DEVICE from nand.c.

Could you explain why it's no longer practical to have NAND by itself?

diff --git a/drivers/mtd/nand/diskonchip.c  
b/drivers/mtd/nand/diskonchip.c

index edf3a09..104d97f 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -134,7 +134,7 @@ static struct rs_control *rs_decoder;

 /*
  * The HW decoder in the DoC ASIC's provides us a error syndrome,
- * which we must convert to a standard syndrom usable by the generic
+ * which we must convert to a standard syndrome usable by the generic
  * Reed-Solomon library code.
  *
  * Fabrice Bellard figured this out in the old docecc code. I added


This file should just go away, as nobody has stepped up to fix and use
it.


 #ifdef CONFIG_MTD_DEBUG
+#define pr_debug(args...)  MTDDEBUG(MTD_DEBUG_LEVEL0, args)
 #define MTDDEBUG(n, args...)   \
do {\
if (n = CONFIG_MTD_DEBUG_VERBOSE)   \
printk(KERN_INFO args); \
} while(0)
 #else /* CONFIG_MTD_DEBUG */
+#define pr_debug(args...)
 #define MTDDEBUG(n, args...)   \
do {\
if (0)  \
printk(KERN_INFO args); \
} while(0)
 #endif /* CONFIG_MTD_DEBUG */


If you define pr_debug() to be absolutely nothing, you won't catch  
errors

until CONFIG_MTD_DEBUG is actually turned on.  That's why MTDDEBUG does
the if (0) thing.

pr_debug() should not be defined in terms of CONFIG_MTD_DEBUG.  What if
this header gets included by some other 

Re: [U-Boot] [PATCH 1/7] Tegra114: Add arch-tegra114 include files

2013-01-16 Thread Stephen Warren
On 01/16/2013 02:14 PM, Tom Warren wrote:
 Common Tegra files are in arch-tegra, shared between T20/T30/T114.
 Tegra114-specific headers are in arch-tegra114. Note that some of
 these will be filled in as more T114 support is added (drivers,
 WB/LP0 support, etc.).

 diff --git a/arch/arm/include/asm/arch-tegra114/gpio.h 
 b/arch/arm/include/asm/arch-tegra114/gpio.h

I think the Tegra30 and Tegra114 GPIO controllers are basically
identical. Can this file be shared at all?

 diff --git a/arch/arm/include/asm/arch-tegra114/tegra.h 
 b/arch/arm/include/asm/arch-tegra114/tegra.h

 +#define BCT_ODMDATA_OFFSET   6116/* 12 bytes from end of BCT */

That's the Tegra30 value. I'm pretty sure the Tegra30 and Tegra114 BCTs
are laid out very differently, so this value isn't valid.

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


Re: [U-Boot] [RFC PATCH 1/2] Initial net6.h

2013-01-16 Thread Kim Phillips
On Wed, 16 Jan 2013 23:01:26 +1300
Chris Packham judge.pack...@gmail.com wrote:

 +typedef union ip6addr_t {
 + __u8u6_addr8[16];
 + __u16   u6_addr16[8];

__be16, for use with sparse.

 + __u32   u6_addr32[4];

__be32

 +} IP6addr_t;

Kim

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


Re: [U-Boot] U-Boot Graphics Library?

2013-01-16 Thread Wolfgang Denk
Dear Simon Glass,

In message CAPnjgZ3rNhvL98JEOPV=90u-Wr3iEqs8QgqYaz=boohrfrj...@mail.gmail.com 
you wrote:
 
 The problem is that a major purpose of the GUIs is to allow installing
 an OS from a USB stick/SD card, since the OS may have become corrupted
 and unbootable. We have looked at keeping around a separate OS image
 for this (e.g. in an available disk partition), but so far that hasn't
 proved practical since that itself can be fairly easily overwritten
 and we then have a doorstop.
 
 The less fancy, the better, but consumers have certain expectations
 that force us to make some efforts...there is already a single font in
 U-Boot, but it's not good enough for multi-language pretty displays
 unfortunately.

Why don't you load and start a small recovery system from the USB
stick then?  I don't see why you need a GUI to do that.  This could be
mostly made automatic.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Brain: an apparatus with which we think we think.- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/7] Tegra114: Add arch-tegra114 include files

2013-01-16 Thread Allen Martin
On Wed, Jan 16, 2013 at 01:14:02PM -0800, Tom Warren wrote:
 Common Tegra files are in arch-tegra, shared between T20/T30/T114.
 Tegra114-specific headers are in arch-tegra114. Note that some of
 these will be filled in as more T114 support is added (drivers,
 WB/LP0 support, etc.).
 
 Signed-off-by: Tom Warren twar...@nvidia.com
 ---

 +#if defined(CONFIG_TEGRA20)
  #define OSC_FREQ_SHIFT 30
  #define OSC_FREQ_MASK  (3U  OSC_FREQ_SHIFT)
 +#else  /* Tegra30, Tegra114 */
 +#define OSC_FREQ_SHIFT 28
 +#define OSC_FREQ_MASK  (0xF  OSC_FREQ_SHIFT)
 +#endif

Can this be a new define instead of a #ifdef?  That makes it easier in
the future to make a single u-boot to boot on all tegras.


 index 953936c..670745f 100644
 --- a/arch/arm/include/asm/arch-tegra/tegra.h
 +++ b/arch/arm/include/asm/arch-tegra/tegra.h
 @@ -73,6 +73,7 @@ enum {
 SKU_ID_AP25E= 0x1b,
 SKU_ID_T25E = 0x1c,
 SKU_ID_T30  = 0x81, /* Cardhu value */
 +   SKU_ID_T114 = 0x00, /* Dalmore value */
  };

Is that really the proper SKU id?  Or is it just unprogrammed on the
early chips?



 diff --git a/arch/arm/include/asm/arch-tegra114/clock.h 
 b/arch/arm/include/asm/arch-tegra114/clock.h
 new file mode 100644
 index 000..9e56f57
 --- /dev/null
 +++ b/arch/arm/include/asm/arch-tegra114/clock.h
 @@ -0,0 +1,24 @@
 +/*
 + * Copyright (c) 2010-2012, NVIDIA CORPORATION.  All rights reserved.

2013, here and all new files

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


Re: [U-Boot] [PATCH 2/7] Tegra114: Add AVP (arm720t) files

2013-01-16 Thread Stephen Warren
On 01/16/2013 02:14 PM, Tom Warren wrote:
 This provides SPL support for T114 boards - AVP early init, plus
 CPU (A15) init/jump to main U-Boot.

 diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c 
 b/arch/arm/cpu/arm720t/tegra-common/cpu.c

 - if (chip_id == 0x30)
 + if (chip_id = 0x30)
   return TEGRA_FAMILY_T3x;
   else
   return TEGRA_FAMILY_T2x;

Shouldn't that comparison use CHIPID_TEGRA30?

Shouldn't there be a TEGRA_FAMILY_T11x for Tegra114; anything that cares
about =Tegra30 can compare the family with = not ==.

Hmm. It seems the only use of the FAMILY value is get_num_cpus() right
below; why not have that just switch on the same chip_id variable that
everything else uses?

 diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.h 
 b/arch/arm/cpu/arm720t/tegra-common/cpu.h

 +#ifndef TRUE
 +#define TRUE 1
 +#endif
 +#ifndef FALSE
 +#define FALSE0
 +#endif

Surely those are in a standard header somewhere; we shouldn't create yet
another duplicate of them.

 diff --git a/arch/arm/cpu/arm720t/tegra114/cpu.c 
 b/arch/arm/cpu/arm720t/tegra114/cpu.c

 +static int is_partition_powered(u32 mask)

 + reg = readl(pmc-pmc_pwrgate_status);
 + if ((reg  mask) == mask)
 + return TRUE;
 +
 + return FALSE;

The last 4 lines are just return reg  mask; or return (reg  mask)
== mask;. Same in the next function.

 +void powerup_cpus(void)
 +{
 + debug(powerup_cpus entry\n);
 +
 + /* Are we booting to the fast cluster? */
 + if (get_cluster_id() == 0) {

Why would we ever boot on anything other than the fast cluster? I would
assume that the kernel assume it will always get booted on the fast
cluster, which would then imply that U-Boot had to boot on or switch to
the fast cluster.

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


Re: [U-Boot] [PATCH 4/7] Tegra114: Add common CPU (shared) files

2013-01-16 Thread Stephen Warren
On 01/16/2013 02:14 PM, Tom Warren wrote:
 These files are used by both SPL and main U-Boot.

 diff --git a/arch/arm/cpu/tegra-common/board.c 
 b/arch/arm/cpu/tegra-common/board.c

 @@ -68,7 +70,7 @@ unsigned int query_sdram_size(void)
   case 3:
   return 0x4000;  /* 1GB */
   }
 -#else/* Tegra30 */
 +#elif defined(CONFIG_TEGRA30)
   /* bits 31:28 in OdmData are used for RAM size on T30  */
   switch ((reg)  28) {
   case 0:
 @@ -84,6 +86,8 @@ unsigned int query_sdram_size(void)
   case 8:
   return 0x7ff0;  /* 2GB - 1MB */
   }
 +#else
 + return 0x7ff0;  /* 2GB - 1MB */

Indentation looks wrong.

I doubt all Tegra114 systems have 2GB RAM; is there no ODMDATA field
allocated for the RAM size? I know there was some discussion of removing
it from ODMDATA and simply reading a memory controller register, since
the information was duplicated there.

 diff --git a/arch/arm/cpu/tegra114-common/clock.c 
 b/arch/arm/cpu/tegra114-common/clock.c
 diff --git a/arch/arm/cpu/tegra114-common/pinmux.c 
 b/arch/arm/cpu/tegra114-common/pinmux.c

I didn't review those two files.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 5/7] Tegra114: Dalmore: Add DT files

2013-01-16 Thread Stephen Warren
On 01/16/2013 02:14 PM, Tom Warren wrote:
 These are stripped down for bringup, They'll be filled out later
 to match-up with the kernel DT contents, and/or as devices are
 brought up (mmc, usb, spi, etc.).

 diff --git a/board/nvidia/dts/tegra114-dalmore.dts 
 b/board/nvidia/dts/tegra114-dalmore.dts

 + memory {
 + device_type = memory;
 + reg = 0x8000 0x4000;
 + };

Indeed, that says just 1GB...

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


Re: [U-Boot] U-Boot Graphics Library?

2013-01-16 Thread Andre Renaud
Hi Simon,

On 17 January 2013 04:17, Simon Glass s...@chromium.org wrote:

 If we do this, rather than re-invent the wheel, does anyone have any
 suggestions on a very small and simple existing library that we could
 bring in to do this?


If what you want is a small graphics/font system then I'd recommend the
work stb libraries from http://nothings.org. He's got an image loader that
comes in at around 40k of x86 binary, which supports PNG, JPEG, GIF
etc... and a .ttf render of around 2,000 lines of code (not sure of the
compiled size). They're all public domain licensed, well maintained,
and have no external dependencies.
They're not the fastest, but they are the smallest that I've seen.

Whether it's a good idea to load such additional features into U-Boot
or not, I don't really know.

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


Re: [U-Boot] [PATCH 7/7] Tegra114: Add/enable Dalmore build (T114 reference board)

2013-01-16 Thread Stephen Warren
On 01/16/2013 02:14 PM, Tom Warren wrote:
 This build is stripped down. It boots to the command prompt.
 GPIO is the only peripheral supported. Others TBD.

 diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c

 +void pinmux_init(void)
 +{
 + pinmux_config_table(tegra3_pinmux_common,
 + ARRAY_SIZE(tegra3_pinmux_common));

I assume that should say tegra114 not tegra3?

 diff --git a/include/configs/dalmore.h b/include/configs/dalmore.h

 +/* Must be off for Dalmore to boot !?!? FIXME */
 +#define CONFIG_SYS_DCACHE_OFF

Who knows if there is any A15 core/cache controller support in U-Boot yet?

Aside from any comments I've made, the series, briefly,
Reviewed-by: Stephen Warren swar...@nvidia.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] U-Boot Graphics Library?

2013-01-16 Thread Simon Glass
Hi Wolfgang,

On Wed, Jan 16, 2013 at 2:40 PM, Wolfgang Denk w...@denx.de wrote:
 Dear Simon Glass,

 In message 
 CAPnjgZ3rNhvL98JEOPV=90u-Wr3iEqs8QgqYaz=boohrfrj...@mail.gmail.com you 
 wrote:

 The problem is that a major purpose of the GUIs is to allow installing
 an OS from a USB stick/SD card, since the OS may have become corrupted
 and unbootable. We have looked at keeping around a separate OS image
 for this (e.g. in an available disk partition), but so far that hasn't
 proved practical since that itself can be fairly easily overwritten
 and we then have a doorstop.

 The less fancy, the better, but consumers have certain expectations
 that force us to make some efforts...there is already a single font in
 U-Boot, but it's not good enough for multi-language pretty displays
 unfortunately.

 Why don't you load and start a small recovery system from the USB
 stick then?  I don't see why you need a GUI to do that.  This could be
 mostly made automatic.

That's exactly what we do, yes!

But the user has to be told that there is a problem, and be able to
select their language so they can understand the instructions. The USB
image needs to be downloaded, and the stick inserted. Also we require
that the stick be inserted while we are watching, since this shows
that the user is actually present, and it is not a remote attacker
causing recovery. All of this means instructions are needed, hence the
bitmaps and text.

Regards,
Simon


 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 Brain: an apparatus with which we think we think.- Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] U-Boot Graphics Library?

2013-01-16 Thread Simon Glass
Hi Andre,

On Wed, Jan 16, 2013 at 2:42 PM, Andre Renaud an...@bluewatersys.com wrote:
 Hi Simon,

 On 17 January 2013 04:17, Simon Glass s...@chromium.org wrote:

 If we do this, rather than re-invent the wheel, does anyone have any
 suggestions on a very small and simple existing library that we could
 bring in to do this?


 If what you want is a small graphics/font system then I'd recommend the
 work stb libraries from http://nothings.org. He's got an image loader that
 comes in at around 40k of x86 binary, which supports PNG, JPEG, GIF
 etc... and a .ttf render of around 2,000 lines of code (not sure of the
 compiled size). They're all public domain licensed, well maintained,
 and have no external dependencies.
 They're not the fastest, but they are the smallest that I've seen.

 Whether it's a good idea to load such additional features into U-Boot
 or not, I don't really know.

Thanks for that Andre - I will take a look!

Regards,
Simon


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


[U-Boot] i.MX6 Solo and Dual Lite

2013-01-16 Thread Eric Nelson

Hi all,

We're preparing to launch i.MX6 Solo/Dual-Lite and Dual versions of
our Nitrogen6X product line.

We made a couple of stabs at patches to support these processor
variants in September and October last year.

The first attempt added run-time detection using i.MX plugins:
http://lists.denx.de/pipermail/u-boot/2012-September/#134442

It was soundly rejected.

The second attempt added preprocessor support to imximage in order
to allow a single board definition file to be compiled for each
processor variant.
http://lists.denx.de/pipermail/u-boot/2012-September/#134442

We think the approach was generally agreed to based on this comment
from Tom:
http://lists.denx.de/pipermail/u-boot/2012-October/137611.html

And a follow-up patch from Troy:
http://lists.denx.de/pipermail/u-boot/2012-October/138162.html

But things seemed to stall here:
http://lists.denx.de/pipermail/u-boot/2012-November/139918.html

Troy submitted a number of other patches, including some fixes to the
DDR initialization, but they were all made based on a 'preprocessorized'
version of mx6q_4x_mt41j128.cfg.

Troy and I also had some discussion surrounding **how** the preprocessor
was used to define the differences between processors:
http://lists.denx.de/pipermail/u-boot/2012-October/136751.html

In a nutshell, the current patch set uses a set of preprocessor macros
to configure things for each. For example, this macro call in the file
mx6q_4x_mt41j128.cfg will write either 0x48254A36 (Quad or Dual)
or 0x3F3F3035 (Dual-Lite/Solo) to register MMDC_P1_MPWRDLCTL:

WRITE_ENTRY2(MMDC_P1_MPWRDLCTL, 0x48254A36, 0x3F3F3035)

Nobody else seemed to comment on this, and it seems pretty critical.

Can we get some feedback before we prepare V2/V3 patches?

Our expectation is that we'll submit patches for each of the
following configurations of Nitrogen6X:

nitrogen6q  - Dual/Quad 1GB
nitrogen6q2g- Dual/Quad 2GB
nitrogen6solo   - Solo 512MB
nitrogen6duallite   - Dual Lite 512MB
nitrogen6solo1G - Solo 1GB
nitrogen6duallite1G - Dual Lite 1GB

Our hope is that we can do this with essentially one code
base but a separate .cfg file or #ifdefs for each.

A single include/config/nitrogen6x.h with #ifdefs should
allow us to exclude those features (e.g. SATA) on the
Solo and Dual-Lite.

Please advise,


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


Re: [U-Boot] [PATCH 2/7] Tegra114: Add AVP (arm720t) files

2013-01-16 Thread Allen Martin
On Wed, Jan 16, 2013 at 01:14:03PM -0800, Tom Warren wrote:
 This provides SPL support for T114 boards - AVP early init, plus
 CPU (A15) init/jump to main U-Boot.
 
 Signed-off-by: Tom Warren twar...@nvidia.com
 ---
  arch/arm/cpu/arm720t/tegra-common/cpu.c |   23 ++-
  arch/arm/cpu/arm720t/tegra-common/cpu.h |   13 +-
  arch/arm/cpu/arm720t/tegra114/Makefile  |   42 
  arch/arm/cpu/arm720t/tegra114/config.mk |   19 ++
  arch/arm/cpu/arm720t/tegra114/cpu.c |  328 
 +++
  5 files changed, 411 insertions(+), 14 deletions(-)
  create mode 100644 arch/arm/cpu/arm720t/tegra114/Makefile
  create mode 100644 arch/arm/cpu/arm720t/tegra114/config.mk
  create mode 100644 arch/arm/cpu/arm720t/tegra114/cpu.c
 
 diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c 
 b/arch/arm/cpu/arm720t/tegra-common/cpu.c
 index 693d584..846163c 100644
 --- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
 +++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
 @@ -40,7 +40,7 @@ enum tegra_family_t get_family(void)
 chip_id = reg  8;
 chip_id = 0xff;
 debug(  tegra_get_family: chip_id = %x\n, chip_id);
 -   if (chip_id == 0x30)
 +   if (chip_id = 0x30)

Should this be CHIPID_TEGRA30?  And it would probably be better to do:

if (chipid == CHIPID_TEGRA30 || chipid == CHIPID_TEGRA114)
 return TEGRA_FAMILY_T3x;
else if (chipid == CHIPID_TEGRA20)
 return TEGRA_FAMILY_T2x;
else
 fail;


That forces the person doing the support for the next tegra chip to
have to make a conscious decision about what to do here.


 return TEGRA_FAMILY_T3x;
 else
 return TEGRA_FAMILY_T2x;
 @@ -56,6 +56,7 @@ int get_num_cpus(void)
   */
  struct clk_pll_table tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] 
 = {
 /* T20: 1 GHz */
 +   /*  n,  m, p, cpcon */
 {{ 1000, 13, 0, 12},/* OSC 13M */
  { 625,  12, 0, 8}, /* OSC 19.2M */
  { 1000, 12, 0, 12},/* OSC 12M */
 @@ -76,11 +77,11 @@ struct clk_pll_table 
 tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
  { 700, 13, 0, 8},
 },
 
 -   /* TEGRA_SOC2_SLOW: 312 MHz */
 -   {{ 312, 13, 0, 12}, /* OSC 13M */
 -{ 260, 16, 0, 8},  /* OSC 19.2M */
 -{ 312, 12, 0, 12}, /* OSC 12M */
 -{ 312, 26, 0, 12}, /* OSC 26M */

Removing TEGRA_SOC2_SLOW should probably be a separate patch, since it
doesn't hae anything to do with t114.

 +   /* T114: 1.4 GHz */
 +   {{ 862, 8, 0, 8},
 +{ 583, 8, 0, 4},
 +{ 696, 12, 0, 8},
 +{ 700, 13, 0, 8},
 },
  };
 
 @@ -166,8 +167,8 @@ void init_pllx(void)
 sel = tegra_pll_x_table[chip_type][osc];
 pllx_set_rate(pll, sel-n, sel-m, sel-p, sel-cpcon);
 
 -   /* adjust PLLP_out1-4 on T30 */
 -   if (chip_type == TEGRA_SOC_T30) {
 +   /* adjust PLLP_out1-4 on T30/T114 */
 +   if (chip_type = TEGRA_SOC_T30) {

same comment here about = T30

 debug(  init_pllx: adjusting PLLP out freqs\n);
 adjust_pllp_out_freqs();
 }
 @@ -203,7 +204,7 @@ void enable_cpu_clock(int enable)
  */
 clk = readl(clkrst-crc_clk_cpu_cmplx);
 clk |= 1  CPU1_CLK_STP_SHIFT;
 -#if defined(CONFIG_TEGRA30)
 +#if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)

Can this be runtime instead of #ifdef?

 clk |= 1  CPU2_CLK_STP_SHIFT;
 clk |= 1  CPU3_CLK_STP_SHIFT;
  #endif
 @@ -308,7 +309,7 @@ void clock_enable_coresight(int enable)
  * Clock divider request for 204MHz would setup CSITE clock as
  * 144MHz for PLLP base 216MHz and 204MHz for PLLP base 408MHz
  */
 -   if (tegra_get_chip_type() == TEGRA_SOC_T30)
 +   if (tegra_get_chip_type() = TEGRA_SOC_T30)

same comment here about = T30

 src = CLK_DIVIDER(NVBL_PLLP_KHZ, 204000);
 else
 src = CLK_DIVIDER(NVBL_PLLP_KHZ, 144000);
 @@ -318,7 +319,7 @@ void clock_enable_coresight(int enable)
 rst = CORESIGHT_UNLOCK;
 writel(rst, CSITE_CPU_DBG0_LAR);
 writel(rst, CSITE_CPU_DBG1_LAR);
 -#if defined(CONFIG_TEGRA30)
 +#if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)

same comment here about runtime vs ifdef

 writel(rst, CSITE_CPU_DBG2_LAR);
 writel(rst, CSITE_CPU_DBG3_LAR);
  #endif
 diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.h 
 b/arch/arm/cpu/arm720t/tegra-common/cpu.h
 index 3e2ea3a..45b346d 100644
 --- a/arch/arm/cpu/arm720t/tegra-common/cpu.h
 +++ b/arch/arm/cpu/arm720t/tegra-common/cpu.h
 @@ -22,14 +22,21 @@
   */
  #include asm/types.h
 
 +#ifndef TRUE
 +#define TRUE   1
 +#endif
 +#ifndef FALSE
 +#define FALSE  0
 +#endif
 +

u-boot seems a little inconsistent here, but it looks like most of
u-boot uses C99 true and false


  /* Stabilization delays, in usec */

[U-Boot] [PATCH v2] tegra: fdt: remove clocks nodes

2013-01-16 Thread Allen Martin
These nodes are unused.

Signed-off-by: Allen Martin amar...@nvidia.com
---
v2: remove clock as well as clocks nodes
remove from non nvidia tegra boards as well
v1: original submission
---
 arch/arm/dts/tegra20.dtsi|   10 --
 arch/arm/dts/tegra30.dtsi|   10 --
 board/avionic-design/dts/tegra20-medcom-wide.dts |   14 --
 board/avionic-design/dts/tegra20-plutux.dts  |   14 --
 board/avionic-design/dts/tegra20-tec.dts |   14 --
 board/compal/dts/tegra20-paz00.dts   |   13 -
 board/compulab/dts/tegra20-trimslice.dts |   13 -
 board/nvidia/dts/tegra20-harmony.dts |   13 -
 board/nvidia/dts/tegra20-seaboard.dts|   10 --
 board/nvidia/dts/tegra20-ventana.dts |   13 -
 board/nvidia/dts/tegra20-whistler.dts|   10 --
 board/nvidia/dts/tegra30-cardhu.dts  |   13 -
 12 files changed, 147 deletions(-)

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 636ec2c..cc086b1 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -10,16 +10,6 @@
#clock-cells = 1;
};
 
-   clocks {
-   #address-cells = 1;
-   #size-cells = 0;
-
-   osc: clock {
-   compatible = fixed-clock;
-   #clock-cells = 0;
-   };
-   };
-
intc: interrupt-controller@50041000 {
compatible = nvidia,tegra20-gic;
interrupt-controller;
diff --git a/arch/arm/dts/tegra30.dtsi b/arch/arm/dts/tegra30.dtsi
index 664c397..09bdb36 100644
--- a/arch/arm/dts/tegra30.dtsi
+++ b/arch/arm/dts/tegra30.dtsi
@@ -9,16 +9,6 @@
#clock-cells = 1;
};
 
-   clocks {
-   #address-cells = 1;
-   #size-cells = 0;
-
-   osc: clock {
-   compatible = fixed-clock;
-   #clock-cells = 0;
-   };
-   };
-
i2c@7000c000 {
#address-cells = 1;
#size-cells = 0;
diff --git a/board/avionic-design/dts/tegra20-medcom-wide.dts 
b/board/avionic-design/dts/tegra20-medcom-wide.dts
index 70587a6..e46afbe 100644
--- a/board/avionic-design/dts/tegra20-medcom-wide.dts
+++ b/board/avionic-design/dts/tegra20-medcom-wide.dts
@@ -14,16 +14,6 @@
reg = 0x 0x2000;
};
 
-   clocks {
-   clk_32k: clk_32k {
-   clock-frequency = 32000;
-   };
-
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
host1x {
status = okay;
 
@@ -37,10 +27,6 @@
};
};
 
-   clock@60006000 {
-   clocks = clk_32k osc;
-   };
-
serial@70006300 {
clock-frequency = 21600;
};
diff --git a/board/avionic-design/dts/tegra20-plutux.dts 
b/board/avionic-design/dts/tegra20-plutux.dts
index 78c394f..3e6cce0 100644
--- a/board/avionic-design/dts/tegra20-plutux.dts
+++ b/board/avionic-design/dts/tegra20-plutux.dts
@@ -14,20 +14,6 @@
reg = 0x 0x2000;
};
 
-   clocks {
-   clk_32k: clk_32k {
-   clock-frequency = 32000;
-   };
-
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
-   clock@60006000 {
-   clocks = clk_32k osc;
-   };
-
serial@70006300 {
clock-frequency = 21600;
};
diff --git a/board/avionic-design/dts/tegra20-tec.dts 
b/board/avionic-design/dts/tegra20-tec.dts
index cdb7527..8135eeb 100644
--- a/board/avionic-design/dts/tegra20-tec.dts
+++ b/board/avionic-design/dts/tegra20-tec.dts
@@ -14,16 +14,6 @@
reg = 0x 0x2000;
};
 
-   clocks {
-   clk_32k: clk_32k {
-   clock-frequency = 32000;
-   };
-
-   osc {
-   clock-frequency = 1200;
-   };
-   };
-
host1x {
status = okay;
 
@@ -37,10 +27,6 @@
};
};
 
-   clock@60006000 {
-   clocks = clk_32k osc;
-   };
-
serial@70006300 {
clock-frequency = 21600;
};
diff --git a/board/compal/dts/tegra20-paz00.dts 
b/board/compal/dts/tegra20-paz00.dts
index afebbe5..0fef713 100644
--- a/board/compal/dts/tegra20-paz00.dts
+++ b/board/compal/dts/tegra20-paz00.dts
@@ -14,19 +14,6 @@
reg = 0x 0x2000;
};
 
-   clocks {
-   clk_32k: clk_32k {
-   clock-frequency = 32000;
-   };
-   osc {
-   clock-frequency = 

[U-Boot] [PATCH] tegra: fdt: sort dts files

2013-01-16 Thread Allen Martin
Sort nodes in dts files according the the following rules:

1) Any nodes that already exist in any /include/d file, in the order
they appear in the /include/d file.

2) Any nodes with a reg property, in order of their address.

3) Any nodes without a reg property, alphabetically by node name.

Signed-off-by: Allen Martin amar...@nvidia.com
---
v1: split this out from SPI driver series
---
 arch/arm/dts/tegra20.dtsi|  377 +++---
 board/avionic-design/dts/tegra20-tec.dts |   22 +-
 board/compal/dts/tegra20-paz00.dts   |   22 +-
 board/nvidia/dts/tegra20-harmony.dts |   20 +-
 board/nvidia/dts/tegra20-seaboard.dts|  108 -
 5 files changed, 268 insertions(+), 281 deletions(-)

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index cc086b1..46e3785 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -4,10 +4,102 @@
compatible = nvidia,tegra20;
interrupt-parent = intc;
 
-   tegra_car: clock@60006000 {
-   compatible = nvidia,tegra20-car;
-   reg = 0x60006000 0x1000;
-   #clock-cells = 1;
+   host1x {
+   compatible = nvidia,tegra20-host1x, simple-bus;
+   reg = 0x5000 0x00024000;
+   interrupts = 0 65 0x04   /* mpcore syncpt */
+ 0 67 0x04; /* mpcore general */
+   status = disabled;
+
+   #address-cells = 1;
+   #size-cells = 1;
+
+   ranges = 0x5400 0x5400 0x0400;
+
+   /* video-encoding/decoding */
+   mpe {
+   reg = 0x5404 0x0004;
+   interrupts = 0 68 0x04;
+   status = disabled;
+   };
+
+   /* video input */
+   vi {
+   reg = 0x5408 0x0004;
+   interrupts = 0 69 0x04;
+   status = disabled;
+   };
+
+   /* EPP */
+   epp {
+   reg = 0x540c 0x0004;
+   interrupts = 0 70 0x04;
+   status = disabled;
+   };
+
+   /* ISP */
+   isp {
+   reg = 0x5410 0x0004;
+   interrupts = 0 71 0x04;
+   status = disabled;
+   };
+
+   /* 2D engine */
+   gr2d {
+   reg = 0x5414 0x0004;
+   interrupts = 0 72 0x04;
+   status = disabled;
+   };
+
+   /* 3D engine */
+   gr3d {
+   reg = 0x5418 0x0004;
+   status = disabled;
+   };
+
+   /* display controllers */
+   dc@5420 {
+   compatible = nvidia,tegra20-dc;
+   reg = 0x5420 0x0004;
+   interrupts = 0 73 0x04;
+   status = disabled;
+
+   rgb {
+   status = disabled;
+   };
+   };
+
+   dc@5424 {
+   compatible = nvidia,tegra20-dc;
+   reg = 0x5424 0x0004;
+   interrupts = 0 74 0x04;
+   status = disabled;
+
+   rgb {
+   status = disabled;
+   };
+   };
+
+   /* outputs */
+   hdmi {
+   compatible = nvidia,tegra20-hdmi;
+   reg = 0x5428 0x0004;
+   interrupts = 0 75 0x04;
+   status = disabled;
+   };
+
+   tvo {
+   compatible = nvidia,tegra20-tvo;
+   reg = 0x542c 0x0004;
+   interrupts = 0 76 0x04;
+   status = disabled;
+   };
+
+   dsi {
+   compatible = nvidia,tegra20-dsi;
+   reg = 0x5430 0x0004;
+   status = disabled;
+   };
};
 
intc: interrupt-controller@50041000 {
@@ -18,44 +110,33 @@
   0x50040100 0x0100 ;
};
 
-   i2c@7000c000 {
-   #address-cells = 1;
-   #size-cells = 0;
-   compatible = nvidia,tegra20-i2c;
-   reg = 0x7000C000 0x100;
-   interrupts =  70 ;
-   /* PERIPH_ID_I2C1, PLL_P_OUT3 */
-   clocks = tegra_car 12, tegra_car 124;
+   tegra_car: clock@60006000 {
+   compatible = nvidia,tegra20-car;
+   reg = 0x60006000 0x1000;
+   #clock-cells = 1;
};
 
-   i2c@7000c400 {
-   

[U-Boot] [PATCH 3/5] libfdt: update fdt.h from upstream dtc

2013-01-16 Thread Kim Phillips
upstream dtc commit feafcd972cb744750a65728440c99526e6199a6d
dtc/libfdt: introduce fdt types for annotation by endian checkers.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Cc: Jerry Van Baren gvb.ub...@gmail.com
---
 include/fdt.h | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/include/fdt.h b/include/fdt.h
index c51212e..f9612ed 100644
--- a/include/fdt.h
+++ b/include/fdt.h
@@ -4,45 +4,45 @@
 #ifndef __ASSEMBLY__
 
 struct fdt_header {
-   uint32_t magic;  /* magic word FDT_MAGIC */
-   uint32_t totalsize;  /* total size of DT block */
-   uint32_t off_dt_struct;  /* offset to structure */
-   uint32_t off_dt_strings; /* offset to strings */
-   uint32_t off_mem_rsvmap; /* offset to memory reserve map */
-   uint32_t version;/* format version */
-   uint32_t last_comp_version;  /* last compatible version */
+   fdt32_t magic;   /* magic word FDT_MAGIC */
+   fdt32_t totalsize;   /* total size of DT block */
+   fdt32_t off_dt_struct;   /* offset to structure */
+   fdt32_t off_dt_strings;  /* offset to strings */
+   fdt32_t off_mem_rsvmap;  /* offset to memory reserve map */
+   fdt32_t version; /* format version */
+   fdt32_t last_comp_version;   /* last compatible version */
 
/* version 2 fields below */
-   uint32_t boot_cpuid_phys;/* Which physical CPU id we're
+   fdt32_t boot_cpuid_phys; /* Which physical CPU id we're
booting on */
/* version 3 fields below */
-   uint32_t size_dt_strings;/* size of the strings block */
+   fdt32_t size_dt_strings; /* size of the strings block */
 
/* version 17 fields below */
-   uint32_t size_dt_struct; /* size of the structure block */
+   fdt32_t size_dt_struct;  /* size of the structure block */
 };
 
 struct fdt_reserve_entry {
-   uint64_t address;
-   uint64_t size;
+   fdt64_t address;
+   fdt64_t size;
 };
 
 struct fdt_node_header {
-   uint32_t tag;
+   fdt32_t tag;
char name[0];
 };
 
 struct fdt_property {
-   uint32_t tag;
-   uint32_t len;
-   uint32_t nameoff;
+   fdt32_t tag;
+   fdt32_t len;
+   fdt32_t nameoff;
char data[0];
 };
 
 #endif /* !__ASSEMBLY */
 
 #define FDT_MAGIC  0xd00dfeed  /* 4: version, 4: total size */
-#define FDT_TAGSIZEsizeof(uint32_t)
+#define FDT_TAGSIZEsizeof(fdt32_t)
 
 #define FDT_BEGIN_NODE 0x1 /* Start node: full name */
 #define FDT_END_NODE   0x2 /* End node */
@@ -51,11 +51,11 @@ struct fdt_property {
 #define FDT_NOP0x4 /* nop */
 #define FDT_END0x9
 
-#define FDT_V1_SIZE(7*sizeof(uint32_t))
-#define FDT_V2_SIZE(FDT_V1_SIZE + sizeof(uint32_t))
-#define FDT_V3_SIZE(FDT_V2_SIZE + sizeof(uint32_t))
+#define FDT_V1_SIZE(7*sizeof(fdt32_t))
+#define FDT_V2_SIZE(FDT_V1_SIZE + sizeof(fdt32_t))
+#define FDT_V3_SIZE(FDT_V2_SIZE + sizeof(fdt32_t))
 #define FDT_V16_SIZE   FDT_V3_SIZE
-#define FDT_V17_SIZE   (FDT_V16_SIZE + sizeof(uint32_t))
+#define FDT_V17_SIZE   (FDT_V16_SIZE + sizeof(fdt32_t))
 
 /* adding a ramdisk needs 0x44 bytes in version 2008.10 */
 #define FDT_RAMDISK_OVERHEAD   0x80
-- 
1.8.1.1


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


[U-Boot] [PATCH 1/2] net: make IPaddr type big endian

2013-01-16 Thread Kim Phillips
for use with sparse.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Cc: Joe Hershberger joe.hershber...@gmail.com
---
 include/net.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net.h b/include/net.h
index 970d4d1..4c5a000 100644
--- a/include/net.h
+++ b/include/net.h
@@ -39,7 +39,7 @@
 #define PKTALIGN   ARCH_DMA_MINALIGN
 
 /* IPv4 addresses are always 32 bits in size */
-typedef u32IPaddr_t;
+typedef __be32 IPaddr_t;
 
 
 /**
-- 
1.8.1.1


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


[U-Boot] [PATCH 2/2] net/tftp: sparse fixes

2013-01-16 Thread Kim Phillips
tftp.c:464:17: warning: cast to restricted __be16
tftp.c:552:29: warning: cast to restricted __be16
tftp.c:640:33: warning: cast to restricted __be16
tftp.c:642:25: warning: cast to restricted __be16

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Cc: Joe Hershberger joe.hershber...@gmail.com
---
 net/tftp.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/tftp.c b/net/tftp.c
index 09790eb..6d333d5 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -446,8 +446,8 @@ static void
 TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip, unsigned src,
unsigned len)
 {
-   ushort proto;
-   ushort *s;
+   __be16 proto;
+   __be16 *s;
int i;
 
if (dest != TftpOurPort) {
@@ -465,7 +465,7 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip, 
unsigned src,
return;
len -= 2;
/* warning: don't use increment (++) in ntohs() macros!! */
-   s = (ushort *)pkt;
+   s = (__be16 *)pkt;
proto = *s++;
pkt = (uchar *)s;
switch (ntohs(proto)) {
@@ -556,7 +556,7 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip, 
unsigned src,
if (len  2)
return;
len -= 2;
-   TftpBlock = ntohs(*(ushort *)pkt);
+   TftpBlock = ntohs(*(__be16 *)pkt);
 
update_block_number();
 
@@ -644,9 +644,9 @@ TftpHandler(uchar *pkt, unsigned dest, IPaddr_t sip, 
unsigned src,
 
case TFTP_ERROR:
printf(\nTFTP error: '%s' (%d)\n,
-  pkt + 2, ntohs(*(ushort *)pkt));
+  pkt + 2, ntohs(*(__be16 *)pkt));
 
-   switch (ntohs(*(ushort *)pkt)) {
+   switch (ntohs(*(__be16 *)pkt)) {
case TFTP_ERR_FILE_NOT_FOUND:
case TFTP_ERR_ACCESS_DENIED:
puts(Not retrying...\n);
-- 
1.8.1.1


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


[U-Boot] [PATCH 1/5] treewide: include libfdt_env.h before fdt.h

2013-01-16 Thread Kim Phillips
and, if including libfdt.h which includes libfdt_env.h in
the correct order, don't include fdt.h before libfdt.h.

this is needed to get the fdt type definitions set from
the project environment before fdt.h uses them.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Cc: Jerry Van Baren gvb.ub...@gmail.com
---
 arch/arm/lib/bootm.c | 1 -
 arch/powerpc/lib/bootm.c | 1 -
 arch/x86/include/asm/arch-coreboot/sysinfo.h | 1 +
 common/cmd_bootm.c   | 1 -
 common/cmd_fdt.c | 1 -
 common/fdt_support.c | 1 -
 common/image.c   | 1 -
 include/fdt_support.h| 1 +
 include/image.h  | 1 -
 tools/fdt_host.h | 1 -
 tools/imls/imls.c| 1 -
 11 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 1bd2730..f3b30c5 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -30,7 +30,6 @@
 #include image.h
 #include u-boot/zlib.h
 #include asm/byteorder.h
-#include fdt.h
 #include libfdt.h
 #include fdt_support.h
 #include asm/bootm.h
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 7088293..33d013f 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -36,7 +36,6 @@
 #include asm/mp.h
 
 #if defined(CONFIG_OF_LIBFDT)
-#include fdt.h
 #include libfdt.h
 #include fdt_support.h
 
diff --git a/arch/x86/include/asm/arch-coreboot/sysinfo.h 
b/arch/x86/include/asm/arch-coreboot/sysinfo.h
index 77ae304..bd88eb5 100644
--- a/arch/x86/include/asm/arch-coreboot/sysinfo.h
+++ b/arch/x86/include/asm/arch-coreboot/sysinfo.h
@@ -32,6 +32,7 @@
 
 #include common.h
 #include compiler.h
+#include libfdt_env.h
 #include fdt.h
 #include asm/arch/tables.h
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 1b8a8c1..e886c4a 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -47,7 +47,6 @@
 #endif
 
 #if defined(CONFIG_OF_LIBFDT)
-#include fdt.h
 #include libfdt.h
 #include fdt_support.h
 #endif
diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index 9e2de34..6eec947 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -29,7 +29,6 @@
 #include linux/ctype.h
 #include linux/types.h
 #include asm/global_data.h
-#include fdt.h
 #include libfdt.h
 #include fdt_support.h
 
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 6b9fa05..7a3fee4 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -28,7 +28,6 @@
 #include linux/ctype.h
 #include linux/types.h
 #include asm/global_data.h
-#include fdt.h
 #include libfdt.h
 #include fdt_support.h
 #include exports.h
diff --git a/common/image.c b/common/image.c
index 95498e6..ae1a9d3 100644
--- a/common/image.c
+++ b/common/image.c
@@ -47,7 +47,6 @@
 #include image.h
 
 #if defined(CONFIG_FIT) || defined(CONFIG_OF_LIBFDT)
-#include fdt.h
 #include libfdt.h
 #include fdt_support.h
 #endif
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 4b9f84a..a08c90b 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -26,6 +26,7 @@
 
 #ifdef CONFIG_OF_LIBFDT
 
+#include libfdt_env.h
 #include fdt.h
 
 u32 fdt_getprop_u32_default(const void *fdt, const char *path,
diff --git a/include/image.h b/include/image.h
index f5adc50..8e285f9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -52,7 +52,6 @@
 #endif /* USE_HOSTCC */
 
 #if defined(CONFIG_FIT)
-#include fdt.h
 #include libfdt.h
 #include fdt_support.h
 #define CONFIG_MD5 /* FIT images need MD5 support */
diff --git a/tools/fdt_host.h b/tools/fdt_host.h
index 085013e..b08bf86 100644
--- a/tools/fdt_host.h
+++ b/tools/fdt_host.h
@@ -21,7 +21,6 @@
 #define __FDT_HOST_H__
 
 /* Make sure to include u-boot version of libfdt include files */
-#include ../include/fdt.h
 #include ../include/libfdt.h
 #include ../include/fdt_support.h
 
diff --git a/tools/imls/imls.c b/tools/imls/imls.c
index b21c505..a982a13 100644
--- a/tools/imls/imls.c
+++ b/tools/imls/imls.c
@@ -38,7 +38,6 @@
 #endif
 
 #include sha1.h
-#include fdt.h
 #include libfdt.h
 #include fdt_support.h
 #include image.h
-- 
1.8.1.1


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


[U-Boot] [PATCH 2/5] libfdt_env.h: add fdt type definitions

2013-01-16 Thread Kim Phillips
fdt types are big endian.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Cc: Jerry Van Baren gvb.ub...@gmail.com
---
 include/libfdt_env.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/libfdt_env.h b/include/libfdt_env.h
index bf63583..3e3defc 100644
--- a/include/libfdt_env.h
+++ b/include/libfdt_env.h
@@ -22,9 +22,14 @@
 #define _LIBFDT_ENV_H
 
 #include compiler.h
+#include linux/types.h
 
 extern struct fdt_header *working_fdt;  /* Pointer to the working fdt */
 
+typedef __be16 fdt16_t;
+typedef __be32 fdt32_t;
+typedef __be64 fdt64_t;
+
 #define fdt32_to_cpu(x)be32_to_cpu(x)
 #define cpu_to_fdt32(x)cpu_to_be32(x)
 #define fdt64_to_cpu(x)be64_to_cpu(x)
-- 
1.8.1.1


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


[U-Boot] [PATCH 4/5] libfdt: update from upstream dtc commit 142419e

2013-01-16 Thread Kim Phillips
commit 142419e dtc/libfdt: sparse fixes, for u-boot's libfdt copy.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Cc: Jerry Van Baren gvb.ub...@gmail.com
---
 include/libfdt.h | 32 
 lib/libfdt/fdt.c |  2 +-
 lib/libfdt/fdt_ro.c  |  2 +-
 lib/libfdt/fdt_rw.c  |  4 ++--
 lib/libfdt/fdt_sw.c  |  4 ++--
 lib/libfdt/fdt_wip.c |  2 +-
 6 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/include/libfdt.h b/include/libfdt.h
index c93ae28..fc7f75b 100644
--- a/include/libfdt.h
+++ b/include/libfdt.h
@@ -882,8 +882,8 @@ int fdt_setprop_inplace(void *fdt, int nodeoffset, const 
char *name,
 static inline int fdt_setprop_inplace_u32(void *fdt, int nodeoffset,
  const char *name, uint32_t val)
 {
-   val = cpu_to_fdt32(val);
-   return fdt_setprop_inplace(fdt, nodeoffset, name, val, sizeof(val));
+   fdt32_t tmp = cpu_to_fdt32(val);
+   return fdt_setprop_inplace(fdt, nodeoffset, name, tmp, sizeof(tmp));
 }
 
 /**
@@ -917,8 +917,8 @@ static inline int fdt_setprop_inplace_u32(void *fdt, int 
nodeoffset,
 static inline int fdt_setprop_inplace_u64(void *fdt, int nodeoffset,
  const char *name, uint64_t val)
 {
-   val = cpu_to_fdt64(val);
-   return fdt_setprop_inplace(fdt, nodeoffset, name, val, sizeof(val));
+   fdt64_t tmp = cpu_to_fdt64(val);
+   return fdt_setprop_inplace(fdt, nodeoffset, name, tmp, sizeof(tmp));
 }
 
 /**
@@ -993,13 +993,13 @@ int fdt_begin_node(void *fdt, const char *name);
 int fdt_property(void *fdt, const char *name, const void *val, int len);
 static inline int fdt_property_u32(void *fdt, const char *name, uint32_t val)
 {
-   val = cpu_to_fdt32(val);
-   return fdt_property(fdt, name, val, sizeof(val));
+   fdt32_t tmp = cpu_to_fdt32(val);
+   return fdt_property(fdt, name, tmp, sizeof(tmp));
 }
 static inline int fdt_property_u64(void *fdt, const char *name, uint64_t val)
 {
-   val = cpu_to_fdt64(val);
-   return fdt_property(fdt, name, val, sizeof(val));
+   fdt64_t tmp = cpu_to_fdt64(val);
+   return fdt_property(fdt, name, tmp, sizeof(tmp));
 }
 static inline int fdt_property_cell(void *fdt, const char *name, uint32_t val)
 {
@@ -1154,8 +1154,8 @@ int fdt_setprop(void *fdt, int nodeoffset, const char 
*name,
 static inline int fdt_setprop_u32(void *fdt, int nodeoffset, const char *name,
  uint32_t val)
 {
-   val = cpu_to_fdt32(val);
-   return fdt_setprop(fdt, nodeoffset, name, val, sizeof(val));
+   fdt32_t tmp = cpu_to_fdt32(val);
+   return fdt_setprop(fdt, nodeoffset, name, tmp, sizeof(tmp));
 }
 
 /**
@@ -1189,8 +1189,8 @@ static inline int fdt_setprop_u32(void *fdt, int 
nodeoffset, const char *name,
 static inline int fdt_setprop_u64(void *fdt, int nodeoffset, const char *name,
  uint64_t val)
 {
-   val = cpu_to_fdt64(val);
-   return fdt_setprop(fdt, nodeoffset, name, val, sizeof(val));
+   fdt64_t tmp = cpu_to_fdt64(val);
+   return fdt_setprop(fdt, nodeoffset, name, tmp, sizeof(tmp));
 }
 
 /**
@@ -1296,8 +1296,8 @@ int fdt_appendprop(void *fdt, int nodeoffset, const char 
*name,
 static inline int fdt_appendprop_u32(void *fdt, int nodeoffset,
 const char *name, uint32_t val)
 {
-   val = cpu_to_fdt32(val);
-   return fdt_appendprop(fdt, nodeoffset, name, val, sizeof(val));
+   fdt32_t tmp = cpu_to_fdt32(val);
+   return fdt_appendprop(fdt, nodeoffset, name, tmp, sizeof(tmp));
 }
 
 /**
@@ -1331,8 +1331,8 @@ static inline int fdt_appendprop_u32(void *fdt, int 
nodeoffset,
 static inline int fdt_appendprop_u64(void *fdt, int nodeoffset,
 const char *name, uint64_t val)
 {
-   val = cpu_to_fdt64(val);
-   return fdt_appendprop(fdt, nodeoffset, name, val, sizeof(val));
+   fdt64_t tmp = cpu_to_fdt64(val);
+   return fdt_appendprop(fdt, nodeoffset, name, tmp, sizeof(tmp));
 }
 
 /**
diff --git a/lib/libfdt/fdt.c b/lib/libfdt/fdt.c
index 4157b21..387e354 100644
--- a/lib/libfdt/fdt.c
+++ b/lib/libfdt/fdt.c
@@ -96,7 +96,7 @@ const void *fdt_offset_ptr(const void *fdt, int offset, 
unsigned int len)
 
 uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
 {
-   const uint32_t *tagp, *lenp;
+   const fdt32_t *tagp, *lenp;
uint32_t tag;
int offset = startoffset;
const char *p;
diff --git a/lib/libfdt/fdt_ro.c b/lib/libfdt/fdt_ro.c
index 1933010..1a461c3 100644
--- a/lib/libfdt/fdt_ro.c
+++ b/lib/libfdt/fdt_ro.c
@@ -326,7 +326,7 @@ const void *fdt_getprop(const void *fdt, int nodeoffset,
 
 uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
 {
-   const uint32_t *php;
+   const fdt32_t *php;
int len;
 
/* FIXME: This is a bit sub-optimal, since we potentially scan
diff --git a/lib/libfdt/fdt_rw.c 

[U-Boot] [PATCH 5/5 v2] common/fdt_support.c: sparse fixes

2013-01-16 Thread Kim Phillips
trivial:

fdt_support.c:89:64: warning: Using plain integer as NULL pointer
fdt_support.c:325:65: warning: Using plain integer as NULL pointer
fdt_support.c:352:65: warning: Using plain integer as NULL pointer

For the following bad constant expression, We hardcode the max. number of
memory banks to four for the foreseeable future, and add an error with
instructions on what to do once it's exceeded:

fdt_support.c:397:22: error: bad constant expression

For the rest below, sparse found a couple of wrong endian conversions
in of_bus_default_translate() and fdt_get_base_address(), but
otherwise the rest is mostly annotation fixes:

fdt_support.c:64:24: warning: cast to restricted __be32
fdt_support.c:192:21: warning: incorrect type in assignment (different base 
types)
fdt_support.c:192:21:expected unsigned int [unsigned] [usertype] tmp
fdt_support.c:192:21:got restricted __be32 [usertype] noident
fdt_support.c:201:21: warning: incorrect type in assignment (different base 
types)
fdt_support.c:201:21:expected unsigned int [unsigned] [addressable] 
[usertype] tmp
fdt_support.c:201:21:got restricted __be32 [usertype] noident
fdt_support.c:304:13: warning: incorrect type in assignment (different base 
types)
fdt_support.c:304:13:expected unsigned int [unsigned] [usertype] val
fdt_support.c:304:13:got restricted __be32 [usertype] noident
fdt_support.c:333:13: warning: incorrect type in assignment (different base 
types)
fdt_support.c:333:13:expected unsigned int [unsigned] [usertype] val
fdt_support.c:333:13:got restricted __be32 [usertype] noident
fdt_support.c:359:13: warning: incorrect type in assignment (different base 
types)
fdt_support.c:359:13:expected unsigned int [unsigned] [usertype] val
fdt_support.c:359:13:got restricted __be32 [usertype] noident
fdt_support.c:373:21: warning: cast to restricted __be32
fdt_support.c:963:48: warning: incorrect type in argument 1 (different base 
types)
fdt_support.c:963:48:expected restricted __be32 const [usertype] *p
fdt_support.c:963:48:got unsigned int [usertype] *noident
fdt_support.c:971:48: warning: incorrect type in argument 1 (different base 
types)
fdt_support.c:971:48:expected restricted __be32 const [usertype] *p
fdt_support.c:971:48:got unsigned int [usertype] *noident
fdt_support.c:984:29: warning: incorrect type in argument 1 (different base 
types)
fdt_support.c:984:29:expected restricted __be32 const [usertype] *cell
fdt_support.c:984:29:got unsigned int [usertype] *addr
fdt_support.c:996:32: warning: incorrect type in argument 1 (different base 
types)
fdt_support.c:996:32:expected restricted __be32 const [usertype] *cell
fdt_support.c:996:32:got unsigned int [usertype] *addr
fdt_support.c:1041:41: warning: incorrect type in argument 1 (different base 
types)
fdt_support.c:1041:41:expected restricted __be32 const [usertype] *cell
fdt_support.c:1041:41:got unsigned int [usertype] *addr
fdt_support.c:1053:41: warning: incorrect type in argument 2 (different base 
types)
fdt_support.c:1053:41:expected restricted __be32 const [usertype] *range
fdt_support.c:1053:41:got unsigned int const [usertype] *[assigned] ranges
fdt_support.c:1064:53: warning: incorrect type in argument 2 (different base 
types)
fdt_support.c:1064:53:expected restricted __be32 const [usertype] *addr
fdt_support.c:1064:53:got unsigned int [usertype] *addr
fdt_support.c:1110:50: warning: incorrect type in argument 2 (different base 
types)
fdt_support.c:1110:50:expected restricted __be32 const [usertype] *addr
fdt_support.c:1110:50:got unsigned int *noident
fdt_support.c:1121:49: warning: incorrect type in argument 1 (different base 
types)
fdt_support.c:1121:49:expected restricted __be32 const [usertype] *cell
fdt_support.c:1121:49:got unsigned int *noident
fdt_support.c:1147:60: warning: incorrect type in argument 2 (different base 
types)
fdt_support.c:1147:60:expected restricted __be32 const [usertype] *addr
fdt_support.c:1147:60:got unsigned int *noident
fdt_support.c:1081:5: warning: symbol '__of_translate_address' was not 
declared. Should it be static?
fdt_support.c:1154:5: error: symbol 'fdt_translate_address' redeclared with 
different type (originally declared at include/fdt_support.h:95) - incompatible 
argument 3 (different base types)
fdt_support.c: In function 'fdt_node_offset_by_compat_reg':
fdt_support.c:1173:17: warning: initialization discards 'const' qualifier from 
pointer target type [enabled by default]

See also linux kernel commit 0131d897 of/address: use proper
endianess in get_flags.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Cc: Jerry Van Baren gvb.ub...@gmail.com
---
v1 sent Tue, 16 Oct 2012 14:28:30 -
v2: updated to use fdt32 instead of be32 nomenclature, now that fdt
specific types exist

 arch/powerpc/cpu/mpc85xx/fdt.c |  2 +-
 common/fdt_support.c   | 86 +++---
 

Re: [U-Boot] [PATCH 1/5] treewide: include libfdt_env.h before fdt.h

2013-01-16 Thread Scott Wood

On 01/16/2013 05:59:04 PM, Kim Phillips wrote:

and, if including libfdt.h which includes libfdt_env.h in
the correct order, don't include fdt.h before libfdt.h.

this is needed to get the fdt type definitions set from
the project environment before fdt.h uses them.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
Cc: Jerry Van Baren gvb.ub...@gmail.com


Maybe fdt.h should include libfdt_env.h?

Or just always use libfdt.h as the public header.

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


[U-Boot] [GIT PULL] u-boot-mpc83xx: support for new SPL

2013-01-16 Thread Kim Phillips
Hi Tom,

Please pull:

The following changes since commit 3a9d879f6f64585b819af728b53be0a05037fe0d:

  Prepare v2013.01 (2013-01-15 14:47:42 -0700)

are available in the git repository at:

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

for you to fetch changes up to a6187dccd813920524987792e49ef2feffb213e6:

  Merge remote-tracking branch 'mpc83xx/next' (2013-01-16 18:34:09 -0600)



Kim Phillips (1):
  Merge remote-tracking branch 'mpc83xx/next'

Scott Wood (3):
  spl: Change PAD_TO to CONFIG_SPL_PAD_TO
  powerpc/mpc83xx: add support for new SPL
  powerpc/mpc83xx: convert MPC8313ERDB to new-SPL

 Makefile   |   6 +-
 README |  10 ++
 arch/powerpc/cpu/mpc83xx/Makefile  |  16 +++
 .../cpu/mpc83xx/{nand_init.c = spl_minimal.c} |   0
 arch/powerpc/cpu/mpc83xx/start.S   |  31 +++---
 .../powerpc/cpu/mpc83xx/u-boot-spl.lds |   0
 arch/powerpc/lib/Makefile  |   3 +-
 board/ait/cam_enc_4xx/config.mk|   2 +-
 board/freescale/mpc8313erdb/mpc8313erdb.c  |  10 +-
 boards.cfg |   4 +-
 include/configs/MPC8313ERDB.h  |  43 +---
 nand_spl/board/freescale/mpc8313erdb/Makefile  | 108 -
 nand_spl/board/freescale/mpc8315erdb/Makefile  |   6 +-
 nand_spl/board/sheldon/simpc8313/Makefile  |   6 +-
 14 files changed, 96 insertions(+), 149 deletions(-)
 rename arch/powerpc/cpu/mpc83xx/{nand_init.c = spl_minimal.c} (100%)
 rename nand_spl/board/freescale/mpc8313erdb/u-boot.lds = 
arch/powerpc/cpu/mpc83xx/u-boot-spl.lds (100%)
 delete mode 100644 nand_spl/board/freescale/mpc8313erdb/Makefile

Thanks,

Kim

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


[U-Boot] configure USB Host1 in U-Boot of iMx53

2013-01-16 Thread Sarvesh Gupta

Dear All,

I have added the USB host controller driver into our Mx53 loco board's u-boot 
and also made some changes in mx53_loco.h and mx53_loco.c.

Below is the complete log what I am getting on serial console:



U-Boot 2009.08-dirty (Jan 15 2013 - 12:32:20)
CPU:   Freescale i.MX53 family 2.1V at 800 MHz
mx53 pll1: 800MHz
mx53 pll2: 400MHz
mx53 pll3: 216MHz
mx53 pll4: 455MHz
ipg clock : Hz
ipg per clock : Hz
uart clock: Hz
cspi clock: 5400Hz
ahb clock : 1Hz
axi_a clock   : 4Hz
axi_b clock   : 2Hz
emi_slow clock: 1Hz
ddr clock : 4Hz
esdhc1 clock  : 8000Hz
esdhc2 clock  : 8000Hz
esdhc3 clock  : 8000Hz
esdhc4 clock  : 8000Hz
nfc clock : 2666Hz
Board: MX53-LOCO 1.0
Boot Reason: [POR]
Boot Device: SD
I2C:   ready
DRAM:   1 GB
MMC:   FSL_ESDHC: 0, FSL_ESDHC: 1
*** Warning - bad CRC or MMC, using default environment

In:serial
Out:   serial
Err:   serial

Serial reinitilized!
Net:   got MAC address from IIM: 00:04:9f:02:41:18
FEC0 [PRIME]
Hit any key to stop autoboot:  0
MX53-LOCO U-Boot 
MX53-LOCO U-Boot 
MX53-LOCO U-Boot  usb start
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... New Device 0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 
0x40
USB DESCRIPTOR_1 18
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 
0x12
USB DESCRIPTOR2 18
NEW DEVICE STRINGS : Mfr=1, Product=2, SerialNumber=0
, Dtype=1
, DClass=9
, DProto=1
, Len=18
, MaxP=64
, ConfigNo=1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 
0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 
0x19
get_conf_no 0 Result 25, wLength 25
if 0, ep 0
##EP epmaxpacketin[1] = 8
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
new device strings: Mfr=1, Product=2, SerialNumber=0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 
0xFF
USB device number 1 default language ID 0x1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 
0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 
0xFF
Manufacturer u-boot
Product  EHCI Host Controller
SerialNumber
USB hub found
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 
0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 
0x8
1 ports detected
individual port power switching
standalone hub
global over-current protection
power on to power good time: 20ms
hub controller current requirement: 0mA
port 1 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4
get_hub_status returned status 1, change 8101
local power source is lost (inactive)
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0
port 1 returns 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
Port 1 Status 101 Change 1
port 1 connection change
port 1 connection change
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 101, change 1, 12 Mb/s
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 
0x0
hub_port_reset: resetting port 0...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 503, change 10, 480 Mb/s
STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 1
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 
0x0
New Device 1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 
0x40
EHCI timed out on TD - token=0x80008c80
USB DESCRIPTOR_1 64
hub_port_reset: resetting port 0...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 503, change 10, 480 Mb/s
STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 1
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 
0x0
set address 2
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length 0x0
EHCI timed out on TD - token=0x80008d80
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 
0x12
EHCI timed out on TD - token=0x80008c80
USB DESCRIPTOR2 18
NEW DEVICE STRINGS : Mfr=0, Product=0, SerialNumber=0
, Dtype=0
, DClass=0
, DProto=0
, Len=0
, MaxP=255
, ConfigNo=0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 
0x9
EHCI timed out on TD - token=0x80008c80
usb_control_msg: request: 0x6, requesttype: 0x80, 

[U-Boot] [PATCH 1/2] SF: Add driver for Gigabyte device GD25LQ and GD25Q64B

2013-01-16 Thread Rajeshwari Shinde
This patch adds driver for the gigabyte devices
GD25LQ and GD25Q64B required for Snow Board.

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 drivers/mtd/spi/Makefile |1 +
 drivers/mtd/spi/gigadevice.c |   66 ++
 drivers/mtd/spi/spi_flash.c  |3 ++
 drivers/mtd/spi/spi_flash_internal.h |1 +
 4 files changed, 71 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/spi/gigadevice.c

diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 90f8392..0af497d 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -39,6 +39,7 @@ COBJS-$(CONFIG_SPI_FLASH_STMICRO) += stmicro.o
 COBJS-$(CONFIG_SPI_FLASH_WINBOND)  += winbond.o
 COBJS-$(CONFIG_SPI_FRAM_RAMTRON)   += ramtron.o
 COBJS-$(CONFIG_SPI_M95XXX) += eeprom_m95xxx.o
+COBJS-$(CONFIG_SPI_FLASH_GIGADEVICE)   += gigadevice.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/mtd/spi/gigadevice.c b/drivers/mtd/spi/gigadevice.c
new file mode 100644
index 000..5dbcd19
--- /dev/null
+++ b/drivers/mtd/spi/gigadevice.c
@@ -0,0 +1,66 @@
+/*
+ * Gigadevice SPI flash driver
+ * Copyright 2013, Samsung Electronics Co., Ltd.
+ * Author: Banajit Goswami banaji...@samsung.com
+ *
+ */
+
+#include common.h
+#include malloc.h
+#include spi_flash.h
+
+#include spi_flash_internal.h
+
+struct gigadevice_spi_flash_params {
+   uint16_tid;
+   uint16_tnr_blocks;
+   const char  *name;
+};
+
+static const struct gigadevice_spi_flash_params gigadevice_spi_flash_table[] = 
{
+   {
+   .id = 0x6016,
+   .nr_blocks  = 64,
+   .name   = GD25LQ,
+   },
+   {
+   .id = 0x4017,
+   .nr_blocks  = 128,
+   .name   = GD25Q64B,
+   },
+
+};
+
+
+struct spi_flash *spi_flash_probe_gigadevice(struct spi_slave *spi, u8 *idcode)
+{
+   const struct gigadevice_spi_flash_params *params;
+   struct spi_flash *flash;
+   unsigned int i;
+
+   for (i = 0; i  ARRAY_SIZE(gigadevice_spi_flash_table); i++) {
+   params = gigadevice_spi_flash_table[i];
+   if (params-id == ((idcode[1]  8) | idcode[2]))
+   break;
+   }
+
+   if (i == ARRAY_SIZE(gigadevice_spi_flash_table)) {
+   debug(SF: Unsupported Gigadevice ID %02x%02x\n,
+   idcode[1], idcode[2]);
+   return NULL;
+   }
+
+   flash = spi_flash_alloc_base(spi, params-name);
+   if (!flash) {
+   debug(SF: Failed to allocate memory\n);
+   return NULL;
+   }
+   /* Assuming power-of-two page size initially. */
+   flash-page_size = 256;
+   /* sector_size = page_size * pages_per_sector */
+   flash-sector_size = flash-page_size * 16;
+   /* size = sector_size * sector_per_block * number of blocks */
+   flash-size = flash-sector_size * 16 * params-nr_blocks;
+
+   return flash;
+}
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 17f3d3c..ee05171 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -305,6 +305,9 @@ static const struct {
 #ifdef CONFIG_SPI_FLASH_EON
{ 0, 0x1c, spi_flash_probe_eon, },
 #endif
+#ifdef CONFIG_SPI_FLASH_GIGADEVICE
+   { 0, 0xc8, spi_flash_probe_gigadevice, },
+#endif
 #ifdef CONFIG_SPI_FLASH_MACRONIX
{ 0, 0xc2, spi_flash_probe_macronix, },
 #endif
diff --git a/drivers/mtd/spi/spi_flash_internal.h 
b/drivers/mtd/spi/spi_flash_internal.h
index 141cfa8..e0afbc3 100644
--- a/drivers/mtd/spi/spi_flash_internal.h
+++ b/drivers/mtd/spi/spi_flash_internal.h
@@ -106,3 +106,4 @@ struct spi_flash *spi_flash_probe_sst(struct spi_slave 
*spi, u8 *idcode);
 struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 *idcode);
 struct spi_flash *spi_flash_probe_winbond(struct spi_slave *spi, u8 *idcode);
 struct spi_flash *spi_fram_probe_ramtron(struct spi_slave *spi, u8 *idcode);
+struct spi_flash *spi_flash_probe_gigadevice(struct spi_slave *spi, u8 
*idcode);
-- 
1.7.4.4

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


[U-Boot] [PATCH 0/2] EXYNOS5: Enable Gigabyte device GD25LQ and GD25Q64B

2013-01-16 Thread Rajeshwari Shinde
This patch set adds driver for Gigabyte device GD25LQ and GD25Q64B
required for Snow board and enables same in config file.

Based on following patches submitted by Simon Glass:
sf: Add spi_flash_alloc() to create a new SPI flash struct
sf: Use spi_flash_alloc() in each SPI flash driver

Rajeshwari Shinde (2):
  SF: Add driver for Gigabyte device GD25LQ and GD25Q64B
  EXYNOS5: Enable SPI Gigabyte device.

 drivers/mtd/spi/Makefile |1 +
 drivers/mtd/spi/gigadevice.c |   66 ++
 drivers/mtd/spi/spi_flash.c  |3 ++
 drivers/mtd/spi/spi_flash_internal.h |1 +
 include/configs/exynos5250-dt.h  |1 +
 5 files changed, 72 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mtd/spi/gigadevice.c

-- 
1.7.4.4

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


[U-Boot] [PATCH 2/2] EXYNOS5: Enable SPI Gigabyte device.

2013-01-16 Thread Rajeshwari Shinde
This patch enables gigabyte device for SMDK5250.

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 include/configs/exynos5250-dt.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index cabd2f2..a01fb96 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -265,6 +265,7 @@
 #define CONFIG_CMD_SF
 #define CONFIG_CMD_SPI
 #define CONFIG_SPI_FLASH_WINBOND
+#define CONFIG_SPI_FLASH_GIGADEVICE
 #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
 #define CONFIG_SF_DEFAULT_SPEED5000
 #define EXYNOS5_SPI_NUM_CONTROLLERS5
-- 
1.7.4.4

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


Re: [U-Boot] U-Boot Graphics Library?

2013-01-16 Thread Dirk Behme

On 16.01.2013 23:54, Simon Glass wrote:

Hi Wolfgang,

On Wed, Jan 16, 2013 at 2:40 PM, Wolfgang Denk w...@denx.de wrote:

Dear Simon Glass,

In message CAPnjgZ3rNhvL98JEOPV=90u-Wr3iEqs8QgqYaz=boohrfrj...@mail.gmail.com 
you wrote:

The problem is that a major purpose of the GUIs is to allow installing
an OS from a USB stick/SD card, since the OS may have become corrupted
and unbootable. We have looked at keeping around a separate OS image
for this (e.g. in an available disk partition), but so far that hasn't
proved practical since that itself can be fairly easily overwritten
and we then have a doorstop.

The less fancy, the better, but consumers have certain expectations
that force us to make some efforts...there is already a single font in
U-Boot, but it's not good enough for multi-language pretty displays
unfortunately.

Why don't you load and start a small recovery system from the USB
stick then?  I don't see why you need a GUI to do that.  This could be
mostly made automatic.


That's exactly what we do, yes!

But the user has to be told that there is a problem, and be able to
select their language so they can understand the instructions. The USB
image needs to be downloaded, and the stick inserted. Also we require
that the stick be inserted while we are watching, since this shows
that the user is actually present, and it is not a remote attacker
causing recovery. All of this means instructions are needed, hence the
bitmaps and text.


Yes, we were thinking about the same use case: An U-Boot based device 
where U-Boot is responsible for the whole system update, including the 
OS. The user has to insert an USB stick or SD card containing the files 
to be updated. Then U-Boot has to copy these files to the NOR, NAND or 
whatever the system boots from. The only user interface is a display, no 
serial console. On the display something like Please insert the USB 
stick, Update in progress, please wait, Update successfully 
finished, Update error xx has to be shown, then.


Best regards

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


[U-Boot] [PATCH] powerpc/p5040: add serdes2 memory map register define

2013-01-16 Thread Roy Zang
Signed-off-by: Roy Zang tie-fei.z...@freescale.com
---
 arch/powerpc/include/asm/immap_85xx.h |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 296b549..0f15799 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -2648,6 +2648,32 @@ typedef struct serdes_corenet {
 } serdes_corenet_t;
 #endif /* CONFIG_SYS_FSL_QORIQ_CHASSIS2 */
 
+typedef struct serdes2_corenet {
+   u32 rstctl; /* Reset Control Register */
+   u32 pllcr0; /* PLL Control Register 0 */
+   u32 pllcr1; /* PLL Control Register 1 */
+   u32 res1[25];
+   u32 srdstcalcr; /* TX Calibration Control */
+   u32 res2[3];
+   u32 srdsrcalcr; /* RX Calibration Control */
+   u32 res3[3];
+   u32 srdsgr0;/* General Register 0 */
+   u32 res4[11];
+   u32 srdspccr0;  /* Protocol Converter Config 0 */
+   u32 res5[79];
+   struct {
+   u32 gcr0;   /* General Control Register 0 */
+   u32 gcr1;   /* General Control Register 1 */
+   u32 res1[2];
+   u32 recr0;  /* Receive Equalization Control Reg 0 */
+   u32 res2;
+   u32 tecr0;  /* TX Equalization Control Reg 0 */
+   u32 res3;
+   u32 ttlcr0; /* Transition Tracking Loop Ctrl 0 */
+   u32 res4[7];
+   } lane[2];
+} serdes2_corenet_t;
+
 enum {
FSL_SRDS_B1_LANE_A = 0,
FSL_SRDS_B1_LANE_B = 1,
-- 
1.7.9.5


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