Re: [PATCH 1/1] mtd: cfi_flash: use __raw_writeq(), __raw_readq()

2020-06-08 Thread Stefan Roese

On 07.06.20 20:42, Heinrich Schuchardt wrote:

On 6/6/20 11:13 PM, Heinrich Schuchardt wrote:

Functions __raw_writeq(), __raw_readq() are available for all
architectures. So let's use them.


The major architectures have these but not m68k, microblaze, nd32,
nios2, powerpc, sh, xtenza.


Just checking to be clear: This patch breaks compiling on these
platforms and you are withdrawing it (for now)?

Thanks,
Stefan



Signed-off-by: Heinrich Schuchardt 
---
  drivers/mtd/cfi_flash.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index b7289ba539..e31e07ca80 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -155,8 +155,7 @@ __maybe_weak void flash_write32(u32 value, void *addr)

  __maybe_weak void flash_write64(u64 value, void *addr)
  {
-   /* No architectures currently implement __raw_writeq() */
-   *(volatile u64 *)addr = value;
+   __raw_writeq(value, addr);
  }

  __maybe_weak u8 flash_read8(void *addr)
@@ -176,8 +175,7 @@ __maybe_weak u32 flash_read32(void *addr)

  __maybe_weak u64 flash_read64(void *addr)
  {
-   /* No architectures currently implement __raw_readq() */
-   return *(volatile u64 *)addr;
+   return __raw_readq(addr);
  }

  /*---
--
2.26.2






Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


Re: [PATCH 1/1] mtd: cfi_flash: use __raw_writeq(), __raw_readq()

2020-06-08 Thread Heinrich Schuchardt
On 6/8/20 9:07 AM, Stefan Roese wrote:
> On 07.06.20 20:42, Heinrich Schuchardt wrote:
>> On 6/6/20 11:13 PM, Heinrich Schuchardt wrote:
>>> Functions __raw_writeq(), __raw_readq() are available for all
>>> architectures. So let's use them.
>>
>> The major architectures have these but not m68k, microblaze, nd32,
>> nios2, powerpc, sh, xtenza.
>
> Just checking to be clear: This patch breaks compiling on these
> platforms and you are withdrawing it (for now)?

Yes, it breaks compiling on the specified platforms.

This can be fixed by adding the missing functions to the platforms:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commits/sunxi

But is it worthwhile to add __raw_writeq(), __raw_readq() to all of these?

Best regards

Heinrich

>
> Thanks,
> Stefan
>
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>   drivers/mtd/cfi_flash.c | 6 ++
>>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
>>> index b7289ba539..e31e07ca80 100644
>>> --- a/drivers/mtd/cfi_flash.c
>>> +++ b/drivers/mtd/cfi_flash.c
>>> @@ -155,8 +155,7 @@ __maybe_weak void flash_write32(u32 value, void
>>> *addr)
>>>
>>>   __maybe_weak void flash_write64(u64 value, void *addr)
>>>   {
>>> -    /* No architectures currently implement __raw_writeq() */
>>> -    *(volatile u64 *)addr = value;
>>> +    __raw_writeq(value, addr);
>>>   }
>>>
>>>   __maybe_weak u8 flash_read8(void *addr)
>>> @@ -176,8 +175,7 @@ __maybe_weak u32 flash_read32(void *addr)
>>>
>>>   __maybe_weak u64 flash_read64(void *addr)
>>>   {
>>> -    /* No architectures currently implement __raw_readq() */
>>> -    return *(volatile u64 *)addr;
>>> +    return __raw_readq(addr);
>>>   }
>>>
>>>  
>>> /*---
>>>
>>> --
>>> 2.26.2
>>>
>>
>
>
> Viele Grüße,
> Stefan
>



Pull request: u-boot-rockchip-20200607

2020-06-08 Thread Kever Yang
Hi Tom,

Please pull the rockchip updates/fixes:
- revive rk3399 puma board to adapt mainline dts;
- Fix rk3399-evb stdout path;
- Enable PCIe for rk3399: Rockpro64, firefly, pinebookpro;
- Add rk3328 Rock-pi-e board;
- Enable SPI boot for rockpro64 and roc-pc-rk3399;

Gitlab ci:
https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3580

Thanks,
- Kever

The following changes since commit 88bd5b1793600b0f5f25c3d236b4d049fb986140:

  configs: Resync with savedefconfig (2020-06-04 19:29:09 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
tags/u-boot-rockchip-20200607

for you to fetch changes up to 187ab38e766393cda7bf3bf4926c1e55f48ad0cb:

  rockchip: enable PCIe and NVMe on Pinebook Pro (2020-06-07 20:53:23 +0800)


Heiko Stuebner (8):
  arm64: dts: rk3399-puma: fix gpio levels for gmac reset pin
  arm64: dts: rk3399-puma: fix gpio levels for vcc5v0-host regulator
  rockchip: puma: fix indentation for -u-boot.dtsi
  rockchip: puma: fix indentation of misc_init_r
  rockchip: puma: reorganize devicetrees to actually work and match upstream
  rockchip: puma: remove separate fit generator
  rockchip: puma: drop special handling of usb host regulator
  rockchip: puma: enable new usb config options

Jagan Teki (4):
  Makefile: Drop to handle rkspi image type
  roc-rk3399-pc: Mark default env from SPI
  roc-rk3399-pc: Add SPI boot
  doc: rockchip: Document SPI flash program steps

Kever Yang (1):
  rockchip: rk3399-evb: add stdout-path for the board

Marcin Juszkiewicz (2):
  rockchip: rockpro64: Store default env into SPI
  rockchip: rockpro64: add SPI boot

Mark Kettenis (2):
  rockchip: Enable PCIe/M.2 and NVMe on Firefly RK3399
  rockchip: Enable PCIe and NVMe on ROCKPro64

Patrick Wildt (1):
  rockchip: enable PCIe and NVMe on Pinebook Pro

b.l.huang (2):
  rockchip: rk3328: add rock-pi-e dts file
  rockchip: rk3328: add rock-pi-e-rk3328_defconfig file

 Makefile   |  11 +-
 arch/arm/dts/Makefile  |   7 +-
 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi  |  33 +++
 arch/arm/dts/rk3328-rock-pi-e.dts  | 267 
 arch/arm/dts/rk3399-evb-u-boot.dtsi|   1 +
 arch/arm/dts/rk3399-puma-ddr1333-u-boot.dtsi   |   4 -
 arch/arm/dts/rk3399-puma-ddr1333.dts   |   8 -
 arch/arm/dts/rk3399-puma-ddr1600-u-boot.dtsi   |   4 -
 arch/arm/dts/rk3399-puma-ddr1600.dts   |   9 -
 arch/arm/dts/rk3399-puma-ddr1866-u-boot.dtsi   |   4 -
 arch/arm/dts/rk3399-puma-ddr1866.dts   |   8 -
 ...-u-boot.dtsi => rk3399-puma-haikou-u-boot.dtsi} |  43 ++--
 arch/arm/dts/rk3399-puma-haikou.dts| 271 +
 arch/arm/dts/rk3399-puma.dtsi  |   4 +-
 arch/arm/dts/rk3399-roc-pc-u-boot.dtsi |  12 +-
 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi  |  12 +-
 board/rockchip/evb_rk3328/MAINTAINERS  |   7 +
 board/theobroma-systems/puma_rk3399/Kconfig|  15 ++
 board/theobroma-systems/puma_rk3399/fit_spl_atf.sh |  94 ---
 board/theobroma-systems/puma_rk3399/puma-rk3399.c  |  93 +--
 configs/firefly-rk3399_defconfig   |   4 +
 configs/pinebook-pro-rk3399_defconfig  |   4 +
 configs/puma-rk3399_defconfig  |   8 +-
 configs/roc-pc-mezzanine-rk3399_defconfig  |   9 +-
 configs/roc-pc-rk3399_defconfig|   9 +-
 configs/rock-pi-e-rk3328_defconfig | 104 
 configs/rockpro64-rk3399_defconfig |  10 +-
 doc/board/rockchip/rockchip.rst|  27 +-
 include/configs/roc-pc-rk3399.h|   4 -
 include/configs/rockpro64_rk3399.h |   2 -
 30 files changed, 830 insertions(+), 258 deletions(-)
 create mode 100644 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3328-rock-pi-e.dts
 delete mode 100644 arch/arm/dts/rk3399-puma-ddr1333-u-boot.dtsi
 delete mode 100644 arch/arm/dts/rk3399-puma-ddr1333.dts
 delete mode 100644 arch/arm/dts/rk3399-puma-ddr1600-u-boot.dtsi
 delete mode 100644 arch/arm/dts/rk3399-puma-ddr1600.dts
 delete mode 100644 arch/arm/dts/rk3399-puma-ddr1866-u-boot.dtsi
 delete mode 100644 arch/arm/dts/rk3399-puma-ddr1866.dts
 rename arch/arm/dts/{rk3399-puma-u-boot.dtsi => 
rk3399-puma-haikou-u-boot.dtsi} (53%)
 create mode 100644 arch/arm/dts/rk3399-puma-haikou.dts
 delete mode 100755 board/theobroma-systems/puma_rk3399/fit_spl_atf.sh
 create mode 100644 configs/rock-pi-e-rk3328_defconfig




Re: [PATCH 1/1] mtd: cfi_flash: use __raw_writeq(), __raw_readq()

2020-06-08 Thread Stefan Roese

On 08.06.20 09:12, Heinrich Schuchardt wrote:

On 6/8/20 9:07 AM, Stefan Roese wrote:

On 07.06.20 20:42, Heinrich Schuchardt wrote:

On 6/6/20 11:13 PM, Heinrich Schuchardt wrote:

Functions __raw_writeq(), __raw_readq() are available for all
architectures. So let's use them.


The major architectures have these but not m68k, microblaze, nd32,
nios2, powerpc, sh, xtenza.


Just checking to be clear: This patch breaks compiling on these
platforms and you are withdrawing it (for now)?


Yes, it breaks compiling on the specified platforms.

This can be fixed by adding the missing functions to the platforms:
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commits/sunxi

But is it worthwhile to add __raw_writeq(), __raw_readq() to all of these?


Sure, why not?

Thanks,
Stefan


Best regards

Heinrich



Thanks,
Stefan



Signed-off-by: Heinrich Schuchardt 
---
   drivers/mtd/cfi_flash.c | 6 ++
   1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index b7289ba539..e31e07ca80 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -155,8 +155,7 @@ __maybe_weak void flash_write32(u32 value, void
*addr)

   __maybe_weak void flash_write64(u64 value, void *addr)
   {
-    /* No architectures currently implement __raw_writeq() */
-    *(volatile u64 *)addr = value;
+    __raw_writeq(value, addr);
   }

   __maybe_weak u8 flash_read8(void *addr)
@@ -176,8 +175,7 @@ __maybe_weak u32 flash_read32(void *addr)

   __maybe_weak u64 flash_read64(void *addr)
   {
-    /* No architectures currently implement __raw_readq() */
-    return *(volatile u64 *)addr;
+    return __raw_readq(addr);
   }

  
/*---


--
2.26.2






Viele Grüße,
Stefan






Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de


pull request of u-boot-mpc85xx for v2020.07

2020-06-08 Thread Priyanka Jain
Dear Tom,
Please find my pull-request for u-boot-mpc85xx
https://travis-ci.org/github/p-priyanka-jain/u-boot/builds/694639674

Summary
DM_ETH support for P2041RDB, T1024RDB, P5040DS, P3041DS, P4080DS, bug fixes
Add TBI Phy access through MII
DDR: Rework errata workaround for A008109, A008378, 009942

Thanks
Priyanka
-
The following changes since commit ecd4d99f654f3f7bfb96001891d69c3125e70b69:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2020-06-01 
23:34:18 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx.git HEAD

for you to fetch changes up to 164a5af43635c63ea2459d4c87a1a4b16acd689a:

  ddr: Rework errata A008109, A008378, 009942 workaround (2020-06-04 18:53:20 
+0530)


Hou Zhiqiang (3):
  doc: dt-bindings: tsec: Correct the Ethernet port compatible string
  net: tsec: Access eTSEC registers using virtual address
  net: tsec: Access TBI PHY through the corresponding MII

Jaiprakash Singh (1):
  ddr: Rework errata A008109, A008378, 009942 workaround

Joakim Tjernlund (1):
  ddr: fsl: Impl. Erratum A008109

Madalin Bucur (22):
  drivers: net: e1000: with DM_ETH needs DM_PCI too
  powerpc/mpc85xx: Fix compiling error with DM_GPIO
  powerpc: mpc85xx: fix unused variable warning
  drivers: net: qe: deselect QE when DM_ETH is enabled
  board/freescale: add the DM_ETH changes for the PPC DPAA platforms
  net: tsec: fsl_mdio: add DM MDIO support
  powerpc: dts: QorIQ: Add node(s) for the platform PLL
  powerpc: dts: add QorIQ GPIOs
  powerpc: dts: add QorIQ DPAA 1 FMan device tree nodes
  powerpc: dts: add QorIQ DPAA 1 FMan v3 device tree nodes
  powerpc: dts: add QorIQ DPAA 1 FMan for P4080
  powerpc: dts: add QorIQ DPAA 1 FMan interfaces to P4080DS
  powerpc: dts: add QorIQ DPAA 1 FMan for P2041
  powerpc: dts: add QorIQ DPAA 1 FMan to P2041RDB
  powerpc: dts: add QorIQ DPAA 1 FMan for P3041
  powerpc: dts: add QorIQ DPAA 1 FMan to P3041DS
  powerpc: dts: add QorIQ DPAA 1 FMan for P5040
  powerpc: dts: add QorIQ DPAA 1 FMan to P5040DS
  powerpc: dts: add QorIQ DPAA 1 FMan v3 for T102x
  powerpc: dts: add QorIQ DPAA 1 FMan v3 to T1024RDB
  configs: enable DM_ETH support for P2041RDB
  configs: enable DM_ETH support for T1024RDB

 arch/powerpc/cpu/mpc85xx/Kconfig   |   6 +
 arch/powerpc/cpu/mpc85xx/cpu_init.c|   6 +-
 arch/powerpc/dts/p2041rdb.dts  |  98 +++-
 arch/powerpc/dts/p2041si-post.dtsi |  42 
 arch/powerpc/dts/p3041ds.dts   | 129 ++-
 arch/powerpc/dts/p3041si-post.dtsi |  42 
 arch/powerpc/dts/p4080ds.dts   | 191 +++-
 arch/powerpc/dts/p4080si-post.dtsi |  61 +
 arch/powerpc/dts/p5040ds.dts   | 252 -
 arch/powerpc/dts/p5040si-post.dtsi |  69 ++
 arch/powerpc/dts/qoriq-clockgen1.dtsi  |  14 ++
 arch/powerpc/dts/qoriq-clockgen2.dtsi  |  14 ++
 arch/powerpc/dts/qoriq-fman-0-10g-0.dtsi   |  37 +++
 arch/powerpc/dts/qoriq-fman-0-1g-0.dtsi|  44 
 arch/powerpc/dts/qoriq-fman-0-1g-1.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-0-1g-2.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-0-1g-3.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-0-1g-4.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-0.dtsi |  79 +++
 arch/powerpc/dts/qoriq-fman-1-10g-0.dtsi   |  36 +++
 arch/powerpc/dts/qoriq-fman-1-1g-0.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-1-1g-1.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-1-1g-2.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-1-1g-3.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-1-1g-4.dtsi|  43 
 arch/powerpc/dts/qoriq-fman-1.dtsi |  79 +++
 .../dts/qoriq-fman3-0-10g-0-best-effort.dtsi   |  47 
 arch/powerpc/dts/qoriq-fman3-0-10g-0.dtsi  |  44 
 .../dts/qoriq-fman3-0-10g-1-best-effort.dtsi   |  47 
 arch/powerpc/dts/qoriq-fman3-0-10g-1.dtsi  |  44 
 arch/powerpc/dts/qoriq-fman3-0-1g-0.dtsi   |  43 
 arch/powerpc/dts/qoriq-fman3-0-1g-1.dtsi   |  43 
 arch/powerpc/dts/qoriq-fman3-0-1g-2.dtsi   |  43 
 arch/powerpc/dts/qoriq-fman3-0-1g-3.dtsi   |  43 
 arch/powerpc/dts/qoriq-fman3-0-1g-4.dtsi   |  43 
 arch/powerpc/dts/qoriq-fman3-0-1g-5.dtsi   |  43 
 arch/powerpc/dts/qoriq-fman3-0.dtsi|  84 +++
 arch/powerpc/dts/qoriq-fman3-1-10g-0.dtsi  |  44 
 arch/powerpc/dts/qoriq-fman3-1-10g-1.dtsi  |  44 
 arch/powerpc/dts/qoriq-fman3-1-1g-0.dtsi   |  43 
 arch/

RE: [PATCHv2 3/3] net: tsec: Access TBI PHY through the corresponding MII

2020-06-08 Thread Priyanka Jain (OSS)
>-Original Message-
>From: U-Boot  On Behalf Of Zhiqiang Hou
>Sent: Sunday, May 3, 2020 8:19 PM
>To: u-boot@lists.denx.de; joe.hershber...@ni.com; bmeng...@gmail.com;
>olte...@gmail.com; Priyanka Jain 
>Cc: Z.q. Hou 
>Subject: [PATCHv2 3/3] net: tsec: Access TBI PHY through the corresponding
>M
II
>
>From: Hou Zhiqiang 
>
>When an eTSEC is configured to use TBI, configuration of the TBI is done
>through the MIIM registers for that eTSEC.
>For example, if a TBI interface is required on eTSEC2, then the MIIM registers
>starting at offset 0x2_5520 are used to configure it.
>
>Fixes: 9a1d6af55ecd ("net: tsec: Add driver model ethernet support")
>Signed-off-by: Hou Zhiqiang 
>Reviewed-by: Vladimir Oltean 
>Tested-by: Vladimir Oltean 
>---

Series applied on mpc85xx. Awaiting upstream

Thanks
Priyanka


RE: [PATCH] drivers: net: e1000: with DM_ETH needs DM_PCI too

2020-06-08 Thread Priyanka Jain (OSS)
>-Original Message-
>From: U-Boot  On Behalf Of Madalin Bucur
>Sent: Wednesday, April 29, 2020 10:56 AM
>To: joe.hershber...@ni.com; u-boot@lists.denx.de
>Cc: Madalin Bucur (OSS) 
>Subject: [PATCH] drivers: net: e1000: with DM_ETH needs DM_PCI too
>
>Compilation error occur when DM_ETH is enabled without DM_PCI.
>
>Signed-off-by: Madalin Bucur 
>---
 
Patch applied on mpc85xx. Awaiting upstream

Thanks
Priyanka


RE: [PATCH] powerpc/mpc85xx: Fix compiling error with DM_GPIO

2020-06-08 Thread Priyanka Jain (OSS)
>-Original Message-
>From: U-Boot  On Behalf Of Madalin Bucur
>Sent: Wednesday, April 29, 2020 11:04 AM
>To: w...@denx.de; u-boot@lists.denx.de
>Cc: Madalin Bucur (OSS) 
>Subject: [PATCH] powerpc/mpc85xx: Fix compiling error with DM_GPIO
>
>P4080DS compilation fails with DM_GPIO enabled:
>
>drivers/gpio/gpio-uclass.c:355:5: error: redefinition of 'gpio_request'
> int gpio_request(unsigned gpio, const char *label)
> ^~~~
>In file included from ./arch/powerpc/include/asm/arch/gpio.h:17:0,
> from ./arch/powerpc/include/asm/gpio.h:1,
> from drivers/gpio/gpio-uclass.c:16:
>./arch/powerpc/include/asm/mpc85xx_gpio.h:68:19: note: previous
>definition of 'gpio_request' was here  static inline int gpio_request(unsigned
>gpio, const char *label)
>   ^~~~
>
>Signed-off-by: Madalin Bucur 
>---

Patch applied on mpc85xx. Awaiting upstream

Thanks
Priyanka


RE: [PATCH] powerpc: mpc85xx: fix unused variable warning

2020-06-08 Thread Priyanka Jain (OSS)
>-Original Message-
>From: U-Boot  On Behalf Of Madalin Bucur
>Sent: Wednesday, April 29, 2020 2:47 PM
>To: Priyanka Jain ; w...@denx.de; u-
>b...@lists.denx.de
>Cc: Madalin Bucur (OSS) 
>Subject: [PATCH] powerpc: mpc85xx: fix unused variable warning
>
>Fix unused variable warning when CONFIG_QE is not set.
>
>Signed-off-by: Madalin Bucur 
>---

Patch applied on mpc85xx. Awaiting upstream

Thanks
Priyanka


RE: [PATCH] drivers: net: qe: deselect QE when DM_ETH is enabled

2020-06-08 Thread Priyanka Jain (OSS)
>-Original Message-
>From: U-Boot  On Behalf Of Madalin Bucur
>Sent: Wednesday, April 29, 2020 2:57 PM
>To: Priyanka Jain ; u-boot@lists.denx.de
>Cc: Madalin Bucur (OSS) 
>Subject: [PATCH] drivers: net: qe: deselect QE when DM_ETH is enabled
>
>A compilation error appears when QE is compiled with DM_ETH
>enabled:
>
>drivers/qe/uec.c: In function 'init_phy':
>drivers/qe/uec.c:425:28: error: dereferencing pointer to incomplete type
>'struct eth_device'
>  uec = (uec_private_t *)dev->priv;
>^~
>drivers/qe/uec.c: In function 'uec_initialize':
>drivers/qe/uec.c:1357:43: error: invalid application of 'sizeof' to incomplete
>type 'struct eth_device'
>  dev = (struct eth_device *)malloc(sizeof(struct eth_device));
>   ^~
>
>The patch disables CONFIG_QE when CONFIG_DM_ETH is set.
>
>Signed-off-by: Madalin Bucur 
>---

Patch applied on mpc85xx. Awaiting upstream

Thanks
Priyanka


Re: [PATCH 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

2020-06-08 Thread Maxime Ripard
Hi,

On Sat, Jun 06, 2020 at 09:58:13AM +, Heinrich Schuchardt wrote:
> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
> relocation.
> 
> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
> 
> CONFIG_LOG=Y is another setting requiring additional early malloc
> area, cf. log_init().
> 
> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
> we see as output in main U-Boot
> 
> alloc_simple() alloc space exhausted
> 
> With this patch the default values of SYS_MALLOC_F_LEN and
> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000.
> 
> Signed-off-by: Heinrich Schuchardt 

Where is this SYS_MALLOC_F_LEN allocated from (in particular for the
SPL). Is it from the SRAM?

If so, on older SoCs, we probably don't have 8k to spare.

Maxime


signature.asc
Description: PGP signature


Re: rockchip: correctly set vop0 or vop1

2020-06-08 Thread Rtp
Patrick Wildt  writes:

Hi,

> The EDP_LCDC_SEL bit has to be set correctly to select vop0 or
> vop1, but so far we have set it in both conditions, which is not
> correct.
>
> Can someone verify this is the correct way round?  vop1 -> set,
> vop0 -> clear?
>
> Signed-off-by: Patrick Wildt 
>
> diff --git a/drivers/video/rockchip/rk_edp.c b/drivers/video/rockchip/rk_edp.c
> index 92188be9275..000bd481408 100644
> --- a/drivers/video/rockchip/rk_edp.c
> +++ b/drivers/video/rockchip/rk_edp.c
> @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev)
>   rk_setreg(&priv->grf->soc_con12, 1 << 4);
>  
>   /* select epd signal from vop0 or vop1 */
> - rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 << 5));
> + rk_clrsetreg(&priv->grf->soc_con6, (1 << 5),
> + (vop_id == 1) ? (1 << 5) : (0 << 5));

