Re: [U-Boot] [PATCH 1/1] efi_loader: re-enable GRUB workaround on 32bit ARM

2019-08-19 Thread Heinrich Schuchardt

On 8/19/19 9:20 PM, Tom Rini wrote:

On Sun, Jul 28, 2019 at 10:13:24AM +0200, Heinrich Schuchardt wrote:

On 7/27/19 11:58 AM, Alexander Graf wrote:


On 27.07.19 10:02, Heinrich Schuchardt wrote:

GRUB on ARM 32bit prior to version 2.04 lacks proper handling of caches.
In U-Boot v2019.04 a workaround for this was inadvertently removed.

The workaround is currently also needed for booting on systems with
caches
that cannot be managed via CP15 (e.g. with an i.MX6 CPU).

Re-enable the workaround and make it customizable.

Fixes: f69d63fae281 ("efi_loader: use efi_start_image() for bootefi")
Signed-off-by: Heinrich Schuchardt 
---
   lib/efi_loader/Kconfig    |  8 
   lib/efi_loader/efi_boottime.c | 28 +---
   2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index a7f2c68fa9..c7027a9676 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -107,4 +107,12 @@ config EFI_HAVE_RUNTIME_RESET
   default y
   depends on ARCH_BCM283X || FSL_LAYERSCAPE || PSCI_RESET ||
SYSRESET_X86

+config EFI_GRUB_ARM32_WORKAROUND
+    bool "Workaround for GRUB on 32bit ARM"
+    default y
+    depends on ARM && !ARM64
+    help
+  GRUB prior to version 2.04 requires U-Boot to disable caches. This
+  workaround currently is also needed on systems with caches that
+  cannot be managed via CP15.
   endif
diff --git a/lib/efi_loader/efi_boottime.c
b/lib/efi_loader/efi_boottime.c
index 4f6e8d1679..f75ca1a67c 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -39,14 +39,6 @@ LIST_HEAD(efi_register_notify_events);
   /* Handle of the currently executing image */
   static efi_handle_t current_image;

-/*
- * If we're running on nasty systems (32bit ARM booting into non-EFI
Linux)
- * we need to do trickery with caches. Since we don't want to break
the EFI
- * aware boot path, only apply hacks when loading exiting directly
(breaking
- * direct Linux EFI booting along the way - oh well).
- */
-static bool efi_is_direct_boot = true;



By removing the toggling, you now couple a U-Boot configuration variant
to a specific grub version. New grub versions will run Linux using the
EFI stub. So enabling CONFIG_EFI_GRUB_ARM32_WORKAROUND means only old
versions work, but new grub versions break.


No, the Wandboard boots fine with GRUB 2.04 and Linux 4.19.55. Do you
have any negative test results?



We really should treat this like any other erratum and make it as
runtime detected as possible, so that we don't block people from making
forward progress towards a the "sane" boot path.


It is not possible to determine at runtime which assumptions a loaded
EFI binary makes about the cache. Your original logic counting the
number of StartImage() invocations cannot detect this. This is why I
added a customizing option.



Btw, has there been any solution for the non-CP15 caches? They would
still be broken with this applied, as payloads can rely on CP15 caches
enabled (for unaligned accesses), but non-CP15 caches disabled, right?


No, this will need future work. With CONFIG_EFI_GRUB_ARM32_WORKAROUND=y
all caches are disabled.

On i.MX6 CONFIG_SYS_L2CACHE_OFF=y selectively disables the non-CP15
cache. So here CONFIG_EFI_GRUB_ARM32_WORKAROUND=n and
CONFIG_SYS_L2CACHE_OFF=y result in compliance with the UEFI spec.


Where did all of this end up, in terms of what combinations of things do
/ don't work, on current master (or v2019.10-rc2) ?  Thanks all!



The patch is merged with CONFIG_EFI_GRUB_ARM32_WORKAROUND=y as default.
I have tested

* Wandboard (i.MX6) with Debian Buster
* Orange Pi PC (Allwinner H3) with Debian Buster
* BananaPi (Allwinner A20) with OpenBSD and Debian Buster

and found no issues.

Best regards

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


Re: [U-Boot] [PATCH] core: of_addr: Correct the size type of of_get_address to fdt_size_t

2019-08-19 Thread Keerthy



On 19/08/19 3:54 PM, Eugeniu Rosca wrote:

Hi Keerthy,

On Wed, Aug 14, 2019 at 03:56:48PM +0530, Keerthy wrote:

Currently the size parameter is defined as u64 type.
Correct the size type of of_get_address to fdt_size_t
so that both 64 bit and 32 bit architectures are taken
care of.

The initial bug report:
https://patchwork.ozlabs.org/patch/1090094/#2212555

Fixes: e679d03b08fb ("core: ofnode: Add ofnode_get_addr_size_index")
Reported-by: Eugeniu Rosca 
Tested-by: Eugeniu Rosca 
Signed-off-by: Keerthy 
---

Changes from RFT:

   * Fixed a typo in the commit log.
   * Added Reported-by: Eugeniu Rosca 
  Tested-by: Eugeniu Rosca 

  drivers/core/of_addr.c | 4 ++--
  drivers/core/ofnode.c  | 2 +-
  include/dm/of_addr.h   | 2 +-
  3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index 4e256d9926..812a400b19 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -122,7 +122,7 @@ static void dev_count_cells(const struct device_node *np, 
int *nap, int *nsp)
  }
  
  const __be32 *of_get_address(const struct device_node *dev, int index,

-u64 *size, unsigned int *flags)
+fdt_size_t *size, unsigned int *flags)


I took some time to also review the changes in addition to testing.

I can see that, since its inception in Linux [1], of_get_address() used
'u64*' type for its 'size' argument. That's still valid in v5.3-rc5.
So, it looks to me that with this patch we diverge from Linux.

I would barely think that the ASAN issue being fixed in this patch
exists in Linux, since the latter receives much more KASAN-enabled
testing on regular basis.

Do you foresee any alternative fix w/o diverging from Linux?


I am afraid No but isn't fdt_size_t also right type to represent size?



[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22ae782f86b7


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


[U-Boot] [PATCH 3/3] rockchip: rk3399: defconfig: remove SPL raw image support

2019-08-19 Thread Kever Yang
RK3399 SPL only support FIT image for ATF bl31.

Signed-off-by: Kever Yang 
---

 configs/chromebook_bob_defconfig | 1 +
 configs/evb-rk3399_defconfig | 1 +
 configs/ficus-rk3399_defconfig   | 1 +
 configs/firefly-rk3399_defconfig | 1 +
 configs/khadas-edge-captain-rk3399_defconfig | 1 +
 configs/khadas-edge-rk3399_defconfig | 1 +
 configs/khadas-edge-v-rk3399_defconfig   | 1 +
 configs/nanopc-t4-rk3399_defconfig   | 1 +
 configs/nanopi-m4-rk3399_defconfig   | 1 +
 configs/nanopi-neo4-rk3399_defconfig | 1 +
 configs/orangepi-rk3399_defconfig| 1 +
 configs/roc-rk3399-pc_defconfig  | 1 +
 configs/rock-pi-4-rk3399_defconfig   | 1 +
 configs/rock960-rk3399_defconfig | 1 +
 configs/rockpro64-rk3399_defconfig   | 1 +
 15 files changed, 15 insertions(+)

diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index d6fc7e3b63..5126098b94 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -18,6 +18,7 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_TEXT_BASE=0xff8c2000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
 CONFIG_SPL_SPI_LOAD=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 14cca5bf2e..a0d215a5f1 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
 CONFIG_TPL=y
diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
index c3d8656d71..8b3692cdf0 100644
--- a/configs/ficus-rk3399_defconfig
+++ b/configs/ficus-rk3399_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEBUG_UART=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_TEXT_BASE=0xff8c2000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index 38ac8a32c3..d022631465 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
 CONFIG_TPL=y
diff --git a/configs/khadas-edge-captain-rk3399_defconfig 
b/configs/khadas-edge-captain-rk3399_defconfig
index 11ec2dab13..acfd91dbe7 100644
--- a/configs/khadas-edge-captain-rk3399_defconfig
+++ b/configs/khadas-edge-captain-rk3399_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-captain.dtbi"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
 CONFIG_TPL=y
diff --git a/configs/khadas-edge-rk3399_defconfig 
b/configs/khadas-edge-rk3399_defconfig
index c31360af86..b71fd3a286 100644
--- a/configs/khadas-edge-rk3399_defconfig
+++ b/configs/khadas-edge-rk3399_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
 CONFIG_TPL=y
diff --git a/configs/khadas-edge-v-rk3399_defconfig 
b/configs/khadas-edge-v-rk3399_defconfig
index 8c9e9fc7b9..0a789872dc 100644
--- a/configs/khadas-edge-v-rk3399_defconfig
+++ b/configs/khadas-edge-v-rk3399_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-v.dtbi"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
 CONFIG_TPL=y
diff --git a/configs/nanopc-t4-rk3399_defconfig 
b/configs/nanopc-t4-rk3399_defconfig
index 8afa5e1986..1d4c8f8a02 100644
--- a/configs/nanopc-t4-rk3399_defconfig
+++ b/configs/nanopc-t4-rk3399_defconfig
@@ -11,6 +11,7 @@ CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopc-t4.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1
 CONFIG_TPL=y
diff --git a/configs/nanopi-m4-rk3399_defconfig 
b/configs/nanopi-m4-rk3399_defconfig
index e708a4fd8c..7375b758a2 100644
--- 

[U-Boot] [PATCH 2/3] rockchip: rk3368: defconfig: remove SPL raw image support

2019-08-19 Thread Kever Yang
RK3368 SPL only support FIT image for ATF bl31.

Signed-off-by: Kever Yang 
---

 configs/evb-px5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/evb-px5_defconfig b/configs/evb-px5_defconfig
index 46a42a7df6..5a06b2a99f 100644
--- a/configs/evb-px5_defconfig
+++ b/configs/evb-px5_defconfig
@@ -29,6 +29,7 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3368-px5-evb.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_ARCH_EARLY_INIT_R=y
 CONFIG_SPL_BOOTROM_SUPPORT=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
 CONFIG_TPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_ATF=y
-- 
2.17.1

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


[U-Boot] [PATCH 1/3] rockchip: rk3328: defconfig: remove SPL raw image support

2019-08-19 Thread Kever Yang
RK3328 SPL only support FIT image for ATF bl31.

Signed-off-by: Kever Yang 
---

 configs/evb-rk3328_defconfig| 1 +
 configs/rock64-rk3328_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 2868f0f133..37610774c1 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -20,6 +20,7 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-evb.dtb"
 # 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_TPL_DRIVERS_MISC_SUPPORT=y
diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
index e8958590f4..3ab0af1158 100644
--- a/configs/rock64-rk3328_defconfig
+++ b/configs/rock64-rk3328_defconfig
@@ -21,6 +21,7 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock64.dtb"
 # 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_ATF=y
-- 
2.17.1

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


Re: [U-Boot] [PATCH 04/10] x86: Move fsp_api.h inclusion out of fsp_support.h

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> This header file is different for each version of FSP. Move it into the
> fsp_arch.h header file.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/fsp1/fsp_support.h | 1 -
>  arch/x86/include/asm/fsp_arch.h | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH 08/10] x86: Move fsp_infoheader.h to the generic fsp directory

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> This header file is the same for FSP v1 and v2. Move it into the general
> fsp directory.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/fsp1/fsp_support.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH 07/10] x86: Move fsp_hob.h to the generic fsp directory

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> This header file is the same for FSP v1 and v2. Move it into the general
> fsp directory.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/{fsp1 => fsp}/fsp_hob.h| 0
>  arch/x86/include/asm/{fsp1 => fsp}/fsp_infoheader.h | 0
>  arch/x86/include/asm/fsp1/fsp_support.h | 1 +
>  3 files changed, 1 insertion(+)
>  rename arch/x86/include/asm/{fsp1 => fsp}/fsp_hob.h (100%)
>  rename arch/x86/include/asm/{fsp1 => fsp}/fsp_infoheader.h (100%)
>

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


Re: [U-Boot] [PATCH 10/10] x86: Move fsp_ffs.h include to fsp_arch.h

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> This include file is only used for FSP v1. Avoid including it from
> fdt_support.h so we can use the latter with FSP v2.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/fsp_arch.h | 1 +
>  1 file changed, 1 insertion(+)
>

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


Re: [U-Boot] [PATCH 03/10] x86: Create a new fsp_arch.h header

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> At present fsp_support.h includes fsp_vpd.h which is an FPSv1 concept
> (VPD means Vital Product Data). For FSPv2 only UPD (Updatable Product
> Data) is used.
>
> To avoid mangling header files, put these two includes in a separate
> header which we can adjust as necessary for FSPv2.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/fsp1/fsp_support.h |  3 +--
>  arch/x86/include/asm/fsp_arch.h | 20 
>  2 files changed, 21 insertions(+), 2 deletions(-)
>  create mode 100644 arch/x86/include/asm/fsp_arch.h
>

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


Re: [U-Boot] [PATCH 05/10] x86: Move fsp_types.h to the generic fsp directory

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> This header file is the same for FSP v1 and v2. Move it into the general
> fsp directory.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/{fsp1 => fsp}/fsp_types.h | 0
>  arch/x86/include/asm/fsp1/fsp_support.h| 2 +-
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename arch/x86/include/asm/{fsp1 => fsp}/fsp_types.h (100%)
>

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


Re: [U-Boot] [PATCH 06/10] x86: Move fsp_fv.h to the generic fsp directory

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> This header file is the same for FSP v1 and v2. Move it into the general
> fsp directory.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/{fsp1 => fsp}/fsp_fv.h | 0
>  arch/x86/include/asm/fsp1/fsp_support.h | 2 +-
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename arch/x86/include/asm/{fsp1 => fsp}/fsp_fv.h (100%)
>

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


Re: [U-Boot] [PATCH 09/10] x86: Move fsp_bootmode.h to the generic fsp directory

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> This header file is the same for FSP v1 and v2, although there may be
> some additions to come. Move it into the generic fsp directory.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/include/asm/{fsp1 => fsp}/fsp_bootmode.h | 0
>  arch/x86/include/asm/fsp1/fsp_support.h   | 3 +--
>  2 files changed, 1 insertion(+), 2 deletions(-)
>  rename arch/x86/include/asm/{fsp1 => fsp}/fsp_bootmode.h (100%)
>

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


Re: [U-Boot] [PATCH 02/10] x86: fsp: Move fsp_azalia include out of fsp_support.h

2019-08-19 Thread Bin Meng
Hi Simon,

On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> This file is only used by one board and we don't need the types for most

Two boards based on the changes in the commit.

> FSP files so it is wasteful to include it so widely. Drop it from this
> header.
>

But it does no harm to include this header, right? Does FSPv2 not
support the fsp_azalia struct?

> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/braswell/fsp_configs.c   | 1 +
>  arch/x86/include/asm/fsp1/fsp_support.h   | 4 +++-
>  board/advantech/som-db5800-som-6867/som-db5800-som-6867.c | 1 +
>  3 files changed, 5 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH 01/10] x86: Rename existing FSP code to fsp1

2019-08-19 Thread Bin Meng
Hi Simon,

On Mon, Aug 19, 2019 at 6:51 AM Simon Glass  wrote:
>
> Since there is now a new version of the FSP and it is incompatible with
> the existing version, move the code into an fsp1 directory. This will
> allow us to put FSP v2 code into an fsp2 directory.
>
> Add a Kconfig which defines which version is in use.
>
> Some of the code in this new fsp1/ directory is generic across both FSPv1
> and FSPv2. Future patches will address this.
>
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/Kconfig  | 25 ++-
>  arch/x86/cpu/baytrail/acpi.c  |  2 +-
>  arch/x86/cpu/baytrail/fsp_configs.c   |  2 +-
>  arch/x86/cpu/braswell/fsp_configs.c   |  2 +-
>  arch/x86/cpu/ivybridge/fsp_configs.c  |  2 +-
>  arch/x86/cpu/queensbay/fsp_configs.c  |  2 +-
>  arch/x86/cpu/queensbay/tnc.c  |  2 +-
>  arch/x86/include/asm/{fsp => fsp1}/fsp_api.h  |  0
>  .../include/asm/{fsp => fsp1}/fsp_azalia.h|  0
>  .../include/asm/{fsp => fsp1}/fsp_bootmode.h  |  0
>  arch/x86/include/asm/{fsp => fsp1}/fsp_ffs.h  |  0
>  arch/x86/include/asm/{fsp => fsp1}/fsp_fv.h   |  0
>  arch/x86/include/asm/{fsp => fsp1}/fsp_hob.h  |  0
>  .../asm/{fsp => fsp1}/fsp_infoheader.h|  0
>  .../include/asm/{fsp => fsp1}/fsp_support.h   |  0
>  .../x86/include/asm/{fsp => fsp1}/fsp_types.h |  0
>  arch/x86/include/asm/u-boot-x86.h |  2 +-
>  arch/x86/lib/Makefile |  3 ++-
>  arch/x86/lib/{fsp => fsp1}/Makefile   |  0
>  arch/x86/lib/{fsp => fsp1}/fsp_car.S  |  0
>  arch/x86/lib/{fsp => fsp1}/fsp_common.c   |  2 +-
>  arch/x86/lib/{fsp => fsp1}/fsp_dram.c |  2 +-
>  arch/x86/lib/{fsp => fsp1}/fsp_graphics.c |  2 +-
>  arch/x86/lib/{fsp => fsp1}/fsp_support.c  |  2 +-
>  .../som-db5800-som-6867/som-db5800-som-6867.c |  2 +-
>  board/intel/cherryhill/cherryhill.c   |  2 +-
>  cmd/x86/fsp.c |  2 +-
>  drivers/pci/pci-uclass.c  |  2 +-
>  28 files changed, 41 insertions(+), 17 deletions(-)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_api.h (100%)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_azalia.h (100%)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_bootmode.h (100%)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_ffs.h (100%)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_fv.h (100%)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_hob.h (100%)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_infoheader.h (100%)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_support.h (100%)
>  rename arch/x86/include/asm/{fsp => fsp1}/fsp_types.h (100%)
>  rename arch/x86/lib/{fsp => fsp1}/Makefile (100%)
>  rename arch/x86/lib/{fsp => fsp1}/fsp_car.S (100%)
>  rename arch/x86/lib/{fsp => fsp1}/fsp_common.c (99%)
>  rename arch/x86/lib/{fsp => fsp1}/fsp_dram.c (98%)
>  rename arch/x86/lib/{fsp => fsp1}/fsp_graphics.c (98%)
>  rename arch/x86/lib/{fsp => fsp1}/fsp_support.c (99%)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 218e817cf3..04e8a1a4e0 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -364,6 +364,29 @@ config HAVE_FSP
>   Note: Without this binary U-Boot will not be able to set up its
>   SDRAM so will not boot.
>
> +choice
> +   prompt "FSP version"
> +   depends on HAVE_FSP
> +   default FSP_VERSION1
> +   help
> + Selects the FSP version to use. Intel has published several versions
> + of the FSP External Architecture Specification and this allows
> + selection of the version number used by a particular SoC.
> +
> +config FSP_VERSION1
> +   bool "FSP version 1.x"
> +   help
> + This covers versions 1.0 and 1.1a. See here for details:
> + https://github.com/IntelFsp/fsp1/wiki

This link should be: https://github.com/IntelFsp/fsp/wiki

> +
> +config FSP_VERSION2
> +   bool "FSP version 2.x"
> +   help
> + This covers versions 2.0 and 2.1. See here for details:
> + https://github.com/IntelFsp/fsp1/wiki

ditto.

> +
> +endchoice
> +

[snip]

Other than above:
Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH 2/2] libavb: Fix build warnings after updating the lib

2019-08-19 Thread Bowgo Tsai
Hi,

Just to re: > taking into account the amount of time needed
(sometimes it can take months, or even years, Sam has good
stories about that) to get something applied to AOSP

This probably needs to be discussed case by case, as there are ~750 project
s
on AOSP now. For large changes, it might be helpful to start by a buganizer
or e-mail thread, to reach a consensus with individual owners.

For small changes (e.g., fix some code health issue), the review should be
just a few days or a few weeks.


On Mon, Aug 19, 2019 at 5:40 PM Igor Opaniuk  wrote:

> Hi Eugeniu,
>
> On Mon, Aug 19, 2019 at 11:28 AM Eugeniu Rosca 
> wrote:
> >
> > Hi all,
> >
> > On Fri, Aug 16, 2019 at 11:46:03AM -0400, David Zeuthen wrote:
> > >Hi,
> > >As for upstreaming libavb patches, I'd be interested in landing them
> > >upstream... makes it easier for anyone.
> > >Our upstream is AOSP and we use gerrit for
> > >code-review:
> https://android-review.googlesource.com/q/project:platform%252Fexternal%252Favb
> > >Here's a guide to
> > >contributing:
> https://source.android.com/setup/contribute/submit-patches ...
> > >hope it's not too painful to use the AOSP process!
> > >Thanks,
> > >David
> >
> > David, thanks for being open about discussing/accepting the fixes.
> >
> > U-Boot folks,
> >
> > What's your opinion w.r.t. the right/best order between accepting
> > the libavb fixes locally in U-Boot and pushing them to upstream?
> > Which should come first? I suppose they can be first applied internally
> > and replaced later on if they get reworked/optimized during upstreaming.
> >
> > --
> > Best Regards,
> > Eugeniu.
>
> IMHO, the best approach here is to upstream fixes to AOSP libavb first,
> only then port stuff to U-boot.
>
> Nevertheless, taking into account the amount of time needed
> (sometimes it can take months, or even years, Sam has good
> stories about that) to get something applied to AOSP, I would suggest
> to proceed internally with commits like this ASAP, but somehow (extended
> commit message for each "libavb sync" patch with the list of patches out of
> AOSP tree; or introduce "doc/android/libavb-porting.txt", where we can
> provide all details about list of commits from AOSP + out-of-tree commits,
> how-to do porting etc; other ideas?) keep track of changes that are not
> up-streamed to AOSP yet.
>
> Ideally we have to achieve 1:1 mapping (with the only difference - SPDX
> tags),
> of [1] in lib/libavb/, otherwise we will fight with constant code
> divergence (obviously).
>
> [1] https://android.googlesource.com/platform/external/avb/+/
> /libavb
>
> --
> Best regards - Freundliche Grüsse - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opan...@gmail.com
> skype: igor.opanyuk
> +380 (93) 836 40 67
> http://ua.linkedin.com/in/iopaniuk
>


-- 

Bowgo Tsai |  Engineer |  bowgot...@google.com |  +886 (2) 8729-6364
<%2B886287296364>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Travis test/py sandbox_spl test fail

2019-08-19 Thread Kever Yang

Hi Stephen,

On 2019/8/20 上午1:34, Stephen Warren wrote:

On 8/18/19 7:01 PM, Kever Yang wrote:

Hi Simon, Stephen,

 Could you help to comment on my other mail, which patch cause 
this failure.


If you run "git bisect", you should be able to track down which patch 
introduced the problem.



I already locate the patch,  and it seems some but in sandbox_spl or 
test, but not the driver,


see below:

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

Thanks,

- Kever






Thanks,

- Kever

On 2019/8/14 下午11:49, Stephen Warren wrote:

On 8/13/19 8:06 PM, Kever Yang wrote:

Hi Stephen,

On 2019/8/14 上午4:54, Stephen Warren wrote:

On 8/13/19 3:39 AM, Simon Glass wrote:

+Stephen

Hi Kever,

On Tue, 13 Aug 2019 at 03:35, Kever Yang 
 wrote:


Hi Simon,

 I got fail in test/py sandbox_spl, and the log says:

E OSError: [Errno 5] Input/output error

I have no idea about what's wrong in source code, could you help

to take a look?

Travis job:

https://travis-ci.org/keveryang/u-boot/jobs/571125119


When I've seen this (ugly) error it is normally because U-Boot
crashed, e.g. with a segfault.


Yes, that's the typical reason. If you run test.py locally you'll 
be able to access the log file (which Travis doesn't save), which 
will likely give you more details about the crash, and/or you 
could attach gdb to the sandbox process to trap the problem too.


I got:

$ ./u-boot
bloblist_init() Existing bloblist not found: creating new bloblist
[1]    958 segmentation fault (core dumped)  ./u-boot

And no more logs, is there any other log file I can check?


There probably isn't any more log information beyond that. I think 
the next step would be to run U-Boot sandbox under gdb, reproduce 
the problem, and then debug it.









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


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze【请注意,邮件由lists.intric...@gmail.com代发】

2019-08-19 Thread Kever Yang

Hi Kurt,


Does this patch fix your issue?

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


Thanks,

- Kever

On 2019/8/20 上午7:32, Kurt Miller wrote:

Hi Jagan,

On Mon, 2019-08-19 at 23:26 +0530, Jagan Teki wrote:

Is your board running at 50MHz? (look like No).

No it is running at 800Mhz or 856MHz (see rkbin TPL output below).


As I said please
explore step-by-step
00: First boot the board rkbin => SPL => U-Boot proper

This step was completed already. Here is the output again for reference:

DDR Version 1.23 20190709
In
channel 0
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
OUT


01: Grab the sdram-*.dtsi (steps mentioned in previous mail) and
replace rkbin withTPL

I am stuck here. I see that there were three 800Mhz entries
in the rkbin rk3399_ddr_800MHz_v1.20.bin file that was used to
create ./arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi.

rk3399-sdram-lpddr4-100.dtsi has one entry that appears to
be from the first 800Mhz data in rk3399_ddr_800MHz_v1.20.bin.

Using the instructions you linked:
https://wiki.amarulasolutions.com/found/target/rk3399_sdram.html

I have inspected rkbin rk3399_ddr_800MHz_v1.23.bin and found
there are two 800Mhz entries in it. I have extracted the two
entries but have have questions that the instructions don't
address well.

Why does the existing rk3399-sdram-lpddr4-100.dtsi only have
one entry while the instructions appear to indicate there
should be two, one for single and another for dual ranked?

Step 6 refers to editing the dtsi file:

"..., edit the initial values (don’t forget that they are in
little endian form) to match what the SPL code expects,
convert the frequency value from the binary back into MHz
(line 38 in the attached dtsi files for reference)"

I believe I was able to convert the data into the updated
values correctly (see attached diff). However, one value
stood out to me. The 800Mhz value of 0x2faf0800 was converted
into decimal 50 in the existing data whereas other sdram files
converted it into 1/2 the Mhz value (e.g. 800Mhz -> 400).

With it set to 50 I get this output before it stops:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 18:45:16)
pctl_start: Failed to init pctl for channel 0

With it set to 400 I get this output before it stops:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 19:14:10)
sdram_init: DDR3 - 400MHz failed!
rk3399_dmc_init DRAM init failed -22
Missing DTB


02: Then dump the regmap if 01 failed.

Jagan.

01 failed. With the timings diff reverted I get this before it freezes:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride
cic: ctr10: (0xff62 - 0x14)
cic: status0: (0xff620010 - 0x101)
grf: ddrc0_con0 (0xff77e380 - 0x1f81)
grf: ddrc1_con0 (0xff77e388 - 0x1f81)
grf: soc_con0 (0xff77e200 - 0x7)
pmu: noc_auto_ena (0xff3100d8 - 0x0)
pmu: bus_idle_req (0xff310060 - 0x0)
pmu: bus_idle_st (0xff310064 - 0x0)
pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
pmugrf: os_reg3 (0xff32030c - 0x2005)
pmusgrf: soc_con4 (0xff33e010 - 0x2600)

Please let me know other items can be tried to get this up and
running with the U-Boot TPL.

Regards,
-Kurt



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


[U-Boot] [PATCH 3/3] arm: socfpga: Convert clock manager from struct to defines

2019-08-19 Thread Ley Foon Tan
Convert clock manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
No functional change.

Signed-off-by: Ley Foon Tan 
---
 arch/arm/mach-socfpga/clock_manager.c |  12 +-
 arch/arm/mach-socfpga/clock_manager_arria10.c | 217 +
 arch/arm/mach-socfpga/clock_manager_gen5.c| 221 +-
 arch/arm/mach-socfpga/clock_manager_s10.c | 167 +++--
 .../mach-socfpga/include/mach/clock_manager.h |  15 ++
 .../include/mach/clock_manager_arria10.h  | 129 --
 .../include/mach/clock_manager_gen5.h | 108 -
 .../include/mach/clock_manager_s10.h  | 111 -
 drivers/mmc/socfpga_dw_mmc.c  |   9 +-
 9 files changed, 451 insertions(+), 538 deletions(-)

