date:20161219

Currently, mdelay() and udelay() are declared in include/common.h,
while ndelay() in include/linux/compat.h.  It would be nice to
collect them into include/linux/delay.h like Linux.

While we are here, fix the ndelay() implementation; I used the
DIV_ROUND_UP() instead of (x)/1000 because we must wait *longer*
than the given period of time.

Signed-off-by: Masahiro Yamada 
---

 include/common.h   |  6 +-
 include/linux/compat.h |  2 --
 include/linux/delay.h  | 24 
 lib/time.c |  6 --
 4 files changed, 25 insertions(+), 13 deletions(-)
 create mode 100644 include/linux/delay.h

diff --git a/include/common.h b/include/common.h
index a8d833b..682205d 100644
--- a/include/common.h
+++ b/include/common.h
@@ -19,6 +19,7 @@ typedef volatile unsigned charvu_char;
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -776,7 +777,6 @@ uint64_t get_ticks(void);
 void   wait_ticks(unsigned long);
 
 /* arch/$(ARCH)/lib/time.c */
-void   __udelay  (unsigned long);
 ulong  usec2ticks(unsigned long usec);
 ulong  ticks2usec(unsigned long ticks);
 intinit_timebase (void);
@@ -833,10 +833,6 @@ void qsort(void *base, size_t nmemb, size_t size,
   int(*compar)(const void *, const void *));
 int strcmp_compar(const void *, const void *);
 
-/* lib/time.c */
-void   udelay(unsigned long);
-void mdelay(unsigned long);
-
 /* lib/uuid.c */
 #include 
 
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 533983f..a43e4d6 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -15,8 +15,6 @@ struct p_current{
 
 extern struct p_current *current;
 
-#define ndelay(x)  udelay((x) < 1000 ? 1 : (x)/1000)
-
 #define dev_dbg(dev, fmt, args...) \
debug(fmt, ##args)
 #define dev_vdbg(dev, fmt, args...)\
diff --git a/include/linux/delay.h b/include/linux/delay.h
new file mode 100644
index 000..3dcd435
--- /dev/null
+++ b/include/linux/delay.h
@@ -0,0 +1,24 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _LINUX_DELAY_H
+#define _LINUX_DELAY_H
+
+#include 
+
+void __udelay(unsigned long usec);
+void udelay(unsigned long usec);
+
+static inline void mdelay(unsigned long msec)
+{
+   while (msec--)
+   udelay(1000);
+}
+
+static inline void ndelay(unsigned long nsec)
+{
+   udelay(DIV_ROUND_UP(nsec, 1000));
+}
+
+#endif /* defined(_LINUX_DELAY_H) */
diff --git a/lib/time.c b/lib/time.c
index f37150f..3c49243 100644
--- a/lib/time.c
+++ b/lib/time.c
@@ -154,9 +154,3 @@ void udelay(unsigned long usec)
usec -= kv;
} while(usec);
 }
-
-void mdelay(unsigned long msec)
-{
-   while (msec--)
-   udelay(1000);
-}
-- 
2.7.4

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

Re: [U-Boot] [PATCH 2/4] ARM: zynq: Remove spi-max-frequency

2016-12-19 Thread Michal Simek

On 16.12.2016 18:28, Moritz Fischer wrote:
> Hi Michal,
> 
> On Fri, Dec 16, 2016 at 5:38 AM, Michal Simek  wrote:
>> spi-max-frequency for spi bus depends on devices which are
>> connected to it. Remove this parameter from dtsi file.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>>  arch/arm/dts/zynq-7000.dtsi | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/arm/dts/zynq-7000.dtsi b/arch/arm/dts/zynq-7000.dtsi
>> index 668f54ec219d..fa9ee276cb59 100644
>> --- a/arch/arm/dts/zynq-7000.dtsi
>> +++ b/arch/arm/dts/zynq-7000.dtsi
>> @@ -177,7 +177,6 @@
>> interrupts = <0 26 4>;
>> clocks = < 25>, < 34>;
>> clock-names = "ref_clk", "pclk";
>> -   spi-max-frequency = <16700>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> };
>> @@ -190,7 +189,6 @@
>> interrupts = <0 49 4>;
>> clocks = < 26>, < 35>;
>> clock-names = "ref_clk", "pclk";
>> -   spi-max-frequency = <16700>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> };
>> --
>> 1.9.1
>>
> 
> While I agree with the patch, doesn't the drivers/spi/zynq_spi.c in u-boot
> (wrongly) use this to determine it's peripheral clock speed?
> 
> 
> plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency",
>   25000);
> 
> 
> and later in zynq_spi_set_speed() to calculate divisors?

Based on DT binding
spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz

In node itself it should be max speed what controller can operate. Every
node should set it up for self and driver should be able to handle it.

