Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

2018-05-08 Thread Marty E. Plummer
On Tue, May 08, 2018 at 11:08:14PM +0200, Dr. Philipp Tomsich wrote:
> 
> > On 8 May 2018, at 21:21, Marty E. Plummer  wrote:
> > 
> > On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
> >> Marty,
> >> 
> >>> On 8 May 2018, at 02:52, Marty E. Plummer  wrote:
> >>> 
> >>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
>  
> > On 7 May 2018, at 04:34, Marty E. Plummer  
> > wrote:
> > 
> > On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
> >> Hi Marty,
> >> 
> >> 
> >> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> >>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> >>> 
> >>> Without this change, my u-boot build for the asus c201 chromebook 
> >>> (4GiB)
> >>> is incorrectly detected as 0 Bytes of ram.
> >> 
> >> I know the root cause for this issue, and I have a local patch for it.
> >> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
> >> before
> >> the max size before return with '<<20'. Sorry for forgot to send it 
> >> out.
> >> 
> >>> 
> >>> Signed-off-by: Marty E. Plummer 
> >>> ---
> >>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
> >>> 1 file changed, 37 insertions(+), 25 deletions(-)
> >>> 
> >>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
> >>> b/arch/arm/mach-rockchip/sdram_common.c
> >>> index 76dbdc8715..a9c9f970a4 100644
> >>> --- a/arch/arm/mach-rockchip/sdram_common.c
> >>> +++ b/arch/arm/mach-rockchip/sdram_common.c
> >>> @@ -10,6 +10,8 @@
> >>> #include 
> >>> #include 
> >>> #include 
> >>> +#include 
> >>> +#include 
> >>> 
> >>> DECLARE_GLOBAL_DATA_PTR;
> >>> size_t rockchip_sdram_size(phys_addr_t reg)
> >>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> >>>   size_t size_mb = 0;
> >>>   u32 ch;
> >>> 
> >>> - u32 sys_reg = readl(reg);
> >>> - u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> >>> -& SYS_REG_NUM_CH_MASK);
> >>> + if (!size_mb) {
> >> 
> >> I don't understand this and follow up changes, we don't really need it,
> >> isn't it?
> >> I think don't need the changes before here.
> > Yeah, that was just another level of indentation for the if (!size_mb)
> > guard, but I've reworked the patch to not do that as it was pointed out
> > that since size_mb is initialized to 0 prior.
> >>> + /*
> >>> +  * we use the 0x~0xfeff space
> >>> +  * since 0xff00~0x is soc register space
> >>> +  * so we reserve it
> >>> +  */
> >>> + size_mb = min(size_mb, 0xff00/SZ_1M);
> >> 
> >> This is what we really need, as Klaus point out, we need to use
> >> SDRAM_MAX_SIZE
> >> instead of hard code.
> > Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> > build and boot tested on my hardware.
>  
>  In that case you just masked the problem but didn???t solve it: assuming 
>  size_mb
>  is size_t (I???ll assume this is 64bit, but did not check), then your 
>  4GB is 0x1__ )
>  which overflows to 0x0 when converted to a u32.
>  
>  In other words: we need to figure out where the truncation occurs (image 
>  what
>  happens if a new 32bit processor with LPAE comes out???).
>  
> >>> A very valid point. With the following patch to sdram_common.c and
> >>> sdram_rk3288.c applied I get the debug output that follows it:
> >>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
> >>> b/arch/arm/mach-rockchip/sdram_common.c
> >>> index 232a7fa655..0fe69bf558 100644
> >>> --- a/arch/arm/mach-rockchip/sdram_common.c
> >>> +++ b/arch/arm/mach-rockchip/sdram_common.c
> >>> @@ -4,6 +4,7 @@
> >>> * SPDX-License-Identifier: GPL-2.0+
> >>> */
> >>> 
> >>> +#define DEBUG 1
> >>> #include 
> >>> #include 
> >>> #include 
> >>> @@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> >>>   SYS_REG_ROW_3_4_MASK;
> >>> 
> >>>   chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> >>> + debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__, 
> >>> chipsize_mb);
> >>> 
> >>>   if (rank > 1)
> >>>   chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
> >>>   if (row_3_4)
> >>>   chipsize_mb = chipsize_mb * 3 / 4;
> >>>   size_mb += chipsize_mb;
> >>> + debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
> >>>   debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
> >>> rank, col, bk, cs0_row, bw, row_3_4);
> >>>   }
> >>> 
> >>> + debug("%s: %d: size_mb %x\n", 

Re: [U-Boot] [PATCH] driver: net: fsl-mc: updated copyright info

2018-05-08 Thread Yogesh Narayan Gaur
Patch rebased with top, v2 send.

Yogesh Gaur

-Original Message-
From: York Sun 
Sent: Tuesday, May 8, 2018 9:19 PM
To: Yogesh Narayan Gaur ; u-boot@lists.denx.de
Subject: Re: [PATCH] driver: net: fsl-mc: updated copyright info

On 03/15/2018 02:07 AM, Yogesh Narayan Gaur wrote:
> Updated copyright info for the issues reported after running 
> check-legal test.
> 
> Signed-off-by: Yogesh Gaur 
> ---
> Legally NXP and Freescale Semiconductor are same entity.

Can you refresh this patch? It has conflict with Tom's recent change on SPDX.

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


[U-Boot] [PATCH v2] driver: net: fsl-mc: updated copyright info

2018-05-08 Thread Yogesh Gaur
Updated copyright info for the issues reported after running
check-legal test.

Signed-off-by: Yogesh Gaur 
Reviewed-by: York Sun 
---
Legally NXP and Freescale Semiconductor are same entity.
Changes for v2:
- Rebase to top as per York's comment.

 drivers/net/fsl-mc/dpbp.c  | 2 +-
 drivers/net/fsl-mc/dpio/dpio.c | 2 +-
 drivers/net/fsl-mc/dpmac.c | 2 +-
 drivers/net/fsl-mc/dpni.c  | 2 +-
 drivers/net/fsl-mc/dprc.c  | 2 +-
 drivers/net/fsl-mc/fsl_dpmng_cmd.h | 2 +-
 drivers/net/fsl-mc/mc.c| 4 ++--
 drivers/net/ldpaa_eth/ldpaa_eth.c  | 2 +-
 drivers/net/ldpaa_eth/ldpaa_eth.h  | 2 +-
 include/fsl-mc/fsl_dpbp.h  | 2 +-
 include/fsl-mc/fsl_dpio.h  | 2 +-
 include/fsl-mc/fsl_dpmac.h | 2 +-
 include/fsl-mc/fsl_dpni.h  | 2 +-
 include/fsl-mc/fsl_dprc.h  | 2 +-
 include/fsl-mc/fsl_mc_cmd.h| 2 +-
 include/fsl-mc/fsl_mc_private.h| 2 +-
 16 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/net/fsl-mc/dpbp.c b/drivers/net/fsl-mc/dpbp.c
index 327bee9..c609efb 100644
--- a/drivers/net/fsl-mc/dpbp.c
+++ b/drivers/net/fsl-mc/dpbp.c
@@ -2,7 +2,7 @@
 /*
  * Freescale Layerscape MC I/O wrapper
  *
- * Copyright (C) 2013-2016 Freescale Semiconductor, Inc.
+ * Copyright 2013-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  */
 #include 
diff --git a/drivers/net/fsl-mc/dpio/dpio.c b/drivers/net/fsl-mc/dpio/dpio.c
index 0bbb760..8884455 100644
--- a/drivers/net/fsl-mc/dpio/dpio.c
+++ b/drivers/net/fsl-mc/dpio/dpio.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2013-2016 Freescale Semiconductor
+ * Copyright 2013-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  */
 
diff --git a/drivers/net/fsl-mc/dpmac.c b/drivers/net/fsl-mc/dpmac.c
index 2aadd4a..43a2ff4 100644
--- a/drivers/net/fsl-mc/dpmac.c
+++ b/drivers/net/fsl-mc/dpmac.c
@@ -2,7 +2,7 @@
 /*
  * Freescale Layerscape MC I/O wrapper
  *
- * Copyright (C) 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2015-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  * Author: Prabhakar Kushwaha 
  */
diff --git a/drivers/net/fsl-mc/dpni.c b/drivers/net/fsl-mc/dpni.c
index 5cf5eeb..443e430 100644
--- a/drivers/net/fsl-mc/dpni.c
+++ b/drivers/net/fsl-mc/dpni.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2013-2016 Freescale Semiconductor
+ * Copyright 2013-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  */
 
diff --git a/drivers/net/fsl-mc/dprc.c b/drivers/net/fsl-mc/dprc.c
index 38d19a4..e0a2865 100644
--- a/drivers/net/fsl-mc/dprc.c
+++ b/drivers/net/fsl-mc/dprc.c
@@ -2,7 +2,7 @@
 /*
  * Freescale Layerscape MC I/O wrapper
  *
- * Copyright (C) 2013-2016 Freescale Semiconductor, Inc.
+ * Copyright 2013-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  */
 
diff --git a/drivers/net/fsl-mc/fsl_dpmng_cmd.h 
b/drivers/net/fsl-mc/fsl_dpmng_cmd.h
index 9e6f27a..e18c88d 100644
--- a/drivers/net/fsl-mc/fsl_dpmng_cmd.h
+++ b/drivers/net/fsl-mc/fsl_dpmng_cmd.h
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
-/* Copyright 2013-2016 Freescale Semiconductor Inc.
+/* Copyright 2013-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  */
 #ifndef __FSL_DPMNG_CMD_H
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 58612cf..982024e 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2017 NXP Semiconductors
- * Copyright (C) 2014 Freescale Semiconductor
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
  */
 #include 
 #include 
diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c 
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index 8688dd4..79facb4 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2014-2016 Freescale Semiconductor
+ * Copyright 2014-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  */
 
diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.h 
b/drivers/net/ldpaa_eth/ldpaa_eth.h
index 54cb633..ee784a5 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.h
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /*
- * Copyright (C) 2014-2016 Freescale Semiconductor
+ * Copyright 2014-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  */
 
diff --git a/include/fsl-mc/fsl_dpbp.h b/include/fsl-mc/fsl_dpbp.h
index 8d7c14d..2278ac9 100644
--- a/include/fsl-mc/fsl_dpbp.h
+++ b/include/fsl-mc/fsl_dpbp.h
@@ -2,7 +2,7 @@
 /*
  * Freescale Layerscape MC I/O wrapper
  *
- * Copyright (C) 2013-2016 Freescale Semiconductor, Inc.
+ * Copyright 2013-2016 Freescale Semiconductor, Inc.
  * Copyright 2017 NXP
  */
 /*!
diff --git a/include/fsl-mc/fsl_dpio.h b/include/fsl-mc/fsl_dpio.h
index c300c94..7788e19 100644

Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

2018-05-08 Thread Petr Vorel
Hi Eugeniu,

> Not sure if partial/limited sync with Linux Kconfig is practiced, but
> if yes, then pick below three Linux commits, which are focused around
> improving the readability of reverse dependencies in menuconfig UI.

> [1] commit 1ccb27143360bd2390a9a970e50709f858b53761
> Author: Petr Vorel 
> kconfig: make "Selected by:" and "Implied by:" readable

> [2] commit 9a47ceec543bfb703fbe2f8d584850b582caf1a6
> Masahiro Yamada 
> kconfig: clean-up reverse dependency help implementation

> [3] commit d9119b5925a03b9a3191fa3e93b4091651d8ad25
> Author: Eugeniu Rosca 
> kconfig: Print reverse dependencies in groups

Thanks for doing it. I also think that syncing to Linux version is better way.


Kind regards,
Petr
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] ARM: dts: exynos5: remove the duplicated nodes

2018-05-08 Thread Anand Moon
Hi Jaehoon,

On 12 January 2018 at 16:37, Jaehoon Chung  wrote:
> Remove the duplicated gic and combiner nodes in exynos5.dtsi.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  arch/arm/dts/exynos5.dtsi | 27 ---
>  1 file changed, 27 deletions(-)
>
> diff --git a/arch/arm/dts/exynos5.dtsi b/arch/arm/dts/exynos5.dtsi
> index 8650800f52..8b725c0ddc 100644
> --- a/arch/arm/dts/exynos5.dtsi
> +++ b/arch/arm/dts/exynos5.dtsi
> @@ -45,33 +45,6 @@
> #size-cells = <0>;
> };
>
> -   combiner: interrupt-controller@1044 {
> -   compatible = "samsung,exynos4210-combiner";
> -   #interrupt-cells = <2>;
> -   interrupt-controller;
> -   samsung,combiner-nr = <32>;
> -   reg = <0x1044 0x1000>;
> -   interrupts =<0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
> -   <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
> -   <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
> -   <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>,
> -   <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>,
> -   <0 20 0>, <0 21 0>, <0 22 0>, <0 23 0>,
> -   <0 24 0>, <0 25 0>, <0 26 0>, <0 27 0>,
> -   <0 28 0>, <0 29 0>, <0 30 0>, <0 31 0>;
> -   };
> -
> -   gic: interrupt-controller@10481000 {
> -   compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
> -   #interrupt-cells = <3>;
> -   interrupt-controller;
> -   reg =   <0x10481000 0x1000>,
> -   <0x10482000 0x1000>,
> -   <0x10484000 0x2000>,
> -   <0x10486000 0x2000>;
> -   interrupts = <1 9 0xf04>;
> -   };
> -
> i2c_0: i2c@12C6 {
> compatible = "samsung,s3c2440-i2c";
> reg = <0x12C6 0x100>;
> --
> 2.15.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

Looks like this series of patch is missing in u-boot git repository.

Best Regards
-Anand
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] SYS_HAVE_*CACHE_MAINTENANCE

2018-05-08 Thread AKASHI Takahiro
Emmanuel,

# Since I haven't subscribed the ML, I can't reply to your post directly.

You haven't enabled those configs on armv8/ARM64 (and other arch's as well).
So if your patch is merged "as it is," I'm afraid that it will
break some functions/commands on such architectures that already
have cache maintenance operations without knowing those new configs.

Thanks,
-Takahiro AKASHI
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot,v2] cmd: add ADC cli commands

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 03:17:57PM +0200, Neil Armstrong wrote:

> Add an 'adc' cli command to get adc devices informations and read single
> shots datas.
> 
> Signed-off-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] image: fit: Show signatures and hashes for configurations

2018-05-08 Thread Tom Rini
On Mon, Apr 30, 2018 at 11:06:40AM +0200, Clément Péron wrote:

> The signature/hash information are displayed for images but nor for
> configurations.
> 
> Add subnodes printing in fit_conf_print() like it's done in fit_image_print()
> 
> Signed-off-by: Clément Péron 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

2018-05-08 Thread Tom Rini
On Wed, May 09, 2018 at 10:27:00AM +0900, Masahiro Yamada wrote:
> Hi.
> 
> 2018-05-09 2:59 GMT+09:00 Eugeniu Rosca :
> > Not sure if partial/limited sync with Linux Kconfig is practiced, but
> > if yes, then pick below three Linux commits, which are focused around
> > improving the readability of reverse dependencies in menuconfig UI.
> >
> > [1] commit 1ccb27143360bd2390a9a970e50709f858b53761
> > Author: Petr Vorel 
> > kconfig: make "Selected by:" and "Implied by:" readable
> >
> > [2] commit 9a47ceec543bfb703fbe2f8d584850b582caf1a6
> > Masahiro Yamada 
> > kconfig: clean-up reverse dependency help implementation
> >
> > [3] commit d9119b5925a03b9a3191fa3e93b4091651d8ad25
> > Author: Eugeniu Rosca 
> > kconfig: Print reverse dependencies in groups
> >
> > Here is an example of re-formatted information about the reverse
> > dependencies of CONFIG_DM (sandbox_defconfig):
> >
> > * W/o the imported commits:
> >
> > Selected by: NIOS2 [=n] &&  || SANDBOX [=y] &&  || X86
> > [=n] &&  || ARCH_MVEBU [=n] &&  || TARGET_STV0991 [=n]
> > &&  || ARCH_BCM283X [=n] &&  || ARCH_EXYNOS [=n] &&
> >  || ARCH_S5PC1XX [=n] && ...
> >
> > * With the imported commits:
> >
> >   Selected by [y]:
> >   - SANDBOX [=y] && 
> >   - LOG [=y]
> >   Selected by [n]:
> >   - NIOS2 [=n] && 
> >   - X86 [=n] && 
> >   - ARCH_MVEBU [=n] && 
> >   - TARGET_STV0991 [=n] && 
> >   - ARCH_BCM283X [=n] && 
> >   - ARCH_EXYNOS [=n] && 
> >   - ARCH_S5PC1XX [=n] && 
> >   - ARCH_INTEGRATOR [=n] && 
> >   - ARCH_MX8M [=n] && 
> >   - ARCH_QEMU [=n] && 
> >   - ARCH_RMOBILE [=n] && 
> >   - ARCH_SNAPDRAGON [=n] && 
> >   - ARCH_SOCFPGA [=n] && 
> >   - ARCH_SUNXI [=n] && 
> >   - ARCH_ZYNQ [=n] && 
> >   - ARCH_ZYNQMP [=n] && 
> >   - TARGET_HIKEY [=n] && 
> >   ...
> >
> > Signed-off-by: Eugeniu Rosca 
> 
> 
> I prefer syncing to check-picking.
> 
> 
> The previous sync was Linux 4.10
> 
> 
> 
> commit bf7ab1e70fd7621fea5dea07b6975c576119b86e
> Author: Masahiro Yamada 
> Date:   Sat Feb 11 12:39:54 2017 +0900
> 
> kconfig: re-sync with Linux 4.10
> 
> Re-sync all files under the scripts/kconfig directory with
> Linux 4.10.
> 
> Some parts include U-Boot own modification.  I made sure to not
> revert the following commits:
> 
>  5b8031ccb4ed ("Add more SPDX-License-Identifier tags")
>  192bc6948b02 ("Fix GCC format-security errors and convert sprintfs.")
>  da58dec86616 ("Various Makefiles: Add SPDX-License-Identifier tags")
>  20c20826efab ("Kconfig: Enable usage of escape char '\' in string 
> values")
> 
> Signed-off-by: Masahiro Yamada 
> 
> 
> I still we still need to carry 20c20826efab for U-Boot.
> 
> 
> Would you do that please?
> Or, do you want me to do it?

I'd greatly appreciate it if you can do a sync up to v4.17-rc4 or so.
Thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2] gdsys: drivers: Add gdsys_rxaui_ctrl driver

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 02:53:33PM +0200, Mario Six wrote:

> Add a driver for RXAUI control on IHS FPGAs.
> 
> Signed-off-by: Mario Six 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 1/3] pci: Don't use pci_indirect when DM is active

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 02:53:37PM +0200, Mario Six wrote:

> Declaration of indirect PCI bridges is not compatible with DM: Both
> define PCI operations, but in different ways. Hence, don't use indirect
> bridges if DM is active.
> 
> Signed-off-by: Mario Six 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v2] clk: Add ICS8N3QV01 driver

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 02:53:15PM +0200, Mario Six wrote:

> Add a driver for the ICS8N3QV01 Quad-Frequency Programmable VCXO.
> 
> Signed-off-by: Mario Six 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v2,2/2] ihs_mdio: Make DM-compatible

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 02:52:10PM +0200, Mario Six wrote:

> Make the ihs_mdio driver DM-compatible, while retaining the old
> functionality for not-yet-converted boards.
> 
> Signed-off-by: Mario Six 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] arm: bitops: fix find_next_zero_bit() for case size < 32

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 07:58:49PM -0500, Grygorii Strashko wrote:

> find_next_zero_bit() incorrectly handles cases when:
> - total bitmap size < 32
> - rest of bits to process
> 
> static inline int find_next_zero_bit(void *addr, int size, int offset)
> {
>   unsigned long *p = ((unsigned long *)addr) + (offset >> 5);
>   unsigned long result = offset & ~31UL;
>   unsigned long tmp;
> 
>   if (offset >= size)
>   return size;
>   size -= result;
>   offset &= 31UL;
>   if (offset) {
>   tmp = *(p++);
>   tmp |= ~0UL >> (32-offset);
>   if (size < 32)
> [1]
>   goto found_first;
>   if (~tmp)
>   goto found_middle;
>   size -= 32;
>   result += 32;
>   }
>   while (size & ~31UL) {
>   tmp = *(p++);
>   if (~tmp)
>   goto found_middle;
>   result += 32;
>   size -= 32;
>   }
> [2]
>   if (!size)
>   return result;
>   tmp = *p;
> 
> found_first:
> [3]  tmp |= ~0UL >> size;
> 
> ^^^ algo can reach above line from from points:
>  [1] offset > 0 and size < 32, tmp[offset-1..0] bits set to 1
>  [2] size < 32 - rest of bits to process
>  in both cases bits to search are tmp[size-1..0], but line [3] will simply
>  set all tmp[31-size..0] bits to 1 and ffz(tmp) below will fail.
> 
> example: bitmap size = 16, offset = 0, bitmap is empty.
>  code will go through the point [2], tmp = 0x0
>  after line [3] => tmp = 0x and ffz(tmp) will return 16.
> 
> found_middle:
>   return result + ffz(tmp);
> }
> 
> Fix it by correctly seting tmp[31..size] bits to 1 in the above case [3].
> 
> Fixes: 81e9fe5a2988 ("arm: implement find_next_zero_bit function")
> Signed-off-by: Grygorii Strashko 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] bootm.c: Correct the flush_len used in bootm_load_os()

2018-05-08 Thread Tom Rini
On Tue, May 01, 2018 at 12:32:37PM -0400, Tom Rini wrote:

> In do_bootm_states when doing BOOTM_STATE_LOADOS we use load_end
> uninitialized and Coverity notes this now.  This however leads down
> another interesting path.  We pass this pointer to bootm_load_os and
> that in turn uses this uninitialized value immediately to calculate the
> flush length, and is wrong.  We do not know what load_end will be until
> after bootm_decomp_image is called, so we must only set flush_len after
> that.  All of this also makes it clear that the only reason we pass a
> pointer for load_end to bootm_load_os is so that we can call lmb_reserve
> on success.  Rather than initialize load_end to 0 in do_bootm_states we
> can just call lmb_reserve ourself.
> 
> Reported-by: Coverity (CID: 175572)
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v2,1/2] ihs_mdio: Encapsulate register access

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 02:52:09PM +0200, Mario Six wrote:

> To prepare for DM conversion, encapsulate all register accesses in
> function calls.
> 
> Signed-off-by: Mario Six 

Applied to u-boot/master, thanks!

-- 
Tom


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


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

2018-05-08 Thread Tom Rini
On Tue, May 08, 2018 at 10:32:20AM +0900, Masahiro Yamada wrote:

> Hi Tom,
> 
> Now that MW is open, please pull UniPhier SoC updates.
> Thanks.
> 
> 
> The following changes since commit a43d46a73cb2c40481791cb292b8eb0b5a80d55e:
> 
>   arm: v7R: Add support for enabling caches (2018-05-07 15:53:29 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-uniphier.git master
> 
> for you to fetch changes up to 079b54f29e4bfacb4a84c859d8ea95e50fb50bb5:
> 
>   ARM: uniphier: enable CONFIG_PINCONF (2018-05-08 10:25:15 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v3] db410c: set clk node to be probed before relocation

2018-05-08 Thread Tom Rini
On Fri, Apr 20, 2018 at 10:39:50PM +0300, Ramon Fried wrote:

> The clock node is used by the serial driver and it's needed
> before relocation.
> This patch ensures that the msm-serial driver can actually
> use the clock node.
> 
> Signed-off-by: Ramon Fried 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2] arm: ti: boot: Extract PARTS_DEFAULT to boot.h

2018-05-08 Thread Tom Rini
On Thu, Apr 19, 2018 at 11:57:30PM +0300, Sam Protsenko wrote:

> Eliminate code duplication: the same PARTS_DEFAULT was defined in
> am57xx_evm.h and in dra7xx_evm.h. Extract it to environment/boot.h and
> use in all OMAP5-based boards.
> 
> Signed-off-by: Sam Protsenko 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] ARM: dts: sti: Add stih410-b2260-u-boot.dtsi

2018-05-08 Thread Tom Rini
On Fri, Apr 20, 2018 at 09:53:55AM +0200, Patrice Chotard wrote:

> STiH410 has 2 PHYs wired on the DWC3 IP, USB2 and USB3 PHYs.
> As currently no U-boot driver is available for the USB3 PHY and to avoid
> issue during DWC3 drive probe, we use DWC3 IP with only USB2 PHY
> using stih410-b2260-u-boot.dtsi file.
> 
> Fixes: 2fd4242cc50e ("ubs: xhci-dwc3: Enable USB3 PHY when available")
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [GIT PULL] Please pull u-boot-mmc master

2018-05-08 Thread Tom Rini
On Tue, May 08, 2018 at 04:22:14PM +0900, Jaehoon Chung wrote:

> Dear Tom,
> 
> Could you pull these patches to u-boot/master?
> If there is a problem, let me know, plz.
> 
> The following changes since commit a43d46a73cb2c40481791cb292b8eb0b5a80d55e:
> 
>   arm: v7R: Add support for enabling caches (2018-05-07 15:53:29 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-mmc.git master
> 
> for you to fetch changes up to e1fd9e6bb88a3f42e7e89e9c59589dbf904efe23:
> 
>   power: pwm regulator: support live tree (2018-05-08 13:12:33 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

2018-05-08 Thread Masahiro Yamada
Hi.

2018-05-09 2:59 GMT+09:00 Eugeniu Rosca :
> Not sure if partial/limited sync with Linux Kconfig is practiced, but
> if yes, then pick below three Linux commits, which are focused around
> improving the readability of reverse dependencies in menuconfig UI.
>
> [1] commit 1ccb27143360bd2390a9a970e50709f858b53761
> Author: Petr Vorel 
> kconfig: make "Selected by:" and "Implied by:" readable
>
> [2] commit 9a47ceec543bfb703fbe2f8d584850b582caf1a6
> Masahiro Yamada 
> kconfig: clean-up reverse dependency help implementation
>
> [3] commit d9119b5925a03b9a3191fa3e93b4091651d8ad25
> Author: Eugeniu Rosca 
> kconfig: Print reverse dependencies in groups
>
> Here is an example of re-formatted information about the reverse
> dependencies of CONFIG_DM (sandbox_defconfig):
>
> * W/o the imported commits:
>
> Selected by: NIOS2 [=n] &&  || SANDBOX [=y] &&  || X86
> [=n] &&  || ARCH_MVEBU [=n] &&  || TARGET_STV0991 [=n]
> &&  || ARCH_BCM283X [=n] &&  || ARCH_EXYNOS [=n] &&
>  || ARCH_S5PC1XX [=n] && ...
>
> * With the imported commits:
>
>   Selected by [y]:
>   - SANDBOX [=y] && 
>   - LOG [=y]
>   Selected by [n]:
>   - NIOS2 [=n] && 
>   - X86 [=n] && 
>   - ARCH_MVEBU [=n] && 
>   - TARGET_STV0991 [=n] && 
>   - ARCH_BCM283X [=n] && 
>   - ARCH_EXYNOS [=n] && 
>   - ARCH_S5PC1XX [=n] && 
>   - ARCH_INTEGRATOR [=n] && 
>   - ARCH_MX8M [=n] && 
>   - ARCH_QEMU [=n] && 
>   - ARCH_RMOBILE [=n] && 
>   - ARCH_SNAPDRAGON [=n] && 
>   - ARCH_SOCFPGA [=n] && 
>   - ARCH_SUNXI [=n] && 
>   - ARCH_ZYNQ [=n] && 
>   - ARCH_ZYNQMP [=n] && 
>   - TARGET_HIKEY [=n] && 
>   ...
>
> Signed-off-by: Eugeniu Rosca 
> ---


I prefer syncing to check-picking.


The previous sync was Linux 4.10



commit bf7ab1e70fd7621fea5dea07b6975c576119b86e
Author: Masahiro Yamada 
Date:   Sat Feb 11 12:39:54 2017 +0900

kconfig: re-sync with Linux 4.10

Re-sync all files under the scripts/kconfig directory with
Linux 4.10.

Some parts include U-Boot own modification.  I made sure to not
revert the following commits:

 5b8031ccb4ed ("Add more SPDX-License-Identifier tags")
 192bc6948b02 ("Fix GCC format-security errors and convert sprintfs.")
 da58dec86616 ("Various Makefiles: Add SPDX-License-Identifier tags")
 20c20826efab ("Kconfig: Enable usage of escape char '\' in string values")

Signed-off-by: Masahiro Yamada 


I still we still need to carry 20c20826efab for U-Boot.


Would you do that please?
Or, do you want me to do it?





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


Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

2018-05-08 Thread Peng Fan


> -Original Message-
> From: Trent Piepho [mailto:tpie...@impinj.com]
> Sent: 2018年5月9日 4:11
> To: Peng Fan ; christian.gmei...@gmail.com; Anson
> Huang ; u-boot@lists.denx.de;
> albert.u.b...@aribaud.net; sba...@denx.de
> Cc: Fabio Estevam 
> Subject: Re: [U-Boot,V2] imx: mx7: psci: add system reset support
> 
> On Tue, 2018-05-08 at 05:29 +, Peng Fan wrote:
> > > -Original Message-
> > > From: Trent Piepho [mailto:tpie...@impinj.com]
> > > Sent: 2018年5月8日 6:07
> > > To: christian.gmei...@gmail.com; Peng Fan ; Anson
> > > Huang ; u-boot@lists.denx.de;
> > > albert.u.b...@aribaud.net; sba...@denx.de
> > > Cc: Fabio Estevam 
> > > Subject: Re: [U-Boot,V2] imx: mx7: psci: add system reset support
> > >
> > > On Thu, 2018-01-04 at 17:03 +0800, Anson Huang wrote:
> > > > Add i.MX7 PSCI system reset support, linux kernel now can use "reboot"
> > > > command to reset system.
> > >
> > >
> > > > +__secure void imx_system_reset(void) {
> > > > +   writew(1 << 2, WDOG1_BASE_ADDR); }
> > >
> > > This does not work properly on our board.
> >
> > You could try write 0x14 to WDOG1_BASE_ADDR to see whether it works.
> > Here using (1 << 2) triggers both SRS and WDOG_B which seems wrong.
> 
> It works when the Linux driver does that and appears to work identically when
> uboot does it that way.
> 
> Triggering both SRS and WDOG_B does not work as it causes a very short
> wdog_b assertion.

Yes.

> 
> There is a little difficulty here in just changing the code to use
> WCR_WDE|WCR_SRS, as that would be wrong if the board does not use an
> external signal.  The Linux driver uses the device tree to determine what to 
> do,
> but this will not work for PSCI.

U-Boot need parse the device tree and configure the WDOG accordingly.

-Peng

> 
> > > Due to an erratum in iMX7d it is necessary to wire the external
> > > WDOG_B signal to the pmic to cycle power in order to reset the
> > > board.  The Linux IMX watchdog driver works when it does a reboot
> > > via the watchdog, but this code does not.
> > >
> > > When the Linux drivers is configured for an external wdog signal,
> > > using a DT property, it sets WCR_SRS to prevent the internal system
> > > reset in response to watchdog triggering.  When that is not done, as
> > > in this patch, the internal reset appears to reset the wdog module
> > > or iomux or something, which causes the imx7d to stop asserting the
> > > external wdog signal.
> > >
> > > In my tests, this takes only about 2.4 µs.  Such a short wdog_b
> > > pulse does not appear to be sufficient to trigger the pmic to cycle power.
> > >
> > > When SRS is set, then the WDOG_B signal will remain asserted until
> > > the POR_B input signal to the imx7d is asserted.  I.e., until pmic
> > > responds to the watchdog signal.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [U-Boot,V2] imx: mx7: psci: add system reset support

2018-05-08 Thread Trent Piepho
On Tue, 2018-05-08 at 05:29 +, Peng Fan wrote:
> > -Original Message-
> > From: Trent Piepho [mailto:tpie...@impinj.com]
> > Sent: 2018年5月8日 6:07
> > To: christian.gmei...@gmail.com; Peng Fan ; Anson
> > Huang ; u-boot@lists.denx.de;
> > albert.u.b...@aribaud.net; sba...@denx.de
> > Cc: Fabio Estevam 
> > Subject: Re: [U-Boot,V2] imx: mx7: psci: add system reset support
> > 
> > On Thu, 2018-01-04 at 17:03 +0800, Anson Huang wrote:
> > > Add i.MX7 PSCI system reset support, linux kernel now can use "reboot"
> > > command to reset system.
> > 
> > 
> > > +__secure void imx_system_reset(void)
> > > +{
> > > + writew(1 << 2, WDOG1_BASE_ADDR);
> > > +}
> > 
> > This does not work properly on our board.
> 
> You could try write 0x14 to WDOG1_BASE_ADDR to see whether it works.
> Here using (1 << 2) triggers both SRS and WDOG_B which seems wrong.

It works when the Linux driver does that and appears to work
identically when uboot does it that way.

Triggering both SRS and WDOG_B does not work as it causes a very short
wdog_b assertion.

There is a little difficulty here in just changing the code to use
WCR_WDE|WCR_SRS, as that would be wrong if the board does not use an
external signal.  The Linux driver uses the device tree to determine
what to do, but this will not work for PSCI.

> > Due to an erratum in iMX7d it is necessary to wire the external WDOG_B
> > signal to the pmic to cycle power in order to reset the board.  The
> > Linux IMX watchdog driver works when it does a reboot via the watchdog,
> > but this code does not.
> > 
> > When the Linux drivers is configured for an external wdog signal, using
> > a DT property, it sets WCR_SRS to prevent the internal system reset in
> > response to watchdog triggering.  When that is not done, as in this
> > patch, the internal reset appears to reset the wdog module or iomux or
> > something, which causes the imx7d to stop asserting the external wdog
> > signal.
> > 
> > In my tests, this takes only about 2.4 µs.  Such a short wdog_b pulse
> > does not appear to be sufficient to trigger the pmic to cycle power.
> > 
> > When SRS is set, then the WDOG_B signal will remain asserted until the
> > POR_B input signal to the imx7d is asserted.  I.e., until pmic responds
> > to the watchdog signal.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] kconfig: Print reverse dependencies in groups

2018-05-08 Thread Eugeniu Rosca
Not sure if partial/limited sync with Linux Kconfig is practiced, but
if yes, then pick below three Linux commits, which are focused around
improving the readability of reverse dependencies in menuconfig UI.

[1] commit 1ccb27143360bd2390a9a970e50709f858b53761
Author: Petr Vorel 
kconfig: make "Selected by:" and "Implied by:" readable

[2] commit 9a47ceec543bfb703fbe2f8d584850b582caf1a6
Masahiro Yamada 
kconfig: clean-up reverse dependency help implementation

[3] commit d9119b5925a03b9a3191fa3e93b4091651d8ad25
Author: Eugeniu Rosca 
kconfig: Print reverse dependencies in groups

Here is an example of re-formatted information about the reverse
dependencies of CONFIG_DM (sandbox_defconfig):

* W/o the imported commits:

Selected by: NIOS2 [=n] &&  || SANDBOX [=y] &&  || X86
[=n] &&  || ARCH_MVEBU [=n] &&  || TARGET_STV0991 [=n]
&&  || ARCH_BCM283X [=n] &&  || ARCH_EXYNOS [=n] &&
 || ARCH_S5PC1XX [=n] && ...

* With the imported commits:

  Selected by [y]:
  - SANDBOX [=y] && 
  - LOG [=y]
  Selected by [n]:
  - NIOS2 [=n] && 
  - X86 [=n] && 
  - ARCH_MVEBU [=n] && 
  - TARGET_STV0991 [=n] && 
  - ARCH_BCM283X [=n] && 
  - ARCH_EXYNOS [=n] && 
  - ARCH_S5PC1XX [=n] && 
  - ARCH_INTEGRATOR [=n] && 
  - ARCH_MX8M [=n] && 
  - ARCH_QEMU [=n] && 
  - ARCH_RMOBILE [=n] && 
  - ARCH_SNAPDRAGON [=n] && 
  - ARCH_SOCFPGA [=n] && 
  - ARCH_SUNXI [=n] && 
  - ARCH_ZYNQ [=n] && 
  - ARCH_ZYNQMP [=n] && 
  - TARGET_HIKEY [=n] && 
  ...

Signed-off-by: Eugeniu Rosca 
---
 scripts/kconfig/expr.c | 34 +-
 scripts/kconfig/expr.h |  2 ++
 scripts/kconfig/menu.c | 12 ++--
 3 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/scripts/kconfig/expr.c b/scripts/kconfig/expr.c
index cbf4996dd9c1..40887d17f1e2 100644
--- a/scripts/kconfig/expr.c
+++ b/scripts/kconfig/expr.c
@@ -1070,7 +1070,9 @@ struct expr *expr_simplify_unmet_dep(struct expr *e1, 
struct expr *e2)
return expr_get_leftmost_symbol(ret);
 }
 
-void expr_print(struct expr *e, void (*fn)(void *, struct symbol *, const char 
*), void *data, int prevtoken)
+void expr_print(struct expr *e,
+   void (*fn)(void *, struct symbol *, const char *),
+   void *data, int prevtoken)
 {
if (!e) {
fn(data, NULL, "y");
@@ -1204,3 +1206,33 @@ void expr_gstr_print(struct expr *e, struct gstr *gs)
 {
expr_print(e, expr_print_gstr_helper, gs, E_NONE);
 }
+
+/*
+ * Transform the top level "||" tokens into newlines and prepend each
+ * line with a minus. This makes expressions much easier to read.
+ * Suitable for reverse dependency expressions.
+ */
+static void expr_print_revdep(struct expr *e,
+ void (*fn)(void *, struct symbol *, const char *),
+ void *data, tristate pr_type, const char **title)
+{
+   if (e->type == E_OR) {
+   expr_print_revdep(e->left.expr, fn, data, pr_type, title);
+   expr_print_revdep(e->right.expr, fn, data, pr_type, title);
+   } else if (expr_calc_value(e) == pr_type) {
+   if (*title) {
+   fn(data, NULL, *title);
+   *title = NULL;
+   }
+
+   fn(data, NULL, "  - ");
+   expr_print(e, fn, data, E_NONE);
+   fn(data, NULL, "\n");
+   }
+}
+
+void expr_gstr_print_revdep(struct expr *e, struct gstr *gs,
+   tristate pr_type, const char *title)
+{
+   expr_print_revdep(e, expr_print_gstr_helper, gs, pr_type, );
+}
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index a73f762c48d6..3a3d334ed554 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -222,6 +222,8 @@ struct expr *expr_simplify_unmet_dep(struct expr *e1, 
struct expr *e2);
 void expr_fprint(struct expr *e, FILE *out);
 struct gstr; /* forward */
 void expr_gstr_print(struct expr *e, struct gstr *gs);
+void expr_gstr_print_revdep(struct expr *e, struct gstr *gs,
+   tristate pr_type, const char *title);
 
 static inline int expr_is_yes(struct expr *e)
 {
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index e9357931b47d..392c1a0a3963 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -675,16 +675,16 @@ static void get_symbol_str(struct gstr *r, struct symbol 
*sym,
 
get_symbol_props_str(r, sym, P_SELECT, _("  Selects: "));
if (sym->rev_dep.expr) {
-   str_append(r, _("  Selected by: "));
-   expr_gstr_print(sym->rev_dep.expr, r);
-   str_append(r, "\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, yes, "  Selected 
by [y]:\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, mod, "  Selected 
by [m]:\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, no, "  Selected by 

[U-Boot] [PATCH] efi_loader: fix off-by-one bug in efi_get_variable

2018-05-08 Thread Ivan Gorinov
efi_get_variable() always stores an extra zero byte after the output data.
When the returned data size matches the output buffer size, the extra zero
byte is stored past the end of the output buffer.

Signed-off-by: Ivan Gorinov 
---
 lib/efi_loader/efi_variable.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6c177da..d031338 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -68,11 +68,11 @@ static const char *hex2mem(u8 *mem, const char *hexstr, int 
count)
do {
int nibble;
 
-   *mem = 0;
-
if (!count || !*hexstr)
break;
 
+   *mem = 0;
+
nibble = hex(*hexstr);
if (nibble < 0)
break;
-- 
2.7.4

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


[U-Boot] [PATCH v4 1/3] apalis_t30: describe pcie ports

2018-05-08 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Add some more comments describing the various PCIe ports available.

Signed-off-by: Marcel Ziswiler 

---

Changes in v4: None
Changes in v3: None
Changes in v2: None

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

diff --git a/arch/arm/dts/tegra30-apalis.dts b/arch/arm/dts/tegra30-apalis.dts
index 0b84dae215..0852d8dc53 100644
--- a/arch/arm/dts/tegra30-apalis.dts
+++ b/arch/arm/dts/tegra30-apalis.dts
@@ -43,16 +43,19 @@
vddio-pex-ctl-supply = <_3v3_reg>;
hvdd-pex-supply = <_3v3_reg>;
 
+   /* Apalis Type Specific 4 Lane PCIe */
pci@1,0 {
/* TS_DIFF1/2/3/4 left disabled */
nvidia,num-lanes = <4>;
};
 
+   /* Apalis PCIe */
pci@2,0 {
/* PCIE1_RX/TX left disabled */
nvidia,num-lanes = <1>;
};
 
+   /* I210 Gigabit Ethernet Controller (On-module) */
pci@3,0 {
status = "okay";
nvidia,num-lanes = <1>;
-- 
2.14.3

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


[U-Boot] [PATCH v4 0/3] fix apalis_t30 optional pcie operation

2018-05-08 Thread Marcel Ziswiler

This series addresses a PCIe reliability issue as observed on Apalis T30
related to a PCIe reset timing violation.

This series is available at 
http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v4:
- Fix spelling of losing vs. loosing.

Changes in v3:
- Updated copyright period to 2014-2018.
- Added a blank line after declarations as warned by patman.
- Added Stephen's acked-by.
- Rebased and resend as series so far never got applied!

Changes in v2:
- Leave resp. enable all port 0 pins input drivers as a customer may
  optionally want to use some of those MXM3 pins as inputs as well.
- Stick to struct tegra_pcie_port as suggested by Stephen.
- Introduce proper CONFIG_APALIS_T30_PCIE_EVALBOARD_INIT Kconfig option
  as suggested by Stephen.
- Improved the ifdef vs. if curly braces sequencing as suggested by
  Stephen.
- Keep PCIe port reset status in order to safeguard for future changes
  to the port reset order or even allow for re-initialisation should
  that ever be implemented in the higher levels of the driver model.

Marcel Ziswiler (3):
  apalis_t30: describe pcie ports
  apalis_t30: fix pcie port 0 and 1 pin muxing
  apalis_t30: fix optional pcie port reset for reliable pcie operation

 arch/arm/dts/tegra30-apalis.dts|  3 ++
 board/toradex/apalis_t30/Kconfig   |  9 
 board/toradex/apalis_t30/apalis_t30.c  | 57 +-
 .../toradex/apalis_t30/pinmux-config-apalis_t30.h  | 16 +++---
 4 files changed, 77 insertions(+), 8 deletions(-)

-- 
2.14.3

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


[U-Boot] [PATCH v4 3/3] apalis_t30: fix optional pcie port reset for reliable pcie operation

2018-05-08 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Allow optionally bringing up the Apalis type specific 4 lane PCIe port
as well as the PCIe switch as found on the Apalis Evaluation board. In
order to avoid violating the PCIe reset timing do this by overriding the
tegra_pcie_board_port_reset() function. Note however that both the
Apalis type specific 4 lane PCIe port as well as the regular Apalis PCIe
port are also left disabled in the device tree by default.

Signed-off-by: Marcel Ziswiler 
Acked-by: Stephen Warren 

---

Changes in v4:
- Fix spelling of losing vs. loosing.

Changes in v3:
- Updated copyright period to 2014-2018.
- Added a blank line after declarations as warned by patman.
- Added Stephen's acked-by.
- Rebased and resend as series so far never got applied!

Changes in v2:
- Stick to struct tegra_pcie_port as suggested by Stephen.
- Introduce proper CONFIG_APALIS_T30_PCIE_EVALBOARD_INIT Kconfig option
  as suggested by Stephen.
- Improved the ifdef vs. if curly braces sequencing as suggested by
  Stephen.
- Keep PCIe port reset status in order to safeguard for future changes
  to the port reset order or even allow for re-initialisation should
  that ever be implemented in the higher levels of the driver model.

 board/toradex/apalis_t30/Kconfig  |  9 ++
 board/toradex/apalis_t30/apalis_t30.c | 57 ++-
 2 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/board/toradex/apalis_t30/Kconfig b/board/toradex/apalis_t30/Kconfig
index 16224daa12..9cd497091d 100644
--- a/board/toradex/apalis_t30/Kconfig
+++ b/board/toradex/apalis_t30/Kconfig
@@ -25,6 +25,15 @@ config TDX_CFG_BLOCK_PART
 config TDX_CFG_BLOCK_OFFSET
default "-512"
 
+config APALIS_T30_PCIE_EVALBOARD_INIT
+   bool "Apalis Evaluation Board PCIe Initialisation"
+   help
+ Bring up the Apalis type specific 4 lane PCIe port as well as the
+ Apalis PCIe port with the PCIe switch as found on the Apalis
+ Evaluation board. Note that by default both those ports are also left
+ disabled in the device tree which needs changing as well for this to
+ actually work.
+
 source "board/toradex/common/Kconfig"
 
 endif
diff --git a/board/toradex/apalis_t30/apalis_t30.c 
b/board/toradex/apalis_t30/apalis_t30.c
index 28830b6345..ace9c5b168 100644
--- a/board/toradex/apalis_t30/apalis_t30.c
+++ b/board/toradex/apalis_t30/apalis_t30.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- *  (C) Copyright 2014-2016
+ *  (C) Copyright 2014-2018
  *  Marcel Ziswiler 
  */
 
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "../common/tdx-common.h"
 
 #include "pinmux-config-apalis_t30.h"
@@ -22,6 +23,13 @@ DECLARE_GLOBAL_DATA_PTR;
 #define PMU_I2C_ADDRESS0x2D
 #define MAX_I2C_RETRY  3
 
+#ifdef CONFIG_APALIS_T30_PCIE_EVALBOARD_INIT
+#define PEX_PERST_NTEGRA_GPIO(S, 7) /* Apalis GPIO7 */
+#define RESET_MOCI_CTRLTEGRA_GPIO(I, 4)
+
+static int pci_reset_status;
+#endif /* CONFIG_APALIS_T30_PCIE_EVALBOARD_INIT */
+
 int arch_misc_init(void)
 {
if (readl(NV_PA_BASE_SRAM + NVBOOTINFOTABLE_BOOTTYPE) ==
@@ -106,6 +114,53 @@ int tegra_pcie_board_init(void)
return err;
}
 
+#ifdef CONFIG_APALIS_T30_PCIE_EVALBOARD_INIT
+   gpio_request(PEX_PERST_N, "PEX_PERST_N");
+   gpio_request(RESET_MOCI_CTRL, "RESET_MOCI_CTRL");
+#endif /* CONFIG_APALIS_T30_PCIE_EVALBOARD_INIT */
+
return 0;
 }
+
+void tegra_pcie_board_port_reset(struct tegra_pcie_port *port)
+{
+   int index = tegra_pcie_port_index_of_port(port);
+
+   if (index == 2) { /* I210 Gigabit Ethernet Controller (On-module) */
+   tegra_pcie_port_reset(port);
+   }
+#ifdef CONFIG_APALIS_T30_PCIE_EVALBOARD_INIT
+   /*
+* Apalis PCIe aka port 1 and Apalis Type Specific 4 Lane PCIe aka port
+* 0 share the same RESET_MOCI therefore only assert it once for both
+* ports to avoid losing the previously brought up port again.
+*/
+   else if ((index == 1) || (index == 0)) {
+   /* only do it once per init cycle */
+   if (pci_reset_status % 2 == 0) {
+   /*
+* Reset PLX PEX 8605 PCIe Switch plus PCIe devices on
+* Apalis Evaluation Board
+*/
+   gpio_direction_output(PEX_PERST_N, 0);
+   gpio_direction_output(RESET_MOCI_CTRL, 0);
+
+   /*
+* Must be asserted for 100 ms after power and clocks
+* are stable
+*/
+   mdelay(100);
+
+   gpio_set_value(PEX_PERST_N, 1);
+   /*
+* Err_5: PEX_REFCLK_OUTpx/nx Clock Outputs is not
+* 

[U-Boot] [PATCH v4 2/3] apalis_t30: fix pcie port 0 and 1 pin muxing

2018-05-08 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Fix optional Apalis type specific 4 lane PCIe port 0 and Apalis PCIe
port 1 pin muxing.

Signed-off-by: Marcel Ziswiler 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Leave resp. enable all port 0 pins input drivers as a customer may
  optionally want to use some of those MXM3 pins as inputs as well.

 board/toradex/apalis_t30/pinmux-config-apalis_t30.h | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/board/toradex/apalis_t30/pinmux-config-apalis_t30.h 
b/board/toradex/apalis_t30/pinmux-config-apalis_t30.h
index e28742ba6f..49c2df7ab2 100644
--- a/board/toradex/apalis_t30/pinmux-config-apalis_t30.h
+++ b/board/toradex/apalis_t30/pinmux-config-apalis_t30.h
@@ -284,17 +284,19 @@ static struct pmux_pingrp_config tegra3_pinmux_common[] = 
{
DEFAULT_PINMUX(SPI1_CS0_N_PX6, SPI1, NORMAL, NORMAL, INPUT),
DEFAULT_PINMUX(SPI1_MISO_PX7, SPI1, NORMAL, NORMAL, INPUT),
 
-   DEFAULT_PINMUX(PEX_L0_PRSNT_N_PDD0, PCIE, NORMAL, NORMAL, INPUT),
-   DEFAULT_PINMUX(PEX_L0_RST_N_PDD1, PCIE, NORMAL, NORMAL, OUTPUT),
-   DEFAULT_PINMUX(PEX_L0_CLKREQ_N_PDD2, PCIE, NORMAL, NORMAL, INPUT),
-   DEFAULT_PINMUX(PEX_WAKE_N_PDD3, PCIE, NORMAL, NORMAL, INPUT),
+   DEFAULT_PINMUX(PEX_L0_PRSNT_N_PDD0, RSVD2, NORMAL, NORMAL, INPUT),
+   DEFAULT_PINMUX(PEX_L0_RST_N_PDD1, RSVD2, NORMAL, NORMAL, INPUT),
+   DEFAULT_PINMUX(PEX_L0_CLKREQ_N_PDD2, RSVD2, NORMAL, NORMAL, INPUT),
+
+   DEFAULT_PINMUX(PEX_L1_PRSNT_N_PDD4, RSVD2, DOWN, TRISTATE, OUTPUT), /* 
NC */
+   DEFAULT_PINMUX(PEX_L1_RST_N_PDD5, RSVD2, DOWN, TRISTATE, OUTPUT), /* NC 
*/
+   DEFAULT_PINMUX(PEX_L1_CLKREQ_N_PDD6, RSVD2, DOWN, TRISTATE, OUTPUT), /* 
NC */
 
-   DEFAULT_PINMUX(PEX_L1_PRSNT_N_PDD4, PCIE, DOWN, TRISTATE, OUTPUT), /* 
NC */
-   DEFAULT_PINMUX(PEX_L1_RST_N_PDD5, PCIE, DOWN, TRISTATE, OUTPUT), /* NC 
*/
-   DEFAULT_PINMUX(PEX_L1_CLKREQ_N_PDD6, PCIE, DOWN, TRISTATE, OUTPUT), /* 
NC */
DEFAULT_PINMUX(PEX_L2_PRSNT_N_PDD7, PCIE, NORMAL, NORMAL, INPUT),
DEFAULT_PINMUX(PEX_L2_RST_N_PCC6, PCIE, NORMAL, NORMAL, OUTPUT),
DEFAULT_PINMUX(PEX_L2_CLKREQ_N_PCC7, PCIE, NORMAL, NORMAL, INPUT),
+   DEFAULT_PINMUX(PEX_WAKE_N_PDD3, PCIE, NORMAL, NORMAL, INPUT),
+
DEFAULT_PINMUX(HDMI_CEC_PEE3, CEC, NORMAL, NORMAL, INPUT),
DEFAULT_PINMUX(HDMI_INT_PN7, RSVD1, NORMAL, NORMAL, INPUT),
 
-- 
2.14.3

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


Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

2018-05-08 Thread Dr. Philipp Tomsich

> On 8 May 2018, at 21:21, Marty E. Plummer  wrote:
> 
> On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
>> Marty,
>> 
>>> On 8 May 2018, at 02:52, Marty E. Plummer  wrote:
>>> 
>>> On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
 
> On 7 May 2018, at 04:34, Marty E. Plummer  wrote:
> 
> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>> Hi Marty,
>> 
>> 
>> On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
>>> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
>>> 
>>> Without this change, my u-boot build for the asus c201 chromebook (4GiB)
>>> is incorrectly detected as 0 Bytes of ram.
>> 
>> I know the root cause for this issue, and I have a local patch for it.
>> The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>> before
>> the max size before return with '<<20'. Sorry for forgot to send it out.
>> 
>>> 
>>> Signed-off-by: Marty E. Plummer 
>>> ---
>>> arch/arm/mach-rockchip/sdram_common.c | 62 ---
>>> 1 file changed, 37 insertions(+), 25 deletions(-)
>>> 
>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>> b/arch/arm/mach-rockchip/sdram_common.c
>>> index 76dbdc8715..a9c9f970a4 100644
>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>> @@ -10,6 +10,8 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> +#include 
>>> 
>>> DECLARE_GLOBAL_DATA_PTR;
>>> size_t rockchip_sdram_size(phys_addr_t reg)
>>> @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>> size_t size_mb = 0;
>>> u32 ch;
>>> 
>>> -   u32 sys_reg = readl(reg);
>>> -   u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
>>> -  & SYS_REG_NUM_CH_MASK);
>>> +   if (!size_mb) {
>> 
>> I don't understand this and follow up changes, we don't really need it,
>> isn't it?
>> I think don't need the changes before here.
> Yeah, that was just another level of indentation for the if (!size_mb)
> guard, but I've reworked the patch to not do that as it was pointed out
> that since size_mb is initialized to 0 prior.
>>> +   /*
>>> +* we use the 0x~0xfeff space
>>> +* since 0xff00~0x is soc register space
>>> +* so we reserve it
>>> +*/
>>> +   size_mb = min(size_mb, 0xff00/SZ_1M);
>> 
>> This is what we really need, as Klaus point out, we need to use
>> SDRAM_MAX_SIZE
>> instead of hard code.
> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> build and boot tested on my hardware.
 
 In that case you just masked the problem but didn???t solve it: assuming 
 size_mb
 is size_t (I???ll assume this is 64bit, but did not check), then your 4GB 
 is 0x1__ )
 which overflows to 0x0 when converted to a u32.
 
 In other words: we need to figure out where the truncation occurs (image 
 what
 happens if a new 32bit processor with LPAE comes out???).
 
>>> A very valid point. With the following patch to sdram_common.c and
>>> sdram_rk3288.c applied I get the debug output that follows it:
>>> diff --git a/arch/arm/mach-rockchip/sdram_common.c 
>>> b/arch/arm/mach-rockchip/sdram_common.c
>>> index 232a7fa655..0fe69bf558 100644
>>> --- a/arch/arm/mach-rockchip/sdram_common.c
>>> +++ b/arch/arm/mach-rockchip/sdram_common.c
>>> @@ -4,6 +4,7 @@
>>> * SPDX-License-Identifier: GPL-2.0+
>>> */
>>> 
>>> +#define DEBUG 1
>>> #include 
>>> #include 
>>> #include 
>>> @@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
>>> SYS_REG_ROW_3_4_MASK;
>>> 
>>> chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
>>> +   debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__, 
>>> chipsize_mb);
>>> 
>>> if (rank > 1)
>>> chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
>>> if (row_3_4)
>>> chipsize_mb = chipsize_mb * 3 / 4;
>>> size_mb += chipsize_mb;
>>> +   debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
>>> debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
>>>   rank, col, bk, cs0_row, bw, row_3_4);
>>> }
>>> 
>>> +   debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
>>> size_mb = min(size_mb, SDRAM_MAX_SIZE/SZ_1M);
>>> 
>>> return (size_t)size_mb << 20;
>>> diff --git a/drivers/ram/rockchip/sdram_rk3288.c 
>>> b/drivers/ram/rockchip/sdram_rk3288.c
>>> index d99bf12476..9738eb088f 100644
>>> --- 

Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug

2018-05-08 Thread Vagrant Cascadian
On 2018-05-08, Vagrant Cascadian wrote:
> On 2018-05-05, Tom Rini wrote:
>> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>>> Markus Krebs discovered that the sheevaplug target has again grown and
>>> installation overlaps where the u-boot env is saved since u-boot
>>> ~2017.09. Running saveenv overwrites u-boot, and installing u-boot
>>> overwrites any prior environment settings.
...
>> I've added the maintainer to the list as well.  I would suggest looking
>> for things to trim out, perhaps CMD_MEMTEST ?
>
> Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
> EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
> *lot* left to disable in the config, but that's a significant start...

And setting SYS_THUMB_BUILD=y as well as disabling EFI_LOADER gets it
down to 432k! Thanks to beeble for the suggestion.

Anyone who has a sheevaplug can test that it actually boots with
CONFIG_SYS_THUMB_BUILD=y enabled?


live well,
  vagrant


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


Re: [U-Boot] Bug#897671: u-boot does not work on sheevaplug

2018-05-08 Thread Vagrant Cascadian
On 2018-05-05, Tom Rini wrote:
> On Sat, May 05, 2018 at 04:04:08PM -0700, Vagrant Cascadian wrote:
>> Markus Krebs discovered that the sheevaplug target has again grown and
>> installation overlaps where the u-boot env is saved since u-boot
>> ~2017.09. Running saveenv overwrites u-boot, and installing u-boot
>> overwrites any prior environment settings.
>> 
>> More detail on the bug report in Debian:
>> 
>>   https://bugs.debian.org/897671
>> 
>> We don't carry any patches for the sheevaplug u-boot target in Debian,
>> so this is likely also an issue upstream. Who are the current
>> maintainers for sheevaplug in u-boot upstream?
>> 
>> A brief summary of the current findings:
>> 
>> On 2018-05-05, Markus Krebs wrote:
>> > Am 05.05.2018 um 20:36 schrieb Markus Krebs:
...
>> > but the environment shouldn't start at 0x8 when u-boot.kwb > 524 KB; 
>> > in this case 'saveenv' overwrites u-boot (?).
>> > Changing 0x8 to 0xa helps ; I compiled a u-boot.kwb from the 
>> > so-modified sources, and now I can start Debian fine.
>> 
>> It looks like it was bumped from 0x6 to 0x8 in 2014:
>> 
>>   
>> http://git.denx.de/?p=u-boot.git;a=commit;h=4dfb0e4d3e75763d6fbe8788316bea9ba23e8e01
>> 
>> If 0x8 isn't enough, there might be some features in the config to
>> experiment with removing, or it may need to be bumped again.
>
> I've added the maintainer to the list as well.  I would suggest looking
> for things to trim out, perhaps CMD_MEMTEST ?

Thanks for the suggestsions. CMD_MEMTEST wasn't present, but disabling
EFI_LOADER made u-boot 2018.05 go from 592k down to 548k. There's not a
*lot* left to disable in the config, but that's a significant start...

On a related note, I'm wondering if EFI_LOADER should only be enabled
with SYS_ARM_ARCH >= 7 by default, as many of the earlier arm systems
tend to be space-constrained, and those that aren't could enable it on a
case-by-case basis.


> Also, a patch to make it a link error when we exceed the size allowed
> would be great, so that in the future we catch this when it happens.
> Thanks!

Will look into it, although would be happy if someone beats me to it. :)


live well,
  vagrant


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


Re: [U-Boot] [PATCH 3/3] rockchip: fix incorrect detection of ram size

2018-05-08 Thread Marty E. Plummer
On Tue, May 08, 2018 at 12:21:24PM +0200, Dr. Philipp Tomsich wrote:
> Marty,
> 
> > On 8 May 2018, at 02:52, Marty E. Plummer  wrote:
> > 
> > On Mon, May 07, 2018 at 11:16:28AM +0200, Dr. Philipp Tomsich wrote:
> >> 
> >>> On 7 May 2018, at 04:34, Marty E. Plummer  wrote:
> >>> 
> >>> On Mon, May 07, 2018 at 10:20:55AM +0800, Kever Yang wrote:
>  Hi Marty,
>  
>  
>  On 05/06/2018 10:25 PM, Marty E. Plummer wrote:
> > Taken from coreboot's src/soc/rockchip/rk3288/sdram.c
> > 
> > Without this change, my u-boot build for the asus c201 chromebook (4GiB)
> > is incorrectly detected as 0 Bytes of ram.
>  
>  I know the root cause for this issue, and I have a local patch for it.
>  The rk3288 is 32bit, and 4GB size is just out of range, so we need to 
>  before
>  the max size before return with '<<20'. Sorry for forgot to send it out.
>  
> > 
> > Signed-off-by: Marty E. Plummer 
> > ---
> > arch/arm/mach-rockchip/sdram_common.c | 62 ---
> > 1 file changed, 37 insertions(+), 25 deletions(-)
> > 
> > diff --git a/arch/arm/mach-rockchip/sdram_common.c 
> > b/arch/arm/mach-rockchip/sdram_common.c
> > index 76dbdc8715..a9c9f970a4 100644
> > --- a/arch/arm/mach-rockchip/sdram_common.c
> > +++ b/arch/arm/mach-rockchip/sdram_common.c
> > @@ -10,6 +10,8 @@
> > #include 
> > #include 
> > #include 
> > +#include 
> > +#include 
> > 
> > DECLARE_GLOBAL_DATA_PTR;
> > size_t rockchip_sdram_size(phys_addr_t reg)
> > @@ -19,34 +21,44 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> > size_t size_mb = 0;
> > u32 ch;
> > 
> > -   u32 sys_reg = readl(reg);
> > -   u32 ch_num = 1 + ((sys_reg >> SYS_REG_NUM_CH_SHIFT)
> > -  & SYS_REG_NUM_CH_MASK);
> > +   if (!size_mb) {
>  
>  I don't understand this and follow up changes, we don't really need it,
>  isn't it?
>  I think don't need the changes before here.
> >>> Yeah, that was just another level of indentation for the if (!size_mb)
> >>> guard, but I've reworked the patch to not do that as it was pointed out
> >>> that since size_mb is initialized to 0 prior.
> > +   /*
> > +* we use the 0x~0xfeff space
> > +* since 0xff00~0x is soc register space
> > +* so we reserve it
> > +*/
> > +   size_mb = min(size_mb, 0xff00/SZ_1M);
>  
>  This is what we really need, as Klaus point out, we need to use
>  SDRAM_MAX_SIZE
>  instead of hard code.
> >>> Yeah, I've got a rework on that which uses SDRAM_MAX_SIZE as instructed,
> >>> build and boot tested on my hardware.
> >> 
> >> In that case you just masked the problem but didn???t solve it: assuming 
> >> size_mb
> >> is size_t (I???ll assume this is 64bit, but did not check), then your 4GB 
> >> is 0x1__ )
> >> which overflows to 0x0 when converted to a u32.
> >> 
> >> In other words: we need to figure out where the truncation occurs (image 
> >> what
> >> happens if a new 32bit processor with LPAE comes out???).
> >> 
> > A very valid point. With the following patch to sdram_common.c and
> > sdram_rk3288.c applied I get the debug output that follows it:
> > diff --git a/arch/arm/mach-rockchip/sdram_common.c 
> > b/arch/arm/mach-rockchip/sdram_common.c
> > index 232a7fa655..0fe69bf558 100644
> > --- a/arch/arm/mach-rockchip/sdram_common.c
> > +++ b/arch/arm/mach-rockchip/sdram_common.c
> > @@ -4,6 +4,7 @@
> >  * SPDX-License-Identifier: GPL-2.0+
> >  */
> > 
> > +#define DEBUG 1
> > #include 
> > #include 
> > #include 
> > @@ -39,16 +40,19 @@ size_t rockchip_sdram_size(phys_addr_t reg)
> > SYS_REG_ROW_3_4_MASK;
> > 
> > chipsize_mb = (1 << (cs0_row + col + bk + bw - 20));
> > +   debug("%s: %d: chipsize_mb %x\n", __func__, __LINE__, 
> > chipsize_mb);
> > 
> > if (rank > 1)
> > chipsize_mb += chipsize_mb >> (cs0_row - cs1_row);
> > if (row_3_4)
> > chipsize_mb = chipsize_mb * 3 / 4;
> > size_mb += chipsize_mb;
> > +   debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
> > debug("rank %d col %d bk %d cs0_row %d bw %d row_3_4 %d\n",
> >   rank, col, bk, cs0_row, bw, row_3_4);
> > }
> > 
> > +   debug("%s: %d: size_mb %x\n", __func__, __LINE__, size_mb);
> > size_mb = min(size_mb, SDRAM_MAX_SIZE/SZ_1M);
> > 
> > return (size_t)size_mb << 20;
> > diff --git a/drivers/ram/rockchip/sdram_rk3288.c 
> > b/drivers/ram/rockchip/sdram_rk3288.c
> > index d99bf12476..9738eb088f 100644
> > --- a/drivers/ram/rockchip/sdram_rk3288.c
> > +++ b/drivers/ram/rockchip/sdram_rk3288.c
> > @@ -7,6 

Re: [U-Boot] [PATCH v2 1/3] efi_loader: allow unaligned memory access

2018-05-08 Thread Heinrich Schuchardt
On 05/07/2018 11:53 PM, Tom Rini wrote:
> On Thu, Apr 05, 2018 at 09:39:20AM +0200, Alexander Graf wrote:
>> On 04/04/2018 09:14 PM, Heinrich Schuchardt wrote:
>>> On 04/04/2018 06:11 PM, Alexander Graf wrote:

 On 04.04.18 17:10, Heinrich Schuchardt wrote:
> On 04/04/2018 02:32 PM, Alexander Graf wrote:
>>
>> On 03.04.18 21:59, Heinrich Schuchardt wrote:
>>> The UEFI spec mandates that unaligned memory access should be enabled if
>>> supported by the CPU architecture.
>>>
>>> This patch adds an empty weak function unaligned_access() that can be
>>> overridden by an architecture specific routine.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>  cmd/bootefi.c   | 13 +
>>>  include/asm-generic/unaligned.h |  3 +++
>>>  2 files changed, 16 insertions(+)
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index ba258ac9f3..412e6519ba 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -18,6 +18,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  DECLARE_GLOBAL_DATA_PTR;
>>> @@ -89,6 +90,15 @@ out:
>>> return ret;
>>>  }
>>> +/*
>>> + * Allow unaligned memory access.
>>> + *
>>> + * This routine is overridden by architectures providing this feature.
>>> + */
>>> +void __weak allow_unaligned(void)
>>> +{
>>> +}
>>> +
>> I'd prefer to guard the body of the function with an #ifdef CONFIG_ARM
>> so everyone knows why it's there. Then call straight into a function
>> provided in the ARM core code:
> The same visibility can be achieved with a comment.
 It's not as obvious. The default really should be to map memory as
 cached and allow for unaligned accesses.

>> static void allow_unaligned(void)
>> {
>> /* On ARM we prohibit unaligned accesses by default, enable them here */
>> #if defined(CONFIG_ARM) && !defined(CONFIG_ARM64) &&
>> !defined(CONFIG_CPU_V7M)
>>   mmu_enable_unaligned();
>> #endif
>> }
> RISC-V also supports traps for unaligned access.
 Just because it supports them doesn't mean we should use them. AArch64
 also allows for unaligned access traps and I went through great length
 to refactor the mm code in U-Boot to ensure that we do not trap.

> Using architecture specific flags outside arch/ is a mess.
> We should not commit new sins but eliminate the existing deviations.
>
>> And then in arch/arm/lib/cache-cp15.c:
>>
>> void mmu_enable_unaligned(void)
>> {
>>   set_cr(get_cr() & ~CR_A);
>> }
> For some ARM architecture versions the bit is reserved and not used for
> unaligned access. No clue what this function would do in this case.
 Do you have pointers? Anything defined in the UEFI spec should have the 
 bit.
>>> UEFI spec 2.7:
>>> 2.3.5 AArch32 Platforms
>>> In addition, the invoking OSs can assume that unaligned access support
>>> is enabled if it is present in the processor.
>>>
>>> So the UEFI spec foresees processors supporting unaligned memory access
>>> and others that do not support it.
>>
>> I think the only corner case is Cortex-M, but that's not terribly high up on
>> my priority list. And if that requires everything to be aligned, so be it.
>>
>>>
> That is why I used a weak function that does nothing if the CPU does not
> support the flag.
 Any platform that uses cache-cp15 also supports the CR_A bit FWIW. So it
 really belongs there.>
 And again, I do not want to prettify a special hack for a broken
 architecture. People should see warts when they're there.

 The real fix IMHO is to enable aligned accesses always, like we do on
 any sane architecture.

>>> Is this a typo: "enable aligned accesses"?
>>>
>>> Aligned access is always enabled. It is unaligned access that currently
>>> is not enabled in U-Boot.
>>
>> Yes, enable unaligned accesses of course :).
>>
>> Albert, this is your call I think. Would you be heavily opposed to
>> Heinrich's initial patch? It really is the best option IMHO:
> 
> Let me try actually saying something this time.  We had a large amount
> of back and forth over "unaligned access" over the last several years.
> Heinrich's is doing something we've expressly chosen not to do (and
> there's pages and pages of discussion in the archives).  So the changes
> here to enter an EFI application in the way it expects need to be done
> for EFI as part of entering EFI.  I would almost suggest something like
> a prepare_for_efi (and a matching unwind) function.
> 

The bootefi command may serve to load an EFI driver binary which will
stay active after returning to the U-Boot prompt. So we cannot disallow
unaligned access after calling bootefi. So there is nothing we could
"unwind".

As this patch series moves allowing unaligned access 

Re: [U-Boot] [PATCH 1/4] i2c: rcar_i2c: Remove the driver

2018-05-08 Thread Marek Vasut
On 05/08/2018 10:14 AM, Heiko Schocher wrote:
> Hello Marek,
> 
> Am 01.05.2018 um 09:03 schrieb Marek Vasut:
>> Remove the rcar_i2c driver, since it's no longer used by any
>> board and will be superseded by a DM and DT capable variant.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Heiko Schocher 
>> Cc: Nobuhiro Iwamatsu 
>> ---
>>   drivers/i2c/Makefile   |   1 -
>>   drivers/i2c/rcar_i2c.c | 293
>> -
>>   2 files changed, 294 deletions(-)
>>   delete mode 100644 drivers/i2c/rcar_i2c.c
> 
> checkpatch says:
> 
> 2018-05-08 03:12:02,870:CON    :tbotlib   # tb_ctrl: WARNING:
> added, moved or deleted file(s), does MAINTAINERS need updating?
> #41:
> deleted file mode 100644
> 
> total: 0 errors, 1 warnings, 0 checks, 7 lines checked
> 
> NOTE: For some of the reported defects, checkpatch may be able to
>   mechanically convert to the typical style using --fix or
> --fix-inplace.
> 
> mbox has style problems, please review.
> 
> And applying patch to current mainline fails:
> 
> 2018-05-08 03:12:04,014:CON    :tbotlib   # tb_ctrl: git am -3 mbox
> 2018-05-08 03:12:04,156:CON    :tbotlib   # tb_ctrl: Applying: i2c:
> rcar_i2c: Remove the driver
> Using index info to reconstruct a base tree...
> M    drivers/i2c/Makefile
> M    drivers/i2c/rcar_i2c.c
> Falling back to patching base and 3-way merge...
> CONFLICT (modify/delete): drivers/i2c/rcar_i2c.c deleted in i2c:
> rcar_i2c: Remove the driver and modified in HEAD. Version HEAD of
> drivers/i2c/rcar_i2c.c left in tree.
> Auto-merging drivers/i2c/Makefile
> error: Failed to merge in the changes.
> Patch failed at 0001 i2c: rcar_i2c: Remove the driver
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> hs@pollux [ 5:12:04] ttbott>
> 
> see full log:
> http://xeidos.ddns.net/tbot/id_740/tbot.txt
> 
> Before I make a dummy mistake, can you please rebase your patchset?
> 
> Thanks!
> 
> Hmm.. why do you remove the driver in this patch, and add it again
> in patch 2 ?

I am replacing it with a different/new driver, since the old one is broken.

> Isn;t it better to squash this 2 patches into one, so we see your
> changes?

No, that'd be just unreviewable mess. Review 2/4 as a new driver.

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


Re: [U-Boot] [PATCH v8 06/35] device-tree-bindings: phy: Sync sun4i-usb-phy bindings

2018-05-08 Thread Marek Vasut
On 05/08/2018 08:07 AM, Jagan Teki wrote:
> Sync sun4i-usb-phy bindings from Linux, since the
> drivers/phy/allwinner/phy-sun4i-usb.c follow similar.
> 
> Sync changes from Linux with below merge commit:
> 
> Merge: 02fc9235984d 486f47e8d3dd
> Author: Stephen Rothwell 
> Date:   Mon Mar 26 19:56:29 2018 +1100
> 
> Merge branch 'akpm/master'

Commit, not merge-commit from next or wherever this came from.

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


Re: [U-Boot] [PATCH v1 08/16] arm: socfpga: stratix10: Add mailbox support for Stratix10 SoC

2018-05-08 Thread Marek Vasut
On 05/08/2018 08:49 AM, Ley Foon Tan wrote:
> On Thu, Apr 19, 2018 at 10:53 AM, Marek Vasut  wrote:
>> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
>>> Add mailbox support for Stratix SoC
>>>
>>> Signed-off-by: Ley Foon Tan 
>>> Signed-off-by: Chin Liang See 
>>> ---

[...]

>>> +static __always_inline int mbox_polling_resp(u32 rout)
>>> +{
>>> + static const struct socfpga_mailbox *mbox_base =
>>> + (void *)SOCFPGA_MAILBOX_ADDRESS;
>>> + u32 rin;
>>> + unsigned long i = ~0;
>>> +
>>> + while (i) {
>>> + rin = readl(_base->rin);
>>> + if (rout != rin)
>>> + return 0;
>>
>> This looks like include/wait_bit.h reimplementation
> The reason we use this method instead of using wait_bit because this
> function will use in Secure Monitor Call (SMC) call as well.
> When run in secure section, timer is not available.  So, we can't use
> wait_for_bit.

Can't you just do timer_init() then ?

>>> +/* Send command only without waiting for responses from SDM */
>>> +static __always_inline int __mbox_send_cmd_only(u8 id, u32 cmd,
>>> + u8 is_indirect, u32 len,
>>> + u32 *arg)
>>> +{
>>> + int ret = mbox_prepare_cmd_only(id, cmd, is_indirect, len, arg);
>>> + /* write doorbell */
>>> + writel(1, MBOX_DOORBELL_TO_SDM_REG);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +/* Return number of responses received in buffer */
>>> +static __always_inline int __mbox_rcv_resp(u32 *resp_buf, u32 
>>> resp_buf_max_len)
>>
>> __always_inline is nonsense, drop it. Let the compiler do it's thing.
> This function used in SMC call as well, so it needs to be inline when
> in secure section.

Why ?

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


[U-Boot] [PATCH] FIT: Make fit_conf_print() be a static function

2018-05-08 Thread Tom Rini
We only call fit_conf_print from one place in the code, so mark it as
static and move it up to where we call it.  This in turn has us move a
few other already static functions up further as well.

Signed-off-by: Tom Rini 
---
 common/image-fit.c | 361 ++---
 include/image.h|   2 -
 2 files changed, 179 insertions(+), 184 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 5b93dceae15c..e032f76c00ce 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -144,6 +144,185 @@ int fit_get_subimage_count(const void *fit, int 
images_noffset)
 
 #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_FIT_SPL_PRINT)
 /**
+ * fit_image_print_data() - prints out the hash node details
+ * @fit: pointer to the FIT format image header
+ * @noffset: offset of the hash node
+ * @p: pointer to prefix string
+ * @type: Type of information to print ("hash" or "sign")
+ *
+ * fit_image_print_data() lists properties for the processed hash node
+ *
+ * This function avoid using puts() since it prints a newline on the host
+ * but does not in U-Boot.
+ *
+ * returns:
+ * no returned results
+ */
+static void fit_image_print_data(const void *fit, int noffset, const char *p,
+const char *type)
+{
+   const char *keyname;
+   uint8_t *value;
+   int value_len;
+   char *algo;
+   int required;
+   int ret, i;
+
+   debug("%s  %s node:'%s'\n", p, type,
+ fit_get_name(fit, noffset, NULL));
+   printf("%s  %s algo:", p, type);
+   if (fit_image_hash_get_algo(fit, noffset, )) {
+   printf("invalid/unsupported\n");
+   return;
+   }
+   printf("%s", algo);
+   keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);
+   required = fdt_getprop(fit, noffset, "required", NULL) != NULL;
+   if (keyname)
+   printf(":%s", keyname);
+   if (required)
+   printf(" (required)");
+   printf("\n");
+
+   ret = fit_image_hash_get_value(fit, noffset, ,
+   _len);
+   printf("%s  %s value:   ", p, type);
+   if (ret) {
+   printf("unavailable\n");
+   } else {
+   for (i = 0; i < value_len; i++)
+   printf("%02x", value[i]);
+   printf("\n");
+   }
+
+   debug("%s  %s len: %d\n", p, type, value_len);
+
+   /* Signatures have a time stamp */
+   if (IMAGE_ENABLE_TIMESTAMP && keyname) {
+   time_t timestamp;
+
+   printf("%s  Timestamp:", p);
+   if (fit_get_timestamp(fit, noffset, ))
+   printf("unavailable\n");
+   else
+   genimg_print_time(timestamp);
+   }
+}
+
+/**
+ * fit_image_print_verification_data() - prints out the hash/signature details
+ * @fit: pointer to the FIT format image header
+ * @noffset: offset of the hash or signature node
+ * @p: pointer to prefix string
+ *
+ * This lists properties for the processed hash node
+ *
+ * returns:
+ * no returned results
+ */
+static void fit_image_print_verification_data(const void *fit, int noffset,
+  const char *p)
+{
+   const char *name;
+
+   /*
+* Check subnode name, must be equal to "hash" or "signature".
+* Multiple hash/signature nodes require unique unit node
+* names, e.g. hash-1, hash-2, signature-1, signature-2, etc.
+*/
+   name = fit_get_name(fit, noffset, NULL);
+   if (!strncmp(name, FIT_HASH_NODENAME, strlen(FIT_HASH_NODENAME))) {
+   fit_image_print_data(fit, noffset, p, "Hash");
+   } else if (!strncmp(name, FIT_SIG_NODENAME,
+   strlen(FIT_SIG_NODENAME))) {
+   fit_image_print_data(fit, noffset, p, "Sign");
+   }
+}
+
+/**
+ * fit_conf_print - prints out the FIT configuration details
+ * @fit: pointer to the FIT format image header
+ * @noffset: offset of the configuration node
+ * @p: pointer to prefix string
+ *
+ * fit_conf_print() lists all mandatory properties for the processed
+ * configuration node.
+ *
+ * returns:
+ * no returned results
+ */
+static void fit_conf_print(const void *fit, int noffset, const char *p)
+{
+   char *desc;
+   const char *uname;
+   int ret;
+   int fdt_index, loadables_index;
+   int ndepth;
+
+   /* Mandatory properties */
+   ret = fit_get_desc(fit, noffset, );
+   printf("%s  Description:  ", p);
+   if (ret)
+   printf("unavailable\n");
+   else
+   printf("%s\n", desc);
+
+   uname = fdt_getprop(fit, noffset, FIT_KERNEL_PROP, NULL);
+   printf("%s  Kernel:   ", p);
+   if (uname == NULL)
+   printf("unavailable\n");
+   else
+   printf("%s\n", uname);
+
+   /* Optional properties */
+   

Re: [U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0

2018-05-08 Thread Florian Fainelli
On 05/06/2018 04:09 AM, Thomas Fitzsimmons wrote:
> Add support for loading U-Boot on the Broadcom 7445D0 SoC.  This port
> assumes Broadcom's BOLT bootloader is acting as the second stage
> bootloader, and U-Boot is acting as the third stage bootloader, loaded
> as an ELF program by BOLT.
> 
> Signed-off-by: Thomas Fitzsimmons 
> Cc: Stefan Roese 

> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9bd70f4..b2df30a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -498,6 +498,17 @@ config TARGET_VEXPRESS_CA15_TC2
>   select CPU_V7_HAS_VIRT
>   select PL011_SERIAL
>  
> +config TARGET_BCM7445D0
> + bool "Broadcom 7445D0 TSBL"
> + select CPU_V7
> + select SUPPORT_SPL
> + help
> +   Support for the Broadcom 7445D0 SoC.  This port assumes Bolt

BOLT

> +   is acting as the second stage bootloader, and U-Boot is
> +   acting as the third stage bootloader (TSBL), loaded by Bolt.

again BOLT

> +   This port may work on other BCM7xxx boards with
> +   configuration changes.

There are other revisions than D0, so I would just name this
TARGET_BCM7445. You would likely want to create a TARGET_BRCMSTB general
menu which would encompass all ARMv7-A based SoCs from the Broadcom
STB/CM division, and then have per-chip Kconfig options (similar to what
the older <= 3.14 STB Linux kernels did).

> +
> +config BCMSTB_ACCOMMODATE_STBLINUX
> + bool ""
> + default y
> + help
> +   This prevents U-Boot from adding memory reservations for the
> +  lengths of initramfs and DTB.  Without skipping these,
> +  stblinux's "contiguous memory allocator" (CMA) Linux driver
> +  (cma_driver) will allocate memory ranges smaller than what
> +  are actually available, because it only checks reservation
> +  sizes.  It doesn't check if the reserved range overlaps the
> +  range it allocates.  stblinux also tries to move the DTB to
> +  a lower memory location early in the Linux boot.  If the FIT
> +  image specifies a load address for the initramfs then
> +  sometimes the DTB is moved into the range where the
> +  initramfs image is loaded.  Defining this will mean that
> +  FIT-provided initramfs load addresses are ignored.

What STB Linux kernel did you observe this with? I am afraid this is
still true about the ranges vs. allocation even in newer kernels, but
that is kind of intented to keep the logic KISS (because it's already
too complicated IMHO).

> +
> +config BCMSTB_SDHCI
> + bool ""
> + default y
> +
> +config BCMSTB_SDHCI_BASE
> + hex ""
> + default 0xf03e0200
> +
> +config BCMSTB_SPI_BASE
> + hex ""
> + default 0xf03e3400

Why don't you get those from the Device Tree blob that BOLT passes?

> +
> +config CMD_FDT_MAX_DUMP
> + int ""
> + default 256
> +
> +config GENERIC_MMC
> + bool ""
> + default y
> +
> +config MMC_SDMA
> + bool ""
> + default y
> +
> +config SDHCI
> + bool ""
> + default y
> +
> +config SYS_BCMSTB_SPI_WAIT
> + int ""
> + default 10
> +
> +config SYS_FDT_SAVE_ADDRESS
> + hex ""
> + default 0x1f0
> +
> +config SYS_NO_FLASH
> + bool ""
> + default y
> +
> +config TIMER_FREQUENCY_REGISTER_ADDRESS
> + hex ""
> + default 0xf0412020
> +
> +config TIMER_LOW_REGISTER_ADDRESS
> + hex ""
> + default 0xf0412008

All of these physical address ares not going to change given a
7445-based design, so why not hard code them in a header file unless you
are keen on taking them from the passed Device Tree blob from BOLT?

> +int dram_init_banksize(void)
> +{
> + bd_t *bd = gd->bd;
> +
> + bd->bi_dram[0].start = 0x;
> + bd->bi_dram[0].size  = 0x4000;
> + bd->bi_dram[1].start = 0x4000;
> + bd->bi_dram[1].size  = 0x4000;
> + bd->bi_dram[2].start = 0x8000;
> + bd->bi_dram[2].size  = 0x4000;

This may be true for your system if you have 3x1GB populated, but 7445
supports additional extension regions, so this must be configurable if
you want to make this flexible enough for other people to use it.


> +/* Copied from stblinux, include/linux/brcmstb/brcmstb.h. */
> +#define DEV_RD(x) (readl((x)))
> +#define DEV_WR(x, y) do { writel((y), (x)); } while (0)
> +#define DEV_UNSET(x, y) do { DEV_WR((x), DEV_RD(x) & ~(y)); } while (0)
> +#define DEV_SET(x, y) do { DEV_WR((x), DEV_RD(x) | (y)); } while (0)
> +
> +#define DEV_WR_RB(x, y) do { DEV_WR((x), (y)); DEV_RD(x); } while (0)
> +#define DEV_SET_RB(x, y) do { DEV_SET((x), (y)); DEV_RD(x); } while (0)
> +#define DEV_UNSET_RB(x, y) do { DEV_UNSET((x), (y)); DEV_RD(x); } while (0)

I would just flat out drop those macros and instead use standard
accessors. Those happen to work just fine given Broadcom STB's GISB bus,
but if you want portable drivers in u-boot, and you likely would want
those, you should use more standard I/O accessors.

[U-Boot] [PATCH] board: sun50i: Add Amarula A64-Relic initial support

2018-05-08 Thread Jagan Teki
Amarula A64-Relic is A64 based IoT device, which support
- Allwinner A64 Cortex-A53
- Mali-400MP2 GPU
- AXP803 PMIC
- 1GB DDR3 RAM
- 8GB eMMC
- AP6330 Wifi/BLE
- MIPI-DSI
- CSI: OV5640 sensor
- USB OTG
- 12V DC power supply

Signed-off-by: Jagan Teki 
---
Note: 
Maxime, I saw your previous comments about CONFIG_CMD_USB_MASS_STORAGE
defining in defconfig, may I know why we can't enable it in defconfig file?

 arch/arm/dts/Makefile |  1 +
 arch/arm/dts/sun50i-a64-amarula-relic.dts | 65 +++
 board/sunxi/MAINTAINERS   |  6 +++
 configs/amarula_a64_relic_defconfig   | 18 +
 4 files changed, 90 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-a64-amarula-relic.dts
 create mode 100644 configs/amarula_a64_relic_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 289e11551a..f69eb4e014 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -376,6 +376,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
+   sun50i-a64-amarula-relic.dtb \
sun50i-a64-bananapi-m64.dtb \
sun50i-a64-nanopi-a64.dtb \
sun50i-a64-olinuxino.dtb \
diff --git a/arch/arm/dts/sun50i-a64-amarula-relic.dts 
b/arch/arm/dts/sun50i-a64-amarula-relic.dts
new file mode 100644
index 00..5a56092707
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-amarula-relic.dts
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 Amarula Solutions B.V.
+ * Author: Jagan Teki 
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "Amarula A64-Relic";
+   compatible = "amarula,a64-relic", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
+_otg {
+   dr_mode = "peripheral";
+   status = "okay";
+};
+
+ {
+   usb0_id_det-gpios = < 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
+   status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 6dd48c0265..d8863fe530 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -116,6 +116,12 @@ M: Paul Kocialkowski 
 S: Maintained
 F: configs/Ainol_AW1_defconfig
 
+AMARULA A64-RELIC
+M: Jagan Teki 
+S: Maintained
+F: configs/amarula_a64_relic_defconfig
+F: arch/arm/dts/sun50i-a64-amarula-relic.dts
+
 AMPE A76 BOARD
 M: Paul Kocialkowski 
 S: Maintained
diff --git a/configs/amarula_a64_relic_defconfig 
b/configs/amarula_a64_relic_defconfig
new file mode 100644
index 00..6eab0d2ae5
--- /dev/null
+++ b/configs/amarula_a64_relic_defconfig
@@ -0,0 +1,18 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I=y
+CONFIG_DRAM_ODT_EN=y
+CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+# CONFIG_VIDEO_DE2 is not set
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_FPGA is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_CMD_USB_MASS_STORAGE=y
+# CONFIG_SPL_ISO_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.14.3

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


Re: [U-Boot] [U-Boot, v2, 2/2] test: regmap: add read/modify/write test

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 11:56:15AM +0200, Neil Armstrong wrote:

> Add calls to regmap_read/modify_bits/write even if the proper memory
> read/write calls are not executed in sandbox.
> 
> Signed-off-by: Neil Armstrong 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH] lib/Kconfig: Mark OF_LIBFDT_OVERLAY as depending on OF_LIBFDT

2018-05-08 Thread Tom Rini
On Tue, May 08, 2018 at 08:53:07AM -0400, Tom Rini wrote:

> The overlay code is only useful when OF_LIBFDT is set, so mark it as
> depending on that first.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 1/4] power: regulator: Add support for stm32-vrefbuf

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 05:00:46PM +0200, Patrice Chotard wrote:

> From: Fabrice Gasnier 
> 
> Add regulator driver for STM32 voltage reference buffer which can be
> used as voltage reference for ADCs, DACs and external components through
> dedicated VREF+ pin.
> 
> Signed-off-by: Fabrice Gasnier 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 1/2] regmap: add regmap_update_bits() helper

2018-05-08 Thread Tom Rini
On Fri, Apr 27, 2018 at 11:56:14AM +0200, Neil Armstrong wrote:

> Add the regmap_update_bits() to simply the read/modify/write of registers
> in a single command. The function is taken from Linux regmap
> implementation.
> 
> Signed-off-by: Neil Armstrong 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 1/2] stm32mp: regulator: add SoC pwr regulator support

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 04:45:18PM +0200, Patrice Chotard wrote:

> From: Patrick Delaunay 
> 
> This driver binds and manages the following regulator of
> SoC's PWR block :
>   - reg11
>   - reg18
>   - usb33
> 
> Signed-off-by: Patrick Delaunay 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 2/4] power: pmic: stpmu1: Add regulator bindings

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 05:13:10PM +0200, Patrice Chotard wrote:

> Add regulator bindings to get access to regulator managed
> by drivers/power/regulator/stpmu1.c regulator driver.
> 
> Signed-off-by: Christophe Kerello 
> Signed-off-by: Patrick Delaunay 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,u-boot] adc: add Amlogic Meson SAR ADC driver

2018-05-08 Thread Tom Rini
On Mon, Apr 23, 2018 at 04:19:23PM +0200, Neil Armstrong wrote:

> This patch adds the driver for the Amlogic Meson Successive Approximation
> Register (SAR) A/D Converter based on the Linux IIO driver thanks to the
> great work of Martin Blumenstingl.
> The driver has been adapted to U-Boot and the ADC UClass.
> 
> This patch depends on the regmap "regmap: add regmap_update_bits() helper"
> patch and has been tested using the newly introducted "adc" CLI command
> in the "cmd: add ADC cli commands" patch.
> 
> Signed-off-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] configs: at91: sama5: updated mtdparts variable in bootargs

2018-05-08 Thread Tom Rini
On Tue, Apr 24, 2018 at 12:00:16PM +0300, Eugen Hristev wrote:

> We have a new demo layout of our sama5 boards for the NAND Flash
> memory.
> According to this new layout, adjust the mtdparts variable in bootargs
> to align with this, which is available at :
> http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d3XplainedMainPage#NAND_Flash_demo_Memory_map,
> 
> Based on original work by Wenyou Yang
> 
> Signed-off-by: Eugen Hristev 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] board: sama5d2_ptc_ek: adjust the smc timings of nand

2018-05-08 Thread Tom Rini
On Tue, Apr 24, 2018 at 10:43:53AM +0300, Eugen Hristev wrote:

> To fix the issue of write the rootfs.ubi, adjust the smc timings
> configuration of the nand controller.
> 
> Based on original work by Wenyou Yang
> 
> Signed-off-by: Eugen Hristev 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] arm: controlcenterdc: Add spi-flash compatible strings

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 10:10:59AM +0200, Mario Six wrote:

