Re: [U-Boot] [PATCH 5/8] sun8i: Display silicon revision of A83t processors

2016-05-16 Thread Chen-Yu Tsai
Hi,

On Tue, May 17, 2016 at 10:39 AM,   wrote:

Description please. How did you learn of the different revisions?
Any differences between the revisions?

> Signed-off-by: Timothy Pearson 
> ---
>  arch/arm/mach-sunxi/cpu_info.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
> index 76b6719..d552061 100644
> --- a/arch/arm/mach-sunxi/cpu_info.c
> +++ b/arch/arm/mach-sunxi/cpu_info.c
> @@ -50,6 +50,17 @@ uint sunxi_get_sram_id(void)
>
> return id;
>  }
> +
> +uint sunxi_get_revision(void)
> +{
> +   uint rev;
> +
> +   /* Unlock sram info reg, read it, relock */
> +   rev = readl(SUNXI_SRAMC_BASE + 0x24) & 0x1;
> +
> +   return rev;
> +}
> +
>  #endif
>
>  #ifdef CONFIG_DISPLAY_CPUINFO
> @@ -84,7 +95,7 @@ int print_cpuinfo(void)
>  #elif defined CONFIG_MACH_SUN8I_A33
> printf("CPU:   Allwinner A33 (SUN8I %04x)\n", sunxi_get_sram_id());
>  #elif defined CONFIG_MACH_SUN8I_A83T
> -   printf("CPU:   Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
> +   printf("CPU:   Allwinner A83T (SUN8I %04x rev. %s)\n", 
> sunxi_get_sram_id(), (sunxi_get_revision() == 0)?"A":"B");

Please wrap the line properly.

ChenYu

>  #elif defined CONFIG_MACH_SUN8I_H3
> printf("CPU:   Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
>  #elif defined CONFIG_MACH_SUN9I
> --
> 2.8.0.rc3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/8] sun8i: Add TZPC setup for A83t

2016-05-16 Thread Chen-Yu Tsai
Hi,

On Tue, May 17, 2016 at 10:39 AM,   wrote:

Description please.

> Signed-off-by: Timothy Pearson 
> ---
>  arch/arm/cpu/armv7/sunxi/Makefile  |  1 +
>  arch/arm/cpu/armv7/sunxi/tzpc.c| 10 ++
>  arch/arm/include/asm/arch-sunxi/tzpc.h | 10 ++
>  arch/arm/mach-sunxi/board.c|  2 +-
>  4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
> b/arch/arm/cpu/armv7/sunxi/Makefile
> index 4d2274a..4dd449b 100644
> --- a/arch/arm/cpu/armv7/sunxi/Makefile
> +++ b/arch/arm/cpu/armv7/sunxi/Makefile
> @@ -11,6 +11,7 @@ obj-y += timer.o
>
>  obj-$(CONFIG_MACH_SUN6I)   += tzpc.o
>  obj-$(CONFIG_MACH_SUN8I_H3)+= tzpc.o
> +obj-$(CONFIG_MACH_SUN8I_A83T)  += tzpc.o
>
>  ifndef CONFIG_SPL_BUILD
>  ifdef CONFIG_ARMV7_PSCI
> diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c
> index 6c8a0fd..7723853 100644
> --- a/arch/arm/cpu/armv7/sunxi/tzpc.c
> +++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
> @@ -24,4 +24,14 @@ void tzpc_init(void)
> writel(SUN8I_H3_TZPC_DECPORT1_ALL, >decport1_set);
> writel(SUN8I_H3_TZPC_DECPORT2_ALL, >decport2_set);
>  #endif
> +
> +#ifdef SUN8I_A83T_TZPC_DECPORT0_ALL
> +   /* Emable non-secure access to RAM */
> +   writel(R0SIZE, >r0size);

Why would you do that? That defeats the whole purpose of having the secure
monitor running in secure SRAM.

> +
> +   /* Enable non-secure access to all peripherals */
> +   writel(SUN8I_A83T_TZPC_DECPORT0_ALL, >decport0_set);
> +   writel(SUN8I_A83T_TZPC_DECPORT1_ALL, >decport1_set);
> +   writel(SUN8I_A83T_TZPC_DECPORT2_ALL, >decport2_set);
> +#endif

And move this block above H3's block.

>  }
> diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h 
> b/arch/arm/include/asm/arch-sunxi/tzpc.h
> index 95c55cd..bcf0713 100644
> --- a/arch/arm/include/asm/arch-sunxi/tzpc.h
> +++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
> @@ -29,6 +29,16 @@ struct sunxi_tzpc {
>  #define SUN8I_H3_TZPC_DECPORT1_ALL  0xff
>  #define SUN8I_H3_TZPC_DECPORT2_ALL  0x7f
>
> +#define SUN8I_A83T_TZPC_DECPORT0_ALL  0xbe
> +#define SUN8I_A83T_TZPC_DECPORT1_ALL  0x7f
> +#define SUN8I_A83T_TZPC_DECPORT2_ALL  0x10

A83T before H3.

> +
> +/*
> + * TZPC Register Value :
> + * R0SIZE: 0x10 : Size of secured ram (64Kib)
> + */
> +#define R0SIZE 0x10

Where did this come from?

> +
>  void tzpc_init(void);
>
>  #endif /* _SUNXI_TZPC_H */
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 20149da..4e0f7f9 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -183,7 +183,7 @@ void s_init(void)
> "orr r0, r0, #1 << 6\n"
> "mcr p15, 0, r0, c1, c0, 1\n");
>  #endif
> -#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
> +#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3 || defined 
> CONFIG_MACH_SUN8I_A83T

A83T comes before H3.

ChenYu

> /* Enable non-secure access to some peripherals */
> tzpc_init();
>  #endif
> --
> 2.8.0.rc3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/8] sun8i: Extend stack size to allow for up to 8 CPUs

2016-05-16 Thread Chen-Yu Tsai
Hi,

On Tue, May 17, 2016 at 10:38 AM,   wrote:
> ---
>  arch/arm/cpu/armv7/psci.S | 1 +
>  arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 4 ++--
>  arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 4 ++--
>  3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
> index 87c0c0b..18a0cc2 100644
> --- a/arch/arm/cpu/armv7/psci.S
> +++ b/arch/arm/cpu/armv7/psci.S
> @@ -203,6 +203,7 @@ ENTRY(psci_get_cpu_stack_top)
> add r5, r5, #0x2000 @ Skip two pages
> lsr r5, r5, #12 @ Align to start of page

Why not just change this line instead?

ChenYu

> lsl r5, r5, #12
> +   add r5, r5, #0x1000 @ Skip an additional page
> sub r5, r5, #4  @ reserve 1 word for target PC
> sub r0, r5, r0  @ here's our stack!
>
> diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S 
> b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
> index 90b5bfd..d35b63e 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
> +++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
> @@ -32,8 +32,8 @@
>   * ._secure_text section
>   * text_end to ALIGN_PAGE(text_end):
>   * nothing
> - * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x1000)
> - * 1kB of stack per CPU (4 CPUs max).
> + * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x2000)
> + * 1kB of stack per CPU (8 CPUs max).
>   */
>
> .pushsection ._secure.text, "ax"
> diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S 
> b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> index e15d587..b8ac50e 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> +++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
> @@ -32,8 +32,8 @@
>   * ._secure_text section
>   * text_end to ALIGN_PAGE(text_end):
>   * nothing
> - * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x1000)
> - * 1kB of stack per CPU (4 CPUs max).
> + * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x2000)
> + * 1kB of stack per CPU (8 CPUs max).
>   */
>
> .pushsection ._secure.text, "ax"
> --
> 2.8.0.rc3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [RFC PATCH] net: macb: Fix build error for CONFIG_DM_ETH enabled

2016-05-16 Thread Wenyou Yang
Use the right phy_connect() prototype for CONFIGF_DM_ETH.
Support to get the phy interface from dt and set GMAC_UR.

Signed-off-by: Wenyou Yang 
---
This patch is based on the patch set,
[PATCH 00/18] at91: Convert Ethernet and LCD to driver model
http://lists.denx.de/pipermail/u-boot/2016-May/253559.html

Hi Simon,

With this patch, the ethernet works on SAMA5D2 Xplained board.
But it includes a lot of #ifdef, I think it is not pretty.

What is your opinions?


 drivers/net/macb.c | 77 --
 1 file changed, 69 insertions(+), 8 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 63fb466..ddb9e23 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -43,6 +43,8 @@
 
 #include "macb.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #define MACB_RX_BUFFER_SIZE4096
 #define MACB_RX_RING_SIZE  (MACB_RX_BUFFER_SIZE / 128)
 #define MACB_TX_RING_SIZE  16
@@ -108,6 +110,10 @@ struct macb_device {
 #endif
unsigned short  phy_addr;
struct mii_dev  *bus;
+
+#ifdef CONFIG_DM_ETH
+   phy_interface_t phy_interface;
+#endif
 };
 #ifndef CONFIG_DM_ETH
 #define to_macb(_nd) container_of(_nd, struct macb_device, netdev)
@@ -434,7 +440,7 @@ static void macb_phy_reset(struct macb_device *macb, const 
char *name)
 }
 
 #ifdef CONFIG_MACB_SEARCH_PHY
-static int macb_phy_find(struct macb_device *macb)
+static int macb_phy_find(struct macb_device *macb, const char *name)
 {
int i;
u16 phy_id;
@@ -444,21 +450,27 @@ static int macb_phy_find(struct macb_device *macb)
macb->phy_addr = i;
phy_id = macb_mdio_read(macb, MII_PHYSID1);
if (phy_id != 0x) {
-   printf("%s: PHY present at %d\n", macb->netdev.name, i);
+   printf("%s: PHY present at %d\n", name, i);
return 1;
}
}
 
/* PHY isn't up to snuff */
-   printf("%s: PHY not found\n", macb->netdev.name);
+   printf("%s: PHY not found\n", name);
 
return 0;
 }
 #endif /* CONFIG_MACB_SEARCH_PHY */
 
-
+#ifdef CONFIG_DM_ETH
+static int macb_phy_init(struct udevice *dev, const char *name)
+#else
 static int macb_phy_init(struct macb_device *macb, const char *name)
+#endif
 {
+#ifdef CONFIG_DM_ETH
+   struct macb_device *macb = dev_get_priv(dev);
+#endif
 #ifdef CONFIG_PHYLIB
struct phy_device *phydev;
 #endif
@@ -470,7 +482,7 @@ static int macb_phy_init(struct macb_device *macb, const 
char *name)
arch_get_mdio_control(name);
 #ifdef CONFIG_MACB_SEARCH_PHY
/* Auto-detect phy_addr */
-   if (!macb_phy_find(macb))
+   if (!macb_phy_find(macb, name))
return 0;
 #endif /* CONFIG_MACB_SEARCH_PHY */
 
@@ -482,9 +494,14 @@ static int macb_phy_init(struct macb_device *macb, const 
char *name)
}
 
 #ifdef CONFIG_PHYLIB
+#ifdef CONFIG_DM_ETH
+   phydev = phy_connect(macb->bus, macb->phy_addr, dev,
+macb->phy_interface);
+#else
/* need to consider other phy interface mode */
phydev = phy_connect(macb->bus, macb->phy_addr, >netdev,
 PHY_INTERFACE_MODE_RGMII);
+#endif
if (!phydev) {
printf("phy_connect failed\n");
return -ENODEV;
@@ -585,8 +602,15 @@ static int gmac_init_multi_queues(struct macb_device *macb)
return 0;
 }
 
+#ifdef CONFIG_DM_ETH
+static int _macb_init(struct udevice *dev, const char *name)
+#else
 static int _macb_init(struct macb_device *macb, const char *name)
+#endif
 {
+#ifdef CONFIG_DM_ETH
+   struct macb_device *macb = dev_get_priv(dev);
+#endif
unsigned long paddr;
int i;
 
@@ -634,13 +658,35 @@ static int _macb_init(struct macb_device *macb, const 
char *name)
 * When the GMAC IP without GE feature, this bit is used
 * to select interface between RMII and MII.
 */
+#ifdef CONFIG_DM_ETH
+   if (macb->phy_interface == PHY_INTERFACE_MODE_RMII)
+   gem_writel(macb, UR, GEM_BIT(RGMII));
+   else
+   gem_writel(macb, UR, 0);
+#else
 #if defined(CONFIG_RGMII) || defined(CONFIG_RMII)
gem_writel(macb, UR, GEM_BIT(RGMII));
 #else
gem_writel(macb, UR, 0);
 #endif
+#endif
} else {
/* choose RMII or MII mode. This depends on the board */
+#ifdef CONFIG_DM_ETH
+#ifdef CONFIG_AT91FAMILY
+   if (macb->phy_interface == PHY_INTERFACE_MODE_RMII) {
+   macb_writel(macb, USRIO,
+   MACB_BIT(RMII) | MACB_BIT(CLKEN));
+   } else {
+   macb_writel(macb, USRIO, MACB_BIT(CLKEN));
+   }
+#else
+   if (macb->phy_interface == PHY_INTERFACE_MODE_RMII)
+   

Re: [U-Boot] [PATCH 2/8] sun8i: Add CCI-400 definitions

2016-05-16 Thread Chen-Yu Tsai
Hi,

On Tue, May 17, 2016 at 10:38 AM,   wrote:

A commit message would be nice.

> Signed-off-by: Timothy Pearson 
> ---
>  arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
> b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> index 65c0441..76da00f 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
> @@ -18,6 +18,9 @@
>  #define SUNXI_SRAM_D_BASE  0x0001  /* 4 kiB */
>  #define SUNXI_SRAM_B_BASE  0x0002  /* 64 kiB (secure) */
>
> +#define SUN8I_CPUXCFG_BASE 0x0170
> +#define SUN8I_CCI400_BASE  0x0179

Please use SUNXI_ prefix. We can potentially add A80 support later on
using the same macro names.

> +
>  #define SUNXI_SRAMC_BASE   0x01c0
>  #define SUNXI_DRAMC_BASE   0x01c01000
>  #define SUNXI_DMA_BASE 0x01c02000
> @@ -168,6 +171,10 @@
>  #define SUNXI_SS_BOND_ID_A31   4
>  #define SUNXI_SS_BOND_ID_A31S  5
>
> +#define CCI400_DVM_MESSAGE_REQ_EN  0x0002
> +#define CCI400_SNOOP_REQ_EN0x0001
> +#defineCCI400_SHAORD_NON_SHAREABLE 0x0002

_SHA_ORD_ would be better as the original name is "Shareable Override
Register".

> +

CCI-400 is a standard IP block from ARM. Please move the
definitions to a separate, shared header, preferably under
arch/arm/include/asm/.

ChenYu

>  #ifndef __ASSEMBLY__
>  void sunxi_board_init(void);
>  void sunxi_reset(void);
> --
> 2.8.0.rc3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] arm: rmobile: Fix HDMI output for BLANCHE board

2016-05-16 Thread masakazu.mochizuki.wd
This commit fixes HDMI output for BLANCHE board

Signed-off-by: Masakazu Mochizuki 
---
 board/renesas/blanche/blanche.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/board/renesas/blanche/blanche.c b/board/renesas/blanche/blanche.c
index 717c169..b2e2e3b 100644
--- a/board/renesas/blanche/blanche.c
+++ b/board/renesas/blanche/blanche.c
@@ -36,8 +36,23 @@ struct pin_db {
 };
 
 #definePMMR0xE606
+#defineGPSR0   0xE6060004
+#defineGPSR1   0xE6060008
+#defineGPSR4   0xE6060014
+#defineGPSR5   0xE6060018
+#defineGPSR6   0xE606001C
+#defineGPSR7   0xE6060020
+#defineGPSR8   0xE6060024
+#defineGPSR9   0xE6060028
 #defineGPSR10  0xE606002C
+#defineGPSR11  0xE6060030
+#defineIPSR6   0xE6060058
+#definePUPR2   0xE6060108
 #definePUPR3   0xE606010C
+#definePUPR4   0xE6060110
+#definePUPR5   0xE6060114
+#definePUPR7   0xE606011C
+#definePUPR9   0xE6060124
 #definePUPR10  0xE6060128
 #definePUPR11  0xE606012C
 
@@ -56,11 +71,26 @@ struct pin_db {
 }
 
 struct pin_db  pin_guard[] = {
+   { GPSR0,0x, 0x0BFF },
+   { GPSR1,0x, 0x002F },
+   { GPSR4,0x, 0x0FFF },
+   { GPSR5,0x, 0x00010FFF },
+   { GPSR6,0x, 0x00010FFF },
+   { GPSR7,0x, 0x00010FFF },
+   { GPSR8,0x, 0x00010FFF },
+   { GPSR9,0x, 0x00010FFF },
{ GPSR10,   0x, 0x04006000 },
+   { GPSR11,   0x, 0x303FEFE0 },
+   { IPSR6,0x, 0x0002000E },
 };
 
 struct pin_db  pin_tbl[] = {
+   { PUPR2,0x, 0x },
{ PUPR3,0x, 0x0803FF40 },
+   { PUPR4,0x, 0x },
+   { PUPR5,0x, 0x00010FFF },
+   { PUPR7,0x, 0x0001AFFF },
+   { PUPR9,0x, 0x0001CFFF },
{ PUPR10,   0x, 0xC0438001 },
{ PUPR11,   0x, 0x0FC7 },
 };
-- 
2.1.4

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


Re: [U-Boot] [PATCH v2 00/25] exynos: video: Convert exynos LCD driver to use driver model

2016-05-16 Thread Minkyu Kang
Hi,

On 17/05/16 13:22, Jaehoon Chung wrote:
> Hi Simon.
> 
> On 05/15/2016 06:22 AM, Simon Glass wrote:
>> Hi Jaehoon,
>>
>> On 13 May 2016 at 07:09, Jaehoon Chung  wrote:
>>> Hi Simon,
>>>
>>> On 05/09/2016 08:00 PM, Minkyu Kang wrote:
 Hi Jaehoon,

 On 08/05/16 06:25, Simon Glass wrote:
> Hi,
>
> On 1 March 2016 at 18:51, Minkyu Kang  wrote:
>> Hi,
>>
>> On 29/02/16 16:18, Jaehoon Chung wrote:
>>> Hi,
>>>
>>> On 02/29/2016 01:23 PM, Simon Glass wrote:
 Hi,

 On 23 February 2016 at 05:04, Minkyu Kang  wrote:
> Dear Simon Glass,
>
> On 23/02/16 15:42, Simon Glass wrote:
>> Hi Minkyu,
>>
>> On 21 February 2016 at 21:08, Simon Glass  wrote:
>>>
>>> This series converts the exynos LCD driver to work with driver 
>>> model. Only
>>> the eDP display is converted - the MIPI display is left mostly 
>>> alone as I
>>> do not have a device to test with.
>>>
>>> The conversion involves some refactoring to simplify the code, 
>>> reduce the
>>> amount of global/static data and allow boards to be built without 
>>> LCD
>>> support.
>>>
>>> The series is tested with snow, spring, pit and pi. It disables LCD 
>>> on other
>>> exynos boards so that they will still build with these changes. 
>>> Further work
>>> will be needed (by someone with a board) to convert the others. I 
>>> am not
>>> sure when this series can be applied.
>>>
>>> The series also brings in device tree features from Linux v4.4. It 
>>> would be
>>> useful to do a full sync with the kernel on these files, but this 
>>> is really
>>> a job for the Samsung maintainer :-)
>>>
>>> The series is available at u-boot-dm/rkg-working.
>>>
>>> Changes in v2:
>>> - Rebase to master
>>> - Rebase to master
>>>
>>
>> What do you think we should do about applying this series?
>>
>
> Although we have to do remaining work, I think applying is possible 
> without next work.
>
> Board maintainers, what do you think?
>
> Remaining Work:
> - MIPI display driver
> - s5pc210_universal
> - smdk5420
> - smdk5250
> - trats
> - trats2
>
> Thanks,
> Minkyu Kang.

 Well, no replies as yet. The main work requires is MIPI, but as I
 don't have the hardware, I can't help with that. At least I have made
 sure that everything builds OK.
>>>
>>> Sorry for late..I will check these patches on this week..Tomorrow is 
>>> holiday..
>>> So I can check from Wed.
>>
>> Thank you, Jaehoon.
>
> It has been a few months now - if you like I can apply these via the -dm 
> tree.
>>>
>>> Yep, I checked these..It needs to remain the future work.
>>> But it seems that it's not problem to apply at -dm repository.
>>> (I have checked with your patch on other boadrs.)
>>>
>>> I needs to check one more things..Could you wait until next Tuesday?
>>>
>>
>> Sure, it's been 3 months so another week won't matter :-)
> 
> Sorry. I have checked more with these patches..We have to work too many 
> things in future for remaining work.
> But it seems those task are our role..If you and Minkyu are ok, you can apply 
> these at dm repository.

I'm OK.
If you want, those can be merged to samsung tree.

