Re: [U-Boot] [PATCH] board: move all the rockchip board in one folder

2016-07-07 Thread Ziyuan Xu



On 2016年07月08日 11:30, Kever Yang wrote:

The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them
to 'rockchip' which is a real _vendor_ name, and meet the architecure
'board///'.

More boards from rockchip like evb_rk3288, evb_rk3399 will comes later.

Signed-off-by: Kever Yang 
---
  arch/arm/mach-rockchip/rk3036/Kconfig  |  4 +-
  board/evb_rk3036/evb_rk3036/Kconfig| 15 --
  board/evb_rk3036/evb_rk3036/MAINTAINERS|  0
  board/evb_rk3036/evb_rk3036/Makefile   |  7 ---
  board/evb_rk3036/evb_rk3036/evb_rk3036.c   | 49 --
  board/kylin/kylin_rk3036/Kconfig   | 15 --
  board/kylin/kylin_rk3036/MAINTAINERS   |  0
  board/kylin/kylin_rk3036/Makefile  |  7 ---
  board/kylin/kylin_rk3036/kylin_rk3036.c| 81 --
  board/rockchip/evb_rk3036/Kconfig  | 15 ++
  board/rockchip/evb_rk3036/MAINTAINERS  |  0
  board/rockchip/evb_rk3036/Makefile |  7 +++
  board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++
  board/rockchip/kylin_rk3036/Kconfig| 15 ++
  board/rockchip/kylin_rk3036/MAINTAINERS|  0
  board/rockchip/kylin_rk3036/Makefile   |  7 +++
  board/rockchip/kylin_rk3036/kylin_rk3036.c | 81 ++
  17 files changed, 176 insertions(+), 176 deletions(-)
  delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig
  delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS
  delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile
  delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c
  delete mode 100644 board/kylin/kylin_rk3036/Kconfig
  delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS
  delete mode 100644 board/kylin/kylin_rk3036/Makefile
  delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c
  create mode 100644 board/rockchip/evb_rk3036/Kconfig
  create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS
  create mode 100644 board/rockchip/evb_rk3036/Makefile
  create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c
  create mode 100644 board/rockchip/kylin_rk3036/Kconfig
  create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS
  create mode 100644 board/rockchip/kylin_rk3036/Makefile
  create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c

diff --git a/arch/arm/mach-rockchip/rk3036/Kconfig 
b/arch/arm/mach-rockchip/rk3036/Kconfig
index cc03808..f7562bd 100644
--- a/arch/arm/mach-rockchip/rk3036/Kconfig
+++ b/arch/arm/mach-rockchip/rk3036/Kconfig
@@ -15,7 +15,7 @@ config SYS_MALLOC_F_LEN
  config ROCKCHIP_COMMON
bool "Support rk common fuction"
  
-source "board/evb_rk3036/evb_rk3036/Kconfig"

-source "board/kylin/kylin_rk3036/Kconfig"
+source "board/rockchip/evb_rk3036/Kconfig"
+source "board/rockchip/kylin_rk3036/Kconfig"
  
  endif

diff --git a/board/evb_rk3036/evb_rk3036/Kconfig 
b/board/evb_rk3036/evb_rk3036/Kconfig
deleted file mode 100644
index ae2a9eb..000
--- a/board/evb_rk3036/evb_rk3036/Kconfig
+++ /dev/null
@@ -1,15 +0,0 @@
-if TARGET_EVB_RK3036
-
-config SYS_BOARD
-   default "evb_rk3036"
-
-config SYS_VENDOR
-   default "evb_rk3036"
-
-config SYS_CONFIG_NAME
-   default "evb_rk3036"
-
-config BOARD_SPECIFIC_OPTIONS # dummy
-   def_bool y
-
-endif
diff --git a/board/evb_rk3036/evb_rk3036/MAINTAINERS 
b/board/evb_rk3036/evb_rk3036/MAINTAINERS
deleted file mode 100644
index e69de29..000
diff --git a/board/evb_rk3036/evb_rk3036/Makefile 
b/board/evb_rk3036/evb_rk3036/Makefile
deleted file mode 100644
index 0403836..000
--- a/board/evb_rk3036/evb_rk3036/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-#
-# (C) Copyright 2015 Google, Inc
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y  += evb_rk3036.o
diff --git a/board/evb_rk3036/evb_rk3036/evb_rk3036.c 
b/board/evb_rk3036/evb_rk3036/evb_rk3036.c
deleted file mode 100644
index f5758b1..000
--- a/board/evb_rk3036/evb_rk3036/evb_rk3036.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * (C) Copyright 2015 Rockchip Electronics Co., Ltd
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-void get_ddr_config(struct rk3036_ddr_config *config)
-{
-   /* K4B4G1646Q config */
-   config->ddr_type = 3;
-   config->rank = 2;
-   config->cs0_row = 15;
-   config->cs1_row = 15;
-
-   /* 8bank */
-   config->bank = 3;
-   config->col = 10;
-
-   /* 16bit bw */
-   config->bw = 1;
-}
-
-int board_init(void)
-{
-   return 0;
-}
-
-int dram_init(void)
-{
-   gd->ram_size = sdram_size();
-
-   return 0;
-}
-
-#ifndef CONFIG_SYS_DCACHE_OFF
-void enable_caches(void)
-{
-   /* Enable D-cache. I-cache is already enabled in start.S */
-   dcache_enable();
-}
-#endif
diff --git a/board/kylin/kylin_rk3036/Kconfig b/board/kylin/kylin_rk3036/Kconfig
deleted file mode 100644
index 5d75c1f..000
--- a/board/kylin/kylin_rk3036/Kconfig
+++ /dev/null
@@ -1,15 +0,0 

Re: [U-Boot] [PATCH] board: move all the rockchip board in one folder

2016-07-07 Thread Eddie Cai
2016-07-08 11:30 GMT+08:00 Kever Yang :
> The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them
> to 'rockchip' which is a real _vendor_ name, and meet the architecure
> 'board///'.
>
> More boards from rockchip like evb_rk3288, evb_rk3399 will comes later.
>
> Signed-off-by: Kever Yang 
Reviewed-by: Eddie Cai 
> ---
>  arch/arm/mach-rockchip/rk3036/Kconfig  |  4 +-
>  board/evb_rk3036/evb_rk3036/Kconfig| 15 --
>  board/evb_rk3036/evb_rk3036/MAINTAINERS|  0
>  board/evb_rk3036/evb_rk3036/Makefile   |  7 ---
>  board/evb_rk3036/evb_rk3036/evb_rk3036.c   | 49 --
>  board/kylin/kylin_rk3036/Kconfig   | 15 --
>  board/kylin/kylin_rk3036/MAINTAINERS   |  0
>  board/kylin/kylin_rk3036/Makefile  |  7 ---
>  board/kylin/kylin_rk3036/kylin_rk3036.c| 81 
> --
>  board/rockchip/evb_rk3036/Kconfig  | 15 ++
>  board/rockchip/evb_rk3036/MAINTAINERS  |  0
>  board/rockchip/evb_rk3036/Makefile |  7 +++
>  board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++
>  board/rockchip/kylin_rk3036/Kconfig| 15 ++
>  board/rockchip/kylin_rk3036/MAINTAINERS|  0
>  board/rockchip/kylin_rk3036/Makefile   |  7 +++
>  board/rockchip/kylin_rk3036/kylin_rk3036.c | 81 
> ++
>  17 files changed, 176 insertions(+), 176 deletions(-)
>  delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig
>  delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS
>  delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile
>  delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c
>  delete mode 100644 board/kylin/kylin_rk3036/Kconfig
>  delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS
>  delete mode 100644 board/kylin/kylin_rk3036/Makefile
>  delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c
>  create mode 100644 board/rockchip/evb_rk3036/Kconfig
>  create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS
>  create mode 100644 board/rockchip/evb_rk3036/Makefile
>  create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c
>  create mode 100644 board/rockchip/kylin_rk3036/Kconfig
>  create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS
>  create mode 100644 board/rockchip/kylin_rk3036/Makefile
>  create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c
>
> diff --git a/arch/arm/mach-rockchip/rk3036/Kconfig 
> b/arch/arm/mach-rockchip/rk3036/Kconfig
> index cc03808..f7562bd 100644
> --- a/arch/arm/mach-rockchip/rk3036/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3036/Kconfig
> @@ -15,7 +15,7 @@ config SYS_MALLOC_F_LEN
>  config ROCKCHIP_COMMON
> bool "Support rk common fuction"
>
> -source "board/evb_rk3036/evb_rk3036/Kconfig"
> -source "board/kylin/kylin_rk3036/Kconfig"
> +source "board/rockchip/evb_rk3036/Kconfig"
> +source "board/rockchip/kylin_rk3036/Kconfig"
>
>  endif
> diff --git a/board/evb_rk3036/evb_rk3036/Kconfig 
> b/board/evb_rk3036/evb_rk3036/Kconfig
> deleted file mode 100644
> index ae2a9eb..000
> --- a/board/evb_rk3036/evb_rk3036/Kconfig
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -if TARGET_EVB_RK3036
> -
> -config SYS_BOARD
> -   default "evb_rk3036"
> -
> -config SYS_VENDOR
> -   default "evb_rk3036"
> -
> -config SYS_CONFIG_NAME
> -   default "evb_rk3036"
> -
> -config BOARD_SPECIFIC_OPTIONS # dummy
> -   def_bool y
> -
> -endif
> diff --git a/board/evb_rk3036/evb_rk3036/MAINTAINERS 
> b/board/evb_rk3036/evb_rk3036/MAINTAINERS
> deleted file mode 100644
> index e69de29..000
> diff --git a/board/evb_rk3036/evb_rk3036/Makefile 
> b/board/evb_rk3036/evb_rk3036/Makefile
> deleted file mode 100644
> index 0403836..000
> --- a/board/evb_rk3036/evb_rk3036/Makefile
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -#
> -# (C) Copyright 2015 Google, Inc
> -#
> -# SPDX-License-Identifier: GPL-2.0+
> -#
> -
> -obj-y  += evb_rk3036.o
> diff --git a/board/evb_rk3036/evb_rk3036/evb_rk3036.c 
> b/board/evb_rk3036/evb_rk3036/evb_rk3036.c
> deleted file mode 100644
> index f5758b1..000
> --- a/board/evb_rk3036/evb_rk3036/evb_rk3036.c
> +++ /dev/null
> @@ -1,49 +0,0 @@
> -/*
> - * (C) Copyright 2015 Rockchip Electronics Co., Ltd
> - *
> - * SPDX-License-Identifier: GPL-2.0+
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -void get_ddr_config(struct rk3036_ddr_config *config)
> -{
> -   /* K4B4G1646Q config */
> -   config->ddr_type = 3;
> -   config->rank = 2;
> -   config->cs0_row = 15;
> -   config->cs1_row = 15;
> -
> -   /* 8bank */
> -   config->bank = 3;
> -   config->col = 10;
> -
> -   /* 16bit bw */
> -   config->bw = 1;
> -}
> -
> -int board_init(void)
> -{
> -   return 0;
> -}
> -
> -int dram_init(void)
> -{
> -   gd->ram_size = sdram_size();
> -
> -   return 0;
> -}
> -
> -#ifndef CONFIG_SYS_DCACHE_OFF

Re: [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288

2016-07-07 Thread Ziyuan Xu



On 2016年07月08日 10:45, Kever Yang wrote:

The grf setting for rkpwm is only need in rk3288, other SoCs like
RK3399 which also use rkpwm do not need set the grf, let's add a
MACRO to make the code only for RK3288.

Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477

Superfluous Change-Id.

Signed-off-by: Kever Yang 
---
  drivers/pwm/rk_pwm.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
index 2d289a4..e34adf0 100644
--- a/drivers/pwm/rk_pwm.c
+++ b/drivers/pwm/rk_pwm.c
@@ -13,8 +13,10 @@
  #include 
  #include 
  #include 
+#ifdef CONFIG_ROCKCHIP_RK3288
  #include 
  #include 
+#endif
  #include 
  #include 
  
@@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;
  
  struct rk_pwm_priv {

struct rk3288_pwm *regs;
+#ifdef CONFIG_ROCKCHIP_RK3288
struct rk3288_grf *grf;
+#endif
  };
  
  static int rk_pwm_set_config(struct udevice *dev, uint channel, uint period_ns,

@@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice *dev)
struct regmap *map;
  
  	priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);

+#ifdef CONFIG_ROCKCHIP_RK3288
map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
if (IS_ERR(map))
return PTR_ERR(map);
priv->grf = regmap_get_range(map, 0);
+#endif
  
  	return 0;

  }
  
  static int rk_pwm_probe(struct udevice *dev)

  {
+#ifdef CONFIG_ROCKCHIP_RK3288
struct rk_pwm_priv *priv = dev_get_priv(dev);
  
  	rk_setreg(>grf->soc_con2, 1 << 0);

+#endif
  
  	return 0;

  }



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


[U-Boot] [PATCH] board: move all the rockchip board in one folder

2016-07-07 Thread Kever Yang
The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them
to 'rockchip' which is a real _vendor_ name, and meet the architecure
'board///'.

More boards from rockchip like evb_rk3288, evb_rk3399 will comes later.

