Re: U-Boot mainline: Digilent Zybo-Z7 support

2020-05-31 Thread Michal Simek
On 01. 06. 20 7:34, Milan Obuch wrote:
>> Hello,
>>
>> I just noticed that the support for the board Zybo-Z7
>> in mainline U-Boot is no longer available.
>>
>> Are there some reasons why it was dropped? Couldn't
>> find any information in the list archive.
>>
>> Thanks in advance!
>>
>> -- 
>> Best regards,
>>
>> Johannes K.
> 
> I was about to ask similar question already, slightly different way.
> Michal decided to somehow unify Zynq based board support with common
> zynq_virtconfig (sp?) configuration, but I did not understand the
> details yet. So I would rephrase the question another way...
> 
> How should one compile u-boot for Zybo Z7 board now and how should
> bootable image be created?


export DEVICE_TREE=zynq-zybo-z7
make xilinx_zynq_virt_defconfig
make -j8

M

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs




signature.asc
Description: OpenPGP digital signature


Re: U-Boot mainline: Digilent Zybo-Z7 support

2020-05-31 Thread Milan Obuch
> Hello,
> 
> I just noticed that the support for the board Zybo-Z7
> in mainline U-Boot is no longer available.
> 
> Are there some reasons why it was dropped? Couldn't
> find any information in the list archive.
> 
> Thanks in advance!
> 
> -- 
> Best regards,
> 
> Johannes K.

I was about to ask similar question already, slightly different way.
Michal decided to somehow unify Zynq based board support with common
zynq_virtconfig (sp?) configuration, but I did not understand the
details yet. So I would rephrase the question another way...

How should one compile u-boot for Zybo Z7 board now and how should
bootable image be created?

Regards,
Milan


RE: [PATCH 07/24] arm: Remove configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig board

2020-05-31 Thread Priyanka Jain
>-Original Message-
>From: Tom Rini 
>Sent: Friday, May 29, 2020 1:32 AM
>To: Priyanka Jain 
>Cc: Jagan Teki ; Simon Glass
>; u-boot@lists.denx.de; linux-
>amar...@amarulasolutions.com
>Subject: Re: [PATCH 07/24] arm: Remove configs/P1010RDB-
>PA_36BIT_NAND_SECBOOT_defconfig board
>
>On Thu, May 28, 2020 at 07:05:38AM +, Priyanka Jain wrote:
>> >-Original Message-
>> >From: U-Boot  On Behalf Of Jagan Teki
>> >Sent: Wednesday, May 27, 2020 10:17 PM
>> >To: Simon Glass ; Tom Rini 
>> >Cc: u-boot@lists.denx.de; linux-amar...@amarulasolutions.com; Jagan
>> >Teki 
>> >Subject: [PATCH 07/24] arm: Remove configs/P1010RDB-
>> >PA_36BIT_NAND_SECBOOT_defconfig board
>> >
>> >This board has not been converted to CONFIG_DM_SPI by the deadline.
>> >
>> >Remove it.
>> >
>> >Patch-cc: Qiang Zhao 
>> >Signed-off-by: Jagan Teki 
>> >---
>> > arch/powerpc/cpu/mpc85xx/Kconfig  |   1 -
>> > board/freescale/p1010rdb/Kconfig  |  14 -
>> > board/freescale/p1010rdb/MAINTAINERS  |  33 -
>> > board/freescale/p1010rdb/Makefile |  24 -
>> > board/freescale/p1010rdb/README.P1010RDB-PA   | 208 -
>> > board/freescale/p1010rdb/README.P1010RDB-PB   | 188 -
>> > board/freescale/p1010rdb/ddr.c| 235 --
>> > board/freescale/p1010rdb/law.c|  16 -
>> > board/freescale/p1010rdb/p1010rdb.c   | 731 -
>> > board/freescale/p1010rdb/spl.c| 114 ---
>> > board/freescale/p1010rdb/spl_minimal.c|  65 --
>> > board/freescale/p1010rdb/tlb.c|  90 --
>> > .../P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig  |  63 --
>> > configs/P1010RDB-PA_36BIT_NAND_defconfig  |  85 --
>> > .../P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig   |  62 --
>> > configs/P1010RDB-PA_36BIT_NOR_defconfig   |  67 --
>> > configs/P1010RDB-PA_36BIT_SDCARD_defconfig|  79 --
>> > ...010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig |  64 --
>> >configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig  |  81 --
>> > configs/P1010RDB-PA_NAND_SECBOOT_defconfig|  62 --
>> > configs/P1010RDB-PA_NAND_defconfig|  84 --
>> > configs/P1010RDB-PA_NOR_SECBOOT_defconfig |  60 --
>> > configs/P1010RDB-PA_NOR_defconfig |  66 --
>> > configs/P1010RDB-PA_SDCARD_defconfig  |  78 --
>> > .../P1010RDB-PA_SPIFLASH_SECBOOT_defconfig|  63 --
>> > configs/P1010RDB-PA_SPIFLASH_defconfig|  80 --
>> > .../P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig  |  63 --
>> > configs/P1010RDB-PB_36BIT_NAND_defconfig  |  85 --
>> > .../P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig   |  62 --
>> > configs/P1010RDB-PB_36BIT_NOR_defconfig   |  67 --
>> > configs/P1010RDB-PB_36BIT_SDCARD_defconfig|  79 --
>> > ...010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig |  64 --
>> >configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig  |  81 --
>> > configs/P1010RDB-PB_NAND_SECBOOT_defconfig|  62 --
>> > configs/P1010RDB-PB_NAND_defconfig|  84 --
>> > configs/P1010RDB-PB_NOR_SECBOOT_defconfig |  61 --
>> > configs/P1010RDB-PB_NOR_defconfig |  66 --
>> > configs/P1010RDB-PB_SDCARD_defconfig  |  78 --
>> > .../P1010RDB-PB_SPIFLASH_SECBOOT_defconfig|  63 --
>> > configs/P1010RDB-PB_SPIFLASH_defconfig|  80 --
>> > include/configs/P1010RDB.h| 766 --
>> > 41 files changed, 4474 deletions(-)
>> > delete mode 100644 board/freescale/p1010rdb/Kconfig  delete mode
>> >100644 board/freescale/p1010rdb/MAINTAINERS
>> > delete mode 100644 board/freescale/p1010rdb/Makefile  delete mode
>> >100644 board/freescale/p1010rdb/README.P1010RDB-PA
>> > delete mode 100644 board/freescale/p1010rdb/README.P1010RDB-PB
>> > delete mode 100644 board/freescale/p1010rdb/ddr.c  delete mode
>> >100644 board/freescale/p1010rdb/law.c  delete mode 100644
>> >board/freescale/p1010rdb/p1010rdb.c
>> > delete mode 100644 board/freescale/p1010rdb/spl.c  delete mode
>> >100644 board/freescale/p1010rdb/spl_minimal.c
>> > delete mode 100644 board/freescale/p1010rdb/tlb.c  delete mode
>> >100644 configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_36BIT_NAND_defconfig
>> > delete mode 100644 configs/P1010RDB-
>PA_36BIT_NOR_SECBOOT_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_36BIT_NOR_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_36BIT_SDCARD_defconfig
>> > delete mode 100644 configs/P1010RDB-
>> >PA_36BIT_SPIFLASH_SECBOOT_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_NAND_SECBOOT_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_NAND_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_NOR_SECBOOT_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_NOR_defconfig  delete mode
>> >100644 configs/P1010RDB-PA_SDCARD_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_SPIFLASH_SECBOOT_defconfig
>> > delete mode 100644 configs/P1010RDB-PA_SPIFLASH_defconfig
>> > delete mode 

Re: [PATCH v2 3/4] x86: tangier: acpi: Drop _ADR() where _HID() is present

2020-05-31 Thread Bin Meng
On Mon, Jun 1, 2020 at 10:57 AM Bin Meng  wrote:
>
> On Thu, May 28, 2020 at 5:17 PM Andy Shevchenko
>  wrote:
> >
> > ACPICA complains that either _HID() or _ADR() should be used.
> > Drop _ADR() where _HID() is present.
> >
> > Reported-by: Bin Meng 
> > Signed-off-by: Andy Shevchenko 
> > ---
> > v2: no changes
> >  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 1 -
> >  1 file changed, 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v2 4/4] x86: tangier: acpi: Drop _HID() where enumerated by _ADR()

2020-05-31 Thread Bin Meng
On Mon, Jun 1, 2020 at 10:57 AM Bin Meng  wrote:
>
> On Thu, May 28, 2020 at 5:17 PM Andy Shevchenko
>  wrote:
> >
> > ACPICA complains that either _HID() or _ADR() should be used.
> > For General Purpose DMA we may not drop the _ADR() because
> > the device is enumerated by PCI. Thus, simple drop _HID().
> >
> > Reported-by: Bin Meng 
> > Signed-off-by: Andy Shevchenko 
> > ---
> > v2: no changes
> >  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 1 -
> >  1 file changed, 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v2 2/4] x86: tangier: acpi: Replace _ADR() by _UID() in description of PCI host bridge

2020-05-31 Thread Bin Meng
On Mon, Jun 1, 2020 at 10:57 AM Bin Meng  wrote:
>
> On Thu, May 28, 2020 at 5:17 PM Andy Shevchenko
>  wrote:
> >
> > PCI Firmware specification requires _UID() and doesn't require _ADR()
> > to be set. Replace latter by former.
> >
> > Reported-by: Bin Meng 
> > Signed-off-by: Andy Shevchenko 
> > ---
> > v2: no changes
> >  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


Re: [PATCH v2 1/4] x86: tangier: acpi: Create buffers outside of the methods

2020-05-31 Thread Bin Meng
On Mon, Jun 1, 2020 at 10:57 AM Bin Meng  wrote:
>
> On Thu, May 28, 2020 at 5:17 PM Andy Shevchenko
>  wrote:
> >
> > Create buffers outside of the methods as ACPICA 20200214 complains about 
> > this:
> >
> > Remark 2173 - Creation of named objects within a method is
> > highly inefficient, use globals or method local variables
> > instead
> >
> > Reported-by: Bin Meng 
> > Signed-off-by: Andy Shevchenko 
> > ---
> > v2: rebased on top of rc3 (Bin)
> >  .../asm/arch-tangier/acpi/southcluster.asl| 95 ++-
> >  1 file changed, 49 insertions(+), 46 deletions(-)
> >
>
> Reviewed-by: Bin Meng 
> Tested-by: Bin Meng 

applied to u-boot-x86, thanks!


[PATCH 1/3] x86: baytrail: acpi: Create buffers outside of the methods

2020-05-31 Thread Bin Meng
Create buffers outside of the methods as ACPICA 20200430 complains
about this:

  Remark 2173 - Creation of named objects within a method is highly
  inefficient, use globals or method local variables instead
  (\_SB.PCI0.LPCB.IURT._CRS)

Signed-off-by: Bin Meng 
---

 arch/x86/include/asm/arch-baytrail/acpi/lpc.asl | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/arch-baytrail/acpi/lpc.asl 
b/arch/x86/include/asm/arch-baytrail/acpi/lpc.asl
index 08b2f53..69455d9 100644
--- a/arch/x86/include/asm/arch-baytrail/acpi/lpc.asl
+++ b/arch/x86/include/asm/arch-baytrail/acpi/lpc.asl
@@ -136,20 +136,20 @@ Device (LPCB)
Store(0, C1EN)
}
 
-   Method(_CRS, 0, Serialized)
+   Name(BUF0, ResourceTemplate()
{
-   Name(BUF0, ResourceTemplate()
-   {
-   IO(Decode16, 0x03f8, 0x03f8, 0x01, 0x08)
-   IRQNoFlags() { 3 }
-   })
-
-   Name(BUF1, ResourceTemplate()
-   {
-   IO(Decode16, 0x03f8, 0x03f8, 0x01, 0x08)
-   IRQNoFlags() { 4 }
-   })
+   IO(Decode16, 0x03f8, 0x03f8, 0x01, 0x08)
+   IRQNoFlags() { 3 }
+   })
 