> Since kirkwook SPI was recently converted to DM, add compatible strings
> to the SPI flash devices to make them work with the new driver.
> 
> Signed-off-by: Mario Six 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] board: sama5d27_som1_ek: Fix the USB vbus power

2018-05-08 Thread Tom Rini
On Tue, Apr 24, 2018 at 02:36:28PM +0300, Eugen Hristev wrote:

> According to the REVB schematic, fix the USB vbus power enable pin.
> 
> Based on original work by Wenyou Yang
> 
> Signed-off-by: Eugen Hristev 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 1/4] power: regulator: stpmu1: Introduce stpmu1 driver

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 05:13:09PM +0200, Patrice Chotard wrote:

> From: Christophe Kerello 
> 
> Enable support for the regulator functions of the STPMU1X PMIC. The
> driver implements get/set api for the various BUCKS and LDOs supported
> by the PMIC device. This driver is controlled by a device tree node
> which includes voltage limits.
> 
> Signed-off-by: Christophe Kerello 
> Signed-off-by: Patrick Delaunay 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] gpio: atmel_pio4: give a full configuration when muxing pins

2018-05-08 Thread Tom Rini
On Tue, Apr 24, 2018 at 10:16:01AM +0300, Eugen Hristev wrote:

> From: Ludovic Desroches 
> 
> When a pin is muxed to a peripheral or as a GPIO, the only
> configuration that can be set is the pullup. It is too restrictive
> so this patch allows to give a full configuration.
> 
> Signed-off-by: Ludovic Desroches 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v4] arm64: Add SMC and HVC commands