Back to your point. plat->frequency setup is weird. It looks like input
reference clock to IP itself instead of max IP freq. I expect the reason
was that we couldn't get this value and Jagan was using it as workaround
how to get any value.
It should be simply clk_get_rate() and clk driver should return value.
And this value should be used in speed calculation. (Linux
Time to move zynq clk driver to DM to get these stuff for free.

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

[U-Boot] [PATCH 0/5] Introduce basic headers for time, typecheck, iopoll




Masahiro Yamada (5):
  delay: collect {m,n,u}delay declarations to include/linux/delay.h
  time: move timer APIs to include/time.h
  typecheck: import include/linux/typecheck.h from Linux 4.9
  time: import time_after, time_before and friends from Linux
  iopoll: import include/linux/iopoll.h from Linux 4.9

 include/common.h  | 14 ++
 include/linux/compat.h|  2 --
 include/linux/delay.h | 24 +
 include/linux/iopoll.h| 68 +++
 include/linux/typecheck.h | 24 +
 include/time.h| 57 +++
 lib/time.c|  6 -
 7 files changed, 175 insertions(+), 20 deletions(-)
 create mode 100644 include/linux/delay.h
 create mode 100644 include/linux/iopoll.h
 create mode 100644 include/linux/typecheck.h
 create mode 100644 include/time.h

-- 
2.7.4

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

[U-Boot] [PATCH 2/5] time: move timer APIs to include/time.h

The include/common.h is a collection of unrelated declarations,
macros, etc.

It is horrible to include such a cluttered header just for some
timer functions.  Split out timer functions into include/timer.h.

Signed-off-by: Masahiro Yamada 
---

 include/common.h |  8 +---
 include/time.h   | 16 
 2 files changed, 17 insertions(+), 7 deletions(-)
 create mode 100644 include/time.h

diff --git a/include/common.h b/include/common.h
index 682205d..08f581c 100644
--- a/include/common.h
+++ b/include/common.h
@@ -17,6 +17,7 @@ typedef volatile unsigned charvu_char;
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -577,12 +578,6 @@ void ddr_enable_ecc(unsigned int dram_size);
 #endif
 #endif
 
-/*
- * Return the current value of a monotonically increasing microsecond timer.
- * Granularity may be larger than 1us if hardware does not support this.
- */
-ulong timer_get_us(void);
-
 /* $(CPU)/cpu.c */
 static inline int cpumask_next(int cpu, unsigned int mask)
 {
@@ -721,7 +716,6 @@ voidexternal_interrupt (struct pt_regs *);
 void   irq_install_handler(int, interrupt_handler_t *, void *);
 void   irq_free_handler   (int);
 void   reset_timer(void);
-ulong  get_timer  (ulong base);
 
 /* Return value of monotonic microsecond timer */
 unsigned long timer_get_us(void);
diff --git a/include/time.h b/include/time.h
new file mode 100644
index 000..5ed021f
--- /dev/null
+++ b/include/time.h
@@ -0,0 +1,16 @@
+/*
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _TIME_H
+#define _TIME_H
+
+unsigned long get_timer(unsigned long base);
+
+/*
+ * Return the current value of a monotonically increasing microsecond timer.
+ * Granularity may be larger than 1us if hardware does not support this.
+ */
+unsigned long timer_get_us(void);
+
+#endif /* _TIME_H */
-- 
2.7.4

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

[U-Boot] [PATCH 4/5] time: import time_after, time_before and friends from Linux

It is not safe to compare timer values directly.

On 32-bit systems, for example, timer_get_us() wraps around every
72 min. (2 ^ 32 / 100 =~ 4295 sec =~ 72 min).  Depending on
the get_ticks() implementation, it may wrap more frequently.
The 72 min might be possible on the use of U-Boot.

Let's borrow time_after, time_before, and friends to solve the
wrap-around problem.

These macros were copied from include/linux/jiffies.h of Linux 4.9.

Signed-off-by: Masahiro Yamada 
---

 include/time.h | 41 +
 1 file changed, 41 insertions(+)

diff --git a/include/time.h b/include/time.h
index 5ed021f..5746ad9 100644
--- a/include/time.h
+++ b/include/time.h
@@ -5,6 +5,8 @@
 #ifndef _TIME_H
 #define _TIME_H
 
+#include 
+
 unsigned long get_timer(unsigned long base);
 
 /*
@@ -13,4 +15,43 @@ unsigned long get_timer(unsigned long base);
  */
 unsigned long timer_get_us(void);
 
+/*
+ * These inlines deal with timer wrapping correctly. You are
+ * strongly encouraged to use them
+ * 1. Because people otherwise forget
+ * 2. Because if the timer wrap changes in future you won't have to
+ *alter your driver code.
+ *
+ * time_after(a,b) returns true if the time a is after time b.
+ *
+ * Do this with "<0" and ">=0" to only test the sign of the result. A
+ * good compiler would generate better code (and a really good compiler
+ * wouldn't care). Gcc is currently neither.
+ */
+#define time_after(a,b)\
+   (typecheck(unsigned long, a) && \
+typecheck(unsigned long, b) && \
+((long)((b) - (a)) < 0))
+#define time_before(a,b)   time_after(b,a)
+
+#define time_after_eq(a,b) \
+   (typecheck(unsigned long, a) && \
+typecheck(unsigned long, b) && \
+((long)((a) - (b)) >= 0))
+#define time_before_eq(a,b)time_after_eq(b,a)
+
+/*
+ * Calculate whether a is in the range of [b, c].
+ */
+#define time_in_range(a,b,c) \
+   (time_after_eq(a,b) && \
+time_before_eq(a,c))
+
+/*
+ * Calculate whether a is in the range of [b, c).
+ */
+#define time_in_range_open(a,b,c) \
+   (time_after_eq(a,b) && \
+time_before(a,c))
+
 #endif /* _TIME_H */
-- 
2.7.4

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

[U-Boot] [PATCH 5/5] iopoll: import include/linux/iopoll.h from Linux 4.9

This was imported from Linux 4.9 and adjusted for U-Boot.

 - Replace the license block with SPDX
 - Drop all *_atomic variants, which make no sense for U-Boot
 - Remove the sleep_us argument, which makes no sense for U-Boot

Signed-off-by: Masahiro Yamada 
---

 include/linux/iopoll.h | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 include/linux/iopoll.h

diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
new file mode 100644
index 000..31c55ae
--- /dev/null
+++ b/include/linux/iopoll.h
@@ -0,0 +1,68 @@
+/*
+ * Copyright (c) 2012-2014 The Linux Foundation. All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#ifndef _LINUX_IOPOLL_H
+#define _LINUX_IOPOLL_H
+
+#include 
+#include 
+#include 
+
+/**
+ * readx_poll_timeout - Periodically poll an address until a condition is met 
or a timeout occurs
+ * @op: accessor function (takes @addr as its only argument)
+ * @addr: Address to poll
+ * @val: Variable to read the value into
+ * @cond: Break condition (usually involving @val)
+ * @timeout_us: Timeout in us, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout. In either
+ * case, the last read value at @addr is stored in @val.
+ *
+ * When available, you'll probably want to use one of the specialized
+ * macros defined below rather than this macro directly.
+ */
+#define readx_poll_timeout(op, addr, val, cond, timeout_us)\
+({ \
+   unsigned long timeout = timer_get_us() + timeout_us; \
+   for (;;) { \
+   (val) = op(addr); \
+   if (cond) \
+   break; \
+   if (timeout_us && time_after(timer_get_us(), timeout)) { \
+   (val) = op(addr); \
+   break; \
+   } \
+   } \
+   (cond) ? 0 : -ETIMEDOUT; \
+})
+
+
+#define readb_poll_timeout(addr, val, cond, timeout_us) \
+   readx_poll_timeout(readb, addr, val, cond, timeout_us)
+
+#define readw_poll_timeout(addr, val, cond, timeout_us) \
+   readx_poll_timeout(readw, addr, val, cond, timeout_us)
+
+#define readl_poll_timeout(addr, val, cond, timeout_us) \
+   readx_poll_timeout(readl, addr, val, cond, timeout_us)
+
+#define readq_poll_timeout(addr, val, cond, timeout_us) \
+   readx_poll_timeout(readq, addr, val, cond, timeout_us)
+
+#define readb_relaxed_poll_timeout(addr, val, cond, timeout_us) \
+   readx_poll_timeout(readb_relaxed, addr, val, cond, timeout_us)
+
+#define readw_relaxed_poll_timeout(addr, val, cond, timeout_us) \
+   readx_poll_timeout(readw_relaxed, addr, val, cond, timeout_us)
+
+#define readl_relaxed_poll_timeout(addr, val, cond, timeout_us) \
+   readx_poll_timeout(readl_relaxed, addr, val, cond, timeout_us)
+
+#define readq_relaxed_poll_timeout(addr, val, cond, timeout_us) \
+   readx_poll_timeout(readq_relaxed, addr, val, cond, timeout_us)
+
+#endif /* _LINUX_IOPOLL_H */
-- 
2.7.4

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

[U-Boot] [PATCH 3/5] typecheck: import include/linux/typecheck.h from Linux 4.9

Copied from Linux 4.9.

Signed-off-by: Masahiro Yamada 
---

 include/linux/typecheck.h | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 include/linux/typecheck.h

diff --git a/include/linux/typecheck.h b/include/linux/typecheck.h
new file mode 100644
index 000..eb5b74a
--- /dev/null
+++ b/include/linux/typecheck.h
@@ -0,0 +1,24 @@
+#ifndef TYPECHECK_H_INCLUDED
+#define TYPECHECK_H_INCLUDED
+
+/*
+ * Check at compile time that something is of a particular type.
+ * Always evaluates to 1 so you may use it easily in comparisons.
+ */
+#define typecheck(type,x) \
+({ type __dummy; \
+   typeof(x) __dummy2; \
+   (void)(&__dummy == &__dummy2); \
+   1; \
+})
+
+/*
+ * Check at compile time that 'function' is a certain type, or is a pointer
+ * to that type (needs to use typedef for the function type.)
+ */
+#define typecheck_fn(type,function) \
+({ typeof(type) __tmp = function; \
+   (void)__tmp; \
+})
+
+#endif /* TYPECHECK_H_INCLUDED */
-- 
2.7.4

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

Re: [U-Boot] [PATCH v3 3/3] ARM64: zynqmp: Replace board specific with generic memory bank decoding

2016-12-19 Thread Michal Simek

On 18.12.2016 15:03, Nathan Rossi wrote:
> The dram_init and dram_init_banksize functions were using a board
> specific implementation for decoding the memory banks from the fdt. This
> board specific implementation uses a static variable 'tmp' which makes
> these functions unsafe for execution from within the board_init_f
> context.
> 
> This change makes the dram_init* functions use a generic implementation
> of decoding and populating memory bank and size data.
> 
> Signed-off-by: Nathan Rossi 
> Fixes: 8d59d7f63b ("ARM64: zynqmp: Read RAM information from DT")
> Cc: Michal Simek 
> ---
>  board/xilinx/zynqmp/zynqmp.c | 112 
> ++-
>  1 file changed, 3 insertions(+), 109 deletions(-)
> 
> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> index cef1f6a13a..8a3d0043b9 100644
> --- a/board/xilinx/zynqmp/zynqmp.c
> +++ b/board/xilinx/zynqmp/zynqmp.c
> @@ -180,121 +180,15 @@ int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
>  }
>  
>  #if !defined(CONFIG_SYS_SDRAM_BASE) && !defined(CONFIG_SYS_SDRAM_SIZE)
> -/*
> - * fdt_get_reg - Fill buffer by information from DT
> - */
> -static phys_size_t fdt_get_reg(const void *fdt, int nodeoffset, void *buf,
> -const u32 *cell, int n)
> -{
> - int i = 0, b, banks;
> - int parent_offset = fdt_parent_offset(fdt, nodeoffset);
> - int address_cells = fdt_address_cells(fdt, parent_offset);
> - int size_cells = fdt_size_cells(fdt, parent_offset);
> - char *p = buf;
> - u64 val;
> - u64 vals;
> -
> - debug("%s: addr_cells=%x, size_cell=%x, buf=%p, cell=%p\n",
> -   __func__, address_cells, size_cells, buf, cell);
> -
> - /* Check memory bank setup */
> - banks = n % (address_cells + size_cells);
> - if (banks)
> - panic("Incorrect memory setup cells=%d, ac=%d, sc=%d\n",
> -   n, address_cells, size_cells);
> -
> - banks = n / (address_cells + size_cells);
> -
> - for (b = 0; b < banks; b++) {
> - debug("%s: Bank #%d:\n", __func__, b);
> - if (address_cells == 2) {
> - val = cell[i + 1];
> - val <<= 32;
> - val |= cell[i];
> - val = fdt64_to_cpu(val);
> - debug("%s: addr64=%llx, ptr=%p, cell=%p\n",
> -   __func__, val, p, [i]);
> - *(phys_addr_t *)p = val;
> - } else {
> - debug("%s: addr32=%x, ptr=%p\n",
> -   __func__, fdt32_to_cpu(cell[i]), p);
> - *(phys_addr_t *)p = fdt32_to_cpu(cell[i]);
> - }
> - p += sizeof(phys_addr_t);
> - i += address_cells;
> -
> - debug("%s: pa=%p, i=%x, size=%zu\n", __func__, p, i,
> -   sizeof(phys_addr_t));
> -
> - if (size_cells == 2) {
> - vals = cell[i + 1];
> - vals <<= 32;
> - vals |= cell[i];
> - vals = fdt64_to_cpu(vals);
> -
> - debug("%s: size64=%llx, ptr=%p, cell=%p\n",
> -   __func__, vals, p, [i]);
> - *(phys_size_t *)p = vals;
> - } else {
> - debug("%s: size32=%x, ptr=%p\n",
> -   __func__, fdt32_to_cpu(cell[i]), p);
> - *(phys_size_t *)p = fdt32_to_cpu(cell[i]);
> - }
> - p += sizeof(phys_size_t);
> - i += size_cells;
> -
> - debug("%s: ps=%p, i=%x, size=%zu\n",
> -   __func__, p, i, sizeof(phys_size_t));
> - }
> -
> - /* Return the first address size */
> - return *(phys_size_t *)((char *)buf + sizeof(phys_addr_t));
> -}
> -
> -#define FDT_REG_SIZE  sizeof(u32)
> -/* Temp location for sharing data for storing */
> -/* Up to 64-bit address + 64-bit size */
> -static u8 tmp[CONFIG_NR_DRAM_BANKS * 16];
> -
>  void dram_init_banksize(void)
>  {
> - int bank;
> -
> - memcpy(>bd->bi_dram[0], , sizeof(tmp));
> -
> - for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
> - debug("Bank #%d: start %llx\n", bank,
> -   (unsigned long long)gd->bd->bi_dram[bank].start);
> - debug("Bank #%d: size %llx\n", bank,
> -   (unsigned long long)gd->bd->bi_dram[bank].size);
> - }
> + fdtdec_setup_memory_banksize();
>  }
>  
>  int dram_init(void)
>  {
> - int node, len;
> - const void *blob = gd->fdt_blob;
> - const u32 *cell;
> -
> - memset(, 0, sizeof(tmp));
> -
> - /* find or create "/memory" node. */
> - node = fdt_subnode_offset(blob, 0, "memory");
> - if (node < 0) {
> - printf("%s: Can't get memory node\n", __func__);
> - return node;
> - }
> -
> - /* Get pointer to cells

Re: [U-Boot] [PATCH v2 0/6] mmc: move some config options to Kconfig

Hi Tom.


2016-12-07 22:10 GMT+09:00 Masahiro Yamada :
>
> I wrote a new SDHCI driver for my new SoCs, but before posting it,
> I just want to make a clean base for my driver entry.
>
> Of course, I could enable some needed options in my header file
> (for options in the "white-list"), but I just thought it is a good
> habit to contribute to Kconfig moves in the area I am working on now.
>
> Some people are actively working on such moves, so this kind of work
> is really conflict-prone.
>
> I described how to generate each commit in its git-log
> in case this series becomes out of date.
>
> I created this series based on v2017.01-rc1, but if some other pull
> requests go in first, I hope Tom will easily reproduce it by following
> each instruction in the log.
>

This series got Reviewed-by from you and Jaehoon.
But it has been left for a while, and it is already staled.

I described how to generate each patch,
and if you are planning to manage it by yourself, that's OK.

But, if there is something I can do to get this series in, please let me know.
My work is being blocked by this series.

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

[U-Boot] Please pull from u-boot-i2c

2016-12-19 Thread Heiko Schocher


Hello Tom,

please pull from u-boot-i2c.git master

The following changes since commit 0b4bc1b3ab1850fccbade3e6103f2036f6bdb364:

  Merge branch 'master' of git://git.denx.de/u-boot-spi (2016-12-16 18:32:43 
-0500)

are available in the git repository at:

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

for you to fetch changes up to 77466267eb3f937f432135f73efb25122e668cfc:

  i2c: mv_i2c.c: Correct address endianness (2016-12-19 09:32:00 +0100)


Bradley Bolen (1):
  i2c: mv_i2c.c: Correct address endianness

 drivers/i2c/mv_i2c.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/2] splash: add support for loading splash from a FIT image

2016-12-19 Thread Tomas Melin

Hi Igor, Simon,

On 12/15/2016 11:08 AM, Igor Grinberg wrote:
> Hi Tomas,
> 
> On 12/14/16 16:23, Tomas Melin wrote:
>> Hi Simon, Igor,
>>
>> On 12/14/2016 02:53 PM, Igor Grinberg wrote:
>>> On 12/13/16 22:29, Simon Glass wrote:
>>>
>>> I think two above debug() are very legitimate - no need to shout if no 
>>> FIT image
>>> or no splash in it...
>>>
 + res = fit_image_get_data_offset(fit_header, node_offset,
 + _offset);
 + if (res < 0) {
 + debug("Could not find 'data-offset' property in FIT\n");
 + return res;
 + }
 +
 + res = fit_image_get_data_size(fit_header, node_offset, 
 _size);
 + if (res < 0) {
 + debug("Could not find 'data-size' property in FIT\n");
 + return res;
 + }
>>>
>>> Now regarding these two, I'm not sure.
>>> Since we have found a valid FIT and also a node with a correct splash 
>>> name,
>>> probably the intent is that we show the splash, right?
>>> But in the two above checks, we find inconsistencies that do not allow 
>>> us to
>>> show the splash - meaning the FIT is not actually good (am I right 
>>> here?).
>>> So may be we should report it to the 'user' and allow correcting the 
>>> FIT?
>>> Otherwise, it is impossible to debug the image w/o a debug version of 
>>> U-Boot...
>>> Do I make sense, or do I miss something?
>>
>> Yes that makes some sense, but the problem is that then you are
>> including error messages always which would never happen in a working
>> system (i.e. it just bloats the code).
>
> Unless, there a kind of corruption or a user mistake and then that same
> user can't even understand what happened because we do not help him with
> an error message.
> You cannot know that these error messages will never happen...
> This is a generic code which can be used by a wide variety of platforms -
> I don't think you can foresee all the possible use cases.
>
> We are talking about several tens of bytes vs. usability.
> If there is an error, it should be stated as such. It should not just
> exit silently...

 I agree with that, there should definitely be an error printed. It
 should say something like 'Failed to load splash screen (err=-4)' or
 something like that. The error number should provide some clues and
 people can dig in.
>>>
>>> Great idea!
>>
>> splash_load_fit() currently fails silently but still reports the error in
>> the return value. And this function is used so that board.c calls 
>> splash_source_load()->splash_load_fit().
>> The board function call will get notified of the error value as provided
>> by the return value for splash_load_fit(). In our board implementation that 
>> is 
>> actually exactly how it is done, the board function call checks the return
>> value and prints ("Failed to load splash screen image, error: %d\n", ret)
>> in case there was and error.
>>
>> IMHO this is quite good behaviour as is, leaving it up to the implementation
>> in the board.c if there should be a error message or not (and if it should 
>> bloat the code with another printf or not).
> 
> Well, yes this makes sense if you care to do the work in the board code.
> Although, I would expect that sometime this code will be called from
> a generic board independent place (e.g. init array, etc.).

I don't have a strong opinion, even if I do prefer the current version.
Please let me know if patch this still needs changes. 

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

Re: [U-Boot] [PATCH 1/3] ARM: revive CONFIG_USE_ARCH_MEMCPY/MEMSET for UniPhier and Tegra

2016-12-20 6:59 GMT+09:00 Tom Rini :
> On Mon, Dec 19, 2016 at 07:31:02PM +0900, Masahiro Yamada wrote:
>> Commit be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to
>> Kconfig") is misconversion.
>>
>> The original logic in include/configs/uniphier.h was as follows:
>>
>>   #if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ARM64)
>>   #define CONFIG_USE_ARCH_MEMSET
>>   #define CONFIG_USE_ARCH_MEMCPY
>>   #endif
>>
>> This means those configs were enabled when building U-Boot proper,
>> but disabled when building SPL.  Likewise for Tegra.
>>
>> Now "depends on !SPL" prevents any boards with SPL support
>> from reaching these options.  This changed the behavior for
>> UniPhier and Tegra SoC family.
>>
>> Please notice these two options only control the U-Boot proper
>> build.  As you see arch/arm/Makefile, ARM-specific memset/memcpy
>> are never compiled for SPL.  So, __HAVE_ARCH_MEMCPY/MEMSET should
>> not set for SPL.
>>
>> Fixes: be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to Kconfig")
>> Signed-off-by: Masahiro Yamada 
>
> Ah, oops, thanks for spotting that one.
>
>> ---
>>
>> I am restoring the original behavior for now.
>> But, I have been wondering if we could remove these options entirely.
>
> We cannot.  That was my first attempt and we have a handful of active (I
> checked) boards with tiny enough SPL constraints that switching to the
> optimized memcpy/memset push them over size limit and they do not have a
> "something" to disable to gain the space back.  So I went with asking
> for asking for a conversion to enable by default these options as widely
> as possible as it's a good thing by and (no pun intended) large.


Perhaps, I may be missing something, but I could not understand
why you were talking about SPL size constraints.


As far as I understood arch/arm/lib/Makefile,
arch/arm/lib/memset.o is never compiled for SPL
in the first place.

I believe CONFIG_USE_ARCH_MEMSET has no impact to SPL.



ifndef CONFIG_SPL_BUILD
ifdef CONFIG_ARM64
obj-y   += relocate_64.o
else
obj-y   += relocate.o
endif

obj-$(CONFIG_CPU_V7M) += cmd_boot.o
obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
obj-$(CONFIG_CMD_BOOTI) += bootm.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
else
obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
endif






-- 
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 2/3] common/init: remove meaningless defined(CONFIG_USE_ARCH_MEMSET)

Hi Tom.

2016-12-20 7:02 GMT+09:00 Tom Rini :
> On Mon, Dec 19, 2016 at 07:31:03PM +0900, Masahiro Yamada wrote:
>
>> CONFIG_USE_ARCH_MEMSET controls nothing about SPL.  (it is effective
>> only on U-Boot proper building of ARM).
>
> That's not true.  We have these functions available to SPL and use them
> there by default now (as it's a speed win and we want out of SPL ASAP).
>

This is not clear to me.

How can you make the optimized memset available to SPL?

As far as see arch/arm/lib/Makefile,
memset.o is only compiled (if CONFIG_USE_ARCH_MEMSET is defined)
for the U-Boot full image.


ifndef CONFIG_SPL_BUILD
ifdef CONFIG_ARM64
obj-y   += relocate_64.o
else
obj-y   += relocate.o
endif

obj-$(CONFIG_CPU_V7M) += cmd_boot.o
obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
obj-$(CONFIG_CMD_BOOTI) += bootm.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
else
obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
endif









-- 
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 23/63] x86: ivybridge: Allow 32-bit init to move to SPL

On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass  wrote:
> Update the Makefile so that some 32-bit init can be built into SPL rather
> than U-Boot proper.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/ivybridge/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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

Re: [U-Boot] [PATCH v2 22/63] x86: Use X86_32BIT_INIT instead of X86_RESET_VECTOR

On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass  wrote:
> Use this new option to control the location of 32-bit init. This will allow
> us to place this in SPL if needed.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/cpu/intel_common/Makefile | 10 ++
>  arch/x86/lib/init_helpers.c|  2 +-
>  2 files changed, 7 insertions(+), 5 deletions(-)
>

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

Re: [U-Boot] [PATCH v2 21/63] x86: Use X86_16BIT_INIT instead of X86_RESET_VECTOR

On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass  wrote:
> Use this new option to control the location of 16-bit init. This will allow
> us to place this in SPL if needed.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  Makefile| 7 ---
>  arch/x86/Makefile   | 6 ++
>  arch/x86/cpu/Makefile   | 2 +-
>  arch/x86/cpu/u-boot.lds | 2 +-
>  4 files changed, 8 insertions(+), 9 deletions(-)
>

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

Re: [U-Boot] [PATCH v2 20/63] x86: Kconfig: Add location options for 16/32-bit init

Hi Simon,

On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass  wrote:
> At present all 16/32-bit init is controlled by CONFIG_X86_RESET_VECTOR. If
> this is enabled, then U-Boot is the 'first' boot loader and handles execution
> from the reset vector through to U-Boot's command prompt. If it is not
> enabled then U-Boot starts at the 32-bit entry and skips most of its init,
> assuming that the previous boot loader has done this already.
>
> With the move to suport 64-bit operation, we have more cases to consider.
> The 16-bit and 32-bit init may be in SPL rather than in U-Boot proper.
>
> Add Kconfig options which control the location of the 16-bit and the 32-bit
> init. These are not intended to be user-setting except for experimentation.
> Their values should be determined by whether 64-bit U-Boot is used.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/Kconfig | 39 +++
>  1 file changed, 39 insertions(+)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 5db8f13..e57362e 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -135,6 +135,45 @@ config X86_RESET_VECTOR
> bool
> default n
>
> +# The following options control where the 16-bit and 32-bit init lies
> +# If SPL is enabled then it normally holds this init code, and U-Boot proper
> +# is normally a 64-bit build.
> +#
> +# The 16-bit init refers to the reset vector and the small amount of code to
> +# get the processor into 32-bit mode. It may be in SPL or in U-Boot proper,
> +# or missing altogether if U-Boot is started from EFI or coreboot.
> +#
> +# The 32-bit init refers to processor init, running binary blobs including
> +# FSP, setting up interrupts and anything else that needs to be done in
> +# 32-bit code. It is normally in the same place as 32-bit init.

in the same place as "16-bit" init?

> +config X86_16BIT_INIT
> +   bool
> +   depends on X86_RESET_VECTOR
> +   default y if X86_RESET_VECTOR && !SPL
> +   help
> + This is enabled when 16-bit init is in U-Boot proper
> +
> +config SPL_X86_16BIT_INIT
> +   bool
> +   depends on X86_RESET_VECTOR
> +   default y if X86_RESET_VECTOR && SPL
> +   help
> + This is enabled when 16-bit init is in SPL
> +
> +config X86_32BIT_INIT
> +   bool
> +   depends on X86_RESET_VECTOR
> +   default y if X86_RESET_VECTOR && !SPL
> +   help
> + This is enabled when 32-bit init is in U-Boot proper
> +
> +config SPL_X86_32BIT_INIT
> +   bool
> +   depends on X86_RESET_VECTOR
> +   default y if X86_RESET_VECTOR && SPL
> +   help
> + This is enabled when 32-bit init is in SPL
> +
>  config RESET_SEG_START
> hex
> depends on X86_RESET_VECTOR
> --

Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH v2 19/63] x86: Add Kconfig options to build 64-bit U-Boot

Hi Simon,

On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass  wrote:
> Add a new CONFIG_X86_64 option which will eventually cause U-Boot to be
> built as a 64-bit application, with SPL doing the 16/32-bit init.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/Kconfig | 46 ++
>  1 file changed, 46 insertions(+)
>

Reviewed-by: Bin Meng 

One nits below:

> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 0884af2..5db8f13 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -5,6 +5,52 @@ config SYS_ARCH
> default "x86"
>
>  choice
> +   prompt "Run U-Boot in 32/64-bit mode"
> +   default X86_RUN_32BIT
> +   help
> + U-Boot can be built as a 32-bit binary which runs in 32-bit mode
> + even on 64-bit machines. In this case SPL is not used, and U-Boot
> + runs directly from the reset vector (via 16-bit start-up).
> +
> + Alternatively it can be run as a 64-bit binary, thus requiring a
> + 64-bit machine. In this case SPL runs in 32-bit mode (via 16-bit
> + start-up) then jumps to U-Boot in 64-bit mode.
> +
> + For now, 32-bit mode is recommended, as 64-bit is still
> + experimental and is missing a lot of features.
> +
> +config X86_RUN_32BIT
> +   bool "32-bit"
> +help

nits: "help" is not aligned

> + Build U-Boot as a 32-bit binary with no SPL. This is the currently
> + supported normal setup. U-Boot will stay in 32-bit mode even on
> + 64-bit machines. When booting a 64-bit kernel, U-Boot will switch
> + to 64-bit just before starting the kernel. Only the bottom 4GB of
> + memory can be accessed through normal means, although
> + arch_phys_memset() can be used for basic access to other memory.
> +
> +config X86_RUN_64BIT
> +   bool "64-bit"
> +   select X86_64
> +   select SUPPORT_SPL
> +   select SPL
> +   select SPL_SEPARATE_BSS
> +   help
> + Build U-Boot as a 64-bit binary with a 32-bit SPL. This is
> + experimental and many features are missing. U-Boot SPL starts up,
> + runs through the 16-bit and 32-bit init, then switches to 64-bit
> + mode and jumps to U-Boot proper.
> +
> +endchoice
> +
> +config X86_64
> +   bool
> +
> +config SPL_X86_64
> +   bool
> +   depends on SPL
> +
> +choice
> prompt "Mainboard vendor"
> default VENDOR_EMULATION
>
> --

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

Re: [U-Boot] [PATCH v2 17/63] x86: fsp: Fix cast for 64-bit compilation

On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass  wrote:
> Fix a cast in get_next_hob() that causes warnings on 64-bit machines.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Fix cast in get_guid_hob_data() also
>
>  arch/x86/include/asm/fsp/fsp_hob.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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

Re: [U-Boot] [PATCH v2 16/63] x86: dts: Mark serial as needed before relocation

On Sun, Nov 20, 2016 at 4:25 AM, Simon Glass  wrote:
> We almost always need the serial port before relocation, so mark it as such.
> This will ensure that it appears in the device tree for SPL, if used.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  arch/x86/dts/serial.dtsi | 1 +
>  1 file changed, 1 insertion(+)
>

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

Re: [U-Boot] [PATCH v2 10/63] x86: Use unsigned long for address in table generation

On Sun, Nov 20, 2016 at 4:24 AM, Simon Glass  wrote:
> We should use unsigned long rather than u32 for addresses. Update this so
> that the table-generation code builds correctly on 64-bit machines.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Move table-related changes from a later patch
> - Rebase to mainline
> - Drop the write_smbios_table_wrapper() function
>
>  arch/x86/cpu/irq.c|  2 +-
>  arch/x86/include/asm/acpi_table.h |  2 +-
>  arch/x86/include/asm/mpspec.h |  2 +-
>  arch/x86/include/asm/sfi.h|  2 +-
>  arch/x86/include/asm/tables.h |  2 +-
>  arch/x86/lib/acpi_table.c |  4 ++--
>  arch/x86/lib/mpspec.c |  2 +-
>  arch/x86/lib/sfi.c|  6 +++---
>  arch/x86/lib/tables.c | 11 ++-
>  arch/x86/lib/zimage.c |  2 +-
>  drivers/misc/qfw.c|  4 ++--
>  include/smbios.h  |  4 ++--
>  lib/smbios.c  | 22 +++---
>  13 files changed, 29 insertions(+), 36 deletions(-)
>

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

Re: [U-Boot] [PATCH v2 1/5] arm: tegra: initial support for apalis tk1

Hi Tom

On Mon, 2016-12-19 at 20:14 +, Tom Warren wrote:
> Marcel,
> 
> > -Original Message-
> > From: Marcel Ziswiler [mailto:mar...@ziswiler.com]
> > Sent: Monday, December 19, 2016 7:36 AM
> > To: u-boot@lists.denx.de
> > Cc: Max Krummenacher ; Stefan Agner
> > ; Marcel Ziswiler
> > ; Heiko Schocher ; Simon
> > Glass
> > ; Masahiro Yamada 
> > ;
> > York Sun ; Tom Warren ;
> > Lokesh
> > Vutla ; Ian Campbell ;
> > Peter Chubb
> > ; Jaehoon Chung  > m>;
> > Hans de Goede ; Alexander Graf 
> > ;
> > Albert Aribaud ; Stefan Roese  > e>;
> > Prabhakar Kushwaha ; Stephen Warren
> > 
> > Subject: [PATCH v2 1/5] arm: tegra: initial support for apalis tk1
> > 
> > From: Marcel Ziswiler 
> > 
> > This patch adds board support for the Toradex Apalis TK1 a computer
> > on
> > module which can be used on different carrier boards.
> > 
> > The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of
> > DDR3L
> > RAM, a bunch of level shifters, an eMMC, a TMP451 temperature
> > sensor
> > chip, an I210 gigabit Ethernet controller and a SGTL5000 audio
> > codec.
> > Furthermore, there is a Kinetis MK20DN512 companion micro
> > controller for
> > analogue, CAN and resistive touch functionality.
> > 
> > For the sake of ease of use we do not distinguish between different
> > carrier boards for now as the base module features are deemed
> > sufficient enough for regular booting.
> > 
> > The following functionality is working so far:
> > - eMMC boot, environment storage and Toradex factory config block
> > - Gigabit Ethernet
> > - MMC/SD cards (both MMC1 as well as SD1 slot)
> > - USB client/host (dual role OTG port as client e.g. for DFU/UMS or
> > host,
> >   other two ports as host)
> > 
> > Signed-off-by: Marcel Ziswiler 
> > Reviewed-by: Simon Glass 
> > 
> > ---
> > 
> > Changes in v2:
> > - Added Simon's reviewed-by.
> > 
> >  arch/arm/dts/Makefile  |1 +
> >  arch/arm/dts/tegra124-apalis.dts   | 2203
> > 
> >  arch/arm/mach-tegra/tegra124/Kconfig   |7 +
> >  board/toradex/apalis-tk1/Kconfig   |   30 +
> >  board/toradex/apalis-tk1/MAINTAINERS   |7 +
> >  board/toradex/apalis-tk1/Makefile  |5 +
> >  board/toradex/apalis-tk1/apalis-tk1.c  |  175 ++
> >  board/toradex/apalis-tk1/as3722_init.c |  117 ++
> >  board/toradex/apalis-tk1/as3722_init.h |   41 +
> >  .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h  |  287 +++
> >  configs/apalis-tk1_defconfig   |   53 +
> >  include/configs/apalis-tk1.h   |  181 ++
> >  12 files changed, 3107 insertions(+)
> >  create mode 100644 arch/arm/dts/tegra124-apalis.dts
> >  create mode 100644 board/toradex/apalis-tk1/Kconfig
> >  create mode 100644 board/toradex/apalis-tk1/MAINTAINERS
> >  create mode 100644 board/toradex/apalis-tk1/Makefile
> >  create mode 100644 board/toradex/apalis-tk1/apalis-tk1.c
> >  create mode 100644 board/toradex/apalis-tk1/as3722_init.c
> >  create mode 100644 board/toradex/apalis-tk1/as3722_init.h
> >  create mode 100644 board/toradex/apalis-tk1/pinmux-config-apalis-
> > tk1.h
> >  create mode 100644 configs/apalis-tk1_defconfig
> >  create mode 100644 include/configs/apalis-tk1.h
> > 
> 
> 
> 
> 
> I tried to apply this to u-boot-tegra/master (after rebasing that
> with u-boot/master TOT), and get the following build error:
> 
> board/toradex/apalis-tk1/apalis-tk1.c: In function 'ft_board_setup':
> board/toradex/apalis-tk1/apalis-tk1.c:39:2: warning: implicit
> declaration of function 'ft_common_board_setup' [-Wimplicit-function-
> declaration]
> board/toradex/common/built-in.o: In function `ft_board_setup':
> /home/tom/denx/uboot-tegra/board/toradex/common/tdx-common.c:125:
> multiple definition of `ft_board_setup'
> board/toradex/apalis-tk1/built-in.o:/home/tom/denx/uboot-
> tegra/board/toradex/apalis-tk1/apalis-tk1.c:39: first defined here
> board/toradex/apalis-tk1/built-in.o: In function `ft_board_setup':
> apalis-tk1.c:(.text.ft_board_setup+0x0): undefined reference to
> `ft_common_board_setup'
> arm-none-linux-gnueabi-ld: BFD (Sourcery CodeBench Lite 2011.09-70)
> 2.21.53.20110905 assertion fail /scratch/jwlemke/2011.09-arm-linux-
> eabi-lite/obj/binutils-src-2011.09-70-arm-none-linux-gnueabi-i686-pc-
> linux-gnu/bfd/elf32-arm.c:7504
> arm-none-linux-gnueabi-ld: BFD (Sourcery CodeBench Lite 2011.09-70)
> 2.21.53.20110905 assertion fail

Re: [U-Boot] [PATCH] driver: net: fsl-mc: Update MC memory allocation code

2016-12-19 Thread york sun

On 12/18/2016 09:11 PM, Priyanka Jain wrote:
> Firmware of Management Complex (MC) should be loaded
> at 512MB aligned privately allocated memory at DRAM end.
> And this memory should be reduced from total memory
> available for general purposes.

It is already reserved at the alignment of CONFIG_SYS_MC_RSV_MEM_ALIGN, 
which is 512MB. What are you changing?

>
> Update memory allocation code in MC driver to support
> above requirements.
>
> Signed-off-by: Priyanka Jain 
> ---
>  drivers/net/fsl-mc/mc.c |   98 +-
>  1 files changed, 45 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 46b8a6b..df3f7fa 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (C) 2014 Freescale Semiconductor
> + * Copyright (C) 2014, 2016 Freescale Semiconductor
>   *
>   * SPDX-License-Identifier:  GPL-2.0+
>   */
> @@ -41,6 +41,7 @@ struct fsl_dpbp_obj *dflt_dpbp = NULL;
>  struct fsl_dpio_obj *dflt_dpio = NULL;
>  struct fsl_dpni_obj *dflt_dpni = NULL;
>  static u64 mc_lazy_dpl_addr;
> +static u64 mc_ram_addr;
>
>  #ifdef DEBUG
>  void dump_ram_words(const char *title, void *addr)
> @@ -89,11 +90,11 @@ void dump_mc_ccsr_regs(struct mc_ccsr_registers __iomem 
> *mc_ccsr_regs)
>   * Copying MC firmware or DPL image to DDR
>   */
>  static int mc_copy_image(const char *title,
> -  u64 image_addr, u32 image_size, u64 mc_ram_addr)
> +  u64 image_addr, u32 image_size, u64 mc_addr)
>  {
> - debug("%s copied to address %p\n", title, (void *)mc_ram_addr);
> - memcpy((void *)mc_ram_addr, (void *)image_addr, image_size);
> - flush_dcache_range(mc_ram_addr, mc_ram_addr + image_size);
> + debug("%s copied to address %p\n", title, (void *)mc_addr);
> + memcpy((void *)mc_addr, (void *)image_addr, image_size);
> + flush_dcache_range(mc_addr, mc_addr + image_size);
>   return 0;
>  }
>
> @@ -156,16 +157,14 @@ int parse_mc_firmware_fit_image(u64 mc_fw_addr,
>  /*
>   * Calculates the values to be used to specify the address range
>   * for the MC private DRAM block, in the MCFBALR/MCFBAHR registers.
> - * It returns the highest 512MB-aligned address within the given
> - * address range, in '*aligned_base_addr', and the number of 256 MiB
> - * blocks in it, in 'num_256mb_blocks'.
> + * It stores the highest 512MB-aligned address within the given
> + * address range, in 'mc_ram_addr', and returns the number of 256 MB
> + * blocks in 'num_256mb_blocks'.
>   */
> -static int calculate_mc_private_ram_params(u64 mc_private_ram_start_addr,
> -size_t mc_ram_size,
> -u64 *aligned_base_addr,
> +static int calculate_mc_private_ram_params(size_t mc_ram_size,
>  u8 *num_256mb_blocks)
>  {
> - u64 addr;
> + u64 mc_ram_end_addr;
>   u16 num_blocks;
>
>   if (mc_ram_size % MC_RAM_SIZE_ALIGNMENT != 0) {
> @@ -180,18 +179,39 @@ static int calculate_mc_private_ram_params(u64 
> mc_private_ram_start_addr,
>  mc_ram_size);
>   return -EINVAL;
>   }
> + *num_256mb_blocks = num_blocks;
>
> - addr = (mc_private_ram_start_addr + mc_ram_size - 1) &
> + /*
> +  * The MC private DRAM block will be carved at the end of DRAM
> +  */
> + if (gd->bd->bi_dram[1].start) {
> + mc_ram_end_addr =
> + gd->bd->bi_dram[1].start + gd->bd->bi_dram[1].size;
> + } else {
> + mc_ram_end_addr =
> + gd->bd->bi_dram[0].start + gd->bd->bi_dram[0].size;
> + }
> +
> + mc_ram_addr = (mc_ram_end_addr - mc_ram_size) &
>   MC_RAM_BASE_ADDR_ALIGNMENT_MASK;
>
> - if (addr < mc_private_ram_start_addr) {
> - printf("fsl-mc: ERROR: bad start address %#llx\n",
> -mc_private_ram_start_addr);
> + if (mc_ram_addr > mc_ram_end_addr) {
> + printf("fsl-mc: ERROR: bad end address %#llx\n",
> +mc_ram_end_addr);
>   return -EFAULT;
>   }
>
> - *aligned_base_addr = addr;
> - *num_256mb_blocks = num_blocks;
> + /*
> +  * Total DRAM available for general purpose will get
> +  * reduced by the size of private DRAM allocated to MC.
> +  */
> + if (gd->bd->bi_dram[1].start) {
> + gd->bd->bi_dram[1].size =
> + mc_ram_addr - gd->bd->bi_dram[1].start;
> + } else {
> + gd->bd->bi_dram[0].size =
> + mc_ram_addr - gd->bd->bi_dram[0].start;
> + }


NAK. You cannot change the global memory size within MC driver. Please 
explain what is not working with current memory reservation.

York

___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH v2 4/4] cmd: mem: Use memcpy for 'cp' command

Hi Tom,

On Mon, Dec 19, 2016 at 8:09 PM, Tom Rini  wrote:

> I feel like this is correct.  I also feel like it's too close to release
> to do this, so I'll be applying this shortly after release, thanks!

Yes, agreed this is material for the next release.

> I also found it odd, and might try and rectify, that we don't have a
> 'cp' test in test.py which would make being relatively sure it's OK on
> x86/MIPS/PowerPC easy, slightly less easy (I'll be firing up qemu by
> hand and maybe writing a test too).

Thanks for doing this!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/4] cmd: mem: Use memcpy for 'cp' command

On Thu, Dec 15, 2016 at 04:00:13PM -0200, Fabio Estevam wrote:

> Simplify the 'cp' command implementation by using the memcpy() function,
> which brings the additional benefit of performance gain for those who have
> CONFIG_USE_ARCH_MEMCPY selected.
> 
> Tested on a mx6qsabreauto board where a 5x gain in performance is seen
> when reading 10MB from the parallel NOR memory.
> 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v1:
> - Always use memcpy()

I feel like this is correct.  I also feel like it's too close to release
to do this, so I'll be applying this shortly after release, thanks!

I also found it odd, and might try and rectify, that we don't have a
'cp' test in test.py which would make being relatively sure it's OK on
x86/MIPS/PowerPC easy, slightly less easy (I'll be firing up qemu by
hand and maybe writing a test too).

-- 
Tom

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

Re: [U-Boot] [PATCH 2/3] common/init: remove meaningless defined(CONFIG_USE_ARCH_MEMSET)

On Mon, Dec 19, 2016 at 07:31:03PM +0900, Masahiro Yamada wrote:

> CONFIG_USE_ARCH_MEMSET controls nothing about SPL.  (it is effective
> only on U-Boot proper building of ARM).

That's not true.  We have these functions available to SPL and use them
there by default now (as it's a speed win and we want out of SPL ASAP).

-- 
Tom

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

[U-Boot] [PATCH] lib: net_utils: make string_to_ip stricter

2016-12-19 Thread Chris Packham

Previously values greater than 255 were implicitly truncated. Add some
stricter checking to reject addresses with components >255.

With the input "1234192.168.1.1" the old behaviour would truncate the
address to 192.168.1.1. New behaviour rejects the string outright and
returns 0.0.0.0, which for the purposes of IP addresses can be
considered an error.

Signed-off-by: Chris Packham 
---
This was part of my long running IPv6 patchset (which I promise I'll get
back to someday). But I feel this stands on it's own merits.

 lib/net_utils.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/lib/net_utils.c b/lib/net_utils.c
index cfae84275241..f148b8a70a7d 100644
--- a/lib/net_utils.c
+++ b/lib/net_utils.c
@@ -24,11 +24,16 @@ struct in_addr string_to_ip(const char *s)
 
for (addr.s_addr = 0, i = 0; i < 4; ++i) {
ulong val = s ? simple_strtoul(s, , 10) : 0;
+   if (val > 255) {
+   addr.s_addr = 0;
+   return addr;
+   }
addr.s_addr <<= 8;
addr.s_addr |= (val & 0xFF);
-   if (s) {
-   s = (*e) ? e+1 : e;
-   }
+   if (*e == '.')
+   s = e + 1;
+   else
+   break;
}
 
addr.s_addr = htonl(addr.s_addr);
-- 
2.11.0.24.ge6920cf

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

Re: [U-Boot] [PATCH 3/3] README: remove description about CONFIG_USE_ARCH_MEMCPY/SET

On Mon, Dec 19, 2016 at 07:31:04PM +0900, Masahiro Yamada wrote:

> These options are now described in the Kconfig help.  We do not want
> to maintain duplicated documentation.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/3] ARM: revive CONFIG_USE_ARCH_MEMCPY/MEMSET for UniPhier and Tegra

On Mon, Dec 19, 2016 at 07:31:02PM +0900, Masahiro Yamada wrote:
> Commit be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to
> Kconfig") is misconversion.
> 
> The original logic in include/configs/uniphier.h was as follows:
> 
>   #if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ARM64)
>   #define CONFIG_USE_ARCH_MEMSET
>   #define CONFIG_USE_ARCH_MEMCPY
>   #endif
> 
> This means those configs were enabled when building U-Boot proper,
> but disabled when building SPL.  Likewise for Tegra.
> 
> Now "depends on !SPL" prevents any boards with SPL support
> from reaching these options.  This changed the behavior for
> UniPhier and Tegra SoC family.
> 
> Please notice these two options only control the U-Boot proper
> build.  As you see arch/arm/Makefile, ARM-specific memset/memcpy
> are never compiled for SPL.  So, __HAVE_ARCH_MEMCPY/MEMSET should
> not set for SPL.
> 
> Fixes: be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to Kconfig")
> Signed-off-by: Masahiro Yamada 

Ah, oops, thanks for spotting that one.

> ---
> 
> I am restoring the original behavior for now.
> But, I have been wondering if we could remove these options entirely.

We cannot.  That was my first attempt and we have a handful of active (I
checked) boards with tiny enough SPL constraints that switching to the
optimized memcpy/memset push them over size limit and they do not have a
"something" to disable to gain the space back.  So I went with asking
for asking for a conversion to enable by default these options as widely
as possible as it's a good thing by and (no pun intended) large.

-- 
Tom


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

[U-Boot] FIT Image Crashing

2016-12-19 Thread Kipper, Matthew

Hi all,

I'm working on a Zynq-7000 system that currently performs a "legacy" boot - the 
kernel, device tree and initramfs are loaded independently into RAM, and then 
they're all loaded by passing their addresses into 'bootm'. I'd like to update 
this to a "moderm" boot, where the system loads a single FIT image instead. 
This is my first exposure to FIT images - I thought I figured out how to do 
this, but my system is crashing so I'm beginning to doubt myself ;)

This is the "legacy" load sequence (output omitted):

setenv bootargs "console=ttyPS0,115200 root=/dev/ram rw ramdisk_size=0x160 
earlyprintk init=/sbin/init"
tftpboot 0x200 devicetree.dtb
tftpboot 0x208 uImage
tftpboot 0x400 initramfs.img

Here's the output when I actually boot:

Zynq> bootm 0x208 0x400 0x200
## Booting kernel from Legacy Image at 0208 ...
   Image Name:   Linux-4.0.0-00011-gcfd1f62
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3297728 Bytes = 3.1 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 0400 ...
   Image Name:   Ramdisk Image
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:22569621 Bytes = 21.5 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0200
   Booting using the fdt blob at 0x200
   Loading Kernel Image ... OK
   Loading Ramdisk to 1ea79000, end 1295 ... OK
   Loading Device Tree to 1ea73000, end 1ea78ba1 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
[Omitted]

The kernel boots. All is well.

To replace this with a FIT image, I created a '.its' file and compiled it with 
'mkimage'. If it matters...


* I'm using the 'mkimage' binary in my u-boot/tools directory

* 'which dtc' points to the 'scripts/dtc' directory in the kernel tree 
that I'm using for my build

I won't post the entire '.its' file, but here is the output from 'mkimage':

FIT description: Test FIT Image
Created: Mon Dec 19 14:09:14 2016
Image 0 (kernel@1)
  Description:  Linux Kernel
  Created:  Mon Dec 19 14:09:14 2016
  Type: Kernel Image
  Compression:  uncompressed
  Data Size:3297792 Bytes = 3220.50 kB = 3.15 MB
  Architecture: ARM
  OS:   Linux
  Load Address: 0x8000
  Entry Point:  0x8000
Image 1 (fdt@1)
  Description:  Device Tree Blob
  Created:  Mon Dec 19 14:09:14 2016
  Type: Flat Device Tree
  Compression:  uncompressed
  Data Size:11170 Bytes = 10.91 kB = 0.01 MB
  Architecture: ARM
Image 2 (ramdisk@1)
  Description:  initramfs
  Created:  Mon Dec 19 14:09:14 2016
  Type: RAMDisk Image
  Compression:  gzip compressed
  Data Size:22569685 Bytes = 22040.71 kB = 21.52 MB
  Architecture: ARM
  OS:   Linux
  Load Address: 0x
  Entry Point:  0x
Default Configuration: 'conf@1'
Configuration 0 (conf@1)
  Description:  Boot Linux kernel with FDT blob
  Kernel:   kernel@1
  Init Ramdisk: ramdisk@1
  FDT:  fdt@1

To me, it looks like the FIT image was built correctly. The load addresses and 
entry points line up with what U-Boot reports during a "legacy" boot. But this 
is my first time using FIT images, so I'm not 100% sure that this is correct.

To load this image, I changed the command sequence to the following (output 
omitted):

setenv bootargs "console=ttyPS0,115200 root=/dev/ram rw ramdisk_size=0x160 
earlyprintk init=/sbin/init"
tftpboot 0x200 image.itb

All my bootargs are the same as before, but now I'm only loading a single FIT 
image into RAM rather than three separate images.

Here's what happens when I try to boot:

Zynq> bootm 0x200
## Loading kernel from FIT Image at 0200 ...
   Using 'conf@1' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel@1' kernel subimage
 Description:  Linux Kernel
 Type: Kernel Image
 Compression:  uncompressed
 Data Start:   0x02c4
 Data Size:3297792 Bytes = 3.1 MiB
 Architecture: ARM
 OS:   Linux
 Load Address: 0x8000
 Entry Point:  0x8000
   Verifying Hash Integrity ... OK
## Loading ramdisk from FIT Image at 0200 ...
   Using 'conf@1' configuration
   Trying 'ramdisk@1' ramdisk subimage
 Description:  initramfs
 Type: RAMDisk Image
 Compression:  gzip compressed
 Data Start:   0x02327f88
 Data Size:22569685 Bytes = 21.5 MiB
 Architecture: ARM
 OS:   Linux
 Load Address: 0x
 Entry Point:  0x
   Verifying Hash Integrity ... OK
## Loading fdt from FIT Image at 0200 ...
   Using 'conf@1' configuration
   Trying 'fdt@1' fdt subimage
 Description:  Device Tree Blob
 Type: Flat Device Tree
 Compression:  uncompressed
 Data Start:   0x02325370
 Data Size:11170

[U-Boot] [ANN] U-Boot v2017.01-rc2 released

Hey all,

It's release day and v2017.01-rc2 is out.  I've tried to clean up my
queue a bit and I think it's looking OK.  I also know that there's a few
things others have outstanding that I'm inclined to let come in such as
binman.  If anyone thinks that's a bad idea, please shout.  I think
things are looking good and I plan to grab some Kconfig changes next
and verify the (lack of) size changes.  Things are on track for -rc3 on
January 2nd.

Thanks all!

-- 
Tom


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

Re: [U-Boot] [U-Boot, V2] tools: mxsimage: Fix build with OpenSSL 1.1.x

On Mon, Dec 19, 2016 at 03:27:50PM +0100, Marek Vasut wrote:

> The EVP_MD_CTX and EVP_CIPHER_CTX are made opaque since 1.1.x , so instead
> of embedding them directly into struct sb_image_ctx and initializing them
> using EVP_*_CTX_init(), we use pointers and allocate the crypto contexts
> using EVP_*_CTX_new().
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] ARM: mxs: Remove unused variable warning

On Thu, Dec 15, 2016 at 04:48:55PM +0100, Marek Vasut wrote:

> Shuffle the macros around a little to remove the following warning
> when building for i.MX28:
> 
> arch/arm/cpu/arm926ejs/mxs/spl_boot.c:44:26: warning: ‘iomux_boot’ defined 
> but not used [-Wunused-const-variable=]
>  static const iomux_cfg_t iomux_boot[] = {
>   ^~
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Stefano Babic 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 03/13] serial: 16550: Add Ingenic JZ4780 support

On Thu, Dec 01, 2016 at 02:06:31AM +0100, Marek Vasut wrote:

> Add compatibility string for the Ingenic JZ4780 SoC, the necessary
> UART enable bit into FCR and register shift. Neither are encoded
> in the DTS coming from Linux, so we need to support it this way.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Daniel Schwierzeck 
> Cc: Paul Burton 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 02/13] serial: 16550: Add port type as driver data