+   Name(BUF1, ResourceTemplate()
+   {
+   IO(Decode16, 0x03f8, 0x03f8, 0x01, 0x08)
+   IRQNoFlags() { 4 }
+   })
+
+   Method(_CRS, 0, Serialized)
+   {
If (LLessEqual(SRID, 0x04)) {
Return (BUF0)
} Else {
-- 
2.7.4



[PATCH 2/3] x86: baytrail: acpi: Replace _ADR() by _UID() in description of PCI host bridge

2020-05-31 Thread Bin Meng
PCI Firmware specification requires _UID() and doesn't require _ADR()
to be set. Replace latter by former. This fixes the following warning
reported by ACPICA 20200430:

  Warning 3073 - Multiple types (Device object requires either a _HID
  or _ADR, but not both)

Signed-off-by: Bin Meng 
---

 arch/x86/include/asm/arch-baytrail/acpi/southcluster.asl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/arch-baytrail/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-baytrail/acpi/southcluster.asl
index 2a1c31c..3b220c7 100644
--- a/arch/x86/include/asm/arch-baytrail/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-baytrail/acpi/southcluster.asl
@@ -11,7 +11,7 @@ Device (PCI0)
Name(_HID, EISAID("PNP0A08"))   /* PCIe */
Name(_CID, EISAID("PNP0A03"))   /* PCI */
 
-   Name(_ADR, 0)
+   Name(_UID, 0)
Name(_BBN, 0)
 
Name(MCRS, ResourceTemplate()
-- 
2.7.4



[PATCH 3/3] x86: quark: acpi: Replace _ADR() by _UID() in description of PCI host bridge

2020-05-31 Thread Bin Meng
PCI Firmware specification requires _UID() and doesn't require _ADR()
to be set. Replace latter by former. This fixes the following warning
reported by ACPICA 20200430:

  Warning 3073 - Multiple types (Device object requires either a _HID
  or _ADR, but not both)

Signed-off-by: Bin Meng 
---

 arch/x86/include/asm/arch-quark/acpi/southcluster.asl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/arch-quark/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-quark/acpi/southcluster.asl
index fe9edc1..384dab2 100644
--- a/arch/x86/include/asm/arch-quark/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-quark/acpi/southcluster.asl
@@ -8,7 +8,7 @@ Device (PCI0)
Name(_HID, EISAID("PNP0A08"))   /* PCIe */
Name(_CID, EISAID("PNP0A03"))   /* PCI */
 
-   Name(_ADR, 0)
+   Name(_UID, 0)
Name(_BBN, 0)
 
Name(MCRS, ResourceTemplate()
-- 
2.7.4



U-Boot mainline: Digilent Zybo-Z7 support

2020-05-31 Thread Johannes Krottmayer
Hello,

I just noticed that the support for the board Zybo-Z7
in mainline U-Boot is no longer available.

Are there some reasons why it was dropped? Couldn't
find any information in the list archive.

Thanks in advance!

-- 
Best regards,

Johannes K.


Re: [PATCH v2 4/4] x86: tangier: acpi: Drop _HID() where enumerated by _ADR()

2020-05-31 Thread Bin Meng
On Thu, May 28, 2020 at 5:17 PM Andy Shevchenko
 wrote:
>
> ACPICA complains that either _HID() or _ADR() should be used.
> For General Purpose DMA we may not drop the _ADR() because
> the device is enumerated by PCI. Thus, simple drop _HID().
>
> Reported-by: Bin Meng 
> Signed-off-by: Andy Shevchenko 
> ---
> v2: no changes
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 1 -
>  1 file changed, 1 deletion(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 


Re: [PATCH v2 3/4] x86: tangier: acpi: Drop _ADR() where _HID() is present

2020-05-31 Thread Bin Meng
On Thu, May 28, 2020 at 5:17 PM Andy Shevchenko
 wrote:
>
> ACPICA complains that either _HID() or _ADR() should be used.
> Drop _ADR() where _HID() is present.
>
> Reported-by: Bin Meng 
> Signed-off-by: Andy Shevchenko 
> ---
> v2: no changes
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 1 -
>  1 file changed, 1 deletion(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 


Re: [PATCH v2 2/4] x86: tangier: acpi: Replace _ADR() by _UID() in description of PCI host bridge

2020-05-31 Thread Bin Meng
On Thu, May 28, 2020 at 5:17 PM Andy Shevchenko
 wrote:
>
> PCI Firmware specification requires _UID() and doesn't require _ADR()
> to be set. Replace latter by former.
>
> Reported-by: Bin Meng 
> Signed-off-by: Andy Shevchenko 
> ---
> v2: no changes
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 


Re: [PATCH v2 1/4] x86: tangier: acpi: Create buffers outside of the methods

2020-05-31 Thread Bin Meng
On Thu, May 28, 2020 at 5:17 PM Andy Shevchenko
 wrote:
>
> Create buffers outside of the methods as ACPICA 20200214 complains about this:
>
> Remark 2173 - Creation of named objects within a method is
> highly inefficient, use globals or method local variables
> instead
>
> Reported-by: Bin Meng 
> Signed-off-by: Andy Shevchenko 
> ---
> v2: rebased on top of rc3 (Bin)
>  .../asm/arch-tangier/acpi/southcluster.asl| 95 ++-
>  1 file changed, 49 insertions(+), 46 deletions(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 


Re: [PATCH 1/1] virtio: VIRTIO_RNG depends on DM_RNG

2020-05-31 Thread Bin Meng
On Sun, May 31, 2020 at 5:07 PM Heinrich Schuchardt  wrote:
>
> Add the missing Kconfig dependency and let VIRTIO_RNG default to yes.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/virtio/Kconfig | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>

Reviewed-by: Bin Meng 


RE: [PATCH v3] spl: allow board_spl_fit_post_load() to fail

2020-05-31 Thread Peng Fan
> Subject: [PATCH v3] spl: allow board_spl_fit_post_load() to fail
> 
> On i.MX platforms board_spl_fit_post_load() can check the loaded SPL image
> for authenticity using its HAB engine.  U-Boot's SPL mechanism allows
> booting images from other sources as well, but in the current setup the SPL
> would just hang if it encounters an image that does not pass scrutiny.

security.

> Allowing the function to return an error, allows the SPL to try booting from
> another source as a fallback instead of ending up as a brick.

This will break secure boot chain.

Regards,
Peng.

> 
> Signed-off-by: Patrick Wildt 
> ---
> Changes in v3:
>  - use EINVAL as return value to have a proper errno
> 
> Changes in v2:
>  - set SPL_FIT_FOUND only after successful post load
> 
>  arch/arm/mach-imx/spl.c |  6 --
>  common/spl/spl_fit.c| 10 ++
>  include/spl.h   |  2 +-
>  3 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c index
> 1a231c67f5a..1a0d979e2d0 100644
> --- a/arch/arm/mach-imx/spl.c
> +++ b/arch/arm/mach-imx/spl.c
> @@ -313,7 +313,7 @@ ulong board_spl_fit_size_align(ulong size)
>   return size;
>  }
> 
> -void board_spl_fit_post_load(ulong load_addr, size_t length)
> +int board_spl_fit_post_load(ulong load_addr, size_t length)
>  {
>   u32 offset = length - CONFIG_CSF_SIZE;
> 
> @@ -321,8 +321,10 @@ void board_spl_fit_post_load(ulong load_addr,
> size_t length)
>  offset + IVT_SIZE + CSF_PAD_SIZE,
>  offset)) {
>   puts("spl: ERROR:  image authentication unsuccessful\n");
> - hang();
> + return -EINVAL;
>   }
> +
> + return 0;
>  }
>  #endif
> 
> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c index
> f581a224213..ead4c6713af 100644
> --- a/common/spl/spl_fit.c
> +++ b/common/spl/spl_fit.c
> @@ -26,8 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
>  #define CONFIG_SYS_BOOTM_LEN (64 << 20)
>  #endif
> 
> -__weak void board_spl_fit_post_load(ulong load_addr, size_t length)
> +__weak int board_spl_fit_post_load(ulong load_addr, size_t length)
>  {
> + return 0;
>  }
> 
>  __weak ulong board_spl_fit_size_align(ulong size) @@ -677,11 +678,12 @@
> int spl_load_simple_fit(struct spl_image_info *spl_image,
>   if (spl_image->entry_point == FDT_ERROR || spl_image->entry_point ==
> 0)
>   spl_image->entry_point = spl_image->load_addr;
> 
> - spl_image->flags |= SPL_FIT_FOUND;
> -
>  #ifdef CONFIG_IMX_HAB
> - board_spl_fit_post_load((ulong)fit, size);
> + ret = board_spl_fit_post_load((ulong)fit, size);
> + if (ret)
> + return ret;
>  #endif
> 
> + spl_image->flags |= SPL_FIT_FOUND;
>   return 0;
>  }
> diff --git a/include/spl.h b/include/spl.h index b31c9bb4ab2..2607767d940
> 100644
> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -564,7 +564,7 @@ int board_return_to_bootrom(struct spl_image_info
> *spl_image,
>   * board_spl_fit_post_load - allow process images after loading finished
>   *
>   */
> -void board_spl_fit_post_load(ulong load_addr, size_t length);
> +int board_spl_fit_post_load(ulong load_addr, size_t length);
> 
>  /**
>   * board_spl_fit_size_align - specific size align before processing payload
> --
> 2.26.2



Re: [PATCH] usb: xhci-dwc3: Fix usage of bulk PHY API

2020-05-31 Thread Chunfeng Yun
Hi Samuel,

This bug was fixed up two weeks ago, 
https://patchwork.ozlabs.org/project/uboot/patch/1589435712-8795-1-git-send-email-chunfeng@mediatek.com/

thanks

On Sat, 2020-05-30 at 03:37 -0500, Samuel Holland wrote:
> The PHY consumer is responsible for allocating the struct phy_bulk.
> During conversion to the bulk API, the contents of the struct were
> replaced by a pointer instead of the struct itself. This leads to a null
> pointer dereference in generic_phy_get_bulk() when setting bulk->phys.
> 
> Fixes: 6dfb8a8052ee ("usb: dwc3: use the phy bulk API to get phys")
> Signed-off-by: Samuel Holland 
> ---
>  drivers/usb/host/xhci-dwc3.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
> index 563db1a426..9b22f271a7 100644
> --- a/drivers/usb/host/xhci-dwc3.c
> +++ b/drivers/usb/host/xhci-dwc3.c
> @@ -19,7 +19,7 @@
>  #include 
>  
>  struct xhci_dwc3_platdata {
> - struct phy_bulk *usb_phys;
> + struct phy_bulk usb_phys;
>  };
>  
>  void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
> @@ -124,7 +124,7 @@ static int xhci_dwc3_probe(struct udevice *dev)
>   hcor = (struct xhci_hcor *)((uintptr_t)hccr +
>   HC_LENGTH(xhci_readl(&(hccr)->cr_capbase)));
>  
> - ret = dwc3_setup_phy(dev, plat->usb_phys);
> + ret = dwc3_setup_phy(dev, >usb_phys);
>   if (ret && (ret != -ENOTSUPP))
>   return ret;
>  
> @@ -167,7 +167,7 @@ static int xhci_dwc3_remove(struct udevice *dev)
>  {
>   struct xhci_dwc3_platdata *plat = dev_get_platdata(dev);
>  
> - dwc3_shutdown_phy(dev, plat->usb_phys);
> + dwc3_shutdown_phy(dev, >usb_phys);
>  
>   return xhci_deregister(dev);
>  }



Re: [PATCH v2 1/2] rockchip: Enable PCIe/M.2 and NVMe on Firefly RK3399

2020-05-31 Thread Kever Yang

Hi Mark,

This is not able to apply directly, this is the first time I met this error:

$ git-pw patch apply 1297197
Applying: rockchip: Enable PCIe/M.2 and NVMe on Firefly RK3399
error: sha1 information is lacking or useless 
(configs/firefly-rk3399_defconfig).

error: could not build fake ancestor
Patch failed at 0001 rockchip: Enable PCIe/M.2 and NVMe on Firefly RK3399


If I use apply this patch manually, these two patch also have conflict 
due to "CONFIG_BAUDRATE".



Thanks,

- Kever

On 2020/5/25 下午5:00, Mark Kettenis wrote:

Enable CONFIG_PCI and CONFIG_NVME and related configs for the
Firefly RK3399 board.

Signed-off-by: Mark Kettenis 
Reviewed-by: Simon Glass 
---
Changes in v2:
- Extend commit message

  configs/firefly-rk3399_defconfig | 4 
  1 file changed, 4 insertions(+)

diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index 831a37d607..2f2a3edb72 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -19,6 +19,7 @@ CONFIG_CMD_BOOTZ=y
  CONFIG_CMD_GPT=y
  CONFIG_CMD_MMC=y
  CONFIG_CMD_USB=y
+CONFIG_CMD_PCI=y
  # CONFIG_CMD_SETEXPR is not set
  CONFIG_CMD_TIME=y
  CONFIG_SPL_OF_CONTROL=y
@@ -38,10 +39,13 @@ CONFIG_SF_DEFAULT_SPEED=2000
  CONFIG_DM_ETH=y
  CONFIG_ETH_DESIGNWARE=y
  CONFIG_GMAC_ROCKCHIP=y
+CONFIG_NVME=y
+CONFIG_PCI=y
  CONFIG_PMIC_RK8XX=y
  CONFIG_REGULATOR_PWM=y
  CONFIG_REGULATOR_RK8XX=y
  CONFIG_PWM_ROCKCHIP=y
+CONFIG_DM_RESET=y
  CONFIG_BAUDRATE=115200
  CONFIG_DEBUG_UART_SHIFT=2
  CONFIG_SYSRESET=y





Re: [PATCH v2 2/2] rockchip: Enable PCIe and NVMe on ROCKPro64

2020-05-31 Thread Kever Yang



On 2020/5/25 下午5:00, Mark Kettenis wrote:

Enable CONFIG_PCI and CONFIG_NVME and related configs for the
ROCKPro64 board.

Signed-off-by: Mark Kettenis 


Reviewed-by: Kever Yang 

Thanks,
- Kever




Re: [PATCH v2 1/2] rockchip: Enable PCIe/M.2 and NVMe on Firefly RK3399

2020-05-31 Thread Kever Yang



On 2020/5/25 下午5:00, Mark Kettenis wrote:

Enable CONFIG_PCI and CONFIG_NVME and related configs for the
Firefly RK3399 board.

Signed-off-by: Mark Kettenis 
Reviewed-by: Simon Glass 


Reviewed-by: Kever Yang 

Thanks,
- Kever




Re: [PATCH 0/3] doc: rockchip: Improve documentation

2020-05-31 Thread Kever Yang



On 2020/5/22 下午10:14, Walter Lozano wrote:

As an additional step in the process of improve the Rockchip documentation
and based on the comments from [1] move the list of supported boards and
configs to doc/board/rockchip.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=177974

Walter Lozano (3):
   doc: board: rockchip: Improve supported board list format
   doc: board: rockchip: Add missing supported boards
   doc: rockchip: Remove list of supported boards

  doc/README.rockchip | 72 ++--
  doc/board/rockchip/rockchip.rst | 84 -
  2 files changed, 54 insertions(+), 102 deletions(-)



Applied to u-boot-rockchip master.

Thanks,
- Kever




Re: [PATCH] pci: Make Rockchip PCIe voltage regulators optional

2020-05-31 Thread Kever Yang



On 2020/5/25 上午10:56, Kever Yang wrote:


On 2020/5/25 上午4:32, Mark Kettenis wrote:

The vpcie*-supply properties are optional and these are absent on
boards like the ROCKPro64 and Firefly RK3399 where the voltage is
supplied by always-on regulators that are already enabled upon
boot.  Make these regulators optional and properly check their
presence before attempting to enable them.

Makes PCIe work on un U-Boot on the boards mentioned above.

Signed-off-by: Mark Kettenis 


Reviewed-by: Kever Yang 


Applied to u-boot-rockchip master.

Thanks,
- Kever




Re: [PATCH] rockchip: rockpro64: enable DM_KEYBOARD

2020-05-31 Thread Kever Yang



On 2020/5/29 下午6:07, Kever Yang wrote:


On 2020/5/27 上午12:18, Marcin Juszkiewicz wrote:

USB stack uses DM so DM_KEYBOARD is needed to get USB keyboard working.

Signed-off-by: Marcin Juszkiewicz 


Reviewed-by: Kever Yang 


Applied to u-boot-rockchip master.

Thanks,
- Kever


Thanks,
- Kever

---
  configs/rockpro64-rk3399_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git configs/rockpro64-rk3399_defconfig 
configs/rockpro64-rk3399_defconfig

index 9d4343a5a7..a511c60d13 100644
--- configs/rockpro64-rk3399_defconfig
+++ configs/rockpro64-rk3399_defconfig
@@ -28,6 +28,7 @@ CONFIG_ENV_IS_IN_MMC=y
  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
  CONFIG_ROCKCHIP_GPIO=y
  CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_DM_KEYBOARD=y
  CONFIG_MISC=y
  CONFIG_ROCKCHIP_EFUSE=y
  CONFIG_MMC_DW=y










Re: [PATCH v6 00/16] Add Rockchip RK3399 USB3.0 Host support

2020-05-31 Thread Kever Yang



On 2020/5/26 上午11:32, Frank Wang wrote:

This series add quirks for DWC3 and add Rockchip RK3399 USB3.0 host support.

The function has been tested pass on rk3399-evb and roc-rk3399-pc board.

For V6 update:
  - Use [PATCH v6 04/16] instead of [PATCH v5 05/16] to fix that the current
Generic PHY subsystem is unable to find PHY if the PHY node is not part of
the root structure.
  - Add 'Reviewed-by' tag for all patches except [PATCH v6 04/16].

For V5 update:
  - Fix dwc3-generic driver followed Marek's comments for [PATCH v4 12/16].
  - Add 'Reviewed-by' and 'Tested-by' tag for [PATCH v4 07/16] and [PATCH v4 
08/16].

For V4 update:
  - Collect Jagan's all fixed patches [1].
  - Amend specific u-boot changes from dts to dtsi for [PATCH v3 6/7].

For V3 update:
  - Fix compile error for [PATCH v2 1/9].
  - Use Jagan's Type-C driver instead of [PATCH v2 5/9].
  - Cleanup dts changes for [PATCH v2 7/9].
  - Cleanup config changes for [PATCH v2 8/9] and [PATCH v2 9/9].

For V2 update:
  - Amend type-c driver followed Jagan's comments for [PATCH 5/8].
  - Fix dts commit for [PATCH 7/8].
  - Split RK3399 default config for [PATCH 8/8].
  - Add 'Reviewed-by' tag for [PATCH 1/8], [PATCH 2/8] and [PATCH 3/8].

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

BR,
Frank

Frank Wang (8):
   arm: mach-rockchip: bind sub-nodes for rk3399_syscon
   usb: dwc3: add dis_enblslpm_quirk
   usb: dwc3: add dis_u2_freeclk_exists_quirk
   usb: dwc3: amend UTMI/UTMIW phy interface setup
   usb: dwc3: add make compatible for rockchip platform
   driver: usb: drop legacy rockchip xhci driver
   ARM: dts: rk3399-evb: usb3.0 host support
   configs: evb-rk3399: update support usb3.0 host

Jagan Teki (8):
   clk: rk3399: Enable/Disable the USB2PHY clk
   clk: rk3399: Set empty for TCPHY assigned-clocks
   clk: rk3399: Enable/Disable TCPHY clocks
   phy: rockchip: Add Rockchip USB2PHY driver
   phy: rockchip: Add Rockchip USB TypeC PHY driver
   usb: dwc3: Add disable u2mac linestate check quirk
   usb: dwc3: Enable AutoRetry feature in the controller
   roc-rk3399-pc: Enable USB3.0 Host

  arch/arm/dts/rk3399-evb-u-boot.dtsi   |  13 +
  arch/arm/mach-rockchip/rk3399/syscon_rk3399.c |   3 +
  configs/evb-rk3399_defconfig  |   6 +
  configs/roc-pc-mezzanine-rk3399_defconfig |   5 +
  configs/roc-pc-rk3399_defconfig   |   6 +
  drivers/Makefile  |   1 +
  drivers/clk/rockchip/clk_rk3399.c |  38 +
  drivers/phy/Kconfig   |   1 +
  drivers/phy/rockchip/Kconfig  |  21 +
  drivers/phy/rockchip/Makefile |   7 +
  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 312 +++
  drivers/phy/rockchip/phy-rockchip-typec.c | 796 ++
  drivers/usb/common/common.c   |  25 +
  drivers/usb/dwc3/core.c   | 106 ++-
  drivers/usb/dwc3/core.h   |  19 +
  drivers/usb/dwc3/dwc3-generic.c   |  33 +-
  drivers/usb/host/Kconfig  |   9 -
  drivers/usb/host/Makefile |   1 -
  drivers/usb/host/xhci-rockchip.c  | 196 -
  include/dwc3-uboot.h  |   3 +
  include/linux/usb/phy.h   |  18 +
  21 files changed, 1376 insertions(+), 243 deletions(-)
  create mode 100644 drivers/phy/rockchip/Kconfig
  create mode 100644 drivers/phy/rockchip/Makefile
  create mode 100644 drivers/phy/rockchip/phy-rockchip-inno-usb2.c
  create mode 100644 drivers/phy/rockchip/phy-rockchip-typec.c
  delete mode 100644 drivers/usb/host/xhci-rockchip.c


Applied to u-boot-rockchip master.

Thanks,
- Kever




Re: [PATCH] rockchip: enable USB OHCI host for RockPro64

2020-05-31 Thread Kever Yang



On 2020/5/29 下午6:01, Kever Yang wrote:


On 2020/5/25 下午10:44, Marcin Juszkiewicz wrote:

U-Boot has video output enabled so time to get keyboard working.

=> usb reset;usb tree
resetting USB...
Bus usb@fe38: USB EHCI 1.00
Bus usb@fe3a: USB OHCI 1.0
Bus usb@fe3c: USB EHCI 1.00
Bus usb@fe3e: USB OHCI 1.0
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe38 for devices... 1 USB Device(s) found
scanning bus usb@fe3a for devices... 1 USB Device(s) found
scanning bus usb@fe3c for devices... 1 USB Device(s) found
scanning bus usb@fe3e for devices... 3 USB Device(s) found
scanning bus dwc3 for devices... cannot reset port 1!?
2 USB Device(s) found
    scanning usb for storage devices... 2 Storage Device(s) found
USB device tree:
   1  Hub (480 Mb/s, 0mA)
  u-boot EHCI Host Controller

   1  Hub (12 Mb/s, 0mA)
   U-Boot Root Hub

   1  Hub (480 Mb/s, 0mA)
  u-boot EHCI Host Controller

   1  Hub (12 Mb/s, 0mA)
   |   U-Boot Root Hub
   |
   +-2  Hub (12 Mb/s, 100mA)
 |  ALCOR Generic USB Hub
 |
 +-3  Mass Storage (12 Mb/s, 200mA)
  Kingston DT 101 G2 001478544887BB3157380157

   1  Hub (5 Gb/s, 0mA)
   |  U-Boot XHCI Host Controller
   |
   +-2  Mass Storage (5 Gb/s, 76mA)
    ADATA ADATA USB Flash Drive 1520405012240002

Signed-off-by: Marcin Juszkiewicz 


Reviewed-by: Kever Yang 


Applied to u-boot-rockchip master.

Thanks,
- Kever




Pull request: u-boot-rockchip-20200531

2020-05-31 Thread Kever Yang
Hi Tom,

Please pull the rockchip updates/fixes:
- Fix mmc of path after syncfrom kernel dts;
- Add dwc3 host support with DM for rk3399;
- Add usb2phy and typec phy for rockchip platform;
- Migrate board list doc to rockchip.rst;
- Add rk3399 Pinebook Pro board support;
- Update dram_init in board_init and add memory node in SPL;


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

Thanks,
- Kever

The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0:

  Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-05-27 
10:56:25 -0400)

are available in the Git repository at:

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

for you to fetch changes up to a343b4fe739a56ef248f01d96d80d080228b4068:

  spl: add fixed memory node in target fdt also when loading ATF (2020-05-31 
22:22:07 +0800)


Frank Wang (8):
  arm: mach-rockchip: bind sub-nodes for rk3399_syscon
  usb: dwc3: add dis_enblslpm_quirk
  usb: dwc3: add dis_u2_freeclk_exists_quirk
  usb: dwc3: amend UTMI/UTMIW phy interface setup
  usb: dwc3: add make compatible for rockchip platform
  driver: usb: drop legacy rockchip xhci driver
  ARM: dts: rk3399-evb: usb3.0 host support
  configs: evb-rk3399: update support usb3.0 host

Heiko Stuebner (2):
  rockchip: spl: do full dram_init instead of only probing
  spl: add fixed memory node in target fdt also when loading ATF

Jagan Teki (13):
  rockchip: Fix spl mmc boot device ofpath
  clk: rk3399: Fix eMMC get_clk reg offset
  arm64: dts: rk3399-nanopi4: Add u-boot,spl-boot-order
  nanopc-t4: Enable USB Gadget
  doc: rockchip: Document eMMC program steps
  clk: rk3399: Enable/Disable the USB2PHY clk
  clk: rk3399: Set empty for TCPHY assigned-clocks
  clk: rk3399: Enable/Disable TCPHY clocks
  phy: rockchip: Add Rockchip USB2PHY driver
  phy: rockchip: Add Rockchip USB TypeC PHY driver
  usb: dwc3: Add disable u2mac linestate check quirk
  usb: dwc3: Enable AutoRetry feature in the controller
  roc-rk3399-pc: Enable USB3.0 Host

Marcin Juszkiewicz (2):
  rockchip: enable USB OHCI host for RockPro64
  rockchip: rockpro64: enable DM_KEYBOARD

Mark Kettenis (2):
  pci: Make Rockchip PCIe voltage regulators optional
  rk3399: Enable NVMe distro bootcmd

Peter Robinson (3):
  dt-bindings: input: adopt Linux gpio-keys binding constants
  arm: dts: rockchip: Add initial DT for Pinebook Pro
  rockchip: Add initial support for the Pinebook Pro laptop from Pine64.

Walter Lozano (3):
  doc: board: rockchip: Improve supported board list format
  doc: board: rockchip: Add missing supported boards
  doc: rockchip: Remove list of supported boards

 arch/arm/dts/Makefile  |1 +
 arch/arm/dts/rk3399-evb-u-boot.dtsi|   15 +-
 arch/arm/dts/rk3399-ficus-u-boot.dtsi  |2 +-
 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi|6 +
 arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi   |   43 +
 arch/arm/dts/rk3399-pinebook-pro.dts   | 1096 
 arch/arm/dts/rk3399-rock960-u-boot.dtsi|2 +-
 arch/arm/mach-rockchip/rk3399/Kconfig  |8 +
 arch/arm/mach-rockchip/rk3399/rk3399.c |4 +-
 arch/arm/mach-rockchip/rk3399/syscon_rk3399.c  |3 +
 arch/arm/mach-rockchip/spl.c   |9 +-
 board/pine64/pinebook-pro-rk3399/Kconfig   |   15 +
 board/pine64/pinebook-pro-rk3399/MAINTAINERS   |8 +
 board/pine64/pinebook-pro-rk3399/Makefile  |1 +
 .../pinebook-pro-rk3399/pinebook-pro-rk3399.c  |   75 ++
 board/theobroma-systems/puma_rk3399/puma-rk3399.c  |4 +-
 common/spl/spl.c   |   19 +-
 configs/evb-rk3399_defconfig   |6 +
 configs/nanopc-t4-rk3399_defconfig |3 +
 configs/pinebook-pro-rk3399_defconfig  |   84 ++
 configs/roc-pc-mezzanine-rk3399_defconfig  |5 +
 configs/roc-pc-rk3399_defconfig|6 +
 configs/rockpro64-rk3399_defconfig |3 +
 doc/README.rockchip|   72 +-
 doc/board/rockchip/rockchip.rst|  116 ++-
 drivers/Makefile   |1 +
 drivers/clk/rockchip/clk_rk3399.c  |   40 +-
 drivers/pci/pcie_rockchip.c|   33 +-
 drivers/phy/Kconfig|1 +
 drivers/phy/rockchip/Kconfig   |   21 +
 drivers/phy/rockchip/Makefile  |7 +
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c  |  312 ++
 drivers/phy/rockchip/phy-rockchip-typec.c  |  796 ++
 drivers/usb/common/common.c

[PATCH] Nokia RX-51: Fix checking if serial console was enabled

2020-05-31 Thread Pali Rohár
There was incorrect logic for parsing OMAP_TAG_UART atag.

Signed-off-by: Pali Rohár 
---
 board/nokia/rx51/rx51.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c
index 2af387edc9..823316ea47 100644
--- a/board/nokia/rx51/rx51.c
+++ b/board/nokia/rx51/rx51.c
@@ -146,7 +146,7 @@ static void reuse_omap_atags(struct tag_omap *t)
}
break;
case OMAP_TAG_UART:
-   if (!t->u.uart.enabled_uarts)
+   if (t->u.uart.enabled_uarts)
serial_was_console_enabled = 1;
break;
case OMAP_TAG_SERIAL_CONSOLE:
-- 
2.20.1



[PATCH] Nokia RX-51: Add link for u-boot-gen-combined script to README file

2020-05-31 Thread Pali Rohár
This patch updates Nokia RX-51 README file.

Signed-off-by: Pali Rohár 
---
 doc/README.nokia_rx51 | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51
index 33c275b416..320b5efc7d 100644
--- a/doc/README.nokia_rx51
+++ b/doc/README.nokia_rx51
@@ -16,6 +16,11 @@ SD card or internal eMMC memory. If this fails or keyboard 
is closed then
 the appended kernel image will be booted using some generated and some
 stored ATAGs (see boot order).
 
+For generating combined image of u-boot and kernel there is a simple script
+called u-boot-gen-combined. It is available in following repository:
+
+  https://github.com/pali/u-boot-maemo
+
 There is support for hardware watchdog. Hardware watchdog is started by
 NOLO so u-boot must kick watchdog to prevent reboot device (but not very
 often, max every 2 seconds). There is also support for framebuffer display
-- 
2.20.1



[PATCH 1/1] efi_loader: validate load option

2020-05-31 Thread Heinrich Schuchardt
For passing the optional data of the load option to the loaded imaged
protocol we need its size.

efi_deserialize_load_option() is changed to return the size of the optional
data.

As a by-product we get a partial validation of the load option.
Checking the length of the device path remains to be implemented.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/efidebug.c   | 21 +++-
 include/efi_loader.h |  3 ++-
 lib/efi_loader/efi_bootmgr.c | 48 +---
 3 files changed, 56 insertions(+), 16 deletions(-)

diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 32430e62f0..58018f700c 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -694,14 +694,19 @@ static int do_efi_boot_rm(struct cmd_tbl *cmdtp, int flag,
  *
  * Decode the value of UEFI load option variable and print information.
  */
-static void show_efi_boot_opt_data(u16 *varname16, void *data, size_t size)
+static void show_efi_boot_opt_data(u16 *varname16, void *data, size_t *size)
 {
struct efi_load_option lo;
char *label, *p;
size_t label_len16, label_len;
u16 *dp_str;
+   efi_status_t ret;

-   efi_deserialize_load_option(, data);
+   ret = efi_deserialize_load_option(, data, size);
+   if (ret != EFI_SUCCESS) {
+   printf("%ls: invalid load option\n", varname16);
+   return;
+   }

label_len16 = u16_strlen(lo.label);
label_len = utf16_utf8_strnlen(lo.label, label_len16);
@@ -728,8 +733,7 @@ static void show_efi_boot_opt_data(u16 *varname16, void 
*data, size_t size)

printf("  data:\n");
print_hex_dump("", DUMP_PREFIX_OFFSET, 16, 1,
-  lo.optional_data, size + (u8 *)data -
-  (u8 *)lo.optional_data, true);
+  lo.optional_data, *size, true);
free(label);
 }

@@ -759,7 +763,7 @@ static void show_efi_boot_opt(u16 *varname16)
_global_variable_guid,
NULL, , data));
if (ret == EFI_SUCCESS)
-   show_efi_boot_opt_data(varname16, data, size);
+   show_efi_boot_opt_data(varname16, data, );
free(data);
}
 }