> 
> I will make a plan to work. (Based on your repository.)
> 
> Actually, i didn't follow a few month, so i'm looking for u-boot history. 
> Sorry. :(
> If you want to add my Reviewed-by tag, then you can add.
> 
> In future work,
> Change to driver model for above targets. (trats2/trats...)
> MIPI display driver..(I will assign to my colleague for this task.)
> 

Thank you!

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


[U-Boot] [PATCH 6/8] sunxi: Add optional logic to start cluster 1 and the associated CCI-400 ports

2016-05-16 Thread tpearson
Signed-off-by: Timothy Pearson 
---
 arch/arm/include/asm/arch-sunxi/prcm.h |  3 ++-
 board/sunxi/board.c| 49 ++
 2 files changed, 51 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-sunxi/prcm.h 
b/arch/arm/include/asm/arch-sunxi/prcm.h
index 556c1af..9e8a367 100644
--- a/arch/arm/include/asm/arch-sunxi/prcm.h
+++ b/arch/arm/include/asm/arch-sunxi/prcm.h
@@ -219,7 +219,8 @@ struct sunxi_prcm_reg {
u32 clk_outd;   /* 0x0f0 */
u8 res6[0xc];   /* 0x0f4 */
u32 cpu_pwroff; /* 0x100 */
-   u8 res7[0xc];   /* 0x104 */
+   u32 cluster1_cpu_pwr;   /* 0x104 */
+   u8 res7[0x8];   /* 0x108 */
u32 vdd_sys_pwroff; /* 0x110 */
u8 res8[0x4];   /* 0x114 */
u32 gpu_pwroff; /* 0x118 */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 3cf3614..65029ab 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifndef CONFIG_ARM64
 #include 
@@ -30,6 +31,18 @@
 #include 
 #include 

+/* CCI-400 registers */
+struct cci400_control {
+   uint32_t unused0[0x3];
+   uint32_t status;
+   uint32_t unused1[0xffc];
+   uint32_t snoop_ctrl_a7;
+   uint32_t sha_ord_a7;
+   uint32_t unused2[0x3fe];
+   uint32_t snoop_ctrl_a15;
+   uint32_t sha_ord_a15;
+};
+
 #if defined CONFIG_VIDEO_LCD_PANEL_I2C && !(defined CONFIG_SPL_BUILD)
 /* So that we can use pin names in Kconfig and sunxi_name_to_gpio() */
 int soft_i2c_gpio_sda;
@@ -122,6 +135,42 @@ int board_init(void)
gpio_direction_output(CONFIG_MACPWR, 1);
 #endif

+#ifdef CONFIG_ENABLE_CLUSTER_1
+struct sunxi_prcm_reg *prcm =
+   (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+   clrbits_le32(>cluster1_cpu_pwr, 0x1);
+#endif
+
+#ifdef CONFIG_ENABLE_CCI400_SNOOP_CLUSTERS_0_1
+   printf("Enabling snoop controls...");
+   struct cci400_control *cci = (struct cci400_control *)SUN8I_CCI400_BASE;
+   uint32_t snoop_ctl;
+
+   /* Set up cluster 0 CCI port */
+   snoop_ctl = readl(>snoop_ctrl_a7);
+   snoop_ctl |= CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN;
+   writel(snoop_ctl, >snoop_ctrl_a7);
+
+   /* Wait for snoop control change to take effect */
+   while (readl(>status) & 0x1);
+
+   /* Set up cluster 1 CCI port */
+   snoop_ctl = readl(>snoop_ctrl_a15);
+   snoop_ctl |= CCI400_DVM_MESSAGE_REQ_EN | CCI400_SNOOP_REQ_EN;
+   writel(snoop_ctl, >snoop_ctrl_a15);
+
+   /* Wait for snoop control change to take effect */
+   while (readl(>status) & 0x1);
+
+   /* Force non-sharable memory */
+   writel(CCI400_SHAORD_NON_SHAREABLE, >sha_ord_a7);
+   writel(CCI400_SHAORD_NON_SHAREABLE, >sha_ord_a15);
+
+   /* Synchronize CCI enable */
+   __asm__ volatile ("dsb\n");
+   printf("done!\n");
+#endif
+
/* Uses dm gpio code so do this here and not in i2c_init_board() */
return soft_i2c_board_init();
 }
-- 
2.8.0.rc3

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


[U-Boot] [PATCH 8/8] a83t: Enable PSCI, non-secure mode, and cluster / cache setup

2016-05-16 Thread tpearson
Signed-off-by: Timothy Pearson 
---
 board/sunxi/Kconfig | 13 +
 1 file changed, 13 insertions(+)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index fa78720..4b82d3d 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -85,8 +85,13 @@ config MACH_SUN50I
 config MACH_SUN8I_A83T
bool "sun8i (Allwinner A83T)"
select CPU_V7
+   select CPU_V7_HAS_NONSEC
+   select CPU_V7_HAS_VIRT
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+   select ENABLE_CLUSTER_1
+   select ENABLE_CCI400_SNOOP_CLUSTERS_0_1
+   select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

 config MACH_SUN9I
bool "sun9i (Allwinner A80)"
@@ -623,4 +628,12 @@ config SPL_STACK_R_ADDR
default 0x4fe0 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || 
MACH_SUN7I || MACH_SUN8I || MACH_SUN50I
default 0x2fe0 if MACH_SUN9I

+config ENABLE_CLUSTER_1
+   bool
+   default n
+
+config ENABLE_CCI400_SNOOP_CLUSTERS_0_1
+   bool
+   default n
+
 endif
-- 
2.8.0.rc3

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


[U-Boot] [PATCH 7/8] sun8i: Enable PSCI cpu_on support for A83t

2016-05-16 Thread tpearson
Signed-off-by: Timothy Pearson 
---
 arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 174 --
 1 file changed, 164 insertions(+), 10 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S 
b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
index d35b63e..b3090ec 100644
--- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
+++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
@@ -21,6 +21,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -45,6 +46,16 @@
 #defineGICD_BASE   0x1c81000
 #defineGICC_BASE   0x1c82000

+@ Attempts to condense sparse ID space on multi-cluster systems to dense ID 
space
+ENTRY(psci_get_cpu_id)
+   mrc p15, 0, r0, c0, c0, 5   /* read MPIDR */
+   lsr r1, r0, #6  /* extract cluster offset */
+   and r1, r1, #0xff
+   and r0, r0, #0xff   /* extract CPU ID in cluster */
+   add r0, r0, r1  /* return adjusted CPU ID */
+   bx  lr
+ENDPROC(psci_get_cpu_id)
+
 .globl psci_fiq_enter
 psci_fiq_enter:
push{r0-r12}
@@ -106,7 +117,7 @@ psci_fiq_enter:
str r10, [r8, #0x100]
timer_wait r10, ONE_MS

-#if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I_H3)
+#if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I_H3) || 
defined(CONFIG_MACH_SUN8I_A83T)
@ Activate power clamp
lsl r12, r9, #2 @ x4
add r12, r12, r8
@@ -134,7 +145,13 @@ out:   mcr p15, 0, r7, c1, c1, 0
 psci_cpu_on:
push{lr}

-   mov r0, r1
+#if defined(CONFIG_MACH_SUN8I_A83T)
+   lsr r3, r1, #6  @ extract cluster offset
+   and r0, r1, #3  @ extract CPU number
+   add r0, r0, r3  @ pass adjusted CPU number to setup
+#else
+   mov r0, r1  @ pass CPU number to setup
+#endif
bl  psci_get_cpu_stack_top  @ get stack top of target CPU
str r2, [r0]@ store target PC at stack top
dsb
@@ -142,15 +159,74 @@ psci_cpu_on:
movwr0, #(SUN6I_CPUCFG_BASE & 0x)
movtr0, #(SUN6I_CPUCFG_BASE >> 16)

+   ldr r6, =psci_cpu_entry
+   str r6, [r0, #0x1a4] @ PRIVATE_REG (boot vector)
+
@ CPU mask
+#if defined(CONFIG_MACH_SUN8I_A83T)
+   lsr r3, r1, #8  @ extract cluster number
+   and r1, r1, #3  @ extract CPU number
+
+   @ obtain silicon revision level
+   movwr0, #(SUNXI_SRAMC_BASE & 0x)
+   movtr0, #(SUNXI_SRAMC_BASE >> 16)
+   ldr r2, [r0, #0x24]
+   and r2, r2, #0x1
+#else
+   ldr r3, #0  @ only one cluster
and r1, r1, #3  @ only care about first cluster
+   ldr r2, #0  @ default revision
+#endif
mov r4, #1
lsl r4, r4, r1

-   ldr r6, =psci_cpu_entry
-   str r6, [r0, #0x1a4] @ PRIVATE_REG (boot vector)
-
@ Assert reset on target CPU
+#if defined(CONFIG_MACH_SUN8I_A83T)
+   movwr0, #(SUN8I_CPUXCFG_BASE & 0x)
+   movtr0, #(SUN8I_CPUXCFG_BASE >> 16)
+
+   lsl r5, r3, #2  @ cluster offset
+   add r5, r5, #0x80   @ SUNXI_CPU_RST_CTRL
+   ldr r6, [r0, r5]
+   bic r6, r6, r4  @ assert reset
+   str r6, [r0, r5]
+
+   cmp r1, #0
+   bne skip_cluster_reset_assert
+
+   lsl r5, r3, #4  @ cluster offset
+   add r5, r5, #0x04   @ SUNXI_CLUSTER_CTRL1
+   ldr r6, [r0, r5]
+   orr r6, r6, #0x1@ assert ACINACTM
+   str r6, [r0, r5]
+
+   lsl r5, r3, #2  @ cluster offset
+   add r5, r5, #0x80   @ SUNXI_CPU_RST_CTRL
+   ldr r6, [r0, r5]
+   bic r6, r6, #0x1000 @ assert HRESET
+   bic r6, r6, #0x100  @ assert L2 cache reset
+   str r6, [r0, r5]
+skip_cluster_reset_assert:
+
+   @ re-calculate CPU control register address
+   movwr0, #(SUN6I_CPUCFG_BASE & 0x)
+   movtr0, #(SUN6I_CPUCFG_BASE >> 16)
+
+   lsl r5, r3, #2  @ cluster offset
+   add r5, r5, #0x30   @ SUNXI_CLUSTER_PWRON_RESET
+   ldr r6, [r0, r5]
+   bic r6, r6, r4  @ assert reset
+   str r6, [r0, r5]
+
+   movwr0, #(SUN8I_CPUXCFG_BASE & 0x)
+   movtr0, #(SUN8I_CPUXCFG_BASE >> 16)
+
+   @ l1 invalidate
+   lsl r5, r3, #4  @ calculate cluster offset
+   ldr r6, [r0, r5]@ CX_CTRL_REG0
+   bic r6, r6, r4
+   str r6, [r0, r5]
+#else
mov r6, #0
lsl r5, r1, #6  @ 64 bytes per CPU
add r5, r5, #0x40   @ Offset from base
@@ -166,32 +242,109 @@ psci_cpu_on:
ldr r6, [r0, #0x1e4] @ CPUCFG_DBG_CTL1_REG
bic r6, r6, r4
str r6, [r0, #0x1e4]
+#endif

movwr0, #(SUNXI_PRCM_BASE & 0x)
movtr0, #(SUNXI_PRCM_BASE >> 16)


[U-Boot] [PATCH 5/8] sun8i: Display silicon revision of A83t processors

2016-05-16 Thread tpearson
Signed-off-by: Timothy Pearson 
---
 arch/arm/mach-sunxi/cpu_info.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index 76b6719..d552061 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -50,6 +50,17 @@ uint sunxi_get_sram_id(void)

return id;
 }
+
+uint sunxi_get_revision(void)
+{
+   uint rev;
+
+   /* Unlock sram info reg, read it, relock */
+   rev = readl(SUNXI_SRAMC_BASE + 0x24) & 0x1;
+
+   return rev;
+}
+
 #endif

 #ifdef CONFIG_DISPLAY_CPUINFO
@@ -84,7 +95,7 @@ int print_cpuinfo(void)
 #elif defined CONFIG_MACH_SUN8I_A33
printf("CPU:   Allwinner A33 (SUN8I %04x)\n", sunxi_get_sram_id());
 #elif defined CONFIG_MACH_SUN8I_A83T
-   printf("CPU:   Allwinner A83T (SUN8I %04x)\n", sunxi_get_sram_id());
+   printf("CPU:   Allwinner A83T (SUN8I %04x rev. %s)\n", 
sunxi_get_sram_id(), (sunxi_get_revision() == 0)?"A":"B");
 #elif defined CONFIG_MACH_SUN8I_H3
printf("CPU:   Allwinner H3 (SUN8I %04x)\n", sunxi_get_sram_id());
 #elif defined CONFIG_MACH_SUN9I
-- 
2.8.0.rc3

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


[U-Boot] [PATCH 1/8] sun8i: Add A83t SMP definitions

2016-05-16 Thread tpearson
Signed-off-by: Timothy Pearson 
---
 include/configs/sun8i.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
index b9a8731..b239548 100644
--- a/include/configs/sun8i.h
+++ b/include/configs/sun8i.h
@@ -26,7 +26,6 @@
#define CONFIG_SUNXI_USB_PHYS   2
 #endif

-#ifndef CONFIG_MACH_SUN8I_A83T
 #define CONFIG_ARMV7_PSCI  1
 #if defined(CONFIG_MACH_SUN8I_A23)
 #define CONFIG_ARMV7_PSCI_NR_CPUS  2
@@ -34,10 +33,12 @@
 #define CONFIG_ARMV7_PSCI_NR_CPUS  4
 #elif defined(CONFIG_MACH_SUN8I_H3)
 #define CONFIG_ARMV7_PSCI_NR_CPUS  4
+#elif defined(CONFIG_MACH_SUN8I_A83T)
+#define CONFIG_ARMV7_PSCI_NR_CPUS  8
+#define CONFIG_ARMV7_SECURE_BASE   SUNXI_SRAM_B_BASE
 #else
 #error Unsupported sun8i variant
 #endif
-#endif

 /*
  * Include common sunxi configuration where most the settings are
-- 
2.8.0.rc3

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


[U-Boot] [RFC] [PATCH 0/8] a83t: Add initial PSCI / SMP support

2016-05-16 Thread tpearson
This is an intial series aimed at getting non-secure mode for virtualization to 
work on the Allwinner A83t devices. 
This series adds PSCI support along with a few other other low-level 
initialization routines and boots the mainline
kernel enough to detect 8 started SMP cores / threads.  Unfortunately the 
mainline kernel appears to have other issues
with timers so this could not be tested further, however it is hoped that with 
proper u-boot PSCI support the kernel
developers will be able to work on SMP support for these SoCs.

This is a first rough draft; in particular the WFI PSCI state has not been 
updated for the new device.  Comments on
the overall approach are welcome!

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


[U-Boot] [PATCH 4/8] sun8i: Add TZPC setup for A83t

2016-05-16 Thread tpearson
Signed-off-by: Timothy Pearson 
---
 arch/arm/cpu/armv7/sunxi/Makefile  |  1 +
 arch/arm/cpu/armv7/sunxi/tzpc.c| 10 ++
 arch/arm/include/asm/arch-sunxi/tzpc.h | 10 ++
 arch/arm/mach-sunxi/board.c|  2 +-
 4 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index 4d2274a..4dd449b 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += timer.o

 obj-$(CONFIG_MACH_SUN6I)   += tzpc.o
 obj-$(CONFIG_MACH_SUN8I_H3)+= tzpc.o
+obj-$(CONFIG_MACH_SUN8I_A83T)  += tzpc.o

 ifndef CONFIG_SPL_BUILD
 ifdef CONFIG_ARMV7_PSCI
diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c
index 6c8a0fd..7723853 100644
--- a/arch/arm/cpu/armv7/sunxi/tzpc.c
+++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
@@ -24,4 +24,14 @@ void tzpc_init(void)
writel(SUN8I_H3_TZPC_DECPORT1_ALL, >decport1_set);
writel(SUN8I_H3_TZPC_DECPORT2_ALL, >decport2_set);
 #endif
+
+#ifdef SUN8I_A83T_TZPC_DECPORT0_ALL
+   /* Emable non-secure access to RAM */
+   writel(R0SIZE, >r0size);
+
+   /* Enable non-secure access to all peripherals */
+   writel(SUN8I_A83T_TZPC_DECPORT0_ALL, >decport0_set);
+   writel(SUN8I_A83T_TZPC_DECPORT1_ALL, >decport1_set);
+   writel(SUN8I_A83T_TZPC_DECPORT2_ALL, >decport2_set);
+#endif
 }
diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h 
b/arch/arm/include/asm/arch-sunxi/tzpc.h
index 95c55cd..bcf0713 100644
--- a/arch/arm/include/asm/arch-sunxi/tzpc.h
+++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
@@ -29,6 +29,16 @@ struct sunxi_tzpc {
 #define SUN8I_H3_TZPC_DECPORT1_ALL  0xff
 #define SUN8I_H3_TZPC_DECPORT2_ALL  0x7f

+#define SUN8I_A83T_TZPC_DECPORT0_ALL  0xbe
+#define SUN8I_A83T_TZPC_DECPORT1_ALL  0x7f
+#define SUN8I_A83T_TZPC_DECPORT2_ALL  0x10
+
+/*
+ * TZPC Register Value :
+ * R0SIZE: 0x10 : Size of secured ram (64Kib)
+ */
+#define R0SIZE 0x10
+
 void tzpc_init(void);

 #endif /* _SUNXI_TZPC_H */
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 20149da..4e0f7f9 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -183,7 +183,7 @@ void s_init(void)
"orr r0, r0, #1 << 6\n"
"mcr p15, 0, r0, c1, c0, 1\n");
 #endif
-#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
+#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3 || defined 
CONFIG_MACH_SUN8I_A83T
/* Enable non-secure access to some peripherals */
tzpc_init();
 #endif
-- 
2.8.0.rc3

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


[U-Boot] [PATCH 2/8] sun8i: Add CCI-400 definitions

2016-05-16 Thread tpearson
Signed-off-by: Timothy Pearson 
---
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 65c0441..76da00f 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -18,6 +18,9 @@
 #define SUNXI_SRAM_D_BASE  0x0001  /* 4 kiB */
 #define SUNXI_SRAM_B_BASE  0x0002  /* 64 kiB (secure) */

+#define SUN8I_CPUXCFG_BASE 0x0170
+#define SUN8I_CCI400_BASE  0x0179
+
 #define SUNXI_SRAMC_BASE   0x01c0
 #define SUNXI_DRAMC_BASE   0x01c01000
 #define SUNXI_DMA_BASE 0x01c02000
@@ -168,6 +171,10 @@
 #define SUNXI_SS_BOND_ID_A31   4
 #define SUNXI_SS_BOND_ID_A31S  5

+#define CCI400_DVM_MESSAGE_REQ_EN  0x0002
+#define CCI400_SNOOP_REQ_EN0x0001
+#defineCCI400_SHAORD_NON_SHAREABLE 0x0002
+
 #ifndef __ASSEMBLY__
 void sunxi_board_init(void);
 void sunxi_reset(void);
-- 
2.8.0.rc3

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


[U-Boot] [PATCH 3/8] sun8i: Extend stack size to allow for up to 8 CPUs

2016-05-16 Thread tpearson
---
 arch/arm/cpu/armv7/psci.S | 1 +
 arch/arm/cpu/armv7/sunxi/psci_sun6i.S | 4 ++--
 arch/arm/cpu/armv7/sunxi/psci_sun7i.S | 4 ++--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/psci.S b/arch/arm/cpu/armv7/psci.S
index 87c0c0b..18a0cc2 100644
--- a/arch/arm/cpu/armv7/psci.S
+++ b/arch/arm/cpu/armv7/psci.S
@@ -203,6 +203,7 @@ ENTRY(psci_get_cpu_stack_top)
add r5, r5, #0x2000 @ Skip two pages
lsr r5, r5, #12 @ Align to start of page
lsl r5, r5, #12
+   add r5, r5, #0x1000 @ Skip an additional page
sub r5, r5, #4  @ reserve 1 word for target PC
sub r0, r5, r0  @ here's our stack!

diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S 
b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
index 90b5bfd..d35b63e 100644
--- a/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
+++ b/arch/arm/cpu/armv7/sunxi/psci_sun6i.S
@@ -32,8 +32,8 @@
  * ._secure_text section
  * text_end to ALIGN_PAGE(text_end):
  * nothing
- * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x1000)
- * 1kB of stack per CPU (4 CPUs max).
+ * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x2000)
+ * 1kB of stack per CPU (8 CPUs max).
  */

.pushsection ._secure.text, "ax"
diff --git a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S 
b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
index e15d587..b8ac50e 100644
--- a/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
+++ b/arch/arm/cpu/armv7/sunxi/psci_sun7i.S
@@ -32,8 +32,8 @@
  * ._secure_text section
  * text_end to ALIGN_PAGE(text_end):
  * nothing
- * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x1000)
- * 1kB of stack per CPU (4 CPUs max).
+ * ALIGN_PAGE(text_end) to ALIGN_PAGE(text_end) + 0x2000)
+ * 1kB of stack per CPU (8 CPUs max).
  */

.pushsection ._secure.text, "ax"
-- 
2.8.0.rc3

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


Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

2016-05-16 Thread Peter Newton
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, May 16, 2016 7:21 AM
> To: Bhupesh Sharma ; Amit Tomer 
> 
> Cc: york sun ; u-boot@lists.denx.de; Peter Newton 
> 
> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> 
> 
> 
> On 16.05.16 14:04, Bhupesh Sharma wrote:
> >
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Monday, May 16, 2016 1:09 PM
> >> To: Amit Tomer 
> >> Cc: Bhupesh Sharma ; york sun
> >> ; u-boot@lists.denx.de; Peter Newton
> >> 
> >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> >>
> >>
> >>
> >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer :
> >>>
>  On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
> >>  wrote:
>  Note that UEFI firmware support is already available on LS2080A-RDB
>  and allows Booting distributions like CentOS on the same.
> >>>
> >>> Sorry to intervene here but it's about having the EFI support inside
> >>> u-boot itself that may *not* required to have separate UEFI firmware
> >>> to boot various distributions.
> >>>
> >>> Please correct, if it's not right ?
> >>
> >> It's correct. The idea is to allow everyone to boot using the uEFI
> >> entry point in Linux (or any other OS), regardless of whether they
> >> want to run U-Boot or a TianoCore based formware.
> >>
> >> This might seem useless today for embedded use cases, but some
> >> features are only available via an EFI entry, such as kASLR. You can
> >> also invoke Linux directly using the "bootefi" command, as Linux is
> >> an EFI binary itself. That way the boot path doesn't become much
> >> longer than with booti today.
> >>
> >
> > The default firmware being offered by NXP to boot distros on LS2080A and 
> > variants is UEFI.
> >
> > EFI application support in u-boot doesn't present a solution to things
> > like run-time variable/service support that is required by distros to
> > update firmware components on the go. And there are several other
> > services being offered by UEFI to help distro boot e.g. secure uefi boot 
> > through x.509 certifications compliant to UEFI specifications.
> 
> Don't get me wrong - I think it's great if there is a TianoCore based 
> firmware for LS2080A. But I didn't get the impression that there is a
> TianoCore based firmware for every NXP SoC out there, so enabling all of them 
> to use the U-Boot provided uEFI implementation is still
> a win.
> 
> That said, there's nothing that keeps us from implementing the bits you 
> mentioned in U-Boot either. There is support for RTS in U-
> Boot, we just didn't convert any drivers (RTC comes to mind first) yet.
> 
> There's also no support for uEFI environment variables, but mostly because 
> most systems I've used this code on so far just didn't have
> any storage to put them.
> 
> Certification checks also shouldn't be an issue if someone cared enough about 
> them.
> 
> But I don't think we need a discussion of TianoCore vs U-Boot. What everyone 
> really wants is to have things "just work". And some
> customers just prefer U-Boot for various reasons that are outside of my 
> control.
> If they can run the same boot path as everyone else, it makes life for me as 
> distribution vendor easier. And unlike other people in the
> community, I don't think being a TianoCore+ACPI messiah is any helpful for 
> that goal.

Agreed, this should not become a U-Boot vs UEFI thread.  And just to be sure it 
is clear to everyone, NXP currently offers both U-Boot and is starting to have 
UEFI firmware releases also.  We are not dropping U-Boot just because we begin 
to have UEFI.



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


[U-Boot] Altera Cyclone 5 UART Communication Issues - U-Boot 2016.03

2016-05-16 Thread Nathan Barrett
Hello All,

I'm currently running U-Boot 2016.03 on a Terasic SoC Kit without any apparent 
issues.

However, when I go to run the same build on our custom board, the debug port's 
UART0 RXD fails to receive any key presses when I'm attempting to stop autoboot.

On both boards, the debug UART0 TX and RX lines are using the same pins for.  
The only difference between the boards is that our custom board is routing the 
UART TX and RX lines through the FPGA fabric.

I'm making sure to start up the FPGA with these few additional lines in the 
boot sequence:

#fatload mmc 0:${mmcloadpart} 0x200 soc_system.rbf; fpga load 0 0x200 
0x23C1B4;

I can tell that the FPGA does seem to be running fine, as the UART TX is coming 
through (I see all the proper boot info) and an FPGA controlled heartbeat LED 
starts blinking.


Does anyone have any insight into what could be going on?


Thank you,

Nathan Barrett

confidentiality: This e-mail and its attachments are intended 
for the above named only and may be confidential. If they have 
come to you in error you must take no action based on them, nor 
must you copy or show them to anyone; please reply to this e-
mail and highlight the error. 

Security Warning: Please note that this e-mail has been created
in the knowledge that Internet e-mail is not a 100% secure
communications medium. We advise that you understand and observe
this lack of security when e-mailing us. Viruses: Although we
have taken steps to ensure that this e-mail and attachments are
free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually
virus free.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] askenv with timeout?

2016-05-16 Thread Eugeniu Rosca
Hi everyone,

Recently I got the need to read some environment variable from stdin, as
user input. So, I discovered the 'askenv' command. One additional
requirement I have is avoiding any blocking behavior, which would be
possible if askenv supported the timeout concept. However, it doesn't
seem to be the case in the 'do_env_ask' function. Here follow some
questions:

- Will there be a timeout option for askenv in future?
- What is the closest alternative right now (I believe some 'echo'
  statements combined with 'bootdelay')?

Thanks for your time.

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


Re: [U-Boot] [PATCH 1/2] scsi: add PCIe to sata converter Marvell chip 88SE9170

2016-05-16 Thread Po Liu

>  -Original Message-
>  From: York Sun [mailto:york@nxp.com]
>  Sent: Tuesday, May 17, 2016 12:03 AM
>  To: Po Liu
>  Cc: u-boot@lists.denx.de; Simon Glass; Bin Meng; o...@andrep.de;
>  mark.langsd...@gmail.com
>  Subject: Re: [PATCH 1/2] scsi: add PCIe to sata converter Marvell chip
>  88SE9170
>  
>  On 04/13/2016 04:09 AM, Po Liu wrote:
>  > Add to the command scsi device list.
>  >
>  > Signed-off-by: Po Liu 
>  > ---
>  >  cmd/scsi.c | 5 +
>  >  1 file changed, 5 insertions(+)
>  >
>  > diff --git a/cmd/scsi.c b/cmd/scsi.c
>  > index 8991125..c85fefc 100644
>  > --- a/cmd/scsi.c
>  > +++ b/cmd/scsi.c
>  > @@ -31,6 +31,11 @@
>  >  #define SCSI_VEND_ID 0x10b9
>  >  #define SCSI_DEV_ID  0x5288
>  >
>  > +#elif defined CONFIG_SATA_88SE9170
>  > +
>  > +#define SCSI_VEND_ID 0x1b4b
>  > +#define SCSI_DEV_ID  0x9170
>  > +
>  >  #elif !defined(CONFIG_SCSI_AHCI_PLAT)  #error no scsi device defined
>  > #endif
>  >
>  
>  Po,
>  
>  Would it be a better idea to define CONFIG_SCSI_DEV_LIST in your board
>  header
>  file? You can merge your two patches into one.
Ok, Understand.
>  
>  York
>  

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


Re: [U-Boot] [PATCH v2 00/25] exynos: video: Convert exynos LCD driver to use driver model

2016-05-16 Thread Jaehoon Chung
Hi Simon.

On 05/15/2016 06:22 AM, Simon Glass wrote:
> Hi Jaehoon,
> 
> On 13 May 2016 at 07:09, Jaehoon Chung  wrote:
>> Hi Simon,
>>
>> On 05/09/2016 08:00 PM, Minkyu Kang wrote:
>>> Hi Jaehoon,
>>>
>>> On 08/05/16 06:25, Simon Glass wrote:
 Hi,

 On 1 March 2016 at 18:51, Minkyu Kang  wrote:
> Hi,
>
> On 29/02/16 16:18, Jaehoon Chung wrote:
>> Hi,
>>
>> On 02/29/2016 01:23 PM, Simon Glass wrote:
>>> Hi,
>>>
>>> On 23 February 2016 at 05:04, Minkyu Kang  wrote:
 Dear Simon Glass,

 On 23/02/16 15:42, Simon Glass wrote:
> Hi Minkyu,
>
> On 21 February 2016 at 21:08, Simon Glass  wrote:
>>
>> This series converts the exynos LCD driver to work with driver 
>> model. Only
>> the eDP display is converted - the MIPI display is left mostly alone 
>> as I
>> do not have a device to test with.
>>
>> The conversion involves some refactoring to simplify the code, 
>> reduce the
>> amount of global/static data and allow boards to be built without LCD
>> support.
>>
>> The series is tested with snow, spring, pit and pi. It disables LCD 
>> on other
>> exynos boards so that they will still build with these changes. 
>> Further work
>> will be needed (by someone with a board) to convert the others. I am 
>> not
>> sure when this series can be applied.
>>
>> The series also brings in device tree features from Linux v4.4. It 
>> would be
>> useful to do a full sync with the kernel on these files, but this is 
>> really
>> a job for the Samsung maintainer :-)
>>
>> The series is available at u-boot-dm/rkg-working.
>>
>> Changes in v2:
>> - Rebase to master
>> - Rebase to master
>>
>
> What do you think we should do about applying this series?
>

 Although we have to do remaining work, I think applying is possible 
 without next work.

 Board maintainers, what do you think?

 Remaining Work:
 - MIPI display driver
 - s5pc210_universal
 - smdk5420
 - smdk5250
 - trats
 - trats2

 Thanks,
 Minkyu Kang.
>>>
>>> Well, no replies as yet. The main work requires is MIPI, but as I
>>> don't have the hardware, I can't help with that. At least I have made
>>> sure that everything builds OK.
>>
>> Sorry for late..I will check these patches on this week..Tomorrow is 
>> holiday..
>> So I can check from Wed.
>
> Thank you, Jaehoon.

 It has been a few months now - if you like I can apply these via the -dm 
 tree.
>>
>> Yep, I checked these..It needs to remain the future work.
>> But it seems that it's not problem to apply at -dm repository.
>> (I have checked with your patch on other boadrs.)
>>
>> I needs to check one more things..Could you wait until next Tuesday?
>>
> 
> Sure, it's been 3 months so another week won't matter :-)

Sorry. I have checked more with these patches..We have to work too many things 
in future for remaining work.
But it seems those task are our role..If you and Minkyu are ok, you can apply 
these at dm repository.

I will make a plan to work. (Based on your repository.)

Actually, i didn't follow a few month, so i'm looking for u-boot history. 
Sorry. :(
If you want to add my Reviewed-by tag, then you can add.

In future work,
Change to driver model for above targets. (trats2/trats...)
MIPI display driver..(I will assign to my colleague for this task.)

Best Regards,
Jaehoon Chung

> 
> 
>>
>> Best Regards,
>> Jaehoon Chung
>>

>>>
>>> any progress?
>>>
>>> Thanks,
>>> Minkyu Kang.
>>>
>>
> 
> Regards,
> Simon
> 
> 

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


Re: [U-Boot] [PATCH v2 8/8] board: am335x: Allow to choose serial device dynamically

2016-05-16 Thread Lokesh Vutla



On 5/17/2016 6:11 AM, Tom Rini wrote:

On Mon, May 16, 2016 at 11:47:29AM +0530, Lokesh Vutla wrote:


Different AM335x based platforms have different serial consoles. As serial
console is Kconfig option a separate defconfig has to be created for each
platform. So pass the serial device dynamically.

Signed-off-by: Lokesh Vutla 
---
Changes since v1:
- New patch.
  board/ti/am335x/board.c | 11 +++
  include/serial.h|  4 
  2 files changed, 15 insertions(+)

diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index ff52314..56f4984 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -59,6 +60,16 @@ static inline int __maybe_unused read_eeprom(void)
return ti_i2c_eeprom_am_get(-1, CONFIG_SYS_I2C_EEPROM_ADDR);
  }

+#ifndef CONFIG_DM_SERIAL
+struct serial_device *default_serial_console(void)
+{
+   if (board_is_icev2())
+   return _device;
+   else
+   return _device;
+}
+#endif
+
  #ifndef CONFIG_SKIP_LOWLEVEL_INIT
  static const struct ddr_data ddr2_data = {
.datardsratio0 = MT47H128M16RT25E_RD_DQS,


... so in the DM case we're already handling this correctly?  Can't we


With DM+DT we are handling it correctly which is only in U-Boot. This 
part of code is meant for only SPL(DM_* is not yet enabled in SPL).


Thanks and regards,
Lokesh


just say that ICEv2 is only supported with DM enabled so that we don't
need to add compat code that we'll remove rather soon (I hope..) ?
Thanks!


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


Re: [U-Boot] [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is avaliable in U-Boot

2016-05-16 Thread Qianyu Gong
Hi York,

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Tuesday, May 17, 2016 12:47 AM
> To: Qianyu Gong ; u-boot@lists.denx.de;
> o...@buserror.net
> Cc: Mingkai Hu 
> Subject: Re: [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is 
> avaliable in U-
> Boot
> 
> On 04/27/2016 11:19 PM, Gong Qianyu wrote:
> > IFC is considered as a required component in Layerscape platforms' Linux.
> > But if IFC is not enabled in U-Boot on some boards, accessing IFC
> > memory space would cause kernel call trace. So disable IFC node in such 
> > cases.
> >
> > Signed-off-by: Gong Qianyu 
> > ---
> > V2:
> >  - Revised the title and message.
> >  - Used #ifndef CONFIG_FSL_IFC rather than #ifdef CONFIG_FSL_QSPI.
> >
> >  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > index 1e875c4..96dab56 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> > @@ -98,4 +98,9 @@ void ft_cpu_setup(void *blob, bd_t *bd)  #ifdef
> > CONFIG_SYS_DPAA_FMAN
> > fdt_fixup_fman_firmware(blob);
> >  #endif
> > +
> > +#ifndef CONFIG_FSL_IFC
> > +   do_fixup_by_compat(blob, "fsl,ifc",
> > +  "status", "disabled", 8 + 1, 1); #endif
> >  }
> >
> 
> Qianyu,
> 
> For the platforms you are testing, is IFC disabled/enabled at SoC level (eg.
> RCW) or board level (eg. FPGA)? Can you detect if IFC is enabled by checking
> registers?
> 
> York

For LS1043AQDS, IFC is disabled at board level(at SoC level, only IFC NOR is 
disabled).
Yes, I can detect if IFC is enabled by checking QIXIS registers.

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


Re: [U-Boot] [PATCH v3] armv8/ls2080a: configure PMU's PCTBENR to enable WDT

2016-05-16 Thread Yunhui Cui
Hi York,

 I think you can move your code into timer_init() in cpu.c and follow the 
example of cltbenr.
[Yunhui] During the u_boot imamge compiled by using the ls2080ardb_defconfig 
bootup on ls2080ardb, timer_init() cannot be called ...
   So maybe cannot move the code to timer_init().

Thanks
Yunhui

> -Original Message-
> From: York Sun [mailto:york@nxp.com]
> Sent: Tuesday, May 17, 2016 12:14 AM
> To: Yunhui Cui
> Cc: u-boot@lists.denx.de; Yunhui Cui; Prabhakar Kushwaha
> Subject: Re: [PATCH v3] armv8/ls2080a: configure PMU's PCTBENR to enable
> WDT
> 
> On 04/14/2016 08:57 PM, Yunhui Cui wrote:
> > From: Yunhui Cui 
> >
> > The SP805-WDT module on LS2080A and LS2085A, requires configuration of
> > PMU's PCTBENR register to enable watchdog counter decrement and reset
> > signal generation. In order not to affect the sp805wdt driver frame,
> > we enable the watchdog clk in advance.
> >
> > Signed-off-by: Yunhui Cui 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 15 +++
> >  arch/arm/include/asm/arch-fsl-layerscape/config.h |  4 
> >  arch/arm/include/asm/arch-fsl-layerscape/soc.h|  1 +
> >  board/freescale/ls2080aqds/ls2080aqds.c   |  2 ++
> >  board/freescale/ls2080ardb/ls2080ardb.c   |  2 ++
> >  5 files changed, 24 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index 0cb0100..c36976d 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -42,6 +42,21 @@ bool soc_has_aiop(void)
> > return false;
> >  }
> >
> > +#if defined(CONFIG_LS2080A)
> > +/*
> > + * In certain Layerscape SoCs, the clock for each core's watchdog
> > + * has an enable bit in the PMU Physical Core Time Base Enable
> > +Register
> > + * (PCTBENR), which allows the watchdog to operate.
> > + */
> > +void enable_watchdog_clk(void)
> > +{
> > +   u32 pmu_val;
> > +
> > +   pmu_val = *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET);
> > +   *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET) = pmu_val |
> > +0xff; } #endif
> > +
> >  #ifdef CONFIG_LS2080A
> >  /*
> >   * This erratum requires setting a value to eddrtqcr1 to diff --git
> > a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> > index 10d17b2..62e4f95 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> > @@ -143,6 +143,10 @@
> >  #define CONFIG_ARM_ERRATA_829520
> >  #define CONFIG_ARM_ERRATA_833471
> >
> > +/* PMU-Physical Core Time Base Enable Register */
> > +#define FSL_PMU_REG_BASE   0x1E3
> > +#define FSL_PMU_PCTBENR_OFFSET 0x8A0
> > +
> >  #elif defined(CONFIG_LS1043A)
> >  #define CONFIG_MAX_CPUS4
> >  #define CONFIG_SYS_CACHELINE_SIZE  64
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> > index 831d817..bd4a8f1 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> > @@ -91,6 +91,7 @@ void fsl_lsch2_early_init_f(void);  #endif
> >
> >  void cpu_name(char *name);
> > +void enable_watchdog_clk(void);
> >  #ifdef CONFIG_SYS_FSL_ERRATUM_A009635  void erratum_a009635(void);
> > #endif diff --git a/board/freescale/ls2080aqds/ls2080aqds.c
> > b/board/freescale/ls2080aqds/ls2080aqds.c
> > index b3bd40a..c109349 100644
> > --- a/board/freescale/ls2080aqds/ls2080aqds.c
> > +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> > @@ -213,6 +213,8 @@ int board_init(void)
> > select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
> > rtc_enable_32khz_output();
> >
> > +   enable_watchdog_clk();
> > +
> > return 0;
> >  }
> >
> > diff --git a/board/freescale/ls2080ardb/ls2080ardb.c
> > b/board/freescale/ls2080ardb/ls2080ardb.c
> > index fb39af6..7872f1f 100644
> > --- a/board/freescale/ls2080ardb/ls2080ardb.c
> > +++ b/board/freescale/ls2080ardb/ls2080ardb.c
> > @@ -181,6 +181,8 @@ int board_init(void)
> > /* invert AQR405 IRQ pins polarity */
> > out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR405_IRQ_MASK);
> >
> > +   enable_watchdog_clk();
> > +
> > return 0;
> >  }
> >
> >
> Yunhui,
> 
> I think you can move your code into timer_init() in cpu.c and follow the
> example of cltbenr.
> 
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 12/12] x86: qemu: rename qemu/acpi_table.c