Signed-off-by: Kever Yang 
---
 arch/arm/mach-rockchip/rk3036/Kconfig  |  4 +-
 board/evb_rk3036/evb_rk3036/Kconfig| 15 --
 board/evb_rk3036/evb_rk3036/MAINTAINERS|  0
 board/evb_rk3036/evb_rk3036/Makefile   |  7 ---
 board/evb_rk3036/evb_rk3036/evb_rk3036.c   | 49 --
 board/kylin/kylin_rk3036/Kconfig   | 15 --
 board/kylin/kylin_rk3036/MAINTAINERS   |  0
 board/kylin/kylin_rk3036/Makefile  |  7 ---
 board/kylin/kylin_rk3036/kylin_rk3036.c| 81 --
 board/rockchip/evb_rk3036/Kconfig  | 15 ++
 board/rockchip/evb_rk3036/MAINTAINERS  |  0
 board/rockchip/evb_rk3036/Makefile |  7 +++
 board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++
 board/rockchip/kylin_rk3036/Kconfig| 15 ++
 board/rockchip/kylin_rk3036/MAINTAINERS|  0
 board/rockchip/kylin_rk3036/Makefile   |  7 +++
 board/rockchip/kylin_rk3036/kylin_rk3036.c | 81 ++
 17 files changed, 176 insertions(+), 176 deletions(-)
 delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig
 delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS
 delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile
 delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c
 delete mode 100644 board/kylin/kylin_rk3036/Kconfig
 delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS
 delete mode 100644 board/kylin/kylin_rk3036/Makefile
 delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c
 create mode 100644 board/rockchip/evb_rk3036/Kconfig
 create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS
 create mode 100644 board/rockchip/evb_rk3036/Makefile
 create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c
 create mode 100644 board/rockchip/kylin_rk3036/Kconfig
 create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS
 create mode 100644 board/rockchip/kylin_rk3036/Makefile
 create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c

diff --git a/arch/arm/mach-rockchip/rk3036/Kconfig 
b/arch/arm/mach-rockchip/rk3036/Kconfig
index cc03808..f7562bd 100644
--- a/arch/arm/mach-rockchip/rk3036/Kconfig
+++ b/arch/arm/mach-rockchip/rk3036/Kconfig
@@ -15,7 +15,7 @@ config SYS_MALLOC_F_LEN
 config ROCKCHIP_COMMON
bool "Support rk common fuction"
 
-source "board/evb_rk3036/evb_rk3036/Kconfig"
-source "board/kylin/kylin_rk3036/Kconfig"
+source "board/rockchip/evb_rk3036/Kconfig"
+source "board/rockchip/kylin_rk3036/Kconfig"
 
 endif
diff --git a/board/evb_rk3036/evb_rk3036/Kconfig 
b/board/evb_rk3036/evb_rk3036/Kconfig
deleted file mode 100644
index ae2a9eb..000
--- a/board/evb_rk3036/evb_rk3036/Kconfig
+++ /dev/null
@@ -1,15 +0,0 @@
-if TARGET_EVB_RK3036
-
-config SYS_BOARD
-   default "evb_rk3036"
-
-config SYS_VENDOR
-   default "evb_rk3036"
-
-config SYS_CONFIG_NAME
-   default "evb_rk3036"
-
-config BOARD_SPECIFIC_OPTIONS # dummy
-   def_bool y
-
-endif
diff --git a/board/evb_rk3036/evb_rk3036/MAINTAINERS 
b/board/evb_rk3036/evb_rk3036/MAINTAINERS
deleted file mode 100644
index e69de29..000
diff --git a/board/evb_rk3036/evb_rk3036/Makefile 
b/board/evb_rk3036/evb_rk3036/Makefile
deleted file mode 100644
index 0403836..000
--- a/board/evb_rk3036/evb_rk3036/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-#
-# (C) Copyright 2015 Google, Inc
-#
-# SPDX-License-Identifier: GPL-2.0+
-#
-
-obj-y  += evb_rk3036.o
diff --git a/board/evb_rk3036/evb_rk3036/evb_rk3036.c 
b/board/evb_rk3036/evb_rk3036/evb_rk3036.c
deleted file mode 100644
index f5758b1..000
--- a/board/evb_rk3036/evb_rk3036/evb_rk3036.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * (C) Copyright 2015 Rockchip Electronics Co., Ltd
- *
- * SPDX-License-Identifier: GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
-
-void get_ddr_config(struct rk3036_ddr_config *config)
-{
-   /* K4B4G1646Q config */
-   config->ddr_type = 3;
-   config->rank = 2;
-   config->cs0_row = 15;
-   config->cs1_row = 15;
-
-   /* 8bank */
-   config->bank = 3;
-   config->col = 10;
-
-   /* 16bit bw */
-   config->bw = 1;
-}
-
-int board_init(void)
-{
-   return 0;
-}
-
-int dram_init(void)
-{
-   gd->ram_size = sdram_size();
-
-   return 0;
-}
-
-#ifndef CONFIG_SYS_DCACHE_OFF
-void enable_caches(void)
-{
-   /* Enable D-cache. I-cache is already enabled in start.S */
-   dcache_enable();
-}
-#endif
diff --git a/board/kylin/kylin_rk3036/Kconfig b/board/kylin/kylin_rk3036/Kconfig
deleted file mode 100644
index 5d75c1f..000
--- a/board/kylin/kylin_rk3036/Kconfig
+++ /dev/null
@@ -1,15 +0,0 @@
-if TARGET_KYLIN_RK3036
-
-config SYS_BOARD
-   default "kylin_rk3036"
-

Re: [U-Boot] [RESEND PATCH] rockchip: add basic support for evb-rk3288 board

2016-07-07 Thread Kever Yang

Hi Simon,

Pls hold this patch for a moment, I have a patch to clean the board 
files

which vendor is rockchip, I will send it later today.

Thanks,
- Kever
On 07/05/2016 06:06 PM, Ziyuan Xu wrote:

evb-3288 board RK3288-based development board with 2 USB ports, HDMI,
VGA, micro-SD card, audio, WiFi and Gigabit Ethernet. It also includes
on-board 8G eMMC and 2GB of SDRAM. Expansion connector provide access to
display pins, I2C, SPI, UART and GPIOs. This add some basic files
required to allow the board to output serial messaged and can run
command(mmc info etc).

evb-rk3288 also supports booting from eMMC or SD card, the default is eMMC.

Signed-off-by: Ziyuan Xu 

---

  arch/arm/dts/Makefile |   1 +
  arch/arm/dts/rk3288-evb.dts   |  59 +
  arch/arm/dts/rk3288-evb.dtsi  | 379 ++
  arch/arm/mach-rockchip/rk3288-board-spl.c |   4 +-
  arch/arm/mach-rockchip/rk3288/Kconfig |  10 +
  board/evb-rk3288/evb-rk3288/Kconfig   |  15 ++
  board/evb-rk3288/evb-rk3288/MAINTAINERS   |   6 +
  board/evb-rk3288/evb-rk3288/Makefile  |   7 +
  board/evb-rk3288/evb-rk3288/evb-rk3288.c  |  15 ++
  configs/evb-rk3288_defconfig  |  67 ++
  doc/README.rockchip   |   3 +-
  include/configs/evb-rk3288.h  |  26 ++
  12 files changed, 590 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/dts/rk3288-evb.dts
  create mode 100644 arch/arm/dts/rk3288-evb.dtsi
  create mode 100644 board/evb-rk3288/evb-rk3288/Kconfig
  create mode 100644 board/evb-rk3288/evb-rk3288/MAINTAINERS
  create mode 100644 board/evb-rk3288/evb-rk3288/Makefile
  create mode 100644 board/evb-rk3288/evb-rk3288/evb-rk3288.c
  create mode 100644 configs/evb-rk3288_defconfig
  create mode 100644 include/configs/evb-rk3288.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5d463ce..493b9da 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -31,6 +31,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-firefly.dtb \
rk3288-jerry.dtb \
rk3288-rock2-square.dtb \
+   rk3288-evb.dtb \
rk3036-sdk.dtb
  dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-odroidc2.dtb
diff --git a/arch/arm/dts/rk3288-evb.dts b/arch/arm/dts/rk3288-evb.dts
new file mode 100644
index 000..caf24ee
--- /dev/null
+++ b/arch/arm/dts/rk3288-evb.dts
@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+ X11
+ */
+
+/dts-v1/;
+#include "rk3288-evb.dtsi"
+
+/ {
+   model = "Evb-RK3288";
+   compatible = "evb-rk3288,evb-rk3288", "rockchip,rk3288";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   rockchip,num-channels = <2>;
+   rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+   0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
+   0x4 0x8 0x4 0x76 0x4 0x0 0x30 0x0
+   0x1 0x2 0x2 0x4 0x0 0x0 0xc0 0x4
+   0x8 0x1f4>;
+   rockchip,phy-timing = <0x48d7dd93 0x187008d8 0x121076
+   0x0 0xc3 0x6 0x2>;
+   rockchip,sdram-channel = /bits/ 8 <0x2 0xa 0x3 0x2 0x2 0x0 0xe 0xe>;
+   rockchip,sdram-params = <0x20d266a4 0x5b6 2 53300 6 9 0>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   reg-shift = <2>;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi
new file mode 100644
index 000..cb7d03e
--- /dev/null
+++ b/arch/arm/dts/rk3288-evb.dtsi
@@ -0,0 +1,379 @@
+/*
+ * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0+ X11
+ */
+
+#include "rk3288.dtsi"
+
+/ {
+   memory {
+   reg = <0 0x8000>;
+   };
+
+   keys: gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   button@0 {
+   gpio-key,wakeup = <1>;
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   label = "GPIO Power";
+   linux,code = <116>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_key>;
+   };
+   };
+
+   vcc_sys: vsys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   vcc_flash: flash-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_flash";
+   regulator-min-microvolt = <180>;
+

[U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288

2016-07-07 Thread Kever Yang
The grf setting for rkpwm is only need in rk3288, other SoCs like
RK3399 which also use rkpwm do not need set the grf, let's add a
MACRO to make the code only for RK3288.

Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477
Signed-off-by: Kever Yang 
---
 drivers/pwm/rk_pwm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
index 2d289a4..e34adf0 100644
--- a/drivers/pwm/rk_pwm.c
+++ b/drivers/pwm/rk_pwm.c
@@ -13,8 +13,10 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_ROCKCHIP_RK3288
 #include 
 #include 
+#endif
 #include 
 #include 
 
@@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 struct rk_pwm_priv {
struct rk3288_pwm *regs;
+#ifdef CONFIG_ROCKCHIP_RK3288
struct rk3288_grf *grf;
+#endif
 };
 
 static int rk_pwm_set_config(struct udevice *dev, uint channel, uint period_ns,
@@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice *dev)
struct regmap *map;
 
priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);
+#ifdef CONFIG_ROCKCHIP_RK3288
map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
if (IS_ERR(map))
return PTR_ERR(map);
priv->grf = regmap_get_range(map, 0);
+#endif
 
return 0;
 }
 
 static int rk_pwm_probe(struct udevice *dev)
 {
+#ifdef CONFIG_ROCKCHIP_RK3288
struct rk_pwm_priv *priv = dev_get_priv(dev);
 
rk_setreg(>grf->soc_con2, 1 << 0);
+#endif
 
return 0;
 }
-- 
1.9.1


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


Re: [U-Boot] Pull request: u-boot-net.git master

2016-07-07 Thread Tom Rini
On Wed, Jul 06, 2016 at 10:46:51AM -0500, Joe Hershberger wrote:

> Hi Tom,
> 
> A few small last minute compile fixes and a phy support addition.
> 
> The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:
> 
>   Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-net.git master
> 
> for you to fetch changes up to 4c64c4db3b87818318ed8b4cd6907c508aaf04ce:
> 
>   net: rtl8169: Fix return value for rtl_send_common (2016-07-06 10:45:11 
> -0500)
> 

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] [PULL] u-boot-usb/master

2016-07-07 Thread Tom Rini
On Thu, Jul 07, 2016 at 03:55:43PM +0200, Marek Vasut wrote:

> Hi Tom,
> 
> I added one more patch by York to fix the powerpc mess. Updated PR
> below, please pull for 2016.07 .
> 
> Thanks!
> 
> The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:
> 
>Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)
> 
> are available in the git repository at:
> 
>git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to eb364c3dc28d59d33e823470d07746b22a8e6fee:
> 
>powerpc: mpc85xx: kmp204x: Fix compiling error for usb errata
> (2016-07-07 13:34:10 +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] Pull request, u-boot-tegra/master

2016-07-07 Thread Tom Rini
On Wed, Jul 06, 2016 at 10:32:53AM -0700, Tom Warren wrote:

> Tom,
> 
> Please pull u-boot-tegra/master into U-Boot/master. Thanks!
> 
> All Tegra builds are OK, and Stephen's automated test system reports that
> all tests pass.
> 
> The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:
> 
>   Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-tegra.git master
> 
> for you to fetch changes up to 703aaf76c2c06109fc36266767b2d1dcfce6f3ba:
> 
>   fdt: Drop some unused compatible strings (2016-07-05 13:23:04 -0700)
> 

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] Please pull u-boot-rockchip

2016-07-07 Thread Tom Rini
On Tue, Jul 05, 2016 at 11:05:36AM -0600, Simon Glass wrote:

> Hi Tom,
> 
> Just a little patch that got lost in time.
> 
> The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:
> 
>   Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git
> 
> for you to fetch changes up to 70c440e5bdca097915b71170f9532ae4faad735a:
> 
>   rockchip: video: Lower hpd wait time (2016-07-05 10:38:56 -0600)
> 

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] BayTrail PCIe x4 slot (Soft-Strap?)

2016-07-07 Thread Bin Meng
Hi Stefan,