2018-05-08 Thread Tom Rini
On Fri, Apr 13, 2018 at 10:40:57AM +0300, Michalis Pappas wrote:

> This patch adds smc and hvc commands, that allow issuing Secure Monitor
> Calls and Hypervisor Calls conforming to the ARM SMC Calling Convention.
> 
> Add Kconfig items to allow each command can be individually enabled.
> 
> Signed-off-by: Michalis Pappas 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 2/4] clk: stm32mp1: Add VREF clock gating

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 05:00:47PM +0200, Patrice Chotard wrote:

> From: Fabrice Gasnier 
> 
> Add VREF clock gating, that may be used by STM32 VREFBUF regulator.
> 
> Signed-off-by: Fabrice Gasnier 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 2/2] ARM: dts: stm32mp157: Add SoC pwr regulator entry

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 04:45:19PM +0200, Patrice Chotard wrote:

> Add SoC power regulator entry for reg11, reg18 and usb33
> regulator.
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 2/2] board: atmel: sama5d2_ptc_ek: update pin configuration for NAND

2018-05-08 Thread Tom Rini
On Mon, Apr 23, 2018 at 10:59:50AM +0300, Eugen Hristev wrote:

> From: Ludovic Desroches 
> 
> The drive strength has to be set to medium for the NAND data lines.
> With a low drive, we can get some data corruption.
> 
> Signed-off-by: Ludovic Desroches 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,2/2] env: ti: android: boot with FIT Image