While working on PBP EDP support, found this too but I'm not sure it's
fine or not. For rk3399, my (not yet published) patch is doing:

+   if (vop_id == 0)
+   rk_clrreg(&priv->grf->soc_con20, (1 << 5));
+   else
+   rk_setreg(&priv->grf->soc_con20, (1 << 5));

I believe that the rk3288 may need similar treatment but I've yet to
look at the rk3288 manual.

Arnaud


[PATCH 2/3] arm64: lx2160a: dts: Add watchdog node

2020-06-08 Thread Biwen Li
From: Zhao Qiang 

Add watchdog node which is sbsa into lx2160a dtsi

Signed-off-by: Zhao Qiang 
---
 arch/arm/dts/fsl-lx2160a.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi
index 1789da8..a2421f6 100644
--- a/arch/arm/dts/fsl-lx2160a.dtsi
+++ b/arch/arm/dts/fsl-lx2160a.dtsi
@@ -204,6 +204,13 @@
#interrupt-cells = <2>;
};
 
+   watchdog@23a {
+   compatible = "arm,sbsa-gwdt";
+   reg = <0x0 0x23a 0 0x1000>,
+ <0x0 0x239 0 0x1000>;
+   timeout-sec = <30>;
+   };
+
usb0: usb3@310 {
compatible = "fsl,layerscape-dwc3";
reg = <0x0 0x310 0x0 0x1>;
-- 
2.7.4



[PATCH 3/3] configs: lx2160a: Enable Watchdog support

2020-06-08 Thread Biwen Li
From: Zhao Qiang 

Enable support to compile SBSA driver.

Signed-off-by: Zhao Qiang 
---
 configs/lx2160aqds_tfa_defconfig | 3 +++
 configs/lx2160ardb_tfa_defconfig | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig
index 716c089..93e6a05 100644
--- a/configs/lx2160aqds_tfa_defconfig
+++ b/configs/lx2160aqds_tfa_defconfig
@@ -29,6 +29,7 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
 CONFIG_CMD_CACHE=y
 CONFIG_MP=y
 CONFIG_OF_CONTROL=y
@@ -82,4 +83,6 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_WDT=y
+CONFIG_WDT_SBSA=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig
index bc654cf..8504a50 100644
--- a/configs/lx2160ardb_tfa_defconfig
+++ b/configs/lx2160ardb_tfa_defconfig
@@ -30,6 +30,7 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PCI=y
 CONFIG_CMD_USB=y
+CONFIG_CMD_WDT=y
 CONFIG_CMD_CACHE=y
 CONFIG_MP=y
 CONFIG_OF_CONTROL=y
@@ -76,4 +77,6 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_WDT=y
+CONFIG_WDT_SBSA=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
-- 
2.7.4



[PATCH 1/3] Watchdog: introduce ARM SBSA watchdog driver

2020-06-08 Thread Biwen Li
From: Zhao Qiang 

According to Server Base System Architecture (SBSA) specification,
the SBSA Generic Watchdog has two stage timeouts: the first signal
(WS0) is for alerting the system by interrupt, the second one (WS1) is a
real hardware reset.
More details about the hardware specification of this device:
ARM DEN0029B - Server Base System Architecture (SBSA)

This driver can operate ARM SBSA Generic Watchdog as a single stage
In the single stage mode, when the timeout is reached, your system
will be reset by WS1. The first signal (WS0) is ignored.

Signed-off-by: Zhao Qiang 
---
 MAINTAINERS  |   1 +
 drivers/watchdog/Kconfig |   6 ++
 drivers/watchdog/Makefile|   1 +
 drivers/watchdog/sbsa_gwdt.c | 131 +++
 4 files changed, 139 insertions(+)
 create mode 100644 drivers/watchdog/sbsa_gwdt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1fd975c..09554c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -685,6 +685,7 @@ M:  Priyanka Jain 
 S: Maintained
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git
 F: drivers/watchdog/sp805_wdt.c
+F: drivers/watchdog/sbsa_gwdt.c
 
 I2C
 M: Heiko Schocher 
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index bf06180..191891c 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -163,6 +163,12 @@ config WDT_SANDBOX
  can be probed and supports all of the methods of WDT, but does not
  really do anything.
 
+config WDT_SBSA
+   bool "SBSA watchdog timer support"
+   depends on WDT
+   help
+  Select this to enable SBSA watchdog timer.
+
 config WDT_SP805
bool "SP805 watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 519bbd3..0f0b2eb 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
 obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
 obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
 obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
+obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o
 obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
 obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
 obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 000..99acb89
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Watchdog driver for SBSA
+ *
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR  0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS  0x000
+#define SBSA_GWDT_WOR  0x008
+#define SBSA_GWDT_WCV  0x010
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR   0xfcc
+#define SBSA_GWDT_IDR  0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN   BIT(0)
+#define SBSA_GWDT_WCS_WS0  BIT(1)
+#define SBSA_GWDT_WCS_WS1  BIT(2)
+
+struct sbsa_gwdt_priv {
+   void __iomem *reg_refresh;
+   void __iomem *reg_control;
+};
+
+static int sbsa_gwdt_reset(struct udevice *dev)
+{
+   struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+
+   writel(0, priv->reg_refresh + SBSA_GWDT_WRR);
+
+   return 0;
+}
+
+static int sbsa_gwdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+   u32 clk;
+   u32 load_value;
+
+   struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+   /*
+* it work in the single stage mode in u-boot,
+* The first signal (WS0) is ignored,
+* the timeout is (WOR * 2), so the WOR should be configured
+* to half value of timeout.
+*/
+   clk = get_tbclk();
+   writel(clk / 2 * timeout,
+  priv->reg_control + SBSA_GWDT_WOR);
+
+   /* writing WCS will cause an explicit watchdog refresh */
+   writel(SBSA_GWDT_WCS_EN, priv->reg_control + SBSA_GWDT_WCS);
+
+   return 0;
+}
+
+static int sbsa_gwdt_stop(struct udevice *dev)
+{
+   struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+
+   writel(0, priv->reg_control + SBSA_GWDT_WCS);
+
+   return 0;
+}
+
+static int sbsa_gwdt_expire_now(struct udevice *dev, ulong flags)
+{
+   sbsa_gwdt_start(dev, 0, flags);
+
+   return 0;
+}
+
+static int sbsa_gwdt_probe(struct udevice *dev)
+{
+   debug("%s: Probing wdt%u (sbsa-gwdt)\n", __func__, dev->seq);
+
+   return 0;
+}
+
+static int sbsa_gwdt_ofdata_to_platdata(struct udevice *dev)
+{
+   struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+
+   priv->reg_control = (void __iomem *)dev_read_addr_index(dev, 0);
+   if (IS_ERR(priv->reg_control))
+   return PTR_ERR(priv->reg_control);
+
+   priv->reg_refresh = (void __iomem *)dev_read_addr_index(dev, 1);
+   if

Re: [PATCH] regmap: Check for out-of-range offsets before mapping them

2020-06-08 Thread Pratyush Yadav
Hi Simon,

On 07/06/20 08:43PM, Simon Glass wrote:
> Hi Pratyush,
> 
> On Tue, 26 May 2020 at 06:06, Pratyush Yadav  wrote:
> >
> > In regmap_raw_{read,write}_range(), offsets are checked to make sure
> > they aren't out of range. But this check happens _after_ the address is
> > mapped from physical memory. Input should be sanity-checked before using
> > it. Mapping the address before validating it leaves the door open to
> > passing an invalid address to map_physmem(). So check for out of range
> > offsets _before_ mapping them.
> >
> > This fixes a segmentation fault in sandbox when -1 is used as an offset
> > to regmap_{read,write}().
> >
> > Signed-off-by: Pratyush Yadav 
> > ---
> >  drivers/core/regmap.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> 
> Reviewed-by: Simon Glass 

Thanks.
 
> Please add a sandbox test to catch this problem.

The test "dm_test_devm_regmap" proposed in [0] should catch this:

ut_asserteq(-ERANGE, regmap_write(priv->cfg_regmap, -1, val));
ut_asserteq(-ERANGE, regmap_read(priv->cfg_regmap, -1, &val));

[0] 
https://patchwork.ozlabs.org/project/uboot/patch/20200605203025.15466-9-p.ya...@ti.com/

-- 
Regards,
Pratyush Yadav
Texas Instruments India


Re: [PATCH 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

2020-06-08 Thread André Przywara
On 08/06/2020 09:02, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 06, 2020 at 09:58:13AM +, Heinrich Schuchardt wrote:
>> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
>> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
>> relocation.
>>
>> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
>> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
>>
>> CONFIG_LOG=Y is another setting requiring additional early malloc
>> area, cf. log_init().
>>
>> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
>> we see as output in main U-Boot
>>
>> alloc_simple() alloc space exhausted
>>
>> With this patch the default values of SYS_MALLOC_F_LEN and
>> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000.

Heinrich, many thanks for the debugging and the nice solution!

>>
>> Signed-off-by: Heinrich Schuchardt 
> 
> Where is this SYS_MALLOC_F_LEN allocated from (in particular for the
> SPL). Is it from the SRAM?

This is the value for U-Boot proper only, so it's taken from DRAM. There
is CONFIG_SPL_SYS_MALLOC_F_LEN for the SPL, which we don't touch. So the
SPL is safe.

Cheers,
Andre

> 
> If so, on older SoCs, we probably don't have 8k to spare.
> 
> Maxime
> 



[PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration

2020-06-08 Thread Patrick Delaunay
Add configuration flag to select the supported dwc driver configuration:
- CONFIG_DWC_ETH_QOS_TEGRA186
- CONFIG_DWC_ETH_QOS_IMX
- CONFIG_DWC_ETH_QOS_STM32

See Linux driver ethernet/stmicro/stmmac and associated glue layers
for other configuration examples.

This patch removes the not-selected compatibles and lets the linker remove
the unused functions to reduce the size of the driver.

Signed-off-by: Patrick Delaunay 
---
Hi,

I propose this patch after Marek's remark in [1].

It is also linked to [2] to limit the STM32 glue for ST compatible.

[1] net: dwc_eth_qos: Make clk_rx and clk_tx optional

http://patchwork.ozlabs.org/project/uboot/patch/20200512095603.29126-5-david...@rock-chips.com/#2432595

[2] net: dwc_eth_qos: update the compatible supported for STM32
http://patchwork.ozlabs.org/project/uboot/list/?series=176917


 drivers/net/Kconfig   | 27 ---
 drivers/net/dwc_eth_qos.c | 12 +---
 2 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0b08de0ef4..c4b3667d3b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -156,9 +156,30 @@ config DWC_ETH_QOS
help
  This driver supports the Synopsys Designware Ethernet QOS (Quality
  Of Service) IP block. The IP supports many options for bus type,
- clocking/reset structure, and feature list. This driver currently
- supports the specific configuration used in NVIDIA's Tegra186 chip,
- but should be extensible to other combinations quite easily.
+ clocking/reset structure, and feature list.
+
+config DWC_ETH_QOS_IMX
+   bool "Synopsys DWC Ethernet QOS device support for IMX"
+   depends on DWC_ETH_QOS
+   help
+ The Synopsys Designware Ethernet QOS IP block with the specific
+ configuration used in IMX soc.
+
+config DWC_ETH_QOS_STM32
+   bool "Synopsys DWC Ethernet QOS device support for STM32"
+   depends on DWC_ETH_QOS
+   default y if ARCH_STM32MP
+   help
+ The Synopsys Designware Ethernet QOS IP block with the specific
+ configuration used in STM32MP soc.
+
+config DWC_ETH_QOS_TEGRA186
+   bool "Synopsys DWC Ethernet QOS device support for TEGRA186"
+   depends on DWC_ETH_QOS
+   default y if TEGRA186
+   help
+ The Synopsys Designware Ethernet QOS IP block with specific
+ configuration used in NVIDIA's Tegra186 chip.
 
 config E1000
bool "Intel PRO/1000 Gigabit Ethernet support"
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 3f4437069b..d4536a325f 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -2100,7 +2100,7 @@ static struct eqos_ops eqos_tegra186_ops = {
.eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_tegra186
 };
 
-static const struct eqos_config eqos_tegra186_config = {
+static const struct eqos_config __maybe_unused eqos_tegra186_config = {
.reg_access_always_ok = false,
.mdio_wait = 10,
.swr_wait = 10,
@@ -2127,7 +2127,7 @@ static struct eqos_ops eqos_stm32_ops = {
.eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_stm32
 };
 
-static const struct eqos_config eqos_stm32_config = {
+static const struct eqos_config __maybe_unused eqos_stm32_config = {
.reg_access_always_ok = false,
.mdio_wait = 1,
.swr_wait = 50,
@@ -2154,7 +2154,7 @@ static struct eqos_ops eqos_imx_ops = {
.eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_imx
 };
 
-struct eqos_config eqos_imx_config = {
+struct eqos_config __maybe_unused eqos_imx_config = {
.reg_access_always_ok = false,
.mdio_wait = 1,
.swr_wait = 50,
@@ -2165,18 +2165,24 @@ struct eqos_config eqos_imx_config = {
 };
 
 static const struct udevice_id eqos_ids[] = {
+#if IS_ENABLED(CONFIG_DWC_ETH_QOS_TEGRA186)
{
.compatible = "nvidia,tegra186-eqos",
.data = (ulong)&eqos_tegra186_config
},
+#endif
+#if IS_ENABLED(CONFIG_DWC_ETH_QOS_STM32)
{
.compatible = "snps,dwmac-4.20a",
.data = (ulong)&eqos_stm32_config
},
+#endif
+#if IS_ENABLED(CONFIG_DWC_ETH_QOS_IMX)
{
.compatible = "fsl,imx-eqos",
.data = (ulong)&eqos_imx_config
},
+#endif
 
{ }
 };
-- 
2.17.1



RE: [RESEND PATCH v2 04/11] net: dwc_eth_qos: Make clk_rx and clk_tx optional

2020-06-08 Thread Patrick DELAUNAY
Hi Marek,

> From: Marek Vasut 
> Sent: mercredi 13 mai 2020 15:54
> 
> On 5/13/20 3:17 PM, Patrick DELAUNAY wrote:
> > Hi David,
> >
> >> From: David Wu 
> >> Sent: mardi 12 mai 2020 11:56
> >>
> >> For others using, clk_rx and clk_tx may not be necessary, and their
> >> clock names are different.
> >>
> >> Signed-off-by: David Wu 
> >> ---
> >>
> >> Changes in v2:
> >> - Don't change the Rx and Tx clock names. (Patrice, Stephen)
> >>
> >>  drivers/net/dwc_eth_qos.c | 61
> >> +++
> >>  1 file changed, 29 insertions(+), 32 deletions(-)
> >>
[...]
> >
> > These clock are mandatory for STM32 glue as explain in Linux binding
> > Documentation/devicetree/bindings/net/stm32-dwmac.txt
> >
> > But I fact when when I check the code, I see perhaps an issue in the 
> > current U-
> Boot glue:
> > we don't select the STM32 glue for the correct compatible, I think I
> > will push
> >
> > static const struct udevice_id eqos_ids[] = {
> > {
> > .compatible = "nvidia,tegra186-eqos",
> > .data = (ulong)&eqos_tegra186_config
> > },
> > {
> > -   .compatible = "snps,dwmac-4.20a",
> > +   .compatible = "st,stm32mp1-dwmac",
> > .data = (ulong)&eqos_stm32_config
> > },
> > {
> > .compatible = "fsl,imx-eqos",
> > .data = (ulong)&eqos_imx_config
> > },
> >
> > { }
> > };
> >
> > Then you can manage your own glue for rockchip ETH for your compatible.
> 
> You might even want to drop the tegra support on ARM32 , thus save space by
> dropping useless code.

For information I push 2 patches after this remark:

[1]  net: dwc_eth_qos: update the compatible supported for STM32
  
http://patchwork.ozlabs.org/project/uboot/patch/20200514130023.15030-1-patrick.delau...@st.com/

[2]  net: dwc_eth_qos: add Kconfig option to select supported configuration
  http://patchwork.ozlabs.org/project/uboot/list/?series=181931


RE: [PATCHv2 00/13] powerpc: covert p1010, p1020 and p2020 RDB board to DM_ETH

2020-06-08 Thread Priyanka Jain (OSS)
>-Original Message-
>From: U-Boot  On Behalf Of Zhiqiang Hou
>Sent: Friday, June 5, 2020 2:25 PM
>To: u-boot@lists.denx.de; Priyanka Jain ;
>bmeng...@gmail.com; olte...@gmail.com
>Cc: Z.q. Hou 
>Subject: [PATCHv2 00/13] powerpc: covert p1010, p1020 and p2020 RDB
>board to DM_ETH
>
>From: Hou Zhiqiang 
>
>Rebased this series on the top of master branch of https://gitlab.denx.de/u-
>boot/custodians/u-boot-mpc85xx.git
>
I have requested a rebase on 'next' branch. 
I have pushed next branch to master (mpc85xx tree) as well today. So you can 
use that now
Please rebase again.

>This patch set depends on:
>https://patchwork.ozlabs.org/project/uboot/list/?series=174343
>
A patch for tsec migration to DM_MDIO was already submitted by Madalin which is 
now merged in mpc85xx tree.
Let me know if that is fine or you need some additional patches from Vladimir.


Regards
Priyanka 





Re: [RESEND PATCH v2 04/11] net: dwc_eth_qos: Make clk_rx and clk_tx optional

2020-06-08 Thread Marek Vasut
On 6/8/20 11:29 AM, Patrick DELAUNAY wrote:
[...]
>>> we don't select the STM32 glue for the correct compatible, I think I
>>> will push
>>>
>>> static const struct udevice_id eqos_ids[] = {
>>> {
>>> .compatible = "nvidia,tegra186-eqos",
>>> .data = (ulong)&eqos_tegra186_config
>>> },
>>> {
>>> -   .compatible = "snps,dwmac-4.20a",
>>> +   .compatible = "st,stm32mp1-dwmac",
>>> .data = (ulong)&eqos_stm32_config
>>> },
>>> {
>>> .compatible = "fsl,imx-eqos",
>>> .data = (ulong)&eqos_imx_config
>>> },
>>>
>>> { }
>>> };
>>>
>>> Then you can manage your own glue for rockchip ETH for your compatible.
>>
>> You might even want to drop the tegra support on ARM32 , thus save space by
>> dropping useless code.
> 
> For information I push 2 patches after this remark:
> 
> [1]  net: dwc_eth_qos: update the compatible supported for STM32
>   
> http://patchwork.ozlabs.org/project/uboot/patch/20200514130023.15030-1-patrick.delau...@st.com/
> 
> [2]  net: dwc_eth_qos: add Kconfig option to select supported configuration
>   http://patchwork.ozlabs.org/project/uboot/list/?series=181931

That's for -next, right ?


Re: [PATCH 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

2020-06-08 Thread Heinrich Schuchardt
On 6/8/20 11:07 AM, André Przywara wrote:
> On 08/06/2020 09:02, Maxime Ripard wrote:
>> Hi,
>>
>> On Sat, Jun 06, 2020 at 09:58:13AM +, Heinrich Schuchardt wrote:
>>> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
>>> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
>>> relocation.
>>>
>>> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
>>> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
>>>
>>> CONFIG_LOG=Y is another setting requiring additional early malloc
>>> area, cf. log_init().
>>>
>>> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
>>> we see as output in main U-Boot
>>>
>>> alloc_simple() alloc space exhausted
>>>
>>> With this patch the default values of SYS_MALLOC_F_LEN and
>>> SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000.
>
> Heinrich, many thanks for the debugging and the nice solution!
>
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>
>> Where is this SYS_MALLOC_F_LEN allocated from (in particular for the
>> SPL). Is it from the SRAM?
>
> This is the value for U-Boot proper only, so it's taken from DRAM. There
> is CONFIG_SPL_SYS_MALLOC_F_LEN for the SPL, which we don't touch. So the
> SPL is safe.

SPL_SYS_MALLOC_F_LEN and TPL_SYS_MALLOC_F_LEN default to
SYS_MALLOC_F_LEN. I am not aware of any TPL usage for ARCH_SUNXI.

So this patch affects all three variables.

But we should explicitly set the SPL_SYS_MALLOC_F_LEN default if 0x2000
is too big for any board.

I will send a new version of the patch.

Best regards

Heinich

>
> Cheers,
> Andre
>
>>
>> If so, on older SoCs, we probably don't have 8k to spare.
>>
>> Maxime
>>
>



[PATCH v2 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

2020-06-08 Thread Heinrich Schuchardt
The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
relocation.

CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.

CONFIG_LOG=Y is another setting requiring additional early malloc
area, cf. log_init().

When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
we see as output in main U-Boot

alloc_simple() alloc space exhausted

With this patch the default values of SYS_MALLOC_F_LEN is raised to 0x2000.
The default for SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI is explicitely set to
0x400 to avoid an increased usage of SRAM on elder SoCs.

Signed-off-by: Heinrich Schuchardt 
---
v2
keep default for SPL_SYS_MALLOC_F_LEN at 0x400
---
 Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Kconfig b/Kconfig
index 0e7ccc0b07..67b594cd74 100644
--- a/Kconfig
+++ b/Kconfig
@@ -146,7 +146,7 @@ config SYS_MALLOC_F_LEN
default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \
   ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \
   ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \
-  ARCH_LS1046A)
+  ARCH_LS1046A || ARCH_SUNXI)
default 0x400
help
  Before relocation, memory is very limited on many platforms. Still,
@@ -166,6 +166,7 @@ config SPL_SYS_MALLOC_F_LEN
hex "Size of malloc() pool in SPL before relocation"
depends on SYS_MALLOC_F && SPL
default 0x2800 if RCAR_GEN3
+   default 0x400 if ARCH_SUNXI
default SYS_MALLOC_F_LEN
help
  Before relocation, memory is very limited on many platforms. Still,
--
2.26.2



Re: rockchip: correctly set vop0 or vop1

2020-06-08 Thread Patrick Wildt
On Mon, Jun 08, 2020 at 10:18:19AM +0200, Arnaud Patard wrote:
> Patrick Wildt  writes:
> 
> Hi,
> 
> > The EDP_LCDC_SEL bit has to be set correctly to select vop0 or
> > vop1, but so far we have set it in both conditions, which is not
> > correct.
> >
> > Can someone verify this is the correct way round?  vop1 -> set,
> > vop0 -> clear?
> >
> > Signed-off-by: Patrick Wildt 
> >
> > diff --git a/drivers/video/rockchip/rk_edp.c 
> > b/drivers/video/rockchip/rk_edp.c
> > index 92188be9275..000bd481408 100644
> > --- a/drivers/video/rockchip/rk_edp.c
> > +++ b/drivers/video/rockchip/rk_edp.c
> > @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev)
> > rk_setreg(&priv->grf->soc_con12, 1 << 4);
> >  
> > /* select epd signal from vop0 or vop1 */
> > -   rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 << 5));
> > +   rk_clrsetreg(&priv->grf->soc_con6, (1 << 5),
> > +   (vop_id == 1) ? (1 << 5) : (0 << 5));
> 
> While working on PBP EDP support, found this too but I'm not sure it's
> fine or not. For rk3399, my (not yet published) patch is doing:
> 
> +   if (vop_id == 0)
> +   rk_clrreg(&priv->grf->soc_con20, (1 << 5));
> +   else
> +   rk_setreg(&priv->grf->soc_con20, (1 << 5));
> 
> I believe that the rk3288 may need similar treatment but I've yet to
> look at the rk3288 manual.
> 
> Arnaud

Yes, it does.  If you look at the linux code, they have:

static const struct rockchip_dp_chip_data rk3399_edp = {
.lcdsel_grf_reg = RK3399_GRF_SOC_CON20,
.lcdsel_big = HIWORD_UPDATE(0, RK3399_EDP_LCDC_SEL),
.lcdsel_lit = HIWORD_UPDATE(RK3399_EDP_LCDC_SEL, RK3399_EDP_LCDC_SEL),
.chip_type = RK3399_EDP,
};

static const struct rockchip_dp_chip_data rk3288_dp = {
.lcdsel_grf_reg = RK3288_GRF_SOC_CON6,
.lcdsel_big = HIWORD_UPDATE(0, RK3288_EDP_LCDC_SEL),
.lcdsel_lit = HIWORD_UPDATE(RK3288_EDP_LCDC_SEL, RK3288_EDP_LCDC_SEL),
.chip_type = RK3288_DP,
};

which indicates that for rk3399 *and* rk3288 the bit has to be set to
select "lit".  Now your diff looks equivalent to mine, apart from using
a different operation to achieve the same goal.

The linux code does

ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
if (ret < 0)
return;

if (ret)
val = dp->data->lcdsel_lit;
else
val = dp->data->lcdsel_big;

Assuming that endpoint_id essentiall returns vop id 0 or vop id 1, this
would mean that vop1 -> lit -> set bit and vop0 -> big -> clr bit.

That said, my diff seems to be fine, and your RK3399 code as well.  Do
you agree?

Patrick


Re: [PATCH v2 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

2020-06-08 Thread Jagan Teki
On Mon, Jun 8, 2020 at 6:59 AM Heinrich Schuchardt  wrote:
>
> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
> relocation.
>
> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
>
> CONFIG_LOG=Y is another setting requiring additional early malloc
> area, cf. log_init().
>
> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
> we see as output in main U-Boot
>
> alloc_simple() alloc space exhausted
>
> With this patch the default values of SYS_MALLOC_F_LEN is raised to 0x2000.
> The default for SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI is explicitely set to
> 0x400 to avoid an increased usage of SRAM on elder SoCs.
>
> Signed-off-by: Heinrich Schuchardt 
> ---

Reviewed-by: Jagan Teki 


Re: [PATCH v2 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

2020-06-08 Thread Heinrich Schuchardt
On 08.06.20 13:50, Jagan Teki wrote:
> On Mon, Jun 8, 2020 at 6:59 AM Heinrich Schuchardt  wrote:
>>
>> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
>> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
>> relocation.
>>
>> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
>> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
>>
>> CONFIG_LOG=Y is another setting requiring additional early malloc
>> area, cf. log_init().
>>
>> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
>> we see as output in main U-Boot
>>
>> alloc_simple() alloc space exhausted
>>
>> With this patch the default values of SYS_MALLOC_F_LEN is raised to 0x2000.
>> The default for SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI is explicitely set to
>> 0x400 to avoid an increased usage of SRAM on elder SoCs.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>
> Reviewed-by: Jagan Teki 
>

Thanks for reviewing.

All sunxi boards have at least 32 KiB SRAM and only this 32 KiB used by
U-Boot for SPL on all sunxi boards. A BananaPi with A20 CPU boots fine
with SPL_SYS_MALLOC_F_LEN=0x2000. So it seems that also version 1 of the
patch was on the safe side.

Best regards

Heinrich


Re: rockchip: correctly set vop0 or vop1

2020-06-08 Thread Rtp
Patrick Wildt  writes:

> On Mon, Jun 08, 2020 at 10:18:19AM +0200, Arnaud Patard wrote:
>> Patrick Wildt  writes:
>> 
>> Hi,
>> 
>> > The EDP_LCDC_SEL bit has to be set correctly to select vop0 or
>> > vop1, but so far we have set it in both conditions, which is not
>> > correct.
>> >
>> > Can someone verify this is the correct way round?  vop1 -> set,
>> > vop0 -> clear?
>> >
>> > Signed-off-by: Patrick Wildt 
>> >
>> > diff --git a/drivers/video/rockchip/rk_edp.c 
>> > b/drivers/video/rockchip/rk_edp.c
>> > index 92188be9275..000bd481408 100644
>> > --- a/drivers/video/rockchip/rk_edp.c
>> > +++ b/drivers/video/rockchip/rk_edp.c
>> > @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev)
>> >rk_setreg(&priv->grf->soc_con12, 1 << 4);
>> >  
>> >/* select epd signal from vop0 or vop1 */
>> > -  rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 << 5));
>> > +  rk_clrsetreg(&priv->grf->soc_con6, (1 << 5),
>> > +  (vop_id == 1) ? (1 << 5) : (0 << 5));
>> 
>> While working on PBP EDP support, found this too but I'm not sure it's
>> fine or not. For rk3399, my (not yet published) patch is doing:
>> 
>> +   if (vop_id == 0)
>> +   rk_clrreg(&priv->grf->soc_con20, (1 << 5));
>> +   else
>> +   rk_setreg(&priv->grf->soc_con20, (1 << 5));
>> 
>> I believe that the rk3288 may need similar treatment but I've yet to
>> look at the rk3288 manual.
>> 
>> Arnaud
>
> Yes, it does.  If you look at the linux code, they have:
>
> static const struct rockchip_dp_chip_data rk3399_edp = {
> .lcdsel_grf_reg = RK3399_GRF_SOC_CON20,
> .lcdsel_big = HIWORD_UPDATE(0, RK3399_EDP_LCDC_SEL),
> .lcdsel_lit = HIWORD_UPDATE(RK3399_EDP_LCDC_SEL, RK3399_EDP_LCDC_SEL),
> .chip_type = RK3399_EDP,
> };
>
> static const struct rockchip_dp_chip_data rk3288_dp = {
> .lcdsel_grf_reg = RK3288_GRF_SOC_CON6,
> .lcdsel_big = HIWORD_UPDATE(0, RK3288_EDP_LCDC_SEL),
> .lcdsel_lit = HIWORD_UPDATE(RK3288_EDP_LCDC_SEL, RK3288_EDP_LCDC_SEL),
> .chip_type = RK3288_DP,
> };
>
> which indicates that for rk3399 *and* rk3288 the bit has to be set to
> select "lit".  Now your diff looks equivalent to mine, apart from using
> a different operation to achieve the same goal.
>
> The linux code does
>
> ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
> if (ret < 0)
> return;
>
> if (ret)
> val = dp->data->lcdsel_lit;
> else
> val = dp->data->lcdsel_big;
>
> Assuming that endpoint_id essentiall returns vop id 0 or vop id 1, this
> would mean that vop1 -> lit -> set bit and vop0 -> big -> clr bit.
>
> That said, my diff seems to be fine, and your RK3399 code as well.  Do
> you agree?

According to the code you've shown, it should be fine for rk3288 I guess
but not for rk3399. Please note that it's grf soc_con6 register for rk3288
but grf soc_con20 for rk3399.

Arnaud


Re: [RFC PATCH 1/1] gpio: Handle NULL pointers gracefully

2020-06-08 Thread Pratyush Yadav
On 01/06/20 11:08AM, Simon Glass wrote:
> Hi Pratyush,
> 
> On Fri, 29 May 2020 at 16:04, Pratyush Yadav  wrote:
> >
> > Prepare the way for a managed GPIO API by handling NULL pointers without
> > crashing or failing. validate_desc() comes from Linux with the prints
> > removed to reduce code size.
> 
> Please can you add a little detail as to why this is needed? Are you
> trying to pass a NULL GPIO descriptor to the function?

Copy-pasting from the cover letter:

  Patch [0] added devm_gpiod_get_index_optional() which would return NULL
  when when no GPIO was assigned to the requested function. This is
  convenient for drivers that need to handle optional GPIOs.
  
  We need to take a stance on who is responsible for the NULL check: the
  driver or the GPIO core? Do we want to trust drivers to take care of the
  NULL checks, or do we want to distrust them and make sure they don't
  send us anything bogus in the GPIO core. Linux does not generally trust
  drivers and usually verifies anything it gets from them. And FWIW, I see
  that the clk and phy subsystems in U-Boot also perform checks like this.
  
  The downside of the checks is of course that they increase code size.
  They might also slightly decrease performance. The benefit is that we
  don't burden drivers with taking care of this.
  
  The patch itself is based on a similar patch by Jean-Jacques.
  
  [0] 
https://patchwork.ozlabs.org/project/uboot/patch/20200529213808.2815-2-p.ya...@ti.com/

Maybe I should put this in the commit message?
 
> > Signed-off-by: Jean-Jacques Hiblot 
> > Signed-off-by: Pratyush Yadav 
> > ---
> >  drivers/gpio/Kconfig   |  9 
> >  drivers/gpio/gpio-uclass.c | 86 ++
> >  include/asm-generic/gpio.h |  2 +-
> >  3 files changed, 88 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index d87f6cc105..f8b6bcdf44 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -36,6 +36,15 @@ config TPL_DM_GPIO
> >   particular GPIOs that they provide. The uclass interface
> >   is defined in include/asm-generic/gpio.h.
> >
> > +config GPIO_VALIDATE_DESC
> > +   bool "Check if GPIO descriptor is NULL and bail out if it is"
> > +   depends on DM_GPIO
> > +   default y
> > +   help
> > + If a GPIO is optional, the GPIO descriptor is NULL. In that
> > + case, calls should bail out instead of causing NULL pointer
> > + access.
> 
> Can you update the gpio function docs in the header file with this info?

Ok.

> > +
> >  config GPIO_HOG
> > bool "Enable GPIO hog support"
> > depends on DM_GPIO
> > diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> > index 9eeab22eef..6b97d3aaff 100644
> > --- a/drivers/gpio/gpio-uclass.c
> > +++ b/drivers/gpio/gpio-uclass.c
> > @@ -20,6 +20,25 @@
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > +#ifdef CONFIG_GPIO_VALIDATE_DESC
> > +/*
> > + * This descriptor validation needs to be inserted verbatim into each
> > + * function taking a descriptor, so we need to use a preprocessor
> > + * macro to avoid endless duplication. If the desc is NULL it is an
> > + * optional GPIO and calls should just bail out.
> 
> Is the macro defined elsewhere?

It comes from the previous version of this patch. The macro has been 
removed in this version. Will fix.
 
> > + */
> > +static inline int validate_desc(const struct gpio_desc *desc)
> > +{
> > +   if (!desc)
> > +   return 0;
> > +   if (IS_ERR(desc))
> > +   return PTR_ERR(desc);
> > +   if (!desc->dev)
> > +   return -EINVAL;
> > +   return 1;
> > +}
> 
> #else
> static inline int validate_desc(const struct gpio_desc *desc)
> {
> return 1;
> }
> 
> > +#endif
> > +
> >  /**
> >   * gpio_desc_init() - Initialize the GPIO descriptor
> >   *
> > @@ -303,11 +322,19 @@ int gpio_hog_lookup_name(const char *name, struct 
> > gpio_desc **desc)
> >
> >  int dm_gpio_request(struct gpio_desc *desc, const char *label)
> >  {
> > -   struct udevice *dev = desc->dev;
> > +   struct udevice *dev;
> > struct gpio_dev_priv *uc_priv;
> > char *str;
> > int ret;
> >
> > +#ifdef CONFIG_GPIO_VALIDATE_DESC
> 
> Please drop the #ifdefs and use the static inline thing from above.

Ok.
 
> > +   ret = validate_desc(desc);
> > +   if (ret <= 0)
> > +   return ret;
> 
> Here you are returning 0 when you did not successfully request the
> GPIO.You should return -ENOENT, otherwise callers have no idea what
> happened and will get confused.

Ok. To be clear, it is ok to return 0 in other places this check is 
done, right?

> > +#endif
> > +
> > +   dev = desc->dev;
> > +
> > uc_priv = dev_get_uclass_priv(dev);
> > if (uc_priv->name[desc->offset])
> > return -EBUSY;
> > @@ -434,6 +461,14 @@ static int check_reserved(const struct gpio_desc 
> > *desc, const c

Re: rockchip: correctly set vop0 or vop1

2020-06-08 Thread Patrick Wildt
On Mon, Jun 08, 2020 at 02:24:32PM +0200, Arnaud Patard wrote:
> Patrick Wildt  writes:
> 
> > On Mon, Jun 08, 2020 at 10:18:19AM +0200, Arnaud Patard wrote:
> >> Patrick Wildt  writes:
> >> 
> >> Hi,
> >> 
> >> > The EDP_LCDC_SEL bit has to be set correctly to select vop0 or
> >> > vop1, but so far we have set it in both conditions, which is not
> >> > correct.
> >> >
> >> > Can someone verify this is the correct way round?  vop1 -> set,
> >> > vop0 -> clear?
> >> >
> >> > Signed-off-by: Patrick Wildt 
> >> >
> >> > diff --git a/drivers/video/rockchip/rk_edp.c 
> >> > b/drivers/video/rockchip/rk_edp.c
> >> > index 92188be9275..000bd481408 100644
> >> > --- a/drivers/video/rockchip/rk_edp.c
> >> > +++ b/drivers/video/rockchip/rk_edp.c
> >> > @@ -1062,7 +1062,8 @@ static int rk_edp_probe(struct udevice *dev)
> >> >  rk_setreg(&priv->grf->soc_con12, 1 << 4);
> >> >  
> >> >  /* select epd signal from vop0 or vop1 */
> >> > -rk_setreg(&priv->grf->soc_con6, (vop_id == 1) ? (1 << 5) : (1 
> >> > << 5));
> >> > +rk_clrsetreg(&priv->grf->soc_con6, (1 << 5),
> >> > +(vop_id == 1) ? (1 << 5) : (0 << 5));
> >> 
> >> While working on PBP EDP support, found this too but I'm not sure it's
> >> fine or not. For rk3399, my (not yet published) patch is doing:
> >> 
> >> +   if (vop_id == 0)
> >> +   rk_clrreg(&priv->grf->soc_con20, (1 << 5));
> >> +   else
> >> +   rk_setreg(&priv->grf->soc_con20, (1 << 5));
> >> 
> >> I believe that the rk3288 may need similar treatment but I've yet to
> >> look at the rk3288 manual.
> >> 
> >> Arnaud
> >
> > Yes, it does.  If you look at the linux code, they have:
> >
> > static const struct rockchip_dp_chip_data rk3399_edp = {
> > .lcdsel_grf_reg = RK3399_GRF_SOC_CON20,
> > .lcdsel_big = HIWORD_UPDATE(0, RK3399_EDP_LCDC_SEL),
> > .lcdsel_lit = HIWORD_UPDATE(RK3399_EDP_LCDC_SEL, 
> > RK3399_EDP_LCDC_SEL),
> > .chip_type = RK3399_EDP,
> > };
> >
> > static const struct rockchip_dp_chip_data rk3288_dp = {
> > .lcdsel_grf_reg = RK3288_GRF_SOC_CON6,
> > .lcdsel_big = HIWORD_UPDATE(0, RK3288_EDP_LCDC_SEL),
> > .lcdsel_lit = HIWORD_UPDATE(RK3288_EDP_LCDC_SEL, 
> > RK3288_EDP_LCDC_SEL),
> > .chip_type = RK3288_DP,
> > };
> >
> > which indicates that for rk3399 *and* rk3288 the bit has to be set to
> > select "lit".  Now your diff looks equivalent to mine, apart from using
> > a different operation to achieve the same goal.
> >
> > The linux code does
> >
> > ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
> > if (ret < 0)
> > return;
> >
> > if (ret)
> > val = dp->data->lcdsel_lit;
> > else
> > val = dp->data->lcdsel_big;
> >
> > Assuming that endpoint_id essentiall returns vop id 0 or vop id 1, this
> > would mean that vop1 -> lit -> set bit and vop0 -> big -> clr bit.
> >
> > That said, my diff seems to be fine, and your RK3399 code as well.  Do
> > you agree?
> 
> According to the code you've shown, it should be fine for rk3288 I guess
> but not for rk3399. Please note that it's grf soc_con6 register for rk3288
> but grf soc_con20 for rk3399.
> 
> Arnaud

Exactly, which is why you had that if defined() in your diff, to compile
one part of the code for RK3288, and the other for RK3399. :)  The bit
though happens to be the same.


Re: Pull request for UEFI sub-system for efi-2020-07-rc4 (2)

2020-06-08 Thread Tom Rini
On Sat, Jun 06, 2020 at 08:14:49AM +0200, Heinrich Schuchardt wrote:

> The following changes since commit 88bd5b1793600b0f5f25c3d236b4d049fb986140:
> 
>   configs: Resync with savedefconfig (2020-06-04 19:29:09 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2020-07-rc4-2
> 
> for you to fetch changes up to 325567d3c59fba32bdbf33a8ec981a8ccb096780:
> 
>   efi_loader: comments EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL (2020-06-05
> 04:04:41 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH v2 1/1] arm: sunxi: increase SYS_MALLOC_F_LEN

2020-06-08 Thread Jagan Teki
On Mon, Jun 8, 2020 at 8:25 AM Heinrich Schuchardt  wrote:
>
> On 08.06.20 13:50, Jagan Teki wrote:
> > On Mon, Jun 8, 2020 at 6:59 AM Heinrich Schuchardt  
> > wrote:
> >>
> >> The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
> >> additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
> >> relocation.
> >>
> >> CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
> >> verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
> >>
> >> CONFIG_LOG=Y is another setting requiring additional early malloc
> >> area, cf. log_init().
> >>
> >> When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
> >> we see as output in main U-Boot
> >>
> >> alloc_simple() alloc space exhausted
> >>
> >> With this patch the default values of SYS_MALLOC_F_LEN is raised to 0x2000.
> >> The default for SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI is explicitely set to
> >> 0x400 to avoid an increased usage of SRAM on elder SoCs.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >
> > Reviewed-by: Jagan Teki 
> >
>
> Thanks for reviewing.
>
> All sunxi boards have at least 32 KiB SRAM and only this 32 KiB used by
> U-Boot for SPL on all sunxi boards. A BananaPi with A20 CPU boots fine
> with SPL_SYS_MALLOC_F_LEN=0x2000. So it seems that also version 1 of the
> patch was on the safe side.

Okay. Planning to push this in MW, since the existing boards look fine.

Jagan.


Re: [PATCH 1/7] Revert "mmc: zynq: parse dt when probing"

2020-06-08 Thread Michal Simek
On 27. 05. 20 8:44, Jaehoon Chung wrote:
> Hi
> 
> On 5/22/20 7:44 PM, Michal Simek wrote:
>> From: Ashok Reddy Soma 
>>
>> This reverts commit 942b5fc03218d1c94468fc658e7dec65dabcc830.
>>
>> This is partial revert of the above commit.
>>
>> mmc_of_parse() is reading no-1-8-v from device tree and if set,
>> it is clearing the UHS speed capabilities of cfg->host_caps.
>> cfg->host_caps &= ~(UHS_CAPS | MMC_MODE_HS200 |
>>  MMC_MODE_HS400 | MMC_MODE_HS400_ES);
>>
>> This is still missing to clear UHS speeds like SDHCI_SUPPORT_SDR104,
>> SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50.
>>
>> Even if we clear the flags SDHCI_SUPPORT_XXX in mmc_of_parse(),
>> these speed flags are getting set again in cfg->host_caps in
>> sdhci_setup_cfg().
>>
>> The reason for this is, SDHCI_SUPPORT_XXX flags are cleared
>> only if controller is not capable of supporting MMC_VDD_165_195 volts.
>>
>> if (caps & SDHCI_CAN_VDD_180)
>>  cfg->voltages |= MMC_VDD_165_195;
>>
>> if (!(cfg->voltages & MMC_VDD_165_195))
>>  caps_1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_SUPPORT_SDR50 |
>>  SDHCI_SUPPORT_DDR50);
> 
> I don't have a target to test with zynq_sdhci.
> If there is no effect no-1-8-v property, i think that it needs to fix main 
> problem.
> I will check about this.

Have you had any time to take a look at it?

Thanks,
Michal


Re: [PATCH 3/5] arm: qemu: implement enable_caches()

2020-06-08 Thread Tom Rini
On Sat, Jun 06, 2020 at 10:50:59PM +0200, Heinrich Schuchardt wrote:
> On 6/6/20 7:15 PM, Ard Biesheuvel wrote:
> > Add an override for enable_caches to enable the I and D caches, along
> > with the cached 1:1 mapping of all of DRAM. This is needed for running
> > U-Boot under virtualization with QEMU/kvm.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  board/emulation/qemu-arm/qemu-arm.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c 
> > b/board/emulation/qemu-arm/qemu-arm.c
> > index 69e8ef46f1f5..1b0d543b93c1 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -4,6 +4,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -94,6 +95,12 @@ void *board_fdt_blob_setup(void)
> > return (void *)CONFIG_SYS_SDRAM_BASE;
> >  }
> >
> > +void enable_caches(void)
> > +{
> > +icache_enable();
> > +dcache_enable();
> > +}
> > +
> 
> For other ARM architectures I have seen:
> 
> int arch_cpu_init(void)
> {
> icache_enable();
>     return 0;
> }
> 
> void enable_caches(void)
> {
>     dcache_enable();
> }
> 
> Some boards have
> 
> if (!icache_status())
>   icache_enable();
> 
> others
> 
> #if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
>   icache_enable();
> #endif
> 
> Tom could you, please, advice what is the correct way to do it.

Off-hand?  Dealing with it per SoC/mach/board as we do today.  Sometimes
we need a dcache_disable() before the dcache_enable() as well to clear
out previous mappings.  So dropping this in here is probably the best
choice for qemu-arm.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH] nvme: Invalidate dcache before submitting admin cmd

2020-06-08 Thread Bin Meng
On Sun, Jun 7, 2020 at 7:22 PM Jagan Teki  wrote:
>
> Some architecture like ARM Cortex A53, A72 would need
> to invalidate dcache to sync the cache with the memory
> contents before flushing the cache to memory.
>
> The NVME here submitting the admin command using dma_addr
> to the memory without prior cache invalidation. This causing
> dma_addr is pointing to an invalid location in the memory
> and found the sane nvme_ctrl result.

insane?

>
> Below example shows the nvme disk scan result improper result
>
> => nvme scan
> nvme_get_info_from_identify: nn = 544502629, vwc = 100,
> sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105
>
> So, invalidating the cache before submitting the admin command
> makes the dma_addr points to a valid location in the memory.
>
> Cc: Andre Przywara 
> Reported-by: Suniel Mahesh 
> Signed-off-by: Michael Trimarchi 
> Signed-off-by: Jagan Teki 
> Tested-by: Suniel Mahesh 
> ---
>  drivers/nvme/nvme.c | 3 +++
>  1 file changed, 3 insertions(+)
>

Reviewed-by: Bin Meng 


[PATCH 1/1] include/configs: ls1012a: Remove fdt_high env variable

2020-06-08 Thread udit . agarwal
From: Udit Agarwal 

Remove "fdt_high" environment variable to use the bootm_size
to safely contain a kernel, device tree and initrd for
relocation.

Signed-off-by: Udit Agarwal 
---
 include/configs/ls1012a2g5rdb.h  | 2 +-
 include/configs/ls1012a_common.h | 2 +-
 include/configs/ls1012afrdm.h| 2 +-
 include/configs/ls1012afrwy.h| 2 +-
 include/configs/ls1012ardb.h | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/configs/ls1012a2g5rdb.h b/include/configs/ls1012a2g5rdb.h
index 869e0ad6b8..ad16fdcbd3 100644
--- a/include/configs/ls1012a2g5rdb.h
+++ b/include/configs/ls1012a2g5rdb.h
@@ -35,7 +35,6 @@
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"verify=no\0"   \
-   "fdt_high=0x\0" \
"initrd_high=0x\0"  \
"fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
@@ -49,6 +48,7 @@
"load_addr=0xa000\0"\
"kernel_size=0x280\0"   \
"kernelheader_size=0x4\0"   \
+   "bootm_size=0x1000\0"   \
"console=ttyS0,115200\0"\
BOOTENV \
"boot_scripts=ls1012ardb_boot.scr\0"\
diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 3bea9a9186..eed12e0234 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -83,11 +83,11 @@
"verify=no\0"   \
"loadaddr=0x8010\0" \
"kernel_addr=0x10\0"\
-   "fdt_high=0x\0" \
"initrd_high=0x\0"  \
"kernel_start=0x100\0"  \
"kernel_load=0xa000\0"  \
"kernel_size=0x280\0"   \
+   "bootm_size=0x1000\0"   \
 
 #undef CONFIG_BOOTCOMMAND
 #ifdef CONFIG_TFABOOT
diff --git a/include/configs/ls1012afrdm.h b/include/configs/ls1012afrdm.h
index 54ea43420f..dae06535d6 100644
--- a/include/configs/ls1012afrdm.h
+++ b/include/configs/ls1012afrdm.h
@@ -25,7 +25,6 @@
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"verify=no\0"   \
"fdt_high=0x\0" \
-   "initrd_high=0x\0"  \
"fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
"scriptaddr=0x8000\0"   \
@@ -35,6 +34,7 @@
"fdt_addr_r=0x9000\0"   \
"load_addr=0x9600\0"\
"kernel_size=0x280\0"   \
+   "bootm_size=0x1000\0"   \
"console=ttyS0,115200\0"\
BOOTENV \
"boot_scripts=ls1012afrdm_boot.scr\0"   \
diff --git a/include/configs/ls1012afrwy.h b/include/configs/ls1012afrwy.h
index 1ea6548015..eeb1fa8122 100644
--- a/include/configs/ls1012afrwy.h
+++ b/include/configs/ls1012afrwy.h
@@ -46,7 +46,6 @@
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"verify=no\0"   \
-   "fdt_high=0x\0" \
"initrd_high=0x\0"  \
"fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
@@ -66,6 +65,7 @@
"load_addr=0x9200\0"\
"kernel_size=0x280\0"   \
"kernelheader_size=0x4\0"   \
+   "bootm_size=0x1000\0"   \
"console=ttyS0,115200\0"\
"BOARD=ls1012afrwy\0"   \
BOOTENV \
diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index 8fb75650e2..428130ee57 100644
--- a/include/configs/ls1012ardb.h
+++ b/include/configs/ls1012ardb.h
@@ -54,7 +54,6 @@
 #undef CONFIG_EXTRA_ENV_SETTINGS
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"verify=no\0"   \
-   "fdt_high=0x\0" \
"initrd_high=0x\0"  \
"fdt_addr=0x00f0\0" \
"kernel_addr=0x0100\0"  \
@@ -68,6 +67,7 @@
"load_addr=0xa000\0"\
"kernel_size=0x280\0"   \
"kernelheader_size=0x4\0"   \
+   "bootm_size=0x1000\0"   \
"console=ttyS0,115200\0"\
BOOTENV \
"boot_scripts=ls1012ardb_boot.scr\0"\
-- 
2.17.1



Re: [PATCH] nvme: Invalidate dcache before submitting admin cmd

2020-06-08 Thread André Przywara
On 07/06/2020 12:22, Jagan Teki wrote:

Hi,

(CC: ing Mark)

Without looking to deep, I think invalidating the cache might be the
right thing to do, but the rationale or at least the wording of it seems
somehow flawed:

> Some architecture like ARM Cortex A53, A72 would need

Please don't mix the term "architecture" with actual implementations.
And the problem is more general, I would say. This *might* be a case
here where this is due to speculation, and then I would expect it to
only show on an A72, for instance. I guess this is about NVMe on RK3399?
Does U-Boot run on an A53 or an A72 core?

> to invalidate dcache to sync the cache with the memory
> contents before flushing the cache to memory.

That is somewhat confusing. What does "sync" and "flush" mean here?
AFAIK only "clean" and "invalidate" are clearly defined terms.
The command buffer is cleaned to DRAM in nvme_submit_cmd(), so this is
purely about the buffer for the *return* data, in which case I would
expect this being a pure invalidation problem.

This issue looks like the case described on slide 30 and 31 here:
https://elinux.org/images/6/6d/Rutland2.pdf

> The NVME here submitting the admin command using dma_addr
> to the memory without prior cache invalidation. This causing
> dma_addr is pointing to an invalid location in the memory

This does not sound right: dma_addr is always pointing to the right
location in memory.
The actual reason this fixes something might be that (some) cache lines
of the DMA buffer were dirty and were evicted *before* the existing
invalidation, but *after* the DMA transfer. That sounds unlikely in an
U-Boot context, though, but would match the case described in Mark's slides.

So there might be more to this. Are we missing a barrier here? Should we
use coherent buffers (memory mapped as un-cached) for the return DMA in
the first place (but I don't think U-Boot provides those)?

> and found the sane nvme_ctrl result.
> 
> Below example shows the nvme disk scan result improper result
> 
> => nvme scan
> nvme_get_info_from_identify: nn = 544502629, vwc = 100,
> sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105
> 
> So, invalidating the cache before submitting the admin command
> makes the dma_addr points to a valid location in the memory.

If this shows up already, I think we should address all the comments in
the driver where it says we should do cache maintenance. And it makes me
wonder how this actually works today ...

Cheers,
Andre.

> 
> Cc: Andre Przywara  
> Reported-by: Suniel Mahesh 
> Signed-off-by: Michael Trimarchi 
> Signed-off-by: Jagan Teki 
> Tested-by: Suniel Mahesh 
> ---
>  drivers/nvme/nvme.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> index 0357aba7f1..fc64d93ab8 100644
> --- a/drivers/nvme/nvme.c
> +++ b/drivers/nvme/nvme.c
> @@ -466,6 +466,9 @@ int nvme_identify(struct nvme_dev *dev, unsigned nsid,
>  
>   c.identify.cns = cpu_to_le32(cns);
>  
> + invalidate_dcache_range(dma_addr,
> + dma_addr + sizeof(struct nvme_id_ctrl));
> +
>   ret = nvme_submit_admin_cmd(dev, &c, NULL);
>   if (!ret)
>   invalidate_dcache_range(dma_addr,
> 



Re: [PATCH] nvme: Invalidate dcache before submitting admin cmd

2020-06-08 Thread Michael Nazzareno Trimarchi
Hi

On Mon, Jun 8, 2020 at 3:52 PM André Przywara  wrote:
>
> On 07/06/2020 12:22, Jagan Teki wrote:
>
> Hi,
>
> (CC: ing Mark)
>
> Without looking to deep, I think invalidating the cache might be the
> right thing to do, but the rationale or at least the wording of it seems
> somehow flawed:
>
> > Some architecture like ARM Cortex A53, A72 would need
>
> Please don't mix the term "architecture" with actual implementations.
> And the problem is more general, I would say. This *might* be a case
> here where this is due to speculation, and then I would expect it to
> only show on an A72, for instance. I guess this is about NVMe on RK3399?
> Does U-Boot run on an A53 or an A72 core?
>
> > to invalidate dcache to sync the cache with the memory
> > contents before flushing the cache to memory.
>

We will adjust commit message. The idea is that when we invalidate after the DMA
transfer, a cache flush happen for the invalidation itself

> That is somewhat confusing. What does "sync" and "flush" mean here?
> AFAIK only "clean" and "invalidate" are clearly defined terms.
> The command buffer is cleaned to DRAM in nvme_submit_cmd(), so this is
> purely about the buffer for the *return* data, in which case I would
> expect this being a pure invalidation problem.
>

Correct

> This issue looks like the case described on slide 30 and 31 here:
> https://elinux.org/images/6/6d/Rutland2.pdf
>

Thank you for point out to the slide

> > The NVME here submitting the admin command using dma_addr
> > to the memory without prior cache invalidation. This causing
> > dma_addr is pointing to an invalid location in the memory
>
> This does not sound right: dma_addr is always pointing to the right
> location in memory.
> The actual reason this fixes something might be that (some) cache lines
> of the DMA buffer were dirty and were evicted *before* the existing
> invalidation, but *after* the DMA transfer. That sounds unlikely in an
> U-Boot context, though, but would match the case described in Mark's slides.

Does it not depend on how invalidation work in the particular CPU?

>
> So there might be more to this. Are we missing a barrier here? Should we
> use coherent buffers (memory mapped as un-cached) for the return DMA in
> the first place (but I don't think U-Boot provides those)?

Right, I don't find a better way and yes this is  general problem in uboot

Michael


>
> > and found the sane nvme_ctrl result.
> >
> > Below example shows the nvme disk scan result improper result
> >
> > => nvme scan
> > nvme_get_info_from_identify: nn = 544502629, vwc = 100,
> > sn = dev_0T, mn = `�\�, fr = t_part, mdts = 105
> >
> > So, invalidating the cache before submitting the admin command
> > makes the dma_addr points to a valid location in the memory.
>
> If this shows up already, I think we should address all the comments in
> the driver where it says we should do cache maintenance. And it makes me
> wonder how this actually works today ...
>
> Cheers,
> Andre.
>
> >
> > Cc: Andre Przywara 
> > Reported-by: Suniel Mahesh 
> > Signed-off-by: Michael Trimarchi 
> > Signed-off-by: Jagan Teki 
> > Tested-by: Suniel Mahesh 
> > ---
> >  drivers/nvme/nvme.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > index 0357aba7f1..fc64d93ab8 100644
> > --- a/drivers/nvme/nvme.c
> > +++ b/drivers/nvme/nvme.c
> > @@ -466,6 +466,9 @@ int nvme_identify(struct nvme_dev *dev, unsigned nsid,
> >
> >   c.identify.cns = cpu_to_le32(cns);
> >
> > + invalidate_dcache_range(dma_addr,
> > + dma_addr + sizeof(struct nvme_id_ctrl));
> > +
> >   ret = nvme_submit_admin_cmd(dev, &c, NULL);
> >   if (!ret)
> >   invalidate_dcache_range(dma_addr,
> >
>


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |


[PATCH] rk3399: Add BOOTENV_SF command

2020-06-08 Thread Jagan Teki
Add missing BOOTENV_SF command in rk3399 config.

Fix it.

Fixes: f263b860acf8 ("rk3399: Enable SF distro bootcmd")
Signed-off-by: Jagan Teki 
Reported-by: Suniel Mahesh 
Tested-by: Suniel Mahesh 
---
 include/configs/rk3399_common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index f0ae6e67a7..e63ebb14f7 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -67,6 +67,7 @@
"partitions=" PARTS_DEFAULT \
ROCKCHIP_DEVICE_SETTINGS \
BOOTENV \
+   BOOTENV_SF \
"altbootcmd=" \
"setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \
"run distro_bootcmd\0"
-- 
2.20.1



Re: [PATCH 01/10] dtoc: add support to scan drivers

2020-06-08 Thread Walter Lozano

Hi Simon,

On 4/6/20 12:59, Simon Glass wrote:

Hi Walter,

On Fri, 29 May 2020 at 12:15, Walter Lozano  wrote:

Currently dtoc scans dtbs to convert them to struct platdata and
to generate U_BOOT_DEVICE entries. These entries need to be filled
with the driver name, but at this moment the information used is the
compatible name present in the dtb. This causes that only nodes with
a compatible name that matches a driver name generate a working
entry.

In order to improve this behaviour, this patch adds to dtoc the
capability of scan drivers source code to generate a list of valid driver
names. This allows to rise a warning in the case that an U_BOOT_DEVICE
entry will try to use a name not valid.

Additionally, in order to add more flexibility to the solution, adds the
U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an
easy way to declare driver name aliases. Thanks to this, dtoc can look
for the driver name based on its alias when it populates the U_BOOT_DEVICE
entry.

Signed-off-by: Walter Lozano 
---
  include/dm/device.h|  7 
  tools/dtoc/dtb_platdata.py | 83 --
  2 files changed, 86 insertions(+), 4 deletions(-)

diff --git a/include/dm/device.h b/include/dm/device.h
index 975eec5d0e..2cfe10766f 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -282,6 +282,13 @@ struct driver {
  #define DM_GET_DRIVER(__name)  \
 ll_entry_get(struct driver, __name, driver)

+/**
+ * Declare a macro to state a alias for a driver name. This macro will
+ * produce no code but its information will be parsed by tools like
+ * dtoc
+ */
+#define U_BOOT_DRIVER_ALIAS(__name, __alias)
+
  /**
   * dev_get_platdata() - Get the platform data for a device
   *
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index ecfe0624d1..23cfda2f88 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -13,6 +13,8 @@ static data.

  import collections
  import copy
+import os
+import re
  import sys

  from dtoc import fdt
@@ -140,6 +142,9 @@ class DtbPlatdata(object):
  _include_disabled: true to include nodes marked status = "disabled"
  _outfile: The current output file (sys.stdout or a real file)
  _lines: Stashed list of output lines for outputting in the future
+_aliases: Dict that hold aliases for compatible strings

key: The driver name, i.e. the part between brackets in U_BOOT_DRIVER(xx)  ??
value: ...

Noted.

+_drivers: List of valid driver names found in drivers/
+_driver_aliases: Dict that holds aliases for driver names

key:
vaue:

OK.



  """
  def __init__(self, dtb_fname, include_disabled):
  self._fdt = None
@@ -149,6 +154,35 @@ class DtbPlatdata(object):
  self._outfile = None
  self._lines = []
  self._aliases = {}
+self._drivers = []
+self._driver_aliases = {}
+
+def get_normalized_compat_name(self, node):
+"""Get a node's normalized compat name
+
+Returns a valid driver name by retrieving node's first compatible
+string as a C identifier and perfomrming a check against _drivers

performing

Noted.



+and a lookup in driver_aliases rising a warning in case of failure.

s/ rising/, printing/

OK.



+
+Args:
+node: Node object to check
+Return:
+Tuple:
+Driver name associated with the first compatible string
+List of C identifiers for all the other compatible strings
+(possibly empty)

Can you update this comment to explain what is returned when it is not found?

Sure.

+"""
+compat_c, aliases_c = get_compat_name(node)
+if compat_c not in self._drivers:
+compat_c_old = compat_c
+compat_c = self._driver_aliases.get(compat_c)
+if not compat_c:
+print('WARNING: the driver %s was not found in the driver 
list' % (compat_c_old))

This creates lots of warnings at present. Either we need a patch to
clean up the differences in the source code, or we need to disable the
warning.



Regarding this, maybe we should have a list of driver names we don't 
expect to support, like simple_bus. For this to work probably the best 
approach is to have a config option similar to CONFIG_OF_REMOVE_PROPS, 
so each config can add their owns.



Also the warning is not really actionable. It needs to add mention of
U_BOOT_DEVICE and ...ALIAS.

I agree with you. Thanks.


In future we can scan the compatible strings and tell the user what
changes to make, I suppose.

Yes, it will be a great improvement!



+compat_c = compat_c_old
+else: # pragma: no cover

Need to fix the coverage here

Noted. I will a few more tests.



+aliases_c = [compat_c_old] + aliases_c
+
+return compat_c, aliases_c

  def setup_output(self, fname):

Re: [PATCH 02/10] dtoc: add option to disable warnings

2020-06-08 Thread Walter Lozano

Hi Simon,

On 4/6/20 12:59, Simon Glass wrote:

Hi Walter,

On Fri, 29 May 2020 at 12:15, Walter Lozano  wrote:

As dtoc now performs checks for valid driver names, when running dtoc
tests several warnings arise as these tests don't use valid driver
names.

This patch adds an option to disable those warning, which is only
intended for running tests.

Signed-off-by: Walter Lozano 
---
  tools/dtoc/dtb_platdata.py | 11 +---
  tools/dtoc/test_dtoc.py| 54 +++---
  2 files changed, 34 insertions(+), 31 deletions(-)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 23cfda2f88..0a54188348 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -141,17 +141,19 @@ class DtbPlatdata(object):
  _valid_nodes: A list of Node object with compatible strings
  _include_disabled: true to include nodes marked status = "disabled"
  _outfile: The current output file (sys.stdout or a real file)
+_warning_disabled: true to disable warnings about driver names not 
found
  _lines: Stashed list of output lines for outputting in the future
  _aliases: Dict that hold aliases for compatible strings
  _drivers: List of valid driver names found in drivers/
  _driver_aliases: Dict that holds aliases for driver names
  """
-def __init__(self, dtb_fname, include_disabled):
+def __init__(self, dtb_fname, include_disabled, warning_disable):
  self._fdt = None
  self._dtb_fname = dtb_fname
  self._valid_nodes = None
  self._include_disabled = include_disabled
  self._outfile = None
+self._warning_disable = warning_disable
  self._lines = []
  self._aliases = {}
  self._drivers = []
@@ -177,7 +179,8 @@ class DtbPlatdata(object):
  compat_c_old = compat_c
  compat_c = self._driver_aliases.get(compat_c)
  if not compat_c:
-print('WARNING: the driver %s was not found in the driver 
list' % (compat_c_old))
+if not self._warning_disable: # pragma: no cover

Need coverage for this.

No problem!



+print('WARNING: the driver %s was not found in the driver 
list' % (compat_c_old))
  compat_c = compat_c_old
  else: # pragma: no cover
  aliases_c = [compat_c_old] + aliases_c
@@ -623,7 +626,7 @@ class DtbPlatdata(object):
  nodes_to_output.remove(node)


-def run_steps(args, dtb_file, include_disabled, output):
+def run_steps(args, dtb_file, include_disabled, output, warning_disable = 
False):

no spaces around =

Sure.

  """Run all the steps of the dtoc tool

  Args:
@@ -635,7 +638,7 @@ def run_steps(args, dtb_file, include_disabled, output):
  if not args:
  raise ValueError('Please specify a command: struct, platdata')

-plat = DtbPlatdata(dtb_file, include_disabled)
+plat = DtbPlatdata(dtb_file, include_disabled, warning_disable)
  plat.scan_drivers()
  plat.scan_dtb()
  plat.scan_tree()
diff --git a/tools/dtoc/test_dtoc.py b/tools/dtoc/test_dtoc.py
index 8498e8303c..a9b605cac8 100755
--- a/tools/dtoc/test_dtoc.py
+++ b/tools/dtoc/test_dtoc.py
@@ -154,12 +154,12 @@ class TestDtoc(unittest.TestCase):
  """Test output from a device tree file with no nodes"""
  dtb_file = get_dtb_file('dtoc_test_empty.dts')
  output = tools.GetOutputFilename('output')
-dtb_platdata.run_steps(['struct'], dtb_file, False, output)
+dtb_platdata.run_steps(['struct'], dtb_file, False, output, True)
  with open(output) as infile:
  lines = infile.read().splitlines()
  self.assertEqual(HEADER.splitlines(), lines)

-dtb_platdata.run_steps(['platdata'], dtb_file, False, output)
+dtb_platdata.run_steps(['platdata'], dtb_file, False, output, True)

Can you create run_test which calls run_steps with that set that to
True, to avoid adding the param everywhere in this file?

Sure, no problem. Thanks!


Regards,

Walter



Re: [PATCH 05/10] core: extend struct driver_info to point to device

2020-06-08 Thread Walter Lozano



On 4/6/20 12:59, Simon Glass wrote:

Hi Walter,

On Fri, 29 May 2020 at 12:15, Walter Lozano  wrote:

Currently when creating an U_BOOT_DEVICE entry a struct driver_info
is declared, which contains the data needed to instantiate the device.
However, the actual device is created at runtime and there is no proper
way to get the device based on its struct driver_info.

This patch extends struct driver_info adding a pointer to udevice which
is populated during the bind process, allowing to generate a set of
functions to get the device based on its struct driver_info.

Signed-off-by: Walter Lozano 
---
  drivers/core/device.c | 26 +++---
  drivers/core/root.c   |  4 
  include/dm/device.h   | 14 ++
  include/dm/platdata.h | 14 ++
  4 files changed, 55 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

Nits below

Thanks for taking the time!

diff --git a/drivers/core/device.c b/drivers/core/device.c
index a0ad080aaf..5adbc30849 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -250,6 +250,7 @@ int device_bind_by_name(struct udevice *parent, bool 
pre_reloc_only,
  {
 struct driver *drv;
 uint platdata_size = 0;
+   int ret = 0;

Can you drop = 0 ?

Noted!



 drv = lists_driver_lookup_name(info->name);
 if (!drv)
@@ -260,9 +261,16 @@ int device_bind_by_name(struct udevice *parent, bool 
pre_reloc_only,
  #if CONFIG_IS_ENABLED(OF_PLATDATA)
 platdata_size = info->platdata_size;
  #endif
-   return device_bind_common(parent, drv, info->name,
-   (void *)info->platdata, 0, ofnode_null(), platdata_size,
-   devp);
+   ret = device_bind_common(parent, drv, info->name,
+(void *)info->platdata, 0, ofnode_null(),
+platdata_size, devp);
+   if (ret)
+   return ret;
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   info->dev = *devp;
+#endif
+
+   return ret;
  }

  static void *alloc_priv(int size, uint flags)
@@ -727,6 +735,18 @@ int device_get_global_by_ofnode(ofnode ofnode, struct 
udevice **devp)
 return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp);
  }

+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+int device_get_by_driver_info(const struct driver_info *info,
+ struct udevice **devp)
+{
+   struct udevice *dev;
+
+   dev = info->dev;
+
+   return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp);
+}
+#endif
+
  int device_find_first_child(const struct udevice *parent, struct udevice 
**devp)
  {
 if (list_empty(&parent->child_head)) {
diff --git a/drivers/core/root.c b/drivers/core/root.c
index c9ee56478a..8f47a6b356 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -346,6 +346,10 @@ int dm_init_and_scan(bool pre_reloc_only)
  {
 int ret;

+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   populate_phandle_data();
+#endif
+
 ret = dm_init(IS_ENABLED(CONFIG_OF_LIVE));
 if (ret) {
 debug("dm_init() failed: %d\n", ret);
diff --git a/include/dm/device.h b/include/dm/device.h
index 2cfe10766f..a3b3e5bc46 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -538,6 +538,20 @@ int device_find_global_by_ofnode(ofnode node, struct 
udevice **devp);
   */
  int device_get_global_by_ofnode(ofnode node, struct udevice **devp);

+/**
+ * device_get_by_driver_info() - Get a device based on driver_info
+ *
+ * Locates a device by its struct driver_info.
+ *
+ * The device is probed to activate it ready for use.
+ *
+ * @info: Struct driver_info

Here you should mention using DM_GET_DRIVER() to find it.

OK, I'll add a reference.

+ * @devp: Returns pointer to device if found, otherwise this is set to NULL
+ * @return 0 if OK, -ve on error
+ */
+int device_get_by_driver_info(const struct driver_info *info,
+ struct udevice **devp);
+
  /**
   * device_find_first_child() - Find the first child of a device
   *
diff --git a/include/dm/platdata.h b/include/dm/platdata.h
index c972fa6936..238379b0e4 100644
--- a/include/dm/platdata.h
+++ b/include/dm/platdata.h
@@ -22,12 +22,14 @@
   * @name:  Driver name
   * @platdata:  Driver-specific platform data
   * @platdata_size: Size of platform data structure
+ * @dev:   Device created from this structure data
   */
  struct driver_info {
 const char *name;
 const void *platdata;
  #if CONFIG_IS_ENABLED(OF_PLATDATA)
 uint platdata_size;
+   struct udevice *dev;
  #endif
  };

@@ -43,4 +45,16 @@ struct driver_info {
  #define U_BOOT_DEVICES(__name) \
 ll_entry_declare_list(struct driver_info, __name, driver_info)

+/* Get a pointer to a given driver */
+#define DM_GET_DEVICE(__name)  \
+   ll_entry_get(struct driver_info, __name, driver_info)
+
+/**
+ * populate_phandle_data() - Populates ph

Re: [PATCH 07/10] dm: doc: update of-plat with new phandle support

2020-06-08 Thread Walter Lozano

Hi Simon,

On 4/6/20 12:59, Simon Glass wrote:

On Fri, 29 May 2020 at 12:15, Walter Lozano  wrote:

Update documentation to reflect the new phandle support when OF_PLATDATA
is used. Now phandles are implemented as pointers to U_BOOT_DEVICE,
which makes it possible to get a pointer to the actual device.

Signed-off-by: Walter Lozano 
---
  doc/driver-model/of-plat.rst | 24 
  1 file changed, 16 insertions(+), 8 deletions(-)

Reviewed-by: Simon Glass 

But note dm_populate_...

I would like it to be easy to see what module/subsystem a function belongs to.



Sure, I totally agree.

Thanks again for your deep review.


Regards,

Walter



Re: [PATCH 09/10] dtoc: update dtb_platdata to support cd-gpios

2020-06-08 Thread Walter Lozano

Hi Simon

On 4/6/20 12:59, Simon Glass wrote:

On Fri, 29 May 2020 at 12:15, Walter Lozano  wrote:

Currently dtoc does not support the property cd-gpios used to declare
the gpios for card detect in mmc.

This patch adds support to cd-gpios property.

Signed-off-by: Walter Lozano 
---
  tools/dtoc/dtb_platdata.py | 13 -
  tools/dtoc/test_dtoc.py|  2 +-
  2 files changed, 9 insertions(+), 6 deletions(-)

Reviewed-by: Simon Glass 

But I think you should mention GPIOs, rather than just cd-gpios, as it
seems this will add support for any GPIO.


Sorry, probably I am missing something, but in order to support GPIOs in 
general we need to support a set of properties such as "cs-gpios", 
"rb-gpios", "gpios" among others.


Do you agree?


Regards,

Walter



[PATCH 1/1] log: uclass_get_name() depends on CONFIG_SPL_DM

2020-06-08 Thread Heinrich Schuchardt
If CONFIG_SPL_DM=n and CONFIG_SPL_LOG=y a build error occurs:

ld.bfd: common/built-in.o: in function `log_get_cat_name':
common/log.c:48: undefined reference to `uclass_get_name'
make[1]: *** [scripts/Makefile.spl:422: spl/u-boot-spl] Error 1

Call uclass_get_name() only if DM is enabled.

Signed-off-by: Heinrich Schuchardt 
---
 common/log.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/common/log.c b/common/log.c
index c5b9b489ca..d7ce74f6b3 100644
--- a/common/log.c
+++ b/common/log.c
@@ -45,7 +45,11 @@ const char *log_get_cat_name(enum log_category_t cat)
if (cat >= LOGC_NONE)
return log_cat_name[cat - LOGC_NONE];

+#if CONFIG_IS_ENABLED(DM)
name = uclass_get_name((enum uclass_id)cat);
+#else
+   name = NULL;
+#endif

return name ? name : "";
 }
--
2.26.2



Re: [PATCH] test_sleep.py: make sleep time and margin configurable

2020-06-08 Thread Stephen Warren
On 6/4/20 9:24 AM, Heiko Schocher wrote:
> make the sleep time and the margin configurable.

Reviewed-by: Stephen Warren 


Re: [PATCH] test_sleep.py: make sleep time and margin configurable

2020-06-08 Thread Stephen Warren
On 6/7/20 7:45 AM, Simon Glass wrote:
> On Thu, 4 Jun 2020 at 09:24, Heiko Schocher  wrote:
>>
>> make the sleep time and the margin configurable.
>>
>> Signed-off-by: Heiko Schocher 
>> ---
>>
>> travis build:
>> https://travis-ci.org/github/hsdenx/u-boot-test/builds/694545225
>>
>> This patch is needed as I start test/py now within tbot [1]. On
>> some configurations U-Boot is compiled on a build machine for
>> example in munich, while the board under test is in my lab in
>> hungary.
>>
>> So the 0.25 seconds default margin is often to low because
>> of latencies on the net.
>>
>> See as an example configuration (within tbot):
>>
>> https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/aristainetos.py#L29
>>
>> [1] http://tbot.tools/modules/tc.html#u-boot-test-py
>>
>>  test/py/tests/test_sleep.py | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> Related, at some point we should change sandbox to fake the time
> movement since this test currently waits for three seconds even on
> sandbox.

We definitely shouldn't do that; that's the exact kind of failure this
test is intended to detect.


Re: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc

2020-06-08 Thread Rayagonda Kokatanur
Hi Simon,

On Thu, Jun 4, 2020 at 8:30 AM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
>  wrote:
> >
> > Hi Simon,
> >
> > On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > >  wrote:
> > > >
> > > > Hi Thomas,
> > > >
> > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> > > >  wrote:
> > > > >
> > > > > Rayagonda Kokatanur  writes:
> > > > >
> > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  
> > > > > > wrote:
> > > > > >>
> > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur 
> > > > > >> wrote:
> > > > > >> > Hi Tom,
> > > > > >> >
> > > > > >> >
> > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini  
> > > > > >> > wrote:
> > > > > >> > >
> > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda Kokatanur 
> > > > > >> > > wrote:
> > > > > >> > >
> > > > > >> > > > This is the second patch set series prepared on top of the
> > > > > >> > > > first patch set ("add initial support for broadcom NS3 soc").
> > > > > >> > > >
> > > > > >> > > > This patch set will add following,
> > > > > >> > > > -dt nodes and defconfig options for basic device like 
> > > > > >> > > > pinctrl,
> > > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > >> > > > -start wdt service
> > > > > >> > > > -Enable GPT commands
> > > > > >> > > > -Enable EXT4 and FAT fs support
> > > > > >> > >
> > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either come 
> > > > > >> > > from
> > > > > >> > > mainline Linux or at least linux-next and have had some level 
> > > > > >> > > upstream
> > > > > >> > > review, right?  Thanks!
> > > > > >> >
> > > > > >> > Yes. All the DTS changes are merged in the Linux and are 
> > > > > >> > available at
> > > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > > >>
> > > > > >> Great.  Please reference the release you're taking these from as 
> > > > > >> that
> > > > > >> will make future resyncs easier.  Thanks!
> > > > > >
> > > > > > It's Linux v5.6.
> > > > >
> > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > > looked at the mainline Linux device trees and I couldn't easily see 
> > > > > the
> > > > > correspondence.  Will the renaming complicate synchronization?
> > > >
> > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > >
> > > If there is no U-Boot driver for a particular node then it will be
> > > ignored. It is easier to keep them in sync if they are the same in
> > > U-Boot and Linux.
> > >
> > > > Please let me know.
> > >
> > > That is implied by your question above :-)
> >
> > NS3 board is derivative of the existing bcm95874t board
> > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> >
> > I compared the dt file size between uboot and Linux.
> > Uboot dt size = 9K
> > Linux dt size  = 41K (32K extra)
> >
> > In uboot we have 8MB non-volatile SPI flash memory.
> > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > space is allocated to other components
> > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> >
> > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > will use extra 33K memory of allocated 1.5MB.
> > This increase in 33K will reduce total memory availability for u-boot
> > and other features (like ARM trusted firmware, Op-TEE OS) development
> > in future.
> > Hence we anticipate qpsi memory shortage going ahead for new features.
> >
> > So please let me know your view on maintaining different dt files in uboot.
>
> Sounds like you have plenty of memory, actually. Is U-Boot the first
> thing to load?
>
> I think it is important to use the same filename and have the same DT
> contents where they are present in U-Boot. But if you want to leave
> out nodes, etc., that seems OK to me. It should be easy enough to meld
> in the updates later.
>
> I wonder if we should add a way to drop unused nodes for U-Boot
> proper, like we do for SPL?

Thank you for your suggestion.

Right now linux dt files are not upstremed.
Upstreaming linux dt files first and then using the same in uboot will
delay these uboot patch merge.
Hence I am planning to do following,
1. Use one sample dt file with just few basic nodes so that uboot can
be built without any issues.
2. Parallely start linux dt file upstream.
3. Once the linux dt file gets merged, I will pull them into uboot and
submit a patch.

Please let me know.

Best regards,
Rayagonda


>
> Regards,
> Simon


Re: [PATCH] Revert "lib: Improve _parse_integer_fixup_radix base 16 detection"

2020-06-08 Thread Sean Anderson
On 6/8/20 2:24 AM, Michal Simek wrote:
> It is in u-boot mainline from February. Then we had to fix it in April.

Do you have a link/commit hash for said fix?

> In the middle of this I have seen IIC one patchset which improves hex
> handling which is likely better way then this.

Same for this.

> I am fine with reverting this patch but I would also like to see more
> comments in the code to say that we shouldn't really change this.

This seems like a larger issue. There is a lot of code in U-Boot
implementing the C standard library, especially the string library.
Should we have a comment in each file which says something like "The
functions here implement the C standard, think carefully before making
semantic changes"?

--Sean


RE: [RESEND PATCH v2 04/11] net: dwc_eth_qos: Make clk_rx and clk_tx optional

2020-06-08 Thread Patrick DELAUNAY
Dear Marek,

> From: Marek Vasut 
> Sent: lundi 8 juin 2020 11:45
> 
> On 6/8/20 11:29 AM, Patrick DELAUNAY wrote:
> [...]
> >>> we don't select the STM32 glue for the correct compatible, I think I
> >>> will push
> >>>
> >>> static const struct udevice_id eqos_ids[] = {
> >>>   {
> >>>   .compatible = "nvidia,tegra186-eqos",
> >>>   .data = (ulong)&eqos_tegra186_config
> >>>   },
> >>>   {
> >>> - .compatible = "snps,dwmac-4.20a",
> >>> + .compatible = "st,stm32mp1-dwmac",
> >>>   .data = (ulong)&eqos_stm32_config
> >>>   },
> >>>   {
> >>>   .compatible = "fsl,imx-eqos",
> >>>   .data = (ulong)&eqos_imx_config
> >>>   },
> >>>
> >>>   { }
> >>> };
> >>>
> >>> Then you can manage your own glue for rockchip ETH for your compatible.
> >>
> >> You might even want to drop the tegra support on ARM32 , thus save
> >> space by dropping useless code.
> >
> > For information I push 2 patches after this remark:
> >
> > [1]  net: dwc_eth_qos: update the compatible supported for STM32
> >
> > http://patchwork.ozlabs.org/project/uboot/patch/20200514130023.15030-1
> > -patrick.delau...@st.com/
> >
> > [2]  net: dwc_eth_qos: add Kconfig option to select supported configuration
> >   http://patchwork.ozlabs.org/project/uboot/list/?series=181931
> 
> That's for -next, right ?

Yes both are for -next.

It is driver improvement (=code size reduction and cleanup compatible) and no 
bugfix.

Patrick.


Re: [PATCH] Revert "lib: Improve _parse_integer_fixup_radix base 16 detection"

2020-06-08 Thread Simon Glass
Hi,

On Mon, 8 Jun 2020 at 00:24, Michal Simek  wrote:
>
> On 07. 06. 20 7:36, Sean Anderson wrote:
> > This reverts commit 0486497e2b5f4d36fa968a1a60fea358cbf70b65.
> >
> > The strtoul has well-defined semantics. It is defined by the C standard and
> > POSIX. To quote the relevant section of the man pages,
> >
> >> If base is zero or 16, the string may then include a "0x" prefix, and the
> >> number will be read in base 16; otherwise, a zero base is taken as 10
> >> (decimal) unless the next character is '0', in which case it is taken as
> >> 8 (octal).
> >
> > Keeping these semantics is important for several reasons. First, it is very
> > surprising for standard library functions to behave differently than usual.
> > Every other implementation of strtoul has different semantics than the
> > implementation in U-Boot at the moment. Second, it can result in very
> > surprising results from small changes. For example, changing the string
> > "1f" to "20" causes the parsed value to *decrease*. Forcing use of the "0x"
> > prefix to specify hexidecimal numbers is a feature, not a bug. Lastly, this
> > is slightly less performant, since the entire number is parsed twice.
> >
> > This fixes the str_simple_strtoul test failing with
> >
> > test/str_ut.c:29, run_strtoul(): expect_val == val: Expected 0x44b (1099), 
> > got 0x1099ab (1087915)
> > test/str_ut.c:46, str_simple_strtoul(): 0 == run_strtoul(uts, str2, 0, 
> > 1099, 4): Expected 0x0 (0), got 0x1 (1)
> >
> > Signed-off-by: Sean Anderson 
> > CC: Michal Simek 
> > CC: Shiril Tichkule 
> > ---
> >
> >  lib/strto.c | 18 +-
> >  1 file changed, 1 insertion(+), 17 deletions(-)
> >
> > diff --git a/lib/strto.c b/lib/strto.c
> > index 3d77115d4d..c00bb5895d 100644
> > --- a/lib/strto.c
> > +++ b/lib/strto.c
> > @@ -22,25 +22,9 @@ static const char *_parse_integer_fixup_radix(const char 
> > *s, unsigned int *base)
> >   *base = 16;
> >   else
> >   *base = 8;
> > - } else {
> > - int i = 0;
> > - char var;
> > -
> > + } else
> >   *base = 10;
> > -
> > - do {
> > - var = tolower(s[i++]);
> > - if (var >= 'a' && var <= 'f') {
> > - *base = 16;
> > - break;
> > - }
> > -
> > - if (!(var >= '0' && var <= '9'))
> > - break;
> > - } while (var);
> > - }
> >   }
> > -
> >   if (*base == 16 && s[0] == '0' && tolower(s[1]) == 'x')
> >   s += 2;
> >   return s;
> >
>
>
> It is in u-boot mainline from February. Then we had to fix it in April.
> In the middle of this I have seen IIC one patchset which improves hex
> handling which is likely better way then this.
> I am fine with reverting this patch but I would also like to see more
> comments in the code to say that we shouldn't really change this.

Once this revert is in I think we should refrain from changing it
until there are tests to cover its current behaviour, e.g. in str_ut.c

Reviewed-by: Simon Glass 

Regards,
Simon


Re: [PATCH 1/1] log: uclass_get_name() depends on CONFIG_SPL_DM

2020-06-08 Thread Simon Glass
Hi Heinrich,

On Mon, 8 Jun 2020 at 10:04, Heinrich Schuchardt  wrote:
>
> If CONFIG_SPL_DM=n and CONFIG_SPL_LOG=y a build error occurs:
>
> ld.bfd: common/built-in.o: in function `log_get_cat_name':
> common/log.c:48: undefined reference to `uclass_get_name'
> make[1]: *** [scripts/Makefile.spl:422: spl/u-boot-spl] Error 1
>
> Call uclass_get_name() only if DM is enabled.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/log.c | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH] test_sleep.py: make sleep time and margin configurable

2020-06-08 Thread Simon Glass
Hi Stephen,

On Mon, 8 Jun 2020 at 10:43, Stephen Warren  wrote:
>
> On 6/7/20 7:45 AM, Simon Glass wrote:
> > On Thu, 4 Jun 2020 at 09:24, Heiko Schocher  wrote:
> >>
> >> make the sleep time and the margin configurable.
> >>
> >> Signed-off-by: Heiko Schocher 
> >> ---
> >>
> >> travis build:
> >> https://travis-ci.org/github/hsdenx/u-boot-test/builds/694545225
> >>
> >> This patch is needed as I start test/py now within tbot [1]. On
> >> some configurations U-Boot is compiled on a build machine for
> >> example in munich, while the board under test is in my lab in
> >> hungary.
> >>
> >> So the 0.25 seconds default margin is often to low because
> >> of latencies on the net.
> >>
> >> See as an example configuration (within tbot):
> >>
> >> https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/aristainetos.py#L29
> >>
> >> [1] http://tbot.tools/modules/tc.html#u-boot-test-py
> >>
> >>  test/py/tests/test_sleep.py | 14 +++---
> >>  1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > Reviewed-by: Simon Glass 
> >
> > Related, at some point we should change sandbox to fake the time
> > movement since this test currently waits for three seconds even on
> > sandbox.
>
> We definitely shouldn't do that; that's the exact kind of failure this
> test is intended to detect.

No, we're not looking for bugs in sandbox's time handling. We are just
testing the plumbing associated with delaying (timer driver, etc.).

Regards,
Simon


Re: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc

2020-06-08 Thread Simon Glass
Hi Rayagonda,

On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur
 wrote:
>
> Hi Simon,
>
> On Thu, Jun 4, 2020 at 8:30 AM Simon Glass  wrote:
> >
> > Hi Rayagonda,
> >
> > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> >  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> > > >
> > > > Hi Rayagonda,
> > > >
> > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > >  wrote:
> > > > >
> > > > > Hi Thomas,
> > > > >
> > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> > > > >  wrote:
> > > > > >
> > > > > > Rayagonda Kokatanur  writes:
> > > > > >
> > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  
> > > > > > > wrote:
> > > > > > >>
> > > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur 
> > > > > > >> wrote:
> > > > > > >> > Hi Tom,
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini  
> > > > > > >> > wrote:
> > > > > > >> > >
> > > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda 
> > > > > > >> > > Kokatanur wrote:
> > > > > > >> > >
> > > > > > >> > > > This is the second patch set series prepared on top of the
> > > > > > >> > > > first patch set ("add initial support for broadcom NS3 
> > > > > > >> > > > soc").
> > > > > > >> > > >
> > > > > > >> > > > This patch set will add following,
> > > > > > >> > > > -dt nodes and defconfig options for basic device like 
> > > > > > >> > > > pinctrl,
> > > > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > > >> > > > -start wdt service
> > > > > > >> > > > -Enable GPT commands
> > > > > > >> > > > -Enable EXT4 and FAT fs support
> > > > > > >> > >
> > > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either 
> > > > > > >> > > come from
> > > > > > >> > > mainline Linux or at least linux-next and have had some 
> > > > > > >> > > level upstream
> > > > > > >> > > review, right?  Thanks!
> > > > > > >> >
> > > > > > >> > Yes. All the DTS changes are merged in the Linux and are 
> > > > > > >> > available at
> > > > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > > > >>
> > > > > > >> Great.  Please reference the release you're taking these from as 
> > > > > > >> that
> > > > > > >> will make future resyncs easier.  Thanks!
> > > > > > >
> > > > > > > It's Linux v5.6.
> > > > > >
> > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts?  I
> > > > > > looked at the mainline Linux device trees and I couldn't easily see 
> > > > > > the
> > > > > > correspondence.  Will the renaming complicate synchronization?
> > > > >
> > > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > > >
> > > > If there is no U-Boot driver for a particular node then it will be
> > > > ignored. It is easier to keep them in sync if they are the same in
> > > > U-Boot and Linux.
> > > >
> > > > > Please let me know.
> > > >
> > > > That is implied by your question above :-)
> > >
> > > NS3 board is derivative of the existing bcm95874t board
> > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> > >
> > > I compared the dt file size between uboot and Linux.
> > > Uboot dt size = 9K
> > > Linux dt size  = 41K (32K extra)
> > >
> > > In uboot we have 8MB non-volatile SPI flash memory.
> > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > > space is allocated to other components
> > > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> > >
> > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > > will use extra 33K memory of allocated 1.5MB.
> > > This increase in 33K will reduce total memory availability for u-boot
> > > and other features (like ARM trusted firmware, Op-TEE OS) development
> > > in future.
> > > Hence we anticipate qpsi memory shortage going ahead for new features.
> > >
> > > So please let me know your view on maintaining different dt files in 
> > > uboot.
> >
> > Sounds like you have plenty of memory, actually. Is U-Boot the first
> > thing to load?
> >
> > I think it is important to use the same filename and have the same DT
> > contents where they are present in U-Boot. But if you want to leave
> > out nodes, etc., that seems OK to me. It should be easy enough to meld
> > in the updates later.
> >
> > I wonder if we should add a way to drop unused nodes for U-Boot
> > proper, like we do for SPL?
>
> Thank you for your suggestion.
>
> Right now linux dt files are not upstremed.
> Upstreaming linux dt files first and then using the same in uboot will

U-Boot

> delay these uboot patch merge.
> Hence I am planning to do following,
> 1. Use one sample dt file with just few basic nodes so that uboot can
> be built without any issues.
> 2. Parallely start linux dt file upstream.
> 3. Once the linux dt file gets merged, I will

Re: [RESEND PATCH v2 04/11] net: dwc_eth_qos: Make clk_rx and clk_tx optional

2020-06-08 Thread Marek Vasut
On 6/8/20 7:05 PM, Patrick DELAUNAY wrote:
> Dear Marek,

Hi,

>> From: Marek Vasut 
>> Sent: lundi 8 juin 2020 11:45
>>
>> On 6/8/20 11:29 AM, Patrick DELAUNAY wrote:
>> [...]
> we don't select the STM32 glue for the correct compatible, I think I
> will push
>
> static const struct udevice_id eqos_ids[] = {
>   {
>   .compatible = "nvidia,tegra186-eqos",
>   .data = (ulong)&eqos_tegra186_config
>   },
>   {
> - .compatible = "snps,dwmac-4.20a",
> + .compatible = "st,stm32mp1-dwmac",
>   .data = (ulong)&eqos_stm32_config
>   },
>   {
>   .compatible = "fsl,imx-eqos",
>   .data = (ulong)&eqos_imx_config
>   },
>
>   { }
> };
>
> Then you can manage your own glue for rockchip ETH for your compatible.

 You might even want to drop the tegra support on ARM32 , thus save
 space by dropping useless code.
>>>
>>> For information I push 2 patches after this remark:
>>>
>>> [1]  net: dwc_eth_qos: update the compatible supported for STM32
>>>
>>> http://patchwork.ozlabs.org/project/uboot/patch/20200514130023.15030-1
>>> -patrick.delau...@st.com/
>>>
>>> [2]  net: dwc_eth_qos: add Kconfig option to select supported configuration
>>>   http://patchwork.ozlabs.org/project/uboot/list/?series=181931
>>
>> That's for -next, right ?
> 
> Yes both are for -next.
> 
> It is driver improvement (=code size reduction and cleanup compatible) and no 
> bugfix.

I am still not entirely sure whether the ifdeffery is the way to go.
I wonder whether we can't rather somehow use the linker-lists to
generate a list of compatible strings at runtime (like we do for
commands) and then reduce that list to only the compatible strings
present in the DT (that's a bit tricky).


Re: [PATCH] riscv: sbi: Add newline to error message

2020-06-08 Thread Atish Patra
On Sat, Jun 6, 2020 at 12:26 PM Sean Anderson  wrote:
>
> Signed-off-by: Sean Anderson 
>
> ---
>
>  common/spl/spl_opensbi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/spl/spl_opensbi.c b/common/spl/spl_opensbi.c
> index e88136e6f3..14f335f75f 100644
> --- a/common/spl/spl_opensbi.c
> +++ b/common/spl/spl_opensbi.c
> @@ -56,7 +56,7 @@ void spl_invoke_opensbi(struct spl_image_info *spl_image)
> /* Find U-Boot image in /fit-images */
> ret = spl_opensbi_find_uboot_node(spl_image->fdt_addr, &uboot_node);
> if (ret) {
> -   pr_err("Can't find U-Boot node, %d", ret);
> +   pr_err("Can't find U-Boot node, %d\n", ret);
> hang();
> }
>
> --
> 2.26.2
>


Reviewed-by: Atish Patra 
-- 
Regards,
Atish


[PATCH 5/5] verdin-imx8mm: Select the watchdog driver

2020-06-08 Thread sbabic
> Currently watchdog driver is not selected, which causes system to reboot
> after staying 60s in the U-Boot prompt.
> Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
> properly serviced.
> Signed-off-by: Fabio Estevam 
> Acked-by: Igor Opaniuk 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH] power: pmic: Add SPL Kconfig entry for PFUZE100

2020-06-08 Thread sbabic
> Add Kconfig entry for the PFUZE PMIC, SPL variant.
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: Jaehoon Chung 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Reviewed-by: Jaehoon Chung 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH v3 3/5] imx8mp_evk: spl: use spl_early_init

2020-06-08 Thread sbabic
> From: Peng Fan 
> Use spl_early_init to replace spl_init, spl_init will be invoked
> in board_init_r, we only need use spl_early_init to setup malloc
> and scan early dt.
> Signed-off-by: Peng Fan 
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH v2 1/1] imx: rom api: fix image offset computation

2020-06-08 Thread sbabic
> When not booting from FlexSPI, the offset computation is:
> offset = image_offset + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512 - 
> 0x8000;
> When booting from SD card or eMMC user partition, image_offset is
> 0x8000. It is useless to add and remove 0x8000.
> When booting from other device, image_offset is 0 so this computation is 
> wrong.
> Simplfy this computation to work on all booting devices.
> Signed-off-by: Sébastien Szymanski 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH] ARM: dts: imxrt1050: indent lcdif node correctly

2020-06-08 Thread sbabic
> Accidentally submitted a patch with indentation not correct, let's fix it
> by indenting wrong lines.
> Signed-off-by: Giulio Benetti 
> Acked-by: Peng Fan 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH] imx: Update MTD partitions layout for display5 (i.MX6Q) board

2020-06-08 Thread sbabic
> This change updates the MTD partition layout on SPI-NOR memory for display5
> board.
> Signed-off-by: Lukasz Majewski 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH 2/2] ARM: dts: imx: m53menlo: Convert to DM_ETH

2020-06-08 Thread sbabic
> Convert the board to DM_ETH instead of legacy networking. This requires
> a minor addition to the DT to satisfy the requirement for specifying a
> PHY node. No functional change from board user perspective.
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: NXP i.MX U-Boot Team 
> Cc: Peng Fan 
> Cc: Stefano Babic 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH v3 1/5] imx8mp_evk: spl: drop useless code

2020-06-08 Thread sbabic
> From: Peng Fan 
> Drop useless getting ccm device, there is no need to explicted do this
> in board code, and we not enable SPL CLK currently.
> Signed-off-by: Peng Fan 
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH v3 4/5] imx8mp_evk: spl: no need the code since spl framework could do that

2020-06-08 Thread sbabic
> From: Peng Fan 
> We no need invoke the code, since spl framework could help
> us do that.
> Signed-off-by: Peng Fan 
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


imx: move ATF to the back of the FIT to fix loading over yModem

2020-06-08 Thread sbabic
> With yModem the FIT Image is only supplied once, so we can only
> seek forward in the yModem supplied image and never backwards.
> With the recent changes to the SPL mechanism, including loading
> U-Boot first, FDT after, then the loadables, we must also reorder
> the FIT image script to make sure that the loadables are last in
> the FIT image.
> Signed-off-by: Patrick Wildt 
> Tested-by: Sébastien Szymanski 
> diff --git a/arch/arm/mach-imx/mkimage_fit_atf.sh 
> b/arch/arm/mach-imx/mkimage_fit_atf.sh
> index dd1ca5ad3fd..fe12b7bb4bd 100755
> --- a/arch/arm/mach-imx/mkimage_fit_atf.sh
> +++ b/arch/arm/mach-imx/mkimage_fit_atf.sh
> @@ -62,6 +62,23 @@ cat << __HEADER_EOF
>   compression = "none";
>   load = <$BL33_LOAD_ADDR>;
>   };
> +__HEADER_EOF
> +
> +cnt=1
> +for dtname in $*
> +do
> + cat << __FDT_IMAGE_EOF
> + fdt@$cnt {
> + description = "$(basename $dtname .dtb)";
> + data = /incbin/("$dtname");
> + type = "flat_dt";
> + compression = "none";
> + };
> +__FDT_IMAGE_EOF
> +cnt=$((cnt+1))
> +done
> +
> +cat << __HEADER_EOF
>   atf@1 {
>   description = "ARM Trusted Firmware";
>   os = "arm-trusted-firmware";
> @@ -88,20 +105,6 @@ cat << __HEADER_EOF
>  __HEADER_EOF
>  fi
>  
> -cnt=1
> -for dtname in $*
> -do
> - cat << __FDT_IMAGE_EOF
> - fdt@$cnt {
> - description = "$(basename $dtname .dtb)";
> - data = /incbin/("$dtname");
> - type = "flat_dt";
> - compression = "none";
> - };
> -__FDT_IMAGE_EOF
> -cnt=$((cnt+1))
> -done
> -
>  cat << __CONF_HEADER_EOF
>   };
>   configurations {
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH] imx8mp_evk: Add a README file

2020-06-08 Thread sbabic
> Add a README file explaining the U-Boot build and SD card flash procedures.
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH 2/5] imx8mn_ddr4_evk: Select the watchdog driver

2020-06-08 Thread sbabic
> Currently watchdog driver is not selected, which causes system to reboot
> after staying 60s in the U-Boot prompt.
> Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
> properly serviced.
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


Re: [PATCH v1 00/15] add basic driver support for broadcom NS3 soc

2020-06-08 Thread Rayagonda Kokatanur
On Mon, Jun 8, 2020 at 10:43 PM Simon Glass  wrote:
>
> Hi Rayagonda,
>
> On Mon, 8 Jun 2020 at 11:03, Rayagonda Kokatanur
>  wrote:
> >
> > Hi Simon,
> >
> > On Thu, Jun 4, 2020 at 8:30 AM Simon Glass  wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Wed, 3 Jun 2020 at 03:10, Rayagonda Kokatanur
> > >  wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Wed, May 20, 2020 at 7:50 PM Simon Glass  wrote:
> > > > >
> > > > > Hi Rayagonda,
> > > > >
> > > > > On Tue, 19 May 2020 at 23:19, Rayagonda Kokatanur
> > > > >  wrote:
> > > > > >
> > > > > > Hi Thomas,
> > > > > >
> > > > > > On Wed, May 20, 2020 at 7:34 AM Thomas Fitzsimmons 
> > > > > >  wrote:
> > > > > > >
> > > > > > > Rayagonda Kokatanur  writes:
> > > > > > >
> > > > > > > > On Tue, May 19, 2020 at 11:01 PM Tom Rini  
> > > > > > > > wrote:
> > > > > > > >>
> > > > > > > >> On Tue, May 19, 2020 at 10:39:49PM +0530, Rayagonda Kokatanur 
> > > > > > > >> wrote:
> > > > > > > >> > Hi Tom,
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > On Tue, May 19, 2020 at 12:46 AM Tom Rini 
> > > > > > > >> >  wrote:
> > > > > > > >> > >
> > > > > > > >> > > On Sun, May 17, 2020 at 01:49:30PM +0530, Rayagonda 
> > > > > > > >> > > Kokatanur wrote:
> > > > > > > >> > >
> > > > > > > >> > > > This is the second patch set series prepared on top of 
> > > > > > > >> > > > the
> > > > > > > >> > > > first patch set ("add initial support for broadcom NS3 
> > > > > > > >> > > > soc").
> > > > > > > >> > > >
> > > > > > > >> > > > This patch set will add following,
> > > > > > > >> > > > -dt nodes and defconfig options for basic device like 
> > > > > > > >> > > > pinctrl,
> > > > > > > >> > > >  gpio, mmc, qspi, wdt, i2c and pcie.
> > > > > > > >> > > > -start wdt service
> > > > > > > >> > > > -Enable GPT commands
> > > > > > > >> > > > -Enable EXT4 and FAT fs support
> > > > > > > >> > >
> > > > > > > >> > > All of the dts changes not in a -u-boot.dtsi file either 
> > > > > > > >> > > come from
> > > > > > > >> > > mainline Linux or at least linux-next and have had some 
> > > > > > > >> > > level upstream
> > > > > > > >> > > review, right?  Thanks!
> > > > > > > >> >
> > > > > > > >> > Yes. All the DTS changes are merged in the Linux and are 
> > > > > > > >> > available at
> > > > > > > >> > arch/arm64/boot/dts/broadcom/stingray/
> > > > > > > >>
> > > > > > > >> Great.  Please reference the release you're taking these from 
> > > > > > > >> as that
> > > > > > > >> will make future resyncs easier.  Thanks!
> > > > > > > >
> > > > > > > > It's Linux v5.6.
> > > > > > >
> > > > > > > What's the relationship between e.g., bcm958742t.dts and ns3.dts? 
> > > > > > >  I
> > > > > > > looked at the mainline Linux device trees and I couldn't easily 
> > > > > > > see the
> > > > > > > correspondence.  Will the renaming complicate synchronization?
> > > > > >
> > > > > > Do we need to maintain the same dt file between linux and uboot ?
> > > > > > Also in uboot we don't enable all devices,  how do we handle this ?
> > > > >
> > > > > If there is no U-Boot driver for a particular node then it will be
> > > > > ignored. It is easier to keep them in sync if they are the same in
> > > > > U-Boot and Linux.
> > > > >
> > > > > > Please let me know.
> > > > >
> > > > > That is implied by your question above :-)
> > > >
> > > > NS3 board is derivative of the existing bcm95874t board
> > > > (arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dt)
> > > > Hence we have different dt for NS3 in Linux but it is not yet upstremed.
> > > >
> > > > I compared the dt file size between uboot and Linux.
> > > > Uboot dt size = 9K
> > > > Linux dt size  = 41K (32K extra)
> > > >
> > > > In uboot we have 8MB non-volatile SPI flash memory.
> > > > Out of 8MB, 1.5MB is allocated to fip.bin image and remaining 6.5MB
> > > > space is allocated to other components
> > > > like nitor/bnxt firmware image, DDR shmoo value and for backup image.
> > > >
> > > > uboot.bin is part of the fip.bin image. If we pull Linux dt files this
> > > > will use extra 33K memory of allocated 1.5MB.
> > > > This increase in 33K will reduce total memory availability for u-boot
> > > > and other features (like ARM trusted firmware, Op-TEE OS) development
> > > > in future.
> > > > Hence we anticipate qpsi memory shortage going ahead for new features.
> > > >
> > > > So please let me know your view on maintaining different dt files in 
> > > > uboot.
> > >
> > > Sounds like you have plenty of memory, actually. Is U-Boot the first
> > > thing to load?
> > >
> > > I think it is important to use the same filename and have the same DT
> > > contents where they are present in U-Boot. But if you want to leave
> > > out nodes, etc., that seems OK to me. It should be easy enough to meld
> > > in the updates later.
> > >
> > > I wonder if we should add a way to drop unused nodes for U-Boot
> > > proper, like we do for SPL?
> >
> > Thank you for your suggestion.
> >
> > Right now linux dt files are not upstremed.
> > Ups

[PATCH 4/5] imx8mp_evk: Select the watchdog driver

2020-06-08 Thread sbabic
> Currently watchdog driver is not selected, which causes system to reboot
> after staying 60s in the U-Boot prompt.
> Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
> properly serviced.
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH v3 2/5] imx8mp_evk: spl: drop timer_init

2020-06-08 Thread sbabic
> From: Peng Fan 
> timer_init has been invoked in arch_cpu_init, no need to invoke
> it again in board code.
> Signed-off-by: Peng Fan 
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH v3 5/5] imx: imx8mp_evk: fix boot issue

2020-06-08 Thread sbabic
> From: Peng Fan 
> The u-boot-spl.bin pad with ddr firmware conflicts with the
> CONFIG_MALLOC_F_ADDR area, the ddr firmware will be overwritten
> by malloc in SPL stage and cause ddr initialization not able
> to finish. So update the related addresses to fix the issue.
> Reported-by: Fabio Estevam 
> Signed-off-by: Peng Fan 
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH] imx: Kconfig: enable IMX_BOOTAUX for i.MX8M

2020-06-08 Thread sbabic
> i.MX8M could use imx bootaux to boot m4/m7 core, so let's add it
> to the dependency list.
> Signed-off-by: Peng Fan 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH 3/5] imx8mm_beacon: Select the watchdog driver

2020-06-08 Thread sbabic
> Currently watchdog driver is not selected, which causes system to reboot
> after staying 60s in the U-Boot prompt.
> Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
> properly serviced.
> Signed-off-by: Fabio Estevam 
> Reviewed-by: Adam Ford 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH 1/2] ARM: imx: m53menlo: Do not fail boot on invalid splash screen

2020-06-08 Thread sbabic
> None of these splash screen loading errors are so critical as to
> justify complete failure to boot, so just print error message as
> needed and return 0, the boot can very likely continue without
> the splash.
> Fix a couple of missing free(dst) instances as well.
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: NXP i.MX U-Boot Team 
> Cc: Peng Fan 
> Cc: Stefano Babic 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH] ARM: imx: ddr: Add missing PHY reset

2020-06-08 Thread sbabic
> The iMX7D RM 9.2.4.9.3 Power removal flow Table 9-11. Re-enabling power
> explicitly says both the DDR controller and the PHY must be reset in the
> correct sequence. Currently the code only resets the controller. This
> leads to a misbehavior where the system brings the DRAM up after reboot,
> but the DRAM is unstable. Add the missing reset.
> The easiest way to trigger this is by triggering WDT without having the
> WDT assert WDOG_B signal, i.e. mw.w 0x3028 0x25 .
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: NXP i.MX U-Boot Team 
> Cc: Peng Fan 
> Cc: Stefano Babic 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


[PATCH 1/5] imx8mm_evk: Select the watchdog driver

2020-06-08 Thread sbabic
> Currently the watchdog driver is not selected, which causes the following
> warnings in both SPL and U-Boot proper:
> U-Boot SPL 2020.07-rc1-00387-g67887903af (May 07 2020 - 23:49:27 -0300)
> Normal Boot
> WDT:   Started without servicing (60s timeout)
> Trying to boot from MMC1
> U-Boot 2020.07-rc1-00387-g67887903af (May 07 2020 - 23:49:27 -0300)
> CPU:   Freescale i.MX8MMQ rev1.0 at 1200 MHz
> Reset cause: POR
> Model: FSL i.MX8MM EVK board
> DRAM:  2 GiB
> WDT:   Started without servicing (60s timeout)
> 
> System reboots after staying 60s in the U-Boot prompt.
> Fix this problem by enabling CONFIG_WATCHDOG so that watchdog can be 
> properly serviced.
> Suggested-by: Marek Vasut 
> Signed-off-by: Fabio Estevam 
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=


Re: [PATCH] test_sleep.py: make sleep time and margin configurable

2020-06-08 Thread Stephen Warren
On 6/8/20 11:12 AM, Simon Glass wrote:
> Hi Stephen,
> 
> On Mon, 8 Jun 2020 at 10:43, Stephen Warren  wrote:
>>
>> On 6/7/20 7:45 AM, Simon Glass wrote:
>>> On Thu, 4 Jun 2020 at 09:24, Heiko Schocher  wrote:

 make the sleep time and the margin configurable.

 Signed-off-by: Heiko Schocher 
 ---

 travis build:
 https://travis-ci.org/github/hsdenx/u-boot-test/builds/694545225

 This patch is needed as I start test/py now within tbot [1]. On
 some configurations U-Boot is compiled on a build machine for
 example in munich, while the board under test is in my lab in
 hungary.

 So the 0.25 seconds default margin is often to low because
 of latencies on the net.

 See as an example configuration (within tbot):

 https://github.com/EmbLux-Kft/tbot-tbot2go/blob/devel/boards/aristainetos.py#L29

 [1] http://tbot.tools/modules/tc.html#u-boot-test-py

  test/py/tests/test_sleep.py | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)
>>>
>>> Reviewed-by: Simon Glass 
>>>
>>> Related, at some point we should change sandbox to fake the time
>>> movement since this test currently waits for three seconds even on
>>> sandbox.
>>
>> We definitely shouldn't do that; that's the exact kind of failure this
>> test is intended to detect.
> 
> No, we're not looking for bugs in sandbox's time handling. We are just
> testing the plumbing associated with delaying (timer driver, etc.).

The entire purpose of the test is to look for bugs in the backend
implementation of the time handling. I should know; I wrote the test!


Re: [PATCH v2 0/2] gpio: Add a managed API

2020-06-08 Thread Pratyush Yadav
Hi Simon,

On 01/06/20 08:45AM, Simon Glass wrote:
> Hi Pratyush,
> 
> On Mon, 1 Jun 2020 at 05:22, Pratyush Yadav  wrote:
> >
> > On 31/05/20 08:08AM, Simon Glass wrote:
> > > Hi Pratyush,
> > >
> > > On Fri, 29 May 2020 at 15:39, Pratyush Yadav  wrote:
> > > >
> > > > Hi,
> > > >
> > > > This is a re-submission of Jean-Jacques' earlier work in October last
> > > > year. It can be found at [0]. The goal is to facilitate porting drivers
> > > > from the linux kernel. Most of the series will be about adding managed
> > > > API to existing infrastructure (GPIO, reset, regmap (already
> > > > submitted)).
> > > >
> > > > This particular series is about GPIOs. It adds a managed API using the
> > > > API as Linux. To make it 100% compatible with linux, there is a small
> > > > deviation from u-boot's way of naming the gpio lists: the managed
> > > > equivalent of gpio_request_by_name(..,"blabla-gpios", ...) is
> > > > devm_gpiod_get_index(..., "blabla", ...)
> > > >
> > > > Changes in v2:
> > > > - The original series had a patch that checked for NULL pointers in the
> > > >   core GPIO functions. The checks were needed because of the addition of
> > > >   devm_gpiod_get_index_optional() which would return NULL when when no
> > > >   GPIO was assigned to the requested function. This is convenient for
> > > >   drivers that need to handle optional GPIOs.
> > > >
> > > >   Simon argued that those should be behind a Kconfig option because of
> > > >   code size concerns. He also argued against implicit return in the
> > > >   macro that checked for the optional GPIOs.
> > > >
> > > >   This submission removes the controversial patch so that base
> > > >   functionality can get unblocked.
> > > >
> > > >   We still need to take a stance on who is responsible for the NULL
> > > >   check: the driver or the GPIO core? Do we want to trust drivers to
> > > >   take care of the NULL checks, or do we want to distrust them and make
> > > >   sure they don't send us anything bogus in the GPIO core. For now the
> > > >   responsibility lies on the drivers by default. I will send a separate
> > > >   RFC of the NULL check patch and we can probably discuss the issue
> > > >   there.
> > > >
> > > > [0] 
> > > > https://patchwork.ozlabs.org/project/uboot/cover/20191001115130.18886-1-jjhib...@ti.com/
> > > >
> > > > Jean-Jacques Hiblot (2):
> > > >   drivers: gpio: Add a managed API to get a GPIO from the device-tree
> > > >   test: gpio: Add tests for the managed API
> > > >
> > > >  arch/sandbox/dts/test.dts  |  10 
> > > >  drivers/gpio/gpio-uclass.c |  70 +
> > > >  include/asm-generic/gpio.h |  47 +
> > > >  test/dm/gpio.c | 102 +
> > > >  4 files changed, 229 insertions(+)
> > > >
> > > > --
> > > > 2.26.2
> > > >
> > >
> > > The first question I have is why do you want to allocate the gpio_desc
> > > and return it? Doesn't the caller have a place for that in its private
> > > struct?
> >
> > Ask the Linux folks that ;-)
> >
> > The main aim of this series is to make it easier to port and maintain
> > drivers from Linux. The less changes we have to make when porting a
> > driver, the easier it is to port future fixes and features.
> >
> > Linux drivers (like the TI J721E WIZ [0] for which this effort is mainly
> > being made) use these APIs. FWIW, the docs in Linux say the optional
> > wrappers to the functions are added as a convenience for drivers that
> > need to handle optional GPIOs.
> 
> U-Boot already supports optional GPIOs.

I seem to have mixed up some things when sending the reply. Sorry. This 
patchset doesn't really have all that much to do with optional GPIOs. It 
is about adding managed counterparts to the GPIO APIs.
 
> Can we put this behind a CONFIG_LINUX_COMPAT_GPIO flag perhaps, so
> people know they are trading off code / memory size for compatibility?

The decision to put these behind a config depends on what U-Boot's 
stance is on the "devm_*" functions in general. I see that there are 
devm_clk_*() functions in mainline already and they aren't beind a 
Kconfig option. A quick search tells me as of now no other subsystem has 
devm_* functions in mainline, though you did drop your Reviewed-by on 
the regmap patch that adds devm_regmap_init() [0] and it isn't guarded 
by a Kconfig option.

So as of now I see the stance is to add devm_* functions without 
wrapping them in a compile time switch. If we don't want to make 
building them mandatory (at the added cognitive cost of code that harder 
to reason about because of the multiple ways you can build it), that can 
be done but IMO we should be consistent about what we put behind a 
config.

One note I have about devm_gpiod_get_index() (which is the main source 
of new code) is that I don't think it is possible to have a dummy 
function in its stead since it is not a direct call to a lower level 
function and instead it plays around with the propname suffix. So i

[PATCH v4 0/4] rockchip: rk3399: Add SPI boot

2020-06-08 Thread Jagan Teki
Now, nvme scan seems stable with environment.

This series v4 version for SPI boot support on rk3399.

Changes for v4:
- adjust env offset, size
changes for v3:
- SPI env offset, size changes based on roc-rk3399-pc
Changes for v2:
- same defconfig to support both MMC, SPI boot
- add spi flash program document 

Any inputs?
Jagan.

Jagan Teki (4):
  Makefile: Drop to handle rkspi image type
  roc-rk3399-pc: Mark default env from SPI
  roc-rk3399-pc: Add SPI boot
  doc: rockchip: Document SPI flash program steps

 Makefile  | 11 ++
 arch/arm/dts/rk3399-roc-pc-u-boot.dtsi| 12 ++-
 configs/roc-pc-mezzanine-rk3399_defconfig |  7 +-
 configs/roc-pc-rk3399_defconfig   |  7 +-
 doc/board/rockchip/rockchip.rst   | 26 ++-
 include/configs/roc-pc-rk3399.h   |  4 
 6 files changed, 50 insertions(+), 17 deletions(-)

-- 
2.20.1



[PATCH v4 2/4] roc-rk3399-pc: Mark default env from SPI

2020-06-08 Thread Jagan Teki
Mark the default U-Boot environment as SPI flash since
this is an on board flash device.

Updated env offset, size in contrast with default since
the U-Boot proper has starting from 384K.

Signed-off-by: Jagan Teki 
---
Changes for v4:
- adjust env offset, size

 configs/roc-pc-mezzanine-rk3399_defconfig | 4 +++-
 configs/roc-pc-rk3399_defconfig   | 4 +++-
 include/configs/roc-pc-rk3399.h   | 4 
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig 
b/configs/roc-pc-mezzanine-rk3399_defconfig
index 1c1539bcb9..9c6fd0c98c 100644
--- a/configs/roc-pc-mezzanine-rk3399_defconfig
+++ b/configs/roc-pc-mezzanine-rk3399_defconfig
@@ -1,7 +1,9 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_ENV_SIZE=0x8000
 CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_ENV_SECT_SIZE=0x1000
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_TARGET_ROC_PC_RK3399=y
 CONFIG_NR_DRAM_BANKS=1
@@ -25,7 +27,7 @@ CONFIG_CMD_TIME=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc-mezzanine"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
-CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index 76e76c160e..b225eb38fe 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -1,7 +1,9 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_ENV_SIZE=0x8000
 CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_ENV_SECT_SIZE=0x1000
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_TARGET_ROC_PC_RK3399=y
 CONFIG_NR_DRAM_BANKS=1
@@ -24,7 +26,7 @@ CONFIG_CMD_TIME=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
-CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
diff --git a/include/configs/roc-pc-rk3399.h b/include/configs/roc-pc-rk3399.h
index d4cbc3532e..59fe22289c 100644
--- a/include/configs/roc-pc-rk3399.h
+++ b/include/configs/roc-pc-rk3399.h
@@ -13,10 +13,6 @@
 
 #include 
 
-#if defined(CONFIG_ENV_IS_IN_MMC)
-# define CONFIG_SYS_MMC_ENV_DEV0
-#endif
-
 #define SDRAM_BANK_SIZE(2UL << 30)
 
 #endif
-- 
2.20.1



[PATCH v4 1/4] Makefile: Drop to handle rkspi image type

2020-06-08 Thread Jagan Teki
On rockchip platforms, SPI boot image creation is not
straightforward like MMC boot image creation where former
requires to specify tpl, spl in multimage format in mkimage,
and later simply do a concatenate mkimaged-tpl with spl.

On this note, let drop rkspi image type creation via kbuild
and let inform via rockchip.rst

Reviewed-by: Kever Yang 
Signed-off-by: Jagan Teki 
---
Changes for v4:
- none

 Makefile | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index 3851dd9fa0..db3b6b9991 100644
--- a/Makefile
+++ b/Makefile
@@ -1438,22 +1438,15 @@ u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE
 
 ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
 
-# rockchip image type
-ifeq ($(CONFIG_SPL_SPI_LOAD),y)
-ROCKCHIP_IMG_TYPE := rkspi
-else
-ROCKCHIP_IMG_TYPE := rksd
-endif
-
 # TPL + SPL
 ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy)
-MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T 
$(ROCKCHIP_IMG_TYPE)
+MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T rksd
 tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE
$(call if_changed,mkimage)
 idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE
$(call if_changed,cat)
 else
-MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T $(ROCKCHIP_IMG_TYPE)
+MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T rksd
 idbloader.img: spl/u-boot-spl.bin FORCE
$(call if_changed,mkimage)
 endif
-- 
2.20.1



[PATCH v4 3/4] roc-rk3399-pc: Add SPI boot

2020-06-08 Thread Jagan Teki
U-Boot TPL 2020.07-rc3-00090-gd4e919f927-dirty (Jun 01 2020 - 23:45:53)
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 4 mhz 0, 1
lpddr4_set_rate: change freq to 8 mhz 1, 0
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2020.07-rc3-00087-ga21e9fd385 (Jun 02 2020 - 00:09:45 +0530)
Trying to boot from MMC1
NOTICE:  BL31: v2.2(release):
NOTICE:  BL31: Built : 15:05:37, May 12 2020

U-Boot 2020.07-rc3-00087-ga21e9fd385 (Jun 02 2020 - 00:09:45 +0530)

SoC: Rockchip rk3399
Reset cause: POR
Model: Firefly ROC-RK3399-PC Board
DRAM:  3.9 GiB
PMIC:  RK808
MMC:   mmc@fe32: 1, sdhci@fe33: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 
Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Model: Firefly ROC-RK3399-PC Board

Reviewed-by: Kever Yang 
Signed-off-by: Jagan Teki 
---
Changes for v4:
- none

 arch/arm/dts/rk3399-roc-pc-u-boot.dtsi| 12 +++-
 configs/roc-pc-mezzanine-rk3399_defconfig |  3 +++
 configs/roc-pc-rk3399_defconfig   |  3 +++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi 
b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index 141dd0b306..fc155e6903 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -12,7 +12,11 @@
};
 
chosen {
-   u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
+   u-boot,spl-boot-order = "same-as-spl", &spi_flash, &sdhci, 
&sdmmc;
+   };
+
+   config {
+   u-boot,spl-payload-offset = <0x6>; /* @ 384KB */
};
 
vcc_hub_en: vcc_hub_en-regulator {
@@ -40,6 +44,12 @@
vin-supply = <&vcc_vbus_typec0>;
 };
 
+&spi1 {
+   spi_flash: flash@0 {
+   u-boot,dm-pre-reloc;
+   };
+};
+
 &vdd_log {
regulator-min-microvolt = <43>;
regulator-init-microvolt = <95>;
diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig 
b/configs/roc-pc-mezzanine-rk3399_defconfig
index 9c6fd0c98c..03ba519af1 100644
--- a/configs/roc-pc-mezzanine-rk3399_defconfig
+++ b/configs/roc-pc-mezzanine-rk3399_defconfig
@@ -9,12 +9,15 @@ CONFIG_TARGET_ROC_PC_RK3399=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_DEBUG_UART_BASE=0xFF1A
 CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc-mezzanine.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_SPI_LOAD=y
 CONFIG_TPL=y
 CONFIG_TPL_GPIO_SUPPORT=y
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index b225eb38fe..b59b54bd89 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -9,12 +9,15 @@ CONFIG_TARGET_ROC_PC_RK3399=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_DEBUG_UART_BASE=0xFF1A
 CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_SPI_LOAD=y
 CONFIG_TPL=y
 CONFIG_TPL_GPIO_SUPPORT=y
 CONFIG_CMD_BOOTZ=y
-- 
2.20.1



[PATCH v4 4/4] doc: rockchip: Document SPI flash program steps

2020-06-08 Thread Jagan Teki
Document SPI flash program steps for rockchip platforms.

Suggested-by: Hugh Cole-Baker 
Signed-off-by: Jagan Teki 
Reviewed-by: Kever Yang 
---
Changes for v4:
- none

 doc/board/rockchip/rockchip.rst | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 7b72fab496..76b228a046 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -162,6 +162,30 @@ Program the flash::
 Note: for rockchip 32-bit platforms the U-Boot proper image
 is u-boot-dtb.img
 
+SPI
+^^^
+
+Generating idbloader for SPI boot would require to input a multi image
+image format to mkimage tool instead of concerting (like for MMC boot).
+
+SPL-alone SPI boot image::
+
+./tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader.img
+
+TPL+SPL SPI boot image::
+
+./tools/mkimage -n rk3399 -T rkspi -d 
tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader.img
+
+Copy SPI boot images into SD card and boot from SD::
+
+sf probe
+load mmc 1:1 $kernel_addr_r idbloader.img
+sf erase 0 +$filesize
+sf write $kernel_addr_r 0 ${filesize}
+load mmc 1:1 ${kernel_addr_r} u-boot.itb
+sf erase 0x6 +$filesize
+sf write $kernel_addr_r 0x6 ${filesize}
+
 TODO
 
 
@@ -171,4 +195,4 @@ TODO
 - Add missing SoC's with it boards list
 
 .. Jagan Teki 
-.. Sunday 24 May 2020 10:08:41 PM IST
+.. Tuesday 02 June 2020 12:18:57 AM IST
-- 
2.20.1



[PATCH v3 0/5] roc-rk3399-pc: Custom SPL init

2020-06-08 Thread Jagan Teki
This series supports custom initialization code required for 
roc-rk3399-pc board on SPL stage. I have marked it as v3, since 
we have tried this before on this series[1]. 

Now this series is well mature code handling to add custom 
spl_board_init code parts.

roc-rk3399-pc would require custom leds initialization based 
on user intervention of the power key. This code handles the 
user intervention via SPI environment variable. If someone 
or production systems wants this feature then 'pwr_key' has 
to be set otherwise it is normal like other rk3399 boards 
in Mainline.

Changes for v3:
- support leds on SPL
- support env 'pwr_key'

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20200319101251.7354-1-ja...@amarulasolutions.com/

Any inputs?
Jagan.

Jagan Teki (5):
  rk3399: spl: Add rk_spl_board_init as __weak
  rk3399: spl: Print SPL banner after relocation
  roc-rk3399-pc: Move leds setup in SPL
  rockchip: Separate the reset cause from display cpuinfo
  roc-rk3399-pc: Set LED only during POR and pwr_key=y

 arch/arm/include/asm/arch-rockchip/cru.h|  2 +
 arch/arm/mach-rockchip/Makefile |  5 +-
 arch/arm/mach-rockchip/cpu-info.c   | 20 +---
 arch/arm/mach-rockchip/rk3399/rk3399.c  | 11 +++-
 arch/arm/mach-rockchip/spl.c|  1 -
 arch/arm/mach-rockchip/tpl.c|  7 ---
 board/firefly/roc-pc-rk3399/Makefile|  4 ++
 board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 21 
 board/firefly/roc-pc-rk3399/spl.c   | 56 +
 configs/roc-pc-mezzanine-rk3399_defconfig   |  6 ++-
 configs/roc-pc-rk3399_defconfig |  6 ++-
 11 files changed, 96 insertions(+), 43 deletions(-)
 create mode 100644 board/firefly/roc-pc-rk3399/spl.c

-- 
2.20.1



[PATCH v3 1/5] rk3399: spl: Add rk_spl_board_init as __weak

2020-06-08 Thread Jagan Teki
Current spl_board_init is mostly specific to puma-rk3399
target and in other words it cannot be required or useful
for other rk3399 boards.

Some boards require their custom initialization to be part
of spl_board_init like roc-rk3399-pc require leds setup,
environments.

So, this patch handles all these possible scenarios.
Add rk_spl_board_init as __weak so that boards that require
their own custom initialization can be defined on their
board file.

Signed-off-by: Jagan Teki 
Tested-by: Suniel Mahesh 
---
Changes for v3:
- new patch

 arch/arm/mach-rockchip/rk3399/rk3399.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 4fda93b152..681f80f339 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -241,7 +241,7 @@ static void rk3399_force_power_on_reset(void)
 }
 #endif
 
-void spl_board_init(void)
+__weak void rk_spl_board_init(void)
 {
 #if defined(SPL_GPIO_SUPPORT)
struct rockchip_cru *cru = rockchip_get_cru();
@@ -274,4 +274,11 @@ void spl_board_init(void)
debug("%s: Cannot enable boot on regulator\n", __func__);
 #endif
 }
+
+void spl_board_init(void)
+{
+   /* board specific spl init */
+   rk_spl_board_init();
+}
+
 #endif
-- 
2.20.1



[PATCH v3 2/5] rk3399: spl: Print SPL banner after relocation

2020-06-08 Thread Jagan Teki
Usually printing the SPL banner varies between architecture
or board codes.
- Some would print before relocation at the end board_init_f
  for making sure all initialization prior to this would happen
  properly. if at all there is a requirement for serial init,
  that happens properly since it prints all after that.
- Some would print after relocation at the spl_board_init for
  making sure all initialization prior to relocation would
  happen properly. Also debug uart on these cases would be
  available before relocation. So debug support is available
  in before and after relocation.

Rockchip SPL is following formar step to print the banner at
the end of board_init_f.

To support various custom use cases in SPL like leds, environment,
board detections later options like printing the banner after
relocation would be a better option. Printing banner would also
help to support debugging availability between relocation codes,
like debug uart available before relocation and banner availability
after relation.

By demonstrating all the above use cases, this patch is trying
to print the SPL banner after relocation.

Signed-off-by: Jagan Teki 
Tested-by: Suniel Mahesh 
---
Changes for v3:
- new patch

 arch/arm/mach-rockchip/rk3399/rk3399.c | 2 ++
 arch/arm/mach-rockchip/spl.c   | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c 
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 681f80f339..af4b0e271b 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -279,6 +279,8 @@ void spl_board_init(void)
 {
/* board specific spl init */
rk_spl_board_init();
+
+   preloader_console_init();
 }
 
 #endif
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index cddf4fd3d5..1c2dca8a72 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -147,7 +147,6 @@ void board_init_f(ulong dummy)
gd->ram_top = gd->ram_base + get_effective_memsize();
gd->ram_top = board_get_usable_ram_top(gd->ram_size);
 #endif
-   preloader_console_init();
 }
 
 #ifdef CONFIG_SPL_LOAD_FIT
-- 
2.20.1



[PATCH v3 3/5] roc-rk3399-pc: Move leds setup in SPL

2020-06-08 Thread Jagan Teki
roc-rk3399-pc has some specific requirements to support LEDS,
environment. board detection and etc prior to U-Boot proper.

So as of now SPL would be a better stage for these custom board
requirements to support unlike TPL. Adding few of these custom
requirements like LEDS in TPL would require extra code pulling
and also the size of TPL can grow.

So, this patch moves the leds code from TPL into SPL after relocation.

Signed-off-by: Jagan Teki 
Tested-by: Suniel Mahesh 
---
Changes for v3:
- new patch

 arch/arm/mach-rockchip/tpl.c|  7 ---
 board/firefly/roc-pc-rk3399/Makefile|  4 
 board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 21 ---
 board/firefly/roc-pc-rk3399/spl.c   | 23 +
 configs/roc-pc-mezzanine-rk3399_defconfig   |  2 +-
 configs/roc-pc-rk3399_defconfig |  2 +-
 6 files changed, 29 insertions(+), 30 deletions(-)
 create mode 100644 board/firefly/roc-pc-rk3399/spl.c

diff --git a/arch/arm/mach-rockchip/tpl.c b/arch/arm/mach-rockchip/tpl.c
index 88f80b05a9..cc908e1b0e 100644
--- a/arch/arm/mach-rockchip/tpl.c
+++ b/arch/arm/mach-rockchip/tpl.c
@@ -43,18 +43,11 @@ __weak void rockchip_stimer_init(void)
   TIMER_CONTROL_REG);
 }
 
-__weak int board_early_init_f(void)
-{
-   return 0;
-}
-
 void board_init_f(ulong dummy)
 {
struct udevice *dev;
int ret;
 
-   board_early_init_f();
-
 #if defined(CONFIG_DEBUG_UART) && defined(CONFIG_TPL_SERIAL_SUPPORT)
/*
 * Debug UART can be used from here if required:
diff --git a/board/firefly/roc-pc-rk3399/Makefile 
b/board/firefly/roc-pc-rk3399/Makefile
index 29c79b25d7..3a9c4c744d 100644
--- a/board/firefly/roc-pc-rk3399/Makefile
+++ b/board/firefly/roc-pc-rk3399/Makefile
@@ -4,4 +4,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+ifdef CONFIG_SPL_BUILD
+obj-y  += spl.o
+else
 obj-y  += roc-pc-rk3399.o
+endif
diff --git a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c 
b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
index 7c3a803654..581cdcd3b0 100644
--- a/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
+++ b/board/firefly/roc-pc-rk3399/roc-pc-rk3399.c
@@ -6,13 +6,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
 
-#ifndef CONFIG_SPL_BUILD
 int board_early_init_f(void)
 {
struct udevice *regulator;
@@ -30,19 +25,3 @@ int board_early_init_f(void)
 out:
return 0;
 }
-#endif
-
-#if defined(CONFIG_TPL_BUILD)
-
-#define GPIO0_BASE  0xff72
-
-int board_early_init_f(void)
-{
-   struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
-
-   /* Turn on red LED, indicating full power mode */
-   spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
-
-   return 0;
-}
-#endif
diff --git a/board/firefly/roc-pc-rk3399/spl.c 
b/board/firefly/roc-pc-rk3399/spl.c
new file mode 100644
index 00..a7664c6b86
--- /dev/null
+++ b/board/firefly/roc-pc-rk3399/spl.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Amarula Solutions(India)
+ */
+
+#include 
+#include 
+#include 
+
+#define GPIO0_BASE 0xff72
+
+static void led_setup(void)
+{
+   struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
+
+   /* Turn on red LED, indicating full power mode */
+   spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
+}
+
+void rk_spl_board_init(void)
+{
+   led_setup();
+}
diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig 
b/configs/roc-pc-mezzanine-rk3399_defconfig
index 03ba519af1..8ad74dc408 100644
--- a/configs/roc-pc-mezzanine-rk3399_defconfig
+++ b/configs/roc-pc-mezzanine-rk3399_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_ENV_SIZE=0x8000
 CONFIG_ENV_OFFSET=0x3F8000
 CONFIG_ENV_SECT_SIZE=0x1000
@@ -19,7 +20,6 @@ CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_TPL=y
-CONFIG_TPL_GPIO_SUPPORT=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index b59b54bd89..6fd06d6381 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ROCKCHIP=y
 CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_ENV_SIZE=0x8000
 CONFIG_ENV_OFFSET=0x3F8000
 CONFIG_ENV_SECT_SIZE=0x1000
@@ -19,7 +20,6 @@ CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_TPL=y
-CONFIG_TPL_GPIO_SUPPORT=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
-- 
2.20.1



[PATCH v3 4/5] rockchip: Separate the reset cause from display cpuinfo

2020-06-08 Thread Jagan Teki
reset cause is a generic functionality based on the soc
cru registers in rockchip. This can be used for printing
the cause of reset in cpuinfo or some other place where
reset cause is needed. 

Other than cpuinfo, reset cause can also be using during
bootcount for checking the specific reset cause and glow
the led based on the reset cause.

So, let's separate the reset cause code from cpuinfo, and
add a check to build it for rk3399, rk3288 since these two
soc are supporting reset cause as of now.

Signed-off-by: Jagan Teki 
Tested-by: Suniel Mahesh 
---
Changes for v3:
- none

 arch/arm/include/asm/arch-rockchip/cru.h |  2 ++
 arch/arm/mach-rockchip/Makefile  |  5 -
 arch/arm/mach-rockchip/cpu-info.c| 20 
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/arm/include/asm/arch-rockchip/cru.h 
b/arch/arm/include/asm/arch-rockchip/cru.h
index 5eb17f9d55..317eb61049 100644
--- a/arch/arm/include/asm/arch-rockchip/cru.h
+++ b/arch/arm/include/asm/arch-rockchip/cru.h
@@ -31,4 +31,6 @@ enum {
 
 #define MHz100
 
+char *get_reset_cause(void);
+
 #endif /* _ROCKCHIP_CLOCK_H */
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 5b38526fe0..ef4898e00c 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -15,6 +15,10 @@ obj-tpl-$(CONFIG_ROCKCHIP_PX30) += px30-board-tpl.o
 
 obj-spl-$(CONFIG_ROCKCHIP_RK3036) += rk3036-board-spl.o
 
+ifeq ($(CONFIG_ROCKCHIP_RK3288)$(CONFIG_ROCKCHIP_RK3399), y)
+obj-y += cpu-info.o
+endif
+
 ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
 
 # Always include boot_mode.o, as we bypass it (i.e. turn it off)
@@ -22,7 +26,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
 # we can have the preprocessor correctly recognise both 0x0 and 0
 # meaning "turn it off".
 obj-y += boot_mode.o
-obj-$(CONFIG_DISPLAY_CPUINFO) += cpu-info.o
 obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
 obj-$(CONFIG_MISC_INIT_R) += misc.o
 endif
diff --git a/arch/arm/mach-rockchip/cpu-info.c 
b/arch/arm/mach-rockchip/cpu-info.c
index 21ca9dedce..76a840e2c3 100644
--- a/arch/arm/mach-rockchip/cpu-info.c
+++ b/arch/arm/mach-rockchip/cpu-info.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 
-static char *get_reset_cause(void)
+char *get_reset_cause(void)
 {
struct rockchip_cru *cru = rockchip_get_cru();
char *cause = NULL;
@@ -41,12 +41,6 @@ static char *get_reset_cause(void)
cause = "unknown reset";
}
 
-   /**
-* reset_reason env is used by rk3288, due to special use case
-* to figure it the boot behavior. so keep this as it is.
-*/
-   env_set("reset_reason", cause);
-
/*
 * Clear glb_rst_st, so we can determine the last reset cause
 * for following resets.
@@ -56,12 +50,22 @@ static char *get_reset_cause(void)
return cause;
 }
 
+#ifdef CONFIG_DISPLAY_CPUINFO
 int print_cpuinfo(void)
 {
+   char *cause = get_reset_cause();
+
printf("SoC: Rockchip %s\n", CONFIG_SYS_SOC);
-   printf("Reset cause: %s\n", get_reset_cause());
+   printf("Reset cause: %s\n", cause);
+
+   /**
+* reset_reason env is used by rk3288, due to special use case
+* to figure it the boot behavior. so keep this as it is.
+*/
+   env_set("reset_reason", cause);
 
/* TODO print operating temparature and clock */
 
return 0;
 }
+#endif
-- 
2.20.1



[PATCH v3 5/5] roc-rk3399-pc: Set LED only during POR and pwr_key=y

2020-06-08 Thread Jagan Teki
ROC-RK3399-PC has specific set of configurations for
on-board led setup.

Due to easiness for user to know the state of the board
roc-rk339-pc board code will setup the low power led
on/off, and waiting for user to press power key and then
glow full power led.

All this needs to happen only during power-on-reset not
for soft reset or WDT.

Also, it is not a proper usage to ask the user to press
the Power key if the board connected remotely, so add
the environment variable 'pwr_key' to check as well.

So, user need to press Power key only
- during POR
- pwr_key=y

Tested-by: Suniel Mahesh 
Signed-off-by: Jagan Teki 
---
Changes for v3:
- new patch

 board/firefly/roc-pc-rk3399/spl.c | 35 ++-
 configs/roc-pc-mezzanine-rk3399_defconfig |  4 ++-
 configs/roc-pc-rk3399_defconfig   |  4 ++-
 3 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/board/firefly/roc-pc-rk3399/spl.c 
b/board/firefly/roc-pc-rk3399/spl.c
index a7664c6b86..771a7fb2f2 100644
--- a/board/firefly/roc-pc-rk3399/spl.c
+++ b/board/firefly/roc-pc-rk3399/spl.c
@@ -4,16 +4,49 @@
  */
 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
+#define PMUGRF_BASE0xff32
 #define GPIO0_BASE 0xff72
 
+/**
+ * LED setup for roc-rk3399-pc
+ *
+ * 1. Set the low power leds (only during POR, pwr_key env is 'y')
+ *glow yellow LED, termed as low power
+ *poll for on board power key press
+ *once powe key pressed, turn off yellow
+ * 2. Turn on red LED, indicating full power mode
+ */
 static void led_setup(void)
 {
struct rockchip_gpio_regs * const gpio0 = (void *)GPIO0_BASE;
+   struct rk3399_pmugrf_regs * const pmugrf = (void *)PMUGRF_BASE;
+   bool press_pwr_key = false;
+
+   if (IS_ENABLED(CONFIG_SPL_ENV_SUPPORT)) {
+   env_init();
+   env_load();
+   if (env_get_yesno("pwr_key") == 1)
+   press_pwr_key = true;
+   }
+
+   if (press_pwr_key && !strcmp(get_reset_cause(), "POR")) {
+   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 1);
+
+   spl_gpio_set_pull(&pmugrf->gpio0_p, GPIO(BANK_A, 5),
+ GPIO_PULL_NORMAL);
+   while (readl(&gpio0->ext_port) & 0x20)
+   ;
+
+   spl_gpio_output(gpio0, GPIO(BANK_A, 2), 0);
+   }
 
-   /* Turn on red LED, indicating full power mode */
spl_gpio_output(gpio0, GPIO(BANK_B, 5), 1);
 }
 
diff --git a/configs/roc-pc-mezzanine-rk3399_defconfig 
b/configs/roc-pc-mezzanine-rk3399_defconfig
index 8ad74dc408..d3369063ea 100644
--- a/configs/roc-pc-mezzanine-rk3399_defconfig
+++ b/configs/roc-pc-mezzanine-rk3399_defconfig
@@ -17,7 +17,8 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc-mezzanine.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
-CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2
+CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_TPL=y
 CONFIG_CMD_BOOTZ=y
@@ -32,6 +33,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc-mezzanine"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index 6fd06d6381..0650b941c2 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -17,7 +17,8 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
-CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2
+CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_TPL=y
 CONFIG_CMD_BOOTZ=y
@@ -31,6 +32,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-- 
2.20.1



Re: [PATCH] image: Add support for ZSTD decompression

2020-06-08 Thread Robert Marko
On Wed, May 20, 2020 at 2:35 PM Tom Rini  wrote:
>
> On Wed, May 20, 2020 at 01:38:01PM +0200, Robert Marko wrote:
>
> > Tom,
> > I have tried various things but CONFIG_IS_ENABLED won't work inside of
> > switch case.
> > It works fine outside of if though.
>
> OK, thanks, I'll poke things more to make sure what I'm worried about
> doesn't happen.

Hi,
were you able to test the commit?

Regards,
Robert
>
> --
> Tom


Re: Pull request: u-boot-rockchip-20200607

2020-06-08 Thread Tom Rini
On Mon, Jun 08, 2020 at 03:23:33PM +0800, Kever Yang wrote:

> Hi Tom,
> 
> Please pull the rockchip updates/fixes:
> - revive rk3399 puma board to adapt mainline dts;
> - Fix rk3399-evb stdout path;
> - Enable PCIe for rk3399: Rockpro64, firefly, pinebookpro;
> - Add rk3328 Rock-pi-e board;
> - Enable SPI boot for rockpro64 and roc-pc-rk3399;
> 
> Gitlab ci:
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3580
> 
> Thanks,
> - Kever
> 
> The following changes since commit 88bd5b1793600b0f5f25c3d236b4d049fb986140:
> 
>   configs: Resync with savedefconfig (2020-06-04 19:29:09 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/u-boot-rockchip-20200607
> 
> for you to fetch changes up to 187ab38e766393cda7bf3bf4926c1e55f48ad0cb:
> 
>   rockchip: enable PCIe and NVMe on Pinebook Pro (2020-06-07 20:53:23 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: pull request of u-boot-mpc85xx for v2020.07

2020-06-08 Thread Tom Rini
On Mon, Jun 08, 2020 at 07:32:47AM +, Priyanka Jain wrote:

> Dear Tom,
> Please find my pull-request for u-boot-mpc85xx
> https://travis-ci.org/github/p-priyanka-jain/u-boot/builds/694639674
> 
> Summary
> DM_ETH support for P2041RDB, T1024RDB, P5040DS, P3041DS, P4080DS, bug fixes
> Add TBI Phy access through MII
> DDR: Rework errata workaround for A008109, A008378, 009942
> 
> Thanks
> Priyanka

Applied to u-boot/master, thanks!

But please note and address:
w+(P3041DS P3041DS_NAND P3041DS_SDCARD P3041DS_SPIFLASH) 
arch/powerpc/dts/p3041ds.dtb: Warning (avoid_default_addr_size): 
/localbus@ffe124000/board-control@3,0: Relying on default #address-cells value
w+(P3041DS P3041DS_NAND P3041DS_SDCARD P3041DS_SPIFLASH) 
arch/powerpc/dts/p3041ds.dtb: Warning (avoid_default_addr_size): 
/localbus@ffe124000/board-control@3,0: Relying on default #size-cells value
w+(P5040DS P5040DS_NAND P5040DS_SDCARD P5040DS_SPIFLASH) 
arch/powerpc/dts/p5040ds.dtb: Warning (avoid_default_addr_size): 
/localbus@ffe124000/board-control@3,0: Relying on default #address-cells value
w+(P5040DS P5040DS_NAND P5040DS_SDCARD P5040DS_SPIFLASH) 
arch/powerpc/dts/p5040ds.dtb: Warning (avoid_default_addr_size): 
/localbus@ffe124000/board-control@3,0: Relying on default #size-cells value

in follow-up patches, thanks!

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 00/15] rockchip: Support building ROM files automatically

2020-06-08 Thread Simon Glass
Rockchip-based Chromebooks support booting from SPI flash. It is annoying
to have to manually build the SPI image when the SD image is built
automatically.

This feature is already available for x86 devices, so the existing
mechanism is reused. Briefly, this allows a BUILD_ROM environment variable
to be provided to indicate that any required binary blobs are present and
it is safe to build the ROM.

A new 'mkimage' type is added to binman to support building binaries with
mkimage with a binman definition. This avoids Makefile/shell/Python code
to do the same thing.

This series uses binman to produce a ROM image on two selected
Chromebooks, Bob (RK3399) and Jerry (RK3388).


Simon Glass (15):
  dm: core Fix long line in device_bind_common()
  .gitignore: Ignore Python 3 cache directories
  binman: cbfs: Fix IFWI typo
  binman: Correct the search patch for pylibfdt
  binman: Add support for calling mkimage
  binman: Fix a few typos in the entry docs
  binman: Adjust pylibfdt for incremental build
  x86: rockchip: Change how selection of ROMs works
  rockchip: Allow Bob to use SPI boot
  Allow building .rom files for non-x86 boards
  rockchip: jerry: Add serial support
  rockchip: bob: Support SPI-flash booting
  rockchip: Allow including rockchip dtsi on 32-bit machines
  rockchip: Enable building a SPI ROM image on jerry
  rockchip: Enable building a SPI ROM image on bob

 .gitignore|  3 ++
 Kconfig   | 18 +++-
 Makefile  | 30 ++---
 arch/Kconfig  |  1 +
 arch/arm/dts/rk3288-u-boot.dtsi   | 24 +++
 arch/arm/dts/rk3399-gru-u-boot.dtsi   |  4 ++
 arch/arm/dts/rk3399-gru.dtsi  |  2 +-
 arch/arm/dts/rk3399-u-boot.dtsi   | 27 
 arch/arm/dts/rockchip-u-boot.dtsi | 10 -
 arch/arm/mach-rockchip/rk3288/Kconfig |  1 +
 arch/arm/mach-rockchip/rk3399/Kconfig |  1 +
 arch/arm/mach-rockchip/spl.c  |  3 +-
 arch/x86/Kconfig  |  4 ++
 configs/chromebook_bob_defconfig  |  4 +-
 configs/chromebook_jerry_defconfig|  1 +
 drivers/core/device.c |  3 +-
 scripts/dtc/pylibfdt/Makefile |  3 ++
 tools/binman/README.entries   | 27 +++-
 tools/binman/etype/_testing.py|  5 +++
 tools/binman/etype/cbfs.py|  2 +-
 tools/binman/etype/mkimage.py | 62 +++
 tools/binman/ftest.py |  7 +++
 tools/binman/main.py  |  2 +-
 tools/binman/test/156_mkimage.dts | 23 ++
 24 files changed, 252 insertions(+), 15 deletions(-)
 create mode 100644 tools/binman/etype/mkimage.py
 create mode 100644 tools/binman/test/156_mkimage.dts

-- 
2.27.0.278.ge193c7cf3a9-goog



[PATCH 04/15] binman: Correct the search patch for pylibfdt

2020-06-08 Thread Simon Glass
Now that binman uses tools/ as its base directory for importing modules,
the path to the pylibfdt build by U-Boot is incorrect. Fix it.

Signed-off-by: Simon Glass 
---

 tools/binman/main.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/binman/main.py b/tools/binman/main.py
index efa7fa8386..4194761f9e 100755
--- a/tools/binman/main.py
+++ b/tools/binman/main.py
@@ -25,7 +25,7 @@ sys.path.insert(2, os.path.join(our_path, '..'))
 from patman import test_util
 
 # Bring in the libfdt module
-sys.path.insert(2, 'scripts/dtc/pylibfdt')
+sys.path.insert(2, os.path.join(our_path, '../../scripts/dtc/pylibfdt'))
 sys.path.insert(2, os.path.join(our_path,
 '../../build-sandbox_spl/scripts/dtc/pylibfdt'))
 
-- 
2.27.0.278.ge193c7cf3a9-goog



[PATCH 02/15] .gitignore: Ignore Python 3 cache directories

2020-06-08 Thread Simon Glass
These can appear when moving between branches that have different tools
in the tree. Ignore them.

Signed-off-by: Simon Glass 
---

 .gitignore | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/.gitignore b/.gitignore
index 2e1c8bf2bf..e66aa864da 100644
--- a/.gitignore
+++ b/.gitignore
@@ -92,3 +92,6 @@ GTAGS
 *.orig
 *~
 \#*#
+
+# Python cache
+__pycache__
-- 
2.27.0.278.ge193c7cf3a9-goog



[PATCH 03/15] binman: cbfs: Fix IFWI typo

2020-06-08 Thread Simon Glass
This comment references the wrong thing. Fix it.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/cbfs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/binman/etype/cbfs.py b/tools/binman/etype/cbfs.py
index e9aed8310c..744a32fa0c 100644
--- a/tools/binman/etype/cbfs.py
+++ b/tools/binman/etype/cbfs.py
@@ -204,7 +204,7 @@ class Entry_cbfs(Entry):
 return True
 
 def _ReadSubnodes(self):
-"""Read the subnodes to find out what should go in this IFWI"""
+"""Read the subnodes to find out what should go in this CBFS"""
 for node in self._node.subnodes:
 entry = Entry.Create(self, node)
 entry.ReadNode()
-- 
2.27.0.278.ge193c7cf3a9-goog



[PATCH 01/15] dm: core Fix long line in device_bind_common()

2020-06-08 Thread Simon Glass
Fix an over-length line in this function.

Signed-off-by: Simon Glass 
---

 drivers/core/device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index a7408d9c76..2e3d555ea4 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -82,7 +82,8 @@ static int device_bind_common(struct udevice *parent, const 
struct driver *drv,
 * This is just a 'requested' sequence, and will be
 * resolved (and ->seq updated) when the device is probed.
 */
-   if (CONFIG_IS_ENABLED(OF_CONTROL) && 
!CONFIG_IS_ENABLED(OF_PLATDATA)) {
+   if (CONFIG_IS_ENABLED(OF_CONTROL) &&
+   !CONFIG_IS_ENABLED(OF_PLATDATA)) {
if (uc->uc_drv->name && ofnode_valid(node))
dev_read_alias_seq(dev, &dev->req_seq);
 #if CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
-- 
2.27.0.278.ge193c7cf3a9-goog



[PATCH 05/15] binman: Add support for calling mkimage

2020-06-08 Thread Simon Glass
As a first step to integrating mkimage into binman, add a new entry type
that feeds data into mkimage for processing and incorporates that output
into the image.

Signed-off-by: Simon Glass 
---

 tools/binman/README.entries   | 23 
 tools/binman/etype/_testing.py|  5 +++
 tools/binman/etype/mkimage.py | 62 +++
 tools/binman/ftest.py |  7 
 tools/binman/test/156_mkimage.dts | 23 
 5 files changed, 120 insertions(+)
 create mode 100644 tools/binman/etype/mkimage.py
 create mode 100644 tools/binman/test/156_mkimage.dts

diff --git a/tools/binman/README.entries b/tools/binman/README.entries
index 6a816bba6b..4f2c48fdc2 100644
--- a/tools/binman/README.entries
+++ b/tools/binman/README.entries
@@ -587,6 +587,29 @@ See README.x86 for information about Intel binary blobs.
 
 
 
+Entry: mkimage: Entry containing a binary produced by mkimage
+-
+
+Properties / Entry arguments:
+- datafile: Filename for -d argument
+- args: Other arguments to pass
+
+The data passed to mkimage is collected from subnodes of the mkimage node,
+e.g.:
+
+mkimage {
+args = "-n test -T imximage";
+
+u-boot-spl {
+};
+};
+
+This calls mkimage to create an imximage with u-boot-spl.bin as the input
+file. The output from mkimage then becomes part of the image produced by
+binman.
+
+
+
 Entry: powerpc-mpc85xx-bootpg-resetvec: PowerPC mpc85xx bootpg + resetvec code 
for U-Boot
 
-
 
diff --git a/tools/binman/etype/_testing.py b/tools/binman/etype/_testing.py
index ed718eed14..ea60561adb 100644
--- a/tools/binman/etype/_testing.py
+++ b/tools/binman/etype/_testing.py
@@ -57,6 +57,8 @@ class Entry__testing(Entry):
  'return-contents-once')
 self.bad_update_contents_twice = fdt_util.GetBool(self._node,
 
'bad-update-contents-twice')
+self.return_contents_later = fdt_util.GetBool(self._node,
+ 'return-contents-later')
 
 # Set to True when the entry is ready to process the FDT.
 self.process_fdt_ready = False
@@ -83,6 +85,9 @@ class Entry__testing(Entry):
 def ObtainContents(self):
 if self.return_unknown_contents or not self.return_contents:
 return False
+if self.return_contents_later:
+self.return_contents_later = False
+return False
 self.data = self.contents
 self.contents_size = len(self.data)
 if self.return_contents_once:
diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
new file mode 100644
index 00..1aa563963a
--- /dev/null
+++ b/tools/binman/etype/mkimage.py
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2016 Google, Inc
+# Written by Simon Glass 
+#
+# Entry-type module for producing an image using mkimage
+#
+
+from collections import OrderedDict
+
+from binman.entry import Entry
+from dtoc import fdt_util
+from patman import tools
+
+class Entry_mkimage(Entry):
+"""Entry containing a binary produced by mkimage
+
+Properties / Entry arguments:
+- datafile: Filename for -d argument
+- args: Other arguments to pass
+
+The data passed to mkimage is collected from subnodes of the mkimage node,
+e.g.:
+
+mkimage {
+args = "-n test -T imximage";
+
+u-boot-spl {
+};
+};
+
+This calls mkimage to create an imximage with u-boot-spl.bin as the input
+file. The output from mkimage then becomes part of the image produced by
+binman.
+"""
+def __init__(self, section, etype, node):
+Entry.__init__(self, section, etype, node)
+self._args = fdt_util.GetString(self._node, 'args').split(' ')
+self._mkimage_entries = OrderedDict()
+self._ReadSubnodes()
+
+def ObtainContents(self):
+data = b''
+for entry in self._mkimage_entries.values():
+# First get the input data and put it in a file. If not available,
+# try later.
+if not entry.ObtainContents():
+return False
+data += entry.GetData()
+uniq = self.GetUniqueName()
+input_fname = tools.GetOutputFilename('mkimage.%s' % uniq)
+tools.WriteFile(input_fname, data)
+output_fname = tools.GetOutputFilename('mkimage-out.%s' % uniq)
+tools.Run('mkimage', '-d', input_fname, *self._args, output_fname)
+self.SetContents(tools.ReadFile(output_fname))
+return True
+
+def _ReadSubnodes(self):
+"""Read the subnodes to find out what should go in this image"""
+for node in self._node.subnodes:
+entry = Entry.Create(self, node)
+

[PATCH 08/15] x86: rockchip: Change how selection of ROMs works

2020-06-08 Thread Simon Glass
Most x86 boards build a u-boot.rom which is programmed into SPI flash. But
this is not unique to x86. For example some rockchip boards can also boot
from SPI flash.

Also, at least on x86, binary blobs are sadly quite common. It is not
possible to build a functional image without them, and U-Boot needs to
know this at build time.

Introduce a new CONFIG_HAS_ROM option which selects whether u-boot.rom is
built and a new CONFIG_ROM_NEEDS_BLOBS option to indicate whether binary
blobs are also needed. If they are not needed, it is safe to build the ROM
always. Otherwise we still require the BUILD_ROM environment variable.

For now this affects only x86, but future patches will enable this for
rockchip too.

Signed-off-by: Simon Glass 
---

 Kconfig  | 18 +-
 Makefile | 17 -
 arch/Kconfig |  1 +
 arch/x86/Kconfig |  4 
 4 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/Kconfig b/Kconfig
index 0e7ccc0b07..876c5db911 100644
--- a/Kconfig
+++ b/Kconfig
@@ -240,9 +240,25 @@ config PHYS_64BIT
  This can be used not only for 64bit SoCs, but also for
  large physical address extension on 32bit SoCs.
 
+config HAS_ROM
+   bool
+   select BINMAN
+   help
+ Enables building of a u-boot.rom target. This collects U-Boot and
+ any necessary binary blobs.
+
+config ROM_NEEDS_BLOBS
+   bool
+   depends on HAS_ROM
+   help
+ Enable this if building the u-boot.rom target needs binary blobs, and
+ so cannot be done normally. In this case, pass BUILD_ROM=1 to make
+ to tell U-Boot to build the ROM.
+
 config BUILD_ROM
bool "Build U-Boot as BIOS replacement"
-   depends on X86
+   depends on HAS_ROM
+   default y if !ROM_NEEDS_BLOBS
help
  This option allows to build a ROM version of U-Boot.
  The build process generally requires several binary blobs
diff --git a/Makefile b/Makefile
index db3b6b9991..d46338a6a4 100644
--- a/Makefile
+++ b/Makefile
@@ -916,9 +916,12 @@ ALL-$(CONFIG_REMAKE_ELF) += u-boot.elf
 ALL-$(CONFIG_EFI_APP) += u-boot-app.efi
 ALL-$(CONFIG_EFI_STUB) += u-boot-payload.efi
 
+ifneq ($(CONFIG_HAS_ROM),)
 ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
-ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+ALL-y += u-boot.rom
 endif
+endif
+
 ifeq ($(CONFIG_SYS_COREBOOT)$(CONFIG_SPL),yy)
 ALL-$(CONFIG_BINMAN) += u-boot-x86-with-spl.bin
 endif
@@ -1580,7 +1583,7 @@ endif
 # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
 # the middle. This is handled by binman based on an image description in the
 # board's device tree.
-ifneq ($(CONFIG_X86_RESET_VECTOR),)
+ifneq ($(CONFIG_HAS_ROM),)
 rom: u-boot.rom FORCE
 
 refcode.bin: $(srctree)/board/$(BOARDDIR)/refcode.bin FORCE
@@ -1590,11 +1593,12 @@ quiet_cmd_ldr = LD  $@
 cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \
   $(filter-out FORCE,$^) -o $@
 
-u-boot.rom: u-boot-x86-start16.bin u-boot-x86-reset16.bin u-boot.bin \
+rom-deps := u-boot.bin
+ifdef CONFIG_X86
+rom-deps += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
$(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
$(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin) \
-   $(if $(CONFIG_HAVE_REFCODE),refcode.bin) FORCE
-   $(call if_changed,binman)
+   $(if $(CONFIG_HAVE_REFCODE),refcode.bin)
 
 OBJCOPYFLAGS_u-boot-x86-start16.bin := -O binary -j .start16
 u-boot-x86-start16.bin: u-boot FORCE
@@ -1603,6 +1607,9 @@ u-boot-x86-start16.bin: u-boot FORCE
 OBJCOPYFLAGS_u-boot-x86-reset16.bin := -O binary -j .resetvec
 u-boot-x86-reset16.bin: u-boot FORCE
$(call if_changed,objcopy)
+
+u-boot.rom: $(rom-deps) FORCE
+   $(call if_changed,binman)
 endif
 
 ifneq ($(CONFIG_ARCH_SUNXI),)
diff --git a/arch/Kconfig b/arch/Kconfig
index a11f872938..bc85e5b50b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -160,6 +160,7 @@ config X86
select TIMER
select USE_PRIVATE_LIBGCC
select X86_TSC_TIMER
+   select HAS_ROM if X86_RESET_VECTOR
imply BLK
imply CMD_DM
imply CMD_FPGA_LOADMK
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c8eae24c07..c688c46475 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -360,6 +360,8 @@ config HAVE_FSP
bool "Add an Firmware Support Package binary"
depends on !EFI
select USE_HOB
+   select HAS_ROM
+   select ROM_NEEDS_BLOBS
help
  Select this option to add an Firmware Support Package binary to
  the resulting U-Boot image. It is a binary blob which U-Boot uses
@@ -519,6 +521,8 @@ config ENABLE_MRC_CACHE
 
 config HAVE_MRC
bool "Add a System Agent binary"
+   select HAS_ROM
+   select ROM_NEEDS_BLOBS
depends on !HAVE_FSP
help
  Select this option to add a System Agent binary to
-- 
2.27.0.278.ge193c7cf3a9-goog



[PATCH 06/15] binman: Fix a few typos in the entry docs

2020-06-08 Thread Simon Glass
Some typos have been fixed in the code but the entry docs were not
regenerated. Fix this.

Signed-off-by: Simon Glass 
---

 tools/binman/README.entries | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/binman/README.entries b/tools/binman/README.entries
index 4f2c48fdc2..d5b4b3af2b 100644
--- a/tools/binman/README.entries
+++ b/tools/binman/README.entries
@@ -519,7 +519,7 @@ Properties / Entry arguments:
 
 This file contains code used by the SoC that is required to make it work.
 The Management Engine is like a background task that runs things that are
-not clearly documented, but may include keyboard, display and network
+not clearly documented, but may include keyboard, deplay and network
 access. For platform that use ME it is not possible to disable it. U-Boot
 does not directly execute code in the ME binary.
 
@@ -616,7 +616,7 @@ Entry: powerpc-mpc85xx-bootpg-resetvec: PowerPC mpc85xx 
bootpg + resetvec code f
 Properties / Entry arguments:
 - filename: Filename of u-boot-br.bin (default 'u-boot-br.bin')
 
-This entry is valid for PowerPC mpc85xx cpus. This entry holds
+This enrty is valid for PowerPC mpc85xx cpus. This entry holds
 'bootpg + resetvec' code for PowerPC mpc85xx CPUs which needs to be
 placed at offset 'RESET_VECTOR_ADDRESS - 0xffc'.
 
-- 
2.27.0.278.ge193c7cf3a9-goog



  1   2   >