On Thu, Dec 01, 2016 at 02:06:30AM +0100, Marek Vasut wrote:

> Add driver data to each compatible string to identify the type of
> the port. Since all the ports in the driver are entirely compatible
> with 16550 for now, all are marked with PORT_NS16550. But, there
> are ports which have specific quirks, like the JZ4780 UART, which
> do not have any DT property to denote the quirks. Instead, Linux
> uses the compatible string to discern such ports and enable the
> necessary quirks.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,01/13] serial: 16550: Add getfcr accessor

On Thu, Dec 01, 2016 at 02:06:29AM +0100, Marek Vasut wrote:

> Add function which allows fetching the default FCR register setting
> from platform data for DM , while retaining old behavior for non-DM
> by returning UART_FCRVAL.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

On Sun, Dec 18, 2016 at 06:48:17PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> please pull from u-boot-imx, thanks !
> 
> The following changes since commit 53e8ca22538c2cec691fe74098684a359302688c:
> 
>   MAINTAINERS: DFU: Change e-mail address for DFU maintainer (2016-12-12
> 13:03:15 -0500)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to 854bb75be98ad792ff64c26ae38a1392ea185cd6:
> 
>   imx6: icorem6_rqs: Add FEC support (2016-12-16 18:39:06 +0100)
> 

After migrating CONFIG_USE_ARCH_MEMSET/MEMCPY (they are on by default
for ARMv7 now), applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 1/5] arm: tegra: initial support for apalis tk1

2016-12-19 Thread Tom Warren

Marcel,

> -Original Message-
> From: Marcel Ziswiler [mailto:mar...@ziswiler.com]
> Sent: Monday, December 19, 2016 7:36 AM
> To: u-boot@lists.denx.de
> Cc: Max Krummenacher ; Stefan Agner
> ; Marcel Ziswiler
> ; Heiko Schocher ; Simon Glass
> ; Masahiro Yamada ;
> York Sun ; Tom Warren ; Lokesh
> Vutla ; Ian Campbell ; Peter Chubb
> ; Jaehoon Chung ;
> Hans de Goede ; Alexander Graf ;
> Albert Aribaud ; Stefan Roese ;
> Prabhakar Kushwaha ; Stephen Warren
> 
> Subject: [PATCH v2 1/5] arm: tegra: initial support for apalis tk1
> 
> From: Marcel Ziswiler 
> 
> This patch adds board support for the Toradex Apalis TK1 a computer on
> module which can be used on different carrier boards.
> 
> The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L
> RAM, a bunch of level shifters, an eMMC, a TMP451 temperature sensor
> chip, an I210 gigabit Ethernet controller and a SGTL5000 audio codec.
> Furthermore, there is a Kinetis MK20DN512 companion micro controller for
> analogue, CAN and resistive touch functionality.
> 
> For the sake of ease of use we do not distinguish between different
> carrier boards for now as the base module features are deemed
> sufficient enough for regular booting.
> 
> The following functionality is working so far:
> - eMMC boot, environment storage and Toradex factory config block
> - Gigabit Ethernet
> - MMC/SD cards (both MMC1 as well as SD1 slot)
> - USB client/host (dual role OTG port as client e.g. for DFU/UMS or host,
>   other two ports as host)
> 
> Signed-off-by: Marcel Ziswiler 
> Reviewed-by: Simon Glass 
> 
> ---
> 
> Changes in v2:
> - Added Simon's reviewed-by.
> 
>  arch/arm/dts/Makefile  |1 +
>  arch/arm/dts/tegra124-apalis.dts   | 2203 
> 
>  arch/arm/mach-tegra/tegra124/Kconfig   |7 +
>  board/toradex/apalis-tk1/Kconfig   |   30 +
>  board/toradex/apalis-tk1/MAINTAINERS   |7 +
>  board/toradex/apalis-tk1/Makefile  |5 +
>  board/toradex/apalis-tk1/apalis-tk1.c  |  175 ++
>  board/toradex/apalis-tk1/as3722_init.c |  117 ++
>  board/toradex/apalis-tk1/as3722_init.h |   41 +
>  .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h  |  287 +++
>  configs/apalis-tk1_defconfig   |   53 +
>  include/configs/apalis-tk1.h   |  181 ++
>  12 files changed, 3107 insertions(+)
>  create mode 100644 arch/arm/dts/tegra124-apalis.dts
>  create mode 100644 board/toradex/apalis-tk1/Kconfig
>  create mode 100644 board/toradex/apalis-tk1/MAINTAINERS
>  create mode 100644 board/toradex/apalis-tk1/Makefile
>  create mode 100644 board/toradex/apalis-tk1/apalis-tk1.c
>  create mode 100644 board/toradex/apalis-tk1/as3722_init.c
>  create mode 100644 board/toradex/apalis-tk1/as3722_init.h
>  create mode 100644 board/toradex/apalis-tk1/pinmux-config-apalis-tk1.h
>  create mode 100644 configs/apalis-tk1_defconfig
>  create mode 100644 include/configs/apalis-tk1.h
> 



I tried to apply this to u-boot-tegra/master (after rebasing that with 
u-boot/master TOT), and get the following build error:

board/toradex/apalis-tk1/apalis-tk1.c: In function 'ft_board_setup':
board/toradex/apalis-tk1/apalis-tk1.c:39:2: warning: implicit declaration of 
function 'ft_common_board_setup' [-Wimplicit-function-declaration]
board/toradex/common/built-in.o: In function `ft_board_setup':
/home/tom/denx/uboot-tegra/board/toradex/common/tdx-common.c:125: multiple 
definition of `ft_board_setup'
board/toradex/apalis-tk1/built-in.o:/home/tom/denx/uboot-tegra/board/toradex/apalis-tk1/apalis-tk1.c:39:
 first defined here
board/toradex/apalis-tk1/built-in.o: In function `ft_board_setup':
apalis-tk1.c:(.text.ft_board_setup+0x0): undefined reference to 
`ft_common_board_setup'
arm-none-linux-gnueabi-ld: BFD (Sourcery CodeBench Lite 2011.09-70) 
2.21.53.20110905 assertion fail 
/scratch/jwlemke/2011.09-arm-linux-eabi-lite/obj/binutils-src-2011.09-70-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:7504
arm-none-linux-gnueabi-ld: BFD (Sourcery CodeBench Lite 2011.09-70) 
2.21.53.20110905 assertion fail 
/scratch/jwlemke/2011.09-arm-linux-eabi-lite/obj/binutils-src-2011.09-70-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13826
Segmentation fault (core dumped)
make: *** [u-boot] Error 139

Is this building OK for you against u-boot-tegra/master or u-boot/master?

Here are my top dozen commits for my local

Re: [U-Boot] Problem: the build does not recurse into subdirectory

2016-12-19 Thread Maxim Sloyko

On Sat, Dec 17, 2016 at 2:46 PM, Simon Glass  wrote:
> Hi Maxim,
>
> On 16 December 2016 at 17:18, Maxim Sloyko  wrote:
>> Greetings,
>>
>> I'm working on adding new platform to U-Boot and right now I'm trying
>> to clean up the directory structure, but running into a problem of
>> Make not recursing into a subdirectory that I've created.
>>
>> in my arch/arm/mach-aspeed/Makefile I have this:
>>
>> obj-$(CONFIG_ASPEED_AST2500) += ast2500/ ast2500-board.o
>>
>> and then in arch/arm/mach-aspeed/ast2500/Makefile:
>>
>> $obj-y += clk_ast2500.o sdram_ast2500.o
>
> What is the $ for? I don't think you want that.

Oh my, I can't believe I was that stupid :)

Thanks for the help, that's what the problem was.

>
>>
>> When I try to build everything, I get this error:
>>
>> arm-linux-gnueabi-ld.bfd: cannot find
>> arch/arm/mach-aspeed/ast2500/built-in.o: No such file or directory
>>
>> If instead in arch/arm/mach-aspeed/Makefile I specify:
>>
>> obj-$(CONFIG_ASPEED_AST2500) += ast2500/clk_ast2500.o
>> ast2500/sdram_ast2500.o ast2500-board.o
>>
>> (That is, I just added binaries from the lower level dir explicitly)
>>
>> everything builds fine, which means that CONFIG_ASPEED_AST2500 is defined.
>>
>> Any ideas what might be the problem here?
>>
>> If you need more details, you can see the code here
>> https://github.com/maksymko/u-boot/tree/aspeed_ast2500_evb/arch/arm/mach-aspeed
>>
>> Many thanks for the help!
>>
>> --
>> Maxim Sloyko
>
> Regards,
> Simon



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

Re: [U-Boot] [RESEND PATCH v2] powerpc: Retain compatible property for L2 cache

2016-12-19 Thread york sun

On 12/18/2016 11:26 PM, Chris Packham wrote:
> When setting the compatible property for the L2 cache ensure that we
> follow the documented binding by setting both
> "-l2-cache-controller" and "cache" as values.
>
> Signed-off-by: Chris Packham 
> ---
>
> Changes in v2:
> - extract a helper function to set the compatible property and use it in
>   both the CONFIG_L2_CACHE and CONFIG_BACKSIDE_L2_CACHE cases.

I guess you meant to remind me about this patch. It is not forgotten. 
Actually it is in my test queue. I planned to merge it after another 
round of 85xx Kconfig change. I will see if I can merge this one sooner.

York

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

Re: [U-Boot] [PATCH 1/2] sunxi: add proper device tree for Orange Pi Zero boards

2016-12-19 Thread Jagan Teki

On Mon, Dec 19, 2016 at 5:23 PM, Icenowy Zheng  wrote:
>
>
> 16.12.2016, 22:52, "Jagan Teki" :
>> On Fri, Dec 16, 2016 at 3:35 PM, Icenowy Zheng  wrote:
>>>  Add a proper device tree file for Orange Pi Zero boards from Xunlong,
>>>  which come with a Allwinner H2+ SoC (similar to H3).
>>>
>>>  Signed-off-by: Icenowy Zheng 
>>
>> Reviewed-by: Jagan Teki 
>
> Could you merge this patchset?
>
> As Hans de Goede said in
> http://lists.denx.de/pipermail/u-boot/2016-December/276487.html ,
> he's no longer the maintainer, and now the maintainer is you.

Yes, I will apply for next.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] sunxi: add proper device tree for Orange Pi Zero boards

2016-12-19 Thread Icenowy Zheng



16.12.2016, 22:52, "Jagan Teki" :
> On Fri, Dec 16, 2016 at 3:35 PM, Icenowy Zheng  wrote:
>>  Add a proper device tree file for Orange Pi Zero boards from Xunlong,
>>  which come with a Allwinner H2+ SoC (similar to H3).
>>
>>  Signed-off-by: Icenowy Zheng 
>
> Reviewed-by: Jagan Teki 

Could you merge this patchset?

As Hans de Goede said in
http://lists.denx.de/pipermail/u-boot/2016-December/276487.html ,
he's no longer the maintainer, and now the maintainer is you.

Thanks!

>
> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problems to Allwinner H3's eFUSE/SID

2016-12-19 Thread Hans de Goede

Hi,

On 19-12-16 17:25, Icenowy Zheng wrote:

20.12.2016, 00:17, "Hans de Goede" :

Hi,

On 19-12-16 17:06, Icenowy Zheng wrote:

19.12.2016, 23:30, "Hans de Goede" :

Hi,

On 19-12-16 16:22, Icenowy Zheng wrote:

Hi everyone,

Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
controller of H3 (incl. H2+).

See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
directly access 0x01c14200.

From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
legacy kernel).

According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
0x58 is H3D (currently not known SoC) )

However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
with 0x02004620, which do not match this rule.

The readout by devmem2 is satisfying this rule: their first word is
0x02c00081, matches H3.

Then I found the SID-reading code from BSP U-Boot[2], which is based on
register operations. With this kind of code (I wrote one prototype in
userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel sid)
And, after accessing to the SID by registers, the value of *0x01c14200 become
also "02c00081".

With direct access to 0x01c14200 after boot with mainline kernel, I got also
"02004620".

Then I altered the program to do the register operations with sunxi-fel, the
result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".

Summary:

+---++
| Read situation | The first word |
+---++
| Direct read by sunxi-fel | 02004620 |
| Direct read in mainline /dev/mem | 02004620 |
| Direct read in legacy /dev/mem | 02c00081 |
| Register access in FEL | 02c00081 |
| Register access in mainline | 02c00081 |
| Direct read after register access in FEL | 02c00081 |
| Direct read after register access in mainline | 02c00081 |
+---++

According to some facts:
- The register based access to SID is weird: it needs ~5 register
operations per word of SID.
- Reading via register access will change the value when reading by accessing
0x01c14200.
- In the u-boot code[2] there's some functions which read out the SID by
registers and then abandoned the value.
- This mismatch do not exist on A64.

I think that: Allwinner designed a "cache" to the SID to make the simplify the
code to read it, and it automatically loaded the cache when booting; however,
when doing first cache on H3, some byte shifts occured, and the value become
wrong. A manual read on H3 can make the cache right again. This is a silicon
bug, and fixed in A64.

This raises a problem: currently many systems has used the misread SID value
to
generated lots of MAC addresses, and workaround this SID bug will change them.

However, if this bug is not workarounded, the sun8i-ths driver won't work well
(as some calibartion value lies in eFUSE). I think some early user of this
driver has already experienced bad readout value.
(The calibration value differs on my opi1 and KotCzarny's opipc)

And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
think sunxi-fel must have the workaround)

Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

Furthermore, A83T may also have this problem, testers are welcome!

[1]
http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
[2]
http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

Experiments:
- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
A SID readout shell script via FEL with register access.
- https://31.135.195.151:20281/d/efuse/
A SID readout program via /dev/mem with register access by KotCzarny.
(with statically compiled binary)

Good detective work!

I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.

Yes.

However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.

I know, but I think we will just need to accept this onetime change
of the fixed MAC addresses to fix this bug. I don't think this is
a big problem since the driver for the H3 ethernet has not been
merged into the

Re: [U-Boot] Problems to Allwinner H3's eFUSE/SID

2016-12-19 Thread Icenowy Zheng