2018-05-08 Thread Tom Rini
On Wed, Apr 25, 2018 at 04:03:24PM -0500, Praneeth Bajjuri wrote:

> Boot android over emmc by default thru FIT image
> 
> Signed-off-by: Praneeth Bajjuri 
> Suggested-by: Andrew F.Davis 
> Reviewed-by: Tom Rini 
> Reviewed-by: Sam Protsenko 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/2] configs: TI: Enable FIT Library overlay support

2018-05-08 Thread Tom Rini
On Wed, Apr 25, 2018 at 04:03:23PM -0500, Praneeth Bajjuri wrote:

> Enable the FDT library overlay support for all TI SOC family.
> 
> Without this option, when Loading fdt from FIT image, the
> following warning is seen.
> 
> "config with overlays but CONFIG_OF_LIBFDT_OVERLAY not set".
> 
> Signed-off-by: Praneeth Bajjuri 
> Suggested-by: Andrew F.Davis 
> Reviewed-by: Tom Rini 
> Reviewed-by: Sam Protsenko 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 3/4] configs: stm32mp15: Enable STM32_VREFBUF flag

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 05:00:48PM +0200, Patrice Chotard wrote:

> From: Fabrice Gasnier 
> 
> Enable vrefbuf on stm32mp15, to be used by ADC.
> 
> Signed-off-by: Fabrice Gasnier 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 3/4] ARM: dts: stm32mp157c-ed1: Add regulator node

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 05:13:11PM +0200, Patrice Chotard wrote:

> Add regulator nodes needed by stpmu1 regulator driver
> Add vmmc-supply and vqmmc-supply regulator property for
> sdmmc1 and sdmmc2.
> 
> Signed-off-by: Christophe Kerello 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] defconfig: at91-sama5d2_ptc_ek: remove unused SYS_EXTRA_OPTIONS

2018-05-08 Thread Tom Rini
On Wed, Apr 25, 2018 at 12:22:41PM +0300, Eugen Hristev wrote:

> From: Ludovic Desroches 
> 
> Remove SYS_USE_NANDFLASH, SYS_USE_MMC as they are deprecated and
> unused.
> The board configurations already use CONFIG_SD_BOOT and
> CONFIG_NAND_BOOT respectively.
> 
> Signed-off-by: Ludovic Desroches 
> [eugen.hris...@microchip.com: rework on latest u-boot]
> Signed-off-by: Eugen Hristev 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/3] arm: dra76: fastboot: extend cpu type for getvar command

2018-05-08 Thread Tom Rini
On Wed, Apr 25, 2018 at 03:56:34PM -0500, Praneeth Bajjuri wrote:

> 'commit dda0bd674481 ("arm: dra762: Add support for device package 
> identification")'
> introduces ABZ and ACD package identification.
> 
> This patch is to extend usage of "fastboot getvar cpu" for
> DRA76x ABZ and ACD devices.
> 
> Helps in fixing the boot warning.
> 
> Warning: fastboot.cpu: unknown CPU rev: 123863298
> on
> CPU  : DRA762-GP ES1.0 ABZ package
> Model: TI AM5748 IDK
> Board: AM574x IDK REV 1.0A
> 
> Signed-off-by: Praneeth Bajjuri 
> Reviewed-by: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/2] gpio: atmel_pio4: add drive strength macros

2018-05-08 Thread Tom Rini
On Mon, Apr 23, 2018 at 10:59:49AM +0300, Eugen Hristev wrote:

> From: Ludovic Desroches 
> 
> Macros for drive strength configuration were missing.
> 
> Signed-off-by: Ludovic Desroches 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot,v2,u-boot] ARM: meson: rename GXBB to GX

2018-05-08 Thread Tom Rini
On Wed, Apr 11, 2018 at 05:13:45PM +0200, Neil Armstrong wrote:

> Taking into account the Amlogic Family name starts with GX, including
> the GXBB, GXL and GXM SoCs.
> 
> Signed-off-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 4/4] configs: stm32mp15_basic: Set regulator relative flags

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 05:13:12PM +0200, Patrice Chotard wrote:

> Enable DM_REGULATOR_STPMU1 flag to activate regulator
> driver for STM32MP15 SoC and CMD_REGULATOR flag to be
> able to set/get regulator state int U-boot command line.
> 
> Disable PMIC_CHILDREN as this flag is not needed in SPL
> for STM32MP1.
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] pci: intel: Add Intel FPGA PCIe controller driver

2018-05-08 Thread Tom Rini
On Fri, Apr 20, 2018 at 09:55:45PM +0800, Ley Foon Tan wrote:

> Add PCIe driver for Intel FPGA PCIe IP. This driver operates the PCIe IP in
> rootport mode only, the EP mode is not supported. The driver is tested
> with the Intel e1000e NIC driver.
> 
> Signed-off-by: Ley Foon Tan 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, RESEND, v1, 4/4] ARM: dts: stm32mp157: Add vrefbuf DT node

2018-05-08 Thread Tom Rini
On Thu, Apr 26, 2018 at 05:00:49PM +0200, Patrice Chotard wrote:

> Add vrefbuf device tree node. This allows to get
> a voltage reference for ADCs.
> 
> Signed-off-by: Patrice Chotard 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v4, 2/3] dm: led: auto probe() LEDs with "default-state"

2018-05-08 Thread Tom Rini
On Wed, Apr 11, 2018 at 11:16:28AM +0200, linux-kernel-...@beckhoff.com wrote:

> From: Patrick Bruenn 
> 
> To avoid board specificy LED activation code, automatically
> activate gpio-leds with "default-state" property during bind().
> 
> Signed-off-by: Patrick Bruenn 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] mach-snapdragon: Fix UART clock flow

2018-05-08 Thread Tom Rini
On Tue, Apr 17, 2018 at 05:43:37PM +0300, Ramon Fried wrote:

> UART clock enabling flow was wrong.
> Changed the flow according to downstream implementation in LK.
> 
> Signed-off-by: Ramon Fried 

This causes a warning on dragonboard410c:
   aarch64:  +   dragonboard410c
+(dragonboard410c)   clk_enable_vote_clk(priv->base, _blsp1_ahb_clk);
+(dragonboard410c)   ^~~
+(dragonboard410c)   clk_enable_bulk
w+(dragonboard410c) arch/arm/mach-snapdragon/clock-apq8016.c: In function 
'clk_init_uart':
w+(dragonboard410c) arch/arm/mach-snapdragon/clock-apq8016.c:81:2: warning: 
implicit declaration of function 'clk_enable_vote_clk'; did you mean 
'clk_enable_bulk'? [-Wimplicit-function-declaration]

-- 
Tom


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


Re: [U-Boot] [U-Boot,3/3] mmc: support writing sparse images

2018-05-08 Thread Tom Rini
On Fri, Apr 06, 2018 at 12:05:24PM +0530, jassisinghb...@gmail.com wrote:

> From: Jassi Brar 
> 
> Provide an alternate path for sparse-images to be
> written to MMC. For example, via tftp on platforms
> that don't support fastboot protocol. Or when an
> image is to written at some offset, rather than the
> start of a partition.
> 
> Signed-off-by: Jassi Brar 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, u-boot, 1/2] ARM64: meson: Sync DT and Bindings with Linux 4.16

2018-05-08 Thread Tom Rini
On Wed, Apr 11, 2018 at 05:40:40PM +0200, Neil Armstrong wrote:

> Synchronize the Linux Device Tree for Amlogic Meson GX boards from Linux 
> 4.16.0.
> 
> Signed-off-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v4, 3/3] dm: led: add testcase for "default-state" property

2018-05-08 Thread Tom Rini
On Wed, Apr 11, 2018 at 11:16:29AM +0200, linux-kernel-...@beckhoff.com wrote:

> From: Patrick Bruenn 
> 
> Add two more gpio-leds to sandbox test device tree with default-state
> property set to "on"/"off".
> Add dm_test_led_default_state() to check that these new LED's are set to
> LEDST_ON and LEDST_OFF.
> 
> dm: led: add testcase for "default-state" property
> 
> Add two more gpio-leds to sandbox test device tree with default-state
> property set to "on"/"off".
> Add dm_test_led_default_state() to check that these new LED's are set to
> LEDST_ON and LEDST_OFF.
> 
> Signed-off-by: Patrick Bruenn 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, u-boot, 2/2] pinctrl: meson: Update pinmux with new Linux bindings

2018-05-08 Thread Tom Rini
On Wed, Apr 11, 2018 at 05:40:41PM +0200, Neil Armstrong wrote:

> The pinctrl bindings has changed for Amlogic Meson SoCs since Linux 4.13,
> update the pinctrl driver to take this in account.
> 
> Signed-off-by: Neil Armstrong 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] clk: clk_stm32f: Use PLLSAIP as USB 48MHz clock

2018-05-08 Thread Tom Rini
On Wed, Apr 11, 2018 at 05:07:45PM +0200, Patrice Chotard wrote:

> On all STM32F4 and F7 SoCs  family (except STM32F429), PLLSAI
> output P can be used as 48MHz clock source for USB and SDMMC.
> 
> Signed-off-by: Patrice Chotard 
> Tested By: Bruno Herrera 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 2/3] fastboot: sparse: make write_sparse_image useable for non-fastboot

2018-05-08 Thread Tom Rini
On Fri, Apr 06, 2018 at 12:05:09PM +0530, jassisinghb...@gmail.com wrote:

> From: Jassi Brar 
> 
> write_sparse_image could be useful for non-fastboot users.
> For ex a platform, without usb-device/fastboot support, could
> get sparse images over tftp and write using the mmc command.
> Or non-android systems could also leverage the sparse format.
> 
> Towards that, this patch removes anything fastboot specific from
> the write_sparse_image implementation. Which includes making the
> function return integer as error code and calls for fastboot logging
> via an optional callback function 'mssg'.
> 
> Signed-off-by: Jassi Brar 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v4, 1/3] dm: led: Support "default-state" property

2018-05-08 Thread Tom Rini
On Wed, Apr 11, 2018 at 11:16:27AM +0200, linux-kernel-...@beckhoff.com wrote:

> From: Patrick Bruenn 
> 
> Add support for the device tree property "default-state". This feature
> might be useful for LEDs indicating "power on" or similar states.
> 
> Note: Even with this commit gpio-leds remain in reset state. That's
> because the led_gpio is not probed until DM_FLAG_ACTIVATED is set.
> 
> Signed-off-by: Patrick Bruenn 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, 1/3] fastboot: sparse: remove redundant argument to write_sparse_image

2018-05-08 Thread Tom Rini
On Fri, Apr 06, 2018 at 12:04:52PM +0530, jassisinghb...@gmail.com wrote:

> From: Jassi Brar 
> 
> 'sz' has no use for write_sparse_image, remove it simplifying the api.
> 
> Signed-off-by: Jassi Brar 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Appended DTB Android boot image support

2018-05-08 Thread Ramon Fried
On Fri, May 4, 2018, 10:38 PM Simon Glass  wrote:

> Hi,
>
> On 1 May 2018 at 04:52, Ramon Fried  wrote:
> > On Tue, May 1, 2018 at 12:20 PM, Alex Deymo  wrote:
> >> Hi Ramon,
> >>
> >> What "header_version" is the boot image you have? The
> >> include/android_image.h in U-Boot is a little bit old so it only
> defines the
> >> v0 format. The "unused" field in v0 was renamed to "header_version"
> where 0
> >> means v0. The v1 adds a few more fields, including a DTB/DTBO for
> *recovery*
> >> mode.
> >> See
> >>
> https://android.googlesource.com/platform/system/core/+/master/mkbootimg/include/bootimg/bootimg.h
> >>
> > Yes, the U-boot has the v0 version.
> >
> >> Having multiple DTs and picking one or merge overlays at runtime is a
> >> reasonable thing and there's some documentation in AOSP on how to do it
> in
> >> Android: https://source.android.com/devices/architecture/dto/multiple
> (and
> >> other sections around it). There are some options on where to store
> these
> >> and even a supported format for placing multiple .dtbo in a single
> "dtbo"
> >> partition (but appending multiple DTBs at the end of the kernel is not
> one
> >> of these).
> >>
> >> Which are the "seconday" fields you are referring to?
> >
> > uint32_t second_size; /* size in bytes */
> > uint32_t second_addr; /* physical load addr */
> >
> > In
> https://android.googlesource.com/platform/system/core/+/master/mkbootimg/include/bootimg/bootimg.h
> >>
> >> I'm not familiar with the Dragonboard images, but it looks like they
> just
> >> extended this over the reserved space in a different way. Maybe you can
> >> convert the header to the newer format, but that still requires work in
> >> U-Boot to support the new format.
> > I'm willing to do it, I just want to get some approval from
> > maintainers before I dive in.
> >
> > Thanks,
> > Ramon
> >>
> >> Regards,
> >> Alex
> >>
> >>
> >> Le lun. 30 avr. 2018 à 16:17, Ramon Fried  a
> écrit :
> >>>
> >>> Hi all.
> >>> I'm currently adding support for Qualcomm Dragonboards  to U-boot as a
> >>> primary bootloader without chain-loading using LK which is currently
> >>> already supported in mainline U-boot.
> >>>
> >>> Qualcomm Android images are regular android images where the DTB's are
> >>> appended to the image. Qualcomm used the "unused" field in the image
> >>> header to populate the size of the DTB *.
> >>>
> >>> I'm looking for a more standard version for supporting these kind of
> >>> images.
> >>> Currently, to boot these images, you must provide DTB somewhere in mem
> >>> and provide it as argument to bootm for instance.
> >>>
> >>> My goal is to add support that U-boot will parse the image, see that
> >>> the DTB is included and use that as the FDT automatically.
> >>>
> >>> I'm looking at the "secondary" fields which are currently not used as
> >>> a valid option to point to the DTB and it's size.
> >>>
> >>> Do you know if someone is working on something similar, or do you have
> >>> any suggestions for the right approach to this issue ?
>
> Does every vendor just do its own thing, or is there a standard header
> structure?
>
I don't know. I'm familiar only with Qualcomm way. Not sure about the rest.

>
> How can we detect multiple incompatible options? Just by the machine
> architecture?
>
Qualcomm is using the unused fields in version 1 of Android boot header. I
guess that ifdef in the source code is the only way.

>
> Can we just use FIT perhaps?
>
Of course we can, I already booted successfully with FIT. But it will
require users to repackage their kernel boot image.


> >>>
> >>> Thanks,
> >>> Ramon
> >>>
> >>> * - Actually, Qualcomm appends a pack of DTBs with offset table and
> >>> chooses the right DTB in runtime.
> >>> ___
> >>> U-Boot mailing list
> >>> U-Boot@lists.denx.de
> >>> https://lists.denx.de/listinfo/u-boot
>
> Regards,
> Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 16/20] fastboot: net: Add NAND support

2018-05-08 Thread Jocelyn Bohr
On Thu, May 3, 2018 at 2:24 PM Joe Hershberger 
wrote:

> On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan 
> wrote:
> > Add NAND support to fastboot UDP flash/erase commands
> >
> > Signed-off-by: Alex Kiernan 
>
> Acked-by: Joe Hershberger 
>

Reviewed-by: Jocelyn Bohr 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 16/20] fastboot: net: Add NAND support

2018-05-08 Thread Jocelyn Bohr
On Tue, May 8, 2018 at 2:09 AM Alex Kiernan  wrote:

> On Tue, May 8, 2018 at 8:20 AM Joe Hershberger 
> wrote:
>
> > On Tue, May 8, 2018 at 1:53 AM, Jocelyn Bohr  wrote:
> > > On Mon, Apr 30, 2018 at 1:33 AM Alex Kiernan 
> wrote:
> > >
> > >> Add NAND support to fastboot UDP flash/erase commands
> > >>
> > >> Signed-off-by: Alex Kiernan 
> > >> ---
> > >>
> > >> Changes in v2: None
> > >>
> > >>  net/fastboot.c | 17 ++---
> > >>  1 file changed, 14 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/net/fastboot.c b/net/fastboot.c
> > >> index 119011c..a07b1ad 100644
> > >> --- a/net/fastboot.c
> > >> +++ b/net/fastboot.c
> > >> @@ -60,7 +60,7 @@ static int fastboot_our_port;
> > >>  static void cb_okay(char *, char *, unsigned int, char *);
> > >>  static void cb_getvar(char *, char *, unsigned int, char *);
> > >>  static void cb_download(char *, char *, unsigned int, char *);
> > >> -#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> > >> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
> > >>  static void cb_flash(char *, char *, unsigned int, char *);
> > >>  static void cb_erase(char *, char *, unsigned int, char *);
> > >>  #endif
> > >> @@ -74,7 +74,7 @@ static void (*fb_net_dispatch[])(char
> *cmd_parameter,
> > >> [FB_CMD_GETVAR] = cb_getvar,
> > >> [FB_CMD_DOWNLOAD] = cb_download,
> > >> [FB_CMD_VERIFY] = NULL,
> > >> -#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> > >> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
> > >> [FB_CMD_FLASH] = cb_flash,
> > >> [FB_CMD_ERASE] = cb_erase,
> > >>  #else
> > >> @@ -324,7 +324,7 @@ static void cb_download(char *cmd_parameter, char
> > >> *fastboot_data,
> > >> }
> > >>  }
> > >>
> > >> -#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> > >> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
> > >>  /**
> > >>   * Writes the previously downloaded image to the partition indicated
> by
> > >>   * cmd_parameter. Writes to response.
> > >> @@ -334,8 +334,14 @@ static void cb_download(char *cmd_parameter, char
> > >> *fastboot_data,
> > >>  static void cb_flash(char *cmd_parameter, char *fastboot_data,
> > >>  unsigned int fastboot_data_len, char *response)
> > >>  {
> > >> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> > >> fb_mmc_flash_write(cmd_parameter, (void
> *)CONFIG_FASTBOOT_BUF_ADDR,
> > >>image_size, response);
> > >> +#endif
> > >> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_NAND)
> > >> +   fb_nand_flash_write(cmd_parameter, (void
> > >> *)CONFIG_FASTBOOT_BUF_ADDR,
> > >> +   image_size, response);
> > >> +#endif
> > >>
> > >
> > > Is there a way to make FASTBOOT_FLASH_MMC and FASTBOOT_FLASH_NAND
> > > mutually exclusive? Currently here and elsewhere, both mmc and nand
> write
> > > are executed
> > > when both configs are enabled, and I'm not sure if that's the intended
> > > behavior.
>
> > I thought in Kconfig those two configs are a "choice" so only one can
> > be enabled at a time.
>
> They are.
>

Oh great, sorry I'm not super familiar with Kconfig. LGTM then!

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


Re: [U-Boot] [RFC PATCH v2 07/20] net: fastboot: Merge AOSP UDP fastboot

2018-05-08 Thread Alex Kiernan
On Tue, May 8, 2018 at 4:24 PM Joe Hershberger 
wrote:

> On Tue, May 8, 2018 at 4:11 AM, Alex Kiernan 
wrote:
> > On Thu, May 3, 2018 at 9:39 PM Joe Hershberger 
> > wrote:
> >
> >> On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan 
> > wrote:
> >
> > 
> >
> >> > +/**
> >> > + * Constructs and sends a packet in response to received fastboot
> > packet
> >> > + *
> >> > + * @param fb_headerHeader for response packet
> >> > + * @param fastboot_dataPointer to received fastboot data
> >> > + * @param fastboot_data_lenLength of received fastboot data
> >> > + * @param retransmit   Nonzero if sending last sent packet
> >> > + */
> >> > +static void fastboot_send(struct fastboot_header fb_header, char
> > *fastboot_data,
> >> > + unsigned int fastboot_data_len, uchar
> > retransmit)
> >> > +{
> >> > +   uchar *packet;
> >> > +   uchar *packet_base;
> >> > +   int len = 0;
> >> > +   const char *error_msg = "An error occurred.";
> >> > +   short tmp;
> >> > +   struct fastboot_header fb_response_header = fb_header;
> >> > +   char response[FASTBOOT_RESPONSE_LEN] = {0};
> >> > +   /*
> >> > +*  We will always be sending some sort of packet, so
> >> > +*  cobble together the packet headers now.
> >> > +*/
> >> > +   packet = net_tx_packet + net_eth_hdr_size() +
IP_UDP_HDR_SIZE;
> >> > +   packet_base = packet;
> >> > +
> >> > +   /* Resend last packet */
> >> > +   if (retransmit) {
> >> > +   memcpy(packet, last_packet, last_packet_len);
> >> > +   net_send_udp_packet(net_server_ethaddr,
> > fastboot_remote_ip,
> >> > +   fastboot_remote_port,
> > fastboot_our_port,
> >> > +   last_packet_len);
> >> > +   return;
> >> > +   }
> >> > +
> >> > +   fb_response_header.seq = htons(fb_response_header.seq);
> >> > +   memcpy(packet, _response_header,
sizeof(fb_response_header));
> >> > +   packet += sizeof(fb_response_header);
> >> > +
> >> > +   switch (fb_header.id) {
> >> > +   case FASTBOOT_QUERY:
> >> > +   tmp = htons(fb_sequence_number);
> >> > +   memcpy(packet, , sizeof(tmp));
> >> > +   packet += sizeof(tmp);
> >> > +   break;
> >> > +   case FASTBOOT_INIT:
> >> > +   tmp = htons(fb_udp_version);
> >> > +   memcpy(packet, , sizeof(tmp));
> >> > +   packet += sizeof(tmp);
> >> > +   tmp = htons(fb_packet_size);
> >> > +   memcpy(packet, , sizeof(tmp));
> >> > +   packet += sizeof(tmp);
> >> > +   break;
> >> > +   case FASTBOOT_ERROR:
> >> > +   memcpy(packet, error_msg, strlen(error_msg));
> >> > +   packet += strlen(error_msg);
> >> > +   break;
> >> > +   case FASTBOOT_FASTBOOT:
> >> > +   if (!cmd_string) {
> >> > +   /* Parse command and send ack */
> >> > +   cmd_parameter = fastboot_data;
> >
> >> This seems unnecessary. There are only 4 cases handled, and of them
> >> only download seems to be a command that happens more than once. And
> >> in download, the first past through this parameter is saved internally
> >> as bytes_expected.
> >
> >> > +   cmd_string = strsep(_parameter, ":");
> >> > +   cmd_string = strdup(cmd_string);
> >> > +   if (cmd_parameter)
> >> > +   cmd_parameter =
strdup(cmd_parameter);
> >> > +   } else if (!strcmp("getvar", cmd_string)) {
> >> > +   fb_getvar(response);
> >
> >> Seems like you should simply pass the "fastboot_data" as a parameter
> >> here rather than using a global.
> >
> > I'm completely pulling this apart in a later patch. I wonder if I should
> > really be folding some of these back into this - I was trying to
maintain a
> > clear line to the AOSP code which this came from.

> What value do we get from that? Is there a merge technique you are
> trying to enable to make pulling in future AOSP changes easier? Are
> you trying to isolate your changes from AOSP for attribution purposes?

I was trying to maintain the attribution line, but given the level of
change I'm struggling to achieve that in what's an increasingly complex
chain of patches which end up interacting too much.

Given Alex and Jocelyn are engaged, I'm not sure I see the value in
continuing trying to do this.

> So far I'm of the opinion that the fixes to the existing code should
> simply be there in the originating patch. Feel free to convince me
> otherwise.

I'll fail to convince you as I'm increasingly unconvinced myself... I'm
spending more time rebasing patches than actually separating the code into

Re: [U-Boot] [PATCH] driver: net: fsl-mc: updated copyright info

2018-05-08 Thread York Sun
On 03/15/2018 02:07 AM, Yogesh Narayan Gaur wrote:
> Updated copyright info for the issues reported after running
> check-legal test.
> 
> Signed-off-by: Yogesh Gaur 
> ---
> Legally NXP and Freescale Semiconductor are same entity.

Can you refresh this patch? It has conflict with Tom's recent change on
SPDX.

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


Re: [U-Boot] [PATCH] net: Protect net_state from reentrant net_loop()

2018-05-08 Thread Joe Hershberger
On Tue, May 8, 2018 at 8:55 AM, Leonid Iziumtsev
 wrote:
> Global variable "net_state" is used in net_loop() state-machine.
> But it happens that some times the net_loop() can be called
> multiple times in the same call stack. For example when the
> netconsole is enabled and we print the message while some other
> net protocol is in action. Netconsole will overwrite the "net_state"
> and that will break the logic for earlier started protocol.
>
> To protect the state save and restore "net_state" variable each
> time when we enter and exit net_loop().
>
> Signed-off-by: Leonid Iziumtsev 

Acked-by: Joe Hershberger 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v6 2/6] apalis-tk1: add missing as3722 gpio0 configuration

2018-05-08 Thread Marcel Ziswiler
From: Marcel Ziswiler 

As the AS3722 GPIO0 is also a not connected on our Apalis TK1 module
explicitly configure it to high-impedance as well.

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

---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add Simon's reviewed-by.

 arch/arm/dts/tegra124-apalis.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/tegra124-apalis.dts b/arch/arm/dts/tegra124-apalis.dts
index 2fc0384d14..fe08d3ea73 100644
--- a/arch/arm/dts/tegra124-apalis.dts
+++ b/arch/arm/dts/tegra124-apalis.dts
@@ -1683,9 +1683,9 @@
bias-pull-up;
};
 
-   gpio1_3_4_5_6 {
-   pins = "gpio1", "gpio3", "gpio4",
-  "gpio5", "gpio6";
+   gpio0_1_3_4_5_6 {
+   pins = "gpio0", "gpio1", "gpio3",
+  "gpio4", "gpio5", "gpio6";
bias-high-impedance;
};
};
-- 
2.14.3

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


[U-Boot] [PATCH v6 4/6] pci: tegra: introduce weak tegra_pcie_board_port_reset() function

2018-05-08 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Introduce a weak tegra_pcie_board_port_reset() function by default
calling the existing tegra_pcie_port_reset() function. Additionally add
a tegra_pcie_port_index_of_port() function to retrieve the specific PCIe
port index if required. This allows overriding the PCIe port reset
functionality from board specific code as e.g. required for Apalis T30
and Apalis TK1.

Signed-off-by: Marcel Ziswiler 
Acked-by: Stephen Warren 

---

Changes in v6:
- Updated to latest SPDX style.

Changes in v5:
- Add Stephen's acked-by.

Changes in v4:
- Revert previously missed (struct tegra_pcie_port *) casts as reported
  by Stephen.

Changes in v3:
- Stick to struct tegra_pcie_port as suggested by Stephen.

Changes in v2:
- Incorporate Stephen's review feedback by introducing a
  tegra_pcie_port_index_of_port() function as well as a board-specific
  reset override function.

 drivers/pci/pci_tegra.c | 17 ++---
 include/pci_tegra.h | 10 ++
 2 files changed, 24 insertions(+), 3 deletions(-)
 create mode 100644 include/pci_tegra.h

diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index b325914b15..56c08585e6 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -888,7 +889,7 @@ static unsigned long tegra_pcie_port_get_pex_ctrl(struct 
tegra_pcie_port *port)
return ret;
 }
 
-static void tegra_pcie_port_reset(struct tegra_pcie_port *port)
+void tegra_pcie_port_reset(struct tegra_pcie_port *port)
 {
unsigned long ctrl = tegra_pcie_port_get_pex_ctrl(port);
unsigned long value;
@@ -905,6 +906,16 @@ static void tegra_pcie_port_reset(struct tegra_pcie_port 
*port)
afi_writel(port->pcie, value, ctrl);
 }
 
+int tegra_pcie_port_index_of_port(struct tegra_pcie_port *port)
+{
+   return port->index;
+}
+
+void __weak tegra_pcie_board_port_reset(struct tegra_pcie_port *port)
+{
+   tegra_pcie_port_reset(port);
+}
+
 static void tegra_pcie_port_enable(struct tegra_pcie_port *port)
 {
struct tegra_pcie *pcie = port->pcie;
@@ -923,7 +934,7 @@ static void tegra_pcie_port_enable(struct tegra_pcie_port 
*port)
 
afi_writel(pcie, value, ctrl);
 
-   tegra_pcie_port_reset(port);
+   tegra_pcie_board_port_reset(port);
 
if (soc->force_pca_enable) {
value = rp_readl(port, RP_VEND_CTL2);
@@ -974,7 +985,7 @@ static bool tegra_pcie_port_check_link(struct 
tegra_pcie_port *port)
} while (--timeout);
 
 retry:
-   tegra_pcie_port_reset(port);
+   tegra_pcie_board_port_reset(port);
} while (--retries);
 
return false;
diff --git a/include/pci_tegra.h b/include/pci_tegra.h
new file mode 100644
index 00..11e92fc26d
--- /dev/null
+++ b/include/pci_tegra.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2018 Toradex, Inc.
+ */
+
+struct tegra_pcie_port;
+
+int tegra_pcie_port_index_of_port(struct tegra_pcie_port *port);
+
+void tegra_pcie_port_reset(struct tegra_pcie_port *port);
-- 
2.14.3

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


[U-Boot] [PATCH v6 5/6] power: as3722: add as3722_ldo_set_voltage signature to header file

2018-05-08 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Just like the already present as3722_sd_set_voltage() add the currently
missing signature of the as3722_ldo_set_voltage() function to its header
file.

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

---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add Simon's reviewed-by.

 include/power/as3722.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/power/as3722.h b/include/power/as3722.h
index ab969809ee..2782857055 100644
--- a/include/power/as3722.h
+++ b/include/power/as3722.h
@@ -25,5 +25,6 @@
 #define AS3722_GPIO_CONTROL_INVERT (1 << 7)
 
 int as3722_sd_set_voltage(struct udevice *dev, unsigned int sd, u8 value);
+int as3722_ldo_set_voltage(struct udevice *dev, unsigned int ldo, u8 value);
 
 #endif /* __POWER_AS3722_H__ */
-- 
2.14.3

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


[U-Boot] [PATCH v6 0/6] fix apalis-tk1 pcie gigabit ethernet operation

2018-05-08 Thread Marcel Ziswiler

This series addresses a gigabit Ethernet reliability issue as observed
on Apalis TK1 related to a PCIe reset timing violation.

This series is available at 
http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next

Changes in v6:
- Use macro AS3722_LDO_CONTROL0_MAX_INDEX instead of the hard-coded
  number 7 in LDO index check as suggested by Jaehoon Chung.
- Updated to latest SPDX style.

Changes in v5:
- Add Stephen's acked-by.
- Updated copyright period to 2016-2018.
- Changed error() to pr_err().
- Added a blank line after declarations as warned by patman.
- Rebased and resend as series so far never got applied!

Changes in v4:
- Revert previously missed (struct tegra_pcie_port *) casts as reported
  by Stephen.

Changes in v3:
- Stick to struct tegra_pcie_port as suggested by Stephen.
- Stick to struct tegra_pcie_port as suggested by Stephen.
- Introduce proper CONFIG_APALIS_TK1_PCIE_EVALBOARD_INIT Kconfig option
  as suggested by Stephen.

Changes in v2:
- Add Simon's reviewed-by.
- New bug fix.
- Incorporate Stephen's review feedback by introducing a
  tegra_pcie_port_index_of_port() function as well as a board-specific
  reset override function.