2016-05-16 Thread Miao Yan
2016-05-17 8:42 GMT+08:00 Tom Rini :
> On Mon, May 16, 2016 at 05:40:16PM +0800, Miao Yan wrote:
>> Hi Bin,
>>
>> 2016-05-13 22:01 GMT+08:00 Bin Meng :
>> > Hi Miao,
>> >
>> > On Fri, May 13, 2016 at 2:29 PM, Miao Yan  wrote:
>> >> Rename  qemu/acpi_table.c to qemu/e820.c, because ACPI stuff is moved
>> >> to qfw core, this file only contains code for installing e820 table.
>> >>
>> >> Signed-off-by: Miao Yan 
>> >> ---
>> >>  arch/x86/cpu/qemu/Makefile |  3 +--
>> >>  arch/x86/cpu/qemu/acpi_table.c | 43 
>> >> --
>> >>  arch/x86/cpu/qemu/e820.c   | 43 
>> >> ++
>> >
>> > Please use "git mv".
>>
>> I did use "git mv". I'll double check.
>
> I believe you need to tell git to work harder to detect renames.  You'll
> have to do git format-patch --find-copies-harder ... and git send-email
> ... rather than just using send-email by itself (or, there's a knob
> somewhere I've missed that lets you tweak the rename threshold via the
> config file).

Thanks Tom,  I'll try that.

Miao

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


Re: [U-Boot] [PATCH 03/12] cmd: qfw: remove qemu_fwcfg_free_files()

2016-05-16 Thread Tom Rini
On Mon, May 16, 2016 at 05:47:43PM +0800, Miao Yan wrote:
> 2016-05-14 4:46 GMT+08:00 Tom Rini :
> > On Fri, May 13, 2016 at 10:00:05PM +0800, Bin Meng wrote:
> >> Hi Miao,
> >>
> >> On Fri, May 13, 2016 at 2:29 PM, Miao Yan  wrote:
> >> > This patch is part of the qfw refactor work.
> >> >
> >> > The qemu_fwcfg_free_files() function is only used in error handling in
> >> > ACPI table generation, let's not make this a core function and move it
> >> > to the right place.
> >> >
> >>
> >> But I suspect this API may still be needed in some other scenarioes?
> >> eg: for future ARM64 ACPI?
> >
> > Yes, as it stands currently the code looks likely useful for non-x86
> > QEMU+ACPI.
> 
> ARM64 and x86 should be able to share common ACPI code. As for now,
> this function is not used anywhere but error handling in only one
> place. I'd prefer not to make this public.

Well, OK, I'm not going to argue too too hard here, but if someone
duplicates this part of the qemu code since it wasn't in common, it's on
you :)

-- 
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 12/12] x86: qemu: rename qemu/acpi_table.c

2016-05-16 Thread Tom Rini
On Mon, May 16, 2016 at 05:40:16PM +0800, Miao Yan wrote:
> Hi Bin,
> 
> 2016-05-13 22:01 GMT+08:00 Bin Meng :
> > Hi Miao,
> >
> > On Fri, May 13, 2016 at 2:29 PM, Miao Yan  wrote:
> >> Rename  qemu/acpi_table.c to qemu/e820.c, because ACPI stuff is moved
> >> to qfw core, this file only contains code for installing e820 table.
> >>
> >> Signed-off-by: Miao Yan 
> >> ---
> >>  arch/x86/cpu/qemu/Makefile |  3 +--
> >>  arch/x86/cpu/qemu/acpi_table.c | 43 
> >> --
> >>  arch/x86/cpu/qemu/e820.c   | 43 
> >> ++
> >
> > Please use "git mv".
> 
> I did use "git mv". I'll double check.

I believe you need to tell git to work harder to detect renames.  You'll
have to do git format-patch --find-copies-harder ... and git send-email
... rather than just using send-email by itself (or, there's a knob
somewhere I've missed that lets you tweak the rename threshold via the
config file).

-- 
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/7] board: am33xx: fit: add support for selecting dtb dynamically

2016-05-16 Thread Tom Rini
On Mon, May 16, 2016 at 11:24:24AM +0530, Lokesh Vutla wrote:

> FIT allows for a multiple dtb in a single image. SPL needs a way to
> detect the right dtb to be used. Adding support for the same.
> 
> Signed-off-by: Lokesh Vutla 

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 v2 2/5] ARM: AM43xx: Enable FIT

2016-05-16 Thread Tom Rini
On Mon, May 16, 2016 at 11:11:16AM +0530, Lokesh Vutla wrote:

> Use a single defconfig for all AM43xx platforms by enabling FIT and delete
> the platform specific defconfigs.
> 
> Signed-off-by: Lokesh Vutla 

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 v2 8/8] board: am335x: Allow to choose serial device dynamically

2016-05-16 Thread Tom Rini
On Mon, May 16, 2016 at 11:47:29AM +0530, Lokesh Vutla wrote:

> Different AM335x based platforms have different serial consoles. As serial
> console is Kconfig option a separate defconfig has to be created for each
> platform. So pass the serial device dynamically.
> 
> Signed-off-by: Lokesh Vutla 
> ---
> Changes since v1:
> - New patch.
>  board/ti/am335x/board.c | 11 +++
>  include/serial.h|  4 
>  2 files changed, 15 insertions(+)
> 
> diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
> index ff52314..56f4984 100644
> --- a/board/ti/am335x/board.c
> +++ b/board/ti/am335x/board.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -59,6 +60,16 @@ static inline int __maybe_unused read_eeprom(void)
>   return ti_i2c_eeprom_am_get(-1, CONFIG_SYS_I2C_EEPROM_ADDR);
>  }
>  
> +#ifndef CONFIG_DM_SERIAL
> +struct serial_device *default_serial_console(void)
> +{
> + if (board_is_icev2())
> + return _device;
> + else
> + return _device;
> +}
> +#endif
> +
>  #ifndef CONFIG_SKIP_LOWLEVEL_INIT
>  static const struct ddr_data ddr2_data = {
>   .datardsratio0 = MT47H128M16RT25E_RD_DQS,

... so in the DM case we're already handling this correctly?  Can't we
just say that ICEv2 is only supported with DM enabled so that we don't
need to add compat code that we'll remove rather soon (I hope..) ?
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 3/7] ARM: AM335x: Enable FIT

2016-05-16 Thread Tom Rini
On Mon, May 16, 2016 at 11:24:26AM +0530, Lokesh Vutla wrote:

> Use a single defconfig for all AM335x platforms by enabling FIT
> 
> Signed-off-by: Lokesh Vutla 

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 v2 2/3] ARM: DRA7: Enable FIT

2016-05-16 Thread Tom Rini
On Mon, May 16, 2016 at 10:51:24AM +0530, Lokesh Vutla wrote:

> Use a single defconfig for all DRA7 platforms by enabling FIT and delete
> the platform specific defconfigs.
> 
> Signed-off-by: Lokesh Vutla 

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


[U-Boot] [PATCH V2] mailbox: implement a sandbox test

2016-05-16 Thread Stephen Warren
From: Stephen Warren 

This adds a sandbox mailbox implementation (provider), a test client
device, instantiates them both from Sandbox's DT, and adds a DM test
that excercises everything.

Signed-off-by: Stephen Warren 
Acked-by: Simon Glass  # v1
---
v2:
* Share SANDBOX_MBOX_PING_XOR via header file.
* Add include guards to header file.
* Use UCLASS_MISC not UCLASS_TEST since the latter seems to have some
  semantics associated with it not desired for this test.
---
 arch/sandbox/dts/test.dts   |  11 
 arch/sandbox/include/asm/mbox.h |  21 
 configs/sandbox_defconfig   |   3 ++
 drivers/mailbox/Kconfig |   7 +++
 drivers/mailbox/Makefile|   2 +
 drivers/mailbox/sandbox-mbox-test.c |  54 +++
 drivers/mailbox/sandbox-mbox.c  | 104 
 test/dm/Makefile|   1 +
 test/dm/mailbox.c   |  31 +++
 9 files changed, 234 insertions(+)
 create mode 100644 arch/sandbox/include/asm/mbox.h
 create mode 100644 drivers/mailbox/sandbox-mbox-test.c
 create mode 100644 drivers/mailbox/sandbox-mbox.c
 create mode 100644 test/dm/mailbox.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 89300096a5ab..686c215aea72 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -216,6 +216,17 @@
};
};
 
+   mbox: mbox {
+   compatible = "sandbox,mbox";
+   #mbox-cells = <1>;
+   };
+
+   mbox-test {
+   compatible = "sandbox,mbox-test";
+   mboxes = < 100>, < 1>;
+   mbox-names = "other", "test";
+   };
+
mmc {
compatible = "sandbox,mmc";
};
diff --git a/arch/sandbox/include/asm/mbox.h b/arch/sandbox/include/asm/mbox.h
new file mode 100644
index ..2d7b7d03e522
--- /dev/null
+++ b/arch/sandbox/include/asm/mbox.h
@@ -0,0 +1,21 @@
+/*
+ * Copyright (c) 2016, NVIDIA CORPORATION.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#ifndef __SANDBOX_MBOX_H
+#define __SANDBOX_MBOX_H
+
+#include 
+
+#define SANDBOX_MBOX_PING_XOR 0x12345678
+
+struct udevice;
+
+int sandbox_mbox_test_get(struct udevice *dev);
+int sandbox_mbox_test_send(struct udevice *dev, uint32_t msg);
+int sandbox_mbox_test_recv(struct udevice *dev, uint32_t *msg);
+int sandbox_mbox_test_free(struct udevice *dev);
+
+#endif
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 9ad570c7fc49..8613da2c15f5 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -167,3 +167,6 @@ CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
 CONFIG_UT_ENV=y
+CONFIG_MISC=y
+CONFIG_DM_MAILBOX=y
+CONFIG_SANDBOX_MBOX=y
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 8ae8edd28c52..9649b705895b 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -10,6 +10,13 @@ config DM_MAILBOX
  the basis of a variety of inter-process/inter-CPU communication
  protocols.
 
+config SANDBOX_MBOX
+   bool "Enable the sandbox mailbox test driver"
+   depends on DM_MAILBOX && SANDBOX
+   help
+ Enable support for a test mailbox implementation, which simply echos
+ back a modified version of any message that is sent.
+
 config TEGRA_HSP
bool "Enable Tegra HSP controller support"
depends on DM_MAILBOX && TEGRA
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index b5bc84032573..155dbeb09942 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -3,4 +3,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_DM_MAILBOX) += mailbox-uclass.o
+obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox.o
+obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox-test.o
 obj-$(CONFIG_TEGRA_HSP) += tegra-hsp.o
diff --git a/drivers/mailbox/sandbox-mbox-test.c 
b/drivers/mailbox/sandbox-mbox-test.c
new file mode 100644
index ..02d161aada33
--- /dev/null
+++ b/drivers/mailbox/sandbox-mbox-test.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright (c) 2016, NVIDIA CORPORATION.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct sandbox_mbox_test {
+   struct mbox_chan chan;
+};
+
+int sandbox_mbox_test_get(struct udevice *dev)
+{
+   struct sandbox_mbox_test *sbmt = dev_get_priv(dev);
+
+   return mbox_get_by_name(dev, "test", >chan);
+}
+
+int sandbox_mbox_test_send(struct udevice *dev, uint32_t msg)
+{
+   struct sandbox_mbox_test *sbmt = dev_get_priv(dev);
+
+   return mbox_send(>chan, );
+}
+
+int sandbox_mbox_test_recv(struct udevice *dev, uint32_t *msg)
+{
+   struct sandbox_mbox_test *sbmt = dev_get_priv(dev);
+
+   return mbox_recv(>chan, msg, 100);
+}
+
+int sandbox_mbox_test_free(struct udevice *dev)
+{
+   struct sandbox_mbox_test *sbmt = dev_get_priv(dev);
+
+   return mbox_free(>chan);
+}
+
+static const 

[U-Boot] [RFC] tools/env: Support UBI devices

2016-05-16 Thread Kevin Smith
Instead of requiring gluebi to update u-boot environments from
Linux, directly support writing to an UBI device.  The
fw_env.config file will look something like this:

Device  Offset  Envsize LEB SizeCount
/dev/ubi0_0 0   0x1 0x1f000 1

It is important to use LEB size instead of PEB size when using
UBI.

Signed-off-by: Kevin Smith 
Cc: Michael Heimpold 
Cc: Joe Hershberger 
---
 tools/env/fw_env.c | 71 --
 1 file changed, 48 insertions(+), 23 deletions(-)

diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index ba11f77..af7a8ae 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,7 @@
 #else
 # define  __user   /* nothing */
 # include 
+# include 
 #endif
 
 #include "fw_env.h"
@@ -54,6 +56,8 @@ struct envdev_s {
uint8_t mtd_type;   /* type of the MTD device */
 };
 