diff --git a/arch/arm/mach-socfpga/clock_manager.c 
b/arch/arm/mach-socfpga/clock_manager.c
index 9f3c643df8..59779e2175 100644
--- a/arch/arm/mach-socfpga/clock_manager.c
+++ b/arch/arm/mach-socfpga/clock_manager.c
@@ -10,18 +10,15 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static const struct socfpga_clock_manager *clock_manager_base =
-   (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-
 void cm_wait_for_lock(u32 mask)
 {
u32 inter_val;
u32 retry = 0;
do {
 #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
-   inter_val = readl(_manager_base->inter) & mask;
+   inter_val = CLKMGR_READL(CLKMGR_INTER) & mask;
 #else
-   inter_val = readl(_manager_base->stat) & mask;
+   inter_val = CLKMGR_READL(CLKMGR_STAT) & mask;
 #endif
/* Wait for stable lock */
if (inter_val == mask)
@@ -36,8 +33,9 @@ void cm_wait_for_lock(u32 mask)
 /* function to poll in the fsm busy bit */
 int cm_wait_for_fsm(void)
 {
-   return wait_for_bit_le32(_manager_base->stat,
-CLKMGR_STAT_BUSY, false, 2, false);
+   return wait_for_bit_le32((const void *)(SOCFPGA_CLKMGR_ADDRESS +
+CLKMGR_STAT), CLKMGR_STAT_BUSY, false, 2,
+false);
 }
 
 int set_cpu_clk_info(void)
diff --git a/arch/arm/mach-socfpga/clock_manager_arria10.c 
b/arch/arm/mach-socfpga/clock_manager_arria10.c
index 334a79fd9c..05b7465680 100644
--- a/arch/arm/mach-socfpga/clock_manager_arria10.c
+++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
@@ -231,9 +231,6 @@ static int of_get_clk_cfg(const void *blob, struct 
mainpll_cfg *main_cfg,
return 0;
 }
 
-static const struct socfpga_clock_manager *clock_manager_base =
-   (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-
 /* calculate the intended main VCO frequency based on handoff */
 static unsigned int cm_calc_handoff_main_vco_clk_hz
(struct mainpll_cfg *main_cfg)
@@ -548,15 +545,15 @@ static void cm_pll_ramp_main(struct mainpll_cfg *main_cfg,
/* execute the ramping here */
for (clk_hz = pll_ramp_main_hz + clk_incr_hz;
 clk_hz < clk_final_hz; clk_hz += clk_incr_hz) {
-   writel((main_cfg->vco1_denom <<
+   CLKMGR_WRITEL((main_cfg->vco1_denom <<
CLKMGR_MAINPLL_VCO1_DENOM_LSB) |
cm_calc_safe_pll_numer(0, main_cfg, per_cfg, clk_hz),
-   _manager_base->main_pll.vco1);
+   CLKMGR_MAINPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
-   writel((main_cfg->vco1_denom << CLKMGR_MAINPLL_VCO1_DENOM_LSB) |
-   main_cfg->vco1_numer, _manager_base->main_pll.vco1);
+   CLKMGR_WRITEL((main_cfg->vco1_denom << CLKMGR_MAINPLL_VCO1_DENOM_LSB) |
+   main_cfg->vco1_numer, CLKMGR_MAINPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
 }
@@ -579,14 +576,16 @@ static void cm_pll_ramp_periph(struct mainpll_cfg 
*main_cfg,
/* execute the ramping here */
for (clk_hz = pll_ramp_periph_hz + clk_incr_hz;
 clk_hz < clk_final_hz; clk_hz += clk_incr_hz) {
-   writel((per_cfg->vco1_denom << CLKMGR_PERPLL_VCO1_DENOM_LSB) |
-   cm_calc_safe_pll_numer(1, main_cfg, per_cfg, clk_hz),
-   _manager_base->per_pll.vco1);
+   CLKMGR_WRITEL((per_cfg->vco1_denom <<
+ CLKMGR_PERPLL_VCO1_DENOM_LSB) |
+ cm_calc_safe_pll_numer(1, main_cfg, per_cfg,
+clk_hz),
+ CLKMGR_PERPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
-   writel((per_cfg->vco1_denom << CLKMGR_PERPLL_VCO1_DENOM_LSB) |
-   per_cfg->vco1_numer, _manager_base->per_pll.vco1);
+   CLKMGR_WRITEL((per_cfg->vco1_denom << CLKMGR_PERPLL_VCO1_DENOM_LSB) |
+ per_cfg->vco1_numer, CLKMGR_PERPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
 }
@@ -636,39 

[U-Boot] [PATCH 2/3] arm: socfpga: Convert system manager from struct to defines

2019-08-19 Thread Ley Foon Tan
Convert system manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
No functional change.

Signed-off-by: Ley Foon Tan 
---
 arch/arm/mach-socfpga/clock_manager_s10.c |   4 +-
 .../include/mach/system_manager.h |  15 ++
 .../include/mach/system_manager_arria10.h |  92 +++--
 .../include/mach/system_manager_gen5.h| 121 ++--
 .../include/mach/system_manager_s10.h | 184 +++---
 arch/arm/mach-socfpga/mailbox_s10.c   |   5 +-
 arch/arm/mach-socfpga/misc_arria10.c  |   7 +-
 arch/arm/mach-socfpga/misc_gen5.c |  16 +-
 arch/arm/mach-socfpga/misc_s10.c  |   8 +-
 arch/arm/mach-socfpga/reset_manager_arria10.c |  24 +--
 arch/arm/mach-socfpga/reset_manager_gen5.c|   7 +-
 arch/arm/mach-socfpga/reset_manager_s10.c |  17 +-
 arch/arm/mach-socfpga/scan_manager.c  |   6 +-
 arch/arm/mach-socfpga/spl_a10.c   |   5 +-
 arch/arm/mach-socfpga/spl_gen5.c  |  15 +-
 arch/arm/mach-socfpga/spl_s10.c   |   9 +-
 arch/arm/mach-socfpga/system_manager_gen5.c   |  33 ++--
 arch/arm/mach-socfpga/system_manager_s10.c|  32 +--
 arch/arm/mach-socfpga/wrap_pll_config_s10.c   |  11 +-
 drivers/ddr/altera/sdram_gen5.c   |   9 +-
 drivers/ddr/altera/sdram_s10.c|   6 +-
 drivers/fpga/socfpga_arria10.c|   7 +-
 drivers/fpga/socfpga_gen5.c   |   4 +-
 drivers/mmc/socfpga_dw_mmc.c  |   6 +-
 24 files changed, 217 insertions(+), 426 deletions(-)

diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c 
b/arch/arm/mach-socfpga/clock_manager_s10.c
index 3ba2a00c02..d8835788cc 100644
--- a/arch/arm/mach-socfpga/clock_manager_s10.c
+++ b/arch/arm/mach-socfpga/clock_manager_s10.c
@@ -14,8 +14,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static const struct socfpga_clock_manager *clock_manager_base =
(struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-static const struct socfpga_system_manager *sysmgr_regs =
-   (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
 
 /*
  * function to write the bypass register which requires a poll of the
@@ -351,7 +349,7 @@ unsigned int cm_get_l4_sp_clk_hz(void)
 
 unsigned int cm_get_qspi_controller_clk_hz(void)
 {
-   return readl(_regs->boot_scratch_cold0);
+   return SYSMGR_READL(SYSMGR_BOOT_SCRATCH_COLD0);
 }
 
 unsigned int cm_get_spi_controller_clk_hz(void)
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h 
b/arch/arm/mach-socfpga/include/mach/system_manager.h
index 7e76df74b7..f2f6bc8aec 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
@@ -6,6 +6,21 @@
 #ifndef _SYSTEM_MANAGER_H_
 #define _SYSTEM_MANAGER_H_
 
+#define SYSMGR_READL(reg)  \
+   readl(SOCFPGA_SYSMGR_ADDRESS + (reg))
+
+#define SYSMGR_WRITEL(data, reg)   \
+   writel(data, SOCFPGA_SYSMGR_ADDRESS + (reg))
+
+#define SYSMGR_CLRBITS(reg, mask)  \
+   clrbits_le32(SOCFPGA_SYSMGR_ADDRESS + (reg), mask)
+
+#define SYSMGR_SETBITS(reg, mask)  \
+   setbits_le32(SOCFPGA_SYSMGR_ADDRESS + (reg), mask)
+
+#define SYSMGR_CLRSETBITS(reg, clear, set) \
+   clrsetbits_le32(SOCFPGA_SYSMGR_ADDRESS + (reg), clear, set)
+
 #if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
 #include 
 #else
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h 
b/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
index 14052b957c..6f79074769 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
@@ -6,73 +6,31 @@
 #ifndef _SYSTEM_MANAGER_ARRIA10_H_
 #define _SYSTEM_MANAGER_ARRIA10_H_
 
-struct socfpga_system_manager {
-   u32  siliconid1;
-   u32  siliconid2;
-   u32  wddbg;
-   u32  bootinfo;
-   u32  mpu_ctrl_l2_ecc;
-   u32  _pad_0x14_0x1f[3];
-   u32  dma;
-   u32  dma_periph;
-   u32  sdmmcgrp_ctrl;
-   u32  sdmmc_l3master;
-   u32  nand_bootstrap;
-   u32  nand_l3master;
-   u32  usb0_l3master;
-   u32  usb1_l3master;
-   u32  emac_global;
-   u32  emac[3];
-   u32  _pad_0x50_0x5f[4];
-   u32  fpgaintf_en_global;
-   u32  fpgaintf_en_0;
-   u32  fpgaintf_en_1;
-   u32  fpgaintf_en_2;
-   u32  fpgaintf_en_3;
-   u32  _pad_0x74_0x7f[3];
-   u32  noc_addr_remap_value;
-   u32  noc_addr_remap_set;
-   u32  noc_addr_remap_clear;
-   u32  _pad_0x8c_0x8f;
-   u32  ecc_intmask_value;
-   u32  ecc_intmask_set;
-   u32  ecc_intmask_clr;
-   u32  ecc_intstatus_serr;
-   u32  ecc_intstatus_derr;
-   u32  mpu_status_l2_ecc;
-   u32  mpu_clear_l2_ecc;
-   u32  mpu_status_l1_parity;
-   u32  mpu_clear_l1_parity;
-   u32  mpu_set_l1_parity;
-   u32  _pad_0xb8_0xbf[2];
-   u32  noc_timeout;
-   u32  

[U-Boot] [PATCH 1/3] arm: socfpga: Convert reset manager from struct to defines

2019-08-19 Thread Ley Foon Tan
Convert reset manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
No functional change.

Signed-off-by: Ley Foon Tan 
---
 .../mach-socfpga/include/mach/reset_manager.h | 12 +
 .../include/mach/reset_manager_arria10.h  | 41 +++-
 .../include/mach/reset_manager_gen5.h | 20 +++-
 .../include/mach/reset_manager_s10.h  | 33 ++---
 arch/arm/mach-socfpga/misc_gen5.c |  6 +--
 arch/arm/mach-socfpga/reset_manager_arria10.c | 49 +--
 arch/arm/mach-socfpga/reset_manager_gen5.c| 26 +-
 arch/arm/mach-socfpga/reset_manager_s10.c | 35 ++---
 drivers/sysreset/sysreset_socfpga.c   |  6 +--
 9 files changed, 86 insertions(+), 142 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 6ad037e325..c460e89d22 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -6,6 +6,18 @@
 #ifndef _RESET_MANAGER_H_
 #define _RESET_MANAGER_H_
 
+#define RSTMGR_READL(reg)  \
+   readl(SOCFPGA_RSTMGR_ADDRESS + (reg))
+
+#define RSTMGR_WRITEL(data, reg)   \
+   writel(data, SOCFPGA_RSTMGR_ADDRESS + (reg))
+
+#define RSTMGR_CLRBITS(reg, mask)  \
+   clrbits_le32(SOCFPGA_RSTMGR_ADDRESS + (reg), mask)
+
+#define RSTMGR_SETBITS(reg, mask)  \
+   setbits_le32(SOCFPGA_RSTMGR_ADDRESS + (reg), mask)
+
 void reset_cpu(ulong addr);
 
 void socfpga_per_reset(u32 reset, int set);
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
index 6623ebee65..8b72f41498 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
@@ -14,40 +14,13 @@ int socfpga_reset_deassert_bridges_handoff(void);
 void socfpga_reset_deassert_osc1wd0(void);
 int socfpga_bridges_reset(void);
 
-struct socfpga_reset_manager {
-   u32 stat;
-   u32 ramstat;
-   u32 miscstat;
-   u32 ctrl;
-   u32 hdsken;
-   u32 hdskreq;
-   u32 hdskack;
-   u32 counts;
-   u32 mpumodrst;
-   u32 per0modrst;
-   u32 per1modrst;
-   u32 brgmodrst;
-   u32 sysmodrst;
-   u32 coldmodrst;
-   u32 nrstmodrst;
-   u32 dbgmodrst;
-   u32 mpuwarmmask;
-   u32 per0warmmask;
-   u32 per1warmmask;
-   u32 brgwarmmask;
-   u32 syswarmmask;
-   u32 nrstwarmmask;
-   u32 l3warmmask;
-   u32 tststa;
-   u32 tstscratch;
-   u32 hdsktimeout;
-   u32 hmcintr;
-   u32 hmcintren;
-   u32 hmcintrens;
-   u32 hmcintrenr;
-   u32 hmcgpout;
-   u32 hmcgpin;
-};
+#define RSTMGR_STATUS  0
+#define RSTMGR_CTRL0xc
+#define RSTMGR_MPUMODRST   0x20
+#define RSTMGR_PER0MODRST  0x24
+#define RSTMGR_PER1MODRST  0x28
+#define RSTMGR_BRGMODRST   0x2c
+#define RSTMGR_SYSMODRST   0x30
 
 /*
  * SocFPGA Arria10 reset IDs, bank mapping is as follows:
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
index f4dcb14623..1b308a2b0e 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
@@ -11,19 +11,13 @@
 void socfpga_bridges_set_handoff_regs(bool h2f, bool lwh2f, bool f2h);
 void socfpga_bridges_reset(int enable);
 
-struct socfpga_reset_manager {
-   u32 status;
-   u32 ctrl;
-   u32 counts;
-   u32 padding1;
-   u32 mpu_mod_reset;
-   u32 per_mod_reset;
-   u32 per2_mod_reset;
-   u32 brg_mod_reset;
-   u32 misc_mod_reset;
-   u32 padding2[12];
-   u32 tstscratch;
-};
+#define RSTMGR_STATUS  0
+#define RSTMGR_CTRL4
+#define RSTMGR_MPUMODRST   0x10
+#define RSTMGR_PERMODRST   0x14
+#define RSTMGR_PER2MODRST  0x18
+#define RSTMGR_BRGMODRST   0x1c
+#define RSTMGR_MISCMODRST  0x20
 
 /*
  * SocFPGA Cyclone V/Arria V reset IDs, bank mapping is as follows:
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h 
b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
index 452147b017..64519c1d92 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
@@ -15,34 +15,11 @@ void socfpga_bridges_reset(int enable);
 void socfpga_per_reset(u32 reset, int set);
 void socfpga_per_reset_all(void);
 
-struct socfpga_reset_manager {
-   u32 status;
-   u32 mpu_rst_stat;
-   u32 misc_stat;
-   u32 padding1;
-   u32 hdsk_en;
-   u32 hdsk_req;
-   u32 

[U-Boot] [PATCH 0/3] arm: socfpga: Convert drivers from struct to defines

2019-08-19 Thread Ley Foon Tan
Convert reset, system and clock manager drivers to use #define
instead of struct.

No functional change.

Ley Foon Tan (3):
  arm: socfpga: Convert reset manager from struct to defines
  arm: socfpga: Convert system manager from struct to defines
  arm: socfpga: Convert clock manager from struct to defines

 arch/arm/mach-socfpga/clock_manager.c |  12 +-
 arch/arm/mach-socfpga/clock_manager_arria10.c | 217 +
 arch/arm/mach-socfpga/clock_manager_gen5.c| 221 +-
 arch/arm/mach-socfpga/clock_manager_s10.c | 171 +++---
 .../mach-socfpga/include/mach/clock_manager.h |  15 ++
 .../include/mach/clock_manager_arria10.h  | 129 --
 .../include/mach/clock_manager_gen5.h | 108 -
 .../include/mach/clock_manager_s10.h  | 111 -
 .../mach-socfpga/include/mach/reset_manager.h |  12 +
 .../include/mach/reset_manager_arria10.h  |  41 +---
 .../include/mach/reset_manager_gen5.h |  20 +-
 .../include/mach/reset_manager_s10.h  |  33 +--
 .../include/mach/system_manager.h |  15 ++
 .../include/mach/system_manager_arria10.h |  92 ++--
 .../include/mach/system_manager_gen5.h| 121 ++
 .../include/mach/system_manager_s10.h | 184 ++-
 arch/arm/mach-socfpga/mailbox_s10.c   |   5 +-
 arch/arm/mach-socfpga/misc_arria10.c  |   7 +-
 arch/arm/mach-socfpga/misc_gen5.c |  22 +-
 arch/arm/mach-socfpga/misc_s10.c  |   8 +-
 arch/arm/mach-socfpga/reset_manager_arria10.c |  73 +++---
 arch/arm/mach-socfpga/reset_manager_gen5.c|  33 ++-
 arch/arm/mach-socfpga/reset_manager_s10.c |  52 ++---
 arch/arm/mach-socfpga/scan_manager.c  |   6 +-
 arch/arm/mach-socfpga/spl_a10.c   |   5 +-
 arch/arm/mach-socfpga/spl_gen5.c  |  15 +-
 arch/arm/mach-socfpga/spl_s10.c   |   9 +-
 arch/arm/mach-socfpga/system_manager_gen5.c   |  33 ++-
 arch/arm/mach-socfpga/system_manager_s10.c|  32 +--
 arch/arm/mach-socfpga/wrap_pll_config_s10.c   |  11 +-
 drivers/ddr/altera/sdram_gen5.c   |   9 +-
 drivers/ddr/altera/sdram_s10.c|   6 +-
 drivers/fpga/socfpga_arria10.c|   7 +-
 drivers/fpga/socfpga_gen5.c   |   4 +-
 drivers/mmc/socfpga_dw_mmc.c  |  15 +-
 drivers/sysreset/sysreset_socfpga.c   |   6 +-
 36 files changed, 754 insertions(+), 1106 deletions(-)

-- 
2.19.0

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


Re: [U-Boot] [PATCH] sunxi: H6: DRAM: Add support for half DQ

2019-08-19 Thread Jernej Škrabec
+CC: Thomas

Dne četrtek, 18. julij 2019 ob 00:16:17 CEST je Jernej Skrabec napisal(a):
> Half DQ configuration seems to be very rare for H6 based boards/STBs,
> but exists nevertheless. Currently the only known product which needs
> this support is Tanix TX6 mini.
> 
> This commit adds support for half DQ configuration. Code was tested
> for regressions on other configurations (OrangePi 3 1 GiB/LPDDR3, Tanix
> TX6 4 GiB/DDR3) and none were found.
> 
> Thanks to Icenowy Zheng for help with this code.
> 
> Signed-off-by: Jernej Skrabec 

Thomas, please test this.

Best regards,
Jernej

> ---
>  .../include/asm/arch-sunxi/dram_sun50i_h6.h   |  1 +
>  arch/arm/mach-sunxi/dram_sun50i_h6.c  | 74 ---
>  2 files changed, 50 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h index
> 0a1da02376..49a8a66f7b 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
> @@ -315,6 +315,7 @@ struct dram_para {
>   u8 cols;
>   u8 rows;
>   u8 ranks;
> + u8 bus_full_width;
>   const u8 dx_read_delays[NR_OF_BYTE_LANES][RD_LINES_PER_BYTE_LANE];
>   const u8 dx_write_delays[NR_OF_BYTE_LANES]
[WR_LINES_PER_BYTE_LANE];
>  };
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> b/arch/arm/mach-sunxi/dram_sun50i_h6.c index 2a8275da3a..0d65327d35 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
> @@ -201,6 +201,9 @@ static void mctl_set_addrmap(struct dram_para *para)
>   u8 rows = para->rows;
>   u8 ranks = para->ranks;
> 
> + if (!para->bus_full_width)
> + cols -= 1;
> +
>   /* Ranks */
>   if (ranks == 2)
>   mctl_ctl->addrmap[0] = rows + cols - 3;
> @@ -213,6 +216,10 @@ static void mctl_set_addrmap(struct dram_para *para)
>   /* Columns */
>   mctl_ctl->addrmap[2] = 0;
>   switch (cols) {
> + case 7:
> + mctl_ctl->addrmap[3] = 0x1F1F1F00;
> + mctl_ctl->addrmap[4] = 0x1F1F;
> + break;
>   case 8:
>   mctl_ctl->addrmap[3] = 0x1F1F;
>   mctl_ctl->addrmap[4] = 0x1F1F;
> @@ -300,13 +307,16 @@ static void mctl_com_init(struct dram_para *para)
>   reg_val = 0x3f00;
>   clrsetbits_le32(_com->unk_0x008, 0x3f00, reg_val);
> 
> - /* TODO: half DQ, DDR4 */
> - reg_val = MSTR_BUSWIDTH_FULL | MSTR_BURST_LENGTH(8) |
> -   MSTR_ACTIVE_RANKS(para->ranks);
> + /* TODO: DDR4 */
> + reg_val = MSTR_BURST_LENGTH(8) | MSTR_ACTIVE_RANKS(para->ranks);
>   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
>   reg_val |= MSTR_DEVICETYPE_LPDDR3;
>   if (para->type == SUNXI_DRAM_TYPE_DDR3)
>   reg_val |= MSTR_DEVICETYPE_DDR3 | MSTR_2TMODE;
> + if (para->bus_full_width)
> + reg_val |= MSTR_BUSWIDTH_FULL;
> + else
> + reg_val |= MSTR_BUSWIDTH_HALF;
>   writel(reg_val | BIT(31), _ctl->mstr);
> 
>   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
> @@ -333,7 +343,10 @@ static void mctl_com_init(struct dram_para *para)
>   }
>   writel(reg_val, _ctl->odtcfg);
> 
> - /* TODO: half DQ */
> + if (!para->bus_full_width) {
> + writel(0x0, _phy->dx[2].gcr[0]);
> + writel(0x0, _phy->dx[3].gcr[0]);
> + }
>  }
> 
>  static void mctl_bit_delay_set(struct dram_para *para)
> @@ -514,22 +527,31 @@ static void mctl_channel_init(struct dram_para *para)
> 
>   if (readl(_phy->pgsr[0]) & 0x40)
>   {
> - /*
> -  * Detect single rank.
> -  * TODO: also detect half DQ.
> -  */
> + /* Check for single rank and optionally half DQ. */
>   if ((readl(_phy->dx[0].rsr[0]) & 0x3) == 2 &&
> - (readl(_phy->dx[1].rsr[0]) & 0x3) == 2 &&
> - (readl(_phy->dx[2].rsr[0]) & 0x3) == 2 &&
> - (readl(_phy->dx[3].rsr[0]) & 0x3) == 2) {
> + (readl(_phy->dx[1].rsr[0]) & 0x3) == 2) {
>   para->ranks = 1;
> +
> + if ((readl(_phy->dx[2].rsr[0]) & 0x3) != 
2 ||
> + (readl(_phy->dx[3].rsr[0]) & 0x3) != 
2)
> + para->bus_full_width = 0;
> +
>   /* Restart DRAM initialization from scratch. 
*/
>   mctl_core_init(para);
>   return;
>   }
> - else {
> - panic("This DRAM setup is currently not 
supported.\n");
> +
> + /* Check for dual rank and half DQ */
> + if ((readl(_phy->dx[0].rsr[0]) & 0x3) == 0 &&
> + (readl(_phy->dx[1].rsr[0]) & 0x3) == 0) {
> + para->bus_full_width = 0;
> +
> + /* Restart DRAM initialization from scratch. 
*/
> + 

Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Kurt Miller
Hi Jagan,

On Mon, 2019-08-19 at 23:26 +0530, Jagan Teki wrote:
> Is your board running at 50MHz? (look like No).

No it is running at 800Mhz or 856MHz (see rkbin TPL output below).

> As I said please
> explore step-by-step
> 00: First boot the board rkbin => SPL => U-Boot proper

This step was completed already. Here is the output again for reference:

DDR Version 1.23 20190709
In   
channel 0
CS = 0   
MR0=0xB8 
MR4=0x1 
MR5=0xFF
MR8=0x10
MR12=0x72   
MR14=0x72   
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
OUT

> 01: Grab the sdram-*.dtsi (steps mentioned in previous mail) and
> replace rkbin withTPL

I am stuck here. I see that there were three 800Mhz entries
in the rkbin rk3399_ddr_800MHz_v1.20.bin file that was used to
create ./arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi.

rk3399-sdram-lpddr4-100.dtsi has one entry that appears to
be from the first 800Mhz data in rk3399_ddr_800MHz_v1.20.bin.

Using the instructions you linked:
https://wiki.amarulasolutions.com/found/target/rk3399_sdram.html

I have inspected rkbin rk3399_ddr_800MHz_v1.23.bin and found
there are two 800Mhz entries in it. I have extracted the two
entries but have have questions that the instructions don't
address well.

Why does the existing rk3399-sdram-lpddr4-100.dtsi only have
one entry while the instructions appear to indicate there
should be two, one for single and another for dual ranked?

Step 6 refers to editing the dtsi file:

"..., edit the initial values (don’t forget that they are in
little endian form) to match what the SPL code expects, 
convert the frequency value from the binary back into MHz
(line 38 in the attached dtsi files for reference)"

I believe I was able to convert the data into the updated
values correctly (see attached diff). However, one value
stood out to me. The 800Mhz value of 0x2faf0800 was converted
into decimal 50 in the existing data whereas other sdram files
converted it into 1/2 the Mhz value (e.g. 800Mhz -> 400).

With it set to 50 I get this output before it stops:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 18:45:16) 
pctl_start: Failed to init pctl for channel 0 

With it set to 400 I get this output before it stops:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 19:14:10)  
sdram_init: DDR3 - 400MHz failed!
rk3399_dmc_init DRAM init failed -22 
Missing DTB 

> 02: Then dump the regmap if 01 failed.
> 
> Jagan.

01 failed. With the timings diff reverted I get this before it freezes:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)  
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB  
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride 
cic: ctr10: (0xff62 - 0x14) 
cic: status0: (0xff620010 - 0x101)  
grf: ddrc0_con0 (0xff77e380 - 0x1f81)   
grf: ddrc1_con0 (0xff77e388 - 0x1f81)   
grf: soc_con0 (0xff77e200 - 0x7)
pmu: noc_auto_ena (0xff3100d8 - 0x0)
pmu: bus_idle_req (0xff310060 - 0x0)
pmu: bus_idle_st (0xff310064 - 0x0)
pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
pmugrf: os_reg3 (0xff32030c - 0x2005)
pmusgrf: soc_con4 (0xff33e010 - 0x2600)

Please let me know other items can be tried to get this up and
running with the U-Boot TPL.

Regards,
-Kurtdiff --git a/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi b/arch/arm/dts/rk3399-sdram-lpddr4-100.dtsi

Re: [U-Boot] [PATCH 1/1] efi_loader: re-enable GRUB workaround on 32bit ARM

2019-08-19 Thread Tom Rini
On Sun, Jul 28, 2019 at 10:13:24AM +0200, Heinrich Schuchardt wrote:
> On 7/27/19 11:58 AM, Alexander Graf wrote:
> >
> > On 27.07.19 10:02, Heinrich Schuchardt wrote:
> >> GRUB on ARM 32bit prior to version 2.04 lacks proper handling of caches.
> >> In U-Boot v2019.04 a workaround for this was inadvertently removed.
> >>
> >> The workaround is currently also needed for booting on systems with
> >> caches
> >> that cannot be managed via CP15 (e.g. with an i.MX6 CPU).
> >>
> >> Re-enable the workaround and make it customizable.
> >>
> >> Fixes: f69d63fae281 ("efi_loader: use efi_start_image() for bootefi")
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >>   lib/efi_loader/Kconfig    |  8 
> >>   lib/efi_loader/efi_boottime.c | 28 +---
> >>   2 files changed, 21 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> >> index a7f2c68fa9..c7027a9676 100644
> >> --- a/lib/efi_loader/Kconfig
> >> +++ b/lib/efi_loader/Kconfig
> >> @@ -107,4 +107,12 @@ config EFI_HAVE_RUNTIME_RESET
> >>   default y
> >>   depends on ARCH_BCM283X || FSL_LAYERSCAPE || PSCI_RESET ||
> >> SYSRESET_X86
> >>
> >> +config EFI_GRUB_ARM32_WORKAROUND
> >> +    bool "Workaround for GRUB on 32bit ARM"
> >> +    default y
> >> +    depends on ARM && !ARM64
> >> +    help
> >> +  GRUB prior to version 2.04 requires U-Boot to disable caches. This
> >> +  workaround currently is also needed on systems with caches that
> >> +  cannot be managed via CP15.
> >>   endif
> >> diff --git a/lib/efi_loader/efi_boottime.c
> >> b/lib/efi_loader/efi_boottime.c
> >> index 4f6e8d1679..f75ca1a67c 100644
> >> --- a/lib/efi_loader/efi_boottime.c
> >> +++ b/lib/efi_loader/efi_boottime.c
> >> @@ -39,14 +39,6 @@ LIST_HEAD(efi_register_notify_events);
> >>   /* Handle of the currently executing image */
> >>   static efi_handle_t current_image;
> >>
> >> -/*
> >> - * If we're running on nasty systems (32bit ARM booting into non-EFI
> >> Linux)
> >> - * we need to do trickery with caches. Since we don't want to break
> >> the EFI
> >> - * aware boot path, only apply hacks when loading exiting directly
> >> (breaking
> >> - * direct Linux EFI booting along the way - oh well).
> >> - */
> >> -static bool efi_is_direct_boot = true;
> >
> >
> > By removing the toggling, you now couple a U-Boot configuration variant
> > to a specific grub version. New grub versions will run Linux using the
> > EFI stub. So enabling CONFIG_EFI_GRUB_ARM32_WORKAROUND means only old
> > versions work, but new grub versions break.
> 
> No, the Wandboard boots fine with GRUB 2.04 and Linux 4.19.55. Do you
> have any negative test results?
> 
> >
> > We really should treat this like any other erratum and make it as
> > runtime detected as possible, so that we don't block people from making
> > forward progress towards a the "sane" boot path.
> 
> It is not possible to determine at runtime which assumptions a loaded
> EFI binary makes about the cache. Your original logic counting the
> number of StartImage() invocations cannot detect this. This is why I
> added a customizing option.
> 
> >
> > Btw, has there been any solution for the non-CP15 caches? They would
> > still be broken with this applied, as payloads can rely on CP15 caches
> > enabled (for unaligned accesses), but non-CP15 caches disabled, right?
> 
> No, this will need future work. With CONFIG_EFI_GRUB_ARM32_WORKAROUND=y
> all caches are disabled.
> 
> On i.MX6 CONFIG_SYS_L2CACHE_OFF=y selectively disables the non-CP15
> cache. So here CONFIG_EFI_GRUB_ARM32_WORKAROUND=n and
> CONFIG_SYS_L2CACHE_OFF=y result in compliance with the UEFI spec.

Where did all of this end up, in terms of what combinations of things do
/ don't work, on current master (or v2019.10-rc2) ?  Thanks all!

-- 
Tom


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


Re: [U-Boot] Pull request: u-boot-rockchip-20190819

2019-08-19 Thread Tom Rini
On Mon, Aug 19, 2019 at 08:19:22PM +0800, Kever Yang wrote:

> Hi Tom,
> 
> Please pull the rockchip update:
> - Add ROC-RK3399-PC board support
> - Move CONFIG_SPI_FLASH_GIGADEVICE and CONFIG_CMD_USB_MASS_STORAGE to Kconfig
> - using SYSRESET_POWER_OFF for poweroff
>   (Note that patch for rk8xx pmic is droped for it can not pass Travis build)
> - fix ofnode_get_name() assert
> 
> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/480
> 
> Thanks,
> - Kever
> 
> The following changes since commit 81fed78c0a59af0d5698b13608eb4d26be84f397:
> 
>   Merge tag 'efi-2019-10-rc3' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2019-08-17 10:31:25 
> -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/u-boot-rockchip-20190819
> 
> for you to fetch changes up to b8050511c6ee4ab60ef4248dff42aff187696249:
> 
>   sysreset: move stm32mp sysreset poweroff implementation to sysreset uclass 
> (2019-08-19 12:43:26 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Please pull u-boot-x86

2019-08-19 Thread Tom Rini
On Mon, Aug 19, 2019 at 09:07:00AM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This PR includes the following changes in x86:
> - QEMU build warning fix when CONFIG_DISTRO_DEFAULTS=n
> - Small fixes on x86 reST docs
> - Allow CBFS to be used in SPL
> - Remove x86 specific GD flags
> 
> The following changes since commit 81fed78c0a59af0d5698b13608eb4d26be84f397:
> 
>   Merge tag 'efi-2019-10-rc3' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2019-08-17
> 10:31:25 -0400)
> 
> are available in the git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-x86
> 
> for you to fetch changes up to d117f917bfd2ccf4eaf90bddfa256501a554b1a4:
> 
>   global_data: Remove comment of reserved arch-specific GD flags
> (2019-08-18 21:54:10 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [PATCH] doc: add full path to patman README

2019-08-19 Thread Ralph Siemsen
Make it a little easier to find the documentation.

Signed-off-by: Ralph Siemsen 
---

 doc/driver-model/spi-howto.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/driver-model/spi-howto.rst b/doc/driver-model/spi-howto.rst
index a538fdcb93..5540eb7d38 100644
--- a/doc/driver-model/spi-howto.rst
+++ b/doc/driver-model/spi-howto.rst
@@ -650,7 +650,7 @@ Prepare patches and send them to the mailing lists
 --
 
 You can use 'tools/patman/patman' to prepare, check and send patches for
-your work. See the README for details.
+your work. See tools/patman/README for details.
 
 A little note about SPI uclass features
 ---
-- 
2.17.1

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


[U-Boot] [RFC PATCH] net: designware: drop compatible altr, socfpga-stmmac

2019-08-19 Thread Ralph Siemsen
The same compatible = "altr,socfpga-stmmac" appears in both
drivers/net/designware.c and drivers/net/dwmac_socfgpa.c,
creating ambiguity in which driver will be bound.

For Intel/Altera SoC devices, dwmac_socfpga.c is the correct driver.
So drop the compatible string from designware.c.

Signed-off-by: Ralph Siemsen 
---
This compatible string also appears in: axs10x_mb.dtsi and hsdk.dts.
Maintainers of those boards have been copied, kindly review.

 drivers/net/designware.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index c4fe40b19a..145eeac45f 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -847,7 +847,6 @@ int designware_eth_ofdata_to_platdata(struct udevice *dev)
 
 static const struct udevice_id designware_eth_ids[] = {
{ .compatible = "allwinner,sun7i-a20-gmac" },
-   { .compatible = "altr,socfpga-stmmac" },
{ .compatible = "amlogic,meson6-dwmac" },
{ .compatible = "amlogic,meson-gx-dwmac" },
{ .compatible = "amlogic,meson-gxbb-dwmac" },
-- 
2.17.1

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


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Kurt Miller
On Mon, 2019-08-19 at 22:08 +0530, Jagan Teki wrote:
> On Mon, Aug 19, 2019 at 7:33 PM Kurt Miller  
> wrote:
> > 
> > 
> > On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > > 
> > > > 
> > > > 
> > > > From: Jagan Teki 
> > > > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > > > 
> > > > + Kever
> > > > 
> > > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller 
> > > >  wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > The Rockpro64_V2.1 2018-07-02 using master code base freezes
> > > > > with only the following output:
> > > > > 
> > > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 
> > > > > 22:31:31)
> > > > > 
> > > > > Whereas another board dated 2018-06-06 works and outputs the 
> > > > > following:
> > > > > 
> > > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 
> > > > > 22:31:31)
> > > > > Trying to boot from BOOTROM
> > > > > Returning to boot ROM...
> > > > > 
> > > > > U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 
> > > > > 22:31:31 +0200)
> > > > > 
> > > > > Both board have 4G RAM.
> > > > > 
> > > > > U-Boot was built by Mark Kettenis from master with only the
> > > > > baud rate changed for both tests. The 2018-07-02 board has different
> > > > > markings for the CPU and the RAM as follows:
> > > > > 
> > > > >  2018-06-06   2018-07-02
> > > > > CPU: RK3399   RK3399
> > > > >  SBETMF976 1652   SBETNM271 1826
> > > > > 
> > > > > RAM: PS006-075 BT PS052-053 BT
> > > > >  N1YJ 83RL
> > > > > 
> > > > > Please let me know if there is additional information needed to
> > > > > further diagnose the boot freeze.
> > > > Please use mainline, and with doc/README.rockchip instructions.
> > > This is mainline as of Aug 16.  I built the image for Kurt and it the
> > > same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my
> > > board.
> > > 
> > > > 
> > > > 
> > > > I'm able to boot with mainline tree.
> > > Sure I can believe that.  I believe your board from the same batch as
> > > mine.  I suspect that the DRAM used on Kurt's board may require
> > > slightly different timings.
> > > 
> > While my board (2018-07-02) freezes with Aug 16 mainline TPL,
> > it does boot ok with the rockchip-linux TPL with the following
> > output which may have some useful info:
> I think rockchip-linux doesn't have lddr4 code instead they rely on
> ddr bin, you can use same bin in Mainline w/o enabling TPL it would
> work like
> 
> rkbin => SPL => U-Boot proper
> 
> > 
> > 
> > DDR Version 1.23 20190709
> > In
> > channel 0
> > CS = 0
> > MR0=0xB8
> > MR4=0x1
> > MR5=0xFF
> > MR8=0x10
> > MR12=0x72
> > MR14=0x72
> > MR18=0x0
> > MR19=0x0
> > MR24=0x8
> > MR25=0x0
> > channel 1
> > CS = 0
> > MR0=0xB8
> > MR4=0x1
> > MR5=0xFF
> > MR8=0x10
> > MR12=0x72
> > MR14=0x72
> > MR18=0x0
> > MR19=0x0
> > MR24=0x8
> > MR25=0x0
> > channel 0 training pass!
> > channel 1 training pass!
> > change freq to 416MHz 0,1
> > Channel 0: LPDDR4,416MHz
> > Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
> > Channel 1: LPDDR4,416MHz
> > Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
> > 256B stride
> > channel 0
> > CS = 0
> > MR0=0xB8
> > MR4=0x1
> > MR5=0xFF
> > MR8=0x10
> > MR12=0x72
> > MR14=0x72
> > MR18=0x0
> > MR19=0x0
> > MR24=0x8
> > MR25=0x0
> > channel 1
> > CS = 0
> > MR0=0xB8
> > MR4=0x1
> > MR5=0xFF
> > MR8=0x10
> > MR12=0x72
> > MR14=0x72
> > MR18=0x0
> > MR19=0x0
> > MR24=0x8
> > MR25=0x0
> > channel 0 training pass!
> > channel 1 training pass!
> > channel 0, cs 0, advanced training done
> > channel 1, cs 0, advanced training done
> > change freq to 856MHz 1,0
> > ch 0 ddrconfig = 0x101, ddrsize = 0x40
> > ch 1 ddrconfig = 0x101, ddrsize = 0x40
> > pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
> > OUT
> Okay.
> 
> There are two possible areas to look here.
> 
> 1) sdram timings, like the one ie used via .dtsi
> Use the working ddr bin and identify the board working frequency
> and follow below instructions to get the sdram dtsi
> https://wiki.amarulasolutions.com/found/target/rk3399_sdram.html

Thank you. In the above output I saw this:

change freq to 856MHz 1,0

There is one entry in rk3399pro_ddr_800MHz_v1.23.bin for 856Mhz and
I was able to extract the DDR timings through step 4 in the provided
link. However from there the instructions don't appear to be correct
and I'm unsure how to get the timings formatted (step 5 and 6) and
added into the build.

Could you provide some additional guidance with these steps?

> 2) lpddr4 set rate sequence in driver, may not be a problem but only
> if 1) failed
> right now, the driver would start initializing the actual board
> frequency(50MHz on my board) and then it switches to 400MHz and 800MHz
> simultaneously to make the proper sequence work on each channel with
> associated training.

___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Jagan Teki
On Mon, Aug 19, 2019 at 10:37 PM Kurt Miller
 wrote:
>
> On Mon, 2019-08-19 at 22:11 +0530, Jagan Teki wrote:
> > On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller  
> > wrote:
> > >
> > >
> > > Hi Michael,
> > >
> > > On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> > > >
> > > > It's possible to dump the register after training in mainline uboot?
> > > I'm working on getting master to build now. How would I
> > > go about dumping the register after training?
> > It would be a bit hard, I tried below sequence at the end of
> > sdram_init (sorry for direct copy)
> >
> > printf("cic: ctr10: (0x%x - 0x%x)\n", >cic->cic_ctrl0,
> > readl(>cic->cic_ctrl0));
> > printf("cic: status0: (0x%x - 0x%x)\n",
> > >cic->cic_status0, readl(>cic->cic_status0));
> > printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
> > >grf->ddrc0_con0, readl(>grf->ddrc0_con0));
> > printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
> > >grf->ddrc1_con0, readl(>grf->ddrc1_con0));
> > printf("grf: soc_con0 (0x%x - 0x%x)\n", >grf->soc_con0,
> > readl(>grf->soc_con0));
> > printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
> > >pmu->pmu_noc_auto_ena, readl(>pmu->pmu_noc_auto_ena));
> > printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
> > >pmu->pmu_bus_idle_req, readl(>pmu->pmu_bus_idle_req));
> > printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
> > >pmu->pmu_bus_idle_st, readl(>pmu->pmu_bus_idle_st));
> > printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
> > >pmugrf->os_reg2, readl(>pmugrf->os_reg2));
> > printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
> > >pmugrf->os_reg3, readl(>pmugrf->os_reg3));
> > printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
> > >pmusgrf->soc_con4, readl(>pmusgrf->soc_con4));
>
> Thank you. I have built mainline with CONFIG_RAM_ROCKCHIP_DEBUG=y
> with your printf's above and it outputs the following before freezing:
>
> U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)
> LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
> LPDDR4, 50MHz
> BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
> 256B stride
> cic: ctr10: (0xff62 - 0x14)
> cic: status0: (0xff620010 - 0x101)
> grf: ddrc0_con0 (0xff77e380 - 0x1f81)
> grf: ddrc1_con0 (0xff77e388 - 0x1f81)
> grf: soc_con0 (0xff77e200 - 0x7)
> pmu: noc_auto_ena (0xff3100d8 - 0x0)
> pmu: bus_idle_req (0xff310060 - 0x0)
> pmu: bus_idle_st (0xff310064 - 0x0)
> pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
> pmugrf: os_reg3 (0xff32030c - 0x2005)
> pmusgrf: soc_con4 (0xff33e010 - 0x2600)
>
> Note that 'Size=1024MB' is incorrect. With 'rockchip-linux' TPL
> I see 'Size=2048MB'.