- Add Simon's reviewed-by.

Marcel Ziswiler (5):
  apalis-tk1: add missing as3722 gpio0 configuration
  power: as3722: fix ldo_get/set_enable for ldo index bigger than 7
  pci: tegra: introduce weak tegra_pcie_board_port_reset() function
  power: as3722: add as3722_ldo_set_voltage signature to header file
  apalis-tk1: fix pcie reset for reliable gigabit ethernet operation

Sanchayan Maity (1):
  configs: apalis-tk1: fix boot failure using ext4 rootfs

 arch/arm/dts/tegra124-apalis.dts   |   6 +-
 board/toradex/apalis-tk1/Kconfig   |   8 +
 board/toradex/apalis-tk1/apalis-tk1.c  | 252 ++---
 drivers/pci/pci_tegra.c|  17 +-
 drivers/power/regulator/as3722_regulator.c |  18 ++-
 include/configs/apalis-tk1.h   |   4 +-
 include/pci_tegra.h|  10 ++
 include/power/as3722.h |   4 +-
 8 files changed, 213 insertions(+), 106 deletions(-)
 create mode 100644 include/pci_tegra.h

-- 
2.14.3

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


[U-Boot] [PATCH v6 3/6] power: as3722: fix ldo_get/set_enable for ldo index bigger than 7

2018-05-08 Thread Marcel Ziswiler
From: Marcel Ziswiler 

Fix ldo_get_enable() and ldo_set_enable() functions for LDOs with an
index > 7. Turns out there are actually two separate AS3722_LDO_CONTROL
registers AS3722_LDO_CONTROL0 and AS3722_LDO_CONTROL1. Actually make use
of both. While at it also actually use the enable parameter of the
ldo_set_enable() function which now truly allows disabling as opposed to
only enabling LDOs.

Signed-off-by: Marcel Ziswiler 

---