20.12.2016, 00:17, "Hans de Goede" :
> Hi,
>
> On 19-12-16 17:06, Icenowy Zheng wrote:
>>  19.12.2016, 23:30, "Hans de Goede" :
>>>  Hi,
>>>
>>>  On 19-12-16 16:22, Icenowy Zheng wrote:
   Hi everyone,

   Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
   controller of H3 (incl. H2+).

   See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

   Two read method of the H3 eFUSE is used in the BSP: by register 
 accessing, or
   directly access 0x01c14200.

   From http://linux-sunxi.org/SID_Register_Guide we can see a difference 
 between
   the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
   legacy kernel).

   According to the source of H2+ BSP[1], H2+ and H3 can be differed by the 
 last
   byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is 
 H3,
   0x58 is H3D (currently not known SoC) )

   However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, 
 start
   with 0x02004620, which do not match this rule.

   The readout by devmem2 is satisfying this rule: their first word is
   0x02c00081, matches H3.

   Then I found the SID-reading code from BSP U-Boot[2], which is based on
   register operations. With this kind of code (I wrote one prototype in
   userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
   my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel 
 sid)
   And, after accessing to the SID by registers, the value of *0x01c14200 
 become
   also "02c00081".

   With direct access to 0x01c14200 after boot with mainline kernel, I got 
 also
   "02004620".

   Then I altered the program to do the register operations with sunxi-fel, 
 the
   result is also "02c00081", and changed `sunxi-fel sid` result to 
 "02c00081".

   Summary:

   +---++
   | Read situation | The first word |
   +---++
   | Direct read by sunxi-fel | 02004620 |
   | Direct read in mainline /dev/mem | 02004620 |
   | Direct read in legacy /dev/mem | 02c00081 |
   | Register access in FEL | 02c00081 |
   | Register access in mainline | 02c00081 |
   | Direct read after register access in FEL | 02c00081 |
   | Direct read after register access in mainline | 02c00081 |
   +---++

   According to some facts:
   - The register based access to SID is weird: it needs ~5 register
 operations per word of SID.
   - Reading via register access will change the value when reading by 
 accessing
 0x01c14200.
   - In the u-boot code[2] there's some functions which read out the SID by
 registers and then abandoned the value.
   - This mismatch do not exist on A64.

   I think that: Allwinner designed a "cache" to the SID to make the 
 simplify the
   code to read it, and it automatically loaded the cache when booting; 
 however,
   when doing first cache on H3, some byte shifts occured, and the value 
 become
   wrong. A manual read on H3 can make the cache right again. This is a 
 silicon
   bug, and fixed in A64.

   This raises a problem: currently many systems has used the misread SID 
 value to
   generated lots of MAC addresses, and workaround this SID bug will change 
 them.

   However, if this bug is not workarounded, the sun8i-ths driver won't 
 work well
   (as some calibartion value lies in eFUSE). I think some early user of 
 this
   driver has already experienced bad readout value.
   (The calibration value differs on my opi1 and KotCzarny's opipc)

   And many wrong SID values have been generated by `sunxi-fel sid`. 
 (Although I
   think sunxi-fel must have the workaround)

   Note: in this email, "SID" and "eFUSE" both indicate the controller on 
 H3/A64
   at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

   Furthermore, A83T may also have this problem, testers are welcome!

   [1] 
 http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
   [2] 
 http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

   Experiments:
   - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
 A SID readout shell script via FEL with register access.
   - https://31.135.195.151:20281/d/efuse/
 A SID readout program via /dev/mem with register access by KotCzarny.
 (with statically compiled binary)
>>>
>>>

[U-Boot] QSPI "sf probe ...", "sf read ..." on Altera SoC FPGA

2016-12-19 Thread Eldor Rødseth

Hi,

 

I observe a behavior with the QSPI functionality on newer uboot versions; e.g. 
2016.11 rc1 and also latest from DENX mainline.

I was wondering whether anyone else has experienced similar issue(s) and can 
perhaps give hints as to what can cause this.

I will try to narrow down the issue to a couple of examples related to “sf 
probe …” and “sf read ..”.

I apologize for the long listing, but I am running with full DEBUG for 
additional details:

 

Example #1:

When issuing “sf probe” with no parameters; i.e. use defaults, the command 
fails and causes board reboot:

=> sf probe

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

spi_find_bus_and_cs: No bus 0

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

uclass_find_device_by_seq: 1 0

   - 0 -1

   - found

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

fdtdec_get_int_array: reg

get_prop_check_min_len: reg

fdtdec_get_uint: spi-max-frequency: 0x5f5e100 (1)

fdtdec_get_int: page-size: 0x100 (256)

fdtdec_get_int: block-size: 0x10 (16)

fdtdec_get_int: tshsl-ns: 0x32 (50)

fdtdec_get_int: tsd2d-ns: 0x32 (50)

fdtdec_get_int: tchsh-ns: 0x4 (4)

fdtdec_get_int: tslch-ns: 0x4 (4)

fdtdec_get_int: sram-size: 0x80 (128)

cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa0 
max-frequency=1 page-size=256

fdtdec_get_int: spi-max-frequency: (not found)

spi_get_bus_and_cs: Binding new device 'spi_flash@0:0', busnum=0, cs=0, 
driver=spi_flash_std

Bound device spi_flash@0:0 to spi@ff705000

uclass_find_device_by_seq: 0 -1

uclass_find_device_by_seq: 0 0

   - -1 -1

   - not found

spi_flash_std_probe: slave=7bf49e88, cs=0

cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf

cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 10Hz Div 0xf

SF: Read data capture delay calibrated to 7 (0 - 15)

cadence_spi_set_speed: speed=10

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=5 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

SF: Got idcodes

: 20 ba 22 10 44  .".D

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

fdtdec_get_addr_size_fixed: memory-map: (not found)

spi_flash_decode_fdt: Cannot decode address

SF: Detected MT25QL02 with page size 256 Bytes, erase size 64 KiB, total 256 MiB

cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf

### ERROR ### Please RESET the board ###

 

--

 

Example #2:

When issuing “sf probe ”; the command apparently succeeds; i.e. 
correct flash type is detected.

However – look at Example #3 below.

=> sf probe 0 1 3 ß should be identical parameters as read from DTS in 
Example #1

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

spi_find_bus_and_cs: No bus 0

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

uclass_find_device_by_seq: 1 0

   - 0 -1

   - found

uclass_find_device_by_seq: 0 0

   - 0 -1

   - not found

fdtdec_get_int_array: reg

get_prop_check_min_len: reg

fdtdec_get_uint: spi-max-frequency: 0x5f5e100 (1)

fdtdec_get_int: page-size: 0x100 (256)

fdtdec_get_int: block-size: 0x10 (16)

fdtdec_get_int: tshsl-ns: 0x32 (50)

fdtdec_get_int: tsd2d-ns: 0x32 (50)

fdtdec_get_int: tchsh-ns: 0x4 (4)

fdtdec_get_int: tslch-ns: 0x4 (4)

fdtdec_get_int: sram-size: 0x80 (128)

cadence_spi_ofdata_to_platdata: regbase=ff705000 ahbbase=ffa0 
max-frequency=1 page-size=256

fdtdec_get_int: spi-max-frequency: (not found)

spi_get_bus_and_cs: Binding new device 'spi_flash@0:0', busnum=0, cs=0, 
driver=spi_flash_std

Bound device spi_flash@0:0 to spi@ff705000

uclass_find_device_by_seq: 0 -1

uclass_find_device_by_seq: 0 0

   - -1 -1

   - not found

spi_flash_std_probe: slave=7bf49ec0, cs=0

cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 100Hz Div 0xf

cadence_qspi_apb_config_baudrate_div: ref_clk 4Hz sclk 1Hz Div 
0x1

SF: Read data capture delay calibrated to 3 (2 - 4)

cadence_spi_set_speed: speed=1

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=5 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

SF: Got idcodes

: 20 ba 22 10 44  .".D

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

cadence_spi_xfer: len=1 [bytes]

cadence_qspi_apb_chipselect : chipselect 0 decode 0

fdtdec_get_addr_size_fixed: memory-map: (not found)

spi_flash_decode_fdt: Cannot decode address

SF: Detected MT25QL02 with page size 256 Bytes, erase size 64 KiB, total 256 MiB

cadence_spi_set_speed: speed=1

spi_get_bus_and_cs: bus=7bf48348, slave=7bf49ec0

=> 

 

--

 

Example #3:

After successful “sf

[U-Boot] [PATCH v2 1/5] arm: tegra: initial support for apalis tk1

From: Marcel Ziswiler 

This patch adds board support for the Toradex Apalis TK1 a computer on
module which can be used on different carrier boards.

The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L
RAM, a bunch of level shifters, an eMMC, a TMP451 temperature sensor
chip, an I210 gigabit Ethernet controller and a SGTL5000 audio codec.
Furthermore, there is a Kinetis MK20DN512 companion micro controller for
analogue, CAN and resistive touch functionality.

For the sake of ease of use we do not distinguish between different
carrier boards for now as the base module features are deemed
sufficient enough for regular booting.

The following functionality is working so far:
- eMMC boot, environment storage and Toradex factory config block
- Gigabit Ethernet
- MMC/SD cards (both MMC1 as well as SD1 slot)
- USB client/host (dual role OTG port as client e.g. for DFU/UMS or host,
  other two ports as host)

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Simon Glass 

---

Changes in v2:
- Added Simon's reviewed-by.

 arch/arm/dts/Makefile  |1 +
 arch/arm/dts/tegra124-apalis.dts   | 2203 
 arch/arm/mach-tegra/tegra124/Kconfig   |7 +
 board/toradex/apalis-tk1/Kconfig   |   30 +
 board/toradex/apalis-tk1/MAINTAINERS   |7 +
 board/toradex/apalis-tk1/Makefile  |5 +
 board/toradex/apalis-tk1/apalis-tk1.c  |  175 ++
 board/toradex/apalis-tk1/as3722_init.c |  117 ++
 board/toradex/apalis-tk1/as3722_init.h |   41 +
 .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h  |  287 +++
 configs/apalis-tk1_defconfig   |   53 +
 include/configs/apalis-tk1.h   |  181 ++
 12 files changed, 3107 insertions(+)
 create mode 100644 arch/arm/dts/tegra124-apalis.dts
 create mode 100644 board/toradex/apalis-tk1/Kconfig
 create mode 100644 board/toradex/apalis-tk1/MAINTAINERS
 create mode 100644 board/toradex/apalis-tk1/Makefile
 create mode 100644 board/toradex/apalis-tk1/apalis-tk1.c
 create mode 100644 board/toradex/apalis-tk1/as3722_init.c
 create mode 100644 board/toradex/apalis-tk1/as3722_init.h
 create mode 100644 board/toradex/apalis-tk1/pinmux-config-apalis-tk1.h
 create mode 100644 configs/apalis-tk1_defconfig
 create mode 100644 include/configs/apalis-tk1.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f437469..e3155b4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -57,6 +57,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra30-colibri.dtb \
tegra30-tec-ng.dtb \
tegra114-dalmore.dtb \
+   tegra124-apalis.dtb \
tegra124-jetson-tk1.dtb \
tegra124-nyan-big.dtb \
tegra124-cei-tk1-som.dtb \
diff --git a/arch/arm/dts/tegra124-apalis.dts b/arch/arm/dts/tegra124-apalis.dts
new file mode 100644
index 000..3853a28
--- /dev/null
+++ b/arch/arm/dts/tegra124-apalis.dts
@@ -0,0 +1,2203 @@
+/*
+ * Copyright 2016 Toradex AG
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER

Re: [U-Boot] [PATCH 08/10] arm: socfpga: arria10: Added drivers for Arria10 clock manager

2016-12-19 Thread Chee, Tien Fong

On Sel, 2016-12-06 at 16:10 +0800, Chee Tien Fong wrote:
> From: Tien Fong Chee 
> 
> The drivers is restructured such common functions, gen5 functions,
> and arria10 functions are moved to clock_manager.c, cock_manager_gen5
> and clock_manager_arria10 respectively.
> 
> Signed-off-by: Tien Fong Chee 
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> Cc: Tien Fong 
> ---
>  arch/arm/mach-socfpga/Makefile |6 +-
>  arch/arm/mach-socfpga/clock_manager.c  |  754 +++---
> --
>  arch/arm/mach-socfpga/clock_manager_arria10.c  |  954
> 
>  arch/arm/mach-socfpga/clock_manager_gen5.c |  342 +++
>  arch/arm/mach-socfpga/include/mach/clock_manager.h |  360 ++--
>  5 files changed, 1910 insertions(+), 506 deletions(-)
>  create mode 100644 arch/arm/mach-socfpga/clock_manager_arria10.c
>  create mode 100644 arch/arm/mach-socfpga/clock_manager_gen5.c
> 
> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> socfpga/Makefile
> index f8b529e..71cf31c 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -9,9 +9,11 @@
>  
Any comments on this patch before i start the version 2?

>  obj-y+= misc.o timer.o reset_manager.o system_manager.o
> clock_manager.o \
>      fpga_manager.o board.o
> -obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o
> misc_arria10.o
> +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o
> misc_arria10.o \
> + clock_manager_arria10.o
>  obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += scan_manager.o
> wrap_pll_config.o \
> - reset_manager_gen5.o misc_gen5.o
> + reset_manager_gen5.o misc_gen5.o \
> + clock_manager_gen5.o
>  
>  ifdef CONFIG_SPL_BUILD
>  obj-y += spl.o
> diff --git a/arch/arm/mach-socfpga/clock_manager.c b/arch/arm/mach-
> socfpga/clock_manager.c
> index aa71636..fe82c39 100644
> --- a/arch/arm/mach-socfpga/clock_manager.c
> +++ b/arch/arm/mach-socfpga/clock_manager.c
> @@ -1,422 +1,293 @@
>  /*
> - *  Copyright (C) 2013 Altera Corporation 
> + *  Copyright (C) 2013-2016 Intel Corporation 
>   *
> - * SPDX-License-Identifier:  GPL-2.0+
> + * SPDX-License-Identifier:  GPL-2.0
>   */
>  
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> +/* Function prototypes */
> +/* Common prototypes */
> +unsigned int cm_get_l4_sp_clk_hz(void);
> +unsigned int cm_get_qspi_controller_clk_hz(void);
> +unsigned int cm_get_mmc_controller_clk_hz(void);
> +unsigned int cm_get_spi_controller_clk_hz(void);
> +static void cm_print_clock_quick_summary(void);
> +int do_showclocks(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[]);
> +void cm_wait_for_lock(uint32_t mask);
> +void cm_wait_for_fsm(void);
> +unsigned int cm_get_main_vco_clk_hz(void);
> +unsigned int cm_get_per_vco_clk_hz(void);
> +unsigned long cm_get_mpu_clk_hz(void);
> +
>  static const struct socfpga_clock_manager *clock_manager_base =
>   (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
>  
> -static void cm_wait_for_lock(uint32_t mask)
> +/* Common functions */
> +int set_cpu_clk_info(void)
>  {
> - register uint32_t inter_val;
> - uint32_t retry = 0;
> - do {
> - inter_val = readl(_manager_base->inter) &
> mask;
> - if (inter_val == mask)
> - retry++;
> - else
> - retry = 0;
> - if (retry >= 10)
> - break;
> - } while (1);
> -}
> + /* Calculate the clock frequencies required for drivers */
> + cm_get_l4_sp_clk_hz();
> + cm_get_mmc_controller_clk_hz();
>  
> -/* function to poll in the fsm busy bit */
> -static void cm_wait_for_fsm(void)
> -{
> - while (readl(_manager_base->stat) & CLKMGR_STAT_BUSY)
> - ;
> -}
> + gd->bd->bi_arm_freq = cm_get_mpu_clk_hz() / 100;
> + gd->bd->bi_dsp_freq = 0;
>  
> -/*
> - * function to write the bypass register which requires a poll of
> the
> - * busy bit
> - */
> -static void cm_write_bypass(uint32_t val)
> -{
> - writel(val, _manager_base->bypass);
> - cm_wait_for_fsm();
> -}
> +#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> + gd->bd->bi_ddr_freq = cm_get_sdram_clk_hz() / 100;
> +#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> + gd->bd->bi_ddr_freq = 0;
> +#endif
>  
> -/* function to write the ctrl register which requires a poll of the
> busy bit */
> -static void cm_write_ctrl(uint32_t val)
> -{
> - writel(val, _manager_base->ctrl);
> - cm_wait_for_fsm();
> + return 0;
>  }
>  
> -/* function to write a clock register that has phase information */
> -static void cm_write_with_phase(uint32_t value,
> - uint32_t reg_address,

Re: [U-Boot] Problems to Allwinner H3's eFUSE/SID

2016-12-19 Thread Hans de Goede

Hi,

On 19-12-16 17:06, Icenowy Zheng wrote:

19.12.2016, 23:30, "Hans de Goede" :

Hi,

On 19-12-16 16:22, Icenowy Zheng wrote:

Hi everyone,

Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
controller of H3 (incl. H2+).

See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
directly access 0x01c14200.

From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
legacy kernel).

According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
0x58 is H3D (currently not known SoC) )

However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
with 0x02004620, which do not match this rule.

The readout by devmem2 is satisfying this rule: their first word is
0x02c00081, matches H3.

With direct access to 0x01c14200 after boot with mainline kernel, I got also
"02004620".

Then I altered the program to do the register operations with sunxi-fel, the
result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".

Summary:

This raises a problem: currently many systems has used the misread SID value to
generated lots of MAC addresses, and workaround this SID bug will change them.

And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
think sunxi-fel must have the workaround)

Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

Furthermore, A83T may also have this problem, testers are welcome!

Good detective work!

I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.

Yes.

However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.

Maybe we should add #ifdef's to MAC generation code after this fix.

I would rather not see #ifdefs for this, see above, but that is no
longer my call, see below.

[U-Boot] Uboot for Wakame Board (New ARM single board openhardware computer).

2016-12-19 Thread madscientist

I am working on a new Allwiner A13 and accesory chipset board, whose 
name is Wakame, after the seafood.


After working several months on this project, now i think that the idea 
of building a prototype starts to come a feasible thing.Obviously it is 
my very first development ever since i entered into the Open Hardware 
arena and some details may come up that could be needing some fix here 
and there.


The reason for this email is that, i'm in need for a Firmware. After 
finding out in several places, many people tells me about Uboot. Happens 
that, i'm not that knowledgeable about it. I tried to build Uboot in my 
pc and when using Make and other parameter i got a menu where i think i 
never could make proper choices for this soon to be arm open computer..


I actually wish this board to be able to boot both from an usb hard disk 
and or usb cd/dvd unit. I have been told that, while the A13 soc may 
have uboot right on it, even i found a pin with that name in the sheets, 
i actually wish to separate the bootrom of the os as i wish to achieve a 
desktop computer behaviour rather than a tablet one.  The closest board 
to Wakame i know is the Olimex A13 but while the SOC is the same, the 
chips in the Wakame are different from the Olimex and that means a 
concern or two about Uboot compatibility..


Should you have any interest on this project, you can see it here:

https://github.com/temporaryuser132/wakameboard

The files in the github above are actually an Altium 2009 workspace, and 
they are available under gnu-glpl terms so anyone with proper knowledge 
can study, modify and build it, in the hope it gets better with time and 
people taking knowledge about it.


Thanks for your support.

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

Re: [U-Boot] Problems to Allwinner H3's eFUSE/SID

2016-12-19 Thread Icenowy Zheng



19.12.2016, 23:30, "Hans de Goede" :
> Hi,
>
> On 19-12-16 16:22, Icenowy Zheng wrote:
>>  Hi everyone,
>>
>>  Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
>>  controller of H3 (incl. H2+).
>>
>>  See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .
>>
>>  Two read method of the H3 eFUSE is used in the BSP: by register accessing, 
>> or
>>  directly access 0x01c14200.
>>
>>  From http://linux-sunxi.org/SID_Register_Guide we can see a difference 
>> between
>>  the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
>>  legacy kernel).
>>
>>  According to the source of H2+ BSP[1], H2+ and H3 can be differed by the 
>> last
>>  byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
>>  0x58 is H3D (currently not known SoC) )
>>
>>  However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
>>  with 0x02004620, which do not match this rule.
>>
>>  The readout by devmem2 is satisfying this rule: their first word is
>>  0x02c00081, matches H3.
>>
>>  Then I found the SID-reading code from BSP U-Boot[2], which is based on
>>  register operations. With this kind of code (I wrote one prototype in
>>  userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
>>  my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel sid)
>>  And, after accessing to the SID by registers, the value of *0x01c14200 
>> become
>>  also "02c00081".
>>
>>  With direct access to 0x01c14200 after boot with mainline kernel, I got also
>>  "02004620".
>>
>>  Then I altered the program to do the register operations with sunxi-fel, the
>>  result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".
>>
>>  Summary:
>>
>>  +---++
>>  | Read situation | The first word |
>>  +---++
>>  | Direct read by sunxi-fel | 02004620 |
>>  | Direct read in mainline /dev/mem | 02004620 |
>>  | Direct read in legacy /dev/mem | 02c00081 |
>>  | Register access in FEL | 02c00081 |
>>  | Register access in mainline | 02c00081 |
>>  | Direct read after register access in FEL | 02c00081 |
>>  | Direct read after register access in mainline | 02c00081 |
>>  +---++
>>
>>  According to some facts:
>>  - The register based access to SID is weird: it needs ~5 register
>>    operations per word of SID.
>>  - Reading via register access will change the value when reading by 
>> accessing
>>    0x01c14200.
>>  - In the u-boot code[2] there's some functions which read out the SID by
>>    registers and then abandoned the value.
>>  - This mismatch do not exist on A64.
>>
>>  I think that: Allwinner designed a "cache" to the SID to make the simplify 
>> the
>>  code to read it, and it automatically loaded the cache when booting; 
>> however,
>>  when doing first cache on H3, some byte shifts occured, and the value become
>>  wrong. A manual read on H3 can make the cache right again. This is a silicon
>>  bug, and fixed in A64.
>>
>>  This raises a problem: currently many systems has used the misread SID 
>> value to
>>  generated lots of MAC addresses, and workaround this SID bug will change 
>> them.
>>
>>  However, if this bug is not workarounded, the sun8i-ths driver won't work 
>> well
>>  (as some calibartion value lies in eFUSE). I think some early user of this
>>  driver has already experienced bad readout value.
>>  (The calibration value differs on my opi1 and KotCzarny's opipc)
>>
>>  And many wrong SID values have been generated by `sunxi-fel sid`. (Although 
>> I
>>  think sunxi-fel must have the workaround)
>>
>>  Note: in this email, "SID" and "eFUSE" both indicate the controller on 
>> H3/A64
>>  at 0x01c14000, which is a OTP memory implemented by eFUSE technique.
>>
>>  Furthermore, A83T may also have this problem, testers are welcome!
>>
>>  [1] 
>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
>>  [2] 
>> http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c
>>
>>  Experiments:
>>  - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
>>    A SID readout shell script via FEL with register access.
>>  - https://31.135.195.151:20281/d/efuse/
>>    A SID readout program via /dev/mem with register access by KotCzarny.
>>    (with statically compiled binary)
>
> Good detective work!
>
> I believe this would best be fixed by making u-boot use the register access
> method to get the SID on affected chips, and make sure u-boot reads the
> SID at-least once.

Yes.

However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.

Maybe we should add #ifdef's to MAC generation code after this fix.

(This is why I will create this discussion)

P.S. Are you still the

Re: [U-Boot] Problems to Allwinner H3's eFUSE/SID

2016-12-19 Thread Hans de Goede

Hi,

On 19-12-16 16:22, Icenowy Zheng wrote:

Hi everyone,

Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
controller of H3 (incl. H2+).

See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
directly access 0x01c14200.

From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
legacy kernel).

According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
0x58 is H3D (currently not known SoC) )

However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
with 0x02004620, which do not match this rule.

The readout by devmem2 is satisfying this rule: their first word is
0x02c00081, matches H3.

With direct access to 0x01c14200 after boot with mainline kernel, I got also
"02004620".

Then I altered the program to do the register operations with sunxi-fel, the
result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".

Summary:

+---++
| Read situation| The first word |
+---++
| Direct read by sunxi-fel | 02004620 |
| Direct read in mainline /dev/mem | 02004620 |
| Direct read in legacy /dev/mem| 02c00081 |
| Register access in FEL| 02c00081 |
| Register access in mainline | 02c00081 |
| Direct read after register access in FEL | 02c00081 |
| Direct read after register access in mainline | 02c00081 |
+---++

This raises a problem: currently many systems has used the misread SID value to
generated lots of MAC addresses, and workaround this SID bug will change them.

And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
think sunxi-fel must have the workaround)

Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

Furthermore, A83T may also have this problem, testers are welcome!

Good detective work!

I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.

Can you write a patch for this ?

Regards,

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

[U-Boot] [PATCH 7/7] arm64: mvebu: Add default configuraton for MACCHIATOBin board

From: Konstantin Porotchkin 

Add default configuration for MACHHIATOBin community board
based on Aramda-8040 SoC.

Change-Id: I60efcca5b31060340ad0a948561f082646f6556c
Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
 configs/mvebu_mcbin-88f8040_defconfig | 65 +++
 1 file changed, 65 insertions(+)
 create mode 100644 configs/mvebu_mcbin-88f8040_defconfig

diff --git a/configs/mvebu_mcbin-88f8040_defconfig 
b/configs/mvebu_mcbin-88f8040_defconfig
new file mode 100644
index 000..ed6e9db
--- /dev/null
+++ b/configs/mvebu_mcbin-88f8040_defconfig
@@ -0,0 +1,65 @@
+CONFIG_ARM=y
+CONFIG_ARCH_MVEBU=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_TARGET_MVEBU_ARMADA_8K=y
+CONFIG_DEFAULT_DEVICE_TREE="armada-8040-mcbin"
+CONFIG_SMBIOS_PRODUCT_NAME=""
+CONFIG_AHCI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_MVEBU_BUBT=y
+CONFIG_BLOCK_CACHE=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_MVTWSI=y
+CONFIG_DM_GPIO=y
+CONFIG_MVEBU_GPIO=y
+CONFIG_MISC=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_PCIE_DW_MVEBU=y
+CONFIG_MVEBU_COMPHY_SUPPORT=y
+# CONFIG_SPL_SERIAL_PRESENT is not set
+CONFIG_DEBUG_UART=y
+CONFIG_DEBUG_UART_BASE=0xf0512000
+CONFIG_DEBUG_UART_CLOCK=2
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_SYS_NS16550=y
+CONFIG_USB=y
+CONFIG_DM_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_DM_MMC=y
+CONFIG_XENON_SDHCI=y
+CONFIG_SMBIOS_MANUFACTURER=""
+CONFIG_PINCTRL=y
+CONFIG_HUSH_PARSER=y
-- 
2.7.4

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

[U-Boot] [PATCH 4/7] mvebu: usb: xhci: Add support for VBUS controlled by GPIO

From: Konstantin Porotchkin 

Add support for "marvell,vbus-gpio" property to mvebu XHCI
board init function.
This option is valid when CONFIG_DM_GPIO=y

Change-Id: I930b3ebe001e50ae8d5abe1f3c774bcdb1739e64
Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
 board/Marvell/mvebu_armada-8k/board.c | 32 ---
 board/Marvell/mvebu_db-88f3720/board.c|  2 +-
 doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29 
 drivers/usb/host/xhci-mvebu.c |  5 ++--
 4 files changed, 55 insertions(+), 13 deletions(-)
 create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt

diff --git a/board/Marvell/mvebu_armada-8k/board.c 
b/board/Marvell/mvebu_armada-8k/board.c
index 7d1b5d9..aa6a6d7 100644
--- a/board/Marvell/mvebu_armada-8k/board.c
+++ b/board/Marvell/mvebu_armada-8k/board.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -95,19 +96,23 @@ int board_xhci_config(void)
return 0;
 }
 
-int board_xhci_enable(void)
+int board_xhci_enable(struct udevice *usb_dev)
 {
struct udevice *dev;
+#ifdef CONFIG_DM_GPIO
+   struct gpio_desc vbus_gpio;
+#endif
int ret;
u8 buf[8];
 
+   /*
+* This function enables all USB ports simultaniously,
+* it only needs to get called once
+*/
+   if (usb_enabled)
+   return 0;
+
if (of_machine_is_compatible("marvell,armada7040-db")) {
-   /*
-* This function enables all USB ports simultaniously,
-* it only needs to get called once
-*/
-   if (usb_enabled)
-   return 0;
 
/* Configure IO exander PCA9555: 7bit address 0x21 */
ret = i2c_get_chip_for_busnum(0, I2C_IO_EXP_ADDR, 1, );
@@ -131,10 +136,19 @@ int board_xhci_enable(void)
return -EIO;
}
 
-   mdelay(500); /* required delay to let output value settle */
-   usb_enabled = 1;
}
 