Is your board running at 50MHz? (look like No). As I said please
explore step-by-step
00: First boot the board rkbin => SPL => U-Boot proper
01: Grab the sdram-*.dtsi (steps mentioned in previous mail) and
replace rkbin withTPL
02: Then dump the regmap if 01 failed.

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


Re: [U-Boot] Travis test/py sandbox_spl test fail

2019-08-19 Thread Stephen Warren

On 8/18/19 7:01 PM, Kever Yang wrote:

Hi Simon, Stephen,

     Could you help to comment on my other mail, which patch cause this 
failure.


If you run "git bisect", you should be able to track down which patch 
introduced the problem.





Thanks,

- Kever

On 2019/8/14 下午11:49, Stephen Warren wrote:

On 8/13/19 8:06 PM, Kever Yang wrote:

Hi Stephen,

On 2019/8/14 上午4:54, Stephen Warren wrote:

On 8/13/19 3:39 AM, Simon Glass wrote:

+Stephen

Hi Kever,

On Tue, 13 Aug 2019 at 03:35, Kever Yang 
 wrote:


Hi Simon,

 I got fail in test/py sandbox_spl, and the log says:

E OSError: [Errno 5] Input/output error

I have no idea about what's wrong in source code, could you help

to take a look?

Travis job:

https://travis-ci.org/keveryang/u-boot/jobs/571125119


When I've seen this (ugly) error it is normally because U-Boot
crashed, e.g. with a segfault.


Yes, that's the typical reason. If you run test.py locally you'll be 
able to access the log file (which Travis doesn't save), which will 
likely give you more details about the crash, and/or you could 
attach gdb to the sandbox process to trap the problem too.


I got:

$ ./u-boot
bloblist_init() Existing bloblist not found: creating new bloblist
[1]    958 segmentation fault (core dumped)  ./u-boot

And no more logs, is there any other log file I can check?


There probably isn't any more log information beyond that. I think the 
next step would be to run U-Boot sandbox under gdb, reproduce the 
problem, and then debug it.





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


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Kurt Miller
On Mon, 2019-08-19 at 22:11 +0530, Jagan Teki wrote:
> On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller  
> wrote:
> > 
> > 
> > Hi Michael,
> > 
> > On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> > > 
> > > It's possible to dump the register after training in mainline uboot?
> > I'm working on getting master to build now. How would I
> > go about dumping the register after training?
> It would be a bit hard, I tried below sequence at the end of
> sdram_init (sorry for direct copy)
> 
> printf("cic: ctr10: (0x%x - 0x%x)\n", >cic->cic_ctrl0,
> readl(>cic->cic_ctrl0));
> printf("cic: status0: (0x%x - 0x%x)\n",
> >cic->cic_status0, readl(>cic->cic_status0));
> printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
> >grf->ddrc0_con0, readl(>grf->ddrc0_con0));
> printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
> >grf->ddrc1_con0, readl(>grf->ddrc1_con0));
> printf("grf: soc_con0 (0x%x - 0x%x)\n", >grf->soc_con0,
> readl(>grf->soc_con0));
> printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
> >pmu->pmu_noc_auto_ena, readl(>pmu->pmu_noc_auto_ena));
> printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
> >pmu->pmu_bus_idle_req, readl(>pmu->pmu_bus_idle_req));
> printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
> >pmu->pmu_bus_idle_st, readl(>pmu->pmu_bus_idle_st));
> printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
> >pmugrf->os_reg2, readl(>pmugrf->os_reg2));
> printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
> >pmugrf->os_reg3, readl(>pmugrf->os_reg3));
> printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
> >pmusgrf->soc_con4, readl(>pmusgrf->soc_con4));

Thank you. I have built mainline with CONFIG_RAM_ROCKCHIP_DEBUG=y
with your printf's above and it outputs the following before freezing:

U-Boot TPL 2019.10-rc2-00016-g81fed78c0a-dirty (Aug 19 2019 - 12:57:39)  
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB  
LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
256B stride 
cic: ctr10: (0xff62 - 0x14) 
cic: status0: (0xff620010 - 0x101)  
grf: ddrc0_con0 (0xff77e380 - 0x1f81)   
grf: ddrc1_con0 (0xff77e388 - 0x1f81)   
grf: soc_con0 (0xff77e200 - 0x7)
pmu: noc_auto_ena (0xff3100d8 - 0x0)
pmu: bus_idle_req (0xff310060 - 0x0)
pmu: bus_idle_st (0xff310064 - 0x0)
pmugrf: os_reg2 (0xff320308 - 0x32a1f2a1)
pmugrf: os_reg3 (0xff32030c - 0x2005)
pmusgrf: soc_con4 (0xff33e010 - 0x2600)

Note that 'Size=1024MB' is incorrect. With 'rockchip-linux' TPL
I see 'Size=2048MB'.

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


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Jagan Teki
On Mon, Aug 19, 2019 at 8:42 PM Kurt Miller  wrote:
>
> Hi Michael,
>
> On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> > It's possible to dump the register after training in mainline uboot?
>
> I'm working on getting master to build now. How would I
> go about dumping the register after training?

It would be a bit hard, I tried below sequence at the end of
sdram_init (sorry for direct copy)

printf("cic: ctr10: (0x%x - 0x%x)\n", >cic->cic_ctrl0,
readl(>cic->cic_ctrl0));
printf("cic: status0: (0x%x - 0x%x)\n",
>cic->cic_status0, readl(>cic->cic_status0));
printf("grf: ddrc0_con0 (0x%x - 0x%x)\n",
>grf->ddrc0_con0, readl(>grf->ddrc0_con0));
printf("grf: ddrc1_con0 (0x%x - 0x%x)\n",
>grf->ddrc1_con0, readl(>grf->ddrc1_con0));
printf("grf: soc_con0 (0x%x - 0x%x)\n", >grf->soc_con0,
readl(>grf->soc_con0));
printf("pmu: noc_auto_ena (0x%x - 0x%x)\n",
>pmu->pmu_noc_auto_ena, readl(>pmu->pmu_noc_auto_ena));
printf("pmu: bus_idle_req (0x%x - 0x%x)\n",
>pmu->pmu_bus_idle_req, readl(>pmu->pmu_bus_idle_req));
printf("pmu: bus_idle_st (0x%x - 0x%x)\n",
>pmu->pmu_bus_idle_st, readl(>pmu->pmu_bus_idle_st));
printf("pmugrf: os_reg2 (0x%x - 0x%x)\n",
>pmugrf->os_reg2, readl(>pmugrf->os_reg2));
printf("pmugrf: os_reg3 (0x%x - 0x%x)\n",
>pmugrf->os_reg3, readl(>pmugrf->os_reg3));
printf("pmusgrf: soc_con4 (0x%x - 0x%x)\n",
>pmusgrf->soc_con4, readl(>pmusgrf->soc_con4));
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Jagan Teki
On Mon, Aug 19, 2019 at 7:33 PM Kurt Miller  wrote:
>
> On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > >
> > > From: Jagan Teki 
> > > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > >
> > > + Kever
> > >
> > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller  
> > > wrote:
> > > >
> > > >
> > > > Hello,
> > > >
> > > > The Rockpro64_V2.1 2018-07-02 using master code base freezes
> > > > with only the following output:
> > > >
> > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > >
> > > > Whereas another board dated 2018-06-06 works and outputs the following:
> > > >
> > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > > Trying to boot from BOOTROM
> > > > Returning to boot ROM...
> > > >
> > > > U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31 
> > > > +0200)
> > > >
> > > > Both board have 4G RAM.
> > > >
> > > > U-Boot was built by Mark Kettenis from master with only the
> > > > baud rate changed for both tests. The 2018-07-02 board has different
> > > > markings for the CPU and the RAM as follows:
> > > >
> > > >  2018-06-06   2018-07-02
> > > > CPU: RK3399   RK3399
> > > >  SBETMF976 1652   SBETNM271 1826
> > > >
> > > > RAM: PS006-075 BT PS052-053 BT
> > > >  N1YJ 83RL
> > > >
> > > > Please let me know if there is additional information needed to
> > > > further diagnose the boot freeze.
> > > Please use mainline, and with doc/README.rockchip instructions.
> > This is mainline as of Aug 16.  I built the image for Kurt and it the
> > same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my
> > board.
> >
> > >
> > > I'm able to boot with mainline tree.
> > Sure I can believe that.  I believe your board from the same batch as
> > mine.  I suspect that the DRAM used on Kurt's board may require
> > slightly different timings.
> >
>
> While my board (2018-07-02) freezes with Aug 16 mainline TPL,
> it does boot ok with the rockchip-linux TPL with the following
> output which may have some useful info:

I think rockchip-linux doesn't have lddr4 code instead they rely on
ddr bin, you can use same bin in Mainline w/o enabling TPL it would
work like

rkbin => SPL => U-Boot proper

>
> DDR Version 1.23 20190709
> In
> channel 0
> CS = 0
> MR0=0xB8
> MR4=0x1
> MR5=0xFF
> MR8=0x10
> MR12=0x72
> MR14=0x72
> MR18=0x0
> MR19=0x0
> MR24=0x8
> MR25=0x0
> channel 1
> CS = 0
> MR0=0xB8
> MR4=0x1
> MR5=0xFF
> MR8=0x10
> MR12=0x72
> MR14=0x72
> MR18=0x0
> MR19=0x0
> MR24=0x8
> MR25=0x0
> channel 0 training pass!
> channel 1 training pass!
> change freq to 416MHz 0,1
> Channel 0: LPDDR4,416MHz
> Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
> Channel 1: LPDDR4,416MHz
> Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
> 256B stride
> channel 0
> CS = 0
> MR0=0xB8
> MR4=0x1
> MR5=0xFF
> MR8=0x10
> MR12=0x72
> MR14=0x72
> MR18=0x0
> MR19=0x0
> MR24=0x8
> MR25=0x0
> channel 1
> CS = 0
> MR0=0xB8
> MR4=0x1
> MR5=0xFF
> MR8=0x10
> MR12=0x72
> MR14=0x72
> MR18=0x0
> MR19=0x0
> MR24=0x8
> MR25=0x0
> channel 0 training pass!
> channel 1 training pass!
> channel 0, cs 0, advanced training done
> channel 1, cs 0, advanced training done
> change freq to 856MHz 1,0
> ch 0 ddrconfig = 0x101, ddrsize = 0x40
> ch 1 ddrconfig = 0x101, ddrsize = 0x40
> pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
> OUT

Okay.

There are two possible areas to look here.

1) sdram timings, like the one ie used via .dtsi
Use the working ddr bin and identify the board working frequency
and follow below instructions to get the sdram dtsi
https://wiki.amarulasolutions.com/found/target/rk3399_sdram.html

2) lpddr4 set rate sequence in driver, may not be a problem but only
if 1) failed
right now, the driver would start initializing the actual board
frequency(50MHz on my board) and then it switches to 400MHz and 800MHz
simultaneously to make the proper sequence work on each channel with
associated training.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Jagan Teki
On Mon, Aug 19, 2019 at 7:01 PM Mark Kettenis  wrote:
>
> > From: Jagan Teki 
> > Date: Mon, 19 Aug 2019 00:21:40 +0530
> >
> > + Kever
> >
> > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller  
> > wrote:
> > >
> > > Hello,
> > >
> > > The Rockpro64_V2.1 2018-07-02 using master code base freezes
> > > with only the following output:
> > >
> > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > >
> > > Whereas another board dated 2018-06-06 works and outputs the following:
> > >
> > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > Trying to boot from BOOTROM
> > > Returning to boot ROM...
> > >
> > > U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31 
> > > +0200)
> > >
> > > Both board have 4G RAM.
> > >
> > > U-Boot was built by Mark Kettenis from master with only the
> > > baud rate changed for both tests. The 2018-07-02 board has different
> > > markings for the CPU and the RAM as follows:
> > >
> > >  2018-06-06   2018-07-02
> > > CPU: RK3399   RK3399
> > >  SBETMF976 1652   SBETNM271 1826
> > >
> > > RAM: PS006-075 BT PS052-053 BT
> > >  N1YJ 83RL
> > >
> > > Please let me know if there is additional information needed to
> > > further diagnose the boot freeze.
> >
> > Please use mainline, and with doc/README.rockchip instructions.
>
> This is mainline as of Aug 16.  I built the image for Kurt and it the
> same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my
> board.
>
> > I'm able to boot with mainline tree.
>
> Sure I can believe that.  I believe your board from the same batch as
> mine.  I suspect that the DRAM used on Kurt's board may require
> slightly different timings.

Yes, this can be the cause. Thanks for pointing this.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] libavb: Fix build warnings after updating the lib

2019-08-19 Thread Tom Rini
On Mon, Aug 19, 2019 at 10:28:41AM +0200, Eugeniu Rosca wrote:
> Hi all,
> 
> On Fri, Aug 16, 2019 at 11:46:03AM -0400, David Zeuthen wrote:
> >Hi,
> >As for upstreaming libavb patches, I'd be interested in landing them
> >upstream... makes it easier for anyone.
> >Our upstream is AOSP and we use gerrit for
> >code-review: 
> > https://android-review.googlesource.com/q/project:platform%252Fexternal%252Favb
> >Here's a guide to
> >contributing: https://source.android.com/setup/contribute/submit-patches 
> > ...
> >hope it's not too painful to use the AOSP process!
> >Thanks,
> >David
> 
> David, thanks for being open about discussing/accepting the fixes.
> 
> U-Boot folks,
> 
> What's your opinion w.r.t. the right/best order between accepting
> the libavb fixes locally in U-Boot and pushing them to upstream?
> Which should come first? I suppose they can be first applied internally
> and replaced later on if they get reworked/optimized during upstreaming.

I think we certainly need to submit the changes upstream first, and then
keep our changes in-sync with any feedback we get from upstream.  This
is just like how we handle DTS changes too.

-- 
Tom


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


Re: [U-Boot] [PATCH 4/4] rockchip: dts: rk3328-rock64: fix usb power supply

2019-08-19 Thread Matwey V. Kornilov
чт, 15 авг. 2019 г. в 11:14, Kever Yang :
>
> According to rock64 schemetic, both VCC_HOST1_5V and VCC_HOST_5V are
> controlled by USB20_HOST_DRV(GPIO0A2), fix it so that we can get correct
> power supply for USB HOST ports.
>
> Signed-off-by: Kever Yang 

Tested-by: Matwey V. Kornilov 

> ---
>
>  arch/arm/dts/rk3328-rock64.dts | 23 ++-
>  1 file changed, 2 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/dts/rk3328-rock64.dts b/arch/arm/dts/rk3328-rock64.dts
> index 7bcc53fcce..a78eb4ac6f 100644
> --- a/arch/arm/dts/rk3328-rock64.dts
> +++ b/arch/arm/dts/rk3328-rock64.dts
> @@ -34,23 +34,10 @@
>
> vcc_host_5v: vcc-host-5v-regulator {
> compatible = "regulator-fixed";
> -   enable-active-high;
> -   gpio = < RK_PA0 GPIO_ACTIVE_HIGH>;
> -   pinctrl-names = "default";
> -   pinctrl-0 = <_host_drv>;
> -   regulator-name = "vcc_host_5v";
> -   regulator-always-on;
> -   regulator-boot-on;
> -   vin-supply = <_sys>;
> -   };
> -
> -   vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
> -   compatible = "regulator-fixed";
> -   enable-active-high;
> -   gpio = < RK_PA2 GPIO_ACTIVE_HIGH>;
> +   gpio = < RK_PA2 GPIO_ACTIVE_LOW>;
> pinctrl-names = "default";
> pinctrl-0 = <_host_drv>;
> -   regulator-name = "vcc_host1_5v";
> +   regulator-name = "vcc_host_5v";
> regulator-always-on;
> regulator-boot-on;
> vin-supply = <_sys>;
> @@ -244,12 +231,6 @@
> rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO 
> _pull_none>;
> };
> };
> -
> -   usb3 {
> -   usb30_host_drv: usb30-host-drv {
> -   rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO 
> _pull_none>;
> -   };
> -   };
>  };
>
>   {
> --
> 2.17.1
>


-- 
With best regards,
Matwey V. Kornilov
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 3/4] rockchip: rk3328: migrate u-boot node to -u-boot.dtsi

2019-08-19 Thread Matwey V. Kornilov
чт, 15 авг. 2019 г. в 11:14, Kever Yang :
>
> Move all the nodes only shown in u-boot to -u-boot.dtsi to make
> rk3328.dtsi clean.
>
> Signed-off-by: Kever Yang 

Tested-by: Matwey V. Kornilov 