On Thu, Jul 7, 2016 at 11:52 PM, Stefan Roese  wrote:
> Hi!
>
> I do have BayTrail / FSP related question. I'm currently trying
> to use a DFI QSeven SoM which has one x4 PCIe slot instead
> of the usual 4 x1 slots. So all 4 PCIe lanes are used by the
> first PCIe controller. With the current U-Boot, all 4 PCIe
> controllers are enabled by the FSP :
>
> 00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express 
> Root Port 1 (rev 11)
> 00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express 
> Root Port 2 (rev 11)
> 00:1c.2 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express 
> Root Port 3 (rev 11)
> 00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express 
> Root Port 4 (rev 11)
>
> In this configuration, the x4 PCIe card that is installed in the
> PCIe slot is not detected. The system always generated hotplug
> events for all for ports, but the link is not established.
>
> The original DFI BIOS only enables the first PCIe controller. The
> controllers 1...3 are not visible via lspci. Here the 4x link
> is established and the 4x PCIe card is detected correctly.
>
> My question now is, how can I enable this 4x link on the first
> PCIe controller via U-Boot / FSP? I have found no option on how
> to configure the PCIe controllers in the FSP dts properties.
> So that only the first controller is enabled and visible via
> lspci etc. The BayTrail datasheet mentions this to configure the
> PCIe setup in chapter "23.2.1 Root Port Configurations":
>
> "
> Root port configurations are set by SoftStraps stored in SPI flash,
> and the default option is “(4) x1”. Links for each root port will
> train automatically to the maximum possible for each port.
> "
>

Correct. It's determined by the soft strap value in the SPI flash, to
be specific, in the descriptor.bin.

> Where is this SoftStraps in the SPI flash located? I've found this
> page mentioning that its a offset 0x100:
>
> https://embedded.communities.intel.com/thread/8539
>
> But I fail to find any documentation for all those Soft-Strap
> Registers / Values in the SPI flash. Does anyone have some further
> infos / documentation on this? How to enable 4x PCIe lanes
> for one PCIe controller on BayTrail / Atom?
>

Please try this:

If you have the original DFI BIOS, extract the descriptor.bin using
U-Boot's ifdtool (ifdtool -x dfi_bios), and use this descriptor.bin to
generate u-boot.rom. Or if you don't have the original DFI BIOS, dump
it using Dediprog SF100, and do the same.

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


Re: [U-Boot] [PATCH] driver: fsl_qspi: disable AHB buffer prefetch

2016-07-07 Thread Yunhui Cui

>On 07/07/2016 1:01 AM, york sun wrote: 
> On 07/03/2016 08:27 PM, Yunhui Cui wrote:
> > From: Yunhui Cui 
> >
> > A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
> > Affects: QuadSPI
> > Description: With AHB buffer prefetch enabled, the QuadSPI may return
> > incorrect data on the AHB interface. The buffer pre-fetch is enabled
> > if the fetch size as configured either in the LUT or in the BUFxCR
> > register is greater than 8 bytes.
> > Impact: Only 64 bit read allowed.
> > Workaround: Keep the read data size to 64 bits (8 Bytes), which
> > disables the prefetch on the AHB buffer, and prevents this issue from
> > occurring.
> >
> > Signed-off-by: Yunhui Cui 
> > ---
> >   drivers/spi/fsl_qspi.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> > 75cbab2..e0a002d 100644
> > --- a/drivers/spi/fsl_qspi.c
> > +++ b/drivers/spi/fsl_qspi.c
> > @@ -444,7 +444,7 @@ static void qspi_init_ahb_read(struct fsl_qspi_priv
> *priv)
> > qspi_write32(priv->flags, >buf1cr,
> QSPI_BUFXCR_INVALID_MSTRID);
> > qspi_write32(priv->flags, >buf2cr,
> QSPI_BUFXCR_INVALID_MSTRID);
> > qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
> > -(0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
> > +(0x1 << QSPI_BUF3CR_ADATSZ_SHIFT));
> >
> > /* We only use the buffer3 */
> > qspi_write32(priv->flags, >buf0ind, 0);
> >
> 
> Yunhui,
> 
> We handle erratum workaround using macros in case the workaround has
> impact on other SoCs.

[Yunhui] For now, all SoCs with Qspi module need this errata.

> We also put the erratum information either in a
> README file, or inline comment. It will be easier to read the code later.

[Yunhui] ok, I will add inline comment in next version.

> You don't have to put the whole erratum description in the commit message,
> as long as it explains what this patch does and refer the erratum number
> somewhere in the message so we can search the git log.
> 
> York

[Yunhui] ok, I will update the commit message in next version.

Thanks
Yunhui




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


Re: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys

2016-07-07 Thread Ziyuan Xu



On 2016年07月08日 04:33, Heiko Stuebner wrote:

Am Donnerstag, 7. Juli 2016, 09:58:38 schrieb Ziyuan Xu:

On 2016年07月06日 21:42, Heiko Stuebner wrote:

Am Mittwoch, 6. Juli 2016, 14:48:57 schrieb Heiko Stuebner:

Am Mittwoch, 6. Juli 2016, 18:20:04 schrieb Ziyuan Xu:

Hi heiko,

On 2016年07月06日 17:34, Ziyuan Xu wrote:

From: Xu Ziyuan 

So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and
Innosilicon. This patch applys dwc2 usb driver framework to implement
phy_init and phy_off for Synopsys phy on Rockchip platform.

Signed-off-by: Ziyuan Xu 

---

Changes in v3:
- Make UOC_CON registers to be unfixed which should be got from DT

Changes in v2:
- Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
- Rework the behaviour in otg_phy_init() and otg_phy_off()

drivers/usb/phy/Makefile|  1 +
drivers/usb/phy/rockchip_usb_syno_phy.c | 47
+ 2 files changed, 48
insertions(+)
create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c

diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 93d147e..8002a18 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -7,3 +7,4 @@

obj-$(CONFIG_TWL4030_USB) += twl4030.o
obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o

+obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o
diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c
b/drivers/usb/phy/rockchip_usb_syno_phy.c new file mode 100644
index 000..ab049e1
--- /dev/null
+++ b/drivers/usb/phy/rockchip_usb_syno_phy.c
@@ -0,0 +1,47 @@
+/*
+ * Copyright 2016 Rockchip Electronics Co., Ltd
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+#include "../gadget/dwc2_udc_otg_priv.h"
+
+#define UOC_CON(x) ((x) * 0x4)

As you know, dwc2 usb driver didn't apply devicetree model. It's hard
to
implement a compatible driver for Rockchip SoCs which use a same udc.

Yeah, it is pretty strange that the dwc2 host part in uboot uses the
devicetree while the gadget part does not - but I maybe someone else
can
answer this, as my contact with uboot was limited until now.
The dwc2 host driver works just fine on my rk3036 kylin board.


For example,
SOFT_CTRL bit is  UOC_CON2[2] on RK3288
I can't assure it's also UOC_CON[2] on other socs.
Do you have any good ideas?

Operating under the current constraints, I guess you could simply do
something similar to what socfpga does in its board file.

socfpga? Could you please indicate which project and file? I can't find
out it.


Aka get the usb controller node, read the phy phandle and get the phy
compatible string from the dts. The usbphys each have per-soc
compatible
values "rockchip,rk3288-usbphy" etc, so you can determine the needed
bits
over that.

In patchset [v3.3/4](http://patchwork.ozlabs.org/patch/645188/), I had
get usb-phy offset from grf.
If I understand it correctly, you mean that implement a struct in driver
to match compatible and platdata. Then define any properties in
platdata, contains of some bits which will be used.  Something similar
to https://patchwork.kernel.org/patch/9190287/?

yep, you just need to find some mechanism to identify the soc you're running
on so that the phy part can access the right registers on each one.

Thanks for your opinion, I will do it.


Heiko






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


[U-Boot] Please pull u-boot-dm

2016-07-07 Thread Simon Glass
Hi Tom,

A little fix.

The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:

  Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to 3cc5cda761c14628b25131bfc0db5dee433a52aa:

  mmc: msm_sdhci: Set mmc->dev pointer in msm_sdc_probe() (2016-07-07
10:10:29 -0600)


Mateusz Kulikowski (1):
  mmc: msm_sdhci: Set mmc->dev pointer in msm_sdc_probe()

 drivers/mmc/msm_sdhci.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH v3 1/4] usb: rockchip-phy: implement USB2.0 phy control for Synopsys

2016-07-07 Thread Heiko Stuebner
Am Donnerstag, 7. Juli 2016, 09:58:38 schrieb Ziyuan Xu:
> On 2016年07月06日 21:42, Heiko Stuebner wrote:
> > Am Mittwoch, 6. Juli 2016, 14:48:57 schrieb Heiko Stuebner:
> >> Am Mittwoch, 6. Juli 2016, 18:20:04 schrieb Ziyuan Xu:
> >>> Hi heiko,
> >>> 
> >>> On 2016年07月06日 17:34, Ziyuan Xu wrote:
>  From: Xu Ziyuan 
>  
>  So far, Rockchip SoCs have two kinds of USB2.0 phy, like Synopsys and
>  Innosilicon. This patch applys dwc2 usb driver framework to implement
>  phy_init and phy_off for Synopsys phy on Rockchip platform.
>  
>  Signed-off-by: Ziyuan Xu 
>  
>  ---
>  
>  Changes in v3:
>  - Make UOC_CON registers to be unfixed which should be got from DT
>  
>  Changes in v2:
>  - Rename rk3288_usb_phy.c to rockchip_usb_syno_phy.c
>  - Rework the behaviour in otg_phy_init() and otg_phy_off()
>  
> drivers/usb/phy/Makefile|  1 +
> drivers/usb/phy/rockchip_usb_syno_phy.c | 47
> + 2 files changed, 48
> insertions(+)
> create mode 100644 drivers/usb/phy/rockchip_usb_syno_phy.c
>  
>  diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
>  index 93d147e..8002a18 100644
>  --- a/drivers/usb/phy/Makefile
>  +++ b/drivers/usb/phy/Makefile
>  @@ -7,3 +7,4 @@
>  
> obj-$(CONFIG_TWL4030_USB) += twl4030.o
> obj-$(CONFIG_OMAP_USB_PHY) += omap_usb_phy.o
>  
>  +obj-$(CONFIG_ROCKCHIP_USB_SYNO_PHY) += rockchip_usb_syno_phy.o
>  diff --git a/drivers/usb/phy/rockchip_usb_syno_phy.c
>  b/drivers/usb/phy/rockchip_usb_syno_phy.c new file mode 100644
>  index 000..ab049e1
>  --- /dev/null
>  +++ b/drivers/usb/phy/rockchip_usb_syno_phy.c
>  @@ -0,0 +1,47 @@
>  +/*
>  + * Copyright 2016 Rockchip Electronics Co., Ltd
>  + *
>  + * SPDX-License-Identifier:GPL-2.0+
>  + */
>  +
>  +#include 
>  +#include 
>  +
>  +#include "../gadget/dwc2_udc_otg_priv.h"
>  +
>  +#define UOC_CON(x)  ((x) * 0x4)
> >>> 
> >>> As you know, dwc2 usb driver didn't apply devicetree model. It's hard
> >>> to
> >>> implement a compatible driver for Rockchip SoCs which use a same udc.
> >> 
> >> Yeah, it is pretty strange that the dwc2 host part in uboot uses the
> >> devicetree while the gadget part does not - but I maybe someone else
> >> can
> >> answer this, as my contact with uboot was limited until now.
> >> The dwc2 host driver works just fine on my rk3036 kylin board.
> >> 
> >>> For example,
> >>> SOFT_CTRL bit is  UOC_CON2[2] on RK3288
> >>> I can't assure it's also UOC_CON[2] on other socs.
> >>> Do you have any good ideas?
> >> 
> >> Operating under the current constraints, I guess you could simply do
> >> something similar to what socfpga does in its board file.
> 
> socfpga? Could you please indicate which project and file? I can't find
> out it.
> 
> >> Aka get the usb controller node, read the phy phandle and get the phy
> >> compatible string from the dts. The usbphys each have per-soc
> >> compatible
> >> values "rockchip,rk3288-usbphy" etc, so you can determine the needed
> >> bits
> >> over that.
> 
> In patchset [v3.3/4](http://patchwork.ozlabs.org/patch/645188/), I had
> get usb-phy offset from grf.
> If I understand it correctly, you mean that implement a struct in driver
> to match compatible and platdata. Then define any properties in
> platdata, contains of some bits which will be used.  Something similar
> to https://patchwork.kernel.org/patch/9190287/?

yep, you just need to find some mechanism to identify the soc you're running 
on so that the phy part can access the right registers on each one.


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


Re: [U-Boot] DMA driver for PL330

2016-07-07 Thread Simon Glass
Hi Dinh,

On 7 July 2016 at 10:30, Dinh Nguyen  wrote:
>
> Hi Simon,
>
> I was wondering if you know of anyone working to add the PL330 driver
> into U-Boot? If not, then perhaps I'll work on adding it to U-Boot.
>
> SoCFPGA has a specific need for it with regards to enabling the SDRAM ECC.

No, not me. Please go ahead.

>
> Thanks,
> Dinh

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


Re: [U-Boot] [PATCH 00/11] buildman: Make the tool friendlier for first-time users

2016-07-07 Thread Stephen Warren

On 07/03/2016 03:14 PM, Simon Glass wrote:

This makes a few minor improvements to buildman to make it work more easiler
for first-time users:

- Improve progress and warning messages when fetching toolchains
- Fix a bug where toolchain paths can be overwritten when fetching
- Note at the top of the help how to get started

Also this series removes MAKEALL. Since buildman has been around for 3 years
it may be time to do this. If not, we can leave it for now.


Sounds great:-)

BTW, one problem I've come across with buildman recently is that it 
re-orders warnings/errors from the compiler. In particular, it seems to 
separate what it thinks are warning from errors (perhaps stdout/stderr 
split??) but I'm not sure it always gets it right, and I think elides 
duplicate lines when doing so. When running buildman repeatedly while 
doing development, and experiencing a compile error, this makes it 
extremely difficult to interpret some of the compiler's multi-line 
messages. Is it possible to have an option that turns off all the output 
processing, and just shows stderr/out mixed up as they would appear 
"interactively" when manually invoked from a shell, with no 
post-processing? Occasionally I have to fall back to a manual "make" 
invocation due to this.

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