+#define UBI_TYPE   UCHAR_MAX
+
 static struct envdev_s envdevices[2] =
 {
{
@@ -943,7 +947,7 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
continue;
}
 
-   if (mtd_type != MTD_ABSENT) {
+   if (mtd_type != MTD_ABSENT && mtd_type != UBI_TYPE) {
erase.start = blockstart;
ioctl(fd, MEMUNLOCK, );
/* These do not need an explicit erase cycle */
@@ -956,11 +960,21 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
}
}
 
-   if (lseek (fd, blockstart, SEEK_SET) == -1) {
-   fprintf (stderr,
-"Seek error on %s: %s\n",
-DEVNAME (dev), strerror (errno));
-   return -1;
+   if (mtd_type == UBI_TYPE) {
+   uint64_t updatesize = erasesize;
+   if (ioctl(fd, UBI_IOCVOLUP, ) != 0) {
+   fprintf(stderr,
+   "Error updating UBI volume: %s\n",
+   strerror(errno));
+   return -1;
+   }
+   } else {
+   if (lseek (fd, blockstart, SEEK_SET) == -1) {
+   fprintf (stderr,
+"Seek error on %s: %s\n",
+DEVNAME (dev), strerror (errno));
+   return -1;
+   }
}
 
 #ifdef DEBUG
@@ -973,7 +987,7 @@ static int flash_write_buf (int dev, int fd, void *buf, 
size_t count,
return -1;
}
 
-   if (mtd_type != MTD_ABSENT)
+   if (mtd_type != MTD_ABSENT && mtd_type != UBI_TYPE)
ioctl(fd, MEMLOCK, );
 
processed  += erasesize;
@@ -1084,6 +1098,7 @@ static int flash_read (int fd)
 {
struct mtd_info_user mtdinfo;
struct stat st;
+   int32_t lnum;
int rc;
 
rc = fstat(fd, );
@@ -1095,28 +1110,38 @@ static int flash_read (int fd)
 
if (S_ISCHR(st.st_mode)) {
rc = ioctl(fd, MEMGETINFO, );
-   if (rc < 0) {
-   fprintf(stderr, "Cannot get MTD information for %s\n",
-   DEVNAME(dev_current));
-   return -1;
+   if (rc >= 0) {
+   if (mtdinfo.type != MTD_NORFLASH &&
+   mtdinfo.type != MTD_NANDFLASH &&
+   mtdinfo.type != MTD_DATAFLASH &&
+   mtdinfo.type != MTD_UBIVOLUME) {
+   fprintf (stderr,
+   "Unsupported flash type %u on %s\n",
+   mtdinfo.type, DEVNAME(dev_current));
+   return -1;
+   }
+   DEVTYPE(dev_current) = mtdinfo.type;
+   goto read;
}
-   if (mtdinfo.type != MTD_NORFLASH &&
-   mtdinfo.type != MTD_NANDFLASH &&
-   mtdinfo.type != MTD_DATAFLASH &&
-   mtdinfo.type != MTD_UBIVOLUME) {
-   fprintf (stderr, "Unsupported flash type %u on %s\n",
-mtdinfo.type, DEVNAME(dev_current));
-   return -1;
+
+   /* Check for an UBI-type device */
+   lnum = 0;
+   rc = ioctl(fd, UBI_IOCEBISMAP, );
+   if (rc >= 0) {
+   DEVTYPE(dev_current) = UBI_TYPE;
+

Re: [U-Boot] [PATCH v2 3/5] dm: ns16550: Don't map_physmem for I/O ports

2016-05-16 Thread Daniel Schwierzeck


Am 16.05.2016 um 19:44 schrieb Paul Burton:
> If the UART is to be accessed using I/O port accessors (inb & outb) then
> using map_physmem doesn't make sense, since it operates in a different
> memory space. Remove the call to map_physmem when
> CONFIG_SYS_NS16550_PORT_MAPPED is defined, allowing I/O port addresses
> to not be mangled by the incorrect mapping.
> 
> Signed-off-by: Paul Burton 

Reviewed-by: Daniel Schwierzeck 
Tested-by: Daniel Schwierzeck 

> ---
> 
> Changes in v2:
> - New patch, part of a simplified approach tackling only a single Malta UART.
> 
>  drivers/serial/ns16550.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 28da9dd..e58e6aa 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -100,7 +100,11 @@ static void ns16550_writeb(NS16550_t port, int offset, 
> int value)
>   unsigned char *addr;
>  
>   offset *= 1 << plat->reg_shift;
> +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
> + addr = (unsigned char *)plat->base + offset;
> +#else
>   addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset;
> +#endif
>   /*
>* As far as we know it doesn't make sense to support selection of
>* these options at run-time, so use the existing CONFIG options.
> @@ -114,7 +118,11 @@ static int ns16550_readb(NS16550_t port, int offset)
>   unsigned char *addr;
>  
>   offset *= 1 << plat->reg_shift;
> +#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
> + addr = (unsigned char *)plat->base + offset;
> +#else
>   addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset;
> +#endif
>  
>   return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
>  }
> 

-- 
- Daniel



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


Re: [U-Boot] [PATCH v2 4/5] malta: Tidy up UART address selection

2016-05-16 Thread Daniel Schwierzeck


Am 16.05.2016 um 19:44 schrieb Paul Burton:
> The address of the UART differs based upon the system controller because
> it's actually within the I/O port region, which is in a different
> location for each system controller. Rather than handling this as 2
> UARTs with the correct one selected at runtime, use I/O port accessors
> for the UART such that access to it gets translated into the I/O port
> region automatically.
> 
> Signed-off-by: Paul Burton 

Reviewed-by: Daniel Schwierzeck 

> ---
> 
> Changes in v2:
> - New patch, simplifying the later DT conversion.
> 
>  board/imgtec/malta/malta.c | 13 -
>  include/configs/malta.h|  4 ++--
>  2 files changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c
> index 3a9e780..4955043 100644
> --- a/board/imgtec/malta/malta.c
> +++ b/board/imgtec/malta/malta.c
> @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include 
>  #include 
> @@ -161,18 +160,6 @@ int misc_init_r(void)
>   return 0;
>  }
>  
> -struct serial_device *default_serial_console(void)
> -{
> - switch (malta_sys_con()) {
> - case SYSCON_GT64120:
> - return _device;
> -
> - default:
> - case SYSCON_MSC01:
> - return _device;
> - }
> -}
> -
>  void pci_init_board(void)
>  {
>   pci_dev_t bdf;
> diff --git a/include/configs/malta.h b/include/configs/malta.h
> index 04dca71..1c3c83c 100644
> --- a/include/configs/malta.h
> +++ b/include/configs/malta.h
> @@ -67,10 +67,10 @@
>  #define CONFIG_BAUDRATE  115200
>  
>  #define CONFIG_SYS_NS16550_SERIAL
> +#define CONFIG_SYS_NS16550_PORT_MAPPED
>  #define CONFIG_SYS_NS16550_REG_SIZE  1
>  #define CONFIG_SYS_NS16550_CLK   (115200 * 16)
> -#define CONFIG_SYS_NS16550_COM1  0xb80003f8
> -#define CONFIG_SYS_NS16550_COM2  0xbb0003f8
> +#define CONFIG_SYS_NS16550_COM1  0x3f8
>  #define CONFIG_CONS_INDEX1
>  
>  /*
> 

-- 
- Daniel



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


Re: [U-Boot] [PATCH v2 5/5] malta: Use device model & tree for UART

2016-05-16 Thread Daniel Schwierzeck


Am 16.05.2016 um 19:44 schrieb Paul Burton:
> Make use of device model & device tree to probe the UART driver. This is
> the initial step in bringing Malta up to date with driver model, and
> allows for cleaner handling of the different I/O addresses for different
> system controllers by specifying the ISA bus address instead of a
> translated memory address.
> 
> Signed-off-by: Paul Burton 

Reviewed-by: Daniel Schwierzeck 

nits below

> ---
> 
> Changes in v2:
> - Only handle the UART we already use, for simplicity.
> 
>  arch/mips/Kconfig   |  5 +
>  arch/mips/dts/Makefile  |  3 ++-
>  arch/mips/dts/mti,malta.dts | 32 
>  configs/malta_defconfig |  1 +
>  configs/maltael_defconfig   |  1 +
>  include/configs/malta.h |  6 --
>  6 files changed, 41 insertions(+), 7 deletions(-)
>  create mode 100644 arch/mips/dts/mti,malta.dts
> 
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index fe37d1f..e407b19 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -23,7 +23,12 @@ config TARGET_QEMU_MIPS
>  
>  config TARGET_MALTA
>   bool "Support malta"
> + select DM
> + select DM_SERIAL

actually DM_SERIAL should be selected in the defconfig. But Malta is a single 
target so it's ok.

>   select DYNAMIC_IO_PORT_BASE
> + select OF_CONTROL
> + select OF_EMBED

but OF_EMBED should go into the defconfig. The user should decide if the DTB 
should be appended or be embedded.

> + select OF_ISA_BUS
>   select SUPPORTS_BIG_ENDIAN
>   select SUPPORTS_LITTLE_ENDIAN
>   select SUPPORTS_CPU_MIPS32_R1
> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
> index b513918..45d623f 100644
> --- a/arch/mips/dts/Makefile
> +++ b/arch/mips/dts/Makefile
> @@ -2,7 +2,8 @@
>  # SPDX-License-Identifier:   GPL-2.0+
>  #
>  
> -dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
> +dtb-$(CONFIG_TARGET_MALTA)   += mti,malta.dtb
> +dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb

this doesn't apply to u-boot-mips/next but I can fix it.

>  
>  targets += $(dtb-y)
>  
> diff --git a/arch/mips/dts/mti,malta.dts b/arch/mips/dts/mti,malta.dts
> new file mode 100644
> index 000..1dba606
> --- /dev/null
> +++ b/arch/mips/dts/mti,malta.dts
> @@ -0,0 +1,32 @@
> +/dts-v1/;
> +
> +/memreserve/ 0x 0x1000;  /* Exception vectors */
> +/memreserve/ 0x000f 0x0001;  /* PIIX4 ISA memory */
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "mti,malta";
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + isa {
> + compatible = "isa";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <1 0 0 0x1000>;

is following dtc warning fixable?

Warning (unit_address_vs_reg): Node /isa has a reg or ranges property, but no 
unit name

> +
> + uart0: serial@3f8 {
> + compatible = "ns16550a";
> +
> + reg = <1 0x3f8 0x40>;
> + reg-shift = <0>;
> +
> + clock-frequency = <1843200>;
> +
> + u-boot,dm-pre-reloc;
> + };
> + };
> +};
> diff --git a/configs/malta_defconfig b/configs/malta_defconfig
> index a16f10b..0b5075f 100644
> --- a/configs/malta_defconfig
> +++ b/configs/malta_defconfig
> @@ -11,3 +11,4 @@ CONFIG_CMD_DHCP=y
>  CONFIG_CMD_PING=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_USE_PRIVATE_LIBGCC=y
> +CONFIG_DEFAULT_DEVICE_TREE="mti,malta"
> diff --git a/configs/maltael_defconfig b/configs/maltael_defconfig
> index 5289797..876e806 100644
> --- a/configs/maltael_defconfig
> +++ b/configs/maltael_defconfig
> @@ -12,3 +12,4 @@ CONFIG_CMD_DHCP=y
>  CONFIG_CMD_PING=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_USE_PRIVATE_LIBGCC=y
> +CONFIG_DEFAULT_DEVICE_TREE="mti,malta"
> diff --git a/include/configs/malta.h b/include/configs/malta.h
> index 1c3c83c..e03935b 100644
> --- a/include/configs/malta.h
> +++ b/include/configs/malta.h
> @@ -65,13 +65,7 @@
>   * Serial driver
>   */
>  #define CONFIG_BAUDRATE  115200
> -
> -#define CONFIG_SYS_NS16550_SERIAL
>  #define CONFIG_SYS_NS16550_PORT_MAPPED
> -#define CONFIG_SYS_NS16550_REG_SIZE  1
> -#define CONFIG_SYS_NS16550_CLK   (115200 * 16)
> -#define CONFIG_SYS_NS16550_COM1  0x3f8
> -#define CONFIG_CONS_INDEX1
>  
>  /*
>   * Flash configuration
> 

-- 
- Daniel



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


[U-Boot] [ANN] U-Boot v2016.05 is released

2016-05-16 Thread Tom Rini
Hey all,

Due to some odds and ends, I ended up taking in some code a bit close to
the original release date, so I ended up just pushing things out a week.
I think moving forward, I really should say that in public, sorry.  But
things are live on git and FTP and Amazon Cloud Drive now.

So, v2016.05 has been released, and there's a few things worth pointing
out here.  First of all, U-Boot can now run EFI applications on ARM and
ARMv8.  The main use case here has been GRUB and that works.  This is
enabled by default on ARM and ARMv8 and a few platforms have turned it
off due to not being useful for their needs or space savings.

Next, we continue to make good progress on device model work and to me
one of the exciting parts is that we brought in the ground work this
release for FIT images from SPL and we've got a bunch of patches queued
up for the next release to make use of it.  The end result here is that
we're now able to keep having one binary that runs on many platforms,
when we can tell what the platforms are at run time, but that need
different DTs to run correctly.

I don't like to single out specific boards that we've added support for
in these emails but looking over the log a lot of things have come in or
gotten big updates including a number of popular / prominent boards.
I'll let the respective custodians and authors showcase that themselves.

Finally, we're making more progress on the testing front.  The
test/py/test.py infrastructure is getting more use and robustness and
there's also tbot, see tools/tbot/README for more details there.

Thanks again everyone!

-- 
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] Please pull u-boot-sunxi master (v2016.05 bugfix)

2016-05-16 Thread Tom Rini
On Sun, May 15, 2016 at 11:30:40AM +0200, Hans de Goede wrote:

> Hi Tom,
> 
> Here is a sunxi pull-req with a small bugfix for v2016.05:
> 
> The following changes since commit 4cf4600f2569d7677a6f3cd933d7a189de6e7973:
> 
>   test, tools: update tbot documentation (2016-05-13 11:25:59 -0400)
> 
> are available in the git repository at:
> 
>   http://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to f0a711ec40a6af4ea438db0bd776886c32780ddd:
> 
>   sunxi: Enable USB host in CHIP defconfig (2016-05-15 11:04:29 +0200)
> 

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 v3 1/7] efi_loader: Add network access support

2016-05-16 Thread Alexander Graf


On 16.05.16 15:24, Simon Glass wrote:
> Hi Alexander,
> 
> On 14 May 2016 at 14:34, Alexander Graf  wrote:
>>
>>
>>> Am 14.05.2016 um 21:49 schrieb Simon Glass :
>>>
>>> Hi Alexander,
>>>
 On 10 May 2016 at 15:25, Alexander Graf  wrote:
 We can now successfully boot EFI applications from disk, but users
 may want to also run them from a PXE setup.

 This patch implements rudimentary network support, allowing a payload
 to send and receive network packets.

 With this patch, I was able to successfully run grub2 with network
 access inside of QEMU's -M xlnx-ep108 and on a zcu102 system.

 Signed-off-by: Alexander Graf 

 ---

 v2 -> v3:

  - Align initialization sequence with net code
  - Set device to initialized after init call
  - Align tx buffers to DMA alignment (rx gets memcpy'd)
  - Add comment about eth_rx()
 ---
 cmd/bootefi.c|   7 ++
 include/efi_api.h| 119 ++
 include/efi_loader.h |   7 ++
 include/net.h|   2 +-
 lib/efi_loader/Makefile  |   1 +
 lib/efi_loader/efi_net.c | 314 
 +++
 net/bootp.c  |   2 +
 net/net.c|   4 +-
 net/tftp.c   |   2 +
 9 files changed, 455 insertions(+), 3 deletions(-)
 create mode 100644 lib/efi_loader/efi_net.c

 diff --git a/cmd/bootefi.c b/cmd/bootefi.c
 index 7f552fc..d3a2331 100644
 --- a/cmd/bootefi.c
 +++ b/cmd/bootefi.c
 @@ -197,6 +197,13 @@ static unsigned long do_bootefi_exec(void *efi, void 
 *fdt)
 #ifdef CONFIG_LCD
efi_gop_register();
 #endif
 +#ifdef CONFIG_NET
 +   void *nethandle = loaded_image_info.device_handle;
 +   efi_net_register();
 +
 +   if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
 +   loaded_image_info.device_handle = nethandle;
 +#endif

/* Call our payload! */
 #ifdef DEBUG_EFI
 diff --git a/include/efi_api.h b/include/efi_api.h
 index 51d7586..20035d7 100644
 --- a/include/efi_api.h
 +++ b/include/efi_api.h
 @@ -412,4 +412,123 @@ struct efi_gop
struct efi_gop_mode *mode;
 };

 +#define EFI_SIMPLE_NETWORK_GUID \
 +   EFI_GUID(0xa19832b9, 0xac25, 0x11d3, \
 +0x9a, 0x2d, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
 +
 +struct efi_mac_address {
 +   char mac_addr[32];
 +};
 +
 +struct efi_ip_address {
 +   u8 ip_addr[16];
 +};
 +
 +enum efi_simple_network_state {
 +   EFI_NETWORK_STOPPED,
 +   EFI_NETWORK_STARTED,
 +   EFI_NETWORK_INITIALIZED,
 +};
 +
 +struct efi_simple_network_mode {
 +   enum efi_simple_network_state state;
 +   u32 hwaddr_size;
 +   u32 media_header_size;
 +   u32 max_packet_size;
 +   u32 nvram_size;
 +   u32 nvram_access_size;
 +   u32 receive_filter_mask;
 +   u32 receive_filter_setting;
 +   u32 max_mcast_filter_count;
 +   u32 mcast_filter_count;
 +   struct efi_mac_address mcast_filter[16];
 +   struct efi_mac_address current_address;
 +   struct efi_mac_address broadcast_address;
 +   struct efi_mac_address permanent_address;
 +   u8 if_type;
 +   u8 mac_changeable;
 +   u8 multitx_supported;
 +   u8 media_present_supported;
 +   u8 media_present;
 +};
 +
 +#define EFI_SIMPLE_NETWORK_RECEIVE_UNICAST 0x01,
 +#define EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST 0x02,
 +#define EFI_SIMPLE_NETWORK_RECEIVE_BROADCAST 0x04,
 +#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS   0x08,
 +#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST 0x10,
 +
 +struct efi_simple_network
 +{
 +   u64 revision;
 +   efi_status_t (EFIAPI *start)(struct efi_simple_network *this);
 +   efi_status_t (EFIAPI *stop)(struct efi_simple_network *this);
 +   efi_status_t (EFIAPI *initialize)(struct efi_simple_network *this,
 +   ulong extra_rx, ulong extra_tx);
 +   efi_status_t (EFIAPI *reset)(struct efi_simple_network *this,
 +   int extended_verification);
 +   efi_status_t (EFIAPI *shutdown)(struct efi_simple_network *this);
 +   efi_status_t (EFIAPI *receive_filters)(struct efi_simple_network 
 *this,
 +   u32 enable, u32 disable, int reset_mcast_filter,
 +   ulong mcast_filter_count,
 +   struct efi_mac_address *mcast_filter);
 +   efi_status_t (EFIAPI *station_address)(struct efi_simple_network 
 *this,
 +   int 

Re: [U-Boot] [PATCH v2] sunxi: Increase SPL header size to 64 bytes to avoid code corruption

2016-05-16 Thread Hans de Goede

Hi,

On 16-05-16 11:56, Bernhard Nortmann wrote:

Given that there now are quite a few additional "reserved" entries, and while 
we're still at SPL_HEADER_VERSION 1, I'd like to renew my request of dedicating one of 
these fields to the script length - which would enable us to set the U-Boot ${filesize} 
accordingly.

i.e.
--- arch-arm-include-asm-arch-sunxi-spl.h
+++ arch-arm-include-asm-arch-sunxi-spl.new.h
@@ -49,7 +49,8 @@
uint8_t spl_signature[4];
};
uint32_t fel_script_address;
-   uint32_t reserved1[3];
+   uint32_t fel_script_length;
+   uint32_t reserved1[2];
uint32_t boot_media;/* written here by the boot ROM */
uint32_t reserved2[5];  /* padding, align to 64 bytes */
 };


I do not intend to further push my specific use cases, however I still consider the (then 
somewhat theoretical) ability to do "import -t ${fel_script_addr} ${filesize}" 
useful. For reference, the previous discussion related to this was somewhere around 
http://lists.denx.de/pipermail/u-boot/2015-September/227454.html


Hmm, given that the boot-rom touches some of these, I wonder if
we should be putting anything here at all.

Other then that worry, I see no problem with adding a
fel_script_length, Siarhei what is your opinion on this ?

Regards,

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


Re: [U-Boot] [PATCH v2 06/13] usb: dwc3: add UniPhier specific glue layer

2016-05-16 Thread Marek Vasut
On 05/16/2016 02:51 PM, Masahiro Yamada wrote:
> Add UniPhier platform specific glue layer to support USB3 Host mode
> on Synopsys DWC3 IP.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Marek Vasut 
> ---
> 
> Changes in v2:
>   - Fix build error
>   - Add missing PHY reset deassert

Applied, thanks!

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


Re: [U-Boot] [PATCH v2 05/13] usb: dwc3: change DWC3 core support code into a driver

2016-05-16 Thread Marek Vasut
On 05/16/2016 02:51 PM, Masahiro Yamada wrote:
> Synopsys DWC3 IP generally works with an SoC-specific glue layer.
> DT binding for that is like this:
> 
>   usb3_glue {
>   compatible = "foo,dwc3";
>   ...
> 
>   usb3 {
>   compatible = "snps,dwc3";
>   ...
>   };
>   };
> 
> The glue layer initializes some SoC-specific parts, then populates
> the child DWC3 core.  To see how it works, refer to
> 
>   drivers/usb/dwc3/dwc3-exynos.c
>   drivers/usb/dwc3/dwc3-keystone.c
>   drivers/usb/dwc3/dwc3-omap.c
>   drivers/usb/dwc3/dwc3-st.c
> 
> of Linux Kernel.
> 
> This commit implements a driver compatible with "snps,dwc3", allowing
> to use the same binding in U-Boot.  The glue layer can be simply
> implemented based on Simple Bus Uclass.
> 
> Signed-off-by: Masahiro Yamada 
> Reviewed-by: Marek Vasut 
> ---

Applied, thanks!

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


Re: [U-Boot] [PATCH v2 03/13] usb: move CONFIG_USB_XHCI_DWC3 to Kconfig

2016-05-16 Thread Marek Vasut
On 05/16/2016 02:51 PM, Masahiro Yamada wrote:
> Create an entry for "config USB_XHCI_DWC3" in Kconfig and
> switch over to it for all boards.
> 
> Signed-off-by: Masahiro Yamada 

Applied, thanks!

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


Re: [U-Boot] [PATCH v2 02/13] usb: move CONFIG_USB_XHCI to Kconfig with renaming

2016-05-16 Thread Marek Vasut
On 05/16/2016 02:51 PM, Masahiro Yamada wrote:
> Move CONFIG_USB_XHCI to defconfig files for all boards, renaming it
> into CONFIG_USB_XHCI_HCD.
> 
> As commented in the help of "config USB_XHCI" entry, this has been
> a TODO for a long time; now CONFIG_USB_XHCI_HCD and CONFIG_USB_XHCI
> have been unified in favor of the former.
> 
> Note:
> Some boards define CONFIG_USB_XHCI in their headers without
> CONFIG_USB, which does not meet the "depends on" in Kconfig.
> I added CONFIG_USB=y for those boards when converting.
> Otherwise, they would fail to build.
> 
> Signed-off-by: Masahiro Yamada 

Applied, thanks!

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


Re: [U-Boot] [PATCH v2 01/13] configs: blackfin: move CONFIG_USB to defconfig

2016-05-16 Thread Marek Vasut
On 05/16/2016 02:51 PM, Masahiro Yamada wrote:
> These Blackfin boards are the last ones that define CONFIG_USB in
> their headers.
> 
> Signed-off-by: Masahiro Yamada 

Applied, thanks!

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


Re: [U-Boot] [PATCH v2 04/13] usb: xhci: add struct devrequest declaration to xhci.h

2016-05-16 Thread Marek Vasut
On 05/16/2016 02:51 PM, Masahiro Yamada wrote:
> If xhci.h is included without include/usb.h, the compiler
> complains like follows:
> warning: 'struct devrequest' declared inside parameter list
> 
> We have two options to teach the compiler that devrequest is
> a structure:
> 
> [1] Declare "struct devrequest;" in xhci.h
> 
> [2] Include  from xhci.h
> 
> This commit takes [1] because nothing else in xhci.h depends on
> include/usb.h.  [2] would require the compiler additional header
> parsing.
> 
> Signed-off-by: Masahiro Yamada 

Applied, thanks!

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


[U-Boot] [PATCH v2 5/5] malta: Use device model & tree for UART

2016-05-16 Thread Paul Burton
Make use of device model & device tree to probe the UART driver. This is
the initial step in bringing Malta up to date with driver model, and
allows for cleaner handling of the different I/O addresses for different
system controllers by specifying the ISA bus address instead of a
translated memory address.

Signed-off-by: Paul Burton 
---

Changes in v2:
- Only handle the UART we already use, for simplicity.

 arch/mips/Kconfig   |  5 +
 arch/mips/dts/Makefile  |  3 ++-
 arch/mips/dts/mti,malta.dts | 32 
 configs/malta_defconfig |  1 +
 configs/maltael_defconfig   |  1 +
 include/configs/malta.h |  6 --
 6 files changed, 41 insertions(+), 7 deletions(-)
 create mode 100644 arch/mips/dts/mti,malta.dts

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index fe37d1f..e407b19 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -23,7 +23,12 @@ config TARGET_QEMU_MIPS
 
 config TARGET_MALTA
bool "Support malta"
+   select DM
+   select DM_SERIAL
select DYNAMIC_IO_PORT_BASE
+   select OF_CONTROL
+   select OF_EMBED
+   select OF_ISA_BUS
select SUPPORTS_BIG_ENDIAN
select SUPPORTS_LITTLE_ENDIAN
select SUPPORTS_CPU_MIPS32_R1
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index b513918..45d623f 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -2,7 +2,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
+dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
+dtb-$(CONFIG_TARGET_PIC32MZDASK)   += pic32mzda_sk.dtb
 
 targets += $(dtb-y)
 
diff --git a/arch/mips/dts/mti,malta.dts b/arch/mips/dts/mti,malta.dts
new file mode 100644
index 000..1dba606
--- /dev/null
+++ b/arch/mips/dts/mti,malta.dts
@@ -0,0 +1,32 @@
+/dts-v1/;
+
+/memreserve/ 0x 0x1000;/* Exception vectors */
+/memreserve/ 0x000f 0x0001;/* PIIX4 ISA memory */
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "mti,malta";
+
+   chosen {
+   stdout-path = 
+   };
+
+   isa {
+   compatible = "isa";
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <1 0 0 0x1000>;
+
+   uart0: serial@3f8 {
+   compatible = "ns16550a";
+
+   reg = <1 0x3f8 0x40>;
+   reg-shift = <0>;
+
+   clock-frequency = <1843200>;
+
+   u-boot,dm-pre-reloc;
+   };
+   };
+};
diff --git a/configs/malta_defconfig b/configs/malta_defconfig
index a16f10b..0b5075f 100644
--- a/configs/malta_defconfig
+++ b/configs/malta_defconfig
@@ -11,3 +11,4 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
 CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
+CONFIG_DEFAULT_DEVICE_TREE="mti,malta"
diff --git a/configs/maltael_defconfig b/configs/maltael_defconfig
index 5289797..876e806 100644
--- a/configs/maltael_defconfig
+++ b/configs/maltael_defconfig
@@ -12,3 +12,4 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
 CONFIG_SYS_NS16550=y
 CONFIG_USE_PRIVATE_LIBGCC=y
+CONFIG_DEFAULT_DEVICE_TREE="mti,malta"
diff --git a/include/configs/malta.h b/include/configs/malta.h
index 1c3c83c..e03935b 100644
--- a/include/configs/malta.h
+++ b/include/configs/malta.h
@@ -65,13 +65,7 @@
  * Serial driver
  */
 #define CONFIG_BAUDRATE115200
-
-#define CONFIG_SYS_NS16550_SERIAL
 #define CONFIG_SYS_NS16550_PORT_MAPPED
-#define CONFIG_SYS_NS16550_REG_SIZE1
-#define CONFIG_SYS_NS16550_CLK (115200 * 16)
-#define CONFIG_SYS_NS16550_COM10x3f8
-#define CONFIG_CONS_INDEX  1
 
 /*
  * Flash configuration
-- 
2.8.2

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


[U-Boot] [PATCH v2 4/5] malta: Tidy up UART address selection

2016-05-16 Thread Paul Burton
The address of the UART differs based upon the system controller because
it's actually within the I/O port region, which is in a different
location for each system controller. Rather than handling this as 2
UARTs with the correct one selected at runtime, use I/O port accessors
for the UART such that access to it gets translated into the I/O port
region automatically.

Signed-off-by: Paul Burton 
---

Changes in v2:
- New patch, simplifying the later DT conversion.

 board/imgtec/malta/malta.c | 13 -
 include/configs/malta.h|  4 ++--
 2 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/board/imgtec/malta/malta.c b/board/imgtec/malta/malta.c
index 3a9e780..4955043 100644
--- a/board/imgtec/malta/malta.c
+++ b/board/imgtec/malta/malta.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -161,18 +160,6 @@ int misc_init_r(void)
return 0;
 }
 
-struct serial_device *default_serial_console(void)
-{
-   switch (malta_sys_con()) {
-   case SYSCON_GT64120:
-   return _device;
-
-   default:
-   case SYSCON_MSC01:
-   return _device;
-   }
-}
-
 void pci_init_board(void)
 {
pci_dev_t bdf;
diff --git a/include/configs/malta.h b/include/configs/malta.h
index 04dca71..1c3c83c 100644
--- a/include/configs/malta.h
+++ b/include/configs/malta.h
@@ -67,10 +67,10 @@
 #define CONFIG_BAUDRATE115200
 
 #define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SYS_NS16550_PORT_MAPPED
 #define CONFIG_SYS_NS16550_REG_SIZE1
 #define CONFIG_SYS_NS16550_CLK (115200 * 16)
-#define CONFIG_SYS_NS16550_COM10xb80003f8
-#define CONFIG_SYS_NS16550_COM20xbb0003f8
+#define CONFIG_SYS_NS16550_COM10x3f8
 #define CONFIG_CONS_INDEX  1
 
 /*
-- 
2.8.2

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


[U-Boot] [PATCH v2 3/5] dm: ns16550: Don't map_physmem for I/O ports

2016-05-16 Thread Paul Burton
If the UART is to be accessed using I/O port accessors (inb & outb) then
using map_physmem doesn't make sense, since it operates in a different
memory space. Remove the call to map_physmem when
CONFIG_SYS_NS16550_PORT_MAPPED is defined, allowing I/O port addresses
to not be mangled by the incorrect mapping.

Signed-off-by: Paul Burton 
---

Changes in v2:
- New patch, part of a simplified approach tackling only a single Malta UART.

 drivers/serial/ns16550.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 28da9dd..e58e6aa 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -100,7 +100,11 @@ static void ns16550_writeb(NS16550_t port, int offset, int 
value)
unsigned char *addr;
 
offset *= 1 << plat->reg_shift;
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+   addr = (unsigned char *)plat->base + offset;
+#else
addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset;
+#endif
/*
 * As far as we know it doesn't make sense to support selection of
 * these options at run-time, so use the existing CONFIG options.
@@ -114,7 +118,11 @@ static int ns16550_readb(NS16550_t port, int offset)
unsigned char *addr;
 
offset *= 1 << plat->reg_shift;
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+   addr = (unsigned char *)plat->base + offset;
+#else
addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset;
+#endif
 
return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
 }
-- 
2.8.2

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


[U-Boot] [PATCH v2 2/5] fdt: Document the rest of struct of_bus

2016-05-16 Thread Paul Burton
Provide some documentation for the fields of struct of_bus, for
consistency with that provided for the new match field.

Signed-off-by: Paul Burton 
---

Changes in v2:
- New patch.

 common/fdt_support.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 96b5d0a..5d8eb12 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -966,10 +966,29 @@ static void of_dump_addr(const char *s, const fdt32_t 
*addr, int na) { }
 
 /**
  * struct of_bus - Callbacks for bus specific translators
+ * @name:  A string used to identify this bus in debug output.
+ * @addresses: The name of the DT property from which addresses are
+ * to be read, typically "reg".
  * @match: Return non-zero if the node whose parent is at
  * parentoffset in the FDT blob corresponds to a bus
  * of this type, otherwise return zero. If NULL a match
  * is assumed.
+ * @count_cells:Count how many cells (be32 values) a node whose parent
+ * is at parentoffset in the FDT blob will require to
+ * represent its address (written to *addrc) & size
+ * (written to *sizec).
+ * @map:   Map the address addr from the address space of this
+ * bus to that of its parent, making use of the ranges
+ * read from DT to an array at range. na and ns are the
+ * number of cells (be32 values) used to hold and address
+ * or size, respectively, for this bus. pna is the number
+ * of cells used to hold an address for the parent bus.
+ * Returns the address in the address space of the parent
+ * bus.
+ * @translate: Update the value of the address cells at addr within an
+ * FDT by adding offset to it. na specifies the number of
+ * cells used to hold the address being translated. Returns
+ * zero on success, non-zero on error.
  *
  * Each bus type will include a struct of_bus in the of_busses array,
  * providing implementations of some or all of the functions used to
-- 
2.8.2

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


[U-Boot] [PATCH v2 1/5] fdt: Support for ISA busses

2016-05-16 Thread Paul Burton
Support ISA busses in much the same way as Linux does. This allows for
ISA bus addresses to be translated, and only if CONFIG_OF_ISA_BUS is
selected in order to avoid including the code in builds which won't need
it.

Signed-off-by: Paul Burton 
---

Changes in v2:
- Document the match function pointer in struct of_bus.
- Make CONFIG_OF_ISA_BUS not user-selectable, and explain it in help text.
- assert() that of_match_bus didn't fail instead of BUG(), and comment why.
- s/_busses[0]/of_busses/

 common/fdt_support.c | 101 +--
 drivers/core/Kconfig |  23 
 2 files changed, 121 insertions(+), 3 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 42e5d8a..96b5d0a 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -964,10 +964,21 @@ static void of_dump_addr(const char *s, const fdt32_t 
*addr, int na)
 static void of_dump_addr(const char *s, const fdt32_t *addr, int na) { }
 #endif
 
-/* Callbacks for bus specific translators */
+/**
+ * struct of_bus - Callbacks for bus specific translators
+ * @match: Return non-zero if the node whose parent is at
+ * parentoffset in the FDT blob corresponds to a bus
+ * of this type, otherwise return zero. If NULL a match
+ * is assumed.
+ *
+ * Each bus type will include a struct of_bus in the of_busses array,
+ * providing implementations of some or all of the functions used to
+ * match the bus & handle address translation for its children.
+ */
 struct of_bus {
const char  *name;
const char  *addresses;
+   int (*match)(void *blob, int parentoffset);
void(*count_cells)(void *blob, int parentoffset,
int *addrc, int *sizec);
u64 (*map)(fdt32_t *addr, const fdt32_t *range,
@@ -1022,8 +1033,70 @@ static int of_bus_default_translate(fdt32_t *addr, u64 
offset, int na)
return 0;
 }
 
+#ifdef CONFIG_OF_ISA_BUS
+
+/* ISA bus translator */
+static int of_bus_isa_match(void *blob, int parentoffset)
+{
+   const char *name;
+
+   name = fdt_get_name(blob, parentoffset, NULL);
+   if (!name)
+   return 0;
+
+   return !strcmp(name, "isa");
+}
+
+static void of_bus_isa_count_cells(void *blob, int parentoffset,
+  int *addrc, int *sizec)
+{
+   if (addrc)
+   *addrc = 2;
+   if (sizec)
+   *sizec = 1;
+}
+
+static u64 of_bus_isa_map(fdt32_t *addr, const fdt32_t *range,
+ int na, int ns, int pna)
+{
+   u64 cp, s, da;
+
+   /* Check address type match */
+   if ((addr[0] ^ range[0]) & cpu_to_be32(1))
+   return OF_BAD_ADDR;
+
+   cp = of_read_number(range + 1, na - 1);
+   s  = of_read_number(range + na + pna, ns);
+   da = of_read_number(addr + 1, na - 1);
+
+   debug("OF: ISA map, cp=%" PRIu64 ", s=%" PRIu64
+ ", da=%" PRIu64 "\n", cp, s, da);
+
+   if (da < cp || da >= (cp + s))
+   return OF_BAD_ADDR;
+   return da - cp;
+}
+
+static int of_bus_isa_translate(fdt32_t *addr, u64 offset, int na)
+{
+   return of_bus_default_translate(addr + 1, offset, na - 1);
+}
+
+#endif /* CONFIG_OF_ISA_BUS */
+
 /* Array of bus specific translators */
 static struct of_bus of_busses[] = {
+#ifdef CONFIG_OF_ISA_BUS
+   /* ISA */
+   {
+   .name = "isa",
+   .addresses = "reg",
+   .match = of_bus_isa_match,
+   .count_cells = of_bus_isa_count_cells,
+   .map = of_bus_isa_map,
+   .translate = of_bus_isa_translate,
+   },
+#endif /* CONFIG_OF_ISA_BUS */
/* Default */
{
.name = "default",
@@ -1034,6 +1107,28 @@ static struct of_bus of_busses[] = {
},
 };
 
+static struct of_bus *of_match_bus(void *blob, int parentoffset)
+{
+   struct of_bus *bus;
+
+   if (ARRAY_SIZE(of_busses) == 1)
+   return of_busses;
+
+   for (bus = of_busses; bus; bus++) {
+   if (!bus->match || bus->match(blob, parentoffset))
+   return bus;
+   }
+
+   /*
+* We should always have matched the default bus at least, since
+* it has a NULL match field. If we didn't then it somehow isn't
+* in the of_busses array or something equally catastrophic has
+* gone wrong.
+*/
+   assert(0);
+   return NULL;
+}
+
 static int of_translate_one(void * blob, int parent, struct of_bus *bus,
struct of_bus *pbus, fdt32_t *addr,
int na, int ns, int pna, const char *rprop)
@@ -1113,7 +1208,7 @@ static u64 __of_translate_address(void *blob, int 
node_offset, const fdt32_t *in
parent = fdt_parent_offset(blob, node_offset);
if (parent < 0)
goto bail;
-   bus = 

[U-Boot] [PATCH v2 0/5] Malta UART using device model & device tree

2016-05-16 Thread Paul Burton
This series converts the MIPS Malta development board to make use of
device model & device tree to probe the UART. This results in a tidier
way to handle differences between Malta boards & starts Malta on the
path to device model conversion.

Paul Burton (5):
  fdt: Support for ISA busses
  fdt: Document the rest of struct of_bus
  dm: ns16550: Don't map_physmem for I/O ports
  malta: Tidy up UART address selection
  malta: Use device model & tree for UART

 arch/mips/Kconfig   |   5 ++
 arch/mips/dts/Makefile  |   3 +-
 arch/mips/dts/mti,malta.dts |  32 
 board/imgtec/malta/malta.c  |  13 -
 common/fdt_support.c| 120 ++--
 configs/malta_defconfig |   1 +
 configs/maltael_defconfig   |   1 +
 drivers/core/Kconfig|  23 +
 drivers/serial/ns16550.c|   8 +++
 include/configs/malta.h |   8 +--
 10 files changed, 190 insertions(+), 24 deletions(-)
 create mode 100644 arch/mips/dts/mti,malta.dts

-- 
2.8.2

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


[U-Boot] PSCI patch set for ARMv7

2016-05-16 Thread York Sun
Albert,

I noticed a set of patch is delegated to you
https://patchwork.ozlabs.org/project/uboot/list/?submitter=68732

Please kindly let me know if you will act on them, or if you prefer I take care
of them. My testing capacity will be limited to ls1 series SoCs.

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


Re: [U-Boot] [PATCH 1/2] drivers/ddr/fsl: Update clk_adjust of sdram_clk_cntl

2016-05-16 Thread York Sun
On 05/03/2016 07:30 PM, Shengzhou Liu wrote:
> The clk_adjust is of SDRAM_CLK_CNTL[5:8] 4-bits on MPC85xx and P-series,
> but is of SDRAM_CLK_CNTL[5:9] 5-bits on T-series and LS-series SoCs.
> We should update it to adapt the case that clk_adjust is odd data.
> 
> Signed-off-by: Shengzhou Liu 
> ---
>  drivers/ddr/fsl/ctrl_regs.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
> index 9073917..b26269c 100644
> --- a/drivers/ddr/fsl/ctrl_regs.c
> +++ b/drivers/ddr/fsl/ctrl_regs.c
> @@ -1835,10 +1835,17 @@ static void set_ddr_sdram_clk_cntl(fsl_ddr_cfg_regs_t 
> *ddr,
>   /* Per FSL Application Note: AN2805 */
>   ss_en = 1;
>  #endif
> - clk_adjust = popts->clk_adjust;
> + if (fsl_ddr_get_version(0) >= 0x40701) {
> + /* clk_adjust in 5-bits on T-series and LS-series */
> + clk_adjust = (popts->clk_adjust & 0x1F) << 22;
> + } else {
> + /* clk_adjust in 4-bits on earlier MPC85xx and P-series */
> + clk_adjust = (popts->clk_adjust & 0xF) << 23;
> + }
> +
>   ddr->ddr_sdram_clk_cntl = (0
>  | ((ss_en & 0x1) << 31)
> -| ((clk_adjust & 0xF) << 23)
> +| clk_adjust
>  );
>   debug("FSLDDR: clk_cntl = 0x%08x\n", ddr->ddr_sdram_clk_cntl);
>  }
> 

Shengzhou,

Your understanding is correct. However, we have done analysis that the
additional bit is not used for finer adjustment. So unless you have a case
requiring values in the middle, I suggest to keep current code.

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


Re: [U-Boot] [Patch v2] fsl-layerscape: fdt: add IFC fixup if no IFC is avaliable in U-Boot

2016-05-16 Thread York Sun
On 04/27/2016 11:19 PM, Gong Qianyu wrote:
> IFC is considered as a required component in Layerscape platforms' Linux.
> But if IFC is not enabled in U-Boot on some boards, accessing IFC memory
> space would cause kernel call trace. So disable IFC node in such cases.
> 
> Signed-off-by: Gong Qianyu 
> ---
> V2:
>  - Revised the title and message.
>  - Used #ifndef CONFIG_FSL_IFC rather than #ifdef CONFIG_FSL_QSPI.
> 
>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index 1e875c4..96dab56 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -98,4 +98,9 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>  #ifdef CONFIG_SYS_DPAA_FMAN
>   fdt_fixup_fman_firmware(blob);
>  #endif
> +
> +#ifndef CONFIG_FSL_IFC
> + do_fixup_by_compat(blob, "fsl,ifc",
> +"status", "disabled", 8 + 1, 1);
> +#endif
>  }
> 

Qianyu,

For the platforms you are testing, is IFC disabled/enabled at SoC level (eg.
RCW) or board level (eg. FPGA)? Can you detect if IFC is enabled by checking
registers?

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


Re: [U-Boot] [PATCH 1/2] scsi: add PCIe to sata converter Marvell chip 88SE9170

2016-05-16 Thread York Sun
On 04/13/2016 04:09 AM, Po Liu wrote:
> Add to the command scsi device list.
> 
> Signed-off-by: Po Liu 
> ---
>  cmd/scsi.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/cmd/scsi.c b/cmd/scsi.c
> index 8991125..c85fefc 100644
> --- a/cmd/scsi.c
> +++ b/cmd/scsi.c
> @@ -31,6 +31,11 @@
>  #define SCSI_VEND_ID 0x10b9
>  #define SCSI_DEV_ID  0x5288
>  
> +#elif defined CONFIG_SATA_88SE9170
> +
> +#define SCSI_VEND_ID 0x1b4b
> +#define SCSI_DEV_ID  0x9170
> +
>  #elif !defined(CONFIG_SCSI_AHCI_PLAT)
>  #error no scsi device defined
>  #endif
> 

Po,

Would it be a better idea to define CONFIG_SCSI_DEV_LIST in your board header
file? You can merge your two patches into one.

York


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


Re: [U-Boot] [PATCH v3] armv8/ls2080a: configure PMU's PCTBENR to enable WDT

2016-05-16 Thread York Sun
On 04/14/2016 08:57 PM, Yunhui Cui wrote:
> From: Yunhui Cui 
> 
> The SP805-WDT module on LS2080A and LS2085A, requires configuration
> of PMU's PCTBENR register to enable watchdog counter decrement and
> reset signal generation. In order not to affect the sp805wdt driver
> frame, we enable the watchdog clk in advance.
> 
> Signed-off-by: Yunhui Cui 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 15 +++
>  arch/arm/include/asm/arch-fsl-layerscape/config.h |  4 
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h|  1 +
>  board/freescale/ls2080aqds/ls2080aqds.c   |  2 ++
>  board/freescale/ls2080ardb/ls2080ardb.c   |  2 ++
>  5 files changed, 24 insertions(+)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 0cb0100..c36976d 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -42,6 +42,21 @@ bool soc_has_aiop(void)
>   return false;
>  }
>  
> +#if defined(CONFIG_LS2080A)
> +/*
> + * In certain Layerscape SoCs, the clock for each core's watchdog
> + * has an enable bit in the PMU Physical Core Time Base Enable Register
> + * (PCTBENR), which allows the watchdog to operate.
> + */
> +void enable_watchdog_clk(void)
> +{
> + u32 pmu_val;
> +
> + pmu_val = *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET);
> + *(u32 *)(FSL_PMU_REG_BASE + FSL_PMU_PCTBENR_OFFSET) = pmu_val | 0xff;
> +}
> +#endif
> +
>  #ifdef CONFIG_LS2080A
>  /*
>   * This erratum requires setting a value to eddrtqcr1 to
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> index 10d17b2..62e4f95 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
> @@ -143,6 +143,10 @@
>  #define CONFIG_ARM_ERRATA_829520
>  #define CONFIG_ARM_ERRATA_833471
>  
> +/* PMU-Physical Core Time Base Enable Register */
> +#define FSL_PMU_REG_BASE 0x1E3
> +#define FSL_PMU_PCTBENR_OFFSET   0x8A0
> +
>  #elif defined(CONFIG_LS1043A)
>  #define CONFIG_MAX_CPUS  4
>  #define CONFIG_SYS_CACHELINE_SIZE64
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> index 831d817..bd4a8f1 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> @@ -91,6 +91,7 @@ void fsl_lsch2_early_init_f(void);
>  #endif
>  
>  void cpu_name(char *name);
> +void enable_watchdog_clk(void);
>  #ifdef CONFIG_SYS_FSL_ERRATUM_A009635
>  void erratum_a009635(void);
>  #endif
> diff --git a/board/freescale/ls2080aqds/ls2080aqds.c 
> b/board/freescale/ls2080aqds/ls2080aqds.c
> index b3bd40a..c109349 100644
> --- a/board/freescale/ls2080aqds/ls2080aqds.c
> +++ b/board/freescale/ls2080aqds/ls2080aqds.c
> @@ -213,6 +213,8 @@ int board_init(void)
>   select_i2c_ch_pca9547(I2C_MUX_CH_DEFAULT);
>   rtc_enable_32khz_output();
>  
> + enable_watchdog_clk();
> +
>   return 0;
>  }
>  
> diff --git a/board/freescale/ls2080ardb/ls2080ardb.c 
> b/board/freescale/ls2080ardb/ls2080ardb.c
> index fb39af6..7872f1f 100644
> --- a/board/freescale/ls2080ardb/ls2080ardb.c
> +++ b/board/freescale/ls2080ardb/ls2080ardb.c
> @@ -181,6 +181,8 @@ int board_init(void)
>   /* invert AQR405 IRQ pins polarity */
>   out_le32(irq_ccsr + IRQCR_OFFSET / 4, AQR405_IRQ_MASK);
>  
> + enable_watchdog_clk();
> +
>   return 0;
>  }
>  
> 
Yunhui,

I think you can move your code into timer_init() in cpu.c and follow the example
of cltbenr.

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


Re: [U-Boot] [PATCH v2 00/13] usb: dwc3: rework DWC3 and convert UniPhier xHCI driver to DM

2016-05-16 Thread Marek Vasut
On 05/16/2016 02:51 PM, Masahiro Yamada wrote:
> Masahiro Yamada (13):
>   configs: blackfin: move CONFIG_USB to defconfig
>   usb: move CONFIG_USB_XHCI to Kconfig with renaming
>   usb: move CONFIG_USB_XHCI_DWC3 to Kconfig
>   usb: xhci: add struct devrequest declaration to xhci.h
>   usb: dwc3: change DWC3 core support code into a driver
>   usb: dwc3: add UniPhier specific glue layer
>   ARM: uniphier: switch over to USB DM
>   ARM: uniphier: enable DWC3 xHCI driver
>   usb: uniphier: remove UniPhier xHCI driver
>   ARM: uniphier: delete unnecessary xHCI pin-mux settings
>   ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG
>   ARM: dts: uniphier: add/update xHCI nodes
>   ARM: uniphier: enable Generic EHCI for PH1-Pro4
> 
>  arch/arm/Kconfig |   1 +
>  arch/arm/dts/uniphier-ph1-ld20.dtsi  |  17 
>  arch/arm/dts/uniphier-ph1-pro4-ref.dts   |   4 +
>  arch/arm/dts/uniphier-ph1-pro4.dtsi  |  32 --
>  arch/arm/dts/uniphier-ph1-pro5.dtsi  |  32 --
>  arch/arm/dts/uniphier-proxstream2.dtsi   |  32 --
>  arch/arm/mach-uniphier/clk/clk-pro4.c|   6 +-
>  arch/arm/mach-uniphier/clk/clk-pro5.c|   6 +-
>  arch/arm/mach-uniphier/clk/clk-pxs2.c|   6 +-
>  arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c|  12 ---
>  arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c|  11 ---
>  arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c|   7 --
>  arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c|   7 --
>  arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c|  11 ---
>  common/usb.c |   2 +-
>  configs/am437x_gp_evm_defconfig  |   2 +
>  configs/am437x_sk_evm_defconfig  |   2 +
>  configs/am43xx_evm_defconfig |   2 +
>  configs/am43xx_evm_ethboot_defconfig |   2 +
>  configs/am43xx_evm_qspiboot_defconfig|   2 +
>  configs/am43xx_evm_usbhost_boot_defconfig|   2 +
>  configs/am57xx_evm_defconfig |   3 +
>  configs/am57xx_evm_nodt_defconfig|   3 +
>  configs/bf526-ezbrd_defconfig|   1 +
>  configs/bf527-ezkit-v2_defconfig |   1 +
>  configs/bf527-ezkit_defconfig|   1 +
>  configs/bf548-ezkit_defconfig|   1 +
>  configs/cm_t43_defconfig |   3 +
>  configs/dra72_evm_defconfig  |   2 +
>  configs/dra74_evm_defconfig  |   2 +
>  configs/dra7xx_evm_defconfig |   2 +
>  configs/dra7xx_evm_qspiboot_defconfig|   2 +
>  configs/dra7xx_evm_uart3_defconfig   |   2 +
>  configs/k2e_evm_defconfig|   3 +
>  configs/k2g_evm_defconfig|   3 +
>  configs/k2hk_evm_defconfig   |   3 +
>  configs/k2l_evm_defconfig|   3 +
>  configs/ls1021aqds_ddr4_nor_defconfig|   3 +
>  configs/ls1021aqds_ddr4_nor_lpuart_defconfig |   3 +
>  configs/ls1021aqds_nand_defconfig|   3 +
>  configs/ls1021aqds_nor_SECURE_BOOT_defconfig |   3 +
>  configs/ls1021aqds_nor_defconfig |   3 +
>  configs/ls1021aqds_nor_lpuart_defconfig  |   3 +
>  configs/ls1021aqds_qspi_defconfig|   3 +
>  configs/ls1021aqds_sdcard_ifc_defconfig  |   3 +
>  configs/ls1021aqds_sdcard_qspi_defconfig |   3 +
>  configs/ls1021atwr_nor_SECURE_BOOT_defconfig |   3 +
>  configs/ls1021atwr_nor_defconfig |   3 +
>  configs/ls1021atwr_nor_lpuart_defconfig  |   3 +
>  configs/ls1021atwr_qspi_defconfig|   3 +
>  configs/ls1021atwr_sdcard_ifc_defconfig  |   3 +
>  configs/ls1021atwr_sdcard_qspi_defconfig |   3 +
>  configs/ls1043aqds_defconfig |   3 +
>  configs/ls1043aqds_lpuart_defconfig  |   3 +
>  configs/ls1043aqds_nand_defconfig|   3 +
>  configs/ls1043aqds_nor_ddr3_defconfig|   3 +
>  configs/ls1043aqds_qspi_defconfig|   3 +
>  configs/ls1043aqds_sdcard_ifc_defconfig  |   3 +
>  configs/ls1043aqds_sdcard_qspi_defconfig |   3 +
>  configs/ls1043ardb_SECURE_BOOT_defconfig |   3 +
>  configs/ls1043ardb_defconfig |   3 +
>  configs/ls1043ardb_nand_defconfig|   3 +
>  configs/ls1043ardb_sdcard_defconfig  |   3 +
>  configs/ls2080aqds_SECURE_BOOT_defconfig |   3 +
>  configs/ls2080aqds_defconfig |   3 +
>  configs/ls2080aqds_nand_defconfig|   3 +
>  configs/ls2080ardb_SECURE_BOOT_defconfig |   3 +
>  configs/ls2080ardb_defconfig |   3 +
>  configs/ls2080ardb_nand_defconfig|   3 +
>  configs/odroid-xu3_defconfig |   2 +
>  

Re: [U-Boot] [PATCH] MARVELL: Delete now-superfluous board/Marvell/{common, include} dirs.

2016-05-16 Thread Marek Vasut
On 05/15/2016 06:12 PM, Robert P. J. Day wrote:
> 
> With dropping support for some boards and the deletion of some source
> files, it appears that both of these directories are now superfluous.
> 
> Signed-off-by: Robert P. J. Day 
> 
> ---

You can always run buildman for all arm boards and see what broke.
I use this script:

{(
branch=`git branch | grep '^*' | sed "s/^..//"`
dir=/tmp/bm-$1
arch="arm aarch64 mips powerpc nios2"
shift 1
./tools/buildman/buildman -o ${dir} -b ${branch} \
  --step=0 ${arch} $@
)}


-- 
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 04/10] ARM: uniphier: switch over to USB DM

2016-05-16 Thread Marek Vasut
On 05/16/2016 03:03 PM, Masahiro Yamada wrote:
> Hi Marek,
> 
> 2016-05-11 20:26 GMT+09:00 Marek Vasut :
>> On 05/11/2016 12:28 PM, Masahiro Yamada wrote:
>>
>> Please, do write commit messages.
>>
>>> Signed-off-by: Masahiro Yamada 
>>> ---
>>>
>>>  arch/arm/Kconfig   | 1 +
>>>  include/configs/uniphier.h | 4 
>>>  2 files changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 6b65d8e..59410cb 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -723,6 +723,7 @@ config ARCH_UNIPHIER
>>>   select DM_SERIAL
>>>   select DM_I2C
>>>   select DM_MMC
>>> + select DM_USB
>>>   help
>>> Support for UniPhier SoC family developed by Socionext Inc.
>>> (formerly, System LSI Business Division of Panasonic Corporation)
>>> diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
>>> index 18cb963..868f001 100644
>>> --- a/include/configs/uniphier.h
>>> +++ b/include/configs/uniphier.h
>>> @@ -136,6 +136,10 @@
>>>  #define CONFIG_FAT_WRITE
>>>  #define CONFIG_DOS_PARTITION
>>>
>>> +#ifdef CONFIG_USB_DWC3_UNIPHIER
>>> +#define CONFIG_USB_XHCI_DWC3
>>
>> Could this be converted to Kconfig ?
>>
> 
> I noticed this task was not so easy as I had imagined first.
> 
> Before moving CONFIB_USB_XHCI_DWC3,
> I need to move CONFIG_USB_XHCI(_HCD)
> because USB_XHCI_DWC3 depends on USB_XHCI_HCD.
> 
> Before moving CONFIB_USB_XHCI(_HCD),
> I need to move CONFIG_USB
> because USB_XHCI(_HCD) depends on USB.
> 
> A problem here is that many boards
> define CONFIG_USB_XHCI without CONFIG_USB.
> 
> In spite of that fact, finally I managed to
> convert them and pass buildman test.
> So, v2 is out now.
> 
> 
> 

Thanks!

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


Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration

2016-05-16 Thread Roger Quadros
On 16/05/16 14:10, Kishon Vijay Abraham I wrote:
> Hi Roger,
> 
> On Monday 16 May 2016 04:01 PM, Roger Quadros wrote:
>> On 16/05/16 13:03, Kishon Vijay Abraham I wrote:
>>> Hi Roger,
>>>
>>> On Monday 16 May 2016 03:19 PM, Roger Quadros wrote:
 On 16/05/16 12:26, Roger Quadros wrote:
> On 16/05/16 12:06, Roger Quadros wrote:
>> On 13/05/16 15:45, Marek Vasut wrote:
>>> On 05/13/2016 02:36 PM, Roger Quadros wrote:
 Currently CONFIG_USB_DWC3 is not selected so doing a usb start
 command results in a serious error [1].
>>>
>>> Why does this error happen ? That is what should be fixed. Selecting
>>> some random options seems like papering over a bug.
>>
>> Agreed. I was lazy :P.
>
> OK. The issue is like this.
>
> CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls
> usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c 
> which calls
> board_usb_init().
>>>
>>> IIRC, board_usb_init for xhci (omap) is mostly a NOP.
>>
>> Then who will call board_usb_init() for host case?
>>
>
> But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 
> is defined
> and that is missing in am57xx_evm.h leading to the serious error. We're 
> trying to
> access the IP without turning on the necessary clocks.
>>>
>>> clocks are not turned on in board_usb_init() right? The board_usb_init() in
>>> am57xx/board.c is used only for gadget mode.
>
> So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or 
> something else.
>>>
>>> right, but before that we might have to cleanup xhci-omap.
>
> But then again looking into the future, what if we want only gadget 
> operation?
> That would not define XHCI, but we still need board_usb_init(). So 
> board_usb_init()
> should be defined based on CONFIG_CMD_USB=y?
>
> What do you suggest?

 But board_usb_init() calls 

 ti_usb_phy_uboot_init(_phy1_device);
 dwc3_omap_uboot_init(_otg_ss1_glue);
 dwc3_uboot_init(_otg_ss1);

 which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and 
 CONFIG_USB_DWC3
 respectively.
>>>
>>> IMO we should cleanup xhci-omap so that all the initializations are done 
>>> using
>>> ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify
>>> dwc3_uboot_init to initialize host or device based on CONFIG_*.
>>>
>>
>> I'm still trying to get a grip of how USB works in u-boot.
>> Is CONFIG_CMD_USB only meant for host mode or gadget mode as well?
> 
> IIRC it is only for host. Commands like usb start, usb stop are used to start
> and stop host.
>> Is dual-role even required in u-boot? probably it is not a good idea and we 
>> just
>> ignore it for simplicity.
> 
> yeah.
>>
>> What determines whether a USB port is meant for Host or device operation? Is 
>> it
>> the CONFIG_ or caller of board_usb_init()?
> It should be the caller of board_usb_init(). The same port can be used as
> device or host based on command used (the command determines the caller of
> board_usb_init).

Then it is upto board_usb_init() to complain if it is called for some mode
and the respective drivers are not enabled.

board_usb_init() must be defined in the board if CONFIG_CMD_USB || USB_GADGET

But there is no single config option for USB_GADGET. people seem to be calling
board_usb_init() from all over the place without any dependency on USB_GADGET.
e.g. dfu.c, ether.c, fastboot.c, thordown.c, usb_mass_storage.c, ether.c

So things will break with various configurations.
So probably for now board_usb_init() has to be always defined.

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


Re: [U-Boot] [PATCH 10/12] cmd: qfw: do not depend on x86

2016-05-16 Thread Bin Meng
Hi Miao,

On Mon, May 16, 2016 at 5:44 PM, Miao Yan  wrote:
> Hi Bin,
>
> 2016-05-13 22:00 GMT+08:00 Bin Meng :
>> Hi Miao,
>>
>> On Fri, May 13, 2016 at 2:29 PM, Miao Yan  wrote:
>>> The qfw command interface used to depend on X86, this patch removes
>>> this restriction so it can be built for sandbox for testing. For normal
>>> usage, it can only be used with CONFIG_QEMU.
>>>
>>> Signed-off-by: Miao Yan 
>>> ---
>>
>> Reviewed-by: Bin Meng 
>>
>> Would you prepare a patch to enable this on Sandbox?
>
> I'll give it a try. Do you prefer to do that in this patch-set or submit 
> later ?
>

Please do in this patch-set so that we can test the sandbox build with
this qfw command.

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


Re: [U-Boot] [PATCH 05/12] x86: qemu: split qfw command interface and qfw core

2016-05-16 Thread Bin Meng
Hi Miao,

On Mon, May 16, 2016 at 5:50 PM, Miao Yan  wrote:
> Hi Bin,
>
> 2016-05-16 16:47 GMT+08:00 Bin Meng :
>> Hi Miao,
>>
>> On Fri, May 13, 2016 at 2:29 PM, Miao Yan  wrote:
>>> This patch splits qfw command interface and qfw core function into two
>>> files, and introduces a new Kconfig option (CONFIG_QFW). for
>>> qfw core.
>>>
>>> Now when qfw command interface is enabled, it will automatically select
>>> qfw core. This patch also makes the ACPI table generation select
>>> CONFIG_QFW.
>>>
>>> Signed-off-by: Miao Yan 
>>> ---
>>>  arch/x86/Kconfig   |   2 +-
>>>  arch/x86/cpu/mp_init.c |   6 +-
>>>  arch/x86/cpu/qemu/Makefile |   3 +-
>>>  arch/x86/cpu/qemu/acpi_table.c |   2 +
>>>  arch/x86/cpu/qemu/qemu.c   |   4 +
>>>  cmd/Kconfig|   1 +
>>>  cmd/Makefile   |   2 +-
>>>  cmd/cmd_qfw.c  | 182 +
>>
>> The file name should be qfw.c without cmd_
>>
>>>  cmd/qemu_fw_cfg.c  | 353 
>>> -
>>
>> And I suspect you can also use "git mv" for cmd/qemu_fw_cfg.c. "git mv
>> cmd/qemu_fw_cfg.c cmd/qfw.c"
>
> But there is already a qfw.c under driver/misc/, having two files
> using the same name seems a bit confusing.
>

No problem because they are in different directory, and the command
one is in a directory named 'cmd'.

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


Re: [U-Boot] [PATCH v3 1/7] efi_loader: Add network access support

2016-05-16 Thread Simon Glass
Hi Alexander,

On 14 May 2016 at 14:34, Alexander Graf  wrote:
>
>
>> Am 14.05.2016 um 21:49 schrieb Simon Glass :
>>
>> Hi Alexander,
>>
>>> On 10 May 2016 at 15:25, Alexander Graf  wrote:
>>> We can now successfully boot EFI applications from disk, but users
>>> may want to also run them from a PXE setup.
>>>
>>> This patch implements rudimentary network support, allowing a payload
>>> to send and receive network packets.
>>>
>>> With this patch, I was able to successfully run grub2 with network
>>> access inside of QEMU's -M xlnx-ep108 and on a zcu102 system.
>>>
>>> Signed-off-by: Alexander Graf 
>>>
>>> ---
>>>
>>> v2 -> v3:
>>>
>>>  - Align initialization sequence with net code
>>>  - Set device to initialized after init call
>>>  - Align tx buffers to DMA alignment (rx gets memcpy'd)
>>>  - Add comment about eth_rx()
>>> ---
>>> cmd/bootefi.c|   7 ++
>>> include/efi_api.h| 119 ++
>>> include/efi_loader.h |   7 ++
>>> include/net.h|   2 +-
>>> lib/efi_loader/Makefile  |   1 +
>>> lib/efi_loader/efi_net.c | 314 
>>> +++
>>> net/bootp.c  |   2 +
>>> net/net.c|   4 +-
>>> net/tftp.c   |   2 +
>>> 9 files changed, 455 insertions(+), 3 deletions(-)
>>> create mode 100644 lib/efi_loader/efi_net.c
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index 7f552fc..d3a2331 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -197,6 +197,13 @@ static unsigned long do_bootefi_exec(void *efi, void 
>>> *fdt)
>>> #ifdef CONFIG_LCD
>>>efi_gop_register();
>>> #endif
>>> +#ifdef CONFIG_NET
>>> +   void *nethandle = loaded_image_info.device_handle;
>>> +   efi_net_register();
>>> +
>>> +   if (!memcmp(bootefi_device_path[0].str, "N\0e\0t", 6))
>>> +   loaded_image_info.device_handle = nethandle;
>>> +#endif
>>>
>>>/* Call our payload! */
>>> #ifdef DEBUG_EFI
>>> diff --git a/include/efi_api.h b/include/efi_api.h
>>> index 51d7586..20035d7 100644
>>> --- a/include/efi_api.h
>>> +++ b/include/efi_api.h
>>> @@ -412,4 +412,123 @@ struct efi_gop
>>>struct efi_gop_mode *mode;
>>> };
>>>
>>> +#define EFI_SIMPLE_NETWORK_GUID \
>>> +   EFI_GUID(0xa19832b9, 0xac25, 0x11d3, \
>>> +0x9a, 0x2d, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
>>> +
>>> +struct efi_mac_address {
>>> +   char mac_addr[32];
>>> +};
>>> +
>>> +struct efi_ip_address {
>>> +   u8 ip_addr[16];
>>> +};
>>> +
>>> +enum efi_simple_network_state {
>>> +   EFI_NETWORK_STOPPED,
>>> +   EFI_NETWORK_STARTED,
>>> +   EFI_NETWORK_INITIALIZED,
>>> +};
>>> +
>>> +struct efi_simple_network_mode {
>>> +   enum efi_simple_network_state state;
>>> +   u32 hwaddr_size;
>>> +   u32 media_header_size;
>>> +   u32 max_packet_size;
>>> +   u32 nvram_size;
>>> +   u32 nvram_access_size;
>>> +   u32 receive_filter_mask;
>>> +   u32 receive_filter_setting;
>>> +   u32 max_mcast_filter_count;
>>> +   u32 mcast_filter_count;
>>> +   struct efi_mac_address mcast_filter[16];
>>> +   struct efi_mac_address current_address;
>>> +   struct efi_mac_address broadcast_address;
>>> +   struct efi_mac_address permanent_address;
>>> +   u8 if_type;
>>> +   u8 mac_changeable;
>>> +   u8 multitx_supported;
>>> +   u8 media_present_supported;
>>> +   u8 media_present;
>>> +};
>>> +
>>> +#define EFI_SIMPLE_NETWORK_RECEIVE_UNICAST 0x01,
>>> +#define EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST 0x02,
>>> +#define EFI_SIMPLE_NETWORK_RECEIVE_BROADCAST 0x04,
>>> +#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS   0x08,
>>> +#define EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST 0x10,
>>> +
>>> +struct efi_simple_network
>>> +{
>>> +   u64 revision;
>>> +   efi_status_t (EFIAPI *start)(struct efi_simple_network *this);
>>> +   efi_status_t (EFIAPI *stop)(struct efi_simple_network *this);
>>> +   efi_status_t (EFIAPI *initialize)(struct efi_simple_network *this,
>>> +   ulong extra_rx, ulong extra_tx);
>>> +   efi_status_t (EFIAPI *reset)(struct efi_simple_network *this,
>>> +   int extended_verification);
>>> +   efi_status_t (EFIAPI *shutdown)(struct efi_simple_network *this);
>>> +   efi_status_t (EFIAPI *receive_filters)(struct efi_simple_network 
>>> *this,
>>> +   u32 enable, u32 disable, int reset_mcast_filter,
>>> +   ulong mcast_filter_count,
>>> +   struct efi_mac_address *mcast_filter);
>>> +   efi_status_t (EFIAPI *station_address)(struct efi_simple_network 
>>> *this,
>>> +   int reset, struct efi_mac_address *new_mac);
>>> +   efi_status_t (EFIAPI *statistics)(struct efi_simple_network *this,
>>> +   int reset, ulong *stat_size, void 

Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

2016-05-16 Thread Bhupesh Sharma
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, May 16, 2016 5:51 PM
> On 16.05.16 14:04, Bhupesh Sharma wrote:
> >
> >
> >> -Original Message-
> >> From: Alexander Graf [mailto:ag...@suse.de]
> >> Sent: Monday, May 16, 2016 1:09 PM
> >> To: Amit Tomer 
> >> Cc: Bhupesh Sharma ; york sun
> >> ; u-boot@lists.denx.de; Peter Newton
> >> 
> >> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> >>
> >>
> >>
> >>> Am 16.05.2016 um 08:58 schrieb Amit Tomer :
> >>>
>  On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
> >>  wrote:
>  Note that UEFI firmware support is already available on LS2080A-
> RDB
>  and allows Booting distributions like CentOS on the same.
> >>>
> >>> Sorry to intervene here but it's about having the EFI support
> inside
> >>> u-boot itself that may *not* required to have separate UEFI
> firmware
> >>> to boot various distributions.
> >>>
> >>> Please correct, if it's not right ?
> >>
> >> It's correct. The idea is to allow everyone to boot using the uEFI
> >> entry point in Linux (or any other OS), regardless of whether they
> >> want to run U-Boot or a TianoCore based formware.
> >>
> >> This might seem useless today for embedded use cases, but some
> >> features are only available via an EFI entry, such as kASLR. You can
> >> also invoke Linux directly using the "bootefi" command, as Linux is
> >> an EFI binary itself. That way the boot path doesn't become much
> >> longer than with booti today.
> >>
> >
> > The default firmware being offered by NXP to boot distros on LS2080A
> and variants is UEFI.
> >
> > EFI application support in u-boot doesn't present a solution to
> things
> > like run-time variable/service support that is required by distros to
> > update firmware components on the go. And there are several other
> > services being offered by UEFI to help distro boot e.g. secure uefi
> boot through x.509 certifications compliant to UEFI specifications.
> 
> Don't get me wrong - I think it's great if there is a TianoCore based
> firmware for LS2080A. But I didn't get the impression that there is a
> TianoCore based firmware for every NXP SoC out there, so enabling all
> of them to use the U-Boot provided uEFI implementation is still a win.
> 
> That said, there's nothing that keeps us from implementing the bits you
> mentioned in U-Boot either. There is support for RTS in U-Boot, we just
> didn't convert any drivers (RTC comes to mind first) yet.
> 
> There's also no support for uEFI environment variables, but mostly
> because most systems I've used this code on so far just didn't have any
> storage to put them.
> 
> Certification checks also shouldn't be an issue if someone cared enough
> about them.
> 
> But I don't think we need a discussion of TianoCore vs U-Boot. What
> everyone really wants is to have things "just work". And some customers
> just prefer U-Boot for various reasons that are outside of my control.
> If they can run the same boot path as everyone else, it makes life for
> me as distribution vendor easier. And unlike other people in the
> community, I don't think being a TianoCore+ACPI messiah is any helpful
> for that goal.

Alex - that's exactly my point. UEFI is currently planned as the default
firmware on all QorIQ-LS ARMv8 SoCs for supporting distros. It's good to have a
u-boot based solution for SoCs which don't support UEFI, but having both 
supported to boot distros 
causes confusion to the end user (IMHO), as the capabilities would vary 
drastically.

Regarding adding support for run-time variable/services, we can always port
everything over from the UEFI specifications - ACPI, run-time variable/services
into u-boot. I think it's a great alternative on SoCs which don't have UEFI 
support available.

But LS2080A and friends (LS1043A) already have UEFI support available and 
support
distros like CentOS to be installed and boot'ed. So, these SoCs would not 
require
an equivalent u-boot + EFI_Application like environment to boot distro.

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


Re: [U-Boot] [PATCH 0/5] MIPS Release 6 Support

2016-05-16 Thread Daniel Schwierzeck


Am 16.05.2016 um 11:52 schrieb Paul Burton:
> This series introduces support for building U-Boot for release 6 of the
> MIPS architecture. This is supported by CPUs such as the M62xx, I6400 &
> P6600 as well as by emulators such as QEMU.
> 
> Paul Burton (5):
>   MIPS: Use unchecked immediate addition/subtraction
>   MIPS: Simplify CONFIG_SYS_CPU values
>   MIPS: Support for targetting MIPSr6
>   malta: Remove ".set mips32" directive
>   malta: Support MIPS32r6 configurations
> 
>  arch/mips/Kconfig  | 39 
> ++
>  arch/mips/Makefile |  2 ++
>  arch/mips/cpu/start.S  | 22 +++--
>  arch/mips/lib/cache_init.S |  2 +-
>  board/imgtec/malta/lowlevel_init.S |  1 -
>  5 files changed, 46 insertions(+), 20 deletions(-)
> 

all patches applied to u-boot-mips/next, thanks

-- 
- Daniel



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


Re: [U-Boot] Remove sh2, sh3, sh4 architecture?

2016-05-16 Thread Simon Glass
Hi,

On 16 May 2016 at 00:18, Yoshinori Sato  wrote:
> On Sun, 15 May 2016 08:19:39 +0900,
> Simon Glass wrote:
>>
>> Hi,
>>
>> On 18 October 2015 at 10:19, Masahiro Yamada
>>  wrote:
>> > 2015-10-19 0:54 GMT+09:00 Tom Rini :
>> >> On Mon, Oct 19, 2015 at 12:30:43AM +0900, Masahiro Yamada wrote:
>> >>> 2015-10-18 21:19 GMT+09:00 Simon Glass :
>> >>> > Hi,
>> >>> >
>> >>> > It looks like these have no maintainer and have not been converted to
>> >>> > generic board. Should we remove the 'sh' architecture?
>> >>> >
>> >>> > Regards,
>> >>> > Simon
>> >>>
>> >>>
>> >>> The maintainer, Nobuhiro, was at the U-Boot mini summit,
>> >>> but, indeed, no work for SH these days.
>> >>>
>> >>> Since he left Renesas and went back to Hitachi,
>> >>> he is now a complete volunteer, I guess.
>> >>>
>> >>> If the maintainer responsibility is painful for him,
>> >>> he can take a step back, but I hope he can continue contribution...
>> >>> Nobuhiro?
>> >>
>> >> I'd hate to see SH2 leave since it's becoming the J-Core architecture..
>> >> Perhaps someone in the community would like to help out too?
>> >
>> > Agree.  Jeff talked about that at Dublin.
>> >
>>
>> I haven't seen any activity. Does anyone have an update?
>>
>
> I have converted code, but it can't be tested by a exsitance target.
>

Are you planning to send patches? We could still take them given that
the alternative is removal. Is there an emulator/qemu?

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


Re: [U-Boot] [PATCH 04/10] ARM: uniphier: switch over to USB DM

2016-05-16 Thread Masahiro Yamada
Hi Marek,

2016-05-11 20:26 GMT+09:00 Marek Vasut :
> On 05/11/2016 12:28 PM, Masahiro Yamada wrote:
>
> Please, do write commit messages.
>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  arch/arm/Kconfig   | 1 +
>>  include/configs/uniphier.h | 4 
>>  2 files changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 6b65d8e..59410cb 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -723,6 +723,7 @@ config ARCH_UNIPHIER
>>   select DM_SERIAL
>>   select DM_I2C
>>   select DM_MMC
>> + select DM_USB
>>   help
>> Support for UniPhier SoC family developed by Socionext Inc.
>> (formerly, System LSI Business Division of Panasonic Corporation)
>> diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
>> index 18cb963..868f001 100644
>> --- a/include/configs/uniphier.h
>> +++ b/include/configs/uniphier.h
>> @@ -136,6 +136,10 @@
>>  #define CONFIG_FAT_WRITE
>>  #define CONFIG_DOS_PARTITION
>>
>> +#ifdef CONFIG_USB_DWC3_UNIPHIER
>> +#define CONFIG_USB_XHCI_DWC3
>
> Could this be converted to Kconfig ?
>

I noticed this task was not so easy as I had imagined first.

Before moving CONFIB_USB_XHCI_DWC3,
I need to move CONFIG_USB_XHCI(_HCD)
because USB_XHCI_DWC3 depends on USB_XHCI_HCD.

Before moving CONFIB_USB_XHCI(_HCD),
I need to move CONFIG_USB
because USB_XHCI(_HCD) depends on USB.

A problem here is that many boards
define CONFIG_USB_XHCI without CONFIG_USB.

In spite of that fact, finally I managed to
convert them and pass buildman test.
So, v2 is out now.



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


[U-Boot] [PATCH v2 00/13] usb: dwc3: rework DWC3 and convert UniPhier xHCI driver to DM

2016-05-16 Thread Masahiro Yamada



Masahiro Yamada (13):
  configs: blackfin: move CONFIG_USB to defconfig
  usb: move CONFIG_USB_XHCI to Kconfig with renaming
  usb: move CONFIG_USB_XHCI_DWC3 to Kconfig
  usb: xhci: add struct devrequest declaration to xhci.h
  usb: dwc3: change DWC3 core support code into a driver
  usb: dwc3: add UniPhier specific glue layer
  ARM: uniphier: switch over to USB DM
  ARM: uniphier: enable DWC3 xHCI driver
  usb: uniphier: remove UniPhier xHCI driver
  ARM: uniphier: delete unnecessary xHCI pin-mux settings
  ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG
  ARM: dts: uniphier: add/update xHCI nodes
  ARM: uniphier: enable Generic EHCI for PH1-Pro4

 arch/arm/Kconfig |   1 +
 arch/arm/dts/uniphier-ph1-ld20.dtsi  |  17 
 arch/arm/dts/uniphier-ph1-pro4-ref.dts   |   4 +
 arch/arm/dts/uniphier-ph1-pro4.dtsi  |  32 --
 arch/arm/dts/uniphier-ph1-pro5.dtsi  |  32 --
 arch/arm/dts/uniphier-proxstream2.dtsi   |  32 --
 arch/arm/mach-uniphier/clk/clk-pro4.c|   6 +-
 arch/arm/mach-uniphier/clk/clk-pro5.c|   6 +-
 arch/arm/mach-uniphier/clk/clk-pxs2.c|   6 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c|  12 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c|  11 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c|   7 --
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c|   7 --
 arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c|  11 ---
 common/usb.c |   2 +-
 configs/am437x_gp_evm_defconfig  |   2 +
 configs/am437x_sk_evm_defconfig  |   2 +
 configs/am43xx_evm_defconfig |   2 +
 configs/am43xx_evm_ethboot_defconfig |   2 +
 configs/am43xx_evm_qspiboot_defconfig|   2 +
 configs/am43xx_evm_usbhost_boot_defconfig|   2 +
 configs/am57xx_evm_defconfig |   3 +
 configs/am57xx_evm_nodt_defconfig|   3 +
 configs/bf526-ezbrd_defconfig|   1 +
 configs/bf527-ezkit-v2_defconfig |   1 +
 configs/bf527-ezkit_defconfig|   1 +
 configs/bf548-ezkit_defconfig|   1 +
 configs/cm_t43_defconfig |   3 +
 configs/dra72_evm_defconfig  |   2 +
 configs/dra74_evm_defconfig  |   2 +
 configs/dra7xx_evm_defconfig |   2 +
 configs/dra7xx_evm_qspiboot_defconfig|   2 +
 configs/dra7xx_evm_uart3_defconfig   |   2 +
 configs/k2e_evm_defconfig|   3 +
 configs/k2g_evm_defconfig|   3 +
 configs/k2hk_evm_defconfig   |   3 +
 configs/k2l_evm_defconfig|   3 +
 configs/ls1021aqds_ddr4_nor_defconfig|   3 +
 configs/ls1021aqds_ddr4_nor_lpuart_defconfig |   3 +
 configs/ls1021aqds_nand_defconfig|   3 +
 configs/ls1021aqds_nor_SECURE_BOOT_defconfig |   3 +
 configs/ls1021aqds_nor_defconfig |   3 +
 configs/ls1021aqds_nor_lpuart_defconfig  |   3 +
 configs/ls1021aqds_qspi_defconfig|   3 +
 configs/ls1021aqds_sdcard_ifc_defconfig  |   3 +
 configs/ls1021aqds_sdcard_qspi_defconfig |   3 +
 configs/ls1021atwr_nor_SECURE_BOOT_defconfig |   3 +
 configs/ls1021atwr_nor_defconfig |   3 +
 configs/ls1021atwr_nor_lpuart_defconfig  |   3 +
 configs/ls1021atwr_qspi_defconfig|   3 +
 configs/ls1021atwr_sdcard_ifc_defconfig  |   3 +
 configs/ls1021atwr_sdcard_qspi_defconfig |   3 +
 configs/ls1043aqds_defconfig |   3 +
 configs/ls1043aqds_lpuart_defconfig  |   3 +
 configs/ls1043aqds_nand_defconfig|   3 +
 configs/ls1043aqds_nor_ddr3_defconfig|   3 +
 configs/ls1043aqds_qspi_defconfig|   3 +
 configs/ls1043aqds_sdcard_ifc_defconfig  |   3 +
 configs/ls1043aqds_sdcard_qspi_defconfig |   3 +
 configs/ls1043ardb_SECURE_BOOT_defconfig |   3 +
 configs/ls1043ardb_defconfig |   3 +
 configs/ls1043ardb_nand_defconfig|   3 +
 configs/ls1043ardb_sdcard_defconfig  |   3 +
 configs/ls2080aqds_SECURE_BOOT_defconfig |   3 +
 configs/ls2080aqds_defconfig |   3 +
 configs/ls2080aqds_nand_defconfig|   3 +
 configs/ls2080ardb_SECURE_BOOT_defconfig |   3 +
 configs/ls2080ardb_defconfig |   3 +
 configs/ls2080ardb_nand_defconfig|   3 +
 configs/odroid-xu3_defconfig |   2 +
 configs/peach-pi_defconfig   |   2 +
 configs/peach-pit_defconfig  |   2 +
 configs/smdk5420_defconfig   |   2 +
 configs/uniphier_ld20_defconfig  |   2 +
 

[U-Boot] [PATCH v2 09/13] usb: uniphier: remove UniPhier xHCI driver

2016-05-16 Thread Masahiro Yamada
UniPhier platform switched to DWC3 core with UniPhier specific
glue layer to support USB3.  This pre-DM driver is no longer
needed.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Marek Vasut 
---

Changes in v2: None

 drivers/usb/host/Kconfig |  7 
 drivers/usb/host/Makefile|  1 -
 drivers/usb/host/xhci-uniphier.c | 85 
 include/fdtdec.h |  1 -
 lib/fdtdec.c |  1 -
 5 files changed, 95 deletions(-)
 delete mode 100644 drivers/usb/host/xhci-uniphier.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a6645dd..3710588 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -11,13 +11,6 @@ config USB_XHCI_HCD
 
 if USB_XHCI_HCD
 
-config USB_XHCI_UNIPHIER
-   bool "Support for UniPhier on-chip xHCI USB controller"
-   depends on ARCH_UNIPHIER
-   default y
-   ---help---
- Enables support for the on-chip xHCI controller on UniPhier SoCs.
-
 config USB_XHCI_DWC3
bool "DesignWare USB3 DRD Core Support"
help
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 8b54fde..eb85650 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -63,7 +63,6 @@ obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
 obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o
 obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
-obj-$(CONFIG_USB_XHCI_UNIPHIER) += xhci-uniphier.o
 
 # designware
 obj-$(CONFIG_USB_DWC2) += dwc2.o
diff --git a/drivers/usb/host/xhci-uniphier.c b/drivers/usb/host/xhci-uniphier.c
deleted file mode 100644
index 1b3f3d2..000
--- a/drivers/usb/host/xhci-uniphier.c
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * Copyright (C) 2015 Masahiro Yamada 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "xhci.h"
-
-static int get_uniphier_xhci_base(int index, struct xhci_hccr **base)
-{
-   DECLARE_GLOBAL_DATA_PTR;
-   int node_list[2];
-   fdt_addr_t addr;
-   int count;
-
-   count = fdtdec_find_aliases_for_id(gd->fdt_blob, "usb",
-  COMPAT_SOCIONEXT_XHCI, node_list,
-  ARRAY_SIZE(node_list));
-
-   if (index >= count)
-   return -ENODEV;
-
-   addr = fdtdec_get_addr(gd->fdt_blob, node_list[index], "reg");
-   if (addr == FDT_ADDR_T_NONE)
-   return -ENODEV;
-
-   *base = (struct xhci_hccr *)addr;
-
-   return 0;
-}
-
-#define USB3_RST_CTRL  0x00100040
-#define IOMMU_RST_N(1 << 5)
-#define LINK_RST_N (1 << 4)
-
-static void uniphier_xhci_reset(void __iomem *base, int on)
-{
-   u32 tmp;
-
-   tmp = readl(base + USB3_RST_CTRL);
-
-   if (on)
-   tmp &= ~(IOMMU_RST_N | LINK_RST_N);
-   else
-   tmp |= IOMMU_RST_N | LINK_RST_N;
-
-   writel(tmp, base + USB3_RST_CTRL);
-}
-
-int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor)
-{
-   int ret;
-   struct xhci_hccr *cr;
-   struct xhci_hcor *or;
-
-   ret = get_uniphier_xhci_base(index, );
-   if (ret < 0)
-   return ret;
-
-   uniphier_xhci_reset(cr, 0);
-
-   or = (void *)cr + HC_LENGTH(xhci_readl(>cr_capbase));
-
-   *hccr = cr;
-   *hcor = or;
-
-   return 0;
-}
-
-void xhci_hcd_stop(int index)
-{
-   int ret;
-   struct xhci_hccr *cr;
-
-   ret = get_uniphier_xhci_base(index, );
-   if (ret < 0)
-   return;
-
-   uniphier_xhci_reset(cr, 1);
-}
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 37d482a..d1fddaa 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -158,7 +158,6 @@ enum fdt_compat_id {
COMPAT_AMS_AS3722,  /* AMS AS3722 PMIC */
COMPAT_INTEL_ICH_SPI,   /* Intel ICH7/9 SPI controller */
COMPAT_INTEL_QRK_MRC,   /* Intel Quark MRC */
-   COMPAT_SOCIONEXT_XHCI,  /* Socionext UniPhier xHCI */
COMPAT_INTEL_PCH,   /* Intel PCH */
COMPAT_ALTERA_SOCFPGA_DWMAC,/* SoCFPGA Ethernet controller */
COMPAT_ALTERA_SOCFPGA_DWMMC,/* SoCFPGA DWMMC controller */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 70acc29..e316cc8 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -63,7 +63,6 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(AMS_AS3722, "ams,as3722"),
COMPAT(INTEL_ICH_SPI, "intel,ich-spi"),
COMPAT(INTEL_QRK_MRC, "intel,quark-mrc"),
-   COMPAT(SOCIONEXT_XHCI, "socionext,uniphier-xhci"),
COMPAT(COMPAT_INTEL_PCH, "intel,bd82x6x"),
COMPAT(ALTERA_SOCFPGA_DWMAC, "altr,socfpga-stmmac"),
COMPAT(ALTERA_SOCFPGA_DWMMC, "altr,socfpga-dw-mshc"),
-- 
1.9.1

___
U-Boot mailing 

[U-Boot] [PATCH v2 13/13] ARM: uniphier: enable Generic EHCI for PH1-Pro4

2016-05-16 Thread Masahiro Yamada
On Driver Model USB, EHCI and xHCI can be enabled at the same time.
PH1-Pro4 SoC has two EHCI cores and two xHCI cores, so enable the
Generic EHCI driver.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 configs/uniphier_pro4_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig
index c9d104b..1e960b0 100644
--- a/configs/uniphier_pro4_defconfig
+++ b/configs/uniphier_pro4_defconfig
@@ -33,4 +33,6 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3_UNIPHIER=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
-- 
1.9.1

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


[U-Boot] [PATCH v2 12/13] ARM: dts: uniphier: add/update xHCI nodes

2016-05-16 Thread Masahiro Yamada
Adjust xHCI nodes to use the DWC3 core and the SoC-specific glue
layer for former SoCs.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/dts/uniphier-ph1-ld20.dtsi| 17 +
 arch/arm/dts/uniphier-ph1-pro4-ref.dts |  4 
 arch/arm/dts/uniphier-ph1-pro4.dtsi| 32 
 arch/arm/dts/uniphier-ph1-pro5.dtsi| 32 
 arch/arm/dts/uniphier-proxstream2.dtsi | 32 
 5 files changed, 93 insertions(+), 24 deletions(-)

diff --git a/arch/arm/dts/uniphier-ph1-ld20.dtsi 
b/arch/arm/dts/uniphier-ph1-ld20.dtsi
index f9cc3c4..5e2b595 100644
--- a/arch/arm/dts/uniphier-ph1-ld20.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld20.dtsi
@@ -256,6 +256,23 @@
#interrupt-cells = <3>;
interrupts = <1 9 4>;
};
+
+   usb: usb@65b0 {
+   compatible = "socionext,uniphier-ld20-dwc3";
+   reg = <0x65b0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb0>, <_usb1>,
+   <_usb2>, <_usb3>;
+   dwc3@65a0 {
+   compatible = "snps,dwc3";
+   reg = <0x65a0 0x1>;
+   interrupts = <0 134 4>;
+   tx-fifo-resize;
+   };
+   };
};
 };
 
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts 
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index 5be76e2..6cc5d1e 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -71,6 +71,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index d5767b6..7f42bc2 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -400,22 +400,38 @@
clocks = < 4>, < 6>;
};
 
-   usb0: usb@65a0 {
-   compatible = "socionext,uniphier-xhci", "generic-xhci";
+   usb0: usb@65b0 {
+   compatible = "socionext,uniphier-pro4-dwc3";
status = "disabled";
-   reg = <0x65a0 0x100>;
-   interrupts = <0 134 4>;
+   reg = <0x65b0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
pinctrl-names = "default";
pinctrl-0 = <_usb0>;
+   dwc3@65a0 {
+   compatible = "snps,dwc3";
+   reg = <0x65a0 0x1>;
+   interrupts = <0 134 4>;
+   tx-fifo-resize;
+   };
};
 
-   usb1: usb@65c0 {
-   compatible = "socionext,uniphier-xhci", "generic-xhci";
+   usb1: usb@65d0 {
+   compatible = "socionext,uniphier-pro4-dwc3";
status = "disabled";
-   reg = <0x65c0 0x100>;
-   interrupts = <0 137 4>;
+   reg = <0x65d0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
pinctrl-names = "default";
pinctrl-0 = <_usb1>;
+   dwc3@65c0 {
+   compatible = "snps,dwc3";
+   reg = <0x65c0 0x1>;
+   interrupts = <0 137 4>;
+   tx-fifo-resize;
+   };
};
 };
 
diff --git a/arch/arm/dts/uniphier-ph1-pro5.dtsi 
b/arch/arm/dts/uniphier-ph1-pro5.dtsi
index bd1b4b1..3036a76 100644
--- a/arch/arm/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro5.dtsi
@@ -379,22 +379,38 @@
bus-width = <4>;
};
 
-   usb0: usb@65a0 {
-   compatible = "socionext,uniphier-xhci", "generic-xhci";
+   usb0: usb@65b0 {
+   compatible = "socionext,uniphier-pro5-dwc3";
status = "disabled";
-   reg = <0x65a0 0x100>;
-   interrupts = <0 134 4>;
+   reg = <0x65b0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
pinctrl-names = "default";
pinctrl-0 = <_usb0>;
+   dwc3@65a0 {
+   compatible = "snps,dwc3";
+   reg = <0x65a0 0x1>;
+   interrupts = <0 134 4>;
+   tx-fifo-resize;
+   };
};
 
-   usb1: usb@65c0 {
-   compatible = "socionext,uniphier-xhci", 

[U-Boot] [PATCH v2 11/13] ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG

2016-05-16 Thread Masahiro Yamada
Now USB 3.0 feature is enabled/disabled by CONFIG_USB_DWC3_UNIPHIER.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/mach-uniphier/clk/clk-pro4.c | 6 +++---
 arch/arm/mach-uniphier/clk/clk-pro5.c | 6 +++---
 arch/arm/mach-uniphier/clk/clk-pxs2.c | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-uniphier/clk/clk-pro4.c 
b/arch/arm/mach-uniphier/clk/clk-pro4.c
index 8746d7d..6a01543 100644
--- a/arch/arm/mach-uniphier/clk/clk-pro4.c
+++ b/arch/arm/mach-uniphier/clk/clk-pro4.c
@@ -15,7 +15,7 @@ void uniphier_pro4_clk_init(void)
 
/* deassert reset */
tmp = readl(SC_RSTCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_USB3C0 |
SC_RSTCTRL_NRST_GIO;
 #endif
@@ -31,7 +31,7 @@ void uniphier_pro4_clk_init(void)
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp = readl(SC_RSTCTRL2);
tmp |= SC_RSTCTRL2_NRST_USB3B1 | SC_RSTCTRL2_NRST_USB3C1;
writel(tmp, SC_RSTCTRL2);
@@ -40,7 +40,7 @@ void uniphier_pro4_clk_init(void)
 
/* provide clocks */
tmp = readl(SC_CLKCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
SC_CLKCTRL_CEN_GIO;
 #endif
diff --git a/arch/arm/mach-uniphier/clk/clk-pro5.c 
b/arch/arm/mach-uniphier/clk/clk-pro5.c
index 823bb06..dd86cad 100644
--- a/arch/arm/mach-uniphier/clk/clk-pro5.c
+++ b/arch/arm/mach-uniphier/clk/clk-pro5.c
@@ -15,7 +15,7 @@ void uniphier_pro5_clk_init(void)
 
/* deassert reset */
tmp = readl(SC_RSTCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_GIO;
 #endif
 #ifdef CONFIG_NAND_DENALI
@@ -24,7 +24,7 @@ void uniphier_pro5_clk_init(void)
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp = readl(SC_RSTCTRL2);
tmp |= SC_RSTCTRL2_NRST_USB3B1;
writel(tmp, SC_RSTCTRL2);
@@ -33,7 +33,7 @@ void uniphier_pro5_clk_init(void)
 
/* provide clocks */
tmp = readl(SC_CLKCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
SC_CLKCTRL_CEN_GIO;
 #endif
diff --git a/arch/arm/mach-uniphier/clk/clk-pxs2.c 
b/arch/arm/mach-uniphier/clk/clk-pxs2.c
index 76bf856..3b50a20 100644
--- a/arch/arm/mach-uniphier/clk/clk-pxs2.c
+++ b/arch/arm/mach-uniphier/clk/clk-pxs2.c
@@ -15,7 +15,7 @@ void uniphier_pxs2_clk_init(void)
 
/* deassert reset */
tmp = readl(SC_RSTCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_GIO;
 #endif
 #ifdef CONFIG_UNIPHIER_ETH
@@ -27,7 +27,7 @@ void uniphier_pxs2_clk_init(void)
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp = readl(SC_RSTCTRL2);
tmp |= SC_RSTCTRL2_NRST_USB3B1;
writel(tmp, SC_RSTCTRL2);
@@ -36,7 +36,7 @@ void uniphier_pxs2_clk_init(void)
 
/* provide clocks */
tmp = readl(SC_CLKCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
SC_CLKCTRL_CEN_GIO;
 #endif
-- 
1.9.1

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


[U-Boot] [PATCH v2 02/13] usb: move CONFIG_USB_XHCI to Kconfig with renaming

2016-05-16 Thread Masahiro Yamada
Move CONFIG_USB_XHCI to defconfig files for all boards, renaming it
into CONFIG_USB_XHCI_HCD.

As commented in the help of "config USB_XHCI" entry, this has been
a TODO for a long time; now CONFIG_USB_XHCI_HCD and CONFIG_USB_XHCI
have been unified in favor of the former.

Note:
Some boards define CONFIG_USB_XHCI in their headers without
CONFIG_USB, which does not meet the "depends on" in Kconfig.
I added CONFIG_USB=y for those boards when converting.
Otherwise, they would fail to build.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 common/usb.c | 2 +-
 configs/am437x_gp_evm_defconfig  | 1 +
 configs/am437x_sk_evm_defconfig  | 1 +
 configs/am43xx_evm_defconfig | 1 +
 configs/am43xx_evm_ethboot_defconfig | 1 +
 configs/am43xx_evm_qspiboot_defconfig| 1 +
 configs/am43xx_evm_usbhost_boot_defconfig| 1 +
 configs/am57xx_evm_defconfig | 2 ++
 configs/am57xx_evm_nodt_defconfig| 2 ++
 configs/cm_t43_defconfig | 2 ++
 configs/dra72_evm_defconfig  | 1 +
 configs/dra74_evm_defconfig  | 1 +
 configs/dra7xx_evm_defconfig | 1 +
 configs/dra7xx_evm_qspiboot_defconfig| 1 +
 configs/dra7xx_evm_uart3_defconfig   | 1 +
 configs/k2e_evm_defconfig| 2 ++
 configs/k2g_evm_defconfig| 2 ++
 configs/k2hk_evm_defconfig   | 2 ++
 configs/k2l_evm_defconfig| 2 ++
 configs/ls1021aqds_ddr4_nor_defconfig| 2 ++
 configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 2 ++
 configs/ls1021aqds_nand_defconfig| 2 ++
 configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 2 ++
 configs/ls1021aqds_nor_defconfig | 2 ++
 configs/ls1021aqds_nor_lpuart_defconfig  | 2 ++
 configs/ls1021aqds_qspi_defconfig| 2 ++
 configs/ls1021aqds_sdcard_ifc_defconfig  | 2 ++
 configs/ls1021aqds_sdcard_qspi_defconfig | 2 ++
 configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 2 ++
 configs/ls1021atwr_nor_defconfig | 2 ++
 configs/ls1021atwr_nor_lpuart_defconfig  | 2 ++
 configs/ls1021atwr_qspi_defconfig| 2 ++
 configs/ls1021atwr_sdcard_ifc_defconfig  | 2 ++
 configs/ls1021atwr_sdcard_qspi_defconfig | 2 ++
 configs/ls1043aqds_defconfig | 2 ++
 configs/ls1043aqds_lpuart_defconfig  | 2 ++
 configs/ls1043aqds_nand_defconfig| 2 ++
 configs/ls1043aqds_nor_ddr3_defconfig| 2 ++
 configs/ls1043aqds_qspi_defconfig| 2 ++
 configs/ls1043aqds_sdcard_ifc_defconfig  | 2 ++
 configs/ls1043aqds_sdcard_qspi_defconfig | 2 ++
 configs/ls1043ardb_SECURE_BOOT_defconfig | 2 ++
 configs/ls1043ardb_defconfig | 2 ++
 configs/ls1043ardb_nand_defconfig| 2 ++
 configs/ls1043ardb_sdcard_defconfig  | 2 ++
 configs/ls2080aqds_SECURE_BOOT_defconfig | 2 ++
 configs/ls2080aqds_defconfig | 2 ++
 configs/ls2080aqds_nand_defconfig| 2 ++
 configs/ls2080ardb_SECURE_BOOT_defconfig | 2 ++
 configs/ls2080ardb_defconfig | 2 ++
 configs/ls2080ardb_nand_defconfig| 2 ++
 configs/odroid-xu3_defconfig | 1 +
 configs/peach-pi_defconfig   | 1 +
 configs/peach-pit_defconfig  | 1 +
 configs/smdk5420_defconfig   | 1 +
 configs/xilinx_zynqmp_ep_defconfig   | 1 +
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
 configs/xilinx_zynqmp_zcu102_defconfig   | 1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
 drivers/usb/host/Kconfig | 6 --
 drivers/usb/host/Makefile| 2 +-
 include/configs/am43xx_evm.h | 1 -
 include/configs/am57xx_evm.h | 1 -
 include/configs/cm_t43.h | 1 -
 include/configs/dra7xx_evm.h | 1 -
 include/configs/ds414.h  | 3 +--
 include/configs/exynos5420-common.h  | 1 -
 include/configs/ls1021aqds.h | 1 -
 include/configs/ls1021atwr.h | 1 -
 include/configs/ls1043aqds.h | 1 -
 include/configs/ls1043ardb.h | 1 -
 include/configs/ls2080aqds.h | 1 -
 include/configs/ls2080ardb.h | 1 -
 include/configs/smdk5420.h   | 1 -
 include/configs/ti_armv7_keystone2.h | 1 -
 include/configs/xilinx_zynqmp.h  | 1 -
 77 files changed, 101 insertions(+), 24 

[U-Boot] [PATCH v2 03/13] usb: move CONFIG_USB_XHCI_DWC3 to Kconfig

2016-05-16 Thread Masahiro Yamada
Create an entry for "config USB_XHCI_DWC3" in Kconfig and
switch over to it for all boards.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 configs/am437x_gp_evm_defconfig  | 1 +
 configs/am437x_sk_evm_defconfig  | 1 +
 configs/am43xx_evm_defconfig | 1 +
 configs/am43xx_evm_ethboot_defconfig | 1 +
 configs/am43xx_evm_qspiboot_defconfig| 1 +
 configs/am43xx_evm_usbhost_boot_defconfig| 1 +
 configs/am57xx_evm_defconfig | 1 +
 configs/am57xx_evm_nodt_defconfig| 1 +
 configs/cm_t43_defconfig | 1 +
 configs/dra72_evm_defconfig  | 1 +
 configs/dra74_evm_defconfig  | 1 +
 configs/dra7xx_evm_defconfig | 1 +
 configs/dra7xx_evm_qspiboot_defconfig| 1 +
 configs/dra7xx_evm_uart3_defconfig   | 1 +
 configs/k2e_evm_defconfig| 1 +
 configs/k2g_evm_defconfig| 1 +
 configs/k2hk_evm_defconfig   | 1 +
 configs/k2l_evm_defconfig| 1 +
 configs/ls1021aqds_ddr4_nor_defconfig| 1 +
 configs/ls1021aqds_ddr4_nor_lpuart_defconfig | 1 +
 configs/ls1021aqds_nand_defconfig| 1 +
 configs/ls1021aqds_nor_SECURE_BOOT_defconfig | 1 +
 configs/ls1021aqds_nor_defconfig | 1 +
 configs/ls1021aqds_nor_lpuart_defconfig  | 1 +
 configs/ls1021aqds_qspi_defconfig| 1 +
 configs/ls1021aqds_sdcard_ifc_defconfig  | 1 +
 configs/ls1021aqds_sdcard_qspi_defconfig | 1 +
 configs/ls1021atwr_nor_SECURE_BOOT_defconfig | 1 +
 configs/ls1021atwr_nor_defconfig | 1 +
 configs/ls1021atwr_nor_lpuart_defconfig  | 1 +
 configs/ls1021atwr_qspi_defconfig| 1 +
 configs/ls1021atwr_sdcard_ifc_defconfig  | 1 +
 configs/ls1021atwr_sdcard_qspi_defconfig | 1 +
 configs/ls1043aqds_defconfig | 1 +
 configs/ls1043aqds_lpuart_defconfig  | 1 +
 configs/ls1043aqds_nand_defconfig| 1 +
 configs/ls1043aqds_nor_ddr3_defconfig| 1 +
 configs/ls1043aqds_qspi_defconfig| 1 +
 configs/ls1043aqds_sdcard_ifc_defconfig  | 1 +
 configs/ls1043aqds_sdcard_qspi_defconfig | 1 +
 configs/ls1043ardb_SECURE_BOOT_defconfig | 1 +
 configs/ls1043ardb_defconfig | 1 +
 configs/ls1043ardb_nand_defconfig| 1 +
 configs/ls1043ardb_sdcard_defconfig  | 1 +
 configs/ls2080aqds_SECURE_BOOT_defconfig | 1 +
 configs/ls2080aqds_defconfig | 1 +
 configs/ls2080aqds_nand_defconfig| 1 +
 configs/ls2080ardb_SECURE_BOOT_defconfig | 1 +
 configs/ls2080ardb_defconfig | 1 +
 configs/ls2080ardb_nand_defconfig| 1 +
 configs/odroid-xu3_defconfig | 1 +
 configs/peach-pi_defconfig   | 1 +
 configs/peach-pit_defconfig  | 1 +
 configs/smdk5420_defconfig   | 1 +
 configs/xilinx_zynqmp_ep_defconfig   | 1 +
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
 configs/xilinx_zynqmp_zcu102_defconfig   | 1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
 drivers/usb/host/Kconfig | 6 ++
 include/configs/am43xx_evm.h | 1 -
 include/configs/am57xx_evm.h | 1 -
 include/configs/cm_t43.h | 1 -
 include/configs/dra7xx_evm.h | 1 -
 include/configs/exynos5-common.h | 1 -
 include/configs/ls1021aqds.h | 1 -
 include/configs/ls1021atwr.h | 1 -
 include/configs/ls1043aqds.h | 1 -
 include/configs/ls1043ardb.h | 1 -
 include/configs/ls2080aqds.h | 1 -
 include/configs/ls2080ardb.h | 1 -
 include/configs/ti_armv7_keystone2.h | 1 -
 include/configs/xilinx_zynqmp.h  | 1 -
 73 files changed, 65 insertions(+), 13 deletions(-)

diff --git a/configs/am437x_gp_evm_defconfig b/configs/am437x_gp_evm_defconfig
index 22620f0..f911281 100644
--- a/configs/am437x_gp_evm_defconfig
+++ b/configs/am437x_gp_evm_defconfig
@@ -39,6 +39,7 @@ CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GADGET=y
 CONFIG_USB_DWC3_OMAP=y
diff --git a/configs/am437x_sk_evm_defconfig b/configs/am437x_sk_evm_defconfig
index 6c96a17..b9e0aae 100644
--- a/configs/am437x_sk_evm_defconfig
+++ b/configs/am437x_sk_evm_defconfig
@@ -43,6 +43,7 @@ CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y

[U-Boot] [PATCH v2 10/13] ARM: uniphier: delete unnecessary xHCI pin-mux settings

2016-05-16 Thread Masahiro Yamada
Now UniPhier platform switched over to the DM-based xHCI driver.
The pin-muxing for that is automatically cared by the pinctrl
driver.  These ad-hoc pin-muxing code is no longer needed.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c | 12 
 arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c | 11 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c |  7 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c |  7 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c | 11 ---
 5 files changed, 48 deletions(-)

diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c
index 6066b16..0da280f 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c
@@ -31,16 +31,4 @@ void uniphier_ld20_pin_init(void)
sg_set_pinsel(17, 0, 8, 4); /* NFD7-> NFD7 */
sg_set_iectrl_range(3, 17);
 #endif
-
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(46, 0, 8, 4); /* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(47, 0, 8, 4); /* USB0OD   -> USB0OD */
-   sg_set_pinsel(48, 0, 8, 4); /* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(49, 0, 8, 4); /* USB1OD   -> USB1OD */
-   sg_set_pinsel(50, 0, 8, 4); /* USB2VBUS -> USB2VBUS */
-   sg_set_pinsel(51, 0, 8, 4); /* USB2OD   -> USB2OD */
-   sg_set_pinsel(52, 0, 8, 4); /* USB3VBUS -> USB3VBUS */
-   sg_set_pinsel(53, 0, 8, 4); /* USB3OD   -> USB3OD */
-   sg_set_iectrl_range(46, 53);
-#endif
 }
diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c
index 913722b..f3b7115 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c
@@ -32,15 +32,4 @@ void uniphier_ld6b_pin_init(void)
sg_set_pinsel(45, 0, 8, 4); /* NFD6   -> NFD6 */
sg_set_pinsel(46, 0, 8, 4); /* NFD7   -> NFD7 */
 #endif
-
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(56, 0, 8, 4); /* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(57, 0, 8, 4); /* USB0OD   -> USB0OD */
-   sg_set_pinsel(58, 0, 8, 4); /* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(59, 0, 8, 4); /* USB1OD   -> USB1OD */
-   sg_set_pinsel(60, 0, 8, 4); /* USB2VBUS -> USB2VBUS */
-   sg_set_pinsel(61, 0, 8, 4); /* USB2OD   -> USB2OD */
-   sg_set_pinsel(62, 0, 8, 4); /* USB3VBUS -> USB3VBUS */
-   sg_set_pinsel(63, 0, 8, 4); /* USB3OD   -> USB3OD */
-#endif
 }
diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c
index 3796491..871d3ef 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c
@@ -33,12 +33,5 @@ void uniphier_pro4_pin_init(void)
/* sg_set_pinsel(132, 1, 4, 8); */  /* TXD2   -> XNFCE1 */
 #endif
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(180, 0, 4, 8);/* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(181, 0, 4, 8);/* USB0OD   -> USB0OD */
-   sg_set_pinsel(182, 0, 4, 8);/* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(183, 0, 4, 8);/* USB1OD   -> USB1OD */
-#endif
-
writel(1, SG_LOADPINCTRL);
 }
diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c
index 32ba923..58dff18 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c
@@ -33,12 +33,5 @@ void uniphier_pro5_pin_init(void)
sg_set_pinsel(35, 0, 4, 8); /* NFD7   -> NFD7 */
 #endif
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(124, 0, 4, 8);/* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(125, 0, 4, 8);/* USB0OD   -> USB0OD */
-   sg_set_pinsel(126, 0, 4, 8);/* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(127, 0, 4, 8);/* USB1OD   -> USB1OD */
-#endif
-
writel(1, SG_LOADPINCTRL);
 }
diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c
index 2d62ab3..fc59205 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c
@@ -32,15 +32,4 @@ void uniphier_pxs2_pin_init(void)
sg_set_pinsel(45, 8, 8, 4); /* NFD6   -> NFD6 */
sg_set_pinsel(46, 8, 8, 4); /* NFD7   -> NFD7 */
 #endif
-
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(56, 8, 8, 4); /* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(57, 8, 8, 4); /* USB0OD   -> USB0OD */
-   sg_set_pinsel(58, 8, 8, 4); /* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(59, 8, 8, 4); /* USB1OD   -> USB1OD */
-   sg_set_pinsel(60, 8, 8, 4); /* USB2VBUS -> USB2VBUS */
-   sg_set_pinsel(61, 8, 8, 4); /* USB2OD   -> USB2OD */
-   sg_set_pinsel(62, 8, 8, 4); /* USB3VBUS -> USB3VBUS */
-   

[U-Boot] [PATCH v2 06/13] usb: dwc3: add UniPhier specific glue layer

2016-05-16 Thread Masahiro Yamada
Add UniPhier platform specific glue layer to support USB3 Host mode
on Synopsys DWC3 IP.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Marek Vasut 
---

Changes in v2:
  - Fix build error
  - Add missing PHY reset deassert

 drivers/usb/host/Kconfig |   7 +++
 drivers/usb/host/Makefile|   1 +
 drivers/usb/host/dwc3-uniphier.c | 119 +++
 3 files changed, 127 insertions(+)
 create mode 100644 drivers/usb/host/dwc3-uniphier.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 89580cc..a6645dd 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -24,6 +24,13 @@ config USB_XHCI_DWC3
  Say Y or if your system has a Dual Role SuperSpeed
  USB controller based on the DesignWare USB3 IP Core.
 
+config USB_DWC3_UNIPHIER
+   bool "DesignWare USB3 Host Support on UniPhier Platforms"
+   depends on ARCH_UNIPHIER && USB_XHCI_DWC3
+   help
+ Support of USB2/3 functionality in Socionext UniPhier platforms.
+ Say 'Y' here if you have one such device.
+
 endif
 
 config USB_OHCI_GENERIC
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 620d114..8b54fde 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_USB_EHCI_ZYNQ) += ehci-zynq.o
 # xhci
 obj-$(CONFIG_USB_XHCI_HCD) += xhci.o xhci-mem.o xhci-ring.o
 obj-$(CONFIG_USB_XHCI_DWC3) += xhci-dwc3.o
+obj-$(CONFIG_USB_DWC3_UNIPHIER) += dwc3-uniphier.o
 obj-$(CONFIG_USB_XHCI_ZYNQMP) += xhci-zynqmp.o
 obj-$(CONFIG_USB_XHCI_KEYSTONE) += xhci-keystone.o
 obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
diff --git a/drivers/usb/host/dwc3-uniphier.c b/drivers/usb/host/dwc3-uniphier.c
new file mode 100644
index 000..e0358ac
--- /dev/null
+++ b/drivers/usb/host/dwc3-uniphier.c
@@ -0,0 +1,119 @@
+/*
+ * UniPhier Specific Glue Layer for DWC3
+ *
+ * Copyright (C) 2016 Socionext Inc.
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UNIPHIER_PRO4_DWC3_RESET   0x40
+#define   UNIPHIER_PRO4_DWC3_RESET_XIOMMU  BIT(5)
+#define   UNIPHIER_PRO4_DWC3_RESET_XLINK   BIT(4)
+#define   UNIPHIER_PRO4_DWC3_RESET_PHY_SS  BIT(2)
+
+#define UNIPHIER_PRO5_DWC3_RESET   0x00
+#define   UNIPHIER_PRO5_DWC3_RESET_PHY_S1  BIT(17)
+#define   UNIPHIER_PRO5_DWC3_RESET_PHY_S0  BIT(16)
+#define   UNIPHIER_PRO5_DWC3_RESET_XLINK   BIT(15)
+#define   UNIPHIER_PRO5_DWC3_RESET_XIOMMU  BIT(14)
+
+#define UNIPHIER_PXS2_DWC3_RESET   0x00
+#define   UNIPHIER_PXS2_DWC3_RESET_XLINK   BIT(15)
+
+static int uniphier_pro4_dwc3_init(void __iomem *regs)
+{
+   u32 tmp;
+
+   tmp = readl(regs + UNIPHIER_PRO4_DWC3_RESET);
+   tmp &= ~UNIPHIER_PRO4_DWC3_RESET_PHY_SS;
+   tmp |= UNIPHIER_PRO4_DWC3_RESET_XIOMMU | UNIPHIER_PRO4_DWC3_RESET_XLINK;
+   writel(tmp, regs + UNIPHIER_PRO4_DWC3_RESET);
+
+   return 0;
+}
+
+static int uniphier_pro5_dwc3_init(void __iomem *regs)
+{
+   u32 tmp;
+
+   tmp = readl(regs + UNIPHIER_PRO5_DWC3_RESET);
+   tmp &= ~(UNIPHIER_PRO5_DWC3_RESET_PHY_S1 |
+UNIPHIER_PRO5_DWC3_RESET_PHY_S0);
+   tmp |= UNIPHIER_PRO5_DWC3_RESET_XLINK | UNIPHIER_PRO5_DWC3_RESET_XIOMMU;
+   writel(tmp, regs + UNIPHIER_PRO5_DWC3_RESET);
+
+   return 0;
+}
+
+static int uniphier_pxs2_dwc3_init(void __iomem *regs)
+{
+   u32 tmp;
+
+   tmp = readl(regs + UNIPHIER_PXS2_DWC3_RESET);
+   tmp |= UNIPHIER_PXS2_DWC3_RESET_XLINK;
+   writel(tmp, regs + UNIPHIER_PXS2_DWC3_RESET);
+
+   return 0;
+}
+
+static int uniphier_dwc3_probe(struct udevice *dev)
+{
+   fdt_addr_t base;
+   void __iomem *regs;
+   int (*init)(void __iomem *regs);
+   int ret;
+
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   regs = map_sysmem(base, SZ_32K);
+   if (!regs)
+   return -ENOMEM;
+
+   init = (int (*)(void __iomem *regs))dev_get_driver_data(dev);
+   ret = init(regs);
+   if (ret) {
+   dev_err(dev, "failed to init glue layer\n");
+   return ret;
+   }
+
+   unmap_sysmem(regs);
+
+   return 0;
+}
+
+static const struct udevice_id uniphier_dwc3_match[] = {
+   {
+   .compatible = "socionext,uniphier-pro4-dwc3",
+   .data = (ulong)uniphier_pro4_dwc3_init,
+   },
+   {
+   .compatible = "socionext,uniphier-pro5-dwc3",
+   .data = (ulong)uniphier_pro5_dwc3_init,
+   },
+   {
+   .compatible = "socionext,uniphier-pxs2-dwc3",
+   .data = (ulong)uniphier_pxs2_dwc3_init,
+   },
+   {
+   .compatible = "socionext,uniphier-ld20-dwc3",
+   .data = (ulong)uniphier_pxs2_dwc3_init,
+   },

[U-Boot] [PATCH v2 01/13] configs: blackfin: move CONFIG_USB to defconfig

2016-05-16 Thread Masahiro Yamada
These Blackfin boards are the last ones that define CONFIG_USB in
their headers.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 configs/bf526-ezbrd_defconfig| 1 +
 configs/bf527-ezkit-v2_defconfig | 1 +
 configs/bf527-ezkit_defconfig| 1 +
 configs/bf548-ezkit_defconfig| 1 +
 include/configs/bf526-ezbrd.h| 1 -
 include/configs/bf527-ezkit.h| 1 -
 include/configs/bf548-ezkit.h| 1 -
 7 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/bf526-ezbrd_defconfig b/configs/bf526-ezbrd_defconfig
index 85c2a6b..ea4f8e4 100644
--- a/configs/bf526-ezbrd_defconfig
+++ b/configs/bf526-ezbrd_defconfig
@@ -17,3 +17,4 @@ CONFIG_CMD_FAT=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
+CONFIG_USB=y
diff --git a/configs/bf527-ezkit-v2_defconfig b/configs/bf527-ezkit-v2_defconfig
index ff797f8..faac28d 100644
--- a/configs/bf527-ezkit-v2_defconfig
+++ b/configs/bf527-ezkit-v2_defconfig
@@ -17,4 +17,5 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_USB=y
 CONFIG_LIB_RAND=y
diff --git a/configs/bf527-ezkit_defconfig b/configs/bf527-ezkit_defconfig
index eff2a12..d69b146 100644
--- a/configs/bf527-ezkit_defconfig
+++ b/configs/bf527-ezkit_defconfig
@@ -17,3 +17,4 @@ CONFIG_NET_RANDOM_ETHADDR=y
 # CONFIG_NET_TFTP_VARS is not set
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_USB=y
diff --git a/configs/bf548-ezkit_defconfig b/configs/bf548-ezkit_defconfig
index 6d398ac..e4fa136 100644
--- a/configs/bf548-ezkit_defconfig
+++ b/configs/bf548-ezkit_defconfig
@@ -16,5 +16,6 @@ CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_USB=y
 CONFIG_CC_OPTIMIZE_LIBS_FOR_SPEED=y
 CONFIG_LIB_RAND=y
diff --git a/include/configs/bf526-ezbrd.h b/include/configs/bf526-ezbrd.h
index 74c3464..cf8ef8a 100644
--- a/include/configs/bf526-ezbrd.h
+++ b/include/configs/bf526-ezbrd.h
@@ -125,7 +125,6 @@
  * USB Settings
  */
 #if !defined(__ADSPBF522__) && !defined(__ADSPBF523__)
-#define CONFIG_USB
 #define CONFIG_USB_MUSB_HCD
 #define CONFIG_USB_BLACKFIN
 #define CONFIG_USB_STORAGE
diff --git a/include/configs/bf527-ezkit.h b/include/configs/bf527-ezkit.h
index e268473..c958a94 100644
--- a/include/configs/bf527-ezkit.h
+++ b/include/configs/bf527-ezkit.h
@@ -128,7 +128,6 @@
  * USB Settings
  */
 #if !defined(__ADSPBF522__) && !defined(__ADSPBF523__)
-#define CONFIG_USB
 #define CONFIG_USB_MUSB_HCD
 #define CONFIG_USB_BLACKFIN
 #define CONFIG_USB_STORAGE
diff --git a/include/configs/bf548-ezkit.h b/include/configs/bf548-ezkit.h
index 6830e4d..be28ea3 100644
--- a/include/configs/bf548-ezkit.h
+++ b/include/configs/bf548-ezkit.h
@@ -151,7 +151,6 @@
  * USB Settings
  */
 #if !defined(__ADSPBF544__)
-#define CONFIG_USB
 #define CONFIG_USB_MUSB_HCD
 #define CONFIG_USB_BLACKFIN
 #define CONFIG_USB_STORAGE
-- 
1.9.1

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


[U-Boot] [PATCH v2 04/13] usb: xhci: add struct devrequest declaration to xhci.h

2016-05-16 Thread Masahiro Yamada
If xhci.h is included without include/usb.h, the compiler
complains like follows:
warning: 'struct devrequest' declared inside parameter list

We have two options to teach the compiler that devrequest is
a structure:

[1] Declare "struct devrequest;" in xhci.h

[2] Include  from xhci.h

This commit takes [1] because nothing else in xhci.h depends on
include/usb.h.  [2] would require the compiler additional header
parsing.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Rephrase git-log

 drivers/usb/host/xhci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 2afa386..16dd61a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1252,6 +1252,8 @@ void xhci_acknowledge_event(struct xhci_ctrl *ctrl);
 union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected);
 int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
 int length, void *buffer);
+
+struct devrequest;
 int xhci_ctrl_tx(struct usb_device *udev, unsigned long pipe,
 struct devrequest *req, int length, void *buffer);
 int xhci_check_maxpacket(struct usb_device *udev);
-- 
1.9.1

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


[U-Boot] [PATCH v2 08/13] ARM: uniphier: enable DWC3 xHCI driver

2016-05-16 Thread Masahiro Yamada
Enable CONFIGs for the DWC3 core and UniPhier specific glue layer.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 configs/uniphier_ld20_defconfig  | 2 ++
 configs/uniphier_pro4_defconfig  | 2 ++
 configs/uniphier_pxs2_ld6b_defconfig | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/configs/uniphier_ld20_defconfig b/configs/uniphier_ld20_defconfig
index cbc65dd..ecf5649 100644
--- a/configs/uniphier_ld20_defconfig
+++ b/configs/uniphier_ld20_defconfig
@@ -27,4 +27,6 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3_UNIPHIER=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig
index 18f4caf..c9d104b 100644
--- a/configs/uniphier_pro4_defconfig
+++ b/configs/uniphier_pro4_defconfig
@@ -31,4 +31,6 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3_UNIPHIER=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/uniphier_pxs2_ld6b_defconfig 
b/configs/uniphier_pxs2_ld6b_defconfig
index cf6d3e4..8356437 100644
--- a/configs/uniphier_pxs2_ld6b_defconfig
+++ b/configs/uniphier_pxs2_ld6b_defconfig
@@ -32,4 +32,6 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3_UNIPHIER=y
 CONFIG_USB_STORAGE=y
-- 
1.9.1

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


[U-Boot] [PATCH v2 05/13] usb: dwc3: change DWC3 core support code into a driver

2016-05-16 Thread Masahiro Yamada
Synopsys DWC3 IP generally works with an SoC-specific glue layer.
DT binding for that is like this:

  usb3_glue {
  compatible = "foo,dwc3";
  ...

  usb3 {
  compatible = "snps,dwc3";
  ...
  };
  };

The glue layer initializes some SoC-specific parts, then populates
the child DWC3 core.  To see how it works, refer to

  drivers/usb/dwc3/dwc3-exynos.c
  drivers/usb/dwc3/dwc3-keystone.c
  drivers/usb/dwc3/dwc3-omap.c
  drivers/usb/dwc3/dwc3-st.c

of Linux Kernel.

This commit implements a driver compatible with "snps,dwc3", allowing
to use the same binding in U-Boot.  The glue layer can be simply
implemented based on Simple Bus Uclass.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Marek Vasut 
---

Changes in v2: None

 drivers/usb/host/xhci-dwc3.c | 71 +++-
 1 file changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 33961cd..c7c8324 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -9,8 +9,13 @@
  */
 
 #include 
-#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+
+#include "xhci.h"
 
 void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
 {
@@ -97,3 +102,67 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
setbits_le32(_reg->g_fladj, GFLADJ_30MHZ_REG_SEL |
GFLADJ_30MHZ(val));
 }
+
+struct dwc3_priv {
+   struct xhci_ctrl ctrl;  /* should be the first member */
+   void __iomem *regs;
+};
+
+static int dwc3_probe(struct udevice *dev)
+{
+   struct dwc3_priv *priv = dev_get_priv(dev);
+   struct xhci_hccr *hccr;
+   struct xhci_hcor *hcor;
+   fdt_addr_t base;
+   int ret;
+
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   priv->regs = map_sysmem(base, SZ_32K);
+   if (!priv->regs)
+   return -ENOMEM;
+
+   hccr = priv->regs;
+
+   hcor = priv->regs + HC_LENGTH(xhci_readl(>cr_capbase));
+
+   ret = dwc3_core_init(priv->regs + DWC3_REG_OFFSET);
+   if (ret) {
+   puts("XHCI: failed to initialize controller\n");
+   return ret;
+   }
+
+   /* We are hard-coding DWC3 core to Host Mode */
+   dwc3_set_mode(priv->regs + DWC3_REG_OFFSET, DWC3_GCTL_PRTCAP_HOST);
+
+   return xhci_register(dev, hccr, hcor);
+}
+
+static int dwc3_remove(struct udevice *dev)
+{
+   struct dwc3_priv *priv = dev_get_priv(dev);
+
+   xhci_deregister(dev);
+   unmap_sysmem(priv->regs);
+
+   return 0;
+}
+
+static const struct udevice_id of_dwc3_match[] = {
+   { .compatible = "snps,dwc3" },
+   { .compatible = "synopsys,dwc3" },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(dwc3) = {
+   .name = "dwc3",
+   .id = UCLASS_USB,
+   .of_match = of_dwc3_match,
+   .probe = dwc3_probe,
+   .remove = dwc3_remove,
+   .ops = _usb_ops,
+   .priv_auto_alloc_size = sizeof(struct dwc3_priv),
+   .flags  = DM_FLAG_ALLOC_PRIV_DMA,
+};
-- 
1.9.1

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


[U-Boot] [PATCH v2 07/13] ARM: uniphier: switch over to USB DM

2016-05-16 Thread Masahiro Yamada
Now UniPhier platform can completely switch over to Driver Model USB,
which allows ARCH_UNIPHIER select DM_USB.  Drop CONFIG_DM_USB=y of
two of UniPhier defconfig files.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 arch/arm/Kconfig| 1 +
 configs/uniphier_ld4_sld8_defconfig | 1 -
 configs/uniphier_sld3_defconfig | 1 -
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..59410cb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -723,6 +723,7 @@ config ARCH_UNIPHIER
select DM_SERIAL
select DM_I2C
select DM_MMC
+   select DM_USB
help
  Support for UniPhier SoC family developed by Socionext Inc.
  (formerly, System LSI Business Division of Panasonic Corporation)
diff --git a/configs/uniphier_ld4_sld8_defconfig 
b/configs/uniphier_ld4_sld8_defconfig
index 22615a6..d13d112 100644
--- a/configs/uniphier_ld4_sld8_defconfig
+++ b/configs/uniphier_ld4_sld8_defconfig
@@ -31,7 +31,6 @@ CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
-CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/uniphier_sld3_defconfig b/configs/uniphier_sld3_defconfig
index 0965019..accbd8a 100644
--- a/configs/uniphier_sld3_defconfig
+++ b/configs/uniphier_sld3_defconfig
@@ -28,7 +28,6 @@ CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
 CONFIG_SPL_NAND_DENALI=y
 CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
-CONFIG_DM_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
-- 
1.9.1

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


Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

2016-05-16 Thread Alexander Graf


On 16.05.16 14:04, Bhupesh Sharma wrote:
> 
> 
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Monday, May 16, 2016 1:09 PM
>> To: Amit Tomer 
>> Cc: Bhupesh Sharma ; york sun
>> ; u-boot@lists.denx.de; Peter Newton
>> 
>> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
>>
>>
>>
>>> Am 16.05.2016 um 08:58 schrieb Amit Tomer :
>>>
 On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
>>  wrote:
 Note that UEFI firmware support is already available on LS2080A-RDB
 and allows Booting distributions like CentOS on the same.
>>>
>>> Sorry to intervene here but it's about having the EFI support inside
>>> u-boot itself that may *not* required to have separate UEFI firmware
>>> to boot various distributions.
>>>
>>> Please correct, if it's not right ?
>>
>> It's correct. The idea is to allow everyone to boot using the uEFI
>> entry point in Linux (or any other OS), regardless of whether they want
>> to run U-Boot or a TianoCore based formware.
>>
>> This might seem useless today for embedded use cases, but some features
>> are only available via an EFI entry, such as kASLR. You can also invoke
>> Linux directly using the "bootefi" command, as Linux is an EFI binary
>> itself. That way the boot path doesn't become much longer than with
>> booti today.
>>
> 
> The default firmware being offered by NXP to boot distros on LS2080A and 
> variants is UEFI.
> 
> EFI application support in u-boot doesn't present a solution to things like 
> run-time variable/service
> support that is required by distros to update firmware components on the go. 
> And there are several
> other services being offered by UEFI to help distro boot e.g. secure uefi 
> boot through x.509 certifications
> compliant to UEFI specifications.

Don't get me wrong - I think it's great if there is a TianoCore based
firmware for LS2080A. But I didn't get the impression that there is a
TianoCore based firmware for every NXP SoC out there, so enabling all of
them to use the U-Boot provided uEFI implementation is still a win.

That said, there's nothing that keeps us from implementing the bits you
mentioned in U-Boot either. There is support for RTS in U-Boot, we just
didn't convert any drivers (RTC comes to mind first) yet.

There's also no support for uEFI environment variables, but mostly
because most systems I've used this code on so far just didn't have any
storage to put them.

Certification checks also shouldn't be an issue if someone cared enough
about them.

But I don't think we need a discussion of TianoCore vs U-Boot. What
everyone really wants is to have things "just work". And some customers
just prefer U-Boot for various reasons that are outside of my control.
If they can run the same boot path as everyone else, it makes life for
me as distribution vendor easier. And unlike other people in the
community, I don't think being a TianoCore+ACPI messiah is any helpful
for that goal.


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


Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot

2016-05-16 Thread Bhupesh Sharma


> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Monday, May 16, 2016 1:09 PM
> To: Amit Tomer 
> Cc: Bhupesh Sharma ; york sun
> ; u-boot@lists.denx.de; Peter Newton
> 
> Subject: Re: [U-Boot] [PATCH 5/5] ls2080ardb: Convert to distro boot
> 
> 
> 
> > Am 16.05.2016 um 08:58 schrieb Amit Tomer :
> >
> >> On Sun, May 15, 2016 at 2:51 AM, Bhupesh Sharma
>  wrote:
> >> Note that UEFI firmware support is already available on LS2080A-RDB
> >> and allows Booting distributions like CentOS on the same.
> >
> > Sorry to intervene here but it's about having the EFI support inside
> > u-boot itself that may *not* required to have separate UEFI firmware
> > to boot various distributions.
> >
> > Please correct, if it's not right ?
> 
> It's correct. The idea is to allow everyone to boot using the uEFI
> entry point in Linux (or any other OS), regardless of whether they want
> to run U-Boot or a TianoCore based formware.
> 
> This might seem useless today for embedded use cases, but some features
> are only available via an EFI entry, such as kASLR. You can also invoke
> Linux directly using the "bootefi" command, as Linux is an EFI binary
> itself. That way the boot path doesn't become much longer than with
> booti today.
> 

The default firmware being offered by NXP to boot distros on LS2080A and 
variants is UEFI.

EFI application support in u-boot doesn't present a solution to things like 
run-time variable/service
support that is required by distros to update firmware components on the go. 
And there are several
other services being offered by UEFI to help distro boot e.g. secure uefi boot 
through x.509 certifications
compliant to UEFI specifications.

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


Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot

2016-05-16 Thread Boris Brezillon
Hi Scott,

On Tue, 03 May 2016 00:06:45 -0500
Scott Wood  wrote:

> On Mon, 2016-04-25 at 22:53 +0200, Boris Brezillon wrote:
> > On Mon, 25 Apr 2016 13:36:46 -0400
> > Tom Rini  wrote:
> >   
> > > On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote:
> > >   
> > > > Hi Scott,
> > > > 
> > > > I've recently contributed a lot of MTD/NAND related patches (and intend
> > > > to continue doing so). Some of them are transversal changes touching the
> > > > MTD and NAND framework internals, which implies patching all NAND
> > > > drivers along with the core changes.
> > > > 
> > > > All those changes are required to properly handle modern NANDs (MLC/TLC
> > > > NANDs), and I need them to add proper NAND support to the sunxi
> > > > platform (and more particularly to the C.H.I.P from NextThing Co.).
> > > > 
> > > > So my question is, how should I port those changes to U-Boot? I see
> > > > that your doing "synchronization commits", but in my case this mean
> > > > including a bunch of driver specific changes into this "sync commit".
> > > > 
> > > > I think it's also worth mentioning that I plan to heavily rework the
> > > > Linux NAND framework to improve NAND performances on modern NAND
> > > > controllers and clarify the NAND chip / NAND controller concepts, and
> > > > other people are also working on merging the BBT code of the NAND and
> > > > OneNAND framework. Which unfortunately means that we're not done porting
> > > > invasive changes to U-Boot :-/.
> > > > 
> > > > Any advice is welcome.
> > > 
> > > I suppose my first suggestion would be to sync the kernel back into
> > > U-Boot more frequently.  With our bi-monthly release cycle it shouldn't
> > > be too hard to pick a window to grab the current kernel release and
> > > bring it over.  I think the more stuff we let build up prior to syncing
> > > the harder it will be.
> > >   
> > 
> > Okay, so this means I should be the one back-porting Linux changes into
> > U-Boot? I was planning on porting my current work on the sunxi NAND
> > driver (including all the core dependencies) and submitting it to
> > U-Boot, but honestly, I don't see how I can keep things in sync in the
> > long run. From my experience, porting things to U-Boot is never as
> > easy at it seems, and I don't think I'll have the time to maintain that
> > by myself. Scott, what's your policy regarding Linux -> U-Boot syncs?
> > Can I expect some help from your side?  
> 
> I usually do syncs when someone complains about needing a sync.  Every release
> seems a bit much.  I'll try to do one soon.

Sorry to bother you with that, but can I ask when you plan to do this
sync (I guess you'll sync with 4.6)? As I explained, I depend on
features introduced in 4.6 to make the sunxi NAND driver usable on
sunxi based boards (the concept of data randomizer/scrambler is
required on some MLC NANDs, and most Allwinner boards embed this
kind of NAND chips).

Don't hesitate to let me know if you need some help.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration

2016-05-16 Thread Kishon Vijay Abraham I
Hi Roger,

On Monday 16 May 2016 04:01 PM, Roger Quadros wrote:
> On 16/05/16 13:03, Kishon Vijay Abraham I wrote:
>> Hi Roger,
>>
>> On Monday 16 May 2016 03:19 PM, Roger Quadros wrote:
>>> On 16/05/16 12:26, Roger Quadros wrote:
 On 16/05/16 12:06, Roger Quadros wrote:
> On 13/05/16 15:45, Marek Vasut wrote:
>> On 05/13/2016 02:36 PM, Roger Quadros wrote:
>>> Currently CONFIG_USB_DWC3 is not selected so doing a usb start
>>> command results in a serious error [1].
>>
>> Why does this error happen ? That is what should be fixed. Selecting
>> some random options seems like papering over a bug.
>
> Agreed. I was lazy :P.

 OK. The issue is like this.

 CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls
 usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c 
 which calls
 board_usb_init().
>>
>> IIRC, board_usb_init for xhci (omap) is mostly a NOP.
> 
> Then who will call board_usb_init() for host case?
> 

 But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 
 is defined
 and that is missing in am57xx_evm.h leading to the serious error. We're 
 trying to
 access the IP without turning on the necessary clocks.
>>
>> clocks are not turned on in board_usb_init() right? The board_usb_init() in
>> am57xx/board.c is used only for gadget mode.

 So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or 
 something else.
>>
>> right, but before that we might have to cleanup xhci-omap.

 But then again looking into the future, what if we want only gadget 
 operation?
 That would not define XHCI, but we still need board_usb_init(). So 
 board_usb_init()
 should be defined based on CONFIG_CMD_USB=y?

 What do you suggest?
>>>
>>> But board_usb_init() calls 
>>>
>>> ti_usb_phy_uboot_init(_phy1_device);
>>> dwc3_omap_uboot_init(_otg_ss1_glue);
>>> dwc3_uboot_init(_otg_ss1);
>>>
>>> which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and 
>>> CONFIG_USB_DWC3
>>> respectively.
>>
>> IMO we should cleanup xhci-omap so that all the initializations are done 
>> using
>> ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify
>> dwc3_uboot_init to initialize host or device based on CONFIG_*.
>>
> 
> I'm still trying to get a grip of how USB works in u-boot.
> Is CONFIG_CMD_USB only meant for host mode or gadget mode as well?

IIRC it is only for host. Commands like usb start, usb stop are used to start
and stop host.
> Is dual-role even required in u-boot? probably it is not a good idea and we 
> just
> ignore it for simplicity.

yeah.
> 
> What determines whether a USB port is meant for Host or device operation? Is 
> it
> the CONFIG_ or caller of board_usb_init()?
It should be the caller of board_usb_init(). The same port can be used as
device or host based on command used (the command determines the caller of
board_usb_init).

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


Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration

2016-05-16 Thread Kishon Vijay Abraham I
Hi Roger,

On Monday 16 May 2016 03:19 PM, Roger Quadros wrote:
> On 16/05/16 12:26, Roger Quadros wrote:
>> On 16/05/16 12:06, Roger Quadros wrote:
>>> On 13/05/16 15:45, Marek Vasut wrote:
 On 05/13/2016 02:36 PM, Roger Quadros wrote:
> Currently CONFIG_USB_DWC3 is not selected so doing a usb start
> command results in a serious error [1].

 Why does this error happen ? That is what should be fixed. Selecting
 some random options seems like papering over a bug.
>>>
>>> Agreed. I was lazy :P.
>>
>> OK. The issue is like this.
>>
>> CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls
>> usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c which 
>> calls
>> board_usb_init().

IIRC, board_usb_init for xhci (omap) is mostly a NOP.
>>
>> But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 is 
>> defined
>> and that is missing in am57xx_evm.h leading to the serious error. We're 
>> trying to
>> access the IP without turning on the necessary clocks.

clocks are not turned on in board_usb_init() right? The board_usb_init() in
am57xx/board.c is used only for gadget mode.
>>
>> So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or 
>> something else.

right, but before that we might have to cleanup xhci-omap.
>>
>> But then again looking into the future, what if we want only gadget 
>> operation?
>> That would not define XHCI, but we still need board_usb_init(). So 
>> board_usb_init()
>> should be defined based on CONFIG_CMD_USB=y?
>>
>> What do you suggest?
> 
> But board_usb_init() calls 
> 
> ti_usb_phy_uboot_init(_phy1_device);
> dwc3_omap_uboot_init(_otg_ss1_glue);
> dwc3_uboot_init(_otg_ss1);
> 
> which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and 
> CONFIG_USB_DWC3
> respectively.

IMO we should cleanup xhci-omap so that all the initializations are done using
ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify
dwc3_uboot_init to initialize host or device based on CONFIG_*.

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


Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration

2016-05-16 Thread Roger Quadros
On 16/05/16 13:03, Kishon Vijay Abraham I wrote:
> Hi Roger,
> 
> On Monday 16 May 2016 03:19 PM, Roger Quadros wrote:
>> On 16/05/16 12:26, Roger Quadros wrote:
>>> On 16/05/16 12:06, Roger Quadros wrote:
 On 13/05/16 15:45, Marek Vasut wrote:
> On 05/13/2016 02:36 PM, Roger Quadros wrote:
>> Currently CONFIG_USB_DWC3 is not selected so doing a usb start
>> command results in a serious error [1].
>
> Why does this error happen ? That is what should be fixed. Selecting
> some random options seems like papering over a bug.

 Agreed. I was lazy :P.
>>>
>>> OK. The issue is like this.
>>>
>>> CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls
>>> usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c 
>>> which calls
>>> board_usb_init().
> 
> IIRC, board_usb_init for xhci (omap) is mostly a NOP.

Then who will call board_usb_init() for host case?

>>>
>>> But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 
>>> is defined
>>> and that is missing in am57xx_evm.h leading to the serious error. We're 
>>> trying to
>>> access the IP without turning on the necessary clocks.
> 
> clocks are not turned on in board_usb_init() right? The board_usb_init() in
> am57xx/board.c is used only for gadget mode.
>>>
>>> So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or 
>>> something else.
> 
> right, but before that we might have to cleanup xhci-omap.
>>>
>>> But then again looking into the future, what if we want only gadget 
>>> operation?
>>> That would not define XHCI, but we still need board_usb_init(). So 
>>> board_usb_init()
>>> should be defined based on CONFIG_CMD_USB=y?
>>>
>>> What do you suggest?
>>
>> But board_usb_init() calls 
>>
>> ti_usb_phy_uboot_init(_phy1_device);
>> dwc3_omap_uboot_init(_otg_ss1_glue);
>> dwc3_uboot_init(_otg_ss1);
>>
>> which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and 
>> CONFIG_USB_DWC3
>> respectively.
> 
> IMO we should cleanup xhci-omap so that all the initializations are done using
> ti_usb_phy_uboot_init, dwc3_omap_uboot_init and dwc3_uboot_init. Then modify
> dwc3_uboot_init to initialize host or device based on CONFIG_*.
> 

I'm still trying to get a grip of how USB works in u-boot.
Is CONFIG_CMD_USB only meant for host mode or gadget mode as well?
Is dual-role even required in u-boot? probably it is not a good idea and we just
ignore it for simplicity.

What determines whether a USB port is meant for Host or device operation? Is it
the CONFIG_ or caller of board_usb_init()?
I see board_usb_init() being used by gadget drivers, host drivers, dfu.c, etc.

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


Re: [U-Boot] [PATCH 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

2016-05-16 Thread Alexander Graf


On 16.05.16 07:28, Huan Wang wrote:
>> On 13.05.16 10:40, Alison Wang wrote:
>>> To support loading a 32-bit OS, the execution state will change from
>>> AArch64 to AArch32 when jumping to kernel.
>>>
>>> The architecture information will be got through checking FIT image,
>>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>>
>>> Signed-off-by: Ebony Zhu 
>>> Signed-off-by: Alison Wang 
>>> Signed-off-by: Chenhui Zhao 
>>> ---
>>>  arch/arm/cpu/armv8/transition.S | 100
>> 
>>>  arch/arm/include/asm/system.h   |   2 +
>>>  arch/arm/lib/bootm.c|  20 +++-
>>>  common/image-fit.c  |  12 -
>>>  4 files changed, 131 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/cpu/armv8/transition.S
>>> b/arch/arm/cpu/armv8/transition.S index 253a39b..9d7a17a 100644
>>> --- a/arch/arm/cpu/armv8/transition.S
>>> +++ b/arch/arm/cpu/armv8/transition.S
>>> @@ -21,3 +21,103 @@ ENTRY(armv8_switch_to_el1)
>>>  0: ret
>>>  1: armv8_switch_to_el1_m x0, x1
>>>  ENDPROC(armv8_switch_to_el1)
>>> +
>>> +/*
>>> + * x0: kernel entry point
>>> + * x1: machine nr
>>> + * x2: fdt address
>>> + */
>>> +ENTRY(armv8_switch_to_el2_aarch32)
>>> +   switch_el x3, 1f, 0f, 0f
>>> +0: ret
>>> +1:
>>> +   mov x7, x0
>>> +   mov x8, x1
>>> +   mov x9, x2
>>> +
>>> +   /* 32bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1
>> */
>>> +   mov x1, 0x1b1
>>> +   msr scr_el3, x1
>>> +   msr cptr_el3, xzr   /* Disable coprocessor traps to EL3 */
>>> +   mov x1, 0x33ff
>>> +   msr cptr_el2, x1/* Disable coprocessor traps to EL2 */
>>> +
>>> +   /* Initialize Generic Timers */
>>> +   msr cntvoff_el2, xzr
>>> +
>>> +   mov x1, #0x0830
>>> +   movkx1, #0x30c5, lsl #16
>>> +   msr sctlr_el2, x1
>>
>> Why is this necessary?
> [Alison Wang] SCTLR_EL2 is architecturally mapped to AArch32 register HSCTLR.
> HSCTLR will provide control of the system operation in Hyp mode.

It still doesn't explain why you move magical values into a random
register that is not set in the 64-bit path.

Please make this code more readable :). Try to #define values for the
bits that you set. Add comments explaining why you do what you do.

>>
>>> +
>>> +   /* Return to AArch32 Hypervisor mode */
>>> +   mov x1, sp
>>> +   msr sp_el2, x1
>>> +   mrs x1, vbar_el3
>>> +   msr vbar_el2, x1/* Migrate VBAR */
>>> +   mov x1, #0x1da
>>> +   msr spsr_el3, x1
>>> +   msr elr_el3, x7
>>> +
>>> +   mov x0, #0
>>> +   mov x1, x8
>>> +   mov x2, x9
>>> +
>>> +   eret
>>> +ENDPROC(armv8_switch_to_el2_aarch32)
>>
>> This whole thing looks like a copy of armv8_switch_to_el2_m. Just
>> parameterize that one and put the few bits that are different in macro
>> ifs.
> [Alison Wang] Yes, they are similar because they both switch from EL3 to EL2.
> But some bits are different because one switch from AArch64 EL3 to AArch64 EL2
> and the other switch from AArch64 EL3 to AArch32 EL2. The parameters need to
> use too.

Yes, so I think it makes a lot of sense to combine the
jump-to-64-bit-el2 and jump-to-32-bit-el2 functions be a single
implementation. That way there's less chance an accidental difference
creeps in.

>>
>>> +
>>> +/*
>>> + * x0: kernel entry point
>>> + * x1: machine nr
>>> + * x2: fdt address
>>> + */
>>> +ENTRY(armv8_switch_to_el1_aarch32)
>>> +   switch_el x3, 0f, 1f, 0f
>>> +0: ret
>>> +1:
>>> +   mov x7, x0
>>> +   mov x8, x1
>>> +   mov x9, x2
>>> +
>>> +   /* Initialize Generic Timers */
>>> +   mrs x0, cnthctl_el2
>>> +   orr x0, x0, #0x3/* Enable EL1 access to timers */
>>> +   msr cnthctl_el2, x0
>>> +   msr cntvoff_el2, xzr
>>> +
>>> +/* Initialize MPID/MPIDR registers */
>>> +   mrs x0, midr_el1
>>> +   mrs x1, mpidr_el1
>>> +   msr vpidr_el2, x0
>>> +   msr vmpidr_el2, x1
>>> +
>>> +/* Disable coprocessor traps */
>>> +   mov x0, #0x33ff
>>> +   msr cptr_el2, x0/* Disable coprocessor traps to EL2 */
>>> +msrhstr_el2, xzr   /* Disable coprocessor traps
>> to EL2 */
>>> +movx0, #3 << 20
>>> +msrcpacr_el1, x0   /* Enable FP/SIMD at EL1 */
>>> +
>>> +   /* Initialize HCR_EL2 */
>>> +   mov x0, #(0 << 31)  /* 32bit EL1 */
>>> +   orr x0, x0, #(1 << 29)  /* Disable HVC */
>>> +   msr hcr_el2, x0
>>> +
>>> +   mov x0, #0x0800
>>> +   movkx0, #0x30d0, lsl #16
>>> +   msr sctlr_el1, x0
>>> +
>>> +   /* Return to AArch32 Supervisor mode */
>>> +   mov x0, sp
>>> +   msr sp_el1, x0  /* Migrate SP */
>>> +   mrs x0, vbar_el2
>>> +   msr vbar_el1, x0/* Migrate VBAR */
>>> +   mov x0, #0x1d3
>>> +   msr spsr_el2, x0
>>> +   msr elr_el2, x7
>>> +
>>> +   mov x0, #0
>>> +   mov x1, x8
>>> +   

[U-Boot] [PATCH 4/5] malta: Remove ".set mips32" directive

2016-05-16 Thread Paul Burton
We always build for a mips32 or higher ISA, so this ".set mips32"
directive is redundant. Once MIPSr6 support is added it will become
harmful since some instruction encodings change & this directive will
cause the older encodings to be incorrectly emitted instead of the
appropriate ones for the build.

In preparation for supporting MIPSr6, remove this redundant directive.

Signed-off-by: Paul Burton 
---

 board/imgtec/malta/lowlevel_init.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/board/imgtec/malta/lowlevel_init.S 
b/board/imgtec/malta/lowlevel_init.S
index ae09c27..534db1d 100644
--- a/board/imgtec/malta/lowlevel_init.S
+++ b/board/imgtec/malta/lowlevel_init.S
@@ -24,7 +24,6 @@
 
.text
.set noreorder
-   .set mips32
 
.globl  lowlevel_init
 lowlevel_init:
-- 
2.8.2

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


[U-Boot] [PATCH 0/5] MIPS Release 6 Support

2016-05-16 Thread Paul Burton
This series introduces support for building U-Boot for release 6 of the
MIPS architecture. This is supported by CPUs such as the M62xx, I6400 &
P6600 as well as by emulators such as QEMU.

Paul Burton (5):
  MIPS: Use unchecked immediate addition/subtraction
  MIPS: Simplify CONFIG_SYS_CPU values
  MIPS: Support for targetting MIPSr6
  malta: Remove ".set mips32" directive
  malta: Support MIPS32r6 configurations

 arch/mips/Kconfig  | 39 ++
 arch/mips/Makefile |  2 ++
 arch/mips/cpu/start.S  | 22 +++--
 arch/mips/lib/cache_init.S |  2 +-
 board/imgtec/malta/lowlevel_init.S |  1 -
 5 files changed, 46 insertions(+), 20 deletions(-)

-- 
2.8.2

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


[U-Boot] [PATCH 5/5] malta: Support MIPS32r6 configurations

2016-05-16 Thread Paul Burton
Both real Malta boards & QEMU's Malta emulation can feature MIPS32r6
CPUs. Allow building U-Boot for such systems by selecting
CONFIG_SUPPORTS_CPU_MIPS32_R6 for Malta.

Signed-off-by: Paul Burton 

---

 arch/mips/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index e53fa83..fbf3e4c 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -28,6 +28,7 @@ config TARGET_MALTA
select SUPPORTS_LITTLE_ENDIAN
select SUPPORTS_CPU_MIPS32_R1
select SUPPORTS_CPU_MIPS32_R2
+   select SUPPORTS_CPU_MIPS32_R6
select SWAP_IO_SPACE
select MIPS_L1_CACHE_SHIFT_6
 
-- 
2.8.2

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


[U-Boot] [PATCH 2/5] MIPS: Simplify CONFIG_SYS_CPU values

2016-05-16 Thread Paul Burton
Rather than having the values for CONFIG_SYS_CPU depend upon each
architecture revision, have them depend upon the more general
CONFIG_CPU_MIPS32 & CONFIG_CPU_MIPS64 which in turn depend upon the
architecture revisions.

This is done in preparation for adding MIPSr6 support, which would
otherwise need to introduce new cases here.

Signed-off-by: Paul Burton 
---

 arch/mips/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index fe37d1f..0520b30 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -5,8 +5,8 @@ config SYS_ARCH
default "mips"
 
 config SYS_CPU
-   default "mips32" if CPU_MIPS32_R1 || CPU_MIPS32_R2
-   default "mips64" if CPU_MIPS64_R1 || CPU_MIPS64_R2
+   default "mips32" if CPU_MIPS32
+   default "mips64" if CPU_MIPS64
 
 choice
prompt "Target select"
-- 
2.8.2

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


[U-Boot] [PATCH 3/5] MIPS: Support for targetting MIPSr6

2016-05-16 Thread Paul Burton
Add support for targetting MIPS32r6 & MIPS64r6 systems, in the same way
that we currently select release 1 or release 2 targets. MIPSr6 is not
entirely backwards compatible with earlier releases of the architecture.
Some instructions are encoded differently, some are removed, some are
reused, so it is not practical to run U-Boot built for earlier revisions
on a MIPSr6 system. Update their Kconfig help text to reflect that.

Signed-off-by: Paul Burton 
---

 arch/mips/Kconfig  | 34 --
 arch/mips/Makefile |  2 ++
 2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0520b30..e53fa83 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -98,7 +98,7 @@ config CPU_MIPS32_R1
depends on SUPPORTS_CPU_MIPS32_R1
select 32BIT
help
- Choose this option to build an U-Boot for release 1 or later of the
+ Choose this option to build an U-Boot for release 1 through 5 of the
  MIPS32 architecture.
 
 config CPU_MIPS32_R2
@@ -106,7 +106,15 @@ config CPU_MIPS32_R2
depends on SUPPORTS_CPU_MIPS32_R2
select 32BIT
help
- Choose this option to build an U-Boot for release 2 or later of the
+ Choose this option to build an U-Boot for release 2 through 5 of the
+ MIPS32 architecture.
+
+config CPU_MIPS32_R6
+   bool "MIPS32 Release 6"
+   depends on SUPPORTS_CPU_MIPS32_R6
+   select 32BIT
+   help
+ Choose this option to build an U-Boot for release 6 or later of the
  MIPS32 architecture.
 
 config CPU_MIPS64_R1
@@ -114,7 +122,7 @@ config CPU_MIPS64_R1
depends on SUPPORTS_CPU_MIPS64_R1
select 64BIT
help
- Choose this option to build a kernel for release 1 or later of the
+ Choose this option to build a kernel for release 1 through 5 of the
  MIPS64 architecture.
 
 config CPU_MIPS64_R2
@@ -122,7 +130,15 @@ config CPU_MIPS64_R2
depends on SUPPORTS_CPU_MIPS64_R2
select 64BIT
help
- Choose this option to build a kernel for release 2 or later of the
+ Choose this option to build a kernel for release 2 through 5 of the
+ MIPS64 architecture.
+
+config CPU_MIPS64_R6
+   bool "MIPS64 Release 6"
+   depends on SUPPORTS_CPU_MIPS64_R6
+   select 64BIT
+   help
+ Choose this option to build a kernel for release 6 or later of the
  MIPS64 architecture.
 
 endchoice
@@ -169,19 +185,25 @@ config SUPPORTS_CPU_MIPS32_R1
 config SUPPORTS_CPU_MIPS32_R2
bool
 
+config SUPPORTS_CPU_MIPS32_R6
+   bool
+
 config SUPPORTS_CPU_MIPS64_R1
bool
 
 config SUPPORTS_CPU_MIPS64_R2
bool
 
+config SUPPORTS_CPU_MIPS64_R6
+   bool
+
 config CPU_MIPS32
bool
-   default y if CPU_MIPS32_R1 || CPU_MIPS32_R2
+   default y if CPU_MIPS32_R1 || CPU_MIPS32_R2 || CPU_MIPS32_R6
 
 config CPU_MIPS64
bool
-   default y if CPU_MIPS64_R1 || CPU_MIPS64_R2
+   default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R6
 
 config MIPS_TUNE_4KC
bool
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index aec5a15..c822178 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -18,8 +18,10 @@ PLATFORM_CPPFLAGS += $(patsubst 
%,-I$(srctree)/%include,$(machdirs))
 # Optimize for MIPS architectures
 arch-$(CONFIG_CPU_MIPS32_R1) += -march=mips32 -Wa,-mips32
 arch-$(CONFIG_CPU_MIPS32_R2) += -march=mips32r2 -Wa,-mips32r2
+arch-$(CONFIG_CPU_MIPS32_R6) += -march=mips32r6 -Wa,-mips32r6
 arch-$(CONFIG_CPU_MIPS64_R1) += -march=mips64 -Wa,-mips64
 arch-$(CONFIG_CPU_MIPS64_R2) += -march=mips64r2 -Wa,-mips64r2
+arch-$(CONFIG_CPU_MIPS64_R6) += -march=mips64r6 -Wa,-mips64r6
 
 # Allow extra optimization for specific CPUs/SoCs
 tune-$(CONFIG_MIPS_TUNE_4KC) += -mtune=4kc
-- 
2.8.2

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


[U-Boot] [PATCH 1/5] MIPS: Use unchecked immediate addition/subtraction

2016-05-16 Thread Paul Burton
In MIPS assembly there have historically been 2 variants of immediate
addition - the standard "addi" which traps if an overflow occurs, and
the unchecked "addiu" which does not trap on overflow. In release 6 of
the MIPS architecture the trapping variants of immediate addition &
subtraction have been removed. In preparation for supporting MIPSr6,
stop using the trapping instructions from assembly & switch to their
unchecked variants.

Signed-off-by: Paul Burton 
---

 arch/mips/cpu/start.S  | 22 --
 arch/mips/lib/cache_init.S |  2 +-
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S
index 1b56ca3..fc6dd66 100644
--- a/arch/mips/cpu/start.S
+++ b/arch/mips/cpu/start.S
@@ -164,12 +164,14 @@ reset:
li  t0, -16
PTR_LI  t1, CONFIG_SYS_INIT_SP_ADDR
and sp, t1, t0  # force 16 byte alignment
-   PTR_SUB sp, sp, GD_SIZE # reserve space for gd
+   PTR_SUBU \
+   sp, sp, GD_SIZE # reserve space for gd
and sp, sp, t0  # force 16 byte alignment
movek0, sp  # save gd pointer
 #ifdef CONFIG_SYS_MALLOC_F_LEN
li  t2, CONFIG_SYS_MALLOC_F_LEN
-   PTR_SUB sp, sp, t2  # reserve space for early malloc
+   PTR_SUBU \
+   sp, sp, t2  # reserve space for early malloc
and sp, sp, t0  # force 16 byte alignment
 #endif
movefp, sp
@@ -179,7 +181,7 @@ reset:
 1:
PTR_S   zero, 0(t0)
blt t0, t1, 1b
-PTR_ADDI t0, PTRSIZE
+PTR_ADDIU t0, PTRSIZE
 
 #ifdef CONFIG_SYS_MALLOC_F_LEN
PTR_S   sp, GD_MALLOC_BASE(k0)  # gd->malloc_base offset
@@ -237,7 +239,7 @@ ENTRY(relocate_code)
 move   a0, s2  # a0 <-- destination address
 
/* Jump to where we've relocated ourselves */
-   PTR_ADDI t0, s2, in_ram - _start
+   PTR_ADDIU t0, s2, in_ram - _start
jr  t0
 nop
 
@@ -257,7 +259,7 @@ in_ram:
PTR_L   t3, -(1 * PTRSIZE)(t0)  # t3 <-- num_got_entries
PTR_L   t8, -(2 * PTRSIZE)(t0)  # t8 <-- _GLOBAL_OFFSET_TABLE_
PTR_ADD t8, s1  # t8 now holds relocated _G_O_T_
-   PTR_ADDI t8, t8, 2 * PTRSIZE# skipping first two entries
+   PTR_ADDIU t8, t8, 2 * PTRSIZE   # skipping first two entries
PTR_LI  t2, 2
 1:
PTR_L   t1, 0(t8)
@@ -265,16 +267,16 @@ in_ram:
 PTR_ADD t1, s1
PTR_S   t1, 0(t8)
 2:
-   PTR_ADDI t2, 1
+   PTR_ADDIU t2, 1
blt t2, t3, 1b
-PTR_ADDI t8, PTRSIZE
+PTR_ADDIU t8, PTRSIZE
 
/* Update dynamic relocations */
PTR_L   t1, -(4 * PTRSIZE)(t0)  # t1 <-- __rel_dyn_start
PTR_L   t2, -(5 * PTRSIZE)(t0)  # t2 <-- __rel_dyn_end
 
b   2f  # skip first reserved entry
-PTR_ADDI t1, 2 * PTRSIZE
+PTR_ADDIU t1, 2 * PTRSIZE
 
 1:
lw  t8, -4(t1)  # t8 <-- relocation info
@@ -293,7 +295,7 @@ in_ram:
 
 2:
blt t1, t2, 1b
-PTR_ADDI t1, 2 * PTRSIZE   # each rel.dyn entry is 2*PTRSIZE bytes
+PTR_ADDIU t1, 2 * PTRSIZE  # each rel.dyn entry is 2*PTRSIZE bytes
 
/*
 * Clear BSS
@@ -307,7 +309,7 @@ in_ram:
 1:
PTR_S   zero, 0(t1)
blt t1, t2, 1b
-PTR_ADDI t1, PTRSIZE
+PTR_ADDIU t1, PTRSIZE
 
movea0, s0  # a0 <-- gd
movea1, s2
diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S
index 14cc2c4..08b7c3a 100644
--- a/arch/mips/lib/cache_init.S
+++ b/arch/mips/lib/cache_init.S
@@ -64,7 +64,7 @@
/* detect associativity */
srl \sz, $1, \off + MIPS_CONF1_DA_SHF - MIPS_CONF1_DA_SHF
andi\sz, \sz, (MIPS_CONF1_DA >> MIPS_CONF1_DA_SHF)
-   addi\sz, \sz, 1
+   addiu   \sz, \sz, 1
 
/* sz *= line_sz */
mul \sz, \sz, \line_sz
-- 
2.8.2

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


[U-Boot] [PATCH v2] sunxi: Increase SPL header size to 64 bytes to avoid code corruption

2016-05-16 Thread Bernhard Nortmann
Given that there now are quite a few additional "reserved" entries, and 
while we're still at SPL_HEADER_VERSION 1, I'd like to renew my request 
of dedicating one of these fields to the script length - which would 
enable us to set the U-Boot ${filesize} accordingly.


i.e.
--- arch-arm-include-asm-arch-sunxi-spl.h
+++ arch-arm-include-asm-arch-sunxi-spl.new.h
@@ -49,7 +49,8 @@
uint8_t spl_signature[4];
};
uint32_t fel_script_address;
-   uint32_t reserved1[3];
+   uint32_t fel_script_length;
+   uint32_t reserved1[2];
uint32_t boot_media;/* written here by the boot ROM */
uint32_t reserved2[5];  /* padding, align to 64 bytes */
 };


I do not intend to further push my specific use cases, however I still 
consider the (then somewhat theoretical) ability to do "import -t 
${fel_script_addr} ${filesize}" useful. For reference, the previous 
discussion related to this was somewhere around 
http://lists.denx.de/pipermail/u-boot/2015-September/227454.html


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


Re: [U-Boot] [PATCH 05/12] x86: qemu: split qfw command interface and qfw core

2016-05-16 Thread Miao Yan
Hi Bin,

2016-05-16 16:47 GMT+08:00 Bin Meng :
> Hi Miao,
>
> On Fri, May 13, 2016 at 2:29 PM, Miao Yan  wrote:
>> This patch splits qfw command interface and qfw core function into two
>> files, and introduces a new Kconfig option (CONFIG_QFW). for
>> qfw core.
>>
>> Now when qfw command interface is enabled, it will automatically select
>> qfw core. This patch also makes the ACPI table generation select
>> CONFIG_QFW.
>>
>> Signed-off-by: Miao Yan 
>> ---
>>  arch/x86/Kconfig   |   2 +-
>>  arch/x86/cpu/mp_init.c |   6 +-
>>  arch/x86/cpu/qemu/Makefile |   3 +-
>>  arch/x86/cpu/qemu/acpi_table.c |   2 +
>>  arch/x86/cpu/qemu/qemu.c   |   4 +
>>  cmd/Kconfig|   1 +
>>  cmd/Makefile   |   2 +-
>>  cmd/cmd_qfw.c  | 182 +
>
> The file name should be qfw.c without cmd_
>
>>  cmd/qemu_fw_cfg.c  | 353 
>> -
>
> And I suspect you can also use "git mv" for cmd/qemu_fw_cfg.c. "git mv
> cmd/qemu_fw_cfg.c cmd/qfw.c"

But there is already a qfw.c under driver/misc/, having two files
using the same name seems a bit confusing.

Thanks,
Miao

>
>>  common/Kconfig |   1 +
>>  drivers/misc/Kconfig   |   6 +
>>  drivers/misc/Makefile  |   1 +
>>  drivers/misc/qemu_fw_cfg.c | 185 +
>>  13 files changed, 390 insertions(+), 358 deletions(-)
>>  create mode 100644 cmd/cmd_qfw.c
>>  delete mode 100644 cmd/qemu_fw_cfg.c
>>  create mode 100644 drivers/misc/qemu_fw_cfg.c
>>
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/4] board: ti: am57xx: Fix USB configuration