> ---
>
>  arch/arm/dts/rk3328-evb-u-boot.dtsi| 31 +++---
>  arch/arm/dts/rk3328-evb.dts|  5 ---
>  arch/arm/dts/rk3328-rock64-u-boot.dtsi | 33 ++-
>  arch/arm/dts/rk3328-u-boot.dtsi| 58 ++
>  arch/arm/dts/rk3328.dtsi   | 24 ---
>  5 files changed, 66 insertions(+), 85 deletions(-)
>  create mode 100644 arch/arm/dts/rk3328-u-boot.dtsi
>
> diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
> b/arch/arm/dts/rk3328-evb-u-boot.dtsi
> index 58ebf52b4b..4a827063c5 100644
> --- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
> @@ -1,33 +1,12 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> + * (C) Copyright 2016-2019 Rockchip Electronics Co., Ltd
>   */
>
> +#include "rk3328-u-boot.dtsi"
>  #include "rk3328-sdram-ddr3-666.dtsi"
>
> -/ {
> -   aliases {
> -   mmc0 = 
> -   mmc1 = 
> -   };
> -
> -   chosen {
> -   u-boot,spl-boot-order = , 
> -   };
> -};
> -
> - {
> -   u-boot,dm-pre-reloc;
> -};
> -
> - {
> -   u-boot,dm-pre-reloc;
> -};
> -
> - {
> -   u-boot,dm-pre-reloc;
> -};
> -
> - {
> -   u-boot,dm-pre-reloc;
> +_host0_xhci {
> +   vbus-supply = <_host_xhci>;
> +   status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
> index ec594a8452..a2ee838fcd 100644
> --- a/arch/arm/dts/rk3328-evb.dts
> +++ b/arch/arm/dts/rk3328-evb.dts
> @@ -116,11 +116,6 @@
> status = "okay";
>  };
>
> -_host0_xhci {
> -   vbus-supply = <_host_xhci>;
> -   status = "okay";
> -};
> -
>   {
> clock-frequency = <40>;
> i2c-scl-rising-time-ns = <168>;
> diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi 
> b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> index 21c2afca3c..1d441f7124 100644
> --- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> @@ -1,38 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+
>  /*
> - * (C) Copyright 2018 Rockchip Electronics Co., Ltd
> - *
> - * SPDX-License-Identifier: GPL-2.0+
> + * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
>   */
>
> +#include "rk3328-u-boot.dtsi"
>  #include "rk3328-sdram-lpddr3-1600.dtsi"
>
> -/ {
> -   aliases {
> -   mmc0 = 
> -   mmc1 = 
> -   };
> -
> -   chosen {
> -   u-boot,spl-boot-order = , 
> -   };
> -};
> -
> - {
> -   u-boot,dm-pre-reloc;
> -};
> -
> - {
> -   u-boot,dm-pre-reloc;
> -};
> -
> - {
> -   u-boot,dm-pre-reloc;
> -};
> -
> - {
> -   u-boot,dm-pre-reloc;
> -};
> -
>  _host0_xhci {
> status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
> new file mode 100644
> index 00..ffbd657e31
> --- /dev/null
> +++ b/arch/arm/dts/rk3328-u-boot.dtsi
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019 Rockchip Electronics Co., Ltd
> + */
> +
> +/ {
> +   aliases {
> +   mmc0 = 
> +   mmc1 = 
> +   };
> +
> +   chosen {
> +   u-boot,spl-boot-order = , 
> +   };
> +
> +   dmc: dmc {
> +   u-boot,dm-pre-reloc;
> +   compatible = "rockchip,rk3328-dmc";
> +   reg = <0x0 0xff40 0x0 0x1000
> +  0x0 0xff78 0x0 0x3000
> +  0x0 0xff10 0x0 0x1000
> +  0x0 0xff44 0x0 0x1000
> +  0x0 0xff72 0x0 0x1000
> +  0x0 0xff798000 0x0 0x1000>;
> +   };
> +
> +   usb_host0_xhci: usb@ff60 {
> +   compatible = "rockchip,rk3328-xhci";
> +   reg = <0x0 0xff60 0x0 0x10>;
> +   interrupts = ;
> +   snps,dis-enblslpm-quirk;
> +   snps,phyif-utmi-bits = <16>;
> +   snps,dis-u2-freeclk-exists-quirk;
> +   snps,dis-u2-susphy-quirk;
> +   status = "disabled";
> +   };
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +   clock-frequency = <2400>;
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +};
> +
> + {
> +   u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
> index a080ae8d69..060c84e6c0 100644
> --- a/arch/arm/dts/rk3328.dtsi
> +++ b/arch/arm/dts/rk3328.dtsi
> @@ -186,7 +186,6 @@
> };
>
> grf: syscon@ff10 {
> -   u-boot,dm-pre-reloc;
> compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> reg = <0x0 0xff10 0x0 0x1000>;
>

[U-Boot] [PATCH] board: fsl: lx2160aqds: fix 'compatible' property

2019-08-19 Thread Florin Chiculita
The code that generates the compatible property concatenates the
ethernet phy id and clause-compatible information without
separating them with a comma, therefore no ethernet phy driver will
be loaded by Linux kernel.

Signed-off-by: Florin Chiculita 
---
 board/freescale/lx2160a/eth_lx2160aqds.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/freescale/lx2160a/eth_lx2160aqds.c 
b/board/freescale/lx2160a/eth_lx2160aqds.c
index f6e22d7..e8e4dd8 100644
--- a/board/freescale/lx2160a/eth_lx2160aqds.c
+++ b/board/freescale/lx2160a/eth_lx2160aqds.c
@@ -685,7 +685,7 @@ int fdt_create_phy_node(void *fdt, int offset, u8 phyaddr, 
int *subnodeoffset,
struct phy_device *phy_dev, int phandle)
 {
char phy_node_name[] = "ethernet-phy@00";
-   char phy_id_compatible_str[] = "ethernet-phy-id.";
+   char phy_id_compatible_str[] = "ethernet-phy-id.,";
int ret;
 
sprintf(phy_node_name, "ethernet-phy@%x", phyaddr);
@@ -699,7 +699,7 @@ int fdt_create_phy_node(void *fdt, int offset, u8 phyaddr, 
int *subnodeoffset,
return *subnodeoffset;
}
 
-   sprintf(phy_id_compatible_str, "ethernet-phy-id%04x.%04x",
+   sprintf(phy_id_compatible_str, "ethernet-phy-id%04x.%04x,",
phy_dev->phy_id >> 16, phy_dev->phy_id & 0x);
debug("phy_id_compatible_str %s\n", phy_id_compatible_str);
 
-- 
1.9.3

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


Re: [U-Boot] [PATCH 2/4] rockchip: dts: rk3328-rock64: enable usb3 xhci controller

2019-08-19 Thread Matwey V. Kornilov
чт, 15 авг. 2019 г. в 11:14, Kever Yang :
>
> Rock64 has a USB3.0 port, enable the controller so that we can use it.
>
> Signed-off-by: Kever Yang 

Tested-by: Matwey V. Kornilov 

> ---
>
>  arch/arm/dts/rk3328-rock64-u-boot.dtsi | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi 
> b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> index dbcce6ac64..21c2afca3c 100644
> --- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> @@ -32,3 +32,7 @@
>   {
> u-boot,dm-pre-reloc;
>  };
> +
> +_host0_xhci {
> +   status = "okay";
> +};
> --
> 2.17.1
>


-- 
With best regards,
Matwey V. Kornilov
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] rockchip: dts: rk3328-rock64: enable usb3 xhci controller

2019-08-19 Thread Matwey V. Kornilov
пн, 19 авг. 2019 г. в 03:35, Kever Yang :
>
> Hi Matwey,
>
> On 2019/8/17 下午10:15, Matwey V. Kornilov wrote:
> > Hi Kever,
> >
> > I've just tested the series on my Rock64 and I see the following
> > issue. An USB pen-drive is not discovered by `usb start' when attached
> > to the USB3 (blue) port.
>
>
> The USB3 is not working correctly by the default code, and it works
> after I enable some debug
>
> option in xHCI, maybe some more delay is needed for XHCI? I have no idea
> for which part of the xHCI
>
> driver is not work correct now.

Ok, now it is clear.

>
>
> Thanks,
>
> - Kever
>
> > Attaching to USB2 port works fine.
> >
> > чт, 15 авг. 2019 г. в 11:14, Kever Yang :
> >> Rock64 has a USB3.0 port, enable the controller so that we can use it.
> >>
> >> Signed-off-by: Kever Yang 
> >> ---
> >>
> >>   arch/arm/dts/rk3328-rock64-u-boot.dtsi | 4 
> >>   1 file changed, 4 insertions(+)
> >>
> >> diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi 
> >> b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> >> index dbcce6ac64..21c2afca3c 100644
> >> --- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> >> +++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
> >> @@ -32,3 +32,7 @@
> >>{
> >>  u-boot,dm-pre-reloc;
> >>   };
> >> +
> >> +_host0_xhci {
> >> +   status = "okay";
> >> +};
> >> --
> >> 2.17.1
> >>
> >
>
>


-- 
With best regards,
Matwey V. Kornilov
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] test/py: Add cmd_memory dependency back to test_mmc_wr

2019-08-19 Thread Stephen Warren

On 8/19/19 3:06 AM, Michal Simek wrote:

Based on discussion with Stephen Warren there was recommendation to list
both memory and random command dependencies just in case that dependency is
not properly handled by Kconfig.


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


Re: [U-Boot] [PATCH v2 2/3] spl: mmc: Add option to set eMMC HW boot partition

2019-08-19 Thread Andreas Dannenberg
On Mon, Aug 19, 2019 at 09:42:09AM +0200, Lukasz Majewski wrote:
> From: Mans Rullgard 
> 
> This change allows setting pre-defined eMMC boot partition for SPL eMMC
> booting. It is necessary in the case when one wants to boot (through falcon
> boot) from eMMC after loading SPL from other memory (like SPI-NOR).
> 
> Signed-off-by: Mans Rullgard 
> [lukma: Edit the commit message]
> Signed-off-by: Lukasz Majewski 


Acked-by: Andreas Dannenberg 

Regards, Andreas

 
> ---
> 
> Changes in v2: None
> 
>  common/spl/Kconfig   | 6 ++
>  common/spl/spl_mmc.c | 4 
>  2 files changed, 10 insertions(+)
> 
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 0a3877ec28..4fe4a1359c 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -293,6 +293,12 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
> Address on the MMC to load U-Boot from, when the MMC is being used
> in raw mode. Units: MMC sectors (1 sector = 512 bytes).
>  
> +config SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
> + int "Number of the eMMC boot partition to use"
> + default 1
> + help
> +   eMMC boot partition number to use when the eMMC in raw mode.
> +
>  config SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
>   bool "MMC Raw mode: by partition"
>   help
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index 2caceb5186..a4d2e63b82 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -334,6 +334,9 @@ int spl_mmc_load(struct spl_image_info *spl_image,
>   err = -EINVAL;
>   switch (boot_mode) {
>   case MMCSD_MODE_EMMCBOOT:
> +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
> + part = CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION;
> +#else
>   /*
>* We need to check what the partition is configured to.
>* 1 and 2 match up to boot0 / boot1 and 7 is user data
> @@ -343,6 +346,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
>  
>   if (part == 7)
>   part = 0;
> +#endif
>  
>   if (CONFIG_IS_ENABLED(MMC_TINY))
>   err = mmc_switch_part(mmc, part);
> -- 
> 2.11.0
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Kurt Miller
Hi Michael,

On Mon, 2019-08-19 at 16:06 +0200, Michael Nazzareno Trimarchi wrote:
> It's possible to dump the register after training in mainline uboot?

I'm working on getting master to build now. How would I
go about dumping the register after training?

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


Re: [U-Boot] [PATCH 1/1] easylogo: avoid buffer overrun

2019-08-19 Thread Tom Rini
On Fri, Aug 16, 2019 at 12:11:57AM +0200, Heinrich Schuchardt wrote:
> On 8/15/19 11:54 PM, Heinrich Schuchardt wrote:
> >Building easylogo with `HOST_TOOLS_ALL=y make tools` results in a build
> >warning due to a possible buffer overrun:
> >
> >tools/easylogo/easylogo.c:453:4: note: ‘sprintf’ output between 7 and
> >262 bytes into a destination of size 256
> > sprintf (str, "%s, 0x%02x", app, *dataptr++);
> > ^~~~
> >
> >Truncate the output to fit into the destination buffer.
> >
> >Signed-off-by: Heinrich Schuchardt 
> 
> Could we change .travis.yml and .gitlab-ci.yml to build all tools?

Don't see why not, once they'd be green again.  Follow up patch if
that's the only problem, v2 of the series if you find more things to
correct.  Thanks!

-- 
Tom


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


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Michael Nazzareno Trimarchi
Hi Kurt

On Mon, Aug 19, 2019 at 4:04 PM Kurt Miller  wrote:
>
> On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > >
> > > From: Jagan Teki 
> > > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > >
> > > + Kever
> > >
> > > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller  
> > > wrote:
> > > >
> > > >
> > > > Hello,
> > > >
> > > > The Rockpro64_V2.1 2018-07-02 using master code base freezes
> > > > with only the following output:
> > > >
> > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > >
> > > > Whereas another board dated 2018-06-06 works and outputs the following:
> > > >
> > > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > > Trying to boot from BOOTROM
> > > > Returning to boot ROM...
> > > >
> > > > U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31 
> > > > +0200)
> > > >
> > > > Both board have 4G RAM.
> > > >
> > > > U-Boot was built by Mark Kettenis from master with only the
> > > > baud rate changed for both tests. The 2018-07-02 board has different
> > > > markings for the CPU and the RAM as follows:
> > > >
> > > >  2018-06-06   2018-07-02
> > > > CPU: RK3399   RK3399
> > > >  SBETMF976 1652   SBETNM271 1826
> > > >
> > > > RAM: PS006-075 BT PS052-053 BT
> > > >  N1YJ 83RL
> > > >
> > > > Please let me know if there is additional information needed to
> > > > further diagnose the boot freeze.
> > > Please use mainline, and with doc/README.rockchip instructions.
> > This is mainline as of Aug 16.  I built the image for Kurt and it the
> > same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my
> > board.
> >
> > >
> > > I'm able to boot with mainline tree.
> > Sure I can believe that.  I believe your board from the same batch as
> > mine.  I suspect that the DRAM used on Kurt's board may require
> > slightly different timings.
> >
>
> While my board (2018-07-02) freezes with Aug 16 mainline TPL,
> it does boot ok with the rockchip-linux TPL with the following
> output which may have some useful info:
>
> DDR Version 1.23 20190709
> In
> channel 0
> CS = 0
> MR0=0xB8
> MR4=0x1
> MR5=0xFF
> MR8=0x10
> MR12=0x72
> MR14=0x72
> MR18=0x0
> MR19=0x0
> MR24=0x8
> MR25=0x0
> channel 1
> CS = 0
> MR0=0xB8
> MR4=0x1
> MR5=0xFF
> MR8=0x10
> MR12=0x72
> MR14=0x72
> MR18=0x0
> MR19=0x0
> MR24=0x8
> MR25=0x0
> channel 0 training pass!
> channel 1 training pass!
> change freq to 416MHz 0,1
> Channel 0: LPDDR4,416MHz
> Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
> Channel 1: LPDDR4,416MHz
> Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
> 256B stride
> channel 0
> CS = 0
> MR0=0xB8
> MR4=0x1
> MR5=0xFF
> MR8=0x10
> MR12=0x72
> MR14=0x72
> MR18=0x0
> MR19=0x0
> MR24=0x8
> MR25=0x0
> channel 1
> CS = 0
> MR0=0xB8
> MR4=0x1
> MR5=0xFF
> MR8=0x10
> MR12=0x72
> MR14=0x72
> MR18=0x0
> MR19=0x0
> MR24=0x8
> MR25=0x0
> channel 0 training pass!
> channel 1 training pass!
> channel 0, cs 0, advanced training done
> channel 1, cs 0, advanced training done
> change freq to 856MHz 1,0
> ch 0 ddrconfig = 0x101, ddrsize = 0x40
> ch 1 ddrconfig = 0x101, ddrsize = 0x40
> pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
> OUT

It's possible to dump the register after training in mainline uboot?

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



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Kurt Miller
On Mon, 2019-08-19 at 15:31 +0200, Mark Kettenis wrote:
> > 
> > From: Jagan Teki 
> > Date: Mon, 19 Aug 2019 00:21:40 +0530
> > 
> > + Kever
> > 
> > On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller  
> > wrote:
> > > 
> > > 
> > > Hello,
> > > 
> > > The Rockpro64_V2.1 2018-07-02 using master code base freezes
> > > with only the following output:
> > > 
> > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > 
> > > Whereas another board dated 2018-06-06 works and outputs the following:
> > > 
> > > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > > Trying to boot from BOOTROM
> > > Returning to boot ROM...
> > > 
> > > U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31 
> > > +0200)
> > > 
> > > Both board have 4G RAM.
> > > 
> > > U-Boot was built by Mark Kettenis from master with only the
> > > baud rate changed for both tests. The 2018-07-02 board has different
> > > markings for the CPU and the RAM as follows:
> > > 
> > >  2018-06-06   2018-07-02
> > > CPU: RK3399   RK3399
> > >  SBETMF976 1652   SBETNM271 1826
> > > 
> > > RAM: PS006-075 BT PS052-053 BT
> > >  N1YJ 83RL
> > > 
> > > Please let me know if there is additional information needed to
> > > further diagnose the boot freeze.
> > Please use mainline, and with doc/README.rockchip instructions.
> This is mainline as of Aug 16.  I built the image for Kurt and it the
> same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my
> board.
> 
> > 
> > I'm able to boot with mainline tree.
> Sure I can believe that.  I believe your board from the same batch as
> mine.  I suspect that the DRAM used on Kurt's board may require
> slightly different timings.
> 

While my board (2018-07-02) freezes with Aug 16 mainline TPL,
it does boot ok with the rockchip-linux TPL with the following
output which may have some useful info:

DDR Version 1.23 20190709
In   
channel 0
CS = 0   
MR0=0xB8 
MR4=0x1 
MR5=0xFF
MR8=0x10
MR12=0x72   
MR14=0x72   
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0xB8
MR4=0x1
MR5=0xFF
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
OUT
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 0/1] i.MX8QM ROM 7720 a1 board won't boot

2019-08-19 Thread Oliver Graute
On 16/08/19, Oliver Graute wrote:
> I'am currently working on the following patch to get the imx8qm-rom7720-a1
> board working with recent u-boot v2019.07. Unfortunaly I get no output on my
> serial line.
> 
> I'am not sure if something in my patch is just missing or if my composition of
> "SCFW + ATF + uboot" which is necessary for this imx8qm board, is not working
> the right way.
> 
> Perhaps somebody can guide me in the right direction to debug this further.
> 
> Currently I'am applying the patch and building u-boot this way:
> 
> $ export ATF_LOAD_ADDR=0x8000
> $ export BL33_LOAD_ADDR=0x8002
> $ make imx8qm_rom7720_a1_4G_defconfig
> $ make flash.bin
> $ dd if=u-boot.itb of=flash.bin bs=512 seek=854
> $ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync
> 
> Then I put the SD card into the board and power it on. But no output ony my
> serial line.

ok I got this working by using the u-boot.bin

$ make u-boot.bin

and put it into the imx-mkimage repo from here:

https://source.codeaurora.org/external/imx/imx-mkimage

to create the full bootstream with scfw + atf + u-boot.

I thought that I could create the full bootsteam directly in u-boot repo
with:

> $ make flash.bin

as seen for other imx8 boards. Perhaps that is possible too but I don't
got it working that way.

U-Boot 2019.07-1-g5854ff8d0e (Aug 19 2019 - 11:12:49 +0200)

CPU:   NXP i.MX8QM RevB A53 at 1200 MHz

Model: Advantech iMX8QM Qseven series
Board: ROM-7720-A1 4GB
Build: SCFW 65afe5f6
Boot:  SD2
DRAM:  3.9 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 2
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial@5a06
Out:   serial@5a06
Err:   serial@5a06
Net:
Error: ethernet@5b04 address not set.
eth-1: ethernet@5b04
Error: ethernet@5b04 address not set.
Can't find FEC0 clk rate: -22
Could not get PHY for FEC1: addr 1
, eth-1: ethernet@5b05
Hit any key to stop autoboot:  0

Best regards,

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


Re: [U-Boot] imx: add i.MX8MQ EVK support

2019-08-19 Thread Jacky Bai
> Sent: Monday, August 19, 2019 2:25 PM
> To: Troy Kisky ; Fabio Estevam
> ; Stefano Babic ;
> u-boot@lists.denx.de; Jacky Bai 
> Subject: RE: imx: add i.MX8MQ EVK support
> 
> Loop Jacky who has more knowledge in the ddr stuff.
> 
> > Subject: re: imx: add i.MX8MQ EVK support
> >
> > Hi Peng
> >
> > In spl.c you have
> >
> > _
> > static void spl_dram_init(void)
> > {
> > /* ddr init */
> > if ((get_cpu_rev() & 0xfff) == CHIP_REV_2_1)
> > ddr_init(_timing);
> > else
> > ddr_init(_timing_b0);
> > }
> >
> > _
> >
> > Could you explain why this is dependent on chip rev ?

It is due an errata in DDR PHY, for chip Rev lower than 2.1, set point < 667mts 
can NOT be supported

> >
> > It it just the extra frequency in lpddr4_timing.c ?
> >
> > __
> > {
> > /* P1 100mts 1D */
> > .drate = 100,
> > .fw_type = FW_1D_IMAGE,
> > .fsp_cfg = lpddr4_fsp2_cfg,
> > .fsp_cfg_num = ARRAY_SIZE(lpddr4_fsp2_cfg),
> > },
> > _
> >
> >
> > Will other i.MX8MQ boards also need this check ?
> >

For most of the customer board, I think the chip Rev is 2.1, so no need such 
check.

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


[U-Boot] [PATCH v4 1/4] USB: gadget: Add the cadence USB3 gadget driver

2019-08-19 Thread Sherry Sun
This driver is ported from NXP i.MX U-Boot version imx_v2019.04
and some changes have also been made to adapt to U-Boot.

Add the Cadence USB3 IP(CDNS3) driver for the gadget (device mode).
The CDNS3 gadget driver support DM mode. CONFIG_DM_USB_GADGET should
be enabled when use this driver.

Signed-off-by: Sherry Sun 
---
 Makefile   |1 +
 doc/device-tree-bindings/usb/cdns-usb3.txt |   39 +
 drivers/usb/Kconfig|2 +
 drivers/usb/cdns3/Kconfig  |   20 +
 drivers/usb/cdns3/Makefile |5 +
 drivers/usb/cdns3/cdns3-generic.c  |  113 +
 drivers/usb/cdns3/cdns3-nxp-reg-def.h  |   93 +
 drivers/usb/cdns3/core.c   |  203 ++
 drivers/usb/cdns3/core.h   |  118 ++
 drivers/usb/cdns3/dev-regs-macro.h |  116 +
 drivers/usb/cdns3/dev-regs-map.h   |  117 ++
 drivers/usb/cdns3/gadget-export.h  |   26 +
 drivers/usb/cdns3/gadget.c | 2218 
 drivers/usb/cdns3/gadget.h |  225 ++
 drivers/usb/cdns3/io.h |   30 +
 drivers/usb/gadget/epautoconf.c|4 +
 drivers/usb/gadget/gadget_chips.h  |7 +
 drivers/usb/gadget/udc/Makefile|1 +
 include/linux/usb/gadget.h |3 +
 scripts/Makefile.spl   |1 +
 20 files changed, 3342 insertions(+)
 create mode 100644 doc/device-tree-bindings/usb/cdns-usb3.txt
 create mode 100644 drivers/usb/cdns3/Kconfig
 create mode 100644 drivers/usb/cdns3/Makefile
 create mode 100644 drivers/usb/cdns3/cdns3-generic.c
 create mode 100644 drivers/usb/cdns3/cdns3-nxp-reg-def.h
 create mode 100644 drivers/usb/cdns3/core.c
 create mode 100644 drivers/usb/cdns3/core.h
 create mode 100644 drivers/usb/cdns3/dev-regs-macro.h
 create mode 100644 drivers/usb/cdns3/dev-regs-map.h
 create mode 100644 drivers/usb/cdns3/gadget-export.h
 create mode 100644 drivers/usb/cdns3/gadget.c
 create mode 100644 drivers/usb/cdns3/gadget.h
 create mode 100644 drivers/usb/cdns3/io.h

diff --git a/Makefile b/Makefile
index 8513db94e3..fab1220114 100644
--- a/Makefile
+++ b/Makefile
@@ -728,6 +728,7 @@ libs-$(CONFIG_SYS_FSL_DDR) += drivers/ddr/fsl/
 libs-$(CONFIG_SYS_FSL_MMDC) += drivers/ddr/fsl/
 libs-$(CONFIG_$(SPL_)ALTERA_SDRAM) += drivers/ddr/altera/
 libs-y += drivers/serial/
+libs-y += drivers/usb/cdns3/
 libs-y += drivers/usb/dwc3/
 libs-y += drivers/usb/common/
 libs-y += drivers/usb/emul/
diff --git a/doc/device-tree-bindings/usb/cdns-usb3.txt 
b/doc/device-tree-bindings/usb/cdns-usb3.txt
new file mode 100644
index 00..0c8710507d
--- /dev/null
+++ b/doc/device-tree-bindings/usb/cdns-usb3.txt
@@ -0,0 +1,39 @@
+* Cadence USB3 Controller
+
+Required properties:
+- compatible: "cdns,usb3";
+- reg: base address and length of the registers
+- interrupts: interrupt for the USB controller
+- interrupt-parent: the interrupt parent for this module
+- clocks: reference to the USB clock
+- clock-names: the name of clocks
+- phys: reference to the USB PHY
+
+Optional properties:
+- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
+- extcon: extcon phandler for cdns3 device
+- power-domains: the power domain for cdns3 controller and phy
+
+Examples:
+
+usbotg3: cdns3@5b11 {
+   compatible = "cdns,usb3";
+   reg = <0x0 0x5B11 0x0 0x1>,
+   <0x0 0x5B13 0x0 0x1>,
+   <0x0 0x5B14 0x0 0x1>,
+   <0x0 0x5B16 0x0 0x4>;
+   interrupt-parent = <>;
+   interrupts = ;
+   clocks = < IMX8QM_USB3_LPM_CLK>,
+   < IMX8QM_USB3_BUS_CLK>,
+   < IMX8QM_USB3_ACLK>,
+   < IMX8QM_USB3_IPG_CLK>,
+   < IMX8QM_USB3_CORE_PCLK>;
+   clock-names = "usb3_lpm_clk", "usb3_bus_clk", "usb3_aclk",
+   "usb3_ipg_clk", "usb3_core_pclk";
+   power-domains = <_conn_usb2>;
+   phys = <>;
+   dr_mode = "otg";
+   extcon = <_ptn5150>;
+   status = "disabled";
+};
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 3b53bf2c58..98f5e936e5 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -70,6 +70,8 @@ source "drivers/usb/host/Kconfig"
 
 source "drivers/usb/dwc3/Kconfig"
 
+source "drivers/usb/cdns3/Kconfig"
+
 source "drivers/usb/musb/Kconfig"
 
 source "drivers/usb/musb-new/Kconfig"
diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
new file mode 100644
index 00..11a7144b05
--- /dev/null
+++ b/drivers/usb/cdns3/Kconfig
@@ -0,0 +1,20 @@
+config USB_CDNS3
+   tristate "Cadence USB3 Dual-Role Controller"
+depends on (USB && USB_GADGET)
+   help
+ Say Y here if your system has a cadence USB3 dual-role controller.
+ It supports: dual-role switch Host-only, and Peripheral-only.
+
+ When compiled dynamically, the module will be called cdns3.ko.
+
+if USB_CDNS3
+
+config USB_CDNS3_GADGET
+   bool 

Re: [U-Boot] [PATCH 0/1] i.MX8QM ROM 7720 a1 board won't boot

2019-08-19 Thread Oliver Graute
On 19/08/19, Peng Fan wrote:
> > Subject: Re: [PATCH 0/1] i.MX8QM ROM 7720 a1 board won't boot
> > 
> > On 16/08/19, Marcel Ziswiler wrote:
> > > Hi Oliver
> > >
> > > On Fri, 2019-08-16 at 12:43 +, Oliver Graute wrote:
> > > > I'am currently working on the following patch to get the imx8qm-
> > > > rom7720-a1
> > >
> > > That version sounds suspiciously like it may be based on initial alpha
> > > silicon from NXP which as far as I know is not supported anywhere any
> > > more. Not even in downstream.
> > >
> > > If it has alpha silicon my suggestion is to throw it away and move on.
> > >
> > > > board working with recent u-boot v2019.07.
> > >
> > > v2019.07 has long since been released. So what you are talking about
> > > would be any future release like v2020.01 as even the v2019.10 merge
> > > window long since closed.
> > >
> > > > Unfortunaly I get no output on my
> > > > serial line.
> > >
> > > Alpha chips came with different boot ROM requiring completely
> > > different SCFW as far as I know.
> > 
> > I have to correct myself. After some investigation I can say that I have the
> > B-Silicium of imx8qm on this board. So should I rename everything from a1 to
> > b1?
> 
> Check scfw uart to see whether there is any output from scu uart.
> Make sure you using and adapt scfw to your board.

ok, there is no output on scu uart. So its broken before u-boot launch.

With nxp vendor boostream (scfw + atf + u-boot-imx) I see some output
and a little cmd line. So I have to check the stuff before u-boot first.

Best Regards,

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


Re: [U-Boot] Rockpro64_V2.1 2018-07-02 Boot Freeze

2019-08-19 Thread Mark Kettenis
> From: Jagan Teki 
> Date: Mon, 19 Aug 2019 00:21:40 +0530
> 
> + Kever
> 
> On Sun, Aug 18, 2019 at 1:21 AM Kurt Miller  
> wrote:
> >
> > Hello,
> >
> > The Rockpro64_V2.1 2018-07-02 using master code base freezes
> > with only the following output:
> >
> > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> >
> > Whereas another board dated 2018-06-06 works and outputs the following:
> >
> > U-Boot TPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31)
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > U-Boot SPL 2019.10-rc2-1-gdf33f86468-dirty (Aug 16 2019 - 22:31:31 
> > +0200)
> >
> > Both board have 4G RAM.
> >
> > U-Boot was built by Mark Kettenis from master with only the
> > baud rate changed for both tests. The 2018-07-02 board has different
> > markings for the CPU and the RAM as follows:
> >
> >  2018-06-06   2018-07-02
> > CPU: RK3399   RK3399
> >  SBETMF976 1652   SBETNM271 1826
> >
> > RAM: PS006-075 BT PS052-053 BT
> >  N1YJ 83RL
> >
> > Please let me know if there is additional information needed to
> > further diagnose the boot freeze.
> 
> Please use mainline, and with doc/README.rockchip instructions.

This is mainline as of Aug 16.  I built the image for Kurt and it the
same binaries (one for TPL+SPL one for U-Boot+ATF) works fine on my
board.

> I'm able to boot with mainline tree.

Sure I can believe that.  I believe your board from the same batch as
mine.  I suspect that the DRAM used on Kurt's board may require
slightly different timings.

> U-Boot TPL 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17)
> Trying to boot from BOOTROM
> Returning to boot ROM...
> 
> U-Boot SPL 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17 +0530)
> Trying to boot from MMC1
> 
> 
> U-Boot 2019.10-rc2-00016-g81fed78c0a (Aug 19 2019 - 00:17:17 +0530)
> 
> Model: Pine64 RockPro64
> DRAM:  3.9 GiB
> MMC:   dwmmc@fe32: 1, sdhci@fe33: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default 
> environment
> 
> In:serial@ff1a
> Out:   serial@ff1a
> Err:   serial@ff1a
> Model: Pine64 RockPro64
> rockchip_dnl_key_pressed: adc_channel_single_shot fail!
> Net:
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH V2] ARM: dts: imx6q-logicpd: Add missing imx6q-logicpd-u-boot for SPL

2019-08-19 Thread Adam Ford
On Wed, Aug 7, 2019 at 10:16 AM Adam Ford  wrote:
>
> The SPL device tree is missing the entires for gpio1, uart1, usdhc1 and
> usdhc2.  This creates the missing imx6q-logicpd-u-boot.dtsi file
> which will enable these functions so SPL can properly setup UART, detect
> microSD card, and startup.
>

Stefano / Tom,

Is there any way we can pull this in for the next RC candidate?
Without this patch, the imx6_logic boards are broken because I forgot
to include this file in my original patch when I enabled
SPL_OF_CONTROL.
 We can disregard the original patch for this V2 if helps clean up the
to-do list in patchwork.

thank you,

adam

> Fixes: 8f4691e31a18 ("ARM: imx6q_logic: With SPL_OF_CONTROL enabled,
> remove MMC init")
>
> Signed-off-by: Adam Ford 
> ---
> V2:  Update MAINTAINER
>  Remove unnecessary empty node.
>  Update subject to reflect this was missing to imply it should have been 
> there before.
>
> diff --git a/arch/arm/dts/imx6q-logicpd-u-boot.dtsi 
> b/arch/arm/dts/imx6q-logicpd-u-boot.dtsi
> new file mode 100644
> index 00..625bed8f7d
> --- /dev/null
> +++ b/arch/arm/dts/imx6q-logicpd-u-boot.dtsi
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Logic PD 
> + */
> +
> +#include "imx6qdl-u-boot.dtsi"
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> +
> + {
> +   u-boot,dm-spl;
> +};
> diff --git a/board/logicpd/imx6/MAINTAINERS b/board/logicpd/imx6/MAINTAINERS
> index 20ec5918e4..4280315269 100644
> --- a/board/logicpd/imx6/MAINTAINERS
> +++ b/board/logicpd/imx6/MAINTAINERS
> @@ -7,3 +7,4 @@ F: configs/imx6q_logic_defconfig
>  F: arch/arm/dts/imx6-logicpd-baseboard.dtsi
>  F: arch/arm/dts/imx6-logicpd-som.dtsi
>  F: arch/arm/dts/imx6q-logicpd.dts
> +F: arch/arm/dts/imx6q-logicpd-u-boot.dtsi
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Question about GPL v3 font

2019-08-19 Thread Tom Rini
On Mon, Aug 19, 2019 at 01:34:06PM +0900, Masahiro Yamada wrote:
> On Fri, Aug 16, 2019 at 2:13 AM Tom Rini  wrote:
> >
> > On Tue, Aug 13, 2019 at 03:34:20AM -0600, Simon Glass wrote:
> > > Hi,
> > >
> > > On Fri, 26 Jul 2019 at 11:07, Tom Rini  wrote:
> > > >
> > > > On Fri, Jul 26, 2019 at 06:42:47PM +0900, Masahiro Yamada wrote:
> > > >
> > > > > Hi.
> > > > >
> > > > > According to the Kconfig entry,
> > > > > drivers/video/fonts/nimbus_sans_l_regular.ttf
> > > > > is licensed under GPL v3.
> > > > >
> > > > > How the license is handled when U-Boot is compiled with
> > > > > CONFIG_CONSOLE_TRUETYPE_NIMBUS=y ?
> > > > >
> > > > > I am asking this since many companies, I guess,
> > > > > have GPL-v3 allergy.
> > > > >
> > > > >
> > > > > config CONSOLE_TRUETYPE_NIMBUS
> > > > > bool "Nimbus Sans Regular"
> > > > > depends on CONSOLE_TRUETYPE
> > > > > default y
> > > > > help
> > > > >   Nimbus Sans L is a version of Nimbus Sans using Adobe font 
> > > > > sources.
> > > > >   It was designed in 1987. A subset of Nimbus Sans L were 
> > > > > released
> > > > >   under the GPL. Although the characters are not exactly the 
> > > > > same,
> > > > >   Nimbus Sans L has metrics almost identical to Helvetica and 
> > > > > Arial.
> > > > >   (From Wikipedia, the free encyclopedia)
> > > > >   From: https://fontlibrary.org/en/font/nimbus-sans-l
> > > > >   License: GNU GPL v3
> > > > >   http://www.gnu.org/copyleft/gpl.html
> > > >
> > > > It's a good question.  I suspect the answer is that we should drop that
> > > > font as I don't know if you can combine "GPLv2 only" and "GPLv2 or
> > > > later" with "GPLv3".
> > >
> > > Yes, agreed. Can we find another similar font?
> 
> Is it important to have a *similar* font?
> 
> We have 3 more fonts in drivers/video/fonts/,
> so they should be functional at least.
> 
> The license incompatibility is a more fatal problem.
> So, we should drop this font as soon as possible.
> 
> When _we_ find nice fonts, we can add them later.
> It is desirable, but not important.

Agreed.  Simon, do you want me to remove it, or do you want to send a
patch to remove it?  Thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT

2019-08-19 Thread Marek Vasut
On 6/4/19 9:06 AM, Vagrant Cascadian wrote:
> On 2019-05-17, Marek Vasut wrote:
>> Update Kosagi Novena to DM / DT and remove the warnings.
>> This depends on the following patches / series:
>>
>>   https://patchwork.ozlabs.org/patch/1095618/
>>   https://patchwork.ozlabs.org/patch/1101171/
> 
> These are now merged in 2019.07-rc3.
> 
>>   https://patchwork.ozlabs.org/project/uboot/list/?series=108463
> 
> These were not yet.
> 
> I have two oustanding issues... with some files it sometimes fails to
> load one or more from SATA:
> 
> Retrieving file: /boot/initrd.img-5.0.0-trunk-armmp
> 20077960 bytes read in 375 ms (51.1 MiB/s)
> Retrieving file: /boot/vmlinuz-5.0.0-trunk-armmp
> 4215296 bytes read in 40 ms (100.5 MiB/s)
> append: root=UUID=9666ab0b-f932-4e2f-95d7-0e96a12a4540 ro quiet
> Retrieving file: /usr/lib/linux-image-5.0.0-trunk-armmp/imx6q-novena.dtb
> CACHE: Misaligned operation at range [fafb5398, fafb6398]
> CACHE: Misaligned operation at range [fafb5398, fafb6398]
> ERROR: v7_outer_cache_inval_range - start address is not aligned -
> 0xfafb5398
> ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> 0xfafb6398
> invalid extent block
> 
> It then falls back to one of the other kernels (using the extlinux.conf
> parsing) and succeeds. It consistantly gets a cache/alignment error with
> this specific file. A bit-for-bit identical .dtb loaded from another
> path works just fine. Older versions of u-boot boot this fine. Would
> some particular EXT4 flag possibly be causing issues?

I don't know. Do you still run into this with u-boot/master ?

> Several other kernel+initrd+dtb combinations work fine.
> 
> I have not noticed issues loading from PXE.
> 
> 
> The second issue is still using one out of four exposed USB ports fails
> and resets the board:
> 
> load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image
> data abort
> pc : []  lr : []
> reloc pc : [<1783367a>]lr : [<178330fd>]
> sp : faf7c6e8  ip : 0003 fp : 0005
> r10: faf8b200  r9 : faf87ea0 r8 : 0001
> r7 : faf8b2c0  r6 : f9f7a040 r5 : faf7c710  r4 : 0038
> r3 : 006d  r2 : f9f7a0a3 r1 : faf8b32c  r0 : f9f7a09f
> Flags: nzCv  IRQs off  FIQs off  Mode SVC_32
> Code: 4630fc5b 81f0e8bd e7d84606 bf082b2f (f822235c)
> Resetting CPU ...
> 
> The three other usb ports work just fine with the same USB stick and
> file. All four ports work with 2019.01.

Can you debug it ? I think some of this was due to the EFI stuff , which
I think was fixed since. Can you re-check that ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v0] rockchip: rk3399: Add ROC-RK3399-PC support【请注意,邮件由u-boot-boun...@lists.denx.de代发】

2019-08-19 Thread Kever Yang


On 2019/8/12 下午12:31, Kever Yang wrote:

Hi Levin,

On 2019/7/26 下午3:43, d...@t-chip.com.cn wrote:

From: Levin Du 

Add initial support for ROC-RK3399-PC board.

Specification
- Rockchip RK3399
- LPDDR4 4GiB
- eMMC slot
- SD card slot
- RTL8211E 1Gbps
- HDMI Out, DP, MIPI DSI/CSI, EDP
- PCIe M.2
- USB 2.0, USB-3.0
- USB C Type

Commit details of rk3399-roc-pc.dts sync from Linux v5.2:
"arm64: dts: rockchip: add support for ROC-RK3399-PC board"
(sha1: 8bb878cf20ae10809c36db96993bfce7026d062b)

Signed-off-by: Levin Du 



Reviewed-by: Kever Yang 



Applied to u-boot-rockchip.

Thank,
- Kever



Thanks,

- Kever



---

  arch/arm/dts/Makefile  |   1 +
  arch/arm/dts/rk3399-roc-pc-u-boot.dtsi |  18 +
  arch/arm/dts/rk3399-roc-pc.dts | 680 +
  board/rockchip/evb_rk3399/MAINTAINERS  |   6 +
  configs/roc-rk3399-pc_defconfig    |  61 +++
  5 files changed, 766 insertions(+)
  create mode 100644 arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3399-roc-pc.dts
  create mode 100644 configs/roc-rk3399-pc_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f5535078c720..547f609e63b0 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -115,6 +115,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
  rk3399-puma-ddr1333.dtb \
  rk3399-puma-ddr1600.dtb \
  rk3399-puma-ddr1866.dtb \
+    rk3399-roc-pc.dtb \
  rk3399-rock-pi-4.dtb \
  rk3399-rock960.dtb \
  rk3399-rockpro64.dtb
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi 
b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi

new file mode 100644
index ..77d5cf5d3cd6
--- /dev/null
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Levin Du 
+ */
+
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
+
+/ {
+    chosen {
+    u-boot,spl-boot-order = "same-as-spl", , 
+    };
+};
+
+_log {
+    regulator-min-microvolt = <43>;
+    regulator-init-microvolt = <95>;
+};
diff --git a/arch/arm/dts/rk3399-roc-pc.dts 
b/arch/arm/dts/rk3399-roc-pc.dts

new file mode 100644
index ..19f7732d728c
--- /dev/null
+++ b/arch/arm/dts/rk3399-roc-pc.dts
@@ -0,0 +1,680 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+    model = "Firefly ROC-RK3399-PC Board";
+    compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
+
+    chosen {
+    stdout-path = "serial2:150n8";
+    };
+
+    backlight: backlight {
+    compatible = "pwm-backlight";
+    pwms = < 0 25000 0>;
+    };
+
+    clkin_gmac: external-gmac-clock {
+    compatible = "fixed-clock";
+    clock-frequency = <12500>;
+    clock-output-names = "clkin_gmac";
+    #clock-cells = <0>;
+    };
+
+    sdio_pwrseq: sdio-pwrseq {
+    compatible = "mmc-pwrseq-simple";
+    clocks = < 1>;
+    clock-names = "ext_clock";
+    pinctrl-names = "default";
+    pinctrl-0 = <_enable_h>;
+
+    /*
+ * On the module itself this is one of these (depending
+ * on the actual card populated):
+ * - SDIO_RESET_L_WL_REG_ON
+ * - PDN (power down when low)
+ */
+    reset-gpios = < RK_PB2 GPIO_ACTIVE_LOW>;
+    };
+
+    vcc_vbus_typec0: vcc-vbus-typec0 {
+    compatible = "regulator-fixed";
+    regulator-name = "vcc_vbus_typec0";
+    regulator-always-on;
+    regulator-boot-on;
+    regulator-min-microvolt = <500>;
+    regulator-max-microvolt = <500>;
+    };
+
+    /*
+ * should be placed inside mp8859, but not until mp8859 has
+ * its own dt-binding.
+ */
+    vcc12v_sys: mp8859-dcdc1 {
+    compatible = "regulator-fixed";
+    regulator-name = "vcc12v_sys";
+    regulator-always-on;
+    regulator-boot-on;
+    regulator-min-microvolt = <1200>;
+    regulator-max-microvolt = <1200>;
+    vin-supply = <_vbus_typec0>;
+    };
+
+    /* switched by pmic_sleep */
+    vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+    compatible = "regulator-fixed";
+    regulator-name = "vcc1v8_s3";
+    regulator-always-on;
+    regulator-boot-on;
+    regulator-min-microvolt = <180>;
+    regulator-max-microvolt = <180>;
+    vin-supply = <_1v8>;
+    };
+
+    vcc3v3_sys: vcc3v3-sys {
+    compatible = "regulator-fixed";
+    regulator-name = "vcc3v3_sys";
+    regulator-always-on;
+    regulator-boot-on;
+    regulator-min-microvolt = <330>;
+    regulator-max-microvolt = <330>;
+    vin-supply = <_sys>;
+    };
+
+    /* Actually 3 regulators (host0, 1, 2) controlled by the same 
gpio */

+    vcc5v0_host: vcc5v0-host-regulator {
+    compatible = "regulator-fixed";
+    enable-active-high;
+    gpio = 

Re: [U-Boot] [PATCH] core: ofnode: do not assert if node not valid in ofnode_get_name()【请注意,邮件由s...@google.com代发】

2019-08-19 Thread Kever Yang


On 2019/7/25 上午3:48, Simon Glass wrote:

On Thu, 18 Jul 2019 at 20:24, Kever Yang  wrote:

In some case with LIVE DT, some node always not valid, or not have
a valid name, eg. blk driver add by mmc.
Return fail instead of Assert for this kind of ofnode, and this
help with assert happen from time to time when of_live is enabled
and DEBUG is enabled.

Signed-off-by: Kever Yang 
---

  drivers/core/ofnode.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

Reviewed-by: Simon Glass 


Applied to u-boot-rockchip.

Thank,
- Kever





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


[U-Boot] Pull request: u-boot-rockchip-20190819

2019-08-19 Thread Kever Yang
Hi Tom,

Please pull the rockchip update:
- Add ROC-RK3399-PC board support
- Move CONFIG_SPI_FLASH_GIGADEVICE and CONFIG_CMD_USB_MASS_STORAGE to Kconfig
- using SYSRESET_POWER_OFF for poweroff
  (Note that patch for rk8xx pmic is droped for it can not pass Travis build)
- fix ofnode_get_name() assert

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

Thanks,
- Kever

The following changes since commit 81fed78c0a59af0d5698b13608eb4d26be84f397:

  Merge tag 'efi-2019-10-rc3' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2019-08-17 10:31:25 -0400)

are available in the Git repository at:

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

for you to fetch changes up to b8050511c6ee4ab60ef4248dff42aff187696249:

  sysreset: move stm32mp sysreset poweroff implementation to sysreset uclass 
(2019-08-19 12:43:26 +0800)


Kever Yang (1):
  core: ofnode: do not assert if node not valid in ofnode_get_name()

Levin Du (1):
  rockchip: rk3399: Add ROC-RK3399-PC support

Urja Rannikko (5):
  configs: Move CONFIG_SPI_FLASH_GIGADEVICE properly into Kconfig
  configs: Move CONFIG_CMD_USB_MASS_STORAGE properly into Kconfig
  configs: update rk3288 veyron defconfigs
  sysreset: switch to using SYSRESET_POWER_OFF for poweroff
  sysreset: move stm32mp sysreset poweroff implementation to sysreset uclass

 arch/Kconfig   |   1 +
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/rk3399-roc-pc-u-boot.dtsi |  18 +
 arch/arm/dts/rk3399-roc-pc.dts | 680 +
 arch/arm/mach-stm32mp/Makefile |   3 -
 arch/arm/mach-stm32mp/cmd_poweroff.c   |  24 --
 arch/sandbox/cpu/state.c   |   1 -
 board/rockchip/evb_rk3399/MAINTAINERS  |   6 +
 configs/chromebit_mickey_defconfig |  27 +-
 configs/chromebook_jerry_defconfig |  27 +-
 configs/chromebook_minnie_defconfig|  27 +-
 configs/chromebook_speedy_defconfig|  27 +-
 configs/evb-rk3036_defconfig   |   3 +-
 configs/evb-rk3229_defconfig   |   1 +
 configs/evb-rk3288_defconfig   |   2 +-
 configs/fennec-rk3288_defconfig|   2 +-
 configs/firefly-rk3288_defconfig   |   2 +-
 configs/kylin-rk3036_defconfig |   3 +-
 configs/miqi-rk3288_defconfig  |   2 +-
 configs/phycore-rk3288_defconfig   |   2 +-
 configs/popmetal-rk3288_defconfig  |   2 +-
 configs/roc-rk3399-pc_defconfig|  61 +++
 configs/rock2_defconfig|   2 +-
 configs/tinker-rk3288_defconfig|   2 +-
 drivers/core/ofnode.c  |   6 +-
 drivers/power/pmic/Kconfig |   1 +
 drivers/sysreset/Kconfig   |  10 +
 drivers/sysreset/sysreset-uclass.c |  18 +
 drivers/sysreset/sysreset_psci.c   |   2 +-
 drivers/sysreset/sysreset_sandbox.c|   4 +-
 include/configs/rk3036_common.h|   7 -
 include/configs/rk322x_common.h|   5 -
 include/configs/rk3288_common.h|   5 -
 include/configs/veyron.h   |   2 -
 include/configs/vyasa-rk3288.h |   1 -
 35 files changed, 883 insertions(+), 104 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-roc-pc.dts
 delete mode 100644 arch/arm/mach-stm32mp/cmd_poweroff.c
 create mode 100644 configs/roc-rk3399-pc_defconfig
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 0/4] Make some changes to SDP

2019-08-19 Thread Sherry Sun
Hi Angus,

I have just finished the SDP test on imx8mq_evk and the SDP can work with some 
board configs.
I guess it may be two problems that lead your SDP can't work on imx8mq_evk. You 
can add
the follow two changes and test it again.

The first change:
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -262,6 +262,7 @@ struct usb_ep *usb_ep_autoconfig(
ep = find_ep(gadget, "ep1-bulk");
if (ep && ep_matches(gadget, ep, desc))
return ep;
+#ifndef CONFIG_SPL_BUILD
} else if (gadget_is_dwc3(gadget)) {
const char *name = NULL;
/*
@@ -284,6 +285,7 @@ struct usb_ep *usb_ep_autoconfig(
ep = find_ep(gadget, name);
if (ep && ep_matches(gadget, ep, desc))
return ep;
+#endif
}

The second change:
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -55,6 +55,13 @@ void enable_tzc380(void)
/* Enable TZASC and lock setting */
setbits_le32(>gpr[10], GPR_TZASC_EN);
setbits_le32(>gpr[10], GPR_TZASC_EN_LOCK);
+
+   /*
+* set Region 0 attribute to allow secure and non-secure read/write 
permission
+* Found some masters like usb dwc3 controllers can't work with secure 
memory.
+*/
+   writel(0xf000, TZASC_BASE_ADDR + 0x108);
+
}

If there is anything you don’t understand, you can also get my test patches at
https://github.com/sherrysun1/u-boot-imx.git. You just need check the first 
four patches  which I
used to test for imx8mq_evk.

And feel free to let me know if any problems.

Best regards
Sherry sun



Hi Sherry,

On Aug. 8, 2019 2:38 a.m., Sherry Sun 
mailto:sherry@nxp.com>> wrote:

Hi Angus,

Sorry for the late reply.

>
> Hi Peng,
>
> On 2019-08-01 18:01, Peng Fan wrote:
> > Angus,
> >
> >> Subject: Re: 答复: [U-Boot] [PATCH 0/4] Make some changes to SDP
> >>
> >> Hi Sherry,
> >>
> >> On 2019-07-31 19:56, Sherry Sun wrote:
> >> > Hi Angus
> >> >
> >> >>
> >> >> Hi Sherry,
> >> >>
> >> >> On 2019-07-17 18:40, sherry sun wrote:
> >> >> > From: Sherry Sun mailto:sherry@nxp.com>>
> >> >> >
> >> >> > This patchset adds:
> >> >> > 1. Add usb_gadget_initialize() and usb_gadget_release() to
> >> >> > initialize and release UDC during sdp download.
> >> >> > 2. Add high speed endpoint descriptor for sdp.
> >> >> > 3. Add a macro definition--CONFIG_SDP_LOADADDR as default sdp
> >> >> > load address while SDP_WRITE and SDP_JUMP command addr is zero.
> >> >> >
> >> >> > Sherry Sun (4):
> >> >> >   imx: spl: Change USB boot device type
> >> >> >   SDP: use CONFIG_SDP_LOADADDR as default load address
> >> >> >   SDP: fix wrong usb request size and add high speed endpoint
> >> >> > descriptor
> >> >> >   SDP: Call usb_gadget_initialize and usb_gadget_release to
> >> >> > support UDC
> >> >>
> >> >> These changes look like like they target SDP on imx8. For imx8mq
> >> >> is this all that is required to get SDP working with uuu or are
> >> >> there additional changes required ?
> >> >>
> >> >
> >> > The changes in patch 1/4 are target on both imx8 and imx8m.
> >> > The rest three patches are target on all boards which used SDP.
> >> > So for imx8mq, if your usb gadget driver is ready ,these changes
> >> > are enough to get SDP working with UUU.
> >> >
> >>
> >> I'm trying to use SDP on the imx8mq-evk but it doesn't look like it's
> >> enabled there. Do you have patches to enable SDP on the imx8mq-evk ,
> >> even if they aren't ready to go upstream ?
> >
> > You could try downstream code,
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> >
> ce.codeaurora.org%2Fexternal%2Fimx%2Fuboot-imx%2Fdata=02%7C01
> %7Cs
> >
> herry.sun%40nxp.com%7C6d63289fbb104168bce308d716f157c4%7C686ea1
> d3bc2b4
> >
> c6fa92cd99c5c301635%7C0%7C0%7C637003098143081621sdata=beh
> 08%2Fv3f
> > s8ZZPP29F1iVMfo3uNTWGf91SYYyak2GVU%3Dreserved=0
> > branch: imx_v2019.04_4.19.35_1.0.0
> >
>
> I already have SDP  working with the vendor u-boot. I'm trying to switch to
> mainline u-boot so I'm looking for mainline patches.
>

May I ask, is your usb gadget driver is working? Such as you can use it for 
fastboot or ums.
If I enable dwc3 gadget and DM for the SPL then I must start removing other SPL 
features to get it to fit in the 124k allocation.

It sounds like you haven't tested this on the imx8mq-evk then ?

Thanks
Angus

Best regards
Sherry sun

> Thanks
> Angus
>
> > Regards,
> > Peng.
> >
> >>
> >> Thanks
> >> Angus
> >>
> >> > Best regards
> >> > Sherry sun
> >> >
> >> >> Thanks
> >> >> Angus
> >> >>
> >> >> >
> >> >> >  arch/arm/mach-imx/spl.c|  2 +-
> >> >> >  common/spl/spl_sdp.c   |  4 
> >> >> >  drivers/usb/gadget/Kconfig |  4 
> >> >> > drivers/usb/gadget/f_sdp.c |
> >> >> > 39
> >> >> > +-
> >> >> >  4 files changed, 43 insertions(+), 6 deletions(-)

___

Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver

2019-08-19 Thread Marek Vasut
On 8/19/19 8:10 AM, Sherry Sun wrote:
> Add the USB3 host driver for NXP imx8 platform, and the
> cadence IP is in it. The USB3 host driver support DM
> mode, it will probe USB3 host node in dts.
> 
> Signed-off-by: Sherry Sun 

[...]

> +static void xhci_imx8_get_reg_addr(struct udevice *dev)
> +{
> + imx8_data.usb3_ctrl_base =
> + (void __iomem *)devfdt_get_addr_index(dev, 0);
> + imx8_data.usb3_core_base =
> + (void __iomem *)devfdt_get_addr_index(dev, 4);
> +}

Inline this.

Also, look at drivers/mtd/renesas_rpc_hf.c to handle both 32bit and
64bit DTs with multiple "reg" entries.

[...]

> +static const struct udevice_id xhci_usb_ids[] = {
> + { .compatible = "cdns,usb3-host", },

https://lore.kernel.org/patchwork/patch/1059917/ would suggest that
cdns,usb3-1.0.0 is the compatible. But I might be wrong.

> + { }
> +};
> +
> +U_BOOT_DRIVER(xhci_imx8) = {
> + .name   = "xhci_imx8",
> + .id = UCLASS_USB,
> + .of_match = xhci_usb_ids,
> + .probe = xhci_imx8_probe,
> + .remove = xhci_imx8_remove,
> + .ops= _usb_ops,
> + .platdata_auto_alloc_size = sizeof(struct usb_platdata),
> + .priv_auto_alloc_size = sizeof(struct xhci_ctrl),
> + .flags  = DM_FLAG_ALLOC_PRIV_DMA,

I think you also need DM_FLAG_OS_PREPARE to trigger .remove before
booting Linux, but I might be wrong. Please check that.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 1/4] USB: gadget: Add the cadence USB3 gadget driver

2019-08-19 Thread Marek Vasut
On 8/19/19 8:10 AM, Sherry Sun wrote:
> This driver is ported from NXP i.MX U-Boot version imx_v2019.04
> and some changes have also been made to adapt to U-Boot.
> 
> Add the Cadence USB3 IP(CDNS3) driver for the gadget (device mode).
> The CDNS3 gadget driver support DM mode. CONFIG_DM_USB_GADGET should
> be enabled when use this driver.
> 
> Signed-off-by: Sherry Sun 

[...]

> +static int cdns_req_ep0_set_configuration(struct usb_ss_dev *usb_ss,
> +   struct usb_ctrlrequest *ctrl_req)
> +{
> + enum usb_device_state device_state = usb_ss->gadget.state;
> + u32 config = le16_to_cpu(ctrl_req->wValue);
> + struct usb_ep *ep;
> + struct usb_ss_endpoint *usb_ss_ep, *temp_ss_ep;
> + int i, result = 0;
> +
> + switch (device_state) {
> + case USB_STATE_ADDRESS:
> + /* Configure non-control EPs */
> + list_for_each_entry_safe(usb_ss_ep, temp_ss_ep,
> +  _ss->ep_match_list,
> +  ep_match_pending_list) {
> + cdns_ep_config(usb_ss_ep);
> + list_del(_ss_ep->ep_match_pending_list);
> + }
> +
> + list_for_each_entry(ep, _ss->gadget.ep_list, ep_list) {
> + usb_ss_ep = to_usb_ss_ep(ep);
> + if (usb_ss_ep->used)
> + cdns_ep_config(usb_ss_ep);
> + }
> +
> +#ifdef CDNS_THREADED_IRQ_HANDLING
> + usb_ss->ep_ien = cdns_readl(_ss->regs->ep_ien)
> + | EP_IEN__EOUTEN0__MASK | EP_IEN__EINEN0__MASK;
> +#endif

This is probably not needed ?

[...]

> +/* Common TRB fields */
> +#define TRB_SET_CYCLE_BIT1uL
> +#define TRB_SET_CHAIN_BIT0x10
> +
> +/* offset 0 */
> +#define TRB_DATA_BUFFER_POINTER_MASK 0x
> +#define TRB_SET_DATA_BUFFER_POINTER(p)   (p & 
> TRB_DATA_BUFFER_POINTER_MASK)
> +
> +/* offset 4 */
> +#define TRB_TRANSFER_LENGTH_MASK 0x1
> +#define TRB_SET_TRANSFER_LENGTH(l)   (l & TRB_TRANSFER_LENGTH_MASK)
> +
> +#define TRB_BURST_LENGTH_MASK0xFF
> +#define TRB_SET_BURST_LENGTH(l)  ((l & TRB_BURST_LENGTH_MASK) << 
> 24)
> +
> +/* offset 8 */
> +#define TRB_SET_INT_ON_SHORT_PACKET  0x04
> +#define TRB_SET_FIFO_MODE0x08
> +#define TRB_SET_INT_ON_COMPLETION0x20
> +
> +#define TRB_TYPE_NORMAL  0x400
> +
> +#define TRB_STREAM_ID_MASK   0x
> +#define TRB_SET_STREAM_ID(sid)   ((sid & TRB_STREAM_ID_MASK) << 
> 16)
> +

$sid needs parenthesis, that is (((sid) & TRB_STREAM_ID_MASK) << 16)

there are a few more such issues above, fix them too.

[...]

> +#endif /* __DRIVERS_CDNS3_GADGET */
> diff --git a/drivers/usb/cdns3/io.h b/drivers/usb/cdns3/io.h
> new file mode 100644
> index 00..22b1b03950
> --- /dev/null
> +++ b/drivers/usb/cdns3/io.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2016 Cadence Design Systems - https://www.cadence.com/
> + * Copyright 2019 NXP
> + */
> +
> +#ifndef __DRIVERS_USB_CDNS_IO_H
> +#define __DRIVERS_USB_CDNS_IO_H
> +
> +#include 
> +
> +static inline u32 cdns_readl(u32 __iomem *reg)
> +{
> + u32 value = 0;

return readl() ? The value is assigned twice here, for no reason.

> + value = readl(reg);
> + return value;
> +}
> +
> +static inline void cdns_writel(u32 __iomem *reg, u32 value)
> +{
> + writel(value, reg);
> +}
> +
> +static inline void cdns_flush_cache(uintptr_t addr, int length)
> +{
> + flush_dcache_range(addr, addr + ROUND(length, ARCH_DMA_MINALIGN));

Drop the ROUND() thing here, just use addr + length. If the start or end
address of the cache flush is wrong, the arch code will warn you about
it. Here, it will just hide possible bugs.

> +}
> +
> +#endif /* __DRIVERS_USB_CDNS_IO_H */
> diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
> index 179b94cdd0..360f2b75ff 100644
> --- a/drivers/usb/gadget/epautoconf.c
> +++ b/drivers/usb/gadget/epautoconf.c
> @@ -167,6 +167,10 @@ static int ep_matches(
>   size = 64;
>   put_unaligned(cpu_to_le16(size), >wMaxPacketSize);
>   }
> +
> + if (gadget->ops->match_ep)
> + return gadget->ops->match_ep(gadget, ep, desc);
> +

Separate patch for core framework changes please.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] core: of_addr: Correct the size type of of_get_address to fdt_size_t

2019-08-19 Thread Eugeniu Rosca
Hi Keerthy,

On Wed, Aug 14, 2019 at 03:56:48PM +0530, Keerthy wrote:
> Currently the size parameter is defined as u64 type.
> Correct the size type of of_get_address to fdt_size_t
> so that both 64 bit and 32 bit architectures are taken
> care of.
> 
> The initial bug report:
> https://patchwork.ozlabs.org/patch/1090094/#2212555
> 
> Fixes: e679d03b08fb ("core: ofnode: Add ofnode_get_addr_size_index")
> Reported-by: Eugeniu Rosca 
> Tested-by: Eugeniu Rosca  
> Signed-off-by: Keerthy 
> ---
> 
> Changes from RFT:
> 
>   * Fixed a typo in the commit log.
>   * Added Reported-by: Eugeniu Rosca 
> Tested-by: Eugeniu Rosca 
> 
>  drivers/core/of_addr.c | 4 ++--
>  drivers/core/ofnode.c  | 2 +-
>  include/dm/of_addr.h   | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
> index 4e256d9926..812a400b19 100644
> --- a/drivers/core/of_addr.c
> +++ b/drivers/core/of_addr.c
> @@ -122,7 +122,7 @@ static void dev_count_cells(const struct device_node *np, 
> int *nap, int *nsp)
>  }
>  
>  const __be32 *of_get_address(const struct device_node *dev, int index,
> -  u64 *size, unsigned int *flags)
> +  fdt_size_t *size, unsigned int *flags)

I took some time to also review the changes in addition to testing.

I can see that, since its inception in Linux [1], of_get_address() used
'u64*' type for its 'size' argument. That's still valid in v5.3-rc5.
So, it looks to me that with this patch we diverge from Linux.

I would barely think that the ASAN issue being fixed in this patch
exists in Linux, since the latter receives much more KASAN-enabled
testing on regular basis.

Do you foresee any alternative fix w/o diverging from Linux?

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22ae782f86b7

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


[U-Boot] [PATCH v2 23/26] imx8m: soc: probe clock device in arch_cpu_init_dm

2019-08-19 Thread Peng Fan
Because we need to get cpu freq in print_cpuinfo at very early stage,
so we need to make sure the ccm be probed.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 3a54db4898..f904049120 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -228,6 +229,22 @@ static void imx_set_wdog_powerdown(bool enable)
writew(enable, >wmcr);
 }
 
+int arch_cpu_init_dm(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   ret = uclass_get_device_by_name(UCLASS_CLK,
+   "clock-controller@3038",
+   );
+   if (ret < 0) {
+   printf("Failed to find clock node. Check device tree\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 int arch_cpu_init(void)
 {
struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
-- 
2.16.4

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


[U-Boot] [PATCH v2 17/26] imx8m: soc: enable SCTR clock before timer init

2019-08-19 Thread Peng Fan
To i.MX8MM SCTR clock is disabled by ROM, so before timer init
need to enable it.
To i.MX8MQ, it does not hurt the clock is enabled again.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index a33ca35653..ac80266010 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -231,6 +231,12 @@ static void imx_set_wdog_powerdown(bool enable)
 int arch_cpu_init(void)
 {
struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+   /*
+* ROM might disable clock for SCTR,
+* enable the clock before timer_init.
+*/
+   if (IS_ENABLED(CONFIG_SPL_BUILD))
+   clock_enable(CCGR_SCTR, 1);
/*
 * Init timer at very early state, because sscg pll setting
 * will use it
-- 
2.16.4

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


[U-Boot] [PATCH v2 10/26] imx8m: update imx-regs for i.MX8MM

2019-08-19 Thread Peng Fan
i.MX8MM has similar architecture with i.MX8MQ, but it has totally
different PLL design and register layout change.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/imx-regs.h | 69 +++---
 1 file changed, 64 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h 
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index 4ce6c1b077..62640d996e 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -10,8 +10,8 @@
 
 #include 
 
-#define ROM_VERSION_A0 0x800
-#define ROM_VERSION_B0 0x83C
+#define ROM_VERSION_A0 IS_ENABLED(CONFIG_IMX8MQ) ? 0x800 : 0x800
+#define ROM_VERSION_B0 IS_ENABLED(CONFIG_IMX8MQ) ? 0x83C : 0x800
 
 #define M4_BOOTROM_BASE_ADDR   0x007E
 
@@ -23,7 +23,6 @@
 #define WDOG1_BASE_ADDR0x3028
 #define WDOG2_BASE_ADDR0x3029
 #define WDOG3_BASE_ADDR0x302A
-#define LCDIF_BASE_ADDR0x3032
 #define IOMUXC_BASE_ADDR   0x3033
 #define IOMUXC_GPR_BASE_ADDR   0x3034
 #define OCOTP_BASE_ADDR0x3035
@@ -46,10 +45,14 @@
 #define UART4_BASE_ADDR0x30A6
 #define USDHC1_BASE_ADDR   0x30B4
 #define USDHC2_BASE_ADDR   0x30B5
+#ifdef CONFIG_IMX8MM
+#define USDHC3_BASE_ADDR   0x30B6
+#endif
 
 #define TZASC_BASE_ADDR0x32F8
 
-#define MXS_LCDIF_BASE LCDIF_BASE_ADDR
+#define MXS_LCDIF_BASE IS_ENABLED(CONFIG_IMX8MQ) ? \
+   0x3032 : 0x32e0
 
 #define SRC_IPS_BASE_ADDR  0x3039
 #define SRC_DDRC_RCR_ADDR  0x30391000
@@ -134,6 +137,7 @@ struct fuse_bank1_regs {
u32 rsvd3[3];
 };
 
+#ifdef CONFIG_IMX8MQ
 struct anamix_pll {
u32 audio_pll1_cfg0;
u32 audio_pll1_cfg1;
@@ -168,6 +172,60 @@ struct anamix_pll {
u32 frac_pllout_div_cfg;
u32 sscg_pllout_div_cfg;
 };
+#else
+struct anamix_pll {
+   u32 audio_pll1_gnrl_ctl;
+   u32 audio_pll1_fdiv_ctl0;
+   u32 audio_pll1_fdiv_ctl1;
+   u32 audio_pll1_sscg_ctl;
+   u32 audio_pll1_mnit_ctl;
+   u32 audio_pll2_gnrl_ctl;
+   u32 audio_pll2_fdiv_ctl0;
+   u32 audio_pll2_fdiv_ctl1;
+   u32 audio_pll2_sscg_ctl;
+   u32 audio_pll2_mnit_ctl;
+   u32 video_pll1_gnrl_ctl;
+   u32 video_pll1_fdiv_ctl0;
+   u32 video_pll1_fdiv_ctl1;
+   u32 video_pll1_sscg_ctl;
+   u32 video_pll1_mnit_ctl;
+   u32 reserved[5];
+   u32 dram_pll_gnrl_ctl;
+   u32 dram_pll_fdiv_ctl0;
+   u32 dram_pll_fdiv_ctl1;
+   u32 dram_pll_sscg_ctl;
+   u32 dram_pll_mnit_ctl;
+   u32 gpu_pll_gnrl_ctl;
+   u32 gpu_pll_div_ctl;
+   u32 gpu_pll_locked_ctl1;
+   u32 gpu_pll_mnit_ctl;
+   u32 vpu_pll_gnrl_ctl;
+   u32 vpu_pll_div_ctl;
+   u32 vpu_pll_locked_ctl1;
+   u32 vpu_pll_mnit_ctl;
+   u32 arm_pll_gnrl_ctl;
+   u32 arm_pll_div_ctl;
+   u32 arm_pll_locked_ctl1;
+   u32 arm_pll_mnit_ctl;
+   u32 sys_pll1_gnrl_ctl;
+   u32 sys_pll1_div_ctl;
+   u32 sys_pll1_locked_ctl1;
+   u32 reserved2[24];
+   u32 sys_pll1_mnit_ctl;
+   u32 sys_pll2_gnrl_ctl;
+   u32 sys_pll2_div_ctl;
+   u32 sys_pll2_locked_ctl1;
+   u32 sys_pll2_mnit_ctl;
+   u32 sys_pll3_gnrl_ctl;
+   u32 sys_pll3_div_ctl;
+   u32 sys_pll3_locked_ctl1;
+   u32 sys_pll3_mnit_ctl;
+   u32 anamix_misc_ctl;
+   u32 anamix_clk_mnit_ctl;
+   u32 reserved3[437];
+   u32 digprog;
+};
+#endif
 
 struct fuse_bank9_regs {
u32 mac_addr0;
@@ -239,7 +297,8 @@ struct bootrom_sw_info {
u32 reserved_3[3];
 };
 
-#define ROM_SW_INFO_ADDR_B00x0968
+#define ROM_SW_INFO_ADDR_B0(IS_ENABLED(CONFIG_IMX8MQ) ? 0x0968 :\
+0x09e8)
 #define ROM_SW_INFO_ADDR_A00x09e8
 
 #define ROM_SW_INFO_ADDR is_soc_rev(CHIP_REV_1_0) ? \
-- 
2.16.4

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


Re: [U-Boot] [PATCH 2/2] libavb: Fix build warnings after updating the lib

2019-08-19 Thread Igor Opaniuk
On Mon, Aug 19, 2019 at 12:40 PM Igor Opaniuk  wrote:
>
> Hi Eugeniu,
>
> On Mon, Aug 19, 2019 at 11:28 AM Eugeniu Rosca  wrote:
> >
> > Hi all,
> >
> > On Fri, Aug 16, 2019 at 11:46:03AM -0400, David Zeuthen wrote:
> > >Hi,
> > >As for upstreaming libavb patches, I'd be interested in landing them
> > >upstream... makes it easier for anyone.
> > >Our upstream is AOSP and we use gerrit for
> > >code-review: 
> > > https://android-review.googlesource.com/q/project:platform%252Fexternal%252Favb
> > >Here's a guide to
> > >contributing: 
> > > https://source.android.com/setup/contribute/submit-patches ...
> > >hope it's not too painful to use the AOSP process!
> > >Thanks,
> > >David
> >
> > David, thanks for being open about discussing/accepting the fixes.
> >
> > U-Boot folks,
> >
> > What's your opinion w.r.t. the right/best order between accepting
> > the libavb fixes locally in U-Boot and pushing them to upstream?
> > Which should come first? I suppose they can be first applied internally
> > and replaced later on if they get reworked/optimized during upstreaming.
> >
> > --
> > Best Regards,
> > Eugeniu.
>
> IMHO, the best approach here is to upstream fixes to AOSP libavb first,
> only then port stuff to U-boot.
>
> Nevertheless, taking into account the amount of time needed
> (sometimes it can take months, or even years, Sam has good
> stories about that) to get something applied to AOSP, I would suggest
> to proceed internally with commits like this ASAP, but somehow (extended
> commit message for each "libavb sync" patch with the list of patches out of
> AOSP tree; or introduce "doc/android/libavb-porting.txt", where we can
> provide all details about list of commits from AOSP + out-of-tree commits,
> how-to do porting etc; other ideas?) keep track of changes that are not
> up-streamed to AOSP yet.
>
> Ideally we have to achieve 1:1 mapping (with the only difference - SPDX tags),

And avb_sysdeps_posix.c (implementation of avb_abort() and list of includes).
You see, I'm already missing some of introduced changes on top of
"vanilla" libavb.

> of [1] in lib/libavb/, otherwise we will fight with constant code
> divergence (obviously).
>
> [1] https://android.googlesource.com/platform/external/avb/+//libavb
>
> --
> Best regards - Freundliche Grüsse - Meilleures salutations
>
> Igor Opaniuk
>
> mailto: igor.opan...@gmail.com
> skype: igor.opanyuk
> +380 (93) 836 40 67
> http://ua.linkedin.com/in/iopaniuk



-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 24/26] arm: dts: import i.MX8MM dtsi

2019-08-19 Thread Peng Fan
Import i.MX8MM dtsi from Linux Kernel,
commit <0a8ad0ffa4d8> ("Merge tag 'for-linus-5.3-ofs1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux")

Signed-off-by: Peng Fan 
---
 arch/arm/dts/imx8mm.dtsi | 733 +++
 1 file changed, 733 insertions(+)
 create mode 100644 arch/arm/dts/imx8mm.dtsi

diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
new file mode 100644
index 00..6b407a94c0
--- /dev/null
+++ b/arch/arm/dts/imx8mm.dtsi
@@ -0,0 +1,733 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx8mm-pinfunc.h"
+
+/ {
+   compatible = "fsl,imx8mm";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   ethernet0 = 
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   spi0 = 
+   spi1 = 
+   spi2 = 
+   mmc0 = 
+   mmc1 = 
+   mmc2 = 
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   gpio3 = 
+   gpio4 = 
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   A53_0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x0>;
+   clock-latency = <61036>; /* two CLK32 periods */
+   clocks = < IMX8MM_CLK_ARM>;
+   enable-method = "psci";
+   next-level-cache = <_L2>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   A53_1: cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x1>;
+   clock-latency = <61036>; /* two CLK32 periods */
+   clocks = < IMX8MM_CLK_ARM>;
+   enable-method = "psci";
+   next-level-cache = <_L2>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   A53_2: cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x2>;
+   clock-latency = <61036>; /* two CLK32 periods */
+   clocks = < IMX8MM_CLK_ARM>;
+   enable-method = "psci";
+   next-level-cache = <_L2>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   A53_3: cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   reg = <0x3>;
+   clock-latency = <61036>; /* two CLK32 periods */
+   clocks = < IMX8MM_CLK_ARM>;
+   enable-method = "psci";
+   next-level-cache = <_L2>;
+   operating-points-v2 = <_opp_table>;
+   };
+
+   A53_L2: l2-cache0 {
+   compatible = "cache";
+   };
+   };
+
+   a53_opp_table: opp-table {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-12 {
+   opp-hz = /bits/ 64 <12>;
+   opp-microvolt = <85>;
+   clock-latency-ns = <15>;
+   };
+
+   opp-16 {
+   opp-hz = /bits/ 64 <16>;
+   opp-microvolt = <90>;
+   clock-latency-ns = <15>;
+   opp-suspend;
+   };
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0x0 0x4000 0 0x8000>;
+   };
+
+   osc_32k: clock-osc-32k {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   clock-output-names = "osc_32k";
+   };
+
+   osc_24m: clock-osc-24m {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+   clock-output-names = "osc_24m";
+   };
+
+   clk_ext1: clock-ext1 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <13300>;
+   clock-output-names = "clk_ext1";
+   };
+
+   clk_ext2: clock-ext2 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <13300>;
+  

[U-Boot] [PATCH v2 26/26] imx: Add i.MX8MM EVK board support.

2019-08-19 Thread Peng Fan
Add board and SoC dts
Add ddr timing codes which are generated by NXP DDR tool.
support SD/MMC/GPIO/PINCTRL/UART

Signed-off-by: Peng Fan 
---
 arch/arm/dts/Makefile  |3 +-
 arch/arm/dts/imx8mm-evk-u-boot.dtsi|   92 ++
 arch/arm/dts/imx8mm-evk.dts|  235 
 arch/arm/mach-imx/imx8m/Kconfig|7 +
 board/freescale/imx8mm_evk/Kconfig |   12 +
 board/freescale/imx8mm_evk/MAINTAINERS |6 +
 board/freescale/imx8mm_evk/Makefile|   12 +
 board/freescale/imx8mm_evk/imx8mm_evk.c|   45 +
 board/freescale/imx8mm_evk/lpddr4_timing.c | 1980 
 board/freescale/imx8mm_evk/spl.c   |  129 ++
 configs/imx8mm_evk_defconfig   |   74 ++
 include/configs/imx8mm_evk.h   |  153 +++
 12 files changed, 2747 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx8mm-evk-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-evk.dts
 create mode 100644 board/freescale/imx8mm_evk/Kconfig
 create mode 100644 board/freescale/imx8mm_evk/MAINTAINERS
 create mode 100644 board/freescale/imx8mm_evk/Makefile
 create mode 100644 board/freescale/imx8mm_evk/imx8mm_evk.c
 create mode 100644 board/freescale/imx8mm_evk/lpddr4_timing.c
 create mode 100644 board/freescale/imx8mm_evk/spl.c
 create mode 100644 configs/imx8mm_evk_defconfig
 create mode 100644 include/configs/imx8mm_evk.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e021888ce4..d913094619 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -628,7 +628,8 @@ dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qxp-colibri.dtb \
fsl-imx8qxp-mek.dtb
 
-dtb-$(CONFIG_ARCH_IMX8M) += fsl-imx8mq-evk.dtb
+dtb-$(CONFIG_ARCH_IMX8M) += fsl-imx8mq-evk.dtb \
+   imx8mm-evk.dtb
 
 dtb-$(CONFIG_RCAR_GEN2) += \
r8a7790-lager-u-boot.dtb \
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi 
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
new file mode 100644
index 00..1095d36e31
--- /dev/null
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019 NXP
+ */
+
+&{/soc} {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+_24m {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-spl;
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_reg_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+_uart2 {
+   u-boot,dm-spl;
+};
+
+_usdhc2_gpio {
+   u-boot,dm-spl;
+};
+
+_usdhc2 {
+   u-boot,dm-spl;
+};
+
+_usdhc3 {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx8mm-evk.dts b/arch/arm/dts/imx8mm-evk.dts
new file mode 100644
index 00..2d5d89475b
--- /dev/null
+++ b/arch/arm/dts/imx8mm-evk.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019 NXP
+ */
+
+/dts-v1/;
+
+#include "imx8mm.dtsi"
+
+/ {
+   model = "FSL i.MX8MM EVK board";
+   compatible = "fsl,imx8mm-evk", "fsl,imx8mm";
+
+   chosen {
+   stdout-path = 
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_led>;
+
+   status {
+   label = "status";
+   gpios = < 16 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
+   reg_usdhc2_vmmc: regulator-usdhc2 {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_reg_usdhc2_vmmc>;
+   regulator-name = "VSD_3V3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 19 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_fec1>;
+   phy-mode = "rgmii-id";
+   phy-handle = <>;
+   fsl,magic-packet;
+   status = "okay";
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethphy0: ethernet-phy@0 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <0>;
+   at803x,led-act-blind-workaround;
+   at803x,eee-okay;
+   at803x,vddio-1p8v;
+   };
+   };
+};
+
+ { /* console */
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart2>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = 

[U-Boot] [PATCH v2 21/26] imx8m: add clk support for i.MX8MM

2019-08-19 Thread Peng Fan
Introduce clk implementation for i.MX8MM, including pll configuration,
ccm configuration. Mostly will be done clk dm driver,
but such as DRAM part, we still use non clk dm driver, because we
have limited sram.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/clock.h|   2 +
 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 387 +
 arch/arm/mach-imx/imx8m/Makefile   |   1 +
 arch/arm/mach-imx/imx8m/clock_imx8mm.c | 306 +++
 arch/arm/mach-imx/imx8m/clock_slice.c  |  63 
 5 files changed, 759 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
 create mode 100644 arch/arm/mach-imx/imx8m/clock_imx8mm.c

diff --git a/arch/arm/include/asm/arch-imx8m/clock.h 
b/arch/arm/include/asm/arch-imx8m/clock.h
index 80245a2f2d..dded6e0797 100644
--- a/arch/arm/include/asm/arch-imx8m/clock.h
+++ b/arch/arm/include/asm/arch-imx8m/clock.h
@@ -9,6 +9,8 @@
 
 #ifdef CONFIG_IMX8MQ
 #include 
+#elif defined(CONFIG_IMX8MM)
+#include 
 #else
 #error "Error no clock.h"
 #endif
diff --git a/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h 
b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
new file mode 100644
index 00..305514a4ec
--- /dev/null
+++ b/arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
@@ -0,0 +1,387 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018-2019 NXP
+ *
+ * Peng Fan 
+ */
+
+#ifndef _ASM_ARCH_IMX8MM_CLOCK_H
+#define _ASM_ARCH_IMX8MM_CLOCK_H
+
+#define PLL_1443X_RATE(_rate, _m, _p, _s, _k)  \
+   {   \
+   .rate   =   (_rate),\
+   .mdiv   =   (_m),   \
+   .pdiv   =   (_p),   \
+   .sdiv   =   (_s),   \
+   .kdiv   =   (_k),   \
+   }
+
+#define LOCK_STATUSBIT(31)
+#define LOCK_SEL_MASK  BIT(29)
+#define CLKE_MASK  BIT(11)
+#define RST_MASK   BIT(9)
+#define BYPASS_MASKBIT(4)
+#defineMDIV_SHIFT  12
+#defineMDIV_MASK   GENMASK(21, 12)
+#define PDIV_SHIFT 4
+#define PDIV_MASK  GENMASK(9, 4)
+#define SDIV_SHIFT 0
+#define SDIV_MASK  GENMASK(2, 0)
+#define KDIV_SHIFT 0
+#define KDIV_MASK  GENMASK(15, 0)
+
+struct imx_int_pll_rate_table {
+   u32 rate;
+   int mdiv;
+   int pdiv;
+   int sdiv;
+   int kdiv;
+};
+
+enum pll_clocks {
+   ANATOP_ARM_PLL,
+   ANATOP_VPU_PLL,
+   ANATOP_GPU_PLL,
+   ANATOP_SYSTEM_PLL1,
+   ANATOP_SYSTEM_PLL2,
+   ANATOP_SYSTEM_PLL3,
+   ANATOP_AUDIO_PLL1,
+   ANATOP_AUDIO_PLL2,
+   ANATOP_VIDEO_PLL,
+   ANATOP_DRAM_PLL,
+};
+
+enum clk_root_index {
+   ARM_A53_CLK_ROOT= 0,
+   ARM_M4_CLK_ROOT = 1,
+   VPU_A53_CLK_ROOT= 2,
+   GPU3D_CLK_ROOT  = 3,
+   GPU2D_CLK_ROOT  = 4,
+   MAIN_AXI_CLK_ROOT   = 16,
+   ENET_AXI_CLK_ROOT   = 17,
+   NAND_USDHC_BUS_CLK_ROOT = 18,
+   VPU_BUS_CLK_ROOT= 19,
+   DISPLAY_AXI_CLK_ROOT= 20,
+   DISPLAY_APB_CLK_ROOT= 21,
+   DISPLAY_RTRM_CLK_ROOT   = 22,
+   USB_BUS_CLK_ROOT= 23,
+   GPU_AXI_CLK_ROOT= 24,
+   GPU_AHB_CLK_ROOT= 25,
+   NOC_CLK_ROOT= 26,
+   NOC_APB_CLK_ROOT= 27,
+   AHB_CLK_ROOT= 32,
+   IPG_CLK_ROOT= 33,
+   AUDIO_AHB_CLK_ROOT  = 34,
+   MIPI_DSI_ESC_RX_CLK_ROOT= 36,
+   DRAM_SEL_CFG= 48,
+   CORE_SEL_CFG= 49,
+   DRAM_ALT_CLK_ROOT   = 64,
+   DRAM_APB_CLK_ROOT   = 65,
+   VPU_G1_CLK_ROOT = 66,
+   VPU_G2_CLK_ROOT = 67,
+   DISPLAY_DTRC_CLK_ROOT   = 68,
+   DISPLAY_DC8000_CLK_ROOT = 69,
+   PCIE_CTRL_CLK_ROOT  = 70,
+   PCIE_PHY_CLK_ROOT   = 71,
+   PCIE_AUX_CLK_ROOT   = 72,
+   DC_PIXEL_CLK_ROOT   = 73,
+   LCDIF_PIXEL_CLK_ROOT= 74,
+   SAI1_CLK_ROOT   = 75,
+   SAI2_CLK_ROOT   = 76,
+   SAI3_CLK_ROOT   = 77,
+   SAI4_CLK_ROOT   = 78,
+   SAI5_CLK_ROOT   = 79,
+   SAI6_CLK_ROOT   = 80,
+   SPDIF1_CLK_ROOT = 81,
+   SPDIF2_CLK_ROOT = 82,
+   ENET_REF_CLK_ROOT   = 83,
+   ENET_TIMER_CLK_ROOT = 84,
+   ENET_PHY_REF_CLK_ROOT   = 85,
+   NAND_CLK_ROOT   = 86,
+   QSPI_CLK_ROOT   

[U-Boot] [PATCH v2 22/26] imx: mmc_env: update runtime SD/MMC boot env device

2019-08-19 Thread Peng Fan
When DM_MMC enabled, the USDHC index in U-Boot is the USDHC port.
To directly return devno, we could avoid add board specific code.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/mmc_env.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-imx/mmc_env.c b/arch/arm/mach-imx/mmc_env.c
index 9c822f721c..addb50f538 100644
--- a/arch/arm/mach-imx/mmc_env.c
+++ b/arch/arm/mach-imx/mmc_env.c
@@ -11,6 +11,9 @@
 
 __weak int board_mmc_get_env_dev(int devno)
 {
+   if (CONFIG_IS_ENABLED(DM_MMC))
+   return devno;
+
return CONFIG_SYS_MMC_ENV_DEV;
 }
 
-- 
2.16.4

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


[U-Boot] [PATCH v2 09/26] imx8m: imx-regs: drop unused register definitions

2019-08-19 Thread Peng Fan
Drop unused register definitions and structures for i.MX8MQ

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/imx-regs.h | 222 +
 1 file changed, 1 insertion(+), 221 deletions(-)

diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h 
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index 68666a535b..4ce6c1b077 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -13,112 +13,41 @@
 #define ROM_VERSION_A0 0x800
 #define ROM_VERSION_B0 0x83C
 
-#define M4_BOOTROM_BASE_ADDR   0x007E
+#define M4_BOOTROM_BASE_ADDR   0x007E
 
-#define SAI1_BASE_ADDR 0x3001
-#define SAI6_BASE_ADDR 0x3003
-#define SAI5_BASE_ADDR 0x3004
-#define SAI4_BASE_ADDR 0x3005
-#define SPBA2_BASE_ADDR0x300F
-#define AIPS1_BASE_ADDR0x301F
 #define GPIO1_BASE_ADDR0X3020
 #define GPIO2_BASE_ADDR0x3021
 #define GPIO3_BASE_ADDR0x3022
 #define GPIO4_BASE_ADDR0x3023
 #define GPIO5_BASE_ADDR0x3024
-#define ANA_TSENSOR_BASE_ADDR  0x3026
-#define ANA_OSC_BASE_ADDR  0x3027
 #define WDOG1_BASE_ADDR0x3028
 #define WDOG2_BASE_ADDR0x3029
 #define WDOG3_BASE_ADDR0x302A
-#define SDMA2_BASE_ADDR0x302C
-#define GPT1_BASE_ADDR 0x302D
-#define GPT2_BASE_ADDR 0x302E
-#define GPT3_BASE_ADDR 0x302F
-#define ROMCP_BASE_ADDR0x3031
 #define LCDIF_BASE_ADDR0x3032
 #define IOMUXC_BASE_ADDR   0x3033
 #define IOMUXC_GPR_BASE_ADDR   0x3034
 #define OCOTP_BASE_ADDR0x3035
 #define ANATOP_BASE_ADDR   0x3036
-#define SNVS_HP_BASE_ADDR  0x3037
 #define CCM_BASE_ADDR  0x3038
 #define SRC_BASE_ADDR  0x3039
 #define GPC_BASE_ADDR  0x303A
-#define SEMAPHORE1_BASE_ADDR   0x303B
-#define SEMAPHORE2_BASE_ADDR   0x303C
-#define RDC_BASE_ADDR  0x303D
-#define CSU_BASE_ADDR  0x303E
 
-#define AIPS2_BASE_ADDR0x305F
-#define PWM1_BASE_ADDR 0x3066
-#define PWM2_BASE_ADDR 0x3067
-#define PWM3_BASE_ADDR 0x3068
-#define PWM4_BASE_ADDR 0x3069
 #define SYSCNT_RD_BASE_ADDR0x306A
 #define SYSCNT_CMP_BASE_ADDR   0x306B
 #define SYSCNT_CTRL_BASE_ADDR  0x306C
-#define GPT6_BASE_ADDR 0x306E
-#define GPT5_BASE_ADDR 0x306F
-#define GPT4_BASE_ADDR 0x3070
-#define PERFMON1_BASE_ADDR 0x307C
-#define PERFMON2_BASE_ADDR 0x307D
-#define QOSC_BASE_ADDR 0x307F
 
-#define SPDIF1_BASE_ADDR   0x3081
-#define ECSPI1_BASE_ADDR   0x3082
-#define ECSPI2_BASE_ADDR   0x3083
-#define ECSPI3_BASE_ADDR   0x3084
 #define UART1_BASE_ADDR0x3086
 #define UART3_BASE_ADDR0x3088
 #define UART2_BASE_ADDR0x3089
-#define SPDIF2_BASE_ADDR   0x308A
-#define SAI2_BASE_ADDR 0x308B
-#define SAI3_BASE_ADDR 0x308C
-#define SPBA1_BASE_ADDR0x308F
-#define CAAM_BASE_ADDR 0x3090
-#define AIPS3_BASE_ADDR0x309F
-#define MIPI_PHY_BASE_ADDR 0x30A0
-#define MIPI_DSI_BASE_ADDR 0x30A1
 #define I2C1_BASE_ADDR 0x30A2
 #define I2C2_BASE_ADDR 0x30A3
 #define I2C3_BASE_ADDR 0x30A4
 #define I2C4_BASE_ADDR 0x30A5
 #define UART4_BASE_ADDR0x30A6
-#define MIPI_CSI_BASE_ADDR 0x30A7
-#define MIPI_CSI_PHY1_BASE_ADDR0x30A8
-#define CSI1_BASE_ADDR 0x30A9
-#define MU_A_BASE_ADDR 0x30AA
-#define MU_B_BASE_ADDR 0x30AB
-#define SEMAPHOR_HS_BASE_ADDR  0x30AC
 #define USDHC1_BASE_ADDR   0x30B4
 #define USDHC2_BASE_ADDR   0x30B5
-#define MIPI_CS2_BASE_ADDR 0x30B6
-#define MIPI_CSI_PHY2_BASE_ADDR0x30B7
-#define CSI2_BASE_ADDR 0x30B8
-#define QSPI0_BASE_ADDR0x30BB
-#define QSPI0_AMBA_BASE0x0800
-#define SDMA1_BASE_ADDR0x30BD
-#define ENET1_BASE_ADDR0x30BE
 
-#define HDMI_CTRL_BASE_ADDR0x32C0
-#define AIPS4_BASE_ADDR0x32DF
-#define DC1_BASE_ADDR  0x32E0
-#define DC2_BASE_ADDR  0x32E1
-#define DC3_BASE_ADDR  0x32E2
-#define HDMI_SEC_BASE_ADDR 0x32E4
 #define TZASC_BASE_ADDR0x32F8
-#define MTR_BASE_ADDR  0x32FB
-#define PLATFORM_CTRL_BASE_ADDR0x32FE
-
-#define MXS_APBH_BASE  0x3300
-#define MXS_GPMI_BASE  0x33002000
-#define MXS_BCH_BASE   0x33004000
-
-#define 

[U-Boot] [PATCH v2 14/26] imx8m: Fix MMU table issue for OPTEE memory

2019-08-19 Thread Peng Fan
When running with OPTEE, the MMU table in u-boot does not remove the OPTEE
memory from its settings. So ARM speculative prefetch in u-boot may access
that OPTEE memory. Due to trust zone is enabled by OPTEE and that memory
is set to secure access, then the speculative prefetch will fail and cause
various memory issue in u-boot.
The fail address register and int_status register in trustzone has logged
that speculative access from u-boot.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 5115471eff..dd393b581b 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -112,16 +112,18 @@ static struct mm_region imx8m_mem_map[] = {
/* DRAM1 */
.virt = 0x4000UL,
.phys = 0x4000UL,
-   .size = 0xC000UL,
+   .size = PHYS_SDRAM_SIZE,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_OUTER_SHARE
+#ifdef PHYS_SDRAM_2_SIZE
}, {
/* DRAM2 */
.virt = 0x1UL,
.phys = 0x1UL,
-   .size = 0x04000UL,
+   .size = PHYS_SDRAM_2_SIZE,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_OUTER_SHARE
+#endif
}, {
/* List terminator */
0,
@@ -130,6 +132,20 @@ static struct mm_region imx8m_mem_map[] = {
 
 struct mm_region *mem_map = imx8m_mem_map;
 
+void enable_caches(void)
+{
+   /*
+* If OPTEE runs, remove OPTEE memory from MMU table to
+* avoid speculative prefetch. OPTEE runs at the top of
+* the first memory bank
+*/
+   if (rom_pointer[1])
+   imx8m_mem_map[5].size -= rom_pointer[1];
+
+   icache_enable();
+   dcache_enable();
+}
+
 static u32 get_cpu_variant_type(u32 type)
 {
struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
-- 
2.16.4

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


[U-Boot] [PATCH v2 13/26] imx: add i.MX8MM PE property

2019-08-19 Thread Peng Fan
i.MX8MM does not have LVTTL, it has a PE property

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/mach-imx/iomux-v3.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/iomux-v3.h 
b/arch/arm/include/asm/mach-imx/iomux-v3.h
index b899a4ff6f..720e8f7043 100644
--- a/arch/arm/include/asm/mach-imx/iomux-v3.h
+++ b/arch/arm/include/asm/mach-imx/iomux-v3.h
@@ -104,7 +104,11 @@ typedef u64 iomux_v3_cfg_t;
 #define PAD_CTL_ODE(0x1 << 5)
 #define PAD_CTL_PUE(0x1 << 6)
 #define PAD_CTL_HYS(0x1 << 7)
+#ifdef CONFIG_IMX8MM
+#define PAD_CTL_PE (0x1 << 8)
+#else
 #define PAD_CTL_LVTTL  (0x1 << 8)
+#endif
 
 #elif defined CONFIG_MX7
 
-- 
2.16.4

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


[U-Boot] [PATCH v2 20/26] imx8m: restructure clock.h

2019-08-19 Thread Peng Fan
i.MX8MQ and i.MX8MM use different analog pll design, but they
share same ccm design.
Add clock_imx8mq.h for i.MX8MQ
keep common part in clock.h

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/clock.h| 489 +++--
 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h | 424 +
 arch/arm/mach-imx/imx8m/clock_imx8mq.c |   5 +-
 3 files changed, 467 insertions(+), 451 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h

diff --git a/arch/arm/include/asm/arch-imx8m/clock.h 
b/arch/arm/include/asm/arch-imx8m/clock.h
index e7c1670f6b..80245a2f2d 100644
--- a/arch/arm/include/asm/arch-imx8m/clock.h
+++ b/arch/arm/include/asm/arch-imx8m/clock.h
@@ -2,27 +2,30 @@
 /*
  * Copyright 2017 NXP
  *
- * Peng Fan 
+ * Peng Fan 
  */
 
-#ifndef _ASM_ARCH_IMX8M_CLOCK_H
-#define _ASM_ARCH_IMX8M_CLOCK_H
-
 #include 
 
+#ifdef CONFIG_IMX8MQ
+#include 
+#else
+#error "Error no clock.h"
+#endif
+
 #define MHZ(X) ((X) * 100UL)
 
-enum pll_clocks {
-   ANATOP_ARM_PLL,
-   ANATOP_GPU_PLL,
-   ANATOP_SYSTEM_PLL1,
-   ANATOP_SYSTEM_PLL2,
-   ANATOP_SYSTEM_PLL3,
-   ANATOP_AUDIO_PLL1,
-   ANATOP_AUDIO_PLL2,
-   ANATOP_VIDEO_PLL1,
-   ANATOP_VIDEO_PLL2,
-   ANATOP_DRAM_PLL,
+/* Mainly for compatible to imx common code. */
+enum mxc_clock {
+   MXC_ARM_CLK = 0,
+   MXC_IPG_CLK,
+   MXC_CSPI_CLK,
+   MXC_ESDHC_CLK,
+   MXC_ESDHC2_CLK,
+   MXC_ESDHC3_CLK,
+   MXC_I2C_CLK,
+   MXC_UART_CLK,
+   MXC_QSPI_CLK,
 };
 
 enum clk_slice_type {
@@ -35,297 +38,6 @@ enum clk_slice_type {
DRAM_SEL_CLOCK_SLICE,
 };
 
-enum clk_root_index {
-   MXC_ARM_CLK = 0,
-   ARM_A53_CLK_ROOT= 0,
-   ARM_M4_CLK_ROOT = 1,
-   VPU_A53_CLK_ROOT= 2,
-   GPU_CORE_CLK_ROOT   = 3,
-   GPU_SHADER_CLK_ROOT = 4,
-   MAIN_AXI_CLK_ROOT   = 16,
-   ENET_AXI_CLK_ROOT   = 17,
-   NAND_USDHC_BUS_CLK_ROOT = 18,
-   VPU_BUS_CLK_ROOT= 19,
-   DISPLAY_AXI_CLK_ROOT= 20,
-   DISPLAY_APB_CLK_ROOT= 21,
-   DISPLAY_RTRM_CLK_ROOT   = 22,
-   USB_BUS_CLK_ROOT= 23,
-   GPU_AXI_CLK_ROOT= 24,
-   GPU_AHB_CLK_ROOT= 25,
-   NOC_CLK_ROOT= 26,
-   NOC_APB_CLK_ROOT= 27,
-   AHB_CLK_ROOT= 32,
-   IPG_CLK_ROOT= 33,
-   MXC_IPG_CLK = 33,
-   AUDIO_AHB_CLK_ROOT  = 34,
-   MIPI_DSI_ESC_RX_CLK_ROOT= 36,
-   DRAM_SEL_CFG= 48,
-   CORE_SEL_CFG= 49,
-   DRAM_ALT_CLK_ROOT   = 64,
-   DRAM_APB_CLK_ROOT   = 65,
-   VPU_G1_CLK_ROOT = 66,
-   VPU_G2_CLK_ROOT = 67,
-   DISPLAY_DTRC_CLK_ROOT   = 68,
-   DISPLAY_DC8000_CLK_ROOT = 69,
-   PCIE1_CTRL_CLK_ROOT = 70,
-   PCIE1_PHY_CLK_ROOT  = 71,
-   PCIE1_AUX_CLK_ROOT  = 72,
-   DC_PIXEL_CLK_ROOT   = 73,
-   LCDIF_PIXEL_CLK_ROOT= 74,
-   SAI1_CLK_ROOT   = 75,
-   SAI2_CLK_ROOT   = 76,
-   SAI3_CLK_ROOT   = 77,
-   SAI4_CLK_ROOT   = 78,
-   SAI5_CLK_ROOT   = 79,
-   SAI6_CLK_ROOT   = 80,
-   SPDIF1_CLK_ROOT = 81,
-   SPDIF2_CLK_ROOT = 82,
-   ENET_REF_CLK_ROOT   = 83,
-   ENET_TIMER_CLK_ROOT = 84,
-   ENET_PHY_REF_CLK_ROOT   = 85,
-   NAND_CLK_ROOT   = 86,
-   QSPI_CLK_ROOT   = 87,
-   MXC_ESDHC_CLK   = 88,
-   USDHC1_CLK_ROOT = 88,
-   MXC_ESDHC2_CLK  = 89,
-   USDHC2_CLK_ROOT = 89,
-   I2C1_CLK_ROOT   = 90,
-   MXC_I2C_CLK = 90,
-   I2C2_CLK_ROOT   = 91,
-   I2C3_CLK_ROOT   = 92,
-   I2C4_CLK_ROOT   = 93,
-   UART1_CLK_ROOT  = 94,
-   UART2_CLK_ROOT  = 95,
-   UART3_CLK_ROOT  = 96,
-   UART4_CLK_ROOT  = 97,
-   USB_CORE_REF_CLK_ROOT   = 98,
-   USB_PHY_REF_CLK_ROOT= 99,
-   GIC_CLK_ROOT= 100,
-   ECSPI1_CLK_ROOT = 101,
-   ECSPI2_CLK_ROOT = 102,
-   PWM1_CLK_ROOT   = 103,
-   PWM2_CLK_ROOT   = 104,
-   PWM3_CLK_ROOT   = 105,
-   PWM4_CLK_ROOT   = 106,
-   GPT1_CLK_ROOT   

[U-Boot] [PATCH v2 08/26] imx: spl: add spl_board_boot_device for i.MX8MM

2019-08-19 Thread Peng Fan
Differnet board has different controller used, it is
hard to use one layout for them all.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/spl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 1f230aca33..7ada60d7a2 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -18,6 +18,11 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+__weak int spl_board_boot_device(enum boot_device boot_dev_spl)
+{
+   return 0;
+}
+
 #if defined(CONFIG_MX6)
 /* determine boot device from SRC_SBMR1 (BOOT_CFG[4:1]) or SRC_GPR9 register */
 u32 spl_boot_device(void)
@@ -127,6 +132,9 @@ u32 spl_boot_device(void)
 
enum boot_device boot_device_spl = get_boot_device();
 
+   if (IS_ENABLED(CONFIG_IMX8MM))
+   return spl_board_boot_device(boot_device_spl);
+
switch (boot_device_spl) {
 #if defined(CONFIG_MX7)
case SD1_BOOT:
-- 
2.16.4

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


[U-Boot] [PATCH v2 12/26] imx8m: add pin header for i.MX8MM

2019-08-19 Thread Peng Fan
Add pin header file for i.MX8MM

To IMX8MM_PAD_NAND_WE_B_USDHC3_CLK, IOMUX_CONFIG_SION needs to be
selected.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h | 691 ++
 1 file changed, 691 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h

diff --git a/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h 
b/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h
new file mode 100644
index 00..210e96e1db
--- /dev/null
+++ b/arch/arm/include/asm/arch-imx8m/imx8mm_pins.h
@@ -0,0 +1,691 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018-2019 NXP
+ */
+
+#ifndef __ASM_ARCH_IMX8MM_PINS_H__
+#define __ASM_ARCH_IMX8MM_PINS_H__
+
+#include 
+
+enum {
+   IMX8MM_PAD_GPIO1_IO00_GPIO1_IO0   =  
IOMUX_PAD(0x0290, 0x0028, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO00_CCM_ENET_PHY_REF_CLK_ROOT   =  
IOMUX_PAD(0x0290, 0x0028, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO00_XTALOSC_REF_CLK_32K =  
IOMUX_PAD(0x0290, 0x0028, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO00_CCM_EXT_CLK1=  
IOMUX_PAD(0x0290, 0x0028, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO01_GPIO1_IO1   =  
IOMUX_PAD(0x0294, 0x002C, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO01_PWM1_OUT=  
IOMUX_PAD(0x0294, 0x002C, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO01_XTALOSC_REF_CLK_24M =  
IOMUX_PAD(0x0294, 0x002C, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO01_CCM_EXT_CLK2=  
IOMUX_PAD(0x0294, 0x002C, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO02_GPIO1_IO2   =  
IOMUX_PAD(0x0298, 0x0030, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_B=  
IOMUX_PAD(0x0298, 0x0030, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO02_WDOG1_WDOG_ANY  =  
IOMUX_PAD(0x0298, 0x0030, 5, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO03_GPIO1_IO3   =  
IOMUX_PAD(0x029C, 0x0034, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO03_USDHC1_VSELECT  =  
IOMUX_PAD(0x029C, 0x0034, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO03_SDMA1_EXT_EVENT0=  
IOMUX_PAD(0x029C, 0x0034, 5, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO04_GPIO1_IO4   =  
IOMUX_PAD(0x02A0, 0x0038, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO04_USDHC2_VSELECT  =  
IOMUX_PAD(0x02A0, 0x0038, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO04_SDMA1_EXT_EVENT1=  
IOMUX_PAD(0x02A0, 0x0038, 5, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO05_GPIO1_IO5   =  
IOMUX_PAD(0x02A4, 0x003C, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO05_ARM_PLATFORM_M4_NMI =  
IOMUX_PAD(0x02A4, 0x003C, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO05_CCM_PMIC_READY  =  
IOMUX_PAD(0x02A4, 0x003C, 5, 0x04BC, 0, 0),
+   IMX8MM_PAD_GPIO1_IO05_SRC_INT_BOOT=  
IOMUX_PAD(0x02A4, 0x003C, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO06_GPIO1_IO6   =  
IOMUX_PAD(0x02A8, 0x0040, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO06_ENET1_MDC   =  
IOMUX_PAD(0x02A8, 0x0040, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO06_USDHC1_CD_B =  
IOMUX_PAD(0x02A8, 0x0040, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO06_CCM_EXT_CLK3=  
IOMUX_PAD(0x02A8, 0x0040, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO07_GPIO1_IO7   =  
IOMUX_PAD(0x02AC, 0x0044, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO07_ENET1_MDIO  =  
IOMUX_PAD(0x02AC, 0x0044, 1, 0x04C0, 0, 0),
+   IMX8MM_PAD_GPIO1_IO07_USDHC1_WP   =  
IOMUX_PAD(0x02AC, 0x0044, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO07_CCM_EXT_CLK4=  
IOMUX_PAD(0x02AC, 0x0044, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO08_GPIO1_IO8   =  
IOMUX_PAD(0x02B0, 0x0048, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO08_ENET1_1588_EVENT0_IN=  
IOMUX_PAD(0x02B0, 0x0048, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO08_USDHC2_RESET_B  =  
IOMUX_PAD(0x02B0, 0x0048, 5, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO08_CCM_WAIT=  
IOMUX_PAD(0x02B0, 0x0048, 6, 0x, 0, 0),
+
+   IMX8MM_PAD_GPIO1_IO09_GPIO1_IO9   =  
IOMUX_PAD(0x02B4, 0x004C, 0, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO09_ENET1_1588_EVENT0_OUT   =  
IOMUX_PAD(0x02B4, 0x004C, 1, 0x, 0, 0),
+   IMX8MM_PAD_GPIO1_IO09_USDHC3_RESET_B  =  
IOMUX_PAD(0x02B4, 0x004C, 4, 0x, 

[U-Boot] [PATCH v2 16/26] imx8m: Configure trustzone region 0 for non-secure access

2019-08-19 Thread Peng Fan
From: Ye Li 

Set trustzone region 0 to allow both non-secure and secure access
when trust zone is enabled. We found USB controller fails to access
DDR if the default region 0 is secure access only.

Signed-off-by: Ye Li 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 261f586fc0..a33ca35653 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -57,6 +57,12 @@ void enable_tzc380(void)
setbits_le32(>gpr[10], GPR_TZASC_EN_LOCK);
if (IS_ENABLED(CONFIG_IMX8MM))
setbits_le32(>gpr[10], BIT(1));
+   /*
+* set Region 0 attribute to allow secure and non-secure
+* read/write permission. Found some masters like usb dwc3
+* controllers can't work with secure memory.
+*/
+   writel(0xf000, TZASC_BASE_ADDR + 0x108);
 }
 
 void set_wdog_reset(struct wdog_regs *wdog)
-- 
2.16.4

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


[U-Boot] [PATCH v2 06/26] imx: imx8mm: add clock bindings header

2019-08-19 Thread Peng Fan
Import clock bindings header file from Linux 5.3.0-rc2

Signed-off-by: Peng Fan 
---
 include/dt-bindings/clock/imx8mm-clock.h | 253 +++
 1 file changed, 253 insertions(+)
 create mode 100644 include/dt-bindings/clock/imx8mm-clock.h

diff --git a/include/dt-bindings/clock/imx8mm-clock.h 
b/include/dt-bindings/clock/imx8mm-clock.h
new file mode 100644
index 00..07e6c686f3
--- /dev/null
+++ b/include/dt-bindings/clock/imx8mm-clock.h
@@ -0,0 +1,253 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2017-2018 NXP
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_IMX8MM_H
+#define __DT_BINDINGS_CLOCK_IMX8MM_H
+
+#define IMX8MM_CLK_DUMMY   0
+#define IMX8MM_CLK_32K 1
+#define IMX8MM_CLK_24M 2
+#define IMX8MM_OSC_HDMI_CLK3
+#define IMX8MM_CLK_EXT14
+#define IMX8MM_CLK_EXT25
+#define IMX8MM_CLK_EXT36
+#define IMX8MM_CLK_EXT47
+#define IMX8MM_AUDIO_PLL1_REF_SEL  8
+#define IMX8MM_AUDIO_PLL2_REF_SEL  9
+#define IMX8MM_VIDEO_PLL1_REF_SEL  10
+#define IMX8MM_DRAM_PLL_REF_SEL11
+#define IMX8MM_GPU_PLL_REF_SEL 12
+#define IMX8MM_VPU_PLL_REF_SEL 13
+#define IMX8MM_ARM_PLL_REF_SEL 14
+#define IMX8MM_SYS_PLL1_REF_SEL15
+#define IMX8MM_SYS_PLL2_REF_SEL16
+#define IMX8MM_SYS_PLL3_REF_SEL17
+#define IMX8MM_AUDIO_PLL1  18
+#define IMX8MM_AUDIO_PLL2  19
+#define IMX8MM_VIDEO_PLL1  20
+#define IMX8MM_DRAM_PLL21
+#define IMX8MM_GPU_PLL 22
+#define IMX8MM_VPU_PLL 23
+#define IMX8MM_ARM_PLL 24
+#define IMX8MM_SYS_PLL125
+#define IMX8MM_SYS_PLL226
+#define IMX8MM_SYS_PLL327
+#define IMX8MM_AUDIO_PLL1_BYPASS   28
+#define IMX8MM_AUDIO_PLL2_BYPASS   29
+#define IMX8MM_VIDEO_PLL1_BYPASS   30
+#define IMX8MM_DRAM_PLL_BYPASS 31
+#define IMX8MM_GPU_PLL_BYPASS  32
+#define IMX8MM_VPU_PLL_BYPASS  33
+#define IMX8MM_ARM_PLL_BYPASS  34
+#define IMX8MM_SYS_PLL1_BYPASS 35
+#define IMX8MM_SYS_PLL2_BYPASS 36
+#define IMX8MM_SYS_PLL3_BYPASS 37
+#define IMX8MM_AUDIO_PLL1_OUT  38
+#define IMX8MM_AUDIO_PLL2_OUT  39
+#define IMX8MM_VIDEO_PLL1_OUT  40
+#define IMX8MM_DRAM_PLL_OUT41
+#define IMX8MM_GPU_PLL_OUT 42
+#define IMX8MM_VPU_PLL_OUT 43
+#define IMX8MM_ARM_PLL_OUT 44
+#define IMX8MM_SYS_PLL1_OUT45
+#define IMX8MM_SYS_PLL2_OUT46
+#define IMX8MM_SYS_PLL3_OUT47
+#define IMX8MM_SYS_PLL1_40M48
+#define IMX8MM_SYS_PLL1_80M49
+#define IMX8MM_SYS_PLL1_100M   50
+#define IMX8MM_SYS_PLL1_133M   51
+#define IMX8MM_SYS_PLL1_160M   52
+#define IMX8MM_SYS_PLL1_200M   53
+#define IMX8MM_SYS_PLL1_266M   54
+#define IMX8MM_SYS_PLL1_400M   55
+#define IMX8MM_SYS_PLL1_800M   56
+#define IMX8MM_SYS_PLL2_50M57
+#define IMX8MM_SYS_PLL2_100M   58
+#define IMX8MM_SYS_PLL2_125M   59
+#define IMX8MM_SYS_PLL2_166M   60
+#define IMX8MM_SYS_PLL2_200M   61
+#define IMX8MM_SYS_PLL2_250M   62
+#define IMX8MM_SYS_PLL2_333M   63
+#define IMX8MM_SYS_PLL2_500M   64
+#define IMX8MM_SYS_PLL2_1000M  65
+
+/* core */
+#define IMX8MM_CLK_A53_SRC 66
+#define IMX8MM_CLK_M4_SRC  67
+#define IMX8MM_CLK_VPU_SRC 68
+#define IMX8MM_CLK_GPU3D_SRC   69
+#define IMX8MM_CLK_GPU2D_SRC   70
+#define IMX8MM_CLK_A53_CG  71
+#define IMX8MM_CLK_M4_CG   72
+#define IMX8MM_CLK_VPU_CG  73
+#define IMX8MM_CLK_GPU3D_CG74
+#define IMX8MM_CLK_GPU2D_CG75
+#define IMX8MM_CLK_A53_DIV 76
+#define IMX8MM_CLK_M4_DIV  77
+#define IMX8MM_CLK_VPU_DIV 78
+#define IMX8MM_CLK_GPU3D_DIV   79
+#define IMX8MM_CLK_GPU2D_DIV   80
+
+/* bus */
+#define IMX8MM_CLK_MAIN_AXI81
+#define IMX8MM_CLK_ENET_AXI82

[U-Boot] [PATCH v2 18/26] imx8m: restrict reset_cpu

2019-08-19 Thread Peng Fan
Make reset_cpu only visible when CONFIG_SYSRESET not defined
or CONFIG_SPL_BUILD.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index ac80266010..3a54db4898 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -301,16 +301,21 @@ int ft_system_setup(void *blob, bd_t *bd)
 }
 #endif
 
+#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SYSRESET)
 void reset_cpu(ulong addr)
 {
-   struct watchdog_regs *wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
+   struct watchdog_regs *wdog = (struct watchdog_regs *)addr;
 
-   /* Clear WDA to trigger WDOG_B immediately */
-   writew((WCR_WDE | WCR_SRS), >wcr);
+   if (!addr)
+  wdog = (struct watchdog_regs *)WDOG1_BASE_ADDR;
 
-   while (1) {
-   /*
-* spin for .5 seconds before reset
-*/
-   }
+   /* Clear WDA to trigger WDOG_B immediately */
+   writew((WCR_WDE | WCR_SRS), >wcr);
+
+   while (1) {
+   /*
+* spin for .5 seconds before reset
+*/
+   }
 }
+#endif
-- 
2.16.4

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


[U-Boot] [PATCH v2 25/26] arm: dts: add i.MX8MM pin func

2019-08-19 Thread Peng Fan
Import i.MX8MM pin func from Linux Kernel,
commit <0a8ad0ffa4d8> ("Merge tag 'for-linus-5.3-ofs1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux")

Signed-off-by: Peng Fan 
---
 arch/arm/dts/imx8mm-pinfunc.h | 629 ++
 1 file changed, 629 insertions(+)
 create mode 100644 arch/arm/dts/imx8mm-pinfunc.h

diff --git a/arch/arm/dts/imx8mm-pinfunc.h b/arch/arm/dts/imx8mm-pinfunc.h
new file mode 100644
index 00..e25f7fcd79
--- /dev/null
+++ b/arch/arm/dts/imx8mm-pinfunc.h
@@ -0,0 +1,629 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2017-2018 NXP
+ */
+
+#ifndef __DTS_IMX8MM_PINFUNC_H
+#define __DTS_IMX8MM_PINFUNC_H
+
+/*
+ * The pin function ID is a tuple of
+ * 
+ */
+
+#define MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0   
0x028 0x290 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO00_CCMSRCGPCMIX_ENET_PHY_REF_CLK_ROOT  
0x028 0x290 0x4C0 0x1 0x0
+#define MX8MM_IOMUXC_GPIO1_IO00_ANAMIX_REF_CLK_32K  
0x028 0x290 0x000 0x5 0x0
+#define MX8MM_IOMUXC_GPIO1_IO00_CCMSRCGPCMIX_EXT_CLK1   
0x028 0x290 0x000 0x6 0x0
+#define MX8MM_IOMUXC_GPIO1_IO00_SJC_FAIL
0x028 0x290 0x000 0x7 0x0
+#define MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1   
0x02C 0x294 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT
0x02C 0x294 0x000 0x1 0x0
+#define MX8MM_IOMUXC_GPIO1_IO01_ANAMIX_REF_CLK_24M  
0x02C 0x294 0x4BC 0x5 0x0
+#define MX8MM_IOMUXC_GPIO1_IO01_CCMSRCGPCMIX_EXT_CLK2   
0x02C 0x294 0x000 0x6 0x0
+#define MX8MM_IOMUXC_GPIO1_IO01_SJC_ACTIVE  
0x02C 0x294 0x000 0x7 0x0
+#define MX8MM_IOMUXC_GPIO1_IO02_GPIO1_IO2   
0x030 0x298 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B
0x030 0x298 0x000 0x1 0x0
+#define MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_ANY  
0x030 0x298 0x000 0x5 0x0
+#define MX8MM_IOMUXC_GPIO1_IO02_SJC_DE_B
0x030 0x298 0x000 0x7 0x0
+#define MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3   
0x034 0x29C 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO03_USDHC1_VSELECT  
0x034 0x29C 0x000 0x1 0x0
+#define MX8MM_IOMUXC_GPIO1_IO03_SDMA1_EXT_EVENT0
0x034 0x29C 0x000 0x5 0x0
+#define MX8MM_IOMUXC_GPIO1_IO03_ANAMIX_XTAL_OK  
0x034 0x29C 0x000 0x6 0x0
+#define MX8MM_IOMUXC_GPIO1_IO03_SJC_DONE
0x034 0x29C 0x000 0x7 0x0
+#define MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4   
0x038 0x2A0 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT  
0x038 0x2A0 0x000 0x1 0x0
+#define MX8MM_IOMUXC_GPIO1_IO04_SDMA1_EXT_EVENT1
0x038 0x2A0 0x000 0x5 0x0
+#define MX8MM_IOMUXC_GPIO1_IO04_ANAMIX_XTAL_OK_LV   
0x038 0x2A0 0x000 0x6 0x0
+#define MX8MM_IOMUXC_GPIO1_IO04_USDHC1_TEST_TRIG
0x038 0x2A0 0x000 0x7 0x0
+#define MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5   
0x03C 0x2A4 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO05_M4_NMI  
0x03C 0x2A4 0x000 0x1 0x0
+#define MX8MM_IOMUXC_GPIO1_IO05_CCMSRCGPCMIX_PMIC_READY 
0x03C 0x2A4 0x000 0x5 0x0
+#define MX8MM_IOMUXC_GPIO1_IO05_CCMSRCGPCMIX_INT_BOOT   
0x03C 0x2A4 0x000 0x6 0x0
+#define MX8MM_IOMUXC_GPIO1_IO05_USDHC2_TEST_TRIG
0x03C 0x2A4 0x000 0x7 0x0
+#define MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6   
0x040 0x2A8 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO06_ENET1_MDC   
0x040 0x2A8 0x000 0x1 0x0
+#define MX8MM_IOMUXC_GPIO1_IO06_USDHC1_CD_B 
0x040 0x2A8 0x000 0x5 0x0
+#define MX8MM_IOMUXC_GPIO1_IO06_CCMSRCGPCMIX_EXT_CLK3   
0x040 0x2A8 0x000 0x6 0x0
+#define MX8MM_IOMUXC_GPIO1_IO06_ECSPI1_TEST_TRIG
0x040 0x2A8 0x000 0x7 0x0
+#define MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7   
0x044 0x2AC 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO07_ENET1_MDIO  
0x044 0x2AC 0x000 0x1 0x0
+#define MX8MM_IOMUXC_GPIO1_IO07_USDHC1_WP   
0x044 0x2AC 0x000 0x5 0x0
+#define MX8MM_IOMUXC_GPIO1_IO07_CCMSRCGPCMIX_EXT_CLK4   
0x044 0x2AC 0x000 0x6 0x0
+#define MX8MM_IOMUXC_GPIO1_IO07_ECSPI2_TEST_TRIG
0x044 0x2AC 0x000 0x7 0x0
+#define MX8MM_IOMUXC_GPIO1_IO08_GPIO1_IO8   
0x048 0x2B0 0x000 0x0 0x0
+#define MX8MM_IOMUXC_GPIO1_IO08_ENET1_1588_EVENT0_IN
0x048 

[U-Boot] [PATCH v2 15/26] imx8m: set BYPASS ID SWAP to avoid AXI bus errors

2019-08-19 Thread Peng Fan
set the BYPASS ID SWAP bit (GPR10 bit 1) in order for GPU not to
generated AXI bus errors with TZC380 enabled.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index dd393b581b..261f586fc0 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -55,6 +55,8 @@ void enable_tzc380(void)
/* Enable TZASC and lock setting */
setbits_le32(>gpr[10], GPR_TZASC_EN);
setbits_le32(>gpr[10], GPR_TZASC_EN_LOCK);
+   if (IS_ENABLED(CONFIG_IMX8MM))
+   setbits_le32(>gpr[10], BIT(1));
 }
 
 void set_wdog_reset(struct wdog_regs *wdog)
-- 
2.16.4

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


[U-Boot] [PATCH v2 11/26] imx: add get_cpu_rev support for i.MX8MM

2019-08-19 Thread Peng Fan
There are several variants based on i.MX8MM, add the support in
get_cpu_rev

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/soc.c | 57 +++
 1 file changed, 47 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 7ec39b3e47..5115471eff 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -130,25 +130,62 @@ static struct mm_region imx8m_mem_map[] = {
 
 struct mm_region *mem_map = imx8m_mem_map;
 
+static u32 get_cpu_variant_type(u32 type)
+{
+   struct ocotp_regs *ocotp = (struct ocotp_regs *)OCOTP_BASE_ADDR;
+   struct fuse_bank *bank = >bank[1];
+   struct fuse_bank1_regs *fuse =
+   (struct fuse_bank1_regs *)bank->fuse_regs;
+
+   u32 value = readl(>tester4);
+
+   if (type == MXC_CPU_IMX8MM) {
+   switch (value & 0x3) {
+   case 2:
+   if (value & 0x1c)
+   return MXC_CPU_IMX8MMDL;
+   else
+   return MXC_CPU_IMX8MMD;
+   case 3:
+   if (value & 0x1c)
+   return MXC_CPU_IMX8MMSL;
+   else
+   return MXC_CPU_IMX8MMS;
+   default:
+   if (value & 0x1c)
+   return MXC_CPU_IMX8MML;
+   break;
+   }
+   }
+
+   return type;
+}
+
 u32 get_cpu_rev(void)
 {
struct anamix_pll *ana_pll = (struct anamix_pll *)ANATOP_BASE_ADDR;
u32 reg = readl(_pll->digprog);
u32 type = (reg >> 16) & 0xff;
+   u32 major_low = (reg >> 8) & 0xff;
u32 rom_version;
 
reg &= 0xff;
 
-   if (reg == CHIP_REV_1_0) {
-   /*
-* For B0 chip, the DIGPROG is not updated, still TO1.0.
-* we have to check ROM version further
-*/
-   rom_version = readl((void __iomem *)ROM_VERSION_A0);
-   if (rom_version != CHIP_REV_1_0) {
-   rom_version = readl((void __iomem *)ROM_VERSION_B0);
-   if (rom_version >= CHIP_REV_2_0)
-   reg = CHIP_REV_2_0;
+   /* i.MX8MM */
+   if (major_low == 0x41) {
+   type = get_cpu_variant_type(MXC_CPU_IMX8MM);
+   } else {
+   if (reg == CHIP_REV_1_0) {
+   /*
+* For B0 chip, the DIGPROG is not updated, still TO1.0.
+* we have to check ROM version further
+*/
+   rom_version = readl((void __iomem *)ROM_VERSION_A0);
+   if (rom_version != CHIP_REV_1_0) {
+   rom_version = readl((void __iomem 
*)ROM_VERSION_B0);
+   if (rom_version >= CHIP_REV_2_0)
+   reg = CHIP_REV_2_0;
+   }
}
}
 
-- 
2.16.4

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


[U-Boot] [PATCH v2 19/26] imx8m: rename clock to clock_imx8mq

2019-08-19 Thread Peng Fan
i.MX8MQ and i.MX8MM has totally different pll design, so
rename clock to clock_imx8mq.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/Makefile| 3 ++-
 arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} | 0
 2 files changed, 2 insertions(+), 1 deletion(-)
 rename arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} (100%)

diff --git a/arch/arm/mach-imx/imx8m/Makefile b/arch/arm/mach-imx/imx8m/Makefile
index feff4941c1..42a1544c6b 100644
--- a/arch/arm/mach-imx/imx8m/Makefile
+++ b/arch/arm/mach-imx/imx8m/Makefile
@@ -3,4 +3,5 @@
 # Copyright 2017 NXP
 
 obj-y += lowlevel_init.o
-obj-y += clock.o clock_slice.o soc.o
+obj-y += clock_slice.o soc.o
+obj-$(CONFIG_IMX8MQ) += clock_imx8mq.o
diff --git a/arch/arm/mach-imx/imx8m/clock.c 
b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
similarity index 100%
rename from arch/arm/mach-imx/imx8m/clock.c
rename to arch/arm/mach-imx/imx8m/clock_imx8mq.c
-- 
2.16.4

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


[U-Boot] [PATCH v2 05/26] imx: add IMX8MM kconfig entry

2019-08-19 Thread Peng Fan
Add IMX8MM kconfig entry

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 9c487870a6..35c978e863 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -8,6 +8,10 @@ config IMX8MQ
bool
select IMX8M
 
+config IMX8MM
+   bool
+   select IMX8M
+
 config SYS_SOC
default "imx8m"
 
-- 
2.16.4

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


[U-Boot] [PATCH v2 07/26] imx: add i.MX8MM cpu type

2019-08-19 Thread Peng Fan
Add i.MX8MM cpu type and related helper functions

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx/cpu.h   |  6 ++
 arch/arm/include/asm/mach-imx/sys_proto.h |  8 
 arch/arm/mach-imx/cpu.c   | 12 
 3 files changed, 26 insertions(+)

diff --git a/arch/arm/include/asm/arch-imx/cpu.h 
b/arch/arm/include/asm/arch-imx/cpu.h
index d4a83eef72..4296e47b9e 100644
--- a/arch/arm/include/asm/arch-imx/cpu.h
+++ b/arch/arm/include/asm/arch-imx/cpu.h
@@ -25,6 +25,12 @@
 #define MXC_CPU_MX7S   0x71 /* dummy ID */
 #define MXC_CPU_MX7D   0x72
 #define MXC_CPU_IMX8MQ 0x82
+#define MXC_CPU_IMX8MM 0x85 /* dummy ID */
+#define MXC_CPU_IMX8MML0x86 /* dummy ID */
+#define MXC_CPU_IMX8MMD0x87 /* dummy ID */
+#define MXC_CPU_IMX8MMDL   0x88 /* dummy ID */
+#define MXC_CPU_IMX8MMS0x89 /* dummy ID */
+#define MXC_CPU_IMX8MMSL   0x8a /* dummy ID */
 #define MXC_CPU_IMX8QXP_A0 0x90 /* dummy ID */
 #define MXC_CPU_IMX8QM 0x91 /* dummy ID */
 #define MXC_CPU_IMX8QXP0x92 /* dummy ID */
diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h 
b/arch/arm/include/asm/mach-imx/sys_proto.h
index 4925dd7894..d01e71f506 100644
--- a/arch/arm/include/asm/mach-imx/sys_proto.h
+++ b/arch/arm/include/asm/mach-imx/sys_proto.h
@@ -43,6 +43,14 @@
 #define is_mx7ulp() (is_cpu_type(MXC_CPU_MX7ULP))
 
 #define is_imx8mq() (is_cpu_type(MXC_CPU_IMX8MQ))
+#define is_imx8mm() (is_cpu_type(MXC_CPU_IMX8MM) || 
is_cpu_type(MXC_CPU_IMX8MML) ||\
+   is_cpu_type(MXC_CPU_IMX8MMD) || is_cpu_type(MXC_CPU_IMX8MMDL) || \
+   is_cpu_type(MXC_CPU_IMX8MMS) || is_cpu_type(MXC_CPU_IMX8MMSL))
+#define is_imx8mml() (is_cpu_type(MXC_CPU_IMX8MML))
+#define is_imx8mmd() (is_cpu_type(MXC_CPU_IMX8MMD))
+#define is_imx8mmdl() (is_cpu_type(MXC_CPU_IMX8MMDL))
+#define is_imx8mms() (is_cpu_type(MXC_CPU_IMX8MMS))
+#define is_imx8mmsl() (is_cpu_type(MXC_CPU_IMX8MMSL))
 #define is_imx8qxp() (is_cpu_type(MXC_CPU_IMX8QXP))
 
 #ifdef CONFIG_MX6
diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
index 6e9a175210..60d12e6884 100644
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -145,6 +145,18 @@ unsigned imx_ddr_size(void)
 const char *get_imx_type(u32 imxtype)
 {
switch (imxtype) {
+   case MXC_CPU_IMX8MM:
+   return "8MMQ";  /* Quad-core version of the imx8mm */
+   case MXC_CPU_IMX8MML:
+   return "8MMQL"; /* Quad-core Lite version of the imx8mm */
+   case MXC_CPU_IMX8MMD:
+   return "8MMD";  /* Dual-core version of the imx8mm */
+   case MXC_CPU_IMX8MMDL:
+   return "8MMDL"; /* Dual-core Lite version of the imx8mm */
+   case MXC_CPU_IMX8MMS:
+   return "8MMS";  /* Single-core version of the imx8mm */
+   case MXC_CPU_IMX8MMSL:
+   return "8MMSL"; /* Single-core Lite version of the imx8mm */
case MXC_CPU_IMX8MQ:
return "8MQ";   /* Quad-core version of the imx8m */
case MXC_CPU_MX7S:
-- 
2.16.4

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


[U-Boot] [PATCH v2 03/26] imx8m: add image cfg for i.MX8MM lpddr4

2019-08-19 Thread Peng Fan
There is no HDMI on i.MX8MM, so we need to remove HDMI entry, then
we could not reuse imximage.cfg, so create a new one.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg

diff --git a/arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg 
b/arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg
new file mode 100644
index 00..1a2e43e671
--- /dev/null
+++ b/arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2019 NXP
+ */
+
+#define __ASSEMBLY__
+
+FIT
+BOOT_FROM  sd
+LOADER spl/u-boot-spl-ddr.bin  0x7E1000
+SECOND_LOADER  u-boot.itb  0x4020 0x6
+
+DDR_FW lpddr4_pmu_train_1d_imem.bin
+DDR_FW lpddr4_pmu_train_1d_dmem.bin
+DDR_FW lpddr4_pmu_train_2d_imem.bin
+DDR_FW lpddr4_pmu_train_2d_dmem.bin
-- 
2.16.4

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


[U-Boot] [PATCH v2 04/26] imx: add IMX8MQ kconfig entry

2019-08-19 Thread Peng Fan
Add IMX8MQ kconfig entry, preparing support IMX8MM

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8m/Kconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 317dee9bc1..9c487870a6 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -4,6 +4,10 @@ config IMX8M
bool
select ROM_UNIFIED_SECTIONS
 
+config IMX8MQ
+   bool
+   select IMX8M
+
 config SYS_SOC
default "imx8m"
 
@@ -13,7 +17,7 @@ choice
 
 config TARGET_IMX8MQ_EVK
bool "imx8mq_evk"
-   select IMX8M
+   select IMX8MQ
select IMX8M_LPDDR4
 
 endchoice
-- 
2.16.4

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


[U-Boot] [PATCH v2 01/26] tools: imx8m_image: align spl bin image size

2019-08-19 Thread Peng Fan
The loader for the DDR firmware in drivers/ddr/imx/imx8m/helper.c uses a
4-byte-aligned address to load the firmware. In cases where OF is
enabled in SPL the dtb will be appended to the SPL binary and can result
in a binary that is not aligned correctly. If OF is not enabled in SPL,
`_end` is already aligned correctly, but this patch does not hurt.

To ensure the correct alignment we use dd to create a temporary file
u-boot-spl-pad.bin with the correct padding.

Reviewed-by: Frieder Schrempf 
Tested-by: Frieder Schrempf 
Signed-off-by: Peng Fan 
---
 tools/imx8m_image.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/imx8m_image.sh b/tools/imx8m_image.sh
index ec0881a128..08a6a48180 100755
--- a/tools/imx8m_image.sh
+++ b/tools/imx8m_image.sh
@@ -35,8 +35,9 @@ if [ $post_process = 1 ]; then
objcopy -I binary -O binary --pad-to 0x8000 --gap-fill=0x0 
$srctree/lpddr4_pmu_train_2d_imem.bin lpddr4_pmu_train_2d_imem_pad.bin
cat lpddr4_pmu_train_1d_imem_pad.bin 
lpddr4_pmu_train_1d_dmem_pad.bin > lpddr4_pmu_train_1d_fw.bin
cat lpddr4_pmu_train_2d_imem_pad.bin 
$srctree/lpddr4_pmu_train_2d_dmem.bin > lpddr4_pmu_train_2d_fw.bin
-   cat spl/u-boot-spl.bin lpddr4_pmu_train_1d_fw.bin 
lpddr4_pmu_train_2d_fw.bin > spl/u-boot-spl-ddr.bin
-   rm -f lpddr4_pmu_train_1d_fw.bin lpddr4_pmu_train_2d_fw.bin 
lpddr4_pmu_train_1d_imem_pad.bin lpddr4_pmu_train_1d_dmem_pad.bin 
lpddr4_pmu_train_2d_imem_pad.bin
+   dd if=spl/u-boot-spl.bin of=spl/u-boot-spl-pad.bin bs=4 
conv=sync
+   cat spl/u-boot-spl-pad.bin lpddr4_pmu_train_1d_fw.bin 
lpddr4_pmu_train_2d_fw.bin > spl/u-boot-spl-ddr.bin
+   rm -f lpddr4_pmu_train_1d_fw.bin lpddr4_pmu_train_2d_fw.bin 
lpddr4_pmu_train_1d_imem_pad.bin lpddr4_pmu_train_1d_dmem_pad.bin 
lpddr4_pmu_train_2d_imem_pad.bin spl/u-boot-spl-pad.bin
fi
 fi
 
-- 
2.16.4

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


[U-Boot] [PATCH v2 02/26] ddr: imx8m: fix ddr firmware location when enable SPL OF

2019-08-19 Thread Peng Fan
With CONFIG_SPL_OF_CONTROL, the device tree will be padded to
end of the u-boot-spl-nodtb.bin, however we also put
the ddr firmware file to this location, so need to adapt
the code with SPL OF and align to 4bytes to ease copy firmware.

Reviewed-by: Frieder Schrempf 
Tested-by: Frieder Schrempf 
Signed-off-by: Peng Fan 
---
 drivers/ddr/imx/imx8m/helper.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/imx/imx8m/helper.c b/drivers/ddr/imx/imx8m/helper.c
index 61cd4f6db1..3e605353ea 100644
--- a/drivers/ddr/imx/imx8m/helper.c
+++ b/drivers/ddr/imx/imx8m/helper.c
@@ -31,7 +31,17 @@ void ddr_load_train_firmware(enum fw_type type)
unsigned long pr_to32, pr_from32;
unsigned long fw_offset = type ? IMEM_2D_OFFSET : 0;
unsigned long imem_start = (unsigned long)&_end + fw_offset;
-   unsigned long dmem_start = imem_start + IMEM_LEN;
+   unsigned long dmem_start;
+
+#ifdef CONFIG_SPL_OF_CONTROL
+   if (gd->fdt_blob && !fdt_check_header(gd->fdt_blob)) {
+   imem_start = roundup((unsigned long)&_end +
+fdt_totalsize(gd->fdt_blob), 4) +
+   fw_offset;
+   }
+#endif
+
+   dmem_start = imem_start + IMEM_LEN;
 
pr_from32 = imem_start;
pr_to32 = DDR_TRAIN_CODE_BASE_ADDR + 4 * IMEM_OFFSET_ADDR;
-- 
2.16.4

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


[U-Boot] [PATCH v2 00/26] i.MX8MM support

2019-08-19 Thread Peng Fan
V2:
Fixed comments from Lukasz and Frieder

V1:
https://patchwork.ozlabs.org/cover/1144326/
This is a splitted and updated patch from
https://patchwork.ozlabs.org/cover/1128799/ which is to support both
i.MX8MM and i.MX8MN.

There is a README added, following that to test if you would like to.

Peng Fan (25):
  tools: imx8m_image: align spl bin image size
  ddr: imx8m: fix ddr firmware location when enable SPL OF
  imx8m: add image cfg for i.MX8MM lpddr4
  imx: add IMX8MQ kconfig entry
  imx: add IMX8MM kconfig entry
  imx: imx8mm: add clock bindings header
  imx: add i.MX8MM cpu type
  imx: spl: add spl_board_boot_device for i.MX8MM
  imx8m: imx-regs: drop unused register definitions
  imx8m: update imx-regs for i.MX8MM
  imx: add get_cpu_rev support for i.MX8MM
  imx8m: add pin header for i.MX8MM
  imx: add i.MX8MM PE property
  imx8m: Fix MMU table issue for OPTEE memory
  imx8m: set BYPASS ID SWAP to avoid AXI bus errors
  imx8m: soc: enable SCTR clock before timer init
  imx8m: restrict reset_cpu
  imx8m: rename clock to clock_imx8mq
  imx8m: restructure clock.h
  imx8m: add clk support for i.MX8MM
  imx: mmc_env: update runtime SD/MMC boot env device
  imx8m: soc: probe clock device in arch_cpu_init_dm
  arm: dts: import i.MX8MM dtsi
  arm: dts: add i.MX8MM pin func
  imx: Add i.MX8MM EVK board support.

Ye Li (1):
  imx8m: Configure trustzone region 0 for non-secure access

 arch/arm/dts/Makefile  |3 +-
 arch/arm/dts/imx8mm-evk-u-boot.dtsi|   92 +
 arch/arm/dts/imx8mm-evk.dts|  235 +++
 arch/arm/dts/imx8mm-pinfunc.h  |  629 +++
 arch/arm/dts/imx8mm.dtsi   |  733 
 arch/arm/include/asm/arch-imx/cpu.h|6 +
 arch/arm/include/asm/arch-imx8m/clock.h|  491 +
 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h |  387 
 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h |  424 +
 arch/arm/include/asm/arch-imx8m/imx-regs.h |  291 +--
 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h  |  691 +++
 arch/arm/include/asm/mach-imx/iomux-v3.h   |4 +
 arch/arm/include/asm/mach-imx/sys_proto.h  |8 +
 arch/arm/mach-imx/cpu.c|   12 +
 arch/arm/mach-imx/imx8m/Kconfig|   17 +-
 arch/arm/mach-imx/imx8m/Makefile   |4 +-
 arch/arm/mach-imx/imx8m/clock_imx8mm.c |  306 +++
 .../arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} |5 +-
 arch/arm/mach-imx/imx8m/clock_slice.c  |   63 +
 arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg|   16 +
 arch/arm/mach-imx/imx8m/soc.c  |  129 +-
 arch/arm/mach-imx/mmc_env.c|3 +
 arch/arm/mach-imx/spl.c|8 +
 board/freescale/imx8mm_evk/Kconfig |   12 +
 board/freescale/imx8mm_evk/MAINTAINERS |6 +
 board/freescale/imx8mm_evk/Makefile|   12 +
 board/freescale/imx8mm_evk/imx8mm_evk.c|   45 +
 board/freescale/imx8mm_evk/lpddr4_timing.c | 1980 
 board/freescale/imx8mm_evk/spl.c   |  129 ++
 configs/imx8mm_evk_defconfig   |   74 +
 drivers/ddr/imx/imx8m/helper.c |   12 +-
 include/configs/imx8mm_evk.h   |  153 ++
 include/dt-bindings/clock/imx8mm-clock.h   |  253 +++
 tools/imx8m_image.sh   |5 +-
 34 files changed, 6535 insertions(+), 703 deletions(-)
 create mode 100644 arch/arm/dts/imx8mm-evk-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-evk.dts
 create mode 100644 arch/arm/dts/imx8mm-pinfunc.h
 create mode 100644 arch/arm/dts/imx8mm.dtsi
 create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mm.h
 create mode 100644 arch/arm/include/asm/arch-imx8m/clock_imx8mq.h
 create mode 100644 arch/arm/include/asm/arch-imx8m/imx8mm_pins.h
 create mode 100644 arch/arm/mach-imx/imx8m/clock_imx8mm.c
 rename arch/arm/mach-imx/imx8m/{clock.c => clock_imx8mq.c} (99%)
 create mode 100644 arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg
 create mode 100644 board/freescale/imx8mm_evk/Kconfig
 create mode 100644 board/freescale/imx8mm_evk/MAINTAINERS
 create mode 100644 board/freescale/imx8mm_evk/Makefile
 create mode 100644 board/freescale/imx8mm_evk/imx8mm_evk.c
 create mode 100644 board/freescale/imx8mm_evk/lpddr4_timing.c
 create mode 100644 board/freescale/imx8mm_evk/spl.c
 create mode 100644 configs/imx8mm_evk_defconfig
 create mode 100644 include/configs/imx8mm_evk.h
 create mode 100644 include/dt-bindings/clock/imx8mm-clock.h

-- 
2.16.4

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


Re: [U-Boot] [PATCH 2/2] libavb: Fix build warnings after updating the lib

2019-08-19 Thread Igor Opaniuk
Hi Eugeniu,

On Mon, Aug 19, 2019 at 11:28 AM Eugeniu Rosca  wrote:
>
> Hi all,
>
> On Fri, Aug 16, 2019 at 11:46:03AM -0400, David Zeuthen wrote:
> >Hi,
> >As for upstreaming libavb patches, I'd be interested in landing them
> >upstream... makes it easier for anyone.
> >Our upstream is AOSP and we use gerrit for
> >code-review: 
> > https://android-review.googlesource.com/q/project:platform%252Fexternal%252Favb
> >Here's a guide to
> >contributing: https://source.android.com/setup/contribute/submit-patches 
> > ...
> >hope it's not too painful to use the AOSP process!
> >Thanks,
> >David
>
> David, thanks for being open about discussing/accepting the fixes.
>
> U-Boot folks,
>
> What's your opinion w.r.t. the right/best order between accepting
> the libavb fixes locally in U-Boot and pushing them to upstream?
> Which should come first? I suppose they can be first applied internally
> and replaced later on if they get reworked/optimized during upstreaming.
>
> --
> Best Regards,
> Eugeniu.

IMHO, the best approach here is to upstream fixes to AOSP libavb first,
only then port stuff to U-boot.

Nevertheless, taking into account the amount of time needed
(sometimes it can take months, or even years, Sam has good
stories about that) to get something applied to AOSP, I would suggest
to proceed internally with commits like this ASAP, but somehow (extended
commit message for each "libavb sync" patch with the list of patches out of
AOSP tree; or introduce "doc/android/libavb-porting.txt", where we can
provide all details about list of commits from AOSP + out-of-tree commits,
how-to do porting etc; other ideas?) keep track of changes that are not
up-streamed to AOSP yet.

Ideally we have to achieve 1:1 mapping (with the only difference - SPDX tags),
of [1] in lib/libavb/, otherwise we will fight with constant code
divergence (obviously).

[1] https://android.googlesource.com/platform/external/avb/+//libavb

--
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1] x86: acpi: Slightly reduce binary size of ACPI tables for Tangier

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 5:17 PM Andy Shevchenko
 wrote:
>
> Using ACPI predefined macros, such as Zero or One, will reduce a binary size
> of resulting ACPI tables.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/include/asm/arch-tangier/acpi/platform.asl | 2 +-
>  arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>

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


Re: [U-Boot] [PATCH v1] tools: Add ifwitool to .gitignore

2019-08-19 Thread Bin Meng
On Mon, Aug 19, 2019 at 5:09 PM Andy Shevchenko
 wrote:
>
> Follow up fix to the commit
>
> 56bf4f863075 ("x86: Add ifwitool for Intel Integrated Firmware Image")
>
> in order to ignore created binary.
>
> Cc: Simon Glass 
> Signed-off-by: Andy Shevchenko 
> ---
>  tools/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
>

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


[U-Boot] [PATCH v1] x86: acpi: Slightly reduce binary size of ACPI tables for Tangier

2019-08-19 Thread Andy Shevchenko
Using ACPI predefined macros, such as Zero or One, will reduce a binary size
of resulting ACPI tables.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/include/asm/arch-tangier/acpi/platform.asl | 2 +-
 arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/arch-tangier/acpi/platform.asl 
b/arch/x86/include/asm/arch-tangier/acpi/platform.asl
index bd1aa9ce88..39bcaf3801 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/platform.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/platform.asl
@@ -18,7 +18,7 @@ Method(_PTS, 1)
 /* The _WAK method is called on system wakeup */
 Method(_WAK, 1)
 {
-Return (Package() {0, 0})
+Return (Package() { Zero, Zero })
 }
 
 Scope (\_SB)
diff --git a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl 
b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
index bb2a59dbc2..aedc62cc0c 100644
--- a/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
+++ b/arch/x86/include/asm/arch-tangier/acpi/southcluster.asl
@@ -10,8 +10,8 @@ Device (PCI0)
 Name (_HID, EISAID("PNP0A08"))/* PCIe */
 Name (_CID, EISAID("PNP0A03"))/* PCI */
 
-Name (_ADR, 0)
-Name (_BBN, 0)
+Name (_ADR, Zero)
+Name (_BBN, Zero)
 
 Name (MCRS, ResourceTemplate()
 {
-- 
2.23.0.rc1

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


[U-Boot] [PATCH v1] tools: Add ifwitool to .gitignore

2019-08-19 Thread Andy Shevchenko
Follow up fix to the commit

56bf4f863075 ("x86: Add ifwitool for Intel Integrated Firmware Image")

in order to ignore created binary.

Cc: Simon Glass 
Signed-off-by: Andy Shevchenko 
---
 tools/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/.gitignore b/tools/.gitignore
index 767b056b87..bd03d32f68 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -14,6 +14,7 @@
 /gen_eth_addr
 /gen_ethaddr_crc
 /ifdtool
+/ifwitool
 /img2srec
 /kwboot
 /lib/
-- 
2.23.0.rc1

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


Re: [U-Boot] [PATCH] test/py: Fix MMC/SD block write test dependency

2019-08-19 Thread Michal Simek
On 15. 08. 19 17:42, Stephen Warren wrote:
> On 8/15/19 12:26 AM, Michal Simek wrote:
>> On 14. 08. 19 17:51, Stephen Warren wrote:
>>> On 8/14/19 12:12 AM, Michal Simek wrote:
 On 13. 08. 19 23:21, Stephen Warren wrote:
> On 8/1/19 10:48 PM, Michal Simek wrote:
>> Test is using random command which has own Kconfig symbol CMD_RANDOM
>> which
>> already depends on CMD_MEMORY. That's why replace cmd_memory by
>> cmd_random.
>
> This might not always be true; I think it'd be better to keep the
> existing dependency list entries and just add CMD_RANDOM:

 Can you please tell me when exactly? I didn't see that.
>>>
>>> If in the future somebody changes the Kconfig file so that CMD_RANDOM
>>> doesn't depend on or select CMD_MEMORY. It may well not be possible
>>> right now; I just want to make sure the test doesn't rely on
>>> implementation details of CMD_RANDOM/CMD_MEMORY; if it explicitly needs
>>> both, it should simply depend on both.
>>
>> Do you think that we have used this rule in past?
> 
> I hope so; I'd consider it a bug in a test if the test used a command
> but didn't explicitly depend on that command's CONFIG_ flag. We have had
> such bugs in the past, and fixed one or two of them.
> 
>> Anyway I understand what you mean but it is questionable if make sense
>> to predict all changes which can happen.
> 
> It's more about the test explicitly specifying exactly what it depends
> on than predicting changes.
> 
>> I would consider if anybody
>> remove this dependency without fixing test suite as bug which should be
>> fixed. Also tests should detect this and report issues to stop this
>> before patch like this is applied.
> 
> True, but people do forget such things.

I have sent a patch. Feel free to fix commit message if needed.

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


[U-Boot] [PATCH] test/py: Add cmd_memory dependency back to test_mmc_wr

2019-08-19 Thread Michal Simek
Based on discussion with Stephen Warren there was recommendation to list
both memory and random command dependencies just in case that dependency is
not properly handled by Kconfig.

Fixes: a09c1f7e1c1b ("test/py: Fix MMC/SD block write test dependency")
Signed-off-by: Michal Simek 
---

 test/py/tests/test_mmc_wr.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/py/tests/test_mmc_wr.py b/test/py/tests/test_mmc_wr.py
index 7678c3c9c181..8b18781eac74 100644
--- a/test/py/tests/test_mmc_wr.py
+++ b/test/py/tests/test_mmc_wr.py
@@ -35,7 +35,7 @@ env__mmc_wr_configs = (
 
 """
 
-@pytest.mark.buildconfigspec('cmd_mmc','cmd_random')
+@pytest.mark.buildconfigspec('cmd_mmc','cmd_memory', 'cmd_random')
 def test_mmc_wr(u_boot_console, env__mmc_wr_config):
 """Test the "mmc write" command.
 
-- 
2.17.1

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


Re: [U-Boot] [PATCH 1/2] mmc: Fix timeout values passed to mmc_wait_dat0()

2019-08-19 Thread Igor Opaniuk
Hi Sam,
So you finally found it :)

On Wed, Aug 14, 2019 at 10:52 PM Sam Protsenko
 wrote:
>
> mmc_wait_dat0() expects timeout argument to be in usec units. But some
> overlying functions operate on timeout in msec units. Convert timeout
> from msec to usec when passing it to mmc_wait_dat0().
>
> This fixes 'avb' commands on BeagleBoard X15, because next chain was
> failing:
>
> get_partition() -> mmc_switch_part() -> __mmc_switch() ->
> mmc_wait_dat0()
>
> when passing incorrect timeout from __mmc_switch() to mmc_wait_dat0().
>
> Fixes: bb98b8c5c06a ("mmc: During a switch, poll on dat0 if available and 
> check the final status")
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/mmc/mmc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index eecc7d687e..e247730ff2 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -235,7 +235,7 @@ int mmc_poll_for_busy(struct mmc *mmc, int timeout)
> unsigned int status;
> int err;
>
> -   err = mmc_wait_dat0(mmc, 1, timeout);
> +   err = mmc_wait_dat0(mmc, 1, timeout * 1000);
> if (err != -ENOSYS)
> return err;
>
> @@ -778,7 +778,7 @@ static int __mmc_switch(struct mmc *mmc, u8 set, u8 
> index, u8 value,
> start = get_timer(0);
>
> /* poll dat0 for rdy/buys status */
> -   ret = mmc_wait_dat0(mmc, 1, timeout);
> +   ret = mmc_wait_dat0(mmc, 1, timeout * 1000);
> if (ret && ret != -ENOSYS)
> return ret;
>
> --
> 2.20.1
>

Tested-by: Igor Opaniuk 
Reviewed-by: Igor Opaniuk 

-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk

mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] mmc: Rename timeout parameters for clarification

2019-08-19 Thread Igor Opaniuk
Hi Sam,

On Wed, Aug 14, 2019 at 10:53 PM Sam Protsenko
 wrote:
>
> It's quite hard to figure out time units for various function that have
> timeout parameters. This leads to possible errors when one forgets to
> convert ms to us, for example. Let's rename those parameters
> correspondingly to 'timeout_us' and 'timeout_ms' to prevent such issues
> further.
>
> While at it, add time units info as comments to struct mmc fields.
>
> This commit doesn't change the behavior, only renames parameters names.
> Buildman should report no changes at all.
>
> Signed-off-by: Sam Protsenko 
> ---
>  drivers/mmc/mmc-uclass.c   |  8 
>  drivers/mmc/mmc.c  | 24 
>  drivers/mmc/mmc_write.c|  8 
>  drivers/mmc/omap_hsmmc.c   |  6 +++---
>  drivers/mmc/renesas-sdhi.c |  7 ---
>  include/mmc.h  | 12 ++--
>  6 files changed, 33 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
> index 551007905c..f740bae3c7 100644
> --- a/drivers/mmc/mmc-uclass.c
> +++ b/drivers/mmc/mmc-uclass.c
> @@ -47,18 +47,18 @@ int mmc_set_ios(struct mmc *mmc)
> return dm_mmc_set_ios(mmc->dev);
>  }
>
> -int dm_mmc_wait_dat0(struct udevice *dev, int state, int timeout)
> +int dm_mmc_wait_dat0(struct udevice *dev, int state, int timeout_us)
>  {
> struct dm_mmc_ops *ops = mmc_get_ops(dev);
>
> if (!ops->wait_dat0)
> return -ENOSYS;
> -   return ops->wait_dat0(dev, state, timeout);
> +   return ops->wait_dat0(dev, state, timeout_us);
>  }
>
> -int mmc_wait_dat0(struct mmc *mmc, int state, int timeout)
> +int mmc_wait_dat0(struct mmc *mmc, int state, int timeout_us)
>  {
> -   return dm_mmc_wait_dat0(mmc->dev, state, timeout);
> +   return dm_mmc_wait_dat0(mmc->dev, state, timeout_us);
>  }
>
>  int dm_mmc_get_wp(struct udevice *dev)
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index e247730ff2..c8f71cd0c1 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -31,7 +31,7 @@ static int mmc_select_mode_and_width(struct mmc *mmc, uint 
> card_caps);
>
>  #if !CONFIG_IS_ENABLED(DM_MMC)
>
> -static int mmc_wait_dat0(struct mmc *mmc, int state, int timeout)
> +static int mmc_wait_dat0(struct mmc *mmc, int state, int timeout_us)
>  {
> return -ENOSYS;
>  }
> @@ -230,12 +230,12 @@ int mmc_send_status(struct mmc *mmc, unsigned int 
> *status)
> return -ECOMM;
>  }
>
> -int mmc_poll_for_busy(struct mmc *mmc, int timeout)
> +int mmc_poll_for_busy(struct mmc *mmc, int timeout_ms)
>  {
> unsigned int status;
> int err;
>
> -   err = mmc_wait_dat0(mmc, 1, timeout * 1000);
> +   err = mmc_wait_dat0(mmc, 1, timeout_ms * 1000);
> if (err != -ENOSYS)
> return err;
>
> @@ -256,13 +256,13 @@ int mmc_poll_for_busy(struct mmc *mmc, int timeout)
> return -ECOMM;
> }
>
> -   if (timeout-- <= 0)
> +   if (timeout_ms-- <= 0)
> break;
>
> udelay(1000);
> }
>
> -   if (timeout <= 0) {
> +   if (timeout_ms <= 0) {
>  #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
> pr_err("Timeout waiting card ready\n");
>  #endif
> @@ -750,17 +750,17 @@ static int __mmc_switch(struct mmc *mmc, u8 set, u8 
> index, u8 value,
>  {
> unsigned int status, start;
> struct mmc_cmd cmd;
> -   int timeout = DEFAULT_CMD6_TIMEOUT_MS;
> +   int timeout_ms = DEFAULT_CMD6_TIMEOUT_MS;
> bool is_part_switch = (set == EXT_CSD_CMD_SET_NORMAL) &&
>   (index == EXT_CSD_PART_CONF);
> int retries = 3;
> int ret;
>
> if (mmc->gen_cmd6_time)
> -   timeout = mmc->gen_cmd6_time * 10;
> +   timeout_ms = mmc->gen_cmd6_time * 10;
>
> if (is_part_switch  && mmc->part_switch_time)
> -   timeout = mmc->part_switch_time * 10;
> +   timeout_ms = mmc->part_switch_time * 10;
>
> cmd.cmdidx = MMC_CMD_SWITCH;
> cmd.resp_type = MMC_RSP_R1b;
> @@ -778,7 +778,7 @@ static int __mmc_switch(struct mmc *mmc, u8 set, u8 
> index, u8 value,
> start = get_timer(0);
>
> /* poll dat0 for rdy/buys status */
> -   ret = mmc_wait_dat0(mmc, 1, timeout * 1000);
> +   ret = mmc_wait_dat0(mmc, 1, timeout_ms * 1000);
> if (ret && ret != -ENOSYS)
> return ret;
>
> @@ -788,11 +788,11 @@ static int __mmc_switch(struct mmc *mmc, u8 set, u8 
> index, u8 value,
>  * stated timeout to be sufficient.
>  */
> if (ret == -ENOSYS && !send_status)
> -   mdelay(timeout);
> +   mdelay(timeout_ms);
>
> /* Finally wait until the card is ready or indicates a failure
>  * to switch. It doesn't hurt to use CMD13 here even if send_status
> -* is false, because by now (after 'timeout' 

  1   2   >