@@ -920,7 +924,12 @@ static int show_efi_boot_order(void)
goto out;
}

-   efi_deserialize_load_option(, data);
+   ret = efi_deserialize_load_option(, data, );
+   if (ret != EFI_SUCCESS) {
+   printf("%ls: invalid load option\n", var_name16);
+   ret = CMD_RET_FAILURE;
+   goto out;
+   }

label_len16 = u16_strlen(lo.label);
label_len = utf16_utf8_strnlen(lo.label, label_len16);
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 9533df26dc..c2cae814b6 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -708,7 +708,8 @@ struct efi_load_option {
const u8 *optional_data;
 };

-void efi_deserialize_load_option(struct efi_load_option *lo, u8 *data);
+efi_status_t efi_deserialize_load_option(struct efi_load_option *lo, u8 *data,
+efi_uintn_t *size);
 unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 **data);
 efi_status_t efi_bootmgr_load(efi_handle_t *handle);

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index fa65445c12..e268e9c4b8 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -38,24 +38,50 @@ static const struct efi_runtime_services *rs;
  *
  * @lo:pointer to target
  * @data:  serialized data
+ * @size:  size of the load option, on return size of the optional data
+ * Return: status code
  */
-void efi_deserialize_load_option(struct efi_load_option *lo, u8 *data)
+efi_status_t efi_deserialize_load_option(struct efi_load_option *lo, u8 *data,
+efi_uintn_t *size)
 {
+   efi_uintn_t len;
+
+   len = sizeof(u32);
+   if (*size < len + 2 * sizeof(u16))
+   return EFI_INVALID_PARAMETER;
lo->attributes = get_unaligned_le32(data);
-   data += sizeof(u32);
+   data += len;
+   *size -= len;

+   len = sizeof(u16);
lo->file_path_length = get_unaligned_le16(data);
-   data += sizeof(u16);
+   data += len;
+   *size -= len;

-   /* FIXME */
lo->label = (u16 *)data;
-   data += (u16_strlen(lo->label) + 1) * sizeof(u16);
-
-   /* FIXME */
+   len = u16_strnlen(lo->label, *size / sizeof(u16) - 1);
+   if (lo->label[len])
+   return EFI_INVALID_PARAMETER;
+   len = (len + 1) * sizeof(u16);
+   if (*size < len)
+   return EFI_INVALID_PARAMETER;
+   data += len;
+   *size -= len;
+
+   len = lo->file_path_length;
+   if (*size 

Re: [PATCH 1/1] test/py: use actual core count for parallel builds

2020-05-31 Thread Stephen Warren
On 5/30/20 4:44 PM, Heinrich Schuchardt wrote:
> When building U-Boot we should not blindly use make -j8 but consider the
> actual core count given by os.cpu_count().

Acked-by: Stephen Warren 


Re: [PATCH v3] spl: allow board_spl_fit_post_load() to fail

2020-05-31 Thread Marek Vasut
On 5/31/20 7:25 PM, Patrick Wildt wrote:
> On i.MX platforms board_spl_fit_post_load() can check the loaded
> SPL image for authenticity using its HAB engine.  U-Boot's SPL
> mechanism allows booting images from other sources as well, but
> in the current setup the SPL would just hang if it encounters an
> image that does not pass scrutiny.  Allowing the function to return
> an error, allows the SPL to try booting from another source as a
> fallback instead of ending up as a brick.
> 
> Signed-off-by: Patrick Wildt 

Reviewed-by: Marek Vasut 


[PATCH v3] spl: allow board_spl_fit_post_load() to fail

2020-05-31 Thread Patrick Wildt
On i.MX platforms board_spl_fit_post_load() can check the loaded
SPL image for authenticity using its HAB engine.  U-Boot's SPL
mechanism allows booting images from other sources as well, but
in the current setup the SPL would just hang if it encounters an
image that does not pass scrutiny.  Allowing the function to return
an error, allows the SPL to try booting from another source as a
fallback instead of ending up as a brick.

Signed-off-by: Patrick Wildt 
---
Changes in v3:
 - use EINVAL as return value to have a proper errno

Changes in v2:
 - set SPL_FIT_FOUND only after successful post load

 arch/arm/mach-imx/spl.c |  6 --
 common/spl/spl_fit.c| 10 ++
 include/spl.h   |  2 +-
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 1a231c67f5a..1a0d979e2d0 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -313,7 +313,7 @@ ulong board_spl_fit_size_align(ulong size)
return size;
 }
 
-void board_spl_fit_post_load(ulong load_addr, size_t length)
+int board_spl_fit_post_load(ulong load_addr, size_t length)
 {
u32 offset = length - CONFIG_CSF_SIZE;
 
@@ -321,8 +321,10 @@ void board_spl_fit_post_load(ulong load_addr, size_t 
length)
   offset + IVT_SIZE + CSF_PAD_SIZE,
   offset)) {
puts("spl: ERROR:  image authentication unsuccessful\n");
-   hang();
+   return -EINVAL;
}
+
+   return 0;
 }
 #endif
 
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index f581a224213..ead4c6713af 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -26,8 +26,9 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20)
 #endif
 
-__weak void board_spl_fit_post_load(ulong load_addr, size_t length)
+__weak int board_spl_fit_post_load(ulong load_addr, size_t length)
 {
+   return 0;
 }
 
 __weak ulong board_spl_fit_size_align(ulong size)
@@ -677,11 +678,12 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (spl_image->entry_point == FDT_ERROR || spl_image->entry_point == 0)
spl_image->entry_point = spl_image->load_addr;
 
-   spl_image->flags |= SPL_FIT_FOUND;
-
 #ifdef CONFIG_IMX_HAB
-   board_spl_fit_post_load((ulong)fit, size);
+   ret = board_spl_fit_post_load((ulong)fit, size);
+   if (ret)
+   return ret;
 #endif
 
+   spl_image->flags |= SPL_FIT_FOUND;
return 0;
 }