Re: [U-Boot] [PATCH 09/11] buildman: Add a quick-start note

2016-07-07 Thread Stephen Warren

On 07/03/2016 03:14 PM, Simon Glass wrote:

For those who just want to build a board, it is useful to see a quick hint
right at the start of the documentation. Add a few commands showing how to
download toolchains and build a board.



diff --git a/tools/buildman/README b/tools/buildman/README



+If you just want to quickly set up buildman so you can build something (for
+example Raspberry Pi 2), and don't mind downloading lots of stuff:
+
+   cd /path/to/u-boot
+   PATH=$PATH:`pwd`/tools/buildman
+   buildman --fetch-arch all
+   buildman -k rpi_2
+   ls ../current/rpi_2
+   # u-boot.bin is the output image


For just an rpi_2 build, perhaps "--fetch-arch arm" would be quicker, 
although I suppose then you'd have to make the text more complicated by 
pointing out that it only downloads an ARM toolchain and so the user 
would need to --fetch-arch again for anything else.

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


Re: [U-Boot] [PATCH 08/11] buildman: Avoid overwriting existing toolchain entries

2016-07-07 Thread Stephen Warren

On 07/03/2016 03:14 PM, Simon Glass wrote:

The current code for setting up the toolchain config always writes the new
paths to an item called 'toolchain'. This means that it will overwrite any
existing toolchain item with the same name. In practice, this means that:

buildman --fetch-arch all

will fetch all toolchains, but only the path of the final one will be added
to the config. This normally works out OK, since most toolchains are the
same version (e.g. gcc 4.9) and will be found on the same path. But it is
not correct and toolchains for archs which don't use the same version will
not function as expected.

Adjust the code to use unique names for each toolchain path entry.



diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py



+def GetItemsAsDict(section):
+"""Get the items from a section of the config.
+
+Args:
+section: name of section to retrieve
+
+Returns:
+Dict:
+   key: name of item
+   value: value of item
+"""
+try:
+items = {}
+for item in settings.items(section):
+items[item[0]] = item[1]


Aren't those last 3 lines equivalent to:

items = dict(settings.items(section))
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 04/11] buildman: Allow the toolchain error to be suppressed

2016-07-07 Thread Stephen Warren

On 07/03/2016 03:14 PM, Simon Glass wrote:

When there are no toolchains a warning is printed. But in some cases this is
confusing, such as when the user is fetching new toolchains.

Adjust the function to supress the warning in this case.



diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py



-def GetPathList(self):
+def GetPathList(self, show_warning=True):
  """Get a list of available toolchain paths

+Args:
+show_warning: True to show a warning if there are no tool chains.


I don't see the new parameter being used anywhere?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 02/11] buildman: Automatically create a config file if needed

2016-07-07 Thread Stephen Warren

On 07/03/2016 03:14 PM, Simon Glass wrote:

If there is no ~/.buildman file, buildman currently complains and exists. To
make things a little more friendly, create an empty one automatically. This
will not allow things to be built, but --fetch-arch can be used to handle
that.


Is it worth pointing out that caveat in the message that's printed?

Is that caveat true e.g. in the case where the user already has a 
suitable compiler installed in (the default?) /usr/bin?

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


Re: [U-Boot] [PATCH 14/14] test: Convert the vboot test to test/py

2016-07-07 Thread Stephen Warren

On 07/03/2016 03:38 PM, Teddy Reed wrote:

Hi Simon,

On Sun, Jul 3, 2016 at 8:40 AM, Simon Glass  wrote:

Now that we have a suitable test framework we should move all tests into it.
The vboot test is a suitable candidate. Rewrite it in Python and move the
data files into an appropriate directory.



+datadir = 'test/py/tests/vboot/'
+fit = '%stest.fit' % tmpdir
+mkimage = cons.config.build_dir + '/tools/mkimage'
+fit_check_sign = cons.config.build_dir + '/tools/fit_check_sign'
+dtc_args = '-I dts -O dtb -i %s' % tmpdir
+dtb = '%ssandbox-u-boot.dtb' % tmpdir
+sig_node = '/configurations/conf@1/signature@1'


If these variables are used throughout the tests like globals, should
they be DATADIR, MKIMAGE, etc?


I'd prefer not to use all-caps variable names.

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


Re: [U-Boot] [PATCH 14/14] test: Convert the vboot test to test/py

2016-07-07 Thread Stephen Warren

On 07/03/2016 09:40 AM, Simon Glass wrote:

Now that we have a suitable test framework we should move all tests into it.
The vboot test is a suitable candidate. Rewrite it in Python and move the
data files into an appropriate directory.



diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py



+# Copyright (c) 2013, Google Inc.


2013-2016?


+@pytest.mark.buildconfigspec('fit_signature')
+def test_vboot(u_boot_console):
+"""Test verified boot signing with mkimage and verification with 'bootm'.
+
+This works using sandbox only as it needs to update the device tree used
+by U-Boot to hold public keys from the signing process.


Since this works on sandbox, the function should be marked:

@pytest.mark.boardspec('sandbox')


+def dtc(dts):



+util.cmd(cons, 'dtc %s %s%s -O dtb '
+   '-o %s%s' % (dtc_args, datadir, dts, tmpdir, dtb))


For all the instances of util.cmd() in this file, it looks pretty easy 
to represent them as arrays rather than strings. Is implementing/using 
cmd() really necessary?



+def run_bootm(test_type, expect_string):



+cons.cleanup_spawn()
+cons.ensure_spawned()


That feels a bit too much like relying on internal details, especially 
as the docstring for cleanup_spawn() says "This is an internal function 
and should not be called directly." Can we introduce a new public 
function cons.restart_uboot() that's intended for public use? The 
implementation would just be the two lines above, but it would provide 
some encapsulation of the details.



+cons.log.action('%s: Test Verified Boot Run: %s' % (algo, test_type))

> +output = cons.run_command_list(
> +['sb load hostfs - 100 %stest.fit' % tmpdir,
> + 'fdt addr 100',
> + 'bootm 100'])
> +assert(expect_string in output)

Would it make sense to do this instead:

with cons.log.section("Verified boot %s %s" % (algo, test_type)):
output = ...
assert ...

? That would nest each invocation of that command list into a separate 
collapsible section of the HTML log file.



+def test_with_algo(sha):
+"""Test verified boot with the given hash algorithm
+
+This is the main part of the test code. The same procedure is followed
+for both hashing algorithms.
+
+Args:
+sha: Either 'sha1' or 'sha256', to select the algorithm to use
+"""
+global algo
+
+algo = sha


Why not just pass that parameter to the couple of functions that need it?

Certainly, having the various utility functions rely on variables from 
outer scopes is consistent with some other existing tests, but if you're 
going to do that, I'd suggest having this function not take the sha 
parameter, but instead pick up "algo" from an outer scope too?



+# Compile our device tree files for kernel and U-Boot
+dtc('sandbox-kernel.dts')
+dtc('sandbox-u-boot.dts')


I think that happens twice, and ends up doing an identical operation. 
Should those commands (and perhaps some others below too?) be moved 
outside the function into top-level setup code?


Also, is it necessary to repeat those commands if a previous test run 
already ran dtc? Here, dtc is an external utility so I don't think 
running it over and over is worthwhile. However, for some/all of the 
mkimage below, since mkimage presumably comes from the current U-Boot 
build, re-running it each time would actually test something about the 
current U-Boot source tree.



+# Build the FIT, but don't sign anything yet
+cons.log.action('%s: Test FIT with signed images' % algo)
+make_fit('sign-images-%s.its' % algo)
+run_bootm('unsigned images', 'dev-')


Perhaps rather than run_bootm() creating its own log section, the 
section should be created here, and wrap all 3 of those lines above?



+# Sign images with our dev keys
+sign_fit()
+run_bootm('signed images', 'dev+')
+
+# Create a fresh .dtb without the public keys
+dtc('sandbox-u-boot.dts')


Doesn't this generate the same DTB as above? I don't see any 
FIT/binary/... include statements etc. in that .dts file.



+byte_list = ['%x' % (byte + 1)] + byte_list[1:]


byte_list[0] = '%x' % (byte + 1)

?


+cons = u_boot_console
+tmpdir = cons.config.result_dir + '/'
+tmp = tmpdir + 'vboot.tmp'
+datadir = 'test/py/tests/vboot/'


I suspect some of the files might usefully be placed into 
ubconfig.persistent_data_dir?



+fit = '%stest.fit' % tmpdir
+mkimage = cons.config.build_dir + '/tools/mkimage'
+fit_check_sign = cons.config.build_dir + '/tools/fit_check_sign'
+dtc_args = '-I dts -O dtb -i %s' % tmpdir
+dtb = '%ssandbox-u-boot.dtb' % tmpdir


I think all those filename concatenations would be clearer as '%s/%s' 
rather than placing the / into one of the strings.



+# Create an RSA key pair
+public_exponent = 65537
+  

