Re: [U-Boot] [PATCH v3 3/3] sunxi: add support for Lichee Pi Zero

2017-02-15 Thread Maxime Ripard
On Thu, Feb 16, 2017 at 01:32:19AM +, André Przywara wrote:
> Whether we need PSCI on an UP system is a separate question, I don't
> know from the top of my head if ARM(32) uses it for suspend/resume. But
> anyway this is not implemented in U-Boot's PSCI implementation, IIRC.

Antoine (in CC) did this for the A13 in order to implement cpuidle.

http://lists.denx.de/pipermail/u-boot/2016-October/271038.html

So it's definitely something we can (and should) do.

Maxime

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


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


Re: [U-Boot] [PATCH v2] armv7m: Add SysTick timer driver

2017-02-15 Thread Phil Edworthy
Hi Vikas,

On 15 February 2017 23:50, Vikas MANOCHA wrote:
> Hi Phil,
> 
> > -Original Message-
> > From: Phil Edworthy [mailto:phil.edwor...@renesas.com]
> > Sent: Monday, February 13, 2017 11:48 PM
> > To: Albert Aribaud 
> > Cc: Tom Rini ; Vikas MANOCHA
> ; Kamil Lulko ; Michael
> > Kurz ; u-boot@lists.denx.de; Phil Edworthy
> 
> > Subject: [PATCH v2] armv7m: Add SysTick timer driver
> >
> > The SysTick is a 24-bit down counter that is found on all ARM Cortex M3, M4,
> M7 devices and is always located at a fixed address.
> >
> > Signed-off-by: Phil Edworthy 
> > ---
> > v2:
> >  - Variables & constant renamed.
> >  - Use the calibration reg to determine if we use the cpu or ref clk
> >  - Use the calibration reg to get the clk rate, unless specified
> > ---
> >  arch/arm/cpu/armv7m/Makefile|   2 +
> >  arch/arm/cpu/armv7m/systick-timer.c | 107
> 
> >  2 files changed, 109 insertions(+)
> >  create mode 100644 arch/arm/cpu/armv7m/systick-timer.c
> >
> > diff --git a/arch/arm/cpu/armv7m/Makefile b/arch/arm/cpu/armv7m/Makefile
> index aff60e8..e1a6c40 100644
> > --- a/arch/arm/cpu/armv7m/Makefile
> > +++ b/arch/arm/cpu/armv7m/Makefile
> > @@ -7,3 +7,5 @@
> >
> >  extra-y := start.o
> >  obj-y += cpu.o
> > +
> > +obj-$(CONFIG_SYS_ARCH_TIMER) += systick-timer.o
> > diff --git a/arch/arm/cpu/armv7m/systick-timer.c
> b/arch/arm/cpu/armv7m/systick-timer.c
> > new file mode 100644
> > index 000..62308f9
> > --- /dev/null
> > +++ b/arch/arm/cpu/armv7m/systick-timer.c
> > @@ -0,0 +1,107 @@
> > +/*
> > + * ARM Cortex M3/M4/M7 SysTick timer driver
> > + * (C) Copyright 2017 Renesas Electronics Europe Ltd
> > + *
> > + * Based on arch/arm/mach-stm32/stm32f1/timer.c
> > + * (C) Copyright 2015
> > + * Kamil Lulko, 
> > + *
> > + * Copyright 2015 ATS Advanced Telematics Systems GmbH
> > + * Copyright 2015 Konsulko Group, Matt Porter 
> > + *
> > + * SPDX-License-Identifier: GPL-2.0+
> > + *
> > + * The SysTick timer is a 24-bit count down timer. The clock can be
> > +either the
> > + * CPU clock or a reference clock. Since the timer will wrap around
> > +very quickly
> > + * when using the CPU clock, and we do not handle the timer interrupts,
> > +it is
> > + * expected that this driver is only ever used with a slow reference clock.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +/* SysTick Base Address - fixed for all Cortex M3, M4 and M7 devices */
> > +#define SYSTICK_BASE   0xE000E010
> > +
> > +struct cm3_systick {
> > +   uint32_t ctrl;
> > +   uint32_t reload_val;
> > +   uint32_t current_val;
> > +   uint32_t calibration;
> > +};
> > +
> > +#define TIMER_MAX_VAL  0x00FF
> > +#define SYSTICK_CTRL_ENBIT(0)
> > +/* Clock source: 0 = Ref clock, 1 = CPU clock */
> > +#define SYSTICK_CTRL_CPU_CLK   BIT(2)
> > +#define SYSTICK_CAL_NOREF  BIT(31)
> > +#define SYSTICK_CAL_SKEW   BIT(30)
> > +#define SYSTICK_CAL_TENMS_MASK 0x00FF
> > +
> > +/* read the 24-bit timer */
> > +static ulong read_timer(void)
> > +{
> > +   struct cm3_systick *systick = (struct cm3_systick *)SYSTICK_BASE;
> > +
> > +   /* The timer counts down, therefore convert to an incrementing timer */
> > +   return TIMER_MAX_VAL - readl(>current_val); }
> > +
> > +int timer_init(void)
> > +{
> > +   struct cm3_systick *systick = (struct cm3_systick *)SYSTICK_BASE;
> > +   u32 cal;
> > +
> > +   writel(TIMER_MAX_VAL, >reload_val);
> > +   /* Any write to current_val reg clears it to 0 */
> > +   writel(0, >current_val);
> > +
> > +   cal = readl(>calibration);
> > +   if (cal & SYSTICK_CAL_NOREF)
> 
> Good.
> 
> > +   /* Use CPU clock, no interrupts */
> > +   writel(SYSTICK_CTRL_EN | SYSTICK_CTRL_CPU_CLK, 
> >ctrl);
> > +   else
> > +   /* Use external clock, no interrupts */
> > +   writel(SYSTICK_CTRL_EN, >ctrl);
> > +
> > +#if defined(CONFIG_SYS_HZ_CLOCK)
> > +   gd->arch.timer_rate_hz = CONFIG_SYS_HZ_CLOCK; #else
> > +   gd->arch.timer_rate_hz = (cal & SYSTICK_CAL_TENMS_MASK) * 100;
> 
> This value is implementation dependent, it can't replace
> CONFIG_SYS_HZ_CLOCK.
> 
> Let me explain a bit,
> Here the assumption is  calibration value is always 1ms at any systick clock
> frequency which is not true. Different arm vendors
> write different values in this register to have timer value for 1 or 10 ms at 
> one
> particular clock frequency, on top of it this particular frequency
> is also different for all vendors.

Hmm, I think it's vendor defined because the clock rate can be different from
different vendors. The field is named TENMS for a reason and the ARM 
description says that it is the ticks for 10ms.

However, I also realise that sometimes this field is 

[U-Boot] [PATCH] ARM: uniphier: remove dram_nr_ch from board parameters

2017-02-15 Thread Masahiro Yamada
This parameter is redundant because we can know the number of
channels by checking if dram_ch[2].size is zero.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/boards.c| 12 
 arch/arm/mach-uniphier/dram/umc-ld11.c |  2 +-
 arch/arm/mach-uniphier/dram/umc-ld20.c | 15 +--
 arch/arm/mach-uniphier/dram/umc-pxs2.c | 14 --
 arch/arm/mach-uniphier/init.h  |  1 -
 5 files changed, 18 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-uniphier/boards.c b/arch/arm/mach-uniphier/boards.c
index 26dae9e..db7d192 100644
--- a/arch/arm/mach-uniphier/boards.c
+++ b/arch/arm/mach-uniphier/boards.c
@@ -16,7 +16,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #if defined(CONFIG_ARCH_UNIPHIER_SLD3)
 static const struct uniphier_board_data uniphier_sld3_data = {
.dram_freq = 1600,
-   .dram_nr_ch = 3,
.dram_ch[0] = {
.size = 0x2000,
.width = 32,
@@ -36,7 +35,6 @@ static const struct uniphier_board_data uniphier_sld3_data = {
 #if defined(CONFIG_ARCH_UNIPHIER_LD4)
 static const struct uniphier_board_data uniphier_ld4_data = {
.dram_freq = 1600,
-   .dram_nr_ch = 2,
.dram_ch[0] = {
.size = 0x1000,
.width = 16,
@@ -53,7 +51,6 @@ static const struct uniphier_board_data uniphier_ld4_data = {
 /* 1GB RAM board */
 static const struct uniphier_board_data uniphier_pro4_data = {
.dram_freq = 1600,
-   .dram_nr_ch = 2,
.dram_ch[0] = {
.size = 0x2000,
.width = 32,
@@ -67,7 +64,6 @@ static const struct uniphier_board_data uniphier_pro4_data = {
 /* 2GB RAM board */
 static const struct uniphier_board_data uniphier_pro4_2g_data = {
.dram_freq = 1600,
-   .dram_nr_ch = 2,
.dram_ch[0] = {
.size = 0x4000,
.width = 32,
@@ -82,7 +78,6 @@ static const struct uniphier_board_data uniphier_pro4_2g_data 
= {
 #if defined(CONFIG_ARCH_UNIPHIER_SLD8)
 static const struct uniphier_board_data uniphier_sld8_data = {
.dram_freq = 1333,
-   .dram_nr_ch = 2,
.dram_ch[0] = {
.size = 0x1000,
.width = 16,
@@ -98,7 +93,6 @@ static const struct uniphier_board_data uniphier_sld8_data = {
 #if defined(CONFIG_ARCH_UNIPHIER_PRO5)
 static const struct uniphier_board_data uniphier_pro5_data = {
.dram_freq = 1866,
-   .dram_nr_ch = 2,
.dram_ch[0] = {
.size = 0x2000,
.width = 32,
@@ -113,7 +107,6 @@ static const struct uniphier_board_data uniphier_pro5_data 
= {
 #if defined(CONFIG_ARCH_UNIPHIER_PXS2)
 static const struct uniphier_board_data uniphier_pxs2_data = {
.dram_freq = 2133,
-   .dram_nr_ch = 3,
.dram_ch[0] = {
.size = 0x4000,
.width = 32,
@@ -132,7 +125,6 @@ static const struct uniphier_board_data uniphier_pxs2_data 
= {
 #if defined(CONFIG_ARCH_UNIPHIER_LD6B)
 static const struct uniphier_board_data uniphier_ld6b_data = {
.dram_freq = 1866,
-   .dram_nr_ch = 3,
.dram_ch[0] = {
.size = 0x4000,
.width = 32,
@@ -151,7 +143,6 @@ static const struct uniphier_board_data uniphier_ld6b_data 
= {
 #if defined(CONFIG_ARCH_UNIPHIER_LD11)
 static const struct uniphier_board_data uniphier_ld11_data = {
.dram_freq = 1600,
-   .dram_nr_ch = 2,
.dram_ch[0] = {
.size = 0x2000,
.width = 16,
@@ -166,7 +157,6 @@ static const struct uniphier_board_data uniphier_ld11_data 
= {
 #if defined(CONFIG_ARCH_UNIPHIER_LD20)
 static const struct uniphier_board_data uniphier_ld20_ref_data = {
.dram_freq = 1866,
-   .dram_nr_ch = 3,
.dram_ch[0] = {
.size = 0x4000,
.width = 32,
@@ -184,7 +174,6 @@ static const struct uniphier_board_data 
uniphier_ld20_ref_data = {
 
 static const struct uniphier_board_data uniphier_ld20_data = {
.dram_freq = 1866,
-   .dram_nr_ch = 3,
.dram_ch[0] = {
.size = 0x4000,
.width = 32,
@@ -202,7 +191,6 @@ static const struct uniphier_board_data uniphier_ld20_data 
= {
 
 static const struct uniphier_board_data uniphier_ld21_data = {
.dram_freq = 1866,
-   .dram_nr_ch = 2,
.dram_ch[0] = {
.size = 0x2000,
.width = 32,
diff --git a/arch/arm/mach-uniphier/dram/umc-ld11.c 
b/arch/arm/mach-uniphier/dram/umc-ld11.c
index 97a9fef..69aa4f2 100644
--- a/arch/arm/mach-uniphier/dram/umc-ld11.c
+++ b/arch/arm/mach-uniphier/dram/umc-ld11.c
@@ -471,7 +471,7 @@ int uniphier_ld11_umc_init(const struct uniphier_board_data 
*bd)
 
ddrphy_init(phy_base, freq);
 
-   for (ch = 0; ch < bd->dram_nr_ch; ch++) {
+   for (ch = 0; ch < DRAM_CH_NR; ch++) {
unsigned long size = bd->dram_ch[ch].size;

[U-Boot] [PATCH v2 3/3] configs: am43xx_evm: Enable SPL_DM

2017-02-15 Thread Lokesh Vutla
Enable SPL_DM on all AM43xx based platforms

Signed-off-by: Lokesh Vutla 
---
 configs/am43xx_evm_defconfig  | 8 +++-
 configs/am43xx_evm_usbhost_boot_defconfig | 8 +++-
 configs/am43xx_hs_evm_defconfig   | 8 +++-
 include/configs/am43xx_evm.h  | 7 ++-
 4 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index 6fb2053f33..1e0af95e81 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
 CONFIG_SPL_YMODEM_SUPPORT=y
@@ -10,7 +11,9 @@ CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1,NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
@@ -38,8 +41,12 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
@@ -73,4 +80,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index e22bc7fbdb..3d528489b7 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_ISW_ENTRY_ADDR=0x40300350
 CONFIG_SPL_STACK_R_ADDR=0x8200
@@ -11,7 +12,9 @@ CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_USB_HOST_SUPPORT=y
@@ -41,8 +44,12 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
@@ -76,4 +83,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 6bcbfd77ed..40e625818d 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_AM43XX=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TI_SECURE_DEVICE=y
 CONFIG_TARGET_AM43XX_EVM=y
 CONFIG_ISW_ENTRY_ADDR=0x403018e0
@@ -14,7 +15,9 @@ CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1,NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_ETH_SUPPORT=y
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_NET_SUPPORT=y
@@ -48,8 +51,12 @@ CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_ISO_PARTITION=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIST="am437x-gp-evm am437x-sk-evm am43x-epos-evm am437x-idk-evm"
 CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 # CONFIG_BLK is not set
 CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
@@ -82,4 +89,3 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Texas Instruments"
 CONFIG_G_DNL_VENDOR_NUM=0x0403
 CONFIG_G_DNL_PRODUCT_NUM=0xbd00
-CONFIG_SPL_OF_LIBFDT=y
diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 1d622eff2f..ec99958fcd 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -18,9 +18,9 @@
 
 /* NS16550 Configuration */
 #define CONFIG_SYS_NS16550_CLK 4800
-#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_DM_SERIAL)
+#if !defined(CONFIG_SPL_DM) || !defined(CONFIG_DM_SERIAL)
+#define CONFIG_SYS_NS16550_REG_SIZE(-4)
 #define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE(-4)
 #endif
 
 /* I2C Configuration */
@@ -111,9 +111,6 @@
  * DM support in SPL
  */
 #ifdef CONFIG_SPL_BUILD
-#undef CONFIG_DM_MMC
-#undef CONFIG_DM_SPI
-#undef CONFIG_DM_SPI_FLASH
 #undef CONFIG_TIMER
 #endif
 
-- 
2.11.0

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


[U-Boot] [PATCH v2 2/3] config: am43xx_usbhost_boot: sync with am43xx_evm

2017-02-15 Thread Lokesh Vutla
am43xx_evm defconfig has been modified without making changes
in am43xx_usbhost_boot defconfig. Synce here.

Signed-off-by: Lokesh Vutla 
---
 configs/am43xx_evm_usbhost_boot_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/am43xx_evm_usbhost_boot_defconfig 
b/configs/am43xx_evm_usbhost_boot_defconfig
index 5775ab16dd..e22bc7fbdb 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -48,13 +48,18 @@ CONFIG_DFU_MMC=y
 CONFIG_DFU_RAM=y
 CONFIG_DFU_SF=y
 CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
 # CONFIG_DM_MMC_OPS is not set
 CONFIG_MMC_OMAP_HS=y
+CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
+CONFIG_DM_SPI=y
 CONFIG_TI_QSPI=y
 CONFIG_TIMER=y
 CONFIG_OMAP_TIMER=y
-- 
2.11.0

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


[U-Boot] [PATCH v2 0/3] ARM: AM43xx: Enable SPL_DM

2017-02-15 Thread Lokesh Vutla
Enable SPL_DM on all AM4xx based boards.

This series depends on:
- DRA7 SPL_DM series[1]
- http://patchwork.ozlabs.org/patch/727106/

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg238751.html

Changes since v1:
- Fixed build error with non-SPL_DM defconfigs
- Increased SYS_MALLOC_F_LEN

Lokesh Vutla (3):
  ARM: dts: am43xx: Add u-boot specific dtsi
  config: am43xx_usbhost_boot: sync with am43xx_evm
  configs: am43xx_evm: Enable SPL_DM

 arch/arm/dts/am437x-gp-evm-u-boot.dtsi| 38 +++
 configs/am43xx_evm_defconfig  |  8 ++-
 configs/am43xx_evm_usbhost_boot_defconfig | 13 ++-
 configs/am43xx_hs_evm_defconfig   |  8 ++-
 include/configs/am43xx_evm.h  |  7 ++
 5 files changed, 66 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/dts/am437x-gp-evm-u-boot.dtsi

-- 
2.11.0

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


[U-Boot] [PATCH v2 1/3] ARM: dts: am43xx: Add u-boot specific dtsi

2017-02-15 Thread Lokesh Vutla
Add u-boot specific dtsi for am43xx-gp-evm so
that it will be used for SPL.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 arch/arm/dts/am437x-gp-evm-u-boot.dtsi

diff --git a/arch/arm/dts/am437x-gp-evm-u-boot.dtsi 
b/arch/arm/dts/am437x-gp-evm-u-boot.dtsi
new file mode 100644
index 00..885a9a92db
--- /dev/null
+++ b/arch/arm/dts/am437x-gp-evm-u-boot.dtsi
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on "dra7.dtsi"
+ */
+
+/{
+   ocp {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+_mdio {
+   u-boot,dm-pre-reloc;
+};
+
+_emac0 {
+   u-boot,dm-pre-reloc;
+};
+
+_sel {
+   u-boot,dm-pre-reloc;
+};
-- 
2.11.0

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


Re: [U-Boot] [PATCH v2 4/4] configs: dra7x/am57x: Enable the SYSCON and REGMAP features

2017-02-15 Thread Lokesh Vutla


On Monday 13 February 2017 08:47 PM, Jean-Jacques Hiblot wrote:
> This is required by the ti_qspi driver to get from the DTS the address of
> the ctrl_mod_mmap register in SPL and in u-boot.
> 
> Signed-off-by: Jean-Jacques Hiblot 

Tested-by: Lokesh Vutla 

Thanks and regards,
Lokesh

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


Re: [U-Boot] [PATCH v4 15/28] arm: socfpga: combine clrbits/setbits into a single clrsetbits

2017-02-15 Thread Ley Foon Tan
Hi Marek

On Mon, Jan 23, 2017 at 11:58 AM, Marek Vasut  wrote:
>
> On 01/10/2017 06:20 AM, Chee Tien Fong wrote:
> > From: Tien Fong Chee 
> >
> > There is no dependency on doing a separate clrbits first in the
> > dwmac_deassert_reset function. Combine them into a single
> > clrsetbits call.
> >
> > Signed-off-by: Dinh Nguyen 
> > Signed-off-by: Tien Fong Chee 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Chin Liang See 
> > Cc: Tien Fong 
> > ---
> >  arch/arm/mach-socfpga/misc.c | 9 +++--
> >  1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> > index 2645129..c97caea 100644
> > --- a/arch/arm/mach-socfpga/misc.c
> > +++ b/arch/arm/mach-socfpga/misc.c
> > @@ -100,13 +100,10 @@ static void dwmac_deassert_reset(const unsigned int 
> > of_reset_id,
> >   return;
> >   }
> >
> > - /* Clearing emac0 PHY interface select to 0 */
> > - clrbits_le32(_regs->emacgrp_ctrl,
> > -  SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << physhift);
> > -
> >   /* configure to PHY interface select choosed */
> > - setbits_le32(_regs->emacgrp_ctrl,
> > -  phymode << physhift);
>
> I don't think this patch is correct. The purpose of using these calls
> separately is so that the write with cleared physel mask actually
> reaches hardware, followed by read and another write with the physel
> mask set. clrsetbits will do only one read-modify-write cycle.
The cleared physel mask is OR with the phymode set and then write to
hardware. So, I think the
result is the same.

 #define clrsetbits(type, addr, clear, set) \
 out_##type((addr), (in_##type(addr) & ~(clear)) | (set))

>
> > + clrsetbits_le32(_regs->emacgrp_ctrl,
> > + SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << physhift,
> > + phymode << physhift);
> >
> >   /* Release the EMAC controller from reset */
> >   socfpga_per_reset(reset, 0);
> >
>
>
> --
> Best regards,
> Marek Vasut
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-15 Thread Dalon Westergreen
On Wed, 2017-02-15 at 23:20 +0100, Marek Vasut wrote:
> On 02/15/2017 10:48 PM, Dalon Westergreen wrote:
> > 
> > On Wed, 2017-02-15 at 22:15 +0100, Marek Vasut wrote:
> > > 
> > > On 02/14/2017 07:28 PM, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > When CSEL=0x0 the socfpga bootrom does not touch the clock
> > > > configuration for the device.  This can lead to a boot failure
> > > > on warm resets.  To address this, the bootrom is configured to
> > > > run a bit of code in the last 4KB of onchip ram on a warm reset.
> > > > This code puts the PLLs in bypass, disables the bootrom configuration
> > > > to run the code snippet, and issues a warm reset to run the bootrom.
> > > > 
> > > > Signed-off-by: Dalon Westergreen 
> > > > 
> > > > --
> > > > Changes in V2:
> > > >  - Fix checkpatch issues predominently due to whitespace issues
> > > > ---
> > > >  arch/arm/mach-socfpga/Makefile |  2 +-
> > > >  arch/arm/mach-socfpga/include/mach/clock_manager.h | 26 +++-
> > > >  arch/arm/mach-socfpga/include/mach/reset_manager.h |  4 ++
> > > >  .../arm/mach-socfpga/include/mach/system_manager.h |  7 ++-
> > > >  arch/arm/mach-socfpga/misc.c   | 27 
> > > >  arch/arm/mach-socfpga/reset_clock_manager.S| 71
> > > > ++
> > > >  6 files changed, 134 insertions(+), 3 deletions(-)
> > > >  create mode 100644 arch/arm/mach-socfpga/reset_clock_manager.S
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > > > socfpga/Makefile
> > > > index 809cd47..6876ccf 100644
> > > > --- a/arch/arm/mach-socfpga/Makefile
> > > > +++ b/arch/arm/mach-socfpga/Makefile
> > > > @@ -8,7 +8,7 @@
> > > >  #
> > > >  
> > > >  obj-y  += misc.o timer.o reset_manager.o system_manager.o
> > > > clock_manager.o \
> > > > -      fpga_manager.o board.o
> > > > +      fpga_manager.o board.o reset_clock_manager.o
> > > >  
> > > >  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
> > > >  
> > > > diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > > b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > > index 803c926..78f63a4 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > > > @@ -19,9 +19,12 @@ const unsigned int cm_get_osc_clk_hz(const int osc);
> > > >  const unsigned int cm_get_f2s_per_ref_clk_hz(void);
> > > >  const unsigned int cm_get_f2s_sdr_ref_clk_hz(void);
> > > >  
> > > > +/* Onchip RAM functions for CSEL=0 */
> > > > +void reset_clock_manager(void);
> > > > +extern unsigned reset_clock_manager_size;
> > > > +
> > > >  /* Clock configuration accessors */
> > > >  const struct cm_config * const cm_get_default_config(void);
> > > > -#endif
> > > >  
> > > >  struct cm_config {
> > > >     /* main group */
> > > > @@ -127,6 +130,19 @@ struct socfpga_clock_manager {
> > > >     struct socfpga_clock_manager_altera altera;
> > > >     u32 _pad_0xe8_0x200[70];
> > > >  };
> > > > +#endif
> > > > +
> > > > +#define CLKMGR_CTRL_ADDRESS 0x0
> > > 
> > > Is this the same as struct socfpga_clock_manager {} ?
> > > Why ?
> > It is, just defining offsets to use in the assembly calls
> 
> The asm is IMO not needed
> 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > +#define CLKMGR_BYPASS_ADDRESS 0x4
> > > > +#define CLKMGR_INTER_ADDRESS 0x8
> > > > +#define CLKMGR_INTREN_ADDRESS 0xc
> > > > +#define CLKMGR_DBCTRL_ADDRESS 0x10
> > > > +#define CLKMGR_STAT_ADDRESS 0x14
> > > > +#define CLKMGR_MAINPLLGRP_MAINQSPICLK_ADDRESS 0x54
> > > > +#define CLKMGR_MAINPLLGRP_MAINNANDSDMMCCLK_ADDRESS 0x58
> > > > +#define CLKMGR_PERPLLGRP_PERQSPICLK_ADDRESS 0x90
> > > > +#define CLKMGR_PERPLLGRP_PERNANDSDMMCCLK_ADDRESS 0x94
> > > > +
> > > >  
> > > >  #define CLKMGR_CTRL_SAFEMODE   (1 << 0)
> > > >  #define CLKMGR_CTRL_SAFEMODE_OFFSET0
> > > > @@ -314,4 +330,12 @@ struct socfpga_clock_manager {
> > > >  #define CLKMGR_SDRPLLGRP_S2FUSER2CLK_PHASE_OFFSET  9
> > > >  #define CLKMGR_SDRPLLGRP_S2FUSER2CLK_PHASE_MASK0x0e
> > > > 00
> > > >  
> > > > +/* Bypass Main and Per PLL, bypass source per input mux */
> > > > +#define CLKMGR_BYPASS_MAIN_PER_PLL_MASK 0x19
> > > > +   
> > > > 
> > > >  
> > > > +#define CLKMGR_MAINQSPICLK_RESET_VALUE  0x3
> > > > +#define CLKMGR_MAINNANDSDMMCCLK_RESET_VALUE 0x3
> > > > +#define CLKMGR_PERQSPICLK_RESET_VALUE   0x1
> > > > +#define CLKMGR_PERNANDSDMMCCLK_RESET_VALUE  0x1
> > > > +
> > > >  #endif /* _CLOCK_MANAGER_H_ */
> > > > diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > > > b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > > > index 2f070f2..58d77fb 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > > > +++ 

Re: [U-Boot] [linux-sunxi] Re: [PATCH v3 3/3] sunxi: add support for Lichee Pi Zero

2017-02-15 Thread Chen-Yu Tsai
On Thu, Feb 16, 2017 at 9:32 AM, André Przywara  wrote:
> On 14/02/17 07:36, Maxime Ripard wrote:
>> On Mon, Feb 13, 2017 at 04:12:04PM +0800, Icenowy Zheng wrote:
>>>
>>> 2017年2月13日 15:17于 Maxime Ripard 写道:

 Hi,

 On Sat, Feb 11, 2017 at 07:11:02PM +0800, Icenowy Zheng wrote:
> @@ -0,0 +1,13 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_SUNXI=y
> +# CONFIG_ARMV7_NONSEC is not set

 Why? It doesn't have Trustzone?
>>>
>>> The CPU has Secure mode, but no TrustZone Peripheral Controller,
>>> neither SMP.
>>
>> Still, booting in HYP and having PSCI sounds like a good idea.
>
> Yes, so without this option Linux will run in secure state, if I am not
> mistaken, which is discouraged. Instead we should enter Linux in
> (non-secure) HYP mode [1], which will allow KVM, for instance. So I'd
> recommend to remove this last line.
> Whether we need PSCI on an UP system is a separate question, I don't
> know from the top of my head if ARM(32) uses it for suspend/resume. But
> anyway this is not implemented in U-Boot's PSCI implementation, IIRC.
> So for just disabling PSCI we could use:
>
> +# CONFIG_ARMV7_PSCI is not set

We'll need to add some more code (or disable some) though. If PSCI isn't
enabled, U-boot will try to bring up the cores (by calling some non-existent-
in-sunxi function) and put them in a holding pen.

I guess Icenowy can figure that bit out.

ChenYu

>
> Cheers,
> Andre.
>
> [1] http://lxr.free-electrons.com/source/Documentation/arm/Booting#L188
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] rsa: Fix build with OpenSSL 1.1.x

2017-02-15 Thread Jonathan Gray
These version tests should be

#if (OPENSSL_VERSION_NUMBER < 0x1010L) || defined(LIBRESSL_VERSION_NUMBER)

or better yet have tests based on functionality rather than version.

opensslv.h on OpenBSD-current/LibreSSL portable master has

/* $OpenBSD: opensslv.h,v 1.39 2017/02/14 03:50:25 bcook Exp $ */
#ifndef HEADER_OPENSSLV_H
#define HEADER_OPENSSLV_H

/* These will change with each release of LibreSSL-portable */
#define LIBRESSL_VERSION_NUMBER 0x2050200fL
#define LIBRESSL_VERSION_TEXT   "LibreSSL 2.5.2"

/* These will never change */
#define OPENSSL_VERSION_NUMBER  0x2000L
#define OPENSSL_VERSION_TEXTLIBRESSL_VERSION_TEXT
#define OPENSSL_VERSION_PTEXT   " part of " OPENSSL_VERSION_TEXT

#define SHLIB_VERSION_HISTORY ""
#define SHLIB_VERSION_NUMBER "1.0.0"

#endif /* HEADER_OPENSSLV_H */

On Mon, Feb 13, 2017 at 10:00:36AM +0100, Jelle van der Waa wrote:
> The rsa_st struct has been made opaque in 1.1.x, add forward compatible
> code to access the n, e, d members of rsa_struct.
> 
> EVP_MD_CTX_cleanup has been removed in 1.1.x and EVP_MD_CTX_reset should be
> called to reinitialise an already created structure.
> ---
>  lib/rsa/rsa-sign.c | 33 +++--
>  1 file changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
> index 8c6637e328..965fb00f95 100644
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -20,6 +20,19 @@
>  #define HAVE_ERR_REMOVE_THREAD_STATE
>  #endif
>  
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> +void RSA_get0_key(const RSA *r,
> + const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
> +{
> +   if (n != NULL)
> +   *n = r->n;
> +   if (e != NULL)
> +   *e = r->e;
> +   if (d != NULL)
> +   *d = r->d;
> +}
> +#endif
> +
>  static int rsa_err(const char *msg)
>  {
>   unsigned long sslErr = ERR_get_error();
> @@ -409,7 +422,11 @@ static int rsa_sign_with_key(RSA *rsa, struct 
> checksum_algo *checksum_algo,
>   ret = rsa_err("Could not obtain signature");
>   goto err_sign;
>   }
> - EVP_MD_CTX_cleanup(context);
> + #if OPENSSL_VERSION_NUMBER < 0x1010L
> + EVP_MD_CTX_cleanup(context);
> + #else
> + EVP_MD_CTX_reset(context);
> + #endif
>   EVP_MD_CTX_destroy(context);
>   EVP_PKEY_free(key);
>  
> @@ -479,6 +496,7 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
>  {
>   int ret;
>   BIGNUM *bn_te;
> + const BIGNUM *key_e;
>   uint64_t te;
>  
>   ret = -EINVAL;
> @@ -487,17 +505,18 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
>   if (!e)
>   goto cleanup;
>  
> - if (BN_num_bits(key->e) > 64)
> + RSA_get0_key(key, NULL, _e, NULL);
> + if (BN_num_bits(key_e) > 64)
>   goto cleanup;
>  
> - *e = BN_get_word(key->e);
> + *e = BN_get_word(key_e);
>  
> - if (BN_num_bits(key->e) < 33) {
> + if (BN_num_bits(key_e) < 33) {
>   ret = 0;
>   goto cleanup;
>   }
>  
> - bn_te = BN_dup(key->e);
> + bn_te = BN_dup(key_e);
>   if (!bn_te)
>   goto cleanup;
>  
> @@ -527,6 +546,7 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
> *n0_invp,
>  {
>   BIGNUM *big1, *big2, *big32, *big2_32;
>   BIGNUM *n, *r, *r_squared, *tmp;
> + const BIGNUM *key_n;
>   BN_CTX *bn_ctx = BN_CTX_new();
>   int ret = 0;
>  
> @@ -548,7 +568,8 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
> *n0_invp,
>   if (0 != rsa_get_exponent(key, exponent))
>   ret = -1;
>  
> - if (!BN_copy(n, key->n) || !BN_set_word(big1, 1L) ||
> + RSA_get0_key(key, NULL, _n, NULL);
> + if (!BN_copy(n, key_n) || !BN_set_word(big1, 1L) ||
>   !BN_set_word(big2, 2L) || !BN_set_word(big32, 32L))
>   ret = -1;
>  
> -- 
> 2.11.1
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/3] sunxi: add support for Lichee Pi Zero

2017-02-15 Thread André Przywara
On 14/02/17 07:36, Maxime Ripard wrote:
> On Mon, Feb 13, 2017 at 04:12:04PM +0800, Icenowy Zheng wrote:
>>
>> 2017年2月13日 15:17于 Maxime Ripard 写道:
>>>
>>> Hi, 
>>>
>>> On Sat, Feb 11, 2017 at 07:11:02PM +0800, Icenowy Zheng wrote: 
 @@ -0,0 +1,13 @@ 
 +CONFIG_ARM=y 
 +CONFIG_ARCH_SUNXI=y 
 +# CONFIG_ARMV7_NONSEC is not set 
>>>
>>> Why? It doesn't have Trustzone? 
>>
>> The CPU has Secure mode, but no TrustZone Peripheral Controller,
>> neither SMP.
> 
> Still, booting in HYP and having PSCI sounds like a good idea.

Yes, so without this option Linux will run in secure state, if I am not
mistaken, which is discouraged. Instead we should enter Linux in
(non-secure) HYP mode [1], which will allow KVM, for instance. So I'd
recommend to remove this last line.
Whether we need PSCI on an UP system is a separate question, I don't
know from the top of my head if ARM(32) uses it for suspend/resume. But
anyway this is not implemented in U-Boot's PSCI implementation, IIRC.
So for just disabling PSCI we could use:

+# CONFIG_ARMV7_PSCI is not set

Cheers,
Andre.

[1] http://lxr.free-electrons.com/source/Documentation/arm/Booting#L188

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


[U-Boot] [PATCH v4 12/13] sunxi: dts: add basic OrangePi PC 2 device tree file

2017-02-15 Thread Andre Przywara
The OrangePi PC 2 is a typical SBC with the 64-bit Allwinner H5 SoC.
Create a new .dts file for it by including the (32-bit) H3 SoC .dtsi
and changing the differing components accordingly.
This is a preliminary device tree mostly for U-Boot's own sake, it
is expected to be updated once the official DT gets accepted upstream.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 arch/arm/dts/Makefile   |   2 +
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts | 147 
 2 files changed, 149 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-h5-orangepi-pc2.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eb68c20..e68f831 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -294,6 +294,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-orangepi-plus.dtb \
sun8i-h3-orangepi-plus2e.dtb \
sun8i-h3-nanopi-neo.dtb
+dtb-$(CONFIG_MACH_SUN50I_H5) += \
+   sun50i-h5-orangepi-pc2.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
sun50i-a64-pine64-plus.dtb \
sun50i-a64-pine64.dtb
diff --git a/arch/arm/dts/sun50i-h5-orangepi-pc2.dts 
b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
new file mode 100644
index 000..de60f78
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5-orangepi-pc2.dts
@@ -0,0 +1,147 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun8i-h3.dtsi"
+
+/ {
+   model = "OrangePi PC 2";
+   compatible = "xunlong,orangepi-pc-2", "allwinner,sun50i-h5";
+
+   cpus {
+   cpu@0 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   enable-method = "psci";
+   };
+   cpu@1 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   enable-method = "psci";
+   };
+   cpu@2 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   enable-method = "psci";
+   };
+   cpu@3 {
+   compatible = "arm,cortex-a53", "arm,armv8";
+   enable-method = "psci";
+   };
+   };
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   timer {
+   compatible = "arm,armv8-timer";
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory {
+   reg = <0x4000 0x4000>;
+   };
+
+   aliases {
+   serial0 = 
+   ethernet0 = 
+   };
+
+   soc {
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+   };
+};
+
+ {
+   compatible = "arm,gic-400";
+};
+
+ {
+   

[U-Boot] [PATCH v4 11/13] sunxi: introduce Allwinner H5 config option

2017-02-15 Thread Andre Przywara
The Allwinner H5 Soc is bascially an H3 with high SRAM and ARMv8 cores.
As the peripherals and the pinmuxing are almost identical, we piggy
back on the shared MACH_SUN8I_H3_H5 config symbol.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 arch/arm/mach-sunxi/cpu_info.c | 2 ++
 board/sunxi/Kconfig| 6 ++
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index f1f6fd5..85633cc 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -91,6 +91,8 @@ int print_cpuinfo(void)
puts("CPU:   Allwinner A80 (SUN9I)\n");
 #elif defined CONFIG_MACH_SUN50I
puts("CPU:   Allwinner A64 (SUN50I)\n");
+#elif defined CONFIG_MACH_SUN50I_H5
+   puts("CPU:   Allwinner H5 (SUN50I)\n");
 #else
 #warning Please update cpu_info.c with correct CPU information
puts("CPU:   SUNXI Family\n");
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index b3af193..3e0e262 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -146,6 +146,12 @@ config MACH_SUN50I
select SUNXI_HIGH_SRAM
select SUPPORT_SPL
 
+config MACH_SUN50I_H5
+   bool "sun50i (Allwinner H5)"
+   select ARM64
+   select MACH_SUNXI_H3_H5
+   select SUNXI_HIGH_SRAM
+
 endchoice
 
 # The sun8i SoCs share a lot, this helps to avoid a lot of "if A23 || A33"
-- 
2.8.2

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


[U-Boot] [PATCH v4 13/13] sunxi: configs: add basic OrangePi PC 2 defconfig

2017-02-15 Thread Andre Przywara
The OrangePi PC 2 is a typical SBC with the 64-bit Allwinner H5 SoC.
Add a (64-bit only) defconfig defining the required options to build
the U-Boot proper.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 board/sunxi/MAINTAINERS|  5 +
 configs/orangepi_pc2_defconfig | 19 +++
 2 files changed, 24 insertions(+)
 create mode 100644 configs/orangepi_pc2_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 2321b8b..3f21129 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -242,6 +242,11 @@ M: Icenowy Zheng 
 S: Maintained
 F: configs/orangepi_zero_defconfig
 
+ORANGEPI PC 2 BOARD
+M: Andre Przywara 
+S: Maintained
+F: configs/orangepi_pc2_defconfig
+
 R16 EVB PARROT BOARD
 M: Quentin Schulz 
 S: Maintained
diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig
new file mode 100644
index 000..19a5c2b
--- /dev/null
+++ b/configs/orangepi_pc2_defconfig
@@ -0,0 +1,19 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN50I_H5=y
+CONFIG_SPL=y
+CONFIG_DRAM_CLK=672
+CONFIG_DRAM_ZQ=3881977
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-pc2"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_CONSOLE_MUX=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_SUN8I_EMAC=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_SPL_SPI_SUNXI=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
-- 
2.8.2

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


[U-Boot] [PATCH v4 08/13] SPI: SPL: sunxi: fix 64-bit build

2017-02-15 Thread Andre Przywara
Addresses passed on to readl and writel are expected to be of the same
size as a pointer. Change the parameter types of sunxi_spi0_read_data()
to make the compiler happy and allow a warning-free aarch64 compile.

Signed-off-by: Andre Przywara 
Reviewed-by: Simon Glass 
Reviewed-by: Maxime Ripard 
Reviewed-by: Jagan Teki 
---
 drivers/mtd/spi/sunxi_spi_spl.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
index a24c115..852abd4 100644
--- a/drivers/mtd/spi/sunxi_spi_spl.c
+++ b/drivers/mtd/spi/sunxi_spi_spl.c
@@ -185,14 +185,14 @@ static void spi0_deinit(void)
 #define SPI_READ_MAX_SIZE 60 /* FIFO size, minus 4 bytes of the header */
 
 static void sunxi_spi0_read_data(u8 *buf, u32 addr, u32 bufsize,
-u32 spi_ctl_reg,
-u32 spi_ctl_xch_bitmask,
-u32 spi_fifo_reg,
-u32 spi_tx_reg,
-u32 spi_rx_reg,
-u32 spi_bc_reg,
-u32 spi_tc_reg,
-u32 spi_bcc_reg)
+ulong spi_ctl_reg,
+ulong spi_ctl_xch_bitmask,
+ulong spi_fifo_reg,
+ulong spi_tx_reg,
+ulong spi_rx_reg,
+ulong spi_bc_reg,
+ulong spi_tc_reg,
+ulong spi_bcc_reg)
 {
writel(4 + bufsize, spi_bc_reg); /* Burst counter (total bytes) */
writel(4, spi_tc_reg);   /* Transfer counter (bytes to send) */
-- 
2.8.2

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


[U-Boot] [PATCH v4 10/13] sunxi: prepare for sharing MACH_SUN8I_H3 config symbol

2017-02-15 Thread Andre Przywara
The Allwinner H5 is very close to the H3 SoC, but has ARMv8 cores.
To allow sharing the clocks, GPIO and driver code easily, create an
architecture agnostic MACH_SUNXI_H3_H5 Kconfig symbol.
Rename the existing symbol to MACH_SUNXI_H3_H5 where code is shared and
let it be selected by a new shared Kconfig option.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h |  4 ++--
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |  4 ++--
 arch/arm/include/asm/arch-sunxi/dram.h|  2 +-
 arch/arm/mach-sunxi/Makefile  |  2 +-
 arch/arm/mach-sunxi/board.c   |  2 +-
 arch/arm/mach-sunxi/clock_sun6i.c |  6 +++---
 arch/arm/mach-sunxi/usb_phy.c |  4 ++--
 board/sunxi/Kconfig   | 14 +-
 drivers/mtd/spi/Kconfig   |  2 +-
 drivers/net/sun8i_emac.c  |  2 +-
 drivers/power/Kconfig |  4 ++--
 drivers/usb/host/ehci-sunxi.c |  2 +-
 12 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
index 3f87672..1bfb48b 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
@@ -242,7 +242,7 @@ struct sunxi_ccm_reg {
 /* ahb_gate0 offsets */
 #define AHB_GATE_OFFSET_USB_OHCI1  30
 #define AHB_GATE_OFFSET_USB_OHCI0  29
-#ifdef CONFIG_MACH_SUN8I_H3
+#ifdef CONFIG_MACH_SUNXI_H3_H5
 /*
  * These are EHCI1 - EHCI3 in the datasheet (EHCI0 is for the OTG) we call
  * them 0 - 2 like they were called on older SoCs.
@@ -293,7 +293,7 @@ struct sunxi_ccm_reg {
 #define CCM_USB_CTRL_PHY1_CLK (0x1 << 9)
 #define CCM_USB_CTRL_PHY2_CLK (0x1 << 10)
 #define CCM_USB_CTRL_PHY3_CLK (0x1 << 11)
-#ifdef CONFIG_MACH_SUN8I_H3
+#ifdef CONFIG_MACH_SUNXI_H3_H5
 /*
  * These are OHCI1 - OHCI3 in the datasheet (OHCI0 is for the OTG) we call
  * them 0 - 2 like they were called on older SoCs.
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 3c85222..ea672fe 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -56,7 +56,7 @@
 #define SUNXI_USB2_BASE0x01c1c000
 #endif
 #ifdef CONFIG_SUNXI_GEN_SUN6I
-#if defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
+#if defined(CONFIG_MACH_SUNXI_H3_H5) || defined(CONFIG_MACH_SUN50I)
 #define SUNXI_USBPHY_BASE  0x01c19000
 #define SUNXI_USB0_BASE0x01c1a000
 #define SUNXI_USB1_BASE0x01c1b000
@@ -94,7 +94,7 @@
 #define SUNXI_KEYPAD_BASE  0x01c23000
 #define SUNXI_TZPC_BASE0x01c23400
 
-#if defined(CONFIG_MACH_SUN8I_A83T) || defined(CONFIG_MACH_SUN8I_H3) || \
+#if defined(CONFIG_MACH_SUN8I_A83T) || defined(CONFIG_MACH_SUNXI_H3_H5) || \
 defined(CONFIG_MACH_SUN50I)
 /* SID address space starts at 0x01c1400, but e-fuse is at offset 0x200 */
 #define SUNXI_SIDC_BASE0x01c14000
diff --git a/arch/arm/include/asm/arch-sunxi/dram.h 
b/arch/arm/include/asm/arch-sunxi/dram.h
index 53e6d47..1dc8220 100644
--- a/arch/arm/include/asm/arch-sunxi/dram.h
+++ b/arch/arm/include/asm/arch-sunxi/dram.h
@@ -24,7 +24,7 @@
 #include 
 #elif defined(CONFIG_MACH_SUN8I_A83T)
 #include 
-#elif defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
+#elif defined(CONFIG_MACH_SUNXI_H3_H5) || defined(CONFIG_MACH_SUN50I)
 #include 
 #elif defined(CONFIG_MACH_SUN9I)
 #include 
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 7daba11..efab481 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -48,7 +48,7 @@ obj-$(CONFIG_MACH_SUN7I)  += dram_sun4i.o
 obj-$(CONFIG_MACH_SUN8I_A23)   += dram_sun8i_a23.o
 obj-$(CONFIG_MACH_SUN8I_A33)   += dram_sun8i_a33.o
 obj-$(CONFIG_MACH_SUN8I_A83T)  += dram_sun8i_a83t.o
-obj-$(CONFIG_MACH_SUN8I_H3)+= dram_sun8i_h3.o
+obj-$(CONFIG_MACH_SUNXI_H3_H5) += dram_sun8i_h3.o
 obj-$(CONFIG_MACH_SUN9I)   += dram_sun9i.o
 obj-$(CONFIG_MACH_SUN50I)  += dram_sun8i_h3.o
 endif
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 96764d1..5e03d03 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -98,7 +98,7 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPB(0), SUN8I_A33_GPB_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPB(1), SUN8I_A33_GPB_UART0);
sunxi_gpio_set_pull(SUNXI_GPB(1), SUNXI_GPIO_PULL_UP);
-#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_H3)
+#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUNXI_H3_H5)
sunxi_gpio_set_cfgpin(SUNXI_GPA(4), SUN8I_H3_GPA_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPA(5), SUN8I_H3_GPA_UART0);

[U-Boot] [PATCH v4 09/13] sunxi: DRAM: add Allwinner H5 support

2017-02-15 Thread Andre Przywara
The DRAM controller in the Allwinner H5 SoC is again very similar to
the one in the H3 and A64.
Based on the existing socid parameter, add support for this controller
by reusing the bulk of the code and only deviating where needed.
These new bits set or cleared here and there have been mostly found by
looking at DRAM register dumps after using the H5 boot0 and comparing
them to what we set in the code. So for now it's mostly unclear what
those bits actually mean - hence the missing names and comments.
Also add the delay line parameters taken from the boot0 and libdram
disassembly.
Register setup differences between H5 and H3 are courtesy of Jens Kuske.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 arch/arm/include/asm/arch-sunxi/cpu.h |  1 +
 arch/arm/mach-sunxi/dram_sun8i_h3.c   | 97 +--
 2 files changed, 82 insertions(+), 16 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h 
b/arch/arm/include/asm/arch-sunxi/cpu.h
index 6f96a97..e8e670e 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -15,5 +15,6 @@
 
 #define SOCID_A64  0x1689
 #define SOCID_H3   0x1680
+#define SOCID_H5   0x1718
 
 #endif /* _SUNXI_CPU_H */
diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
b/arch/arm/mach-sunxi/dram_sun8i_h3.c
index 9f7cc7f..d681a9d 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
@@ -177,6 +177,34 @@ static void mctl_set_master_priority_a64(void)
writel(0x8104, _com->mdfs_bwlr[2]);
 }
 
+static void mctl_set_master_priority_h5(void)
+{
+   struct sunxi_mctl_com_reg * const mctl_com =
+   (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
+
+   /* enable bandwidth limit windows and set windows size 1us */
+   writel(399, _com->tmr);
+   writel((1 << 16), _com->bwcr);
+
+   /* set cpu high priority */
+   writel(0x0001, _com->mapr);
+
+   /* Port 2 is reserved per Allwinner's linux-3.10 source, yet
+* they initialise it */
+   MBUS_CONF(   CPU, true, HIGHEST, 0,  300,  260,  150);
+   MBUS_CONF(   GPU, true, HIGHEST, 0,  600,  400,  200);
+   MBUS_CONF(UNUSED, true, HIGHEST, 0,  512,  256,   96);
+   MBUS_CONF(   DMA, true, HIGHEST, 0,  256,  128,   32);
+   MBUS_CONF(VE, true, HIGHEST, 0, 1900, 1500, 1000);
+   MBUS_CONF(   CSI, true, HIGHEST, 0,  150,  120,  100);
+   MBUS_CONF(  NAND, true,HIGH, 0,  256,  128,   64);
+   MBUS_CONF(SS, true, HIGHEST, 0,  256,  128,   64);
+   MBUS_CONF(TS, true, HIGHEST, 0,  256,  128,   64);
+   MBUS_CONF(DI, true,HIGH, 0, 1024,  256,   64);
+   MBUS_CONF(DE, true, HIGHEST, 3, 3400, 2400, 1024);
+   MBUS_CONF(DE_CFD, true, HIGHEST, 0,  600,  400,  200);
+}
+
 static void mctl_set_master_priority(uint16_t socid)
 {
switch (socid) {
@@ -186,6 +214,9 @@ static void mctl_set_master_priority(uint16_t socid)
case SOCID_A64:
mctl_set_master_priority_a64();
return;
+   case SOCID_H5:
+   mctl_set_master_priority_h5();
+   return;
}
 }
 
@@ -256,7 +287,7 @@ static void mctl_set_timing_params(uint16_t socid, struct 
dram_para *para)
 
/* set two rank timing */
clrsetbits_le32(_ctl->dramtmg[8], (0xff << 8) | (0xff << 0),
-   (0x66 << 8) | (0x10 << 0));
+   ((socid == SOCID_H5 ? 0x33 : 0x66) << 8) | (0x10 << 0));
 
/* set PHY interface timing, write latency and read latency configure */
writel((0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8) |
@@ -391,7 +422,7 @@ static void mctl_sys_init(uint16_t socid, struct dram_para 
*para)
CCM_DRAMCLK_CFG_DIV(1) |
CCM_DRAMCLK_CFG_SRC_PLL11 |
CCM_DRAMCLK_CFG_UPD);
-   } else if (socid == SOCID_H3) {
+   } else if (socid == SOCID_H3 || socid == SOCID_H5) {
clock_set_pll5(CONFIG_DRAM_CLK * 2 * 100, false);
clrsetbits_le32(>dram_clk_cfg,
CCM_DRAMCLK_CFG_DIV_MASK |
@@ -410,7 +441,7 @@ static void mctl_sys_init(uint16_t socid, struct dram_para 
*para)
setbits_le32(>dram_clk_cfg, CCM_DRAMCLK_CFG_RST);
udelay(10);
 
-   writel(0xc00e, _ctl->clken);
+   writel(socid == SOCID_H5 ? 0x8000 : 0xc00e, _ctl->clken);
udelay(500);
 }
 
@@ -434,7 +465,10 @@ static int mctl_channel_init(uint16_t socid, struct 
dram_para *para)
 
/* setting VTC, default disable all VT */
clrbits_le32(_ctl->pgcr[0], (1 << 30) | 0x3f);
-   clrsetbits_le32(_ctl->pgcr[1], 1 << 24, 1 << 26);
+   if (socid == SOCID_H5)
+   setbits_le32(_ctl->pgcr[1], (1 << 24) | (1 << 26));
+   else
+   clrsetbits_le32(_ctl->pgcr[1], 1 << 24, 1 << 

[U-Boot] [PATCH v4 03/13] fsl: ls102x: remove redundant GENERIC_TIMER_CLK

2017-02-15 Thread Andre Przywara
Some Freescale boards used an extra version of the constant to hold the
Generic Timer frequency. This can easily be covered by the now unified
COUNTER_FREQUENCY constant, so remove this extra variable from those
boards.

Signed-off-by: Andre Przywara 
Reviewed-by: York Sun 
Reviewed-by: Jagan Teki 
---
 arch/arm/cpu/armv7/ls102xa/psci.S  | 2 +-
 arch/arm/cpu/armv7/ls102xa/timer.c | 2 +-
 include/configs/ls1021aiot.h   | 5 -
 include/configs/ls1021aqds.h   | 5 -
 include/configs/ls1021atwr.h   | 5 -
 5 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/arch/arm/cpu/armv7/ls102xa/psci.S 
b/arch/arm/cpu/armv7/ls102xa/psci.S
index 3d41d37..e1dc5f3 100644
--- a/arch/arm/cpu/armv7/ls102xa/psci.S
+++ b/arch/arm/cpu/armv7/ls102xa/psci.S
@@ -37,7 +37,7 @@
 
.align  5
 
-#defineONE_MS  (GENERIC_TIMER_CLK / 1000)
+#defineONE_MS  (COUNTER_FREQUENCY / 1000)
 #defineRESET_WAIT  (30 * ONE_MS)
 
 .globl psci_version
diff --git a/arch/arm/cpu/armv7/ls102xa/timer.c 
b/arch/arm/cpu/armv7/ls102xa/timer.c
index e6a32ca..d5237d2 100644
--- a/arch/arm/cpu/armv7/ls102xa/timer.c
+++ b/arch/arm/cpu/armv7/ls102xa/timer.c
@@ -62,7 +62,7 @@ int timer_init(void)
/* Enable System Counter */
writel(SYS_COUNTER_CTRL_ENABLE, >cntcr);
 
-   freq = GENERIC_TIMER_CLK;
+   freq = COUNTER_FREQUENCY;
asm("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
 
/* Set PL1 Physical Timer Ctrl */
diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h
index 86f4fee..9d70f5c 100644
--- a/include/configs/ls1021aiot.h
+++ b/include/configs/ls1021aiot.h
@@ -36,11 +36,6 @@
 #define CONFIG_CMD_EXT2
 #endif
 
-/*
- * Generic Timer Definitions
- */
-#define GENERIC_TIMER_CLK  1250
-
 #define CONFIG_SYS_CLK_FREQ1
 #define CONFIG_DDR_CLK_FREQ1
 
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 54fedc3..07b56c3 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -27,11 +27,6 @@
 #define CONFIG_SYS_INIT_RAM_ADDR   OCRAM_BASE_ADDR
 #define CONFIG_SYS_INIT_RAM_SIZE   OCRAM_SIZE
 
-/*
- * Generic Timer Definitions
- */
-#define GENERIC_TIMER_CLK  1250
-
 #ifndef __ASSEMBLY__
 unsigned long get_board_sys_clk(void);
 unsigned long get_board_ddr_clk(void);
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 7582633..f9192b0 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -56,11 +56,6 @@
 #define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2
 #endif
 
-/*
- * Generic Timer Definitions
- */
-#define GENERIC_TIMER_CLK  1250
-
 #define CONFIG_SYS_CLK_FREQ1
 #define CONFIG_DDR_CLK_FREQ1
 
-- 
2.8.2

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


[U-Boot] [PATCH v4 04/13] sunxi: simplify ACTLR.SMP bit set #ifdef

2017-02-15 Thread Andre Przywara
Instead of enumerating all SoC families that need that bit set, let's
just express this more clearly: The SMP bits needs to be set on
SMP capable ARMv7 CPUs. It's much easier in Kconfig to express it the
other way round, so we use ! CPU_IS_UP and ! ARM64.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
---
 arch/arm/Kconfig| 4 
 arch/arm/mach-sunxi/board.c | 5 +
 board/sunxi/Kconfig | 2 ++
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0229800..240320a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -126,6 +126,10 @@ config ENABLE_ARM_SOC_BOOT0_HOOK
  ARM_SOC_BOOT0_HOOK which contains the required assembler
  preprocessor code.
 
+config ARM_CORTEX_CPU_IS_UP
+   bool
+   default n
+
 config USE_ARCH_MEMCPY
bool "Use an assembly optimized implementation of memcpy"
default y
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 58fbacb..fdcf68e 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -180,10 +180,7 @@ void s_init(void)
/* No H3 BSP, boot0 seems to not modify SUNXI_SRAMC_BASE + 0x44 */
 #endif
 
-#if defined CONFIG_MACH_SUN6I || \
-defined CONFIG_MACH_SUN7I || \
-defined CONFIG_MACH_SUN8I || \
-defined CONFIG_MACH_SUN9I
+#if !defined(CONFIG_ARM_CORTEX_CPU_IS_UP) && !defined(CONFIG_ARM64)
/* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */
asm volatile(
"mrc p15, 0, r0, c1, c0, 1\n"
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 37b4252..ea0d658 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -50,12 +50,14 @@ choice
 config MACH_SUN4I
bool "sun4i (Allwinner A10)"
select CPU_V7
+   select ARM_CORTEX_CPU_IS_UP
select SUNXI_GEN_SUN4I
select SUPPORT_SPL
 
 config MACH_SUN5I
bool "sun5i (Allwinner A13)"
select CPU_V7
+   select ARM_CORTEX_CPU_IS_UP
select SUNXI_GEN_SUN4I
select SUPPORT_SPL
 
-- 
2.8.2

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


[U-Boot] [PATCH v4 06/13] sunxi: Kconfig: introduce CONFIG_SUNXI_HIGH_SRAM

2017-02-15 Thread Andre Przywara
Traditionally Allwinner SoCs have their boot ROM mapped just below 4GB,
while the first SRAM region is mapped at address 0.
With the extended physical memory support of the A80 this was changed,
so the BROM is now at address 0 and the SRAM region starts right behind
this at 64KB. This configuration seems to be called "high SRAM".
Instead of enumerating the SoCs which have copied this configuration,
let's call a spade a spade and introduce a Kconfig option for this setup.
SoCs implementing this (A80, A64 and H5, so far), can then select this
configuration.
Simplify the config header definition on the way.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
Reviewed-by: Jagan Teki 
---
 arch/arm/include/asm/arch-sunxi/spl.h |  2 +-
 board/sunxi/Kconfig   | 13 +
 include/configs/sunxi-common.h| 19 +++
 3 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/spl.h 
b/arch/arm/include/asm/arch-sunxi/spl.h
index 5d7ab55..831d0c0 100644
--- a/arch/arm/include/asm/arch-sunxi/spl.h
+++ b/arch/arm/include/asm/arch-sunxi/spl.h
@@ -12,7 +12,7 @@
 #define SPL_SIGNATURE  "SPL" /* marks "sunxi" SPL header */
 #define SPL_HEADER_VERSION 1
 
-#if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
+#ifdef CONFIG_SUNXI_HIGH_SRAM
 #define SPL_ADDR   0x1
 #else
 #define SPL_ADDR   0x0
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ea0d658..654ec73 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -27,6 +27,17 @@ config SPL_POWER_SUPPORT
 config SPL_SERIAL_SUPPORT
default y
 
+config SUNXI_HIGH_SRAM
+   bool
+   default n
+   ---help---
+   Older Allwinner SoCs have their mask boot ROM mapped just below 4GB,
+   with the first SRAM region being located at address 0.
+   Some newer SoCs map the boot ROM at address 0 instead and move the
+   SRAM to 64KB, just behind the mask ROM.
+   Chips using the latter setup are supposed to select this option to
+   adjust the addresses accordingly.
+
 # Note only one of these may be selected at a time! But hidden choices are
 # not supported by Kconfig
 config SUNXI_GEN_SUN4I
@@ -120,6 +131,7 @@ config MACH_SUN8I_H3
 config MACH_SUN9I
bool "sun9i (Allwinner A80)"
select CPU_V7
+   select SUNXI_HIGH_SRAM
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
 
@@ -127,6 +139,7 @@ config MACH_SUN50I
bool "sun50i (Allwinner A64)"
select ARM64
select SUNXI_GEN_SUN6I
+   select SUNXI_HIGH_SRAM
select SUPPORT_SPL
 
 endchoice
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 3b9ced8..5fe886b 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -86,7 +86,7 @@
 
 #define CONFIG_SPL_BSS_MAX_SIZE0x0008 /* 512 KiB */
 
-#if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
+#ifdef CONFIG_SUNXI_HIGH_SRAM
 /*
  * The A80's A1 sram starts at 0x0001 rather then at 0x and is
  * slightly bigger. Note that it is possible to map the first 32 KiB of the
@@ -183,29 +183,24 @@
 #define CONFIG_SPL_BOARD_LOAD_IMAGE
 #endif
 
-#if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
+#ifdef CONFIG_SUNXI_HIGH_SRAM
 #define CONFIG_SPL_TEXT_BASE   0x10040 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x7fc0  /* 32 KiB on sun9/50i */
+#define CONFIG_SPL_MAX_SIZE0x7fc0  /* 32 KiB */
+#define LOW_LEVEL_SRAM_STACK   0x00018000
 #else
 #define CONFIG_SPL_TEXT_BASE   0x40/* sram start+header */
 #define CONFIG_SPL_MAX_SIZE0x5fc0  /* 24KB on sun4i/sun7i 
*/
+#define LOW_LEVEL_SRAM_STACK   0x8000  /* End of sram */
 #endif
 
+#define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
+
 #ifndef CONFIG_ARM64
 #define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/sunxi/u-boot-spl.lds"
 #endif
 
 #define CONFIG_SPL_PAD_TO  32768   /* decimal for 'dd' */
 
-#if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
-/* FIXME: 40 KiB instead of 32 KiB ? */
-#define LOW_LEVEL_SRAM_STACK   0x00018000
-#define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
-#else
-/* end of 32 KiB in sram */
-#define LOW_LEVEL_SRAM_STACK   0x8000 /* End of sram */
-#define CONFIG_SPL_STACK   LOW_LEVEL_SRAM_STACK
-#endif
 
 /* I2C */
 #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
-- 
2.8.2

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


[U-Boot] [PATCH v4 05/13] sunxi: configs: merge sun9i and sun50i SPL memory definitions

2017-02-15 Thread Andre Przywara
For some reason we were pretty conservative when defining the maximum
SPL size for the Allwinner A80(sun9i) SoC.
According to the manual the SRAM A1 is even 40KB, but the BROM
probably still has the 32 KiB load limit. For the sake of simplicity,
merge the SPL memory definitions for the A64 and A80 SoCs, since both
SoC share the BROM/SRAM A1 memory layout.
This helps to further simplify this is in the next patch.

Signed-off-by: Andre Przywara 
Reviewed-by: Jagan Teki 
---
 include/configs/sunxi-common.h | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 7a53e47..3b9ced8 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -183,12 +183,9 @@
 #define CONFIG_SPL_BOARD_LOAD_IMAGE
 #endif
 
-#if defined(CONFIG_MACH_SUN9I)
-#define CONFIG_SPL_TEXT_BASE   0x10040 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x5fc0  /* ? KiB on sun9i */
-#elif defined(CONFIG_MACH_SUN50I)
+#if defined(CONFIG_MACH_SUN9I) || defined(CONFIG_MACH_SUN50I)
 #define CONFIG_SPL_TEXT_BASE   0x10040 /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE0x7fc0  /* 32 KiB on sun50i */
+#define CONFIG_SPL_MAX_SIZE0x7fc0  /* 32 KiB on sun9/50i */
 #else
 #define CONFIG_SPL_TEXT_BASE   0x40/* sram start+header */
 #define CONFIG_SPL_MAX_SIZE0x5fc0  /* 24KB on sun4i/sun7i 
*/
-- 
2.8.2

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


[U-Boot] [PATCH v4 02/13] ARM: rename CONFIG_TIMER_CLK_FREQ to COUNTER_FREQUENCY

2017-02-15 Thread Andre Przywara
Many ARMv8 boards define a constant COUNTER_FREQUENCY to specify the
frequency of the ARM Generic Timer (aka. arch timer).
ARMv7 boards traditionally used CONFIG_TIMER_CLK_FREQ for the same
purpose. It seems useful to unify them.
Since there are less occurences of the latter version, lets convert all
users over to COUNTER_FREQUENCY.

Signed-off-by: Andre Przywara 
Reviewed-by: Jagan Teki 
---
 arch/arm/cpu/armv7/nonsec_virt.S | 4 ++--
 arch/arm/cpu/armv7/sunxi/psci.c  | 2 +-
 board/sunxi/board.c  | 6 +++---
 include/configs/exynos-common.h  | 2 +-
 include/configs/ls1021aiot.h | 2 +-
 include/configs/ls1021aqds.h | 2 +-
 include/configs/ls1021atwr.h | 2 +-
 include/configs/mx7_common.h | 2 +-
 include/configs/sun50i.h | 1 -
 include/configs/sunxi-common.h   | 2 +-
 scripts/config_whitelist.txt | 1 -
 11 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/arch/arm/cpu/armv7/nonsec_virt.S b/arch/arm/cpu/armv7/nonsec_virt.S
index 95ce938..e39aba7 100644
--- a/arch/arm/cpu/armv7/nonsec_virt.S
+++ b/arch/arm/cpu/armv7/nonsec_virt.S
@@ -188,11 +188,11 @@ ENTRY(_nonsec_init)
  * we do this here instead.
  * But first check if we have the generic timer.
  */
-#ifdef CONFIG_TIMER_CLK_FREQ
+#ifdef COUNTER_FREQUENCY
mrc p15, 0, r0, c0, c1, 1   @ read ID_PFR1
and r0, r0, #CPUID_ARM_GENTIMER_MASK@ mask arch timer bits
cmp r0, #(1 << CPUID_ARM_GENTIMER_SHIFT)
-   ldreq   r1, =CONFIG_TIMER_CLK_FREQ
+   ldreq   r1, =COUNTER_FREQUENCY
mcreq   p15, 0, r1, c14, c0, 0  @ write CNTFRQ
 #endif
 
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 766b8c7..104dc90 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -46,7 +46,7 @@ static u32 __secure cp15_read_cntp_ctl(void)
return val;
 }
 
-#define ONE_MS (CONFIG_TIMER_CLK_FREQ / 1000)
+#define ONE_MS (COUNTER_FREQUENCY / 1000)
 
 static void __secure __mdelay(u32 ms)
 {
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 5365638..b966012 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -100,14 +100,14 @@ int board_init(void)
 * we avoid the risk of writing to it.
 */
asm volatile("mrc p15, 0, %0, c14, c0, 0" : "=r"(freq));
-   if (freq != CONFIG_TIMER_CLK_FREQ) {
+   if (freq != COUNTER_FREQUENCY) {
debug("arch timer frequency is %d Hz, should be %d, 
fixing ...\n",
- freq, CONFIG_TIMER_CLK_FREQ);
+ freq, COUNTER_FREQUENCY);
 #ifdef CONFIG_NON_SECURE
printf("arch timer frequency is wrong, but cannot 
adjust it\n");
 #else
asm volatile("mcr p15, 0, %0, c14, c0, 0"
-: : "r"(CONFIG_TIMER_CLK_FREQ));
+: : "r"(COUNTER_FREQUENCY));
 #endif
}
}
diff --git a/include/configs/exynos-common.h b/include/configs/exynos-common.h
index 7a40c98..f03ab3a 100644
--- a/include/configs/exynos-common.h
+++ b/include/configs/exynos-common.h
@@ -23,7 +23,7 @@
 
 /* input clock of PLL: 24MHz input clock */
 #define CONFIG_SYS_CLK_FREQ2400
-#define CONFIG_TIMER_CLK_FREQ  CONFIG_SYS_CLK_FREQ
+#define COUNTER_FREQUENCY  CONFIG_SYS_CLK_FREQ
 
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_CMDLINE_TAG
diff --git a/include/configs/ls1021aiot.h b/include/configs/ls1021aiot.h
index c4ee23e..86f4fee 100644
--- a/include/configs/ls1021aiot.h
+++ b/include/configs/ls1021aiot.h
@@ -246,7 +246,7 @@
 #define CONFIG_PEN_ADDR_BIG_ENDIAN
 #define CONFIG_LAYERSCAPE_NS_ACCESS
 #define CONFIG_SMP_PEN_ADDR0x01ee0200
-#define CONFIG_TIMER_CLK_FREQ  1250
+#define COUNTER_FREQUENCY  1250
 
 #define CONFIG_HWCONFIG
 #define HWCONFIG_BUFFER_SIZE   256
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 774a1de..54fedc3 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -504,7 +504,7 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_PEN_ADDR_BIG_ENDIAN
 #define CONFIG_LAYERSCAPE_NS_ACCESS
 #define CONFIG_SMP_PEN_ADDR0x01ee0200
-#define CONFIG_TIMER_CLK_FREQ  1250
+#define COUNTER_FREQUENCY  1250
 
 #define CONFIG_HWCONFIG
 #define HWCONFIG_BUFFER_SIZE   256
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index c49ad36..7582633 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -374,7 +374,7 @@
 #define CONFIG_PEN_ADDR_BIG_ENDIAN
 #define CONFIG_LAYERSCAPE_NS_ACCESS
 #define CONFIG_SMP_PEN_ADDR0x01ee0200
-#define CONFIG_TIMER_CLK_FREQ  1250
+#define COUNTER_FREQUENCY  1250
 
 #define 

[U-Boot] [PATCH v4 07/13] sunxi: provide ARMv8 mem_map for every ARM64 board

2017-02-15 Thread Andre Przywara
Every armv8 board needs the memory map, so change the #ifdef to
ARM64 to avoid enumerating every single board or SoC.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
Reviewed-by: Jagan Teki 
---
 arch/arm/mach-sunxi/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index fdcf68e..96764d1 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -40,7 +40,7 @@ struct fel_stash {
 
 struct fel_stash fel_stash __attribute__((section(".data")));
 
-#ifdef CONFIG_MACH_SUN50I
+#ifdef CONFIG_ARM64
 #include 
 
 static struct mm_region sunxi_mem_map[] = {
-- 
2.8.2

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


[U-Boot] [PATCH v4 00/13] sunxi: Allwinner H5 and OrangePi PC2 support

2017-02-15 Thread Andre Przywara
Hi,

thanks for all the reviews and ACKs!

Only minor changes this time, see the Changelog below.

Cheers,
Andre.

--
This series introduces support for the Allwinner H5 SoC with four
Cortex-A53 cores. The SoC's peripherals are very similar to the H3,
although the cores and the BROM/SRAM layout resembles the A64.
The first 8 patches contain some fixes and refactoring, to make code
sharing between the three mentioned SoCs easier.
Patch 09/13 adds support for the H5 DRAM controller, by extending
the already existing combined H3/A64 DRAM code.
Patch 10/13 renames the existing CONFIG_MACH_SUN8I_H3 config symbol to
let it be used by all peripheral code that can be shared between the
H3 and H5. Patch 11/13 introduces the H5 SoC config option into Kconfig,
which defines this shared symbol as well.
Patch 12/13 adds an easy device tree, which actually uses the H3 .dtsi
and overwrites nodes which are different. This is good enough for U-Boot,
the DT will be changed anyway once we get the DT merged into the Linux
kernel.
The final patch then adds the defconfig for the OrangePi PC2 board.
Since this board comes with soldered SPI flash, we enable support for
it in the SPL. This has been tested by writing the SPI flash with some
special sunxi-fel version. The BROM loaded and executed the SPL, which
in turn loaded and executed U-Boot proper. Both parts are 64-bit only
for now.
Ethernet support is enabled, but fails at the moment since the EMAC
driver does not support setting a GPIO to enable the external Gigabit PHY.

At the moment this build suffers from the same problem as the A64: the
ATF is missing, so Linux won't boot easily. With the RFC version of the
SPL FIT extension series on the list, applied on top of this one this
should now be solved.

This series is on top of v2017.03-rc2.

Please have a look and let me know your opinion!

Cheers,
Andre.

Changelog v3..v4:
- Adding ACKs and RBs
- adding help text for CONFIG_SUNXI_HIGH_SRAM option
- adapting _defconfig to upstream changes

Changelog v2..v3:
- Adding ACKs and RBs
- remove not needed CONFIG_MACH_SUN50I_H5_64
- move ARM_CORTEX_CPU_IS_UP to arch/arm/Kconfig

Changelog v1..v2:
- Adding Maxime's ACKs
- new patch 2 and 3 to rename CONFIG_TIMER_CLK_FREQ to COUNTER_FREQUENCY
- renaming CONFIG symbol name for single core SoCs
- fixing one checkpatch issue (some are left, though)
- mentioning methodology and reason for missing data in DRAM driver
- renaming shared config symbol to CONFIG_MACH_SUNXI_H3_H5
- updated to lastest origin/master

Andre Przywara (13):
  sunxi: fix ACTLR.SMP assembly routine
  ARM: rename CONFIG_TIMER_CLK_FREQ to COUNTER_FREQUENCY
  fsl: ls102x: remove redundant GENERIC_TIMER_CLK
  sunxi: simplify ACTLR.SMP bit set #ifdef
  sunxi: configs: merge sun9i and sun50i SPL memory definitions
  sunxi: Kconfig: introduce CONFIG_SUNXI_HIGH_SRAM
  sunxi: provide ARMv8 mem_map for every ARM64 board
  SPI: SPL: sunxi: fix 64-bit build
  sunxi: DRAM: add Allwinner H5 support
  sunxi: prepare for sharing MACH_SUN8I_H3 config symbol
  sunxi: introduce Allwinner H5 config option
  sunxi: dts: add basic OrangePi PC 2 device tree file
  sunxi: configs: add basic OrangePi PC 2 defconfig

 arch/arm/Kconfig  |   4 +
 arch/arm/cpu/armv7/ls102xa/psci.S |   2 +-
 arch/arm/cpu/armv7/ls102xa/timer.c|   2 +-
 arch/arm/cpu/armv7/nonsec_virt.S  |   4 +-
 arch/arm/cpu/armv7/sunxi/psci.c   |   2 +-
 arch/arm/dts/Makefile |   2 +
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts   | 147 ++
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h |   4 +-
 arch/arm/include/asm/arch-sunxi/cpu.h |   1 +
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |   4 +-
 arch/arm/include/asm/arch-sunxi/dram.h|   2 +-
 arch/arm/include/asm/arch-sunxi/spl.h |   2 +-
 arch/arm/mach-sunxi/Makefile  |   2 +-
 arch/arm/mach-sunxi/board.c   |  12 +--
 arch/arm/mach-sunxi/clock_sun6i.c |   6 +-
 arch/arm/mach-sunxi/cpu_info.c|   2 +
 arch/arm/mach-sunxi/dram_sun8i_h3.c   |  97 ++---
 arch/arm/mach-sunxi/usb_phy.c |   4 +-
 board/sunxi/Kconfig   |  35 +-
 board/sunxi/MAINTAINERS   |   5 +
 board/sunxi/board.c   |   6 +-
 configs/orangepi_pc2_defconfig|  19 
 drivers/mtd/spi/Kconfig   |   2 +-
 drivers/mtd/spi/sunxi_spi_spl.c   |  16 +--
 drivers/net/sun8i_emac.c  |   2 +-
 drivers/power/Kconfig |   4 +-
 drivers/usb/host/ehci-sunxi.c |   2 +-
 include/configs/exynos-common.h   |   2 +-
 include/configs/ls1021aiot.h  |   7 +-
 include/configs/ls1021aqds.h  |   7 +-
 include/configs/ls1021atwr.h  |   7 +-
 

[U-Boot] [PATCH v4 01/13] sunxi: fix ACTLR.SMP assembly routine

2017-02-15 Thread Andre Przywara
If we take the liberty to use register r0 to perform our bit set, we
should be nice enough to tell the compiler about it.
Add r0 to the clobber list to avoid potential mayhem.

Signed-off-by: Andre Przywara 
Acked-by: Maxime Ripard 
Acked-by: Jagan Teki 
---
 arch/arm/mach-sunxi/board.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 52be5b0..58fbacb 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -188,7 +188,8 @@ void s_init(void)
asm volatile(
"mrc p15, 0, r0, c1, c0, 1\n"
"orr r0, r0, #1 << 6\n"
-   "mcr p15, 0, r0, c1, c0, 1\n");
+   "mcr p15, 0, r0, c1, c0, 1\n"
+   ::: "r0");
 #endif
 #if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
/* Enable non-secure access to some peripherals */
-- 
2.8.2

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


[U-Boot] Veyron-speedy u-boot

2017-02-15 Thread Riley Baird
Hi Simon,

I've tried porting u-boot to the veyron-speedy Chromebook, based upon
the veyron-minnie patch.

I've attached a patch with my changes to this email.

However, when I boot, all I get is a black screen. So, I have some
questions:

1. Does u-boot show output to the laptop's screen, or do I have to make
a serial console?
2. If I have to make a serial console, where do I do this/what is the
pin layout?
3. Do I just have to sign u-boot-dtb.img with vbutil_kernel before
dd-ing it onto a USB, or do I have to do something else to make the
right image?

Yours thankfully,

Riley Baird
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eb68c204bb..a2b1283658 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -33,6 +33,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3288-veyron-jerry.dtb \
 	rk3288-veyron-mickey.dtb \
 	rk3288-veyron-minnie.dtb \
+	rk3288-veyron-speedy.dtb \
 	rk3288-rock2-square.dtb \
 	rk3288-evb.dtb \
 	rk3288-fennec.dtb \
diff --git a/arch/arm/dts/rk3288-veyron-speedy.dts b/arch/arm/dts/rk3288-veyron-speedy.dts
new file mode 100644
index 00..666e797cf3
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-speedy.dts
@@ -0,0 +1,190 @@
+/*
+ * Google Veyron Speedy Rev 1+ board device tree source
+ *
+ * Copyright 2015 Google, Inc
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3288-veyron-chromebook.dtsi"
+#include "cros-ec-sbs.dtsi"
+
+/ {
+	model = "Google Speedy";
+	compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
+		 "google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
+		 "google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
+		 "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
+		 "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
+
+	panel_regulator: panel-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = < 14 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <_enable_h>;
+		regulator-name = "panel_regulator";
+		startup-delay-us = <10>;
+		vin-supply = <_sys>;
+	};
+
+	vcc18_lcd: vcc18-lcd {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = < 13 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <_1v8_disp_en>;
+		regulator-name = "vcc18_lcd";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <_wl>;
+	};
+
+	backlight_regulator: backlight-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = < 12 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <_pwr_en>;
+		regulator-name = "backlight_regulator";
+		vin-supply = <_sys>;
+		startup-delay-us = <15000>;
+	};
+};
+
+ {
+	power-supply = <_regulator>;
+};
+
+_alert0 {
+	temperature = <65000>;
+};
+
+_alert1 {
+	temperature = <7>;
+};
+
+ {
+	/delete-property/pinctrl-names;
+	/delete-property/pinctrl-0;
+
+	force-hpd;
+};
+
+ {
+	power-supply= <_regulator>;
+};
+
+ {
+	pinctrl-names = "default";
+	pinctrl-0 = <_int_l>;
+};
+
+ {
+	rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
+		0x6 

Re: [U-Boot] [PATCH] sunxi: makes an invisible option for H3-like DRAM controllers

2017-02-15 Thread André Przywara
On 14/02/17 13:49, Icenowy Zheng wrote:
> Allwinner SoCs after H3 (e.g. A64, H5, R40, V3s) uses a H3-like
> DesignWare DRAM controller, which do not have official free DRAM
> initialization code, but can use modified dram_sun8i_h3.c.
> 
> Add a invisible option for easier DRAM initialization code reuse.

Thanks for the patch, I like this approach.

> Signed-off-by: Icenowy Zheng 
> Acked-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  arch/arm/include/asm/arch-sunxi/dram.h   | 4 ++--
>  .../include/asm/arch-sunxi/{dram_sun8i_h3.h => dram_sunxi_dw.h}  | 0
>  arch/arm/mach-sunxi/Makefile | 2 +-
>  arch/arm/mach-sunxi/{dram_sun8i_h3.c => dram_sunxi_dw.c} | 0
>  board/sunxi/Kconfig  | 9 
> +
>  5 files changed, 12 insertions(+), 3 deletions(-)
>  rename arch/arm/include/asm/arch-sunxi/{dram_sun8i_h3.h => dram_sunxi_dw.h} 
> (100%)
>  rename arch/arm/mach-sunxi/{dram_sun8i_h3.c => dram_sunxi_dw.c} (100%)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/dram.h 
> b/arch/arm/include/asm/arch-sunxi/dram.h
> index 53e6d471d2..6f0131ab16 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram.h
> @@ -24,8 +24,8 @@
>  #include 
>  #elif defined(CONFIG_MACH_SUN8I_A83T)
>  #include 
> -#elif defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
> -#include 
> +#elif defined(CONFIG_SUNXI_DW_DRAM)
> +#include 
>  #elif defined(CONFIG_MACH_SUN9I)
>  #include 
>  #else
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> similarity index 100%
> rename from arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h
> rename to arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> index 7daba1169c..25d896a14e 100644
> --- a/arch/arm/mach-sunxi/Makefile
> +++ b/arch/arm/mach-sunxi/Makefile
> @@ -48,7 +48,7 @@ obj-$(CONFIG_MACH_SUN7I)+= dram_sun4i.o
>  obj-$(CONFIG_MACH_SUN8I_A23) += dram_sun8i_a23.o
>  obj-$(CONFIG_MACH_SUN8I_A33) += dram_sun8i_a33.o
>  obj-$(CONFIG_MACH_SUN8I_A83T)+= dram_sun8i_a83t.o
> -obj-$(CONFIG_MACH_SUN8I_H3)  += dram_sun8i_h3.o
> +obj-$(CONFIG_SUNXI_DW_DRAM)  += dram_sunxi_dw.o
>  obj-$(CONFIG_MACH_SUN9I) += dram_sun9i.o
>  obj-$(CONFIG_MACH_SUN50I)+= dram_sun8i_h3.o
>  endif
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> similarity index 100%
> rename from arch/arm/mach-sunxi/dram_sun8i_h3.c
> rename to arch/arm/mach-sunxi/dram_sunxi_dw.c
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index 018bdd12dd..d09ae6067e 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -42,6 +42,13 @@ config SUNXI_GEN_SUN6I
>   separate ahb reset control registers, custom pmic bus, new style
>   watchdog, etc.
>  
> +config SUNXI_DW_DRAM
> + bool
> + ---help---
> + Select this for sunxi SoCs which uses a DRAM controller like the
> + DesignWare controller used in H3, mainly SoCs after H3, which do
> + not have official open-source DRAM initialization code, but can
> + use modified H3 DRAM initialization code.
>  
>  choice
>   prompt "Sunxi SoC Variant"
> @@ -113,6 +120,7 @@ config MACH_SUN8I_H3
>   select ARCH_SUPPORT_PSCI
>   select SUNXI_GEN_SUN6I
>   select SUPPORT_SPL
> + select SUNXI_DW_DRAM
>   select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT
>  
>  config MACH_SUN8I_V3S
> @@ -134,6 +142,7 @@ config MACH_SUN50I
>   select ARM64
>   select SUNXI_GEN_SUN6I
>   select SUPPORT_SPL
> + select SUNXI_DW_DRAM
>  
>  endchoice
>  
> 

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


Re: [U-Boot] [PATCH v5 2/6] spl: Add option to enable SPL Legacy image support

2017-02-15 Thread Tom Rini
On Wed, Feb 15, 2017 at 01:45:47PM -0600, Andrew F. Davis wrote:

> Add a Kconfig option that enables Legacy image support, this allows
> boards to explicitly disable this, for instance when needed for
> security reasons.
> 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Simon Glass 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [U-Boot] [PATCH v5 1/6] spl: Convert CONFIG_SPL_ABORT_ON_RAW_IMAGE into a positive option

2017-02-15 Thread Tom Rini
On Wed, Feb 15, 2017 at 01:45:46PM -0600, Andrew F. Davis wrote:

> CONFIG_SPL_ABORT_ON_RAW_IMAGE causes SPL to abort and move on when it
> encounters RAW images, express this same functionality as a positive
> option enabling support for RAW images: CONFIG_SPL_RAW_IMAGE_SUPPORT
> 
> Also move uses of this to defconfigs.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [U-Boot] [PATCH v5 0/6] Allow disabling non-FIT image loading from SPL

2017-02-15 Thread Tom Rini
On Wed, Feb 15, 2017 at 01:45:45PM -0600, Andrew F. Davis wrote:

> Hello all,
> 
> To address a needed feature brought up by Andreas[0], we need a way to
> disable SPL from loading non-FIT images.
> 
> The function spl_parse_image_header is common to all SPL loading paths
> (common/spl/spl_(nand|net|nor|etc..)) so we add the check here.
> 
> This version of the series is a bit different than the last 2 due
> to suggestions by Simon, instead of a negative option disabling
> non-FIT images, we allow the other image format's support to be
> toggled off, and do that on HS boards.

I think this would be cleaner if we introduce the symbols to be default
n if TI_SECURE_DEVICE and then we don't have to modify the defconfig
files.  That said, we should probably do that as a new patch #3 so it's
clear in the commit history when we default it off.  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v2] driver: net: ldpaa: Update priv->phydev after free()

2017-02-15 Thread Joe Hershberger
On Wed, Feb 15, 2017 at 9:26 AM, Ashish Kumar  wrote:
> From: Prabhakar Kushwaha 
>
> Even after memory free of phydev, priv is still pointing to the
> obsolete address.
> So update priv->phydev as NULL after memory free.
>
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 

Please always Cc me on network changes.

> ---
> v2:
> Add signoff
>
>  drivers/net/ldpaa_eth/ldpaa_eth.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
> b/drivers/net/ldpaa_eth/ldpaa_eth.c
> index 4e61700..f235b62 100644
> --- a/drivers/net/ldpaa_eth/ldpaa_eth.c
> +++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
> @@ -587,8 +587,10 @@ static void ldpaa_eth_stop(struct eth_device *net_dev)
>  #ifdef CONFIG_PHYLIB
> if (priv->phydev && bus != NULL)
> phy_shutdown(priv->phydev);
> -   else
> +   else {
> free(priv->phydev);
> +   priv->phydev = NULL;
> +   }

This is strange. Why not just drop the free? It seems bad to delete
the phydev just because the mdio interface is not there, especially in
stop().

>  #endif
>
> ldpaa_dpbp_free();
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] armv7m: Add SysTick timer driver

2017-02-15 Thread Vikas MANOCHA
Hi Phil,

> -Original Message-
> From: Phil Edworthy [mailto:phil.edwor...@renesas.com]
> Sent: Monday, February 13, 2017 11:48 PM
> To: Albert Aribaud 
> Cc: Tom Rini ; Vikas MANOCHA ; 
> Kamil Lulko ; Michael
> Kurz ; u-boot@lists.denx.de; Phil Edworthy 
> 
> Subject: [PATCH v2] armv7m: Add SysTick timer driver
> 
> The SysTick is a 24-bit down counter that is found on all ARM Cortex M3, M4, 
> M7 devices and is always located at a fixed address.
> 
> Signed-off-by: Phil Edworthy 
> ---
> v2:
>  - Variables & constant renamed.
>  - Use the calibration reg to determine if we use the cpu or ref clk
>  - Use the calibration reg to get the clk rate, unless specified
> ---
>  arch/arm/cpu/armv7m/Makefile|   2 +
>  arch/arm/cpu/armv7m/systick-timer.c | 107 
> 
>  2 files changed, 109 insertions(+)
>  create mode 100644 arch/arm/cpu/armv7m/systick-timer.c
> 
> diff --git a/arch/arm/cpu/armv7m/Makefile b/arch/arm/cpu/armv7m/Makefile 
> index aff60e8..e1a6c40 100644
> --- a/arch/arm/cpu/armv7m/Makefile
> +++ b/arch/arm/cpu/armv7m/Makefile
> @@ -7,3 +7,5 @@
> 
>  extra-y := start.o
>  obj-y += cpu.o
> +
> +obj-$(CONFIG_SYS_ARCH_TIMER) += systick-timer.o
> diff --git a/arch/arm/cpu/armv7m/systick-timer.c 
> b/arch/arm/cpu/armv7m/systick-timer.c
> new file mode 100644
> index 000..62308f9
> --- /dev/null
> +++ b/arch/arm/cpu/armv7m/systick-timer.c
> @@ -0,0 +1,107 @@
> +/*
> + * ARM Cortex M3/M4/M7 SysTick timer driver
> + * (C) Copyright 2017 Renesas Electronics Europe Ltd
> + *
> + * Based on arch/arm/mach-stm32/stm32f1/timer.c
> + * (C) Copyright 2015
> + * Kamil Lulko, 
> + *
> + * Copyright 2015 ATS Advanced Telematics Systems GmbH
> + * Copyright 2015 Konsulko Group, Matt Porter 
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + *
> + * The SysTick timer is a 24-bit count down timer. The clock can be
> +either the
> + * CPU clock or a reference clock. Since the timer will wrap around
> +very quickly
> + * when using the CPU clock, and we do not handle the timer interrupts,
> +it is
> + * expected that this driver is only ever used with a slow reference clock.
> + */
> +
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/* SysTick Base Address - fixed for all Cortex M3, M4 and M7 devices */
> +#define SYSTICK_BASE 0xE000E010
> +
> +struct cm3_systick {
> + uint32_t ctrl;
> + uint32_t reload_val;
> + uint32_t current_val;
> + uint32_t calibration;
> +};
> +
> +#define TIMER_MAX_VAL0x00FF
> +#define SYSTICK_CTRL_EN  BIT(0)
> +/* Clock source: 0 = Ref clock, 1 = CPU clock */
> +#define SYSTICK_CTRL_CPU_CLK BIT(2)
> +#define SYSTICK_CAL_NOREFBIT(31)
> +#define SYSTICK_CAL_SKEW BIT(30)
> +#define SYSTICK_CAL_TENMS_MASK   0x00FF
> +
> +/* read the 24-bit timer */
> +static ulong read_timer(void)
> +{
> + struct cm3_systick *systick = (struct cm3_systick *)SYSTICK_BASE;
> +
> + /* The timer counts down, therefore convert to an incrementing timer */
> + return TIMER_MAX_VAL - readl(>current_val); }
> +
> +int timer_init(void)
> +{
> + struct cm3_systick *systick = (struct cm3_systick *)SYSTICK_BASE;
> + u32 cal;
> +
> + writel(TIMER_MAX_VAL, >reload_val);
> + /* Any write to current_val reg clears it to 0 */
> + writel(0, >current_val);
> +
> + cal = readl(>calibration);
> + if (cal & SYSTICK_CAL_NOREF)

Good.

> + /* Use CPU clock, no interrupts */
> + writel(SYSTICK_CTRL_EN | SYSTICK_CTRL_CPU_CLK, >ctrl);
> + else
> + /* Use external clock, no interrupts */
> + writel(SYSTICK_CTRL_EN, >ctrl);
> +
> +#if defined(CONFIG_SYS_HZ_CLOCK)
> + gd->arch.timer_rate_hz = CONFIG_SYS_HZ_CLOCK; #else
> + gd->arch.timer_rate_hz = (cal & SYSTICK_CAL_TENMS_MASK) * 100;

This value is implementation dependent, it can't replace CONFIG_SYS_HZ_CLOCK.

Let me explain a bit,
Here the assumption is  calibration value is always 1ms at any systick clock 
frequency which is not true. Different arm vendors
write different values in this register to have timer value for 1 or 10 ms at 
one particular clock frequency, on top of it this particular frequency
is also different for all vendors.

Otherwise,
Reviewed-by: Vikas MANOCHA 

Cheers,
Vikas

> #endif
> +
> + gd->arch.tbl = 0;
> + gd->arch.tbu = 0;
> + gd->arch.lastinc = read_timer();
> +
> + return 0;
> +}
> +
> +/* return milli-seconds timer value */
> +ulong get_timer(ulong base)
> +{
> + unsigned long long t = get_ticks() * 1000;
> +
> + return (ulong)((t / gd->arch.timer_rate_hz)) - base; }
> +
> +unsigned long long get_ticks(void)
> +{
> + u32 now = read_timer();
> +
> + if (now >= 

[U-Boot] [PATCH v2 10/10] armv8: layerscape: Update early MMU for DDR after initialization

2017-02-15 Thread York Sun
In early MMU table, DDR has to be mapped as device memory to avoid
speculative access. After DDR is initialized, it needs to be updated
to normal memory to allow code execution. To simplify the code,
dram_init() is moved into a common file as a weak function.

Signed-off-by: York Sun 

---

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 76 ++
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h | 12 +++-
 arch/arm/include/asm/arch-fsl-layerscape/mmu.h |  2 +-
 board/freescale/ls1012afrdm/ls1012afrdm.c  |  5 ++
 board/freescale/ls1012aqds/ls1012aqds.c|  5 ++
 board/freescale/ls1012ardb/ls1012ardb.c|  5 ++
 board/freescale/ls1043aqds/ls1043aqds.c|  5 ++
 board/freescale/ls1043ardb/ls1043ardb.c|  7 ---
 board/freescale/ls1046aqds/ls1046aqds.c|  5 ++
 board/freescale/ls1046ardb/ls1046ardb.c|  7 ---
 board/freescale/ls2080a/ls2080a.c  |  7 ---
 board/freescale/ls2080aqds/ls2080aqds.c|  7 ---
 board/freescale/ls2080ardb/ls2080ardb.c|  8 +--
 13 files changed, 113 insertions(+), 38 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index fcf8a75..b3bfa5b 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -769,3 +769,79 @@ void efi_add_known_memory(void)
}
 }
 #endif
+
+/*
+ * Before DDR size is known, early MMU table have DDR mapped as device memory
+ * to avoid speculative access. To relocate U-Boot to DDR, "normal memory"
+ * needs to be set for these mappings.
+ * If a special case configures DDR with holes in the mapping, the holes need
+ * to be marked as invalid. This is not implemented in this function.
+ */
+void update_early_mmu_table(void)
+{
+   if (!gd->arch.tlb_addr)
+   return;
+
+   if (gd->ram_size <= CONFIG_SYS_FSL_DRAM_SIZE1) {
+   mmu_change_region_attr(
+   CONFIG_SYS_SDRAM_BASE,
+   gd->ram_size,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+   } else {
+   mmu_change_region_attr(
+   CONFIG_SYS_SDRAM_BASE,
+   CONFIG_SYS_DDR_BLOCK1_SIZE,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+#ifdef CONFIG_SYS_DDR_BLOCK3_BASE
+#ifndef CONFIG_SYS_DDR_BLOCK2_SIZE
+#error "Missing CONFIG_SYS_DDR_BLOCK2_SIZE"
+#endif
+   if (gd->ram_size - CONFIG_SYS_DDR_BLOCK1_SIZE >
+   CONFIG_SYS_DDR_BLOCK2_SIZE) {
+   mmu_change_region_attr(
+   CONFIG_SYS_DDR_BLOCK2_BASE,
+   CONFIG_SYS_DDR_BLOCK2_SIZE,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+   mmu_change_region_attr(
+   CONFIG_SYS_DDR_BLOCK3_BASE,
+   gd->ram_size -
+   CONFIG_SYS_DDR_BLOCK1_SIZE -
+   CONFIG_SYS_DDR_BLOCK2_SIZE,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+   } else
+#endif
+   {
+   mmu_change_region_attr(
+   CONFIG_SYS_DDR_BLOCK2_BASE,
+   gd->ram_size -
+   CONFIG_SYS_DDR_BLOCK1_SIZE,
+   PTE_BLOCK_MEMTYPE(MT_NORMAL)|
+   PTE_BLOCK_OUTER_SHARE   |
+   PTE_BLOCK_NS|
+   PTE_TYPE_VALID);
+   }
+   }
+}
+
+__weak int dram_init(void)
+{
+   gd->ram_size = initdram(0);
+#if !defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD)
+   /* This will break-before-make MMU for DDR */
+   update_early_mmu_table();
+#endif
+
+   return 0;
+}
diff --git 

[U-Boot] [PATCH v2 07/10] armv8: layerscape: Update MMU mapping with actual DDR size

2017-02-15 Thread York Sun
Update mapping with actual DDR size. Non-existing memory should not
be mapped as "normal" memory to avoid speculative access.

Signed-off-by: York Sun 
---

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 42 +++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 36451a2..800ad62 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -101,12 +101,50 @@ static inline void final_mmu_setup(void)
 {
u64 tlb_addr_save = gd->arch.tlb_addr;
unsigned int el = current_el();
-#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
int index;
-#endif
 
mem_map = final_map;
 
+   /* Update mapping for DDR to actual size */
+   for (index = 0; index < ARRAY_SIZE(final_map) - 2; index++) {
+   /*
+* Find the entry for DDR mapping and update the address and
+* size. Zero-sized mapping will be skipped when creating MMU
+* table.
+*/
+   switch (final_map[index].virt) {
+   case CONFIG_SYS_FSL_DRAM_BASE1:
+   final_map[index].virt = gd->bd->bi_dram[0].start;
+   final_map[index].phys = gd->bd->bi_dram[0].start;
+   final_map[index].size = gd->bd->bi_dram[0].size;
+   break;
+#ifdef CONFIG_SYS_FSL_DRAM_BASE2
+   case CONFIG_SYS_FSL_DRAM_BASE2:
+#if (CONFIG_NR_DRAM_BANKS >= 2)
+   final_map[index].virt = gd->bd->bi_dram[1].start;
+   final_map[index].phys = gd->bd->bi_dram[1].start;
+   final_map[index].size = gd->bd->bi_dram[1].size;
+#else
+   final_map[index].size = 0;
+#endif
+   break;
+#endif
+#ifdef CONFIG_SYS_FSL_DRAM_BASE3
+   case CONFIG_SYS_FSL_DRAM_BASE3:
+#if (CONFIG_NR_DRAM_BANKS >= 3)
+   final_map[index].virt = gd->bd->bi_dram[2].start;
+   final_map[index].phys = gd->bd->bi_dram[2].start;
+   final_map[index].size = gd->bd->bi_dram[2].size;
+#else
+   final_map[index].size = 0;
+#endif
+   break;
+#endif
+   default:
+   break;
+   }
+   }
+
 #ifdef CONFIG_SYS_MEM_RESERVE_SECURE
if (gd->arch.secure_ram & MEM_RESERVE_SECURE_MAINTAINED) {
if (el == 3) {
-- 
2.7.4

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


[U-Boot] [PATCH v2 05/10] armv8: layerscape: Rewrite memory reservation

2017-02-15 Thread York Sun
For ARMv8 Layerscape SoCs, secure memory and MC memorey are reserved
at the end of DDR. DDR is spit into two or three banks. This patch
reverts commit aabd7ddb and simplifies the calculation of reserved
memory, and moves the code into common SoC file. Secure memory is
carved out first. DDR bank size is reduced. Reserved memory is then
allocated on the top of available memory. U-Boot still has access
to reserved memory as data transferring is needed. Device tree is
fixed with reduced memory size to hide the reserved memory from OS.
The same region is reserved for efi_loader.

Signed-off-by: York Sun 

---

Changes in v2:
  Implement SoC level efi_add_known_memory(). DP-DDR is skipped so no
  need to add it as reserved memory later.

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c   | 198 +-
 arch/arm/include/asm/arch-fsl-layerscape/config.h |   4 +-
 board/freescale/ls1012afrdm/ls1012afrdm.c |  29 
 board/freescale/ls1012aqds/ls1012aqds.c   |  29 
 board/freescale/ls1012ardb/ls1012ardb.c   |  29 
 board/freescale/ls1043aqds/ddr.c  |  29 
 board/freescale/ls1043ardb/ddr.c  |  29 
 board/freescale/ls1046aqds/ddr.c  |  29 
 board/freescale/ls1046ardb/ddr.c  |  29 
 board/freescale/ls2080a/ddr.c |  55 --
 board/freescale/ls2080a/ls2080a.c |  10 ++
 board/freescale/ls2080aqds/ddr.c  |  55 --
 board/freescale/ls2080aqds/ls2080aqds.c   |  10 ++
 board/freescale/ls2080ardb/ddr.c  |  55 --
 board/freescale/ls2080ardb/ls2080ardb.c   |  18 +-
 common/board_f.c  |  32 +---
 drivers/net/fsl-mc/mc.c   |  16 +-
 17 files changed, 233 insertions(+), 423 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 335f225..36451a2 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -524,15 +524,201 @@ phys_size_t board_reserve_ram_top(phys_size_t ram_size)
 {
phys_size_t ram_top = ram_size;
 
-#ifdef CONFIG_SYS_MEM_TOP_HIDE
-#error CONFIG_SYS_MEM_TOP_HIDE not to be used together with this function
-#endif
-
-/* Carve the MC private DRAM block from the end of DRAM */
 #ifdef CONFIG_FSL_MC_ENET
+   /* The start address of MC reserved memory needs to be aligned. */
ram_top -= mc_get_dram_block_size();
ram_top &= ~(CONFIG_SYS_MC_RSV_MEM_ALIGN - 1);
 #endif
 
-   return ram_top;
+   return ram_size - ram_top;
+}
+
+phys_size_t get_effective_memsize(void)
+{
+   phys_size_t ea_size, rem = 0;
+
+   /*
+* For ARMv8 SoCs, DDR memory is split into two or three regions. The
+* first region is 2GB space at 0x8000_. If the memory extends to
+* the second region (or the third region if applicable), the secure
+* memory and Management Complex (MC) memory should be put into the
+* highest region, i.e. the end of DDR memory. CONFIG_MAX_MEM_MAPPED
+* is set to the size of first region so U-Boot doesn't relocate itself
+* into higher address. Should DDR be configured to skip the first
+* region, this function needs to be adjusted.
+*/
+   if (gd->ram_size > CONFIG_MAX_MEM_MAPPED) {
+   ea_size = CONFIG_MAX_MEM_MAPPED;
+   rem = gd->ram_size - ea_size;
+   } else {
+   ea_size = gd->ram_size;
+   }
+
+#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
+   /* Check if we have enough space for secure memory */
+   if (rem > CONFIG_SYS_MEM_RESERVE_SECURE) {
+   rem -= CONFIG_SYS_MEM_RESERVE_SECURE;
+   } else {
+   if (ea_size > CONFIG_SYS_MEM_RESERVE_SECURE) {
+   ea_size -= CONFIG_SYS_MEM_RESERVE_SECURE;
+   rem = 0;/* Presume MC requires more memory */
+   } else {
+   printf("Error: No enough space for secure memory.\n");
+   }
+   }
+#endif
+   /* Check if we have enough memory for MC */
+   if (rem < board_reserve_ram_top(rem)) {
+   /* Not enough memory in high region to reserve */
+   if (ea_size > board_reserve_ram_top(rem))
+   ea_size -= board_reserve_ram_top(rem);
+   else
+   printf("Error: No enough space for reserved memory.\n");
+   }
+
+   return ea_size;
+}
+
+void dram_init_banksize(void)
+{
+#ifdef CONFIG_SYS_DP_DDR_BASE_PHY
+   phys_size_t dp_ddr_size;
+#endif
+
+   /*
+* gd->ram_size has the total size of DDR memory, less reserved secure
+* memory. The DDR extends from low region to high region(s) presuming
+* no hole is created with DDR configuration. gd->arch.secure_ram tracks
+* the location of secure 

[U-Boot] [PATCH v2 00/10] Rewrite ARMv8 layerscape MMU

2017-02-15 Thread York Sun
A recent debug revealed MMU for DDR shouldn't be enabled before
DDR is initialized. Otherwise, a "normal memory" mapping may cause
speculative access which may hang the system if accessing to DDR
is not allowed at time.  For Layerscape platforms, we have early
MMU setup to speed up execution on emulators. The solution is to
update MMU after DDR is ready. The same idea goes to final MMU as
well. Actual DDR size is used to create the mappings. Non-exist
address should be marked as "fault", i.e. invalid to avoid unwanted
speculative access.

Aside from the DDR size, reserved memory used for secure RAM and
Management Complex (MC) makes things more complicated. To simplify
it, a new global is added to track the reserved RAM. Secure RAM
is excluded from U-Boot MMU. The reserved RAM is still mapped
under U-Boot since we will need to copy data into it. Reserved
RAM is excluded when device tree is fixed up so OS won't see it.
An SoC level efi_add_known_memory() is implemented to add valid
memory banks. DP-DDR is not added as memory.

Some MC configurations are moved to Kconfig.

Verified on LS2080ARDB with regular Linux boot and distro boot from USB.

Changes in v2:
  Add change to efi mapping
  Implement SoC level efi_add_known_memory(). DP-DDR is skipped so no
  need to add it as reserved memory later.

York Sun (10):
  armv8: Add global variable resv_ram
  armv8: ls2080a: Move CONFIG_FSL_MC_ENET to Kconfig
  armv8: ls2080a: Move CONFIG_SYS_MC_RSV_MEM_ALIGN to Kconfig
  efi: Add a hook to allow adding memory mapping
  armv8: layerscape: Rewrite memory reservation
  driver: net: fsl-mc: Update calculation of MC RAM
  armv8: layerscape: Update MMU mapping with actual DDR size
  armv8: layerscape: Flush MMU tables after creattion
  armv8: mmu: Add a function to change mapping attributes
  armv8: layerscape: Update early MMU for DDR after initialization

 arch/arm/cpu/armv8/cache_v8.c |  72 -
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig |  22 ++
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c   | 325 +-
 arch/arm/include/asm/arch-fsl-layerscape/config.h |   4 +-
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h|  12 +-
 arch/arm/include/asm/arch-fsl-layerscape/mmu.h|   2 +-
 arch/arm/include/asm/armv8/mmu.h  |   5 +
 arch/arm/include/asm/global_data.h|   3 +
 arch/arm/include/asm/system.h |   1 +
 board/freescale/ls1012afrdm/ls1012afrdm.c |  34 +--
 board/freescale/ls1012aqds/ls1012aqds.c   |  34 +--
 board/freescale/ls1012ardb/ls1012ardb.c   |  34 +--
 board/freescale/ls1043aqds/ddr.c  |  29 --
 board/freescale/ls1043aqds/ls1043aqds.c   |   5 +
 board/freescale/ls1043ardb/ddr.c  |  29 --
 board/freescale/ls1043ardb/ls1043ardb.c   |   7 -
 board/freescale/ls1046aqds/ddr.c  |  29 --
 board/freescale/ls1046aqds/ls1046aqds.c   |   5 +
 board/freescale/ls1046ardb/ddr.c  |  29 --
 board/freescale/ls1046ardb/ls1046ardb.c   |   7 -
 board/freescale/ls2080a/ddr.c |  55 
 board/freescale/ls2080a/ls2080a.c |  17 +-
 board/freescale/ls2080aqds/ddr.c  |  55 
 board/freescale/ls2080aqds/ls2080aqds.c   |  17 +-
 board/freescale/ls2080ardb/ddr.c  |  55 
 board/freescale/ls2080ardb/ls2080ardb.c   |  26 +-
 cmd/bdinfo.c  |   4 +
 common/board_f.c  |  32 +--
 drivers/net/fsl-mc/mc.c   |  75 +
 include/configs/ls2080a_common.h  |   2 -
 lib/efi_loader/efi_memory.c   |  14 +-
 scripts/config_whitelist.txt  |   2 -
 32 files changed, 516 insertions(+), 526 deletions(-)

-- 
2.7.4

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


[U-Boot] [PATCH v2 09/10] armv8: mmu: Add a function to change mapping attributes

2017-02-15 Thread York Sun
Function mmu_change_region_attr() is added to change existing mapping
with updated PXN, UXN and memory type. This is a break-before-make
process during which the mapping becomes fault (invalid) before final
attributres are set.

Signed-off-by: York Sun 
---

Changes in v2: None

 arch/arm/cpu/armv8/cache_v8.c| 72 +---
 arch/arm/include/asm/armv8/mmu.h |  5 +++
 arch/arm/include/asm/system.h|  1 +
 3 files changed, 74 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 6c5630c..bd1c3e0 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -501,7 +501,8 @@ static bool is_aligned(u64 addr, u64 size, u64 align)
return !(addr & (align - 1)) && !(size & (align - 1));
 }
 
-static u64 set_one_region(u64 start, u64 size, u64 attrs, int level)
+/* Use flag to indicate if attrs has more than d-cache attributes */
+static u64 set_one_region(u64 start, u64 size, u64 attrs, bool flag, int level)
 {
int levelshift = level2shift(level);
u64 levelsize = 1ULL << levelshift;
@@ -509,8 +510,13 @@ static u64 set_one_region(u64 start, u64 size, u64 attrs, 
int level)
 
/* Can we can just modify the current level block PTE? */
if (is_aligned(start, size, levelsize)) {
-   *pte &= ~PMD_ATTRINDX_MASK;
-   *pte |= attrs;
+   if (flag) {
+   *pte &= ~PMD_ATTRMASK;
+   *pte |= attrs & PMD_ATTRMASK;
+   } else {
+   *pte &= ~PMD_ATTRINDX_MASK;
+   *pte |= attrs & PMD_ATTRINDX_MASK;
+   }
debug("Set attrs=%llx pte=%p level=%d\n", attrs, pte, level);
 
return levelsize;
@@ -560,7 +566,8 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
u64 r;
 
for (level = 1; level < 4; level++) {
-   r = set_one_region(start, size, attrs, level);
+   /* Set d-cache attributes only */
+   r = set_one_region(start, size, attrs, false, level);
if (r) {
/* PTE successfully replaced */
size -= r;
@@ -581,6 +588,63 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start, 
size_t size,
flush_dcache_range(real_start, real_start + real_size);
 }
 
+/*
+ * Modify MMU table for a region with updated PXN/UXN/Memory type/valid bits.
+ * The procecess is break-before-make. The target region will be marked as
+ * invalid during the process of changing.
+ */
+void mmu_change_region_attr(phys_addr_t addr, size_t siz, u64 attrs)
+{
+   int level;
+   u64 r, size, start;
+
+   start = addr;
+   size = siz;
+   /*
+* Loop through the address range until we find a page granule that fits
+* our alignment constraints, then set it to "invalid".
+*/
+   while (size > 0) {
+   for (level = 1; level < 4; level++) {
+   /* Set PTE to fault */
+   r = set_one_region(start, size, PTE_TYPE_FAULT, true,
+  level);
+   if (r) {
+   /* PTE successfully invalidated */
+   size -= r;
+   start += r;
+   break;
+   }
+   }
+   }
+
+   flush_dcache_range(gd->arch.tlb_addr,
+  gd->arch.tlb_addr + gd->arch.tlb_size);
+   __asm_invalidate_tlb_all();
+
+   /*
+* Loop through the address range until we find a page granule that fits
+* our alignment constraints, then set it to the new cache attributes
+*/
+   start = addr;
+   size = siz;
+   while (size > 0) {
+   for (level = 1; level < 4; level++) {
+   /* Set PTE to new attributes */
+   r = set_one_region(start, size, attrs, true, level);
+   if (r) {
+   /* PTE successfully updated */
+   size -= r;
+   start += r;
+   break;
+   }
+   }
+   }
+   flush_dcache_range(gd->arch.tlb_addr,
+  gd->arch.tlb_addr + gd->arch.tlb_size);
+   __asm_invalidate_tlb_all();
+}
+
 #else  /* CONFIG_SYS_DCACHE_OFF */
 
 /*
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index e9b4cdb..a349903 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -53,6 +53,7 @@
 #define PTE_TYPE_FAULT (0 << 0)
 #define PTE_TYPE_TABLE (3 << 0)
 #define PTE_TYPE_BLOCK (1 << 0)
+#define PTE_TYPE_VALID   

[U-Boot] [PATCH v2 08/10] armv8: layerscape: Flush MMU tables after creattion

2017-02-15 Thread York Sun
MMU tables should be flushed if current code runs with d-cache on. This
applies to early MMU tables with SPL boot, and all final MMU tables.

Signed-off-by: York Sun 
---

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 800ad62..fcf8a75 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -80,6 +80,13 @@ static inline void early_mmu_setup(void)
/* Create early page tables */
setup_pgtables();
 
+
+#if defined(CONFIG_SPL) || !defined(CONFIG_SPL_BUILD)
+   /* For SPL RAM boot, cache is enabled. MMU table needs to be flushed */
+   flush_dcache_range(gd->arch.tlb_addr,
+  gd->arch.tlb_addr + gd->arch.tlb_size);
+#endif
+
/* point TTBR to the new table */
set_ttbr_tcr_mair(el, gd->arch.tlb_addr,
  get_tcr(el, NULL, NULL) &
@@ -184,6 +191,8 @@ static inline void final_mmu_setup(void)
/* flush new MMU table */
flush_dcache_range(gd->arch.tlb_addr,
   gd->arch.tlb_addr + gd->arch.tlb_size);
+   flush_dcache_range(gd->arch.tlb_emerg,
+  gd->arch.tlb_emerg + gd->arch.tlb_size);
 
/* point TTBR to the new table */
set_ttbr_tcr_mair(el, gd->arch.tlb_addr, get_tcr(el, NULL, NULL),
-- 
2.7.4

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


[U-Boot] [PATCH v2 02/10] armv8: ls2080a: Move CONFIG_FSL_MC_ENET to Kconfig

2017-02-15 Thread York Sun
Use Kconfig option instead of config macro in header file.
Clean up existing usage.

Signed-off-by: York Sun 
---

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 8 
 include/configs/ls2080a_common.h  | 1 -
 scripts/config_whitelist.txt  | 1 -
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index a40556f..ad9c982 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -85,6 +85,14 @@ config FSL_LSCH3
select SYS_FSL_SRDS_1
select SYS_HAS_SERDES
 
+config FSL_MC_ENET
+   bool "Management Complex network"
+   depends on ARCH_LS2080A
+   default y
+   select RESV_RAM_TOP
+   help
+ Enable Management Complex (MC) network
+
 menu "Layerscape architecture"
depends on FSL_LSCH2 || FSL_LSCH3
 
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 7aef43f..1b86578 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -147,7 +147,6 @@ unsigned long long get_qixis_addr(void);
 #define CONFIG_SYS_NAND_BASE_PHYS  0x3000
 
 /* MC firmware */
-#define CONFIG_FSL_MC_ENET
 /* TODO Actual DPL max length needs to be confirmed with the MC FW team */
 #define CONFIG_SYS_LS_MC_DPC_MAX_LENGTH0x2
 #define CONFIG_SYS_LS_MC_DRAM_DPC_OFFSET0x00F0
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index d21589b..9af403a 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1196,7 +1196,6 @@ CONFIG_FSL_LAYERSCAPE
 CONFIG_FSL_LBC
 CONFIG_FSL_LINFLEXUART
 CONFIG_FSL_MC9SDZ60
-CONFIG_FSL_MC_ENET
 CONFIG_FSL_MEMAC
 CONFIG_FSL_NFC_CHIPS
 CONFIG_FSL_NFC_SPARE_SIZE
-- 
2.7.4

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


[U-Boot] [PATCH v2 04/10] efi: Add a hook to allow adding memory mapping

2017-02-15 Thread York Sun
Instead of adding all memory banks, add a hook so individual SoC/board
can has its own implementation.

Signed-off-by: York Sun 
CC: Alexander Graf 

---

Changes in v2:
  Add change to efi mapping

 lib/efi_loader/efi_memory.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 95aa590..db2ae19 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -431,11 +431,8 @@ efi_status_t efi_get_memory_map(unsigned long 
*memory_map_size,
return EFI_SUCCESS;
 }
 
-int efi_memory_init(void)
+__weak void efi_add_known_memory(void)
 {
-   unsigned long runtime_start, runtime_end, runtime_pages;
-   unsigned long uboot_start, uboot_pages;
-   unsigned long uboot_stack_size = 16 * 1024 * 1024;
int i;
 
/* Add RAM */
@@ -448,6 +445,15 @@ int efi_memory_init(void)
efi_add_memory_map(start, pages, EFI_CONVENTIONAL_MEMORY,
   false);
}
+}
+
+int efi_memory_init(void)
+{
+   unsigned long runtime_start, runtime_end, runtime_pages;
+   unsigned long uboot_start, uboot_pages;
+   unsigned long uboot_stack_size = 16 * 1024 * 1024;
+
+   efi_add_known_memory();
 
/* Add U-Boot */
uboot_start = (gd->start_addr_sp - uboot_stack_size) & ~EFI_PAGE_MASK;
-- 
2.7.4

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


[U-Boot] [PATCH v2 03/10] armv8: ls2080a: Move CONFIG_SYS_MC_RSV_MEM_ALIGN to Kconfig

2017-02-15 Thread York Sun
Use Kconfig option instead of config macro in header file.

Signed-off-by: York Sun 
---

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 8 
 include/configs/ls2080a_common.h  | 1 -
 scripts/config_whitelist.txt  | 1 -
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index ad9c982..55760ad 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -307,3 +307,11 @@ config SYS_FSL_ERRATUM_A009660
 
 config SYS_FSL_ERRATUM_A009929
bool
+
+config SYS_MC_RSV_MEM_ALIGN
+   hex "Management Complex reserved memory alignment"
+   depends on RESV_RAM_TOP
+   default 0x2000
+   help
+ Reserved memory needs to be aligned for MC to use. Default value
+ is 512MB.
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 1b86578..be15d38 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -164,7 +164,6 @@ unsigned long long get_qixis_addr(void);
  */
 #ifdef CONFIG_FSL_MC_ENET
 #define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE   (512UL * 1024 * 1024)
-#define CONFIG_SYS_MC_RSV_MEM_ALIGN(512UL * 1024 * 1024)
 #endif
 
 /* Command line configuration */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 9af403a..68685ce 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -5045,7 +5045,6 @@ CONFIG_SYS_MCKR_VAL
 CONFIG_SYS_MCLINK_MAX
 CONFIG_SYS_MCMEM0_VAL
 CONFIG_SYS_MCMEM1_VAL
-CONFIG_SYS_MC_RSV_MEM_ALIGN
 CONFIG_SYS_MDC1_PIN
 CONFIG_SYS_MDCNFG_VAL
 CONFIG_SYS_MDC_PIN
-- 
2.7.4

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


[U-Boot] [PATCH v2 06/10] driver: net: fsl-mc: Update calculation of MC RAM

2017-02-15 Thread York Sun
Since the reserved RAM is tracked by gd->arch.resv_ram, calculation
of MC memory blocks can be simplified. The MC RAM is guaranteed to be
aligned by the reservation process.

Signed-off-by: York Sun 
CC: Priyanka Jain 
---

Changes in v2: None

 drivers/net/fsl-mc/mc.c | 59 +++--
 1 file changed, 8 insertions(+), 51 deletions(-)

diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 231a6d5..9f69d75 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -154,48 +154,6 @@ int parse_mc_firmware_fit_image(u64 mc_fw_addr,
 }
 #endif
 
-/*
- * Calculates the values to be used to specify the address range
- * for the MC private DRAM block, in the MCFBALR/MCFBAHR registers.
- * It returns the highest 512MB-aligned address within the given
- * address range, in '*aligned_base_addr', and the number of 256 MiB
- * blocks in it, in 'num_256mb_blocks'.
- */
-static int calculate_mc_private_ram_params(u64 mc_private_ram_start_addr,
-  size_t mc_ram_size,
-  u64 *aligned_base_addr,
-  u8 *num_256mb_blocks)
-{
-   u64 addr;
-   u16 num_blocks;
-
-   if (mc_ram_size % MC_RAM_SIZE_ALIGNMENT != 0) {
-   printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
-  mc_ram_size);
-   return -EINVAL;
-   }
-
-   num_blocks = mc_ram_size / MC_RAM_SIZE_ALIGNMENT;
-   if (num_blocks < 1 || num_blocks > 0xff) {
-   printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
-  mc_ram_size);
-   return -EINVAL;
-   }
-
-   addr = (mc_private_ram_start_addr + mc_ram_size - 1) &
-   MC_RAM_BASE_ADDR_ALIGNMENT_MASK;
-
-   if (addr < mc_private_ram_start_addr) {
-   printf("fsl-mc: ERROR: bad start address %#llx\n",
-  mc_private_ram_start_addr);
-   return -EFAULT;
-   }
-
-   *aligned_base_addr = addr;
-   *num_256mb_blocks = num_blocks;
-   return 0;
-}
-
 static int mc_fixup_dpc_mac_addr(void *blob, int noff, int dpmac_id,
struct eth_device *eth_dev)
 {
@@ -550,17 +508,16 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
size_t raw_image_size = 0;
 #endif
struct mc_version mc_ver_info;
-   u64 mc_ram_aligned_base_addr;
u8 mc_ram_num_256mb_blocks;
size_t mc_ram_size = mc_get_dram_block_size();
 
-
-   error = calculate_mc_private_ram_params(mc_ram_addr,
-   mc_ram_size,
-   _ram_aligned_base_addr,
-   _ram_num_256mb_blocks);
-   if (error != 0)
+   mc_ram_num_256mb_blocks = mc_ram_size / MC_RAM_SIZE_ALIGNMENT;
+   if (mc_ram_num_256mb_blocks < 1 || mc_ram_num_256mb_blocks > 0xff) {
+   error = -EINVAL;
+   printf("fsl-mc: ERROR: invalid MC private RAM size (%lu)\n",
+  mc_ram_size);
goto out;
+   }
 
/*
 * Management Complex cores should be held at reset out of POR.
@@ -602,11 +559,11 @@ int mc_init(u64 mc_fw_addr, u64 mc_dpc_addr)
/*
 * Tell MC what is the address range of the DRAM block assigned to it:
 */
-   reg_mcfbalr = (u32)mc_ram_aligned_base_addr |
+   reg_mcfbalr = (u32)mc_ram_addr |
  (mc_ram_num_256mb_blocks - 1);
out_le32(_ccsr_regs->reg_mcfbalr, reg_mcfbalr);
out_le32(_ccsr_regs->reg_mcfbahr,
-(u32)(mc_ram_aligned_base_addr >> 32));
+(u32)(mc_ram_addr >> 32));
out_le32(_ccsr_regs->reg_mcfapr, FSL_BYPASS_AMQ);
 
/*
-- 
2.7.4

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


[U-Boot] [PATCH v2 01/10] armv8: Add global variable resv_ram

2017-02-15 Thread York Sun
Use gd->arch.resv_ram to track reserved memory allocation.

Signed-off-by: York Sun 
---

Changes in v2: None

 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 6 ++
 arch/arm/include/asm/global_data.h| 3 +++
 cmd/bdinfo.c  | 4 
 3 files changed, 13 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index adccdf1..a40556f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -273,6 +273,12 @@ config SYS_FSL_SDHC_CLK_DIV
  clock, in another word SDHC_clk = Platform_clk / this_divider.
 endmenu
 
+config RESV_RAM_TOP
+   bool
+   help
+ Reserve memory from the top, tracked by gd->arch.resv_ram. It's up
+ to implementation to allow access to this reserved memory or not.
+
 config SYS_FSL_ERRATUM_A008336
bool
 
diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index aee87cd..b1fc410 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -59,6 +59,9 @@ struct arch_global_data {
phys_addr_t secure_ram;
unsigned long tlb_allocated;
 #endif
+#ifdef CONFIG_RESV_RAM_TOP
+   phys_addr_t resv_ram;
+#endif
 
 #ifdef CONFIG_ARCH_OMAP2
u32 omap_boot_device;
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index ae3027a..0c5fa56 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -392,6 +392,10 @@ static int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
  gd->arch.secure_ram & MEM_RESERVE_SECURE_ADDR_MASK);
}
 #endif
+#ifdef CONFIG_RESV_RAM_TOP
+   if (gd->arch.resv_ram)
+   print_num("Reserved ram", gd->arch.resv_ram);
+#endif
 #if defined(CONFIG_CMD_NET) && !defined(CONFIG_DM_ETH)
print_eths();
 #endif
-- 
2.7.4

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


Re: [U-Boot] [PATCH v2] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-15 Thread Marek Vasut
On 02/15/2017 10:48 PM, Dalon Westergreen wrote:
> On Wed, 2017-02-15 at 22:15 +0100, Marek Vasut wrote:
>> On 02/14/2017 07:28 PM, Dalon Westergreen wrote:
>>>
>>> When CSEL=0x0 the socfpga bootrom does not touch the clock
>>> configuration for the device.  This can lead to a boot failure
>>> on warm resets.  To address this, the bootrom is configured to
>>> run a bit of code in the last 4KB of onchip ram on a warm reset.
>>> This code puts the PLLs in bypass, disables the bootrom configuration
>>> to run the code snippet, and issues a warm reset to run the bootrom.
>>>
>>> Signed-off-by: Dalon Westergreen 
>>>
>>> --
>>> Changes in V2:
>>>  - Fix checkpatch issues predominently due to whitespace issues
>>> ---
>>>  arch/arm/mach-socfpga/Makefile |  2 +-
>>>  arch/arm/mach-socfpga/include/mach/clock_manager.h | 26 +++-
>>>  arch/arm/mach-socfpga/include/mach/reset_manager.h |  4 ++
>>>  .../arm/mach-socfpga/include/mach/system_manager.h |  7 ++-
>>>  arch/arm/mach-socfpga/misc.c   | 27 
>>>  arch/arm/mach-socfpga/reset_clock_manager.S| 71
>>> ++
>>>  6 files changed, 134 insertions(+), 3 deletions(-)
>>>  create mode 100644 arch/arm/mach-socfpga/reset_clock_manager.S
>>>
>>> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
>>> index 809cd47..6876ccf 100644
>>> --- a/arch/arm/mach-socfpga/Makefile
>>> +++ b/arch/arm/mach-socfpga/Makefile
>>> @@ -8,7 +8,7 @@
>>>  #
>>>  
>>>  obj-y  += misc.o timer.o reset_manager.o system_manager.o
>>> clock_manager.o \
>>> -  fpga_manager.o board.o
>>> +  fpga_manager.o board.o reset_clock_manager.o
>>>  
>>>  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
>>>  
>>> diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager.h
>>> b/arch/arm/mach-socfpga/include/mach/clock_manager.h
>>> index 803c926..78f63a4 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
>>> @@ -19,9 +19,12 @@ const unsigned int cm_get_osc_clk_hz(const int osc);
>>>  const unsigned int cm_get_f2s_per_ref_clk_hz(void);
>>>  const unsigned int cm_get_f2s_sdr_ref_clk_hz(void);
>>>  
>>> +/* Onchip RAM functions for CSEL=0 */
>>> +void reset_clock_manager(void);
>>> +extern unsigned reset_clock_manager_size;
>>> +
>>>  /* Clock configuration accessors */
>>>  const struct cm_config * const cm_get_default_config(void);
>>> -#endif
>>>  
>>>  struct cm_config {
>>> /* main group */
>>> @@ -127,6 +130,19 @@ struct socfpga_clock_manager {
>>> struct socfpga_clock_manager_altera altera;
>>> u32 _pad_0xe8_0x200[70];
>>>  };
>>> +#endif
>>> +
>>> +#define CLKMGR_CTRL_ADDRESS 0x0
>>
>> Is this the same as struct socfpga_clock_manager {} ?
>> Why ?
> It is, just defining offsets to use in the assembly calls

The asm is IMO not needed

>>
>>>
>>> +#define CLKMGR_BYPASS_ADDRESS 0x4
>>> +#define CLKMGR_INTER_ADDRESS 0x8
>>> +#define CLKMGR_INTREN_ADDRESS 0xc
>>> +#define CLKMGR_DBCTRL_ADDRESS 0x10
>>> +#define CLKMGR_STAT_ADDRESS 0x14
>>> +#define CLKMGR_MAINPLLGRP_MAINQSPICLK_ADDRESS 0x54
>>> +#define CLKMGR_MAINPLLGRP_MAINNANDSDMMCCLK_ADDRESS 0x58
>>> +#define CLKMGR_PERPLLGRP_PERQSPICLK_ADDRESS 0x90
>>> +#define CLKMGR_PERPLLGRP_PERNANDSDMMCCLK_ADDRESS 0x94
>>> +
>>>  
>>>  #define CLKMGR_CTRL_SAFEMODE   (1 << 0)
>>>  #define CLKMGR_CTRL_SAFEMODE_OFFSET0
>>> @@ -314,4 +330,12 @@ struct socfpga_clock_manager {
>>>  #define CLKMGR_SDRPLLGRP_S2FUSER2CLK_PHASE_OFFSET  9
>>>  #define CLKMGR_SDRPLLGRP_S2FUSER2CLK_PHASE_MASK0x0e00
>>>  
>>> +/* Bypass Main and Per PLL, bypass source per input mux */
>>> +#define CLKMGR_BYPASS_MAIN_PER_PLL_MASK 0x19
>>> +   
>>>  
>>> +#define CLKMGR_MAINQSPICLK_RESET_VALUE  0x3
>>> +#define CLKMGR_MAINNANDSDMMCCLK_RESET_VALUE 0x3
>>> +#define CLKMGR_PERQSPICLK_RESET_VALUE   0x1
>>> +#define CLKMGR_PERNANDSDMMCCLK_RESET_VALUE  0x1
>>> +
>>>  #endif /* _CLOCK_MANAGER_H_ */
>>> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
>>> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
>>> index 2f070f2..58d77fb 100644
>>> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
>>> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
>>> @@ -7,6 +7,7 @@
>>>  #ifndef_RESET_MANAGER_H_
>>>  #define_RESET_MANAGER_H_
>>>  
>>> +#ifndef __ASSEMBLY__
>>>  void reset_cpu(ulong addr);
>>>  void reset_deassert_peripherals_handoff(void);
>>>  
>>> @@ -28,6 +29,8 @@ struct socfpga_reset_manager {
>>> u32 padding2[12];
>>> u32 tstscratch;
>>>  };
>>> +#endif
>>> +
>>>  
>>>  #if defined(CONFIG_SOCFPGA_VIRTUAL_TARGET)
>>>  #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 2
>>> @@ -40,6 +43,7 @@ struct socfpga_reset_manager {
>>>   * and reset ID can be extracted 

Re: [U-Boot] [PATCH 13/13] mips: jz47xx: Add Creator CI20 platform

2017-02-15 Thread Marek Vasut
On 02/15/2017 10:50 PM, Tom Rini wrote:
> On Wed, Feb 15, 2017 at 09:46:38PM +0100, Marek Vasut wrote:
>> On 02/15/2017 12:11 AM, Tom Rini wrote:
>>> On Wed, Feb 15, 2017 at 12:03:32AM +0100, Marek Vasut wrote:
 On 02/14/2017 11:58 PM, Tom Rini wrote:
> On Sun, Feb 12, 2017 at 12:52:45PM +0100, Andreas Färber wrote:
>> Hi Marek,
>>
>> Am 01.12.2016 um 02:06 schrieb Marek Vasut:
>>> From: Paul Burton 
>>>
>>> Add support for the Creator CI20 platform based on the JZ4780 SoC.
>>> The DTS file comes from Linux 4.6 as of revision
>>> 78800558d104e003f9ae92e0107f1de39cf9de9f
>>>
>>> So far, there are still a few details which will have to be fixed
>>> once they are fleshed out in Linux:
>>> - pinmux: Thus far, this board just pokes the pinmux registers to
>>>   set the pinmux. For MMC in SPL, this will have to stay.
>>>   But for full u-boot a proper pinmux driver will have to
>>>   be added once the pinmux semantics in DT are in mainline
>>>   Linux.
>>> - ethernet,efuse: DT bindings are missing from mainline Linux.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Daniel Schwierzeck 
>>> Cc: Paul Burton 
>>> ---
>>>  arch/mips/dts/Makefile|   1 +
>>>  arch/mips/dts/ci20.dts| 114 ++
>>>  arch/mips/mach-jz47xx/Kconfig |  11 ++
>>>  board/imgtec/ci20/Kconfig |  35 +
>>>  board/imgtec/ci20/Makefile|   5 +
>>>  board/imgtec/ci20/README  |  10 ++
>>>  board/imgtec/ci20/ci20.c  | 354 
>>> ++
>>>  configs/ci20_defconfig|  28 
>>>  include/configs/ci20.h| 105 +
>>>  9 files changed, 663 insertions(+)
>>>  create mode 100644 arch/mips/dts/ci20.dts
>>>  create mode 100644 board/imgtec/ci20/Kconfig
>>>  create mode 100644 board/imgtec/ci20/Makefile
>>>  create mode 100644 board/imgtec/ci20/README
>>>  create mode 100644 board/imgtec/ci20/ci20.c
>>>  create mode 100644 configs/ci20_defconfig
>>>  create mode 100644 include/configs/ci20.h
>>
>> I've looked into testing the remainder of this patchset, not seeing a
>> newer version. You can find my branch here:
>>
>> https://github.com/afaerber/u-boot/commits/ci20
> [snip]
>>   LD  spl/u-boot-spl
>> mipsel-suse-linux-ld.bfd: u-boot-spl section `.data' will not fit in
>> region `.sram'
>> mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes
>
> I can recreate that too here real quick, but can't test out changes on
> my Ci20 right now.  Can you try:
>
> diff --git a/include/configs/ci20.h b/include/configs/ci20.h
> index 4503adb..9e2ad7b 100644
> --- a/include/configs/ci20.h
> +++ b/include/configs/ci20.h
> @@ -70,10 +70,10 @@
>  /* SPL */
>  #define CONFIG_SPL_FRAMEWORK
>  
> -#define CONFIG_SPL_STACK 0xf4008000 /* only max. 2KB spare! */
> +#define CONFIG_SPL_STACK 0xf4008200 /* only max. 1.5KB spare! */
>  
>  #define CONFIG_SPL_TEXT_BASE 0xf4000a00
> -#define CONFIG_SPL_MAX_SIZE  ((14 * 1024) - 0xa00)
> +#define CONFIG_SPL_MAX_SIZE  ((14 * 1024) - 0x800)

 This will not work, the stack is configured at it's limit already.

>  #define CONFIG_SPL_BSS_START_ADDR0xf4004000
>  #define CONFIG_SPL_BSS_MAX_SIZE  0x2000 /* 512KB, arbitrary 
> */
>
>
> Now, off the top of my head I'm only giving myself a 50/50 chance of
> having moved the stack address in the correct direction.  And note that
> I don't know why we say only max of 2KB for stack, and then ensure we
> have 2.5KB of room, but I've shifted 512 bytes from one side to the
> other.  And it's quite probable that we should make use having SPL stack
> get moved into DDR

 You mean the DDR which you init in the SPL ? :)
>>>
>>> Yes, I mean the DDR which we init in the SPL, after we've init'd it, so
>>> that we can work more comfortably in cramped and constrained spaces.
>>
>> You know, you are still limited by the 14 kiB load limit of the BootROM.
>> I think there's more than 16 kiB of SRAM total, so there's no real
>> problem with the stack. The problem is that 14 kiB load limit of the
>> BootROM, it will NOT LOAD MORE than 14 kiB of code . I tried (because,
>> well, 14 kiB is too small). IT DOES NOT WORK.
> 
> Can we use those last 2KiB of SRAM for our stack or does that freak out
> the BootROM?

IIRC I tried pretty much everything to squeeze more space out of this
chip and this is the only thing that worked.

> If so, we should tweak the above definitions to set the
> hard limit at 14 * SZ_1K and put stack at 0xf4004200 ?

Be my guest, research the hell out of this 

Re: [U-Boot] [PATCH 4/9] armv8: layerscape: Rewrite memory reservation

2017-02-15 Thread Alexander Graf



On 15/02/2017 19:52, york sun wrote:

Reduce CC list.

On 02/14/2017 11:56 AM, Alexander Graf wrote:



On 14/02/2017 18:38, york sun wrote:

On 02/14/2017 09:00 AM, york@nxp.com wrote:

On 02/14/2017 07:31 AM, Alexander Graf wrote:



On 14/02/2017 04:45, York Sun wrote:

For ARMv8 Layerscape SoCs, secure memory and MC memorey are reserved
at the end of DDR. DDR is spit into two or three banks. This patch
reverts commit aabd7ddb and simplifies the calculation of reserved
memory, and moves the code into common SoC file. Secure memory is
carved out first. DDR bank size is reduced. Reserved memory is then
allocated on the top of available memory. U-Boot still has access
to reserved memory as data transferring is needed. Device tree is
fixed with reduced memory size to hide the reserved memory from OS.


I haven't looked in detail, but could you please ensure that you also
reserve those regions in the efi_loader memory map?


I missed efi reserved memory map. Will add in v2 patch.



Alex,

Is the misc_init_r() the best place to add such reservation under your
code dealing with DP_DDR? It is per board code. As of now, we only have
ls2080ardb with efi boot.


Ideally I'd like to make sure efi boot works on all boards, not just
individual ones. So if you find a more generic place that gets called
after efi_memory_init(), that would be great.

Since you add a global kconfig define for reserved memory, you can even
do it inside efi_memory_init() directly for the top-of-ram region.



Alex,

I am thinking to add a weak function efi_add_known_memory() to do the
work you have at the beginning of efi_memory_init(). Then I will add
this function to arch/arm/cpu/armv8/fsl-layerscape/cpu.c. Since the SoC
file has the knowledge of DP-DDR and how memory is reserved, it can be
easily added without risking breaking anything else.


That's certainly a possibility, yes :).


By the way, I failed to run distro boot as I set up before. I am going
to re-download the DVD ISO file and deploy it again to my USB thumb
drive. Any tips on running it without installation, i.e. live CD mode? I
remember last time I did some trick to drop to the shell.


Grub should give you a rescue menu item which gets you into a shell, 
yes. Inside the installer you can also exit into a very minimalistic 
shell if you like, but it's not very powerful.



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


Re: [U-Boot] [PATCH 13/13] mips: jz47xx: Add Creator CI20 platform

2017-02-15 Thread Tom Rini
On Wed, Feb 15, 2017 at 09:46:38PM +0100, Marek Vasut wrote:
> On 02/15/2017 12:11 AM, Tom Rini wrote:
> > On Wed, Feb 15, 2017 at 12:03:32AM +0100, Marek Vasut wrote:
> >> On 02/14/2017 11:58 PM, Tom Rini wrote:
> >>> On Sun, Feb 12, 2017 at 12:52:45PM +0100, Andreas Färber wrote:
>  Hi Marek,
> 
>  Am 01.12.2016 um 02:06 schrieb Marek Vasut:
> > From: Paul Burton 
> >
> > Add support for the Creator CI20 platform based on the JZ4780 SoC.
> > The DTS file comes from Linux 4.6 as of revision
> > 78800558d104e003f9ae92e0107f1de39cf9de9f
> >
> > So far, there are still a few details which will have to be fixed
> > once they are fleshed out in Linux:
> > - pinmux: Thus far, this board just pokes the pinmux registers to
> >   set the pinmux. For MMC in SPL, this will have to stay.
> >   But for full u-boot a proper pinmux driver will have to
> >   be added once the pinmux semantics in DT are in mainline
> >   Linux.
> > - ethernet,efuse: DT bindings are missing from mainline Linux.
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Daniel Schwierzeck 
> > Cc: Paul Burton 
> > ---
> >  arch/mips/dts/Makefile|   1 +
> >  arch/mips/dts/ci20.dts| 114 ++
> >  arch/mips/mach-jz47xx/Kconfig |  11 ++
> >  board/imgtec/ci20/Kconfig |  35 +
> >  board/imgtec/ci20/Makefile|   5 +
> >  board/imgtec/ci20/README  |  10 ++
> >  board/imgtec/ci20/ci20.c  | 354 
> > ++
> >  configs/ci20_defconfig|  28 
> >  include/configs/ci20.h| 105 +
> >  9 files changed, 663 insertions(+)
> >  create mode 100644 arch/mips/dts/ci20.dts
> >  create mode 100644 board/imgtec/ci20/Kconfig
> >  create mode 100644 board/imgtec/ci20/Makefile
> >  create mode 100644 board/imgtec/ci20/README
> >  create mode 100644 board/imgtec/ci20/ci20.c
> >  create mode 100644 configs/ci20_defconfig
> >  create mode 100644 include/configs/ci20.h
> 
>  I've looked into testing the remainder of this patchset, not seeing a
>  newer version. You can find my branch here:
> 
>  https://github.com/afaerber/u-boot/commits/ci20
> >>> [snip]
>    LD  spl/u-boot-spl
>  mipsel-suse-linux-ld.bfd: u-boot-spl section `.data' will not fit in
>  region `.sram'
>  mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes
> >>>
> >>> I can recreate that too here real quick, but can't test out changes on
> >>> my Ci20 right now.  Can you try:
> >>>
> >>> diff --git a/include/configs/ci20.h b/include/configs/ci20.h
> >>> index 4503adb..9e2ad7b 100644
> >>> --- a/include/configs/ci20.h
> >>> +++ b/include/configs/ci20.h
> >>> @@ -70,10 +70,10 @@
> >>>  /* SPL */
> >>>  #define CONFIG_SPL_FRAMEWORK
> >>>  
> >>> -#define CONFIG_SPL_STACK 0xf4008000 /* only max. 2KB spare! */
> >>> +#define CONFIG_SPL_STACK 0xf4008200 /* only max. 1.5KB spare! */
> >>>  
> >>>  #define CONFIG_SPL_TEXT_BASE 0xf4000a00
> >>> -#define CONFIG_SPL_MAX_SIZE  ((14 * 1024) - 0xa00)
> >>> +#define CONFIG_SPL_MAX_SIZE  ((14 * 1024) - 0x800)
> >>
> >> This will not work, the stack is configured at it's limit already.
> >>
> >>>  #define CONFIG_SPL_BSS_START_ADDR0xf4004000
> >>>  #define CONFIG_SPL_BSS_MAX_SIZE  0x2000 /* 512KB, arbitrary 
> >>> */
> >>>
> >>>
> >>> Now, off the top of my head I'm only giving myself a 50/50 chance of
> >>> having moved the stack address in the correct direction.  And note that
> >>> I don't know why we say only max of 2KB for stack, and then ensure we
> >>> have 2.5KB of room, but I've shifted 512 bytes from one side to the
> >>> other.  And it's quite probable that we should make use having SPL stack
> >>> get moved into DDR
> >>
> >> You mean the DDR which you init in the SPL ? :)
> > 
> > Yes, I mean the DDR which we init in the SPL, after we've init'd it, so
> > that we can work more comfortably in cramped and constrained spaces.
> 
> You know, you are still limited by the 14 kiB load limit of the BootROM.
> I think there's more than 16 kiB of SRAM total, so there's no real
> problem with the stack. The problem is that 14 kiB load limit of the
> BootROM, it will NOT LOAD MORE than 14 kiB of code . I tried (because,
> well, 14 kiB is too small). IT DOES NOT WORK.

Can we use those last 2KiB of SRAM for our stack or does that freak out
the BootROM?  If so, we should tweak the above definitions to set the
hard limit at 14 * SZ_1K and put stack at 0xf4004200 ?  Where is
0xf4008000 in the memory map?

> >>> , but I don't have the memory map handy either (and
> >>> based on the above snippets I'm confused as CONFIG_SPL_BSS_START_ADDR
> >>> should be in DDR space, I don't know 

Re: [U-Boot] [PATCH v2] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-15 Thread Dalon Westergreen
On Wed, 2017-02-15 at 22:15 +0100, Marek Vasut wrote:
> On 02/14/2017 07:28 PM, Dalon Westergreen wrote:
> > 
> > When CSEL=0x0 the socfpga bootrom does not touch the clock
> > configuration for the device.  This can lead to a boot failure
> > on warm resets.  To address this, the bootrom is configured to
> > run a bit of code in the last 4KB of onchip ram on a warm reset.
> > This code puts the PLLs in bypass, disables the bootrom configuration
> > to run the code snippet, and issues a warm reset to run the bootrom.
> > 
> > Signed-off-by: Dalon Westergreen 
> > 
> > --
> > Changes in V2:
> >  - Fix checkpatch issues predominently due to whitespace issues
> > ---
> >  arch/arm/mach-socfpga/Makefile |  2 +-
> >  arch/arm/mach-socfpga/include/mach/clock_manager.h | 26 +++-
> >  arch/arm/mach-socfpga/include/mach/reset_manager.h |  4 ++
> >  .../arm/mach-socfpga/include/mach/system_manager.h |  7 ++-
> >  arch/arm/mach-socfpga/misc.c   | 27 
> >  arch/arm/mach-socfpga/reset_clock_manager.S| 71
> > ++
> >  6 files changed, 134 insertions(+), 3 deletions(-)
> >  create mode 100644 arch/arm/mach-socfpga/reset_clock_manager.S
> > 
> > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
> > index 809cd47..6876ccf 100644
> > --- a/arch/arm/mach-socfpga/Makefile
> > +++ b/arch/arm/mach-socfpga/Makefile
> > @@ -8,7 +8,7 @@
> >  #
> >  
> >  obj-y  += misc.o timer.o reset_manager.o system_manager.o
> > clock_manager.o \
> > -      fpga_manager.o board.o
> > +      fpga_manager.o board.o reset_clock_manager.o
> >  
> >  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
> >  
> > diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > index 803c926..78f63a4 100644
> > --- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > +++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > @@ -19,9 +19,12 @@ const unsigned int cm_get_osc_clk_hz(const int osc);
> >  const unsigned int cm_get_f2s_per_ref_clk_hz(void);
> >  const unsigned int cm_get_f2s_sdr_ref_clk_hz(void);
> >  
> > +/* Onchip RAM functions for CSEL=0 */
> > +void reset_clock_manager(void);
> > +extern unsigned reset_clock_manager_size;
> > +
> >  /* Clock configuration accessors */
> >  const struct cm_config * const cm_get_default_config(void);
> > -#endif
> >  
> >  struct cm_config {
> >     /* main group */
> > @@ -127,6 +130,19 @@ struct socfpga_clock_manager {
> >     struct socfpga_clock_manager_altera altera;
> >     u32 _pad_0xe8_0x200[70];
> >  };
> > +#endif
> > +
> > +#define CLKMGR_CTRL_ADDRESS 0x0
> 
> Is this the same as struct socfpga_clock_manager {} ?
> Why ?
It is, just defining offsets to use in the assembly calls
> 
> > 
> > +#define CLKMGR_BYPASS_ADDRESS 0x4
> > +#define CLKMGR_INTER_ADDRESS 0x8
> > +#define CLKMGR_INTREN_ADDRESS 0xc
> > +#define CLKMGR_DBCTRL_ADDRESS 0x10
> > +#define CLKMGR_STAT_ADDRESS 0x14
> > +#define CLKMGR_MAINPLLGRP_MAINQSPICLK_ADDRESS 0x54
> > +#define CLKMGR_MAINPLLGRP_MAINNANDSDMMCCLK_ADDRESS 0x58
> > +#define CLKMGR_PERPLLGRP_PERQSPICLK_ADDRESS 0x90
> > +#define CLKMGR_PERPLLGRP_PERNANDSDMMCCLK_ADDRESS 0x94
> > +
> >  
> >  #define CLKMGR_CTRL_SAFEMODE   (1 << 0)
> >  #define CLKMGR_CTRL_SAFEMODE_OFFSET0
> > @@ -314,4 +330,12 @@ struct socfpga_clock_manager {
> >  #define CLKMGR_SDRPLLGRP_S2FUSER2CLK_PHASE_OFFSET  9
> >  #define CLKMGR_SDRPLLGRP_S2FUSER2CLK_PHASE_MASK0x0e00
> >  
> > +/* Bypass Main and Per PLL, bypass source per input mux */
> > +#define CLKMGR_BYPASS_MAIN_PER_PLL_MASK 0x19
> > +   
> >  
> > +#define CLKMGR_MAINQSPICLK_RESET_VALUE  0x3
> > +#define CLKMGR_MAINNANDSDMMCCLK_RESET_VALUE 0x3
> > +#define CLKMGR_PERQSPICLK_RESET_VALUE   0x1
> > +#define CLKMGR_PERNANDSDMMCCLK_RESET_VALUE  0x1
> > +
> >  #endif /* _CLOCK_MANAGER_H_ */
> > diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > index 2f070f2..58d77fb 100644
> > --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > @@ -7,6 +7,7 @@
> >  #ifndef_RESET_MANAGER_H_
> >  #define_RESET_MANAGER_H_
> >  
> > +#ifndef __ASSEMBLY__
> >  void reset_cpu(ulong addr);
> >  void reset_deassert_peripherals_handoff(void);
> >  
> > @@ -28,6 +29,8 @@ struct socfpga_reset_manager {
> >     u32 padding2[12];
> >     u32 tstscratch;
> >  };
> > +#endif
> > +
> >  
> >  #if defined(CONFIG_SOCFPGA_VIRTUAL_TARGET)
> >  #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 2
> > @@ -40,6 +43,7 @@ struct socfpga_reset_manager {
> >   * and reset ID can be extracted using the subsequent macros
> >   * RSTMGR_RESET() and RSTMGR_BANK().
> >   */
> 

Re: [U-Boot] [PATCH v2] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-15 Thread Marek Vasut
On 02/14/2017 07:28 PM, Dalon Westergreen wrote:
> When CSEL=0x0 the socfpga bootrom does not touch the clock
> configuration for the device.  This can lead to a boot failure
> on warm resets.  To address this, the bootrom is configured to
> run a bit of code in the last 4KB of onchip ram on a warm reset.
> This code puts the PLLs in bypass, disables the bootrom configuration
> to run the code snippet, and issues a warm reset to run the bootrom.
> 
> Signed-off-by: Dalon Westergreen 
> 
> --
> Changes in V2:
>  - Fix checkpatch issues predominently due to whitespace issues
> ---
>  arch/arm/mach-socfpga/Makefile |  2 +-
>  arch/arm/mach-socfpga/include/mach/clock_manager.h | 26 +++-
>  arch/arm/mach-socfpga/include/mach/reset_manager.h |  4 ++
>  .../arm/mach-socfpga/include/mach/system_manager.h |  7 ++-
>  arch/arm/mach-socfpga/misc.c   | 27 
>  arch/arm/mach-socfpga/reset_clock_manager.S| 71 
> ++
>  6 files changed, 134 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/mach-socfpga/reset_clock_manager.S
> 
> diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
> index 809cd47..6876ccf 100644
> --- a/arch/arm/mach-socfpga/Makefile
> +++ b/arch/arm/mach-socfpga/Makefile
> @@ -8,7 +8,7 @@
>  #
>  
>  obj-y+= misc.o timer.o reset_manager.o system_manager.o 
> clock_manager.o \
> -fpga_manager.o board.o
> +fpga_manager.o board.o reset_clock_manager.o
>  
>  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
>  
> diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager.h 
> b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> index 803c926..78f63a4 100644
> --- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> @@ -19,9 +19,12 @@ const unsigned int cm_get_osc_clk_hz(const int osc);
>  const unsigned int cm_get_f2s_per_ref_clk_hz(void);
>  const unsigned int cm_get_f2s_sdr_ref_clk_hz(void);
>  
> +/* Onchip RAM functions for CSEL=0 */
> +void reset_clock_manager(void);
> +extern unsigned reset_clock_manager_size;
> +
>  /* Clock configuration accessors */
>  const struct cm_config * const cm_get_default_config(void);
> -#endif
>  
>  struct cm_config {
>   /* main group */
> @@ -127,6 +130,19 @@ struct socfpga_clock_manager {
>   struct socfpga_clock_manager_altera altera;
>   u32 _pad_0xe8_0x200[70];
>  };
> +#endif
> +
> +#define CLKMGR_CTRL_ADDRESS 0x0

Is this the same as struct socfpga_clock_manager {} ?
Why ?

> +#define CLKMGR_BYPASS_ADDRESS 0x4
> +#define CLKMGR_INTER_ADDRESS 0x8
> +#define CLKMGR_INTREN_ADDRESS 0xc
> +#define CLKMGR_DBCTRL_ADDRESS 0x10
> +#define CLKMGR_STAT_ADDRESS 0x14
> +#define CLKMGR_MAINPLLGRP_MAINQSPICLK_ADDRESS 0x54
> +#define CLKMGR_MAINPLLGRP_MAINNANDSDMMCCLK_ADDRESS 0x58
> +#define CLKMGR_PERPLLGRP_PERQSPICLK_ADDRESS 0x90
> +#define CLKMGR_PERPLLGRP_PERNANDSDMMCCLK_ADDRESS 0x94
> +
>  
>  #define CLKMGR_CTRL_SAFEMODE (1 << 0)
>  #define CLKMGR_CTRL_SAFEMODE_OFFSET  0
> @@ -314,4 +330,12 @@ struct socfpga_clock_manager {
>  #define CLKMGR_SDRPLLGRP_S2FUSER2CLK_PHASE_OFFSET9
>  #define CLKMGR_SDRPLLGRP_S2FUSER2CLK_PHASE_MASK  0x0e00
>  
> +/* Bypass Main and Per PLL, bypass source per input mux */
> +#define CLKMGR_BYPASS_MAIN_PER_PLL_MASK 0x19
> + 
>
> +#define CLKMGR_MAINQSPICLK_RESET_VALUE  0x3
> +#define CLKMGR_MAINNANDSDMMCCLK_RESET_VALUE 0x3
> +#define CLKMGR_PERQSPICLK_RESET_VALUE   0x1
> +#define CLKMGR_PERNANDSDMMCCLK_RESET_VALUE  0x1
> +
>  #endif /* _CLOCK_MANAGER_H_ */
> diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
> b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> index 2f070f2..58d77fb 100644
> --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> @@ -7,6 +7,7 @@
>  #ifndef  _RESET_MANAGER_H_
>  #define  _RESET_MANAGER_H_
>  
> +#ifndef __ASSEMBLY__
>  void reset_cpu(ulong addr);
>  void reset_deassert_peripherals_handoff(void);
>  
> @@ -28,6 +29,8 @@ struct socfpga_reset_manager {
>   u32 padding2[12];
>   u32 tstscratch;
>  };
> +#endif
> +
>  
>  #if defined(CONFIG_SOCFPGA_VIRTUAL_TARGET)
>  #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 2
> @@ -40,6 +43,7 @@ struct socfpga_reset_manager {
>   * and reset ID can be extracted using the subsequent macros
>   * RSTMGR_RESET() and RSTMGR_BANK().
>   */
> +#define RSTMGR_CTRL_OFFSET   4
>  #define RSTMGR_BANK_OFFSET   8
>  #define RSTMGR_BANK_MASK 0x7
>  #define RSTMGR_RESET_OFFSET  0
> diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h 
> b/arch/arm/mach-socfpga/include/mach/system_manager.h
> index c45edea..b89f269 100644
> --- 

Re: [U-Boot] [PATCH 13/13] mips: jz47xx: Add Creator CI20 platform

2017-02-15 Thread Marek Vasut
On 02/15/2017 12:11 AM, Tom Rini wrote:
> On Wed, Feb 15, 2017 at 12:03:32AM +0100, Marek Vasut wrote:
>> On 02/14/2017 11:58 PM, Tom Rini wrote:
>>> On Sun, Feb 12, 2017 at 12:52:45PM +0100, Andreas Färber wrote:
 Hi Marek,

 Am 01.12.2016 um 02:06 schrieb Marek Vasut:
> From: Paul Burton 
>
> Add support for the Creator CI20 platform based on the JZ4780 SoC.
> The DTS file comes from Linux 4.6 as of revision
> 78800558d104e003f9ae92e0107f1de39cf9de9f
>
> So far, there are still a few details which will have to be fixed
> once they are fleshed out in Linux:
> - pinmux: Thus far, this board just pokes the pinmux registers to
>   set the pinmux. For MMC in SPL, this will have to stay.
> But for full u-boot a proper pinmux driver will have to
> be added once the pinmux semantics in DT are in mainline
> Linux.
> - ethernet,efuse: DT bindings are missing from mainline Linux.
>
> Signed-off-by: Marek Vasut 
> Cc: Daniel Schwierzeck 
> Cc: Paul Burton 
> ---
>  arch/mips/dts/Makefile|   1 +
>  arch/mips/dts/ci20.dts| 114 ++
>  arch/mips/mach-jz47xx/Kconfig |  11 ++
>  board/imgtec/ci20/Kconfig |  35 +
>  board/imgtec/ci20/Makefile|   5 +
>  board/imgtec/ci20/README  |  10 ++
>  board/imgtec/ci20/ci20.c  | 354 
> ++
>  configs/ci20_defconfig|  28 
>  include/configs/ci20.h| 105 +
>  9 files changed, 663 insertions(+)
>  create mode 100644 arch/mips/dts/ci20.dts
>  create mode 100644 board/imgtec/ci20/Kconfig
>  create mode 100644 board/imgtec/ci20/Makefile
>  create mode 100644 board/imgtec/ci20/README
>  create mode 100644 board/imgtec/ci20/ci20.c
>  create mode 100644 configs/ci20_defconfig
>  create mode 100644 include/configs/ci20.h

 I've looked into testing the remainder of this patchset, not seeing a
 newer version. You can find my branch here:

 https://github.com/afaerber/u-boot/commits/ci20
>>> [snip]
   LD  spl/u-boot-spl
 mipsel-suse-linux-ld.bfd: u-boot-spl section `.data' will not fit in
 region `.sram'
 mipsel-suse-linux-ld.bfd: region `.sram' overflowed by 288 bytes
>>>
>>> I can recreate that too here real quick, but can't test out changes on
>>> my Ci20 right now.  Can you try:
>>>
>>> diff --git a/include/configs/ci20.h b/include/configs/ci20.h
>>> index 4503adb..9e2ad7b 100644
>>> --- a/include/configs/ci20.h
>>> +++ b/include/configs/ci20.h
>>> @@ -70,10 +70,10 @@
>>>  /* SPL */
>>>  #define CONFIG_SPL_FRAMEWORK
>>>  
>>> -#define CONFIG_SPL_STACK   0xf4008000 /* only max. 2KB spare! */
>>> +#define CONFIG_SPL_STACK   0xf4008200 /* only max. 1.5KB spare! */
>>>  
>>>  #define CONFIG_SPL_TEXT_BASE   0xf4000a00
>>> -#define CONFIG_SPL_MAX_SIZE((14 * 1024) - 0xa00)
>>> +#define CONFIG_SPL_MAX_SIZE((14 * 1024) - 0x800)
>>
>> This will not work, the stack is configured at it's limit already.
>>
>>>  #define CONFIG_SPL_BSS_START_ADDR  0xf4004000
>>>  #define CONFIG_SPL_BSS_MAX_SIZE0x2000 /* 512KB, arbitrary 
>>> */
>>>
>>>
>>> Now, off the top of my head I'm only giving myself a 50/50 chance of
>>> having moved the stack address in the correct direction.  And note that
>>> I don't know why we say only max of 2KB for stack, and then ensure we
>>> have 2.5KB of room, but I've shifted 512 bytes from one side to the
>>> other.  And it's quite probable that we should make use having SPL stack
>>> get moved into DDR
>>
>> You mean the DDR which you init in the SPL ? :)
> 
> Yes, I mean the DDR which we init in the SPL, after we've init'd it, so
> that we can work more comfortably in cramped and constrained spaces.

You know, you are still limited by the 14 kiB load limit of the BootROM.
I think there's more than 16 kiB of SRAM total, so there's no real
problem with the stack. The problem is that 14 kiB load limit of the
BootROM, it will NOT LOAD MORE than 14 kiB of code . I tried (because,
well, 14 kiB is too small). IT DOES NOT WORK.

>>> , but I don't have the memory map handy either (and
>>> based on the above snippets I'm confused as CONFIG_SPL_BSS_START_ADDR
>>> should be in DDR space, I don't know if internal memory directly follows
>>> into DDR here or what).
>>>
>>> I do want to reiterate that I am eager to have Ci20 be working in
>>> mainline as I have one and I want to figure out how to include it in my
>>> farm, or at least manual testing from time to time.  Thanks!
>>
>> Well, these patches were rotting on the list for year or so without
>> getting any attention, until the point I had to scream on the IRC to get
>> ANY review comments, multiple times, so I really see a lot of interest
>> in 

Re: [U-Boot] [PATCH v2] arm: socfpga: fix issue with warm reset when CSEL is 0

2017-02-15 Thread Marek Vasut
On 02/15/2017 07:56 AM, Chin Liang See wrote:
> On Sel, 2017-02-14 at 10:28 -0800, Dalon Westergreen wrote:
>> When CSEL=0x0 the socfpga bootrom does not touch the clock
>> configuration for the device.  This can lead to a boot failure
>> on warm resets.  To address this, the bootrom is configured to
>> run a bit of code in the last 4KB of onchip ram on a warm reset.
>> This code puts the PLLs in bypass, disables the bootrom configuration
>> to run the code snippet, and issues a warm reset to run the bootrom.
>>
>> Signed-off-by: Dalon Westergreen 
>>
>> --
>> Changes in V2:
>>  - Fix checkpatch issues predominently due to whitespace issues
>> ---
>>  arch/arm/mach-socfpga/Makefile |  2 +-
>>  arch/arm/mach-socfpga/include/mach/clock_manager.h | 26 +++-
>>  arch/arm/mach-socfpga/include/mach/reset_manager.h |  4 ++
>>  .../arm/mach-socfpga/include/mach/system_manager.h |  7 ++-
>>  arch/arm/mach-socfpga/misc.c   | 27 
>>  arch/arm/mach-socfpga/reset_clock_manager.S| 71
>> ++
>>  6 files changed, 134 insertions(+), 3 deletions(-)
>>  create mode 100644 arch/arm/mach-socfpga/reset_clock_manager.S
>>
>>
> 
> Acked-by: Chin Liang See 

Sorry, in this state, definitelly

Naked-by: Marek Vasut 

-- 
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 1/1] Secure Boot: Set NPSWA_EN bit for SNVS state transition to happen in EL2.

2017-02-15 Thread york sun
On 02/15/2017 04:23 AM, Udit Agarwal wrote:
> For Layerscape chasis Gen 3 based platforms, during PPA execution
> exception level transition happens from EL3 to EL2. While in EL2 state
> SNVS state doesnot changes from secure to non secure state in
> case of ESBC failure.
>
> So to enable the SNVS transition in EL2 state, NPSWA_EN bit has to be set
> when in EL3 state.

Wouldn't this be better implemented in PPA firmware?

York

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


Re: [U-Boot] [PATCH 4/9] armv8: layerscape: Rewrite memory reservation

2017-02-15 Thread york sun
Reduce CC list.

On 02/14/2017 11:56 AM, Alexander Graf wrote:
>
>
> On 14/02/2017 18:38, york sun wrote:
>> On 02/14/2017 09:00 AM, york@nxp.com wrote:
>>> On 02/14/2017 07:31 AM, Alexander Graf wrote:


 On 14/02/2017 04:45, York Sun wrote:
> For ARMv8 Layerscape SoCs, secure memory and MC memorey are reserved
> at the end of DDR. DDR is spit into two or three banks. This patch
> reverts commit aabd7ddb and simplifies the calculation of reserved
> memory, and moves the code into common SoC file. Secure memory is
> carved out first. DDR bank size is reduced. Reserved memory is then
> allocated on the top of available memory. U-Boot still has access
> to reserved memory as data transferring is needed. Device tree is
> fixed with reduced memory size to hide the reserved memory from OS.

 I haven't looked in detail, but could you please ensure that you also
 reserve those regions in the efi_loader memory map?
>>>
>>> I missed efi reserved memory map. Will add in v2 patch.
>>>
>>
>> Alex,
>>
>> Is the misc_init_r() the best place to add such reservation under your
>> code dealing with DP_DDR? It is per board code. As of now, we only have
>> ls2080ardb with efi boot.
>
> Ideally I'd like to make sure efi boot works on all boards, not just
> individual ones. So if you find a more generic place that gets called
> after efi_memory_init(), that would be great.
>
> Since you add a global kconfig define for reserved memory, you can even
> do it inside efi_memory_init() directly for the top-of-ram region.
>

Alex,

I am thinking to add a weak function efi_add_known_memory() to do the 
work you have at the beginning of efi_memory_init(). Then I will add 
this function to arch/arm/cpu/armv8/fsl-layerscape/cpu.c. Since the SoC 
file has the knowledge of DP-DDR and how memory is reserved, it can be 
easily added without risking breaking anything else.

By the way, I failed to run distro boot as I set up before. I am going 
to re-download the DVD ISO file and deploy it again to my USB thumb 
drive. Any tips on running it without installation, i.e. live CD mode? I 
remember last time I did some trick to drop to the shell.

York

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


[U-Boot] [PATCH v5 3/6] ARM: AM335x: Disable non-FIT based image loading for HS devices

2017-02-15 Thread Andrew F. Davis
Disable support for loading non-FIT images for AM335x platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 configs/am335x_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
index f2f92f70f6..fbb8f18912 100644
--- a/configs/am335x_hs_evm_defconfig
+++ b/configs/am335x_hs_evm_defconfig
@@ -14,6 +14,8 @@ CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SYS_EXTRA_OPTIONS="NAND"
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
-- 
2.11.0

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


[U-Boot] [PATCH v5 2/6] spl: Add option to enable SPL Legacy image support

2017-02-15 Thread Andrew F. Davis
Add a Kconfig option that enables Legacy image support, this allows
boards to explicitly disable this, for instance when needed for
security reasons.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 Kconfig  |  8 
 common/spl/spl.c | 10 --
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/Kconfig b/Kconfig
index cfc8f929ee..8504199493 100644
--- a/Kconfig
+++ b/Kconfig
@@ -299,6 +299,14 @@ config SPL_RAW_IMAGE_SUPPORT
  is y. If this is not set, SPL will move on to other available
  boot media to find a suitable image.
 
+config SPL_LEGACY_IMAGE_SUPPORT
+   bool "Support SPL loading and booting of Legacy images"
+   default y
+   help
+ SPL will support loading and booting Legacy images when this option
+ is y. If this is not set, SPL will move on to other available
+ boot media to find a suitable image.
+
 config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
int "CPU clock frequency"
diff --git a/common/spl/spl.c b/common/spl/spl.c
index da8f55eef6..3d6c0ecba1 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -93,9 +93,10 @@ void spl_set_header_raw_uboot(struct spl_image_info 
*spl_image)
 int spl_parse_image_header(struct spl_image_info *spl_image,
   const struct image_header *header)
 {
-   u32 header_size = sizeof(struct image_header);
-
if (image_get_magic(header) == IH_MAGIC) {
+#ifdef CONFIG_SPL_LEGACY_IMAGE_SUPPORT
+   u32 header_size = sizeof(struct image_header);
+
if (spl_image->flags & SPL_COPY_PAYLOAD_ONLY) {
/*
 * On some system (e.g. powerpc), the load-address and
@@ -118,6 +119,11 @@ int spl_parse_image_header(struct spl_image_info 
*spl_image,
debug("spl: payload image: %.*s load addr: 0x%lx size: %d\n",
(int)sizeof(spl_image->name), spl_image->name,
spl_image->load_addr, spl_image->size);
+#else
+   /* LEGACY image not supported */
+   debug("Legacy boot image support not enabled, proceeding to 
other boot methods");
+   return -EINVAL;
+#endif
} else {
 #ifdef CONFIG_SPL_PANIC_ON_RAW_IMAGE
/*
-- 
2.11.0

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


[U-Boot] [PATCH v5 0/6] Allow disabling non-FIT image loading from SPL

2017-02-15 Thread Andrew F. Davis
Hello all,

To address a needed feature brought up by Andreas[0], we need a way to
disable SPL from loading non-FIT images.

The function spl_parse_image_header is common to all SPL loading paths
(common/spl/spl_(nand|net|nor|etc..)) so we add the check here.

This version of the series is a bit different than the last 2 due
to suggestions by Simon, instead of a negative option disabling
non-FIT images, we allow the other image format's support to be
toggled off, and do that on HS boards.

Thanks,
Andrew

[0] https://www.mail-archive.com/u-boot@lists.denx.de/msg219253.html

Changes from v4:
 - Finish conversion of SPL_RAW_IMAGE_SUPPORT

Changes from v3:
 - Add debug print as suggested by Simon

Andrew F. Davis (6):
  spl: Convert CONFIG_SPL_ABORT_ON_RAW_IMAGE into a positive option
  spl: Add option to enable SPL Legacy image support
  ARM: AM335x: Disable non-FIT based image loading for HS devices
  ARM: AM43xx: Disable non-FIT based image loading for HS devices
  ARM: AM57xx: Disable non-FIT based image loading for HS devices
  ARM: DRA7xx: Disable non-FIT based image loading for HS devices

 Kconfig| 15 +++
 README |  4 
 common/spl/spl.c   | 20 ++--
 configs/am335x_hs_evm_defconfig|  2 ++
 configs/am43xx_hs_evm_defconfig|  2 ++
 configs/am57xx_hs_evm_defconfig|  2 ++
 configs/apalis_imx6_defconfig  |  1 +
 configs/cgtqmx6eval_defconfig  |  1 +
 configs/cm_fx6_defconfig   |  1 +
 configs/colibri_imx6_defconfig |  1 +
 configs/dra7xx_hs_evm_defconfig|  2 ++
 configs/gwventana_defconfig|  1 +
 configs/imx6dl_icore_mmc_defconfig |  1 +
 configs/imx6dl_icore_rqs_mmc_defconfig |  1 +
 configs/imx6q_icore_mmc_defconfig  |  1 +
 configs/imx6q_icore_rqs_mmc_defconfig  |  1 +
 configs/imx6ul_geam_mmc_defconfig  |  1 +
 configs/liteboard_defconfig|  1 +
 configs/mccmon6_sd_defconfig   |  1 +
 configs/mx6cuboxi_defconfig|  1 +
 configs/mx6sabresd_spl_defconfig   |  1 +
 configs/mx6slevk_spl_defconfig |  1 +
 configs/mx6sxsabresd_spl_defconfig |  1 +
 configs/mx6ul_14x14_evk_defconfig  |  1 +
 configs/mx6ul_9x9_evk_defconfig|  1 +
 configs/novena_defconfig   |  1 +
 configs/pcm058_defconfig   |  1 +
 configs/platinum_picon_defconfig   |  1 +
 configs/platinum_titanium_defconfig|  1 +
 configs/socfpga_de1_soc_defconfig  |  1 +
 configs/udoo_defconfig |  1 +
 configs/udoo_neo_defconfig |  1 +
 configs/wandboard_defconfig|  1 +
 configs/xpress_spl_defconfig   |  1 +
 configs/zc5202_defconfig   |  1 +
 configs/zc5601_defconfig   |  1 +
 include/configs/imx6_spl.h |  2 --
 include/configs/socfpga_de1_soc.h  |  2 --
 include/spl.h  |  2 +-
 39 files changed, 67 insertions(+), 15 deletions(-)

-- 
2.11.0

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


[U-Boot] [PATCH v5 5/6] ARM: AM57xx: Disable non-FIT based image loading for HS devices

2017-02-15 Thread Andrew F. Davis
Disable support for loading non-FIT images for AM57xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 configs/am57xx_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index 7e84ccddf3..4adbde427b 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -14,6 +14,8 @@ CONFIG_FIT=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.11.0

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


[U-Boot] [PATCH v5 1/6] spl: Convert CONFIG_SPL_ABORT_ON_RAW_IMAGE into a positive option

2017-02-15 Thread Andrew F. Davis
CONFIG_SPL_ABORT_ON_RAW_IMAGE causes SPL to abort and move on when it
encounters RAW images, express this same functionality as a positive
option enabling support for RAW images: CONFIG_SPL_RAW_IMAGE_SUPPORT

Also move uses of this to defconfigs.

Signed-off-by: Andrew F. Davis 
---
 Kconfig|  7 +++
 README |  4 
 common/spl/spl.c   | 10 ++
 configs/apalis_imx6_defconfig  |  1 +
 configs/cgtqmx6eval_defconfig  |  1 +
 configs/cm_fx6_defconfig   |  1 +
 configs/colibri_imx6_defconfig |  1 +
 configs/gwventana_defconfig|  1 +
 configs/imx6dl_icore_mmc_defconfig |  1 +
 configs/imx6dl_icore_rqs_mmc_defconfig |  1 +
 configs/imx6q_icore_mmc_defconfig  |  1 +
 configs/imx6q_icore_rqs_mmc_defconfig  |  1 +
 configs/imx6ul_geam_mmc_defconfig  |  1 +
 configs/liteboard_defconfig|  1 +
 configs/mccmon6_sd_defconfig   |  1 +
 configs/mx6cuboxi_defconfig|  1 +
 configs/mx6sabresd_spl_defconfig   |  1 +
 configs/mx6slevk_spl_defconfig |  1 +
 configs/mx6sxsabresd_spl_defconfig |  1 +
 configs/mx6ul_14x14_evk_defconfig  |  1 +
 configs/mx6ul_9x9_evk_defconfig|  1 +
 configs/novena_defconfig   |  1 +
 configs/pcm058_defconfig   |  1 +
 configs/platinum_picon_defconfig   |  1 +
 configs/platinum_titanium_defconfig|  1 +
 configs/socfpga_de1_soc_defconfig  |  1 +
 configs/udoo_defconfig |  1 +
 configs/udoo_neo_defconfig |  1 +
 configs/wandboard_defconfig|  1 +
 configs/xpress_spl_defconfig   |  1 +
 configs/zc5202_defconfig   |  1 +
 configs/zc5601_defconfig   |  1 +
 include/configs/imx6_spl.h |  2 --
 include/configs/socfpga_de1_soc.h  |  2 --
 include/spl.h  |  2 +-
 35 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/Kconfig b/Kconfig
index 81b4226463..cfc8f929ee 100644
--- a/Kconfig
+++ b/Kconfig
@@ -291,6 +291,13 @@ config SYS_TEXT_BASE
help
  TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture
 
+config SPL_RAW_IMAGE_SUPPORT
+   bool "Support SPL loading and booting of RAW images"
+   default y
+   help
+ SPL will support loading and booting a RAW image when this option
+ is y. If this is not set, SPL will move on to other available
+ boot media to find a suitable image.
 
 config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
diff --git a/README b/README
index 4f0dbd4fca..a45c6b88bf 100644
--- a/README
+++ b/README
@@ -3279,10 +3279,6 @@ FIT uImage format:
consider that a completely unreadable NAND block is bad,
and thus should be skipped silently.
 
-   CONFIG_SPL_ABORT_ON_RAW_IMAGE
-   When defined, SPL will proceed to another boot method
-   if the image it has loaded does not have a signature.
-
CONFIG_SPL_RELOC_STACK
Adress of the start of the stack SPL will use after
relocation.  If unspecified, this is equal to
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 766fb3d6f4..da8f55eef6 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -146,16 +146,18 @@ int spl_parse_image_header(struct spl_image_info 
*spl_image,
}
 #endif
 
-#ifdef CONFIG_SPL_ABORT_ON_RAW_IMAGE
-   /* Signature not found, proceed to other boot methods. */
-   return -EINVAL;
-#else
+#ifdef CONFIG_SPL_RAW_IMAGE_SUPPORT
/* Signature not found - assume u-boot.bin */
debug("mkimage signature not found - ih_magic = %x\n",
header->ih_magic);
spl_set_header_raw_uboot(spl_image);
+#else
+   /* RAW image not supported, proceed to other boot methods. */
+   debug("Raw boot image support not enabled, proceeding to other 
boot methods");
+   return -EINVAL;
 #endif
}
+
return 0;
 }
 
diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index 6b2daa9b47..d76b828c7d 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ -9,6 +9,7 @@ CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_VIDEO=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,MX6Q"
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_BOOTDELAY=1
 # CONFIG_CONSOLE_MUX is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
diff --git a/configs/cgtqmx6eval_defconfig b/configs/cgtqmx6eval_defconfig
index 2e4ed36cc1..7c73ac185a 100644
--- a/configs/cgtqmx6eval_defconfig
+++ b/configs/cgtqmx6eval_defconfig
@@ -14,6 +14,7 @@ CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_VIDEO=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6QDL"
+# 

[U-Boot] [PATCH v5 4/6] ARM: AM43xx: Disable non-FIT based image loading for HS devices

2017-02-15 Thread Andrew F. Davis
Disable support for loading non-FIT images for AM43xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 configs/am43xx_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index 8bb1b3535a..fabf876621 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -10,6 +10,8 @@ CONFIG_FIT=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1, NAND"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.11.0

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


[U-Boot] [PATCH v5 6/6] ARM: DRA7xx: Disable non-FIT based image loading for HS devices

2017-02-15 Thread Andrew F. Davis
Disable support for loading non-FIT images for DRA7xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 configs/dra7xx_hs_evm_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 244940cd6c..c5e7b16c8b 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -15,6 +15,8 @@ CONFIG_FIT=y
 CONFIG_FIT_IMAGE_POST_PROCESS=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
 CONFIG_VERSION_VARIABLE=y
-- 
2.11.0

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


Re: [U-Boot] [PATCH v4 1/6] spl: Convert CONFIG_SPL_ABORT_ON_RAW_IMAGE into a positive option

2017-02-15 Thread Andrew F. Davis
On 02/14/2017 03:04 PM, Tom Rini wrote:
> On Tue, Feb 14, 2017 at 02:32:42PM -0600, Andrew F. Davis wrote:
>> On 02/14/2017 02:15 PM, Tom Rini wrote:
>>> On Mon, Feb 13, 2017 at 12:47:36PM -0600, Andrew F. Davis wrote:
>>>
 CONFIG_SPL_ABORT_ON_RAW_IMAGE causes SPL to abort and move on when it
 encounters RAW images, express this same functionality as a positive
 option enabling support for RAW images: CONFIG_SPL_RAW_IMAGE_SUPPORT

 Signed-off-by: Andrew F. Davis 
 ---
  Kconfig   |  7 +++
  README|  4 
  common/spl/spl.c  | 10 ++
  include/configs/imx6_spl.h|  4 ++--
  include/configs/socfpga_de1_soc.h |  2 +-
>>>
>>> OK, with this in Kconfig, we need to migrate the appropriate configs/
>>> files rather than tweak include/configs/ files again.  I think
>>> moveconfig.py will be reasonable to run here given that you can pass a
>>> list of defconfigs to look at (anything that sets CONFIG_IMX6 and so
>>> on).  Thanks!
>>
>> It does, and it removes the symbols I tweaked in the include/configs/
>> automatically. The issue is that it also caused a lot of churn in the
>> defconfig files as a lot of symbols have become out of order and get
>> re-ordered. With other similar patches re-ordering defconfig symbols
>> this would be trouble for you to merge and for me to rebase if it needs
>> a re-spin. Maybe moveconfig.py could be done on your side when patches
>> like this are taken?
> 
> So in this case, the way you deal with it is:
> 1) Do a moveconfig.py -s and commit the results.
> 2) Do the rest of your patches
> 3) Drop that first patch and post.  If it doesn't apply cleanly
> (sometimes it in fact does), I end up dealing with the fallout.
> 
> It's easier for me to deal with fixing defconfig fails to apply than it
> is to be sure that everything is migrated correctly and as intended.
> 

Works for me, I'll post v5 with this change.

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


Re: [U-Boot] [PATCH] ARM: DRA7xx: Fix memory allocation overflow

2017-02-15 Thread Tom Rini
On Wed, Feb 15, 2017 at 09:16:53AM -0600, Andrew F. Davis wrote:

> When using early malloc the allocated memory can overflow into the SRAM
> scratch space, move NON_SECURE_SRAM_IMG_END down a bit to allow more
> dynamic allocation at the expense of a slightly smaller maximum image
> size.
> 
> Signed-off-by: Andrew F. Davis 
> Reviewed-by: Lokesh Vutla 

Er, I thought we could define how big the early malloc pool is and not
have this type of problem?

-- 
Tom


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


Re: [U-Boot] [PATCH 07/10] mvebu: a37xx: Add init for ESPRESSBin Topaz switch

2017-02-15 Thread Joe Hershberger
On Wed, Feb 15, 2017 at 9:32 AM, Konstantin Porotchkin
 wrote:
>
>
> On 02/15/2017 11:07 AM, Konstantin Porotchkin wrote:
>>
>> Hi, Joe,
>>
>> On 02/14/2017 07:17 PM, Joe Hershberger wrote:
>>>
>>> On Tue, Feb 14, 2017 at 6:32 AM, Stefan Roese  wrote:
>>> > (added Joe to Cc as network custodian)
>>> >
>>> >
>>> > On 14.02.2017 13:13, Konstantin Porotchkin wrote:
>>> >>
>>> >> Hi, Stefan,
>>> >>
>>> >> On 2/14/2017 13:49, Stefan Roese wrote:
>>> >>>
>>> >>> Hi Kosta,
>>> >>>
>>> >>> On 13.02.2017 14:38, kos...@marvell.com wrote:
>>> 
>>>  From: Konstantin Porotchkin 
>>> 
>>>  Implement the board-specific network init function for
>>>  ESPRESSOBin community board, setting the on-board Topaz
>>>  switch port to forward mode and allow network connection
>>>  through any of the available Etherenet ports.
>>> 
>>>  Signed-off-by: Konstantin Porotchkin 
>>>  Cc: Stefan Roese 
>>>  Cc: Igal Liberman 
>>>  ---
>>>   board/Marvell/mvebu_db-88f3720/board.c | 49
>>>  ++
>>>   1 file changed, 49 insertions(+)
>>> 
>>>  diff --git a/board/Marvell/mvebu_db-88f3720/board.c
>>>  b/board/Marvell/mvebu_db-88f3720/board.c
>>>  index 3337f3f..45098ce 100644
>>>  --- a/board/Marvell/mvebu_db-88f3720/board.c
>>>  +++ b/board/Marvell/mvebu_db-88f3720/board.c
>>>  @@ -6,6 +6,7 @@
>>> 
>>>   #include 
>>>   #include 
>>>  +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>>  @@ -156,3 +157,51 @@ int board_xhci_enable(void)
>>> 
>>>   return 0;
>>>   }
>>>  +
>>>  +static int mii_multi_chip_mode_write(struct mii_dev *bus, int
>>>  dev_smi_addr,
>>>  + int smi_addr, int reg, u16 value)
>>>  +{
>>>  +u16 data = 0;
>>>  +
>>>  +if (bus->write(bus, dev_smi_addr, 0, 1, value) != 0) {
>>>  +printf("Error writing to the PHY addr=%02x reg=%02x\n",
>>>  +   smi_addr, reg);
>>>  +return -EFAULT;
>>>  +}
>>>  +
>>>  +data = (1 << 15) | (1 << 12) | (1 << 10) | (smi_addr << 5) |
>>> reg;
>>>  +if (bus->write(bus, dev_smi_addr, 0, 0, data) != 0) {
>>>  +printf("Error writing to the PHY addr=%02x reg=%02x\n",
>>>  +   smi_addr, reg);
>>>  +return -EFAULT;
>>>  +}
>>>  +
>>>  +return 0;
>>>  +}
>>>  +
>>>  +
>>>  +int board_network_enable(struct mii_dev *bus)
>>>  +{
>>>  +if
>>> (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
>>>  +return 0;
>>>  +
>>>  +/*
>>>  + * FIXME: remove this code once Topaz driver gets available
>>>  + * A3720 Community Board Only
>>>  + * Configure Topaz switch (88E6341)
>>>  + * Set port 0,1,2,3 to forwarding Mode
>>>  + */
>>> >>>
>>> >>>
>>> >>> Just checking: Is this "Topaz switch driver" something thats being
>>> >>> worked on or in the queue to do?
>>> >>
>>> >>
>>> >> I currently do not have it in my queue.
>>> >> I think the driver exists in the kernel (or will exist in 4.10/4.11
>>> >> release), so we may want to port it if required.
>>> >> Which switch operations are needed at u-bot stage?
>>> >
>>> >
>>> > I'm not 100% sure if there is anything really "needed" other than
>>> > to get some ports into operation for the ethernet driver connected
>>> > to this switch. So it might be that such a few register writes
>>> > are acceptable - I'm pretty sure other boards do it this way as
>>> > well.
>>> >
>>> > On the other hand you could take a look at the
>>> > "drivers/net/phy/mv88e61xx.c" switch driver. Might be that this is
>>> > something similar to what you want / need.
>>>
>>> I think the switch driver to model after is drivers/net/vsc9953.c -
>>> there is a command: cmd/ethsw.c / include ethsw.h that implements the
>>> framework (doc/README.t1040-l2switch).
>>
>>
>> I will check this code, thank you for the reference!
>>>
>>>
>>> There is also the drivers/net/cpsw.c that just hard-codes the config.
>>> Eth switches have varying levels of support. What level of support are
>>> you able to implement?
>>
>> I am not really sure about level of support required by the u-boot.
>> The Linux driver configures the 3 output ports of this switch as lan0,
>> lan1
>> and wan interfaces, so they are presented to the kernel as separate NICs.
>> So if I set the NFS server on lan0 and the cable connected to lan1, the
>> connection attempt will fail.
>> The u-boot code however just sets the switch ports to follow all the
>> traffic
>> to the CPU. So when I tfttpload image using default neta0 interface, any
>> switch port will work for that.
>> Anyway, I will check what is supported by the reference code you just
>> pointed
>> and check what I can provide.

Re: [U-Boot] arm: cache: misaligned operation with fastboot

2017-02-15 Thread Fabio Estevam
On Wed, Feb 15, 2017 at 2:04 PM, Gary Bisson
 wrote:
> Hi,
>
> I've been testing fastboot to flash a sparse image on a i.MX6Q platform
> (Nitrogen6x) with U-Boot v2017.01.
>
> This test shows a lot of "misaligned operation" traces:
> => fastboot 0
> Starting download of 415679660 bytes
> ...
> downloading of 415679660 bytes finished
> Flashing sparse image at offset 82124
> Flashing Sparse Image
> CACHE: Misaligned operation at range [1228, 12028028]
> CACHE: Misaligned operation at range [12028044, 1208f044]
> CACHE: Misaligned operation at range [1208f060, 123fd060]
> ...
>
> Has any of you seen that behavior?
>
> Note that this behavior only happens for sparse images, flashing a raw
> image doesn't exhibit the problem.

Adding DFU maintainer, Lukasz on Cc.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] mx6sx: udoo_neo: Define the default serial console

2017-02-15 Thread Breno Matheus Lima
Hi Peter,

2017-02-14 11:10 GMT-02:00  Peter Robinson :
> From: Peter Robinson 
> Date: Tue, Feb 14, 2017 at 11:10 AM
> Subject: [U-Boot] [PATCH 1/3] mx6sx: udoo_neo: Define the default serial 
> console
> To: Breno Lima , Francesco Montefoschi
> , Stefano Babic ,
> u-boot@lists.denx.de
>
>
> Standard boot processes including distro boot generally expect the
> default console to be defined.
>
> Signed-off-by: Peter Robinson 

For the entire series:

Tested-by: Breno Lima 

Thanks
Best Regards,
-- 
Breno Matheus Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] sunxi: Add defconfig for Allwinner A23 EVB

2017-02-15 Thread Florent Jacquet
This enables the support for the Allwinner A23 Evaluation Board (EVB),
that already had a device tree (from Linux) but no defconfig.

This board has an AXP223 PMIC, some NAND, Audio out and in plugs, an
accelerometer and light sensor, as well as a USB HSIC hub and a USB
OTG mini-USB connector. It also has a Wifi/BT chip.

Access to the other buses (LCD, MIPI DSI, LVDS, etc) can be done
through dedicated pin headers.

Signed-off-by: Florent Jacquet 
---
 configs/sun8i_a23_evb_defconfig | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 configs/sun8i_a23_evb_defconfig

diff --git a/configs/sun8i_a23_evb_defconfig b/configs/sun8i_a23_evb_defconfig
new file mode 100644
index 000..296df00
--- /dev/null
+++ b/configs/sun8i_a23_evb_defconfig
@@ -0,0 +1,19 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_MACH_SUN8I_A23=y
+CONFIG_DRAM_CLK=552
+CONFIG_DRAM_ZQ=63351
+CONFIG_USB0_VBUS_PIN="axp_drivebus"
+CONFIG_USB0_VBUS_DET="axp_vbus_detect"
+CONFIG_USB1_VBUS_PIN="PH7"
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-a23-evb"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=5"
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_USB_EHCI_HCD=y
-- 
2.7.4

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


[U-Boot] a question about the source of uboot(for armv8).

2017-02-15 Thread ????????
Hi Haikun Wang,

I have a question about the source of uboot.

http://lists.denx.de/pipermail/u-boot/2015-June/217446.html
>u32 __iomem *dcfg_ccsr = (u32 __iomem *)DCFG_BASE;
>val = in_le32(dcfg_ccsr + DCFG_RCWSR13 / 4);

 

The question is this,

why does DCFG_RCWSR13 device by 4.

 

(1)dcfg_ccsr is the base address of Dcfg_ccsr

(2)DCFG_RCWSR13 is the offset of Dcfg_rcwsr13

So I think the next is right

>val = in_le32(dcfg_ccsr + DCFG_RCWSR13);




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


[U-Boot] arm: cache: misaligned operation with fastboot

2017-02-15 Thread Gary Bisson
Hi,

I've been testing fastboot to flash a sparse image on a i.MX6Q platform
(Nitrogen6x) with U-Boot v2017.01.

This test shows a lot of "misaligned operation" traces:
=> fastboot 0
Starting download of 415679660 bytes
...
downloading of 415679660 bytes finished
Flashing sparse image at offset 82124
Flashing Sparse Image
CACHE: Misaligned operation at range [1228, 12028028]
CACHE: Misaligned operation at range [12028044, 1208f044]
CACHE: Misaligned operation at range [1208f060, 123fd060]
...

Has any of you seen that behavior?

Note that this behavior only happens for sparse images, flashing a raw
image doesn't exhibit the problem.

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


Re: [U-Boot] [PATCH 07/10] mvebu: a37xx: Add init for ESPRESSBin Topaz switch

2017-02-15 Thread Konstantin Porotchkin



On 02/15/2017 11:07 AM, Konstantin Porotchkin wrote:

Hi, Joe,

On 02/14/2017 07:17 PM, Joe Hershberger wrote:

On Tue, Feb 14, 2017 at 6:32 AM, Stefan Roese  wrote:
> (added Joe to Cc as network custodian)
>
>
> On 14.02.2017 13:13, Konstantin Porotchkin wrote:
>>
>> Hi, Stefan,
>>
>> On 2/14/2017 13:49, Stefan Roese wrote:
>>>
>>> Hi Kosta,
>>>
>>> On 13.02.2017 14:38, kos...@marvell.com wrote:

 From: Konstantin Porotchkin 

 Implement the board-specific network init function for
 ESPRESSOBin community board, setting the on-board Topaz
 switch port to forward mode and allow network connection
 through any of the available Etherenet ports.

 Signed-off-by: Konstantin Porotchkin 
 Cc: Stefan Roese 
 Cc: Igal Liberman 
 ---
  board/Marvell/mvebu_db-88f3720/board.c | 49
 ++
  1 file changed, 49 insertions(+)

 diff --git a/board/Marvell/mvebu_db-88f3720/board.c
 b/board/Marvell/mvebu_db-88f3720/board.c
 index 3337f3f..45098ce 100644
 --- a/board/Marvell/mvebu_db-88f3720/board.c
 +++ b/board/Marvell/mvebu_db-88f3720/board.c
 @@ -6,6 +6,7 @@

  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -156,3 +157,51 @@ int board_xhci_enable(void)

  return 0;
  }
 +
 +static int mii_multi_chip_mode_write(struct mii_dev *bus, int
 dev_smi_addr,
 + int smi_addr, int reg, u16 value)
 +{
 +u16 data = 0;
 +
 +if (bus->write(bus, dev_smi_addr, 0, 1, value) != 0) {
 +printf("Error writing to the PHY addr=%02x reg=%02x\n",
 +   smi_addr, reg);
 +return -EFAULT;
 +}
 +
 +data = (1 << 15) | (1 << 12) | (1 << 10) | (smi_addr << 5) |
reg;
 +if (bus->write(bus, dev_smi_addr, 0, 0, data) != 0) {
 +printf("Error writing to the PHY addr=%02x reg=%02x\n",
 +   smi_addr, reg);
 +return -EFAULT;
 +}
 +
 +return 0;
 +}
 +
 +
 +int board_network_enable(struct mii_dev *bus)
 +{
 +if
(!of_machine_is_compatible("marvell,armada-3720-espressobin"))
 +return 0;
 +
 +/*
 + * FIXME: remove this code once Topaz driver gets available
 + * A3720 Community Board Only
 + * Configure Topaz switch (88E6341)
 + * Set port 0,1,2,3 to forwarding Mode
 + */
>>>
>>>
>>> Just checking: Is this "Topaz switch driver" something thats being
>>> worked on or in the queue to do?
>>
>>
>> I currently do not have it in my queue.
>> I think the driver exists in the kernel (or will exist in 4.10/4.11
>> release), so we may want to port it if required.
>> Which switch operations are needed at u-bot stage?
>
>
> I'm not 100% sure if there is anything really "needed" other than
> to get some ports into operation for the ethernet driver connected
> to this switch. So it might be that such a few register writes
> are acceptable - I'm pretty sure other boards do it this way as
> well.
>
> On the other hand you could take a look at the
> "drivers/net/phy/mv88e61xx.c" switch driver. Might be that this is
> something similar to what you want / need.

I think the switch driver to model after is drivers/net/vsc9953.c -
there is a command: cmd/ethsw.c / include ethsw.h that implements the
framework (doc/README.t1040-l2switch).


I will check this code, thank you for the reference!


There is also the drivers/net/cpsw.c that just hard-codes the config.
Eth switches have varying levels of support. What level of support are
you able to implement?

I am not really sure about level of support required by the u-boot.
The Linux driver configures the 3 output ports of this switch as lan0, lan1
and wan interfaces, so they are presented to the kernel as separate NICs.
So if I set the NFS server on lan0 and the cable connected to lan1, the
connection attempt will fail.
The u-boot code however just sets the switch ports to follow all the
traffic
to the CPU. So when I tfttpload image using default neta0 interface, any
switch port will work for that.
Anyway, I will check what is supported by the reference code you just
pointed
and check what I can provide.
I personally not an expert in this Topaz switch internals and may need
to request help
from other Marvell teams for doing something smarter than the code already
provided in this patch.
I went trough the Vitesse driver and understood that at this moment I 
cannot implement something similar.

There are two reasons for this:
1. I am not an expert in SOHO switches.
2. It looks like a long task and it is not included in my current schedule.
So I will try to make this code more readable by adding some defines 
that replace the numeric values at least for pointing to the register 
names. My 

[U-Boot] [PATCH 2/3] armv8: ls1088ardb: Add support for LS1088ARDB platform

2017-02-15 Thread Ashish Kumar
LS1088A is an ARMv8 implementation. The LS1088ARDB is an evaluatoin
platform that supports the LS1088A family SoCs. This patch add basic
support of the platform.

Signed-off-by: Alison Wang 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
Signed-off-by: Raghav Dogra 
Signed-off-by: Shaohui Xie 
---
 arch/arm/Kconfig   |  12 +
 arch/arm/cpu/armv8/Kconfig |   1 +
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  31 +-
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   1 +
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |   6 +-
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   4 +
 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/fsl-ls1088a-rdb.dts   |  40 +++
 arch/arm/dts/fsl-ls1088a.dtsi  |  78 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  68 -
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   2 +-
 .../asm/arch-fsl-layerscape/ls1088a_stream_id.h|  57 
 board/freescale/ls1088a/Kconfig|  15 +
 board/freescale/ls1088a/MAINTAINERS|   9 +
 board/freescale/ls1088a/Makefile   |   9 +
 board/freescale/ls1088a/ddr.c  | 243 +++
 board/freescale/ls1088a/ddr.h  |  46 +++
 board/freescale/ls1088a/eth_ls1088ardb.c   | 102 +++
 board/freescale/ls1088a/ls1088a.c  | 334 +
 board/freescale/ls1088a/ls1088a_qixis.h|  34 +++
 configs/ls1088ardb_defconfig   |  25 ++
 configs/ls1088ardb_qspi_defconfig  |  33 ++
 drivers/ddr/fsl/util.c |   2 +-
 include/configs/ls1088a_common.h   | 199 
 include/configs/ls1088ardb.h   | 327 
 25 files changed, 1673 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/dts/fsl-ls1088a-rdb.dts
 create mode 100644 arch/arm/dts/fsl-ls1088a.dtsi
 create mode 100644 arch/arm/include/asm/arch-fsl-layerscape/ls1088a_stream_id.h
 create mode 100644 board/freescale/ls1088a/Kconfig
 create mode 100644 board/freescale/ls1088a/MAINTAINERS
 create mode 100644 board/freescale/ls1088a/Makefile
 create mode 100644 board/freescale/ls1088a/ddr.c
 create mode 100644 board/freescale/ls1088a/ddr.h
 create mode 100644 board/freescale/ls1088a/eth_ls1088ardb.c
 create mode 100644 board/freescale/ls1088a/ls1088a.c
 create mode 100644 board/freescale/ls1088a/ls1088a_qixis.h
 create mode 100644 configs/ls1088ardb_defconfig
 create mode 100644 configs/ls1088ardb_qspi_defconfig
 create mode 100644 include/configs/ls1088a_common.h
 create mode 100644 include/configs/ls1088ardb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0229800..0c63dfe 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -847,6 +847,17 @@ config TARGET_LS1012AFRDM
  development platform that supports the QorIQ LS1012A
  Layerscape Architecture processor.
 
+config TARGET_LS1088ARDB
+   bool "Support ls1088ardb"
+   select ARCH_LS1088A
+   select ARM64
+   select ARMV8_MULTIENTRY
+   help
+ Support for NXP LS1088ARDB platform.
+ The LS1088AA Reference design board (RDB) is a high-performance
+ development platform that supports the QorIQ LS1088A
+ Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
bool "Support ls1021aqds"
select BOARD_LATE_INIT
@@ -1100,6 +,7 @@ source "board/denx/m53evk/Kconfig"
 source "board/freescale/ls2080a/Kconfig"
 source "board/freescale/ls2080aqds/Kconfig"
 source "board/freescale/ls2080ardb/Kconfig"
+source "board/freescale/ls1088a/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 0188b95..630bb78 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -88,6 +88,7 @@ config PSCI_RESET
depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && !TARGET_LS2080A_EMU && \
   !TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
   !TARGET_LS2080ARDB && !TARGET_LS1012AQDS && \
+  !TARGET_LS1088ARDB && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index d07632f..a418c91 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -49,6 +49,25 @@ config ARCH_LS1046A
select BOARD_EARLY_INIT_F
select 

[U-Boot] [PATCH] driver: net: ldpaa: Update priv->phydev after free()

2017-02-15 Thread Ashish Kumar
From: Prabhakar Kushwaha 

Even after memory free of phydev, priv is still pointing to the
obsolete address.
So update priv->phydev as NULL after memory free.

Signed-off-by: Prabhakar Kushwaha 
---
 drivers/net/ldpaa_eth/ldpaa_eth.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index 4e61700..f235b62 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -587,8 +587,10 @@ static void ldpaa_eth_stop(struct eth_device *net_dev)
 #ifdef CONFIG_PHYLIB
if (priv->phydev && bus != NULL)
phy_shutdown(priv->phydev);
-   else
+   else {
free(priv->phydev);
+   priv->phydev = NULL;
+   }
 #endif
 
ldpaa_dpbp_free();
-- 
1.9.1

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


[U-Boot] [PATCH 1/3] armv8: ls1088a: Add NXP LS1088A SoC support

2017-02-15 Thread Ashish Kumar
The QorIQ LS1088A processor is built on the Layerscape
architecture combining eight ARM A53 processor cores
with advanced, high-performance datapath acceleration
and networks, peripheral interfaces required for
networking, wireless infrastructure, and general-purpose
embedded applications.

LS1088A is compliant to the Layerscape Chassis Generation 3.

Features summary:
 - Eight 32-bit / 64-bit ARM v8 Cortex-A53 CPUs
 - Cores are in 2 cluster of 4-cores each
 - Cache coherent interconnect (CCI-400)
 - One 64-bit DDR4 SDRAM memory controller with ECC
 - Data path acceleration architecture 2.0 (DPAA2)
 - Ethernet interfaces: SGMIIs, RGMIIs, QSGMIIs, XFIs
 - QSPI, IFC, 3 PCIe, 1 SATA, 2 USB, 1 SDXC, 2 DUARTs etc

Signed-off-by: Alison Wang 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c|  10 ++
 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c | 124 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  46 
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   4 +
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   1 +
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  11 ++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   4 +
 drivers/net/ldpaa_eth/Makefile |   1 +
 drivers/net/ldpaa_eth/ls1088a.c|  87 +++
 10 files changed, 292 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
 create mode 100644 drivers/net/ldpaa_eth/ls1088a.c

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index c9ab93e..cfad154 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -38,3 +38,7 @@ endif
 ifneq ($(CONFIG_ARCH_LS1046A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls1046a_serdes.o
 endif
+
+ifneq ($(CONFIG_ARCH_LS1088A),)
+obj-$(CONFIG_SYS_HAS_SERDES) += ls1088a_serdes.o
+endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
index 955e0b7..d7e2d3c 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
@@ -28,6 +28,11 @@ __weak void wriop_init_dpmac_qsgmii(int sd, int lane_prtcl)
return;
 }
 
+__weak int serdes_get_number(int serdes, int cfg)
+{
+   return cfg;
+}
+
 int is_serdes_configured(enum srds_prtcl device)
 {
int ret = 0;
@@ -73,6 +78,9 @@ int serdes_get_first_lane(u32 sd, enum srds_prtcl device)
printf("invalid SerDes%d\n", sd);
break;
}
+
+   cfg = serdes_get_number(sd, cfg);
+
/* Is serdes enabled at all? */
if (cfg == 0)
return -ENODEV;
@@ -99,6 +107,8 @@ void serdes_init(u32 sd, u32 sd_addr, u32 rcwsr, u32 
sd_prctl_mask,
 
cfg = gur_in32(>rcwsr[rcwsr - 1]) & sd_prctl_mask;
cfg >>= sd_prctl_shift;
+
+   cfg = serdes_get_number(sd, cfg);
printf("Using SERDES%d Protocol: %d (0x%x)\n", sd + 1, cfg, cfg);
 
if (!is_serdes_prtcl_valid(sd, cfg))
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
new file mode 100644
index 000..9f89bd0
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
@@ -0,0 +1,124 @@
+/*
+ * Copyright 2017 NXP
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+struct serdes_config {
+   u8 ip_protocol;
+   u8 lanes[SRDS_MAX_LANES];
+   u8 rcw_lanes[SRDS_MAX_LANES];
+};
+
+static struct serdes_config serdes1_cfg_tbl[] = {
+   /* SerDes 1 */
+   {0x12, {SGMII3, SGMII7, SGMII1, SGMII2 }, {3, 3, 3, 3 }  },
+   {0x15, {SGMII3, SGMII7, XFI1, XFI2 }, {3, 3, 1, 1 } },
+   {0x16, {SGMII3, SGMII7, SGMII1, XFI2 }, {3, 3, 3, 1 } },
+   {0x17, {SGMII3, SGMII7, SGMII1, SGMII2 }, {3, 3, 3, 2 } },
+   {0x18, {SGMII3, SGMII7, SGMII1, SGMII2 }, {3, 3, 2, 2 } },
+   {0x19, {SGMII3, QSGMII_B, XFI1, XFI2}, {3, 4, 1, 1 } },
+   {0x1A, {SGMII3, QSGMII_B, SGMII1, XFI2 }, {3, 4, 3, 1 } },
+   {0x1B, {SGMII3, QSGMII_B, SGMII1, SGMII2 }, {3, 4, 3, 2 } },
+   {0x1C, {SGMII3, QSGMII_B, SGMII1, SGMII2 }, {3, 4, 2, 2 } },
+   {0x1D, {QSGMII_A, QSGMII_B, XFI1, XFI2 }, {4, 4, 1, 1 } },
+   {0x1E, {QSGMII_A, QSGMII_B, SGMII1, XFI2  }, {4, 4, 3, 1 } },
+   {0x1F, {QSGMII_A, QSGMII_B, SGMII1, SGMII2  }, {4, 4, 3, 2 } },
+   {0x20, {QSGMII_A, QSGMII_B, SGMII1, SGMII2 }, {4, 4, 2, 2 } },
+   {0x35, {SGMII3, QSGMII_B, SGMII1, SGMII2 }, {3, 4, 3, 3 } },
+   {0x36, {QSGMII_A, QSGMII_B, SGMII1, SGMII2 }, {4, 4, 3, 3 } },
+   {}
+};
+static struct serdes_config serdes2_cfg_tbl[] = 

[U-Boot] [PATCH 3/3] armv8: ls1088aqds: Add support of LS1088AQDS

2017-02-15 Thread Ashish Kumar
This patch add support of LS1088AQDS platform.

The LS1088A QorIQTM Development System (QDS) is a
high-performance computing, evaluation, and
development platform that supports the LS1088A QorIQ Architecture
processor.

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
Signed-off-by: Shaohui Xie 
---
 arch/arm/Kconfig   |  11 +
 arch/arm/cpu/armv8/Kconfig |   2 +-
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  21 +
 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c |   2 +
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   1 +
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/fsl-ls1088a-qds.dts   |  70 +++
 board/freescale/ls1088a/Kconfig|  16 +
 board/freescale/ls1088a/MAINTAINERS|  10 +-
 board/freescale/ls1088a/Makefile   |   1 +
 board/freescale/ls1088a/ddr.c  | 119 +---
 board/freescale/ls1088a/ddr.h  |   9 +-
 board/freescale/ls1088a/eth_ls1088aqds.c   | 650 +
 board/freescale/ls1088a/ls1088a.c  | 106 +++-
 board/freescale/ls1088a/ls1088a_qixis.h|   5 +
 configs/ls1088aqds_qspi_defconfig  |  27 +
 configs/ls1088ardb_qspi_defconfig  |   6 -
 include/configs/ls1088a_common.h   |   8 +-
 include/configs/ls1088aqds.h   | 403 +
 19 files changed, 1321 insertions(+), 147 deletions(-)
 create mode 100644 arch/arm/dts/fsl-ls1088a-qds.dts
 create mode 100644 board/freescale/ls1088a/eth_ls1088aqds.c
 create mode 100644 configs/ls1088aqds_qspi_defconfig
 create mode 100644 include/configs/ls1088aqds.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0c63dfe..435a8f8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -776,6 +776,17 @@ config TARGET_LS2080A_SIMU
  development platform that supports the QorIQ LS2080A
  Layerscape Architecture processor.
 
+config TARGET_LS1088AQDS
+   bool "Support ls1088aqds"
+   select ARCH_LS1088A
+   select ARM64
+   select ARMV8_MULTIENTRY
+   help
+ Support for NXP LS1088AQDS platform
+ The LS1088A Development System (QDS) is a high-performance
+ development platform that supports the QorIQ LS1088A
+ Layerscape Architecture processor.
+
 config TARGET_LS2080AQDS
bool "Support ls2080aqds"
select ARCH_LS2080A
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 630bb78..b3565a5 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -88,7 +88,7 @@ config PSCI_RESET
depends on !ARCH_EXYNOS7 && !ARCH_BCM283X && !TARGET_LS2080A_EMU && \
   !TARGET_LS2080A_SIMU && !TARGET_LS2080AQDS && \
   !TARGET_LS2080ARDB && !TARGET_LS1012AQDS && \
-  !TARGET_LS1088ARDB && \
+  !TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index a418c91..bf48918 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -229,6 +229,27 @@ config FSL_TZASC_1
 config FSL_TZASC_2
bool
 
+config SYS_FSL_ERRATUM_A008336
+   bool
+
+config SYS_FSL_ERRATUM_A009801
+   bool
+
+config SYS_FSL_ERRATUM_A009803
+   bool
+
+config SYS_FSL_ERRATUM_A009942
+   bool
+
+config SYS_FSL_ERRATUM_A010165
+   bool
+
+config SYS_FSL_ERRATUM_A008511
+   bool
+
+config SYS_FSL_ERRATUM_A008850
+   bool
+
 endmenu
 
 menu "Layerscape clock tree configuration"
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
index 9f89bd0..9f5cdd5 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
@@ -30,6 +30,7 @@ static struct serdes_config serdes1_cfg_tbl[] = {
{0x20, {QSGMII_A, QSGMII_B, SGMII1, SGMII2 }, {4, 4, 2, 2 } },
{0x35, {SGMII3, QSGMII_B, SGMII1, SGMII2 }, {3, 4, 3, 3 } },
{0x36, {QSGMII_A, QSGMII_B, SGMII1, SGMII2 }, {4, 4, 3, 3 } },
+   {0x3A, {SGMII3, PCIE1, SGMII1, SGMII2 }, {3, 5, 3, 3 } },
{}
 };
 static struct serdes_config serdes2_cfg_tbl[] = {
@@ -39,6 +40,7 @@ static struct serdes_config serdes2_cfg_tbl[] = {
{0x0E, {PCIE1, PCIE1, PCIE2, SATA1 }, {7, 7, 6, 9 }  },
{0x13, {PCIE1, PCIE1, PCIE3, PCIE3 }, {7, 7, 7, 7 }  },
{0x14, {PCIE1, PCIE2, PCIE3, PCIE3 }, {5, 5, 7, 7 }  },
+   {0x3C, {NONE, PCIE2, NONE, PCIE3 }, {0, 5, 0, 6 }  },
 

[U-Boot] [PATCH v2] armv8:fsl-layerscape: Avoid RCWSR28 register hard-coding

2017-02-15 Thread Ashish Kumar
From: Prabhakar Kushwaha 

SerDes information is not necessary to be present in RCWSR29 register.
It may vary from SoC to SoC.

So Avoid RCWSR28 register hard-coding.

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
---
v2:
Incorporate York's Review comments

 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 28 --
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  9 +++
 2 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
index c2fc646..955e0b7 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
@@ -51,20 +51,22 @@ int is_serdes_configured(enum srds_prtcl device)
 int serdes_get_first_lane(u32 sd, enum srds_prtcl device)
 {
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
-   u32 cfg = gur_in32(>rcwsr[28]);
+   u32 cfg = 0;
int i;
 
switch (sd) {
 #ifdef CONFIG_SYS_FSL_SRDS_1
case FSL_SRDS_1:
-   cfg &= FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_MASK;
-   cfg >>= FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_SHIFT;
+   cfg = gur_in32(>rcwsr[FSL_CHASSIS3_SRDS1_REGSR - 1]);
+   cfg &= FSL_CHASSIS3_SRDS1_PRTCL_MASK;
+   cfg >>= FSL_CHASSIS3_SRDS1_PRTCL_SHIFT;
break;
 #endif
 #ifdef CONFIG_SYS_FSL_SRDS_2
case FSL_SRDS_2:
-   cfg &= FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_MASK;
-   cfg >>= FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_SHIFT;
+   cfg = gur_in32(>rcwsr[FSL_CHASSIS3_SRDS2_REGSR - 1]);
+   cfg &= FSL_CHASSIS3_SRDS2_PRTCL_MASK;
+   cfg >>= FSL_CHASSIS3_SRDS2_PRTCL_SHIFT;
break;
 #endif
default:
@@ -83,8 +85,8 @@ int serdes_get_first_lane(u32 sd, enum srds_prtcl device)
return -ENODEV;
 }
 
-void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32 sd_prctl_shift,
-   u8 serdes_prtcl_map[SERDES_PRCTL_COUNT])
+void serdes_init(u32 sd, u32 sd_addr, u32 rcwsr, u32 sd_prctl_mask,
+u32 sd_prctl_shift, u8 serdes_prtcl_map[SERDES_PRCTL_COUNT])
 {
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
u32 cfg;
@@ -95,7 +97,7 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32 
sd_prctl_shift,
 
memset(serdes_prtcl_map, 0, sizeof(u8) * SERDES_PRCTL_COUNT);
 
-   cfg = gur_in32(>rcwsr[28]) & sd_prctl_mask;
+   cfg = gur_in32(>rcwsr[rcwsr - 1]) & sd_prctl_mask;
cfg >>= sd_prctl_shift;
printf("Using SERDES%d Protocol: %d (0x%x)\n", sd + 1, cfg, cfg);
 
@@ -152,15 +154,17 @@ void fsl_serdes_init(void)
 #ifdef CONFIG_SYS_FSL_SRDS_1
serdes_init(FSL_SRDS_1,
CONFIG_SYS_FSL_LSCH3_SERDES_ADDR,
-   FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_MASK,
-   FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_SHIFT,
+   FSL_CHASSIS3_SRDS1_REGSR,
+   FSL_CHASSIS3_SRDS1_PRTCL_MASK,
+   FSL_CHASSIS3_SRDS1_PRTCL_SHIFT,
serdes1_prtcl_map);
 #endif
 #ifdef CONFIG_SYS_FSL_SRDS_2
serdes_init(FSL_SRDS_2,
CONFIG_SYS_FSL_LSCH3_SERDES_ADDR + FSL_SRDS_2 * 0x1,
-   FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_MASK,
-   FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_SHIFT,
+   FSL_CHASSIS3_SRDS2_REGSR,
+   FSL_CHASSIS3_SRDS2_PRTCL_MASK,
+   FSL_CHASSIS3_SRDS2_PRTCL_SHIFT,
serdes2_prtcl_map);
 #endif
 }
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 43ae686..0678fba 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -232,10 +232,19 @@ struct ccsr_gur {
 #define FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_MASK   0x3f
 #define FSL_CHASSIS3_RCWSR0_MEM2_PLL_RAT_SHIFT 18
 #define FSL_CHASSIS3_RCWSR0_MEM2_PLL_RAT_MASK  0x3f
+
+#if defined(CONFIG_ARCH_LS2080A)
 #defineFSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_MASK   0x00FF
 #defineFSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_SHIFT  16
 #defineFSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_MASK   0xFF00
 #defineFSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_SHIFT  24
+#define FSL_CHASSIS3_SRDS1_PRTCL_MASK  FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_MASK
+#define FSL_CHASSIS3_SRDS1_PRTCL_SHIFT FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_SHIFT
+#define FSL_CHASSIS3_SRDS2_PRTCL_MASK  FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_MASK
+#define FSL_CHASSIS3_SRDS2_PRTCL_SHIFT FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_SHIFT
+#define FSL_CHASSIS3_SRDS1_REGSR   29
+#define FSL_CHASSIS3_SRDS2_REGSR   29
+#endif
 #define RCW_SB_EN_REG_INDEX9
 #define RCW_SB_EN_MASK 0x0400
 
-- 
1.9.1

[U-Boot] [PATCH v2] driver: net: ldpaa: Update priv->phydev after free()

2017-02-15 Thread Ashish Kumar
From: Prabhakar Kushwaha 

Even after memory free of phydev, priv is still pointing to the
obsolete address.
So update priv->phydev as NULL after memory free.

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
---
v2:
Add signoff

 drivers/net/ldpaa_eth/ldpaa_eth.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index 4e61700..f235b62 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -587,8 +587,10 @@ static void ldpaa_eth_stop(struct eth_device *net_dev)
 #ifdef CONFIG_PHYLIB
if (priv->phydev && bus != NULL)
phy_shutdown(priv->phydev);
-   else
+   else {
free(priv->phydev);
+   priv->phydev = NULL;
+   }
 #endif
 
ldpaa_dpbp_free();
-- 
1.9.1

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


[U-Boot] [PATCH] ARM: DRA7xx: Fix memory allocation overflow

2017-02-15 Thread Andrew F. Davis
When using early malloc the allocated memory can overflow into the SRAM
scratch space, move NON_SECURE_SRAM_IMG_END down a bit to allow more
dynamic allocation at the expense of a slightly smaller maximum image
size.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Lokesh Vutla 
---
 arch/arm/include/asm/arch-omap5/omap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-omap5/omap.h 
b/arch/arm/include/asm/arch-omap5/omap.h
index b5e5519fbd..8f31da1a7b 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -188,7 +188,7 @@ struct s32ktimer {
 #if defined(CONFIG_DRA7XX)
 #define NON_SECURE_SRAM_START  0x4030
 #define NON_SECURE_SRAM_END0x4038  /* Not inclusive */
-#define NON_SECURE_SRAM_IMG_END0x4037E000
+#define NON_SECURE_SRAM_IMG_END0x4037C000
 #else
 #define NON_SECURE_SRAM_START  0x4030
 #define NON_SECURE_SRAM_END0x4032  /* Not inclusive */
-- 
2.11.0

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


[U-Boot] [PATCH v2] arm: fsl-layerscape: Move QSGMII wriop_init to SoC file

2017-02-15 Thread Ashish Kumar
From: Prabhakar Kushwaha 

MAC number used per QSGMII is not fixed. It may wary from SoC to SoC.

So move QSGMII wriop_init_dpmac() to SoC file.

Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Ashish Kumar 
---
v2:
Incorporate York's Review comments

 .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 25 +-
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |  8 +++---
 drivers/net/ldpaa_eth/ls2080a.c| 30 ++
 include/fsl-mc/ldpaa_wriop.h   |  1 +
 4 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
index 7faa86c..c2fc646 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
@@ -23,6 +23,11 @@ int xfi_dpmac[XFI8 + 1];
 int sgmii_dpmac[SGMII16 + 1];
 #endif
 
+__weak void wriop_init_dpmac_qsgmii(int sd, int lane_prtcl)
+{
+   return;
+}
+
 int is_serdes_configured(enum srds_prtcl device)
 {
int ret = 0;
@@ -106,28 +111,10 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, 
u32 sd_prctl_shift,
 #ifdef CONFIG_FSL_MC_ENET
switch (lane_prtcl) {
case QSGMII_A:
-   wriop_init_dpmac(sd, 5, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 6, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 7, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 8, (int)lane_prtcl);
-   break;
case QSGMII_B:
-   wriop_init_dpmac(sd, 1, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 2, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 3, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 4, (int)lane_prtcl);
-   break;
case QSGMII_C:
-   wriop_init_dpmac(sd, 13, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 14, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 15, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 16, (int)lane_prtcl);
-   break;
case QSGMII_D:
-   wriop_init_dpmac(sd, 9, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 10, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 11, (int)lane_prtcl);
-   wriop_init_dpmac(sd, 12, (int)lane_prtcl);
+   wriop_init_dpmac_qsgmii(sd, (int)lane_prtcl);
break;
default:
if (lane_prtcl >= XFI1 && lane_prtcl <= XFI8)
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h 
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
index d9d948e..70181c5 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
@@ -48,10 +48,10 @@ enum srds_prtcl {
SGMII14,
SGMII15,
SGMII16,
-   QSGMII_A, /* A indicates MACs 1-4 */
-   QSGMII_B, /* B indicates MACs 5-8 */
-   QSGMII_C, /* C indicates MACs 9-12 */
-   QSGMII_D, /* D indicates MACs 12-16 */
+   QSGMII_A,
+   QSGMII_B,
+   QSGMII_C,
+   QSGMII_D,
SERDES_PRCTL_COUNT
 };
 
diff --git a/drivers/net/ldpaa_eth/ls2080a.c b/drivers/net/ldpaa_eth/ls2080a.c
index 93ed4f1..673e428 100644
--- a/drivers/net/ldpaa_eth/ls2080a.c
+++ b/drivers/net/ldpaa_eth/ls2080a.c
@@ -79,3 +79,33 @@ phy_interface_t wriop_dpmac_enet_if(int dpmac_id, int 
lane_prtcl)
 
return PHY_INTERFACE_MODE_NONE;
 }
+
+void wriop_init_dpmac_qsgmii(int sd, int lane_prtcl)
+{
+   switch (lane_prtcl) {
+   case QSGMII_A:
+   wriop_init_dpmac(sd, 5, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 6, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 7, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 8, (int)lane_prtcl);
+   break;
+   case QSGMII_B:
+   wriop_init_dpmac(sd, 1, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 2, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 3, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 4, (int)lane_prtcl);
+   break;
+   case QSGMII_C:
+   wriop_init_dpmac(sd, 13, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 14, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 15, (int)lane_prtcl);
+   wriop_init_dpmac(sd, 16, (int)lane_prtcl);
+   break;
+   case QSGMII_D:
+   wriop_init_dpmac(sd, 

[U-Boot] [PATCH 1/1] Secure Boot: Set NPSWA_EN bit for SNVS state transition to happen in EL2.

2017-02-15 Thread Udit Agarwal
For Layerscape chasis Gen 3 based platforms, during PPA execution
exception level transition happens from EL3 to EL2. While in EL2 state
SNVS state doesnot changes from secure to non secure state in
case of ESBC failure.

So to enable the SNVS transition in EL2 state, NPSWA_EN bit has to be set
when in EL3 state.

Signed-off-by: Udit Agarwal 
---
 drivers/crypto/fsl/jr.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 1b88229..ccd2168 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include "fsl_sec.h"
 #include "jr.h"
 #include "jobdesc.h"
@@ -574,6 +575,12 @@ int sec_init_idx(uint8_t sec_idx)
uint32_t liodn_s;
 #endif
 
+#if defined(CONFIG_FSL_LSCH3) && defined(CONFIG_SYS_LS_PPA_ESBC_ADDR)
+#define SEC_MON_HPCOMR (CONFIG_SYS_SEC_MON_ADDR + 0x04)
+#define SEC_MON_HPCOMR_NPSWA_EN0x8000
+   sec_mon_setbits32(SEC_MON_HPCOMR, SEC_MON_HPCOMR_NPSWA_EN);
+#endif
+
if (!(sec_idx < CONFIG_SYS_FSL_MAX_NUM_OF_SEC)) {
printf("SEC initialization failed\n");
return -1;
-- 
1.9.1

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


Re: [U-Boot] [PATCH v2 1/6] arm: am57xx: reintroduce the CONFIG_AM57XX symbol

2017-02-15 Thread Uri Mashiach



On 02/15/2017 01:30 PM, Roger Quadros wrote:

On 15/02/17 10:24, Roger Quadros wrote:

On 14/02/17 22:12, Tom Rini wrote:

On Tue, Feb 14, 2017 at 01:26:24PM -0600, Nishanth Menon wrote:

On 02/14/2017 01:20 PM, Tom Rini wrote:

On Tue, Feb 14, 2017 at 01:18:20PM -0600, menon.nisha...@gmail.com wrote:

On Mon, Feb 13, 2017 at 7:27 AM, Tom Rini  wrote:

On Mon, Feb 13, 2017 at 01:34:52PM +0200, Uri Mashiach wrote:


The SOC family symbol CONFIG_AM57XX was removed by the commit
3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX".

The symbol is needed by the XHCI OMAP USB driver.
Without the symbol all the AM57x targets symbols should be ored in the
ifdef'ery.

Signed-off-by: Uri Mashiach 


We need to introduce it into Kconfig files now, thanks!


DRA7 and AM57xx are literally the same. the #ifdeffery in USB is more
to do which port to use rather than having anything to do with DRA7 Vs
AM57xx.


Yes, agreed.  And we need to solve this, and introduce some Kconfig
CONFIG symbol to deal with it.  Maybe the better way to look at this is,
can we have DRA7xx boards configured in the way Uri wants to be able to
configure the AM57xx board he's working with? And vice versa?  The
answer to that will help drive what the right CONFIG_xxx name is.


Should'nt be ideally done via DM model instead? I have no
understanding of USB integration done in u-boot to comment better.


That's also something that could be explored.



Yes, ideally this should be taken care of by DM.
Till that migration is complete I'm fine with fixing this temporarily.

OMAP5, DRA7, AM57 and AM43 use different XHCI_BASE address.


Just to clarify further on this
DRA7 and AM57 are identical SoCs but the EVMs are using different
instances of the USB as host so the difference in XHCI_BASE.

DRA7-evm uses USB1 instance whereas AM57x-EVM uses USB0 instance as host.


Alternative solution:
* Definition of registers base groups for USB0 and USB1.
* Target based definition of XHCI_USB0 or XHCI_USB1.
* Selection of register base group based on the definition of XHCI_USB0 
or XHCI_USB1.

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


Re: [U-Boot] Simple Malloc Breaks omap3_logic

2017-02-15 Thread Adam Ford
On Tue, Feb 14, 2017 at 4:07 PM, Tom Rini  wrote:
> On Tue, Feb 14, 2017 at 03:56:43PM -0600, Adam Ford wrote:
>> On Feb 14, 2017 3:10 PM, "Tom Rini"  wrote:
>>
>> On Tue, Feb 14, 2017 at 03:03:44PM -0600, Adam Ford wrote:
>>
>> > Tom,
>> >
>> > I noticed there was an update to the omap3_logic_defconfig to use Simple
>> Malloc
>> >
>> > http://git.denx.de/?p=u-boot.git;a=commit;h=0959649dc6d9e6a371617abd3b0363
>> 0c5d4d5a72
>> >
>> >
>> > I didn't see anything in my inbox indicating the patch, I only noticed
>> > it because I pulled the latest from the trunk.  Unfortunately, this
>> > patch breaks the board.
>> >
>> > (ie. MLO doesn't load U-Boot)
>> >
>> > See Log:
>> >
>> > U-Boot SPL 2017.03-rc2-8-g2ebb842-dirty (Feb 14 2017 - 14:54:59)
>> > Trying to boot from MMC1
>> > reading args
>> > spl_load_image_fat_os: error reading image args, err - -1
>> > reading u-boot.img
>> > reading u-boot.img
>> >
>> > (then it just hangs)
>> >
>> > Removing this line from the defconfig returns the board to a functional
>> state.
>> >
>> > Is there an alternative that we can explore to give you what you need?
>> >
>> > I am able to build with gcc version 5.4.0 , but I can help you do some
>> > testing if you need.
>>
>> Oh, sorry, I thought I had made sure to copy all of the required logic
>> to have simple malloc work.  I think it's highly likely I forgot to make
>> sure that CONFIG_SYS_MALLOC_F_LEN is also set and that's why it all went
>> south.  Sorry again!
>>
>>
>> That's OK, I just hope I can be included in changes so I can test them. I
>> do appreciate the help in making the code and user experience better.
>>
>> Can you send me an updated patch so I can test your change?
>
> Try this please:
> diff --git a/configs/omap3_logic_defconfig b/configs/omap3_logic_defconfig
> index fe762c0a6b04..9d1304f08e49 100644
> --- a/configs/omap3_logic_defconfig
> +++ b/configs/omap3_logic_defconfig
> @@ -1,5 +1,6 @@
>  CONFIG_ARM=y
>  CONFIG_OMAP34XX=y
> +CONFIG_SYS_MALLOC_F_LEN=0x2000
>  CONFIG_TARGET_OMAP3_LOGIC=y
>  CONFIG_SYS_EXTRA_OPTIONS="NAND"
>  CONFIG_SYS_CONSOLE_INFO_QUIET=y
>

Unfortunately, it still doesn't boot.  The log is different, but it
still doesn't boot.  The log is a little less chatty now:


U-Boot SPL 2017.03-rc2-8-g2ebb842-dirty (Feb 15 2017 - 07:18:07)
Trying to boot from MMC1


Are there other things you want me to try?

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


[U-Boot] [PATCH v4] tools: omapimage: Fix size in header

2017-02-15 Thread Lokesh Vutla
The size field in GP header that is expected by ROM is size of the
image + size of the header. But omapimage generates a gp header
only with size of the image as size field. Fix it

Signed-off-by: Lokesh Vutla 
---
 tools/omapimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/omapimage.c b/tools/omapimage.c
index 7198b3330d..e31b94ae4f 100644
--- a/tools/omapimage.c
+++ b/tools/omapimage.c
@@ -143,7 +143,7 @@ static void omapimage_set_header(void *ptr, struct stat 
*sbuf, int ifd,
toc++;
memset(toc, 0xff, sizeof(*toc));
 
-   gph_set_header(gph, sbuf->st_size - OMAP_FILE_HDR_SIZE,
+   gph_set_header(gph, sbuf->st_size - OMAP_CH_HDR_SIZE + GPIMAGE_HDR_SIZE,
   params->addr, 0);
 
if (strncmp(params->imagename, "byteswap", 8) == 0) {
-- 
2.11.0

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


Re: [U-Boot] [PATCH v3 1/5] tools: omapimage: Fix size in header

2017-02-15 Thread Tom Rini
On Wed, Feb 15, 2017 at 06:02:37PM +0530, Lokesh Vutla wrote:
> Hi Tom,
> 
> On Friday 10 February 2017 08:37 PM, Lokesh Vutla wrote:
> > The size field in GP header that is expected by ROM is size of the
> > image + size of the header. But omapimage generates a gp header
> > only with size of the image as size field. Fix it
> 
> Unfortunately this is not ture for Keystone2. K2 rom still expects only
> the image size but the $subject patch effects K2 as well. Can you please
> take the below patch instead?
> Let me know if you want me to resend the series.

Please just re-send the v4 of 1/5 so patchwork will pick it up
correctly, thanks!

> 
> From 3cb059cca5af5cb7538a411b2386ee4c5f753f2e Mon Sep 17 00:00:00 2001
> From: Lokesh Vutla 
> Date: Wed, 15 Feb 2017 16:06:00 +0530
> Subject: [PATCH v4] tools: omapimage: Fix size in header
> 
> The size field in GP header that is expected by ROM is size of the
> image + size of the header. But omapimage generates a gp header
> only with size of the image as size field. Fix it
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  tools/omapimage.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/omapimage.c b/tools/omapimage.c
> index 7198b3330d..e31b94ae4f 100644
> --- a/tools/omapimage.c
> +++ b/tools/omapimage.c
> @@ -143,7 +143,7 @@ static void omapimage_set_header(void *ptr, struct
> stat *sbuf, int ifd,
>   toc++;
>   memset(toc, 0xff, sizeof(*toc));
> 
> - gph_set_header(gph, sbuf->st_size - OMAP_FILE_HDR_SIZE,
> + gph_set_header(gph, sbuf->st_size - OMAP_CH_HDR_SIZE + GPIMAGE_HDR_SIZE,
>  params->addr, 0);
> 
>   if (strncmp(params->imagename, "byteswap", 8) == 0) {
> -- 
> 2.11.0

-- 
Tom


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


Re: [U-Boot] [PATCH v3 1/5] tools: omapimage: Fix size in header

2017-02-15 Thread Lokesh Vutla
Hi Tom,

On Friday 10 February 2017 08:37 PM, Lokesh Vutla wrote:
> The size field in GP header that is expected by ROM is size of the
> image + size of the header. But omapimage generates a gp header
> only with size of the image as size field. Fix it

Unfortunately this is not ture for Keystone2. K2 rom still expects only
the image size but the $subject patch effects K2 as well. Can you please
take the below patch instead?
Let me know if you want me to resend the series.

>From 3cb059cca5af5cb7538a411b2386ee4c5f753f2e Mon Sep 17 00:00:00 2001
From: Lokesh Vutla 
Date: Wed, 15 Feb 2017 16:06:00 +0530
Subject: [PATCH v4] tools: omapimage: Fix size in header

The size field in GP header that is expected by ROM is size of the
image + size of the header. But omapimage generates a gp header
only with size of the image as size field. Fix it

Signed-off-by: Lokesh Vutla 
---
 tools/omapimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/omapimage.c b/tools/omapimage.c
index 7198b3330d..e31b94ae4f 100644
--- a/tools/omapimage.c
+++ b/tools/omapimage.c
@@ -143,7 +143,7 @@ static void omapimage_set_header(void *ptr, struct
stat *sbuf, int ifd,
toc++;
memset(toc, 0xff, sizeof(*toc));

-   gph_set_header(gph, sbuf->st_size - OMAP_FILE_HDR_SIZE,
+   gph_set_header(gph, sbuf->st_size - OMAP_CH_HDR_SIZE + GPIMAGE_HDR_SIZE,
   params->addr, 0);

if (strncmp(params->imagename, "byteswap", 8) == 0) {
-- 
2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] splash: fix splash source flags check

2017-02-15 Thread Tomas Melin
Hi,


On 01/16/2017 08:36 PM, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> 
> 
> On 14 Jan 2017 3:54 a.m., "Anatolij Gustschin"  wrote:
> 
> From: "tomas.me...@vaisala.com" 
> 
> SPLASH_STORAGE_RAW is defined as 0, so a check against & will
> never be true. These flags are never combined so do a check
> against == instead.
> 
> Signed-off-by: Tomas Melin 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v2:
> - rebased on u-boot-video/master
> 
>  common/splash_source.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/common/splash_source.c b/common/splash_source.c
> index 4c64f10..a5eeb3f 100644
> --- a/common/splash_source.c
> +++ b/common/splash_source.c
> @@ -395,9 +395,9 @@ int splash_source_load(struct splash_location
> *locations, uint size)
> if (!splash_location)
> return -EINVAL;
> 
> -   if (splash_location->flags & SPLASH_STORAGE_RAW)
> +   if (splash_location->flags == SPLASH_STORAGE_RAW)
> return splash_load_raw(splash_location, bmp_load_addr);
> -   else if (splash_location->flags & SPLASH_STORAGE_FS)
> +   else if (splash_location->flags == SPLASH_STORAGE_FS)
> return splash_load_fs(splash_location, bmp_load_addr);
>  #ifdef CONFIG_FIT
> else if (splash_location->flags == SPLASH_STORAGE_FIT)
> 
> 
> So switch
Yes, maybe indeed it makes sense to change to a switch case instead for these.
I will send a new patch.

Tomas

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


Re: [U-Boot] [PATCH v2 1/6] arm: am57xx: reintroduce the CONFIG_AM57XX symbol

2017-02-15 Thread Roger Quadros
On 15/02/17 10:24, Roger Quadros wrote:
> On 14/02/17 22:12, Tom Rini wrote:
>> On Tue, Feb 14, 2017 at 01:26:24PM -0600, Nishanth Menon wrote:
>>> On 02/14/2017 01:20 PM, Tom Rini wrote:
 On Tue, Feb 14, 2017 at 01:18:20PM -0600, menon.nisha...@gmail.com wrote:
> On Mon, Feb 13, 2017 at 7:27 AM, Tom Rini  wrote:
>> On Mon, Feb 13, 2017 at 01:34:52PM +0200, Uri Mashiach wrote:
>>
>>> The SOC family symbol CONFIG_AM57XX was removed by the commit
>>> 3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX".
>>>
>>> The symbol is needed by the XHCI OMAP USB driver.
>>> Without the symbol all the AM57x targets symbols should be ored in the
>>> ifdef'ery.
>>>
>>> Signed-off-by: Uri Mashiach 
>>
>> We need to introduce it into Kconfig files now, thanks!
>
> DRA7 and AM57xx are literally the same. the #ifdeffery in USB is more
> to do which port to use rather than having anything to do with DRA7 Vs
> AM57xx.

 Yes, agreed.  And we need to solve this, and introduce some Kconfig
 CONFIG symbol to deal with it.  Maybe the better way to look at this is,
 can we have DRA7xx boards configured in the way Uri wants to be able to
 configure the AM57xx board he's working with? And vice versa?  The
 answer to that will help drive what the right CONFIG_xxx name is.
>>>
>>> Should'nt be ideally done via DM model instead? I have no
>>> understanding of USB integration done in u-boot to comment better.
>>
>> That's also something that could be explored.
>>
> 
> Yes, ideally this should be taken care of by DM.
> Till that migration is complete I'm fine with fixing this temporarily.
> 
> OMAP5, DRA7, AM57 and AM43 use different XHCI_BASE address.
> 
Just to clarify further on this
DRA7 and AM57 are identical SoCs but the EVMs are using different
instances of the USB as host so the difference in XHCI_BASE.

DRA7-evm uses USB1 instance whereas AM57x-EVM uses USB0 instance as host.

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


Re: [U-Boot] [PATCH v2] spl: net: Add FIT image support over network boot

2017-02-15 Thread Vignesh R
Hi,

On Wednesday 08 February 2017 11:21 PM, Davis, Andrew wrote:
> FIT support in the net boot case is much like the RAM boot case in that
> we load our image to "load_addr" and pass a dummy read function into
> "spl_load_simple_fit()". As the load address is no longer hard-coded to
> the final execution address, RAW image loading will rely on "load_addr"
> pointing to the execution address as they should have before.
> 

[...]

>  #if defined(CONFIG_SPL_ETH_SUPPORT) || defined(CONFIG_SPL_USBETH_SUPPORT)
> +static ulong spl_net_load_read(struct spl_load_info *load, ulong sector,
> +ulong count, void *buf)
> +{
> + debug("%s: sector %lx, count %lx, buf %lx\n",
> +   __func__, sector, count, (ulong)buf);
> + memcpy(buf, (void *)(load_addr + sector), count);
> + return count;
> +}
> +
>  static int spl_net_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev)
>  {
> + struct image_header *header = (struct image_header *)load_addr;
>   int rv;
>  
>   env_init();
>   env_relocate();
>   setenv("autoload", "yes");
> - load_addr = CONFIG_SYS_TEXT_BASE - sizeof(struct image_header);

This breaks when FIT image is not used (For example, breaks
am335x_evm_usbspl_defconfig)

Below snippet helps non FIT case:

+   if (!IS_ENABLED(CONFIG_SPL_LOAD_FIT))
+   load_addr = CONFIG_SYS_TEXT_BASE - sizeof(struct
image_header);
+



>   rv = eth_initialize();
>   if (rv == 0) {
>   printf("No Ethernet devices found\n");
> @@ -36,8 +46,22 @@ static int spl_net_load_image(struct spl_image_info 
> *spl_image,
>   printf("Problem booting with BOOTP\n");
>   return rv;
>   }
> - return spl_parse_image_header(spl_image,
> -   (struct image_header *)load_addr);
> +
> + if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
> + image_get_magic(header) == FDT_MAGIC) {
> + struct spl_load_info load;
> +
> + debug("Found FIT\n");
> + load.bl_len = 1;
> + load.read = spl_net_load_read;
> + rv = spl_load_simple_fit(spl_image, , 0, header);
> + } else {
> + debug("Legacy image\n");
> +
> + rv = spl_parse_image_header(spl_image, header);
> + }
> +
> + return rv;
>  }
>  #endif
>  
> 

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


Re: [U-Boot] [PATCH v1 1/3] x86: Introduce INTEL_MID quirk option

2017-02-15 Thread Andy Shevchenko
On Wed, 2017-02-15 at 18:09 +0800, Bin Meng wrote:
> Hi Andy,
> 
> On Wed, Feb 15, 2017 at 5:50 PM, Andy Shevchenko
>  wrote:
> > On Wed, 2017-02-15 at 11:00 +0800, Bin Meng wrote:
> > > On Tue, Feb 14, 2017 at 10:47 PM, Andy Shevchenko
> > >  wrote:

> > > What's the architecture of Intel Edison? Normally such platform
> > > Kconfig option should go to arch/x86/cpu//Kconfig
> > 
> > What do you mean?
> > x86_64.
> 
> Sorry I should say what the platform is, like Ivybridge, Baytrail,
> Quark that U-Boot currently supports.

It's misunderstanding here.
arch/x86/cpu//
So, all of above either SoC or platform. A little mess.

So, we will put the code to tangier folder because Intel Tangier is SoC.
Platform is Intel Merrifield.

>  If this is a new platform,

Yes.

>  we
> should probably move it to arch/x86/cpu//Kconfig.

Probably not. Intel MID covers more than one SoC/platform. This option
is x86 scope.

I dunno that U-Boot will run on the rest MID devices, but for sake of
logic and consistency it is not about Edison or Merrifield or Tangier.

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 1/3] x86: Introduce INTEL_MID quirk option

2017-02-15 Thread Bin Meng
Hi Andy,

On Wed, Feb 15, 2017 at 5:50 PM, Andy Shevchenko
 wrote:
> On Wed, 2017-02-15 at 11:00 +0800, Bin Meng wrote:
>> Hi Andy,
>>
>> On Tue, Feb 14, 2017 at 10:47 PM, Andy Shevchenko
>>  wrote:
>> > Intel Mobile Internet Device (MID) platforms have special treatment
>> > in
>> > some cases, such as CPU enumeration or boot parameters
>> > configuration.
>> >
>> > Here we introduce specific quirk option for such cases.
>> >
>> > It is supposed to be selected by Intel MID platform boards, for
>> > example,
>> > Intel Edison.
>>
>> Does this mean you have plan to upstream the Intel Edison support?
>
> Yes.
>
>>
>> >
>> > Signed-off-by: Andy Shevchenko 
>> > ---
>> >  arch/x86/Kconfig | 4 
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> > index 5f9597b230..ba57bcfca4 100644
>> > --- a/arch/x86/Kconfig
>> > +++ b/arch/x86/Kconfig
>> > @@ -80,6 +80,10 @@ config VENDOR_INTEL
>> >
>> >  endchoice
>> >
>> > +# subarchitectures-specific options below
>> > +config INTEL_MID
>> > +   bool
>>
>> What's the architecture of Intel Edison? Normally such platform
>> Kconfig option should go to arch/x86/cpu//Kconfig
>
> What do you mean?
> x86_64.

Sorry I should say what the platform is, like Ivybridge, Baytrail,
Quark that U-Boot currently supports. If this is a new platform, we
should probably move it to arch/x86/cpu//Kconfig.

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


Re: [U-Boot] [PATCH v1 3/3] x86: Intel MID platforms has no microcode update

2017-02-15 Thread Andy Shevchenko
On Wed, 2017-02-15 at 11:10 +0800, Bin Meng wrote:
> Hi Andy,
> 
> On Tue, Feb 14, 2017 at 10:47 PM, Andy Shevchenko
>  wrote:
> > There is no microcode update available for SoCs used on Intel MID
> > platforms.
> > 
> > Use conditional to bypass it.
> > 
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/cpu/mp_init.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> > index 988073cc79..4e2f000f75 100644
> > --- a/arch/x86/cpu/mp_init.c
> > +++ b/arch/x86/cpu/mp_init.c
> > @@ -248,7 +248,7 @@ static int load_sipi_vector(atomic_t
> > **ap_countp, int num_cpus)
> > if (!stack)
> > return -ENOMEM;
> > params->stack_top = (u32)(stack + size);
> > -#if !defined(CONFIG_QEMU) && !defined(CONFIG_HAVE_FSP)
> > +#if !defined(CONFIG_QEMU) && !defined(CONFIG_HAVE_FSP) &&
> > !defined(CONFIG_INTEL_MID)
> > params->microcode_ptr = ucode_base;
> > debug("Microcode at %x\n", params->microcode_ptr);
> >  #endif
> 
> Is this patch necessary? If Intel MID does not define CONFIG_QEMU or
> CONFIG_HAVE_FSP, current logic should work.

This code is executed when neither of option is defined. For Intel MID
we do *not* need to have this code executed.

I dunno how it possible can work otherwise (ucode_base is not defined).

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 1/3] x86: Introduce INTEL_MID quirk option

2017-02-15 Thread Andy Shevchenko
On Wed, 2017-02-15 at 11:00 +0800, Bin Meng wrote:
> Hi Andy,
> 
> On Tue, Feb 14, 2017 at 10:47 PM, Andy Shevchenko
>  wrote:
> > Intel Mobile Internet Device (MID) platforms have special treatment
> > in
> > some cases, such as CPU enumeration or boot parameters
> > configuration.
> > 
> > Here we introduce specific quirk option for such cases.
> > 
> > It is supposed to be selected by Intel MID platform boards, for
> > example,
> > Intel Edison.
> 
> Does this mean you have plan to upstream the Intel Edison support?

Yes.

> 
> > 
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/Kconfig | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 5f9597b230..ba57bcfca4 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -80,6 +80,10 @@ config VENDOR_INTEL
> > 
> >  endchoice
> > 
> > +# subarchitectures-specific options below
> > +config INTEL_MID
> > +   bool
> 
> What's the architecture of Intel Edison? Normally such platform
> Kconfig option should go to arch/x86/cpu//Kconfig

What do you mean?
x86_64.

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 04/10] arm64: a37xx: Handle pin controls in early board init

2017-02-15 Thread Konstantin Porotchkin



On 02/14/2017 02:25 PM, Konstantin Porotchkin wrote:



On 2/14/2017 14:21, Stefan Roese wrote:

On 14.02.2017 13:07, Konstantin Porotchkin wrote:

Hi, Stefan,

On 2/14/2017 13:43, Stefan Roese wrote:

Hi Kosta,

On 13.02.2017 14:38, kos...@marvell.com wrote:

From: Konstantin Porotchkin 

Fix the default pin control values in a board-specific
function on early board init stage.
This fix allows the NETA driver to work in RGMII
mode until the full-featured pin control driver gets
introduced.

Signed-off-by: Konstantin Porotchkin 
Cc: Stefan Roese 
Cc: Igal Liberman 
---
 board/Marvell/mvebu_db-88f3720/board.c | 26
+-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/board/Marvell/mvebu_db-88f3720/board.c
b/board/Marvell/mvebu_db-88f3720/board.c
index edf88c7..3337f3f 100644
--- a/board/Marvell/mvebu_db-88f3720/board.c
+++ b/board/Marvell/mvebu_db-88f3720/board.c
@@ -19,9 +19,33 @@ DECLARE_GLOBAL_DATA_PTR;
 #define I2C_IO_REG_0_SATA_OFF2
 #define I2C_IO_REG_0_USB_H_OFF1

+#define PINCTRL_NB_REG_VALUE0x000173fa
+#define PINCTRL_SB_REG_VALUE0x7a23
+


I am aware that this is a temporary solution, but are these values
correct for the A3720-DB or only the ESPRESSBin board?

They are good for the DB board as well. Actually without this change the
NETA driver will crash if we try to ping the server.


Okay. And do you have any ideas on when this pinctrl driver might be
available?

I will query our team that is responsible for A37xx features. I think
they are currently working on SATA/SCSI issues discovered when moved to
the new code base. Hope the pin control will be the next task, but I
have to ensure it.


Just got an update - the pin control driver task is scheduled to March.






BTW: You are now using the "Marvell/mvebu_db-88f3720" board directory
for multiple board and not only the A3720-DB. I would prefer to see
a rename of the board directory before this, like we've done to the
A7k/8k directory. What do you think?

Agree, I can do it. Should we change it in this patch series or
introduce an additional patch later?


We have no chance to get this patchset into this release, so we have
a bit of time for the next one. I would prefer a clean switch and
add this rename as one of the first patches in the next version of
this patchset.

Ok, got you, I will work on this change.



Thanks,
Stefan

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


Re: [U-Boot] [PATCH] env_mmc: Allow SPL to use any MMC device to load/save the environment

2017-02-15 Thread Jean-Jacques Hiblot



On 14/02/2017 19:52, Tom Rini wrote:

On Tue, Feb 14, 2017 at 02:16:13PM +0100, Jean-Jacques Hiblot wrote:


Hi Tom,

Have you had a chance to look at the patch below?

It looks fine but was too close to the release window (given the
potential impact) to merge.  Thanks!

Ok Thank you for the feedback.



Jean-Jacques


On 01/02/2017 11:26, Jean-Jacques Hiblot wrote:

SPL has been restricted to use only dev 0 based on the assumption that only
one MMC device is registered. This is not always the case and many
platforms now register several devices as expected by the spl mmc boot code
For those platform SPL_ENV_SUPPORT is broken if dev is forced to 0.

A word of warning: this commit may break SPL_ENV_SUPPORT on platforms that
do not register the same MMC controllers in SPL and in u-boot (mostly iMX6
based platforms). Fortunately none of those activate SPL_ENV_SUPPORT in
their default configuration.

Signed-off-by: Jean-Jacques Hiblot 
---
  common/env_mmc.c | 15 ---
  1 file changed, 15 deletions(-)

diff --git a/common/env_mmc.c b/common/env_mmc.c
index 16f6a17..a5d14d4 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -82,10 +82,6 @@ static int mmc_set_env_part(struct mmc *mmc)
int dev = mmc_get_env_dev();
int ret = 0;
-#ifdef CONFIG_SPL_BUILD
-   dev = 0;
-#endif
-
env_mmc_orig_hwpart = mmc_get_blk_desc(mmc)->hwpart;
ret = blk_select_hwpart_devnum(IF_TYPE_MMC, dev, part);
if (ret)
@@ -116,9 +112,6 @@ static void fini_mmc_for_env(struct mmc *mmc)
  #ifdef CONFIG_SYS_MMC_ENV_PART
int dev = mmc_get_env_dev();
-#ifdef CONFIG_SPL_BUILD
-   dev = 0;
-#endif
blk_select_hwpart_devnum(IF_TYPE_MMC, dev, env_mmc_orig_hwpart);
  #endif
  }
@@ -223,10 +216,6 @@ void env_relocate_spec(void)
ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env1, 1);
ALLOC_CACHE_ALIGN_BUFFER(env_t, tmp_env2, 1);
-#ifdef CONFIG_SPL_BUILD
-   dev = 0;
-#endif
-
mmc = find_mmc_device(dev);
errmsg = init_mmc_for_env(mmc);
@@ -306,10 +295,6 @@ void env_relocate_spec(void)
int dev = mmc_get_env_dev();
const char *errmsg;
-#ifdef CONFIG_SPL_BUILD
-   dev = 0;
-#endif
-
mmc = find_mmc_device(dev);
errmsg = init_mmc_for_env(mmc);


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


Re: [U-Boot] [PATCH 07/10] mvebu: a37xx: Add init for ESPRESSBin Topaz switch

2017-02-15 Thread Konstantin Porotchkin

Hi, Joe,

On 02/14/2017 07:17 PM, Joe Hershberger wrote:

On Tue, Feb 14, 2017 at 6:32 AM, Stefan Roese  wrote:
> (added Joe to Cc as network custodian)
>
>
> On 14.02.2017 13:13, Konstantin Porotchkin wrote:
>>
>> Hi, Stefan,
>>
>> On 2/14/2017 13:49, Stefan Roese wrote:
>>>
>>> Hi Kosta,
>>>
>>> On 13.02.2017 14:38, kos...@marvell.com wrote:

 From: Konstantin Porotchkin 

 Implement the board-specific network init function for
 ESPRESSOBin community board, setting the on-board Topaz
 switch port to forward mode and allow network connection
 through any of the available Etherenet ports.

 Signed-off-by: Konstantin Porotchkin 
 Cc: Stefan Roese 
 Cc: Igal Liberman 
 ---
  board/Marvell/mvebu_db-88f3720/board.c | 49
 ++
  1 file changed, 49 insertions(+)

 diff --git a/board/Marvell/mvebu_db-88f3720/board.c
 b/board/Marvell/mvebu_db-88f3720/board.c
 index 3337f3f..45098ce 100644
 --- a/board/Marvell/mvebu_db-88f3720/board.c
 +++ b/board/Marvell/mvebu_db-88f3720/board.c
 @@ -6,6 +6,7 @@

  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -156,3 +157,51 @@ int board_xhci_enable(void)

  return 0;
  }
 +
 +static int mii_multi_chip_mode_write(struct mii_dev *bus, int
 dev_smi_addr,
 + int smi_addr, int reg, u16 value)
 +{
 +u16 data = 0;
 +
 +if (bus->write(bus, dev_smi_addr, 0, 1, value) != 0) {
 +printf("Error writing to the PHY addr=%02x reg=%02x\n",
 +   smi_addr, reg);
 +return -EFAULT;
 +}
 +
 +data = (1 << 15) | (1 << 12) | (1 << 10) | (smi_addr << 5) | reg;
 +if (bus->write(bus, dev_smi_addr, 0, 0, data) != 0) {
 +printf("Error writing to the PHY addr=%02x reg=%02x\n",
 +   smi_addr, reg);
 +return -EFAULT;
 +}
 +
 +return 0;
 +}
 +
 +
 +int board_network_enable(struct mii_dev *bus)
 +{
 +if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
 +return 0;
 +
 +/*
 + * FIXME: remove this code once Topaz driver gets available
 + * A3720 Community Board Only
 + * Configure Topaz switch (88E6341)
 + * Set port 0,1,2,3 to forwarding Mode
 + */
>>>
>>>
>>> Just checking: Is this "Topaz switch driver" something thats being
>>> worked on or in the queue to do?
>>
>>
>> I currently do not have it in my queue.
>> I think the driver exists in the kernel (or will exist in 4.10/4.11
>> release), so we may want to port it if required.
>> Which switch operations are needed at u-bot stage?
>
>
> I'm not 100% sure if there is anything really "needed" other than
> to get some ports into operation for the ethernet driver connected
> to this switch. So it might be that such a few register writes
> are acceptable - I'm pretty sure other boards do it this way as
> well.
>
> On the other hand you could take a look at the
> "drivers/net/phy/mv88e61xx.c" switch driver. Might be that this is
> something similar to what you want / need.

I think the switch driver to model after is drivers/net/vsc9953.c -
there is a command: cmd/ethsw.c / include ethsw.h that implements the
framework (doc/README.t1040-l2switch).


I will check this code, thank you for the reference!


There is also the drivers/net/cpsw.c that just hard-codes the config.
Eth switches have varying levels of support. What level of support are
you able to implement?

I am not really sure about level of support required by the u-boot.
The Linux driver configures the 3 output ports of this switch as lan0, lan1
and wan interfaces, so they are presented to the kernel as separate NICs.
So if I set the NFS server on lan0 and the cable connected to lan1, the
connection attempt will fail.
The u-boot code however just sets the switch ports to follow all the traffic
to the CPU. So when I tfttpload image using default neta0 interface, any
switch port will work for that.
Anyway, I will check what is supported by the reference code you just pointed
and check what I can provide.
I personally not an expert in this Topaz switch internals and may need to 
request help
from other Marvell teams for doing something smarter than the code already
provided in this patch.


Thanks,
-Joe



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


Re: [U-Boot] Assigning u-boot environment variables from memory

2017-02-15 Thread Lukasz Majewski
On Tue, 14 Feb 2017 14:27:30 -0700 (MST)
brendan  wrote:

> I am storing some information regarding my board within EEPROM (in
> memory after I use the >eeprom read command) and I was wondering if
> it was possible for me to somehow read from memory and store the
> values into an environment variable.

You might look at "env import ..." command.

It should do what you need. Please also pay attention to its switches
-r| -t ... etc.

> 
> I have done a search but could not find anything of relevance.  
> 
> Thanks
> 
> 
> 
> --
> View this message in context:
> http://u-boot.10912.n7.nabble.com/Assigning-u-boot-environment-variables-from-memory-tp281788.html
> Sent from the U-Boot mailing list archive at Nabble.com.
> ___ U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/6] arm: am57xx: reintroduce the CONFIG_AM57XX symbol

2017-02-15 Thread Roger Quadros
On 14/02/17 22:12, Tom Rini wrote:
> On Tue, Feb 14, 2017 at 01:26:24PM -0600, Nishanth Menon wrote:
>> On 02/14/2017 01:20 PM, Tom Rini wrote:
>>> On Tue, Feb 14, 2017 at 01:18:20PM -0600, menon.nisha...@gmail.com wrote:
 On Mon, Feb 13, 2017 at 7:27 AM, Tom Rini  wrote:
> On Mon, Feb 13, 2017 at 01:34:52PM +0200, Uri Mashiach wrote:
>
>> The SOC family symbol CONFIG_AM57XX was removed by the commit
>> 3891a54: "ARM: DRA7x/AM57xx: Get rid of CONFIG_AM57XX".
>>
>> The symbol is needed by the XHCI OMAP USB driver.
>> Without the symbol all the AM57x targets symbols should be ored in the
>> ifdef'ery.
>>
>> Signed-off-by: Uri Mashiach 
>
> We need to introduce it into Kconfig files now, thanks!

 DRA7 and AM57xx are literally the same. the #ifdeffery in USB is more
 to do which port to use rather than having anything to do with DRA7 Vs
 AM57xx.
>>>
>>> Yes, agreed.  And we need to solve this, and introduce some Kconfig
>>> CONFIG symbol to deal with it.  Maybe the better way to look at this is,
>>> can we have DRA7xx boards configured in the way Uri wants to be able to
>>> configure the AM57xx board he's working with? And vice versa?  The
>>> answer to that will help drive what the right CONFIG_xxx name is.
>>
>> Should'nt be ideally done via DM model instead? I have no
>> understanding of USB integration done in u-boot to comment better.
> 
> That's also something that could be explored.
> 

Yes, ideally this should be taken care of by DM.
Till that migration is complete I'm fine with fixing this temporarily.

OMAP5, DRA7, AM57 and AM43 use different XHCI_BASE address.

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