diff --git a/include/spl.h b/include/spl.h
index b31c9bb4ab2..2607767d940 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -564,7 +564,7 @@ int board_return_to_bootrom(struct spl_image_info 
*spl_image,
  * board_spl_fit_post_load - allow process images after loading finished
  *
  */
-void board_spl_fit_post_load(ulong load_addr, size_t length);
+int board_spl_fit_post_load(ulong load_addr, size_t length);
 
 /**
  * board_spl_fit_size_align - specific size align before processing payload
-- 
2.26.2



Re: [PATCH] ARM: imx: hab: panic on authentication failure

2020-05-31 Thread Patrick Wildt
On Sun, May 31, 2020 at 06:51:14PM +0200, Marek Vasut wrote:
> On 5/31/20 5:53 PM, Patrick Wildt wrote:
> > On Sun, May 31, 2020 at 05:38:05PM +0200, Marek Vasut wrote:
> >> On 5/30/20 10:53 PM, Patrick Wildt wrote:
> >>> On Sat, May 30, 2020 at 10:29:19PM +0200, Marek Vasut wrote:
>  On 5/30/20 10:14 PM, Patrick Wildt wrote:
> > On Sat, May 30, 2020 at 03:31:29PM -0300, Fabio Estevam wrote:
> >> Hi Marek,
> >>
> >> [Adding Breno]
> >>
> >> On Sat, May 30, 2020 at 3:29 PM Marek Vasut  wrote:
> >>>
> >>> Instead of hang()ing the system and thus disallowing any automated
> >>> recovery possibility from a HAB authentication failure, panic() .
> >>> The panic() function can be configured to hang() the system after
> >>> printing an error message, however the default is to reset the
> >>> system instead.
> >>>
> >>> This allows redundant boot to work correctly. In case the primary
> >>> or secondary image cannot be authenticated, the system reboots and
> >>> bootrom can try to start the other one.
> >>>
> >>> Signed-off-by: Marek Vasut 
> >>> Cc: Fabio Estevam 
> >>> Cc: NXP i.MX U-Boot Team 
> >>> Cc: Peng Fan 
> >>> Cc: Stefano Babic 
> >>
> >> This is a better behavior indeed:
> >>
> >> Reviewed-by: Fabio Estevam 
> >
> > What about this?  Have you ignored this patch for a reason? :/
> >
> > https://marc.info/?l=u-boot=159069441005730=2
> 
>  Yes, and the reason is I was not even aware of your patch, sorry. The CC
>  list in this mail should cover all the interested parties, so use it
>  when sending V2, or use patman.
> >>>
> >>> I already had 11 people on CC, but apparently I missed you.
> >>>
>  The patch looks fine, one nit is that you should return errno.h return
>  value and another is that it changes the current behavior. Now that I
>  look at this imx code, board_spl_fit_post_load() should not even be in
>  arch/ , sigh, but that's for separate patch either way.
> 
>  So I think if you want to support this sort of fallback, you should make
>  the board_spl_fit_post_load() be in board/ files, with default __weak
>  implementation calling some arch_hab_authenticate...() which implements
>  current content of board_spl_fit_post_load(), and let boards decide how
>  to handle the fallback if it needs to be altered.
> 
>  Would that work ?
> >>>
> >>> I'm not sure.  In comparison to the people from NXP who are paid to
> >>> upstream their code and still don't do it correctly, I'm doing this
> >>> in my spare time and I'm not sure I want to bikeshed all day long.
> >>>
> >>> I can send a V3 that replaces the -1 with EINVAL, EACCESS, EPERM or
> >>> something the like.  If you want to clean up after NXP, feel free to.
> >>
> >> In fact, what is it that you're trying to achieve with this fallback ?
> >> What are you falling back to , another fallback fitImage ?
> > 
> > Exactly.
> > 
> > I have a device with a glued enclosure, with no external sources, apart
> > from a serial console.  If the SPL fails to load the U-Boot main image
> > from eMMC, the only way to fix it is to destroy the case, open up the
> > enclosure and short some lines.  That's not really nice, since we'd have
> > to get a new enclosure, new serial number label,... it's a hassle.
> 
> Look for SRC PERSIST_SECONDARY_BOOT in your datasheet then. This will
> let you use two copies of SPL, two copies of U-Boot, etc.

I'll have a look!

> > If the SPL was gone as well, the BootROM would fall back to other
> > sources.  But with only one half of U-Boot missing, it would just hang.
> > I'm sure that's also why you replace the hang() with a panic().
> > 
> > I thought that if the SPL is still fine, but only the U-Boot image was
> > gone, why not make use of the spl_boot_list to try and boot from another
> > source?  Like yModem.  For that I sent the following fix, also with many
> > people CCd:
> > 
> > https://marc.info/?l=u-boot=158893200030861=2
> > 
> > Now the board spl boot order can have eMMC as first, and yModem as
> > second.  If eMMC fails, it falls back to yModem.  If none work, it
> > though hang()s, doing
> > 
> > puts(SPL_TPL_PROMPT "failed to boot from all boot devices\n");
> > hang();
> > 
> > Maybe you want this as panic instead?
> > 
> > Anyway, I think this is nicer option for recovery, instead of simply
> > hanging or rebooting.
> 
> The problem is, this only works for fitImage and not for raw uImage. But
> in your case, that is probably OK.
> 
> So if you can just fix the errno return value to some -EINVAL (?) and
> send a V3, I think that would be good.

Ok, will do, thanks!


Re: [PATCH] ARM: imx: hab: panic on authentication failure

2020-05-31 Thread Marek Vasut
On 5/31/20 5:53 PM, Patrick Wildt wrote:
> On Sun, May 31, 2020 at 05:38:05PM +0200, Marek Vasut wrote:
>> On 5/30/20 10:53 PM, Patrick Wildt wrote:
>>> On Sat, May 30, 2020 at 10:29:19PM +0200, Marek Vasut wrote:
 On 5/30/20 10:14 PM, Patrick Wildt wrote:
> On Sat, May 30, 2020 at 03:31:29PM -0300, Fabio Estevam wrote:
>> Hi Marek,
>>
>> [Adding Breno]
>>
>> On Sat, May 30, 2020 at 3:29 PM Marek Vasut  wrote:
>>>
>>> Instead of hang()ing the system and thus disallowing any automated
>>> recovery possibility from a HAB authentication failure, panic() .
>>> The panic() function can be configured to hang() the system after
>>> printing an error message, however the default is to reset the
>>> system instead.
>>>
>>> This allows redundant boot to work correctly. In case the primary
>>> or secondary image cannot be authenticated, the system reboots and
>>> bootrom can try to start the other one.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Fabio Estevam 
>>> Cc: NXP i.MX U-Boot Team 
>>> Cc: Peng Fan 
>>> Cc: Stefano Babic 
>>
>> This is a better behavior indeed:
>>
>> Reviewed-by: Fabio Estevam 
>
> What about this?  Have you ignored this patch for a reason? :/
>
> https://marc.info/?l=u-boot=159069441005730=2

 Yes, and the reason is I was not even aware of your patch, sorry. The CC
 list in this mail should cover all the interested parties, so use it
 when sending V2, or use patman.
>>>
>>> I already had 11 people on CC, but apparently I missed you.
>>>
 The patch looks fine, one nit is that you should return errno.h return
 value and another is that it changes the current behavior. Now that I
 look at this imx code, board_spl_fit_post_load() should not even be in
 arch/ , sigh, but that's for separate patch either way.

 So I think if you want to support this sort of fallback, you should make
 the board_spl_fit_post_load() be in board/ files, with default __weak
 implementation calling some arch_hab_authenticate...() which implements
 current content of board_spl_fit_post_load(), and let boards decide how
 to handle the fallback if it needs to be altered.

 Would that work ?
>>>
>>> I'm not sure.  In comparison to the people from NXP who are paid to
>>> upstream their code and still don't do it correctly, I'm doing this
>>> in my spare time and I'm not sure I want to bikeshed all day long.
>>>
>>> I can send a V3 that replaces the -1 with EINVAL, EACCESS, EPERM or
>>> something the like.  If you want to clean up after NXP, feel free to.
>>
>> In fact, what is it that you're trying to achieve with this fallback ?
>> What are you falling back to , another fallback fitImage ?
> 
> Exactly.
> 
> I have a device with a glued enclosure, with no external sources, apart
> from a serial console.  If the SPL fails to load the U-Boot main image
> from eMMC, the only way to fix it is to destroy the case, open up the
> enclosure and short some lines.  That's not really nice, since we'd have
> to get a new enclosure, new serial number label,... it's a hassle.

Look for SRC PERSIST_SECONDARY_BOOT in your datasheet then. This will
let you use two copies of SPL, two copies of U-Boot, etc.

> If the SPL was gone as well, the BootROM would fall back to other
> sources.  But with only one half of U-Boot missing, it would just hang.
> I'm sure that's also why you replace the hang() with a panic().
> 
> I thought that if the SPL is still fine, but only the U-Boot image was
> gone, why not make use of the spl_boot_list to try and boot from another
> source?  Like yModem.  For that I sent the following fix, also with many
> people CCd:
> 
> https://marc.info/?l=u-boot=158893200030861=2
> 
> Now the board spl boot order can have eMMC as first, and yModem as
> second.  If eMMC fails, it falls back to yModem.  If none work, it
> though hang()s, doing
> 
>   puts(SPL_TPL_PROMPT "failed to boot from all boot devices\n");
>   hang();
> 
> Maybe you want this as panic instead?
> 
> Anyway, I think this is nicer option for recovery, instead of simply
> hanging or rebooting.

The problem is, this only works for fitImage and not for raw uImage. But
in your case, that is probably OK.

So if you can just fix the errno return value to some -EINVAL (?) and
send a V3, I think that would be good.


Re: [PATCH 1/1] log: check argument of 'log level' command

2020-05-31 Thread Simon Glass
On Sun, 31 May 2020 at 07:44, Heinrich Schuchardt  wrote:
>
> Check that the argument provided to the 'log level' command is in the range
> between zero and CONFIG_LOG_MAX_LEVEL.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/log.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

Then we should have a little test for the log command, perhaps
run_command() and then check that the default log level is set (or
not, on error).


Re: [PATCH 1/1] doc: move README.log to HTML documentation

2020-05-31 Thread Simon Glass
On Sun, 31 May 2020 at 02:46, Heinrich Schuchardt  wrote:
>
> Convert README.log to reStructuredText and add it to the generated HTML
> documentation.
>
> Assign doc/develop/logging.rst to the maintainer of LOGGING.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  MAINTAINERS |   1 +
>  doc/README.log  | 285 ---
>  doc/develop/index.rst   |   1 +
>  doc/develop/logging.rst | 290 
>  4 files changed, 292 insertions(+), 285 deletions(-)
>  delete mode 100644 doc/README.log
>  create mode 100644 doc/develop/logging.rst

Reviewed-by: Simon Glass 


Re: [PATCH 1/1] virtio: VIRTIO_RNG depends on DM_RNG

2020-05-31 Thread Simon Glass
On Sun, 31 May 2020 at 03:08, Heinrich Schuchardt  wrote:
>
> Add the missing Kconfig dependency and let VIRTIO_RNG default to yes.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/virtio/Kconfig | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 1/1] log: clean up Kconfig

2020-05-31 Thread Simon Glass
On Sun, 31 May 2020 at 07:34, Heinrich Schuchardt  wrote:
>
> LOG_DEFAULT_LEVEL has been chosen as 6. Adjust the default of LOG_MAX_LEVEL
> to this value.
>
> Use ranges to clamp log levels to reasonable values.
>
> Group output options by main U-Boot, SPL, TPL, followed by other logging
> options.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/Kconfig | 159 ++---
>  1 file changed, 85 insertions(+), 74 deletions(-)

Reviewed-by: Simon Glass 


Re: printk

2020-05-31 Thread Simon Glass
Hi Heinrich,

On Sun, 31 May 2020 at 09:34, Heinrich Schuchardt  wrote:
>
> Hello Simon,
>
> in some drivers we use printk() which is restricted by CONFIG_LOGLEVEL
> and translates to printf().
>
> Shouldn't printk() be translated to log() instead?
>
> CONFIG_LOGLEVEL probably should better be renamed to
> CONFIG_PRINTK_LOGLEVEL to avoid confusion.
>
> And those different levels like KERN_WARNING should probably be properly
> defined to translate into out log levels.

Yes definitely. I have been thinking about those things for a while,
not to mention dev_err() and friends.

Regards,
Simon


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

2020-05-31 Thread Tom Rini
On Sun, May 31, 2020 at 11:47:44PM +0800, Kever Yang wrote:

> Hi Tom,
> 
>     Please ignore this patch, I'm going to send a new PR with pinebook Pro
> support.

OK.

> 
> 
> Thanks,
> 
> - Kever
> 
> On 2020/5/31 上午9:51, Kever Yang wrote:
> > Hi Tom,
> > 
> > Please pull the rockchip updates/fixes:
> > - Fix mmc of path after syncfrom kernel dts;
> > - Add dwc3 host support with DM for rk3399;
> > - Add usb2phy and typec phy for rockchip platform;
> > - Migrate board list doc to rockchip.rst
> > 
> > Gitlab ci:
> > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3495
> > 
> > Thanks,
> > - Kever
> > 
> > The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0:
> > 
> >Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell 
> > (2020-05-27 10:56:25 -0400)
> > 
> > are available in the Git repository at:
> > 
> >https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> > tags/u-boot-rockchip-20200530
> > 
> > for you to fetch changes up to 63a3c89855cabc173c76a9958053408d34d33dc2:
> > 
> >rockchip: rockpro64: enable DM_KEYBOARD (2020-05-30 07:38:50 +0800)
> > 
> > 
> > Frank Wang (8):
> >arm: mach-rockchip: bind sub-nodes for rk3399_syscon
> >usb: dwc3: add dis_enblslpm_quirk
> >usb: dwc3: add dis_u2_freeclk_exists_quirk
> >usb: dwc3: amend UTMI/UTMIW phy interface setup
> >usb: dwc3: add make compatible for rockchip platform
> >driver: usb: drop legacy rockchip xhci driver
> >ARM: dts: rk3399-evb: usb3.0 host support
> >configs: evb-rk3399: update support usb3.0 host
> > 
> > Jagan Teki (13):
> >rockchip: Fix spl mmc boot device ofpath
> >clk: rk3399: Fix eMMC get_clk reg offset
> >arm64: dts: rk3399-nanopi4: Add u-boot,spl-boot-order
> >nanopc-t4: Enable USB Gadget
> >doc: rockchip: Document eMMC program steps
> >clk: rk3399: Enable/Disable the USB2PHY clk
> >clk: rk3399: Set empty for TCPHY assigned-clocks
> >clk: rk3399: Enable/Disable TCPHY clocks
> >phy: rockchip: Add Rockchip USB2PHY driver
> >phy: rockchip: Add Rockchip USB TypeC PHY driver
> >usb: dwc3: Add disable u2mac linestate check quirk
> >usb: dwc3: Enable AutoRetry feature in the controller
> >roc-rk3399-pc: Enable USB3.0 Host
> > 
> > Marcin Juszkiewicz (2):
> >rockchip: enable USB OHCI host for RockPro64
> >rockchip: rockpro64: enable DM_KEYBOARD
> > 
> > Mark Kettenis (2):
> >pci: Make Rockchip PCIe voltage regulators optional
> >rk3399: Enable NVMe distro bootcmd
> > 
> > Walter Lozano (3):
> >doc: board: rockchip: Improve supported board list format
> >doc: board: rockchip: Add missing supported boards
> >doc: rockchip: Remove list of supported boards
> > 
> >   arch/arm/dts/rk3399-evb-u-boot.dtsi   |  15 +-
> >   arch/arm/dts/rk3399-ficus-u-boot.dtsi |   2 +-
> >   arch/arm/dts/rk3399-nanopi4-u-boot.dtsi   |   6 +
> >   arch/arm/dts/rk3399-rock960-u-boot.dtsi   |   2 +-
> >   arch/arm/mach-rockchip/rk3399/rk3399.c|   4 +-
> >   arch/arm/mach-rockchip/rk3399/syscon_rk3399.c |   3 +
> >   board/theobroma-systems/puma_rk3399/puma-rk3399.c |   4 +-
> >   configs/evb-rk3399_defconfig  |   6 +
> >   configs/nanopc-t4-rk3399_defconfig|   3 +
> >   configs/roc-pc-mezzanine-rk3399_defconfig |   5 +
> >   configs/roc-pc-rk3399_defconfig   |   6 +
> >   configs/rockpro64-rk3399_defconfig|   3 +
> >   doc/README.rockchip   |  72 +-
> >   doc/board/rockchip/rockchip.rst   | 116 +++-
> >   drivers/Makefile  |   1 +
> >   drivers/clk/rockchip/clk_rk3399.c |  40 +-
> >   drivers/pci/pcie_rockchip.c   |  33 +-
> >   drivers/phy/Kconfig   |   1 +
> >   drivers/phy/rockchip/Kconfig  |  21 +
> >   drivers/phy/rockchip/Makefile |   7 +
> >   drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 312 +
> >   drivers/phy/rockchip/phy-rockchip-typec.c | 796 
> > ++
> >   drivers/usb/common/common.c   |  25 +
> >   drivers/usb/dwc3/core.c   | 106 ++-
> >   drivers/usb/dwc3/core.h   |  19 +
> >   drivers/usb/dwc3/dwc3-generic.c   |  34 +-
> >   drivers/usb/host/Kconfig  |   9 -
> >   drivers/usb/host/Makefile |   1 -
> >   drivers/usb/host/xhci-rockchip.c  | 197 --
> >   include/configs/rockchip-common.h |   7 +
> >   include/configs/rockpro64_rk3399.h|   2 +
> >   include/dwc3-uboot.h  

[PATCHv5][2/2] rockchip: rk3328: add rock-pi-e-rk3328_defconfig file

2020-05-31 Thread b.l.huang
This commit add the default configuration file and relevant description
for rock-pi-e board

Signed-off-by: Banglang Huang 
---
 board/rockchip/evb_rk3328/MAINTAINERS |   7 ++
 configs/rock-pi-e-rk3328_defconfig| 104 ++
 doc/board/rockchip/rockchip.rst   |   1 +
 3 files changed, 112 insertions(+)
 create mode 100644 configs/rock-pi-e-rk3328_defconfig

diff --git a/board/rockchip/evb_rk3328/MAINTAINERS 
b/board/rockchip/evb_rk3328/MAINTAINERS
index 89becf41c5..e7dd59ff4e 100644
--- a/board/rockchip/evb_rk3328/MAINTAINERS
+++ b/board/rockchip/evb_rk3328/MAINTAINERS
@@ -17,3 +17,10 @@ M:  Matwey V. Kornilov 
 S:  Maintained
 F:  configs/rock64-rk3328_defconfig
 F:  arch/arm/dts/rk3328-rock64-u-boot.dtsi
+
+ROCKPIE-RK3328
+M:  Banglang Huang 
+S:  Maintained
+F:  configs/rock-pi-e-rk3328_defconfig
+F:  arch/arm/dts/rk3328-rock-pi-e.dts
+F:  arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
diff --git a/configs/rock-pi-e-rk3328_defconfig 
b/configs/rock-pi-e-rk3328_defconfig
new file mode 100644
index 00..759838775f
--- /dev/null
+++ b/configs/rock-pi-e-rk3328_defconfig
@@ -0,0 +1,104 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_ROCKCHIP_RK3328=y
+CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_TPL_LIBCOMMON_SUPPORT=y
+CONFIG_TPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x400
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xFF13
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SMBIOS_PRODUCT_NAME="rock-pi-e_rk3328"
+CONFIG_DEBUG_UART=y
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x800
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock-pi-e.dtb"
+CONFIG_MISC_INIT_R=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_TPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
+CONFIG_TPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_TPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock-pi-e"
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_TPL_OF_PLATDATA=y
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_TPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_TPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_TPL_SYSCON=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_FASTBOOT_BUF_ADDR=0x800800
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2000
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_SPL_DM_REGULATOR=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_SPL_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_RAM=y
+CONFIG_SPL_RAM=y
+CONFIG_TPL_RAM=y
+CONFIG_DM_RESET=y
+CONFIG_BAUDRATE=150
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_SYSRESET=y
+# CONFIG_TPL_SYSRESET is not set
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_GENERIC=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_SPL_TINY_MEMSET=y
+CONFIG_TPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
+CONFIG_SMBIOS_MANUFACTURER="radxa"
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 7b72fab496..e7dee7d0ac 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -48,6 +48,7 @@ List of mainline supported rockchip boards:
  - Rockchip Evb-RK3328 (evb-rk3328)
  - Pine64 Rock64 (rock64-rk3328)
  - Firefly-RK3328 (roc-cc-rk3328)
+ - Radxa Rockpi E (rock-pi-e-rk3328)
 * rk3368
  - GeekBox (geekbox)
  - PX5 EVB (evb-px5)
-- 
2.17.1

[PATCHv5][1/2] rockchip: rk3328: add rock-pi-e dts file

2020-05-31 Thread b.l.huang
The ROCK-PI-E is a credit card size SBC based on Rockchip RK3328
Quad-Core ARM Cortex A53.

Net - Dual ethernet port, 1 X Gbe, 1 X 100M
USB - USB 3.0
DC  - USB-Type C, 5V 2A
Storage - TF card, eMMC

Just build idbloader.img and u-boot.itb for Rockpi E board and
follow the blow steps to replace the relevant partition.

dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc
dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc

Signed-off-by: Banglang Huang 
---

Changes for v5
- Update the board information to
  doc/board/rockchip/rockchip.rst

Changes for v4

- separate dts file to another commit
- fix bootup on tpl / spl mode

Changes for v3

- rename to rock-pi-e

Changes for v2

- add introduction for rockpie in doc/README.rockchip
- enable CONFIG_MISC_INIT_R, CONFIG_SMBIOS_MANUFACTURER,
  and CONFIG_SMBIOS_PRODUCT_NAME
---
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi |  33 +++
 arch/arm/dts/rk3328-rock-pi-e.dts | 267 ++
 3 files changed, 302 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3328-rock-pi-e.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 12ec6c71dc..67d1adea2d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -107,7 +107,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
 dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
rk3328-roc-cc.dtb \
-   rk3328-rock64.dtb
+   rk3328-rock64.dtb \
+   rk3328-rock-pi-e.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3368) += \
rk3368-lion.dtb \
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi 
b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
new file mode 100644
index 00..bf5b1f3adc
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Radxa
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr3-666.dtsi"
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_gpio {
+   u-boot,dm-spl;
+};
+
+_pull_up_4ma {
+   u-boot,dm-spl;
+};
+
+_host0_xhci {
+   vbus-supply = <_host_xhci>;
+   status = "okay";
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+_sd {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3328-rock-pi-e.dts 
b/arch/arm/dts/rk3328-rock-pi-e.dts
new file mode 100644
index 00..21656b64a2
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e.dts
@@ -0,0 +1,267 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Radxa
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Radxa Rockpi E";
+   compatible = "radxa,rock-pi-e", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio>;
+   regulator-name = "vcc_sd";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_io>;
+   };
+
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   regulator-name = "vcc5v0_host_xhci";
+   gpio = < RK_PA7 GPIO_ACTIVE_HIGH>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc_sys: vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+   supports-emmc;
+   disable-wp;
+   non-removable;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _bus8>;
+   vmmc-supply = <_io>;
+   vqmmc-supply = <_emmc>;
+   status = "okay";
+};
+
+ {
+   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <_clkin>, <_clkin>;
+   clock_in_out = "input";
+   phy-supply = <_io>;
+   phy-mode = "rgmii";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   snps,force_thresh_dma_mode;
+   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 

Re: [PATCH] ARM: imx: hab: panic on authentication failure

2020-05-31 Thread Patrick Wildt
On Sun, May 31, 2020 at 05:38:05PM +0200, Marek Vasut wrote:
> On 5/30/20 10:53 PM, Patrick Wildt wrote:
> > On Sat, May 30, 2020 at 10:29:19PM +0200, Marek Vasut wrote:
> >> On 5/30/20 10:14 PM, Patrick Wildt wrote:
> >>> On Sat, May 30, 2020 at 03:31:29PM -0300, Fabio Estevam wrote:
>  Hi Marek,
> 
>  [Adding Breno]
> 
>  On Sat, May 30, 2020 at 3:29 PM Marek Vasut  wrote:
> >
> > Instead of hang()ing the system and thus disallowing any automated
> > recovery possibility from a HAB authentication failure, panic() .
> > The panic() function can be configured to hang() the system after
> > printing an error message, however the default is to reset the
> > system instead.
> >
> > This allows redundant boot to work correctly. In case the primary
> > or secondary image cannot be authenticated, the system reboots and
> > bootrom can try to start the other one.
> >
> > Signed-off-by: Marek Vasut 
> > Cc: Fabio Estevam 
> > Cc: NXP i.MX U-Boot Team 
> > Cc: Peng Fan 
> > Cc: Stefano Babic 
> 
>  This is a better behavior indeed:
> 
>  Reviewed-by: Fabio Estevam 
> >>>
> >>> What about this?  Have you ignored this patch for a reason? :/
> >>>
> >>> https://marc.info/?l=u-boot=159069441005730=2
> >>
> >> Yes, and the reason is I was not even aware of your patch, sorry. The CC
> >> list in this mail should cover all the interested parties, so use it
> >> when sending V2, or use patman.
> > 
> > I already had 11 people on CC, but apparently I missed you.
> > 
> >> The patch looks fine, one nit is that you should return errno.h return
> >> value and another is that it changes the current behavior. Now that I
> >> look at this imx code, board_spl_fit_post_load() should not even be in
> >> arch/ , sigh, but that's for separate patch either way.
> >>
> >> So I think if you want to support this sort of fallback, you should make
> >> the board_spl_fit_post_load() be in board/ files, with default __weak
> >> implementation calling some arch_hab_authenticate...() which implements
> >> current content of board_spl_fit_post_load(), and let boards decide how
> >> to handle the fallback if it needs to be altered.
> >>
> >> Would that work ?
> > 
> > I'm not sure.  In comparison to the people from NXP who are paid to
> > upstream their code and still don't do it correctly, I'm doing this
> > in my spare time and I'm not sure I want to bikeshed all day long.
> > 
> > I can send a V3 that replaces the -1 with EINVAL, EACCESS, EPERM or
> > something the like.  If you want to clean up after NXP, feel free to.
> 
> In fact, what is it that you're trying to achieve with this fallback ?
> What are you falling back to , another fallback fitImage ?

Exactly.

I have a device with a glued enclosure, with no external sources, apart
from a serial console.  If the SPL fails to load the U-Boot main image
from eMMC, the only way to fix it is to destroy the case, open up the
enclosure and short some lines.  That's not really nice, since we'd have
to get a new enclosure, new serial number label,... it's a hassle.

If the SPL was gone as well, the BootROM would fall back to other
sources.  But with only one half of U-Boot missing, it would just hang.
I'm sure that's also why you replace the hang() with a panic().

I thought that if the SPL is still fine, but only the U-Boot image was
gone, why not make use of the spl_boot_list to try and boot from another
source?  Like yModem.  For that I sent the following fix, also with many
people CCd:

https://marc.info/?l=u-boot=158893200030861=2

Now the board spl boot order can have eMMC as first, and yModem as
second.  If eMMC fails, it falls back to yModem.  If none work, it
though hang()s, doing

puts(SPL_TPL_PROMPT "failed to boot from all boot devices\n");
hang();

Maybe you want this as panic instead?

Anyway, I think this is nicer option for recovery, instead of simply
hanging or rebooting.

Patrick


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

2020-05-31 Thread Kever Yang

Hi Tom,

    Please ignore this patch, I'm going to send a new PR with pinebook 
Pro support.



Thanks,

- Kever

On 2020/5/31 上午9:51, Kever Yang wrote:

Hi Tom,

Please pull the rockchip updates/fixes:
- Fix mmc of path after syncfrom kernel dts;
- Add dwc3 host support with DM for rk3399;
- Add usb2phy and typec phy for rockchip platform;
- Migrate board list doc to rockchip.rst

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

Thanks,
- Kever

The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0:

   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-05-27 
10:56:25 -0400)

are available in the Git repository at:

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

for you to fetch changes up to 63a3c89855cabc173c76a9958053408d34d33dc2:

   rockchip: rockpro64: enable DM_KEYBOARD (2020-05-30 07:38:50 +0800)


Frank Wang (8):
   arm: mach-rockchip: bind sub-nodes for rk3399_syscon
   usb: dwc3: add dis_enblslpm_quirk
   usb: dwc3: add dis_u2_freeclk_exists_quirk
   usb: dwc3: amend UTMI/UTMIW phy interface setup
   usb: dwc3: add make compatible for rockchip platform
   driver: usb: drop legacy rockchip xhci driver
   ARM: dts: rk3399-evb: usb3.0 host support
   configs: evb-rk3399: update support usb3.0 host

Jagan Teki (13):
   rockchip: Fix spl mmc boot device ofpath
   clk: rk3399: Fix eMMC get_clk reg offset
   arm64: dts: rk3399-nanopi4: Add u-boot,spl-boot-order
   nanopc-t4: Enable USB Gadget
   doc: rockchip: Document eMMC program steps
   clk: rk3399: Enable/Disable the USB2PHY clk
   clk: rk3399: Set empty for TCPHY assigned-clocks
   clk: rk3399: Enable/Disable TCPHY clocks
   phy: rockchip: Add Rockchip USB2PHY driver
   phy: rockchip: Add Rockchip USB TypeC PHY driver
   usb: dwc3: Add disable u2mac linestate check quirk
   usb: dwc3: Enable AutoRetry feature in the controller
   roc-rk3399-pc: Enable USB3.0 Host

Marcin Juszkiewicz (2):
   rockchip: enable USB OHCI host for RockPro64
   rockchip: rockpro64: enable DM_KEYBOARD

Mark Kettenis (2):
   pci: Make Rockchip PCIe voltage regulators optional
   rk3399: Enable NVMe distro bootcmd

Walter Lozano (3):
   doc: board: rockchip: Improve supported board list format
   doc: board: rockchip: Add missing supported boards
   doc: rockchip: Remove list of supported boards

  arch/arm/dts/rk3399-evb-u-boot.dtsi   |  15 +-
  arch/arm/dts/rk3399-ficus-u-boot.dtsi |   2 +-
  arch/arm/dts/rk3399-nanopi4-u-boot.dtsi   |   6 +
  arch/arm/dts/rk3399-rock960-u-boot.dtsi   |   2 +-
  arch/arm/mach-rockchip/rk3399/rk3399.c|   4 +-
  arch/arm/mach-rockchip/rk3399/syscon_rk3399.c |   3 +
  board/theobroma-systems/puma_rk3399/puma-rk3399.c |   4 +-
  configs/evb-rk3399_defconfig  |   6 +
  configs/nanopc-t4-rk3399_defconfig|   3 +
  configs/roc-pc-mezzanine-rk3399_defconfig |   5 +
  configs/roc-pc-rk3399_defconfig   |   6 +
  configs/rockpro64-rk3399_defconfig|   3 +
  doc/README.rockchip   |  72 +-
  doc/board/rockchip/rockchip.rst   | 116 +++-
  drivers/Makefile  |   1 +
  drivers/clk/rockchip/clk_rk3399.c |  40 +-
  drivers/pci/pcie_rockchip.c   |  33 +-
  drivers/phy/Kconfig   |   1 +
  drivers/phy/rockchip/Kconfig  |  21 +
  drivers/phy/rockchip/Makefile |   7 +
  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 312 +
  drivers/phy/rockchip/phy-rockchip-typec.c | 796 ++
  drivers/usb/common/common.c   |  25 +
  drivers/usb/dwc3/core.c   | 106 ++-
  drivers/usb/dwc3/core.h   |  19 +
  drivers/usb/dwc3/dwc3-generic.c   |  34 +-
  drivers/usb/host/Kconfig  |   9 -
  drivers/usb/host/Makefile |   1 -
  drivers/usb/host/xhci-rockchip.c  | 197 --
  include/configs/rockchip-common.h |   7 +
  include/configs/rockpro64_rk3399.h|   2 +
  include/dwc3-uboot.h  |   3 +
  include/linux/usb/phy.h   |  18 +
  33 files changed, 1510 insertions(+), 369 deletions(-)
  create mode 100644 drivers/phy/rockchip/Kconfig
  create mode 100644 drivers/phy/rockchip/Makefile
  create mode 100644 drivers/phy/rockchip/phy-rockchip-inno-usb2.c
  create mode 100644 drivers/phy/rockchip/phy-rockchip-typec.c
  delete mode 100644 drivers/usb/host/xhci-rockchip.c









Re: [PATCH] ARM: imx: hab: panic on authentication failure

2020-05-31 Thread Marek Vasut
On 5/30/20 10:53 PM, Patrick Wildt wrote:
> On Sat, May 30, 2020 at 10:29:19PM +0200, Marek Vasut wrote:
>> On 5/30/20 10:14 PM, Patrick Wildt wrote:
>>> On Sat, May 30, 2020 at 03:31:29PM -0300, Fabio Estevam wrote:
 Hi Marek,

 [Adding Breno]

 On Sat, May 30, 2020 at 3:29 PM Marek Vasut  wrote:
>
> Instead of hang()ing the system and thus disallowing any automated
> recovery possibility from a HAB authentication failure, panic() .
> The panic() function can be configured to hang() the system after
> printing an error message, however the default is to reset the
> system instead.
>
> This allows redundant boot to work correctly. In case the primary
> or secondary image cannot be authenticated, the system reboots and
> bootrom can try to start the other one.
>
> Signed-off-by: Marek Vasut 
> Cc: Fabio Estevam 
> Cc: NXP i.MX U-Boot Team 
> Cc: Peng Fan 
> Cc: Stefano Babic 

 This is a better behavior indeed:

 Reviewed-by: Fabio Estevam 
>>>
>>> What about this?  Have you ignored this patch for a reason? :/
>>>
>>> https://marc.info/?l=u-boot=159069441005730=2
>>
>> Yes, and the reason is I was not even aware of your patch, sorry. The CC
>> list in this mail should cover all the interested parties, so use it
>> when sending V2, or use patman.
> 
> I already had 11 people on CC, but apparently I missed you.
> 
>> The patch looks fine, one nit is that you should return errno.h return
>> value and another is that it changes the current behavior. Now that I
>> look at this imx code, board_spl_fit_post_load() should not even be in
>> arch/ , sigh, but that's for separate patch either way.
>>
>> So I think if you want to support this sort of fallback, you should make
>> the board_spl_fit_post_load() be in board/ files, with default __weak
>> implementation calling some arch_hab_authenticate...() which implements
>> current content of board_spl_fit_post_load(), and let boards decide how
>> to handle the fallback if it needs to be altered.
>>
>> Would that work ?
> 
> I'm not sure.  In comparison to the people from NXP who are paid to
> upstream their code and still don't do it correctly, I'm doing this
> in my spare time and I'm not sure I want to bikeshed all day long.
> 
> I can send a V3 that replaces the -1 with EINVAL, EACCESS, EPERM or
> something the like.  If you want to clean up after NXP, feel free to.

In fact, what is it that you're trying to achieve with this fallback ?
What are you falling back to , another fallback fitImage ?


Re: [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC

2020-05-31 Thread Heinrich Schuchardt
On 5/22/20 8:12 PM, Heinrich Schuchardt wrote:
> On 5/22/20 5:21 PM, Jan Kiszka wrote:
>> On 22.05.20 16:55, Heinrich Schuchardt wrote:
>>> On 22.05.20 14:21, Jan Kiszka wrote:
 On 22.05.20 13:38, Heinrich Schuchardt wrote:
> Am May 22, 2020 10:50:29 AM UTC schrieb Jan Kiszka 
> :
>> On 22.05.20 12:42, Heinrich Schuchardt wrote:
>>> On 5/20/20 2:22 PM, Tom Rini wrote:
 On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrote:

> From: Jan Kiszka 
>
> This driver is safe to use in SPL without relocation. Denying
> DM_FLAG_PRE_RELOC prevents its usability for verifying the main
>> U-Boot
> or other artifacts from the SPL unless needless enabling the full
>> driver
> set (SPL_OF_PLATDATA).
>
> Fixes: 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid
>> DM_FLAG_PRE_RELOC")
> CC: Heinrich Schuchardt 
> CC: Marek Vasut 
> Signed-off-by: Jan Kiszka 

 Applied to u-boot/master, thanks!

>>>
>>> With this patch applied pine64-lts_defconfig with CONFIG_RSA=y does
>> not
>>> boot anymore. See the output below. So something is wrong with this
>> driver.
>>>
>>> Do you have an idea how to analyze what is wrong? Unfortunately there
>> is
>>> no DEBUG_UART available on the Pine A64 LTS board.
>>
>> I would start crippling it down until things start to boot again. Are
>> you using it (for image verification e.g.), or is this just the
>> registration that breaks already?
>>
>
>
> RSA is needed in the UEFI subsystem for verifying variables and images. 
> But there is no need in SPL for it at all.
>
> In my configuration RSA is not used at all. Something breaks before even 
> the console becomes available.
>
> The pine64-lts_defconfig board boots via SPL->BL31->U-Boot

 But then a workaround for you would be to turn this driver off in SPL.
 UEFI is main U-Boot only, isn't it?

 That said, understanding the reason for the breakage would still be nice
 for the case someone needs to validate what SPL loads with the help of
 RSA (which is the case for us on an AM65x board).

 Jan

>>> As I described above I did *not* select RSA_SPL. The breakage is in main
>>> U-boot. SPL works fine loading TF-A BL31 which in turn loads U-Boot. But
>>> during driver initialization U-Boot does not even reach the point where
>>> we have a console due to something wrong with DM_FLAG_PRE_RELOC.
>>>
>>
>> Sorry, missed that detail. But that is indeed weird because - to my
>> understanding - this driver should be totally passive until someone
>> calls rsa_mod_exp() (which should only happen late, when UEFI comes into
>> play).
>>
>> Can you validate that this function is not involved by emptying its body?
>>
>> Also, until everything is understood, we could limit DM_FLAG_PRE_RELOC
>> to BUILD_SPL.
>>
>> Jan
>>
>
> Disabling the only consumer of UCLASS_MOD_EXP does not help.
>
> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
> index 1d55b997e3..89a08274f2 100644
> --- a/lib/rsa/rsa-verify.c
> +++ b/lib/rsa/rsa-verify.c
> @@ -334,7 +334,8 @@ static int rsa_verify_key(struct image_sign_info *info,
> hash_len = checksum->checksum_len;
>
>  #if !defined(USE_HOSTCC)
> -   ret = uclass_get_device(UCLASS_MOD_EXP, 0, _exp_dev);
> +   //ret = uclass_get_device(UCLASS_MOD_EXP, 0, _exp_dev);
> +   ret = 1;
>
> Emptying function mod_exp_sw() does not help.
>
> The board boots if I rename the driver:
>
>  U_BOOT_DRIVER(mod_exp_sw) = {
> -   .name   = "mod_exp_sw",
> +   .name   = "mod_exp_sw1",
>
> So it seems the very act of loading the driver before relocation is
> enough to cause the problem.
>
> To be more specific, if
>
>     ret = uclass_get(drv->id, );
>
> is called in device_bind_common() - drivers/core/device.c for name =
> "mod_exp_sw" booting fails.
>
> This does not boot:
>
> ret = uclass_get(drv->id, );
> +   if (!strcmp(name, "mod_exp_sw"))
> +   return -ENOENT;
>
> This does boot:
>
> +   if (!strcmp(name, "mod_exp_sw"))
> +   return -ENOENT;
> ret = uclass_get(drv->id, );
>
> So I tried to look into uclass_get():
>
> If
>
> uc = calloc(1, sizeof(*uc));
>
> is executed in uclass_add() for UCLASS_MOD_EXP booting fails.
>
> This does not boot:
>
> uc = calloc(1, sizeof(*uc));
> if (!uc)
> return -ENOMEM;
> +   if (id == UCLASS_MOD_EXP)
> +   return -ENOENT;
>
> This boots:
>
> +   if (id == UCLASS_MOD_EXP)
> +   return -ENOENT;
> uc = calloc(1, sizeof(*uc));
>
> Enlarging CONFIG_SYS_MALLOC_F_LEN from 0x400 to 0x8000 does not help.
>
> Best regards
>
> Heinrich
>

What finally helps is CONFIG_INIT_SP_RELATIVE=y.

diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig
index 

printk

2020-05-31 Thread Heinrich Schuchardt
Hello Simon,

in some drivers we use printk() which is restricted by CONFIG_LOGLEVEL
and translates to printf().

Shouldn't printk() be translated to log() instead?

CONFIG_LOGLEVEL probably should better be renamed to
CONFIG_PRINTK_LOGLEVEL to avoid confusion.

And those different levels like KERN_WARNING should probably be properly
defined to translate into out log levels.

Best regards

Heinrich


Fwd: [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS

2020-05-31 Thread Heinrich Schuchardt
On 5/31/20 12:43 PM, Heinrich Schuchardt wrote:
> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
> fails if CONFIG_INIT_SP_RELATIVE is not set.
>
> Signed-off-by: Heinrich Schuchardt 

CC: Jagan Teki 

Is this something that should be solved on board config level or on the
SUNXI level?

Where is the stack pointer currently defined for the sunxi boards?

Best regards

Heinrich

> ---
>  configs/pine64-lts_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig
> index ef108a1a31..b03bef01b1 100644
> --- a/configs/pine64-lts_defconfig
> +++ b/configs/pine64-lts_defconfig
> @@ -1,5 +1,8 @@
>  CONFIG_ARM=y
> +CONFIG_INIT_SP_RELATIVE=y
>  CONFIG_ARCH_SUNXI=y
> +CONFIG_SYS_MALLOC_F_LEN=0x8000
> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
>  CONFIG_SPL=y
>  CONFIG_MACH_SUN50I=y
>  CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
> --
> 2.20.1
>



[PATCH v2 1/1] log: don't show function by default

2020-05-31 Thread Heinrich Schuchardt
The name of the function emitting a log message may be of interest for a
developer but is distracting for normal users. See the example below:

try_load_entry() Booting: Debian

Make the default format for log messages customizable. By default show
only the message text.

Signed-off-by: Heinrich Schuchardt 
---
v2:
adjust logging tests
adjust description of log command
---
 cmd/log.c |  2 +-
 common/Kconfig| 18 ++
 include/log.h | 12 +++-
 test/log/syslog_test.c| 20 ++--
 test/py/tests/test_log.py |  2 ++
 5 files changed, 46 insertions(+), 8 deletions(-)

diff --git a/cmd/log.c b/cmd/log.c
index 78352b2cb9..2c91545c0d 100644
--- a/cmd/log.c
+++ b/cmd/log.c
@@ -139,7 +139,7 @@ static char log_help_text[] =
"log format  - set log output format.  is a string where\n"
"\teach letter indicates something that should be displayed:\n"
"\tc=category, l=level, F=file, L=line number, f=function, m=msg\n"
-   "\tor 'default', equivalent to 'fm', or 'all' for all\n"
+   "\tor 'default', or 'all' for all\n"
"log rec   - "
"output a log record"
;
diff --git a/common/Kconfig b/common/Kconfig
index 7872bc46cd..60cae77f20 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -792,6 +792,24 @@ config TPL_LOG_CONSOLE

 endif

+config LOGF_FILE
+   bool "Show source file name in log messages by default"
+   help
+ Show the source file name in log messages by default. This value
+ can be overridden using the 'log format' command.
+
+config LOGF_LINE
+   bool "Show source line number in log messages by default"
+   help
+ Show the source line number in log messages by default. This value
+ can be overridden using the 'log format' command.
+
+config LOGF_FUNC
+   bool "Show function name in log messages by default"
+   help
+ Show the function name in log messages by default. This value can
+ be overridden using the 'log format' command.
+
 config LOG_ERROR_RETURN
bool "Log all functions which return an error"
help
diff --git a/include/log.h b/include/log.h
index df65398c04..ec471c3a01 100644
--- a/include/log.h
+++ b/include/log.h
@@ -411,7 +411,17 @@ enum log_fmt {
LOGF_MSG,

LOGF_COUNT,
-   LOGF_DEFAULT = (1 << LOGF_FUNC) | (1 << LOGF_MSG),
+   LOGF_DEFAULT =
+#ifdef CONFIG_LOGF_FILE
+   (1 << LOGF_FILE) |
+#endif
+#ifdef CONFIG_LOGF_LINE
+   (1 << LOGF_LINE) |
+#endif
+#ifdef CONFIG_LOGF_FUNC
+   (1 << LOGF_FUNC) |
+#endif
+   (1 << LOGF_MSG),
LOGF_ALL = 0x3f,
 };

diff --git a/test/log/syslog_test.c b/test/log/syslog_test.c
index 26536ebca7..d1dfd08581 100644
--- a/test/log/syslog_test.c
+++ b/test/log/syslog_test.c
@@ -21,6 +21,8 @@

 DECLARE_GLOBAL_DATA_PTR;

+#define LOGF_TEST ((1 << LOGF_FUNC) | (1 << LOGF_MSG))
+
 /**
  * struct sb_log_env - private data for sandbox ethernet driver
  *
@@ -102,7 +104,7 @@ static int log_test_syslog_err(struct unit_test_state *uts)
int old_log_level = gd->default_log_level;
struct sb_log_env env;

-   gd->log_fmt = LOGF_DEFAULT;
+   gd->log_fmt = LOGF_TEST;
gd->default_log_level = LOGL_INFO;
env_set("ethact", "eth@10002000");
env_set("log_hostname", "sandbox");
@@ -116,6 +118,7 @@ static int log_test_syslog_err(struct unit_test_state *uts)
/* Check that the callback function was called */
sandbox_eth_set_tx_handler(0, NULL);
gd->default_log_level = old_log_level;
+   gd->log_fmt = LOGF_DEFAULT;

return 0;
 }