Re: [U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel

2016-07-07 Thread Michal Simek
Hi,

2016-07-07 13:44 GMT+02:00 Alexander Graf :

> On 07/07/2016 08:25 AM, Alison Wang wrote:
>
>> As CONFIG_ARMV8_SWITCH_TO_EL1 is not used now, this patch is to remove
>> CONFIG_ARMV8_SWITCH_TO_EL1 and the corresponding functions.
>>
>> Signed-off-by: Alison Wang 
>>
>
> I'll CC the maintainers for ZynqMP and Exynos as well, but from my side
> this patch is a great step forward.
>
> Reviewed-by: Alexander Graf 



I am against this patch. The reason is simple. We are using this option for
testing to make sure that hyperviser and OS
behaves correctly when they start from different level.

Thanks,
Michal

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


Re: [U-Boot] [PATCH] driver: fsl_qspi: disable AHB buffer prefetch

2016-07-07 Thread york sun
On 07/07/2016 12:52 AM, Yunhui Cui wrote:
>
>> On 07/07/2016 1:01 AM, york sun wrote:
>> On 07/03/2016 08:27 PM, Yunhui Cui wrote:
>>> From: Yunhui Cui 
>>>
>>> A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
>>> Affects: QuadSPI
>>> Description: With AHB buffer prefetch enabled, the QuadSPI may return
>>> incorrect data on the AHB interface. The buffer pre-fetch is enabled
>>> if the fetch size as configured either in the LUT or in the BUFxCR
>>> register is greater than 8 bytes.
>>> Impact: Only 64 bit read allowed.
>>> Workaround: Keep the read data size to 64 bits (8 Bytes), which
>>> disables the prefetch on the AHB buffer, and prevents this issue from
>>> occurring.
>>>
>>> Signed-off-by: Yunhui Cui 
>>> ---
>>>drivers/spi/fsl_qspi.c | 2 +-
>>>1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
>>> 75cbab2..e0a002d 100644
>>> --- a/drivers/spi/fsl_qspi.c
>>> +++ b/drivers/spi/fsl_qspi.c
>>> @@ -444,7 +444,7 @@ static void qspi_init_ahb_read(struct fsl_qspi_priv
>> *priv)
>>> qspi_write32(priv->flags, >buf1cr,
>> QSPI_BUFXCR_INVALID_MSTRID);
>>> qspi_write32(priv->flags, >buf2cr,
>> QSPI_BUFXCR_INVALID_MSTRID);
>>> qspi_write32(priv->flags, >buf3cr, QSPI_BUF3CR_ALLMST_MASK |
>>> -(0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
>>> +(0x1 << QSPI_BUF3CR_ADATSZ_SHIFT));
>>>
>>> /* We only use the buffer3 */
>>> qspi_write32(priv->flags, >buf0ind, 0);
>>>
>>
>> Yunhui,
>>
>> We handle erratum workaround using macros in case the workaround has
>> impact on other SoCs.
>
> [Yunhui] For now, all SoCs with Qspi module need this errata.

I still think it is better to gate the workaround with #ifdef in case we 
need to disable it for future SoCs. It will also be easier to locate the 
workaround code.

>
>> We also put the erratum information either in a
>> README file, or inline comment. It will be easier to read the code later.
>
> [Yunhui] ok, I will add inline comment in next version.
>
>> You don't have to put the whole erratum description in the commit message,
>> as long as it explains what this patch does and refer the erratum number
>> somewhere in the message so we can search the git log.
>>
>> York
>
> [Yunhui] ok, I will update the commit message in next version.
>

Thanks.

York


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


Re: [U-Boot] [PATCH 13/14] test/py: Fix up after the rename of CONFIG_SYS_HUSH_PARSER

2016-07-07 Thread Stephen Warren

On 07/03/2016 09:40 AM, Simon Glass wrote:

At present all the hush tests are skipped on sandbox because the test thinks
that this option is disabled. In fact it has just been renamed.

It might be better to use the full CONFIG_xxx name in tests with
@pytest.mark.buildconfigspec(), since at present it is not really clear that
the options are related.

Fixes: f1f9d4fa (hush: complete renaming CONFIG_SYS_HUSH_PARSER to 
CONFIG_HUSH_PARSER)


Oh, I sent almost a duplicate of this later:

https://patchwork.ozlabs.org/patch/645376/

That one also fixes a similar issue due to the reset -> sysreset rename.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 08/14] test/py: Add an option to execute a string containing a command

2016-07-07 Thread Stephen Warren

On 07/03/2016 09:40 AM, Simon Glass wrote:

It is sometimes inconvenient to convert a string into a list for execution
with run_and_log(). Provide a helper function to do this.



diff --git a/test/py/u_boot_utils.py b/test/py/u_boot_utils.py



+def cmd(u_boot_console, cmd_str):
+"""Run a single command string and log its output.
+
+Args:
+u_boot_console: A console connection to U-Boot.
+cmd: The command to run, as a string.
+
+Returns:
+The output as a string.
+"""


Thinking about this more: I believe the Pythonic way to do this would be 
to extend the existing run_and_log() to support the cmd parameter being 
either an array, or a string; I think something like just adding the 
following at the start of run_and_log():


if isinstance(cmd, str):
cmd = str.split()

This would also allow other higher-order functions like your later 
run_command_list() to take either a list of argv[] or a list of strings 
(or even a mixture), without having to code multiple versions of the 
higher level functions for the different cases.

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


Re: [U-Boot] [PATCH 09/14] test/py: Provide a way to check that a command fails

2016-07-07 Thread Stephen Warren

On 07/03/2016 09:40 AM, Simon Glass wrote:

Sometimes we want to run a command and check that it fails. Add a function
to handle this. It can check the return code and also make sure that the
output contains a given error message.



diff --git a/test/py/u_boot_utils.py b/test/py/u_boot_utils.py



+def run_and_log_expect_exception(u_boot_console, cmd, retcode, msg):
+"""Run a command which is expected to fail.
+
+This runs a command and checks that it fails with the expected return code
+and exception method. If not, an exception is raised.
+
+Args:
+u_boot_console: A console connection to U-Boot.
+cmd: The command to run, as an array of argv[].
+retcode: Expected non-zero return code from the command.
+msg: String which should be contained within the command's output.
+"""


retcode isn't used anywhere. Do we care what the return code is, so long 
as it's something non-zero, and the desired exception message appears?

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


Re: [U-Boot] [PATCH 08/14] test/py: Add an option to execute a string containing a command

2016-07-07 Thread Stephen Warren

On 07/03/2016 09:40 AM, Simon Glass wrote:

It is sometimes inconvenient to convert a string into a list for execution
with run_and_log(). Provide a helper function to do this.



diff --git a/test/py/u_boot_utils.py b/test/py/u_boot_utils.py



+def cmd(u_boot_console, cmd_str):


"cmd" seems very generic and doesn't give any clue what it does. How 
about extending the existing function name to e.g. "run_and_log_str"?

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


[U-Boot] DMA driver for PL330

2016-07-07 Thread Dinh Nguyen
Hi Simon,

I was wondering if you know of anyone working to add the PL330 driver
into U-Boot? If not, then perhaps I'll work on adding it to U-Boot.

SoCFPGA has a specific need for it with regards to enabling the SDRAM ECC.

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


Re: [U-Boot] [PATCH 2/2] dm: mmc: dwmmc: use the callback functions as static

2016-07-07 Thread Simon Glass
Hi Minkyu,

On 6 July 2016 at 20:14, Minkyu Kang  wrote:
> Hi,
>
> On 01/07/16 04:53, Simon Glass wrote:
>> Hi Jaehoon,
>>
>> On 28 June 2016 at 20:47, Jaehoon Chung  wrote:
>>> Hi Simon,
>>>
>>> On 06/29/2016 12:28 PM, Simon Glass wrote:
 Hi Jaehoon,

 On 27 June 2016 at 23:52, Jaehoon Chung  wrote:
> There are no places to call these functions.
> It should be used the callback function.
> Then it can be used as static functions.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/mmc/dw_mmc.c | 4 ++--
>  include/dwmmc.h  | 3 ---
>  2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 3411f95..f83a6bc 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -182,7 +182,7 @@ static int dwmci_set_transfer_mode(struct dwmci_host 
> *host,
>  }
>
>  #ifdef CONFIG_DM_MMC_OPS
> -int dwmci_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,

 >From what I can see this is already static. Which commit are you basing 
 >off?
>>>
>>> I'm checking with your 'blk-working' branch. I'm not sure what's correct.
>>>
>>> commit dee390a1250c17a4e71e359d6e461319a7cdea54
>>> Author: Simon Glass 
>>> Date:   Sat Jun 11 19:01:49 2016 -0600
>>>
>>> dm: blk: Enable CONFIG_BLK if DM_MMC is enabled
>>>
>>> If i need to work with other branch, let me know,plz.
>>> I have tested the DM with dw_mmc_exynos.c. (It's working fine.)
>>>
>>> I will send the patch-set for exynos dwmmc and sdhci controller.
>>> So i need to know which repository and branch are correct. :)
>>>
>>> Then it's helpful to me for working dm. I think that i can help you for 
>>> checking on mmc side with DM.
>>
>> OK I see, thanks.
>>
>> Reviewed-by: Simon Glass 
>>
>
> This patch has been delegated to me, but cannot apply to u-boot-samsung.
> should go to dm tree?

Yes, it depends on dm/next. I'll assign those to patches to myself.

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


[U-Boot] BayTrail PCIe x4 slot (Soft-Strap?)

2016-07-07 Thread Stefan Roese
Hi!

I do have BayTrail / FSP related question. I'm currently trying
to use a DFI QSeven SoM which has one x4 PCIe slot instead
of the usual 4 x1 slots. So all 4 PCIe lanes are used by the
first PCIe controller. With the current U-Boot, all 4 PCIe
controllers are enabled by the FSP :

00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express 
Root Port 1 (rev 11)
00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express 
Root Port 2 (rev 11)
00:1c.2 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express 
Root Port 3 (rev 11)
00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express 
Root Port 4 (rev 11)

In this configuration, the x4 PCIe card that is installed in the
PCIe slot is not detected. The system always generated hotplug
events for all for ports, but the link is not established.

The original DFI BIOS only enables the first PCIe controller. The
controllers 1...3 are not visible via lspci. Here the 4x link
is established and the 4x PCIe card is detected correctly.

My question now is, how can I enable this 4x link on the first
PCIe controller via U-Boot / FSP? I have found no option on how
to configure the PCIe controllers in the FSP dts properties.
So that only the first controller is enabled and visible via
lspci etc. The BayTrail datasheet mentions this to configure the
PCIe setup in chapter "23.2.1 Root Port Configurations":

"
Root port configurations are set by SoftStraps stored in SPI flash,
and the default option is “(4) x1”. Links for each root port will
train automatically to the maximum possible for each port.
"

Where is this SoftStraps in the SPI flash located? I've found this
page mentioning that its a offset 0x100:

https://embedded.communities.intel.com/thread/8539

But I fail to find any documentation for all those Soft-Strap
Registers / Values in the SPI flash. Does anyone have some further
infos / documentation on this? How to enable 4x PCIe lanes
for one PCIe controller on BayTrail / Atom?

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


Re: [U-Boot] [PULL] u-boot-usb/master

2016-07-07 Thread Marek Vasut

Hi Tom,

I added one more patch by York to fix the powerpc mess. Updated PR 
below, please pull for 2016.07 .


Thanks!

The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:

   Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)

are available in the git repository at:

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

for you to fetch changes up to eb364c3dc28d59d33e823470d07746b22a8e6fee:

   powerpc: mpc85xx: kmp204x: Fix compiling error for usb errata 
(2016-07-07 13:34:10 +0200)



Hans de Goede (2):
   usb: dm: Add a usb_for_each_root_dev() helper function
   usb: dm: Make "usb info" use usb_for_each_root_dev()

Marek Vasut (1):
   powerpc: mpc85xx: Do not build errata command in SPL

York Sun (1):
   powerpc: mpc85xx: kmp204x: Fix compiling error for usb errata

  arch/powerpc/cpu/mpc85xx/Makefile   |  2 ++
  cmd/usb.c   | 46 
++

  include/configs/km/kmp204x-common.h |  1 +
  3 files changed, 21 insertions(+), 28 deletions(-)

--
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 2/3] ARM: board: cm_fx6: fixup mtd partitions in the fdt

2016-07-07 Thread Christopher Spinrath
Hi Nikita,

On 07/07/2016 10:53 AM, Nikita Kiryanov wrote:
> On Wed, Jun 22, 2016 at 07:17:53PM +0300, Igor Grinberg wrote:
>> On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
>>> The cm-fx6 module has an on-board st,m25p compatible spi flash chip
>>> used for u-boot (binary & environment). Overwrite the partitions in
>>> the device tree by the partition table provided in the mtdparts
>>> environment variable, if it is set.
>>>
>>> This allows to specify a kernel independent partitioning in the
>>> environment and provides a convient way for the user to adapt the
>>> partition table.
>>>
>>> Signed-off-by: Christopher Spinrath 
>>> ---
>>>  board/compulab/cm_fx6/cm_fx6.c | 16 +++-
>>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
>>> index 712057a..81a7ae2 100644
>>> --- a/board/compulab/cm_fx6/cm_fx6.c
>>> +++ b/board/compulab/cm_fx6/cm_fx6.c
>>
>> [...]
>>
>>> +#ifdef CONFIG_FDT_FIXUP_PARTITIONS
>>> +struct node_info nodes[] = {
>>> +   { "st,m25p",MTD_DEV_TYPE_NOR,   },
>>
>> Nikita, is this enough for all flashes we assemble on cm-fx6?
> 
> Yes, CM-FX6 is using M25PX16 and SST25VF016B, both of which are
> supported by the m25p80.c driver. However, on the mainline branch
> I don't see "m25p" in the list of device ids, and IIRC the request
> is to favor "jedec,spi-nor" as compatible string over device specific
> ones.

Linux is going to use "st,m25p", "jedec,spi-nor" as compatible list
(currently queued for inclusion in v4.8:
https://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git/tree/arch/arm/boot/dts/imx6q-cm-fx6.dts?h=next/dt#n123
).

I have chosen "st,m25p" here to cover both the mainline and CompuLab's
device trees (I have seen some where "jedec,spi-nor" is not in the
list). However, if you prefer I will switch to "jedec,spi-nor"
(excluding some device trees) in v2.

Thanks,
Christopher

> 
>>
>>> +};
>>> +#endif
>>> +
>>
>> [...]
>>
>> -- 
>> Regards,
>> Igor.
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2016-07-07 Thread Alexander Graf

On 07/07/2016 02:46 PM, Ryan Harkin wrote:

On 7 July 2016 at 13:41, Alexander Graf  wrote:

On 07/07/2016 02:35 PM, Ryan Harkin wrote:

On 7 July 2016 at 13:30, Alexander Graf  wrote:

On 07/07/2016 02:16 PM, Ryan Harkin wrote:

On 7 July 2016 at 07:30, 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 

Unfortunately, this patch fails to boot for me.

On FVP Foundation models, I see this error before the model hangs:

[snip]
Starting kernel ...

resetting ...
[snip]

And I see the same output on AEMv8 Base models and Juno boards, only
they reset continuously rather than hang.

I think the problem is that I see this from ARM Trusted Firmware on
boot:

INFO:BL31: Preparing for EL3 exit to normal world

Looking at the patch, it appears to be changing everything to boot in
EL2.


That was the case before the patch (with the removal of the EL1 boot
thing)
already. Linux can't run in EL3, that's why it has to boot in EL2 (or
EL1,
but that really should be limited to VMs).


Pah!  I misread the patch, specifically this hunk (and the one before
it, I suppose):

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index e3c9832..59adab8 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -193,7 +193,6 @@ static void do_nonsec_virt_switch(void)
   {
   smp_kick_all_cpus();
   dcache_disable();/* flush cache before swtiching to EL2 */
-armv8_switch_to_el2();
   }
   #endif

That's a "-", not a "+" on the call to armv8_switch_to_el2().

Either way, all my platforms are dead with this patch.


Since you're running in software models, can you try to figure out where
exactly it breaks?

You assume that because I have a model that I have the ability to debug it ;-)

ARM's FVP Foundation model is publicly available and free to use.  So
if you want to give it a spin, it's there for the taking.


I thought the Foundation model doesn't support external debugging? I'd 
basically want to put a breakpoint at the point where the kernel exit 
print goes and then trace it from there :).


But since Alison wrote the patches, I'm sure he can do that too :).


Alex

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


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

2016-07-07 Thread Ryan Harkin
On 7 July 2016 at 13:41, Alexander Graf  wrote:
> On 07/07/2016 02:35 PM, Ryan Harkin wrote:
>>
>> On 7 July 2016 at 13:30, Alexander Graf  wrote:
>>>
>>> On 07/07/2016 02:16 PM, Ryan Harkin wrote:

 On 7 July 2016 at 07:30, 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 

 Unfortunately, this patch fails to boot for me.

 On FVP Foundation models, I see this error before the model hangs:

 [snip]
 Starting kernel ...

 resetting ...
 [snip]

 And I see the same output on AEMv8 Base models and Juno boards, only
 they reset continuously rather than hang.

 I think the problem is that I see this from ARM Trusted Firmware on
 boot:

 INFO:BL31: Preparing for EL3 exit to normal world

 Looking at the patch, it appears to be changing everything to boot in
 EL2.
>>>
>>>
>>> That was the case before the patch (with the removal of the EL1 boot
>>> thing)
>>> already. Linux can't run in EL3, that's why it has to boot in EL2 (or
>>> EL1,
>>> but that really should be limited to VMs).
>>>
>> Pah!  I misread the patch, specifically this hunk (and the one before
>> it, I suppose):
>>
>> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
>> index e3c9832..59adab8 100644
>> --- a/arch/arm/lib/bootm.c
>> +++ b/arch/arm/lib/bootm.c
>> @@ -193,7 +193,6 @@ static void do_nonsec_virt_switch(void)
>>   {
>>   smp_kick_all_cpus();
>>   dcache_disable();/* flush cache before swtiching to EL2 */
>> -armv8_switch_to_el2();
>>   }
>>   #endif
>>
>> That's a "-", not a "+" on the call to armv8_switch_to_el2().
>>
>> Either way, all my platforms are dead with this patch.
>
>
> Since you're running in software models, can you try to figure out where
> exactly it breaks?

You assume that because I have a model that I have the ability to debug it ;-)

ARM's FVP Foundation model is publicly available and free to use.  So
if you want to give it a spin, it's there for the taking.

> I'm slightly confused that it's resetting. The switch to
> EL2 shouldn't matter in your setup, because you're executing U-Boot in EL2
> already, since you're running ATF in EL3.
>
>
> Alex
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2016-07-07 Thread Alexander Graf