+#ifdef CONFIG_DM_GPIO
+   gpio_request_by_name(usb_dev, "marvell,vbus-gpio", 0,
+_gpio, GPIOD_IS_OUT);
+
+   if (dm_gpio_is_valid(_gpio))
+   dm_gpio_set_value(_gpio, 1);
+#endif
+
+   mdelay(500); /* required delay to let output value settle */
+   usb_enabled = 1;
+
return 0;
 }
 
diff --git a/board/Marvell/mvebu_db-88f3720/board.c 
b/board/Marvell/mvebu_db-88f3720/board.c
index edf88c7..75679ff 100644
--- a/board/Marvell/mvebu_db-88f3720/board.c
+++ b/board/Marvell/mvebu_db-88f3720/board.c
@@ -69,7 +69,7 @@ int board_ahci_enable(void)
 }
 
 /* Board specific xHCI enable code */
-int board_xhci_enable(void)
+int board_xhci_enable(struct udevice *usb_dev)
 {
struct udevice *dev;
int ret;
diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt 
b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
new file mode 100644
index 000..b0a53ad
--- /dev/null
+++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt
@@ -0,0 +1,29 @@
+Marvell SOC USB controllers
+
+This controller is integrated in Armada 3700/8K.
+It uses the same properties as a generic XHCI host controller
+
+Required properties :
+ - compatible: should be one or more of:
+   - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs
+   - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs
+ - reg: should contain address and length of the standard XHCI
+register set for the device.
+ - interrupts: one XHCI interrupt should be described here.
+
+Optional properties:
+ - clocks: reference to a clock
+ - marvell,vbus-gpio : If present, specifies a gpio that needs to be
+   activated for the bus to be powered.
+
+Example:
+   cpm_usb3_0: usb3@50 {
+   compatible = "marvell,armada-8k-xhci",
+"generic-xhci";
+   reg = <0x50 0x4000>;
+   interrupts = ;
+   clocks = <_syscon0 1 22>;
+   marvell,vbus-gpio = <_gpio1 15 GPIO_ACTIVE_HIGH>;
+   status = "disabled";
+   };
+
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
index 46eb937..843a51b 100644
--- a/drivers/usb/host/xhci-mvebu.c
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "xhci.h"
 
@@ -34,7 +33,7 @@ struct mvebu_xhci {
  * Dummy implementation that can be overwritten by a board
  * specific function
  */
-__weak int board_xhci_enable(void)
+__weak int board_xhci_enable(struct udevice *usb_dev)
 {
return 0;
 }
@@ -51,7 +50,7 @@ static int

[U-Boot] [PATCH 3/7] arm64: mvebu: dts: Add i2c1 pin definitions to CPM

From: Konstantin Porotchkin 

Add i2c-1 pin mappings to CP0(master) DTSI file

Change-Id: I0c6e6de8a557393f518f7df8e6daa6dfce1788b0
Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
 arch/arm/dts/armada-cp110-master.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/armada-cp110-master.dtsi 
b/arch/arm/dts/armada-cp110-master.dtsi
index a3e922d..3776e4e 100644
--- a/arch/arm/dts/armada-cp110-master.dtsi
+++ b/arch/arm/dts/armada-cp110-master.dtsi
@@ -94,6 +94,10 @@
marvell,pins = < 37 38 >;
marvell,function = <2>;
};
+   cpm_i2c1_pins: cpm-i2c-pins-1 {
+   marvell,pins = < 35 36 >;
+   marvell,function = <2>;
+   };
cpm_ge2_rgmii_pins: cpm-ge-rgmii-pins-0 {
marvell,pins = < 44 45 46 47 48 49 50 51
 52 53 54 55 >;
-- 
2.7.4

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

[U-Boot] [PATCH 2/7] arm64: mvebu: gpio: Add GPIO nodes to A8K family devices

From: Konstantin Porotchkin 

Add GPIO nodes to AP-806 and CP-110-master DTSI files.

Change-Id: I05958698d460cb721b7d8683d34f74a5ea32532c
Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
 arch/arm/dts/armada-7040.dtsi |  1 +
 arch/arm/dts/armada-8040.dtsi |  1 +
 arch/arm/dts/armada-ap806.dtsi|  8 
 arch/arm/dts/armada-cp110-master.dtsi | 18 ++
 arch/arm/dts/armada-cp110-slave.dtsi  | 18 ++
 5 files changed, 46 insertions(+)

diff --git a/arch/arm/dts/armada-7040.dtsi b/arch/arm/dts/armada-7040.dtsi
index 78d995d..b5be0c4 100644
--- a/arch/arm/dts/armada-7040.dtsi
+++ b/arch/arm/dts/armada-7040.dtsi
@@ -45,6 +45,7 @@
  * one CP110.
  */
 
+#include 
 #include "armada-ap806-quad.dtsi"
 #include "armada-cp110-master.dtsi"
 
diff --git a/arch/arm/dts/armada-8040.dtsi b/arch/arm/dts/armada-8040.dtsi
index 9c1b28c..96cc112 100644
--- a/arch/arm/dts/armada-8040.dtsi
+++ b/arch/arm/dts/armada-8040.dtsi
@@ -45,6 +45,7 @@
  * two CP110.
  */
 
+#include 
 #include "armada-ap806-quad.dtsi"
 #include "armada-cp110-master.dtsi"
 #include "armada-cp110-slave.dtsi"
diff --git a/arch/arm/dts/armada-ap806.dtsi b/arch/arm/dts/armada-ap806.dtsi
index b6d31af..d86e5dd 100644
--- a/arch/arm/dts/armada-ap806.dtsi
+++ b/arch/arm/dts/armada-ap806.dtsi
@@ -158,6 +158,14 @@
};
};
 
+   ap_gpio0: gpio@6F5040 {
+   compatible = "marvell,orion-gpio";
+   reg = <0x6F5040 0x40>;
+   ngpios = <20>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
xor@40 {
compatible = "marvell,mv-xor-v2";
reg = <0x40 0x1000>,
diff --git a/arch/arm/dts/armada-cp110-master.dtsi 
b/arch/arm/dts/armada-cp110-master.dtsi
index d637867..a3e922d 100644
--- a/arch/arm/dts/armada-cp110-master.dtsi
+++ b/arch/arm/dts/armada-cp110-master.dtsi
@@ -113,6 +113,24 @@
};
};
 