Changes in v6:
- Use macro AS3722_LDO_CONTROL0_MAX_INDEX instead of the hard-coded
  number 7 in LDO index check as suggested by Jaehoon Chung.

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- New bug fix.

 drivers/power/regulator/as3722_regulator.c | 18 --
 include/power/as3722.h |  3 ++-
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/power/regulator/as3722_regulator.c 
b/drivers/power/regulator/as3722_regulator.c
index 63f4615398..a0703c9e05 100644
--- a/drivers/power/regulator/as3722_regulator.c
+++ b/drivers/power/regulator/as3722_regulator.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#define AS3722_LDO_CONTROL0_MAX_INDEX 7
+
 static int stepdown_get_value(struct udevice *dev)
 {
return -ENOSYS;
@@ -68,10 +70,16 @@ static int ldo_set_value(struct udevice *dev, int uvolt)
 static int ldo_set_enable(struct udevice *dev, bool enable)
 {
struct udevice *pmic = dev_get_parent(dev);
+   u8 ctrl_reg = AS3722_LDO_CONTROL0;
int ldo = dev->driver_data;
int ret;
 
-   ret = pmic_clrsetbits(pmic, AS3722_LDO_CONTROL, 0, 1 << ldo);
+   if (ldo > AS3722_LDO_CONTROL0_MAX_INDEX) {
+   ctrl_reg = AS3722_LDO_CONTROL1;
+   ldo -= 8;
+   }
+
+   ret = pmic_clrsetbits(pmic, ctrl_reg, !enable << ldo, enable << ldo);
if (ret < 0) {
debug("%s: failed to write LDO control register: %d", __func__,
  ret);
@@ -84,10 +92,16 @@ static int ldo_set_enable(struct udevice *dev, bool enable)
 static int ldo_get_enable(struct udevice *dev)
 {
struct udevice *pmic = dev_get_parent(dev);
+   u8 ctrl_reg = AS3722_LDO_CONTROL0;
int ldo = dev->driver_data;
int ret;
 
-   ret = pmic_reg_read(pmic, AS3722_LDO_CONTROL);
+   if (ldo > AS3722_LDO_CONTROL0_MAX_INDEX) {
+   ctrl_reg = AS3722_LDO_CONTROL1;
+   ldo -= 8;
+   }
+
+   ret = pmic_reg_read(pmic, ctrl_reg);
if (ret < 0) {
debug("%s: failed to read SD control register: %d", __func__,
  ret);
diff --git a/include/power/as3722.h b/include/power/as3722.h
index 9f045d5ab6..ab969809ee 100644
--- a/include/power/as3722.h
+++ b/include/power/as3722.h
@@ -13,7 +13,8 @@
 #define AS3722_SD_VOLTAGE(n) (0x00 + (n))
 #define AS3722_LDO_VOLTAGE(n) (0x10 + (n))
 #define AS3722_SD_CONTROL 0x4d
-#define AS3722_LDO_CONTROL 0x4e
+#define AS3722_LDO_CONTROL0 0x4e
+#define AS3722_LDO_CONTROL1 0x4f
 #define AS3722_ASIC_ID1 0x90
 #define AS3722_ASIC_ID2 0x91
 
-- 
2.14.3

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


[U-Boot] [PATCH] Licenses/README: Update some style and add explicit license to the document

2018-05-08 Thread Tom Rini
- Add an SPDX license tag to the file, saying it's GPL-2.0.
- From the Linux Kernel v4.17-rc4, import the "License identifier
  syntax" section as-is from Documentation/process/license-rules.rst
  and then change it to be clearer about examples from the Linux Kernel
  vs examples found in U-Boot, and when we're talking about U-Boot.

Signed-off-by: Tom Rini 
---
 Licenses/README | 102 ++--
 1 file changed, 92 insertions(+), 10 deletions(-)

diff --git a/Licenses/README b/Licenses/README
index 5ad921ddfc9a..486e18d0d804 100644
--- a/Licenses/README
+++ b/Licenses/README
@@ -1,3 +1,5 @@
+SPDX-License-Identifier: GPL-2.0
+
   U-Boot is Free Software.  It is copyrighted by Wolfgang Denk and
 many others who contributed code (see the actual source code and the
 git commit messages for details).  You can redistribute U-Boot and/or
@@ -31,27 +33,107 @@ information, ...) which makes automatic processing a 
nightmare.
 
 To make this easier, such license headers in the source files will be
 replaced with a single line reference to Unique License Identifiers
-as defined by the Linux Foundation's SPDX project [1].  For example,
-in a source file the full "GPL v2.0 or later" header text will be
-replaced by a single line:
-
-   SPDX-License-Identifier:GPL-2.0+
-
-Ideally, the license terms of all files in the source tree should be
-defined by such License Identifiers; in no case a file can contain
-more than one such License Identifier list.
+as defined by the Linux Foundation's SPDX project [1].
 
 If a "SPDX-License-Identifier:" line references more than one Unique
 License Identifier, then this means that the respective file can be
 used under the terms of either of these licenses, i. e. with
 
-   SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+   SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
 
 you can choose between GPL-2.0+ and BSD-3-Clause licensing.
 
 We use the SPDX Unique License Identifiers here; these are available
 at [2].
 
+License identifier syntax
+-
+
+1. Placement:
+
+   The SPDX license identifier in U-Boot files shall be added at the first
+   possible line in a file which can contain a comment.  For the majority
+   or files this is the first line, except for scripts which require the
+   '#!PATH_TO_INTERPRETER' in the first line.  For those scripts the SPDX
+   identifier goes into the second line.
+
+|
+
+2. Style:
+
+   The SPDX license identifier is added in form of a comment.  The comment
+   style depends on the file type::
+
+  C source:// SPDX-License-Identifier: 
+  C header:/* SPDX-License-Identifier:  */
+  ASM: /* SPDX-License-Identifier:  */
+  scripts: # SPDX-License-Identifier: 
+  .rst:.. SPDX-License-Identifier: 
+  .dts{i}: // SPDX-License-Identifier: 
+
+   If a specific tool cannot handle the standard comment style, then the
+   appropriate comment mechanism which the tool accepts shall be used. This
+   is the reason for having the "/\* \*/" style comment in C header
+   files. There was build breakage observed with generated .lds files where
+   'ld' failed to parse the C++ comment. This has been fixed by now, but
+   there are still older assembler tools which cannot handle C++ style
+   comments.
+
+|
+
+3. Syntax:
+
+   A  is either an SPDX short form license
+   identifier found on the SPDX License List, or the combination of two
+   SPDX short form license identifiers separated by "WITH" when a license
+   exception applies. When multiple licenses apply, an expression consists
+   of keywords "AND", "OR" separating sub-expressions and surrounded by
+   "(", ")" .
+
+   License identifiers for licenses like [L]GPL with the 'or later' option
+   are constructed by using a "+" for indicating the 'or later' option.::
+
+  // SPDX-License-Identifier: GPL-2.0+
+  // SPDX-License-Identifier: LGPL-2.1+
+
+   WITH should be used when there is a modifier to a license needed.
+   For example, the linux kernel UAPI files use the expression::
+
+  // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
+  // SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note
+
+   Other examples using WITH exceptions found in the linux kernel are::
+
+  // SPDX-License-Identifier: GPL-2.0 WITH mif-exception
+  // SPDX-License-Identifier: GPL-2.0+ WITH GCC-exception-2.0
+
+   Exceptions can only be used with particular License identifiers. The
+   valid License identifiers are listed in the tags of the exception text
+   file.
+
+   OR should be used if the file is dual licensed and only one license is
+   to be selected.  For example, some dtsi files are available under dual
+   licenses::
+
+  // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+
+   Examples from U-Boot for license expressions in dual licensed files::
+
+  // SPDX-License-Identifier: GPL-2.0 OR MIT
+  

[U-Boot] [PATCH v6 6/6] apalis-tk1: fix pcie reset for reliable gigabit ethernet operation

2018-05-08 Thread Marcel Ziswiler
From: Marcel Ziswiler 

It turns out that the current PCIe reset implementation in the PCIe
board init function is not quite working reliably due to PCIe reset
timing violations. Fix this by overriding the
tegra_pcie_board_port_reset() function.

Also allow optionally bringing up the PCIe switch as found on the Apalis
Evaluation board. Note however that the Apalis PCIe port is also left
disabled in the device tree by default.

Signed-off-by: Marcel Ziswiler 

---

Changes in v6: None
Changes in v5:
- Updated copyright period to 2016-2018.
- Changed error() to pr_err().
- Added a blank line after declarations as warned by patman.
- Rebased and resend as series so far never got applied!

Changes in v4: None
Changes in v3:
- Stick to struct tegra_pcie_port as suggested by Stephen.
- Introduce proper CONFIG_APALIS_TK1_PCIE_EVALBOARD_INIT Kconfig option
  as suggested by Stephen.

Changes in v2: None

 board/toradex/apalis-tk1/Kconfig  |   8 ++
 board/toradex/apalis-tk1/apalis-tk1.c | 252 +-
 2 files changed, 165 insertions(+), 95 deletions(-)

diff --git a/board/toradex/apalis-tk1/Kconfig b/board/toradex/apalis-tk1/Kconfig
index 05407ad2d5..159b8fb19a 100644
--- a/board/toradex/apalis-tk1/Kconfig
+++ b/board/toradex/apalis-tk1/Kconfig
@@ -25,6 +25,14 @@ config TDX_CFG_BLOCK_PART
 config TDX_CFG_BLOCK_OFFSET
default "-512"
 
+config APALIS_TK1_PCIE_EVALBOARD_INIT
+   bool "Apalis Evaluation Board PCIe Initialisation"
+   help
+ Bring up the Apalis PCIe port with the PCIe switch as found on the
+ Apalis Evaluation board. Note that by default the PCIe port is also
+ left disabled in the device tree which needs changing as well for this
+ to actually work.
+
 source "board/toradex/common/Kconfig"
 
 endif
diff --git a/board/toradex/apalis-tk1/apalis-tk1.c 
b/board/toradex/apalis-tk1/apalis-tk1.c
index 6bb2acca16..d6a736d8aa 100644
--- a/board/toradex/apalis-tk1/apalis-tk1.c
+++ b/board/toradex/apalis-tk1/apalis-tk1.c
@@ -1,20 +1,29 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (c) 2016 Toradex, Inc.
+ * Copyright (c) 2016-2018 Toradex, Inc.
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "../common/tdx-common.h"
 #include "pinmux-config-apalis-tk1.h"
 
-#define LAN_RESET_N TEGRA_GPIO(S, 2)
+#define LAN_DEV_OFF_N  TEGRA_GPIO(O, 6)
+#define LAN_RESET_NTEGRA_GPIO(S, 2)
+#define LAN_WAKE_N TEGRA_GPIO(O, 5)
+#ifdef CONFIG_APALIS_TK1_PCIE_EVALBOARD_INIT
+#define PEX_PERST_NTEGRA_GPIO(DD, 1) /* Apalis GPIO7 */
+#define RESET_MOCI_CTRLTEGRA_GPIO(U, 4)
+#endif /* CONFIG_APALIS_TK1_PCIE_EVALBOARD_INIT */
 
 int arch_misc_init(void)
 {
@@ -58,123 +67,176 @@ void pinmux_init(void)
 }
 
 #ifdef CONFIG_PCI_TEGRA
-int tegra_pcie_board_init(void)
+/* TODO: Convert to driver model */
+static int as3722_sd_enable(struct udevice *pmic, unsigned int sd)
 {
-   /* TODO: Convert to driver model
-   struct udevice *pmic;
int err;
 
-   err = as3722_init();
+   if (sd > 6)
+   return -EINVAL;
+
+   err = pmic_clrsetbits(pmic, AS3722_SD_CONTROL, 0, 1 << sd);
if (err) {
-   error("failed to initialize AS3722 PMIC: %d\n", err);
+   pr_err("failed to update SD control register: %d", err);
return err;
}
 
-   err = as3722_sd_enable(pmic, 4);
-   if (err < 0) {
-   error("failed to enable SD4: %d\n", err);
-   return err;
-   }
+   return 0;
+}
 
-   err = as3722_sd_set_voltage(pmic, 4, 0x24);
-   if (err < 0) {
-   error("failed to set SD4 voltage: %d\n", err);
-   return err;
-   }
+/* TODO: Convert to driver model */
+static int as3722_ldo_enable(struct udevice *pmic, unsigned int ldo)
+{
+   int err;
+   u8 ctrl_reg = AS3722_LDO_CONTROL0;
 
-   err = as3722_gpio_configure(pmic, 1, AS3722_GPIO_OUTPUT_VDDH |
-AS3722_GPIO_INVERT);
-   if (err < 0) {
-   error("failed to configure GPIO#1 as output: %d\n", err);
-   return err;
-   }
+   if (ldo > 11)
+   return -EINVAL;
 
-   err = as3722_gpio_direction_output(pmic, 2, 1);
-   if (err < 0) {
-   error("failed to set GPIO#2 high: %d\n", err);
-   return err;
+   if (ldo > 7) {
+   ctrl_reg = AS3722_LDO_CONTROL1;
+   ldo -= 8;
}
-   */
 
-   /* Reset I210 Gigabit Ethernet Controller */
-   gpio_request(LAN_RESET_N, "LAN_RESET_N");
-   gpio_direction_output(LAN_RESET_N, 0);
-
-   /*
-* Make sure we don't get any back feeding from LAN_WAKE_N resp.
-* DEV_OFF_N
-*/
-   gpio_request(TEGRA_GPIO(O, 5), "LAN_WAKE_N");
-   gpio_direction_output(TEGRA_GPIO(O, 5), 

[U-Boot] [PATCH v6 1/6] configs: apalis-tk1: fix boot failure using ext4 rootfs

2018-05-08 Thread Marcel Ziswiler
From: Sanchayan Maity 

Trying to boot from an ext4 rootfs fails due to us defaulting to ext3.
While the downstream T20/T30 L4T kernel has issues with ext4 later TK1
L4T should work just fine with it. Hence enable ext4 for sdboot and
usbboot on TK1.

Signed-off-by: Sanchayan Maity 
Acked-by: Marcel Ziswiler 

---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/configs/apalis-tk1.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/apalis-tk1.h b/include/configs/apalis-tk1.h
index fe8168458f..667d084611 100644
--- a/include/configs/apalis-tk1.h
+++ b/include/configs/apalis-tk1.h
@@ -80,7 +80,7 @@
"&& setenv dtbparam ${fdt_addr_r}\0"
 
 #define SD_BOOTCMD \
-   "sdargs=ip=off root=/dev/mmcblk1p2 rw rootfstype=ext3 rootwait\0" \
+   "sdargs=ip=off root=/dev/mmcblk1p2 rw rootfstype=ext4 rootwait\0" \
"sdboot=run setup; setenv bootargs ${defargs} ${sdargs} ${setupargs} " \
"${vidargs}; echo Booting from SD card in 8bit slot...; " \
"run sddtbload; load mmc 1:1 ${kernel_addr_r} " \
@@ -91,7 +91,7 @@
"&& setenv dtbparam ${fdt_addr_r}\0"
 
 #define USB_BOOTCMD \
-   "usbargs=ip=off root=/dev/sda2 rw rootfstype=ext3 rootwait\0" \
+   "usbargs=ip=off root=/dev/sda2 rw rootfstype=ext4 rootwait\0" \
"usbboot=run setup; setenv bootargs ${defargs} ${setupargs} " \
"${usbargs} ${vidargs}; echo Booting from USB stick...; " \
"usb start && run usbdtbload; load usb 0:1 ${kernel_addr_r} " \
-- 
2.14.3

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


Re: [U-Boot] [RFC PATCH v2 11/20] fastboot: net: Change 'continue' so it matches USB fastboot

2018-05-08 Thread Joe Hershberger
On Tue, May 8, 2018 at 4:20 AM, Alex Kiernan  wrote:
> On Thu, May 3, 2018 at 9:58 PM Joe Hershberger 
> wrote:
>
>> On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan 
> wrote:
>> > Change the behaviour of 'continue' so that we simply exit the fastboot
>> > server and leave the caller to decide what to do next. This matches
>> > the USB fastboot behaviour.
>
>> Good, I was considering recommending this approach.
>
>> Acked-by: Joe Hershberger 
>
>> >
>> > Signed-off-by: Alex Kiernan 
>> > ---
>> >
>> > Changes in v2: None
>> >
>> >  net/fastboot.c | 13 +++--
>> >  1 file changed, 3 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/net/fastboot.c b/net/fastboot.c
>> > index cd09ada..ed13890 100644
>> > --- a/net/fastboot.c
>> > +++ b/net/fastboot.c
>> > @@ -218,8 +218,6 @@ static void fastboot_send(struct fastboot_header
> fb_header, char *fastboot_data,
>> > if (!strncmp("OKAY", response, 4)) {
>> > if (!strcmp("boot", cmd_string)) {
>> > boot_downloaded_image();
>> > -   } else if (!strcmp("continue", cmd_string)) {
>> > -   run_command(env_get("bootcmd"), CMD_FLAG_ENV);
>> > } else if (!strncmp("reboot", cmd_string, 6)) {
>> > /* Matches reboot or reboot-bootloader */
>> > do_reset(NULL, 0, 0, NULL);
>> > @@ -313,20 +311,15 @@ static void fb_erase(char *response)
>> >  #endif
>> >
>> >  /**
>> > - * Continues normal boot process by running "bootcmd". Writes
>> > + * Continues normal boot process by exiting fastboot server. Writes
>> >   * to response.
>> >   *
>> >   * @param repsonsePointer to fastboot response buffer
>> >   */
>> >  static void fb_continue(char *response)
>> >  {
>> > -   char *bootcmd;
>> > -
>> > -   bootcmd = env_get("bootcmd");
>> > -   if (bootcmd)
>> > -   fastboot_okay(NULL, response);
>> > -   else
>> > -   fastboot_fail("bootcmd not set", response);
>> > +   net_set_state(NETLOOP_SUCCESS);
>> > +   fastboot_okay(NULL, response);
>> >  }
>> >
>
> I'm struggling with this returning the final ACK to the client correctly.
> If I add something like mdelay(5) before exiting the server, then I get the
> final ACK, without that, I never see it hit the network, even though I can
> see it traversing all the layers of the net code if I wind up the debug
> (and of course it makes it out if I wind up the debug, presumably as it
> then goes much slower).
>
> Wild hand wavey speculation... it's getting lost in something like a DMA
> buffer in the network driver which gets torn down before it makes it onto
> the wire? This is using the TI CPSW on an am335x.

Sounds like a reasonable theory.

The eth driver for that board probably needs to check for the TX
channel to be in a quiescent state in the davinci_eth_close() function
before tearing it down.

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


Re: [U-Boot] [PATCH v2 1/2] common: Add support for Android DT image

2018-05-08 Thread Alex Deymo
Le jeu. 19 avr. 2018 à 22:52, Sam Protsenko  a
écrit :

> Android documentation recommends new image format for storing DTB/DTBO
> files: [1]. To support that format, two things should be done:
>
> 1. Add dt_table.h file from Android (BSD-3 relicensed version): [2].
>This header defines structures and constants that we need to work
>with that DT image format.
>
>Changes:
> - re-licensed from Apache to BSD-3
>
I'm not familiar with how you handle these re-licensing so I can't say
anything about that.


> - removed functions declarations
>
You also removed DT_TABLE_DEFAULT_VERSION but left
DT_TABLE_DEFAULT_PAGE_SIZE, was that intentional?

- change the coding style to kernel (make checkpatch happy)
>
> 2. Add helper functions for Android DTB/DTBO format. In
>image-android-dt.* files you can find helper functions to work with
>Android DT image format, such us routines for:
> - printing the dump of image structure
> - getting the address and size of desired dtb/dtbo file
>
> [1] https://source.android.com/devices/architecture/dto/partitions
> [2]
> https://android.googlesource.com/platform/system/libufdt/+/58a7582180f477032cd6c74f8d9afad0038e74c3/utils/src/dt_table.h
>
> Signed-off-by: Sam Protsenko 
> ---
>  common/image-android-dt.c  | 157 +
>  include/dt_table.h |  46 +++
>  include/image-android-dt.h |  21 +
>  3 files changed, 224 insertions(+)
>  create mode 100644 common/image-android-dt.c
>  create mode 100644 include/dt_table.h
>  create mode 100644 include/image-android-dt.h
>
> diff --git a/common/image-android-dt.c b/common/image-android-dt.c
> new file mode 100644
> index 00..9b7683faab
> --- /dev/null
> +++ b/common/image-android-dt.c
> @@ -0,0 +1,157 @@
> +/*
> + * (C) Copyright 2018 Linaro Ltd.
> + * Sam Protsenko 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * Check if image header is correct.
> + *
> + * @param hdr_addr Start address of DT image
> + * @return true if header is correct or false if header is incorrect
> + */
> +bool android_dt_check_header(ulong hdr_addr)
> +{
> +   const struct dt_table_header *hdr;
> +   u32 magic;
> +
> +   hdr = map_sysmem(hdr_addr, sizeof(*hdr));
> +   magic = fdt32_to_cpu(hdr->magic);
> +   unmap_sysmem(hdr);
> +
> +   return magic == DT_TABLE_MAGIC;
> +}
> +
> +/**
> + * Get the address of FDT (dtb or dtbo) in memory by its index in image.
> + *
> + * @param hdr_addr Start address of DT image
> + * @param index Index of desired FDT in image (starting from 0)
> + * @param[out] addr If not NULL, will contain address to specified FDT
> + * @param[out] size If not NULL, will contain size of specified FDT
> + *
> + * @return true on success or false on error
> + */
> +bool android_dt_get_fdt_by_index(ulong hdr_addr, u32 index, ulong *addr,
> +u32 *size)
> +{
> +   const struct dt_table_header *hdr;
> +   const struct dt_table_entry *e;
> +   u32 entry_count, entries_offset, entry_size;
> +   ulong e_addr;
> +   u32 dt_offset, dt_size;
> +
> +   hdr = map_sysmem(hdr_addr, sizeof(*hdr));
> +   entry_count = fdt32_to_cpu(hdr->dt_entry_count);
> +   entries_offset = fdt32_to_cpu(hdr->dt_entries_offset);
> +   entry_size = fdt32_to_cpu(hdr->dt_entry_size);
> +   unmap_sysmem(hdr);
> +
> +   if (index > entry_count) {
> +   printf("Error: index > dt_entry_count (%u > %u)\n", index,
> +  entry_count);
> +   return false;
> +   }
>
This function assumes the image is valid in several places, but here you
could also check that the relative offset you are going to load falls
within the the fdt32_to_cpu(hdr->total_size).

+
> +   e_addr = hdr_addr + entries_offset + index * entry_size;
> +   e = map_sysmem(e_addr, sizeof(*e));
> +   dt_offset = fdt32_to_cpu(e->dt_offset);
> +   dt_size = fdt32_to_cpu(e->dt_size);
> +   unmap_sysmem(e);
> +
> +   if (addr)
> +   *addr = hdr_addr + dt_offset;
> +   if (size)
> +   *size = dt_size;
> +
> +   return true;
> +}
> +
> +#if !defined(CONFIG_SPL_BUILD)
> +static void android_dt_print_fdt_info(const struct fdt_header *fdt)
> +{
> +   u32 fdt_size;
> +   int root_node_off;
> +   const char *compatible = NULL;
> +
> +   fdt_size = fdt_totalsize(fdt);
> +   root_node_off = fdt_path_offset(fdt, "/");
> +   if (root_node_off < 0) {
> +   printf("Error: Root node not found\n");
> +   } else {
> +   compatible = fdt_getprop(fdt, root_node_off, "compatible",
> +NULL);
> +   }
> +
> +   printf("   (FDT)size = %d\n", fdt_size);
> +   printf(" 

Re: [U-Boot] [PATCH v2 2/2] cmd: Add dtimg command

2018-05-08 Thread Alex Deymo
Le jeu. 19 avr. 2018 à 22:52, Sam Protsenko  a
écrit :

> dtimg command allows user to work with Android DTB/DTBO image format.
> Such as, getting the address of desired DTB/DTBO file, printing the dump
> of the image in U-Boot shell, etc.
>
> This command is needed to provide Android boot with new Android DT image
> format further.
>
> Signed-off-by: Sam Protsenko 
> ---
>  cmd/Kconfig |   8 +++
>  cmd/Makefile|   1 +
>  cmd/dtimg.c | 142 
>  common/Makefile |   4 ++
>  4 files changed, 155 insertions(+)
>  create mode 100644 cmd/dtimg.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index bc1d2f31c0..68f3cc7b48 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -256,6 +256,14 @@ config CMD_BOOTMENU
> help
>   Add an ANSI terminal boot menu command.
>
> +config CMD_DTIMG
> +   bool "dtimg"
> +   help
> + Android DTB/DTBO image manipulation commands. Read dtb/dtbo
> files from
> + image into RAM, dump image structure information, etc. Those
> dtb/dtbo
> + files should be merged in one dtb further, which needs to be
> passed to
> + the kernel, as part of a boot process.
> +
>  config CMD_ELF
> bool "bootelf, bootvx"
> default y
> diff --git a/cmd/Makefile b/cmd/Makefile
> index c4269ac8ac..1cc2e74e9e 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -43,6 +43,7 @@ ifdef CONFIG_POST
>  obj-$(CONFIG_CMD_DIAG) += diag.o
>  endif
>  obj-$(CONFIG_CMD_DISPLAY) += display.o
> +obj-$(CONFIG_CMD_DTIMG) += dtimg.o
>  obj-$(CONFIG_CMD_ECHO) += echo.o
>  obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
>  obj-$(CONFIG_CMD_EEPROM) += eeprom.o
> diff --git a/cmd/dtimg.c b/cmd/dtimg.c
> new file mode 100644
> index 00..5295a341ad
> --- /dev/null
> +++ b/cmd/dtimg.c
> @@ -0,0 +1,142 @@
> +/*
> + * (C) Copyright 2018 Linaro Ltd.
> + * Sam Protsenko 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +
> +enum cmd_dtimg_info {
> +   CMD_DTIMG_START = 0,
> +   CMD_DTIMG_SIZE,
> +};
> +
> +static int do_dtimg_dump(cmd_tbl_t *cmdtp, int flag, int argc,
> +char * const argv[])
> +{
> +   char *endp;
> +   ulong hdr_addr;
> +
> +   if (argc != 2)
> +   return CMD_RET_USAGE;
> +
> +   hdr_addr = simple_strtoul(argv[1], , 16);
> +   if (*endp != '\0') {
> +   printf("Error: Wrong image address\n");
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   if (!android_dt_check_header(hdr_addr)) {
> +   printf("Error: DT image header is incorrect\n");
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   android_dt_print_contents(hdr_addr);
> +
> +   return CMD_RET_SUCCESS;
> +}
> +
> +static int dtimg_get_fdt(int argc, char * const argv[], enum
> cmd_dtimg_info cmd)
> +{
> +   ulong hdr_addr;
> +   u32 index;
> +   char *endp;
> +   ulong fdt_addr;
> +   u32 fdt_size;
> +   char buf[65];
> +
> +   if (argc != 4)
> +   return CMD_RET_USAGE;
> +
> +   hdr_addr = simple_strtoul(argv[1], , 16);
> +   if (*endp != '\0') {
> +   printf("Error: Wrong image address\n");
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   if (!android_dt_check_header(hdr_addr)) {
> +   printf("Error: DT image header is incorrect\n");
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   index = simple_strtoul(argv[2], , 0);
> +   if (*endp != '\0') {
> +   printf("Error: Wrong index\n");
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   if (!android_dt_get_fdt_by_index(hdr_addr, index, _addr,
> _size))
> +   return CMD_RET_FAILURE;
> +
> +   switch (cmd) {
> +   case CMD_DTIMG_START:
> +   snprintf(buf, sizeof(buf), "%lx", fdt_addr);
> +   break;
> +   case CMD_DTIMG_SIZE:
> +   snprintf(buf, sizeof(buf), "%x", fdt_size);
> +   break;
> +   default:
> +   printf("Error: Unknown cmd_dtimg_info value: %d\n", cmd);
> +   return CMD_RET_FAILURE;
> +   }
> +
> +   env_set(argv[3], buf);
> +
> +   return CMD_RET_SUCCESS;
> +}
> +
> +static int do_dtimg_start(cmd_tbl_t *cmdtp, int flag, int argc,
> + char * const argv[])
> +{
> +   return dtimg_get_fdt(argc, argv, CMD_DTIMG_START);
> +}
> +
> +static int do_dtimg_size(cmd_tbl_t *cmdtp, int flag, int argc,
> +char * const argv[])
> +{
> +   return dtimg_get_fdt(argc, argv, CMD_DTIMG_SIZE);
> +}
> +
> +static cmd_tbl_t cmd_dtimg_sub[] = {
> +   U_BOOT_CMD_MKENT(dump, 2, 0, do_dtimg_dump, "", ""),
> +   U_BOOT_CMD_MKENT(start, 4, 0, do_dtimg_start, "", ""),
> +   U_BOOT_CMD_MKENT(size, 4, 0, do_dtimg_size, "", ""),
> +};
> +
> +static int 

Re: [U-Boot] [RFC PATCH v2 07/20] net: fastboot: Merge AOSP UDP fastboot

2018-05-08 Thread Joe Hershberger
On Tue, May 8, 2018 at 4:11 AM, Alex Kiernan  wrote:
> On Thu, May 3, 2018 at 9:39 PM Joe Hershberger 
> wrote:
>
>> On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan 
> wrote:
>
> 
>
>> > +/**
>> > + * Constructs and sends a packet in response to received fastboot
> packet
>> > + *
>> > + * @param fb_headerHeader for response packet
>> > + * @param fastboot_dataPointer to received fastboot data
>> > + * @param fastboot_data_lenLength of received fastboot data
>> > + * @param retransmit   Nonzero if sending last sent packet
>> > + */
>> > +static void fastboot_send(struct fastboot_header fb_header, char
> *fastboot_data,
>> > + unsigned int fastboot_data_len, uchar
> retransmit)
>> > +{
>> > +   uchar *packet;
>> > +   uchar *packet_base;
>> > +   int len = 0;
>> > +   const char *error_msg = "An error occurred.";
>> > +   short tmp;
>> > +   struct fastboot_header fb_response_header = fb_header;
>> > +   char response[FASTBOOT_RESPONSE_LEN] = {0};
>> > +   /*
>> > +*  We will always be sending some sort of packet, so
>> > +*  cobble together the packet headers now.
>> > +*/
>> > +   packet = net_tx_packet + net_eth_hdr_size() + IP_UDP_HDR_SIZE;
>> > +   packet_base = packet;
>> > +
>> > +   /* Resend last packet */
>> > +   if (retransmit) {
>> > +   memcpy(packet, last_packet, last_packet_len);
>> > +   net_send_udp_packet(net_server_ethaddr,
> fastboot_remote_ip,
>> > +   fastboot_remote_port,
> fastboot_our_port,
>> > +   last_packet_len);
>> > +   return;
>> > +   }
>> > +
>> > +   fb_response_header.seq = htons(fb_response_header.seq);
>> > +   memcpy(packet, _response_header, sizeof(fb_response_header));
>> > +   packet += sizeof(fb_response_header);
>> > +
>> > +   switch (fb_header.id) {
>> > +   case FASTBOOT_QUERY:
>> > +   tmp = htons(fb_sequence_number);
>> > +   memcpy(packet, , sizeof(tmp));
>> > +   packet += sizeof(tmp);
>> > +   break;
>> > +   case FASTBOOT_INIT:
>> > +   tmp = htons(fb_udp_version);
>> > +   memcpy(packet, , sizeof(tmp));
>> > +   packet += sizeof(tmp);
>> > +   tmp = htons(fb_packet_size);
>> > +   memcpy(packet, , sizeof(tmp));
>> > +   packet += sizeof(tmp);
>> > +   break;
>> > +   case FASTBOOT_ERROR:
>> > +   memcpy(packet, error_msg, strlen(error_msg));
>> > +   packet += strlen(error_msg);
>> > +   break;
>> > +   case FASTBOOT_FASTBOOT:
>> > +   if (!cmd_string) {
>> > +   /* Parse command and send ack */
>> > +   cmd_parameter = fastboot_data;
>
>> This seems unnecessary. There are only 4 cases handled, and of them
>> only download seems to be a command that happens more than once. And
>> in download, the first past through this parameter is saved internally
>> as bytes_expected.
>
>> > +   cmd_string = strsep(_parameter, ":");
>> > +   cmd_string = strdup(cmd_string);
>> > +   if (cmd_parameter)
>> > +   cmd_parameter = strdup(cmd_parameter);
>> > +   } else if (!strcmp("getvar", cmd_string)) {
>> > +   fb_getvar(response);
>
>> Seems like you should simply pass the "fastboot_data" as a parameter
>> here rather than using a global.
>
> I'm completely pulling this apart in a later patch. I wonder if I should
> really be folding some of these back into this - I was trying to maintain a
> clear line to the AOSP code which this came from.

What value do we get from that? Is there a merge technique you are
trying to enable to make pulling in future AOSP changes easier? Are
you trying to isolate your changes from AOSP for attribution purposes?
So far I'm of the opinion that the fixes to the existing code should
simply be there in the originating patch. Feel free to convince me
otherwise.

>> > +/**
>> > + * Copies image data from fastboot_data to CONFIG_FASTBOOT_BUF_ADDR.
>> > + * Writes to response.
>> > + *
>> > + * @param fastboot_dataPointer to received fastboot data
>> > + * @param fastboot_data_lenLength of received fastboot data
>> > + * @param repsonse Pointer to fastboot response buffer
>> > + */
>> > +static void fb_download(char *fastboot_data, unsigned int
> fastboot_data_len,
>> > +   char *response)
>> > +{
>> > +   char *tmp;
>> > +
>> > +   if (bytes_expected == 0) {
>> > +   if (!cmd_parameter) {
>> > +   write_fb_response("FAIL", "Expected command
> parameter",
>> > +   

[U-Boot] [PATCH] net: Protect net_state from reentrant net_loop()

2018-05-08 Thread Leonid Iziumtsev
Global variable "net_state" is used in net_loop() state-machine.
But it happens that some times the net_loop() can be called
multiple times in the same call stack. For example when the
netconsole is enabled and we print the message while some other
net protocol is in action. Netconsole will overwrite the "net_state"
and that will break the logic for earlier started protocol.

To protect the state save and restore "net_state" variable each
time when we enter and exit net_loop().

Signed-off-by: Leonid Iziumtsev 
---
 net/net.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/net.c b/net/net.c
index c3adba2..cb34c3b 100644
--- a/net/net.c
+++ b/net/net.c
@@ -417,6 +417,7 @@ void net_init(void)
 int net_loop(enum proto_t protocol)
 {
int ret = -EINVAL;
+   enum net_loop_state prev_net_state = net_state;

net_restarted = 0;
net_dev_exists = 0;
@@ -454,6 +455,7 @@ restart:
case 1:
/* network not configured */
eth_halt();
+   net_set_state(prev_net_state);
return -ENODEV;

case 2:
@@ -674,6 +676,7 @@ done:
net_set_udp_handler(NULL);
net_set_icmp_handler(NULL);
 #endif
+   net_set_state(prev_net_state);
return ret;
 }

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


Re: [U-Boot] [linux-sunxi] Re: [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

2018-05-08 Thread Andre Przywara
Hi,

On 08/05/18 11:34, Jagan Teki wrote:
> On Sun, Apr 1, 2018 at 8:11 AM, Chen-Yu Tsai  wrote:
>> On Sun, Apr 1, 2018 at 9:28 AM, André Przywara  
>> wrote:
>>> On 30/03/18 05:25, Chen-Yu Tsai wrote:
>>>
>>> 
> OK. So meanwhile I have something almost(TM) working:
> - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of
> the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx,
> CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually
> (I did it the U-Boot way, not pulling in any super-fancy Linux code).
> Porting this over to H3/H5 and other SoCs should be trivial: copy/paste
> for now. We can look at how to unify this later.
> - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is
> also not too bad, but I seem to miss a bit in here, as it times out.
> Will debug this tonight.
> - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking
> the single bit in :-(
>
> That looks tight to still get into this merge window, though, at least
> if we follow the usual process.

 You could post an initial version during the merge window, and refine it
 in the following two weeks? AFAIK the rules allow for it to be merged for
 the coming release, instead of the next.
>>>
>>> Is that so? I had the impression that this was tightened in the last few
>>> releases, so no features would be allowed beyond the merge window
>>> anymore. I will try to send something ASAP, but ...
>>>
 Curiously, U-boot repositories don't have -next branches. Is that a
 maintainer preference? Having one would help developers in a way as
 to not have to hunt down prerequisites and try to figure out whether
 they have passed review and will be merged or not, and also avoid
 conflicts with other to-be-queued patches. I know this takes extra
 effort from the maintainer to possibly rebase or manage conflicts
 after a new merge window has opened, as I personally manage sunxi-next
 for the Linux kernel to serve as sort of an integration branch for
 others. I'm asking is it possible to have -next, even just for sunxi.

>
> Keep you posted.

 I'm interested. IMHO we don't need full blown drivers like in Linux.
 We should be able to get away with selectively supporting only the
 resources needed for the peripherals supported / actively used in U-boot.
 This goes for clocks, resets, pinctrl, regulators, etc..
>>>
>>> So I have something(TM) working now. This is a bit like a can of worms:
>>> - As mentioned above, we need a UCLASS_CLK driver. This is pretty
>>> straightforward, one driver per SoC, then something like:
>>> int sunxi_clk_enable(clk)
>>> {
>>> switch (clk->id) {
>>> case CLK_MMC0:
>>> addr = priv->base + 0x88;
>>> setbits_le32(clk_base, BIT(31));
>>> (plus get_rate/set_rate)
>>> As you guessed, we just list the clocks we need, in the moment this is
>>> UART and MMC. Adding new clocks is easy, other SoCs can be copy
>>> for now, we might find a clever way of code sharing later.
>>> One nasty property is the marriage of RESET and CLK in the sunxi-ng
>>> clock binding. So we also need a DM reset driver. I need to wrap my head
>>> around how to instantiate those at the same time from only one compatible.
>>
>> We could look at how the DM gpio driver currently does it: The compatible
>> matches the driver directly, and the DM bind function creates many child
>> devices using platform data and binds it to the same driver. The device
>> node is also assigned to the same one. AFAIK you have to figure out how
>> to lookup a different driver by name for the child device, e.g. a reset
>> driver to bind to the child device of the clk device.
>>
>> In addition, Philipp from Theobroma Systems posted a series some time ago
>> for sunxi DM conversion, which included some patches that involved creating
>> multiple uclass devices for the same device node.
>>
>>>
>>> - Also I realised two days ago that we need a DM pinctrl driver. As this
>>> was on my list anyway, I just bit the bullet. Eventually this isn't as
>>> bad as it sounds, as I resorted to the "pinmux" property to give me the
>>> mux value, so don't need the huge table Linux uses.
>>> But: a similar problem as above, as we need to marry this to the already
>>> existing DM_GPIO driver, because they share a DT node.
>>
>> Same as the above I guess? And having the pinctrl driver as the base device
>> might work out better. It looks like we won't have gpio/pinctrl exclusivity
>> like we do in Linux, so people should try to avoid shooting themselves in
>> the foot. We could try denying requests based on whether the pinmux value
>> in the register is not the default GPIO / disconnected value.
>>
>>>
>>> So the current status is:
>>> - UCLASS_CLK works and looks fairly reasonable.
>>> - 

[U-Boot] [PATCH] lib/Kconfig: Mark OF_LIBFDT_OVERLAY as depending on OF_LIBFDT

2018-05-08 Thread Tom Rini
The overlay code is only useful when OF_LIBFDT is set, so mark it as
depending on that first.

Signed-off-by: Tom Rini 
---
 lib/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/Kconfig b/lib/Kconfig
index 3fa1731a4951..1590f7afa402 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -286,6 +286,7 @@ config OF_LIBFDT
 
 config OF_LIBFDT_OVERLAY
bool "Enable the FDT library overlay support"
+   depends on OF_LIBFDT
default y if ARCH_OMAP2PLUS || ARCH_KEYSTONE
help
  This enables the FDT library (libfdt) overlay support.
-- 
2.7.4

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


  1   2   >