On 07/07/2016 02:35 PM, Ryan Harkin wrote:

On 7 July 2016 at 13:30, Alexander Graf  wrote:

On 07/07/2016 02:16 PM, Ryan Harkin wrote:

On 7 July 2016 at 07:30, 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 

Unfortunately, this patch fails to boot for me.

On FVP Foundation models, I see this error before the model hangs:

[snip]
Starting kernel ...

resetting ...
[snip]

And I see the same output on AEMv8 Base models and Juno boards, only
they reset continuously rather than hang.

I think the problem is that I see this from ARM Trusted Firmware on boot:

INFO:BL31: Preparing for EL3 exit to normal world

Looking at the patch, it appears to be changing everything to boot in EL2.


That was the case before the patch (with the removal of the EL1 boot thing)
already. Linux can't run in EL3, that's why it has to boot in EL2 (or EL1,
but that really should be limited to VMs).


Pah!  I misread the patch, specifically this hunk (and the one before
it, I suppose):

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index e3c9832..59adab8 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -193,7 +193,6 @@ static void do_nonsec_virt_switch(void)
  {
  smp_kick_all_cpus();
  dcache_disable();/* flush cache before swtiching to EL2 */
-armv8_switch_to_el2();
  }
  #endif

That's a "-", not a "+" on the call to armv8_switch_to_el2().

Either way, all my platforms are dead with this patch.


Since you're running in software models, can you try to figure out where 
exactly it breaks? I'm slightly confused that it's resetting. The switch 
to EL2 shouldn't matter in your setup, because you're executing U-Boot 
in EL2 already, since you're running ATF in EL3.



Alex

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


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

2016-07-07 Thread Ryan Harkin
On 7 July 2016 at 13:30, Alexander Graf  wrote:
> On 07/07/2016 02:16 PM, Ryan Harkin wrote:
>>
>> On 7 July 2016 at 07:30, 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 
>>
>> Unfortunately, this patch fails to boot for me.
>>
>> On FVP Foundation models, I see this error before the model hangs:
>>
>> [snip]
>> Starting kernel ...
>>
>> resetting ...
>> [snip]
>>
>> And I see the same output on AEMv8 Base models and Juno boards, only
>> they reset continuously rather than hang.
>>
>> I think the problem is that I see this from ARM Trusted Firmware on boot:
>>
>> INFO:BL31: Preparing for EL3 exit to normal world
>>
>> Looking at the patch, it appears to be changing everything to boot in EL2.
>
>
> That was the case before the patch (with the removal of the EL1 boot thing)
> already. Linux can't run in EL3, that's why it has to boot in EL2 (or EL1,
> but that really should be limited to VMs).
>

Pah!  I misread the patch, specifically this hunk (and the one before
it, I suppose):

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index e3c9832..59adab8 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -193,7 +193,6 @@ static void do_nonsec_virt_switch(void)
 {
 smp_kick_all_cpus();
 dcache_disable();/* flush cache before swtiching to EL2 */
-armv8_switch_to_el2();
 }
 #endif

That's a "-", not a "+" on the call to armv8_switch_to_el2().

Either way, all my platforms are dead with this patch.


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


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

2016-07-07 Thread Alexander Graf

On 07/07/2016 02:16 PM, Ryan Harkin wrote:

On 7 July 2016 at 07:30, 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 

Unfortunately, this patch fails to boot for me.

On FVP Foundation models, I see this error before the model hangs:

[snip]
Starting kernel ...

resetting ...
[snip]

And I see the same output on AEMv8 Base models and Juno boards, only
they reset continuously rather than hang.

I think the problem is that I see this from ARM Trusted Firmware on boot:

INFO:BL31: Preparing for EL3 exit to normal world

Looking at the patch, it appears to be changing everything to boot in EL2.


That was the case before the patch (with the removal of the EL1 boot 
thing) already. Linux can't run in EL3, that's why it has to boot in EL2 
(or EL1, but that really should be limited to VMs).



Alex

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


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

2016-07-07 Thread Ryan Harkin
On 7 July 2016 at 07:30, 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 

Unfortunately, this patch fails to boot for me.

On FVP Foundation models, I see this error before the model hangs:

[snip]
Starting kernel ...

resetting ...
[snip]

And I see the same output on AEMv8 Base models and Juno boards, only
they reset continuously rather than hang.

I think the problem is that I see this from ARM Trusted Firmware on boot:

INFO:BL31: Preparing for EL3 exit to normal world

Looking at the patch, it appears to be changing everything to boot in EL2.

The title of the patch is "armv8: Support loading 32-bit OS in AArch32
execution state", which implies it only makes changes to AArch32 code
execution paths, however, it is clearly changing AArch64 boot too, so
I'm not happy with the title or description of the patch either.

> ---
> Changes in v5:
> - Modified armv8_switch_to_el2(). It will always jump to ep when switching to 
> AArch64 or AArch32 modes.
>
> Changes in v4:
> - Correct config ARM64_SUPPORT_AARCH32.
> - Omit arch and ftaddr arguments.
> - Rename "xreg5" to "tmp".
> - Use xxx_RES1 to combine all RES1 fields in xxx register.
> - Use an immediate cmp directly.
> - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.
>
> Changes in v3:
> - Comments the functions and the arguments.
> - Rename the real parameters.
> - Use the macros instead of the magic values.
> - Remove the redundant codes.
> - Clean up all of the mess in boot_jump_linux().
> - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't 
> support AArch32 state.
>
> Changes in v2:
> - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used
>   to switch to AArch64 EL2 or AArch32 Hyp.
> - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used
>   to switch to AArch64 EL1 or AArch32 SVC.
>
>  arch/arm/Kconfig|   6 +++
>  arch/arm/cpu/armv8/start.S  |   2 +
>  arch/arm/cpu/armv8/transition.S |   4 +-
>  arch/arm/include/asm/macro.h|  80 ---
>  arch/arm/include/asm/system.h   | 104 
> +++-
>  arch/arm/lib/bootm.c|  13 -
>  common/image-fit.c  |  19 +++-
>  7 files changed, 206 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 3237a74..1b30447 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -99,6 +99,12 @@ config ENABLE_ARM_SOC_BOOT0_HOOK
>   ARM_SOC_BOOT0_HOOK which contains the required assembler
>   preprocessor code.
>
> +config ARM64_SUPPORT_AARCH32
> +   bool "ARM64 system support AArch32 execution state"
> +   default y if ARM64 && !TARGET_THUNDERX_88XX
> +   help
> + This ARM64 system supports AArch32 execution state.
> +
>  choice
> prompt "Target select"
> default TARGET_HIKEY
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index ab434a6..a0c55d7 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -244,6 +244,8 @@ WEAK(lowlevel_init)
> /*
>  * All slaves will enter EL2.
>  */
> +   mov x3, lr
> +   ldr x4, =ES_TO_AARCH64
> bl  armv8_switch_to_el2
>
>  #endif /* CONFIG_ARMV8_MULTIENTRY */
> diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S
> index 209d5c8..62d54b3 100644
> --- a/arch/arm/cpu/armv8/transition.S
> +++ b/arch/arm/cpu/armv8/transition.S
> @@ -11,7 +11,7 @@
>  #include 
>
>  ENTRY(armv8_switch_to_el2)
> -   switch_el x0, 1f, 0f, 0f
> +   switch_el x5, 1f, 0f, 0f
>  0: ret
> -1: armv8_switch_to_el2_m x0
> +1: armv8_switch_to_el2_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el2)
> diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
> index c1b3452..5108900 100644
> --- a/arch/arm/include/asm/macro.h
> +++ b/arch/arm/include/asm/macro.h
> @@ -8,6 +8,9 @@
>
>  #ifndef __ASM_ARM_MACRO_H__
>  #define __ASM_ARM_MACRO_H__
> +
> +#include 
> +
>  #ifdef __ASSEMBLY__
>
>  /*
> @@ -135,13 +138,21 @@ lr.reqx30
>  #endif
>  .endm
>
> -.macro armv8_switch_to_el2_m, xreg1
> -   /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 */
> -   mov \xreg1, #0x5b1
> -   msr scr_el3, \xreg1
> +/*
> + * Switch from EL3 to EL2 for ARMv8
> + * @ep: kernel entry point
> + * @flag:   The execution state flag for lower exception
> + *  level, ES_TO_AARCH64 or ES_TO_AARCH32
> + * @tmp:temporary register
> + *
> + * For loading 32-bit OS, x1 is machine nr and x2 is 

Re: [U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel

2016-07-07 Thread Alexander Graf

On 07/07/2016 08:25 AM, Alison Wang wrote:

As CONFIG_ARMV8_SWITCH_TO_EL1 is not used now, this patch is to remove
CONFIG_ARMV8_SWITCH_TO_EL1 and the corresponding functions.

Signed-off-by: Alison Wang 


I'll CC the maintainers for ZynqMP and Exynos as well, but from my side 
this patch is a great step forward.


Reviewed-by: Alexander Graf 


---
  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 13 
  arch/arm/cpu/armv8/start.S   |  5 +--
  arch/arm/cpu/armv8/transition.S  |  6 
  arch/arm/include/asm/macro.h | 47 
  arch/arm/include/asm/system.h|  1 -
  arch/arm/lib/bootm.c |  3 --
  arch/arm/mach-exynos/soc.c   |  1 -
  include/configs/vexpress_aemv8a.h|  1 -
  include/configs/xilinx_zynqmp.h  |  2 --
  9 files changed, 1 insertion(+), 78 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 5af6b73..d3a0117 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -325,19 +325,12 @@ ENTRY(secondary_boot_func)
  #endif
  
  	bl secondary_switch_to_el2

-#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-   bl secondary_switch_to_el1
-#endif
  
  slave_cpu:

wfe
ldr x0, [x11]
cbz x0, slave_cpu
-#ifndef CONFIG_ARMV8_SWITCH_TO_EL1
mrs x1, sctlr_el2
-#else
-   mrs x1, sctlr_el1
-#endif
tbz x1, #25, cpu_is_le
rev x0, x0  /* BE to LE conversion */
  cpu_is_le:
@@ -350,12 +343,6 @@ ENTRY(secondary_switch_to_el2)
  1:armv8_switch_to_el2_m x0
  ENDPROC(secondary_switch_to_el2)
  
-ENTRY(secondary_switch_to_el1)

-   switch_el x0, 0f, 1f, 0f
-0: ret
-1: armv8_switch_to_el1_m x0, x1
-ENDPROC(secondary_switch_to_el1)
-
/* Ensure that the literals used by the secondary boot code are
 * assembled within it (this is required so that we can protect
 * this area with a single memreserve region
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 670e323..ab434a6 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -242,12 +242,9 @@ WEAK(lowlevel_init)
  #endif
  
  	/*

-* All slaves will enter EL2 and optionally EL1.
+* All slaves will enter EL2.
 */
bl  armv8_switch_to_el2
-#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-   bl  armv8_switch_to_el1
-#endif
  
  #endif /* CONFIG_ARMV8_MULTIENTRY */
  
diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S

index 253a39b..209d5c8 100644
--- a/arch/arm/cpu/armv8/transition.S
+++ b/arch/arm/cpu/armv8/transition.S
@@ -15,9 +15,3 @@ ENTRY(armv8_switch_to_el2)
  0:ret
  1:armv8_switch_to_el2_m x0
  ENDPROC(armv8_switch_to_el2)
-
-ENTRY(armv8_switch_to_el1)
-   switch_el x0, 0f, 1f, 0f
-0: ret
-1: armv8_switch_to_el1_m x0, x1
-ENDPROC(armv8_switch_to_el1)
diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
index 9bb0efa..c1b3452 100644
--- a/arch/arm/include/asm/macro.h
+++ b/arch/arm/include/asm/macro.h
@@ -167,53 +167,6 @@ lr .reqx30
eret
  .endm
  
-.macro armv8_switch_to_el1_m, xreg1, xreg2