2016-05-16 Thread Roger Quadros
On 16/05/16 12:26, Roger Quadros wrote:
> On 16/05/16 12:06, Roger Quadros wrote:
>> On 13/05/16 15:45, Marek Vasut wrote:
>>> On 05/13/2016 02:36 PM, Roger Quadros wrote:
 Currently CONFIG_USB_DWC3 is not selected so doing a usb start
 command results in a serious error [1].
>>>
>>> Why does this error happen ? That is what should be fixed. Selecting
>>> some random options seems like papering over a bug.
>>
>> Agreed. I was lazy :P.
> 
> OK. The issue is like this.
> 
> CONFIG_CMD_USB and CONFIG_USB_XHCI is defined, so usb_init() calls
> usb_lowlevel_init() in xhci.c which calls xhci_hcd_init in xhci-omap.c which 
> calls
> board_usb_init().
> 
> But board_usb_init() in am57xx/board.c is defined only if CONFIG_USB_DWC3 is 
> defined
> and that is missing in am57xx_evm.h leading to the serious error. We're 
> trying to
> access the IP without turning on the necessary clocks.
> 
> So it looks like we need to define it based on CONFIG_USB_XHCI_OMAP or 
> something else.
> 
> But then again looking into the future, what if we want only gadget operation?
> That would not define XHCI, but we still need board_usb_init(). So 
> board_usb_init()
> should be defined based on CONFIG_CMD_USB=y?
> 
> What do you suggest?

