[U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14

[Heiko Schocher]

resync mtd, ubi and ubifs subsystem with linux:

commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds 
Date:   Sun Mar 30 20:40:15 2014 -0700

Linux 3.14

Main reason for this sync is, we now have UBI fastmap support
in U-Boot.

Tested it on am33xx, imx6 and mpc83xx boards. MAKEALL for arm, mips
and powerpc compiles clean.

Tested UBI fastmap on a board with 512 MiB nand flash. Attach time
from old U-Boot was 2 seconds, reduced with UBI fastmap to 0.2 seconds.

Please test this patchserie!

The patches 

  lib, rbtree: resync with Linux-3.14
  lib, list_sort: add list_sort from linux 3.14
  mtd, ubi, ubifs: resync with Linux-3.14

are not checkpatch clean, as they use code from Linux and
I do not want to change this.

Remarks:
- UBI Fastmap is now availiable in U-Boot
  activate it with CONFIG_MTD_UBI_FASTMAP

- replace UBI_LINUX in current UBI code from U-Boot with
  __UBOOT__ as this define is used in other places in U-Boot
  where code from other projects is used.

- move a lot of defines from include/ubi_uboot.h to
  include/linux/compat.h, as this is the correcter place for it.

- add usb device to linux device, so usb uses "struct device"
  from "linux/compat.h"

- onenand changes only compile tested.

- Following Code in drivers/mtd/nand/nand_base.c nand_do_write_ops()
  adapted for U-Boot:

  +#ifndef __UBOOT__
/* Reject writes, which are not page aligned */
if (NOTALIGNED(to) || NOTALIGNED(ops->len)) {
  +else
  + /* Reject writes, which are not page aligned */
  + if (NOTALIGNED(to)) {
  +endif

  as the original linux code leads in not working use of the env
  var "filesize". For example a "nand write 8000 8 ${filesize}"
  would not work with it ...

- add CONFIG_MTD_NAND_VERIFY_WRITE from U-Boot code
  (only compile tested)

- Documented the config defines in README

- kmalloc now uses memalign for allocating memory. This prevented
  crashes when tested ubi/ubifs on imx6 board.

- To produce this patch I did three steps:
  - copied the linux source files to U-Boot tree -> commit this
  - adapt license text in each file -> commit this
  - make the code again compile clean and working -> commit this

  Then squashed this three patches to this patch, to not break
  bisectability. To make further sync with linux easier, the
  above three patches can be found in:

  
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/update-mtd%2Bubi-linux-v3.14

  This branch is only thought for further linux syncs! Please
  do not use this branch for testing this patchseries!

- Hope I get all U-Boot specific changes ... so please, test,
  test, test ...

- changes for v2:
  - add lib/linux_compat.c as Joerg Krause detected

- changes for v3:
  - patch:
Patchwork [U-Boot,RFC,v2,1/4] dm: rename device struct to udevice
http://patchwork.ozlabs.org/patch/351422/
not longer needed, as it found its way into mainline
  - add in the commit message the description, how this sync patch
with linux was done, as Marek and Tom suggested.
  - rebase with current U-Boot commit
61e76f53708cf082ef9061a140b57df3513b8ba1

- changes for v4:
  - rebase with commit d8a97f934c64a7ba6f11da5e4cc7f3be57fcb82d
  - remove compile error for mips, as Tom Rini suggested
check "MAKEALL mips" compiles clean
  - fix blackfin and microblaze compile
add fix for blackfin from Trom Rini also add his Signed-off-by

Cc: Marek Vasut 
Cc: Sergey Lapin 
Cc: Scott Wood 
Cc: Wolfgang Denk 
Cc: Joerg Krause 

Heiko Schocher (3):
  lib, rbtree: resync with Linux-3.14
  lib, list_sort: add list_sort from linux 3.14
  mtd, ubi, ubifs: resync with Linux-3.14

 README  |   61 +
 board/prodrive/alpr/nand.c  |4 +
 board/socrates/nand.c   |6 +
 board/tqc/tqm8272/nand.c|4 +
 common/cmd_ubi.c|   29 +-
 common/cmd_ubifs.c  |2 +-
 drivers/mtd/mtdconcat.c |  230 ++-
 drivers/mtd/mtdcore.c   | 1112 -
 drivers/mtd/mtdcore.h   |   23 +
 drivers/mtd/mtdpart.c   |  521 +-
 drivers/mtd/nand/fsl_elbc_nand.c|4 +
 drivers/mtd/nand/fsl_ifc_nand.c |4 +
 drivers/mtd/nand/fsl_upm.c  |4 +
 drivers/mtd/nand/mpc5121_nfc.c  |4 +
 drivers/mtd/nand/mxc_nand.c |8 +
 drivers/mtd/nand/nand_base.c| 1897 +++--
 drivers/mtd/nand/nand_bbt.c |  296 ++--
 drivers/mtd/nand/nand_ids.c |  256 +--
 drivers/mtd/nand/nand_util.c|3 +
 drivers/mtd/nand/ndfc.c |4 +
 drivers/mtd/onenand/onenand_base.c  |1 +
 drivers/mtd/onenand/onenand_bbt.c   |1 -
 drivers/mtd/onenand/samsung.c   |   10 +-
 drivers/mtd/ubi/Makefile|3 +-
 drivers/mtd/ubi/attach.c| 1754 
 drivers/mtd/ubi/build.c |  812 ++---
 drivers/mtd/ubi/crc32.c |   13 +-
 drivers/m

[U-Boot] [PATCH v4 2/3] lib, list_sort: add list_sort from linux 3.14

[Heiko Schocher]

from linux 3.14:

commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds 
Date:   Sun Mar 30 20:40:15 2014 -0700

Linux 3.14

Needed for the MTD/UBI/UBIFS resync

Just copied the files from Linux, and added in the c-file
the "#define __UBOOT__" for adding U-Boot special code. In
this case we use this just for adding including U-Boot
headers.

Signed-off-by: Heiko Schocher 
Cc: Marek Vasut 
Cc: Sergey Lapin 
Cc: Scott Wood 
Cc: Tom Rini 

---
- changes for v2:
  - none
- changes for v3:
  - add in the commit message the description, how this sync with
linux patch was done, as Marek and Tom suggested.
- changes for v4:
  - none

 include/linux/list_sort.h |  11 ++
 lib/Makefile  |   1 +
 lib/list_sort.c   | 298 ++
 3 files changed, 310 insertions(+)
 create mode 100644 include/linux/list_sort.h
 create mode 100644 lib/list_sort.c

diff --git a/include/linux/list_sort.h b/include/linux/list_sort.h
new file mode 100644
index 000..1a2df2e
--- /dev/null
+++ b/include/linux/list_sort.h
@@ -0,0 +1,11 @@
+#ifndef _LINUX_LIST_SORT_H
+#define _LINUX_LIST_SORT_H
+
+#include 
+
+struct list_head;
+
+void list_sort(void *priv, struct list_head *head,
+  int (*cmp)(void *priv, struct list_head *a,
+ struct list_head *b));
+#endif
diff --git a/lib/Makefile b/lib/Makefile
index 377ab13..37030a4 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -41,6 +41,7 @@ obj-y += strmhz.o
 obj-$(CONFIG_TPM) += tpm.o
 obj-$(CONFIG_RBTREE)   += rbtree.o
 obj-$(CONFIG_BITREVERSE) += bitrev.o
+obj-y += list_sort.o
 endif
 
 ifdef CONFIG_SPL_BUILD
diff --git a/lib/list_sort.c b/lib/list_sort.c
new file mode 100644
index 000..81de0a1
--- /dev/null
+++ b/lib/list_sort.c
@@ -0,0 +1,298 @@
+#define __UBOOT__
+#ifndef __UBOOT__
+#include 
+#include 
+#include 
+#else
+#include 
+#include 
+#include 
+#endif
+#include 
+#include 
+
+#define MAX_LIST_LENGTH_BITS 20
+
+/*
+ * Returns a list organized in an intermediate format suited
+ * to chaining of merge() calls: null-terminated, no reserved or
+ * sentinel head node, "prev" links not maintained.
+ */
+static struct list_head *merge(void *priv,
+   int (*cmp)(void *priv, struct list_head *a,
+   struct list_head *b),
+   struct list_head *a, struct list_head *b)
+{
+   struct list_head head, *tail = &head;
+
+   while (a && b) {
+   /* if equal, take 'a' -- important for sort stability */
+   if ((*cmp)(priv, a, b) <= 0) {
+   tail->next = a;
+   a = a->next;
+   } else {
+   tail->next = b;
+   b = b->next;
+   }
+   tail = tail->next;
+   }
+   tail->next = a?:b;
+   return head.next;
+}
+
+/*
+ * Combine final list merge with restoration of standard doubly-linked
+ * list structure.  This approach duplicates code from merge(), but
+ * runs faster than the tidier alternatives of either a separate final
+ * prev-link restoration pass, or maintaining the prev links
+ * throughout.
+ */
+static void merge_and_restore_back_links(void *priv,
+   int (*cmp)(void *priv, struct list_head *a,
+   struct list_head *b),
+   struct list_head *head,
+   struct list_head *a, struct list_head *b)
+{
+   struct list_head *tail = head;
+
+   while (a && b) {
+   /* if equal, take 'a' -- important for sort stability */
+   if ((*cmp)(priv, a, b) <= 0) {
+   tail->next = a;
+   a->prev = tail;
+   a = a->next;
+   } else {
+   tail->next = b;
+   b->prev = tail;
+   b = b->next;
+   }
+   tail = tail->next;
+   }
+   tail->next = a ? : b;
+
+   do {
+   /*
+* In worst cases this loop may run many iterations.
+* Continue callbacks to the client even though no
+* element comparison is needed, so the client's cmp()
+* routine can invoke cond_resched() periodically.
+*/
+   (*cmp)(priv, tail->next, tail->next);
+
+   tail->next->prev = tail;
+   tail = tail->next;
+   } while (tail->next);
+
+   tail->next = head;
+   head->prev = tail;
+}
+
+/**
+ * list_sort - sort a list
+ * @priv: private data, opaque to list_sort(), passed to @cmp
+ * @head: the list to sort
+ * @cmp: the elements comparison function
+ *
+ * This function implements "merge sort", which has O(nlog(n))
+ * complexity.
+ *
+ * The comparison function @cmp must return a negative value if @a
+ * should sort before @b, and a

[U-Boot] [PATCH v4 1/3] lib, rbtree: resync with Linux-3.14

[Heiko Schocher]

resync with linux:

commit 455c6fdbd219161bd09b1165f11699d6d73de11c
Author: Linus Torvalds 
Date:   Sun Mar 30 20:40:15 2014 -0700

Linux 3.14

Needed for the MTD/UBI/UBIFS resync

Just copied the files from Linux, changed the license file header,
and add in the c-file:

+#define __UBOOT__
 #include 
+#ifndef __UBOOT__
 #include 
+#else
+#include 
+#endif

so, it compiles for U-Boot.

Signed-off-by: Heiko Schocher 
Cc: Marek Vasut 
Cc: Sergey Lapin 
Cc: Scott Wood 
Cc: Tom Rini 

---
- changes for v2:
  - none
- changes for v3:
  - add in the commit message the description, how this sync patch
with linux was done, as Marek and Tom suggested.
- changes for v4:
  - none

 include/linux/rbtree.h   | 147 +++--
 include/linux/rbtree_augmented.h | 220 +
 lib/rbtree.c | 684 ---
 3 files changed, 698 insertions(+), 353 deletions(-)
 create mode 100644 include/linux/rbtree_augmented.h

diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index ad892d1..b5994e3 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -1,7 +1,7 @@
 /*
   Red Black Trees
   (C) 1999  Andrea Arcangeli 
-
+  
  * SPDX-License-Identifier:GPL-2.0+
 
   linux/include/linux/rbtree.h
@@ -11,138 +11,89 @@
   I know it's not the cleaner way,  but in C (not in C++) to get
   performances and genericity...
 
-  Some example of insert and search follows here. The search is a plain
-  normal search over an ordered tree. The insert instead must be implemented
-  int two steps: as first thing the code must insert the element in
-  order as a red leaf in the tree, then the support library function
-  rb_insert_color() must be called. Such function will do the
-  not trivial work to rebalance the rbtree if necessary.
-

-static inline struct page * rb_search_page_cache(struct inode * inode,
-unsigned long offset)
-{
-   struct rb_node * n = inode->i_rb_page_cache.rb_node;
-   struct page * page;
-
-   while (n)
-   {
-   page = rb_entry(n, struct page, rb_page_cache);
-
-   if (offset < page->offset)
-   n = n->rb_left;
-   else if (offset > page->offset)
-   n = n->rb_right;
-   else
-   return page;
-   }
-   return NULL;
-}
-
-static inline struct page * __rb_insert_page_cache(struct inode * inode,
-  unsigned long offset,
-  struct rb_node * node)
-{
-   struct rb_node ** p = &inode->i_rb_page_cache.rb_node;
-   struct rb_node * parent = NULL;
-   struct page * page;
-
-   while (*p)
-   {
-   parent = *p;
-   page = rb_entry(parent, struct page, rb_page_cache);
-
-   if (offset < page->offset)
-   p = &(*p)->rb_left;
-   else if (offset > page->offset)
-   p = &(*p)->rb_right;
-   else
-   return page;
-   }
-
-   rb_link_node(node, parent, p);
-
-   return NULL;
-}
-
-static inline struct page * rb_insert_page_cache(struct inode * inode,
-unsigned long offset,
-struct rb_node * node)
-{
-   struct page * ret;
-   if ((ret = __rb_insert_page_cache(inode, offset, node)))
-   goto out;
-   rb_insert_color(node, &inode->i_rb_page_cache);
- out:
-   return ret;
-}

+  See Documentation/rbtree.txt for documentation and samples.
 */
 
 #ifndef_LINUX_RBTREE_H
 #define_LINUX_RBTREE_H
 
+#define __UBOOT__
+#ifndef __UBOOT__
+#include 
+#endif
 #include 
 
-struct rb_node
-{
-   unsigned long  rb_parent_color;
-#defineRB_RED  0
-#defineRB_BLACK1
+struct rb_node {
+   unsigned long  __rb_parent_color;
struct rb_node *rb_right;
struct rb_node *rb_left;
 } __attribute__((aligned(sizeof(long;
 /* The alignment might seem pointless, but allegedly CRIS needs it */
 
-struct rb_root
-{
+struct rb_root {
struct rb_node *rb_node;
 };
 
 
-#define rb_parent(r)   ((struct rb_node *)((r)->rb_parent_color & ~3))
-#define rb_color(r)   ((r)->rb_parent_color & 1)
-#define rb_is_red(r)   (!rb_color(r))
-#define rb_is_black(r) rb_color(r)
-#define rb_set_red(r)  do { (r)->rb_parent_color &= ~1; } while (0)
-#define rb_set_black(r)  do { (r)->rb_parent_color |= 1; } while (0)
-
-static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
-{
-   rb->rb_parent_color = (rb->rb_parent_color & 3) | (unsigned long)p;
-}
-static inline void rb_set_color(struct rb_node *rb, int color)
-{

Re: [U-Boot] [PATCH] Fix bug in io64 target (introduced by commit aba27ac)

[Vasili Galka]

Hi Dirk,

On Tue, Jun 17, 2014 at 9:18 AM, Dirk Eibach  wrote:
> Heh. Good catch. thanks!
> But now I'm curious: how did you find this?
>
> Acked-by: dirk.eib...@gdsys.cc
>
> Cheers
> Dirk

I had the following compiler warning (and I actually don't understand
why it was generated here):

In file included from /home/lab/dev/uboot/board/gdsys/405ex/io64.c:25:0:
/home/lab/dev/uboot/board/gdsys/405ex/io64.c: In function 'last_stage_init':
/home/lab/dev/uboot/include/gdsys_fpga.h:35:17: warning: iteration 2u
invokes undefined behavior [-Waggressive-loop-optimizations]
&fpga_ptr[ix]->fld, \
 ^
/home/lab/dev/uboot/board/gdsys/405ex/io64.c:307:4: note: in expansion
of macro 'FPGA_GET_REG'
FPGA_GET_REG(k, hicb_ch[k].status_int, &status);
^
/home/lab/dev/uboot/board/gdsys/405ex/io64.c:305:3: note: containing loop
   for (k = 0; k < 32; ++k) {
   ^

So I had to look on the code...

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

Re: [U-Boot] m68k: Fix warnings with gcc 4.6

[Masahiro Yamada]

Hi Simon,


On Wed, 11 Jun 2014 18:19:28 -0400
Tom Rini  wrote:

> On Sat, Jun 07, 2014 at 10:07:58PM -0600, Simon Glass wrote:
> 
> > Most of the warnings seem to be related to using 'int' for size_t. Change
> > this and fix up the remaining warnings and problems. For bootm, the warning
> > was masked by others, and there is an actual bug in the code.
> > 
> > Signed-off-by: Simon Glass 
> 
> Applied to u-boot/master, thanks!
> 
> -- 
> Tom



Since commit ddc94378d, I see lots of warnings when compiling m68k boards like 
this:




Configuring for M52277EVB - Board: M52277EVB, Options: 
SYS_SPANSION_BOOT,SYS_TEXT_BASE=0x
   textdata bss dec hex filename
 117375   115304092  132997   20785 ./u-boot
common/cli_simple.c: In function 'process_macros':
common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 
'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat]
common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 
'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat]
drivers/mtd/spi/sf.c: In function 'spi_flash_read_write':
drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 
'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 
'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops':
drivers/mtd/spi/sf_ops.c:323:3: warning: format '%zu' expects argument of type 
'size_t', but argument 7 has type 'long unsigned int' [-Wformat]
common/cmd_sf.c: In function 'spi_flash_update_block':
common/cmd_sf.c:154:2: warning: format '%zx' expects argument of type 'size_t', 
but argument 4 has type 'long unsigned int' [-Wformat]
common/cmd_sf.c:161:3: warning: format '%zx' expects argument of type 'size_t', 
but argument 3 has type 'long unsigned int' [-Wformat]
common/cmd_sf.c: In function 'spi_flash_update':
common/cmd_sf.c:218:9: warning: format '%zu' expects argument of type 'size_t', 
but argument 2 has type 'long unsigned int' [-Wformat]
common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 'size_t', 
but argument 2 has type 'long unsigned int' [-Wformat]
common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 'size_t', 
but argument 3 has type 'long unsigned int' [-Wformat]
common/cmd_sf.c: In function 'do_spi_flash_read_write':
common/cmd_sf.c:291:10: warning: format '%zu' expects argument of type 
'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
common/cmd_sf.c: In function 'do_spi_flash_erase':
common/cmd_sf.c:326:9: warning: format '%zu' expects argument of type 'size_t', 
but argument 2 has type 'long unsigned int' [-Wformat]
common/cmd_nvedit.c: In function 'do_env_export':
common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 
'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
common/cmd_nvedit.c: In function 'do_env_import':
common/cmd_nvedit.c:1036:3: warning: format '%zu' expects argument of type 
'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
common/cmd_nvedit.c:1036:3: warning: format '%zX' expects argument of type 
'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
lib/hashtable.c: In function 'hexport_r':
lib/hashtable.c:605:2: warning: format '%zu' expects argument of type 'size_t', 
but argument 5 has type 'long unsigned int' [-Wformat]
lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', 
but argument 2 has type 'long unsigned int' [-Wformat]
lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', 
but argument 3 has type 'long unsigned int' [-Wformat]
lib/hashtable.c: In function 'himport_r':
lib/hashtable.c:793:3: warning: format '%zu' expects argument of type 'size_t', 
but argument 2 has type 'long unsigned int' [-Wformat]


Reverting the following fixes the warnings.

 --- a/arch/m68k/include/asm/posix_types.h
 +++ b/arch/m68k/include/asm/posix_types.h
 @@ -15,7 +15,7 @@ typedef long  __kernel_off_t;
  typedef int__kernel_pid_t;
  typedef unsigned int   __kernel_uid_t;
  typedef unsigned int   __kernel_gid_t;
 -typedef unsigned int   __kernel_size_t;
 +typedef unsigned long  __kernel_size_t;
  typedef int__kernel_ssize_t;
  typedef long   __kernel_ptrdiff_t;
  typedef long   __kernel_time_t;



In m68k Linux,  __kernel_size_t is set to unsigned int.

So I am not sure if your change is good.
(At least for me, it worsens the situation.)

Does it depend on each tool-chain ?


My tool-chain is like this:

$ m68k-linux-gcc -v
Using built-in specs.
COLLECT_GCC=m68k-linux-gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.6.3-nolibc/m68k-linux/bin/../libexec/gcc/m68k-linux/4.6.3/lto-wrapper
Target: m68k-linux
Configured with: /home/tony/buildall/src/gcc/configure --target=m68k-linux 
--host=x86_64-linux-gnu --build=x86_64-linux-gnu --enab

Re: [U-Boot] [PATCH 1/7] nand_spl: remove P1023RDS_NAND support

[Masahiro Yamada]

Hello Scott,

On Mon, 16 Jun 2014 16:46:13 -0500
Scott Wood  wrote:

> FWIW, all p1023rds support can probably be removed.  Very few boards
> were ever sold, and support was recently removed from Linux (commit
> fd7e5b7a8758093781a44df9577fe24e9e11723e).
> 

In that case, could you send a patch to remove it?
Or shall I do that ?

Best Regards
Masahiro Yamada

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

Re: [U-Boot] [PATCH] arm: zynq: fix a bug in Zynq linker script

[Masahiro Yamada]

Hi Michal,

On Thu,  5 Jun 2014 19:47:45 +0900
Masahiro Yamada  wrote:

> Commit 41623c91 moved exception handlers to ".vectores" section
> but it missed to adjust Zynq linker script.
> 
> Zynq boards hang up after relocation because "_start" symbol
> does not point to the correct address and gd->relocaddr gets insane.
> 
> Signed-off-by: Masahiro Yamada 
> Cc: Albert ARIBAUD 
> Cc: Michal Simek 
> Tested-by: Michal Simek 
> ---
>  arch/arm/cpu/armv7/zynq/u-boot.lds | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/cpu/armv7/zynq/u-boot.lds 
> b/arch/arm/cpu/armv7/zynq/u-boot.lds
> index 69500a6..4dc9bb0 100644
> --- a/arch/arm/cpu/armv7/zynq/u-boot.lds
> +++ b/arch/arm/cpu/armv7/zynq/u-boot.lds
> @@ -18,6 +18,7 @@ SECTIONS
>   .text :
>   {
>   *(.__image_copy_start)
> + *(.vectors)
>   CPUDIR/start.o (.text*)
>   *(.text*)
>   }


This bug should be fixed asap.

Because this patch is assigned to you, 
could you apply it and send a pull-request, please?

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

Re: [U-Boot] [PATCH V2 1/2] fs: implement size/fatsize/ext4size

[Lukasz Majewski]

Hi Stephen,

> From: Stephen Warren 
> 
> These commands may be used to determine the size of a file without
> actually reading the whole file content into memory. This may be used
> to determine if the file will fit into the memory buffer that will
> contain it. In particular, the DFU code will use it for this purpose
> in the next commit.
> 
> Signed-off-by: Stephen Warren 
> ---
> v2: New patch

Stephen thanks for the patch.

Acked-by: Lukasz Majewski 

Test HW: Trats2 (Exynos4412):
Tested-by: Lukasz Majewski 

Organizational issue:

File systems don't have their own trees, so if Tom or Marek don't mind
I would like to take this patch to -dfu tree.

Justification:
This patch was written solely for fixing flaws of DFU, so I think that
it is appropriate to take it to -dfu tree and in this way provide
consistency with the following DFU patch.



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/2] dfu: fix some issues with reads/uploads

[Lukasz Majewski]

Hi Stephen,

> From: Stephen Warren 
> 
> DFU read support appears to rely upon dfu->read_medium() updating the
> passed-by-reference len parameter to indicate the remaining size
> available for reading.
> 
> dfu_read_medium_mmc() never does this, and the implementation of
> dfu_read_medium_nand() will only work if called just once; it
> hard-codes the value to the total size of the NAND device
> irrespective of read offset.
> 
> I believe that overloading dfu->read_medium() is confusing. As such,
> this patch introduces a new function dfu->get_medium_size() which can
> be used to explicitly find out the medium size, and nothing else.
> dfu_read() is modified to use this function to set the initial value
> for dfu->r_left, rather than attempting to use the side-effects of
> dfu->read_medium() for this purpose.
> 
> Due to this change, dfu_read() must initially set dfu->b_left to 0,
> since no data has been read.
> 
> dfu_read_buffer_fill() must also be modified not to adjust dfu->r_left
> when simply copying data from dfu->i_buf_start to the upload request
> buffer. r_left represents the amount of data left to be read from HW.
> That value is not affected by the memcpy(), but only by calls to
> dfu->read_medium().
> 
> After this change, I can read from either a 4MB or 1.5MB chunk of a
> 4MB eMMC boot partion with CONFIG_SYS_DFU_DATA_BUF_SIZE==1MB. Without
> this change, attempting to do that would result in DFU read returning
> no data at all due to r_left never being set.
> 
> Signed-off-by: Stephen Warren 

Stephen thanks for the patch.

Acked-by: Lukasz Majewski 

Test HW: Trats2 (Exynos4412):
Tested-by: Lukasz Majewski 

I will pull this patch to -dfu tree when I receive Tom's and Marek's
responde to the first patch in this series.

> ---
> v2:
> * Fix dfu_get_medium_size_mmc() to handle DFU_FS_FAT/EXT5 layouts too,
>   by calling the recently introduced "size" command.
> ---
>  drivers/dfu/dfu.c  | 20 -
>  drivers/dfu/dfu_mmc.c  | 59
> ++
> drivers/dfu/dfu_nand.c |  7 +- drivers/dfu/dfu_ram.c  | 11
> +- include/dfu.h  |  3 +++
>  5 files changed, 79 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index dc09ff6466e6..dab5e7048ed5 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -267,7 +267,6 @@ static int dfu_read_buffer_fill(struct dfu_entity
> *dfu, void *buf, int size) 
>   dfu->i_buf += chunk;
>   dfu->b_left -= chunk;
> - dfu->r_left -= chunk;
>   size -= chunk;
>   buf += chunk;
>   readn += chunk;
> @@ -313,10 +312,19 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
> int size, int blk_seq_num) if (dfu->i_buf_start == NULL)
>   return -ENOMEM;
>  
> - ret = dfu->read_medium(dfu, 0, dfu->i_buf_start,
> &dfu->r_left);
> - if (ret != 0) {
> - debug("%s: failed to get r_left\n",
> __func__);
> - return ret;
> + dfu->r_left = dfu->get_medium_size(dfu);
> + if (dfu->r_left < 0)
> + return dfu->r_left;
> + switch (dfu->layout) {
> + case DFU_RAW_ADDR:
> + case DFU_RAM_ADDR:
> + break;
> + default:
> + if (dfu->r_left >= dfu_buf_size) {
> + printf("%s: File too big for
> buffer\n",
> +__func__);
> + return -EOVERFLOW;
> + }
>   }
>  
>   debug("%s: %s %ld [B]\n", __func__, dfu->name,
> dfu->r_left); @@ -326,7 +334,7 @@ int dfu_read(struct dfu_entity
> *dfu, void *buf, int size, int blk_seq_num) dfu->offset = 0;
>   dfu->i_buf_end = dfu_get_buf() + dfu_buf_size;
>   dfu->i_buf = dfu->i_buf_start;
> - dfu->b_left = min(dfu_buf_size, dfu->r_left);
> + dfu->b_left = 0;
>  
>   dfu->bad_skip = 0;
>  
> diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
> index 63cc876612c9..322bd8c5d2de 100644
> --- a/drivers/dfu/dfu_mmc.c
> +++ b/drivers/dfu/dfu_mmc.c
> @@ -12,6 +12,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
> @@ -113,22 +115,17 @@ static int mmc_file_buffer(struct dfu_entity
> *dfu, void *buf, long *len) static int mmc_file_op(enum dfu_op op,
> struct dfu_entity *dfu, void *buf, long *len)
>  {
> + const char *fsname, *opname;
>   char cmd_buf[DFU_CMD_BUF_SIZE];
>   char *str_env;
>   int ret;
>  
>   switch (dfu->layout) {
>   case DFU_FS_FAT:
> - sprintf(cmd_buf, "fat%s mmc %d:%d 0x%x %s",
> - op == DFU_OP_READ ? "load" : "write",
> - dfu->data.mmc.dev,

[U-Boot] [PATCH 01/10] exynos_fb: Remove usage of static defines

[Ajay Kumar]

Previously, we used to statically assign values for vl_col, vl_row and
vl_bpix using #defines like LCD_XRES, LCD_YRES and LCD_COLOR16.

Introducing the function exynos_lcd_early_init() would take care of this
assignment on the fly by parsing FIMD DT properties, thereby allowing us
to remove LCD_XRES and LCD_YRES from the main config file.

Signed-off-by: Ajay Kumar 
---
 arch/arm/include/asm/arch-exynos/system.h |  1 +
 board/samsung/common/board.c  | 15 +++
 drivers/video/exynos_fb.c | 17 +
 include/configs/exynos5250-dt.h   |  2 --
 include/configs/s5pc210_universal.h   |  3 ---
 include/configs/trats.h   |  3 ---
 include/configs/trats2.h  |  3 ---
 7 files changed, 21 insertions(+), 23 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/system.h 
b/arch/arm/include/asm/arch-exynos/system.h
index 7e2057c..4968d3d 100644
--- a/arch/arm/include/asm/arch-exynos/system.h
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -39,5 +39,6 @@ struct exynos5_sysreg {
 
 void set_usbhost_mode(unsigned int mode);
 void set_system_display_ctrl(void);
+int exynos_lcd_early_init(const void *blob);
 
 #endif /* _EXYNOS4_SYSTEM_H */
diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 9dc7c83..1f6f0a0 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -148,6 +149,20 @@ int board_early_init_f(void)
board_i2c_init(gd->fdt_blob);
 #endif
 
+#if defined(CONFIG_OF_CONTROL) && defined(CONFIG_EXYNOS_FB)
+/*
+ * board_init_f(arch/arm/lib/board.c) calls lcd_setmem() which needs
+ * panel_info.vl_col, panel_info.vl_row and panel_info.vl_bpix, to reserve
+ * FB memory at a very early stage. So, we need to fill panel_info.vl_col,
+ * panel_info.vl_row and panel_info.vl_bpix before lcd_setmem() is called.
+ */
+   err = exynos_lcd_early_init(gd->fdt_blob);
+   if (err) {
+   debug("LCD early init failed\n");
+   return err;
+   }
+#endif
+
return exynos_early_init_f();
 }
 #endif
diff --git a/drivers/video/exynos_fb.c b/drivers/video/exynos_fb.c
index e1e0d80..bc478a9 100644
--- a/drivers/video/exynos_fb.c
+++ b/drivers/video/exynos_fb.c
@@ -27,17 +27,12 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static unsigned int panel_width, panel_height;
 
-/*
- * board_init_f(arch/arm/lib/board.c) calls lcd_setmem() which needs
- * panel_info.vl_col, panel_info.vl_row and panel_info.vl_bpix to reserve
- * FB memory at a very early stage, i.e even before exynos_fimd_parse_dt()
- * is called. So, we are forced to statically assign it.
- */
 #ifdef CONFIG_OF_CONTROL
 vidinfo_t panel_info  = {
-   .vl_col = LCD_XRES,
-   .vl_row = LCD_YRES,
-   .vl_bpix = LCD_COLOR16,
+   /* Insert a value here so that we don't end up in the BSS
+* Reference: drivers/video/tegra.c
+*/
+   .vl_col = -1,
 };
 #endif
 
@@ -141,7 +136,7 @@ static void lcd_panel_on(vidinfo_t *vid)
 }
 
 #ifdef CONFIG_OF_CONTROL
-int exynos_fimd_parse_dt(const void *blob)
+int exynos_lcd_early_init(const void *blob)
 {
unsigned int node;
node = fdtdec_next_compatible(blob, 0, COMPAT_SAMSUNG_EXYNOS_FIMD);
@@ -286,8 +281,6 @@ void lcd_ctrl_init(void *lcdbase)
set_lcd_clk();
 
 #ifdef CONFIG_OF_CONTROL
-   if (exynos_fimd_parse_dt(gd->fdt_blob))
-   debug("Can't get proper panel info\n");
 #ifdef CONFIG_EXYNOS_MIPI_DSIM
exynos_init_dsim_platform_data(&panel_info);
 #endif
diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h
index 9d1d56a..86a2570 100644
--- a/include/configs/exynos5250-dt.h
+++ b/include/configs/exynos5250-dt.h
@@ -65,8 +65,6 @@
 #ifdef CONFIG_LCD
 #define CONFIG_EXYNOS_FB
 #define CONFIG_EXYNOS_DP
-#define LCD_XRES   2560
-#define LCD_YRES   1600
 #define LCD_BPPLCD_COLOR16
 #endif
 #endif  /* __CONFIG_5250_H */
diff --git a/include/configs/s5pc210_universal.h 
b/include/configs/s5pc210_universal.h
index eb046cd..20985da 100644
--- a/include/configs/s5pc210_universal.h
+++ b/include/configs/s5pc210_universal.h
@@ -247,7 +247,4 @@ int universal_spi_read(void);
 #define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 160 * 4) + 54)
 
-#define LCD_XRES   480
-#define LCD_YRES   800
-
 #endif /* __CONFIG_H */
diff --git a/include/configs/trats.h b/include/configs/trats.h
index 90f1962..35c1feb 100644
--- a/include/configs/trats.h
+++ b/include/configs/trats.h
@@ -261,7 +261,4 @@
 #define CONFIG_VIDEO_BMP_GZIP
 #define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE  ((500 * 160 * 4) + 54)
 
-#define LCD_XRES   720
-#define LCD_YRES   1280
-
 #endif /* __CONFIG_H */
diff --git a/include/configs/trats2.h b/include/configs/trats2.h
index 206975b..94c8a9f 100644
--- a/include/configs/trats2.h
+++ b

[U-Boot] [PATCH 05/10] video: Add driver for Parade PS8625 dP to LVDS bridge

[Ajay Kumar]

From: Vadim Bendebury 

The initialization table comes from the "Illustration of I2C command
for initialing PS8625" document supplied by Parade.

Signed-off-by: Vadim Bendebury 
Signed-off-by: Ajay Kumar 
---
 drivers/video/Makefile |   1 +
 drivers/video/parade.c | 220 +
 include/fdtdec.h   |   1 +
 lib/fdtdec.c   |   1 +
 4 files changed, 223 insertions(+)
 create mode 100644 drivers/video/parade.c

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 945f35d..8618590 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -41,3 +41,4 @@ obj-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
 obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
 obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
 obj-$(CONFIG_FORMIKE) += formike.o
+obj-$(CONFIG_VIDEO_PARADE) += parade.o
diff --git a/drivers/video/parade.c b/drivers/video/parade.c
new file mode 100644
index 000..36e5d80
--- /dev/null
+++ b/drivers/video/parade.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright (c) 2014 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+/*
+ * This file is a driver for Parade dP<->LVDS bridges. The original submission
+ * is for the ps8625 chip.
+ */
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Initialization of the chip is a process of writing certaing values into
+ * certain registers over i2c bus. The chip in fact responds to a range of
+ * addresses on the i2c bus, so for each written value three parameters are
+ * required: i2c address, register address and the actual value.
+ *
+ * The base address is derived from the device tree, only address offset is
+ * stored in the table below.
+ */
+/**
+ * struct reg_data() - data for a parade register write
+ *
+ * @addr_offoffset from the i2c base address for parade
+ * @reg_addrregister address to write
+ * @value   value to be written
+ */
+struct reg_data {
+   uint8_t addr_off;
+   uint8_t reg;
+   uint8_t value;
+} _packed;
+
+#define END_OF_TABLE 0xff /* Ficticious offset */
+
+static const struct reg_data parade_values[] = {
+   {0x02, 0xa1, 0x01},  /* HPD low */
+/*
+ * SW setting
+ * [1:0] SW output 1.2V voltage is lower to 96%
+ */
+   {0x04, 0x14, 0x01},
+/*
+ * RCO SS setting
+ * [5:4] = b01 0.5%, b10 1%, b11 1.5%
+ */
+   {0x04, 0xe3, 0x20},
+   {0x04, 0xe2, 0x80}, /* [7] RCO SS enable */
+/*
+ *  RPHY Setting
+ * [3:2] CDR tune wait cycle before
+ * measure for fine tune b00: 1us,
+ * 01: 0.5us, 10:2us, 11:4us.
+ */
+   {0x04, 0x8a, 0x0c},
+   {0x04, 0x89, 0x08}, /* [3] RFD always on */
+/*
+ * CTN lock in/out:
+ * 2ppm/8ppm. Lock out 2
+ * times.
+ */
+   {0x04, 0x71, 0x2d},
+/*
+ * 2.7G CDR settings
+ * NOF=40LSB for HBR CDR setting
+ */
+   {0x04, 0x7d, 0x07},
+   {0x04, 0x7b, 0x00},  /* [1:0] Fmin=+4bands */
+   {0x04, 0x7a, 0xfd},  /* [7:5] DCO_FTRNG=+-40% */
+/*
+ * 1.62G CDR settings
+ * [5:2]NOF=64LSB [1:0]DCO scale is 2/5
+ */
+   {0x04, 0xc0, 0x12},
+   {0x04, 0xc1, 0x92},  /* Gitune=-37% */
+   {0x04, 0xc2, 0x1c},  /* Fbstep=100% */
+   {0x04, 0x32, 0x80},  /* [7] LOS signal disable */
+/*
+ * RPIO Setting
+ * [7:4] LVDS driver bias current :
+ * 75% (250mV swing)
+ */
+   {0x04, 0x00, 0xb0},
+/*
+ * [7:6] Right-bar GPIO output strength is 8mA
+ */
+   {0x04, 0x15, 0x40},
+/* EQ Training State Machine Setting */
+   {0x04, 0x54, 0x10},  /* RCO calibration start */
+/* [4:0] MAX_LANE_COUNT set to one lane */
+   {0x01, 0x02, 0x81},
+/* [4:0] LANE_COUNT_SET set to one lane */
+   {0x01, 0x21, 0x81},
+   {0x00, 0x52, 0x20},
+   {0x00, 0xf1, 0x03},  /* HPD CP toggle enable */
+   {0x00, 0x62, 0x41},
+/* Counter number, add 1ms counter delay */
+   {0x00, 0xf6, 0x01},
+/*
+ * [6]PWM function control by
+ * DPCD0040f[7], default is PWM
+ * block always works.
+ */
+   {0x00, 0x77, 0x06},
+/*
+ * 04h Adjust VTotal tolerance to
+ * fix the 30Hz no display issue
+ */
+   {0x00, 0x4c, 0x04},
+/* DPCD00400='h00, Parade OUI = 'h001cf8 */
+   {0x01, 0xc0, 0x00},
+   {0x01, 0xc1, 0x1c},  /* DPCD00401='h1c */
+   {0x01, 0xc2, 0xf8},  /* DPCD00402='hf8 */
+/*
+ * DPCD403~408 = ASCII code
+ * D2SLV5='h4432534c5635
+ */
+   {0x01, 0xc3, 0x44},
+   {0x01, 0xc4, 0x32},  /* DPCD404 */
+   {0x01, 0xc5, 0x53},  /* DPCD405 */
+   {0x01, 0xc6, 0x4c},  /* DPCD406 */
+   {0x01, 0xc7, 0x56},  /* DPCD407 */
+   {0x01,

[U-Boot] [PATCH 00/10] peach_pit: Add support for FIMD, DP and parade chip

[Ajay Kumar]

This patchset has dependency on Akshay's base patchset for peach_pit:
https://www.mail-archive.com/u-boot@lists.denx.de/msg138595.html

This patchset is actually a rebase of my older patchset:
http://lists.denx.de/pipermail/u-boot/2013-November/166935.html,
and this patchset enables display on exynos5420 based peach_pit board.

The last patch is TEST_ONLY, and it adds support for cros-ec on peach_pit.
Simon will be sending a proper patchset for the same.

Ajay Kumar (9):
  [PATCH 1/10] exynos_fb: Remove usage of static defines
  [PATCH 2/10] arm: exynos: Add RPLL for Exynos5420
  [PATCH 3/10] arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for 
Exynos5420
  [PATCH 4/10] video: exynos_fimd: Add framework to disable FIMD sysmmu
  [PATCH 6/10] ARM: exynos: Add missing declaration for gpio_direction_input
  [PATCH 7/10] exynos5420: add callbacks needed for exynos_fb driver
  [PATCH 8/10] ARM: exynos: peach_pit: Add DT nodes for fimd and parade bridge 
chip
  [PATCH 9/10] CONFIGS: peach_pit: Enable display for peach_pit board

Vadim Bendebury (1):
  [PATCH 5/10] video: Add driver for Parade PS8625 dP to LVDS bridge

Simon Glass (1):
  [TEST_ONLY 10/10] Pit WIP

 arch/arm/cpu/armv7/exynos/clock.c  |  74 -
 arch/arm/cpu/armv7/exynos/clock_init.h |   3 +
 arch/arm/cpu/armv7/exynos/clock_init_exynos5.c |  13 ++
 arch/arm/cpu/armv7/exynos/exynos5_setup.h  |   2 +-
 arch/arm/dts/exynos5420-peach-pit.dts  |  30 
 arch/arm/dts/exynos54xx.dtsi   |  10 ++
 arch/arm/include/asm/arch-exynos/clk.h |   1 +
 arch/arm/include/asm/arch-exynos/gpio.h|   1 +
 arch/arm/include/asm/arch-exynos/system.h  |   4 +
 board/samsung/common/board.c   |  15 ++
 board/samsung/smdk5420/smdk5420.c  | 129 ++-
 doc/device-tree-bindings/video/exynos-fb.txt   |   2 +
 drivers/misc/cros_ec_spi.c |   4 +-
 drivers/power/pmic/Makefile|   3 +-
 drivers/power/pmic/pmic_tps65090_ec.c  | 212 
 drivers/spi/exynos_spi.c   |   9 +-
 drivers/spi/spi.c  |   2 +
 drivers/video/Makefile |   1 +
 drivers/video/exynos_fb.c  |  17 +-
 drivers/video/exynos_fimd.c|  52 ++
 drivers/video/parade.c | 220 +
 include/configs/exynos5-dt.h   |   2 +-
 include/configs/exynos5250-dt.h|   2 -
 include/configs/peach-pit.h|  12 ++
 include/configs/s5pc210_universal.h|   3 -
 include/configs/trats.h|   3 -
 include/configs/trats2.h   |   3 -
 include/fdtdec.h   |   5 +
 include/power/tps65090_pmic.h  |   6 +
 lib/fdtdec.c   |   3 +
 30 files changed, 726 insertions(+), 117 deletions(-)
 create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c
 create mode 100644 drivers/video/parade.c

-- 
1.8.1.2

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

[U-Boot] [PATCH 04/10] video: exynos_fimd: Add framework to disable FIMD sysmmu

[Ajay Kumar]

On Exynos5420 and newer versions, the FIMD sysmmus are in
"on state" by default.
We have to disable them in order to make FIMD DMA work.
This patch adds the required framework to exynos_fimd driver,
and disables FIMD sysmmu on Exynos5420.

Signed-off-by: Ajay Kumar 
---
 arch/arm/dts/exynos54xx.dtsi | 10 ++
 doc/device-tree-bindings/video/exynos-fb.txt |  2 ++
 drivers/video/exynos_fimd.c  | 52 
 include/fdtdec.h |  4 +++
 lib/fdtdec.c |  2 ++
 5 files changed, 70 insertions(+)

diff --git a/arch/arm/dts/exynos54xx.dtsi b/arch/arm/dts/exynos54xx.dtsi
index b9f8e0b..402d12b 100644
--- a/arch/arm/dts/exynos54xx.dtsi
+++ b/arch/arm/dts/exynos54xx.dtsi
@@ -113,6 +113,16 @@
status = "disabled";
};
 
+   fimdm0_sysmmu@0x1464 {
+   compatible = "samsung,sysmmu-fimdm0";
+   reg = <0x1464 0x100>;
+   };
+
+   fimdm1_sysmmu@0x1468 {
+   compatible = "samsung,sysmmu-fimdm1";
+   reg = <0x1468 0x100>;
+   };
+
fimd@1440 {
/* sysmmu is not used in U-Boot */
samsung,disable-sysmmu;
diff --git a/doc/device-tree-bindings/video/exynos-fb.txt 
b/doc/device-tree-bindings/video/exynos-fb.txt
index bb7441c..7d9b995 100644
--- a/doc/device-tree-bindings/video/exynos-fb.txt
+++ b/doc/device-tree-bindings/video/exynos-fb.txt
@@ -55,6 +55,8 @@ Board(panel specific):
samsung,pclk-name: parent clock identifier: 1(MPLL), 2(EPLL), 3(VPLL)
samsung,sclk-div: parent_clock/source_clock ratio
samsung,dual-lcd-enabled: 1 if you support two LCD, else 0
+   samsung,disable-sysmmu: present if you want to disable the sysmmu
+   (needed for Exynos5420 and newer versions)
 
 Example:
 SOC specific part:
diff --git a/drivers/video/exynos_fimd.c b/drivers/video/exynos_fimd.c
index cebbba7..5630d0b 100644
--- a/drivers/video/exynos_fimd.c
+++ b/drivers/video/exynos_fimd.c
@@ -251,6 +251,54 @@ void exynos_fimd_window_off(unsigned int win_id)
writel(cfg, &fimd_ctrl->winshmap);
 }
 
+#ifdef CONFIG_OF_CONTROL
+void exynos_fimd_disable_sysmmu(void)
+{
+   u32 *sysmmufimd;
+   unsigned int node;
+
+   /*
+   * The reset value for FIMD SYSMMU register MMU_CTRL is 3
+   * on Exynos5420 and newer versions.
+   * This means FIMD SYSMMU is on by default on Exynos5420
+   * and newer versions.
+   * Since in u-boot we don't use SYSMMU, we should disable
+   * those FIMD SYSMMU.
+   * Note that there are 2 SYSMMU for FIMD: m0 and m1.
+   * m0 handles windows 0 and 4, and m1 handles windows 1, 2 and 3.
+   * We disable both of them here.
+   */
+   node = fdtdec_next_compatible(gd->fdt_blob, 0,
+   COMPAT_SAMSUNG_EXYNOS_FIMD_SYSMMU0);
+   if (node <= 0) {
+   debug("exynos_fb: Can't get device node for fimd dma m0\n");
+   return;
+   }
+
+   sysmmufimd = (u32 *)fdtdec_get_addr(gd->fdt_blob, node, "reg");
+   if (!sysmmufimd) {
+   debug("Can't get base address for sysmmu fimdm0");
+   return;
+   }
+
+   writel(0x0, sysmmufimd);
+
+   node = fdtdec_next_compatible(gd->fdt_blob, 0,
+   COMPAT_SAMSUNG_EXYNOS_FIMD_SYSMMU1);
+   if (node <= 0) {
+   debug("exynos_fb: Can't get device node for fimd dma m1\n");
+   return;
+   }
+
+   sysmmufimd = (u32 *)fdtdec_get_addr(gd->fdt_blob, node, "reg");
+   if (!sysmmufimd) {
+   debug("Can't get base address for sysmmu fimdm0");
+   return;
+   }
+
+   writel(0x0, sysmmufimd);
+}
+#endif
 
 void exynos_fimd_lcd_init(vidinfo_t *vid)
 {
@@ -268,6 +316,10 @@ void exynos_fimd_lcd_init(vidinfo_t *vid)
node, "reg");
if (fimd_ctrl == NULL)
debug("Can't get the FIMD base address\n");
+
+   if (fdtdec_get_bool(gd->fdt_blob, node, "samsung,disable-sysmmu"))
+   exynos_fimd_disable_sysmmu();
+
 #else
fimd_ctrl = (struct exynos_fb *)samsung_get_base_fimd();
 #endif
diff --git a/include/fdtdec.h b/include/fdtdec.h
index a7e6ee7..3329623 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -94,6 +94,10 @@ enum fdt_compat_id {
COMPAT_SANDBOX_LCD_SDL, /* Sandbox LCD emulation with SDL */
COMPAT_TI_TPS65090, /* Texas Instrument TPS65090 */
COMPAT_NXP_PTN3460, /* NXP PTN3460 DP/LVDS bridge */
+   /* Exynos Display controller sysmmu0 */
+   COMPAT_SAMSUNG_EXYNOS_FIMD_SYSMMU0,
+   /* Exynos Display controller sysmmu1 */
+   COMPAT_SAMSUNG_EXYNOS_FIMD_SYSMMU1,
 
COMPAT_COUNT,
 };
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 13d3d2f..701169e 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -

[U-Boot] [PATCH 03/10] arm: exynos: Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420

[Ajay Kumar]

Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 needed by
exynos video driver.
Also, configure ACLK_400_DISP1 as the parent for MUX_ACLK_400_DISP1_SUB_SEL.

Signed-off-by: Ajay Kumar 
---
 arch/arm/cpu/armv7/exynos/clock.c | 74 +--
 arch/arm/cpu/armv7/exynos/exynos5_setup.h |  2 +-
 arch/arm/include/asm/arch-exynos/clk.h|  1 +
 3 files changed, 73 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
b/arch/arm/cpu/armv7/exynos/clock.c
index 400d134..c29b12d 100644
--- a/arch/arm/cpu/armv7/exynos/clock.c
+++ b/arch/arm/cpu/armv7/exynos/clock.c
@@ -82,7 +82,8 @@ static int exynos_get_pll_clk(int pllreg, unsigned int r, 
unsigned int k)
 * VPLL_CON: MIDV [24:16]
 * BPLL_CON: MIDV [25:16]: Exynos5
 */
-   if (pllreg == APLL || pllreg == MPLL || pllreg == BPLL)
+   if (pllreg == APLL || pllreg == MPLL || pllreg == BPLL ||
+   pllreg == SPLL)
mask = 0x3ff;
else
mask = 0x1ff;
@@ -391,6 +392,9 @@ static unsigned long exynos5420_get_pll_clk(int pllreg)
r = readl(&clk->rpll_con0);
k = readl(&clk->rpll_con1);
break;
+   case SPLL:
+   r = readl(&clk->spll_con0);
+   break;
default:
printf("Unsupported PLL (%d)\n", pllreg);
return 0;
@@ -1027,6 +1031,40 @@ static unsigned long exynos5_get_lcd_clk(void)
return pclk;
 }
 
+static unsigned long exynos5420_get_lcd_clk(void)
+{
+   struct exynos5420_clock *clk =
+   (struct exynos5420_clock *)samsung_get_base_clock();
+   unsigned long pclk, sclk;
+   unsigned int sel;
+   unsigned int ratio;
+
+   /*
+* CLK_SRC_DISP10
+* FIMD1_SEL [4]
+* 0: SCLK_RPLL
+* 1: SCLK_SPLL
+*/
+   sel = readl(&clk->src_disp10);
+   sel &= (1 << 4);
+
+   if (sel)
+   sclk = get_pll_clk(SPLL);
+   else
+   sclk = get_pll_clk(RPLL);
+
+   /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO [3:0]
+*/
+   ratio = readl(&clk->div_disp10);
+   ratio = ratio & 0xf;
+
+   pclk = sclk / (ratio + 1);
+
+   return pclk;
+}
+
 void exynos4_set_lcd_clk(void)
 {
struct exynos4_clock *clk =
@@ -1131,6 +1169,33 @@ void exynos5_set_lcd_clk(void)
clrsetbits_le32(&clk->div_disp1_0, 0xf, 0x0);
 }
 
+void exynos5420_set_lcd_clk(void)
+{
+   struct exynos5420_clock *clk =
+   (struct exynos5420_clock *)samsung_get_base_clock();
+   unsigned int cfg;
+
+   /*
+* CLK_SRC_DISP10
+* FIMD1_SEL [4]
+* 0: SCLK_RPLL
+* 1: SCLK_SPLL
+*/
+   cfg = readl(&clk->src_disp10);
+   cfg &= ~(0x1 << 4);
+   cfg |= (0 << 4);
+   writel(cfg, &clk->src_disp10);
+
+   /*
+* CLK_DIV_DISP10
+* FIMD1_RATIO  [3:0]
+*/
+   cfg = readl(&clk->div_disp10);
+   cfg &= ~(0xf << 0);
+   cfg |= (0 << 0);
+   writel(cfg, &clk->div_disp10);
+}
+
 void exynos4_set_mipi_clk(void)
 {
struct exynos4_clock *clk =
@@ -1602,14 +1667,17 @@ unsigned long get_lcd_clk(void)
 {
if (cpu_is_exynos4())
return exynos4_get_lcd_clk();
-   else
-   return exynos5_get_lcd_clk();
+   else if (proid_is_exynos5420())
+   return exynos5420_get_lcd_clk();
+   return exynos5_get_lcd_clk();
 }
 
 void set_lcd_clk(void)
 {
if (cpu_is_exynos4())
exynos4_set_lcd_clk();
+   else if (proid_is_exynos5420())
+   exynos5420_set_lcd_clk();
else
exynos5_set_lcd_clk();
 }
diff --git a/arch/arm/cpu/armv7/exynos/exynos5_setup.h 
b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
index db8ea86..5eac9cf 100644
--- a/arch/arm/cpu/armv7/exynos/exynos5_setup.h
+++ b/arch/arm/cpu/armv7/exynos/exynos5_setup.h
@@ -779,7 +779,7 @@
 #define CLK_SRC_TOP2_VAL   0x11101000
 #define CLK_SRC_TOP3_VAL   0x
 #define CLK_SRC_TOP4_VAL   0x0111
-#define CLK_SRC_TOP5_VAL   0x1100
+#define CLK_SRC_TOP5_VAL   0x1101
 #define CLK_SRC_TOP6_VAL   0x0111
 #define CLK_SRC_TOP7_VAL   0x00022200
 
diff --git a/arch/arm/include/asm/arch-exynos/clk.h 
b/arch/arm/include/asm/arch-exynos/clk.h
index ffbc07e..db24dc0 100644
--- a/arch/arm/include/asm/arch-exynos/clk.h
+++ b/arch/arm/include/asm/arch-exynos/clk.h
@@ -15,6 +15,7 @@
 #define VPLL   4
 #define BPLL   5
 #define RPLL   6
+#define SPLL   7
 
 #define MASK_PRE_RATIO(x)  (0xff << ((x << 4) + 8))
 #define MASK_RATIO(x)  (0xf << (x << 4))
-- 
1.8.1.2

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

[U-Boot] [PATCH 06/10] ARM: exynos: Add missing declaration for gpio_direction_input

[Ajay Kumar]

This patch adds missing declaration for gpio_direction_input
function, thereby helps in resolving compilation warnings.

Signed-off-by: Ajay Kumar 
---
 arch/arm/include/asm/arch-exynos/gpio.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/arch-exynos/gpio.h 
b/arch/arm/include/asm/arch-exynos/gpio.h
index be5113f..8fb5c23 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -1504,6 +1504,7 @@ static const struct gpio_name_num_table 
exynos5420_gpio_table[] = {
 void gpio_cfg_pin(int gpio, int cfg);
 void gpio_set_pull(int gpio, int mode);
 void gpio_set_drv(int gpio, int mode);
+int gpio_direction_input(unsigned gpio);
 int gpio_direction_output(unsigned gpio, int value);
 int gpio_set_value(unsigned gpio, int value);
 int gpio_get_value(unsigned gpio);
-- 
1.8.1.2

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

[U-Boot] [PATCH 02/10] arm: exynos: Add RPLL for Exynos5420

[Ajay Kumar]

RPLL is needed to drive the LCD panel on Exynos5420 based boards.

Signed-off-by: Ajay Kumar 
---
 arch/arm/cpu/armv7/exynos/clock_init.h |  3 +++
 arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 +
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/cpu/armv7/exynos/clock_init.h 
b/arch/arm/cpu/armv7/exynos/clock_init.h
index a875d0b..fce502f 100644
--- a/arch/arm/cpu/armv7/exynos/clock_init.h
+++ b/arch/arm/cpu/armv7/exynos/clock_init.h
@@ -75,6 +75,9 @@ struct mem_timings {
unsigned spll_mdiv;
unsigned spll_pdiv;
unsigned spll_sdiv;
+   unsigned rpll_mdiv;
+   unsigned rpll_pdiv;
+   unsigned rpll_sdiv;
unsigned pclk_cdrex_ratio;
unsigned direct_cmd_msr[MEM_TIMINGS_MSR_COUNT];
 
diff --git a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c 
b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
index 1d6977f..b6a9bc1 100644
--- a/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
+++ b/arch/arm/cpu/armv7/exynos/clock_init_exynos5.c
@@ -179,6 +179,10 @@ struct mem_timings mem_timings[] = {
.spll_mdiv = 0xc8,
.spll_pdiv = 0x3,
.spll_sdiv = 0x2,
+   /* RPLL @70.5Mhz */
+   .rpll_mdiv = 0x5E,
+   .rpll_pdiv = 0x2,
+   .rpll_sdiv = 0x4,
 
.direct_cmd_msr = {
0x00020018, 0x0003, 0x00010046, 0x0d70,
@@ -800,6 +804,7 @@ static void exynos5420_system_clock_init(void)
writel(mem->ipll_pdiv * PLL_LOCK_FACTOR, &clk->ipll_lock);
writel(mem->spll_pdiv * PLL_LOCK_FACTOR, &clk->spll_lock);
writel(mem->kpll_pdiv * PLL_LOCK_FACTOR, &clk->kpll_lock);
+   writel(mem->rpll_pdiv * PLL_X_LOCK_FACTOR, &clk->rpll_lock);
 
setbits_le32(&clk->src_cpu, MUX_HPM_SEL_MASK);
 
@@ -898,6 +903,14 @@ static void exynos5420_system_clock_init(void)
while ((readl(&clk->spll_con0) & PLL_LOCKED) == 0)
;
 
+   /* Set RPLL */
+   writel(RPLL_CON2_VAL, &clk->rpll_con2);
+   writel(RPLL_CON1_VAL, &clk->rpll_con1);
+   val = set_pll(mem->rpll_mdiv, mem->rpll_pdiv, mem->rpll_sdiv);
+   writel(val, &clk->rpll_con0);
+   while ((readl(&clk->rpll_con0) & PLL_LOCKED) == 0)
+   ;
+
writel(CLK_DIV_CDREX0_VAL, &clk->div_cdrex0);
writel(CLK_DIV_CDREX1_VAL, &clk->div_cdrex1);
 
-- 
1.8.1.2

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

[U-Boot] [PATCH 09/10] CONFIGS: peach-pit: Enable display for peach_pit board

[Ajay Kumar]

Enable drivers for FIMD, DP and parade bridge chip.

Signed-off-by: Ajay Kumar 
---
 include/configs/peach-pit.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/configs/peach-pit.h b/include/configs/peach-pit.h
index 76b8d7a..88c093f 100644
--- a/include/configs/peach-pit.h
+++ b/include/configs/peach-pit.h
@@ -22,4 +22,14 @@
 #define CONFIG_SYS_PROMPT  "Peach # "
 #define CONFIG_IDENT_STRING" for Peach"
 
+#define CONFIG_VIDEO_PARADE
+
+/* Display */
+#define CONFIG_LCD
+#ifdef CONFIG_LCD
+#define CONFIG_EXYNOS_FB
+#define CONFIG_EXYNOS_DP
+#define LCD_BPPLCD_COLOR16
+#endif
+
 #endif /* __CONFIG_PEACH_PIT_H */
-- 
1.8.1.2

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

[U-Boot] [PATCH 08/10] ARM: exynos: peach_pit: Add DT nodes for fimd and parade bridge chip

[Ajay Kumar]

This patch adds DT properties for fimd and the parade bridge chip
present on peach_pit. The panel supports 1366x768 resolution.

Signed-off-by: Ajay Kumar 
---
 arch/arm/dts/exynos5420-peach-pit.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/dts/exynos5420-peach-pit.dts 
b/arch/arm/dts/exynos5420-peach-pit.dts
index 8d148af..3ed70a8 100644
--- a/arch/arm/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/dts/exynos5420-peach-pit.dts
@@ -63,6 +63,11 @@
  reg = <0x20>;
  compatible = "maxim,max98090-codec";
   };
+
+   edp-lvds-bridge@48 {
+   compatible = "parade,ps8625";
+   reg = <0x48>;
+   };
};
 
 sound@383 {
@@ -124,4 +129,29 @@
xhci@1240 {
samsung,vbus-gpio = <&gpio 0x41 0>; /* H01 */
};
+
+   fimd@1440 {
+   samsung,vl-freq = <60>;
+   samsung,vl-col = <1366>;
+   samsung,vl-row = <768>;
+   samsung,vl-width = <1366>;
+   samsung,vl-height = <768>;
+
+   samsung,vl-clkp;
+   samsung,vl-dp;
+   samsung,vl-bpix = <4>;
+
+   samsung,vl-hspw = <32>;
+   samsung,vl-hbpd = <40>;
+   samsung,vl-hfpd = <40>;
+   samsung,vl-vspw = <6>;
+   samsung,vl-vbpd = <10>;
+   samsung,vl-vfpd = <12>;
+   samsung,vl-cmd-allow-len = <0xf>;
+
+   samsung,winid = <3>;
+   samsung,interface-mode = <1>;
+   samsung,dp-enabled = <1>;
+   samsung,dual-lcd-enabled = <0>;
+   };
 };
-- 
1.8.1.2

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

[U-Boot] [PATCH 07/10] exynos5420: add callbacks needed for exynos_fb driver

[Ajay Kumar]

Add initialization code for peach_pit panel, parade bridge chip,
and backlight.

Signed-off-by: Ajay Kumar 
---
 arch/arm/include/asm/arch-exynos/system.h |   3 +
 board/samsung/smdk5420/smdk5420.c | 129 +++---
 2 files changed, 50 insertions(+), 82 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/system.h 
b/arch/arm/include/asm/arch-exynos/system.h
index 4968d3d..320763f 100644
--- a/arch/arm/include/asm/arch-exynos/system.h
+++ b/arch/arm/include/asm/arch-exynos/system.h
@@ -41,4 +41,7 @@ void set_usbhost_mode(unsigned int mode);
 void set_system_display_ctrl(void);
 int exynos_lcd_early_init(const void *blob);
 
+/* Initialize the Parade dP<->LVDS bridge if present */
+int parade_init(const void *blob);
+
 #endif /* _EXYNOS4_SYSTEM_H */
diff --git a/board/samsung/smdk5420/smdk5420.c 
b/board/samsung/smdk5420/smdk5420.c
index 183c522..270ee83 100644
--- a/board/samsung/smdk5420/smdk5420.c
+++ b/board/samsung/smdk5420/smdk5420.c
@@ -10,11 +10,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -40,95 +43,57 @@ int exynos_init(void)
 }
 
 #ifdef CONFIG_LCD
-void cfg_lcd_gpio(void)
+static int has_edp_bridge(void)
 {
-   /* For Backlight */
-   gpio_cfg_pin(EXYNOS5420_GPIO_B20, S5P_GPIO_OUTPUT);
-   gpio_set_value(EXYNOS5420_GPIO_B20, 1);
+   int node;
+
+   node = fdtdec_next_compatible(gd->fdt_blob, 0, COMPAT_PARADE_PS8625);
 
-   /* LCD power on */
-   gpio_cfg_pin(EXYNOS5420_GPIO_X15, S5P_GPIO_OUTPUT);
-   gpio_set_value(EXYNOS5420_GPIO_X15, 1);
+   /* No node for bridge in device tree. */
+   if (node <= 0)
+   return 0;
 
-   /* Set Hotplug detect for DP */
-   gpio_cfg_pin(EXYNOS5420_GPIO_X07, S5P_GPIO_FUNC(0x3));
+   /* Default is with bridge ic */
+   return 1;
 }
 
-vidinfo_t panel_info = {
-   .vl_freq= 60,
-   .vl_col = 2560,
-   .vl_row = 1600,
-   .vl_width   = 2560,
-   .vl_height  = 1600,
-   .vl_clkp= CONFIG_SYS_LOW,
-   .vl_hsp = CONFIG_SYS_LOW,
-   .vl_vsp = CONFIG_SYS_LOW,
-   .vl_dp  = CONFIG_SYS_LOW,
-   .vl_bpix= 4,/* LCD_BPP = 2^4, for output conosle on LCD */
-
-   /* wDP panel timing infomation */
-   .vl_hspw= 32,
-   .vl_hbpd= 80,
-   .vl_hfpd= 48,
-
-   .vl_vspw= 6,
-   .vl_vbpd= 37,
-   .vl_vfpd= 3,
-   .vl_cmd_allow_len = 0xf,
-
-   .win_id = 3,
-   .cfg_gpio   = cfg_lcd_gpio,
-   .backlight_on   = NULL,
-   .lcd_power_on   = NULL,
-   .reset_lcd  = NULL,
-   .dual_lcd_enabled = 0,
-
-   .init_delay = 0,
-   .power_on_delay = 0,
-   .reset_delay= 0,
-   .interface_mode = FIMD_RGB_INTERFACE,
-   .dp_enabled = 1,
-};
-
-static struct edp_device_info edp_info = {
-   .disp_info = {
-   .h_res = 2560,
-   .h_sync_width = 32,
-   .h_back_porch = 80,
-   .h_front_porch = 48,
-   .v_res = 1600,
-   .v_sync_width  = 6,
-   .v_back_porch = 37,
-   .v_front_porch = 3,
-   .v_sync_rate = 60,
-   },
-   .lt_info = {
-   .lt_status = DP_LT_NONE,
-   },
-   .video_info = {
-   .master_mode = 0,
-   .bist_mode = DP_DISABLE,
-   .bist_pattern = NO_PATTERN,
-   .h_sync_polarity = 0,
-   .v_sync_polarity = 0,
-   .interlaced = 0,
-   .color_space = COLOR_RGB,
-   .dynamic_range = VESA,
-   .ycbcr_coeff = COLOR_YCBCR601,
-   .color_depth = COLOR_8,
-   },
-};
-
-static struct exynos_dp_platform_data dp_platform_data = {
-   .phy_enable = set_dp_phy_ctrl,
-   .edp_dev_info   = &edp_info,
-};
-
-void init_panel_info(vidinfo_t *vid)
+void exynos_lcd_power_on(void)
 {
-   vid->rgb_mode   = MODE_RGB_P;
+   int ret;
+
+#ifdef CONFIG_POWER_TPS65090
+   ret = tps65090_init();
+   if (ret < 0) {
+   printf("%s: tps65090_init() failed\n", __func__);
+   return;
+   }
+
+   tps65090_fet_enable(6);
+#endif
+
+   mdelay(5);
+
+   /* TODO(ajaykumar...@samsung.com): Use device tree */
+   gpio_direction_output(EXYNOS5420_GPIO_X35, 1);  /* EDP_SLP# */
+   mdelay(10);
+   gpio_direction_output(EXYNOS5420_GPIO_Y77, 1);  /* EDP_RST# */
+   gpio_direction_input(EXYNOS5420_GPIO_X26);  /* EDP_HPD */
+   gpio_set_pull(EXYNOS5420_GPIO_X26, S5P_GPIO_PULL_NONE);
 
-   exynos_set_dp_platform_data(&dp_platform_data);
+   if (has_edp_bridge())
+   if (parade_init(gd->fdt_blob))
+   printf("%s: ps8625_init() failed\n", __func__);
+}
+
+void exynos_backlight_

[U-Boot] [PATCH 10/10] Pit WIP

[Ajay Kumar]

From: Simon Glass 

WIP patch to enable cros-ec on peach_pit.

Signed-off-by: Simon Glass 
---
 drivers/misc/cros_ec_spi.c|   4 +-
 drivers/power/pmic/Makefile   |   3 +-
 drivers/power/pmic/pmic_tps65090_ec.c | 212 ++
 drivers/spi/exynos_spi.c  |   9 +-
 drivers/spi/spi.c |   2 +
 include/configs/exynos5-dt.h  |   2 +-
 include/configs/peach-pit.h   |   2 +
 include/power/tps65090_pmic.h |   6 +
 8 files changed, 232 insertions(+), 8 deletions(-)
 create mode 100644 drivers/power/pmic/pmic_tps65090_ec.c

diff --git a/drivers/misc/cros_ec_spi.c b/drivers/misc/cros_ec_spi.c
index 7df709c..015333f 100644
--- a/drivers/misc/cros_ec_spi.c
+++ b/drivers/misc/cros_ec_spi.c
@@ -98,7 +98,7 @@ int cros_ec_spi_command(struct cros_ec_dev *dev, uint8_t cmd, 
int cmd_version,
}
 
out = dev->dout;
-   out[0] = cmd_version;
+   out[0] = EC_CMD_VERSION0 + cmd_version;
out[1] = cmd;
out[2] = (uint8_t)dout_len;
memcpy(out + 3, dout, dout_len);
@@ -165,7 +165,7 @@ int cros_ec_spi_decode_fdt(struct cros_ec_dev *dev, const 
void *blob)
  */
 int cros_ec_spi_init(struct cros_ec_dev *dev, const void *blob)
 {
-   dev->spi = spi_setup_slave_fdt(blob, dev->parent_node, dev->node);
+   dev->spi = spi_setup_slave_fdt(blob, dev->node, dev->parent_node);
if (!dev->spi) {
debug("%s: Could not setup SPI slave\n", __func__);
return -1;
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index a472f61..e7b07eb 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -11,7 +11,8 @@ obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
 obj-$(CONFIG_POWER_PFUZE100) += pmic_pfuze100.o
-obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
+obj-$(CONFIG_POWER_TPS65090_I2C) += pmic_tps65090.o
+obj-$(CONFIG_POWER_TPS65090_EC) += pmic_tps65090_ec.o
 obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 obj-$(CONFIG_POWER_TPS65218) += pmic_tps65218.o
 obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
diff --git a/drivers/power/pmic/pmic_tps65090_ec.c 
b/drivers/power/pmic/pmic_tps65090_ec.c
new file mode 100644
index 000..93b7923
--- /dev/null
+++ b/drivers/power/pmic/pmic_tps65090_ec.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define TPS65090_ADDR  0x48
+
+static struct tps65090 {
+   struct cros_ec_dev *dev;/* The CROS_EC device */
+} config;
+
+/* TPS65090 register addresses */
+enum {
+   REG_FET1_CTRL = 0x0f,
+   REG_FET2_CTRL,
+   REG_FET3_CTRL,
+   REG_FET4_CTRL,
+   REG_FET5_CTRL,
+   REG_FET6_CTRL,
+   REG_FET7_CTRL,
+   TPS65090_NUM_REGS,
+};
+
+enum {
+   MAX_FET_NUM = 7,
+   MAX_CTRL_READ_TRIES = 5,
+
+   /* TPS65090 FET_CTRL register values */
+   FET_CTRL_TOFET  = 1 << 7,  /* Timeout, startup, overload */
+   FET_CTRL_PGFET  = 1 << 4,  /* Power good for FET status */
+   FET_CTRL_WAIT   = 3 << 2,  /* Overcurrent timeout max */
+   FET_CTRL_ADENFET= 1 << 1,  /* Enable output auto discharge */
+   FET_CTRL_ENFET  = 1 << 0,  /* Enable FET */
+};
+
+/**
+ * tps65090_read - read a byte from tps6090
+ *
+ * @param reg  The register address to read from.
+ * @param val  We'll return value value read here.
+ * @return 0 if ok; error if EC returns failure.
+ */
+static int tps65090_read(u32 reg, u8 *val)
+{
+   return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
+   val, 1, true);
+}
+
+/**
+ * tps65090_write - write a byte to tps6090
+ *
+ * @param reg  The register address to write to.
+ * @param val  The value to write.
+ * @return 0 if ok; error if EC returns failure.
+ */
+static int tps65090_write(u32 reg, u8 val)
+{
+   return cros_ec_i2c_xfer(config.dev, TPS65090_ADDR, reg, 1,
+   &val, 1, false);
+}
+
+/**
+ * Checks for a valid FET number
+ *
+ * @param fet_id   FET number to check
+ * @return 0 if ok, -1 if FET value is out of range
+ */
+static int tps65090_check_fet(unsigned int fet_id)
+{
+   if (fet_id == 0 || fet_id > MAX_FET_NUM) {
+   debug("parameter fet_id is out of range, %u not in 1 ~ %u\n",
+ fet_id, MAX_FET_NUM);
+   return -1;
+   }
+
+   return 0;
+}
+
+/**
+ * Set the power state for a FET
+ 

Re: [U-Boot] [PATCH] dfu: add write error handling

[Lukasz Majewski]

Hi Stephen,

> From: Stephen Warren 
> 
> Fix calls to dfu_write() and dfu_flush() to detect errors in the I/O
> itself. This could happen due to problems with the storage medium, or
> simply when trying to write a FAT/ext file that is larger than the
> buffer dfu_mmc.c maintains for this purpose.
> 
> Signal the error by switching the DFU state/status. This will be
> picked up by the DFU client when it sends the next DFU request. Note
> that errors can't simply be returned from e.g.
> dnload_request_complete(), since that function has no way to pass
> errors back to the DFU client; a call to dnload_request_complete()
> simply means that a USB OUT completed.
> 
> This error state/status needs to be cleared when the next DFU client
> connects. While there is a DFU_CLRSTATUS request, no DFU client seems
> to send this. Hence, clear this when selecting the USB alternate
> setting on the USB interface.
> 
> Finally, dfu.c relies on a call to dfu_flush() to clear up the
> internal state of the write transaction. Now that errors in
> dfu_write() are detected, dfu_flush() may no longer be called for
> every transaction. Separate out the cleanup code into a new function,
> and call it whenever dfu_write() fails, as well as from any call to
> dfu_flush().
> 
> Signed-off-by: Stephen Warren 
> ---
> This probably depends on "dfu: fix some issues with reads/uploads",
> for context if nothing else.

Stephen, thanks for the patch.

Acked-by: Lukasz Majewski 

Test HW: Exynos4412 - Trats2

Tested-by: Lukasz Majewski 

> ---
>  drivers/dfu/dfu.c  | 46
> --
> drivers/usb/gadget/f_dfu.c | 20  2 files changed,
> 44 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index dab5e7048ed5..1bf66d0613c9 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -147,6 +147,19 @@ static int dfu_write_buffer_drain(struct
> dfu_entity *dfu) return ret;
>  }
>  
> +void dfu_write_transaction_cleanup(struct dfu_entity *dfu)
> +{
> + /* clear everything */
> + dfu_free_buf();
> + dfu->crc = 0;
> + dfu->offset = 0;
> + dfu->i_blk_seq_num = 0;
> + dfu->i_buf_start = dfu_buf;
> + dfu->i_buf_end = dfu_buf;
> + dfu->i_buf = dfu->i_buf_start;
> + dfu->inited = 0;
> +}
> +
>  int dfu_flush(struct dfu_entity *dfu, void *buf, int size, int
> blk_seq_num) {
>   int ret = 0;
> @@ -162,23 +175,14 @@ int dfu_flush(struct dfu_entity *dfu, void
> *buf, int size, int blk_seq_num) printf("\nDFU complete %s:
> 0x%08x\n", dfu_hash_algo->name, dfu->crc);
>  
> - /* clear everything */
> - dfu_free_buf();
> - dfu->crc = 0;
> - dfu->offset = 0;
> - dfu->i_blk_seq_num = 0;
> - dfu->i_buf_start = dfu_buf;
> - dfu->i_buf_end = dfu_buf;
> - dfu->i_buf = dfu->i_buf_start;
> - dfu->inited = 0;
> + dfu_write_transaction_cleanup(dfu);
>  
>   return ret;
>  }
>  
>  int dfu_write(struct dfu_entity *dfu, void *buf, int size, int
> blk_seq_num) {
> - int ret = 0;
> - int tret;
> + int ret;
>  
>   debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x offset:
> 0x%llx bufoffset: 0x%x\n", __func__, dfu->name, buf, size,
> blk_seq_num, dfu->offset, @@ -202,6 +206,7 @@ int dfu_write(struct
> dfu_entity *dfu, void *buf, int size, int blk_seq_num) if
> (dfu->i_blk_seq_num != blk_seq_num) { printf("%s: Wrong sequence
> number! [%d] [%d]\n", __func__, dfu->i_blk_seq_num, blk_seq_num);
> + dfu_write_transaction_cleanup(dfu);
>   return -1;
>   }
>  
> @@ -223,15 +228,18 @@ int dfu_write(struct dfu_entity *dfu, void
> *buf, int size, int blk_seq_num) 
>   /* flush buffer if overflow */
>   if ((dfu->i_buf + size) > dfu->i_buf_end) {
> - tret = dfu_write_buffer_drain(dfu);
> - if (ret == 0)
> - ret = tret;
> + ret = dfu_write_buffer_drain(dfu);
> + if (ret) {
> + dfu_write_transaction_cleanup(dfu);
> + return ret;
> + }
>   }
>  
>   /* we should be in buffer now (if not then size too large) */
>   if ((dfu->i_buf + size) > dfu->i_buf_end) {
>   error("Buffer overflow! (0x%p + 0x%x > 0x%p)\n",
> dfu->i_buf, size, dfu->i_buf_end);
> + dfu_write_transaction_cleanup(dfu);
>   return -1;
>   }
>  
> @@ -240,12 +248,14 @@ int dfu_write(struct dfu_entity *dfu, void
> *buf, int size, int blk_seq_num) 
>   /* if end or if buffer full flush */
>   if (size == 0 || (dfu->i_buf + size) > dfu->i_buf_end) {
> - tret = dfu_write_buffer_drain(dfu);
> - if (ret == 0)
> - ret = tret;
> + ret = dfu_write_buffer_drain(dfu);
> + if (ret) {
> + dfu_write_transaction_cleanup(dfu);
> + return ret;
> + }
>   }
>  
> - return ret;
> + return 0;
>  }
>

Re: [U-Boot] [PATCH v2] test:dfu: Add test scripts for testing DFU regression

[Lukasz Majewski]

Hi Simon,

> Hi Lukasz,
> 
> On 3 June 2014 03:54, Lukasz Majewski  wrote:
> > This commit adds test scripts for testing if any commit has
> > introduced regression to the DFU subsystem.
> >
> > It uses md5 to test if sent and received file is correct.
> > The test detailed description is available at README file.
> >
> > Signed-off-by: Lukasz Majewski 
> > ---
> > Changes for v2:
> > - Rename DESCRIPTION.TXT to README
> > - Introduction of COLOUR_* variables to hold code necessary to
> > change console color
> > - File to create initial setup - dfu_gadget_test_init.sh has been
> > added
> > - Test files are now automatically generated with the above script
> 
> Looks good, but a few comments below.
> 
> > ---
> >  test/dfu/README  |   27 
> >  test/dfu/dfu_gadget_test.sh  |   88
> > ++
> > test/dfu/dfu_gadget_test_init.sh |   34 +++ 3 files
> > changed, 149 insertions(+) create mode 100644 test/dfu/README
> >  create mode 100755 test/dfu/dfu_gadget_test.sh
> >  create mode 100755 test/dfu/dfu_gadget_test_init.sh
> >
> > diff --git a/test/dfu/README b/test/dfu/README
> > new file mode 100644
> > index 000..f8f5a43
> > --- /dev/null
> > +++ b/test/dfu/README
> > @@ -0,0 +1,27 @@
> > +DFU TEST CASE DESCRIPTION:
> > +
> > +The prerequisites for running this script are assured by
> > +dfu_gadget_test_init.sh script.
> > +In this file user is able to generate their own set of test files
> > by altering +the default set of TEST_FILES_SIZES variable
> > +
> > +Moreover, on a target device the "dfu_alt_info" env variable
> > should be extended +to have "dfu_test.bin fat 0 6;" \ entry ([1]).
> > For reference please consult the +config file for TRATS/TRATS2
> > devices (./include/configs/trats{2}.h) +
> > +One can use fat, ext4 or any other supported file system, which
> > can be +created in a convenient way with exporting partitions via
> > UMS (ums 0 mmc 0) +and using standard tools on host (like
> > mkfs.ext4). +
> > +Example usage:
> > +1. On the target:
> > +   env default -a
> > +   dfu 0 mmc 0
> > +2. On the host:
> > +   ./dfu_gadget_test.sh 11
> > +
> > +where 11 is the mumber of alt setting corresponding to entry [1].
> > +
> > +The number of the alt setting entry can be obtained with dfu-util
> > -l command. +In its output one should look for the
> > 'name="dfu_test1.bin"' and corresponding +alt=11.
> > diff --git a/test/dfu/dfu_gadget_test.sh
> > b/test/dfu/dfu_gadget_test.sh new file mode 100755
> > index 000..8abd8e7
> > --- /dev/null
> > +++ b/test/dfu/dfu_gadget_test.sh
> > @@ -0,0 +1,88 @@
> > +#! /bin/bash
> > +set -e # any command return if not equal to zero
> > +clear
> > +
> > +COLOR_RED="\33[31m"
> > +COLOR_GREEN="\33[32m"
> > +COLOR_DEFAULT="\33[0m"
> 
> Which side of the pond are you? :-) I think it should be COLOUR in
> U-Boot.

Ok, I will change the spelling from COLOR to COLOUR.

> 
> > +
> > +DIR=./
> > +SUFFIX=img
> > +RCV_DIR=rcv/
> > +LOG_FILE=./log/log-`date +%d-%m-%Y_%H-%M-%S`
> > +
> > +./dfu_gadget_test_init.sh
> > +
> > +cleanup () {
> > +rm -rf $RCV_DIR
> > +}
> > +
> > +die () {
> > +   printf "   $COLOR_RED FAILED $COLOR_DEFAULT \n"
> > +   cleanup
> > +   exit 1
> > +}
> > +
> > +calculate_md5sum () {
> > +MD5SUM=`md5sum $1`
> > +MD5SUM=`echo $MD5SUM | cut -d ' ' -f1`
> > +echo "md5sum:"$MD5SUM
> > +}
> > +
> > +dfu_test_file () {
> > +printf "$COLOR_GREEN
> > =
> > $COLOR_DEFAULT\n"
> > +printf "File:$COLOR_GREEN %s $COLOR_DEFAULT\n" $1
> > +
> > +dfu-util -D $1 -a $TARGET_ALT_SETTING >> $LOG_FILE 2>&1 || die
> > $? +
> > +echo -n "TX: "
> > +calculate_md5sum $1
> > +
> > +MD5_TX=$MD5SUM
> > +
> > +N_FILE=$DIR$RCV_DIR${1:2}"_rcv"
> > +
> > +dfu-util -U $N_FILE -a $TARGET_ALT_SETTING >> $LOG_FILE 2>&1
> > || die $? +
> > +echo -n "RX: "
> > +calculate_md5sum $N_FILE
> > +MD5_RX=$MD5SUM
> > +
> > +if [ "$MD5_TX" == "$MD5_RX" ]; then
> > +   printf "   $COLOR_GREEN ---> OK $COLOR_DEFAULT \n"
> > +else
> > +   printf "   $COLOR_RED ---> FAILED $COLOR_DEFAULT \n"
> > +   cleanup
> > +   exit 1
> > +fi
> > +
> > +}
> > +
> > +printf
> > "$COLOR_GREEN=
> > $COLOR_DEFAULT\n" +echo "DFU EP0 transmission test program" +echo
> > "Trouble shoot -> disable DBG (even the KERN_DEBUG) in the UDC
> > driver" +echo "@ -> TRATS2 # dfu 0 mmc 0" +mkdir -p $RCV_DIR
> > +touch $LOG_FILE
> > +
> > +if [ $# -eq 0 ]
> > +then
> > +   printf "   $COLOR_RED Please pass alt setting number!!
> > $COLOR_DEFAULT \n"
> > +   exit 0
> > +fi
> > +
> > +TARGET_ALT_SETTING=$1
> > +
> > +if [ -n "$2" ]
> > +then
> > +   dfu_test_file $2
> 
> Where is $2 mentioned? in your example usage?

$2 is for the case when one wants to test a part

Re: [U-Boot] [PATCH v2 04/11] drivers:dfu: new feature: separated bootloader alt setting

[Przemyslaw Marczak]

Hello Stephen,

On 06/16/2014 09:52 PM, Stephen Warren wrote:

On 06/12/2014 03:46 AM, Przemyslaw Marczak wrote:

This patch introduces new feature: initialization of the dfu
bootloader entity from a separate environmental variable which
can be set on a boot time.

By default, DFU always check environmental variable: $dfu_alt_info.

Changes:
- DFU will also look for environmental variable: $dfu_alt_bootloader
- if any of dfu_alt_* variable is properly defined, then function
   dfu_init_env_entities() will return success.

Use case:
Some devices can boot from various media type (SD, eMMC, NAND, etc.)
or some board configs are common for more than one board type.
In a such case, bootloader is probably placed on a different
devices or even offsets. So such DFU feature is welcome.


Why should the "dfu" command look at different environment variables?
Whatever code dynamically sets the value of $dfu_alt_bootloader should
simply set $dfu_alt_info instead.



Dynamically setting of any entity cold be done at boot time, like this:

# int buf_len = strlen(alt_bootloader) + strlen(CONFIG_DFU_ALT) + 4;
# char *buf = memalign(1, buf_len);
#
# sprintf(buf, "%s; %s", alt_bootloader, CONFIG_DFU_ALT);
# setenv("dfu_alt_info", buf);

But overwriting the $dfu_alt_info on each boot is not a good idea.
If user modify the dfu entities - then it will be overwritten at next boot.

In the other side I can store entities as $dfu_alt_default
and change the above code to:

# char *alt_default = getenv("dfu_alt_default");
# if (!alt_default)
#   alt_default = "";
#
# int buf_len = strlen(alt_bootloader) + strlen(alt_default) + 4;
# char *buf = memalign(1, buf_len);
#
# sprintf(buf, "%s; %s", alt_bootloader, alt_default);
# setenv("dfu_alt_info", buf);

But then, there is some mess in the environment because of duplicated 
default alt_info.


Those both, above solutions takes more time than just one simple line:

# setenv("dfu_alt_bootlaoder", CONFIG_SOME_ALT_INFO);

like in this patch set.

Maybe better could be modification of the function 
dfu_init_env_entities() to support parsing variables

in the $dfu_alt_info instead of hard coded env variables
names, e.g:

dfu_alt_info="${alt_info_boot}, ${alt_info_system},..."

dfu_alt_info could be set with default variables names in each board 
config file in the CONFIG_EXTRA_ENV_SETTINGS and then just one proper 
variable could be set at boot, and others from env - simple and fast.


And then in the dfu init code - entities are initialized from env 
variables - if they exists, like in the loop code from this patch.


I need some solution to automatically set proper bootloader entities, 
since one binary can be stored on SD and eMMC cards.


Thank you,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [GIT PULL] Zynq fix

[Michal Simek]

Hi Albert and Tom,

here is one critical fix which should go to v2014.07 release.
Without it u-boot for zynq is not working.
Please add it to your tree.

Thanks,
Michal


The following changes since commit d8a97f934c64a7ba6f11da5e4cc7f3be57fcb82d:

  Merge branch 'master' of git://git.denx.de/u-boot-mmc (2014-06-12 09:02:23 
-0400)

are available in the git repository at:


  git://www.denx.de/git/u-boot-microblaze.git zynq

for you to fetch changes up to a811db5a8c557138e4d22000aca4ce7f6c3b25b5:

  arm: zynq: fix a bug in Zynq linker script (2014-06-17 12:28:26 +0200)


Masahiro Yamada (1):
  arm: zynq: fix a bug in Zynq linker script

 arch/arm/cpu/armv7/zynq/u-boot.lds | 1 +
 1 file changed, 1 insertion(+)


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: zynq: fix a bug in Zynq linker script

[Michal Simek]

On 06/17/2014 10:45 AM, Masahiro Yamada wrote:
> Hi Michal,
> 
> On Thu,  5 Jun 2014 19:47:45 +0900
> Masahiro Yamada  wrote:
> 
>> Commit 41623c91 moved exception handlers to ".vectores" section
>> but it missed to adjust Zynq linker script.
>>
>> Zynq boards hang up after relocation because "_start" symbol
>> does not point to the correct address and gd->relocaddr gets insane.
>>
>> Signed-off-by: Masahiro Yamada 
>> Cc: Albert ARIBAUD 
>> Cc: Michal Simek 
>> Tested-by: Michal Simek 
>> ---
>>  arch/arm/cpu/armv7/zynq/u-boot.lds | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/cpu/armv7/zynq/u-boot.lds 
>> b/arch/arm/cpu/armv7/zynq/u-boot.lds
>> index 69500a6..4dc9bb0 100644
>> --- a/arch/arm/cpu/armv7/zynq/u-boot.lds
>> +++ b/arch/arm/cpu/armv7/zynq/u-boot.lds
>> @@ -18,6 +18,7 @@ SECTIONS
>>  .text :
>>  {
>>  *(.__image_copy_start)
>> +*(.vectors)
>>  CPUDIR/start.o (.text*)
>>  *(.text*)
>>  }
> 
> 
> This bug should be fixed asap.
> 
> Because this patch is assigned to you, 
> could you apply it and send a pull-request, please?

Applied and pull request sent.

Thanks,
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] kbuild: Use relative path when possible

[Masahiro Yamada]

On Mon, 16 Jun 2014 18:56:39 +0900
Masahiro Yamada  wrote:

> Import 3 useful commits by Michal Marek 
> from Linux 3.16-rc1.
> 
>   commit 9da0763bdd82572be243fcf5161734f11568960f
>   kbuild: Use relative path when building in a subdir of the source tree
> 
>   commit 890676c65d699db3ad82e70cf8fb449031af
>   kbuild: Use relative path when building in the source tree
> 
>   commit 7e1c04779efd51154baf652e653ceb24ce68939b
>   kbuild: Use relative path for $(objtree)
> 
> mkconfig and tools/Makefile must be adjusted to use relative path
> for srctree.
> 
> Signed-off-by: Masahiro Yamada 


Some regressions about these commits have been reported to linux-kbuild ML.

It might be too early to import them to U-boot, so I decided to postpone this 
patch.

I will change its status to RFC.


Best Regards
Masahiro Yamada

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

[U-Boot] Atmel SAMA5D31 NOR boot - sanity check required

[Andy Pont]

Hello!

I am currently working on an implementation of NOR boot support for the
Atmel SAMA5D31-EK reference platform as a precursor to a custom hardware
platform.  When tested and working I will push the support back to the
community but what I have at the moment doesn't appear to do anything so I
would appreciate a sanity check on the work done so far.  

For reference the documentation for the Atmel SoC says:

If BMS signal is tied to 0, BMS_BIT is read at 1.  The ROM code allows
execution of the code contained in the memory connected to Chip Select 0 of
the External Bus Interface (J828F128P33TF70A) and then goes on to detail the
startup mode and changes that need to be made to the PLL and SMC.

For simplicity sake, I have taken the standard SAMA5D31-EK configuration of
SPL+U-Boot and have added NOR boot support to SPL based on one of the other
boards.  The board header file has the following configuration:

#define CONFIG_SPL_NOR_SUPPORT
#define CONFIG_SYS_FLASH_CFI1
#define CONFIG_FLASH_CFI_DRIVER 1
#define CONFIG_SYS_FLASH_BASE   0x
#define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE

As per the standard SPL build for this hardware platform the
CONFIG_SYS_INIT_SP_ADDR value is set to 0x31 but I haven't found a
definitive statement that confirms that the internal SRAM is mapped to that
location when in this boot mode.

So my questions are...

Is the SPL+U-Boot implementation the best way for NOR booting or should it
all just be built as a single U-Boot image?

Do the settings above look correct, particularly the value for the initial
stack pointer?

How best do I debug SPL to determine where it is getting lost in the weeds?

Many thanks,

Andy.


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

[U-Boot] Powerpc/lib: wait_ticks function hangs(u-boot-2014.04 )

[ranjini Raveendran]

Hi,

We are using u-boot-2014.04 for the Freescale COM Express Evaluation board.
We compiled it for SD card boot option . uboot hangs due to wait_ticks
function .

We went through the mailing list. Found out that a patch for this function
had done around 28 Jan 2013 .

But in our board still it hangs .
When we commented the function and the uboot came up . But I know this is
not the fix for the problem.
Can You suggest any patch up for the same  ?


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

Re: [U-Boot] U-boot hangs on imx6 pci driver

[Fabio Estevam]

Hi Tim,

On Fri, Jun 6, 2014 at 1:35 AM, Tim Harvey  wrote:

> Fabio,
>
> Good catch, but that doesn't resolve the issue i'm seeing here.
>
> Any other ideas?

Do you still have issues after applying David's delay workaround?

On my mx6qsabresd I noticed that:

- if U-boot has PCI driver enabled, then kernel hangs 100% of time.

- if U-boot does not have PCI driver enabled, then the kernel boots
but does not detect my PCI card.

After applying David's workaround I can boot the kernel with PCI
driver enabled in U-boot and the kernel does detect the PCI Wifi
module.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx6: Fix definition of IOMUXC_GPR12_DEVICE_TYPE_RC

[Stefano Babic]

Hi Fabio,

On 06/06/2014 00:31, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> mx6 reference manual incorrectly states that the DEVICE_TYPE field of 
> IOMUXC_GPR12 register should be configured as '0010' for setting the PCI 
> controller in RC mode. The correct value should be '0100' instead.
> 
> This also aligns with the same value used in the mx6 pci kernel driver.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/include/asm/arch-mx6/iomux.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/arch-mx6/iomux.h 
> b/arch/arm/include/asm/arch-mx6/iomux.h
> index f9ee0d9..6a4a632 100644
> --- a/arch/arm/include/asm/arch-mx6/iomux.h
> +++ b/arch/arm/include/asm/arch-mx6/iomux.h
> @@ -39,7 +39,7 @@
>  #define IOMUXC_GPR12_LOS_LEVEL_MASK  (0x1f << 4)
>  #define IOMUXC_GPR12_APPS_LTSSM_ENABLE   (1 << 10)
>  #define IOMUXC_GPR12_DEVICE_TYPE_EP  (0x0 << 12)
> -#define IOMUXC_GPR12_DEVICE_TYPE_RC  (0x2 << 12)
> +#define IOMUXC_GPR12_DEVICE_TYPE_RC  (0x4 << 12)
>  #define IOMUXC_GPR12_DEVICE_TYPE_MASK(0xf << 12)
>  

Applied to u-boot-imx, thanks !

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] [PATCH 2/2] arm: mx5: Enable CONFIG_SYS_GENERIC_BOARD on M53EVK

[Stefano Babic]

On 13/06/2014 00:02, Marek Vasut wrote:
> On Thursday, April 03, 2014 at 07:12:37 PM, Marek Vasut wrote:
>> Signed-off-by: Marek Vasut 
>> ---
>>  include/configs/m53evk.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/configs/m53evk.h b/include/configs/m53evk.h
>> index 16546c2..496f046 100644
>> --- a/include/configs/m53evk.h
>> +++ b/include/configs/m53evk.h
>> @@ -9,6 +9,7 @@
>>  #define __M53EVK_CONFIG_H__
>>
>>  #define CONFIG_MX53
>> +#define CONFIG_SYS_GENERIC_BOARD
>>  #define CONFIG_MXC_GPIO
>>
>>  #include 
> 
> Hi Stefano, I think you missed this.

Yes, it is set to deferred in patchwork (it was not me, I was not set as
delegate). It does not matter:

Applied to u-boot-imx, thanks !

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] [PATCH] mx6: drop ARM errata 742230

[Stefano Babic]

Hi Shawn,

On 11/06/2014 10:52, Shawn Guo wrote:
> Commit e9fd66defd7e (ARM: mx6: define CONFIG_ARM_ERRATA_742230) enables
> errata 742230 for imx6, because it helps remove one reboot issue.
> However, this errata does not really apply on imx6, because Cortex-A9
> on imx6 is r2p10 while the errata only applies to revisions r1p0..r2p2.
> 
> At a later time, commit f71cbfe3ca5d (ARM: Add workaround for Cortex-A9
> errata 794072) adds support of errata 794072, which applies to all
> Cortex-A9 revisions.  As the workaround for both errata are exactly
> same, it makes a lot more sense to select 794072 instead of 742230 for
> imx6.  Since we already enable 794072 for imx6, it's time to drop
> errata 742230 to avoid confusion.
> 
> Signed-off-by: Shawn Guo 
> ---

Applied to u-boot-imx, thanks !

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] [PATCH] embestmx6boards: Fix CONFIG_CONSOLE_DEV

[Stefano Babic]

Hi Fabio,

On 09/06/2014 18:35, Fabio Estevam wrote:
> mars and riot boards use UART2 as console, so CONFIG_CONSOLE_DEV should point
> to 'ttymxc1' instead.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

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] [PATCH] embestmx6boards: Fix the dtb file name for riotboard

[Stefano Babic]

Hi Fabio,

On 09/06/2014 18:42, Fabio Estevam wrote:
> The name of the dtb file used in the kernel is 'imx6dl-riotboard.dtb', so fix
> it accordingly.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  include/configs/embestmx6boards.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/embestmx6boards.h 
> b/include/configs/embestmx6boards.h
> index 1d5fde6..f1000f3 100644
> --- a/include/configs/embestmx6boards.h
> +++ b/include/configs/embestmx6boards.h
> @@ -293,7 +293,7 @@
>  
>  #if defined(CONFIG_ENV_IS_IN_MMC)
>  /* RiOTboard */
> -#define CONFIG_DEFAULT_FDT_FILE  "imx6s-riotboard.dtb"
> +#define CONFIG_DEFAULT_FDT_FILE  "imx6dl-riotboard.dtb"
>  #define CONFIG_SYS_FSL_USDHC_NUM 3
>  #define CONFIG_SYS_MMC_ENV_DEV   2   /* SDHC4 */
>  #define CONFIG_ENV_OFFSET(6 * 64 * 1024)
> 

Applied to u-boot-imx, thanks !

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] [PATCH v3 1/3] mx28evk: Fix warning when CONFIG_ENV_IS_IN_SPI_FLASH is selected

[Stefano Babic]

On 10/06/2014 05:03, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> When building a target with CONFIG_ENV_IS_IN_SPI_FLASH the following 
> warning is seen:
> 
> include/configs/mx28evk.h:73:0: warning: "CONFIG_ENV_SIZE" redefined [enabled 
> by default]
> 
> Protect the definition of CONFIG_ENV_SIZE to avoid the warning.
> 
> Signed-off-by: Fabio Estevam 
> ---

Applied to u-boot-imx, thanks !

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

[U-Boot] [PATCH] OMAP: disable gpmc timeout safely for reenabling

[Stefano Babic]

gpmc timeout is disabled and the reset counter
is set to 0. However, if later a driver activates
the timeout setting the reset to a valid value,
the old reset value with zero is still valid
for the first access. In fact, the timeout block
loads the reset counter after a successful access.

Found on a am335x board with a FPGA connected
to the GPMC bus together with the NAND.
When the FPGA driver in kernel activates
the timeout, the system hangs at the first access
by the NAND driver.

Signed-off-by: Stefano Babic 
---
 arch/arm/cpu/armv7/omap-common/mem-common.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap-common/mem-common.c 
b/arch/arm/cpu/armv7/omap-common/mem-common.c
index 944ef84..7a6ed84 100644
--- a/arch/arm/cpu/armv7/omap-common/mem-common.c
+++ b/arch/arm/cpu/armv7/omap-common/mem-common.c
@@ -121,7 +121,8 @@ void gpmc_init(void)
writel(0x0008, &gpmc_cfg->sysconfig);
writel(0x, &gpmc_cfg->irqstatus);
writel(0x, &gpmc_cfg->irqenable);
-   writel(0x, &gpmc_cfg->timeout_control);
+   /* disable timeout, set a safe reset value */
+   writel(0x1ff0, &gpmc_cfg->timeout_control);
 #ifdef CONFIG_NOR
writel(0x0200, &gpmc_cfg->config);
 #else
-- 
1.9.1

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

Re: [U-Boot] [PATCH 1/6] usb: ehci: mx6: Add support for i.MX6SL

[Stefano Babic]

Hi Otavio,

On 16/06/2014 02:46, Otavio Salvador wrote:
> The i.MX6SL has a different base address for the controller. This
> patch adapts the driver to support the different base address for this
> case.
> 
> Signed-off-by: Otavio Salvador 
> ---
> 
>  drivers/usb/host/ehci-mx6.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index c0a557b..5ba1c5e 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -53,6 +53,12 @@
>  #define UCMD_RUN_STOP   (1 << 0) /* controller run/stop */
>  #define UCMD_RESET   (1 << 1) /* controller reset */
>  
> +#ifdef CONFIG_MX6SL
> +#define USB_BASE_ADDRUSBO2H_USB_BASE_ADDR
> +#else
> +#define USB_BASE_ADDRUSBOH3_USB_BASE_ADDR
> +#endif
> +

What about using the is_cpu_type() function, recently added together
with SPL support ? I think we have reached, thank to Tim's patches, the
goal to have a single image for different Freescale's mx6 variations. It
is pity to go back and decide at compile time which SOC is running.

>  static const unsigned phy_bases[] = {
>   USB_PHY0_BASE_ADDR,
>   USB_PHY1_BASE_ADDR,
> @@ -174,7 +180,7 @@ struct usbnc_regs {
>  
>  static void usb_oc_config(int index)
>  {
> - struct usbnc_regs *usbnc = (struct usbnc_regs *)(USBOH3_USB_BASE_ADDR +
> + struct usbnc_regs *usbnc = (struct usbnc_regs *)(USB_BASE_ADDR +
>   USB_OTHERREGS_OFFSET);
>   void __iomem *ctrl = (void __iomem *)(&usbnc->ctrl[index]);
>   u32 val;
> @@ -207,7 +213,7 @@ int ehci_hcd_init(int index, enum usb_init_type init,
>   struct ehci_hccr **hccr, struct ehci_hcor **hcor)
>  {
>   enum usb_init_type type;
> - struct usb_ehci *ehci = (struct usb_ehci *)(USBOH3_USB_BASE_ADDR +
> + struct usb_ehci *ehci = (struct usb_ehci *)(USB_BASE_ADDR +
>   (0x200 * index));
>  
>   if (index > 3)
> 

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] [PATCH 1/6] usb: ehci: mx6: Add support for i.MX6SL

[Otavio Salvador]

On Tue, Jun 17, 2014 at 11:56 AM, Stefano Babic  wrote:
> Hi Otavio,
>
> On 16/06/2014 02:46, Otavio Salvador wrote:
>> The i.MX6SL has a different base address for the controller. This
>> patch adapts the driver to support the different base address for this
>> case.
>>
>> Signed-off-by: Otavio Salvador 
>> ---
>>
>>  drivers/usb/host/ehci-mx6.c | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
>> index c0a557b..5ba1c5e 100644
>> --- a/drivers/usb/host/ehci-mx6.c
>> +++ b/drivers/usb/host/ehci-mx6.c
>> @@ -53,6 +53,12 @@
>>  #define UCMD_RUN_STOP   (1 << 0) /* controller run/stop */
>>  #define UCMD_RESET   (1 << 1) /* controller reset */
>>
>> +#ifdef CONFIG_MX6SL
>> +#define USB_BASE_ADDRUSBO2H_USB_BASE_ADDR
>> +#else
>> +#define USB_BASE_ADDRUSBOH3_USB_BASE_ADDR
>> +#endif
>> +
>
> What about using the is_cpu_type() function, recently added together
> with SPL support ? I think we have reached, thank to Tim's patches, the
> goal to have a single image for different Freescale's mx6 variations. It
> is pity to go back and decide at compile time which SOC is running.

Yes; I will do it for v2.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] mmc: fsl_esdhc: Add support to force VSELECT set

[Stefano Babic]

Hi Otavio,

On 16/06/2014 02:46, Otavio Salvador wrote:
> There are board were we cannot do voltage negotiation but want to set
> the VSELECT bit forcely to ensure it to work at 1.8V.
> 
> This commit adds CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT flag for this use.
> 
> Signed-off-by: Otavio Salvador 
> ---
> 
>  drivers/mmc/fsl_esdhc.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index c75b38f..b3870e2 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -517,6 +517,10 @@ static int esdhc_init(struct mmc *mmc)
>   /* Set timout to the maximum value */
>   esdhc_clrsetbits32(®s->sysctl, SYSCTL_TIMEOUT_MASK, 14 << 16);
>  
> +#ifdef CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
> + esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
> +#endif

Instead of adding a new compiler switch that should be documented (I
have already read Marek's comments), what do you think to extend struct
fsl_esdhc_cfg, putting for exmaple an "options" field with this kind of
specialization ?

I see also a CONFIG_SYS_FSL_ESDHC_USE_PIO that slipped into mainline
(you are both right : Otavio is not the first to add such kind of
configuration switches that are still undocumented, but according to
rules should be documented as Marek said).

I would suggest to get rid as much as possible with these CONFIG_
switches. If we have some specialization for this driver before calling
esdhc_init (better: fsl_esdhc_initialize), they are self explaining and
we do not need further documentation. What do you think ?

Best regards,
Stefano


-- 
=
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] [PATCH 4/6] mmc: fsl_esdhc: Add support to force VSELECT set

[Stefano Babic]

Hi Michael,

On 17/06/2014 17:14, Michael Trimarchi wrote:

>>> Instead of adding a new compiler switch that should be documented (I
>>> have already read Marek's comments), what do you think to extend struct
>>> fsl_esdhc_cfg, putting for exmaple an "options" field with this kind of
>>> specialization ?
>>
>> I will try to cook something in this direction.
>>
> 
> Well I already said some emails ago ;).

Nice I am not alone to think it in this way :-). Sorry, I have not read
your answer, I was dropped from the CC list and I missed that you have
already said the same.

Best regards,
Stefano

-- 
=
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] [PATCH 1/4] mx6: Add support for the mx6solox variant

[Stefano Babic]

Hi Fabio,

On 14/06/2014 22:29, Fabio Estevam wrote:
> From: Fabio Estevam 
> 

Sorry to be noisy. I have not idea which mx6solox means. Can you (I have
not found any documentation on Freescale's website) spend a couple of
line and introduce this new i.MX6 variation ?

Which are the main differences with other i.MX6 CPU we are already
supporting, for example the Solo ?

Recently, we added several patches to make runtime detection for the cpu
- see is_cpu_type(). What about to use it in your patches ?

> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/cpu/armv7/mx6/clock.c|   4 +-
>  arch/arm/cpu/armv7/mx6/soc.c  |  26 +
>  arch/arm/imx-common/cpu.c |   2 +
>  arch/arm/include/asm/arch-imx/cpu.h   |   3 +-
>  arch/arm/include/asm/arch-mx6/crm_regs.h  | 170 
> ++
>  arch/arm/include/asm/arch-mx6/imx-regs.h  | 122 -
>  arch/arm/include/asm/arch-mx6/mx6-ddr.h   |   4 +
>  arch/arm/include/asm/arch-mx6/mx6sx-ddr.h |  45 
>  8 files changed, 369 insertions(+), 7 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-mx6/mx6sx-ddr.h
> 
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index bd65a08..d31fbbd 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -214,7 +214,7 @@ static u32 get_uart_clk(void)
>   u32 reg, uart_podf;
>   u32 freq = decode_pll(PLL_USBOTG, MXC_HCLK) / 6; /* static divider */
>   reg = __raw_readl(&imx_ccm->cscdr1);
> -#ifdef CONFIG_MX6SL
> +#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
>   if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
>   freq = MXC_HCLK;
>  #endif
> @@ -282,7 +282,7 @@ static u32 get_emi_slow_clk(void)
>   return root_freq / (emi_slow_podf + 1);
>  }
>  
> -#ifdef CONFIG_MX6SL
> +#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
>  static u32 get_mmdc_ch0_clk(void)
>  {
>   u32 cbcmr = __raw_readl(&imx_ccm->cbcmr);
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index 1725279..e394e3f 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -79,9 +79,15 @@ u32 __weak get_board_rev(void)
>  void init_aips(void)
>  {
>   struct aipstz_regs *aips1, *aips2;
> +#ifdef CONFIG_MX6SX
> + struct aipstz_regs *aips3;
> +#endif
>  
>   aips1 = (struct aipstz_regs *)AIPS1_BASE_ADDR;
>   aips2 = (struct aipstz_regs *)AIPS2_BASE_ADDR;
> +#ifdef CONFIG_MX6SX
> + aips3 = (struct aipstz_regs *)AIPS3_BASE_ADDR;
> +#endif
>  
>   /*
>* Set all MPROTx to be non-bufferable, trusted for R/W,
> @@ -107,6 +113,26 @@ void init_aips(void)
>   writel(0x, &aips2->opacr2);
>   writel(0x, &aips2->opacr3);
>   writel(0x, &aips2->opacr4);
> +
> +#ifdef CONFIG_MX6SX
> + /*
> +  * Set all MPROTx to be non-bufferable, trusted for R/W,
> +  * not forced to user-mode.
> +  */
> + writel(0x, &aips3->mprot0);
> + writel(0x, &aips3->mprot1);
> +
> + /*
> +  * Set all OPACRx to be non-bufferable, not require
> +  * supervisor privilege level for access,allow for
> +  * write access and untrusted master access.
> +  */
> + writel(0x, &aips3->opacr0);
> + writel(0x, &aips3->opacr1);
> + writel(0x, &aips3->opacr2);
> + writel(0x, &aips3->opacr3);
> + writel(0x, &aips3->opacr4);
> +#endif
>  }
>  
>  static void clear_ldo_ramp(void)
> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
> index 5a09107..7bb0e83 100644
> --- a/arch/arm/imx-common/cpu.c
> +++ b/arch/arm/imx-common/cpu.c
> @@ -112,6 +112,8 @@ const char *get_imx_type(u32 imxtype)
>   return "6SOLO"; /* Solo version of the mx6 */
>   case MXC_CPU_MX6SL:
>   return "6SL";   /* Solo-Lite version of the mx6 */
> + case MXC_CPU_MX6SX:
> + return "6SX";   /* SoloX version of the mx6 */
>   case MXC_CPU_MX51:
>   return "51";
>   case MXC_CPU_MX53:
> diff --git a/arch/arm/include/asm/arch-imx/cpu.h 
> b/arch/arm/include/asm/arch-imx/cpu.h
> index a35940e..a3cc96f 100644
> --- a/arch/arm/include/asm/arch-imx/cpu.h
> +++ b/arch/arm/include/asm/arch-imx/cpu.h
> @@ -8,6 +8,7 @@
>  #define MXC_CPU_MX53 0x53
>  #define MXC_CPU_MX6SL0x60
>  #define MXC_CPU_MX6DL0x61
> -#define MXC_CPU_MX6SOLO  0x62
> +#define MXC_CPU_MX6SX0x62
>  #define MXC_CPU_MX6Q 0x63
>  #define MXC_CPU_MX6D 0x64
> +#define MXC_CPU_MX6SOLO  0x65 /* dummy ID */
> diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h 
> b/arch/arm/include/asm/arch-mx6/crm_regs.h
> index 7202073..0fcef69 100644
> --- a/arch/arm/include/asm/arch-mx6/crm_regs.h
> +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
> @@ -113,7 +113,11 @@ struct mxc_ccm_reg {
>  #define MXC_CCM_CCR_WB_COUNT_MASK  

Re: [U-Boot] [PATCH 3/4] mx6: clock: Do not enable sata and ipu clocks

[Stefano Babic]

Hi Fabio,

On 14/06/2014 22:29, Fabio Estevam wrote:
> From: Fabio Estevam 
> 
> mx6sx does not have sata nor ipu blocks, so do not handle such clocks.
> 

We have already a check inside setup_sata():

   if (!is_cpu_type(MXC_CPU_MX6Q) && !is_cpu_type(MXC_CPU_MX6D))
return 1;

enable_sata_clock() is called only for quad and dual. I think you do not
need at all to block  enable_sata_clock(), it should be not called.

I would prefer we carry on with this approach: board are calling
functions to set up hardware, and each peripheral (setup_sata or the ipu
driver) makes the check at runtime for the running cpu.

> Signed-off-by: Fabio Estevam 
> ---
>  arch/arm/cpu/armv7/mx6/clock.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index d31fbbd..51c964c 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -437,6 +437,7 @@ static int enable_enet_pll(uint32_t en)
>   return 0;
>  }
>  
> +#ifndef CONFIG_MX6SX
>  static void ungate_sata_clock(void)
>  {
>   struct mxc_ccm_reg *const imx_ccm =
> @@ -445,6 +446,7 @@ static void ungate_sata_clock(void)
>   /* Enable SATA clock. */
>   setbits_le32(&imx_ccm->CCGR5, MXC_CCM_CCGR5_SATA_MASK);
>  }
> +#endif
>  
>  static void ungate_pcie_clock(void)
>  {
> @@ -455,11 +457,13 @@ static void ungate_pcie_clock(void)
>   setbits_le32(&imx_ccm->CCGR4, MXC_CCM_CCGR4_PCIE_MASK);
>  }
>  
> +#ifndef CONFIG_MX6SX
>  int enable_sata_clock(void)
>  {
>   ungate_sata_clock();
>   return enable_enet_pll(BM_ANADIG_PLL_ENET_ENABLE_SATA);
>  }
> +#endif
>  
>  int enable_pcie_clock(void)
>  {
> @@ -491,7 +495,9 @@ int enable_pcie_clock(void)
>   clrbits_le32(&ccm_regs->cbcmr, MXC_CCM_CBCMR_PCIE_AXI_CLK_SEL);
>  
>   /* Party time! Ungate the clock to the PCIe. */
> +#ifndef CONFIG_MX6SX
>   ungate_sata_clock();
> +#endif
>   ungate_pcie_clock();
>  
>   return enable_enet_pll(BM_ANADIG_PLL_ENET_ENABLE_SATA |
> @@ -573,6 +579,7 @@ int do_mx6_showclocks(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
>   return 0;
>  }
>  
> +#ifndef CONFIG_MX6SX
>  void enable_ipu_clock(void)
>  {
>   struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> @@ -581,6 +588,7 @@ void enable_ipu_clock(void)
>   reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK;
>   writel(reg, &mxc_ccm->CCGR3);
>  }
> +#endif
>  /***/
>  
>  U_BOOT_CMD(
> 

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] [PATCH 4/6] mmc: fsl_esdhc: Add support to force VSELECT set

[Michael Trimarchi]

Hi Stefano

On Tue, Jun 17, 2014 at 5:12 PM, Otavio Salvador
 wrote:
> On Tue, Jun 17, 2014 at 12:11 PM, Stefano Babic  wrote:
>> On 16/06/2014 02:46, Otavio Salvador wrote:
>>> There are board were we cannot do voltage negotiation but want to set
>>> the VSELECT bit forcely to ensure it to work at 1.8V.
>>>
>>> This commit adds CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT flag for this use.
>>>
>>> Signed-off-by: Otavio Salvador 
>>> ---
>>>
>>>  drivers/mmc/fsl_esdhc.c | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
>>> index c75b38f..b3870e2 100644
>>> --- a/drivers/mmc/fsl_esdhc.c
>>> +++ b/drivers/mmc/fsl_esdhc.c
>>> @@ -517,6 +517,10 @@ static int esdhc_init(struct mmc *mmc)
>>>   /* Set timout to the maximum value */
>>>   esdhc_clrsetbits32(®s->sysctl, SYSCTL_TIMEOUT_MASK, 14 << 16);
>>>
>>> +#ifdef CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
>>> + esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
>>> +#endif
>>
>> Instead of adding a new compiler switch that should be documented (I
>> have already read Marek's comments), what do you think to extend struct
>> fsl_esdhc_cfg, putting for exmaple an "options" field with this kind of
>> specialization ?
>
> I will try to cook something in this direction.
>

Well I already said some emails ago ;).

Michael

> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] mmc: fsl_esdhc: Add support to force VSELECT set

[Otavio Salvador]

On Tue, Jun 17, 2014 at 12:11 PM, Stefano Babic  wrote:
> On 16/06/2014 02:46, Otavio Salvador wrote:
>> There are board were we cannot do voltage negotiation but want to set
>> the VSELECT bit forcely to ensure it to work at 1.8V.
>>
>> This commit adds CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT flag for this use.
>>
>> Signed-off-by: Otavio Salvador 
>> ---
>>
>>  drivers/mmc/fsl_esdhc.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
>> index c75b38f..b3870e2 100644
>> --- a/drivers/mmc/fsl_esdhc.c
>> +++ b/drivers/mmc/fsl_esdhc.c
>> @@ -517,6 +517,10 @@ static int esdhc_init(struct mmc *mmc)
>>   /* Set timout to the maximum value */
>>   esdhc_clrsetbits32(®s->sysctl, SYSCTL_TIMEOUT_MASK, 14 << 16);
>>
>> +#ifdef CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
>> + esdhc_setbits32(®s->vendorspec, ESDHC_VENDORSPEC_VSELECT);
>> +#endif
>
> Instead of adding a new compiler switch that should be documented (I
> have already read Marek's comments), what do you think to extend struct
> fsl_esdhc_cfg, putting for exmaple an "options" field with this kind of
> specialization ?

I will try to cook something in this direction.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/7] nand_spl: remove P1023RDS_NAND support

[Scott Wood]

On Tue, 2014-06-17 at 17:36 +0900, Masahiro Yamada wrote:
> Hello Scott,
> 
> On Mon, 16 Jun 2014 16:46:13 -0500
> Scott Wood  wrote:
> 
> > FWIW, all p1023rds support can probably be removed.  Very few boards
> > were ever sold, and support was recently removed from Linux (commit
> > fd7e5b7a8758093781a44df9577fe24e9e11723e).
> > 
> 
> In that case, could you send a patch to remove it?
> Or shall I do that ?

I'm hoping York and/or Roy will comment on the removal first.

-Scott


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

Re: [U-Boot] [PATCH 4/6] mmc: fsl_esdhc: Add support to force VSELECT set

[Marek Vasut]

On Tuesday, June 17, 2014 at 08:06:38 AM, Michael Trimarchi wrote:
> Hi Marek
> 
> Il 17/giu/2014 08:03 "Marek Vasut"  ha scritto:
> > On Monday, June 16, 2014 at 01:48:11 PM, Otavio Salvador wrote:
> > > On Mon, Jun 16, 2014 at 4:03 AM, Igor Grinberg
> > > 
> > 
> > wrote:
> > > > Hi Otavio,
> > > > 
> > > > On 06/16/14 05:24, Otavio Salvador wrote:
> > > >> On Sun, Jun 15, 2014 at 11:03 PM, Marek Vasut  wrote:
> > > >>> On Monday, June 16, 2014 at 03:39:08 AM, Otavio Salvador wrote:
> > >  On Sun, Jun 15, 2014 at 10:27 PM, Marek Vasut 
> 
> wrote:
> > > > On Monday, June 16, 2014 at 03:22:22 AM, Otavio Salvador wrote:
> > > > 
> > > > [...]
> > > > 
> > >  +#ifdef CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
> > >  + esdhc_setbits32(®s->vendorspec,
> > >  ESDHC_VENDORSPEC_VSELECT); +#endif
> > > >>> 
> > > >>> Documentation is missing.
> > > >> 
> > > >> There is no FSL ESDHC README file so that's why I didn't include
> 
> it
> 
> > > >> anywhere.
> > > > 
> > > > I'm at loss for words here, really...
> > > > 
> > > > I think you know what needs to be done (hint: write the
> > > > documentation), right ?
> > >  
> > >  I won't write the full documentation for it. I am sorry.
> > > >>> 
> > > >>> Undocumented configuration option is not acceptable, period.
> > > >> 
> > > >> Who accepted the driver in the first version, without Doc?
> > > >> 
> > > >> I am not in the position to write the full doc.
> > > > 
> > > > I think there is a misunderstanding here...
> > > > I think Marek does not want to say that you need to write the full
> > > > documentation for the driver, but only document the
> > > > CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT configuration option (what does it
> 
> do
> 
> > > > when you define it and why should one define it).
> > > 
> > > Great but where if it does not exist?
> > > 
> > > should I make a README.fsl-esdhc and include just it?
> > 
> > I briefly looked over the options in the driver, prefixed with hash are
> 
> the ones
> 
> > which are not driver specific:
> > 
> > CONFIG_ESDHC_DETECT_8_BIT_QUIRK
> > CONFIG_ESDHC_DETECT_QUIRK
> > CONFIG_FSL_ESDHC_PIN_MUX
> > CONFIG_FSL_USDHC
> > #CONFIG_MX53
> > #CONFIG_OF_LIBFDT
> > CONFIG_SYS_FSL_ERRATUM_ESDHC111
> > CONFIG_SYS_FSL_ERRATUM_ESDHC135
> > CONFIG_SYS_FSL_ERRATUM_ESDHC_A001
> > CONFIG_SYS_FSL_ESDHC_ADDR
> > CONFIG_SYS_FSL_ESDHC_USE_PIO
> > CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33
> > #CONFIG_SYS_MMC_MAX_BLK_COUNT
> > #CONFIG_SYS_SD_VOLTAGE
> > #CONFIG_T4240QDS
> > 
> > It looks like completely ad-hoc addition of new and new config options as
> > whoever seen fit to me, both from their names and git log of the driver.
> 
> This
> 
> > makes the driver completely unmaintainable. I would like to see them
> 
> documented
> 
> Do you think that could be a better option to use flags and runtime detect
> instead having hundred of define?

Eventually, when we transition to DT, this will be indeed needed anyway. But 
before that, we need to understand what those flags do (which we don't because 
previous patches neglected adding proper documentation).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/3] mtd, ubi, ubifs: resync with Linux-3.14

[Scott Wood]

On Tue, 2014-06-17 at 09:15 +0200, Heiko Schocher wrote:
> - Following Code in drivers/mtd/nand/nand_base.c nand_do_write_ops()
>   adapted for U-Boot:
> 
>   +#ifndef __UBOOT__
> /* Reject writes, which are not page aligned */
> if (NOTALIGNED(to) || NOTALIGNED(ops->len)) {
>   +else
>   + /* Reject writes, which are not page aligned */
>   + if (NOTALIGNED(to)) {
>   +endif

This sort of ifdeffing is a bad idea -- if a larger number of lines are
ifdeffed, to avoid context conflicts, subsequent merges can silently put
updates into the non-U-Boot section that are needed in the U-Boot
section.

Plus, it impairs readability, and in this case breaks text-editor
brace-matching.

Plus plus, that line has been that way in Linux since 2006 -- why is it
being touched at all?  Did you merge in changes from the previous mtd
sync, or did you just copy the new files over and then try to fix
resulting problems? (answered below)

>   as the original linux code leads in not working use of the env
>   var "filesize". For example a "nand write 8000 8 ${filesize}"
>   would not work with it ...
> 
> - add CONFIG_MTD_NAND_VERIFY_WRITE from U-Boot code
>   (only compile tested)
> 
> - Documented the config defines in README
> 
> - kmalloc now uses memalign for allocating memory. This prevented
>   crashes when tested ubi/ubifs on imx6 board.
> 
> - To produce this patch I did three steps:
>   - copied the linux source files to U-Boot tree -> commit this
>   - adapt license text in each file -> commit this
>   - make the code again compile clean and working -> commit this

OK, so you did just copy stuff over.  This method will lead to U-Boot
changes being reverted every time.  You should look in the U-Boot
history to see what Linux version corresponded to the last mtd sync, and
generate a diff relative to that.

-Scott


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

Re: [U-Boot] [Patch v2 0/7] Add support for TQMa6 modules

[Stefano Babic]

Hi Markus,

On 16/06/2014 18:51, Markus Niebel wrote:
> From: Markus Niebel 
> 
> This series add support for the TQMa6 boards from TQ Systems.
> The first Patch adds basic support for the modiules and the 
> starterkit baseboard while the other patches add additional features
> 
> Markus Niebel (7):
>   Add TQ Systems TQMa6 board support
>   TQMa6: mba6: add RGMII enet
>   TQMa6: add SPI support
>   TQMa6: add SPI NOR boot support
>   TQMa6: MBa6: add usb support
>   TQMa6: add I2C support
>   TQMa6: add pmic support
> 
>  board/tqc/tqma6/Makefile |9 +
>  board/tqc/tqma6/README   |   35 
>  board/tqc/tqma6/clocks.cfg   |   24 +++
>  board/tqc/tqma6/tqma6.c  |  258 +++
>  board/tqc/tqma6/tqma6_bb.h   |   30 +++
>  board/tqc/tqma6/tqma6_mba6.c |  358 +++
>  board/tqc/tqma6/tqma6q.cfg   |  125 +++
>  board/tqc/tqma6/tqma6s.cfg   |  125 +++
>  boards.cfg   |4 +
>  include/configs/tqma6.h  |  477 
> ++

I understand that your patchset follow your internal development.
However, it is very uncommon that patches introducing new files are
followed by patches changing the same files again.

I think you should squash your patches.  This makes easy to review them.

Do you take a look at the last patches to have a single image running on
different variations of i.MX6 ? Dual and Quad are supported. Some work
for the Solo is required.

Is it not an attractive alternative for you ? Instead of having several
entries in boards.cfg for each variation of your board, you could have
maybe only one or a couple.

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] [RFC PATCH] Fix bug in T4240QDS code. Don't access nonexistent registers

[York Sun]

On 06/16/2014 07:41 AM, Vasili Galka wrote:
> The code in misc_init_r() verifies actual SERDES clocks versus
> expected. It supposes that the number of clocks is MAX_SERDES.
> However, the number of pllcr0 registers is only SRDS_MAX_BANK. This
> clearly results in access to wrong memory. I don't have the datasheet
> to design a correct solution, but at least let's change it to access
> only the existing registers.
> 
> Signed-off-by: Vasili Galka 
> Cc: York Sun 
> ---
>  board/freescale/t4qds/t4240qds.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/board/freescale/t4qds/t4240qds.c 
> b/board/freescale/t4qds/t4240qds.c
> index fe1bc7f..6646042 100644
> --- a/board/freescale/t4qds/t4240qds.c
> +++ b/board/freescale/t4qds/t4240qds.c
> @@ -662,7 +662,7 @@ int misc_init_r(void)
>   }
>   }
>  
> - for (i = 0; i < MAX_SERDES; i++) {
> + for (i = 0; i < SRDS_MAX_BANK; i++) {
>   u32 pllcr0 = srds_regs->bank[i].pllcr0;
>   u32 expected = pllcr0 & SRDS_PLLCR0_RFCK_SEL_MASK;
>   if (expected != actual[i]) {
> 
Thanks for fixing it.

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

Re: [U-Boot] [PATCH 4/6] mmc: fsl_esdhc: Add support to force VSELECT set

[Michael Trimarchi]

Hi

On Tue, Jun 17, 2014 at 5:49 PM, Marek Vasut  wrote:
> On Tuesday, June 17, 2014 at 08:06:38 AM, Michael Trimarchi wrote:
>> Hi Marek
>>
>> Il 17/giu/2014 08:03 "Marek Vasut"  ha scritto:
>> > On Monday, June 16, 2014 at 01:48:11 PM, Otavio Salvador wrote:
>> > > On Mon, Jun 16, 2014 at 4:03 AM, Igor Grinberg
>> > > 
>> >
>> > wrote:
>> > > > Hi Otavio,
>> > > >
>> > > > On 06/16/14 05:24, Otavio Salvador wrote:
>> > > >> On Sun, Jun 15, 2014 at 11:03 PM, Marek Vasut  wrote:
>> > > >>> On Monday, June 16, 2014 at 03:39:08 AM, Otavio Salvador wrote:
>> > >  On Sun, Jun 15, 2014 at 10:27 PM, Marek Vasut 
>>
>> wrote:
>> > > > On Monday, June 16, 2014 at 03:22:22 AM, Otavio Salvador wrote:
>> > > >
>> > > > [...]
>> > > >
>> > >  +#ifdef CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT
>> > >  + esdhc_setbits32(®s->vendorspec,
>> > >  ESDHC_VENDORSPEC_VSELECT); +#endif
>> > > >>>
>> > > >>> Documentation is missing.
>> > > >>
>> > > >> There is no FSL ESDHC README file so that's why I didn't include
>>
>> it
>>
>> > > >> anywhere.
>> > > >
>> > > > I'm at loss for words here, really...
>> > > >
>> > > > I think you know what needs to be done (hint: write the
>> > > > documentation), right ?
>> > > 
>> > >  I won't write the full documentation for it. I am sorry.
>> > > >>>
>> > > >>> Undocumented configuration option is not acceptable, period.
>> > > >>
>> > > >> Who accepted the driver in the first version, without Doc?
>> > > >>
>> > > >> I am not in the position to write the full doc.
>> > > >
>> > > > I think there is a misunderstanding here...
>> > > > I think Marek does not want to say that you need to write the full
>> > > > documentation for the driver, but only document the
>> > > > CONFIG_SYS_FSL_ESDHC_FORCE_VSELECT configuration option (what does it
>>
>> do
>>
>> > > > when you define it and why should one define it).
>> > >
>> > > Great but where if it does not exist?
>> > >
>> > > should I make a README.fsl-esdhc and include just it?
>> >
>> > I briefly looked over the options in the driver, prefixed with hash are
>>
>> the ones
>>
>> > which are not driver specific:
>> >
>> > CONFIG_ESDHC_DETECT_8_BIT_QUIRK
>> > CONFIG_ESDHC_DETECT_QUIRK
>> > CONFIG_FSL_ESDHC_PIN_MUX
>> > CONFIG_FSL_USDHC
>> > #CONFIG_MX53
>> > #CONFIG_OF_LIBFDT
>> > CONFIG_SYS_FSL_ERRATUM_ESDHC111
>> > CONFIG_SYS_FSL_ERRATUM_ESDHC135
>> > CONFIG_SYS_FSL_ERRATUM_ESDHC_A001
>> > CONFIG_SYS_FSL_ESDHC_ADDR
>> > CONFIG_SYS_FSL_ESDHC_USE_PIO
>> > CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33
>> > #CONFIG_SYS_MMC_MAX_BLK_COUNT
>> > #CONFIG_SYS_SD_VOLTAGE
>> > #CONFIG_T4240QDS
>> >
>> > It looks like completely ad-hoc addition of new and new config options as
>> > whoever seen fit to me, both from their names and git log of the driver.
>>
>> This
>>
>> > makes the driver completely unmaintainable. I would like to see them
>>
>> documented
>>
>> Do you think that could be a better option to use flags and runtime detect
>> instead having hundred of define?
>
> Eventually, when we transition to DT, this will be indeed needed anyway. But
> before that, we need to understand what those flags do (which we don't because
> previous patches neglected adding proper documentation).

I suggest as Stefano said to add this option/flags now in preparation
of DT transition
and start to document flags as you said.

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

Re: [U-Boot] [PATCH v2] mxs: fixed battery boot on imx233-olinuxino-micro

[Stefano Babic]

Hi peter,

On 17/06/2014 00:19, Marek Vasut wrote:
> On Tuesday, June 17, 2014 at 12:18:55 AM, Marek Vasut wrote:
>> On Sunday, June 15, 2014 at 03:11:56 PM, Peter Schumann wrote:
>>> This patch makes it possible to boot from battery on olinuxino Boards
>>> from Olimex.
>>>
>>> We should not set DOUBLE_FETS in HW_POWER_MINPWR, it makes my system
>>> reset with in seconds while running on battery power.
>>>
>>> Also  mxs_power_enable_4p2() should not be called if running from
>>> battery. It switches VDDD and VDDA to LinReg mode and than turns off
>>> the VDDIO DCDC supply. At this point the system resets.
>>> If we run on battery this is no good idea because the LinRegs are
>>> chained behind VDDIO and battery voltage seems not enough to power
>>> the system from LinRegs.
>>> Also is the power system already running on DCDC after BootROM hands
>>> over to u-boot, so no sense in switching back to LinRegs.
>>>
>>> Signed-off-by: Peter Schumann 
>>
>> +CC Fabio, I'd like to see his take on this too.
> 
> Reviewed-by: Marek Vasut 
> 
> I'd like to get this merged after 2014.07 though, so it can get some proper 
> testing. We're too late in the -rc cycle anyway ...
> 

Agree. Reason is that this change is for all boards, and without a
proper testing I will avoid to merge it in the release.

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] [PATCH 1/6] usb: ehci: mx6: Add support for i.MX6SL

[Nikolay Dimitrov]

Hi Marek,

On 6/16/2014 5:53 PM, Marek Vasut wrote:
Please do not top-post. 
Please excuse me - I was unable to find posting guidelines for the 
mailing list, so just posted by habit (last time I had to post to 
another list, they wanted me to top-post).


With the upcoming DM implementation, that's what we plan. Moreover, 
the checks are not expensive, you just decide the address based on the 
CPU model and assign it into some variable. You then access the 
registers via that variable + offset, as usual. 

I see. Would be great to see this compatibility coming.


Best regards,
Marek Vasut

Thanks for taking your time to reply.

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

Re: [U-Boot] [PATCH 1/7] nand_spl: remove P1023RDS_NAND support

[York Sun]

On 06/17/2014 08:41 AM, Scott Wood wrote:
> On Tue, 2014-06-17 at 17:36 +0900, Masahiro Yamada wrote:
>> Hello Scott,
>>
>> On Mon, 16 Jun 2014 16:46:13 -0500
>> Scott Wood  wrote:
>>
>>> FWIW, all p1023rds support can probably be removed.  Very few boards
>>> were ever sold, and support was recently removed from Linux (commit
>>> fd7e5b7a8758093781a44df9577fe24e9e11723e).
>>>
>>
>> In that case, could you send a patch to remove it?
>> Or shall I do that ?
> 
> I'm hoping York and/or Roy will comment on the removal first.
> 

Looks like we agree to remove P1023RDS board. We have a patch pending for this.
I will test it soon.

York

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

Re: [U-Boot] [PATCH 1/6] usb: ehci: mx6: Add support for i.MX6SL

[Marek Vasut]

On Tuesday, June 17, 2014 at 06:21:05 PM, Nikolay Dimitrov wrote:
> Hi Marek,
> 
> On 6/16/2014 5:53 PM, Marek Vasut wrote:
> > Please do not top-post.
> 
> Please excuse me - I was unable to find posting guidelines for the
> mailing list, so just posted by habit (last time I had to post to
> another list, they wanted me to top-post).

Then follow RFC1855, quote:

"
- If you are sending a reply to a message or a posting be sure you
  summarize the original at the top of the message, or include just
  enough text of the original to give a context.  This will make
  sure readers understand when they start to read your response.
"
;-)

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

Re: [U-Boot] [PATCH v2 04/11] drivers:dfu: new feature: separated bootloader alt setting

[Stephen Warren]

On 06/17/2014 04:20 AM, Przemyslaw Marczak wrote:
> Hello Stephen,
> 
> On 06/16/2014 09:52 PM, Stephen Warren wrote:
>> On 06/12/2014 03:46 AM, Przemyslaw Marczak wrote:
>>> This patch introduces new feature: initialization of the dfu
>>> bootloader entity from a separate environmental variable which
>>> can be set on a boot time.
>>>
>>> By default, DFU always check environmental variable: $dfu_alt_info.
>>>
>>> Changes:
>>> - DFU will also look for environmental variable: $dfu_alt_bootloader
>>> - if any of dfu_alt_* variable is properly defined, then function
>>>dfu_init_env_entities() will return success.
>>>
>>> Use case:
>>> Some devices can boot from various media type (SD, eMMC, NAND, etc.)
>>> or some board configs are common for more than one board type.
>>> In a such case, bootloader is probably placed on a different
>>> devices or even offsets. So such DFU feature is welcome.
>>
>> Why should the "dfu" command look at different environment variables?
>> Whatever code dynamically sets the value of $dfu_alt_bootloader should
>> simply set $dfu_alt_info instead.
> 
> Dynamically setting of any entity cold be done at boot time, like this:
> 
> # int buf_len = strlen(alt_bootloader) + strlen(CONFIG_DFU_ALT) + 4;
> # char *buf = memalign(1, buf_len);
> #
> # sprintf(buf, "%s; %s", alt_bootloader, CONFIG_DFU_ALT);

Note that you can't have a space after the ; due to the use of strsep().
Switching to strtok() might solve that.

> # setenv("dfu_alt_info", buf);
> 
> But overwriting the $dfu_alt_info on each boot is not a good idea.
> If user modify the dfu entities - then it will be overwritten at next boot.

What if the user sees that $dfu_alt_bootloader is set, and modifies that
without realizing that it's an auto-generated variable? The same thing
then applies.

Perhaps we need a standard where system-/automatically-set variables are
named with a auto_ prefix or _auto suffix or something, to make this clear?

I'd prefer that the dfu command didn't use any environment variables,
but rather required the user to always pass the list on the
command-line. Then, the user could invoke either:

dfu "foo mmc x..." # Manually specified
dfu $dfu_alt_info # Use 'user-defined' variable
dfu $dfu_alt_bootloaer # Use 'system-defined' variable

That way, the code doesn't have to loop over a bunch of variables and
get more complex. Implicitly depending on environment variables make it
hard to tell what a sequence of commands will do.

...
> Maybe better could be modification of the function
> dfu_init_env_entities() to support parsing variables
> in the $dfu_alt_info instead of hard coded env variables
> names, e.g:
> 
> dfu_alt_info="${alt_info_boot}, ${alt_info_system},..."

I feel like the shell already has the capability to interpolate variable
values into strings, so this would be quite easy to do in the shell
rather than duplicating that code inside the dfu command.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PULL] : Please pull u-boot-imx

[Stefano Babic]

Hi Albert,

please pull from u-boot-imx, thanks !

The following changes since commit 49692c5f517d8e44ed9db0de778728fe7d2a300c:

  net/designware: Make DMA burst length configurable and reduce by
default (2014-05-25 17:23:58 +0200)

are available in the git repository at:

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

for you to fetch changes up to f2f07e8553185022b16adb91581700c86dc3a09a:

  imx: correct HAB status for new chip TO (2014-06-17 17:45:09 +0200)


Eric Nelson (1):
  serial_mxc: disable new features of autobaud detection

Fabio Estevam (9):
  mx6sabreauto: Add the mx6dual-lite variant
  mx6sabred: Add PFUZE100 PMIC support
  mx25pdk: Add generic board support
  mx6: Fix definition of IOMUXC_GPR12_DEVICE_TYPE_RC
  embestmx6boards: Fix CONFIG_CONSOLE_DEV
  embestmx6boards: Fix the dtb file name for riotboard
  mx28evk: Fix warning when CONFIG_ENV_IS_IN_SPI_FLASH is selected
  mx28evk: Add a target for SPI NOR boot
  mx28evk: Add documentation on how to boot from SPI NOR

Marek Vasut (1):
  arm: mx5: Enable CONFIG_SYS_GENERIC_BOARD on M53EVK

Masahiro Yamada (1):
  spl: consolidate arch/arm/include/asm/arch-*/spl.h

Shawn Guo (1):
  mx6: drop ARM errata 742230

Stefano Babic (2):
  MX25: fix build due to missing sys_proto.h
  imx: correct HAB status for new chip TO

Tim Harvey (12):
  spl: nand: add support for mxs nand
  mx6: add common SPL configuration
  mx6: add boot device support for SPL
  imx: add comments and remove unused struct fields
  mx6: add structs for mmdc and ddr iomux registers
  mx6: add mmdc configuration for MX6Q/MX6DL
  imx: iomux: add macros to setup iomux for multiple SoC types
  imx: ventana: split read_eeprom into standalone file
  imx: ventana: auto-configure for IMX6Q vs IMX6DL
  imx: ventana: switch to SPL
  dwc_ahsata: return failure for MX6 if not IMX6Q/IMX6D
  imx: sata: return failure if not IMX6Q/IMX6D

 arch/arm/cpu/arm720t/tegra-common/spl.c |   2 +-
 arch/arm/cpu/armv7/mx6/Makefile |   1 +
 arch/arm/cpu/armv7/mx6/ddr.c| 490
++
 arch/arm/cpu/armv7/mx6/hab.c|  73 +-
 arch/arm/imx-common/Makefile|   1 +
 arch/arm/imx-common/cpu.c   |  16 +--
 arch/arm/imx-common/iomux-v3.c  |  18 ++-
 arch/arm/imx-common/sata.c  |   7 +-
 arch/arm/imx-common/spl.c   |  81 +++
 arch/arm/include/asm/arch-at91/spl.h|  24 
 arch/arm/include/asm/arch-davinci/spl.h |  16 ---
 arch/arm/include/asm/arch-mx35/spl.h|  22 ---
 arch/arm/include/asm/arch-mx5/spl.h |  13 --
 arch/arm/include/asm/arch-mx6/hab.h |  17 ++-
 arch/arm/include/asm/arch-mx6/imx-regs.h|   2 +
 arch/arm/include/asm/arch-mx6/iomux.h   |   2 +-
 arch/arm/include/asm/arch-mx6/mx6-ddr.h | 231
++
 arch/arm/include/asm/arch-mx6/sys_proto.h   |   4 +-
 arch/arm/include/asm/arch-tegra114/spl.h|  22 ---
 arch/arm/include/asm/arch-tegra124/spl.h|  13 --
 arch/arm/include/asm/arch-tegra20/spl.h |  12 --
 arch/arm/include/asm/arch-tegra30/spl.h |  12 --
 arch/arm/include/asm/imx-common/iomux-v3.h  |  25 
 arch/arm/include/asm/spl.h  |  20 +++
 board/denx/m53evk/m53evk.c  |   2 +-
 board/freescale/mx28evk/README  |  22 ++-
 board/freescale/mx6qsabreauto/mx6dl.cfg | 130 +
 board/freescale/mx6sabresd/mx6sabresd.c |  84 +++
 board/gateworks/gw_ventana/Makefile |   3 +-
 board/gateworks/gw_ventana/README   |  92 +++-
 board/gateworks/gw_ventana/eeprom.c |  89 
 board/gateworks/gw_ventana/gw_ventana.c | 597
+---
 board/gateworks/gw_ventana/gw_ventana.cfg   |  15 --
 board/gateworks/gw_ventana/gw_ventana_spl.c | 419
+
 board/gateworks/gw_ventana/ventana_eeprom.h |  11 ++
 boards.cfg  |   8 +-
 doc/README.mxs  |  26 
 drivers/block/dwc_ahsata.c  |   5 +
 drivers/mtd/nand/Makefile   |   1 +
 drivers/mtd/nand/mxs_nand_spl.c | 231
++
 drivers/serial/serial_mxc.c |   4 +-
 include/configs/embestmx6boards.h   |   4 +-
 include/configs/gw_ventana.h|  11 ++
 include/configs/imx6_spl.h  |  71 +
 include/configs/m53evk.h|   1 +
 include/configs/mx25pdk.h   |   2 +
 include/configs/mx28evk.h   |   5 +-
 include/configs/mx6_common.h|   1 -
 include/configs/mx6qsabreauto.h

[U-Boot] [PATCH] video: ipu_disp: squash clang warning

[Jeroen Hofstee]

Since rgb2ycbcr_coeff and friends are declared const, but assigned
to a void pointer, clang will warn that the const is implicity casted
away. If the pointer is changed to void const * gcc will warn when it
is implicitly casted to a const int array. Just add a correctly
typed pointer instead to prevent these casts and hence the warnings.

Cc: Troy Kisky 
Cc: Stefano Babic 
Signed-off-by: Jeroen Hofstee 

---
changes since v1:
  Do actually fix the warning. As pointed out by Troy Kisky
  the patch was doing something different then the commit
  message said.
---
 drivers/video/ipu_disp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/ipu_disp.c b/drivers/video/ipu_disp.c
index cefd2dc..d5e857c 100644
--- a/drivers/video/ipu_disp.c
+++ b/drivers/video/ipu_disp.c
@@ -33,7 +33,7 @@ enum csc_type_t {
 
 struct dp_csc_param_t {
int mode;
-   void *coeff;
+   const int (*coeff)[5][3];
 };
 
 #define SYNC_WAVE 0
-- 
1.8.3.2

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

[U-Boot] [[PATCH v2]] video: ipu_disp: squash clang warning

[Jeroen Hofstee]

Since rgb2ycbcr_coeff and friends are declared const, but assigned
to a void pointer, clang will warn that the const is implicity casted
away. If the pointer is changed to void const * gcc will warn when it
is implicitly casted to a const int array. Just add a correctly
typed pointer instead to prevent these casts and hence the warnings.

Cc: Troy Kisky 
Cc: Stefano Babic 
Signed-off-by: Jeroen Hofstee 

---
changes since v1:
  Do actually fix the warning. As pointed out by Troy Kisky
  the patch was doing something different then the commit
  message said.

  ... and prefix subject with v2
---
 drivers/video/ipu_disp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/ipu_disp.c b/drivers/video/ipu_disp.c
index cefd2dc..d5e857c 100644
--- a/drivers/video/ipu_disp.c
+++ b/drivers/video/ipu_disp.c
@@ -33,7 +33,7 @@ enum csc_type_t {
 
 struct dp_csc_param_t {
int mode;
-   void *coeff;
+   const int (*coeff)[5][3];
 };
 
 #define SYNC_WAVE 0
-- 
1.8.3.2

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

Re: [U-Boot] [Patch v2 0/7] Add support for TQMa6 modules

[Markus Niebel]

Am 17.06.2014 17:55, wrote Stefano Babic:
> Hi Markus,
> 
> On 16/06/2014 18:51, Markus Niebel wrote:
>> From: Markus Niebel 
>>
>> This series add support for the TQMa6 boards from TQ Systems.
>> The first Patch adds basic support for the modiules and the 
>> starterkit baseboard while the other patches add additional features
>>
>> Markus Niebel (7):
>>   Add TQ Systems TQMa6 board support
>>   TQMa6: mba6: add RGMII enet
>>   TQMa6: add SPI support
>>   TQMa6: add SPI NOR boot support
>>   TQMa6: MBa6: add usb support
>>   TQMa6: add I2C support
>>   TQMa6: add pmic support
>>
>>  board/tqc/tqma6/Makefile |9 +
>>  board/tqc/tqma6/README   |   35 
>>  board/tqc/tqma6/clocks.cfg   |   24 +++
>>  board/tqc/tqma6/tqma6.c  |  258 +++
>>  board/tqc/tqma6/tqma6_bb.h   |   30 +++
>>  board/tqc/tqma6/tqma6_mba6.c |  358 +++
>>  board/tqc/tqma6/tqma6q.cfg   |  125 +++
>>  board/tqc/tqma6/tqma6s.cfg   |  125 +++
>>  boards.cfg   |4 +
>>  include/configs/tqma6.h  |  477 
>> ++
> 
> I understand that your patchset follow your internal development.
> However, it is very uncommon that patches introducing new files are
> followed by patches changing the same files again.
> 
> I think you should squash your patches.  This makes easy to review them.
> 
I thought to have at first a simple and restricted config / board support would 
be easier 
to read, but no problem - will squash it.
> Do you take a look at the last patches to have a single image running on
> different variations of i.MX6 ? Dual and Quad are supported. Some work
> for the Solo is required.
> 
> Is it not an attractive alternative for you ? Instead of having several
> entries in boards.cfg for each variation of your board, you could have
> maybe only one or a couple.
Sure it is - main difference will be boot devices. The env on different boot 
media
in one image is AFAIK not possible - so at the moment four configs are needed: 
SP vs MMC and i.MX6Q/D vs i.MX6S (But this is slightly OT)
> 
> Best regards,
> Stefano Babic
> 

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

Re: [U-Boot] [PATCH 1/6] usb: ehci: mx6: Add support for i.MX6SL

[Nikolay Dimitrov]

Hi Igor,

On 6/17/2014 9:26 AM, Igor Grinberg wrote:
That is exactly what we do already (code is on the way) and IMO what 
we should aim for.
I really didn't knew this in the beginning before seeing your answers, 
this would be definitely easier

to support.


For me it is just an artificial complication which prevents single binary for
i.MX6 based boards.
Don't get me wrong, I think that in your board code you can choose which
approach you want, whether it will be single or multi binary, but this
is i.MX6 (and possibly future i.MX*) USB code which can be used on many
i.MX6 boards.

I definitely like the idea, no argument on this.

Again, what are we talking about? A couple of bytes? 

I think it will cost 22 additional bytes per check. Here's a rough example:

(Code that just assigns the address to the struct pointer -> 10 bytes)
p = (mx6_usb_t*)0x55667788;
8380:   f247 7388   movwr3, #30600  ; 0x7788
8384:   f2c5 5366   movtr3, #21862  ; 0x5566
8388:   60fbstr r3, [r7, #12]


(Code that checks in runtime the CPU type -> 32 bytes)
if (is_imx6q())
8380:   f7ff ffee   bl  8360 
8384:   4603mov r3, r0
8386:   2b00cmp r3, #0
8388:   d005beq.n   8396 
{
p = (mx6_usb_t*)0x11223344;
838a:   f243 3344   movwr3, #13124  ; 0x3344
838e:   f2c1 1322   movtr3, #4386   ; 0x1122
8392:   60fbstr r3, [r7, #12]
8394:   e004b.n 83a0 
}
else
{
p = (mx6_usb_t*)0x55667788;
8396:   f247 7388   movwr3, #30600  ; 0x7788
839a:   f2c5 5366   movtr3, #21862  ; 0x5566
839e:   60fbstr r3, [r7, #12]
}

If I assume that we have 20 sub-systems in U-Boot, and each needs to 
check the CPU type
in 10 places, this makes 4400 bytes difference, which is roughly the 
size of a moderately
small driver in U-Boot. I need to say that I'm in no way expert in ARM 
assembly, so please

feel free to point out any mistakes in my assumptions.

Please don't get me wrong - I don't want to argue at all. I was just 
wondering about this topic

and decided to check with you guys just to be sure.

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

Re: [U-Boot] [Patch v2 0/7] Add support for TQMa6 modules

[Stefano Babic]

Hi Markus,

On 17/06/2014 19:40, Markus Niebel wrote:

>> Is it not an attractive alternative for you ? Instead of having several
>> entries in boards.cfg for each variation of your board, you could have
>> maybe only one or a couple.

> Sure it is - main difference will be boot devices.

Right - I am expecting then an entry in boards.cfg for each media, that
is able to run on all SOCs.

> The env on different boot media
> in one image is AFAIK not possible - so at the moment four configs are 
> needed: 
> SP vs MMC and i.MX6Q/D vs i.MX6S (But this is slightly OT)

Well, SP vs MMC is right. But having an entry for all SOCs without
having to select one of it at compile time, it is really a plus ;-)

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

[U-Boot] Use UART1 port on p1022 through U-Boot

[Nildo Junior]

Hi,

I am using a Freescale p1022 processor, and I need to write to the UART1
port of this processor, through U-Boot. I know it currently uses UART0 as
the console input/output. I could not find out how to configure it so I can
use UART1 as well.

If somebody have a hint, I will be really grateful.

Cheers,

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

Re: [U-Boot] [PATCH 2/5] kbuild: sync mixed targets handling with Linux 3.16-rc1

[Jeroen Hofstee]

Hello Masahiro,

On 17-06-14 03:42, Masahiro Yamada wrote:

On Mon, 16 Jun 2014 19:58:28 +0200
Jeroen Hofstee  wrote:


Hello Masahiro,

On ma, 2014-06-16 at 18:56 +0900, Masahiro Yamada wrote:

"make %_config all" was supported for the first time in U-Boot:
   commit 53bca5ab
   kbuild: support simultaneous board configuration and "make all"

Surprisingly it had not been working in Linux Kernel for a long time.

So I sent back the patch to the Linux Kbuild community and it was
accepted with a little code improvement, at commit 9319f453.

Now, you can do "make defconfig all" or "make %_defconfig all"
in Linux too.


There is some issue with this in current master I guess. I haven't
bothered too much, but I think the one liner cause gcc to be called even
if both compilers are set to clang. With a separate config and make step
I have never seen such behavior. I only noticed it on FreeBSD though
since gcc is not installed there and actually errors, so it might be
awk / sed related as well.

Anyway, perhaps rings a bell...


Could you tell me how to reproduce the problem?

As far as I tested on FreeBSD where gcc is not installed,
I do not see that problem.

This is my repeat steps.
It fails on the halfway, but at least Clang is used for both HOSTCC and CC.


Weird, below is my build output on current master with some floating
patches to make the build succeed [1] (well I didn't send the time.h yet
since I don't understand how linux gets away with that at the moment)

As mentioned I have no clue why it fails and haven't looked into it.
Just noticed it didn't work.

[1] https://github.com/jhofstee/u-boot/tree/FreeBSD

Regards,
Jeroen

[jeroen@freebsd /usr/home/jeroen/u-boot]$ cc -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd11.0
Thread model: posix
Selected GCC installation:

[jeroen@freebsd /usr/home/jeroen/u-boot]$ gmake -v
GNU Make 3.82
Built for amd64-portbld-freebsd10.0
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


[jeroen@freebsd /usr/home/jeroen/u-boot]$ git branch
* FreeBSD
  master
[jeroen@freebsd /usr/home/jeroen/u-boot]$ rm -rf *
[jeroen@freebsd /usr/home/jeroen/u-boot]$ git branch
* FreeBSD
  master
[jeroen@freebsd /usr/home/jeroen/u-boot]$ git checkout -f
[jeroen@freebsd /usr/home/jeroen/u-boot]$ git describe
v2014.07-rc3-73-g9188205
[jeroen@freebsd /usr/home/jeroen/u-boot]$ uname -a
FreeBSD freebsd 11.0-CURRENT FreeBSD 11.0-CURRENT #0 0ed0329(master): 
Fri Jun  6 14:47:31 CEST 2014 root@freebsd:/usr/obj/usr/src/sys/GENERIC  
amd64
[jeroen@freebsd /usr/home/jeroen/u-boot]$ gmake CC="cc" HOSTCC="cc" V=1 
NO_SDL=1 sandbox_config tools

set -e; \
for i in sandbox_config tools; do \
gmake -f /usr/home/jeroen/u-boot/Makefile $i; \
done
Configuring for sandbox board...
  cc -x c -DDO_DEPS_ONLY -M -Wall -Wstrict-prototypes 
-Wno-format-security -fno-builtin -ffreestanding -Os 
-fno-stack-protector -g -Wno-format-nonliteral   -D__KERNEL__ 
-DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE 
-DCONFIG_ARCH_MAP_SYSMEM -DCONFIG_SYS_GENERIC_BOARD -DSANDBOX_NO_SDL  
-pipe -Iinclude -I/usr/home/jeroen/u-boot/arch/sandbox/include  
-nostdinc -isystem /usr/lib/include -MQ include/autoconf.mk 
/usr/home/jeroen/u-boot/include/common.h > include/autoconf.mk.dep || rm 
include/autoconf.mk.dep
  cc -E -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin 
-ffreestanding -Os  -fno-stack-protector -g -Wno-format-nonliteral 
-D__KERNEL__   -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE 
-DCONFIG_ARCH_MAP_SYSMEM -DCONFIG_SYS_GENERIC_BOARD -DSANDBOX_NO_SDL  
-pipe -Iinclude -I/usr/home/jeroen/u-boot/arch/sandbox/include  
-nostdinc -isystem /usr/lib/include -DDO_DEPS_ONLY -dM 
/usr/home/jeroen/u-boot/include/common.h > include/autoconf.mk.tmp && 
sed -n -f /usr/home/jeroen/u-boot/tools/scripts/define2mk.sed 
include/autoconf.mk.tmp > include/autoconf.mk; rm include/autoconf.mk.tmp

gmake[1]: gcc: Command not found
gmake[1]: gcc: Command not found
gcc: not found
usage: dirname string [...]
set -e; : '  CHK include/config/uboot.release'; mkdir -p 
include/config/; echo "2014.07-rc3$(sh 
/usr/home/jeroen/u-boot/scripts/setlocalversion 
/usr/home/jeroen/u-boot)" < Makefile > include/config/uboot.release.tmp; 
if [ -r include/config/uboot.release ] && cmp -s 
include/config/uboot.release include/config/uboot.release.tmp; then rm 
-f include/config/uboot.release.tmp; else : '  UPD 
include/config/uboot.release'; mv -f include/config/uboot.release.tmp 
include/config/uboot.release; fi

gmake[1]: gcc: Command not found
set -e; : '  CHK include/generated/version_autogenerated.h'; mkdir 
-p include/generated/; (echo \#define PLAIN_VERSION 
\"2014.07-rc3-00073-g9188205\"; echo \#define U_BOOT_VERSION \"U-Boot \" 
PLAIN_VERSION; echo \#define CC_VE

Re: [U-Boot] [PATCH 2/4] mx6sx: Add pin definitions

[Eric Nelson]

Hi Stefano,

On 06/17/2014 08:40 AM, Stefano Babic wrote:
> Hi Fabio,
> 
> On 14/06/2014 22:29, Fabio Estevam wrote:
>> From: Fabio Estevam 
>>
>> Add the pin definitions for mx6sx.
>>
> 
> A base question. There was a lot of work to try to abstract the pin
> definitions for the i.MX6 SOCs. For QUAD and DUAL, the pins are defined
> with the MX6_PAD_DECL macro. It works differently according to the
> selected CPU. If more as one CPU is supported in the same image, the
> check is done at runtime.
> 
> Previously, we had IOMUX_PAD, I know. Is there any special reason we
> cannot use MX6_PAD_DECL even for this new SOC ? I will not want to go
> back ignoring a lot of work that was done to merge the SOCs together.
> 

The rationale for the MX6_PAD_DECL came from the fact that the
i.MX6DQ and i.MX6DLS cpu variants had different address schemes,
but were pin-compatible.

The i.MX6SL (and i.MX6SX) are not, so any board supporting these
processors only supports that processor.

Regards,


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

[U-Boot] [PATCH] usb: cosmetic: double const

[Jeroen Hofstee]

For plain array const can be either before or after
the type definition. Adding both is simply redundand.
Remove the later one.

cc: ma...@denx.de
Signed-off-by: Jeroen Hofstee 
---
 drivers/usb/eth/asix.c| 2 +-
 drivers/usb/eth/mcs7830.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
index ce133f0..6557055 100644
--- a/drivers/usb/eth/asix.c
+++ b/drivers/usb/eth/asix.c
@@ -565,7 +565,7 @@ struct asix_dongle {
int flags;
 };
 
-static const struct asix_dongle const asix_dongles[] = {
+static const struct asix_dongle asix_dongles[] = {
{ 0x05ac, 0x1402, FLAG_TYPE_AX88772 },  /* Apple USB Ethernet Adapter */
{ 0x07d1, 0x3c05, FLAG_TYPE_AX88772 },  /* D-Link DUB-E100 H/W Ver B1 */
{ 0x2001, 0x1a02, FLAG_TYPE_AX88772 },  /* D-Link DUB-E100 H/W Ver C1 */
diff --git a/drivers/usb/eth/mcs7830.c b/drivers/usb/eth/mcs7830.c
index c353286..8e738d4 100644
--- a/drivers/usb/eth/mcs7830.c
+++ b/drivers/usb/eth/mcs7830.c
@@ -666,7 +666,7 @@ struct mcs7830_dongle {
 /*
  * mcs7830_dongles - the list of supported Moschip based USB ethernet dongles
  */
-static const struct mcs7830_dongle const mcs7830_dongles[] = {
+static const struct mcs7830_dongle mcs7830_dongles[] = {
{ 0x9710, 0x7832, },/* Moschip 7832 */
{ 0x9710, 0x7830, },/* Moschip 7830 */
{ 0x9710, 0x7730, },/* Moschip 7730 */
-- 
1.8.3.2

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

[U-Boot] [PATCH] mtd: cfi_flash: fix clang warning

[Jeroen Hofstee]

clang warns this check is silly; it is since s is
a local variable.

u-boot/drivers/mtd/cfi_flash.c:2363:13: warning: comparison of
  array 's' not equal to a null pointer is always true
  else if ((s != NULL) && (strcmp(s, "yes") == 0)) {

cc: Stefan Roese 
Signed-off-by: Jeroen Hofstee 
---
 drivers/mtd/cfi_flash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index a389cd1..c4b5bc1 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -2360,7 +2360,7 @@ unsigned long flash_init (void)
 #endif /* CONFIG_SYS_FLASH_QUIET_TEST */
}
 #ifdef CONFIG_SYS_FLASH_PROTECTION
-   else if ((s != NULL) && (strcmp(s, "yes") == 0)) {
+   else if (strcmp(s, "yes") == 0) {
/*
 * Only the U-Boot image and it's environment
 * is protected, all other sectors are
-- 
1.8.3.2

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

[U-Boot] [PATCH] driver/ddr: Fix DDR4 driver for ARM

[York Sun]

Previously the driver was only tested on Power SoCs. Minor fix is needed
for ARM SoCs.

Signed-off-by: York Sun 
---
 arch/arm/include/asm/arch-fsl-lsch3/config.h |4 
 drivers/ddr/fsl/fsl_ddr_gen4.c   |9 +
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/include/asm/arch-fsl-lsch3/config.h 
b/arch/arm/include/asm/arch-fsl-lsch3/config.h
index d61a213..60719fd 100644
--- a/arch/arm/include/asm/arch-fsl-lsch3/config.h
+++ b/arch/arm/include/asm/arch-fsl-lsch3/config.h
@@ -71,7 +71,11 @@
 /* DDR */
 #define CONFIG_SYS_FSL_DDR_LE
 #define CONFIG_VERY_BIG_RAM
+#ifdef CONFIG_SYS_FSL_DDR4
+#define CONFIG_SYS_FSL_DDRC_GEN4
+#else
 #define CONFIG_SYS_FSL_DDRC_ARM_GEN3   /* Enable Freescale ARM DDR3 driver */
+#endif
 #define CONFIG_SYS_FSL_DDR /* Freescale DDR driver */
 #define CONFIG_SYS_LS2_DDR_BLOCK1_SIZE ((phys_size_t)2 << 30)
 #define CONFIG_MAX_MEM_MAPPED  CONFIG_SYS_LS2_DDR_BLOCK1_SIZE
diff --git a/drivers/ddr/fsl/fsl_ddr_gen4.c b/drivers/ddr/fsl/fsl_ddr_gen4.c
index 7cd878a..04f0c44 100644
--- a/drivers/ddr/fsl/fsl_ddr_gen4.c
+++ b/drivers/ddr/fsl/fsl_ddr_gen4.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #if (CONFIG_CHIP_SELECTS_PER_CTRL > 4)
@@ -183,12 +184,20 @@ step2:
 * we choose the max, that is 500 us for all of case.
 */
udelay(500);
+#ifdef CONFIG_PPC
asm volatile("sync;isync");
+#else
+   asm volatile("dsb sy;isb");
+#endif
 
/* Let the controller go */
temp_sdram_cfg = ddr_in32(&ddr->sdram_cfg) & ~SDRAM_CFG_BI;
ddr_out32(&ddr->sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
+#ifdef CONFIG_PPC
asm volatile("sync;isync");
+#else
+   asm volatile("dsb sy;isb");
+#endif
 
total_gb_size_per_controller = 0;
for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH v4 09/15] dm: Cast away the const-ness of the global_data pointer

[Marek Vasut]

On Thursday, June 12, 2014 at 05:26:50 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 8 June 2014 01:00, Marek Vasut  wrote:
> > On Friday, June 06, 2014 at 09:13:26 PM, Simon Glass wrote:
> >> In a very few cases we need to adjust the driver model root device, such
> >> as when setting it up at initialisation. Add a macro to make this
> >> easier.
> >> 
> >> Signed-off-by: Simon Glass 
> >> ---
> > 
> > [...]
> > 
> >> - ret = device_bind_by_name(NULL, &root_info, &gd->dm_root);
> >> + ret = device_bind_by_name(NULL, &root_info, &DM_ROOT());
> > 
> > [...]
> > 
> >> +/* Cast away any volatile pointer */
> >> +#define DM_ROOT()(((gd_t *)gd)->dm_root)
> >> +#define DM_UCLASS_ROOT() (((gd_t *)gd)->uclass_root)
> > 
> > Can you implement this "DM_ROOT()" macro as a function instead ? I
> > believe that'd be much nicer , would have typechecking etc., usual
> > stuff.
> 
> I had a look at this. I don't see how I can do it, but you might have
> ideas.
> 
> In this function call I need to pass a pointer without its const bit.
> I made it const since nothing should change the dm root except driver
> model itself.

All right, I will just be doing a little guesswork here. Shall you not have 
some 
functions to change the DM root then instead of exposing the DM root ? Such 
functions shall not be exported publicly , but available via separate header 
file too ?

Sorry, I might be completely wrong.

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

[U-Boot] [PATCH] spi: davinci: Fix register address for SPI1_BUS

[Axel Lin]

Fix a trivial copy-paste bug.

Signed-off-by: Axel Lin 
---
 drivers/spi/davinci_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 28fb3a2..0ec5b9d 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -41,7 +41,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned 
int cs,
break;
 #ifdef CONFIG_SYS_SPI1
case SPI1_BUS:
-   ds->regs = (struct davinci_spi_regs *)SPI0_BASE;
+   ds->regs = (struct davinci_spi_regs *)SPI1_BASE;
break;
 #endif
 #ifdef CONFIG_SYS_SPI2
-- 
1.8.3.2



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

Re: [U-Boot] Atmel SAMA5D31 NOR boot - sanity check required

[Bo Shen]

Hi Andy,

On 06/17/2014 07:09 PM, Andy Pont wrote:

Hello!

I am currently working on an implementation of NOR boot support for the
Atmel SAMA5D31-EK reference platform as a precursor to a custom hardware
platform.  When tested and working I will push the support back to the
community but what I have at the moment doesn't appear to do anything so I
would appreciate a sanity check on the work done so far.

For reference the documentation for the Atmel SoC says:

If BMS signal is tied to 0, BMS_BIT is read at 1.  The ROM code allows
execution of the code contained in the memory connected to Chip Select 0 of
the External Bus Interface (J828F128P33TF70A) and then goes on to detail the
startup mode and changes that need to be made to the PLL and SMC.


I think you should check more detail in section 12 "Standard Boot 
Strategies". It needs more things to do. I will give a picture in 
following answer.



For simplicity sake, I have taken the standard SAMA5D31-EK configuration of
SPL+U-Boot and have added NOR boot support to SPL based on one of the other
boards.  The board header file has the following configuration:

#define CONFIG_SPL_NOR_SUPPORT
#define CONFIG_SYS_FLASH_CFI1
#define CONFIG_FLASH_CFI_DRIVER 1
#define CONFIG_SYS_FLASH_BASE   0x
#define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE

As per the standard SPL build for this hardware platform the
CONFIG_SYS_INIT_SP_ADDR value is set to 0x31 but I haven't found a
definitive statement that confirms that the internal SRAM is mapped to that
location when in this boot mode.

So my questions are...

Is the SPL+U-Boot implementation the best way for NOR booting or should it
all just be built as a single U-Boot image?


I think SPL + U-boot is a good choice.


Do the settings above look correct, particularly the value for the initial
stack pointer?


The stack pointer use the top address of internal SRAM.


How best do I debug SPL to determine where it is getting lost in the weeds?


As the code execute on NOR flash, so, the SPL configure the CPU clock 
will cause SMC access abortion. So, a brief guide as following:


1. Write a ram function, which do as the datasheet says.
2. Add copy function (copy the ram function into sram) at the begin of 
the SPL code.
3. After the step 1, finished to execute, then, you can jump back to NOR 
to execute.


May you got what I mean, if any questions, please let me know.


Many thanks,

Andy.


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

Re: [U-Boot] [PATCH v3 5/5] Exynos: Split 5250 and 5420 memory bank configuration

[Simon Glass]

Hi Minkyu,

On 16 June 2014 23:28, Minkyu Kang  wrote:
> Dear Akshay Saraswat,
>
> On 04/06/14 01:17, Akshay Saraswat wrote:
>> From: Michael Pratt 
>>
>> Since snow has a different memory configuration than peach, split the
>> configuration between the 5250 and 5420. Exynos 5420 supports runtime
>> memory configuration detection, and can make the determination between 4
>> and 7 banks at runtime.
>
> I think this patch should be included to your peach-pit patchset.
> And I think, the number of banks and the size of bank seems to board specific 
> feature.
> Can you guarantee if it uses same SoC then have same memory banks?

I think this is better than what we have there at present. There is a
patch from Chromium that puts this in the device tree, but it is
probably best dealt with when more patches have landed.

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

[U-Boot] [PATCH v2] arm: rmobile: koelsch: Remove NOR-Flash support from boards.cfg

[Nobuhiro Iwamatsu]

Koelsch board has NOR-Flash function. But this is not used basically.
SPI-ROM is used instead. NOR-Flash support code has been removed, but
this remains in the boards.cfg.
This commit removes config of NOR-Flash from boards.cfg.

Signed-off-by: Nobuhiro Iwamatsu 
Signed-off-by: Nobuhiro Iwamatsu 
---
 V2: Update commit message.
 
 boards.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/boards.cfg b/boards.cfg
index 5a85fad..97335b1 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -375,7 +375,6 @@ Active  arm armv7  omap5   ti   
   omap5_uevm
 Active  arm armv7  rmobile atmark-techno   
armadillo-800evaarmadillo-800eva  - 

Nobuhiro Iwamatsu 
 Active  arm armv7  rmobile kmc kzm9g   
kzm9g - 

Nobuhiro Iwamatsu :Tetsuyuki 
Kobayashi 
 Active  arm armv7  rmobile renesas koelsch 
koelsch   - 

Nobuhiro Iwamatsu 
-Active  arm armv7  rmobile renesas koelsch 
koelsch_nor   koelsch:NORFLASH  

Nobuhiro Iwamatsu 
 Active  arm armv7  rmobile renesas lager   
lager - 

Nobuhiro Iwamatsu 
 Active  arm armv7  rmobile renesas lager   
lager_nor lager:NORFLASH

Nobuhiro Iwamatsu 
 Active  arm armv7  s5pc1xx samsung goni
s5p_goni  - 

Przemyslaw Marczak 
-- 
2.0.0

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

[U-Boot] [PATCH v2] arm: rmobile: lager: Remove NOR-Flash support from boards.cfg

[Nobuhiro Iwamatsu]

Lager board has NOR-Flash function. But this is not used basically.
SPI-ROM is used instead. NOR-Flash support code has been removed, but
this remains in the boards.cfg.
This commit removes config of NOR-Flash from boards.cfg.

Signed-off-by: Nobuhiro Iwamatsu 
Signed-off-by: Nobuhiro Iwamatsu 
---
 v2: Update commit message.

 boards.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/boards.cfg b/boards.cfg
index 97335b1..2509233 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -376,7 +376,6 @@ Active  arm armv7  rmobile 
atmark-techno   armadillo-800eva
 Active  arm armv7  rmobile kmc kzm9g   
kzm9g - 

Nobuhiro Iwamatsu :Tetsuyuki 
Kobayashi 
 Active  arm armv7  rmobile renesas koelsch 
koelsch   - 

Nobuhiro Iwamatsu 
 Active  arm armv7  rmobile renesas lager   
lager - 

Nobuhiro Iwamatsu 
-Active  arm armv7  rmobile renesas lager   
lager_nor lager:NORFLASH

Nobuhiro Iwamatsu 
 Active  arm armv7  s5pc1xx samsung goni
s5p_goni  - 

Przemyslaw Marczak 
 Active  arm armv7  s5pc1xx samsung smdkc100
smdkc100  - 

Minkyu Kang 
 Active  arm armv7  socfpga altera  socfpga 
socfpga_cyclone5  - 

-
-- 
2.0.0

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

Re: [U-Boot] m68k: Fix warnings with gcc 4.6

[Simon Glass]

Hi Masahiro,

On 17 June 2014 01:34, Masahiro Yamada  wrote:
> Hi Simon,
>
>
> On Wed, 11 Jun 2014 18:19:28 -0400
> Tom Rini  wrote:
>
>> On Sat, Jun 07, 2014 at 10:07:58PM -0600, Simon Glass wrote:
>>
>> > Most of the warnings seem to be related to using 'int' for size_t. Change
>> > this and fix up the remaining warnings and problems. For bootm, the warning
>> > was masked by others, and there is an actual bug in the code.
>> >
>> > Signed-off-by: Simon Glass 
>>
>> Applied to u-boot/master, thanks!
>>
>> --
>> Tom
>
>
>
> Since commit ddc94378d, I see lots of warnings when compiling m68k boards 
> like this:
>
>
>
>
> Configuring for M52277EVB - Board: M52277EVB, Options: 
> SYS_SPANSION_BOOT,SYS_TEXT_BASE=0x
>textdata bss dec hex filename
>  117375   115304092  132997   20785 ./u-boot
> common/cli_simple.c: In function 'process_macros':
> common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 
> 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat]
> common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 
> 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat]
> drivers/mtd/spi/sf.c: In function 'spi_flash_read_write':
> drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
> drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
> drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops':
> drivers/mtd/spi/sf_ops.c:323:3: warning: format '%zu' expects argument of 
> type 'size_t', but argument 7 has type 'long unsigned int' [-Wformat]
> common/cmd_sf.c: In function 'spi_flash_update_block':
> common/cmd_sf.c:154:2: warning: format '%zx' expects argument of type 
> 'size_t', but argument 4 has type 'long unsigned int' [-Wformat]
> common/cmd_sf.c:161:3: warning: format '%zx' expects argument of type 
> 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
> common/cmd_sf.c: In function 'spi_flash_update':
> common/cmd_sf.c:218:9: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
> common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
> common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 
> 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
> common/cmd_sf.c: In function 'do_spi_flash_read_write':
> common/cmd_sf.c:291:10: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
> common/cmd_sf.c: In function 'do_spi_flash_erase':
> common/cmd_sf.c:326:9: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
> common/cmd_nvedit.c: In function 'do_env_export':
> common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 
> 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
> common/cmd_nvedit.c: In function 'do_env_import':
> common/cmd_nvedit.c:1036:3: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
> common/cmd_nvedit.c:1036:3: warning: format '%zX' expects argument of type 
> 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
> lib/hashtable.c: In function 'hexport_r':
> lib/hashtable.c:605:2: warning: format '%zu' expects argument of type 
> 'size_t', but argument 5 has type 'long unsigned int' [-Wformat]
> lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
> lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 
> 'size_t', but argument 3 has type 'long unsigned int' [-Wformat]
> lib/hashtable.c: In function 'himport_r':
> lib/hashtable.c:793:3: warning: format '%zu' expects argument of type 
> 'size_t', but argument 2 has type 'long unsigned int' [-Wformat]
>
>
> Reverting the following fixes the warnings.
>
>  --- a/arch/m68k/include/asm/posix_types.h
>  +++ b/arch/m68k/include/asm/posix_types.h
>  @@ -15,7 +15,7 @@ typedef long  __kernel_off_t;
>   typedef int__kernel_pid_t;
>   typedef unsigned int   __kernel_uid_t;
>   typedef unsigned int   __kernel_gid_t;
>  -typedef unsigned int   __kernel_size_t;
>  +typedef unsigned long  __kernel_size_t;
>   typedef int__kernel_ssize_t;
>   typedef long   __kernel_ptrdiff_t;
>   typedef long   __kernel_time_t;
>
>
>
> In m68k Linux,  __kernel_size_t is set to unsigned int.
>
> So I am not sure if your change is good.
> (At least for me, it worsens the situation.)
>
> Does it depend on each tool-chain ?
>
>
> My tool-chain is like this:
>
> $ m68k-linux-gcc -v
> Using built-in specs.
> COLLECT_GCC=m68k-linux-gcc
> COLL

[U-Boot] Pull request v2: u-boot-sh/rmobile into u-boot-arm/master

[Nobuhiro Iwamatsu]

Dear Albert Aribaud,

Please pull u-boot-sh/rmobile into u-boot-arm/master.

The following changes since commit 0a26e1d6c394aacbf1153977b7348d1dff85db3f:

  arm: fix a double-definition error of _start symbol (2014-06-09
10:36:40 +0200)

are available in the git repository at:

  git://git.denx.de/u-boot-sh.git rmobile

for you to fetch changes up to 2f7b27caf4e6bdc6cb4047ef3ee4021f20e14c5f:

  arm: rmobile: lager: Remove NOR-Flash support from boards.cfg
(2014-06-11 06:59:36 +0900)


Nobuhiro Iwamatsu (2):
  arm: rmobile: koelsch: Remove NOR-Flash support from boards.cfg
  arm: rmobile: lager: Remove NOR-Flash support from boards.cfg

 boards.cfg | 2 --
 1 file changed, 2 deletions(-)


-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: rpi_b: enable GENERIC_BOARD

[Simon Glass]

On 13 June 2014 22:37, Stephen Warren  wrote:
> Serial port, SD card, and LCD all work.
>
> Signed-off-by: Stephen Warren 

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

Re: [U-Boot] [PATCH] pmic: tps65090: correct checking i2c bus

[Simon Glass]

On 15 June 2014 08:17, Jeroen Hofstee  wrote:
> The function tps65090_init checks the i2c bus of p->bus. However
> the pointer p is not intialiased at this point. Check the local
> variable bus instead.
>
> cc: Tom Wai-Hong Tam 
> cc: Simon Glass 
> Signed-off-by: Jeroen Hofstee 

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

Re: [U-Boot] [PATCH] includes: move openssl headers to include/u-boot

[Simon Glass]

Hi Jeroen,

On 12 June 2014 13:27, Jeroen Hofstee  wrote:
> commit 18b06652cd "tools: include u-boot version of sha256.h"
> unconditionally forced the sha256.h from u-boot to be used
> for tools instead of the host version. This is fragile though
> as it will also include the host version. Therefore move it
> to include/u-boot to join u-boot/md5.h etc which were renamed
> for the same reason.
>
> cc: Simon Glass 
> Signed-off-by: Jeroen Hofstee 

This seems like a much better solution. But I think you should keep
the sort order - so u-boot/xxx should go after asm/xxx in the
#includes I think.

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

Re: [U-Boot] [PATCH v4 09/15] dm: Cast away the const-ness of the global_data pointer

[Simon Glass]

Hi Marek,

On 17 June 2014 16:42, Marek Vasut  wrote:
> On Thursday, June 12, 2014 at 05:26:50 AM, Simon Glass wrote:
>> Hi Marek,
>>
>> On 8 June 2014 01:00, Marek Vasut  wrote:
>> > On Friday, June 06, 2014 at 09:13:26 PM, Simon Glass wrote:
>> >> In a very few cases we need to adjust the driver model root device, such
>> >> as when setting it up at initialisation. Add a macro to make this
>> >> easier.
>> >>
>> >> Signed-off-by: Simon Glass 
>> >> ---
>> >
>> > [...]
>> >
>> >> - ret = device_bind_by_name(NULL, &root_info, &gd->dm_root);
>> >> + ret = device_bind_by_name(NULL, &root_info, &DM_ROOT());
>> >
>> > [...]
>> >
>> >> +/* Cast away any volatile pointer */
>> >> +#define DM_ROOT()(((gd_t *)gd)->dm_root)
>> >> +#define DM_UCLASS_ROOT() (((gd_t *)gd)->uclass_root)
>> >
>> > Can you implement this "DM_ROOT()" macro as a function instead ? I
>> > believe that'd be much nicer , would have typechecking etc., usual
>> > stuff.
>>
>> I had a look at this. I don't see how I can do it, but you might have
>> ideas.
>>
>> In this function call I need to pass a pointer without its const bit.
>> I made it const since nothing should change the dm root except driver
>> model itself.
>
> All right, I will just be doing a little guesswork here. Shall you not have 
> some
> functions to change the DM root then instead of exposing the DM root ? Such
> functions shall not be exported publicly , but available via separate header
> file too ?

Firstly I should retitle the commit - it is of course the volatile
that I'm trying to get rid of as it says in the commit message. I
might have just been trying to confuse everyone.

I have code like this:

INIT_LIST_HEAD(&gd->uclass_root);

I don't see how I can turn this into a function. I suppose I could
init the list head in a temporary variable and then assign it to
gd->uclass_root, perhaps with memcpy(), but that doesn't really seem
any better to me.

>
> Sorry, I might be completely wrong.

Well I'm not saying it's pretty, so if you have time and come up with
a better option please let me know.

Also, this is not exported 'publicly'. It is in device-internal.h

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

[U-Boot] [PATCH] Avoid using gawk-specific strtonum()

[Simon Glass]

We need to subtract two hex numbers. Avoid using strtonum() by doing the
subtraction in bc with a suitable input base.

Signed-off-by: Simon Glass 
Reported-by: Vasili Galka 
---

 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 24d9687..bb2f615 100644
--- a/Makefile
+++ b/Makefile
@@ -788,7 +788,8 @@ OBJCOPYFLAGS_u-boot.bin := -O binary
 binary_size_check: u-boot.bin System.map FORCE
@file_size=`stat -c %s u-boot.bin` ; \
map_size=$(shell cat System.map | \
-   awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end 
= $$1} END {if (start != "" && end != "") print strtonum("0x" end) - 
strtonum("0x" start)}'); \
+   awk '/_image_copy_start/ {start = $$1} /_image_binary_end/ {end 
= $$1} END {if (start != "" && end != "") print "ibase=16; " toupper(end) " - " 
toupper(start)}' \
+   | bc); \
if [ "" != "$$map_size" ]; then \
if test $$map_size -ne $$file_size; then \
echo "System.map shows a binary size of $$map_size" >&2 
; \
-- 
2.0.0.526.g5318336

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

Re: [U-Boot] strtonum() is gawk specific extension

[Simon Glass]

Hi,

On 15 June 2014 06:56, Vasili Galka  wrote:
> The following patch "Check that u-boot.bin size looks correct":
> http://patchwork.ozlabs.org/patch/355151/
> Uses strtonum() function which is gawk specific extension:
> https://www.gnu.org/software/gawk/manual/html_node/Strtonum-Function.html
>
> As a result, currenlty, u-boot/master generates build errors on systems
> with alternative awk implementations e.g. I get:
>
> awk: line 2: function strtonum never defined
>
> Either gawk shall be required and explicitly used or the
> implementation changed.

I thought of an ugly way and sent a patch using bc, but please let me
know if you have something better.

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

Re: [U-Boot] [PATCH] dfu: free entities when parsing fails

[Lukasz Majewski]

Hi Stephen,

> From: Stephen Warren 
> 
> When dfu_init_env_entities() fails part-way through, some entities may
> have been added to dfu_list. These are only removed by
> dfu_free_entities(). If that function isn't called, those stale
> entities will still exist the next time dfu_init_env_entities() is
> called, leading to confusion. Fix do_dfu() to ensure that
> dfu_free_entities() is always called, to avoid this confusion.
> 
> Signed-off-by: Stephen Warren 
> ---
>  common/cmd_dfu.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
> index a03538dabb37..433bddd5d2bd 100644
> --- a/common/cmd_dfu.c
> +++ b/common/cmd_dfu.c
> @@ -27,8 +27,9 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) ret = dfu_init_env_entities(interface,
> simple_strtoul(devstring, NULL, 10));
>   if (ret)
> - return ret;
> + goto done;
>  
> + ret = CMD_RET_SUCCESS;
>   if (argc > 4 && strcmp(argv[4], "list") == 0) {
>   dfu_show_entities();
>   goto done;
> @@ -61,7 +62,7 @@ done:
>   if (dfu_reset())
>   run_command("reset", 0);
>  
> - return CMD_RET_SUCCESS;
> + return ret;
>  }
>  
>  U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,

Acked-by: Lukasz Majewski 

Test HW: Exynos4412 - Trats2

Tested-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Use UART1 port on p1022 through U-Boot

[Dirk Eibach]

Just use
#define CONFIG_CONS_INDEX 2
to select UART1 as u-boot console.
Remember to set "consoledev=ttyS1" in the kernel parameters.

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

Re: [U-Boot] [PATCH v2 03/11] board:samsung: check the mmc boot device and init the right mmc driver.

[Minkyu Kang]

Dear Przemyslaw Marczak,

On 12/06/14 18:46, Przemyslaw Marczak wrote:
> It is possible to boot from a few media devices, especially using a micro
> SD or eMMC slots. In this situation, boot device should be registered
> as block device 0 in the MMC framework, because CONFIG_SYS_MMC_ENV_DEV
> is usually set to "0" in the most config cases.
> 
> Signed-off-by: Przemyslaw Marczak 
> Cc: Piotr Wilczek 
> Cc: Minkyu Kang 
> ---
>  board/samsung/common/board.c | 32 
>  include/samsung/misc.h   |  5 +
>  2 files changed, 29 insertions(+), 8 deletions(-)
> 
> diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
> index 9dc7c83..2970340 100644
> --- a/board/samsung/common/board.c
> +++ b/board/samsung/common/board.c
> @@ -25,6 +25,8 @@
>  #include 
>  #include 
>  
> +static int bootmode;
> +
>  DECLARE_GLOBAL_DATA_PTR;
>  
>  int __exynos_early_init_f(void)
> @@ -243,19 +245,33 @@ int board_eth_init(bd_t *bis)
>  int board_mmc_init(bd_t *bis)
>  {
>   int ret;
> + struct exynos4_power *pwr = (struct exynos4_power *)
> + samsung_get_base_power();

Hm, no. This file is samsung common not only for exynos4.
Although this code will not be made any problems for other SoCs (because 
om_stat is always first item of power), it looks weird.
I think you can make new function for getting boot mode.

> +
> + bootmode = BOOT_MODE(readl(&pwr->om_stat));
> + if (bootmode == BOOT_SDMMC) {
> +#ifdef CONFIG_SDHCI
> + /* mmc initializattion for available channels */
> + ret = exynos_mmc_init(gd->fdt_blob);
> +#endif
>  #ifdef CONFIG_DWMMC
> - /* dwmmc initializattion for available channels */
> - ret = exynos_dwmmc_init(gd->fdt_blob);
> - if (ret)
> - debug("dwmmc init failed\n");
> + /* dwmmc initializattion for available channels */
> + ret = exynos_dwmmc_init(gd->fdt_blob);
> +#endif
> + } else {
> +#ifdef CONFIG_DWMMC
> + /* dwmmc initializattion for available channels */
> + ret = exynos_dwmmc_init(gd->fdt_blob);
>  #endif
> -
>  #ifdef CONFIG_SDHCI
> - /* mmc initializattion for available channels */
> - ret = exynos_mmc_init(gd->fdt_blob);
> + /* mmc initializattion for available channels */
> + ret = exynos_mmc_init(gd->fdt_blob);
> +#endif
> + }
> +
>   if (ret)
>   debug("mmc init failed\n");
> -#endif
> +
>   return ret;
>  }
>  #endif
> diff --git a/include/samsung/misc.h b/include/samsung/misc.h
> index 10653a1..87b53ec 100644
> --- a/include/samsung/misc.h
> +++ b/include/samsung/misc.h
> @@ -28,4 +28,9 @@ void check_boot_mode(void);
>  void draw_logo(void);
>  #endif
>  
> +#define BOOT_SDMMC   0x2
> +#define BOOT_MODE_MASK   (0x1f)
> +#define BOOT_MODE_SHIFT  (0x1)
> +#define BOOT_MODE(x) ((x >> BOOT_MODE_SHIFT) & BOOT_MODE_MASK)

((x) >> BOOT_MODE_SHIFT)

> +
>  #endif /* __SAMSUNG_MISC_COMMON_H__ */
> 

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

Re: [U-Boot] [PATCH v3 5/5] Exynos: Split 5250 and 5420 memory bank configuration

[Minkyu Kang]

On 18/06/14 11:11, Simon Glass wrote:
> Hi Minkyu,
> 
> On 16 June 2014 23:28, Minkyu Kang  wrote:
>> Dear Akshay Saraswat,
>>
>> On 04/06/14 01:17, Akshay Saraswat wrote:
>>> From: Michael Pratt 
>>>
>>> Since snow has a different memory configuration than peach, split the
>>> configuration between the 5250 and 5420. Exynos 5420 supports runtime
>>> memory configuration detection, and can make the determination between 4
>>> and 7 banks at runtime.
>>
>> I think this patch should be included to your peach-pit patchset.
>> And I think, the number of banks and the size of bank seems to board 
>> specific feature.
>> Can you guarantee if it uses same SoC then have same memory banks?
> 
> I think this is better than what we have there at present. There is a
> patch from Chromium that puts this in the device tree, but it is
> probably best dealt with when more patches have landed.
> 

I didn't deny this patch.
My comment is about present state.
If you can not guarantee that have same memory banks
then please split this configuration to each board's configs.

Thanks,
Minkyu Kang.

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

Re: [U-Boot] strtonum() is gawk specific extension

[Vasili Galka]

Hi Simon,

On Wed, Jun 18, 2014 at 9:10 AM, Simon Glass  wrote:
> I thought of an ugly way and sent a patch using bc, but please let me
> know if you have something better.

I honestly don't know. Is bc considered "standard" and always comes on
Linux systems?
Maybe there shall be a list of prerequisites in README file?
For example some configurations require openssl on the host.

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

Re: [U-Boot] [PATCH v3 5/5] Exynos: Split 5250 and 5420 memory bank configuration

[Simon Glass]

Hi Minkyu,

On 17 June 2014 23:30, Minkyu Kang  wrote:
> On 18/06/14 11:11, Simon Glass wrote:
>> Hi Minkyu,
>>
>> On 16 June 2014 23:28, Minkyu Kang  wrote:
>>> Dear Akshay Saraswat,
>>>
>>> On 04/06/14 01:17, Akshay Saraswat wrote:
 From: Michael Pratt 

 Since snow has a different memory configuration than peach, split the
 configuration between the 5250 and 5420. Exynos 5420 supports runtime
 memory configuration detection, and can make the determination between 4
 and 7 banks at runtime.
>>>
>>> I think this patch should be included to your peach-pit patchset.
>>> And I think, the number of banks and the size of bank seems to board 
>>> specific feature.
>>> Can you guarantee if it uses same SoC then have same memory banks?
>>
>> I think this is better than what we have there at present. There is a
>> patch from Chromium that puts this in the device tree, but it is
>> probably best dealt with when more patches have landed.
>>
>
> I didn't deny this patch.
> My comment is about present state.
> If you can not guarantee that have same memory banks
> then please split this configuration to each board's configs.

For Pit which can support 2GB or 4GB, U-Boot detects the correct size
at run-time. So the setting in the config file is the *maximum* memory
supported by that SOC, which is indeed fixed by the SOC and has
nothing to do with the board.

But i maybe misunderstand what you are getting at?

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