-   /* Initialize Generic Timers */
-   mrs \xreg1, cnthctl_el2
-   orr \xreg1, \xreg1, #0x3/* Enable EL1 access to timers */
-   msr cnthctl_el2, \xreg1
-   msr cntvoff_el2, xzr
-
-   /* Initilize MPID/MPIDR registers */
-   mrs \xreg1, midr_el1
-   mrs \xreg2, mpidr_el1
-   msr vpidr_el2, \xreg1
-   msr vmpidr_el2, \xreg2
-
-   /* Disable coprocessor traps */
-   mov \xreg1, #0x33ff
-   msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */
-   msr hstr_el2, xzr   /* Disable coprocessor traps to EL2 */
-   mov \xreg1, #3 << 20
-   msr cpacr_el1, \xreg1   /* Enable FP/SIMD at EL1 */
-
-   /* Initialize HCR_EL2 */
-   mov \xreg1, #(1 << 31)/* 64bit EL1 */
-   orr \xreg1, \xreg1, #(1 << 29)/* Disable HVC */
-   msr hcr_el2, \xreg1
-
-   /* SCTLR_EL1 initialization
-*
-* setting RES1 bits (29,28,23,22,20,11) to 1
-* and RES0 bits (31,30,27,21,17,13,10,6) +
-* UCI,EE,EOE,WXN,nTWE,nTWI,UCT,DZE,I,UMA,SED,ITD,
-* CP15BEN,SA0,SA,C,A,M to 0
-*/
-   mov \xreg1, #0x0800
-   movk\xreg1, #0x30d0, lsl #16
-   msr sctlr_el1, \xreg1
-
-   /* Return to the EL1_SP1 mode from EL2 */
-   mov \xreg1, sp
-   msr sp_el1, \xreg1  /* Migrate SP */
-   mrs \xreg1, vbar_el2
-   msr vbar_el1, \xreg1/* Migrate VBAR */
-   mov \xreg1, #0x3c5
-   msr spsr_el2, \xreg1/* EL1_SP1 | D | 

Re: [U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel

2016-07-07 Thread Ryan Harkin
On 7 July 2016 at 07:25, Alison Wang  wrote:
> As CONFIG_ARMV8_SWITCH_TO_EL1 is not used now, this patch is to remove
> CONFIG_ARMV8_SWITCH_TO_EL1 and the corresponding functions.
>
> Signed-off-by: Alison Wang 

I haven't reviewed the code changes, but I have tested it and
everything still works for me with this change.

I tested on FVP AEMv8 Base and FVP Foundation models and Juno R0, R1
and R2 development boards; booting BusyBox, OpenEmbedded (not on R0 or
R2) and Android environments (not on R1).

Tested-by: Ryan Harkin 

> ---
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 13 
>  arch/arm/cpu/armv8/start.S   |  5 +--
>  arch/arm/cpu/armv8/transition.S  |  6 
>  arch/arm/include/asm/macro.h | 47 
> 
>  arch/arm/include/asm/system.h|  1 -
>  arch/arm/lib/bootm.c |  3 --
>  arch/arm/mach-exynos/soc.c   |  1 -
>  include/configs/vexpress_aemv8a.h|  1 -
>  include/configs/xilinx_zynqmp.h  |  2 --
>  9 files changed, 1 insertion(+), 78 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
> b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> index 5af6b73..d3a0117 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> @@ -325,19 +325,12 @@ ENTRY(secondary_boot_func)
>  #endif
>
> bl secondary_switch_to_el2
> -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> -   bl secondary_switch_to_el1
> -#endif
>
>  slave_cpu:
> wfe
> ldr x0, [x11]
> cbz x0, slave_cpu
> -#ifndef CONFIG_ARMV8_SWITCH_TO_EL1
> mrs x1, sctlr_el2
> -#else
> -   mrs x1, sctlr_el1
> -#endif
> tbz x1, #25, cpu_is_le
> rev x0, x0  /* BE to LE conversion */
>  cpu_is_le:
> @@ -350,12 +343,6 @@ ENTRY(secondary_switch_to_el2)
>  1: armv8_switch_to_el2_m x0
>  ENDPROC(secondary_switch_to_el2)
>
> -ENTRY(secondary_switch_to_el1)
> -   switch_el x0, 0f, 1f, 0f
> -0: ret
> -1: armv8_switch_to_el1_m x0, x1
> -ENDPROC(secondary_switch_to_el1)
> -
> /* Ensure that the literals used by the secondary boot code are
>  * assembled within it (this is required so that we can protect
>  * this area with a single memreserve region
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index 670e323..ab434a6 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -242,12 +242,9 @@ WEAK(lowlevel_init)
>  #endif
>
> /*
> -* All slaves will enter EL2 and optionally EL1.
> +* All slaves will enter EL2.
>  */
> bl  armv8_switch_to_el2
> -#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
> -   bl  armv8_switch_to_el1
> -#endif
>
>  #endif /* CONFIG_ARMV8_MULTIENTRY */
>
> diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S
> index 253a39b..209d5c8 100644
> --- a/arch/arm/cpu/armv8/transition.S
> +++ b/arch/arm/cpu/armv8/transition.S
> @@ -15,9 +15,3 @@ ENTRY(armv8_switch_to_el2)
>  0: ret
>  1: armv8_switch_to_el2_m x0
>  ENDPROC(armv8_switch_to_el2)
> -
> -ENTRY(armv8_switch_to_el1)
> -   switch_el x0, 0f, 1f, 0f
> -0: ret
> -1: armv8_switch_to_el1_m x0, x1
> -ENDPROC(armv8_switch_to_el1)
> diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
> index 9bb0efa..c1b3452 100644
> --- a/arch/arm/include/asm/macro.h
> +++ b/arch/arm/include/asm/macro.h
> @@ -167,53 +167,6 @@ lr .reqx30
> eret
>  .endm
>
> -.macro armv8_switch_to_el1_m, xreg1, xreg2
> -   /* Initialize Generic Timers */
> -   mrs \xreg1, cnthctl_el2
> -   orr \xreg1, \xreg1, #0x3/* Enable EL1 access to timers */
> -   msr cnthctl_el2, \xreg1
> -   msr cntvoff_el2, xzr
> -
> -   /* Initilize MPID/MPIDR registers */
> -   mrs \xreg1, midr_el1
> -   mrs \xreg2, mpidr_el1
> -   msr vpidr_el2, \xreg1
> -   msr vmpidr_el2, \xreg2
> -
> -   /* Disable coprocessor traps */
> -   mov \xreg1, #0x33ff
> -   msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */
> -   msr hstr_el2, xzr   /* Disable coprocessor traps to EL2 */
> -   mov \xreg1, #3 << 20
> -   msr cpacr_el1, \xreg1   /* Enable FP/SIMD at EL1 */
> -
> -   /* Initialize HCR_EL2 */
> -   mov \xreg1, #(1 << 31)  /* 64bit EL1 */
> -   orr \xreg1, \xreg1, #(1 << 29)  /* Disable HVC */
> -   msr hcr_el2, \xreg1
> -
> -   /* SCTLR_EL1 initialization
> -*
> -* setting RES1 bits (29,28,23,22,20,11) to 1
> -* and RES0 bits (31,30,27,21,17,13,10,6) +
> -* UCI,EE,EOE,WXN,nTWE,nTWI,UCT,DZE,I,UMA,SED,ITD,
> -* CP15BEN,SA0,SA,C,A,M to 0
> -*/
> 

Re: [U-Boot] [PATCH 2/3] ARM: board: cm_fx6: fixup mtd partitions in the fdt

2016-07-07 Thread Nikita Kiryanov
On Wed, Jun 22, 2016 at 07:17:53PM +0300, Igor Grinberg wrote:
> On 06/19/2016 06:44 PM, Christopher Spinrath wrote:
> > The cm-fx6 module has an on-board st,m25p compatible spi flash chip
> > used for u-boot (binary & environment). Overwrite the partitions in
> > the device tree by the partition table provided in the mtdparts
> > environment variable, if it is set.
> > 
> > This allows to specify a kernel independent partitioning in the
> > environment and provides a convient way for the user to adapt the
> > partition table.
> > 
> > Signed-off-by: Christopher Spinrath 
> > ---
> >  board/compulab/cm_fx6/cm_fx6.c | 16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
> > index 712057a..81a7ae2 100644
> > --- a/board/compulab/cm_fx6/cm_fx6.c
> > +++ b/board/compulab/cm_fx6/cm_fx6.c
> 
> [...]
> 
> > +#ifdef CONFIG_FDT_FIXUP_PARTITIONS
> > +struct node_info nodes[] = {
> > +   { "st,m25p",MTD_DEV_TYPE_NOR,   },
> 
> Nikita, is this enough for all flashes we assemble on cm-fx6?

Yes, CM-FX6 is using M25PX16 and SST25VF016B, both of which are
supported by the m25p80.c driver. However, on the mainline branch
I don't see "m25p" in the list of device ids, and IIRC the request
is to favor "jedec,spi-nor" as compatible string over device specific
ones.


> 
> > +};
> > +#endif
> > +
> 
> [...]
> 
> -- 
> Regards,
> Igor.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] ARM: configs: cm_fx6: improve default environment

2016-07-07 Thread Nikita Kiryanov
On Sun, Jun 19, 2016 at 05:44:54PM +0200, Christopher Spinrath wrote:
> Currently, entire script segments have to be changed in the default
> environment to change the kernel image location or to append kernel
> cmdline parameters. In the later case this has to be changed for
> every possible boot device.
> 
> Introduce new variables for kernel image locations and boot device
> independent kernel parameters to make it easier to change these
> settings.

Reviewed-by: Nikita Kiryanov 

> 
> Signed-off-by: Christopher Spinrath 
> ---
>  include/configs/cm_fx6.h | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Building efi_boottime.o fails for OpenRD (kirkwood) targets

2016-07-07 Thread Alexander Graf


On 06.07.16 23:16, Karsten Merker wrote:
> Hello,
> 
> current u-boot master shows problems when building efi_boottime.o
> for the openrd_base, openrd_client and openrd_ultimate targets
> (all based on Marvell "Kirkwood" SoCs).  This was discovered
> during builds of the (experimental) Debian u-boot 2016.07-rc3
> package, but exactly the same problem occurs with plain upstream. 
> Running "make openrd_base_defconfig; make" results in the
> following error:
> 
>   CC  lib/efi_loader/efi_image_loader.o
>   CC  lib/efi_loader/efi_boottime.o
> {standard input}: Assembler messages:
> {standard input}:1672: Error: invalid immediate for address calculation
> (value = 0x000A)
> make[2]: *** [lib/efi_loader/efi_boottime.o] Error 1
> scripts/Makefile.build:280: recipe for target 'lib/efi_loader/efi_boottime.o' 
> failed
> make[1]: *** [lib/efi_loader] Error 2
> scripts/Makefile.build:425: recipe for target 'lib/efi_loader' failed
> make: *** [lib] Error 2
> Makefile:1210: recipe for target 'lib' failed
> 
> The same happens when building the openrd_client and
> openrd_ultimate targets.

Thanks for the report. Tom pointed me to it yesterday as well and I
submitted a fix:

  https://patchwork.ozlabs.org/patch/644968/

Please just apply it and things should work for you.


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


[U-Boot] [PATCH] armv8: Remove the codes about switching to EL1 before jumping to kernel

2016-07-07 Thread Alison Wang
As CONFIG_ARMV8_SWITCH_TO_EL1 is not used now, this patch is to remove
CONFIG_ARMV8_SWITCH_TO_EL1 and the corresponding functions.

Signed-off-by: Alison Wang 
---
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 13 
 arch/arm/cpu/armv8/start.S   |  5 +--
 arch/arm/cpu/armv8/transition.S  |  6 
 arch/arm/include/asm/macro.h | 47 
 arch/arm/include/asm/system.h|  1 -
 arch/arm/lib/bootm.c |  3 --
 arch/arm/mach-exynos/soc.c   |  1 -
 include/configs/vexpress_aemv8a.h|  1 -
 include/configs/xilinx_zynqmp.h  |  2 --
 9 files changed, 1 insertion(+), 78 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 5af6b73..d3a0117 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -325,19 +325,12 @@ ENTRY(secondary_boot_func)
 #endif
 
bl secondary_switch_to_el2
-#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-   bl secondary_switch_to_el1
-#endif
 
 slave_cpu:
wfe
ldr x0, [x11]
cbz x0, slave_cpu
-#ifndef CONFIG_ARMV8_SWITCH_TO_EL1
mrs x1, sctlr_el2
-#else
-   mrs x1, sctlr_el1
-#endif
tbz x1, #25, cpu_is_le
rev x0, x0  /* BE to LE conversion */
 cpu_is_le:
@@ -350,12 +343,6 @@ ENTRY(secondary_switch_to_el2)
 1: armv8_switch_to_el2_m x0
 ENDPROC(secondary_switch_to_el2)
 
-ENTRY(secondary_switch_to_el1)
-   switch_el x0, 0f, 1f, 0f
-0: ret
-1: armv8_switch_to_el1_m x0, x1
-ENDPROC(secondary_switch_to_el1)
-
/* Ensure that the literals used by the secondary boot code are
 * assembled within it (this is required so that we can protect
 * this area with a single memreserve region
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index 670e323..ab434a6 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -242,12 +242,9 @@ WEAK(lowlevel_init)
 #endif
 
/*
-* All slaves will enter EL2 and optionally EL1.
+* All slaves will enter EL2.
 */
bl  armv8_switch_to_el2
-#ifdef CONFIG_ARMV8_SWITCH_TO_EL1
-   bl  armv8_switch_to_el1
-#endif
 
 #endif /* CONFIG_ARMV8_MULTIENTRY */
 
diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S
index 253a39b..209d5c8 100644
--- a/arch/arm/cpu/armv8/transition.S
+++ b/arch/arm/cpu/armv8/transition.S
@@ -15,9 +15,3 @@ ENTRY(armv8_switch_to_el2)
 0: ret
 1: armv8_switch_to_el2_m x0
 ENDPROC(armv8_switch_to_el2)
-
-ENTRY(armv8_switch_to_el1)
-   switch_el x0, 0f, 1f, 0f
-0: ret
-1: armv8_switch_to_el1_m x0, x1
-ENDPROC(armv8_switch_to_el1)
diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
index 9bb0efa..c1b3452 100644
--- a/arch/arm/include/asm/macro.h
+++ b/arch/arm/include/asm/macro.h
@@ -167,53 +167,6 @@ lr .reqx30
eret
 .endm
 