But board_usb_init() calls 

ti_usb_phy_uboot_init(_phy1_device);
dwc3_omap_uboot_init(_otg_ss1_glue);
dwc3_uboot_init(_otg_ss1);

which depend on CONFIG_USB_DWC3_PHY_OMAP, CONFIG_USB_DWC3_OMAP and 
CONFIG_USB_DWC3
respectively.

So I really don't know how to fix all this.


--
cheers,
-roger

>>
>>>
 Fix that by enabling CONFIG_USB_DWC3 and other related options
 CONFIG_USB_DWC3_PHY_OMAP and CONFIG_USB_DWC3_OMAP.

 [1]
 => usb start
 starting USB...
 USB0:   data abort
 pc : []  lr : []
 reloc pc : [<8081dd10>]lr : [<8081dbbf>]
 sp : fef3d260  ip :  fp : fef3d2a8
 r10: fffa4610  r9 : fef50ed0 r8 : 
 r7 : fef3d280  r6 : fef3d284 r5 : fffbc380  r4 : 
 r3 : 4888  r2 :  r1 :   r0 : fffbc380
 Flags: nzcv  IRQs off  FIQs off  Mode SVC_32
 Resetting CPU ...

 Signed-off-by: Roger Quadros 
 ---
  include/configs/am57xx_evm.h | 3 +++
  1 file changed, 3 insertions(+)