+   cpm_gpio0: gpio@440100 {
+   compatible = "marvell,orion-gpio";
+   reg = <0x440100 0x40>;
+   ngpios = <32>;
+   gpiobase = <20>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   cpm_gpio1: gpio@440140 {
+   compatible = "marvell,orion-gpio";
+   reg = <0x440140 0x40>;
+   ngpios = <31>;
+   gpiobase = <52>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
cpm_sata0: sata@54 {
compatible = "marvell,armada-8k-ahci";
reg = <0x54 0x3>;
diff --git a/arch/arm/dts/armada-cp110-slave.dtsi 
b/arch/arm/dts/armada-cp110-slave.dtsi
index 92ef55c..ff3fbed 100644
--- a/arch/arm/dts/armada-cp110-slave.dtsi
+++ b/arch/arm/dts/armada-cp110-slave.dtsi
@@ -100,6 +100,24 @@
};
};
 
+   cps_gpio0: gpio@440100 {
+   compatible = "marvell,orion-gpio";
+   reg = <0x440100 0x40>;
+   ngpios = <32>;
+   gpiobase = <20>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   cps_gpio1: gpio@440140 {
+   compatible = "marvell,orion-gpio";
+   reg = <0x440140 0x40>;
+   ngpios = <31>;
+   gpiobase = <52>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
cps_sata0: sata@54 {
compatible = "marvell,armada-8k-ahci";
reg = <0x54 0x3>;
-- 
2.7.4

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

[U-Boot] [PATCH 5/7] mvebu: pcie: Add support for GPIO reset for PCIe device

From: Konstantin Porotchkin 

Add board init hook to mvebu DW PCIe device driver.
Add support for "marvell,reset-gpio" property to A8K
board init function.
This option is valid when CONFIG_DM_GPIO=y

Change-Id: Ic17c500449050c2fbb700731f1a9ca8b83298986
Signed-off-by: Konstantin Porotchkin 
Signed-off-by: Rabeeh Khoury 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
 board/Marvell/mvebu_armada-8k/board.c  | 22 
 doc/device-tree-bindings/pci/armada8k-pcie.txt | 49 ++
 drivers/pci/pcie_dw_mvebu.c| 11 ++
 3 files changed, 82 insertions(+)
 create mode 100644 doc/device-tree-bindings/pci/armada8k-pcie.txt

diff --git a/board/Marvell/mvebu_armada-8k/board.c 
b/board/Marvell/mvebu_armada-8k/board.c
index aa6a6d7..7fca8ed 100644
--- a/board/Marvell/mvebu_armada-8k/board.c
+++ b/board/Marvell/mvebu_armada-8k/board.c
@@ -152,6 +152,28 @@ int board_xhci_enable(struct udevice *usb_dev)
return 0;
 }
 
+int board_pcie_init(struct udevice *pcie_dev)
+{
+#ifdef CONFIG_DM_GPIO
+   struct gpio_desc reset_gpio;
+
+   gpio_request_by_name(pcie_dev, "marvell,reset-gpio", 0,
+_gpio, GPIOD_IS_OUT);
+   /*
+* Issue reset to add-in card trough the dedicated GPIO.
+* Some boards are connecting the card reset pin to common
+* system reset wire and others are using separate GPIO port.
+* In the last case we have to release a reset of the addon
+* card using this GPIO.
+*/
+   if (dm_gpio_is_valid(_gpio)) {
+   dm_gpio_set_value(_gpio, 1);
+   mdelay(100);
+   }
+#endif /* CONFIG_DM_GPIO */
+   return 0;
+}
+
 int board_early_init_f(void)
 {
/* Nothing to do (yet), perhaps later some pin-muxing etc */
diff --git a/doc/device-tree-bindings/pci/armada8k-pcie.txt 
b/doc/device-tree-bindings/pci/armada8k-pcie.txt
new file mode 100644
index 000..7230f10
--- /dev/null
+++ b/doc/device-tree-bindings/pci/armada8k-pcie.txt
@@ -0,0 +1,49 @@
+Armada-8K PCIe DT details:
+==
+
+Armada-8k uses synopsis designware PCIe controller.
+
+Required properties:
+- compatible : should be "marvell,armada8k-pcie", "snps,dw-pcie".
+- reg: base addresses and lengths of the pcie control and global control 
registers.
+ "ctrl" registers points to the global control registers, while the "config" 
space
+ points to the pcie configuration registers as mentioned in dw-pcie dt 
bindings in the link below.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+  define the mapping of the PCIe interface to interrupt numbers.
+- All other definitions as per generic PCI bindings
+See Linux kernel documentation:
+"Documentation/devicetree/bindings/pci/designware-pcie.txt"
+
+Optional properties:
+PHY support is still not supported for armada-8k, once it will, the following 
parameters can be used:
+- phys : phandle to phy node associated with pcie controller.
+- phy-names: must be "pcie-phy"
+- marvell,reset-gpio :  specifies a gpio that needs to be activated for plug-in
+   card reset signal release.
+Example:
+
+cpm_pcie0: pcie@f260 {
+   compatible = "marvell,armada8k-pcie", "snps,dw-pcie";
+   reg = <0 0xf260 0 0x1>,
+ <0 0xf6f0 0 0x8>;
+   reg-names = "ctrl", "config";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   device_type = "pci";
+   dma-coherent;
+
+   bus-range = <0 0xff>;
+   ranges =
+   /* downstream I/O */
+   <0x8100 0 0xf900 0  0xf900 0 0x1
+   /* non-prefetchable memory */
+   0x8200 0 0xf600 0  0xf600 0 0xf0>;
+   interrupt-map-mask = <0 0 0 0>;
+   interrupt-map = <0 0 0 0  0 GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+   interrupts = ;
+   num-lanes = <1>;
+   clocks = <_syscon0 1 13>;
+   marvell,reset-gpio = <_gpio1 20 GPIO_ACTIVE_HIGH>;
+   status = "disabled";
+};
diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c
index 17fa024..26451b8 100644
--- a/drivers/pci/pcie_dw_mvebu.c
+++ b/drivers/pci/pcie_dw_mvebu.c
@@ -112,6 +112,15 @@ struct pcie_dw_mvebu {
int first_busno;
 };
 
+/*
+ * Dummy implementation that can be overwritten by a board
+ * specific function
+ */
+__weak int board_pcie_init(struct udevice *pcie_dev)
+{
+   return 0;
+}
+
 static int pcie_dw_get_link_speed(const void *regs_base)
 {
return (readl(regs_base + PCIE_LINK_STATUS_REG) &
@@ -464,6 +473,8 @@ static int pcie_dw_mvebu_probe(struct udevice *dev)
 
pcie->first_busno =

[U-Boot] [PATCH 6/7] arm64: mvebu: dts: Add DTS file for MACCHIATOBin board

From: Rabeeh Khoury 

Added A8040 dts file for community board MACCHIATIBin.
The patch includes the following features:
AP -  eMMC, Serial console (connected to onboard FTDI usb to serial)
CP0 - PCIe x4, SATA, I2C and 10G KR
  (connected to Marvell 3310 10G copper / SFP+ phy)
CP1 - Boot SPI, USB3 host, 2xSATA, 10G KR
  (connected to Marvell 3310 10G copper / SFP+ phy),
  SGMII connected to onboard 1512 1Gbps copper phy,
  and additional SGMII connected to SFP
  (default 1Gbps can be configured to 2.5Gbps).

Network interface naming -
egiga0 - CP0 KR
egiga1 - CP1 KR
egiga2 - CP1 RJ45 1Gbps connector (recommended for TFTP boot)
egiga3 - CP1 SFP default 1Gbps and can be modified to 2.5Gbps

Change-Id: Icb844eff9a8f07cd76ca8f86ffb01fe297bde836
Signed-off-by: Konstantin Porotchkin 
Signed-off-by: Rabeeh Khoury 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/armada-8040-mcbin.dts | 253 +
 2 files changed, 254 insertions(+)
 create mode 100644 arch/arm/dts/armada-8040-mcbin.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ff78385..10e0536 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -76,6 +76,7 @@ dtb-$(CONFIG_ARCH_MVEBU) +=   \
armada-385-amc.dtb  \
armada-7040-db.dtb  \
armada-8040-db.dtb  \
+   armada-8040-mcbin.dtb   \
armada-xp-gp.dtb\
armada-xp-maxbcm.dtb\
armada-xp-synology-ds414.dtb\
diff --git a/arch/arm/dts/armada-8040-mcbin.dts 
b/arch/arm/dts/armada-8040-mcbin.dts
new file mode 100644
index 000..682e6f7
--- /dev/null
+++ b/arch/arm/dts/armada-8040-mcbin.dts
@@ -0,0 +1,253 @@
+/*
+ * Copyright (C) 2016 Marvell International Ltd.
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ * https://spdx.org/licenses
+ */
+
+#include "armada-8040.dtsi" /* include SoC device tree */
+
+/ {
+   model = "MACCHIATOBin-8040";
+   compatible = "marvell,armada8040-mcbin",
+"marvell,armada8040";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   i2c0 = _i2c0;
+   i2c1 = _i2c1;
+   spi0 = _spi1;
+   gpio0 = _gpio0;
+   gpio1 = _gpio0;
+   gpio2 = _gpio1;
+   };
+
+   memory@ {
+   device_type = "memory";
+   reg = <0x0 0x0 0x0 0x8000>;
+   };
+};
+
+/* Accessible over the mini-USB CON9 connector on the main board */
+ {
+   status = "okay";
+};
+
+_pinctl {
+   /*
+* MPP Bus:
+* eMMC [0-10]
+* UART0 [11,19]
+*/
+ /* 0 1 2 3 4 5 6 7 8 9 */
+   pin-func = < 1 1 1 1 1 1 1 1 1 1
+1 3 0 0 0 0 0 0 0 3 >;
+};
+
+/* on-board eMMC */
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_emmc_pins>;
+   bus-width= <8>;
+   status = "okay";
+};
+
+_pinctl {
+   /*
+* MPP Bus:
+* [0-31] = 0xff: Keep default CP0_shared_pins:
+* [11] CLKOUT_MPP_11 (out)
+* [23] LINK_RD_IN_CP2CP (in)
+* [25] CLKOUT_MPP_25 (out)
+* [29] AVS_FB_IN_CP2CP (in)
+* [32,34] SMI
+* [33]MSS power down
+* [35-38] CP0 I2C1 and I2C0
+* [39] MSS CKE Enable
+* [40,41] CP0 UART1 TX/RX
+* [42,43] XSMI (controls two 10G phys)
+* [47] USB VBUS EN
+* [48] FAN PWM
+* [49] 10G port 1 interrupt
+* [50] 10G port 0 interrupt
+* [51] 2.5G SFP TX fault
+* [52] PCIe reset out
+* [53] 2.5G SFP mode
+* [54] 2.5G SFP LOS
+* [55] Micro SD card detect
+* [56-61] Micro SD
+* [62] CP1 KR SFP FAULT
+*/
+   /*   0123456789 */
+   pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
+0xff 070xa  722220xa
+7788000000
+0090000xe  0xe  0xe  0xe
+0xe  0xe  0 >;
+};
+
+/* PCIe x4 */
+_pcie0 {
+   num-lanes = <4>;
+   marvell,reset-gpio = <_gpio1 20 GPIO_ACTIVE_HIGH>; /* GPIO[52] */
+   status = "okay";
+};
+
+_i2c0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0_pins>;
+   status = "okay";
+   clock-frequency = <10>;
+};
+

[U-Boot] [PATCH 1/7] arm64: mvebu: Update bubt command MMC block device access

From: Konstantin Porotchkin 

Update the MMC block device access code in bubt command
implementation according to the latest MMC driver changes

Change-Id: Ie852ceefa0b040ffe1362bdb7815fcea9b2d923b
Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
 cmd/mvebu/bubt.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 1cbfcf0..0ac2e63 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -111,6 +112,7 @@ static ulong get_load_addr(void)
 static int mmc_burn_image(size_t image_size)
 {
struct mmc  *mmc;
+   struct blk_desc *blk_desc;
lbaint_tstart_lba;
lbaint_tblk_count;
ulong   blk_written;
@@ -144,13 +146,18 @@ static int mmc_burn_image(size_t image_size)
 * MMC/eMMC boots from LBA-0
 */
start_lba = IS_SD(mmc) ? 1 : 0;
-   blk_count = image_size / mmc->block_dev.blksz;
-   if (image_size % mmc->block_dev.blksz)
+   blk_count = image_size / mmc->write_bl_len;
+   if (image_size % mmc->write_bl_len)
blk_count += 1;
 
-   blk_written = mmc->block_dev.block_write(mmc_dev_num,
-   start_lba, blk_count,
-   (void *)get_load_addr());
+   blk_desc = mmc_get_blk_desc(mmc);
+   if (!blk_desc) {
+   printf("Error - failed to obtain block descriptor\n");
+   return -ENODEV;
+   }
+   blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
+(void *)get_load_addr());
+
if (blk_written != blk_count) {
printf("Error - written %#lx blocks\n", blk_written);
return -ENOSPC;
-- 
2.7.4

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

[U-Boot] [PATCH 0/7] arm64: mvebu: Add support for A8K community board

From: Konstantin Porotchkin 

This patch series adds initil support for A8K community board
MACCHIATOBin manufactured by SolidRun.
It should be applied on top of Stefan Roese patches adding support
for SD/eMMC devices on Marvell A37x0/A80x0/A70x0 SoCs.
The top level patch is called:
"arm64: mvebu: Enable SDHCI/MMC support for the db-88f7040/8040"
The default board DTS file is based on the original work of Rabeeh
Khory from SolidRun.

Konstantin Porotchkin (6):
  arm64: mvebu: Update bubt command MMC block device access
  arm64: mvebu: gpio: Add GPIO nodes to A8K family devices
  arm64: mvebu: dts: Add i2c1 pin definitions to CPM
  mvebu: usb: xhci: Add support for VBUS controlled by GPIO
  mvebu: pcie: Add support for GPIO reset for PCIe device
  arm64: mvebu: Add default configuraton for MACCHIATOBin board

Rabeeh Khoury (1):
  arm64: mvebu: dts: Add DTS file for MACCHIATOBin board

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/armada-7040.dtsi |   1 +
 arch/arm/dts/armada-8040-mcbin.dts| 253 ++
 arch/arm/dts/armada-8040.dtsi |   1 +
 arch/arm/dts/armada-ap806.dtsi|   8 +
 arch/arm/dts/armada-cp110-master.dtsi |  22 ++
 arch/arm/dts/armada-cp110-slave.dtsi  |  18 ++
 board/Marvell/mvebu_armada-8k/board.c |  54 -
 board/Marvell/mvebu_db-88f3720/board.c|   2 +-
 cmd/mvebu/bubt.c  |  17 +-
 configs/mvebu_mcbin-88f8040_defconfig |  65 ++
 doc/device-tree-bindings/pci/armada8k-pcie.txt|  49 +
 doc/device-tree-bindings/usb/marvell.xhci-usb.txt |  29 +++
 drivers/pci/pcie_dw_mvebu.c   |  11 +
 drivers/usb/host/xhci-mvebu.c |   5 +-
 15 files changed, 518 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm/dts/armada-8040-mcbin.dts
 create mode 100644 configs/mvebu_mcbin-88f8040_defconfig
 create mode 100644 doc/device-tree-bindings/pci/armada8k-pcie.txt
 create mode 100644 doc/device-tree-bindings/usb/marvell.xhci-usb.txt

-- 
2.7.4

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

[U-Boot] [PATCH v2] arm64: mvebu: Fix A8K memory mapping and add documentation

From: Konstantin Porotchkin 

Fix the MMU mapping for A8K device family:
 - Separate A7K and A8K memory mappings
 - Fix memory regions by including IO mapping for all
   3 PCIe interfaces existing on each connected CP110 controller
Add A8K memory mapping documentation with all regions
configured by Marvell ATF.

Change-Id: I9c930569b1853900f5fba2d5db319b092cc7a2a6
Signed-off-by: Konstantin Porotchkin 
Signed-off-by: Stefan Roese 
Cc: Stefan Roese 
Cc: Nadav Haklai 
Cc: Neta Zur Hershkovits 
Cc: Omri Itach 
Cc: Igal Liberman 
Cc: Haim Boot 
Cc: Hanna Hawa 
---
Changes for v2:
- Exclude CP1 memory regions from A7K MMU map
- Dynamically adjust the MMU regions list according to the platform type

 arch/arm/mach-mvebu/armada8k/cpu.c | 58 +-
 doc/mvebu/armada-8k-memory.txt | 56 
 2 files changed, 101 insertions(+), 13 deletions(-)
 create mode 100644 doc/mvebu/armada-8k-memory.txt

diff --git a/arch/arm/mach-mvebu/armada8k/cpu.c 
b/arch/arm/mach-mvebu/armada8k/cpu.c
index 2719d68..2325e9a 100644
--- a/arch/arm/mach-mvebu/armada8k/cpu.c
+++ b/arch/arm/mach-mvebu/armada8k/cpu.c
@@ -21,7 +21,33 @@ DECLARE_GLOBAL_DATA_PTR;
 #define RFU_GLOBAL_SW_RST  (MVEBU_RFU_BASE + 0x84)
 #define RFU_SW_RESET_OFFSET0
 
+/*
+ * The following table includes all memory regions for Armada 7k and
+ * 8k SoCs. The Armada 7k is missing the CP110 slave regions here. Lets
+ * define these regions at the beginning of the struct so that they
+ * can be easier removed later dynamically if an Armada 7k device is detected.
+ * For a detailed memory map, please see doc/mvebu/armada-8k-memory.txt
+ */
+#define ARMADA_7K8K_COMMON_REGIONS_START   2
 static struct mm_region mvebu_mem_map[] = {
+   /* Armada 80x0 memory regions include the CP1 (slave) units */
+   {
+   /* SRAM, MMIO regions - CP110 slave region */
+   .phys = 0xf400UL,
+   .virt = 0xf400UL,
+   .size = 0x0200UL,   /* 32MiB internal registers */
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE
+   },
+   {
+   /* PCI CP1 regions */
+   .phys = 0xfa00UL,
+   .virt = 0xfa00UL,
+   .size = 0x0400UL,   /* 64MiB CP110 slave PCI space */
+   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE
+   },
+   /* Armada 80x0 and 70x0 common memory regions start here */
{
/* RAM */
.phys = 0x0UL,
@@ -47,29 +73,35 @@ static struct mm_region mvebu_mem_map[] = {
 PTE_BLOCK_NON_SHARE
},
{
-   /* SRAM, MMIO regions - CP110 slave region */
-   .phys = 0xf400UL,
-   .virt = 0xf400UL,
-   .size = 0x0200UL,   /* 32MiB internal registers */
+   /* PCI CP0 regions */
+   .phys = 0xf600UL,
+   .virt = 0xf600UL,
+   .size = 0x0400UL,   /* 64MiB CP110 master PCI space */
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE
},
{
-   /* PCI regions */
-   .phys = 0xf800UL,
-   .virt = 0xf800UL,
-   .size = 0x0800UL,   /* 128MiB PCI space (master & slave) */
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE
-   },
-   {
-   /* List terminator */
0,
}
 };
 
 struct mm_region *mem_map = mvebu_mem_map;
 
+void enable_caches(void)
+{
+   /*
+* Armada 7k is not equipped with the CP110 slave CP. In case this
+* code runs on an Armada 7k device, lets remove the CP110 slave
+* entries from the memory mapping by moving the start to the
+* common regions.
+*/
+   if (of_machine_is_compatible("marvell,armada7040"))
+   mem_map = _mem_map[ARMADA_7K8K_COMMON_REGIONS_START];
+
+   icache_enable();
+   dcache_enable();
+}
+
 void reset_cpu(ulong ignored)
 {
u32 reg;
diff --git a/doc/mvebu/armada-8k-memory.txt b/doc/mvebu/armada-8k-memory.txt
new file mode 100644
index 000..064518e
--- /dev/null
+++ b/doc/mvebu/armada-8k-memory.txt
@@ -0,0 +1,56 @@
+Memory Layout on Armada-8k SoC's
+
+
+The below desribes the physical memory layout for Marvell's Armada-8k SoC's.
+
+This assumes that the SoC includes Dual CP configuration, in case the flavor 
is using
+a single CP configuration, then all secondary-CP mappings are invalid.
+

[U-Boot] [PATCH 2/4] pci: kconfig: fix spelling in description

From: Marcel Ziswiler 

Fix 'driver model' rather than 'driver mode' in description.

Signed-off-by: Marcel Ziswiler 
---

 drivers/pci/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index ff2c370..275b29b 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -9,7 +9,7 @@ menuconfig PCI
 if PCI
 
 config DM_PCI
-   bool "Enable driver mode for PCI"
+   bool "Enable driver model for PCI"
depends on DM
help
  Use driver model for PCI. Driver model is the new method for
-- 
2.9.3

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

[U-Boot] [PATCH 3/4] apalis_t30: comment about disabled pcie nodes

From: Marcel Ziswiler 

Add a comment about the disabled PCIe port nodes.

Signed-off-by: Marcel Ziswiler 
---

 arch/arm/dts/tegra30-apalis.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/tegra30-apalis.dts b/arch/arm/dts/tegra30-apalis.dts
index f83f094..9e4ab8c 100644
--- a/arch/arm/dts/tegra30-apalis.dts
+++ b/arch/arm/dts/tegra30-apalis.dts
@@ -44,10 +44,12 @@
hvdd-pex-supply = <_3v3_reg>;
 
pci@1,0 {
+   /* TS_DIFF1/2/3/4 left disabled */
nvidia,num-lanes = <4>;
};
 
pci@2,0 {
+   /* PCIE1_RX/TX left disabled */
nvidia,num-lanes = <1>;
};
 
-- 
2.9.3

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

[U-Boot] [PATCH 0/4] arm: tegra: colibri_t20: ulpi reset polarity fix & various other patches

From: Marcel Ziswiler 


This series contains two spelling fixes, some added comments as well as
the Toradex Colibri T20 ULPI reset polarity fix.

The whole series is also available here:

http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next


Marcel Ziswiler (4):
  video: tegra: fix spelling in comment
  pci: kconfig: fix spelling in description
  apalis_t30: comment about disabled pcie nodes
  colibri_t20: fix ulpi reset polarity

 arch/arm/dts/tegra20-colibri.dts | 6 --
 arch/arm/dts/tegra30-apalis.dts  | 2 ++
 drivers/pci/Kconfig  | 2 +-
 drivers/video/tegra124/display.c | 2 +-
 4 files changed, 8 insertions(+), 4 deletions(-)

-- 
2.9.3

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

[U-Boot] [PATCH 4/4] colibri_t20: fix ulpi reset polarity

From: Marcel Ziswiler 

Fix ULPI reset polarity which caused a hard hang on Colibri T20 upon
attempting to start the USB subsystem:

This fixes my late commit d5a24d8b53d350364bd429b7104ec369b817e4b8
(colibri_t20: fix usb operation and controller order) inadvertently
having overwritten Stephen's previous commit
2f6a7e8ce5df8b99d84bfd486c6f99d92322ce04 (ARM: tegra: fix USB ULPI PHY
reset signal inversion confusion).

While at it also fix comment about on-module USB port.

Signed-off-by: Marcel Ziswiler 

---

 arch/arm/dts/tegra20-colibri.dts | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/tegra20-colibri.dts b/arch/arm/dts/tegra20-colibri.dts
index 89adfb6..3c10dd6 100644
--- a/arch/arm/dts/tegra20-colibri.dts
+++ b/arch/arm/dts/tegra20-colibri.dts
@@ -16,7 +16,7 @@
i2c2 = "/i2c@7000c400";
mmc0 = "/sdhci@c8000600";
usb0 = "/usb@c500";
-   usb1 = "/usb@c5004000"; /* on-module only, for ASIX */
+   usb1 = "/usb@c5004000"; /* On-module only, for ASIX */
usb2 = "/usb@c5008000";
};
 
@@ -92,8 +92,10 @@
/* EHCI instance 1: ULPI -> USB3340 -> AX88772B */
usb@c5004000 {
status = "okay";
+   /* ULPI_RESET */
+   nvidia,phy-reset-gpio =
+   < TEGRA_GPIO(V, 1) GPIO_ACTIVE_LOW>;
/* VBUS_LAN */
-   nvidia,phy-reset-gpio = < TEGRA_GPIO(V, 1) 
GPIO_ACTIVE_HIGH>;
nvidia,vbus-gpio = < TEGRA_GPIO(BB, 1) GPIO_ACTIVE_HIGH>;
};
 
-- 
2.9.3

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

[U-Boot] [PATCH v2 4/5] mmc: tegra: allow disabling external clock loopback

From: Marcel Ziswiler 

Introduce CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK to disable the external clock
loopback and use the internal one on SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0
register's SDMMC_SPARE1 bits being set to 0xfffd according to the TRM.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Simon Glass 

---

Changes in v2:
- Added Simon's reviewed-by.
- Added TODO(email) as suggested by Simon so it is clear this is
  temporary and will be moved to device tree controlled approach once
  proper kernel integration made it mainline.

 arch/arm/include/asm/arch-tegra/tegra_mmc.h |  2 ++
 drivers/mmc/Kconfig | 11 +++
 drivers/mmc/tegra_mmc.c | 16 
 3 files changed, 29 insertions(+)

diff --git a/arch/arm/include/asm/arch-tegra/tegra_mmc.h 
b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
index 64c848a..c40599a 100644
--- a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
+++ b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
@@ -108,6 +108,8 @@ struct tegra_mmc {
 #define TEGRA_MMC_CLKCON_SDCLK_FREQ_SEL_SHIFT  8
 #define TEGRA_MMC_CLKCON_SDCLK_FREQ_SEL_MASK   (0xff << 8)
 
+#define TEGRA_MMC_MISCON_ENABLE_EXT_LOOPBACK   (1 << 17)
+
 #define TEGRA_MMC_SWRST_SW_RESET_FOR_ALL   (1 << 0)
 #define TEGRA_MMC_SWRST_SW_RESET_FOR_CMD_LINE  (1 << 1)
 #define TEGRA_MMC_SWRST_SW_RESET_FOR_DAT_LINE  (1 << 2)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 18f0e97..6372876 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -116,4 +116,15 @@ config TEGRA_MMC
help
  This selects support for SDHCI on Tegra SoCs.
 
+config TEGRA124_MMC_DISABLE_EXT_LOOPBACK
+   bool "Disable external clock loopback"
+   depends on TEGRA_MMC && TEGRA124
+   help
+ Disable the external clock loopback and use the internal one on SDMMC3
+ as per the SDMMC_VENDOR_MISC_CNTRL_0 register's SDMMC_SPARE1 bits
+ being set to 0xfffd according to the TRM.
+
+ TODO(marcel.ziswi...@toradex.com): Move to device tree controlled
+ approach once proper kernel integration made it mainline.
+
 endmenu
diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
index 97b1154..839b15d 100644
--- a/drivers/mmc/tegra_mmc.c
+++ b/drivers/mmc/tegra_mmc.c
@@ -511,6 +511,22 @@ static int tegra_mmc_init(struct mmc *mmc)
 
tegra_mmc_reset(priv, mmc);
 
+#if defined(CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK)
+   /*
+* Disable the external clock loopback and use the internal one on
+* SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0 register's SDMMC_SPARE1
+* bits being set to 0xfffd according to the TRM.
+*
+* TODO(marcel.ziswi...@toradex.com): Move to device tree controlled
+* approach once proper kernel integration made it mainline.
+*/
+   if (priv->reg == (void *)0x700b0400) {
+   mask = readl(>reg->venmiscctl);
+   mask &= ~TEGRA_MMC_MISCON_ENABLE_EXT_LOOPBACK;
+   writel(mask, >reg->venmiscctl);
+   }
+#endif
+
priv->version = readw(>reg->hcver);
debug("host version = %x\n", priv->version);
 
-- 
2.9.3

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

[U-Boot] [PATCH v2 0/5] arm: tegra: apalis-tk1, mmc and ext clock loopback

From: Marcel Ziswiler 


This series adds support for the Toradex Apalis TK1 as well as moves
the CONFIG_TEGRA_MMC to Kconfig and introduces a new option to disable
the external clock loopback on SDMMC3.

The whole series is also available here:

http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v2:
- Added Simon's reviewed-by.
- Added TODO(email) as suggested by Simon so it is clear this is
  temporary and will be moved to device tree controlled approach once
  proper kernel integration made it mainline.

Marcel Ziswiler (5):
  arm: tegra: initial support for apalis tk1
  mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig
  mmc: tegra: move CONFIG_TEGRA_MMC from headers to defconfigs
  mmc: tegra: allow disabling external clock loopback
  apalis-tk1: disable external clock loopback on SDMMC3

 arch/arm/dts/Makefile  |1 +
 arch/arm/dts/tegra124-apalis.dts   | 2203 
 arch/arm/include/asm/arch-tegra/tegra_mmc.h|2 +
 arch/arm/mach-tegra/tegra124/Kconfig   |7 +
 board/toradex/apalis-tk1/Kconfig   |   30 +
 board/toradex/apalis-tk1/MAINTAINERS   |7 +
 board/toradex/apalis-tk1/Makefile  |5 +
 board/toradex/apalis-tk1/apalis-tk1.c  |  175 ++
 board/toradex/apalis-tk1/as3722_init.c |  117 ++
 board/toradex/apalis-tk1/as3722_init.h |   41 +
 .../toradex/apalis-tk1/pinmux-config-apalis-tk1.h  |  287 +++
 configs/apalis-tk1_defconfig   |   55 +
 configs/apalis_t30_defconfig   |1 +
 configs/beaver_defconfig   |1 +
 configs/cardhu_defconfig   |1 +
 configs/cei-tk1-som_defconfig  |1 +
 configs/colibri_t20_defconfig  |1 +
 configs/colibri_t30_defconfig  |1 +
 configs/dalmore_defconfig  |1 +
 configs/harmony_defconfig  |1 +
 configs/jetson-tk1_defconfig   |1 +
 configs/medcom-wide_defconfig  |1 +
 configs/nyan-big_defconfig |1 +
 configs/paz00_defconfig|1 +
 configs/plutux_defconfig   |1 +
 configs/seaboard_defconfig |1 +
 configs/tec-ng_defconfig   |1 +
 configs/tec_defconfig  |1 +
 configs/trimslice_defconfig|1 +
 configs/venice2_defconfig  |1 +
 configs/ventana_defconfig  |1 +
 configs/whistler_defconfig |1 +
 drivers/mmc/Kconfig|   17 +
 drivers/mmc/tegra_mmc.c|   16 +
 include/configs/apalis-tk1.h   |  180 ++
 include/configs/apalis_t30.h   |1 -
 include/configs/beaver.h   |1 -
 include/configs/cardhu.h   |1 -
 include/configs/cei-tk1-som.h  |1 -
 include/configs/colibri_t20.h  |1 -
 include/configs/colibri_t30.h  |1 -
 include/configs/dalmore.h  |1 -
 include/configs/e2220-1170.h   |1 -
 include/configs/harmony.h  |1 -
 include/configs/jetson-tk1.h   |1 -
 include/configs/medcom-wide.h  |1 -
 include/configs/nyan-big.h |1 -
 include/configs/p2371-.h   |1 -
 include/configs/p2371-2180.h   |1 -
 include/configs/p2571.h|1 -
 include/configs/p2771-.h   |1 -
 include/configs/paz00.h|1 -
 include/configs/plutux.h   |1 -
 include/configs/seaboard.h |1 -
 include/configs/tec-ng.h   |1 -
 include/configs/tec.h  |1 -
 include/configs/trimslice.h|1 -
 include/configs/venice2.h  |1 -
 include/configs/ventana.h  |1 -
 include/configs/whistler.h |1 -
 scripts/config_whitelist.txt   |1 -
 61 files changed, 3163 insertions(+), 26 deletions(-)
 create mode 100644 arch/arm/dts/tegra124-apalis.dts
 create mode 100644 board/toradex/apalis-tk1/Kconfig
 create mode 100644 board/toradex/apalis-tk1/MAINTAINERS
 create mode 100644 board/toradex/apalis-tk1/Makefile
 create mode 100644 board/toradex/apalis-tk1/apalis-tk1.c
 create mode 100644 board/toradex/apalis-tk1/as3722_init.c

[U-Boot] [PATCH 1/4] video: tegra: fix spelling in comment

From: Marcel Ziswiler 

Get rid of spurious 'are' in the comment.

Signed-off-by: Marcel Ziswiler 
---

 drivers/video/tegra124/display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/tegra124/display.c b/drivers/video/tegra124/display.c
index d8999c3..28db96c 100644
--- a/drivers/video/tegra124/display.c
+++ b/drivers/video/tegra124/display.c
@@ -343,7 +343,7 @@ static int display_init(struct udevice *dev, void *lcdbase,
 
/*
 * Before we probe the display device (eDP), tell it that this device
-* is are the source of the display data.
+* is the source of the display data.
 */
ret = uclass_find_first_device(UCLASS_DISPLAY, _dev);
if (ret) {
-- 
2.9.3

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

[U-Boot] [PATCH v2 3/5] mmc: tegra: move CONFIG_TEGRA_MMC from headers to defconfigs

From: Marcel Ziswiler 

Basically running the following script:

tools/moveconfig.py CONFIG_TEGRA_MMC

Note that I left the SPL specific handling in
include/configs/tegra-common-post.h unchanged.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Simon Glass 

---

Changes in v2:
- Added Simon's reviewed-by.

BTW: I will look at converting tegra to use CONFIG_BLK and
CONFIG_DM_MMC_OPS in a later separate step.

---
 configs/apalis-tk1_defconfig  | 1 +
 configs/apalis_t30_defconfig  | 1 +
 configs/beaver_defconfig  | 1 +
 configs/cardhu_defconfig  | 1 +
 configs/cei-tk1-som_defconfig | 1 +
 configs/colibri_t20_defconfig | 1 +
 configs/colibri_t30_defconfig | 1 +
 configs/dalmore_defconfig | 1 +
 configs/harmony_defconfig | 1 +
 configs/jetson-tk1_defconfig  | 1 +
 configs/medcom-wide_defconfig | 1 +
 configs/nyan-big_defconfig| 1 +
 configs/paz00_defconfig   | 1 +
 configs/plutux_defconfig  | 1 +
 configs/seaboard_defconfig| 1 +
 configs/tec-ng_defconfig  | 1 +
 configs/tec_defconfig | 1 +
 configs/trimslice_defconfig   | 1 +
 configs/venice2_defconfig | 1 +
 configs/ventana_defconfig | 1 +
 configs/whistler_defconfig| 1 +
 include/configs/apalis-tk1.h  | 1 -
 include/configs/apalis_t30.h  | 1 -
 include/configs/beaver.h  | 1 -
 include/configs/cardhu.h  | 1 -
 include/configs/cei-tk1-som.h | 1 -
 include/configs/colibri_t20.h | 1 -
 include/configs/colibri_t30.h | 1 -
 include/configs/dalmore.h | 1 -
 include/configs/e2220-1170.h  | 1 -
 include/configs/harmony.h | 1 -
 include/configs/jetson-tk1.h  | 1 -
 include/configs/medcom-wide.h | 1 -
 include/configs/nyan-big.h| 1 -
 include/configs/p2371-.h  | 1 -
 include/configs/p2371-2180.h  | 1 -
 include/configs/p2571.h   | 1 -
 include/configs/p2771-.h  | 1 -
 include/configs/paz00.h   | 1 -
 include/configs/plutux.h  | 1 -
 include/configs/seaboard.h| 1 -
 include/configs/tec-ng.h  | 1 -
 include/configs/tec.h | 1 -
 include/configs/trimslice.h   | 1 -
 include/configs/venice2.h | 1 -
 include/configs/ventana.h | 1 -
 include/configs/whistler.h| 1 -
 scripts/config_whitelist.txt  | 1 -
 48 files changed, 21 insertions(+), 27 deletions(-)

diff --git a/configs/apalis-tk1_defconfig b/configs/apalis-tk1_defconfig
index ae95f6b..c1caef1 100644
--- a/configs/apalis-tk1_defconfig
+++ b/configs/apalis-tk1_defconfig
@@ -36,6 +36,7 @@ CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_TEGRA_MMC=y
 CONFIG_E1000=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
diff --git a/configs/apalis_t30_defconfig b/configs/apalis_t30_defconfig
index 691148c..0822e2e 100644
--- a/configs/apalis_t30_defconfig
+++ b/configs/apalis_t30_defconfig
@@ -25,6 +25,7 @@ CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_TEGRA_MMC=y
 CONFIG_E1000=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
diff --git a/configs/beaver_defconfig b/configs/beaver_defconfig
index 5cb73c0..69c9ccd 100644
--- a/configs/beaver_defconfig
+++ b/configs/beaver_defconfig
@@ -28,6 +28,7 @@ CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_TEGRA_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_RTL8169=y
diff --git a/configs/cardhu_defconfig b/configs/cardhu_defconfig
index 0214758..e8e8b20 100644
--- a/configs/cardhu_defconfig
+++ b/configs/cardhu_defconfig
@@ -23,6 +23,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_SPL_DM=y
 # CONFIG_BLK is not set
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_TEGRA_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_RTL8169=y
diff --git a/configs/cei-tk1-som_defconfig b/configs/cei-tk1-som_defconfig
index 909b367..57b87c9 100644
--- a/configs/cei-tk1-som_defconfig
+++ b/configs/cei-tk1-som_defconfig
@@ -28,6 +28,7 @@ CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_TEGRA_MMC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_RTL8169=y
diff --git a/configs/colibri_t20_defconfig b/configs/colibri_t20_defconfig
index a543246..3a4dc31 100644
--- a/configs/colibri_t20_defconfig
+++ b/configs/colibri_t20_defconfig
@@ -28,6 +28,7 @@ CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_TEGRA_MMC=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_DM_PMIC=y
 CONFIG_DM_REGULATOR=y
diff --git a/configs/colibri_t30_defconfig b/configs/colibri_t30_defconfig
index 2ab6764..724a600 100644
--- a/configs/colibri_t30_defconfig
+++ b/configs/colibri_t30_defconfig
@@ -25,6 +25,7 @@ CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 # CONFIG_DM_MMC_OPS is not set
+CONFIG_TEGRA_MMC=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/dalmore_defconfig b/configs/dalmore_defconfig
index 0db2d1d..285785d 100644
--- a/configs/dalmore_defconfig
+++ b/configs/dalmore_defconfig
@@ -28,6 +28,7 @@ CONFIG_DFU_MMC=y

[U-Boot] [PATCH v2 2/5] mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig

From: Marcel Ziswiler 

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Simon Glass 

---

Changes in v2:
- Added Simon's reviewed-by.

 drivers/mmc/Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 5e84a41..18f0e97 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -110,4 +110,10 @@ config SANDBOX_MMC
  improves build coverage for sandbox and makes it easier to detect
  MMC build errors with sandbox.
 
+config TEGRA_MMC
+   bool "Tegra SDHCI aka MMC support"
+   depends on DM_MMC && TEGRA
+   help
+ This selects support for SDHCI on Tegra SoCs.
+
 endmenu
-- 
2.9.3

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

[U-Boot] [PATCH v2 5/5] apalis-tk1: disable external clock loopback on SDMMC3

From: Marcel Ziswiler 

Actually make use of that shiny new CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK.

Signed-off-by: Marcel Ziswiler 
---

Changes in v2: None

 configs/apalis-tk1_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/apalis-tk1_defconfig b/configs/apalis-tk1_defconfig
index c1caef1..204137b 100644
--- a/configs/apalis-tk1_defconfig
+++ b/configs/apalis-tk1_defconfig
@@ -37,6 +37,7 @@ CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_TEGRA_MMC=y
+CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK=y
 CONFIG_E1000=y
 CONFIG_PCI=y
 CONFIG_DM_PCI=y
-- 
2.9.3

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

Re: [U-Boot] [PATCH v3 19/26] sunxi: H3/A64: fix non-ODT setting

2016-12-19 Thread Jens Kuske

On 19.12.2016 11:33, Andre Przywara wrote:
> Hi,
> 
> On 19/12/16 10:01, Maxime Ripard wrote:
>> On Mon, Dec 19, 2016 at 01:50:09AM +, Andre Przywara wrote:
>>> According to Jens disabling the on-die-termination should set bit 5,
>>> not bit 1 in the respective register. Fix this.
>>>
>>> Reported-by: Jens Kuske 
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
>>> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>>> index 6ee73ae..1bdd738 100644
>>> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>>> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>>> @@ -438,7 +438,7 @@ static int mctl_channel_init(uint16_t socid, struct 
>>> dram_para *para)
>>> clrsetbits_le32(_ctl->dx[i].gcr, (0x3 << 4) |
>>> (0x1 << 1) | (0x3 << 2) | (0x3 << 12) |
>>> (0x3 << 14),
>>> -   IS_ENABLED(CONFIG_DRAM_ODT_EN) ? 0x0 : 0x2);
>>> +   IS_ENABLED(CONFIG_DRAM_ODT_EN) ? 0x0 : 0x20);
>>
>> You should use a define here if that bit function is known.
> 
> I agree, and I tried but I failed to find one. That part seems to differ
> from the Keystone documentation, which doesn't know an ODT _dis_able bit
> at all.
> 
> Maybe Jens can add his source?

I think DXnGCR bits 5:4 mean:

0x0 = dynamic ODT
0x1 = ODT always on
0x2 = ODT off

But its only guessed, there is no documentation.
Compare to A83 boot0 code [1], setting dram_odt_en parameter in H3
boot0 to these values results in matching changes in bits 5:4.

Jens

[1] 
https://github.com/allwinner-zh/bootloader/blob/182661abb29d5467a15eb83cf9824e6471d80d8d/basic_loader/bsp/bsp_for_a83/init_dram/mctl_hal.c#L691-L726

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

[U-Boot] [PATCH V2] tools: mxsimage: Fix build with OpenSSL 1.1.x

The EVP_MD_CTX and EVP_CIPHER_CTX are made opaque since 1.1.x , so instead
of embedding them directly into struct sb_image_ctx and initializing them
using EVP_*_CTX_init(), we use pointers and allocate the crypto contexts
using EVP_*_CTX_new().

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
V2: Fix build with older versions of OpenSSL than 1.1.0
---
 tools/mxsimage.c | 104 +--
 1 file changed, 70 insertions(+), 34 deletions(-)

diff --git a/tools/mxsimage.c b/tools/mxsimage.c
index 98fc644..32a7978 100644
--- a/tools/mxsimage.c
+++ b/tools/mxsimage.c
@@ -22,6 +22,36 @@
 #include "pbl_crc32.h"
 #include 
 
+/*
+ * OpenSSL 1.1.0 and newer compatibility functions:
+ * https://wiki.openssl.org/index.php/1.1_API_Changes
+ */
+#if OPENSSL_VERSION_NUMBER < 0x1010L
+static void *OPENSSL_zalloc(size_t num)
+{
+   void *ret = OPENSSL_malloc(num);
+
+   if (ret != NULL)
+   memset(ret, 0, num);
+   return ret;
+}
+
+EVP_MD_CTX *EVP_MD_CTX_new(void)
+{
+   return OPENSSL_zalloc(sizeof(EVP_MD_CTX));
+}
+
+void EVP_MD_CTX_free(EVP_MD_CTX *ctx)
+{
+   EVP_MD_CTX_cleanup(ctx);
+   OPENSSL_free(ctx);
+}
+
+int EVP_CIPHER_CTX_reset(EVP_CIPHER_CTX *ctx)
+{
+   return EVP_CIPHER_CTX_cleanup(ctx);
+}
+#endif
 
 /*
  * DCD block
@@ -144,8 +174,8 @@ struct sb_image_ctx {
struct sb_dcd_ctx   *dcd_head;
struct sb_dcd_ctx   *dcd_tail;
 
-   EVP_CIPHER_CTX  cipher_ctx;
-   EVP_MD_CTX  md_ctx;
+   EVP_CIPHER_CTX  *cipher_ctx;
+   EVP_MD_CTX  *md_ctx;
uint8_t digest[32];
struct sb_key_dictionary_keysb_dict_key;
 
@@ -173,24 +203,26 @@ struct sb_image_ctx {
  */
 static int sb_aes_init(struct sb_image_ctx *ictx, uint8_t *iv, int enc)
 {
-   EVP_CIPHER_CTX *ctx = >cipher_ctx;
+   EVP_CIPHER_CTX *ctx;
int ret;
 
/* If there is no init vector, init vector is all zeroes. */
if (!iv)
iv = ictx->image_key;
 
-   EVP_CIPHER_CTX_init(ctx);
+   ctx = EVP_CIPHER_CTX_new();
ret = EVP_CipherInit(ctx, EVP_aes_128_cbc(), ictx->image_key, iv, enc);
-   if (ret == 1)
+   if (ret == 1) {
EVP_CIPHER_CTX_set_padding(ctx, 0);
+   ictx->cipher_ctx = ctx;
+   }
return ret;
 }
 
 static int sb_aes_crypt(struct sb_image_ctx *ictx, uint8_t *in_data,
uint8_t *out_data, int in_len)
 {
-   EVP_CIPHER_CTX *ctx = >cipher_ctx;
+   EVP_CIPHER_CTX *ctx = ictx->cipher_ctx;
int ret, outlen;
uint8_t *outbuf;
 
@@ -215,13 +247,13 @@ err:
 
 static int sb_aes_deinit(EVP_CIPHER_CTX *ctx)
 {
-   return EVP_CIPHER_CTX_cleanup(ctx);
+   return EVP_CIPHER_CTX_reset(ctx);
 }
 
 static int sb_aes_reinit(struct sb_image_ctx *ictx, int enc)
 {
int ret;
-   EVP_CIPHER_CTX *ctx = >cipher_ctx;
+   EVP_CIPHER_CTX *ctx = ictx->cipher_ctx;
struct sb_boot_image_header *sb_header = >payload;
uint8_t *iv = sb_header->iv;
 
@@ -276,7 +308,7 @@ static int sb_get_time(time_t time, struct tm *tm)
 
 static void sb_encrypt_sb_header(struct sb_image_ctx *ictx)
 {
-   EVP_MD_CTX *md_ctx = >md_ctx;
+   EVP_MD_CTX *md_ctx = ictx->md_ctx;
struct sb_boot_image_header *sb_header = >payload;
uint8_t *sb_header_ptr = (uint8_t *)sb_header;
 
@@ -287,7 +319,7 @@ static void sb_encrypt_sb_header(struct sb_image_ctx *ictx)
 
 static void sb_encrypt_sb_sections_header(struct sb_image_ctx *ictx)
 {
-   EVP_MD_CTX *md_ctx = >md_ctx;
+   EVP_MD_CTX *md_ctx = ictx->md_ctx;
struct sb_section_ctx *sctx = ictx->sect_head;
struct sb_sections_header *shdr;
uint8_t *sb_sections_header_ptr;
@@ -307,7 +339,7 @@ static void sb_encrypt_sb_sections_header(struct 
sb_image_ctx *ictx)
 
 static void sb_encrypt_key_dictionary_key(struct sb_image_ctx *ictx)
 {
-   EVP_MD_CTX *md_ctx = >md_ctx;
+   EVP_MD_CTX *md_ctx = ictx->md_ctx;
 
sb_aes_crypt(ictx, ictx->image_key, ictx->sb_dict_key.key,
 sizeof(ictx->sb_dict_key.key));
@@ -316,7 +348,7 @@ static void sb_encrypt_key_dictionary_key(struct 
sb_image_ctx *ictx)
 
 static void sb_decrypt_key_dictionary_key(struct sb_image_ctx *ictx)
 {
-   EVP_MD_CTX *md_ctx = >md_ctx;
+   EVP_MD_CTX *md_ctx = ictx->md_ctx;
 
EVP_DigestUpdate(md_ctx, >sb_dict_key, sizeof(ictx->sb_dict_key));
sb_aes_crypt(ictx, ictx->sb_dict_key.key, ictx->image_key,
@@ -326,7 +358,7 @@ static void sb_decrypt_key_dictionary_key(struct 
sb_image_ctx *ictx)
 static void sb_encrypt_tag(struct sb_image_ctx *ictx,
struct sb_cmd_ctx *cctx)
 {
-   EVP_MD_CTX *md_ctx = >md_ctx;
+   EVP_MD_CTX *md_ctx = ictx->md_ctx;
struct sb_command *cmd = >payload;
 
sb_aes_crypt(ictx,

Re: [U-Boot] [PATCH v3] timer: Support clocks via phandle

2016-12-19 Thread Vlad Zakharov

Hi Tom,

On Fri, 2016-12-09 at 17:18 +0300, Vlad Zakharov wrote:
> Earlier timer driver needed a clock-frequency property in compatible
> device-tree nodes. Another way is to reference a clock via a phandle.
> 
> So now timer_pre_probe tries to get clock by reference through device
> tree. In case it is impossible to get clock device through the
> reference, clock-frequency property of the timer node is read to provide
> backward compatibility.
> 
> Signed-off-by: Vlad Zakharov 
> Reviewed-by: Simon Glass 
> ---
> Changes v2..v3:
>  - Use value type instead of pointer for timer_clk in order to fix
> build time warnings
> 
>  drivers/timer/timer-uclass.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/timer/timer-uclass.c b/drivers/timer/timer-uclass.c
> index f8ddf93..5c63e6b 100644
> --- a/drivers/timer/timer-uclass.c
> +++ b/drivers/timer/timer-uclass.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -42,9 +43,19 @@ unsigned long notrace timer_get_rate(struct udevice *dev)
>  static int timer_pre_probe(struct udevice *dev)
>  {
>   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> -
> - uc_priv->clock_rate = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
> -  "clock-frequency", 0);
> + struct clk timer_clk;
> + int err;
> + ulong ret;
> +
> + err = clk_get_by_index(dev, 0, _clk);
> + if (!err) {
> + ret = clk_get_rate(_clk);
> + if (IS_ERR_VALUE(ret))
> + return ret;
> + uc_priv->clock_rate = ret;
> + } else
> + uc_priv->clock_rate = fdtdec_get_int(gd->fdt_blob,
> + dev->of_offset, "clock-frequency", 0);
>  
>   return 0;
>  }

Could you please apply this patch if there's no any objections or comments on 
it?
Thanks.

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

Re: [U-Boot] [RFC PATCH 2/3] sunxi: video: Add video driver for H3 SoC

Hi,

On Wed, Dec 14, 2016 at 11:11:19PM +0100, Jernej Škrabec wrote:
> > > While I took Rockchip HDMI code for reference, it can't be easily reused.
> > > First of, it uses DT nodes. I guess I could write DT binding or modify
> > > existing driver to work without it.
> > 
> > Like we discussed in the other part of the thread, I think the latter
> > would be easier to deal with.
> 
> I forgot to mention that it also uses driver model. The way I would go with 
> this is to split out common code to dwc_hdmi.c and have platform dependant 
> drivers for Rockchip, Allwinner, etc. Basically the same way as it is done in 
> Linux.

That sounds reasonable.

> > > Thirdly, and in my opinion most annoying, Rockchip driver uses 32
> > > bit aligned registers, but H3 does not. This also means a lot of
> > > work to make it more generic.
> > 
> > How does Linux deal with that? Would just using some kind of accessors
> > that would abstract that away from the driver help, or is it more
> > complicated?
> 
> Yes, Linux driver checks "reg-io-width" property and selects accessors 
> accordingly. I suppose I could do similar, save function pointer in a driver 
> private data. I suppose it is ok that platform specific code initializes this 
> private data?

Something like passing a flag stored in the platform data (and/or read
from DT for the relevant cases) to a generic accessor would also be a
solution, without the need for everyone to implement its accessors.

> > > Actually, H3 is more similar to i.MX6 HDMI in this regard, but
> > > driver's code is scattered throughout multiple files (search for
> > > mxc_hdmi.h inclusion). It is certainly doable, but it will take much
> > > more time.  Basically, U-Boot already has two drivers for DWC HDMI
> > > and with this patch it will get third. Merging all three
> > > implementations into one would be very tedious, but very desirable
> > > goal. I must state that I didn't really try to understand i.MX6 HDMI
> > > code at all, so I don't now how hard it would be to pull it out.
> > 
> > I'm not sure that merging a third and saying that it would be up to
> > the fourth to do the work is reasonable. It's just hiding an issue
> > under the carpet, but I don't see how it will be easier for the next
> > person to work on that. Quite the opposite actually.
> 
> True. I wonder if Renesas already prepared U-Boot DWC HDMI driver...
> 
> Do you think it makes sense to put all files related to Allwinner
> video drivers to sunxi subfolder? There will be at least 4 .c files
> according to my plan and even more in the future (at least for TV
> out driver).

On principle, I don't see anything wrong with that.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH 04/10] arm: socfpga: arria10: Added clock manager and pin mux compat macro

On 12/19/2016 11:31 AM, Chee, Tien Fong wrote:
> On Isn, 2016-12-19 at 11:04 +0100, Marek Vasut wrote:
>> On 12/19/2016 09:54 AM, Chee, Tien Fong wrote:
>>>
>>> On Isn, 2016-12-19 at 09:43 +0100, Marek Vasut wrote:

 On 12/19/2016 09:40 AM, Chee, Tien Fong wrote:
>
>
> On Isn, 2016-12-19 at 08:55 +0100, Marek Vasut wrote:
>>
>>
>> On 12/19/2016 05:10 AM, Chee, Tien Fong wrote:
>>>
>>>
>>>
>>> On Rab, 2016-12-07 at 14:54 +0100, Marek Vasut wrote:



 On 12/07/2016 11:48 AM, Chee, Tien Fong wrote:
>
>
>
>
> On Sel, 2016-12-06 at 13:49 +0100, Marek Vasut wrote:
>>
>>
>>
>>
>> On 12/06/2016 08:52 AM, Chee Tien Fong wrote:
>>>
>>>
>>>
>>>
>>>
>>> From: Tien Fong Chee 
>>>
>>> These compat macros would be used by clock manager
>>> and
>>> pin
>>> mux
>>> drivers
>>> to look the required HW info from DTS for hardware
>>> initialization.
>>>
>>> Signed-off-by: Tien Fong Chee >> .com


>>> Cc: Marek Vasut 
>>> Cc: Dinh Nguyen 
>>> Cc: Chin Liang See 
>>> Cc: Tien Fong 
>>> ---
>>>  include/fdtdec.h |8 
>>>  lib/fdtdec.c |2 ++
>>>  2 files changed, 10 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>>> index 27887c8..68cb199 100644
>>> --- a/include/fdtdec.h
>>> +++ b/include/fdtdec.h
>>> @@ -155,6 +155,14 @@ enum fdt_compat_id {
>>> COMPAT_INTEL_BAYTRAIL_FSP_MDP,  /*
>>> Intel
>>> FSP
>>> memory-
>>> down params */
>>> COMPAT_INTEL_IVYBRIDGE_FSP, /*
>>> Intel
>>> Ivy
>>> Bridge
>>> FSP
>>> */
>>> COMPAT_SUNXI_NAND,  /* SUNXI
>>> NAND
>>> controller
>>> */
>>> +   COMPAT_ALTERA_SOCFPGA_CLK,  /*
>>> SoCFPGA
>>> Clock
>>> initialization */
>>> +   COMPAT_ALTERA_SOCFPGA_PINCTRL_SINGLE,   
>>> /
>>> *
>>> pinctrl-
>>> single */
>>> +   COMPAT_ALTERA_SOCFPGA_H2F_BRG,  
>>> /*
>>> Arria10
>>> hps2fpga bridge */
>>> +   COMPAT_ALTERA_SOCFPGA_LWH2F_BRG,/*
>>> Arria10
>>> lwhps2fpga bridge */
>>> +   COMPAT_ALTERA_SOCFPGA_F2H_BRG,  
>>> /*
>>> Arria10
>>> fpga2hps bridge */
>>> +   COMPAT_ALTERA_SOCFPGA_F2SDR0,   
>>> /
>>> *
>>> Arria10
>>> fpga2SDRAM0 bridge */
>>> +   COMPAT_ALTERA_SOCFPGA_F2SDR1,   
>>> /
>>> *
>>> Arria10
>>> fpga2SDRAM1 bridge */
>>> +   COMPAT_ALTERA_SOCFPGA_F2SDR2,   
>>> /
>>> *
>>> Arria10
>>> fpga2SDRAM2 bridge */
>> Is all of this needed ? You're only adding two
>> entries in
>> the
>> FDTDEC
>> below.
>>
> This is to avoid compilation error, we have some
> functions
> ported
> from
> our internal branch, which using above COMPAT macro.
> Soon,
> in
> upcoming
> patches, we will need those functions and more entries
> will
> be
> added
> into FDTDEC below.
 You can add the compat strings when you really need them.
 Still,
 with
 DM, you shouldn't even need them AFAIK.

>>> We have some drivers in these series of patches contain
>>> some
>>> COMPAT
>>> strings, without these compact strings, the compilation
>>> would
>>> fail
>>> due
>>> to error compact string is not defined.
>> All of them ? Mind you, with DM you should not need to add
>> those
>> at
>> all.
>>
>>>
>>>
>>>
>>> I think having compact string
>>> would giving us flexbility to put our nodes where we want
>>> without
>>> worrying to break our existing codes?
>> Which existing codes ?
>>
> let say we have version A, we found the node based on COMPAT
> STRING.
> One day, we move the node to somewhere else in version B, we
> still
> can
> find them based on COMPAT STRING without checking the node
> path.
> What
> do you think?
 I do not understand what you're trying to tell me here. The DM
 core
 will
 walk the DT and bind drivers according to compat strings, so if
 you ever move a node, it will still be bound.

Re: [U-Boot] [PATCH 1/2] libfdt: overlay: Fix missing symbols condition

On Sat, Dec 17, 2016 at 04:56:49PM -0800, Stefan Agner wrote:
> > Do you have a base DT and an overlay showing up the error you're
> > trying to fix? Either way, that should be discussed with upstream's
> > libfdt ml and maintainer, not (only) on U-Boot.
> 
> Yeah my problem was that my base DT had no symbols and used labels.
> Wasn't aware of the whole symbols problematic...
> 
> I actually just realized that this got fixed upstream:
> https://git.kernel.org/cgit/utils/dtc/dtc.git/commit/libfdt/fdt_overlay.c?id=7d8ef6e1db9794f72805a0855f4f7f12fadd03d3
> 
> I guess we could backport that fix?

Yep.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH 02/10] arm: socfpga: arria10: Added config option build for SPL

On 12/19/2016 11:34 AM, Chee, Tien Fong wrote:
> On Isn, 2016-12-19 at 09:44 +0100, Marek Vasut wrote:
>> On 12/19/2016 09:41 AM, Chee, Tien Fong wrote:
>>>
>>> On Isn, 2016-12-19 at 08:56 +0100, Marek Vasut wrote:

 On 12/19/2016 05:04 AM, Chee, Tien Fong wrote:
>
>
> On Jum, 2016-12-09 at 14:02 +0100, Marek Vasut wrote:
>>
>>
>> On 12/09/2016 10:46 AM, Chee, Tien Fong wrote:
>>>
>>>
>>>
>>> On Rab, 2016-12-07 at 14:54 +0100, Marek Vasut wrote:



 On 12/07/2016 11:57 AM, Chee, Tien Fong wrote:
>
>
>
>
> On Sel, 2016-12-06 at 13:47 +0100, Marek Vasut wrote:
>>
>>
>>
>>
>> On 12/06/2016 08:52 AM, Chee Tien Fong wrote:
>>>
>>>
>>>
>>>
>>>
>>> From: Tien Fong Chee 
>>>
>>> These changes to ensure Arria10 SPL build success.
>> Please reword the commit message, mention you're
>> removing
>> the
>> Arria10
>> bits. Still, this does not even apply on mainline, on
>> top
>> of
>> what
>> does
>> this apply ?
>>
> I disabled some features temporary, so SPL build can
> pass
> and
> print
> out
> working. I will enable these features back in upcoming
> patches.
> This is
> base on 01-arria10 branch.
 But this patch seems to only enable stuff ... ?

>>> Enable the spl. Disable SPI flash temporary, for preventing
>>> build
>>> failed, but this will be enabled back with upcoming patches
>>> for
>>> supporting SPI flash.
>> What's the problem with SPI flash ? I thought it's the same
>> block
>> as
>> in
>> C/A 5 ?
>>
> Some compilation error, but i haven't checked it out what
> errors
> causing the build failed. My plan is to have SPL and print out
> working,
> then following boot from SDMMC, FPGA configuration, DDR up.
> Once
> booting from SDMMC working, i will work to boot from QSPI and
> NAND
> too.
 MW is now closed, so you can focus on fixing the CQSPI too, it
 shouldn't
 be too hard.

>>> What is MW?
>>>
>> Merge Window
> 
> just for comfirmation, are you means rebase to master of u-boot-
> socfpga.git or denx master? I think former,right?
> 
You can use either now, u-boot-socfpga has no patches queued and
u-boot.git is more up-to-date .

-- 
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 3/3] README: remove description about CONFIG_USE_ARCH_MEMCPY/SET

On Mon, Dec 19, 2016 at 8:31 AM, Masahiro Yamada
 wrote:
> These options are now described in the Kconfig help.  We do not want
> to maintain duplicated documentation.
>
> Signed-off-by: Masahiro Yamada 

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

Re: [U-Boot] [PATCH 1/3] ARM: revive CONFIG_USE_ARCH_MEMCPY/MEMSET for UniPhier and Tegra

On Mon, Dec 19, 2016 at 8:31 AM, Masahiro Yamada
 wrote:
> Commit be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to
> Kconfig") is misconversion.
>
> The original logic in include/configs/uniphier.h was as follows:
>
>   #if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ARM64)
>   #define CONFIG_USE_ARCH_MEMSET
>   #define CONFIG_USE_ARCH_MEMCPY
>   #endif
>
> This means those configs were enabled when building U-Boot proper,
> but disabled when building SPL.  Likewise for Tegra.
>
> Now "depends on !SPL" prevents any boards with SPL support
> from reaching these options.  This changed the behavior for
> UniPhier and Tegra SoC family.
>
> Please notice these two options only control the U-Boot proper
> build.  As you see arch/arm/Makefile, ARM-specific memset/memcpy
> are never compiled for SPL.  So, __HAVE_ARCH_MEMCPY/MEMSET should
> not set for SPL.
>
> Fixes: be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to Kconfig")
> Signed-off-by: Masahiro Yamada 

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

Re: [U-Boot] [PATCH 2/3] common/init: remove meaningless defined(CONFIG_USE_ARCH_MEMSET)

On Mon, Dec 19, 2016 at 8:31 AM, Masahiro Yamada
 wrote:
> CONFIG_USE_ARCH_MEMSET controls nothing about SPL.  (it is effective
> only on U-Boot proper building of ARM).
>
> Signed-off-by: Masahiro Yamada 

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

Re: [U-Boot] [PATCH v3 16/26] sunxi: H3: add DRAM controller single bit delay support

2016-12-19 Thread Andre Przywara

Hi,

On 19/12/16 09:57, Maxime Ripard wrote:
> On Mon, Dec 19, 2016 at 01:50:06AM +, Andre Przywara wrote:
>> From: Jens Kuske 
>>
>> So far the DRAM driver for the H3 SoC (and apparently boot0/libdram as
>> well) only applied coarse delay line settings, with one delay value for
>> all the data lines in each byte lane and one value for the control lines.
>>
>> Instead of setting the delays for whole bytes only allow setting it for
>> each individual bit. Also add support for address/command lane delays.
>>
>> For the purpose of this patch the rules for the existing coarse settings
>> were just applied to the new scheme, so the actual register writes don't
>> change for the H3. Other SoCs will utilize this feature later properly.
>>
>> With a stock GCC 5.3.0 this increases the dram_sun8i_h3.o code size from
>> 2296 to 2344 Bytes.
>>
>> [Andre: move delay parameters into macros to ease later sharing, use
>>  defines for numbers of delay registers, extend commit message]
>>
>> Signed-off-by: Jens Kuske 
>> Signed-off-by: Andre Przywara 
> 
> I said it earlier, but some comments on these new fields would really
> be welcome to document the structure and what values they're supposed
> to hold.

I guess you know as much as I do on this topic.
Apparently there are delays to compensate for differing trace lengths on
the PCB, one for every bit line. On the 32-bit DRAM controller these are
grouped in four groups of 8 bits each (hence byte lane).

Please keep in mind that there is no easily available documentation,
some parts are just copying what boot0/libdram does.
As we don't know the exact meaning of these fields, I prefer to not add
any guesses here.
I was hoping that the defines I added in this version would shed some
light on this? I am pretty sure of their meaning, but that's as far as
it goes. For instance I have no idea what the units are, for cycles they
are quite big.

So frankly I don't really know what to add here still.

I can elaborate on how to get these actual values from an existing
boot0/libdram, but that would be more of a documentation patch than
actual code.

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

Re: [U-Boot] [PATCH 02/10] arm: socfpga: arria10: Added config option build for SPL

2016-12-19 Thread Chee, Tien Fong

On Isn, 2016-12-19 at 09:44 +0100, Marek Vasut wrote:
> On 12/19/2016 09:41 AM, Chee, Tien Fong wrote:
> > 
> > On Isn, 2016-12-19 at 08:56 +0100, Marek Vasut wrote:
> > > 
> > > On 12/19/2016 05:04 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Jum, 2016-12-09 at 14:02 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 12/09/2016 10:46 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Rab, 2016-12-07 at 14:54 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 12/07/2016 11:57 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Sel, 2016-12-06 at 13:47 +0100, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 12/06/2016 08:52 AM, Chee Tien Fong wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > 
> > > > > > > > > > These changes to ensure Arria10 SPL build success.
> > > > > > > > > Please reword the commit message, mention you're
> > > > > > > > > removing
> > > > > > > > > the
> > > > > > > > > Arria10
> > > > > > > > > bits. Still, this does not even apply on mainline, on
> > > > > > > > > top
> > > > > > > > > of
> > > > > > > > > what
> > > > > > > > > does
> > > > > > > > > this apply ?
> > > > > > > > > 
> > > > > > > > I disabled some features temporary, so SPL build can
> > > > > > > > pass
> > > > > > > > and
> > > > > > > > print
> > > > > > > > out
> > > > > > > > working. I will enable these features back in upcoming
> > > > > > > > patches.
> > > > > > > > This is
> > > > > > > > base on 01-arria10 branch.
> > > > > > > But this patch seems to only enable stuff ... ?
> > > > > > > 
> > > > > > Enable the spl. Disable SPI flash temporary, for preventing
> > > > > > build
> > > > > > failed, but this will be enabled back with upcoming patches
> > > > > > for
> > > > > > supporting SPI flash.
> > > > > What's the problem with SPI flash ? I thought it's the same
> > > > > block
> > > > > as
> > > > > in
> > > > > C/A 5 ?
> > > > > 
> > > > Some compilation error, but i haven't checked it out what
> > > > errors
> > > > causing the build failed. My plan is to have SPL and print out
> > > > working,
> > > > then following boot from SDMMC, FPGA configuration, DDR up.
> > > > Once
> > > > booting from SDMMC working, i will work to boot from QSPI and
> > > > NAND
> > > > too.
> > > MW is now closed, so you can focus on fixing the CQSPI too, it
> > > shouldn't
> > > be too hard.
> > > 
> > What is MW?
> > 
> Merge Window

just for comfirmation, are you means rebase to master of u-boot-
socfpga.git or denx master? I think former,right?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/3] README: remove description about CONFIG_USE_ARCH_MEMCPY/SET

These options are now described in the Kconfig help.  We do not want
to maintain duplicated documentation.

Signed-off-by: Masahiro Yamada 
---

 README | 6 --
 1 file changed, 6 deletions(-)

diff --git a/README b/README
index 25cad2f..0bd6e6c 100644
--- a/README
+++ b/README
@@ -4593,12 +4593,6 @@ Low Level (hardware related) configuration options:
addressable memory. This option causes some memory accesses
to be mapped through map_sysmem() / unmap_sysmem().
 
-- CONFIG_USE_ARCH_MEMCPY
-  CONFIG_USE_ARCH_MEMSET
-   If these options are used a optimized version of memcpy/memset 
will
-   be used if available. These functions may be faster under some
-   conditions but may increase the binary size.
-
 - CONFIG_X86_RESET_VECTOR
If defined, the x86 reset vector code is included. This is not
needed when U-Boot is running from Coreboot.
-- 
2.7.4

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

Re: [U-Boot] [PATCH v3 19/26] sunxi: H3/A64: fix non-ODT setting

2016-12-19 Thread Andre Przywara

Hi,

On 19/12/16 10:01, Maxime Ripard wrote:
> On Mon, Dec 19, 2016 at 01:50:09AM +, Andre Przywara wrote:
>> According to Jens disabling the on-die-termination should set bit 5,
>> not bit 1 in the respective register. Fix this.
>>
>> Reported-by: Jens Kuske 
>> Signed-off-by: Andre Przywara 
>> ---
>>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
>> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> index 6ee73ae..1bdd738 100644
>> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> @@ -438,7 +438,7 @@ static int mctl_channel_init(uint16_t socid, struct 
>> dram_para *para)
>>  clrsetbits_le32(_ctl->dx[i].gcr, (0x3 << 4) |
>>  (0x1 << 1) | (0x3 << 2) | (0x3 << 12) |
>>  (0x3 << 14),
>> -IS_ENABLED(CONFIG_DRAM_ODT_EN) ? 0x0 : 0x2);
>> +IS_ENABLED(CONFIG_DRAM_ODT_EN) ? 0x0 : 0x20);
> 
> You should use a define here if that bit function is known.

I agree, and I tried but I failed to find one. That part seems to differ
from the Keystone documentation, which doesn't know an ODT _dis_able bit
at all.

Maybe Jens can add his source?

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

[U-Boot] [PATCH 0/3] ARM: fix the Kconfig misconversion of CONFIG_USE_ARCH_MEMCPY/MEMSET




Masahiro Yamada (3):
  ARM: revive CONFIG_USE_ARCH_MEMCPY/MEMSET for UniPhier and Tegra
  common/init: remove meaningless defined(CONFIG_USE_ARCH_MEMSET)
  README: remove description about CONFIG_USE_ARCH_MEMCPY/SET

 README| 6 --
 arch/arm/Kconfig  | 4 ++--
 arch/arm/include/asm/string.h | 4 ++--
 common/init/board_init.c  | 4 +---
 4 files changed, 5 insertions(+), 13 deletions(-)

-- 
2.7.4

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

[U-Boot] [PATCH 1/3] ARM: revive CONFIG_USE_ARCH_MEMCPY/MEMSET for UniPhier and Tegra

Commit be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to
Kconfig") is misconversion.

The original logic in include/configs/uniphier.h was as follows:

  #if !defined(CONFIG_SPL_BUILD) && !defined(CONFIG_ARM64)
  #define CONFIG_USE_ARCH_MEMSET
  #define CONFIG_USE_ARCH_MEMCPY
  #endif

This means those configs were enabled when building U-Boot proper,
but disabled when building SPL.  Likewise for Tegra.

Now "depends on !SPL" prevents any boards with SPL support
from reaching these options.  This changed the behavior for
UniPhier and Tegra SoC family.

Please notice these two options only control the U-Boot proper
build.  As you see arch/arm/Makefile, ARM-specific memset/memcpy
are never compiled for SPL.  So, __HAVE_ARCH_MEMCPY/MEMSET should
not set for SPL.

Fixes: be72591bcd64 ("Kconfig: Move USE_ARCH_MEMCPY/MEMSET to Kconfig")
Signed-off-by: Masahiro Yamada 
---

I am restoring the original behavior for now.
But, I have been wondering if we could remove these options entirely.

As you see scripts/config_whitelist.txt, we still have 8000 options.
As I stated before, it is a crazy idea to move all of them as they are.

We should refactor the code, and we should delete options
if they turned out unneeded.

I think CONFIG_USE_ARCH_MEMSET/MEMCPY are questionable ones.

U-Boot supports arch-optimized memcpy/memset
for ARC, ARM (only 32bit), Blackfin, PowerPC, and x86.

Strange enough, only ARM 32bit uses CONFIG_USE_ARCH_MEMSET/MEMCPY
to make it user-configurable.
(Other architectures always turn on the optimized variants if supported)

Even more strangely, those two options enable/disable
ARM-specific memcpy/memset for the U-Boot full image.
(Please note they are never compiled for SPL)

The U-Boot full image generally does not have strong memory
footprint constraint.  So, if we talk about the image size,
it shouldn't hurt to enable ARM-optimized memcpy/set all the time.


 arch/arm/Kconfig  | 4 ++--
 arch/arm/include/asm/string.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 587f288..6820479 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -129,7 +129,7 @@ config ENABLE_ARM_SOC_BOOT0_HOOK
 config USE_ARCH_MEMCPY
bool "Use an assembly optimized implementation of memcpy"
default y if CPU_V7
-   depends on !ARM64 && !SPL
+   depends on !ARM64
help
  Enable the generation of an optimized version of memcpy.
  Such implementation may be faster under some conditions
@@ -138,7 +138,7 @@ config USE_ARCH_MEMCPY
 config USE_ARCH_MEMSET
bool "Use an assembly optimized implementation of memset"
default y if CPU_V7
-   depends on !ARM64 && !SPL
+   depends on !ARM64
help
  Enable the generation of an optimized version of memset.
  Such implementation may be faster under some conditions
diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
index c6dfb25..11eaa34 100644
--- a/arch/arm/include/asm/string.h
+++ b/arch/arm/include/asm/string.h
@@ -14,7 +14,7 @@ extern char * strrchr(const char * s, int c);
 #undef __HAVE_ARCH_STRCHR
 extern char * strchr(const char * s, int c);
 
-#ifdef CONFIG_USE_ARCH_MEMCPY
+#if CONFIG_IS_ENABLED(USE_ARCH_MEMCPY)
 #define __HAVE_ARCH_MEMCPY
 #endif
 extern void * memcpy(void *, const void *, __kernel_size_t);
@@ -26,7 +26,7 @@ extern void * memmove(void *, const void *, __kernel_size_t);
 extern void * memchr(const void *, int, __kernel_size_t);
 
 #undef __HAVE_ARCH_MEMZERO
-#ifdef CONFIG_USE_ARCH_MEMSET
+#if CONFIG_IS_ENABLED(USE_ARCH_MEMSET)
 #define __HAVE_ARCH_MEMSET
 #endif
 extern void * memset(void *, int, __kernel_size_t);
-- 
2.7.4

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

[U-Boot] [PATCH 2/3] common/init: remove meaningless defined(CONFIG_USE_ARCH_MEMSET)

CONFIG_USE_ARCH_MEMSET controls nothing about SPL.  (it is effective
only on U-Boot proper building of ARM).

Signed-off-by: Masahiro Yamada 
---

 common/init/board_init.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/common/init/board_init.c b/common/init/board_init.c
index ef01a9a..a2edb4e 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -15,9 +15,7 @@ DECLARE_GLOBAL_DATA_PTR;
  * It isn't trivial to figure out whether memcpy() exists. The arch-specific
  * memcpy() is not normally available in SPL due to code size.
  */
-#if !defined(CONFIG_SPL_BUILD) || \
-   (defined(CONFIG_SPL_LIBGENERIC_SUPPORT) && \
-   !defined(CONFIG_USE_ARCH_MEMSET))
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBGENERIC_SUPPORT)
 #define _USE_MEMCPY
 #endif
 
-- 
2.7.4

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

Re: [U-Boot] [PATCH 04/10] arm: socfpga: arria10: Added clock manager and pin mux compat macro

2016-12-19 Thread Chee, Tien Fong

On Isn, 2016-12-19 at 11:04 +0100, Marek Vasut wrote:
> On 12/19/2016 09:54 AM, Chee, Tien Fong wrote:
> > 
> > On Isn, 2016-12-19 at 09:43 +0100, Marek Vasut wrote:
> > > 
> > > On 12/19/2016 09:40 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Isn, 2016-12-19 at 08:55 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 12/19/2016 05:10 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Rab, 2016-12-07 at 14:54 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 12/07/2016 11:48 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Sel, 2016-12-06 at 13:49 +0100, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 12/06/2016 08:52 AM, Chee Tien Fong wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > 
> > > > > > > > > > These compat macros would be used by clock manager
> > > > > > > > > > and
> > > > > > > > > > pin
> > > > > > > > > > mux
> > > > > > > > > > drivers
> > > > > > > > > > to look the required HW info from DTS for hardware
> > > > > > > > > > initialization.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > > > .com
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > Cc: Marek Vasut 
> > > > > > > > > > Cc: Dinh Nguyen 
> > > > > > > > > > Cc: Chin Liang See 
> > > > > > > > > > Cc: Tien Fong 
> > > > > > > > > > ---
> > > > > > > > > >  include/fdtdec.h |8 
> > > > > > > > > >  lib/fdtdec.c |2 ++
> > > > > > > > > >  2 files changed, 10 insertions(+), 0 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/include/fdtdec.h b/include/fdtdec.h
> > > > > > > > > > index 27887c8..68cb199 100644
> > > > > > > > > > --- a/include/fdtdec.h
> > > > > > > > > > +++ b/include/fdtdec.h
> > > > > > > > > > @@ -155,6 +155,14 @@ enum fdt_compat_id {
> > > > > > > > > >     COMPAT_INTEL_BAYTRAIL_FSP_MDP,  /*
> > > > > > > > > > Intel
> > > > > > > > > > FSP
> > > > > > > > > > memory-
> > > > > > > > > > down params */
> > > > > > > > > >     COMPAT_INTEL_IVYBRIDGE_FSP, /*
> > > > > > > > > > Intel
> > > > > > > > > > Ivy
> > > > > > > > > > Bridge
> > > > > > > > > > FSP
> > > > > > > > > > */
> > > > > > > > > >     COMPAT_SUNXI_NAND,  /* SUNXI
> > > > > > > > > > NAND
> > > > > > > > > > controller
> > > > > > > > > > */
> > > > > > > > > > +   COMPAT_ALTERA_SOCFPGA_CLK,  /*
> > > > > > > > > > SoCFPGA
> > > > > > > > > > Clock
> > > > > > > > > > initialization */
> > > > > > > > > > +   COMPAT_ALTERA_SOCFPGA_PINCTRL_SINGLE,   
> > > > > > > > > > /
> > > > > > > > > > *
> > > > > > > > > > pinctrl-
> > > > > > > > > > single */
> > > > > > > > > > +   COMPAT_ALTERA_SOCFPGA_H2F_BRG,  
> > > > > > > > > > /*
> > > > > > > > > > Arria10
> > > > > > > > > > hps2fpga bridge */
> > > > > > > > > > +   COMPAT_ALTERA_SOCFPGA_LWH2F_BRG,/*
> > > > > > > > > > Arria10
> > > > > > > > > > lwhps2fpga bridge */
> > > > > > > > > > +   COMPAT_ALTERA_SOCFPGA_F2H_BRG,  
> > > > > > > > > > /*
> > > > > > > > > > Arria10
> > > > > > > > > > fpga2hps bridge */
> > > > > > > > > > +   COMPAT_ALTERA_SOCFPGA_F2SDR0,   
> > > > > > > > > > /
> > > > > > > > > > *
> > > > > > > > > > Arria10
> > > > > > > > > > fpga2SDRAM0 bridge */
> > > > > > > > > > +   COMPAT_ALTERA_SOCFPGA_F2SDR1,   
> > > > > > > > > > /
> > > > > > > > > > *
> > > > > > > > > > Arria10
> > > > > > > > > > fpga2SDRAM1 bridge */
> > > > > > > > > > +   COMPAT_ALTERA_SOCFPGA_F2SDR2,   
> > > > > > > > > > /
> > > > > > > > > > *
> > > > > > > > > > Arria10
> > > > > > > > > > fpga2SDRAM2 bridge */
> > > > > > > > > Is all of this needed ? You're only adding two
> > > > > > > > > entries in
> > > > > > > > > the
> > > > > > > > > FDTDEC
> > > > > > > > > below.
> > > > > > > > > 
> > > > > > > > This is to avoid compilation error, we have some
> > > > > > > > functions
> > > > > > > > ported
> > > > > > > > from
> > > > > > > > our internal branch, which using above COMPAT macro.
> > > > > > > > Soon,
> > > > > > > > in
> > > > > > > > upcoming
> > > > > > > > patches, we will need those functions and more entries
> > > > > > > > will
> > > > > > > > be
> > > > > > > > added
> > > > > > > > into FDTDEC below.
> > > > > > > You can add the compat strings when you really need them.
> > > > > > > Still,
> > > > > > > with
> > > > > > > DM, you shouldn't even need them AFAIK.
> > > > > > > 
> > > > > > We have some drivers in these series of patches contain
> > > > > > some
> > > > > > COMPAT
> > > > > > strings, without these compact strings, the

Re: [U-Boot] [PATCH v2 23/23] sunxi: A64: add 32-bit SPL support

2016-12-19 Thread Andre Przywara

Salut Maxime,

On 19/12/16 08:20, Maxime Ripard wrote:
> On Sat, Dec 17, 2016 at 02:44:46PM +, André Przywara wrote:
>>> Instead, can you do something similar to tegra, which uses ARMv4t for
>>> SPL and ARMv7 for U-Boot proper?
>>
>> You will need two different (cross-)compilers, so just setting some
>> compiler options will not help.
>> Besides compiling the SPL as 32-bit is only an option, the SPL also
>> works as a pure 64-bit binary. And people expressed the wish of having
>> the option of using both ways - at least for the time being.
> 
> Honestly, I have the feeling that this is the only thing that holds
> this serie back. Maybe you can send it without it first, we merge it,
> and then we work on the 32 bits SPL. That way, we don't delay
> everything else but the very last patch.

Feel free to do so already.
I deliberately made the series this way, so you can merge anything up to
and including "[PATCH v3 21/26] sunxi: A64: enable SPL" and get the
64-bit SPL functionality. If you like, you can also take the others but
the last patch as well.

Actually I would be very glad to get that two-digit patch count off my
back, as this makes handling much easier.
Also I have the H5 support ready on top of that ...

Thanks!

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

Re: [U-Boot] [PATCH 04/10] arm: socfpga: arria10: Added clock manager and pin mux compat macro

On 12/19/2016 09:54 AM, Chee, Tien Fong wrote:
> On Isn, 2016-12-19 at 09:43 +0100, Marek Vasut wrote:
>> On 12/19/2016 09:40 AM, Chee, Tien Fong wrote:
>>>
>>> On Isn, 2016-12-19 at 08:55 +0100, Marek Vasut wrote:

 On 12/19/2016 05:10 AM, Chee, Tien Fong wrote:
>
>
> On Rab, 2016-12-07 at 14:54 +0100, Marek Vasut wrote:
>>
>>
>> On 12/07/2016 11:48 AM, Chee, Tien Fong wrote:
>>>
>>>
>>>
>>> On Sel, 2016-12-06 at 13:49 +0100, Marek Vasut wrote:



 On 12/06/2016 08:52 AM, Chee Tien Fong wrote:
>
>
>
>
> From: Tien Fong Chee 
>
> These compat macros would be used by clock manager and
> pin
> mux
> drivers
> to look the required HW info from DTS for hardware
> initialization.
>
> Signed-off-by: Tien Fong Chee >
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> Cc: Tien Fong 
> ---
>  include/fdtdec.h |8 
>  lib/fdtdec.c |2 ++
>  2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 27887c8..68cb199 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -155,6 +155,14 @@ enum fdt_compat_id {
>   COMPAT_INTEL_BAYTRAIL_FSP_MDP,  /* Intel
> FSP
> memory-
> down params */
>   COMPAT_INTEL_IVYBRIDGE_FSP, /* Intel
> Ivy
> Bridge
> FSP
> */
>   COMPAT_SUNXI_NAND,  /* SUNXI
> NAND
> controller
> */
> + COMPAT_ALTERA_SOCFPGA_CLK,  /* SoCFPGA
> Clock
> initialization */
> + COMPAT_ALTERA_SOCFPGA_PINCTRL_SINGLE,   /
> *
> pinctrl-
> single */
> + COMPAT_ALTERA_SOCFPGA_H2F_BRG,  
> /*
> Arria10
> hps2fpga bridge */
> + COMPAT_ALTERA_SOCFPGA_LWH2F_BRG,/*
> Arria10
> lwhps2fpga bridge */
> + COMPAT_ALTERA_SOCFPGA_F2H_BRG,  
> /*
> Arria10
> fpga2hps bridge */
> + COMPAT_ALTERA_SOCFPGA_F2SDR0,   /
> *
> Arria10
> fpga2SDRAM0 bridge */
> + COMPAT_ALTERA_SOCFPGA_F2SDR1,   /
> *
> Arria10
> fpga2SDRAM1 bridge */
> + COMPAT_ALTERA_SOCFPGA_F2SDR2,   /
> *
> Arria10
> fpga2SDRAM2 bridge */
 Is all of this needed ? You're only adding two entries in
 the
 FDTDEC
 below.

>>> This is to avoid compilation error, we have some functions
>>> ported
>>> from
>>> our internal branch, which using above COMPAT macro. Soon,
>>> in
>>> upcoming
>>> patches, we will need those functions and more entries will
>>> be
>>> added
>>> into FDTDEC below.
>> You can add the compat strings when you really need them.
>> Still,
>> with
>> DM, you shouldn't even need them AFAIK.
>>
> We have some drivers in these series of patches contain some
> COMPAT
> strings, without these compact strings, the compilation would
> fail
> due
> to error compact string is not defined.
 All of them ? Mind you, with DM you should not need to add those
 at
 all.

>
>
> I think having compact string
> would giving us flexbility to put our nodes where we want
> without
> worrying to break our existing codes?
 Which existing codes ?

>>> let say we have version A, we found the node based on COMPAT
>>> STRING.
>>> One day, we move the node to somewhere else in version B, we still
>>> can
>>> find them based on COMPAT STRING without checking the node path.
>>> What
>>> do you think?
>> I do not understand what you're trying to tell me here. The DM core
>> will
>> walk the DT and bind drivers according to compat strings, so if
>> you ever move a node, it will still be bound.
>>
>> Also, you didn't answer my question -- which existing codes do you
>> refer
>> to. Or is this some hypothetical concern ?
>>
> existing codes is hypothetical example, when someone move the node
> somewhere, the DM still can find the node based on COMPAT STRING.

Correct. If you only have hypothetical concerns, we'll deal with those
when they become real.

> Without COMPAT STRING, we need to change the driver code for the node
> path right?

Uh no, the driver must never encode a fixed DT path. It should match on
the compat string and that's it. And the compat string is part of the
driver, not the FDT decoder. AFAIK, the strings in FDT decoder are just

Re: [U-Boot] [PATCH 06/10] arm: socfpga: arria10: Added drivers for Arria10 Reset Manager

On 12/19/2016 10:30 AM, Chee, Tien Fong wrote:
> On Isn, 2016-12-19 at 08:47 +0100, Marek Vasut wrote:
>> On 12/19/2016 07:53 AM, Chee, Tien Fong wrote:
>>>
>>> On Jum, 2016-12-09 at 13:51 +0100, Marek Vasut wrote:

 On 12/09/2016 11:04 AM, Chee, Tien Fong wrote:
>
>
> On Rab, 2016-12-07 at 14:58 +0100, Marek Vasut wrote:
>>
>>
>> On 12/07/2016 12:58 PM, Chee, Tien Fong wrote:
>>>
>>>
>>>
>>> On Sel, 2016-12-06 at 13:55 +0100, Marek Vasut wrote:



 On 12/06/2016 09:08 AM, Chee Tien Fong wrote:
>
>
>
>
> From: Tien Fong Chee 
>
> Drivers for reset manager is restructured such that
> common
> functions,
> gen5 drivers and Arria10 drivers are moved to
> reset_manager.c,
> reset_manager_gen5.c and reset_manager_arria10.c
> respectively.
>
> Signed-off-by: Tien Fong Chee >
> Cc: Marek Vasut 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> Cc: Tien Fong 
>> [...]
>>
>>>
>>>
>>>



>
>
>
> +void reset_deassert_dedicated_peripherals(void)
> +{
> + int i;
> + u32 mask0 = 0;
> + u32 mask1 = 0;
> + u32 pinmux_addr =
> SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS;
> + u32 mask = 0;
> +#if defined(CONFIG_MMC)
> + mask |=
> ALT_RSTMGR_PER0MODRST_SDMMCECC_SET_MSK;
> +#elif defined(CONFIG_CADENCE_QSPI)
> + mask |= ALT_RSTMGR_PER0MODRST_QSPIECC_SET_MSK;
> +#elif defined(CONFIG_NAND_DENALI)
> + mask |= ALT_RSTMGR_PER0MODRST_NANDECC_SET_MSK;
> +#else
 Shouldn't this come from OF instead of being ifdef'd ?

>>> What is OF?
>> Device Tree (Open Firmware).
>>
>>>
>>>
>>>
>>> what is your suggestion to make this function generic for
>>> all type of flash?
>> Pull it from OF ?
>>
> Why you prefer device tree implementation over #define in
> defconfig,
> because there is performance penalty.
 Because we are moving away from excessive random #defines and
 toward
 having one single binary where you could exchange just the DT and
 run
 it on multiple boards, just like Linux, that is the ultimate
 goal.

 Also, this is not performance critical code, is it.

>>> This code just to release peripherals from reset, not performance
>>> critical codes. However, our defconfigs based on flash type
>>> booting, so
>>> this is why i din't use the DT, since we have flash type determined
>>> from defconfig. Since DT is ultimate goal, i can change to DT
>>> implementation.
>> You should really only unreset the peripherals which you need and,
>> ideally, only when you need them. So it should be the driver which
>> handles the peripheral reset, not the common code (unless there is
>> a reason for the common code to do it).
>>
> Yeah, i agree with you too. Did our cyclone5 implement this also?
> Does DM has framework to support  user define reset mechanism?

The CV does it at least for ethernet . I don't think there is a
dedicated mechanism yet.

-- 
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 v3 26/26] sunxi: A64: add 32-bit SPL support

On Mon, Dec 19, 2016 at 01:50:16AM +, Andre Przywara wrote:
> When compiling the SPL for the Allwinner A64 in AArch64 mode, we can't
> use the more compact Thumb2 encoding, which only exists for AArch32
> code. This makes the SPL rather big, up to a point where any code
> additions or even a different compiler may easily exceed the 32KB limit
> that the Allwinner BROM imposes.
> Introduce a separate, mostly generic sun50i-a64 configuration, which
> defines the CPU_V7 symbol and thus will create a 32-bit binary using
> the memory-saving Thumb2 encoding.
> This should only be used for the SPL, the U-Boot proper should still be
> using the existing 64-bit configuration. The SPL code can switch to
> AArch64 if needed, so a 32-bit SPL can be combined with a 64-bit U-Boot
> proper to eventually launch arm64 kernels.
> 
> Signed-off-by: Andre Przywara 

Like I said in the previous version of those patches, I'd like to
discuss this more and not merge this patch right now.. For context,
this would be better to keep the current discussion on the v2 ongoing.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 25/26] sunxi: introduce RMR switch to enter payloads in 64-bit mode

On Mon, Dec 19, 2016 at 01:50:15AM +, Andre Przywara wrote:
> The ARMv8 capable Allwinner A64 SoC comes out of reset in AArch32 mode.
> To run AArch64 code, we have to trigger a warm reset via the RMR register,
> which proceeds with code execution at the address stored in the RVBAR
> register.
> If the bootable payload in the FIT image is using a different
> architecture than the SPL has been compiled for, enter it via this said
> RMR switch mechanism, by writing the entry point address into the MMIO
> mapped, writable version of the RVBAR register.
> Then the warm reset is triggered via a system register write.
> If the payload architecture is the same as the SPL, we use the normal
> branch as usual.
> 
> Signed-off-by: Andre Przywara 

Acked-by: Maxime Ripard 

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 21/26] sunxi: A64: enable SPL

On Mon, Dec 19, 2016 at 01:50:11AM +, Andre Przywara wrote:
> Now that the SPL is ready to be compiled in AArch64 and the DRAM
> init code is ready, enable SPL support for the A64 SoC and in the
> Pine64 defconfig.
> For now we keep the boot0 header in the U-Boot proper, as this allows
> to still use boot0 as an SPL replacement without hurting the SPL use
> case.
> We disable FEL support for now by making its compilation conditional
> and disabling it for ARM64, as the code isn't ready yet.
> 
> Signed-off-by: Andre Przywara 

Acked-by: Maxime Ripard 

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 20/26] sunxi: DRAM: fix H3 DRAM size display on aarch64

On Mon, Dec 19, 2016 at 01:50:10AM +, Andre Przywara wrote:
> Fix the output of the DRAM size on AArch64 SPLs.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Alexander Graf 
> Reviewed-by: Simon Glass 

Acked-by: Maxime Ripard 

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 19/26] sunxi: H3/A64: fix non-ODT setting

On Mon, Dec 19, 2016 at 01:50:09AM +, Andre Przywara wrote:
> According to Jens disabling the on-die-termination should set bit 5,
> not bit 1 in the respective register. Fix this.
> 
> Reported-by: Jens Kuske 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> index 6ee73ae..1bdd738 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> @@ -438,7 +438,7 @@ static int mctl_channel_init(uint16_t socid, struct 
> dram_para *para)
>   clrsetbits_le32(_ctl->dx[i].gcr, (0x3 << 4) |
>   (0x1 << 1) | (0x3 << 2) | (0x3 << 12) |
>   (0x3 << 14),
> - IS_ENABLED(CONFIG_DRAM_ODT_EN) ? 0x0 : 0x2);
> + IS_ENABLED(CONFIG_DRAM_ODT_EN) ? 0x0 : 0x20);

You should use a define here if that bit function is known.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 18/26] sunxi: A64: use H3 DRAM initialization code for A64 as well

On Mon, Dec 19, 2016 at 01:50:08AM +, Andre Przywara wrote:
> From: Jens Kuske 
> 
> The A64 DRAM controller is very similar to the H3 one,
> so the code can be reused with some small changes.
> This refactoring does not change the code size for the existing H3 part.
> 
> [Andre: rework from #ifdefs to using socid parameters in static
> functions, minor fixes, merging in fixes from Jens]
> 
> Signed-off-by: Jens Kuske 
> Signed-off-by: Andre Przywara 

Acked-by: Maxime Ripard 

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 16/26] sunxi: H3: add DRAM controller single bit delay support

On Mon, Dec 19, 2016 at 01:50:06AM +, Andre Przywara wrote:
> From: Jens Kuske 
> 
> So far the DRAM driver for the H3 SoC (and apparently boot0/libdram as
> well) only applied coarse delay line settings, with one delay value for
> all the data lines in each byte lane and one value for the control lines.
> 
> Instead of setting the delays for whole bytes only allow setting it for
> each individual bit. Also add support for address/command lane delays.
> 
> For the purpose of this patch the rules for the existing coarse settings
> were just applied to the new scheme, so the actual register writes don't
> change for the H3. Other SoCs will utilize this feature later properly.
> 
> With a stock GCC 5.3.0 this increases the dram_sun8i_h3.o code size from
> 2296 to 2344 Bytes.
> 
> [Andre: move delay parameters into macros to ease later sharing, use
>   defines for numbers of delay registers, extend commit message]
> 
> Signed-off-by: Jens Kuske 
> Signed-off-by: Andre Przywara 

I said it earlier, but some comments on these new fields would really
be welcome to document the structure and what values they're supposed
to hold.

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [U-Boot] [PATCH v3 17/26] sunxi: clocks: Use the correct pattern register for PLL11