-.macro armv8_switch_to_el1_m, xreg1, xreg2
-   /* Initialize Generic Timers */
-   mrs \xreg1, cnthctl_el2
-   orr \xreg1, \xreg1, #0x3/* Enable EL1 access to timers */
-   msr cnthctl_el2, \xreg1
-   msr cntvoff_el2, xzr
-
-   /* Initilize MPID/MPIDR registers */
-   mrs \xreg1, midr_el1
-   mrs \xreg2, mpidr_el1
-   msr vpidr_el2, \xreg1
-   msr vmpidr_el2, \xreg2
-
-   /* Disable coprocessor traps */
-   mov \xreg1, #0x33ff
-   msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */
-   msr hstr_el2, xzr   /* Disable coprocessor traps to EL2 */
-   mov \xreg1, #3 << 20
-   msr cpacr_el1, \xreg1   /* Enable FP/SIMD at EL1 */
-
-   /* Initialize HCR_EL2 */
-   mov \xreg1, #(1 << 31)  /* 64bit EL1 */
-   orr \xreg1, \xreg1, #(1 << 29)  /* Disable HVC */
-   msr hcr_el2, \xreg1
-
-   /* SCTLR_EL1 initialization
-*
-* setting RES1 bits (29,28,23,22,20,11) to 1
-* and RES0 bits (31,30,27,21,17,13,10,6) +
-* UCI,EE,EOE,WXN,nTWE,nTWI,UCT,DZE,I,UMA,SED,ITD,
-* CP15BEN,SA0,SA,C,A,M to 0
-*/
-   mov \xreg1, #0x0800
-   movk\xreg1, #0x30d0, lsl #16
-   msr sctlr_el1, \xreg1
-
-   /* Return to the EL1_SP1 mode from EL2 */
-   mov \xreg1, sp
-   msr sp_el1, \xreg1  /* Migrate SP */
-   mrs \xreg1, vbar_el2
-   msr vbar_el1, \xreg1/* Migrate VBAR */
-   mov \xreg1, #0x3c5
-   msr spsr_el2, \xreg1/* EL1_SP1 | D | A | I | F */
-   msr elr_el2, lr
-   eret
-.endm
-
 #if defined(CONFIG_GICV3)
 .macro gic_wait_for_interrupt_m xreg1
 0 :wfi
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 

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

2016-07-07 Thread Alison Wang
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 
---
Changes in v5:
- Modified armv8_switch_to_el2(). It will always jump to ep when switching to 
AArch64 or AArch32 modes.

Changes in v4:
- Correct config ARM64_SUPPORT_AARCH32.
- Omit arch and ftaddr arguments.
- Rename "xreg5" to "tmp".
- Use xxx_RES1 to combine all RES1 fields in xxx register.
- Use an immediate cmp directly.
- Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.

Changes in v3:
- Comments the functions and the arguments.
- Rename the real parameters.
- Use the macros instead of the magic values.
- Remove the redundant codes.
- Clean up all of the mess in boot_jump_linux().
- Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't 
support AArch32 state.

Changes in v2:
- armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used
  to switch to AArch64 EL2 or AArch32 Hyp.
- armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used
  to switch to AArch64 EL1 or AArch32 SVC.

 arch/arm/Kconfig|   6 +++
 arch/arm/cpu/armv8/start.S  |   2 +
 arch/arm/cpu/armv8/transition.S |   4 +-
 arch/arm/include/asm/macro.h|  80 ---
 arch/arm/include/asm/system.h   | 104 +++-
 arch/arm/lib/bootm.c|  13 -
 common/image-fit.c  |  19 +++-
 7 files changed, 206 insertions(+), 22 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3237a74..1b30447 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -99,6 +99,12 @@ config ENABLE_ARM_SOC_BOOT0_HOOK
  ARM_SOC_BOOT0_HOOK which contains the required assembler
  preprocessor code.
 
+config ARM64_SUPPORT_AARCH32
+   bool "ARM64 system support AArch32 execution state"
+   default y if ARM64 && !TARGET_THUNDERX_88XX
+   help
+ This ARM64 system supports AArch32 execution state.
+
 choice
prompt "Target select"
default TARGET_HIKEY
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index ab434a6..a0c55d7 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -244,6 +244,8 @@ WEAK(lowlevel_init)
/*
 * All slaves will enter EL2.
 */
+   mov x3, lr
+   ldr x4, =ES_TO_AARCH64
bl  armv8_switch_to_el2
 
 #endif /* CONFIG_ARMV8_MULTIENTRY */
diff --git a/arch/arm/cpu/armv8/transition.S b/arch/arm/cpu/armv8/transition.S
index 209d5c8..62d54b3 100644
--- a/arch/arm/cpu/armv8/transition.S
+++ b/arch/arm/cpu/armv8/transition.S
@@ -11,7 +11,7 @@
 #include 
 
 ENTRY(armv8_switch_to_el2)
-   switch_el x0, 1f, 0f, 0f
+   switch_el x5, 1f, 0f, 0f
 0: ret
-1: armv8_switch_to_el2_m x0
+1: armv8_switch_to_el2_m x3, x4, x5
 ENDPROC(armv8_switch_to_el2)
diff --git a/arch/arm/include/asm/macro.h b/arch/arm/include/asm/macro.h
index c1b3452..5108900 100644
--- a/arch/arm/include/asm/macro.h
+++ b/arch/arm/include/asm/macro.h
@@ -8,6 +8,9 @@
 
 #ifndef __ASM_ARM_MACRO_H__
 #define __ASM_ARM_MACRO_H__
+
+#include 
+
 #ifdef __ASSEMBLY__
 
 /*
@@ -135,13 +138,21 @@ lr.reqx30
 #endif
 .endm
 
-.macro armv8_switch_to_el2_m, xreg1
-   /* 64bit EL2 | HCE | SMD | RES1 (Bits[5:4]) | Non-secure EL0/EL1 */
-   mov \xreg1, #0x5b1
-   msr scr_el3, \xreg1
+/*
+ * Switch from EL3 to EL2 for ARMv8
+ * @ep: kernel entry point
+ * @flag:   The execution state flag for lower exception
+ *  level, ES_TO_AARCH64 or ES_TO_AARCH32
+ * @tmp:temporary register
+ *
+ * For loading 32-bit OS, x1 is machine nr and x2 is ftaddr.
+ * For loading 64-bit OS, x0 is physical address to the FDT blob.
+ * They will be passed to the guest.
+ */
+.macro armv8_switch_to_el2_m, ep, flag, tmp
msr cptr_el3, xzr   /* Disable coprocessor traps to EL3 */
-   mov \xreg1, #0x33ff
-   msr cptr_el2, \xreg1/* Disable coprocessor traps to EL2 */
+   mov \tmp, #CPTR_EL2_RES1
+   msr cptr_el2, \tmp  /* Disable coprocessor traps to EL2 */
 
/* Initialize Generic Timers */
msr cntvoff_el2, xzr
@@ -152,18 +163,55 @@ lr.reqx30
 * and RES0 bits (31,30,27,26,24,21,20,17,15-13,10-6) +
 * EE,WXN,I,SA,C,A,M to 0
 */
-   mov \xreg1, #0x0830
-   movk\xreg1, #0x30C5, lsl #16
-   msr sctlr_el2, \xreg1
+   ldr \tmp, =(SCTLR_EL2_RES1 | SCTLR_EL2_EE_LE |\
+   SCTLR_EL2_WXN_DIS | SCTLR_EL2_ICACHE_DIS |\
+   SCTLR_EL2_SA_DIS | SCTLR_EL2_DCACHE_DIS |\
+   SCTLR_EL2_ALIGN_DIS | 

[U-Boot] [PATCH v5 2/2] armv8: fsl-layerscape: SMP support for loading 32-bit OS

2016-07-07 Thread Alison Wang
Spin-table method is used for secondary cores to load 32-bit OS. The
architecture information will be got through checking FIT image and
saved in the os_arch element of spin-table, then the secondary cores
will check os_arch and jump to 32-bit OS or 64-bit OS automatically.

Signed-off-by: Alison Wang 
Signed-off-by: Chenhui Zhao 
---
Changes in v5:
- Make secondary_switch_to_el2() always jump to ep when switching to AArch64 or 
AArch32 modes.

Changes in v4:
- Omit arch and ftaddr arguments.

Changes in v3:
- Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m. 

Changes in v2:
- Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m.

 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S  | 23 ++-
 arch/arm/cpu/armv8/fsl-layerscape/mp.c| 10 ++
 arch/arm/include/asm/arch-fsl-layerscape/mp.h |  6 ++
 arch/arm/lib/bootm.c  |  6 ++
 4 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index d3a0117..9535350 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -13,6 +13,8 @@
 #ifdef CONFIG_MP
 #include 
 #endif
+#include 
+#include 
 
 ENTRY(lowlevel_init)
mov x29, lr /* Save LR */
@@ -324,8 +326,6 @@ ENTRY(secondary_boot_func)
 gic_wait_for_interrupt_m x0, w1
 #endif
 
-   bl secondary_switch_to_el2
-
 slave_cpu:
wfe
ldr x0, [x11]
@@ -334,13 +334,26 @@ slave_cpu:
tbz x1, #25, cpu_is_le
rev x0, x0  /* BE to LE conversion */
 cpu_is_le:
-   br  x0  /* branch to the given address */
+
+   ldr x5, [x11, #24]
+   ldr x6, =IH_ARCH_DEFAULT
+   cmp x6, x5
+   b.eq1f
+
+   ldr x3, [x11]
+   ldr x4, =ES_TO_AARCH32
+   bl  secondary_switch_to_el2
+
+1:
+   ldr x3, [x11]
+   ldr x4, =ES_TO_AARCH64
+   bl  secondary_switch_to_el2
 ENDPROC(secondary_boot_func)
 
 ENTRY(secondary_switch_to_el2)
-   switch_el x0, 1f, 0f, 0f
+   switch_el x5, 1f, 0f, 0f
 0: ret
-1: armv8_switch_to_el2_m x0
+1: armv8_switch_to_el2_m x3, x4, x5
 ENDPROC(secondary_switch_to_el2)
 
/* Ensure that the literals used by the secondary boot code are
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/mp.c 
b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
index df7ffb8..dd91550 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/mp.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/mp.c
@@ -22,6 +22,16 @@ phys_addr_t determine_mp_bootpg(void)
return (phys_addr_t)_boot_code;
 }
 
+void update_os_arch_secondary_cores(uint8_t os_arch)
+{
+   u64 *table = get_spin_tbl_addr();
+   int i;
+
+   for (i = 1; i < CONFIG_MAX_CPUS; i++)
+   table[i * WORDS_PER_SPIN_TABLE_ENTRY +
+   SPIN_TABLE_ELEM_OS_ARCH_IDX] = os_arch;
+}
+
 int fsl_layerscape_wake_seconday_cores(void)
 {
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/mp.h 
b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
index e46e076..55f0e0c 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/mp.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/mp.h
@@ -13,6 +13,7 @@
 *  uint64_t entry_addr;
 *  uint64_t status;
 *  uint64_t lpid;
+*  uint64_t os_arch;
 * };
 * we pad this struct to 64 bytes so each entry is in its own cacheline
 * the actual spin table is an array of these structures
@@ -20,6 +21,7 @@
 #define SPIN_TABLE_ELEM_ENTRY_ADDR_IDX 0
 #define SPIN_TABLE_ELEM_STATUS_IDX 1
 #define SPIN_TABLE_ELEM_LPID_IDX   2
+#define SPIN_TABLE_ELEM_OS_ARCH_IDX3
 #define WORDS_PER_SPIN_TABLE_ENTRY 8   /* pad to 64 bytes */
 #define SPIN_TABLE_ELEM_SIZE   64
 
@@ -35,4 +37,8 @@ phys_addr_t determine_mp_bootpg(void);
 void secondary_boot_func(void);
 int is_core_online(u64 cpu_id);
 #endif
+
+#define IH_ARCH_ARM2   /* ARM */
+#define IH_ARCH_ARM64  22  /* ARM64 */
+
 #endif /* _FSL_LAYERSCAPE_MP_H */
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 59adab8..56052c1 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -264,6 +264,10 @@ bool armv7_boot_nonsec(void)
 }
 #endif
 
+__weak void update_os_arch_secondary_cores(uint8_t os_arch)
+{
+}
+
 /* Subcommand: GO */
 static void boot_jump_linux(bootm_headers_t *images, int flag)
 {
@@ -284,6 +288,8 @@ static void boot_jump_linux(bootm_headers_t *images, int 
flag)
if (!fake) {
do_nonsec_virt_switch();
 
+   update_os_arch_secondary_cores(images->os.arch);
+
if ((IH_ARCH_DEFAULT == IH_ARCH_ARM64) &&
(images->os.arch == IH_ARCH_ARM))

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

2016-07-07 Thread Alison Wang
This series is 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.

Spin-table method is used for secondary cores to load 32-bit OS. The 
architecture
information will be got through checking FIT image and saved in the os_arch 
element
of spin-table, then the secondary cores will check os_arch and jump to 32-bit 
OS or
64-bit OS automatically.

---
Changes in v5:
- Modified armv8_switch_to_el2(). It will always jump to ep when switching to 
AArch64 or AArch32 modes.
- Make secondary_switch_to_el2() always jump to ep when switching to AArch64 or 
AArch32 modes.

Changes in v4:
- Correct config ARM64_SUPPORT_AARCH32.
- Omit arch and ftaddr arguments.
- Rename "xreg5" to "tmp".
- Use xxx_RES1 to combine all RES1 fields in xxx register.
- Use an immediate cmp directly.
- Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.

Changes in v3:
- Comments the functions and the arguments.
- Rename the real parameters.
- Use the macros instead of the magic values.
- Remove the redundant codes.
- Clean up all of the mess in boot_jump_linux().
- Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't 
support AArch32 state.
- Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m.

Changes in v2:
- armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used
  to switch to AArch64 EL2 or AArch32 Hyp.
- armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used
  to switch to AArch64 EL1 or AArch32 SVC.
- Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m.


Alison Wang (2):
  armv8: Support loading 32-bit OS in AArch32 execution state
  armv8: fsl-layerscape: SMP support for loading 32-bit OS

 arch/arm/Kconfig  |   6 ++
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S  |  23 +++-
 arch/arm/cpu/armv8/fsl-layerscape/mp.c|  10 +
 arch/arm/cpu/armv8/start.S|   1 +
 arch/arm/cpu/armv8/transition.S   |   4 ++--
 arch/arm/include/asm/arch-fsl-layerscape/mp.h |   6 ++
 arch/arm/include/asm/macro.h  |  80 
+--
 arch/arm/include/asm/system.h | 104 
+++-
 arch/arm/lib/bootm.c  |  19 ++--
 common/image-fit.c|  19 +++-
 10 files changed, 245 insertions(+), 27 deletions(-)

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