@@ -132,7 +135,7 @@ static int log_test_syslog_warning(struct unit_test_state 
*uts)
int old_log_level = gd->default_log_level;
struct sb_log_env env;

-   gd->log_fmt = LOGF_DEFAULT;
+   gd->log_fmt = LOGF_TEST;
gd->default_log_level = LOGL_INFO;
env_set("ethact", "eth@10002000");
env_set("log_hostname", "sandbox");
@@ -147,6 +150,7 @@ static int log_test_syslog_warning(struct unit_test_state 
*uts)
/* Check that the callback function was called */
ut_assertnull(env.expected);
gd->default_log_level = old_log_level;
+   gd->log_fmt = LOGF_DEFAULT;

return 0;
 }
@@ -163,7 +167,7 @@ static int log_test_syslog_notice(struct unit_test_state 
*uts)
int old_log_level = gd->default_log_level;
struct sb_log_env env;

-   gd->log_fmt = LOGF_DEFAULT;
+   gd->log_fmt = LOGF_TEST;
gd->default_log_level = LOGL_INFO;
env_set("ethact", "eth@10002000");
env_set("log_hostname", "sandbox");
@@ -178,6 +182,7 @@ static int log_test_syslog_notice(struct unit_test_state 
*uts)
/* Check that the callback function was called */
ut_assertnull(env.expected);
gd->default_log_level = old_log_level;
+   gd->log_fmt = LOGF_DEFAULT;


[PATCH 1/1] log: don't show function by default

2020-05-31 Thread Heinrich Schuchardt
The name of the function emitting a log message may be of interest for a
developer but is distracting for normal users. See the example below:

try_load_entry() Booting: Debian

Make the default format for log messages customizable. By default show
only the message text.

Signed-off-by: Heinrich Schuchardt 
---
 common/Kconfig | 18 ++
 include/log.h  | 12 +++-
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/common/Kconfig b/common/Kconfig
index 7872bc46cd..60cae77f20 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -792,6 +792,24 @@ config TPL_LOG_CONSOLE

 endif

+config LOGF_FILE
+   bool "Show source file name in log messages by default"
+   help
+ Show the source file name in log messages by default. This value
+ can be overridden using the 'log format' command.
+
+config LOGF_LINE
+   bool "Show source line number in log messages by default"
+   help
+ Show the source line number in log messages by default. This value
+ can be overridden using the 'log format' command.
+
+config LOGF_FUNC
+   bool "Show function name in log messages by default"
+   help
+ Show the function name in log messages by default. This value can
+ be overridden using the 'log format' command.
+
 config LOG_ERROR_RETURN
bool "Log all functions which return an error"
help
diff --git a/include/log.h b/include/log.h
index df65398c04..b45a4565a3 100644
--- a/include/log.h
+++ b/include/log.h
@@ -411,7 +411,17 @@ enum log_fmt {
LOGF_MSG,

LOGF_COUNT,
-   LOGF_DEFAULT = (1 << LOGF_FUNC) | (1 << LOGF_MSG),
+   LOGF_DEFAULT =
+#ifdef CONFIG_LOGF_FILE
+   (1 << LOGF_FILE) |
+#endif
+#ifdef CONFIG_LOGF_LINE
+   (1 << LOGF_LINE) |
+#endif
+#ifdef CONFIG_LOGF_FUNC
+   (1 << LOGF_FUNC) |
+#endif
+   (1 << LOGF_MSG);
LOGF_ALL = 0x3f,
 };

--
2.20.1



Re: [PATCH v2] gpio: octeon_gpio: Add GPIO controller driver for Octeon

2020-05-31 Thread Simon Glass
On Tue, 26 May 2020 at 06:19, Stefan Roese  wrote:
>
> From: Suneel Garapati 
>
> Add support for GPIO controllers found on Octeon II/III and Octeon TX
> TX2 SoC platforms.
>
> Signed-off-by: Aaron Williams 
> Signed-off-by: Suneel Garapati 
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Daniel Schwierzeck 
> Cc: Aaron Williams 
> Cc: Chandrakala Chavva 
> ---
> v2 (Stefan):
> - Removed #ifdef's for Octeon vs OcteonTX/TX2 completely
>   The differentiation is now made via driver data / compatible
>   string
>
> RFC -> v1 (Stefan)
> - Separated this patch from the OcteonTX/TX2 RFC patch series into a
>   single patch. This is useful, as the upcoming MIPS Octeon support will
>   use this GPIO driver.
> - Added MIPS Octeon II/III support (big endian). Rename driver and its
>   function names from "octeontx" to "octeon" to better match all Octeon
>   platforms.
> - Moved from union to defines / bitmasks. This makes the driver usage
>   on little- and big-endian platforms much easier.
> - Used clrbits_64() instead of clrbits_le64() and friends to support
>   usage on little- and big-endian systems
> - Removed dev->req_seq assignment
> - Enhanced Kconfig text
> - Rewrote GPIO_BIT macro
> - Dropped many macros to calculate the registers offsets and implemented
>   simple functions for this (easier to read)
> - Used GENMASK_ULL and FIELD_GET helpers
> - Minor cosmetic changes (dropped brackets etc)
> - Reword commit text and subject
>
>  drivers/gpio/Kconfig   |  10 ++
>  drivers/gpio/Makefile  |   1 +
>  drivers/gpio/octeon_gpio.c | 253 +
>  3 files changed, 264 insertions(+)
>  create mode 100644 drivers/gpio/octeon_gpio.c
>

Reviewed-by: Simon Glass 


Re: [PATCH v2 08/10] rtc: i2c_rtc_emul: catch any write to the "reset" register

2020-05-31 Thread Simon Glass
On Tue, 19 May 2020 at 16:01, Rasmus Villemoes
 wrote:
>
> It's more natural that any write that happens to touch the reset
> register should cause a reset, rather than just a write that starts at
> that offset.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  drivers/rtc/i2c_rtc_emul.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v2] doc: log: correct option name CONFIG_LOG_MAX_LEVEL

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 01:43, Patrick Delaunay  wrote:
>
> Replace CONFIG_(SPL_)MAX_LOG_LEVEL by the correct name as defined in
> common/Kconfig:
> line 668:config LOG_MAX_LEVEL
> line 688:config SPL_LOG_MAX_LEVEL
> line 708:config TPL_LOG_MAX_LEVEL
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2:
> - add commnet for TPL with CONFIG_TPL_LOG_MAX_LEVEL example
>
>  doc/README.log | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH 4/8] regmap: Allow left shifting register offset before access

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 06:52, Pratyush Yadav  wrote:
>
> Drivers can configure it to adjust the final read/write location.
>
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/core/regmap.c | 6 +-
>  include/regmap.h  | 6 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
Reviewed-by: Simon Glass 


Re: [PATCH 1/1] test/py: use actual core count for parallel builds

2020-05-31 Thread Simon Glass
On Sat, 30 May 2020 at 16:44, Heinrich Schuchardt  wrote:
>
> When building U-Boot we should not blindly use make -j8 but consider the
> actual core count given by os.cpu_count().
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  test/py/conftest.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

I did send a patch to make this use buildman, but people were not keen
on the extra dependency.


> diff --git a/test/py/conftest.py b/test/py/conftest.py
> index e3392ff6bc..30920474b3 100644
> --- a/test/py/conftest.py
> +++ b/test/py/conftest.py
> @@ -156,7 +156,7 @@ def pytest_configure(config):
>  o_opt = ''
>  cmds = (
>  ['make', o_opt, '-s', board_type + '_defconfig'],
> -['make', o_opt, '-s', '-j8'],
> +['make', o_opt, '-s', '-j{}'.format(os.cpu_count())],
>  )
>  name = 'make'
>
> --
> 2.26.2
>


Re: [PATCH v2 06/10] rtc: add rtc command

2020-05-31 Thread Simon Glass
Hi Rasmus,

On Tue, 19 May 2020 at 16:01, Rasmus Villemoes
 wrote:
>
> Mostly as an aid for debugging RTC drivers, provide a command that can
> be used to read/write arbitrary registers (assuming the driver
> provides the read/write methods or their single-register-at-a-time
> variants).
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  cmd/Kconfig  |   6 ++
>  cmd/Makefile |   1 +
>  cmd/rtc.c| 159 +++
>  3 files changed, 166 insertions(+)
>  create mode 100644 cmd/rtc.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index f9be1988f6..7eea25facd 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1715,6 +1715,12 @@ config CMD_DATE
>   Enable the 'date' command for getting/setting the time/date in RTC
>   devices.
>
> +config CMD_RTC
> +   bool "rtc"
> +   depends on DM_RTC
> +   help
> + Enable the 'rtc' command for low-level access to RTC devices.
> +
>  config CMD_TIME
> bool "time"
> help
> diff --git a/cmd/Makefile b/cmd/Makefile
> index 974ad48b0a..c7992113e4 100644
> --- a/cmd/Makefile
> +++ b/cmd/Makefile
> @@ -120,6 +120,7 @@ obj-$(CONFIG_CMD_REISER) += reiser.o
>  obj-$(CONFIG_CMD_REMOTEPROC) += remoteproc.o
>  obj-$(CONFIG_CMD_RNG) += rng.o
>  obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
> +obj-$(CONFIG_CMD_RTC) += rtc.o
>  obj-$(CONFIG_SANDBOX) += host.o
>  obj-$(CONFIG_CMD_SATA) += sata.o
>  obj-$(CONFIG_CMD_NVME) += nvme.o
> diff --git a/cmd/rtc.c b/cmd/rtc.c
> new file mode 100644
> index 00..e26b7ca18f
> --- /dev/null
> +++ b/cmd/rtc.c
> @@ -0,0 +1,159 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_RTC_BYTES 32
> +
> +static int do_rtc_read(struct udevice *dev, int argc, char * const argv[])
> +{
> +   u8 buf[MAX_RTC_BYTES];
> +   int reg, len, ret;
> +   u8 *addr;
> +
> +   if (argc < 2 || argc > 3)
> +   return CMD_RET_USAGE;
> +
> +   reg = simple_strtoul(argv[0], NULL, 0);

I think these should be hex (i.e. 16), since that is the norm in U-Boot.

> +   len = simple_strtoul(argv[1], NULL, 0);
> +   if (argc == 3) {
> +   addr = map_sysmem(simple_strtoul(argv[2], NULL, 16), len);
> +   } else {
> +   if (len > sizeof(buf)) {
> +   printf("can read at most %d registers at a time\n", 
> MAX_RTC_BYTES);

It would be better to loop like print_buffer() does.

> +   return CMD_RET_FAILURE;
> +   }
> +   addr = buf;
> +   }
> +
> +   ret = rtc_read(dev, reg, addr, len);
> +   if (ret) {
> +   printf("rtc_read() failed: %d\n", ret);
> +   ret = CMD_RET_FAILURE;
> +   goto out;
> +   } else {
> +   ret = CMD_RET_SUCCESS;
> +   }
> +
> +   if (argc == 2) {
> +   while (len--)
> +   printf("%d: 0x%02x\n", reg++, *addr++);

Perhaps use print_buffer()?

> +   }
> +out:
> +   if (argc == 3)
> +   unmap_sysmem(addr);
> +   return ret;
> +}
> +
> +static int do_rtc_write(struct udevice *dev, int argc, char * const argv[])
> +{
> +   u8 buf[MAX_RTC_BYTES];
> +   u8 *addr;
> +   int reg, len, ret;
> +
> +   if (argc < 2 || argc > 3)
> +   return CMD_RET_USAGE;
> +
> +   reg = simple_strtoul(argv[0], NULL, 0);
> +
> +   if (argc == 3) {
> +   len = simple_strtoul(argv[1], NULL, 0);
> +   addr = map_sysmem(simple_strtoul(argv[2], NULL, 16), len);
> +   } else {
> +   const char *s = argv[1];
> +
> +   /* Convert hexstring, bail out if too long. */
> +   addr = buf;
> +   len = strlen(s);
> +   if (len > 2*MAX_RTC_BYTES) {

Spaces around *

> +   printf("hex string too long, can write at most %d 
> bytes\n", MAX_RTC_BYTES);

Please can you try checkpatch or patman? This lines seems too long

> +   return CMD_RET_FAILURE;
> +   }
> +   len /= 2;
> +   if (hex2bin(addr, s, len)) {
> +   printf("invalid hex string\n");
> +   return CMD_RET_FAILURE;
> +   }
> +   }
> +
> +   ret = rtc_write(dev, reg, addr, len);
> +   if (ret) {
> +   printf("rtc_write() failed: %d\n", ret);
> +   ret = CMD_RET_FAILURE;
> +   } else {
> +   ret = CMD_RET_SUCCESS;
> +   }
> +
> +   if (argc == 3)
> +   unmap_sysmem(addr);
> +   return ret;
> +}
> +
> +int do_rtc(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> +   static int curr_rtc = 0;
> +   struct udevice *dev;
> +   int ret, idx;
> +
> +   if (argc < 2)
> +   return CMD_RET_USAGE;
> +
> +   argc--;
> +   argv++;
> +
> +   if 

Re: [PATCH 2/2] dma-mapping: Add header file for ARCH_DMA_MINALIGN

2020-05-31 Thread Simon Glass
Hi Tom,

On Sat, 30 May 2020 at 11:27, Tom Rini  wrote:
>
> On Sat, May 30, 2020 at 01:20:10PM -0400, Tom Rini wrote:
> > On Sat, May 30, 2020 at 10:29:04AM -0600, Simon Glass wrote:
> >
> > > This is defined in the asm/cache.h header file. Update this header file to
> > > include it.
> > >
> > > Signed-off-by: Simon Glass 
> >
> > Reviewed-by: Tom Rini 
> >
> > There's also drivers/usb/host/ohci.h and lib/elf.c which also reference
> > ARCH_DMA_MINALIGN without also logically pulling it in, I'll fix those.
>
> Dunno how I missed that 1/2 is what fixed that one, sorry.  And
> lib/elf.c is a problem in theory but would be a fail to build if not
> pulled in logically so I'll leave it be for now.

Yes I think the issue is the #ifdef default. Probably that should be
removed at some point as it is quite risky to have that sort of thing.

Regards,
Simon


Re: [PATCH v3 4/4] spl: fit: improve spl_nand_fit_read(...) readability

2020-05-31 Thread Simon Glass
Hi Dario,

On Wed, 27 May 2020 at 05:56, Dario Binacchi  wrote:
>
> Replacing the ret variable with err and handling first the error
> condition about the value returned by the spl_nand_fit_read routine,
> improves the code readability.
> Furthermore, the 'else' int the 'else return ret' instruction was
> useless.
>
> cc: Michael Trimarchi 
> Signed-off-by: Dario Binacchi 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  common/spl/spl_nand.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

I think 'ret' is better than 'err' since we don't know if it is an
error until we check it, but we do know it is a return code.

Regards,
Simon


Re: [PATCH v3 1/4] spl: fix format of function documentation

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 05:56, Dario Binacchi  wrote:
>
> U-Boot adopted the kernel-doc annotation style.
>
> cc: Michael Trimarchi 
> Signed-off-by: Dario Binacchi 
> ---
>
> Changes in v3: None
> Changes in v2: None
>
>  include/spl.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH 2/4] trace: clang compatible handling of gd register

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 12:04, Heinrich Schuchardt  wrote:
>
> On ARM systems gd is stored in register r9 or x18. When compiling with
> clang gd is defined as a macro calling function gd_ptr(). So we can not
> make assignments to gd.
>
> Use function set_gd() for setting the register on ARM.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/trace.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v1 1/3] drivers: reset: Handle gracefully NULL pointers

2020-05-31 Thread Simon Glass
Hi Pratyush,

On Wed, 27 May 2020 at 11:12, Pratyush Yadav  wrote:
>
> Hi Simon,
>
> On 29/10/19 07:48PM, Simon Glass wrote:
> > Hi Jean-Jacques,
> >
> > On Mon, 30 Sep 2019 at 08:31, Jean-Jacques Hiblot  
> > wrote:
> > >
> > > Prepare the way for a managed reset API by handling NULL pointers without
> > > crashing nor failing.
> > >
> > > Signed-off-by: Jean-Jacques Hiblot 
> > > ---
> > >
> > >  drivers/reset/reset-uclass.c | 30 +-
> > >  1 file changed, 17 insertions(+), 13 deletions(-)
> >
> > Same comment here about code size / Kconfig option.
>
> A lot of the changes below are ternary operators. I'm not sure how to
> put them behind a Kconfig option to reduce code size. Do you want me to
> change the NULL check to a separate if() block to put behind an #ifdef?
>
> One way of doing this is like in this patch [0]. The other would be to
> wrap individual if statements in #ifdef, which tends to hurt
> readability.

Well for this I would really favour:

  int reset_request(struct reset_ctl *reset_ctl)
  {
 struct reset_ops *ops;

if (!result_ctl)
return 0;

ops = reset_dev_ops(reset_ctl->dev);

But why allow result_ctl to be NULL? You should explain that in your
commit message.

> > - struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
> > + struct reset_ops *ops = reset_dev_ops(reset_ctl);
> >
> >   debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
> >
> > - return ops->request(reset_ctl);
> > + return ops->request ? ops->request(reset_ctl) : 0;
> >  }
> >
>
> [0] 
> https://patchwork.ozlabs.org/project/uboot/patch/20191001115130.18886-2-jjhib...@ti.com/

[..]

Regards,
Simon


Re: [PATCH 3/4] arm: remove outdated comment concerning -ffixed-x18

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 12:04, Heinrich Schuchardt  wrote:
>
> Clang 9 supports -ffixed-x18.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  arch/arm/include/asm/global_data.h | 4 
>  1 file changed, 4 deletions(-)

Reviewed-by: Simon Glass 


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

2020-05-31 Thread Simon Glass
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?

Regards,
Simon


Re: [PATCH v3 2/4] spl: fit: fail fit loading in case of FDT appending error

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 05:56, Dario Binacchi  wrote:
>
> If uboot does not embed its device tree and the FIT loading function

U-Boot

> returns error in case of failure in the FDT append, the redundant itb
> image could be loaded.
>
> cc: Michael Trimarchi 
> Signed-off-by: Dario Binacchi 
> Reviewed-by: Michael Trimarchi 
>
> ---
>
> Changes in v3: None
> Changes in v2:
>  - Replace CONFIG_IS_ENABLED(OF_EMBED) with IS_ENABLED(CONFIG_OF_EMBED))
>
>  common/spl/spl_fit.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH 8/8] test: dm: Add tests for regmap managed API and regmap fields

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 06:52, Pratyush Yadav  wrote:
>
> From: Jean-Jacques Hiblot 
>
> The tests rely on a dummy driver to allocate and initialize the regmaps
> and the regmap fields using the managed API. The first test checks if
> the regmap config fields like width, reg_offset_shift, range specifiers,
> etc work. The second test checks if regmap fields behave properly (mask
> and shift are ok) by peeking into the regmap.
>
> Signed-off-by: Jean-Jacques Hiblot 
> Signed-off-by: Pratyush Yadav 
> ---
>  arch/sandbox/dts/test.dts |  13 +++
>  test/dm/regmap.c  | 198 ++
>  2 files changed, 211 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH 7/8] regmap: Add support for regmap fields

2020-05-31 Thread Simon Glass
Hi Pratyush,

On Wed, 27 May 2020 at 06:52, Pratyush Yadav  wrote:
>
> From: Jean-Jacques Hiblot 
>
> A regmap field is an abstraction available in Linux. It provides to access
> bitfields in a regmap without having to worry about shifts and masks.
>
> Signed-off-by: Jean-Jacques Hiblot 
> Reviewed-by: Simon Glass 
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/core/regmap.c |  78 ++
>  include/regmap.h  | 108 ++
>  2 files changed, 186 insertions(+)
>

Reviewed-by: Simon Glass 

Please see below

> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index 4792067f24..cbc01b689a 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -18,6 +18,15 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +struct regmap_field {

Needs comments as I'm not sure what this is for

> +   struct regmap *regmap;
> +   unsigned int mask;
> +   /* lsb */
> +   unsigned int shift;
> +   unsigned int reg;
> +};
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -545,3 +554,72 @@ int regmap_update_bits(struct regmap *map, uint offset, 
> uint mask, uint val)
>
> return regmap_write(map, offset, reg | (val & mask));
>  }
> +
> +int regmap_field_read(struct regmap_field *field, unsigned int *val)
> +{
> +   int ret;
> +   unsigned int reg_val;
> +
> +   ret = regmap_read(field->regmap, field->reg, _val);
> +   if (ret != 0)
> +   return ret;
> +
> +   reg_val &= field->mask;
> +   reg_val >>= field->shift;
> +   *val = reg_val;
> +
> +   return ret;
> +}
> +
> +int regmap_field_write(struct regmap_field *field, unsigned int val)
> +{
> +   return regmap_update_bits(field->regmap, field->reg, field->mask,
> + val << field->shift);
> +}
> +
> +static void regmap_field_init(struct regmap_field *rm_field,
> + struct regmap *regmap,
> + struct reg_field reg_field)
> +{
> +   rm_field->regmap = regmap;
> +   rm_field->reg = reg_field.reg;
> +   rm_field->shift = reg_field.lsb;
> +   rm_field->mask = GENMASK(reg_field.msb, reg_field.lsb);
> +}
> +
> +struct regmap_field *devm_regmap_field_alloc(struct udevice *dev,
> +struct regmap *regmap,
> +struct reg_field reg_field)
> +{
> +   struct regmap_field *rm_field = devm_kzalloc(dev, sizeof(*rm_field),
> +GFP_KERNEL);
> +   if (!rm_field)
> +   return ERR_PTR(-ENOMEM);
> +
> +   regmap_field_init(rm_field, regmap, reg_field);
> +
> +   return rm_field;
> +}
> +
> +void devm_regmap_field_free(struct udevice *dev, struct regmap_field *field)
> +{
> +   devm_kfree(dev, field);
> +}
> +
> +struct regmap_field *regmap_field_alloc(struct regmap *regmap,
> +   struct reg_field reg_field)
> +{
> +   struct regmap_field *rm_field = kzalloc(sizeof(*rm_field), 
> GFP_KERNEL);
> +
> +   if (!rm_field)
> +   return ERR_PTR(-ENOMEM);
> +
> +   regmap_field_init(rm_field, regmap, reg_field);
> +
> +   return rm_field;
> +}
> +
> +void regmap_field_free(struct regmap_field *field)
> +{
> +   kfree(field);
> +}
> diff --git a/include/regmap.h b/include/regmap.h
> index 007e6f4b6f..190ea44f6a 100644
> --- a/include/regmap.h
> +++ b/include/regmap.h
> @@ -314,6 +314,43 @@ int regmap_raw_read_range(struct regmap *map, uint 
> range_num, uint offset,
> regmap_read_poll_timeout_test(map, addr, val, cond, sleep_us, \
>   timeout_ms, 0) \
>
> +/**
> + * regmap_field_read_poll_timeout - Poll until a condition is met or a 
> timeout
> + * occurs
> + *
> + * @field: Regmap field to read from
> + * @val:   Unsigned integer variable to read the value into
> + * @cond:  Break condition (usually involving @val)
> + * @sleep_us:  Maximum time to sleep between reads in us (0 tight-loops).
> + * @timeout_ms:Timeout in ms, 0 means never timeout
> + *
> + * Returns 0 on success and -ETIMEDOUT upon a timeout or the 
> regmap_field_read
> + * error return value in case of a error read. In the two former cases,
> + * the last read value at @addr is stored in @val.
> + *
> + * This is modelled after the regmap_read_poll_timeout macros in linux but
> + * with millisecond timeout.
> + */
> +#define regmap_field_read_poll_timeout(field, val, cond, sleep_us, 
> timeout_ms) \
> +({ \
> +   unsigned long __start = get_timer(0); \
> +   int __ret; \
> +   for (;;) { \
> +   __ret = regmap_field_read((field), &(val)); \
> +   if (__ret) \
> +   break; \
> +   if (cond) \
> +   break; \
> +   if ((timeout_ms) && get_timer(__start) > 

Re: [U-boot,1/2] eth: mtk-eth: enable mt7629 sgmii mode support in mediatek eth driver

2020-05-31 Thread Simon Glass
Hi MarkLee,

On Wed, 27 May 2020 at 05:25, MarkLee  wrote:
>
> The sgmii mode init flow is almost the same for all mediatek SoC, the
> only difference is the register offset(SGMSYS_GEN2_SPEED) is 0x2028
> for old chip(mt7622) but changed to 0x128 for newer chip(mt7629 and
> the following chips).
>
> Signed-off-by: MarkLee 
> ---
>  drivers/net/mtk_eth.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/mtk_eth.h b/drivers/net/mtk_eth.h
> index f2940c9996..3c85eab91a 100644
> --- a/drivers/net/mtk_eth.h
> +++ b/drivers/net/mtk_eth.h
> @@ -44,7 +44,12 @@
>  #define SGMSYS_QPHY_PWR_STATE_CTRL 0xe8
>  #define SGMII_PHYA_PWD BIT(4)
>
> +#if defined(CONFIG_TARGET_MT7622)
>  #define SGMSYS_GEN2_SPEED  0x2028
> +#else
> +#define SGMSYS_GEN2_SPEED  0x128
> +#endif

You can't check #ifdefs in drivers. You should use a compatible
string, then device_get_driver_data() to decide what the value is
here.

Or if this is board-specific you could add it to the device-tree node
as a property, if it is in the binding.

Regards,
Simon


Re: [PATCH 1/1] fs: fat_write: fix short name creation.

2020-05-31 Thread Simon Glass
Hi Heinrich,

On Tue, 26 May 2020 at 13:12, Heinrich Schuchardt  wrote:
>
> Truncate file names if the buffer size is exceeded to avoid a buffer
> overflow.
>
> Use Sphinx style function description.
>
> Add a TODO comment.
>
> Reported-by: CID 303779
> Signed-off-by: Heinrich Schuchardt 
> ---
>  fs/fat/fat_write.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)

Reviewed-by: Simon Glass 

See below

>
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index 59cc0bae94..b16a39d3ff 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -50,8 +50,11 @@ static int disk_write(__u32 block, __u32 nr_blocks, void 
> *buf)
> return ret;
>  }
>
> -/*
> - * Set short name in directory entry
> +/**
> + * set_name() - set short name in directory entry
> + *
> + * @dirent:directory entry
> + * @filename:  long file name
>   */
>  static void set_name(dir_entry *dirent, const char *filename)
>  {
> @@ -66,7 +69,8 @@ static void set_name(dir_entry *dirent, const char 
> *filename)
> if (len == 0)
> return;
>
> -   strcpy(s_name, filename);
> +   strncpy(s_name, filename, VFAT_MAXLEN_BYTES - 1);
> +   s_name[VFAT_MAXLEN_BYTES - 1] = '\0';

Could use strlcpy() here

> uppercase(s_name, len);
>
> period = strchr(s_name, '.');
> @@ -87,6 +91,11 @@ static void set_name(dir_entry *dirent, const char 
> *filename)
> memcpy(dirent->name, s_name, period_location);
> } else {
> memcpy(dirent->name, s_name, 6);
> +   /*
> +* TODO: Translating two long names with the same first six
> +*   characters to the same short name is utterly wrong.
> +*   Short names must be unique.
> +*/
> dirent->name[6] = '~';
> dirent->name[7] = '1';
> }
> --
> 2.26.2
>

Regards,
Simon


Re: [PATCH v3 2/5] mkimage: fit_image: handle multiple errors when writing signatures

2020-05-31 Thread Simon Glass
Hi Heiko,

On Tue, 26 May 2020 at 04:44, Heiko Stuebner  wrote:
>
> From: Heiko Stuebner 
>
> fit_image_write_sig() contains mostly functions from libfdt that
> return FDT_ERR_foo errors but also a call to fit_set_timestamp()
> which returns a regular error.
>
> When handling the size increase via multiple iterations, check
> for both -FDT_ERR_NOSPACE but also for -ENOSPC.
>
> There is no real conflict, as FDT_ERR_NOSPACE = 3 = ESRCH
> (No such process) and ENOSPC = 28 which is above any FDT_ERR_*.
>
> Signed-off-by: Heiko Stuebner 
> Reviewed-by: Simon Glass 
> Reviewed-by: Kever Yang 
> ---
>  tools/image-host.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Changing my mind on this - I wonder if we can change
fit_image_write_sig() to always return an errno code, never an FDT
code? Could be a follow-on patch.

>
> diff --git a/tools/image-host.c b/tools/image-host.c
> index 9a83b7f675..baf9590f3b 100644
> --- a/tools/image-host.c
> +++ b/tools/image-host.c
> @@ -241,7 +241,7 @@ static int fit_image_process_sig(const char *keydir, void 
> *keydest,
> ret = fit_image_write_sig(fit, noffset, value, value_len, comment,
> NULL, 0, cmdname);
> if (ret) {
> -   if (ret == -FDT_ERR_NOSPACE)
> +   if (ret == -FDT_ERR_NOSPACE || ret == -ENOSPC)
> return -ENOSPC;
> printf("Can't write signature for '%s' signature node in '%s' 
> conf node: %s\n",
>node_name, image_name, fdt_strerror(ret));
> --
> 2.25.1
>

Regards,
Simon


Re: [PATCH v2 10/10] test: dm: rtc: add tests of rtc shell command

2020-05-31 Thread Simon Glass
On Tue, 19 May 2020 at 16:01, Rasmus Villemoes
 wrote:
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  test/dm/rtc.c | 61 +++
>  1 file changed, 61 insertions(+)
>

Reviewed-by: Simon Glass 

But please add a commit message.


Re: [PATCH 6/8] regmap: Allow devices to specify regmap range start and size in config

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 06:52, Pratyush Yadav  wrote:
>
> Some devices need to calculate the regmap base address at runtime. This
> makes it impossible to use device tree to get the regmap base. Instead,
> allow devices to specify it in the regmap config. This will create a
> regmap with a single range that corresponds to the start and size given
> by the driver.
>
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/core/regmap.c | 6 +-
>  include/regmap.h  | 6 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 1/4] efi_loader: allow compiling with clang

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 12:04, Heinrich Schuchardt  wrote:
>
> On ARM systems gd is stored in register r9 or x18. When compiling with
> clang gd is defined as a macro calling function gd_ptr(). So we can not
> make assignments to gd.
>
> In the UEFI sub-system we need to save gd when leaving to UEFI binaries and
> have to restore gd when reentering U-Boot.
>
> Define a new function set_gd() for setting gd and use it in the UEFI
> sub-system.
>
> Signed-off-by: Heinrich Schuchardt 
> Tested-by: Tom Rini 
> ---
> Resent.

Series-prefix: Resend

does that for you

> ---
>  arch/arm/include/asm/global_data.h |  9 +
>  lib/efi_loader/efi_boottime.c  | 10 +-
>  2 files changed, 14 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass 


Re: [PATCH 5/8] regmap: Add regmap_init_mem_range()

2020-05-31 Thread Simon Glass
On Wed, 27 May 2020 at 06:52, Pratyush Yadav  wrote:
>
> Right now, the base of a regmap can only be obtained from the device
> tree. This makes it impossible for devices which calculate the base at
> runtime to use a regmap. An example of such a device is the Cadence
> Sierra PHY.
>
> Allow creating a regmap with one range whose start and size can be
> specified by the driver based on calculations at runtime.
>
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/core/regmap.c | 27 +++
>  include/regmap.h  | 19 +++
>  2 files changed, 46 insertions(+)
>

Reviewed-by: Simon Glass 


Re: [PATCH 2/8] regmap: zero out the regmap on allocation

2020-05-31 Thread Simon Glass
Hi Pratyush,

On Wed, 27 May 2020 at 06:52, Pratyush Yadav  wrote:
>
> Some fields will be introduced in the regmap structure that should be
> set to 0 by default. So, once we allocate a regmap, make sure it is
> zeroed out to avoid unexpected defaults for those values.
>
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/core/regmap.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 

But I think you should use calloc() instead


> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index 74225361fd..24651fb3ec 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -30,10 +30,12 @@ DECLARE_GLOBAL_DATA_PTR;
>  static struct regmap *regmap_alloc(int count)
>  {
> struct regmap *map;
> +   size_t size = sizeof(*map) + sizeof(map->ranges[0]) * count;
>
> -   map = malloc(sizeof(*map) + sizeof(map->ranges[0]) * count);
> +   map = malloc(size);
> if (!map)
> return NULL;
> +   memset(map, 0, size);
> map->range_count = count;
>
> return map;
> --
> 2.26.2
>


Re: [PATCH v3 3/5] spl: fit: enable signing a generated u-boot.itb

2020-05-31 Thread Simon Glass
On Tue, 26 May 2020 at 04:44, Heiko Stuebner  wrote:
>
> From: Heiko Stuebner 
>
> With SPL_FIT_SIGNATURE enabled we will likely want a generated
> u-boot.itb to be signed and the key stores so that the spl can
> reach it.
>
> So add a SPL_FIT_SIGNATURE_KEY_DIR option and suitable hooks
> into the Makefile to have mkimage sign the .itb and store the
> used key into the spl dtb file.
>
> The added dependencies should make sure that the u-boot.itb
> gets generated before the spl-binary gets build, so that there
> is the necessary space for the key to get included.
>
> Signed-off-by: Heiko Stuebner 
> Reviewed-by: Philipp Tomsich 
> ---
> changes in v2.1:
> - depend on $(CONFIG_SPL_FIT_SIGNATURE)$(U_BOOT_ITS)
>   instead of only $(CONFIG_SPL_FIT_GENERATOR)
>
>  Kconfig  |  8 
>  Makefile | 11 ++-
>  2 files changed, 18 insertions(+), 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 3/8] regmap: Allow specifying read/write width

2020-05-31 Thread Simon Glass
Hi Pratyush,

On Wed, 27 May 2020 at 06:52, Pratyush Yadav  wrote:
>
> Right now, regmap_read() and regmap_write() read/write a 32-bit value
> only. To write other lengths, regmap_raw_read() and regmap_raw_write()
> need to be used.
>
> This means that any driver ported from Linux that relies on
> regmap_{read,write}() to know the size already has to be updated at each
> callsite. This makes the port harder to maintain.
>
> So, allow specifying the read/write width to make it easier to port the
> drivers, since now the only change needed is when initializing the
> regmap.
>
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/core/regmap.c | 12 +---
>  include/regmap.h  | 28 ++--
>  2 files changed, 27 insertions(+), 13 deletions(-)

Reviewed-by: Simon Glass 

See below

>
> diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
> index 24651fb3ec..0180246095 100644
> --- a/drivers/core/regmap.c
> +++ b/drivers/core/regmap.c
> @@ -245,7 +245,7 @@ struct regmap *devm_regmap_init(struct udevice *dev,
> const struct regmap_config *config)
>  {
> int rc;
> -   struct regmap **mapp;
> +   struct regmap **mapp, *map;
>
> mapp = devres_alloc(devm_regmap_release, sizeof(struct regmap *),
> __GFP_ZERO);
> @@ -256,6 +256,10 @@ struct regmap *devm_regmap_init(struct udevice *dev,
> if (rc)
> return ERR_PTR(rc);
>
> +   map = *mapp;
> +   if (config)
> +   map->width = config->width;
> +
> devres_add(dev, mapp);
> return *mapp;
>  }
> @@ -378,7 +382,8 @@ int regmap_raw_read(struct regmap *map, uint offset, void 
> *valp, size_t val_len)
>
>  int regmap_read(struct regmap *map, uint offset, uint *valp)
>  {
> -   return regmap_raw_read(map, offset, valp, REGMAP_SIZE_32);
> +   return regmap_raw_read(map, offset, valp,
> +  map->width ? map->width : REGMAP_SIZE_32);

Can you set up map->width so you can avoid the checks?

Regards,
Simon


Re: [PATCHv2 4/8] rockchip: Remove ARCH= references from documentation

2020-05-31 Thread Simon Glass
On Tue, 26 May 2020 at 12:37, Tom Rini  wrote:
>
> When building U-Boot we select the architecture via Kconfig and not ARCH
> being passed in via the environment or make cmdline.
>
> Acked-by: Kever Yang 
> Cc: Simon Glass 
> Cc: Philipp Tomsich 
> Acked-by: Klaus Goger 
> Cc: Jagan Teki 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - None
>
> As an aside, these files should be converted rST and moved to doc/board/
> and the MAINTAINERS file updated to include the new documentation file
> too.  Thanks!
> ---
>  board/rockchip/evb_rk3229/README   | 1 -
>  board/rockchip/evb_rk3399/README   | 1 -
>  board/theobroma-systems/lion_rk3368/README | 4 ++--
>  board/vamrs/rock960_rk3399/README  | 1 -
>  4 files changed, 2 insertions(+), 5 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v1 2/3] x86: acpi: Replace _ADR() by _UID() in description of PCI host bridge

2020-05-31 Thread Simon Glass
On Tue, 26 May 2020 at 11:16, Andy Shevchenko
 wrote:
>
> PCI Firmware specification requires _UID() and doesn't require _ADR()
> to be set. Replace latter by former.
>
> Reported-by: Bin Meng 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Re: [PATCH v3 5/5] rockchip: make_fit_atf: add signature handling

2020-05-31 Thread Simon Glass
On Tue, 26 May 2020 at 04:44, Heiko Stuebner  wrote:
>
> From: Heiko Stuebner 
>
> If the newly added fit-generator key-options are found, append needed
> signature nodes to all generated image blocks, so that they can get
> signed when mkimage later compiles the .itb from the generated .its.
>
> Signed-off-by: Heiko Stuebner 
> Reviewed-by: Kever Yang 
> ---
>  arch/arm/mach-rockchip/make_fit_atf.py | 51 +-
>  1 file changed, 50 insertions(+), 1 deletion(-)
>

Maybe I am repeating myself, but this really should move to binman I
think. I'll send a few patches that might help.


- Simon


Re: [PATCH v2 09/10] test: dm: rtc: add test of rtc_read, rtc_write

2020-05-31 Thread Simon Glass
On Tue, 19 May 2020 at 16:01, Rasmus Villemoes
 wrote:
>
> Define a few aux registers and check that they can be read/written
> individually. Also check that one can access the time-keeping
> registers directly and get the expected results.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  arch/sandbox/include/asm/rtc.h |  5 
>  test/dm/rtc.c  | 45 ++
>  2 files changed, 50 insertions(+)

Reviewed-by: Simon Glass 


Re: [PATCH v2] i2c: octeon_i2c: Add I2C controller driver for Octeon

2020-05-31 Thread Simon Glass
Hi Stefan,

On Tue, 26 May 2020 at 06:13, Stefan Roese  wrote:
>
> From: Suneel Garapati 
>
> Add support for I2C controllers found on Octeon II/III and Octeon TX
> TX2 SoC platforms.
>
> Signed-off-by: Aaron Williams 
> Signed-off-by: Suneel Garapati 
> Signed-off-by: Stefan Roese 
> Cc: Heiko Schocher 
> Cc: Simon Glass 
> Cc: Daniel Schwierzeck 
> Cc: Aaron Williams 
> Cc: Chandrakala Chavva 
> ---
> v2 (Stefan):
> - Added clk framework support and dropped ad-hoc clock code
> - Removed #ifdef's for Octeon vs OcteonTX/TX2 completely
>   The differentiation is now made via driver data / compatible
>   string
> - Added device-tree bindings documentation
> - Removed unused macro
>
> RFC -> v1 (Stefan):
> - Separated this patch from the OcteonTX/TX2 RFC patch series into a
>   single patch. This is useful, as the upcoming MIPS Octeon support will
>   use this I2C driver.
> - Added MIPS Octeon II/III support (big endian). Rename driver and its
>   function names from "octeontx" to "octeon" to better match all Octeon
>   platforms.
> - Moved from union to defines / bitmasks as suggested by Simon. This makes
>   the driver usage on little- and big-endian platforms much easier.
> - Enhanced Kconfig text
> - Removed all clock macros (use values from DT)
> - Removed long driver debug strings. This is only available when a debug
>   version of this driver is built. The user / developer can lookup the
>   descriptive error messages in the driver in this case anyway.
> - Removed static "last_id"
> - Dropped misc blank lines. Misc reformatting.
> - Dropped "!= 0"
> - Added missing function comments
> - Added missing strut comments
> - Changed comment style
> - Renames "result" to "ret"
> - Hex numbers uppercase
> - Minor other changes
> - Reword commit text and subject
>
>  doc/device-tree-bindings/i2c/octeon-i2c.txt |  24 +
>  drivers/i2c/Kconfig |  10 +
>  drivers/i2c/Makefile|   1 +
>  drivers/i2c/octeon_i2c.c| 847 
>  4 files changed, 882 insertions(+)
>  create mode 100644 doc/device-tree-bindings/i2c/octeon-i2c.txt
>  create mode 100644 drivers/i2c/octeon_i2c.c
>

Reviewed-by: Simon Glass 


Re: [PATCH v1 3/3] x86: acpi: Drop _ADR() where _HID() is present

2020-05-31 Thread Simon Glass
On Tue, 26 May 2020 at 11:16, Andy Shevchenko
 wrote:
>
> ACPICA complains that either _HID() or _ADR() should be used.
> Drop _ADR() where _HID() is present.
>
> Reported-by: Bin Meng 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 1 -
>  1 file changed, 1 deletion(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH 9/9] doc: driver-model: Update SPI migration status

2020-05-31 Thread Simon Glass
On Tue, 26 May 2020 at 02:05, Jagan Teki  wrote:
>
> Update SPI drivers, driver model conversion status
> as per latest conversion and dropping nondm code.
>
> Signed-off-by: Jagan Teki 
> ---
>  doc/driver-model/migration.rst | 5 -
>  1 file changed, 5 deletions(-)
>

Reviewed-by: Simon Glass 


Re: [PATCH v2 07/10] rtc: sandbox-rtc: fix set method

2020-05-31 Thread Simon Glass
On Tue, 19 May 2020 at 16:01, Rasmus Villemoes
 wrote:
>
> The current set method is broken; a simple test case is to first set
> the date to something in April, then change the date to 31st May:
>
> => date 040412122020.34
> Date: 2020-04-04 (Saturday)Time: 12:12:34
> => date 053112122020.34
> Date: 2020-05-01 (Friday)Time: 12:12:34
>
> or via the amending of the existing rtc_set_get test case similarly:
>
> $ ./u-boot -T -v
> => ut dm rtc_set_get
> Test: dm_test_rtc_set_get: rtc.c
> expected: 31/08/2004 18:18:00
> actual: 01/08/2004 18:18:00
>
> The problem is that after each register write,
> sandbox_i2c_rtc_complete_write() gets called and sets the internal
> time from the current set of registers. However, when we get to
> writing 31 to mday, the registers are in an inconsistent state (mon is
> still 4), so the mktime machinery ends up translating April 31st to
> May 1st. Upon the next register write, the registers are populated by
> sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets
> overwritten by a 1.
>
> Fix it by writing all registers at once, and for consistency, update
> the get method to retrieve them all with one "i2c transfer".
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  drivers/rtc/sandbox_rtc.c | 65 +++
>  test/dm/rtc.c | 15 -
>  2 files changed, 38 insertions(+), 42 deletions(-)

Nice fix!

Reviewed-by: Simon Glass 


Re: [PATCH 8/9] spi: Zap SOFT_SPI (non-dm)

2020-05-31 Thread Simon Glass
On Tue, 26 May 2020 at 02:05, Jagan Teki  wrote:
>
> - Deadline for DM migration already passed by months.
> - Sent couple of zap patches and
> - No response on dm conversation
> hence removed the driver.
>
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/Kconfig   |  13 ++-
>  drivers/spi/Makefile  |   1 -
>  drivers/spi/soft_spi_legacy.c | 168 --
>  3 files changed, 6 insertions(+), 176 deletions(-)
>  delete mode 100644 drivers/spi/soft_spi_legacy.c
>

Reviewed-by: Simon Glass 


Re: [PATCH v3 0/3] cmd: add driver, fs and part type listing commands

2020-05-31 Thread Simon Glass
Hi Tom,

On Tue, 26 May 2020 at 13:24, Tom Rini  wrote:
>
> On Tue, May 26, 2020 at 09:57:19AM +0200, Wolfgang Denk wrote:
>
> > Dear Tom,
> >
> > for patch series all review comments have been resolved, and the
> > latest version has seen no further comments, but it has not been
> > pulled either.
> >
> > Is any further action required to get this into mainline?
>
> Ah, sorry.  It's on my list to grab and see what the size growth is,
> since there's new features in generic code.  I'll try and get to that
> soon.

I pushed a rebased tree to u-boot-dm/try-fs (due to cmd_tbl_t change).

Size growth on firefly-rk3288 is:

04: cmd: dm: Fixed/Added DM driver listing subcommands
   arm: (for 1/1 boards) all +1434.0 bss +20.0 data +84.0 rodata
+468.0 text +862.0

Regards,
Simon


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

2020-05-31 Thread Tom Rini
On Sat, May 30, 2020 at 11:06:43PM +0200, Marek Vasut wrote:

> The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell
> (2020-05-27 10:56:25 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 73021d11d4d53cddaa2b1c8e0bd6eb3c79dc7fdc:
> 
>   usb: ehci-mx6: Print error code on failure (2020-05-29 19:23:36 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PULL] u-boot-sh/master

2020-05-31 Thread Tom Rini
On Sat, May 30, 2020 at 11:07:29PM +0200, Marek Vasut wrote:

> The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0:
> 
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell
> (2020-05-27 10:56:25 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sh.git master
> 
> for you to fetch changes up to d8172f606ffd474248172c9a932483913c9f7b7d:
> 
>   sh: r2dplus: Enable HUSH (2020-05-29 19:20:54 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCHv4][2/2] rockchip: rk3328: add rock-pi-e-rk3328_defconfig file

2020-05-31 Thread Kever Yang

Hi Banglong,

On 2020/5/31 下午5:45, b.l.huang wrote:

-Three RK3328 boards are supported:
+Four RK3328 boards are supported:
  
 - EVB RK3328 - use evb-rk3328_defconfig

 - Pine64 Rock64 board - use rock64-rk3328_defconfig
 - Firefly / Libre Computer Project ROC-RK3328-CC board -
   use roc-cc-rk3328_defconfig
+   - Radxa Rockpi E board - use rock-pi-e-rk3328_defconfig


Please update this to doc/board/rockchip/rockchip.rst.

Reference to u-boot-rockchip for latest code for this file.

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


Thanks,

- Kever





Re: [PATCHv4][2/2] rockchip: rk3328: add rock-pi-e-rk3328_defconfig file

2020-05-31 Thread Kever Yang

Hi Banglong,

On 2020/5/31 下午5:45, b.l.huang wrote:

-Three RK3328 boards are supported:
+Four RK3328 boards are supported:
  
 - EVB RK3328 - use evb-rk3328_defconfig

 - Pine64 Rock64 board - use rock64-rk3328_defconfig
 - Firefly / Libre Computer Project ROC-RK3328-CC board -
   use roc-cc-rk3328_defconfig
+   - Radxa Rockpi E board - use rock-pi-e-rk3328_defconfig


Please update this to doc/board/rockchip/rockchip.rst.


Thanks,

- Kever





[PATCH 1/1] log: check argument of 'log level' command

2020-05-31 Thread Heinrich Schuchardt
Check that the argument provided to the 'log level' command is in the range
between zero and CONFIG_LOG_MAX_LEVEL.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/log.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/cmd/log.c b/cmd/log.c
index 664f7bd7ac..78352b2cb9 100644
--- a/cmd/log.c
+++ b/cmd/log.c
@@ -14,10 +14,18 @@ static char log_fmt_chars[LOGF_COUNT] = "clFLfm";
 static int do_log_level(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
 {
-   if (argc > 1)
-   gd->default_log_level = simple_strtol(argv[1], NULL, 10);
-   else
+   if (argc > 1) {
+   long log_level = simple_strtol(argv[1], NULL, 10);
+
+   if (log_level < 0 || log_level > _LOG_MAX_LEVEL) {
+   printf("Only log levels <= %d are supported\n",
+  _LOG_MAX_LEVEL);
+   return CMD_RET_FAILURE;
+   }
+   gd->default_log_level = log_level;
+   } else {
printf("Default log level: %d\n", gd->default_log_level);
+   }

return 0;
 }
--
2.20.1



Re: [PATCHv4][1/2] rockchip: rk3328: add rock-pi-e dts file

2020-05-31 Thread Kever Yang



On 2020/5/31 下午5:43, b.l.huang wrote:

The ROCK-PI-E is a credit card size SBC based on Rockchip RK3328
Quad-Core ARM Cortex A53.

 Net - Dual ethernet port, 1 X Gbe, 1 X 100M
 USB - USB 3.0
 DC  - USB-Type C, 5V 2A
 Storage - TF card, eMMC

Just build idbloader.img and u-boot.itb for Rockpi E board and
follow the blow steps to replace the relevant partition.

 dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc
 dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc

Signed-off-by: Banglang Huang 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---

Changes for v4

 - separate dts file to another commit
 - fix bootup on tpl / spl mode

Changes for v3

 - rename to rock-pi-e

Changes for v2

 - add introduction for rockpie in doc/README.rockchip
 - enable CONFIG_MISC_INIT_R, CONFIG_SMBIOS_MANUFACTURER,
   and CONFIG_SMBIOS_PRODUCT_NAME
---
  arch/arm/dts/Makefile |   3 +-
  arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi |  33 +++
  arch/arm/dts/rk3328-rock-pi-e.dts | 267 ++
  3 files changed, 302 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3328-rock-pi-e.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 12ec6c71dc..67d1adea2d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -107,7 +107,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
  dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
rk3328-roc-cc.dtb \
-   rk3328-rock64.dtb
+   rk3328-rock64.dtb \
+   rk3328-rock-pi-e.dtb
  
  dtb-$(CONFIG_ROCKCHIP_RK3368) += \

rk3368-lion.dtb \
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi 
b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
new file mode 100644
index 00..bf5b1f3adc
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Radxa
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr3-666.dtsi"
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_gpio {
+   u-boot,dm-spl;
+};
+
+_pull_up_4ma {
+   u-boot,dm-spl;
+};
+
+_host0_xhci {
+   vbus-supply = <_host_xhci>;
+   status = "okay";
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+_sd {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3328-rock-pi-e.dts 
b/arch/arm/dts/rk3328-rock-pi-e.dts
new file mode 100644
index 00..21656b64a2
--- /dev/null
+++ b/arch/arm/dts/rk3328-rock-pi-e.dts
@@ -0,0 +1,267 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Radxa
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Radxa Rockpi E";
+   compatible = "radxa,rock-pi-e", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio>;
+   regulator-name = "vcc_sd";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_io>;
+   };
+
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   regulator-name = "vcc5v0_host_xhci";
+   gpio = < RK_PA7 GPIO_ACTIVE_HIGH>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   vcc_sys: vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   cpu-supply = <_arm>;
+};
+
+ {
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   mmc-hs200-1_8v;
+   supports-emmc;
+   disable-wp;
+   non-removable;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _bus8>;
+   vmmc-supply = <_io>;
+   vqmmc-supply = <_emmc>;
+   status = "okay";
+};
+
+ {
+   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <_clkin>, <_clkin>;
+   clock_in_out = "input";
+   phy-supply = <_io>;
+   phy-mode = "rgmii";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   snps,force_thresh_dma_mode;
+   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us 

Re: [PATCHv4][2/2] rockchip: rk3328: add rock-pi-e-rk3328_defconfig file

2020-05-31 Thread Kever Yang



On 2020/5/31 下午5:45, b.l.huang wrote:

This commit add the default configuration file and relevant description
for rock-pi-e board

Signed-off-by: Banglang Huang 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
  board/rockchip/evb_rk3328/MAINTAINERS |   7 ++
  configs/rock-pi-e-rk3328_defconfig| 104 ++
  doc/README.rockchip   |   3 +-
  3 files changed, 113 insertions(+), 1 deletion(-)
  create mode 100644 configs/rock-pi-e-rk3328_defconfig

diff --git a/board/rockchip/evb_rk3328/MAINTAINERS 
b/board/rockchip/evb_rk3328/MAINTAINERS
index 89becf41c5..e7dd59ff4e 100644
--- a/board/rockchip/evb_rk3328/MAINTAINERS
+++ b/board/rockchip/evb_rk3328/MAINTAINERS
@@ -17,3 +17,10 @@ M:  Matwey V. Kornilov 
  S:  Maintained
  F:  configs/rock64-rk3328_defconfig
  F:  arch/arm/dts/rk3328-rock64-u-boot.dtsi
+
+ROCKPIE-RK3328
+M:  Banglang Huang 
+S:  Maintained
+F:  configs/rock-pi-e-rk3328_defconfig
+F:  arch/arm/dts/rk3328-rock-pi-e.dts
+F:  arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
diff --git a/configs/rock-pi-e-rk3328_defconfig 
b/configs/rock-pi-e-rk3328_defconfig
new file mode 100644
index 00..759838775f
--- /dev/null
+++ b/configs/rock-pi-e-rk3328_defconfig
@@ -0,0 +1,104 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_ENV_OFFSET=0x3F8000
+CONFIG_ROCKCHIP_RK3328=y
+CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_TPL_LIBCOMMON_SUPPORT=y
+CONFIG_TPL_LIBGENERIC_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x400
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x4000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xFF13
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SMBIOS_PRODUCT_NAME="rock-pi-e_rk3328"
+CONFIG_DEBUG_UART=y
+CONFIG_TPL_SYS_MALLOC_F_LEN=0x800
+# CONFIG_ANDROID_BOOT_IMAGE is not set
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock-pi-e.dtb"
+CONFIG_MISC_INIT_R=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_TPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_POWER_SUPPORT=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
+CONFIG_TPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_TPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock-pi-e"
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks 
assigned-clock-rates assigned-clock-parents"
+CONFIG_TPL_OF_PLATDATA=y
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_TPL_DM=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_TPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_TPL_SYSCON=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_FASTBOOT_BUF_ADDR=0x800800
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2000
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PHY=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_SPL_DM_REGULATOR=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_SPL_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_RAM=y
+CONFIG_SPL_RAM=y
+CONFIG_TPL_RAM=y
+CONFIG_DM_RESET=y
+CONFIG_BAUDRATE=150
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_DEBUG_UART_ANNOUNCE=y
+CONFIG_DEBUG_UART_SKIP_INIT=y
+CONFIG_SYSRESET=y
+# CONFIG_TPL_SYSRESET is not set
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_GENERIC=y
+CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
+# CONFIG_USB_DWC3_GADGET is not set
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DWC2_OTG=y
+CONFIG_SPL_TINY_MEMSET=y
+CONFIG_TPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
+CONFIG_SMBIOS_MANUFACTURER="radxa"
diff --git a/doc/README.rockchip b/doc/README.rockchip
index 70c8798ed2..a58d480fb3 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -52,12 +52,13 @@ Two RK3308 boards are supported:
 - EVB RK3308 - use evb-rk3308 configuration
 - ROC-CC-RK3308 - use roc-cc-rk3308 configuration
  
-Three RK3328 boards are supported:

+Four RK3328 boards are supported:
  
 - EVB RK3328 - use evb-rk3328_defconfig

 - Pine64 Rock64 board - use rock64-rk3328_defconfig
 - Firefly / Libre Computer Project ROC-RK3328-CC board -
   use roc-cc-rk3328_defconfig
+   - Radxa Rockpi E board - use rock-pi-e-rk3328_defconfig
  
  Size RK3399 boards are supported (aarch64):
  





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

2020-05-31 Thread Kever Yang

Hi Peter,

On 2020/5/31 下午7:38, Peter Robinson wrote:

On Sun, May 31, 2020 at 2:52 AM Kever Yang  wrote:

Hi Tom,

Please pull the rockchip updates/fixes:
- Fix mmc of path after syncfrom kernel dts;
- Add dwc3 host support with DM for rk3399;
- Add usb2phy and typec phy for rockchip platform;
- Migrate board list doc to rockchip.rst

Still no Pinebook Pro?


Sorry for not ask for a resend directly,

Let me apply your patches with below update:

- Fix conflict on top of latest tree;

- update subject of 5/5 patch with acceptable format;

- Update SPDX-License-Identifier in line 1 for pinebook-pro-rk3399.c and 
pinebook-pro-rk3399.h;


- Fix "Invalid MAINTAINERS address" at 
board/pine64/pinebook-pro-rk3399/MAINTAINERS



Thanks,

- Kever


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

Thanks,
- Kever

The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0:

   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-05-27 
10:56:25 -0400)

are available in the Git repository at:

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

for you to fetch changes up to 63a3c89855cabc173c76a9958053408d34d33dc2:

   rockchip: rockpro64: enable DM_KEYBOARD (2020-05-30 07:38:50 +0800)


Frank Wang (8):
   arm: mach-rockchip: bind sub-nodes for rk3399_syscon
   usb: dwc3: add dis_enblslpm_quirk
   usb: dwc3: add dis_u2_freeclk_exists_quirk
   usb: dwc3: amend UTMI/UTMIW phy interface setup
   usb: dwc3: add make compatible for rockchip platform
   driver: usb: drop legacy rockchip xhci driver
   ARM: dts: rk3399-evb: usb3.0 host support
   configs: evb-rk3399: update support usb3.0 host

Jagan Teki (13):
   rockchip: Fix spl mmc boot device ofpath
   clk: rk3399: Fix eMMC get_clk reg offset
   arm64: dts: rk3399-nanopi4: Add u-boot,spl-boot-order
   nanopc-t4: Enable USB Gadget
   doc: rockchip: Document eMMC program steps
   clk: rk3399: Enable/Disable the USB2PHY clk
   clk: rk3399: Set empty for TCPHY assigned-clocks
   clk: rk3399: Enable/Disable TCPHY clocks
   phy: rockchip: Add Rockchip USB2PHY driver
   phy: rockchip: Add Rockchip USB TypeC PHY driver
   usb: dwc3: Add disable u2mac linestate check quirk
   usb: dwc3: Enable AutoRetry feature in the controller
   roc-rk3399-pc: Enable USB3.0 Host

Marcin Juszkiewicz (2):
   rockchip: enable USB OHCI host for RockPro64
   rockchip: rockpro64: enable DM_KEYBOARD

Mark Kettenis (2):
   pci: Make Rockchip PCIe voltage regulators optional
   rk3399: Enable NVMe distro bootcmd

Walter Lozano (3):
   doc: board: rockchip: Improve supported board list format
   doc: board: rockchip: Add missing supported boards
   doc: rockchip: Remove list of supported boards

  arch/arm/dts/rk3399-evb-u-boot.dtsi   |  15 +-
  arch/arm/dts/rk3399-ficus-u-boot.dtsi |   2 +-
  arch/arm/dts/rk3399-nanopi4-u-boot.dtsi   |   6 +
  arch/arm/dts/rk3399-rock960-u-boot.dtsi   |   2 +-
  arch/arm/mach-rockchip/rk3399/rk3399.c|   4 +-
  arch/arm/mach-rockchip/rk3399/syscon_rk3399.c |   3 +
  board/theobroma-systems/puma_rk3399/puma-rk3399.c |   4 +-
  configs/evb-rk3399_defconfig  |   6 +
  configs/nanopc-t4-rk3399_defconfig|   3 +
  configs/roc-pc-mezzanine-rk3399_defconfig |   5 +
  configs/roc-pc-rk3399_defconfig   |   6 +
  configs/rockpro64-rk3399_defconfig|   3 +
  doc/README.rockchip   |  72 +-
  doc/board/rockchip/rockchip.rst   | 116 +++-
  drivers/Makefile  |   1 +
  drivers/clk/rockchip/clk_rk3399.c |  40 +-
  drivers/pci/pcie_rockchip.c   |  33 +-
  drivers/phy/Kconfig   |   1 +
  drivers/phy/rockchip/Kconfig  |  21 +
  drivers/phy/rockchip/Makefile |   7 +
  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 312 +
  drivers/phy/rockchip/phy-rockchip-typec.c | 796 ++
  drivers/usb/common/common.c   |  25 +
  drivers/usb/dwc3/core.c   | 106 ++-
  drivers/usb/dwc3/core.h   |  19 +
  drivers/usb/dwc3/dwc3-generic.c   |  34 +-
  drivers/usb/host/Kconfig  |   9 -
  drivers/usb/host/Makefile |   1 -
  drivers/usb/host/xhci-rockchip.c  | 197 --
  include/configs/rockchip-common.h |   7 +
  include/configs/rockpro64_rk3399.h|   2 +
  include/dwc3-uboot.h  |   3 +
  include/linux/usb/phy.h   |  18 +
  33 files changed, 1510 

Re: [PATCH v2 1/2] rockchip: spl: do full dram_init instead of only probing

2020-05-31 Thread Kever Yang

Hi Heiko,

    Below error happen when build:

+arch/arm/mach-rockchip/spl.c: In function 'board_init_f':
690 
+arch/arm/mach-rockchip/spl.c:112:18: 
error: unused variable 'dev' [-Werror=unused-variable]


    I will fix it when apply, but please make sure all the boards can 
pass the build next time.


Thanks,
- Kever
On 2020/5/26 上午1:57, Heiko Stuebner wrote:

-   ret = uclass_get_device(UCLASS_RAM, 0, );
+   ret = dram_init();


[PATCH 1/1] log: clean up Kconfig

2020-05-31 Thread Heinrich Schuchardt
LOG_DEFAULT_LEVEL has been chosen as 6. Adjust the default of LOG_MAX_LEVEL
to this value.

Use ranges to clamp log levels to reasonable values.

Group output options by main U-Boot, SPL, TPL, followed by other logging
options.

Signed-off-by: Heinrich Schuchardt 
---
 common/Kconfig | 159 ++---
 1 file changed, 85 insertions(+), 74 deletions(-)

diff --git a/common/Kconfig b/common/Kconfig
index 2d86dd7e63..7872bc46cd 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -647,28 +647,12 @@ config LOG
  discarded if not needed. Logging supports various categories and
  levels of severity.

-config SPL_LOG
-   bool "Enable logging support in SPL"
-   depends on LOG
-   help
- This enables support for logging of status and debug messages. These
- can be displayed on the console, recorded in a memory buffer, or
- discarded if not needed. Logging supports various categories and
- levels of severity.
-
-config TPL_LOG
-   bool "Enable logging support in TPL"
-   depends on LOG
-   help
- This enables support for logging of status and debug messages. These
- can be displayed on the console, recorded in a memory buffer, or
- discarded if not needed. Logging supports various categories and
- levels of severity.
+if LOG

 config LOG_MAX_LEVEL
int "Maximum log level to record"
-   depends on LOG
-   default 5
+   default 6
+   range 0 9
help
  This selects the maximum log level that will be recorded. Any value
  higher than this will be ignored. If possible log statements below
@@ -685,14 +669,15 @@ config LOG_MAX_LEVEL
8 - debug content
9 - debug hardware I/O

-config SPL_LOG_MAX_LEVEL
-   int "Maximum log level to record in SPL"
-   depends on SPL_LOG
-   default 3
+config LOG_DEFAULT_LEVEL
+   int "Default logging level to display"
+   default LOG_MAX_LEVEL
+   range 0 LOG_MAX_LEVEL
help
- This selects the maximum log level that will be recorded. Any value
- higher than this will be ignored. If possible log statements below
- this level will be discarded at build time. Levels:
+ This is the default logging level set when U-Boot starts. It can
+ be adjusted later using the 'log level' command. Note that setting
+ this to a value above LOG_MAX_LEVEL will be ineffective, since the
+ higher levels are not compiled in to U-Boot.

0 - emergency
1 - alert
@@ -705,10 +690,38 @@ config SPL_LOG_MAX_LEVEL
8 - debug content
9 - debug hardware I/O

-config TPL_LOG_MAX_LEVEL
-   int "Maximum log level to record in TPL"
-   depends on TPL_LOG
+config LOG_CONSOLE
+   bool "Allow log output to the console"
+   default y
+   help
+ Enables a log driver which writes log records to the console.
+ Generally the console is the serial port or LCD display. Only the
+ log message is shown - other details like level, category, file and
+ line number are omitted.
+
+config LOG_SYSLOG
+   bool "Log output to syslog server"
+   depends on NET
+   help
+ Enables a log driver which broadcasts log records via UDP port 514
+ to syslog servers.
+
+config SPL_LOG
+   bool "Enable logging support in SPL"
+   depends on LOG
+   help
+ This enables support for logging of status and debug messages. These
+ can be displayed on the console, recorded in a memory buffer, or
+ discarded if not needed. Logging supports various categories and
+ levels of severity.
+
+if SPL_LOG
+
+config SPL_LOG_MAX_LEVEL
+   int "Maximum log level to record in SPL"
+   depends on SPL_LOG
default 3
+   range 0 9
help
  This selects the maximum log level that will be recorded. Any value
  higher than this will be ignored. If possible log statements below
@@ -725,14 +738,37 @@ config TPL_LOG_MAX_LEVEL
8 - debug content
9 - debug hardware I/O

-config LOG_DEFAULT_LEVEL
-   int "Default logging level to display"
-   default 6
+config SPL_LOG_CONSOLE
+   bool "Allow log output to the console in SPL"
+   default y
help
- This is the default logging level set when U-Boot starts. It can
- be adjusted later using the 'log level' command. Note that setting
- this to a value above LOG_MAX_LEVEL will be ineffective, since the
- higher levels are not compiled in to U-Boot.
+ Enables a log driver which writes log records to the console.
+ Generally the console is the serial port or LCD display. Only the
+ log message is shown - other details like level, category, file and
+ line number are omitted.
+
+endif
+
+config TPL_LOG
+   bool "Enable logging support in 

Re: [PATCH v2 1/2] rockchip: spl: do full dram_init instead of only probing

2020-05-31 Thread Kever Yang



On 2020/5/26 上午1:57, Heiko Stuebner wrote:

From: Heiko Stuebner 

Parts of later SPL may need RAM information as well, so do full
dram_init() call, which includes the existing dram probing but also
initializes the ram information in gd.

dram_init() from sdram.c does the following steps:
- uclass_get_device(UCLASS_RAM, ...) like the current code
- ret = ram_get_info(dev, );
- gd->ram_size = ram.size;

CONFIG_SPL_RAM already makes sure that sdram.c gets compiled
and thus no other variant of dram_init() can exist.

So it's the same functionality as before and only adds that the
SPL now aquires knowledge about the amount of available ram,
which it didn't know about before.

Signed-off-by: Heiko Stuebner 


Reviewed-by: Kever Yang 

Thanks,
- Kever

---
changes in v2:
- dropped changeid
- expanded commit message on how this does not change functionality

  arch/arm/mach-rockchip/spl.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index 0b76af6080..0eda2c3485 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -135,13 +135,15 @@ void board_init_f(ulong dummy)
/* Init ARM arch timer in arch/arm/cpu/armv7/arch_timer.c */
timer_init();
  #endif
-#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_OS_BOOT)
+#if !defined(CONFIG_TPL) || defined(CONFIG_SPL_RAM)
debug("\nspl:init dram\n");
-   ret = uclass_get_device(UCLASS_RAM, 0, );
+   ret = dram_init();
if (ret) {
printf("DRAM init failed: %d\n", ret);
return;
}
+   gd->ram_top = gd->ram_base + get_effective_memsize();
+   gd->ram_top = board_get_usable_ram_top(gd->ram_size);
  #endif
preloader_console_init();
  }





Re: [PATCH][1/1] README.rockchip: fix typo error

2020-05-31 Thread Tom Rini
On Sun, May 31, 2020 at 05:48:28PM +0800, b.l.huang wrote:

> This commit fix the typo error of doc/README.rockchip,
> it is 'Six' not 'Size'.
> 
> Signed-off-by: Banglang Huang 
> ---
>  doc/README.rockchip | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/README.rockchip b/doc/README.rockchip
> index a58d480fb3..82a3962405 100644
> --- a/doc/README.rockchip
> +++ b/doc/README.rockchip
> @@ -60,7 +60,7 @@ Four RK3328 boards are supported:
>   use roc-cc-rk3328_defconfig
> - Radxa Rockpi E board - use rock-pi-e-rk3328_defconfig
>  
> -Size RK3399 boards are supported (aarch64):
> +Six RK3399 boards are supported (aarch64):
>  
> - EBV RK3399 - use evb_rk3399 configuration
> - Firefly RK3399 - use the firefly_rk3399 configuration

Nak.  The patch which moves the whole list to the rST file is what we
need here.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


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

2020-05-31 Thread Peter Robinson
On Sun, May 31, 2020 at 2:52 AM Kever Yang  wrote:
>
> Hi Tom,
>
> Please pull the rockchip updates/fixes:
> - Fix mmc of path after syncfrom kernel dts;
> - Add dwc3 host support with DM for rk3399;
> - Add usb2phy and typec phy for rockchip platform;
> - Migrate board list doc to rockchip.rst

Still no Pinebook Pro?

> Gitlab ci:
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3495
>
> Thanks,
> - Kever
>
> The following changes since commit ab80137cc436e977ef91a154372ae5aeae3f4fb0:
>
>   Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell (2020-05-27 
> 10:56:25 -0400)
>
> are available in the Git repository at:
>
>   https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/u-boot-rockchip-20200530
>
> for you to fetch changes up to 63a3c89855cabc173c76a9958053408d34d33dc2:
>
>   rockchip: rockpro64: enable DM_KEYBOARD (2020-05-30 07:38:50 +0800)
>
> 
> Frank Wang (8):
>   arm: mach-rockchip: bind sub-nodes for rk3399_syscon
>   usb: dwc3: add dis_enblslpm_quirk
>   usb: dwc3: add dis_u2_freeclk_exists_quirk
>   usb: dwc3: amend UTMI/UTMIW phy interface setup
>   usb: dwc3: add make compatible for rockchip platform
>   driver: usb: drop legacy rockchip xhci driver
>   ARM: dts: rk3399-evb: usb3.0 host support
>   configs: evb-rk3399: update support usb3.0 host
>
> Jagan Teki (13):
>   rockchip: Fix spl mmc boot device ofpath
>   clk: rk3399: Fix eMMC get_clk reg offset
>   arm64: dts: rk3399-nanopi4: Add u-boot,spl-boot-order
>   nanopc-t4: Enable USB Gadget
>   doc: rockchip: Document eMMC program steps
>   clk: rk3399: Enable/Disable the USB2PHY clk
>   clk: rk3399: Set empty for TCPHY assigned-clocks
>   clk: rk3399: Enable/Disable TCPHY clocks
>   phy: rockchip: Add Rockchip USB2PHY driver
>   phy: rockchip: Add Rockchip USB TypeC PHY driver
>   usb: dwc3: Add disable u2mac linestate check quirk
>   usb: dwc3: Enable AutoRetry feature in the controller
>   roc-rk3399-pc: Enable USB3.0 Host
>
> Marcin Juszkiewicz (2):
>   rockchip: enable USB OHCI host for RockPro64
>   rockchip: rockpro64: enable DM_KEYBOARD
>
> Mark Kettenis (2):
>   pci: Make Rockchip PCIe voltage regulators optional
>   rk3399: Enable NVMe distro bootcmd
>
> Walter Lozano (3):
>   doc: board: rockchip: Improve supported board list format
>   doc: board: rockchip: Add missing supported boards
>   doc: rockchip: Remove list of supported boards
>
>  arch/arm/dts/rk3399-evb-u-boot.dtsi   |  15 +-
>  arch/arm/dts/rk3399-ficus-u-boot.dtsi |   2 +-
>  arch/arm/dts/rk3399-nanopi4-u-boot.dtsi   |   6 +
>  arch/arm/dts/rk3399-rock960-u-boot.dtsi   |   2 +-
>  arch/arm/mach-rockchip/rk3399/rk3399.c|   4 +-
>  arch/arm/mach-rockchip/rk3399/syscon_rk3399.c |   3 +
>  board/theobroma-systems/puma_rk3399/puma-rk3399.c |   4 +-
>  configs/evb-rk3399_defconfig  |   6 +
>  configs/nanopc-t4-rk3399_defconfig|   3 +
>  configs/roc-pc-mezzanine-rk3399_defconfig |   5 +
>  configs/roc-pc-rk3399_defconfig   |   6 +
>  configs/rockpro64-rk3399_defconfig|   3 +
>  doc/README.rockchip   |  72 +-
>  doc/board/rockchip/rockchip.rst   | 116 +++-
>  drivers/Makefile  |   1 +
>  drivers/clk/rockchip/clk_rk3399.c |  40 +-
>  drivers/pci/pcie_rockchip.c   |  33 +-
>  drivers/phy/Kconfig   |   1 +
>  drivers/phy/rockchip/Kconfig  |  21 +
>  drivers/phy/rockchip/Makefile |   7 +
>  drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 312 +
>  drivers/phy/rockchip/phy-rockchip-typec.c | 796 
> ++
>  drivers/usb/common/common.c   |  25 +
>  drivers/usb/dwc3/core.c   | 106 ++-
>  drivers/usb/dwc3/core.h   |  19 +
>  drivers/usb/dwc3/dwc3-generic.c   |  34 +-
>  drivers/usb/host/Kconfig  |   9 -
>  drivers/usb/host/Makefile |   1 -
>  drivers/usb/host/xhci-rockchip.c  | 197 --
>  include/configs/rockchip-common.h |   7 +
>  include/configs/rockpro64_rk3399.h|   2 +
>  include/dwc3-uboot.h  |   3 +
>  include/linux/usb/phy.h   |  18 +
>  33 files changed, 1510 insertions(+), 369 deletions(-)
>  create mode 100644 drivers/phy/rockchip/Kconfig
>  create mode 100644 drivers/phy/rockchip/Makefile
>  create mode 100644 drivers/phy/rockchip/phy-rockchip-inno-usb2.c
>  create mode 100644 drivers/phy/rockchip/phy-rockchip-typec.c
>  delete mode 100644 drivers/usb/host/xhci-rockchip.c
>
>


  1   2   >