>>>
>>> Changelog is missing ;-)
>>>
 diff --git a/include/configs/am57xx_evm.h b/include/configs/am57xx_evm.h
 index 32d7d4d..939057c 100644
 --- a/include/configs/am57xx_evm.h
 +++ b/include/configs/am57xx_evm.h
 @@ -63,6 +63,7 @@
  #define CONFIG_SUPPORT_EMMC_BOOT
  
  /* USB xHCI HOST */
 +#define CONFIG_USB_DWC3
  #define CONFIG_USB_HOST
  #define CONFIG_USB_XHCI_DWC3
  #define CONFIG_USB_XHCI
 @@ -72,6 +73,8 @@
  
  #define CONFIG_OMAP_USB_PHY
  #define CONFIG_OMAP_USB3PHY1_HOST
 +#define CONFIG_USB_DWC3_PHY_OMAP
 +#define CONFIG_USB_DWC3_OMAP
  
  /* SATA */
  #define CONFIG_BOARD_LATE_INIT

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


Re: [U-Boot] [PATCH 03/12] cmd: qfw: remove qemu_fwcfg_free_files()

2016-05-16 Thread Miao Yan
2016-05-14 4:46 GMT+08:00 Tom Rini :
> On Fri, May 13, 2016 at 10:00:05PM +0800, Bin Meng wrote:
>> Hi Miao,
>>
>> On Fri, May 13, 2016 at 2:29 PM, Miao Yan  wrote:
>> > This patch is part of the qfw refactor work.
>> >
>> > The qemu_fwcfg_free_files() function is only used in error handling in
>> > ACPI table generation, let's not make this a core function and move it
>> > to the right place.
>> >
>>
>> But I suspect this API may still be needed in some other scenarioes?
>> eg: for future ARM64 ACPI?
>
> Yes, as it stands currently the code looks likely useful for non-x86
> QEMU+ACPI.

ARM64 and x86 should be able to share common ACPI code. As for now,
this function is not used anywhere but error handling in only one
place. I'd prefer not to make this public.

Thanks,
Miao


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


  1   2   >