[U-Boot] [PATCH v2 0/5] Marvell DB-XC3-24G4XG board support

[Chris Packham]

This series adds support for Marvell's Switches with integrated CPUs and
the DB-XC3-24G4XG board. The CPU side is similar to the Armada range.

For now the DDR training code needs to come from the Marvell bin_hdr.
It's one area where the integrated SoCs differ from the Armada range so
neither the Armada-XP nor Armada-38x training code will work as-is. I'm
asking Marvell about the possibility of re-licensing the code under a
Proprietary/BSD/GPL as they did with Armada-38x.

I also have access to a DB-DXBC2-MM board with a different chip. I'll
look at adding support for that as well at some point. It's harder to
work with because it has no USB, but other than that it's similar to the
DB-XC3.

Changes in v2:
- use CONFIG_ARMADA_MSYS instead of just CONFIG_MSYS
- Disable MBUS Error proagation
- new, split out from Add DB-XC3-24G4XG board with a better explanation
- u-boot specific changes in u-boot.dtsi
- remove unnecessary entries from board config.h
- move some changes to earlier patches

Chris Packham (5):
  arm: sync armada-xp dts files from Linux 5.0
  arm: mvebu: Add Marvell's integrated CPUs
  arm: mvebu: NAND clock support for MSYS devices
  tools: kwbimage: don't adjust for image_header for Armada MSYS
  arm: mvebu: Add DB-XC3-24G4XG board

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/armada-370-xp.dtsi   | 133 +++
 arch/arm/dts/armada-xp-98dx3236.dtsi  | 343 ++
 arch/arm/dts/armada-xp-98dx3336.dtsi  |  39 ++
 arch/arm/dts/armada-xp-98dx4251.dtsi  |  54 +++
 .../dts/armada-xp-db-xc3-24g4xg-u-boot.dtsi   |  24 ++
 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts  | 110 ++
 arch/arm/dts/armada-xp-gp.dts | 167 -
 arch/arm/dts/armada-xp-maxbcm.dts |  24 +-
 arch/arm/dts/armada-xp-mv78230.dtsi   |  55 +--
 arch/arm/dts/armada-xp-mv78260.dtsi   |  58 +--
 arch/arm/dts/armada-xp-mv78460.dtsi   |  58 +--
 arch/arm/dts/armada-xp-synology-ds414.dts | 199 +-
 arch/arm/dts/armada-xp-theadorable.dts|  69 ++--
 arch/arm/dts/armada-xp.dtsi   | 214 ++-
 arch/arm/mach-mvebu/Kconfig   |  26 +-
 arch/arm/mach-mvebu/Makefile  |   1 +
 arch/arm/mach-mvebu/cpu.c |  33 +-
 arch/arm/mach-mvebu/include/mach/config.h |   2 +-
 arch/arm/mach-mvebu/include/mach/cpu.h|   3 +
 arch/arm/mach-mvebu/include/mach/soc.h|  31 ++
 arch/arm/mach-mvebu/mbus.c|   5 +
 board/Marvell/db-xc3-24g4xg/MAINTAINERS   |   7 +
 board/Marvell/db-xc3-24g4xg/Makefile  |   5 +
 board/Marvell/db-xc3-24g4xg/README|   4 +
 board/Marvell/db-xc3-24g4xg/binary.0  |  11 +
 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c   |  68 
 board/Marvell/db-xc3-24g4xg/kwbimage.cfg  |  12 +
 configs/db-xc3-24g4xg_defconfig   |  55 +++
 drivers/ddr/marvell/axp/xor_regs.h|   4 +
 include/configs/db-xc3-24g4xg.h   |  41 +++
 tools/Makefile|   4 +
 tools/kwbimage.c  |   4 +
 33 files changed, 1319 insertions(+), 547 deletions(-)
 create mode 100644 arch/arm/dts/armada-xp-98dx3236.dtsi
 create mode 100644 arch/arm/dts/armada-xp-98dx3336.dtsi
 create mode 100644 arch/arm/dts/armada-xp-98dx4251.dtsi
 create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg-u-boot.dtsi
 create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts
 create mode 100644 board/Marvell/db-xc3-24g4xg/MAINTAINERS
 create mode 100644 board/Marvell/db-xc3-24g4xg/Makefile
 create mode 100644 board/Marvell/db-xc3-24g4xg/README
 create mode 100644 board/Marvell/db-xc3-24g4xg/binary.0
 create mode 100644 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c
 create mode 100644 board/Marvell/db-xc3-24g4xg/kwbimage.cfg
 create mode 100644 configs/db-xc3-24g4xg_defconfig
 create mode 100644 include/configs/db-xc3-24g4xg.h

-- 
2.20.1

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

Re: [U-Boot] Pull request: u-boot-sunxi/master

[Tom Rini]

On Thu, Feb 14, 2019 at 10:50:11PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> PR about some random fixes.
> 
> Summary:
> - MMC CD pin fix on Orangepi Zero plus
> - SPI boot for  Olinuxino Lime2-eMMC boards
> - Change in dram frequnecy for tbs_a711
> 
> The following changes since commit dbe70c7d4e3d5c705a98d82952e05a591efd0683:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-02-10 08:11:53 
> -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to d065a6c00a63c2f441bb8b5d31407c5e10da9612:
> 
>   configs: tbs_a711: lower dram frequency (2019-02-12 17:25:44 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] efi_loader: Swap roles with Heinrich

[Tom Rini]

On Thu, Feb 14, 2019 at 02:35:17PM +0100, Alexander Graf wrote:

> Heinrich is going to take over maintainership of the efi_loader tree
> going forward.
> 
> To ensure that I will still receive review mails at least, add me as
> reviewer with a stable email address.
> 
> Signed-off-by: Alexander Graf 

Thanks again for all your efforts on the project!

Reviewed-by: Tom Rini 

-- 
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] rpi: Make Matthias maintainer

[Tom Rini]

On Thu, Feb 14, 2019 at 02:37:59PM +0100, Alexander Graf wrote:

> Matthias Brugger agreed to take over maintainership from me for the
> Raspberry Pi tree. Add him to the MAINTAINERS file instead.
> 
> Signed-off-by: Alexander Graf 

Reviewed-by: Tom Rini 

-- 
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 2/2] cmd: bootefi: rework do_bootefi()

[Heinrich Schuchardt]

On 2/14/19 8:56 AM, AKASHI Takahiro wrote:
> In this patch, do_bootefi() will be reworked, without any functional
> change, as it is a bit sloppy after Heinrich's "efi_loader: rework
> loading and starting of images."
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  cmd/bootefi.c | 101 ++
>  1 file changed, 52 insertions(+), 49 deletions(-)

I agree that cmd/bootefi.c is not very easy to read.

We just went through a refactoring by Simon in v2019.01.

- With your proposal the total code does not get any shorter.
- The function modules do not get shorter.
- No bug is resolved.

I tend to revisit this after switching both the bootmgr and the
non-bootmgr paths to call LoadImage() and relying on Exit() to clean up
the image.

> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index e064edcd0cdb..159dc1ab8a30 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -361,34 +361,68 @@ err_add_protocol:
>   return ret;
>  }
>  
> -static int do_bootefi_bootmgr_exec(void)
> +static int do_bootefi_load_and_exec(const char *arg)
>  {
> - struct efi_device_path *device_path, *file_path;
> - void *addr;
> + void *image_buf;
> + struct efi_device_path *device_path, *image_path;
> + const char *saddr;
> + unsigned long addr, size;

Please, use a pointer when referring to an address in memory and size_t
when referring to the difference between two pointers.

Outside of GCC there is no rule requiring unsigned long to have the size
of a pointer.

>   efi_status_t r;
>  
> - addr = efi_bootmgr_load(_path, _path);
> - if (!addr)
> - return 1;
> + if (!strcmp(arg, "bootmgr")) {
> + image_buf = efi_bootmgr_load(_path, _path);
> + if (!image_buf)
> + return CMD_RET_FAILURE;
> +
> + addr = map_to_sysmem(image_buf);
> + } else
> +#ifdef CONFIG_CMD_BOOTEFI_HELLO
> + if (!strcmp(arg, "hello")) {
> + saddr = env_get("loadaddr");
> + size = __efi_helloworld_end - __efi_helloworld_begin;
> +
> + if (saddr)
> + addr = simple_strtoul(saddr, NULL, 16);
> + else
> + addr = CONFIG_SYS_LOAD_ADDR;
> +
> + image_buf = map_sysmem(addr, size);
> + memcpy(image_buf, __efi_helloworld_begin, size);
> +
> + device_path = NULL;
> + image_path = NULL;
> + } else/a
> +#endif
> + {
> + saddr = arg;
> + size = 0;
> +
> + addr = simple_strtoul(saddr, NULL, 16);
> + /* Check that a numeric value was passed */
> + if (!addr && *saddr != '0')
> + return CMD_RET_USAGE;
> +
> + image_buf = map_sysmem(addr, size);
> +
> + device_path = bootefi_device_path;
> + image_path = bootefi_image_path;
> + }
>  
> - printf("## Starting EFI application at %p ...\n", addr);
> - r = do_bootefi_exec(addr, device_path, file_path);
> - printf("## Application terminated, r = %lu\n",
> -r & ~EFI_ERROR_MASK);
> + printf("## Starting EFI application at %08lx ...\n", addr);

Can we be sure we will never load above 4 GiB? Using %p is a better choice.

> + r = do_bootefi_exec(image_buf, device_path, image_path);
> + printf("## Application terminated, r = %lu\n", r & ~EFI_ERROR_MASK);
>  
>   if (r != EFI_SUCCESS)
> - return 1;
> + return CMD_RET_FAILURE;

That's the style I prefer (and Simon dislikes).

>  
> - return 0;
> + return CMD_RET_SUCCESS;

Best regards

Heinrich

>  }
>  
>  /* Interpreter command to boot an arbitrary EFI image from memory */
>  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[])
>  {
> - unsigned long addr;
> - char *saddr;
> - efi_status_t r;
>   unsigned long fdt_addr;
> + efi_status_t r;
>  
>   /* Allow unaligned memory access */
>   allow_unaligned();
> @@ -421,18 +455,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
>   efi_install_configuration_table(_guid_fdt, NULL);
>   printf("WARNING: booting without device tree\n");
>   }
> -#ifdef CONFIG_CMD_BOOTEFI_HELLO
> - if (!strcmp(argv[1], "hello")) {
> - ulong size = __efi_helloworld_end - __efi_helloworld_begin;
>  
> - saddr = env_get("loadaddr");
> - if (saddr)
> - addr = simple_strtoul(saddr, NULL, 16);
> - else
> - addr = CONFIG_SYS_LOAD_ADDR;
> - memcpy(map_sysmem(addr, size), __efi_helloworld_begin, size);
> - } else
> -#endif
>  #ifdef CONFIG_CMD_BOOTEFI_SELFTEST
>   if (!strcmp(argv[1], "selftest")) {
>   struct efi_loaded_image_obj *image_obj;
> @@ -447,30 +470,10 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[])
>

[U-Boot] [PATCH V2 1/2] davinci: da850evm: Move BSS to SDRAM because SRAM is full

[Adam Ford]

In order to fully support SPL_OF_CONTROL, we need BSS to be a bit
larger. This patch relocates BSS to SDRAM instead of SRAM which
is similar to how ARMv7 boards (like OMAP2+) do it.

This means two new variables are required:
CONFIG_SPL_BSS_START_ADDR  set to DAVINCI_DDR_EMIF_DATA_BASE
CONFIG_SPL_BSS_MAX_SIZE is set to 0x108 which is 1 byte
before the location where U-Boot will load.

Signed-off-by: Adam Ford 
---
V2:  No Change

diff --git a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds 
b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
index 7b5fab7756..8f04911306 100644
--- a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
+++ b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
@@ -10,6 +10,9 @@
 MEMORY { .sram : ORIGIN = IMAGE_TEXT_BASE,\
LENGTH = CONFIG_SPL_MAX_FOOTPRINT }
 
+MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \
+LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
+
 OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
 OUTPUT_ARCH(arm)
 ENTRY(_start)
@@ -42,6 +45,15 @@ SECTIONS
__rel_dyn_end = .;
} >.sram
 
+   __image_copy_end = .;
+
+   .end :
+   {
+   *(.__end)
+   }
+
+   _image_binary_end = .;
+
.bss :
{
. = ALIGN(4);
@@ -49,12 +61,5 @@ SECTIONS
*(.bss*)
. = ALIGN(4);
__bss_end = .;
-   } >.sram
-
-   __image_copy_end = .;
-
-   .end :
-   {
-   *(.__end)
-   }
+   } >.sdram
 }
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 14a3046f19..bb549e363a 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -48,7 +48,8 @@
 #define PHYS_SDRAM_1   DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */
 #define PHYS_SDRAM_1_SIZE  (64 << 20) /* SDRAM size 64MB */
 #define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/
-
+#define CONFIG_SPL_BSS_START_ADDR DAVINCI_DDR_EMIF_DATA_BASE
+#define CONFIG_SPL_BSS_MAX_SIZE 0x108
 /* memtest start addr */
 #define CONFIG_SYS_MEMTEST_START   (PHYS_SDRAM_1 + 0x200)
 
-- 
2.17.1

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

[U-Boot] [PATCH V2 2/2] ARM: davinci: da850evm: Enable SPL_OF_CONTROL without PLATDATA

[Adam Ford]

With the memory mapping giving us some more avialable RAM, this
updates the da850-evm-u-boot.dtsi to include the serial port, SPI
and Flash nodes along with some dependent nodes in the SPL dtb.
This also removes the platform data initialization code for the
serial port and SPI Flash.

Signed-off-by: Adam Ford 
---
V2:  Add da850evm_nand_defconfig to build with DT as well

diff --git a/arch/arm/dts/da850-evm-u-boot.dtsi 
b/arch/arm/dts/da850-evm-u-boot.dtsi
index ab1de77954..ab9368b9d3 100644
--- a/arch/arm/dts/da850-evm-u-boot.dtsi
+++ b/arch/arm/dts/da850-evm-u-boot.dtsi
@@ -6,6 +6,24 @@
  * Copyright (C) Adam Ford
  */
 
+/ {
+   soc@1c0 {
+   u-boot,dm-spl;
+   };
+};
+
  {
compatible = "m25p64", "spi-flash";
 };
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index b0b29b3887..e8ec553f99 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -49,33 +49,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define CFG_MAC_ADDR_OFFSET(flash->size - SZ_64K)
 
-#ifdef CONFIG_SPL_BUILD
-#include 
-#include 
-
-static const struct ns16550_platdata da850evm_serial = {
-   .base = DAVINCI_UART2_BASE,
-   .reg_shift = 2,
-   .clock = 15000,
-   .fcr = UART_FCR_DEFVAL,
-};
-
-U_BOOT_DEVICE(da850evm_uart) = {
-   .name = "ns16550_serial",
-   .platdata = _serial,
-};
-
-static const struct davinci_spi_platdata davinci_spi_data = {
-.regs = (struct davinci_spi_regs *)0x01f0e000,
-.num_cs = 4,
-};
-
-U_BOOT_DEVICE(davinci_spi) = {
-.name = "davinci_spi",
-.platdata = _spi_data,
-};
-#endif
-
 #ifdef CONFIG_MAC_ADDR_IN_SPIFLASH
 static int get_mac_addr(u8 *addr)
 {
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index 41dae05fb9..4b09ba10a6 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_DAVINCI=y
 CONFIG_SYS_TEXT_BASE=0xc108
 CONFIG_TARGET_DA850EVM=y
@@ -13,6 +14,7 @@ CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SYS_EXTRA_OPTIONS="MAC_ADDR_IN_SPIFLASH"
 CONFIG_BOOTDELAY=3
+CONFIG_DEFAULT_FDT_FILE="da850-evm.dtb"
 CONFIG_MISC_INIT_R=y
 CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_CPUINFO is not set
@@ -20,6 +22,7 @@ CONFIG_VERSION_VARIABLE=y
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot > "
@@ -39,10 +42,11 @@ CONFIG_CMD_DIAG=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="da850-evm"
-CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_DM_GPIO=y
 CONFIG_DA8XX_GPIO=y
 CONFIG_DM_I2C=y
diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
index 48b7c2a97a..af5ba813c2 100644
--- a/configs/da850evm_nand_defconfig
+++ b/configs/da850evm_nand_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_DAVINCI=y
 CONFIG_SYS_TEXT_BASE=0xc108
 CONFIG_TARGET_DA850EVM=y
@@ -12,12 +13,14 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_SYS_EXTRA_OPTIONS="MAC_ADDR_IN_SPIFLASH"
 CONFIG_BOOTDELAY=3
+CONFIG_DEFAULT_FDT_FILE="da850-evm.dtb"
 CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
@@ -37,13 +40,15 @@ CONFIG_CMD_DIAG=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="da850-evm"
-CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_DM_GPIO=y
 CONFIG_DA8XX_GPIO=y
 CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
 CONFIG_NAND=y
 CONFIG_NAND_DAVINCI=y
 CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
-- 
2.17.1

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

[U-Boot] [PATCH 2/2] ARM: davinci: da850evm: Enable SPL_OF_CONTROL without PLATDATA

[Adam Ford]

With the memory mapping giving us some more avialable RAM, this
updates the da850-evm-u-boot.dtsi to include the serial port, SPI
and Flash nodes along with some dependent nodes in the SPL dtb.
This also removes the platform data initialization code for the
serial port and SPI Flash.

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/da850-evm-u-boot.dtsi 
b/arch/arm/dts/da850-evm-u-boot.dtsi
index ab1de77954..ab9368b9d3 100644
--- a/arch/arm/dts/da850-evm-u-boot.dtsi
+++ b/arch/arm/dts/da850-evm-u-boot.dtsi
@@ -6,6 +6,24 @@
  * Copyright (C) Adam Ford
  */
 
+/ {
+   soc@1c0 {
+   u-boot,dm-spl;
+   };
+};
+
  {
compatible = "m25p64", "spi-flash";
 };
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index b0b29b3887..e8ec553f99 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -49,33 +49,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define CFG_MAC_ADDR_OFFSET(flash->size - SZ_64K)
 
-#ifdef CONFIG_SPL_BUILD
-#include 
-#include 
-
-static const struct ns16550_platdata da850evm_serial = {
-   .base = DAVINCI_UART2_BASE,
-   .reg_shift = 2,
-   .clock = 15000,
-   .fcr = UART_FCR_DEFVAL,
-};
-
-U_BOOT_DEVICE(da850evm_uart) = {
-   .name = "ns16550_serial",
-   .platdata = _serial,
-};
-
-static const struct davinci_spi_platdata davinci_spi_data = {
-.regs = (struct davinci_spi_regs *)0x01f0e000,
-.num_cs = 4,
-};
-
-U_BOOT_DEVICE(davinci_spi) = {
-.name = "davinci_spi",
-.platdata = _spi_data,
-};
-#endif
-
 #ifdef CONFIG_MAC_ADDR_IN_SPIFLASH
 static int get_mac_addr(u8 *addr)
 {
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index 41dae05fb9..4b09ba10a6 100644
--- a/configs/da850evm_defconfig
+++ b/configs/da850evm_defconfig
@@ -1,4 +1,5 @@
 CONFIG_ARM=y
+CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_DAVINCI=y
 CONFIG_SYS_TEXT_BASE=0xc108
 CONFIG_TARGET_DA850EVM=y
@@ -13,6 +14,7 @@ CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SYS_EXTRA_OPTIONS="MAC_ADDR_IN_SPIFLASH"
 CONFIG_BOOTDELAY=3
+CONFIG_DEFAULT_FDT_FILE="da850-evm.dtb"
 CONFIG_MISC_INIT_R=y
 CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_CPUINFO is not set
@@ -20,6 +22,7 @@ CONFIG_VERSION_VARIABLE=y
 CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot > "
@@ -39,10 +42,11 @@ CONFIG_CMD_DIAG=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="da850-evm"
-CONFIG_SPL_OF_PLATDATA=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_DM_GPIO=y
 CONFIG_DA8XX_GPIO=y
 CONFIG_DM_I2C=y
diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig
index 48b7c2a97a..e3309cfe44 100644
--- a/configs/da850evm_nand_defconfig
+++ b/configs/da850evm_nand_defconfig
@@ -44,6 +44,7 @@ CONFIG_SPL_DM=y
 CONFIG_DM_GPIO=y
 CONFIG_DA8XX_GPIO=y
 CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
 CONFIG_NAND=y
 CONFIG_NAND_DAVINCI=y
 CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
-- 
2.17.1

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

[U-Boot] [PATCH 1/2] davinci: da850evm: Move BSS to SDRAM because SRAM is full

[Adam Ford]

In order to fully support SPL_OF_CONTROL, we need BSS to be a bit
larger. This patch relocates BSS to SDRAM instead of SRAM which
is similar to how ARMv7 boards (like OMAP2+) do it.

This means two new variables are required:
CONFIG_SPL_BSS_START_ADDR  set to DAVINCI_DDR_EMIF_DATA_BASE
CONFIG_SPL_BSS_MAX_SIZE is set to 0x108 which is 1 byte
before the location where U-Boot will load.

Signed-off-by: Adam Ford 

diff --git a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds 
b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
index 7b5fab7756..8f04911306 100644
--- a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
+++ b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
@@ -10,6 +10,9 @@
 MEMORY { .sram : ORIGIN = IMAGE_TEXT_BASE,\
LENGTH = CONFIG_SPL_MAX_FOOTPRINT }
 
+MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR, \
+LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
+
 OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
 OUTPUT_ARCH(arm)
 ENTRY(_start)
@@ -42,6 +45,15 @@ SECTIONS
__rel_dyn_end = .;
} >.sram
 
+   __image_copy_end = .;
+
+   .end :
+   {
+   *(.__end)
+   }
+
+   _image_binary_end = .;
+
.bss :
{
. = ALIGN(4);
@@ -49,12 +61,5 @@ SECTIONS
*(.bss*)
. = ALIGN(4);
__bss_end = .;
-   } >.sram
-
-   __image_copy_end = .;
-
-   .end :
-   {
-   *(.__end)
-   }
+   } >.sdram
 }
diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
index 14a3046f19..bb549e363a 100644
--- a/include/configs/da850evm.h
+++ b/include/configs/da850evm.h
@@ -48,7 +48,8 @@
 #define PHYS_SDRAM_1   DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */
 #define PHYS_SDRAM_1_SIZE  (64 << 20) /* SDRAM size 64MB */
 #define CONFIG_MAX_RAM_BANK_SIZE (512 << 20) /* max size from SPRS586*/
-
+#define CONFIG_SPL_BSS_START_ADDR DAVINCI_DDR_EMIF_DATA_BASE
+#define CONFIG_SPL_BSS_MAX_SIZE 0x108
 /* memtest start addr */
 #define CONFIG_SYS_MEMTEST_START   (PHYS_SDRAM_1 + 0x200)
 
-- 
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] cmd: bootefi: move bootefi_test_prepare() forward

[Heinrich Schuchardt]

On 2/14/19 8:56 AM, AKASHI Takahiro wrote:
> This is a preparatory patch for reworking do_bootefi().
> 
> Signed-off-by: AKASHI Takahiro 

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

[U-Boot] [PATCH 2/2] test: adjust names of Unicode test functions

[Heinrich Schuchardt]

In test/py/conftest.py the assumption is made that for if a test is called
with `ut unicode` the test function name starts with 'unicode_test_'. As
the Unicode tests did not follow this naming scheme they were not executed
by `make tests`.

Rename the Unicode test functions.

Signed-off-by: Heinrich Schuchardt 
---
 test/unicode_ut.c | 98 +++
 1 file changed, 49 insertions(+), 49 deletions(-)

diff --git a/test/unicode_ut.c b/test/unicode_ut.c
index 84fc9a3b53..8e1efe6f69 100644
--- a/test/unicode_ut.c
+++ b/test/unicode_ut.c
@@ -50,7 +50,7 @@ static const char j1[] = {0x6a, 0x31, 0xa1, 0x6c, 0x00};
 static const char j2[] = {0x6a, 0x32, 0xc3, 0xc3, 0x6c, 0x00};
 static const char j3[] = {0x6a, 0x33, 0xf0, 0x90, 0xf0, 0x00};
 
-static int ut_u16_strdup(struct unit_test_state *uts)
+static int unicode_test_u16_strdup(struct unit_test_state *uts)
 {
u16 *copy = u16_strdup(c4);
 
@@ -59,9 +59,9 @@ static int ut_u16_strdup(struct unit_test_state *uts)
free(copy);
return 0;
 }
-UNICODE_TEST(ut_u16_strdup);
+UNICODE_TEST(unicode_test_u16_strdup);
 
-static int ut_u16_strcpy(struct unit_test_state *uts)
+static int unicode_test_u16_strcpy(struct unit_test_state *uts)
 {
u16 *r;
u16 copy[10];
@@ -71,11 +71,11 @@ static int ut_u16_strcpy(struct unit_test_state *uts)
ut_assert(!memcmp(copy, c1, sizeof(c1)));
return 0;
 }
-UNICODE_TEST(ut_u16_strcpy);
+UNICODE_TEST(unicode_test_u16_strcpy);
 
 /* U-Boot uses UTF-16 strings in the EFI context only. */
 #if CONFIG_IS_ENABLED(EFI_LOADER) && !defined(API_BUILD)
-static int ut_string16(struct unit_test_state *uts)
+static int unicode_test_string16(struct unit_test_state *uts)
 {
char buf[20];
 
@@ -113,10 +113,10 @@ static int ut_string16(struct unit_test_state *uts)
 
return 0;
 }
-UNICODE_TEST(ut_string16);
+UNICODE_TEST(unicode_test_string16);
 #endif
 
-static int ut_utf8_get(struct unit_test_state *uts)
+static int unicode_test_utf8_get(struct unit_test_state *uts)
 {
const char *s;
s32 code;
@@ -152,9 +152,9 @@ static int ut_utf8_get(struct unit_test_state *uts)
 
return 0;
 }
-UNICODE_TEST(ut_utf8_get);
+UNICODE_TEST(unicode_test_utf8_get);
 
-static int ut_utf8_put(struct unit_test_state *uts)
+static int unicode_test_utf8_put(struct unit_test_state *uts)
 {
char buffer[8] = { 0, };
char *pos;
@@ -190,9 +190,9 @@ static int ut_utf8_put(struct unit_test_state *uts)
 
return 0;
 }
-UNICODE_TEST(ut_utf8_put);
+UNICODE_TEST(unicode_test_utf8_put);
 
-static int ut_utf8_utf16_strlen(struct unit_test_state *uts)
+static int unicode_test_utf8_utf16_strlen(struct unit_test_state *uts)
 {
ut_asserteq(6, utf8_utf16_strlen(d1));
ut_asserteq(8, utf8_utf16_strlen(d2));
@@ -206,9 +206,9 @@ static int ut_utf8_utf16_strlen(struct unit_test_state *uts)
 
return 0;
 }
-UNICODE_TEST(ut_utf8_utf16_strlen);
+UNICODE_TEST(unicode_test_utf8_utf16_strlen);
 
-static int ut_utf8_utf16_strnlen(struct unit_test_state *uts)
+static int unicode_test_utf8_utf16_strnlen(struct unit_test_state *uts)
 {
ut_asserteq(3, utf8_utf16_strnlen(d1, 3));
ut_asserteq(6, utf8_utf16_strnlen(d1, 13));
@@ -224,7 +224,7 @@ static int ut_utf8_utf16_strnlen(struct unit_test_state 
*uts)
 
return 0;
 }
-UNICODE_TEST(ut_utf8_utf16_strnlen);
+UNICODE_TEST(unicode_test_utf8_utf16_strnlen);
 
 /**
  * ut_u16_strcmp() - Compare to u16 strings.
@@ -234,7 +234,7 @@ UNICODE_TEST(ut_utf8_utf16_strnlen);
  * @count: number of u16 to compare
  * Return: -1 if a1 < a2, 0 if a1 == a2, 1 if a1 > a2
  */
-static int ut_u16_strcmp(const u16 *a1, const u16 *a2, size_t count)
+static int unicode_test_u16_strcmp(const u16 *a1, const u16 *a2, size_t count)
 {
for (; (*a1 || *a2) && count; ++a1, ++a2, --count) {
if (*a1 < *a2)
@@ -245,7 +245,7 @@ static int ut_u16_strcmp(const u16 *a1, const u16 *a2, 
size_t count)
return 0;
 }
 
-static int ut_utf8_utf16_strcpy(struct unit_test_state *uts)
+static int unicode_test_utf8_utf16_strcpy(struct unit_test_state *uts)
 {
u16 buf[16];
u16 *pos;
@@ -253,44 +253,44 @@ static int ut_utf8_utf16_strcpy(struct unit_test_state 
*uts)
pos = buf;
utf8_utf16_strcpy(, d1);
ut_asserteq(6, pos - buf);
-   ut_assert(!ut_u16_strcmp(buf, c1, SIZE_MAX));
+   ut_assert(!unicode_test_u16_strcmp(buf, c1, SIZE_MAX));
 
pos = buf;
utf8_utf16_strcpy(, d2);
ut_asserteq(8, pos - buf);
-   ut_assert(!ut_u16_strcmp(buf, c2, SIZE_MAX));
+   ut_assert(!unicode_test_u16_strcmp(buf, c2, SIZE_MAX));
 
pos = buf;
utf8_utf16_strcpy(, d3);
ut_asserteq(3, pos - buf);
-   ut_assert(!ut_u16_strcmp(buf, c3, SIZE_MAX));
+   ut_assert(!unicode_test_u16_strcmp(buf, c3, SIZE_MAX));
 
pos = buf;
utf8_utf16_strcpy(, d4);
ut_asserteq(6, pos - buf);
-   

[U-Boot] [PATCH 0/2] lib/vsprintf: print '?' for illegal Unicode sequence

[Heinrich Schuchardt]

Commit 0e66c10a7d80 ("lib: vsprintf: avoid overflow printing UTF16
strings") broke the Unicode unit tests: an illegal UTF16 code point
should be printed as '?'.

Unfortunately the Unicode unit tests were never executed on Travis due to
an unmet naming convention. So let's rename the Unicode test functions.

Heinrich Schuchardt (2):
  lib/vsprintf: print '?' for illegal Unicode sequence
  test: adjust names of Unicode test functions

 lib/vsprintf.c|  2 +
 test/unicode_ut.c | 98 +++
 2 files changed, 51 insertions(+), 49 deletions(-)

-- 
2.20.1

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

[U-Boot] [PATCH 1/2] lib/vsprintf: print '?' for illegal Unicode sequence

[Heinrich Schuchardt]

Commit 0e66c10a7d80 ("lib: vsprintf: avoid overflow printing UTF16
strings") broke the Unicode unit tests: an illegal UTF16 code point
should be printed as '?'.

Fixes: 0e66c10a7d80 ("lib: vsprintf: avoid overflow printing UTF16 strings")
Signed-off-by: Heinrich Schuchardt 
---
 lib/vsprintf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index de5db1aa5c..1b6c154d8d 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -288,6 +288,8 @@ static char *string16(char *buf, char *end, u16 *s, int 
field_width,
for (i = 0; i < len && buf + utf16_utf8_strnlen(str, 1) <= end; ++i) {
s32 s = utf16_get();
 
+   if (s < 0)
+   s = '?';
utf8_put(s, );
}
for (; len < field_width; --field_width)
-- 
2.20.1

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

[U-Boot] [PATCH v2 4/5] tools: kwbimage: don't adjust for image_header for Armada MSYS

[Chris Packham]

For the time being the Armada MSYS SoCs need to use the bin_hdr from the
Marvell U-Boot. Because of this the binary.0 does not contain the image
header that a proper u-boot SPL would so the adjustment introduced by
commit 94084eea3bd3 ("tools: kwbimage: Fix dest addr") does not apply.

Signed-off-by: Chris Packham 
---

Changes in v2:
- new, split out from Add DB-XC3-24G4XG board with a better explanation

 tools/Makefile   | 4 
 tools/kwbimage.c | 4 
 2 files changed, 8 insertions(+)

diff --git a/tools/Makefile b/tools/Makefile
index 081383d7a790..d99098d6167a 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -148,6 +148,10 @@ ifneq ($(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X),)
 HOSTCFLAGS_kwbimage.o += -DCONFIG_KWB_SECURE
 endif
 
+ifneq ($(CONFIG_ARMADA_MSYS),)
+HOSTCFLAGS_kwbimage.o += -DCONFIG_KWB_DESTADDR_COMPAT
+endif
+
 # MXSImage needs LibSSL
 ifneq 
($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE),)
 HOSTLOADLIBES_mkimage += \
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index a88a3830c0c8..4c60679fbb53 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1252,8 +1252,12 @@ static void *image_create_v1(size_t *imagesz, struct 
image_tool_params *params,
cpu_to_le32(payloadsz - headersz + sizeof(uint32_t));
main_hdr->headersz_lsb = cpu_to_le16(headersz & 0x);
main_hdr->headersz_msb = (headersz & 0x) >> 16;
+#ifdef CONFIG_KWB_DESTADDR_COMPAT
+   main_hdr->destaddr = cpu_to_le32(params->addr);
+#else
main_hdr->destaddr = cpu_to_le32(params->addr)
 - sizeof(image_header_t);
+#endif
main_hdr->execaddr = cpu_to_le32(params->ep);
main_hdr->srcaddr  = cpu_to_le32(headersz);
main_hdr->ext  = hasext;
-- 
2.20.1

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

[U-Boot] [PATCH v2 5/5] arm: mvebu: Add DB-XC3-24G4XG board

[Chris Packham]

From: Chris Packham 

The DB-XC3-24G4XG is a switch development board from Marvell. It can
either use and external CPU card such as the db-88f6820-amc or the
internal CPU that is integrated into the switch.

Add support for running U-Boot on the internal CPU and enable the USB,
SPI and NAND peripherals. For now this needs the bin_hdr from the
Marvell U-Boot for this board.

Signed-off-by: Chris Packham 
---

Changes in v2:
- u-boot specific changes in u-boot.dtsi
- remove unnecessary entries from board config.h
- move some changes to earlier patches

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/armada-xp-98dx3236.dtsi  | 343 ++
 arch/arm/dts/armada-xp-98dx3336.dtsi  |  39 ++
 arch/arm/dts/armada-xp-98dx4251.dtsi  |  54 +++
 .../dts/armada-xp-db-xc3-24g4xg-u-boot.dtsi   |  24 ++
 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts  | 110 ++
 arch/arm/mach-mvebu/Kconfig   |   8 +
 board/Marvell/db-xc3-24g4xg/MAINTAINERS   |   7 +
 board/Marvell/db-xc3-24g4xg/Makefile  |   5 +
 board/Marvell/db-xc3-24g4xg/README|   4 +
 board/Marvell/db-xc3-24g4xg/binary.0  |  11 +
 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c   |  68 
 board/Marvell/db-xc3-24g4xg/kwbimage.cfg  |  12 +
 configs/db-xc3-24g4xg_defconfig   |  55 +++
 include/configs/db-xc3-24g4xg.h   |  41 +++
 15 files changed, 783 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/armada-xp-98dx3236.dtsi
 create mode 100644 arch/arm/dts/armada-xp-98dx3336.dtsi
 create mode 100644 arch/arm/dts/armada-xp-98dx4251.dtsi
 create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg-u-boot.dtsi
 create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts
 create mode 100644 board/Marvell/db-xc3-24g4xg/MAINTAINERS
 create mode 100644 board/Marvell/db-xc3-24g4xg/Makefile
 create mode 100644 board/Marvell/db-xc3-24g4xg/README
 create mode 100644 board/Marvell/db-xc3-24g4xg/binary.0
 create mode 100644 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c
 create mode 100644 board/Marvell/db-xc3-24g4xg/kwbimage.cfg
 create mode 100644 configs/db-xc3-24g4xg_defconfig
 create mode 100644 include/configs/db-xc3-24g4xg.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ca5062348087..133f09d8ba63 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -113,7 +113,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-xp-theadorable.dtb   \
armada-38x-controlcenterdc.dtb  \
armada-385-atl-x530.dtb \
-   armada-385-atl-x530DP.dtb
+   armada-385-atl-x530DP.dtb   \
+   armada-xp-db-xc3-24g4xg.dtb
 
 dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \
uniphier-ld11-global.dtb \
diff --git a/arch/arm/dts/armada-xp-98dx3236.dtsi 
b/arch/arm/dts/armada-xp-98dx3236.dtsi
new file mode 100644
index ..5df1d1848dbc
--- /dev/null
+++ b/arch/arm/dts/armada-xp-98dx3236.dtsi
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree Include file for Marvell 98dx3236 family SoC
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Contains definitions specific to the 98dx3236 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+#include "armada-370-xp.dtsi"
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   model = "Marvell 98DX3236 SoC";
+   compatible = "marvell,armadaxp-98dx3236", "marvell,armada-370-xp";
+
+   aliases {
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "marvell,98dx3236-smp";
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "marvell,sheeva-v7";
+   reg = <0>;
+   clocks = < 0>;
+   clock-latency = <100>;
+   };
+   };
+
+   soc {
+   compatible = "marvell,armadaxp-mbus", "simple-bus";
+
+   ranges = ;
+
+   bootrom {
+   compatible = "marvell,bootrom";
+   reg = ;
+   };
+
+   /*
+* 98DX3236 has 1 x1 PCIe unit Gen2.0
+*/
+   pciec: pcie@8200 {
+   compatible = "marvell,armada-xp-pcie";
+   status = "disabled";
+   device_type = "pci";
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   msi-parent = <>;
+   bus-range = <0x00 0xff>;
+
+   ranges =
+  <0x8200 0 0x4 MBUS_ID(0xf0, 0x01) 
0x4 0 0x2000   /* Port 0.0 registers */
+   0x8200 0x1 0   MBUS_ID(0x04, 0xe8) 0 1 
0 /* Port 

[U-Boot] [PATCH v2 3/5] arm: mvebu: NAND clock support for MSYS devices

[Chris Packham]

One difference with the integrated CPUs is that they use a different
clock control block to the Armada devices. Update mvebu_get_nand_clock()
accordingly.

Signed-off-by: Chris Packham 
---
This could probably be squashed into the previous change. I was trying
to separate things to aid review but it's hard to do so and keep
bisectability.

Changes in v2: None

 arch/arm/mach-mvebu/cpu.c  |  2 ++
 arch/arm/mach-mvebu/include/mach/soc.h | 11 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 61b222a21070..5609ee2f9a3b 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -499,6 +499,8 @@ u32 mvebu_get_nand_clock(void)
 
if (mvebu_soc_family() == MVEBU_SOC_A38X)
reg = MVEBU_DFX_DIV_CLK_CTRL(1);
+   else if (mvebu_soc_family() == MVEBU_SOC_MSYS)
+   reg = MVEBU_DFX_DIV_CLK_CTRL(8);
else
reg = MVEBU_CORE_DIV_CLK_CTRL(1);
 
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
b/arch/arm/mach-mvebu/include/mach/soc.h
index 2d88c410b88c..f666ee24243b 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -100,9 +100,20 @@
 #define SPI_PUP_EN BIT(5)
 
 #define MVEBU_CORE_DIV_CLK_CTRL(i) (MVEBU_CLOCK_BASE + ((i) * 0x8))
+#ifdef CONFIG_ARMADA_MSYS
+#define MVEBU_DFX_DIV_CLK_CTRL(i)  (MVEBU_DFX_BASE + 0xf8000 + 0x250 + 
((i) * 0x4))
+#define NAND_ECC_DIVCKL_RATIO_OFFS 6
+#define NAND_ECC_DIVCKL_RATIO_MASK (0xF << NAND_ECC_DIVCKL_RATIO_OFFS)
+#else
 #define MVEBU_DFX_DIV_CLK_CTRL(i)  (MVEBU_DFX_BASE + 0x250 + ((i) * 0x4))
+#endif
+#ifdef CONFIG_ARMADA_MSYS
+#define NAND_ECC_DIVCKL_RATIO_OFFS 6
+#define NAND_ECC_DIVCKL_RATIO_MASK (0xF << NAND_ECC_DIVCKL_RATIO_OFFS)
+#else
 #define NAND_ECC_DIVCKL_RATIO_OFFS 8
 #define NAND_ECC_DIVCKL_RATIO_MASK (0x3F << NAND_ECC_DIVCKL_RATIO_OFFS)
+#endif
 
 #define SDRAM_MAX_CS   4
 #define SDRAM_ADDR_MASK0xFF00
-- 
2.20.1

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

[U-Boot] [PATCH v2 2/5] arm: mvebu: Add Marvell's integrated CPUs

[Chris Packham]

Marvell's switch chips with integrated CPUs (collectively referred to as
MSYS) share common ancestry with the Armada SoCs. Some of the IP blocks
(e.g. xor) are located at different addresses and DFX server exists as a
separate target on the MBUS (on Armada-38x it's just part of the core
complex registers).

Signed-off-by: Chris Packham 
---

Changes in v2:
- use CONFIG_ARMADA_MSYS instead of just CONFIG_MSYS
- Disable MBUS Error proagation

 arch/arm/mach-mvebu/Kconfig   | 18 -
 arch/arm/mach-mvebu/Makefile  |  1 +
 arch/arm/mach-mvebu/cpu.c | 31 +--
 arch/arm/mach-mvebu/include/mach/config.h |  2 +-
 arch/arm/mach-mvebu/include/mach/cpu.h|  3 +++
 arch/arm/mach-mvebu/include/mach/soc.h| 20 +++
 arch/arm/mach-mvebu/mbus.c|  5 
 drivers/ddr/marvell/axp/xor_regs.h|  4 +++
 8 files changed, 80 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 7dda04e0e34e..08c9972f02d7 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -46,7 +46,7 @@ config ARMADA_8K
 # Armada PLL frequency (used for NAND clock generation)
 config SYS_MVEBU_PLL_CLOCK
int
-   default "20" if ARMADA_XP || ARMADA_3700 || ARMADA_8K
+   default "20" if ARMADA_XP || ARMADA_3700 || ARMADA_8K || 
ARMADA_MSYS
default "10" if ARMADA_38X || ARMADA_375
 
 # Armada XP/38x SoC types...
@@ -63,6 +63,22 @@ config MV78460
bool
select ARMADA_XP
 
+config ARMADA_MSYS
+   bool
+   select ARMADA_32BIT
+
+config 98DX4251
+   bool
+   select ARMADA_MSYS
+
+config 98DX3336
+   bool
+   select ARMADA_MSYS
+
+config 98DX3236
+   bool
+   select ARMADA_MSYS
+
 config 88F6820
bool
select ARMADA_38X
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index ee2eca913484..2ab7b3c8417e 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -24,6 +24,7 @@ ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_ARMADA_375) += ../../../drivers/ddr/marvell/axp/xor.o
 obj-$(CONFIG_ARMADA_38X) += ../../../drivers/ddr/marvell/a38x/xor.o
 obj-$(CONFIG_ARMADA_XP) += ../../../drivers/ddr/marvell/axp/xor.o
+obj-$(CONFIG_ARMADA_MSYS) += ../../../drivers/ddr/marvell/axp/xor.o
 obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
 
 extra-y += kwbimage.cfg
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 919d05c88c77..61b222a21070 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -23,6 +23,11 @@ static struct mbus_win windows[] = {
/* NOR */
{ MBUS_BOOTROM_BASE, MBUS_BOOTROM_SIZE,
  CPU_TARGET_DEVICEBUS_BOOTROM_SPI, CPU_ATTR_BOOTROM },
+
+#ifdef CONFIG_ARMADA_MSYS
+   /* DFX */
+   { MBUS_DFX_BASE, MBUS_DFX_SIZE, CPU_TARGET_DFX, 0 },
+#endif
 };
 
 void lowlevel_init(void)
@@ -121,6 +126,14 @@ static const struct sar_freq_modes sar_freq_tab[] = {
{ 0x13,  0x0, 2000, 1000, 933 },
{ 0xff, 0xff,0,0,   0 } /* 0xff marks end of array */
 };
+#elif defined(CONFIG_ARMADA_MSYS)
+static const struct sar_freq_modes sar_freq_tab[] = {
+   {  0x0, 0x0,  400,  400, 400 },
+   {  0x2, 0x0,  667,  333, 667 },
+   {  0x3, 0x0,  800,  400, 800 },
+   {  0x5, 0x0,  800,  400, 800 },
+   { 0xff, 0xff,0,   0,   0 }  /* 0xff marks end of array */
+};
 #else
 /* SAR frequency values for Armada XP */
 static const struct sar_freq_modes sar_freq_tab[] = {
@@ -144,7 +157,7 @@ void get_sar_freq(struct sar_freq_modes *sar_freq)
u32 freq;
int i;
 
-#if defined(CONFIG_ARMADA_375)
+#if defined(CONFIG_ARMADA_375) || defined(CONFIG_ARMADA_MSYS)
val = readl(CONFIG_SAR2_REG);   /* SAR - Sample At Reset */
 #else
val = readl(CONFIG_SAR_REG);/* SAR - Sample At Reset */
@@ -160,7 +173,7 @@ void get_sar_freq(struct sar_freq_modes *sar_freq)
 #endif
for (i = 0; sar_freq_tab[i].val != 0xff; i++) {
if (sar_freq_tab[i].val == freq) {
-#if defined(CONFIG_ARMADA_375) || defined(CONFIG_ARMADA_38X)
+#if defined(CONFIG_ARMADA_375) || defined(CONFIG_ARMADA_38X) || 
defined(CONFIG_ARMADA_MSYS)
*sar_freq = sar_freq_tab[i];
return;
 #else
@@ -270,6 +283,20 @@ int print_cpuinfo(void)
}
}
 
+   if (mvebu_soc_family() == MVEBU_SOC_MSYS) {
+   switch (revid) {
+   case 3:
+   puts("A0");
+   break;
+   case 4:
+   puts("A1");
+   break;
+   default:
+   printf("?? (%x)", revid);
+   break;
+   }
+   }
+
get_sar_freq(_freq);
printf(" at %d MHz\n", sar_freq.p_clk);
 
diff --git a/arch/arm/mach-mvebu/include/mach/config.h 
b/arch/arm/mach-mvebu/include/mach/config.h

[U-Boot] [PATCH v2 1/5] arm: sync armada-xp dts files from Linux 5.0

[Chris Packham]

Bring in the Armada 370/XP dts/dtsi files from Linux. As U-Boot hasn't
got the new NAND driver the updating binding has not been included.

Signed-off-by: Chris Packham 
---

Changes in v2: None

 arch/arm/dts/armada-370-xp.dtsi   | 133 ++
 arch/arm/dts/armada-xp-gp.dts | 167 +++--
 arch/arm/dts/armada-xp-maxbcm.dts |  24 +--
 arch/arm/dts/armada-xp-mv78230.dtsi   |  55 ++
 arch/arm/dts/armada-xp-mv78260.dtsi   |  58 ++
 arch/arm/dts/armada-xp-mv78460.dtsi   |  58 ++
 arch/arm/dts/armada-xp-synology-ds414.dts | 199 ++--
 arch/arm/dts/armada-xp-theadorable.dts|  69 +++
 arch/arm/dts/armada-xp.dtsi   | 214 --
 9 files changed, 435 insertions(+), 542 deletions(-)

diff --git a/arch/arm/dts/armada-370-xp.dtsi b/arch/arm/dts/armada-370-xp.dtsi
index 0b2a78d39301..e4c35d4e98f4 100644
--- a/arch/arm/dts/armada-370-xp.dtsi
+++ b/arch/arm/dts/armada-370-xp.dtsi
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
  * Device Tree Include file for Marvell Armada 370 and Armada XP SoC
  *
@@ -8,50 +9,10 @@
  * Thomas Petazzoni 
  * Ben Dooks 
  *
- * This file is dual-licensed: you can use it either under the terms
- * of the GPL or the X11 license, at your option. Note that this dual
- * licensing only applies to this file, and not this project as a
- * whole.
- *
- *  a) This file is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of the
- * License, or (at your option) any later version.
- *
- * This file is distributed in the hope that it will be useful
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * Or, alternatively
- *
- *  b) Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
- * copy, modify, merge, publish, distribute, sublicense, and/or
- * sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following
- * conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
- * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
- * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
  * This file contains the definitions that are common to the Armada
  * 370 and Armada XP SoC.
  */
 
-/include/ "skeleton64.dtsi"
-
 #define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
 
 / {
@@ -86,7 +47,7 @@
pcie-mem-aperture = <0xf800 0x7e0>;
pcie-io-aperture  = <0xffe0 0x10>;
 
-   devbus-bootcs {
+   devbus_bootcs: devbus-bootcs {
compatible = "marvell,mvebu-devbus";
reg = ;
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x>;
@@ -96,7 +57,7 @@
status = "disabled";
};
 
-   devbus-cs0 {
+   devbus_cs0: devbus-cs0 {
compatible = "marvell,mvebu-devbus";
reg = ;
ranges = <0 MBUS_ID(0x01, 0x3e) 0 0x>;
@@ -106,7 +67,7 @@
status = "disabled";
};
 
-   devbus-cs1 {
+   devbus_cs1: devbus-cs1 {
compatible = "marvell,mvebu-devbus";
reg = ;
ranges = <0 MBUS_ID(0x01, 0x3d) 0 0x>;
@@ -116,7 +77,7 @@
status = "disabled";
};
 
-   devbus-cs2 {
+   devbus_cs2: devbus-cs2 {
compatible = "marvell,mvebu-devbus";
reg = ;
ranges = <0 MBUS_ID(0x01, 0x3b) 0 0x>;
@@ -126,7 +87,7 @@
status = "disabled";
};
 
-   devbus-cs3 {
+   devbus_cs3: devbus-cs3 {
compatible = "marvell,mvebu-devbus";
reg = ;
ranges = <0 

Re: [U-Boot] [PATCH v5 3/3] cmd: mdio: Switch to generic helpers when accessing the registers

[Vladimir Oltean]

On 2/12/19 2:20 PM, Vladimir Oltean wrote:
> On 08.02.2019 19:26, Carlo Caione wrote:
>> Switch to use the generic helpers to access the MMD registers so that we
>> can used the same command also for C45 PHYs, C22 PHYs with direct and
>> indirect access and PHYs implementing a custom way to access the
>> registers.
>>
>> Signed-off-by: Carlo Caione 
>> ---
>>cmd/mdio.c | 27 ---
>>1 file changed, 16 insertions(+), 11 deletions(-)
>>
>> diff --git a/cmd/mdio.c b/cmd/mdio.c
>> index 184868063a..efe8c9ef09 100644
>> --- a/cmd/mdio.c
>> +++ b/cmd/mdio.c
>> @@ -39,21 +39,24 @@ static int extract_range(char *input, int *plo, int *phi)
>>  return 0;
>>}
>>
>> -static int mdio_write_ranges(struct phy_device *phydev, struct mii_dev *bus,
>> +static int mdio_write_ranges(struct mii_dev *bus,
>>   int addrlo,
>>   int addrhi, int devadlo, int devadhi,
>>   int reglo, int reghi, unsigned short data,
>>   int extended)
>>{
>> +struct phy_device *phydev;
>>  int addr, devad, reg;
>>  int err = 0;
>>
>>  for (addr = addrlo; addr <= addrhi; addr++) {
>> +phydev = bus->phymap[addr];
>> +
>>  for (devad = devadlo; devad <= devadhi; devad++) {
>>  for (reg = reglo; reg <= reghi; reg++) {
>>  if (!extended)
>> -err = bus->write(bus, addr, devad,
>> - reg, data);
>> +err = phy_write_mmd(phydev, devad,
>> +reg, data);
>>  else
>>  err = phydev->drv->writeext(phydev,
>>  addr, devad, reg, data);
>> @@ -68,15 +71,17 @@ err_out:
>>  return err;
>>}
>>
>> -static int mdio_read_ranges(struct phy_device *phydev, struct mii_dev *bus,
>> +static int mdio_read_ranges(struct mii_dev *bus,
>>  int addrlo,
>>  int addrhi, int devadlo, int devadhi,
>>  int reglo, int reghi, int extended)
>>{
>>  int addr, devad, reg;
>> +struct phy_device *phydev;
>>
>>  printf("Reading from bus %s\n", bus->name);
>>  for (addr = addrlo; addr <= addrhi; addr++) {
>> +phydev = bus->phymap[addr];
>>  printf("PHY at address %x:\n", addr);
>>
>>  for (devad = devadlo; devad <= devadhi; devad++) {
>> @@ -84,7 +89,7 @@ static int mdio_read_ranges(struct phy_device *phydev, 
>> struct mii_dev *bus,
>>  int val;
>>
>>  if (!extended)
>> -val = bus->read(bus, addr, devad, reg);
>> +val = phy_read_mmd(phydev, devad, reg);
>>  else
>>  val = phydev->drv->readext(phydev, addr,
>>  devad, reg);
>> @@ -222,14 +227,14 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int 
>> argc, char * const argv[])
>>  bus = phydev->bus;
>>  extended = 1;
>>  } else {
>> -return -1;
>> +return CMD_RET_FAILURE;
>>  }
>>
>>  if (!phydev->drv ||
>>  (!phydev->drv->writeext && (op[0] == 'w')) ||
>>  (!phydev->drv->readext && (op[0] == 'r'))) {
>>  puts("PHY does not have extended functions\n");
>> -return -1;
>> +return CMD_RET_FAILURE;
>>  }
>>  }
>>  }
>> @@ -242,13 +247,13 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int 
>> argc, char * const argv[])
>>  if (pos > 1)
>>  if (extract_reg_range(argv[pos--], , ,
>>, ))
>> -return -1;
>> +return CMD_RET_FAILURE;
>>
>>  default:
>>  if (pos > 1)
>>  if (extract_phy_range([2], pos - 1, ,
>>, , ))
>> -return -1;
>> +return CMD_RET_FAILURE;
>>
>>  break;
>>  }
>> @@ -264,12 +269,12 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int 
>> argc, char * const argv[])
>>
>>  switch (op[0]) {
>>  case 'w':
>> -mdio_write_ranges(phydev, bus, addrlo, addrhi, devadlo, devadhi,
>> +mdio_write_ranges(bus, addrlo, addrhi, devadlo, devadhi,
>>reglo, reghi, 

[U-Boot] [PATCH v1 07/22] configs: move CONFIG_MXC_OCOTP to Kconfig

[Marcel Ziswiler]

From: Marcel Ziswiler 

While commit 3e020f03e94f ("driver: misc: add MXC_OCOTP Kconfig entry")
introduced a Kconfig entry it did not actually migrate all
configurations to using it.

As CONFIG_MXC_OCOTP was in mx{6/7}_common.h enable it by default on
those architectures. Additionally, also enable it on ARCH_IMX8M and
ARCH_VF610 where all current members enabled it through their legacy
configuration header files.

Signed-off-by: Marcel Ziswiler 

---

 configs/bk4r1_defconfig  | 1 -
 configs/pcm052_defconfig | 1 -
 drivers/misc/Kconfig | 2 ++
 include/configs/advantech_dms-ba16.h | 2 --
 include/configs/apalis_imx6.h| 5 -
 include/configs/colibri_imx6.h   | 5 -
 include/configs/colibri_vf.h | 4 
 include/configs/dh_imx6.h| 5 -
 include/configs/ge_bx50v3.h  | 2 --
 include/configs/imx8mq_evk.h | 1 -
 include/configs/kp_imx6q_tpc.h   | 5 -
 include/configs/mx6_common.h | 3 ---
 include/configs/mx7_common.h | 3 ---
 include/configs/vf610twr.h   | 4 
 14 files changed, 2 insertions(+), 41 deletions(-)

diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig
index e3852f4856..439207fd39 100644
--- a/configs/bk4r1_defconfig
+++ b/configs/bk4r1_defconfig
@@ -49,7 +49,6 @@ CONFIG_SYS_I2C_MXC_I2C4=y
 CONFIG_LED=y
 CONFIG_LED_GPIO=y
 CONFIG_MISC=y
-CONFIG_MXC_OCOTP=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SYS_I2C_EEPROM_BUS=2
diff --git a/configs/pcm052_defconfig b/configs/pcm052_defconfig
index 906abbfd69..fd093b35c2 100644
--- a/configs/pcm052_defconfig
+++ b/configs/pcm052_defconfig
@@ -36,7 +36,6 @@ CONFIG_SYS_I2C_MXC_I2C2=y
 CONFIG_SYS_I2C_MXC_I2C3=y
 CONFIG_SYS_I2C_MXC_I2C4=y
 CONFIG_MISC=y
-CONFIG_MXC_OCOTP=y
 CONFIG_I2C_EEPROM=y
 CONFIG_SYS_I2C_EEPROM_ADDR=0x50
 CONFIG_SYS_I2C_EEPROM_BUS=2
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 704c8dd195..137baa71f0 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -128,6 +128,8 @@ config JZ4780_EFUSE
 
 config MXC_OCOTP
bool "Enable MXC OCOTP Driver"
+   depends on ARCH_IMX8M || ARCH_MX6 || ARCH_MX7 || ARCH_VF610
+   default y
help
  If you say Y here, you will get support for the One Time
  Programmable memory pages that are stored on the some
diff --git a/include/configs/advantech_dms-ba16.h 
b/include/configs/advantech_dms-ba16.h
index 0c9de6125d..a22c6a7d45 100644
--- a/include/configs/advantech_dms-ba16.h
+++ b/include/configs/advantech_dms-ba16.h
@@ -34,8 +34,6 @@
 
 #define CONFIG_MXC_UART
 
-#define CONFIG_MXC_OCOTP
-
 /* SATA Configs */
 #define CONFIG_SYS_SATA_MAX_DEVICE 1
 #define CONFIG_DWC_AHSATA_PORT_ID  0
diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
index c8aa1bdddf..95dd6f9362 100644
--- a/include/configs/apalis_imx6.h
+++ b/include/configs/apalis_imx6.h
@@ -41,11 +41,6 @@
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_MXC_I2C3_SPEED  40
 
-/* OCOTP Configs */
-#ifdef CONFIG_CMD_FUSE
-#define CONFIG_MXC_OCOTP
-#endif
-
 /* MMC Configs */
 #define CONFIG_FSL_USDHC
 #define CONFIG_SYS_FSL_ESDHC_ADDR  0
diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h
index a6a823ee1f..d2f8a58e80 100644
--- a/include/configs/colibri_imx6.h
+++ b/include/configs/colibri_imx6.h
@@ -39,11 +39,6 @@
 #define CONFIG_SYS_I2C_SPEED   10
 #define CONFIG_SYS_MXC_I2C3_SPEED  40
 
-/* OCOTP Configs */
-#ifdef CONFIG_CMD_FUSE
-#define CONFIG_MXC_OCOTP
-#endif
-
 /* MMC Configs */
 #define CONFIG_FSL_USDHC
 #define CONFIG_SYS_FSL_ESDHC_ADDR  0
diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 7b974d9e97..e7b786e48b 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -17,10 +17,6 @@
 
 #define CONFIG_SKIP_LOWLEVEL_INIT
 
-#ifdef CONFIG_CMD_FUSE
-#define CONFIG_MXC_OCOTP
-#endif
-
 #ifdef CONFIG_VIDEO_FSL_DCU_FB
 #define CONFIG_SPLASH_SCREEN_ALIGN
 #define CONFIG_VIDEO_LOGO
diff --git a/include/configs/dh_imx6.h b/include/configs/dh_imx6.h
index 9231bd853f..4dc795c3f4 100644
--- a/include/configs/dh_imx6.h
+++ b/include/configs/dh_imx6.h
@@ -48,11 +48,6 @@
 #define CONFIG_FEC_MXC_PHYADDR 0
 #define CONFIG_ARP_TIMEOUT 200UL
 
-/* Fuses */
-#ifdef CONFIG_CMD_FUSE
-#define CONFIG_MXC_OCOTP
-#endif
-
 /* I2C Configs */
 #define CONFIG_SYS_I2C
 #define CONFIG_SYS_I2C_MXC
diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
index e0e1f713ef..8bbda2788d 100644
--- a/include/configs/ge_bx50v3.h
+++ b/include/configs/ge_bx50v3.h
@@ -35,8 +35,6 @@
 
 #define CONFIG_MXC_UART
 
-#define CONFIG_MXC_OCOTP
-
 /* SATA Configs */
 #ifdef CONFIG_CMD_SATA
 #define CONFIG_SYS_SATA_MAX_DEVICE 1
diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h
index f0430224cb..044a254320 100644
--- a/include/configs/imx8mq_evk.h
+++ 

[U-Boot] [PATCH v1 00/22] colibri vybrid fixes, device tree enablement and driver model conversion

[Marcel Ziswiler]

This series addresses some shortcomings, enables/introduces device tree
support and converts all except video to using the driver model. This is
fully tested both running our latest downstream BSP as well as the
mainline Linux kernel.

This series is based on Lukasz' previous work on Vybrid [1] and is
available together with his and my previous series addressing Apalis
and Colibri iMX6 on our git server [2].

[1] https://patchwork.ozlabs.org/cover/1041597/
[2] http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next


Bhuvanchandra DV (1):
  colibri_vf: sync the board info message

Gerard Salvatella (1):
  colibri_vf: fix sdboot for vybrid modules

Marcel Ziswiler (12):
  add missing space in comment
  vf610: ddrmc: add missing include
  imx: bootaux: add dependency on vf610
  configs: move CONFIG_USB_EHCI_VF to Kconfig
  configs: colibri_vf: remove obsolete mmc/sd card environment
  configs: colibri_vf: limit size of malloc() pool before relocation
  configs: move CONFIG_MXC_OCOTP to Kconfig
  ARM: dts: colibri_vf: update device trees
  configs: colibri_vf: disable obscure options
  colibri_vf: migrate pinctrl and regulators to dtb/dm
  colibri_vf: migrate fec, esdhc, nfc and usb to driver model
  config: colibri_vf: use macros from linux/sizes.h

Stefan Agner (8):
  colibri_vf: add distroboot support
  colibri_vf: set fdtfile for distroboot
  colibri_vf: enable user debug by default
  colibri_vf: disable undefined instruction events in user debug
  config: colibri_vf: enable mtd partitions via dt
  arm: vf610: add uart2 clock/pinmux support
  colibri_vf: adjust timing according to data sheet
  colibri_vf: use leveling evaluated by DDR validation tools

 arch/arm/dts/vf-colibri-u-boot.dtsi   |  23 ++
 arch/arm/dts/vf-colibri.dtsi  | 198 +-
 arch/arm/dts/vf500-colibri.dts|   1 +
 arch/arm/dts/vf610-colibri.dts|   1 +
 arch/arm/include/asm/arch-vf610/crm_regs.h|   1 +
 arch/arm/include/asm/arch-vf610/ddrmc-vf610.h |   2 +
 arch/arm/include/asm/arch-vf610/iomux-vf610.h |   6 +-
 arch/arm/mach-imx/Kconfig |   2 +-
 board/freescale/imx8qxp_mek/imx8qxp_mek.c |   2 +-
 board/toradex/colibri_vf/MAINTAINERS  |   4 +-
 board/toradex/colibri_vf/colibri_vf.c | 241 ++
 configs/bk4r1_defconfig   |   1 -
 configs/colibri_vf_defconfig  |  22 +-
 configs/pcm052_defconfig  |   1 -
 drivers/misc/Kconfig  |   2 +
 drivers/usb/host/Kconfig  |   7 +
 drivers/video/videomodes.c|   2 +-
 include/configs/advantech_dms-ba16.h  |   2 -
 include/configs/apalis_imx6.h |   5 -
 include/configs/colibri_imx6.h|   5 -
 include/configs/colibri_vf.h  | 109 
 include/configs/dh_imx6.h |   5 -
 include/configs/ge_bx50v3.h   |   2 -
 include/configs/imx8mq_evk.h  |   1 -
 include/configs/kp_imx6q_tpc.h|   5 -
 include/configs/mx6_common.h  |   3 -
 include/configs/mx7_common.h  |   3 -
 include/configs/vf610twr.h|   4 -
 scripts/config_whitelist.txt  |   1 -
 29 files changed, 344 insertions(+), 317 deletions(-)
 create mode 100644 arch/arm/dts/vf-colibri-u-boot.dtsi

-- 
2.20.1

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

[U-Boot] [PATCH v1 21/22] colibri_vf: use leveling evaluated by DDR validation tools

[Marcel Ziswiler]

From: Stefan Agner 

The DDR validation tool (which is part of Processor Expert) allows
to evaluate leveling parameters for CR105/CR106/CR110. Several
runs have been made with Colibri VF50 and VF61 and it seems to
evaluate very similar values. Use this values by default.

Note: The newly evaluated parameters seem to require CTLUPD_AREF
to be enabled!

Note 2: The tool also evaluated 6 as a new value for PHY02/18
GATE_CFG (Coarse adjust of gate open time). However, this seems
not to work in practise.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 

---

 board/toradex/colibri_vf/colibri_vf.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index 8c4909af54..87debf1360 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -27,6 +27,13 @@
 DECLARE_GLOBAL_DATA_PTR;
 
 static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
+   { DDRMC_CR79_CTLUPD_AREF(1), 79 },
+   /* sets manual values for read lvl. (gate) delay of data slice 0/1 */
+   { DDRMC_CR105_RDLVL_DL_0(28), 105 },
+   { DDRMC_CR106_RDLVL_GTDL_0(24), 106 },
+   { DDRMC_CR110_RDLVL_DL_1(28) | DDRMC_CR110_RDLVL_GTDL_1(24), 110 },
+   { DDRMC_CR102_RDLVL_GT_REGEN | DDRMC_CR102_RDLVL_REG_EN, 102 },
+
/* AXI */
{ DDRMC_CR117_AXI0_W_PRI(0) | DDRMC_CR117_AXI0_R_PRI(0), 117 },
{ DDRMC_CR118_AXI1_W_PRI(1) | DDRMC_CR118_AXI1_R_PRI(1), 118 },
-- 
2.20.1

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

[U-Boot] [PATCH v1 20/22] colibri_vf: adjust timing according to data sheet

[Marcel Ziswiler]

From: Stefan Agner 

Using the DDR Validation tool in Processor Expert uncovered two
timing inconsistencies. Since those timings are related to the
suspend mode they do not affect or change regular memory behaviour.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 

---

 board/toradex/colibri_vf/colibri_vf.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index d28a73332a..8c4909af54 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -99,15 +99,21 @@ int dram_init(void)
.tras_lockout  = 0,
.tdal  = 12,
.bstlen= 3,
-   .tdll  = 512,
+   .tdll  = 512, /* not applicable since freq. scaling
+  * is not used
+  */
.trp_ab= 6,
.tref  = 3120,
.trfc  = 64,
.tref_int  = 0,
.tpdex = 3,
.txpdll= 10,
-   .txsnr = 48,
-   .txsr  = 468,
+   .txsnr = 68,  /* changed to conform to JEDEC
+  * specifications
+  */
+   .txsr  = 506, /* changed to conform to JEDEC
+  * specifications
+  */
.cksrx = 5,
.cksre = 5,
.freq_chg_en   = 0,
-- 
2.20.1

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

Re: [U-Boot] [BUG] qemu-x86_defconfig does not build with GCC 8.1

[Ayush Dosaj]

I have one question, where to remove "-g" and in which make file ?
I am stuck on this BUG. Please Help me out.
-- 
Ayush Dosaj
VIT Vellore
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v1 18/22] config: colibri_vf: enable mtd partitions via dt

[Marcel Ziswiler]

From: Stefan Agner 

Use device tree to set MTD partitions of the NAND chip.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 

---

 configs/colibri_vf_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
index 344fe77234..8f6cceca7f 100644
--- a/configs/colibri_vf_defconfig
+++ b/configs/colibri_vf_defconfig
@@ -91,4 +91,5 @@ CONFIG_VIDEO_FSL_DCU_FB=y
 CONFIG_VIDEO=y
 CONFIG_SYS_CONSOLE_FG_COL=0x00
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_FDT_FIXUP_PARTITIONS=y
 # CONFIG_EFI_UNICODE_CAPITALIZATION is not set
-- 
2.20.1

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

[U-Boot] [PATCH v1 15/22] colibri_vf: sync the board info message

[Marcel Ziswiler]

From: Bhuvanchandra DV 

Use similar info message as on other modules.

Signed-off-by: Bhuvanchandra DV 
Acked-by: Marcel Ziswiler 

---

 board/toradex/colibri_vf/colibri_vf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index 421a4791a1..d28a73332a 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -405,9 +405,9 @@ int board_init(void)
 int checkboard(void)
 {
if (is_colibri_vf61())
-   puts("Board: Colibri VF61\n");
+   puts("Model: Toradex Colibri VF61\n");
else
-   puts("Board: Colibri VF50\n");
+   puts("Model: Toradex Colibri VF50\n");
 
return 0;
 }
-- 
2.20.1

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

[U-Boot] Porting to the HTG-Z920

[Patrick Schuetterle]

Hello,

I've been trying to compile U-boot for hi-tech global's HTG-Z920 board.
It's SoC is the zynq ZU19EG ultrascale+.
I'm mainly confused as to how I should configure Kbuild with the bare
necessities -- UART, SD-LS, and DDR. I've managed to get things running via
an FSBL generated with the xilinx sdk (ver. 2018.2), so I know it should be
possible.
Currently, I only receive the FSBL boot messages,  even after enabling the
early debug UART.  I tried to match the addresses given by my hardware
definition file (.hdf), but nothing's appearing.

Should I try adapting one of the pre-set boards' configs (e.g. for the
zcu104?), or are there some major pieces I'd still need?
I also have the device tree derived from the .hdf file. Would it be simpler
to use that?

Any help you can spare would be greatly appreciated!

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

[U-Boot] [PATCH v1 19/22] arm: vf610: add uart2 clock/pinmux support

[Marcel Ziswiler]

From: Stefan Agner 

Add support for Vybrid's UART2 (Colibri UART_B).

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 

---

 arch/arm/include/asm/arch-vf610/crm_regs.h| 1 +
 arch/arm/include/asm/arch-vf610/iomux-vf610.h | 6 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h 
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 9fce49ddc6..0c9ed52933 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -200,6 +200,7 @@ struct anadig_reg {
 #define CCM_REG_CTRL_MASK  0x
 #define CCM_CCGR0_UART0_CTRL_MASK   (0x3 << 14)
 #define CCM_CCGR0_UART1_CTRL_MASK  (0x3 << 16)
+#define CCM_CCGR0_UART2_CTRL_MASK  (0x3 << 18)
 #define CCM_CCGR0_DSPI0_CTRL_MASK  (0x3 << 24)
 #define CCM_CCGR0_DSPI1_CTRL_MASK  (0x3 << 26)
 #define CCM_CCGR1_USBC0_CTRL_MASK   (0x3 << 8)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h 
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index 01bc2998b8..8ba03e5a17 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -132,10 +132,14 @@ enum {
VF610_PAD_PTD24__GPIO_70= IOMUX_PAD(0x0118, 0x0118, 0, 
__NA_, 0, VF610_GPIO_PAD_CTRL),
VF610_PAD_PTD23__NF_IO7 = IOMUX_PAD(0x011c, 0x011c, 2, 
__NA_, 0, VF610_NFC_IO_PAD_CTRL),
VF610_PAD_PTD0__QSPI0_A_QSCK= IOMUX_PAD(0x013c, 0x013c, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
+   VF610_PAD_PTD0__UART2_TX= IOMUX_PAD(0x013c, 0x013c, 2, 
0x38c, 2, VF610_UART_PAD_CTRL),
VF610_PAD_PTD1__QSPI0_A_CS0 = IOMUX_PAD(0x0140, 0x0140, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
+   VF610_PAD_PTD1__UART2_RX= IOMUX_PAD(0x0140, 0x0140, 2, 
0x388, 2, VF610_UART_PAD_CTRL),
VF610_PAD_PTD2__QSPI0_A_DATA3   = IOMUX_PAD(0x0144, 0x0144, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
+   VF610_PAD_PTD2__GPIO_81 = IOMUX_PAD(0x0144, 0x0144, 0, 
__NA_, 0, VF610_GPIO_PAD_CTRL),
VF610_PAD_PTD3__QSPI0_A_DATA2   = IOMUX_PAD(0x0148, 0x0148, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
-   VF610_PAD_PTD4__GPIO_83 = IOMUX_PAD(0x014C, 0x014C, 0, __NA_, 
0, VF610_GPIO_PAD_CTRL),
+   VF610_PAD_PTD3__GPIO_82 = IOMUX_PAD(0x0148, 0x0148, 0, 
__NA_, 0, VF610_GPIO_PAD_CTRL),
+   VF610_PAD_PTD4__GPIO_83 = IOMUX_PAD(0x014C, 0x014C, 0, 
__NA_, 0, VF610_GPIO_PAD_CTRL),
VF610_PAD_PTD4__QSPI0_A_DATA1   = IOMUX_PAD(0x014c, 0x014c, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD5__QSPI0_A_DATA0   = IOMUX_PAD(0x0150, 0x0150, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
VF610_PAD_PTD7__QSPI0_B_QSCK= IOMUX_PAD(0x0158, 0x0158, 1, 
__NA_, 0, VF610_QSPI_PAD_CTRL),
-- 
2.20.1

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

[U-Boot] [PATCH v1 22/22] colibri_vf: fix sdboot for vybrid modules

[Marcel Ziswiler]

From: Gerard Salvatella 

Currently, Vybrid's sdboot variable tries to load the kernel from /boot
of the root partition (typically second partition when using the sdcard
image). However, since we moved to flash the kernel in a separate UBI
volume, we no longer deploy the kernel/device tree to /boot, hence
sdboot does not work in its current state.

Load the kernel and device tree from the first (typically FAT) partition
as customary on all Toradex modules.

While at it also change from rw to ro as e.g. systemd will re-mount the
root file system rw anyway after checking it.

Signed-off-by: Gerard Salvatella 
Acked-by: Stefan Agner 
Acked-by: Marcel Ziswiler 

---

 include/configs/colibri_vf.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index b2f27c1977..0d57e303a1 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -68,11 +68,11 @@
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
 #define SD_BOOTCMD \
-   "sdargs=root=/dev/mmcblk0p2 rw rootwait\0"  \
+   "sdargs=root=/dev/mmcblk0p2 ro rootwait\0"  \
"sdboot=run setup; setenv bootargs ${defargs} ${sdargs} ${mtdparts} " \
"${setupargs} ${vidargs}; echo Booting from MMC/SD card...; " \
-   "load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
-   "load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-${fdt_board}.dtb && " \
+   "load mmc 0:1 ${kernel_addr_r} ${kernel_file} && " \
+   "load mmc 0:1 ${fdt_addr_r} ${soc}-colibri-${fdt_board}.dtb && " \
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
 #define UBI_BOOTCMD \
-- 
2.20.1

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

[U-Boot] [PATCH v1 04/22] configs: move CONFIG_USB_EHCI_VF to Kconfig

[Marcel Ziswiler]

From: Marcel Ziswiler 

Move CONFIG_USB_EHCI_VF to drivers/usb/host/Kconfig and update the one
and only user thereof being colibri_vf.

Signed-off-by: Marcel Ziswiler 

---

 drivers/usb/host/Kconfig | 7 +++
 include/configs/colibri_vf.h | 1 -
 scripts/config_whitelist.txt | 1 -
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 60f37f40fd..6cda1cbfbd 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -154,6 +154,13 @@ config USB_EHCI_OMAP
  Enables support for the on-chip EHCI controller on OMAP3 and later
  SoCs.
 
+config USB_EHCI_VF
+   bool "Support for Vybrid on-chip EHCI USB controller"
+   depends on ARCH_VF610
+   default y
+   help
+ Enables support for the on-chip EHCI controller on Vybrid SoCs.
+
 if USB_EHCI_MX7
 
 config MXC_USB_OTG_HACTIVE
diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 31ff8a00a6..2fe7f217fa 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -159,7 +159,6 @@
 #endif
 
 /* USB Host Support */
-#define CONFIG_USB_EHCI_VF
 #define CONFIG_USB_MAX_CONTROLLER_COUNT 2
 #define CONFIG_EHCI_HCD_INIT_AFTER_RESET
 
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 2b3572568b..9ca974bbae 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4533,7 +4533,6 @@ CONFIG_USB_EHCI_SPEAR
 CONFIG_USB_EHCI_TEGRA
 CONFIG_USB_EHCI_TXFIFO_THRESH
 CONFIG_USB_EHCI_VCT
-CONFIG_USB_EHCI_VF
 CONFIG_USB_ETH_QMULT
 CONFIG_USB_ETH_SUBSET
 CONFIG_USB_EXT2_BOOT
-- 
2.20.1

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

[U-Boot] [PATCH v1 13/22] colibri_vf: add distroboot support

[Marcel Ziswiler]

From: Stefan Agner 

Add support for distro boot. This is especially helpful for external
devices. There is a global boot command which scans a predefined
list of boot targets:
  run distro_bootcmd

As well as direct boot commands such as:
  run bootcmd_mmc0
  run bootcmd_usb
  run bootcmd_dhcp
  ...

Refer to doc/README.distro fo details.

While at it also re-order boot command macros as well as the
CONFIG_EXTRA_ENV_SETTINGS.

Signed-off-by: Stefan Agner 
Acked-by: Max Krummenacher 
Acked-by: Marcel Ziswiler 

---

 include/configs/colibri_vf.h | 75 ++--
 1 file changed, 46 insertions(+), 29 deletions(-)

diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 9effa56539..83a33ff786 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -48,13 +48,15 @@
 /* We boot from the gfxRAM area of the OCRAM. */
 #define CONFIG_BOARD_SIZE_LIMIT520192
 
-#define SD_BOOTCMD \
-   "sdargs=root=/dev/mmcblk0p2 rw rootwait\0"  \
-   "sdboot=run setup; setenv bootargs ${defargs} ${sdargs} ${mtdparts} " \
-   "${setupargs} ${vidargs}; echo Booting from MMC/SD card...; " \
-   "load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
-   "load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-${fdt_board}.dtb && " \
-   "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
+#define MEM_LAYOUT_ENV_SETTINGS \
+   "bootm_size=0x1000\0" \
+   "fdt_addr_r=0x8200\0" \
+   "fdt_high=0x\0" \
+   "initrd_high=0x\0" \
+   "kernel_addr_r=0x8100\0" \
+   "pxefile_addr_r=0x8710\0" \
+   "ramdisk_addr_r=0x8210\0" \
+   "scriptaddr=0x8700\0"
 
 #define NFS_BOOTCMD \
"nfsargs=ip=:eth0: root=/dev/nfs\0" \
@@ -65,7 +67,15 @@
"tftp ${fdt_addr_r} ${soc}-colibri-${fdt_board}.dtb && " \
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
-#define UBI_BOOTCMD\
+#define SD_BOOTCMD \
+   "sdargs=root=/dev/mmcblk0p2 rw rootwait\0"  \
+   "sdboot=run setup; setenv bootargs ${defargs} ${sdargs} ${mtdparts} " \
+   "${setupargs} ${vidargs}; echo Booting from MMC/SD card...; " \
+   "load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
+   "load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-${fdt_board}.dtb && " \
+   "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
+
+#define UBI_BOOTCMD \
"ubiargs=ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs " \
"ubi.fm_autoconvert=1\0" \
"ubiboot=run setup; " \
@@ -76,36 +86,43 @@
"ubi read ${fdt_addr_r} dtb && " \
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
-#define CONFIG_BOOTCOMMAND "run ubiboot; run sdboot; run nfsboot"
+#define CONFIG_BOOTCOMMAND "run ubiboot; run distro_bootcmd;"
+
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(USB, usb, 0) \
+   func(DHCP, dhcp, na)
+#include 
+#undef BOOTENV_RUN_NET_USB_START
+#define BOOTENV_RUN_NET_USB_START ""
 
 #define DFU_ALT_NAND_INFO "vf-bcb part 0,1;u-boot part 0,2;ubi part 0,4"
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "kernel_addr_r=0x8200\0" \
-   "fdt_addr_r=0x8400\0" \
-   "kernel_file=zImage\0" \
-   "fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
+   BOOTENV \
+   MEM_LAYOUT_ENV_SETTINGS \
+   NFS_BOOTCMD \
+   SD_BOOTCMD \
+   UBI_BOOTCMD \
+   "console=ttyLP0\0" \
+   "defargs=\0" \
+   "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
"fdt_board=eval-v3\0" \
+   "fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
"fdt_fixup=;\0" \
-   "defargs=\0" \
-   "console=ttyLP0\0" \
-   "setup=setenv setupargs " \
-   "console=tty1 console=${console}" \
-   ",${baudrate}n8 ${memargs}\0" \
+   "kernel_file=zImage\0" \
+   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
"setsdupdate=mmc rescan && set interface mmc && " \
-   "fatload ${interface} 0:1 ${loadaddr} flash_blk.img && " \
-   "source ${loadaddr}\0" \
-   "setusbupdate=usb start && set interface usb && " \
-   "fatload ${interface} 0:1 ${loadaddr} flash_blk.img && " \
-   "source ${loadaddr}\0" \
+   "fatload ${interface} 0:1 ${loadaddr} flash_blk.img && " \
+   "source ${loadaddr}\0" \
+   "setup=setenv setupargs console=tty1 console=${console}" \
+   ",${baudrate}n8 ${memargs}\0" \
"setupdate=run setsdupdate || run setusbupdate\0" \
-   "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
-   "dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
-   "video-mode=dcufb:640x480-16@60,monitor=lcd\0" \
+   "setusbupdate=usb start && set interface usb && " \
+   "fatload ${interface} 0:1 ${loadaddr} flash_blk.img && " \
+   "source ${loadaddr}\0" \
"splashpos=m,m\0" \
-   SD_BOOTCMD \
-   NFS_BOOTCMD \
-   UBI_BOOTCMD
+   

[U-Boot] [PATCH v1 11/22] colibri_vf: migrate fec, esdhc, nfc and usb to driver model

[Marcel Ziswiler]

From: Marcel Ziswiler 

Migrate FEC, ESDHC, NFC and USB to driver model.

While at it also do no longer enable optional I2C clock in board file as
the generic clock code now handles this. Note for space reason and as
it is not required just for booting we do not enable I2C in U-Boot by
default.

While at it also update copyright period.

Signed-off-by: Marcel Ziswiler 

---

 board/toradex/colibri_vf/colibri_vf.c | 83 +--
 configs/colibri_vf_defconfig  |  5 ++
 include/configs/colibri_vf.h  | 13 +
 3 files changed, 7 insertions(+), 94 deletions(-)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index c9de3c0c76..421a4791a1 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -16,24 +16,16 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 
 #include "../common/tdx-common.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define USB_PEN_GPIO   83
-#define USB_CDET_GPIO  102
-
 static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
/* AXI */
{ DDRMC_CR117_AXI0_W_PRI(0) | DDRMC_CR117_AXI0_R_PRI(0), 117 },
@@ -238,25 +230,6 @@ static void setup_tcon(void)
 }
 #endif
 
-#ifdef CONFIG_FSL_ESDHC
-struct fsl_esdhc_cfg esdhc_cfg[1] = {
-   {ESDHC1_BASE_ADDR},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
-   /* eSDHC1 is always present */
-   return 1;
-}
-
-int board_mmc_init(bd_t *bis)
-{
-   esdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK);
-
-   return fsl_esdhc_initialize(bis, _cfg[0]);
-}
-#endif
-
 static inline int is_colibri_vf61(void)
 {
struct mscm *mscm = (struct mscm *)MSCM_BASE_ADDR;
@@ -289,7 +262,7 @@ static void clock_init(void)
CCM_CCGR3_ANADIG_CTRL_MASK | CCM_CCGR3_SCSC_CTRL_MASK);
clrsetbits_le32(>ccgr4, CCM_REG_CTRL_MASK,
CCM_CCGR4_WKUP_CTRL_MASK | CCM_CCGR4_CCM_CTRL_MASK |
-   CCM_CCGR4_GPC_CTRL_MASK | CCM_CCGR4_I2C0_CTRL_MASK);
+   CCM_CCGR4_GPC_CTRL_MASK);
clrsetbits_le32(>ccgr6, CCM_REG_CTRL_MASK,
CCM_CCGR6_OCOTP_CTRL_MASK | CCM_CCGR6_DDRMC_CTRL_MASK);
clrsetbits_le32(>ccgr7, CCM_REG_CTRL_MASK,
@@ -378,14 +351,6 @@ static void mscm_init(void)
writew(MSCM_IRSPRC_CP0_EN, >irsprc[i]);
 }
 
-int board_phy_config(struct phy_device *phydev)
-{
-   if (phydev->drv->config)
-   phydev->drv->config(phydev);
-
-   return 0;
-}
-
 int board_early_init_f(void)
 {
clock_init();
@@ -432,13 +397,8 @@ int board_init(void)
 * so we must use the external oscillator in order
 * to maintain correct time in the hwclock
 */
-
setbits_le32(>sosc_ctr, SCSC_SOSC_CTR_SOSC_EN);
 
-#ifdef CONFIG_USB_EHCI_VF
-   gpio_request(USB_CDET_GPIO, "usb-cdet-gpio");
-#endif
-
return 0;
 }
 
@@ -474,44 +434,3 @@ int ft_board_setup(void *blob, bd_t *bd)
return ft_common_board_setup(blob, bd);
 }
 #endif
-
-#ifdef CONFIG_USB_EHCI_VF
-int board_ehci_hcd_init(int port)
-{
-   switch (port) {
-   case 0:
-   /* USBC does not have PEN, also configured as USB client only */
-   break;
-   case 1:
-   gpio_request(USB_PEN_GPIO, "usb-pen-gpio");
-   gpio_direction_output(USB_PEN_GPIO, 0);
-   break;
-   }
-   return 0;
-}
-
-int board_usb_phy_mode(int port)
-{
-   switch (port) {
-   case 0:
-   /*
-* Port 0 is used only in client mode on Colibri Vybrid modules
-* Check for state of USB client gpio pin and accordingly return
-* USB_INIT_DEVICE or USB_INIT_HOST.
-*/
-   if (gpio_get_value(USB_CDET_GPIO))
-   return USB_INIT_DEVICE;
-   else
-   return USB_INIT_HOST;
-   case 1:
-   /* Port 1 is used only in host mode on Colibri Vybrid modules */
-   return USB_INIT_HOST;
-   default:
-   /*
-* There are only two USB controllers on Vybrid. Ideally we will
-* not reach here. However return USB_INIT_HOST if we do.
-*/
-   return USB_INIT_HOST;
-   }
-}
-#endif
diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
index 9a91cb4b82..344fe77234 100644
--- a/configs/colibri_vf_defconfig
+++ b/configs/colibri_vf_defconfig
@@ -56,13 +56,18 @@ CONFIG_DM=y
 CONFIG_DFU_NAND=y
 CONFIG_DM_GPIO=y
 CONFIG_VYBRID_GPIO=y
+CONFIG_DM_MMC=y
 # CONFIG_MMC_HW_PARTITIONING is not set
 CONFIG_FSL_ESDHC=y
+CONFIG_MTD=y
 CONFIG_NAND_VF610_NFC=y
+CONFIG_NAND_VF610_NFC_DT=y
 CONFIG_SYS_NAND_VF610_NFC_60_ECC_BYTES=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_DM_ETH=y
+CONFIG_FEC_MXC=y

[U-Boot] [PATCH v1 12/22] config: colibri_vf: use macros from linux/sizes.h

[Marcel Ziswiler]

From: Marcel Ziswiler 

Use SZ_X{MK} macros from linux/sizes.h for include/configs/colibri_vf.h.

Signed-off-by: Marcel Ziswiler 

---

 include/configs/colibri_vf.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 1acc6e5056..9effa56539 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -12,6 +12,7 @@
 #define __CONFIG_H
 
 #include 
+#include 
 
 #define CONFIG_SYS_FSL_CLK
 
@@ -28,7 +29,7 @@
 #endif
 
 /* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * SZ_1M)
 
 /* Allow to overwrite serial and ethaddr */
 #define CONFIG_ENV_OVERWRITE
@@ -118,7 +119,7 @@
 
 /* Physical memory map */
 #define PHYS_SDRAM (0x8000)
-#define PHYS_SDRAM_SIZE(256 * 1024 * 1024)
+#define PHYS_SDRAM_SIZE(256 * SZ_1M)
 
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM
 #define CONFIG_SYS_INIT_RAM_ADDR   IRAM_BASE_ADDR
@@ -141,6 +142,6 @@
 #define CONFIG_EHCI_HCD_INIT_AFTER_RESET
 
 /* USB DFU */
-#define CONFIG_SYS_DFU_DATA_BUF_SIZE (1024 * 1024)
+#define CONFIG_SYS_DFU_DATA_BUF_SIZE (SZ_1M)
 
 #endif /* __CONFIG_H */
-- 
2.20.1

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

[U-Boot] [PATCH v1 10/22] colibri_vf: migrate pinctrl and regulators to dtb/dm

[Marcel Ziswiler]

From: Marcel Ziswiler 

Migrate pinctrl and regulators to device tree resp. driver model: DDR,
DSPI, ENET, ESDHC, I2C, NFC and UART.

Enable CMD_DM, PINCTRL and DM_REGULATOR.

While at it also update copyright period and sort include files.

Signed-off-by: Marcel Ziswiler 

---

 board/toradex/colibri_vf/colibri_vf.c | 139 ++
 configs/colibri_vf_defconfig  |   5 +
 2 files changed, 16 insertions(+), 128 deletions(-)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index 19cf748c5d..c9de3c0c76 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -1,43 +1,36 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright 2015 Toradex, Inc.
+ * Copyright 2015-2019 Toradex, Inc.
  *
  * Based on vf610twr.c:
  * Copyright 2013 Freescale Semiconductor, Inc.
  */
 
 #include 
-#include 
+
+#include 
+#include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
+
 #include "../common/tdx-common.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define UART_PAD_CTRL  (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \
-   PAD_CTL_DSE_25ohm | PAD_CTL_OBE_IBE_ENABLE)
-
-#define ESDHC_PAD_CTRL (PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_HIGH | \
-   PAD_CTL_DSE_20ohm | PAD_CTL_OBE_IBE_ENABLE)
-
-#define ENET_PAD_CTRL  (PAD_CTL_PUS_47K_UP | PAD_CTL_SPEED_HIGH | \
-   PAD_CTL_DSE_50ohm | PAD_CTL_OBE_IBE_ENABLE)
-
 #define USB_PEN_GPIO   83
 #define USB_CDET_GPIO  102
 
@@ -88,11 +81,6 @@ static struct ddrmc_cr_setting colibri_vf_cr_settings[] = {
{ 0, -1 }
 };
 
-static const iomux_v3_cfg_t usb_pads[] = {
-   VF610_PAD_PTD4__GPIO_83,
-   VF610_PAD_PTC29__GPIO_102,
-};
-
 int dram_init(void)
 {
static const struct ddr3_jedec_timings timings = {
@@ -146,92 +134,12 @@ int dram_init(void)
.wldqsen   = 25,
};
 
-   ddrmc_setup_iomux(NULL, 0);
-
ddrmc_ctrl_init_ddr3(, colibri_vf_cr_settings, NULL, 1, 2);
gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
 
return 0;
 }
 
-static void setup_iomux_uart(void)
-{
-   static const iomux_v3_cfg_t uart_pads[] = {
-   NEW_PAD_CTRL(VF610_PAD_PTB4__UART1_TX, UART_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTB5__UART1_RX, UART_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTB10__UART0_TX, UART_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTB11__UART0_RX, UART_PAD_CTRL),
-   };
-
-   imx_iomux_v3_setup_multiple_pads(uart_pads, ARRAY_SIZE(uart_pads));
-}
-
-static void setup_iomux_enet(void)
-{
-   static const iomux_v3_cfg_t enet0_pads[] = {
-   NEW_PAD_CTRL(VF610_PAD_PTA6__RMII0_CLKOUT, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC10__RMII1_MDIO, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC9__RMII1_MDC, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC11__RMII1_CRS_DV, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC12__RMII1_RD1, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC13__RMII1_RD0, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC14__RMII1_RXER, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC15__RMII1_TD1, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC16__RMII1_TD0, ENET_PAD_CTRL),
-   NEW_PAD_CTRL(VF610_PAD_PTC17__RMII1_TXEN, ENET_PAD_CTRL),
-   };
-
-   imx_iomux_v3_setup_multiple_pads(enet0_pads, ARRAY_SIZE(enet0_pads));
-}
-
-static void setup_iomux_i2c(void)
-{
-   static const iomux_v3_cfg_t i2c0_pads[] = {
-   VF610_PAD_PTB14__I2C0_SCL,
-   VF610_PAD_PTB15__I2C0_SDA,
-   };
-
-   imx_iomux_v3_setup_multiple_pads(i2c0_pads, ARRAY_SIZE(i2c0_pads));
-}
-
-#ifdef CONFIG_NAND_VF610_NFC
-static void setup_iomux_nfc(void)
-{
-   static const iomux_v3_cfg_t nfc_pads[] = {
-   VF610_PAD_PTD23__NF_IO7,
-   VF610_PAD_PTD22__NF_IO6,
-   VF610_PAD_PTD21__NF_IO5,
-   VF610_PAD_PTD20__NF_IO4,
-   VF610_PAD_PTD19__NF_IO3,
-   VF610_PAD_PTD18__NF_IO2,
-   VF610_PAD_PTD17__NF_IO1,
-   VF610_PAD_PTD16__NF_IO0,
-   VF610_PAD_PTB24__NF_WE_B,
-   VF610_PAD_PTB25__NF_CE0_B,
-   VF610_PAD_PTB27__NF_RE_B,
-   VF610_PAD_PTC26__NF_RB_B,
-   VF610_PAD_PTC27__NF_ALE,
-   VF610_PAD_PTC28__NF_CLE
-   };
-
-   imx_iomux_v3_setup_multiple_pads(nfc_pads, ARRAY_SIZE(nfc_pads));
-}
-#endif
-
-#ifdef CONFIG_FSL_DSPI
-static void setup_iomux_dspi(void)
-{
-   static const iomux_v3_cfg_t dspi1_pads[] = {
-   VF610_PAD_PTD5__DSPI1_CS0,
-   

[U-Boot] [PATCH v1 09/22] configs: colibri_vf: disable obscure options

[Marcel Ziswiler]

From: Marcel Ziswiler 

Disable more obscure options to save another 26 KB in preparation of
the upcoming driver model migration.

Signed-off-by: Marcel Ziswiler 

---

 configs/colibri_vf_defconfig | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
index 8188582ed9..706d7ca634 100644
--- a/configs/colibri_vf_defconfig
+++ b/configs/colibri_vf_defconfig
@@ -17,11 +17,17 @@ CONFIG_BOARD_EARLY_INIT_F=y
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMDLINE_EDITING is not set
 # CONFIG_AUTO_COMPLETE is not set
+# CONFIG_SYS_LONGHELP is not set
 CONFIG_SYS_PROMPT="Colibri VFxx # "
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
 CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_IMI is not set
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_DFU=y
+# CONFIG_CMD_FLASH is not set
 CONFIG_CMD_FUSE=y
 CONFIG_CMD_GPIO=y
 # CONFIG_CMD_LOADB is not set
@@ -46,10 +52,10 @@ CONFIG_DEFAULT_DEVICE_TREE="vf610-colibri"
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_DM=y
-CONFIG_DFU_MMC=y
 CONFIG_DFU_NAND=y
 CONFIG_DM_GPIO=y
 CONFIG_VYBRID_GPIO=y
+# CONFIG_MMC_HW_PARTITIONING is not set
 CONFIG_FSL_ESDHC=y
 CONFIG_NAND_VF610_NFC=y
 CONFIG_SYS_NAND_VF610_NFC_60_ECC_BYTES=y
@@ -57,6 +63,8 @@ CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
 CONFIG_MII=y
+# CONFIG_SPL_SERIAL_PRESENT is not set
+# CONFIG_TPL_SERIAL_PRESENT is not set
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
 CONFIG_USB=y
-- 
2.20.1

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

[U-Boot] [PATCH v1 08/22] ARM: dts: colibri_vf: update device trees

[Marcel Ziswiler]

From: Marcel Ziswiler 

Update device tree in preparation of further driver model migration:
Ethernet FEC, ESDHC aka MMC/SD card, I2C, NFC aka NAND flash controller,
USBH_PEN GPIO regulator.

Add iomux resp. pinctrl entries to be removed from proprietary platform
data: DSPI, ESDHC, FEC, I2C, NFC, UART, USBH_PEN GPIO.

Introduce a U-Boot specific device tree with some required
u-boot,dm-pre-reloc properties: soc, aips0, pinctrl_ddr and uart0 incl.
pinctrl.

While at it also update the MAINTAINERS file.

Signed-off-by: Marcel Ziswiler 

---

 arch/arm/dts/vf-colibri-u-boot.dtsi  |  23 
 arch/arm/dts/vf-colibri.dtsi | 198 ++-
 arch/arm/dts/vf500-colibri.dts   |   1 +
 arch/arm/dts/vf610-colibri.dts   |   1 +
 board/toradex/colibri_vf/MAINTAINERS |   4 +-
 5 files changed, 224 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/vf-colibri-u-boot.dtsi

diff --git a/arch/arm/dts/vf-colibri-u-boot.dtsi 
b/arch/arm/dts/vf-colibri-u-boot.dtsi
new file mode 100644
index 00..db86739805
--- /dev/null
+++ b/arch/arm/dts/vf-colibri-u-boot.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+
+/ {
+   soc {
+   u-boot,dm-pre-reloc;
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+_ddr {
+   u-boot,dm-pre-reloc;
+};
+
+_uart0 {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/vf-colibri.dtsi b/arch/arm/dts/vf-colibri.dtsi
index 923dc2451c..5ce17076e9 100644
--- a/arch/arm/dts/vf-colibri.dtsi
+++ b/arch/arm/dts/vf-colibri.dtsi
@@ -1,18 +1,37 @@
 // SPDX-License-Identifier: GPL-2.0+ OR X11
 /*
- * Copyright 2014 Toradex AG
+ * Copyright 2014-2019 Toradex AG
  */
+
+/dts-v1/;
 #include "vf.dtsi"
+#include "vf610-pinfunc.h"
 
 / {
chosen {
stdout-path = 
};
+
+   aliases {
+   usb0 =  /* required for ums */
+   };
+
+   reg_usbh_vbus: regulator-usbh-vbus {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_usbh1_reg>;
+   regulator-name = "VCC_USB[1-4]";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 19 GPIO_ACTIVE_LOW>; /* USBH_PEN */
+   };
 };
 
  {
-   status = "okay";
bus-num = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_dspi1>;
+   status = "okay";
 
spi_cmd: sspi@0 {
reg = <0>;
@@ -29,8 +48,183 @@
  {
dr_mode = "host";
status = "okay";
+   vbus-supply = <_usbh_vbus>;
+};
+
+ {
+   bus-width = <4>;
+   cd-gpios = < 10 GPIO_ACTIVE_LOW>;
+   disable-wp;
+   pinctrl-names = "default";
+   pinctrl-0 = <_esdhc1>;
+   status = "okay";
+};
+
+ {
+   phy-mode = "rmii";
+   pinctrl-names = "default";
+   pinctrl-0 = <_fec1>;
+   status = "okay";
+};
+
+ {
+   clock-frequency = <40>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0>;
+   status = "okay";
+
+   /* M41T0M6 real time clock on carrier board */
+   rtc: m41t0m6@68 {
+   compatible = "st,m41t0";
+   reg = <0x68>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ddr>;
+
+   pinctrl_ddr: ddrgrp {
+   fsl,pins = <
+   VF610_PAD_DDR_A15__DDR_A_15 0x180
+   VF610_PAD_DDR_A14__DDR_A_14 0x180
+   VF610_PAD_DDR_A13__DDR_A_13 0x180
+   VF610_PAD_DDR_A12__DDR_A_12 0x180
+   VF610_PAD_DDR_A11__DDR_A_11 0x180
+   VF610_PAD_DDR_A10__DDR_A_10 0x180
+   VF610_PAD_DDR_A9__DDR_A_9   0x180
+   VF610_PAD_DDR_A8__DDR_A_8   0x180
+   VF610_PAD_DDR_A7__DDR_A_7   0x180
+   VF610_PAD_DDR_A6__DDR_A_6   0x180
+   VF610_PAD_DDR_A5__DDR_A_5   0x180
+   VF610_PAD_DDR_A4__DDR_A_4   0x180
+   VF610_PAD_DDR_A3__DDR_A_3   0x180
+   VF610_PAD_DDR_A2__DDR_A_2   0x180
+   VF610_PAD_DDR_A1__DDR_A_1   0x180
+   VF610_PAD_DDR_A0__DDR_A_0   0x180
+   VF610_PAD_DDR_BA2__DDR_BA_2 0x180
+   VF610_PAD_DDR_BA1__DDR_BA_1 0x180
+   VF610_PAD_DDR_BA0__DDR_BA_0 0x180
+   VF610_PAD_DDR_CAS__DDR_CAS_B0x180
+   VF610_PAD_DDR_CKE__DDR_CKE_00x180
+   VF610_PAD_DDR_CLK__DDR_CLK_00x180
+   VF610_PAD_DDR_CS__DDR_CS_B_0   

[U-Boot] [PATCH v1 03/22] imx: bootaux: add dependency on vf610

[Marcel Ziswiler]

From: Marcel Ziswiler 

Allow using bootaux also on VF610 aka Vybrid.

Signed-off-by: Marcel Ziswiler 

---

 arch/arm/mach-imx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index a1566cc2ad..313a886c6b 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -23,7 +23,7 @@ config IMX_RDC
 
 config IMX_BOOTAUX
bool "Support boot auxiliary core"
-   depends on ARCH_MX7 || ARCH_MX6
+   depends on ARCH_MX7 || ARCH_MX6 || ARCH_VF610
help
  bootaux [addr] to boot auxiliary core.
 
-- 
2.20.1

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

[U-Boot] [PATCH v1 14/22] colibri_vf: set fdtfile for distroboot

[Marcel Ziswiler]

From: Stefan Agner 

Set fdtfile to represent the current board. This allows distribution
to load the correct device tree, which in the module case often
deviates from the common fallback ${soc}-${board}${boardver}.dtb...

Signed-off-by: Stefan Agner 
Acked-by: Max Krummenacher 
Acked-by: Marcel Ziswiler 

---

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

diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 83a33ff786..0bbeeb902e 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -86,7 +86,8 @@
"ubi read ${fdt_addr_r} dtb && " \
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
-#define CONFIG_BOOTCOMMAND "run ubiboot; run distro_bootcmd;"
+#define CONFIG_BOOTCOMMAND "run ubiboot; " \
+   "setenv fdtfile ${soc}-colibri-${fdt_board}.dtb && run distro_bootcmd;"
 
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
@@ -108,7 +109,6 @@
"defargs=\0" \
"dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
"fdt_board=eval-v3\0" \
-   "fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
"fdt_fixup=;\0" \
"kernel_file=zImage\0" \
"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
-- 
2.20.1

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

[U-Boot] [PATCH v1 17/22] colibri_vf: disable undefined instruction events in user debug

[Marcel Ziswiler]

From: Stefan Agner 

It turns out that OpenSSL calls undefined instructions to detect
ARM capabilities at runtime (via SIGILL handler). This leads to
stack traces e.g. when logging in using SSH:
  [  877.464442] sshd (613): undefined instruction: pc=76ee2da8
  ...

Disable undefined instruction events since it is used as an
autodetecion mechanism.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 

---

 include/configs/colibri_vf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 030281bb67..b2f27c1977 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -106,7 +106,7 @@
SD_BOOTCMD \
UBI_BOOTCMD \
"console=ttyLP0\0" \
-   "defargs=user_debug=31\0" \
+   "defargs=user_debug=30\0" \
"dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
"fdt_board=eval-v3\0" \
"fdt_fixup=;\0" \
-- 
2.20.1

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

[U-Boot] [PATCH v1 16/22] colibri_vf: enable user debug by default

[Marcel Ziswiler]

From: Stefan Agner 

Let the kernel print some debug messages when a user program
crashes due to an exception.

Signed-off-by: Stefan Agner 
Acked-by: Marcel Ziswiler 

---

 include/configs/colibri_vf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 0bbeeb902e..030281bb67 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -106,7 +106,7 @@
SD_BOOTCMD \
UBI_BOOTCMD \
"console=ttyLP0\0" \
-   "defargs=\0" \
+   "defargs=user_debug=31\0" \
"dfu_alt_info=" DFU_ALT_NAND_INFO "\0" \
"fdt_board=eval-v3\0" \
"fdt_fixup=;\0" \
-- 
2.20.1

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

[U-Boot] [PATCH v1 06/22] configs: colibri_vf: limit size of malloc() pool before relocation

[Marcel Ziswiler]

From: Marcel Ziswiler 

Limit the size of the malloc() pool before relocation
(SYS_MALLOC_F_LEN).

Signed-off-by: Marcel Ziswiler 

---

 configs/colibri_vf_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
index 4192501257..8188582ed9 100644
--- a/configs/colibri_vf_defconfig
+++ b/configs/colibri_vf_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_SYS_THUMB_BUILD=y
 CONFIG_ARCH_VF610=y
 CONFIG_SYS_TEXT_BASE=0x3f401000
+CONFIG_SYS_MALLOC_F_LEN=0x800
 CONFIG_TARGET_COLIBRI_VF=y
 CONFIG_ENV_VARS_UBOOT_CONFIG=y
 CONFIG_NR_DRAM_BANKS=1
-- 
2.20.1

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

[U-Boot] [PATCH v1 05/22] configs: colibri_vf: remove obsolete mmc/sd card environment

[Marcel Ziswiler]

From: Marcel Ziswiler 

Remove obsolete MMC/SD card environment configuration dating back to
un-fused samples times.

While at it also remove meanwhile spurious "USB Storage" comment.

Signed-off-by: Marcel Ziswiler 

---

 include/configs/colibri_vf.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 2fe7f217fa..7b974d9e97 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -145,13 +145,6 @@
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)
 
 /* Environment organization */
-
-#ifdef CONFIG_ENV_IS_IN_MMC
-#define CONFIG_SYS_MMC_ENV_DEV 0
-#define CONFIG_ENV_OFFSET  (12 * 64 * 1024)
-#define CONFIG_ENV_SIZE(8 * 1024)
-#endif
-
 #ifdef CONFIG_ENV_IS_IN_NAND
 #define CONFIG_ENV_SIZE(64 * 2048)
 #define CONFIG_ENV_RANGE   (4 * 64 * 2048)
@@ -165,6 +158,4 @@
 /* USB DFU */
 #define CONFIG_SYS_DFU_DATA_BUF_SIZE (1024 * 1024)
 
-/* USB Storage */
-
 #endif /* __CONFIG_H */
-- 
2.20.1

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

[U-Boot] [PATCH v1 02/22] vf610: ddrmc: add missing include

[Marcel Ziswiler]

From: Marcel Ziswiler 

The DDR memory controller include file for the Vybrid uses
iomux_v3_cfg_t without actually including iomux-vf610.h.

Signed-off-by: Marcel Ziswiler 

---

 arch/arm/include/asm/arch-vf610/ddrmc-vf610.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/arch-vf610/ddrmc-vf610.h 
b/arch/arm/include/asm/arch-vf610/ddrmc-vf610.h
index c7da2b8a5e..03e3cecb95 100644
--- a/arch/arm/include/asm/arch-vf610/ddrmc-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/ddrmc-vf610.h
@@ -10,6 +10,8 @@
 #ifndef __ASM_ARCH_VF610_DDRMC_H
 #define __ASM_ARCH_VF610_DDRMC_H
 
+#include 
+
 struct ddr3_jedec_timings {
u8 tinit;
u32 trst_pwron;
-- 
2.20.1

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

[U-Boot] [PATCH v1 01/22] add missing space in comment

[Marcel Ziswiler]

From: Marcel Ziswiler 

Spottet two missing spaces in comments.

Signed-off-by: Marcel Ziswiler 

---

 board/freescale/imx8qxp_mek/imx8qxp_mek.c | 2 +-
 drivers/video/videomodes.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/freescale/imx8qxp_mek/imx8qxp_mek.c 
b/board/freescale/imx8qxp_mek/imx8qxp_mek.c
index a4c587a390..63cd605b6a 100644
--- a/board/freescale/imx8qxp_mek/imx8qxp_mek.c
+++ b/board/freescale/imx8qxp_mek/imx8qxp_mek.c
@@ -112,7 +112,7 @@ void build_info(void)
sc_misc_build_info(-1, _build, _commit);
if (!sc_build) {
printf("SCFW does not support build info\n");
-   sc_commit = 0; /* Display 0 when the build info is not 
supported*/
+   sc_commit = 0; /* Display 0 when the build info is not 
supported */
}
printf("Build: SCFW %x\n", sc_commit);
 }
diff --git a/drivers/video/videomodes.c b/drivers/video/videomodes.c
index 1cfeaa980f..d7614329ff 100644
--- a/drivers/video/videomodes.c
+++ b/drivers/video/videomodes.c
@@ -397,7 +397,7 @@ int video_edid_dtd_to_ctfb_res_modes(struct 
edid_detailed_timing *t,
EDID_DETAILED_TIMING_VERTICAL_BLANKING(*t) == 0 ||
EDID_DETAILED_TIMING_HSYNC_OFFSET(*t) == 0 ||
EDID_DETAILED_TIMING_VSYNC_OFFSET(*t) == 0 ||
-   /* 3d formats are not supported*/
+   /* 3d formats are not supported */
EDID_DETAILED_TIMING_FLAG_STEREO(*t) != 0)
return -EINVAL;
 
-- 
2.20.1

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

[U-Boot] [PATCH v2 1/2] watchdog: orion_wdt: support SPL usage

[Chris Packham]

When run from the SPL the mvebu targets are using the hardware default
offset for the SoC peripherals. devfdt_get_addr_size_index() understands
how to deal with this via dm_get_translation_offset() so use this
instead of fdtdec_get_addr_size_auto_noparent().

Signed-off-by: Chris Packham 
Reviewed-by: Stefan Roese 
---

Changes in v2: None

 drivers/watchdog/orion_wdt.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index a0df02d10382..c1add3e7c121 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -114,9 +114,7 @@ static inline bool save_reg_from_ofdata(struct udevice 
*dev, int index,
fdt_addr_t addr;
fdt_size_t off;
 
-   addr = fdtdec_get_addr_size_auto_noparent(
-   gd->fdt_blob, dev_of_offset(dev), "reg", index, , true);
-
+   addr = devfdt_get_addr_size_index(dev, index, );
if (addr == FDT_ADDR_T_NONE)
return false;
 
-- 
2.20.1

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

[U-Boot] [PATCH v2 2/2] arm: mvebu: x530: Enable watchdog in SPL and U-Boot

[Chris Packham]

Enable the hardware watchdog to guard against system lock ups when
running in the SPL or U-Boot. Stop the watchdog just before booting so
that the OS can re-enable it if needed.

Signed-off-by: Chris Packham 
---

Changes in v2:
- update commit message

 arch/arm/dts/armada-385-atl-x530-u-boot.dtsi |  4 ++
 board/alliedtelesis/x530/x530.c  | 48 
 configs/x530_defconfig   |  5 ++
 3 files changed, 57 insertions(+)

diff --git a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi 
b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
index 7074a73537fa..79b694cb84bc 100644
--- a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
+++ b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
@@ -11,3 +11,7 @@
  {
u-boot,dm-pre-reloc;
 };
+
+ {
+   u-boot,dm-pre-reloc;
+};
diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
index d7d1942fe686..1b22b6307cd2 100644
--- a/board/alliedtelesis/x530/x530.c
+++ b/board/alliedtelesis/x530/x530.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,10 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CONFIG_NVS_LOCATION0xf480
 #define CONFIG_NVS_SIZE(512 << 10)
 
+#ifdef CONFIG_WATCHDOG
+static struct udevice *watchdog_dev;
+#endif
+
 static struct serdes_map board_serdes_map[] = {
{PEX0, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
{DEFAULT_SERDES, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
@@ -75,6 +80,10 @@ struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
 
 int board_early_init_f(void)
 {
+#ifdef CONFIG_WATCHDOG
+   watchdog_dev = NULL;
+#endif
+
/* Configure MPP */
writel(0x, MVEBU_MPP_BASE + 0x00);
writel(0x, MVEBU_MPP_BASE + 0x04);
@@ -88,6 +97,17 @@ int board_early_init_f(void)
return 0;
 }
 
+void spl_board_init(void)
+{
+#ifdef CONFIG_WATCHDOG
+   int ret;
+
+   ret = uclass_get_device(UCLASS_WDT, 0, _dev);
+   if (!ret)
+   wdt_start(watchdog_dev, 2500ULL * 120, 0);
+#endif
+}
+
 int board_init(void)
 {
/* address of boot parameters */
@@ -100,9 +120,37 @@ int board_init(void)
/* DEV_READYn is not needed for NVS, ignore it when accessing CS1 */
writel(0x4001, MVEBU_DEV_BUS_BASE + 0xc8);
 
+   spl_board_init();
+
return 0;
 }
 
+void arch_preboot_os(void)
+{
+#ifdef CONFIG_WATCHDOG
+   wdt_stop(watchdog_dev);
+#endif
+}
+
+#ifdef CONFIG_WATCHDOG
+void watchdog_reset(void)
+{
+   static ulong next_reset = 0;
+   ulong now;
+
+   if (!watchdog_dev)
+   return;
+
+   now = timer_get_us();
+
+   /* Do not reset the watchdog too often */
+   if (now > next_reset) {
+   wdt_reset(watchdog_dev);
+   next_reset = now + 1000;
+   }
+}
+#endif
+
 static int led_7seg_init(unsigned int segments)
 {
int node;
diff --git a/configs/x530_defconfig b/configs/x530_defconfig
index 25b9e885d8e6..3bc37b9bee11 100644
--- a/configs/x530_defconfig
+++ b/configs/x530_defconfig
@@ -19,6 +19,8 @@ CONFIG_SILENT_CONSOLE=y
 CONFIG_SILENT_U_BOOT_ONLY=y
 CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC=y
 CONFIG_MISC_INIT_R=y
+CONFIG_SPL_BOARD_INIT=y
+CONFIG_SPL_WATCHDOG_SUPPORT=y
 CONFIG_CMD_MEMINFO=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
@@ -70,3 +72,6 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_WATCHDOG=y
+CONFIG_WDT=y
+CONFIG_WDT_ORION=y
-- 
2.20.1

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

[U-Boot] [PATCH v2 0/2] x530: Enable watchdog

[Chris Packham]

We've seen some issues with the x530 under extreme conditions where the
DDR gets into a bad state. Generally this results in an application
crash followed by a lock-up in u-boot.

Enabling the watchdog prevents the lock up and will let the DDR training
have another go. Sometimes this recovers but even a reboot loop is
better than a complete lockup.

Changes in v2:
- update commit message

Chris Packham (2):
  watchdog: orion_wdt: support SPL usage
  arm: mvebu: x530: Enable watchdog in SPL and U-Boot

 arch/arm/dts/armada-385-atl-x530-u-boot.dtsi |  4 ++
 board/alliedtelesis/x530/x530.c  | 48 
 configs/x530_defconfig   |  5 ++
 drivers/watchdog/orion_wdt.c |  4 +-
 4 files changed, 58 insertions(+), 3 deletions(-)

-- 
2.20.1

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

Re: [U-Boot] [PATCH 2/2] arm: mvebu: x530: Enable watchdog in SPL and U-Boot

[Chris Packham]

On Sat, Feb 16, 2019 at 12:23 AM Chris Packham  wrote:
>
>
>
> On Fri, 15 Feb 2019 21:46 Stefan Roese >
>> Hi Chris,
>>
>> On 15.02.19 03:12, Chris Packham wrote:
>> > Enable the hardware watchdog to guard against system lock ups when
>> > running in the SPL or U-Boot. Stop the watchdog just before booting so
>> > that the OS.
>> >
>> > Signed-off-by: Chris Packham 
>> > ---
>> >
>> >   arch/arm/dts/armada-385-atl-x530-u-boot.dtsi |  4 ++
>> >   board/alliedtelesis/x530/x530.c  | 48 
>> >   configs/x530_defconfig   |  5 ++
>> >   3 files changed, 57 insertions(+)
>> >
>> > diff --git a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi 
>> > b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
>> > index 7074a73537fa..79b694cb84bc 100644
>> > --- a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
>> > +++ b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
>> > @@ -11,3 +11,7 @@
>> >{
>> >   u-boot,dm-pre-reloc;
>> >   };
>> > +
>> > + {
>> > + u-boot,dm-pre-reloc;
>> > +};
>> > diff --git a/board/alliedtelesis/x530/x530.c 
>> > b/board/alliedtelesis/x530/x530.c
>> > index d7d1942fe686..1b22b6307cd2 100644
>> > --- a/board/alliedtelesis/x530/x530.c
>> > +++ b/board/alliedtelesis/x530/x530.c
>> > @@ -7,6 +7,7 @@
>> >   #include 
>> >   #include 
>> >   #include 
>> > +#include 
>> >   #include 
>> >   #include 
>> >   #include 
>> > @@ -24,6 +25,10 @@ DECLARE_GLOBAL_DATA_PTR;
>> >   #define CONFIG_NVS_LOCATION 0xf480
>> >   #define CONFIG_NVS_SIZE (512 << 10)
>> >
>> > +#ifdef CONFIG_WATCHDOG
>> > +static struct udevice *watchdog_dev;
>> > +#endif
>> > +
>> >   static struct serdes_map board_serdes_map[] = {
>> >   {PEX0, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
>> >   {DEFAULT_SERDES, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
>> > @@ -75,6 +80,10 @@ struct mv_ddr_topology_map 
>> > *mv_ddr_topology_map_get(void)
>> >
>> >   int board_early_init_f(void)
>> >   {
>> > +#ifdef CONFIG_WATCHDOG
>> > + watchdog_dev = NULL;
>> > +#endif
>> > +
>> >   /* Configure MPP */
>> >   writel(0x, MVEBU_MPP_BASE + 0x00);
>> >   writel(0x, MVEBU_MPP_BASE + 0x04);
>> > @@ -88,6 +97,17 @@ int board_early_init_f(void)
>> >   return 0;
>> >   }
>> >
>> > +void spl_board_init(void)
>> > +{
>> > +#ifdef CONFIG_WATCHDOG
>> > + int ret;
>> > +
>> > + ret = uclass_get_device(UCLASS_WDT, 0, _dev);
>> > + if (!ret)
>> > + wdt_start(watchdog_dev, 2500ULL * 120, 0);
>>
>> This is CONFIG_SYS_TCLK? Would it make sense to use this macro
>> instead here?
>
> Yes it would. I'll send a v2 with this change.
>

Spoke too soon. It's not SYS_TCLK but numerically it happens to be
SYS_TCLK / 10. I'd like to keep this as-is (I'll still send v2 with
the updated commit message).

> Ideally I'd specify the value in ms and have orion_wdt deal with the details 
> of SYS_TCLK.
>

I think this is actually what's needed. Right now orion_wdt justs
casts timeout_ms to u32 and uses it directly. It should figure out how
many timer ticks are needed (which will be a function of
CONFIG_SYS_TCLK) and figure out the value appropriately.

>>
>> > +#endif
>> > +}
>> > +
>> >   int board_init(void)
>> >   {
>> >   /* address of boot parameters */
>> > @@ -100,9 +120,37 @@ int board_init(void)
>> >   /* DEV_READYn is not needed for NVS, ignore it when accessing CS1 */
>> >   writel(0x4001, MVEBU_DEV_BUS_BASE + 0xc8);
>> >
>> > + spl_board_init();
>> > +
>> >   return 0;
>> >   }
>> >
>> > +void arch_preboot_os(void)
>> > +{
>> > +#ifdef CONFIG_WATCHDOG
>> > + wdt_stop(watchdog_dev);
>> > +#endif
>> > +}
>>
>> So you are not using the WDT in the OS (Linux)?
>>
>> > +
>> > +#ifdef CONFIG_WATCHDOG
>> > +void watchdog_reset(void)
>> > +{
>> > + static ulong next_reset = 0;
>> > + ulong now;
>> > +
>> > + if (!watchdog_dev)
>> > + return;
>> > +
>> > + now = timer_get_us();
>> > +
>> > + /* Do not reset the watchdog too often */
>> > + if (now > next_reset) {
>> > + wdt_reset(watchdog_dev);
>> > + next_reset = now + 1000;
>> > + }
>> > +}
>> > +#endif
>>
>> When I recently implemented the watchdog support the MT7688, I
>> wondered why there is so much code necessary, that each board
>> and platform needs to copy to get this real watchdog working.
>> We should definitely rework this at some time, so make this more
>> generic with less board specific code that could be shared.
>>
>> You don't need to change this here. I just wanted to express my
>> thoughts, as I'm stumbling over this code again.
>>
>> Other than this (and your commit text change):
>>
>> Reviewed-by: Stefan Roese 
>>
>> Thanks,
>> Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 7/9] power: regulator: s2mps11: Add enable delay

[Simon Glass]

Hi Krzysztof,

On Wed, 13 Feb 2019 at 17:47, Krzysztof Kozlowski  wrote:
>
> According to datasheet, the output on LDO regulators will start
> appearing after 10-15 us.
>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/power/regulator/s2mps11_regulator.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/regulator/s2mps11_regulator.c 
> b/drivers/power/regulator/s2mps11_regulator.c
> index 723d27f67c9a..1f1581852ee2 100644
> --- a/drivers/power/regulator/s2mps11_regulator.c
> +++ b/drivers/power/regulator/s2mps11_regulator.c
> @@ -551,7 +551,14 @@ static int ldo_get_enable(struct udevice *dev)
>
>  static int ldo_set_enable(struct udevice *dev, bool enable)
>  {
> -   return s2mps11_ldo_enable(dev, PMIC_OP_SET, );
> +   int ret;
> +
> +   ret = s2mps11_ldo_enable(dev, PMIC_OP_SET, );

How about:

if (ret)
return ret;

> +
> +   /* Wait the "enable delay" for voltage to start to rise */
> +   udelay(15);
> +
> +   return ret;

return 0;

>  }
>
>  static int ldo_get_mode(struct udevice *dev)
> --
> 2.17.1
>

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

Re: [U-Boot] [PATCH v1 1/2] dm: pinctrl: Avoid race condition on probe for UCLASS_PINCTRL

[Simon Glass]

On Fri, 15 Feb 2019 at 15:31, Patrice Chotard  wrote:
>
> In case of system with several pin-controller device, probe the first
> UCLASS_PINCTRL by seq number (defined by alias) to avoid race condition
> with I2C PINCONTROL driver for GPIO expander (GPIO expander need I2C bus,
> I2C driver need PINCONFIG).
>
> Signed-off-by: Patrick DELAUNAY 
> Signed-off-by: Patrice Chotard 
> ---
>
>  drivers/pinctrl/pinctrl-uclass.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)

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

Re: [U-Boot] [PATCH v1 2/2] dm: pinctrl: Skip gpio-controller node in pinconfig_post_bind()

[Simon Glass]

On Fri, 15 Feb 2019 at 15:31, Patrice Chotard  wrote:
>
> From: Patrick Delaunay 
>
> Some binding define child node gpio-controller without compatible property.
> This patch avoid to bind the pinconfig uclass to these node.

Some bindings define a child node gpio-controller without a compatible property.
Avoid binding the pinconfig uclass to these node since ...(add explanation here)

>
> Signed-off-by: Patrick Delaunay 
> Signed-off-by: Patrice Chotard 
> ---
>
>  drivers/pinctrl/pinctrl-uclass.c | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Simon Glass 


>
> diff --git a/drivers/pinctrl/pinctrl-uclass.c 
> b/drivers/pinctrl/pinctrl-uclass.c
> index abb622cfe79e..9df06a262cd5 100644
> --- a/drivers/pinctrl/pinctrl-uclass.c
> +++ b/drivers/pinctrl/pinctrl-uclass.c
> @@ -149,6 +149,9 @@ static int pinconfig_post_bind(struct udevice *dev)
> ofnode_get_property(node, "compatible", );
> if (ret >= 0)
> continue;
> +   /* If this node has "gpio-controller" property, skip */
> +   if (ofnode_read_bool(node, "gpio-controller"))
> +   continue;
>
> if (ret != -FDT_ERR_NOTFOUND)
> return ret;
> --
> 1.9.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] PRs, Breakage architecture

[Stefano Babic]

Hi Tom,

On 15/02/19 17:40, Tom Rini wrote:
> On Fri, Feb 15, 2019 at 05:16:40PM +0100, Stefano Babic wrote:
> 
>> Hi Tom,
>>
>> my run on Travis reports errors with sun8i and sun50i (I do not think
>> they are related to commits on u-boot-imx). I see on your travis that
>> you have a "WIP-14Feb2019 u-boot-sunxi merged", and this runs
>> succesfully (but not yet merged). So if I send a PR now, I have a broken
>> run on Travis. What is your expectation I should do ? Simply send a PR
>> because issues are known or wait until WIP-14Feb2019 goes to -master
>> (but this means a rebase of u-boto-imx) ?
> 
> As a rule, https://travis-ci.org/u-boot/u-boot/builds and master (so
> also https://travis-ci.org/trini/u-boot and master) is always green.

Got it.

>  If
> something fails in any of my WIP-* (or other things like TRAVIS-* or
> GC-*), then I fix the failure.
> 
> Looking at https://travis-ci.org/sbabic/u-boot-imx/jobs/493736548
> something in your PR is causing sunxi to overflow there.  You should be
> able to build for orangepi_pc2 locally and also see the overflow and
> bisect your way to what change is causing things to break.  It's just a
> coincidence that I'm testing a sunxi PR right now.

Understood, thanks ;-)

Starting bisecting

Stefano


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

Re: [U-Boot] [PATCH v2 8/8] spi: sun4i: Driver cleanup

[Jagan Teki]

On Fri, Feb 15, 2019 at 5:30 AM André Przywara  wrote:
>
> On 14/02/2019 08:36, Jagan Teki wrote:
> > - drop unused macros.
> > - use base instead of base_addr, for better code readability
>
> Actually this part is now pretty pointless, since we use it only a few
> times, and base_addr is actually more descriptive than just "base".

base can be easily understood as base address, I would usually prefer
as simple and meaningful as possible.

>
> > - move .probe and .ofdata_to_platdata functions in required
> >   places to add platdata support in future.
>
> I don't get the reason for that move?

As I explained above, if you add platdata in future we need separate
ifdefs, move above U_BOOT_DRIVER macro would keep the common code in
one place with one macro. and in fact it just follow similar to other
spi dm drivers. where probe and of_pladata core calls are below.

Example: drivers/spi/davinci_spi.c

>
> > - use sentinel sun4i_spi_ids.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> >  drivers/spi/sun4i_spi.c | 190 +---
> >  image.map   |   4 +
>
> Please keep this file for you ;-)

Sorry, its 3:00 AM work ;)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] PRs, Breakage architecture

[Tom Rini]

On Fri, Feb 15, 2019 at 05:16:40PM +0100, Stefano Babic wrote:

> Hi Tom,
> 
> my run on Travis reports errors with sun8i and sun50i (I do not think
> they are related to commits on u-boot-imx). I see on your travis that
> you have a "WIP-14Feb2019 u-boot-sunxi merged", and this runs
> succesfully (but not yet merged). So if I send a PR now, I have a broken
> run on Travis. What is your expectation I should do ? Simply send a PR
> because issues are known or wait until WIP-14Feb2019 goes to -master
> (but this means a rebase of u-boto-imx) ?

As a rule, https://travis-ci.org/u-boot/u-boot/builds and master (so
also https://travis-ci.org/trini/u-boot and master) is always green.  If
something fails in any of my WIP-* (or other things like TRAVIS-* or
GC-*), then I fix the failure.

Looking at https://travis-ci.org/sbabic/u-boot-imx/jobs/493736548
something in your PR is causing sunxi to overflow there.  You should be
able to build for orangepi_pc2 locally and also see the overflow and
bisect your way to what change is causing things to break.  It's just a
coincidence that I'm testing a sunxi PR right now.

-- 
Tom


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

[U-Boot] Pull request: BCM ARM changes

[Matthias Brugger]

The following changes since commit 97276a91db8e98f081a40ddf9dc8f81d4032a756:

  Prepare v2019.04-rc1 (2019-02-07 21:32:19 -0500)

are available in the Git repository at:

  https://github.com/mbgg/u-boot.git tags/2019.01-next

for you to fetch changes up to 7e2ae620e15ef578b8f2812ec21ec07fae6c1e2f:

  rpi: add Compute Module 3+ (2019-02-15 12:49:13 +0100)


- add compute module 3+
- fix 64 bit warning in bmp command


Adam Heinrich (1):
  cmd: bmp: Make integer-to-pointer cast platform, independent

Jonathan Gray (1):
  rpi: add Compute Module 3+

 board/raspberrypi/rpi/rpi.c | 5 +
 cmd/bmp.c   | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] PRs, Breakage architecture

[Stefano Babic]

Hi Tom,

my run on Travis reports errors with sun8i and sun50i (I do not think
they are related to commits on u-boot-imx). I see on your travis that
you have a "WIP-14Feb2019 u-boot-sunxi merged", and this runs
succesfully (but not yet merged). So if I send a PR now, I have a broken
run on Travis. What is your expectation I should do ? Simply send a PR
because issues are known or wait until WIP-14Feb2019 goes to -master
(but this means a rebase of u-boto-imx) ?

Thanks,
Stefano

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

Re: [U-Boot] [PATCH V2 3/3] sunxi: Fix A33 memory initialization

[Andre Przywara]

On Fri, 15 Feb 2019 17:01:40 +0100
Michael Nazzareno Trimarchi  wrote:

> Hi all
> 
> On Fri, Feb 15, 2019 at 12:40 PM Philipp Tomsich
>  wrote:
> >
> >
> >
> > Dipl.-Ing. Dr.techn. Philipp Tomsich
> > Theobroma Systems Design und Consulting GmbH
> > Seestadtstrasse 27 (Aspern IQ), A-1220 Wien, Austria
> > Phone: +43 1 2369893-401, Fax: +43 1 2369893-9-401
> > Cell phone: +43 664 8346109
> > http://www.theobroma-systems.com
> >
> >
> >
> >
> > On 15.02.2019, at 12:31, Andre Przywara  wrote:
> >
> > On Fri, 15 Feb 2019 11:18:38 +0100
> > Philipp Tomsich  wrote:
> >
> > Hi Philipp,
> >
> > On 14.02.2019, at 22:24, André Przywara  wrote:
> >
> > On 14/02/2019 16:36, Philipp Tomsich wrote:
> >
> >
> >
> > On 14.02.2019, at 16:58, Michael Trimarchi  
> > wrote:
> >
> > Set two rank timing and exit self-refresh timing seems not done
> > properly. We know use the same write that we are using
> > on H5 silicon. Tested was done in A33 allwinner cpu, dual rank
> > connection connected with two MT41K512M16HA-125:A memory model.
> > Memory is configure as DDR3 1.5V
> >  
> 
> I will fix the commit
> 
> > Signed-off-by: Michael Trimarchi 
> > ---
> >
> > V1->V2: adjust commit message
> >
> > ---
> > arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c 
> > b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> > index d73a93a132..355fe30aba 100644
> > --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
> > +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> > @@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para *para)
> > writel(reg_val, _ctl->dramtmg5);
> > /* Set two rank timing and exit self-refresh timing */
> > clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0),
> > - 0x33 << 8 | (0x8 << 0));
> > + 0x33 << 8 | (0x10 << 0));
> >
> >
> > How exactly does the change in constants match up with the commit message?
> > What is the field at “<< 0”?
> >
> >
> > From looking at the ZynqMP register guide, which is reported to be close
> > to the various Allwinner DRAM controllers, bits [6:0] are tXS: Self
> > refresh exit delay. Increasing that should not hurt, and if I understand
> > it correctly it only affects the time after the self-refresh *exit*,
> > which happens only after (re-)initialisation(?).
> >  
> 
> Seems that affect the initialization sequence.
> 
> >
> > The “set two rank timing” comment doesn’t match our expectation that
> > this will be self-refresh timings, as on the ZynqMP or the A80.  
> 
> The comment is the original one
> 
> > Self-refresh only happens, if someone puts the DRAM into self-refresh
> > (i.e. “suspend to DRAM”) and then resumes it.  I don’t see a reference
> > to the error occurring from this.
> >
> >
> > So I was wondering about this as well. Indeed we don't seem to *explicitly* 
> > enter or exit Self-Refresh anywhere, but maybe this is done implicitly as 
> > part of some training phase?
> > I might be wrong about this, but in some DDR3 documentation I see that 
> > changing the DLL state is connected to self refresh, and enabling the DLL 
> > is required as part of the initialisation? So is the DRAMC somehow 
> > triggering a self refresh exit "magically"? If I understand this correctly, 
> > our ranking test does reset the controller?
> >
> >
> > I’d need to reread JESD79 (a much more relaxing read than the daily news),
> > to figure out whether there’s any valid reason to play with self-refresh 
> > during
> > the training.
> >
> > That said, if the field indeed was the exit self-refresh timing, this would
> > usually be tXSDLL, encoded as tXSDLL/32. JESD79 specifies tESXR as
> > tXSDLL (which in turn is tDLLK(min)), which is 512 nCK always: 0x10
> > would be 512 and 0x08 would only be 256… then again, this should only
> > matter when exiting self-refresh.
> >  
> 
> What is the best option here? create a better commit or try to go in deep.

Well, we don't need to get this out of hand:
1) This change affects all A33 systems, unconditionally. We would need 
confirmation from owners of those other systems that it still works for them.
2) Yes, the commit message should be changed. Please state the issue you have 
seen, maybe roughly summarise our guesses here. Then mention that this changes 
the DRAM init part for all A33 users.

Cheers,
Andre.

> 
> >
> > So I was looking at this:
> > https://www.xilinx.com/html_docs/registers/ug1087/ddrc___dramtmg8.html
> > and tXSDLL is bits [14:8], while the non-DLL tXS is bits [6:0].
> >
> > Note that the ‘auto-enter self-refresh’ functionality is controlled through
> > BIT(3) in PWRCTL on the A33, according to Allwinner’s basic_loader.
> > I don’t know whether that may be turned on by the driver (i.e. didn’t
> > check).
> >
> >
> > I don't see us touching pwrctl for the A33 (but for the A23).
> >
> > OTOH, when working with an underdocumented DRAM register layout
> > and once one has an educated guess at what register/setting may be
> > affected, a 

Re: [U-Boot] [PATCH V2 3/3] sunxi: Fix A33 memory initialization

[Michael Nazzareno Trimarchi]

Hi all

On Fri, Feb 15, 2019 at 12:40 PM Philipp Tomsich
 wrote:
>
>
>
> Dipl.-Ing. Dr.techn. Philipp Tomsich
> Theobroma Systems Design und Consulting GmbH
> Seestadtstrasse 27 (Aspern IQ), A-1220 Wien, Austria
> Phone: +43 1 2369893-401, Fax: +43 1 2369893-9-401
> Cell phone: +43 664 8346109
> http://www.theobroma-systems.com
>
>
>
>
> On 15.02.2019, at 12:31, Andre Przywara  wrote:
>
> On Fri, 15 Feb 2019 11:18:38 +0100
> Philipp Tomsich  wrote:
>
> Hi Philipp,
>
> On 14.02.2019, at 22:24, André Przywara  wrote:
>
> On 14/02/2019 16:36, Philipp Tomsich wrote:
>
>
>
> On 14.02.2019, at 16:58, Michael Trimarchi  
> wrote:
>
> Set two rank timing and exit self-refresh timing seems not done
> properly. We know use the same write that we are using
> on H5 silicon. Tested was done in A33 allwinner cpu, dual rank
> connection connected with two MT41K512M16HA-125:A memory model.
> Memory is configure as DDR3 1.5V
>

I will fix the commit

> Signed-off-by: Michael Trimarchi 
> ---
>
> V1->V2: adjust commit message
>
> ---
> arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c 
> b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> index d73a93a132..355fe30aba 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> @@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para *para)
> writel(reg_val, _ctl->dramtmg5);
> /* Set two rank timing and exit self-refresh timing */
> clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0),
> - 0x33 << 8 | (0x8 << 0));
> + 0x33 << 8 | (0x10 << 0));
>
>
> How exactly does the change in constants match up with the commit message?
> What is the field at “<< 0”?
>
>
> From looking at the ZynqMP register guide, which is reported to be close
> to the various Allwinner DRAM controllers, bits [6:0] are tXS: Self
> refresh exit delay. Increasing that should not hurt, and if I understand
> it correctly it only affects the time after the self-refresh *exit*,
> which happens only after (re-)initialisation(?).
>

Seems that affect the initialization sequence.

>
> The “set two rank timing” comment doesn’t match our expectation that
> this will be self-refresh timings, as on the ZynqMP or the A80.

The comment is the original one

> Self-refresh only happens, if someone puts the DRAM into self-refresh
> (i.e. “suspend to DRAM”) and then resumes it.  I don’t see a reference
> to the error occurring from this.
>
>
> So I was wondering about this as well. Indeed we don't seem to *explicitly* 
> enter or exit Self-Refresh anywhere, but maybe this is done implicitly as 
> part of some training phase?
> I might be wrong about this, but in some DDR3 documentation I see that 
> changing the DLL state is connected to self refresh, and enabling the DLL is 
> required as part of the initialisation? So is the DRAMC somehow triggering a 
> self refresh exit "magically"? If I understand this correctly, our ranking 
> test does reset the controller?
>
>
> I’d need to reread JESD79 (a much more relaxing read than the daily news),
> to figure out whether there’s any valid reason to play with self-refresh 
> during
> the training.
>
> That said, if the field indeed was the exit self-refresh timing, this would
> usually be tXSDLL, encoded as tXSDLL/32. JESD79 specifies tESXR as
> tXSDLL (which in turn is tDLLK(min)), which is 512 nCK always: 0x10
> would be 512 and 0x08 would only be 256… then again, this should only
> matter when exiting self-refresh.
>

What is the best option here? create a better commit or try to go in deep.

>
> So I was looking at this:
> https://www.xilinx.com/html_docs/registers/ug1087/ddrc___dramtmg8.html
> and tXSDLL is bits [14:8], while the non-DLL tXS is bits [6:0].
>
> Note that the ‘auto-enter self-refresh’ functionality is controlled through
> BIT(3) in PWRCTL on the A33, according to Allwinner’s basic_loader.
> I don’t know whether that may be turned on by the driver (i.e. didn’t
> check).
>
>
> I don't see us touching pwrctl for the A33 (but for the A23).
>
> OTOH, when working with an underdocumented DRAM register layout
> and once one has an educated guess at what register/setting may be
> affected, a DRAM protocol analyzer can provide conclusive answers
> by looking at the differences in behaviour with 0x8 and 0x10 in that
> bitfield…

Nice to have but It's not my case. The best for me is update the commit
message and give more info there. Add the memory components and the layout of my
setup, ask to test other boards before get included

Michael

>
>
> All I have is a multimeter and no A33 ;-)
>
>
> You are aware that was more of a philosophical rambling and not intended
> as a request to you…
> However, I am way more surprised that none of the parties having money
> riding on their A33 designs has gone through the required effort.
>
> Cheers,
> Philipp.
>


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| 

Re: [U-Boot] [PATCH 3/3] sunxi: display: Implement fallback to ddc probe when hpd fails

[Anatolij Gustschin]

On Wed, 19 Dec 2018 15:06:09 +0200
Priit Laes pl...@plaes.org wrote:

> From: Priit Laes 
> 
> There are HDMI displays where hpd pin is not connected, thus
> we cannot get it to work unless we specifically set the resolution.
> 
> Rework the display probing, so hotplug detect failure causes
> fallback to probing ddc for EDID data.
> 
> Signed-off-by: Priit Laes 
> ---
>  drivers/video/sunxi/sunxi_display.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)

Applied to u-boot-video/master, thanks!

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

Re: [U-Boot] [PATCH 2/3] sunxi: display: Move DDC PLL setup to HDMI init

[Anatolij Gustschin]

On Wed, 19 Dec 2018 15:06:08 +0200
Priit Laes pl...@plaes.org wrote:

> From: Priit Laes 
> 
> Move PLL initialization code to single place so
> we won't call it every time we query for EDID data.
> 
> Signed-off-by: Priit Laes 
> ---
>  drivers/video/sunxi/sunxi_display.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)

Applied to u-boot-video/master, thanks!

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

Re: [U-Boot] [PATCH 1/3] videomodes: Allow EDID timings where hsync/vsync pulse is 0

[Anatolij Gustschin]

Hi Jagan,

On Thu, 14 Feb 2019 22:42:51 +0530
Jagan Teki ja...@amarulasolutions.com wrote:
... 
> Any comments? I will mark these patches to you will that be OK?

OK, thanks.

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

Re: [U-Boot] [PATCH v2 1/3] sunxi: Sync Bananapi M2+ device tree from Linux v5.0-rc1

[Jagan Teki]

On Fri, Feb 15, 2019 at 7:46 PM Andre Przywara  wrote:
>
> On Fri, 15 Feb 2019 19:28:20 +0530
> Jagan Teki  wrote:
>
> > On Fri, Feb 15, 2019 at 4:33 PM Chen-Yu Tsai  wrote:
> > >
> > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> > > device tree for the Bananapi M2+ has been split into a common dtsi
> > > file, and an SoC-specific board device tree file that includes both
> > > the shared dtsi file and the soc dtsi file. This was done to support
> > > both the H3 and H5 variants of the same board. This is similar to what
> > > was done for the Libre Computer ALL-H3-CC in U-boot commit
> > > d7b17f1c24af ("sunxi: Split out common board design for ALL-H3-CC
> > > device tree").
> > >
> > > The newly split files are directly synced from Linux tag v5.0-rc1.
> >
> > Based on my previous patch comment, I expected to have full sync with
> > all H3 related files. any plan?
>
> Weren't you dismissing the idea because of "past the MW"?
>
> So coming back to that discussion, I was wondering how DT *updates* are
> actually a new feature (from a U-Boot perspective)?

I would consider as new feature, since I have encountered an mmc issue
due to sync[1] atleast some thing broken with sync during MW.

> Actually I see a lot of warnings from dtc about various things in our
> older .dts's, which spoils buildman runs. From this point of view updating
> the DTs is a mere fix (as they remove these warnings).
> So would you be willing to push for DT updates for this U-Boot release
> still, if I can show that U-Boot is not affected by the DT updates? Stuff
> like adding audio DT nodes have actually zero risk of affecting U-Boot ;-)

I don't believe 100% based on my experience with [1] . I agree with
above lot of warnings older stuff, but I'm considering dts syncs as
part of MW as well to avoid regressions. please see my last PR about
sync[2].

[1] https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg29264.html
[2] https://patchwork.ozlabs.org/patch/976408/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v1 4/4] ARM: dts: Add STMFX gpio expander support for stm32mp157c-ev1

[Patrice Chotard]

From: Patrick Delaunay 

Adds alias to set the pincontrol seq id.
For STMFX gpio expander, force sequence number after
the last bank (GPIOZ) to avoid conflict between STM32MP and STMFX
gpio bank sequence number.

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi |  3 +++
 arch/arm/dts/stm32mp157c-ev1.dts | 18 ++
 2 files changed, 21 insertions(+)

diff --git a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
index be3b1526288f..aafda5b58c0d 100644
--- a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
@@ -7,8 +7,11 @@
 
 / {
aliases {
+   gpio26 = _pinctrl;
i2c1 = 
i2c4 = 
+   pinctrl0 = 
+   pinctrl1 = _z;
spi0 = 
};
 };
diff --git a/arch/arm/dts/stm32mp157c-ev1.dts b/arch/arm/dts/stm32mp157c-ev1.dts
index e114c9b628b8..a6ee37924fe1 100644
--- a/arch/arm/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/dts/stm32mp157c-ev1.dts
@@ -98,6 +98,24 @@
i2c-scl-rising-time-ns = <185>;
i2c-scl-falling-time-ns = <20>;
status = "okay";
+
+   stmfx: stmfx@42 {
+   compatible = "st,stmfx-0300";
+   reg = <0x42>;
+   interrupts = <8 IRQ_TYPE_EDGE_RISING>;
+   interrupt-parent = <>;
+   vdd-supply = <>;
+
+   stmfx_pinctrl: stmfx-pin-controller {
+   compatible = "st,stmfx-0300-pinctrl";
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-ranges = <_pinctrl 0 0 24>;
+   status = "disabled";
+   };
+   };
 };
 
  {
-- 
1.9.1

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

[U-Boot] [PATCH v1 0/4] Add STMFX gpio expander support for stm32mp157c-ev1 board

[Patrice Chotard]

This series adds:
  - STMFX pinctrl driver
  - update STM32MP15 basic and trusted config
  - Add stmfx node in stm32mp157c-ev1 DT
  - Update stm32mp1 board to probe pinctrl drivers early to be
able to hog pins.

There are dependencies with :
  - http://patchwork.ozlabs.org/project/uboot/list/?series=92268
  - http://patchwork.ozlabs.org/project/uboot/list/?series=91422
which must be merged first.



Patrice Chotard (1):
  board: stm32mp1: Force pinctrl driver probe in board_init()

Patrick Delaunay (3):
  pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver
  config: stm32mp15: Enable STMFX support
  ARM: dts: Add STMFX gpio expander support for stm32mp157c-ev1

 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi |   3 +
 arch/arm/dts/stm32mp157c-ev1.dts |  18 ++
 board/st/stm32mp1/stm32mp1.c |   9 +
 configs/stm32mp15_basic_defconfig|   5 +-
 configs/stm32mp15_trusted_defconfig  |   5 +-
 drivers/pinctrl/Kconfig  |  19 ++
 drivers/pinctrl/Makefile |   1 +
 drivers/pinctrl/pinctrl-stmfx.c  | 431 +++
 8 files changed, 487 insertions(+), 4 deletions(-)
 create mode 100644 drivers/pinctrl/pinctrl-stmfx.c

-- 
1.9.1

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

[U-Boot] [PATCH v1 1/4] pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver

[Patrice Chotard]

From: Patrick Delaunay 

This patch adds pinctrl/GPIO driver for STMicroelectronics
Multi-Function eXpander (STMFX) GPIO expander.
STMFX is an I2C slave controller, offering up to 24 GPIOs.
The driver relies on UCLASS_PINCTRL and UCLASS_GPIO.

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
---

 drivers/pinctrl/Kconfig |  19 ++
 drivers/pinctrl/Makefile|   1 +
 drivers/pinctrl/pinctrl-stmfx.c | 431 
 3 files changed, 451 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-stmfx.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index be709f73d7df..a0ac167d145a 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -209,6 +209,25 @@ config PINCTRL_STM32
  the GPIO definitions and pin control functions for each available
  multiplex function.
 
+config PINCTRL_STMFX
+   bool "STMicroelectronics STMFX I2C GPIO expander pinctrl driver"
+   depends on DM && PINCTRL_FULL
+   help
+ I2C driver for STMicroelectronics Multi-Function eXpander (STMFX)
+ GPIO expander.
+ Supports pin multiplexing control on stm32 SoCs.
+
+ The driver is controlled by a device tree node which contains both
+ the GPIO definitions and pin control functions for each available
+ multiplex function.
+
+config SPL_PINCTRL_STMFX
+   bool "STMicroelectronics STMFX I2C GPIO expander pinctrl driver in SPL"
+   depends on SPL_PINCTRL_FULL
+   help
+ This option is an SPL-variant of the SPL_PINCTRL_STMFX option.
+ See the help of PINCTRL_STMFX for details.
+
 config ASPEED_AST2500_PINCTRL
   bool "Aspeed AST2500 pin control driver"
   depends on DM && PINCTRL_GENERIC && ASPEED_AST2500
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index e2c2b159d8c8..4b080b74dcd1 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -22,4 +22,5 @@ obj-$(CONFIG_ARCH_MVEBU)  += mvebu/
 obj-$(CONFIG_PINCTRL_SINGLE)   += pinctrl-single.o
 obj-$(CONFIG_PINCTRL_STI)  += pinctrl-sti.o
 obj-$(CONFIG_PINCTRL_STM32)+= pinctrl_stm32.o
+obj-$(CONFIG_$(SPL_)PINCTRL_STMFX) += pinctrl-stmfx.o
 obj-y  += broadcom/
diff --git a/drivers/pinctrl/pinctrl-stmfx.c b/drivers/pinctrl/pinctrl-stmfx.c
new file mode 100644
index ..5431df9813a1
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-stmfx.c
@@ -0,0 +1,431 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * Driver for STMicroelectronics Multi-Function eXpander (STMFX) GPIO expander
+ * based on Linux driver : pinctrl/pinctrl-stmfx.c
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* STMFX pins = GPIO[15:0] + aGPIO[7:0] */
+#define STMFX_MAX_GPIO 16
+#define STMFX_MAX_AGPIO8
+
+/* General */
+#define STMFX_REG_CHIP_ID  0x00 /* R */
+#define STMFX_REG_FW_VERSION_MSB   0x01 /* R */
+#define STMFX_REG_FW_VERSION_LSB   0x02 /* R */
+#define STMFX_REG_SYS_CTRL 0x40 /* RW */
+
+/* MFX boot time is around 10ms, so after reset, we have to wait this delay */
+#define STMFX_BOOT_TIME_MS 10
+
+/* GPIOs expander */
+/* GPIO_STATE1 0x10, GPIO_STATE2 0x11, GPIO_STATE3 0x12 */
+#define STMFX_REG_GPIO_STATE   0x10 /* R */
+/* GPIO_DIR1 0x60, GPIO_DIR2 0x61, GPIO_DIR3 0x63 */
+#define STMFX_REG_GPIO_DIR 0x60 /* RW */
+/* GPIO_TYPE1 0x64, GPIO_TYPE2 0x65, GPIO_TYPE3 0x66 */
+#define STMFX_REG_GPIO_TYPE0x64 /* RW */
+/* GPIO_PUPD1 0x68, GPIO_PUPD2 0x69, GPIO_PUPD3 0x6A */
+#define STMFX_REG_GPIO_PUPD0x68 /* RW */
+/* GPO_SET1 0x6C, GPO_SET2 0x6D, GPO_SET3 0x6E */
+#define STMFX_REG_GPO_SET  0x6C /* RW */
+/* GPO_CLR1 0x70, GPO_CLR2 0x71, GPO_CLR3 0x72 */
+#define STMFX_REG_GPO_CLR  0x70 /* RW */
+
+/* STMFX_REG_CHIP_ID bitfields */
+#define STMFX_REG_CHIP_ID_MASK GENMASK(7, 0)
+
+/* STMFX_REG_SYS_CTRL bitfields */
+#define STMFX_REG_SYS_CTRL_GPIO_EN BIT(0)
+#define STMFX_REG_SYS_CTRL_ALTGPIO_EN  BIT(3)
+#define STMFX_REG_SYS_CTRL_SWRST   BIT(7)
+
+#define NR_GPIO_REGS   3
+#define NR_GPIOS_PER_REG   8
+#define get_reg(offset)((offset) / NR_GPIOS_PER_REG)
+#define get_shift(offset)  ((offset) % NR_GPIOS_PER_REG)
+#define get_mask(offset)   (BIT(get_shift(offset)))
+
+struct stmfx_pinctrl {
+   struct udevice *gpio;
+};
+
+static int stmfx_read(struct udevice *dev, uint offset)
+{
+   return  dm_i2c_reg_read(dev_get_parent(dev), offset);
+}
+
+static int stmfx_write(struct udevice *dev, uint offset, unsigned int val)
+{
+   return dm_i2c_reg_write(dev_get_parent(dev), offset, val);
+}
+
+static int stmfx_gpio_get(struct udevice *dev, unsigned int offset)
+{
+   u32 reg = 

[U-Boot] [PATCH v1 3/4] board: stm32mp1: Force pinctrl driver probe in board_init()

[Patrice Chotard]

In order to insure that hog GPIOs are configured early during
the boot process, force all pinctrl driver probing in board_init().

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
---

 board/st/stm32mp1/stm32mp1.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 253094e6b418..7b3383547b1c 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -372,9 +372,18 @@ int board_late_init(void)
 /* board dependent setup after realloc */
 int board_init(void)
 {
+   struct udevice *dev;
+
/* address of boot parameters */
gd->bd->bi_boot_params = STM32_DDR_BASE + 0x100;
 
+   /* probe all PINCTRL for hog */
+   for (uclass_first_device(UCLASS_PINCTRL, );
+dev;
+uclass_next_device()) {
+   pr_debug("probe pincontrol = %s\n", dev->name);
+   }
+
if (IS_ENABLED(CONFIG_LED))
led_default_state();
 
-- 
1.9.1

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

[U-Boot] [PATCH v1 2/4] config: stm32mp15: Enable STMFX support

[Patrice Chotard]

From: Patrick Delaunay 

Activate PINCTRL_STMFX and needed part for generic pincontrol
PINCTRL_FULL, PINCONF. Increase pre-reloc memory for MALLOC
(needed for each DM pinconfig node).

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
---

 configs/stm32mp15_basic_defconfig   | 5 +++--
 configs/stm32mp15_trusted_defconfig | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/configs/stm32mp15_basic_defconfig 
b/configs/stm32mp15_basic_defconfig
index ac597c75c355..68bccaaed63a 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_STM32MP=y
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SYS_MALLOC_F_LEN=0x3000
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL=y
 CONFIG_TARGET_STM32MP1=y
@@ -42,8 +42,9 @@ CONFIG_DM_MMC=y
 CONFIG_STM32_SDMMC2=y
 CONFIG_PHY=y
 CONFIG_PHY_STM32_USBPHYC=y
-# CONFIG_PINCTRL_FULL is not set
+CONFIG_PINCONF=y
 # CONFIG_SPL_PINCTRL_FULL is not set
+CONFIG_PINCTRL_STMFX=y
 CONFIG_DM_PMIC=y
 # CONFIG_SPL_PMIC_CHILDREN is not set
 CONFIG_PMIC_STPMIC1=y
diff --git a/configs/stm32mp15_trusted_defconfig 
b/configs/stm32mp15_trusted_defconfig
index 3e8a6fd43f9b..ed0962cb561b 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_STM32MP=y
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SYS_MALLOC_F_LEN=0x3000
 CONFIG_TARGET_STM32MP1=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_NR_DRAM_BANKS=1
@@ -35,7 +35,8 @@ CONFIG_DM_MMC=y
 CONFIG_STM32_SDMMC2=y
 CONFIG_PHY=y
 CONFIG_PHY_STM32_USBPHYC=y
-# CONFIG_PINCTRL_FULL is not set
+CONFIG_PINCONF=y
+CONFIG_PINCTRL_STMFX=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_STPMIC1=y
 CONFIG_DM_REGULATOR_FIXED=y
-- 
1.9.1

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

Re: [U-Boot] Clock drivers for SiFive FU540

[Simon Glass]

On Thu, 14 Feb 2019 at 06:29, Anup Patel  wrote:
>
> Hi Simon,
>
> I have addressed your comments on fixed-factor clock driver.
>
> Can you please re-look at clock driver patches for SiFive FU540?
> https://patchwork.ozlabs.org/patch/1039635/
> https://patchwork.ozlabs.org/patch/1039638/
>
> Is it possible to include these patches for U-Boot-2019.04?
>
> Regards,
> Anup
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/3] sunxi: Sync Bananapi M2+ device tree from Linux v5.0-rc1

[Andre Przywara]

On Fri, 15 Feb 2019 19:28:20 +0530
Jagan Teki  wrote:

> On Fri, Feb 15, 2019 at 4:33 PM Chen-Yu Tsai  wrote:
> >
> > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> > device tree for the Bananapi M2+ has been split into a common dtsi
> > file, and an SoC-specific board device tree file that includes both
> > the shared dtsi file and the soc dtsi file. This was done to support
> > both the H3 and H5 variants of the same board. This is similar to what
> > was done for the Libre Computer ALL-H3-CC in U-boot commit
> > d7b17f1c24af ("sunxi: Split out common board design for ALL-H3-CC
> > device tree").
> >
> > The newly split files are directly synced from Linux tag v5.0-rc1.  
> 
> Based on my previous patch comment, I expected to have full sync with
> all H3 related files. any plan?

Weren't you dismissing the idea because of "past the MW"?

So coming back to that discussion, I was wondering how DT *updates* are
actually a new feature (from a U-Boot perspective)?
Actually I see a lot of warnings from dtc about various things in our
older .dts's, which spoils buildman runs. From this point of view updating
the DTs is a mere fix (as they remove these warnings).
So would you be willing to push for DT updates for this U-Boot release
still, if I can show that U-Boot is not affected by the DT updates? Stuff
like adding audio DT nodes have actually zero risk of affecting U-Boot ;-)

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

[U-Boot] [PATCH v1 0/2] Update pinctrl-uclass

[Patrice Chotard]

This series adds:
  - For system with multiple pincontroller device, insure
probe order to avoid race condition using sequence number (alias)
  - Avoid to bind child node with gpio-controller properties.


Patrice Chotard (1):
  dm: pinctrl: Avoid race condition on probe for UCLASS_PINCTRL

Patrick Delaunay (1):
  dm: pinctrl: Skip gpio-controller node in pinconfig_post_bind()

 drivers/pinctrl/pinctrl-uclass.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

-- 
1.9.1

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

[U-Boot] [GIT PULL] Xilinx patches for v2019.04-rc2

[Michal Simek]

Hi Tom,

please pull these patches to your tree. I had to wait a little bit when
i2c dm patches are applied which is done now.
The biggest changes are that all platforms are using DM_I2C that's why
it was possible to get rid of board files in include/configs/ and also
old driver.
Another one is moving to distro boot with qspi and nand support as
primary boot method. It was supported in past but not at the first place.

Buildman looks good.
Yesterday travis looked good but I have decided not to include two
gmii2rgmii patches because there are some stuff which I am not happy
with. That's why rerunning it again but don't expecting issue with it.

https://travis-ci.org/michalsimek/u-boot/builds/493774726

Thanks,
Michal


The following changes since commit 63f7e3fca391a50a499fed828fe16325fdee45f3:

  Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot
(2019-02-13 07:12:29 -0500)

are available in the git repository at:


  git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2019.04-rc2

for you to fetch changes up to 91d7e0c47f51e73cd8357f023ffc7c217a3c7291:

  arm64: zynqmp: Create fdtfile from compatible string (2019-02-15
15:04:01 +0100)


Xilinx changes for v2019.04-rc2

xilinx:
- Start to use distro boot commands first
- Setup fdtfile on ZynqMP
- Move mac addr eeprom read to common location
- Convert to OF_SEPARATE
- Switch all board to DM_I2C
- Some DT syncs

i2c:
- Remove !DM_I2C zynq driver

versal:
- Enable some more features
- Add mini configurations


Amit Kucheria (1):
  arm64: dts: Fix various entry-method properties to reflect
documentation

Luis Araneda (2):
  ARM: dts: zynq: Set correct manufacturer for ZedBoard and MicroZed
boards
  ARM: dts: zynq: correct and improve the model property of dt files

Michal Simek (23):
  ARM: zynq: Run distribution boot commands first
  xilinx: Move zynq_board_read_rom_ethaddr to shared location
  xilinx: common: Add support for DM_I2C zynq_board_read_rom_ethaddr()
  ARM: zynq: Convert Antminer to OF_SEPARATE
  arm64: versal: Enable different ethernet phy for virt platform
  spi: zynqmp_gqspi: Enable versal compatible string
  arm64: versal: Disable showing information about console
  arm64: versal: Remove one level of indentation in board_early_init_r()
  arm64: versal: Move IOU_SWITCH_DIVISOR0 to Kconfig
  ARM: zynq: Convert Syzygy to DM_I2C
  ARM: zynq: Convert dlc20 and zc70x board to DM_I2C
  ARM: zynq: Remove addresses for i2c controllers
  arm64: zynqmp: Switch all platforms to DM_I2C
  arm64: zynqmp: Remove addresses for i2c controllers
  i2c: Remove ancient zynq_i2c driver
  xilinx: common: Remove !DM_i2C code for reading mac from eeprom
  arm64: zynqmp: Fix logic around CONFIG_ZYNQ_SDHCI
  arm64: zynqmp: Remove SPD related configurations
  arm64: zynqmp: Remove board config files
  ARM: dts: Use mmc@ instead sdhci@
  xilinx: dts: Remove additional empty lines
  arm64: zynqmp: Remove autodetected devices without description
  arm64: zynqmp: Create fdtfile from compatible string

Mounika Grace Akula (1):
  arm64: zynqmp: Add reset-on-timeout for all boards and modify
default timeout value

Shubhrajyoti Datta (1):
  arm64: zynqmp: Fix i2c boot warning

Siva Durga Prasad Paladugu (7):
  arm64: zynqmp: Define distro boot commnads for qspi and nand
  arm64: versal: Add new Kconfig SYS_MEM_RSVD_FOR_MMU
  arm64: versal: Add mini eMMC configuration
  arm: zynq: Define distro boot commnads for qspi, nand and nor
  arm: zynq: Update boot_targets based on bootmode
  arm64: versal: Define distro boot commnads for qspi ospi and mmc
  arm64: versal: Add mini configuration for Versal

Venkatesh Yadav Abbarapu (1):
  arm64: zynqmp: Change the spi-rx-bus-width property to x1

 README   |   5 ---
 arch/arm/dts/Makefile|   4 ++
 arch/arm/dts/versal-mini-emmc0.dts   |  64

 arch/arm/dts/versal-mini-emmc1.dts   |  64

 arch/arm/dts/versal-mini.dts |  36 ++
 arch/arm/dts/zynq-7000.dtsi  |   4 +-
 arch/arm/dts/zynq-cc108.dts  |   2 +-
 arch/arm/dts/zynq-microzed.dts   |   2 +-
 arch/arm/dts/zynq-syzygy-hub.dts |   6 +++
 arch/arm/dts/zynq-zc702.dts  |   2 +-
 arch/arm/dts/zynq-zc706.dts  |   2 +-
 arch/arm/dts/zynq-zc770-xm010.dts|   3 +-
 arch/arm/dts/zynq-zc770-xm011.dts|   2 +-
 arch/arm/dts/zynq-zc770-xm012.dts|   2 +-
 arch/arm/dts/zynq-zc770-xm013.dts|   2 +-
 arch/arm/dts/zynq-zed.dts|   4 +-
 

[U-Boot] [PATCH v1 2/2] dm: pinctrl: Skip gpio-controller node in pinconfig_post_bind()

[Patrice Chotard]

From: Patrick Delaunay 

Some binding define child node gpio-controller without compatible property.
This patch avoid to bind the pinconfig uclass to these node.

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
---

 drivers/pinctrl/pinctrl-uclass.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index abb622cfe79e..9df06a262cd5 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -149,6 +149,9 @@ static int pinconfig_post_bind(struct udevice *dev)
ofnode_get_property(node, "compatible", );
if (ret >= 0)
continue;
+   /* If this node has "gpio-controller" property, skip */
+   if (ofnode_read_bool(node, "gpio-controller"))
+   continue;
 
if (ret != -FDT_ERR_NOTFOUND)
return ret;
-- 
1.9.1

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

[U-Boot] [PATCH v1 1/2] dm: pinctrl: Avoid race condition on probe for UCLASS_PINCTRL

[Patrice Chotard]

In case of system with several pin-controller device, probe the first
UCLASS_PINCTRL by seq number (defined by alias) to avoid race condition
with I2C PINCONTROL driver for GPIO expander (GPIO expander need I2C bus,
I2C driver need PINCONFIG).

Signed-off-by: Patrick DELAUNAY 
Signed-off-by: Patrice Chotard 
---

 drivers/pinctrl/pinctrl-uclass.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index 0e3260afd1ee..abb622cfe79e 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -201,11 +201,14 @@ static int pinctrl_select_state_simple(struct udevice 
*dev)
int ret;
 
/*
-* For simplicity, assume the first device of PINCTRL uclass
-* is the correct one.  This is most likely OK as there is
-* usually only one pinctrl device on the system.
+* For most system, there is only one pincontroller device. But in
+* case of multiple pincontroller devices, probe the one with sequence
+* number 0 (defined by alias) to avoid race condition.
 */
-   ret = uclass_get_device(UCLASS_PINCTRL, 0, );
+   ret = uclass_get_device_by_seq(UCLASS_PINCTRL, 0, );
+   if (ret)
+   /* if not found, get the first one */
+   ret = uclass_get_device(UCLASS_PINCTRL, 0, );
if (ret)
return ret;
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 1/3] sunxi: Sync Bananapi M2+ device tree from Linux v5.0-rc1

[Chen-Yu Tsai]

On Fri, Feb 15, 2019 at 9:58 PM Jagan Teki  wrote:
>
> On Fri, Feb 15, 2019 at 4:33 PM Chen-Yu Tsai  wrote:
> >
> > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> > device tree for the Bananapi M2+ has been split into a common dtsi file,
> > and an SoC-specific board device tree file that includes both the shared
> > dtsi file and the soc dtsi file. This was done to support both the H3
> > and H5 variants of the same board. This is similar to what was done for
> > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af ("sunxi: Split
> > out common board design for ALL-H3-CC device tree").
> >
> > The newly split files are directly synced from Linux tag v5.0-rc1.
>
> Based on my previous patch comment, I expected to have full sync with
> all H3 related files. any plan?

I thought the plan was to merge these first, then do a full sync for the
next merge window?

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

Re: [U-Boot] [PATCH v2 1/3] sunxi: Sync Bananapi M2+ device tree from Linux v5.0-rc1

[Jagan Teki]

On Fri, Feb 15, 2019 at 4:33 PM Chen-Yu Tsai  wrote:
>
> As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> device tree for the Bananapi M2+ has been split into a common dtsi file,
> and an SoC-specific board device tree file that includes both the shared
> dtsi file and the soc dtsi file. This was done to support both the H3
> and H5 variants of the same board. This is similar to what was done for
> the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af ("sunxi: Split
> out common board design for ALL-H3-CC device tree").
>
> The newly split files are directly synced from Linux tag v5.0-rc1.

Based on my previous patch comment, I expected to have full sync with
all H3 related files. any plan?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] arm: mvebu: Add DB-XC3-24G4XG board

[Chris Packham]

On Fri, 15 Feb 2019, 11:17 PM Stefan Roese  Hi Chris,
>
> please find a few comments / questions below.
>
> On 15.02.19 10:41, Chris Packham wrote:
> > From: Chris Packham 
> >
> > The DB-XC3-24G4XG is a switch development board from Marvell. It can
> > either use and external CPU card such as the db-88f6820-amc or the
> > internal CPU that is integrated into the switch.
> >
> > Add support for running U-Boot on the internal CPU and enable the USB,
> > SPI and NAND peripherals. For now this needs the bin_hdr from the
> > Marvell U-Boot for this board.
> >
> > Signed-off-by: Chris Packham 
> > ---
> >
> >   arch/arm/dts/Makefile   |   3 +-
> >   arch/arm/dts/armada-xp-98dx3236.dtsi| 343 
> >   arch/arm/dts/armada-xp-98dx3336.dtsi|  39 +++
> >   arch/arm/dts/armada-xp-98dx4251.dtsi|  54 +++
> >   arch/arm/dts/armada-xp-db-xc3-24g4xg.dts| 122 +++
> >   arch/arm/mach-mvebu/Kconfig |   8 +
> >   board/Marvell/db-xc3-24g4xg/MAINTAINERS |   7 +
> >   board/Marvell/db-xc3-24g4xg/Makefile|   5 +
> >   board/Marvell/db-xc3-24g4xg/README  |   4 +
> >   board/Marvell/db-xc3-24g4xg/binary.0|  11 +
> >   board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c |  71 
> >   board/Marvell/db-xc3-24g4xg/kwbimage.cfg|  12 +
> >   configs/db-xc3-24g4xg_defconfig |  55 
> >   include/configs/db-xc3-24g4xg.h |  45 +++
> >   tools/Makefile  |   4 +
> >   tools/kwbimage.c|   4 +
>
> Could you please split the kwbimage tool changes into a separate
> patch?
>

Yes will do.


> >   16 files changed, 786 insertions(+), 1 deletion(-)
> >   create mode 100644 arch/arm/dts/armada-xp-98dx3236.dtsi
> >   create mode 100644 arch/arm/dts/armada-xp-98dx3336.dtsi
> >   create mode 100644 arch/arm/dts/armada-xp-98dx4251.dtsi
> >   create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts
> >   create mode 100644 board/Marvell/db-xc3-24g4xg/MAINTAINERS
> >   create mode 100644 board/Marvell/db-xc3-24g4xg/Makefile
> >   create mode 100644 board/Marvell/db-xc3-24g4xg/README
> >   create mode 100644 board/Marvell/db-xc3-24g4xg/binary.0
> >   create mode 100644 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c
> >   create mode 100644 board/Marvell/db-xc3-24g4xg/kwbimage.cfg
> >   create mode 100644 configs/db-xc3-24g4xg_defconfig
> >   create mode 100644 include/configs/db-xc3-24g4xg.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index ca5062348087..133f09d8ba63 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -113,7 +113,8 @@ dtb-$(CONFIG_ARCH_MVEBU) +=   \
> >   armada-xp-theadorable.dtb   \
> >   armada-38x-controlcenterdc.dtb  \
> >   armada-385-atl-x530.dtb \
> > - armada-385-atl-x530DP.dtb
> > + armada-385-atl-x530DP.dtb   \
> > + armada-xp-db-xc3-24g4xg.dtb
> >
> >   dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \
> >   uniphier-ld11-global.dtb \
> > diff --git a/arch/arm/dts/armada-xp-98dx3236.dtsi
> b/arch/arm/dts/armada-xp-98dx3236.dtsi
> > new file mode 100644
> > index ..5df1d1848dbc
> > --- /dev/null
> > +++ b/arch/arm/dts/armada-xp-98dx3236.dtsi
> > @@ -0,0 +1,343 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Device Tree Include file for Marvell 98dx3236 family SoC
> > + *
> > + * Copyright (C) 2016 Allied Telesis Labs
> > + *
> > + * Contains definitions specific to the 98dx3236 SoC that are not
> > + * common to all Armada XP SoCs.
> > + */
> > +
> > +#include "armada-370-xp.dtsi"
> > +
> > +/ {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + model = "Marvell 98DX3236 SoC";
> > + compatible = "marvell,armadaxp-98dx3236", "marvell,armada-370-xp";
> > +
> > + aliases {
> > + gpio0 = 
> > + gpio1 = 
> > + gpio2 = 
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + enable-method = "marvell,98dx3236-smp";
> > +
> > + cpu@0 {
> > + device_type = "cpu";
> > + compatible = "marvell,sheeva-v7";
> > + reg = <0>;
> > + clocks = < 0>;
> > + clock-latency = <100>;
> > + };
> > + };
> > +
> > + soc {
> > + compatible = "marvell,armadaxp-mbus", "simple-bus";
> > +
> > + ranges =  > +   MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> > +   MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
> > +   MBUS_ID(0x03, 0x00) 0 0 0xa800 0x400
> > +   MBUS_ID(0x08, 0x00) 0 0 0xac00 0x10>;
> > +
> > + bootrom {
> > + compatible = "marvell,bootrom";
> > +  

Re: [U-Boot] [PATCH 6/6] doc: imx: habv4: Remove secure_boot.txt guide

[Stefano Babic]

On 15/02/19 13:45, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Fri, Feb 15, 2019 at 9:57 AM Stefano Babic  wrote:
> 
>>> diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
>>> deleted file mode 100644
>>> index ae68dc8040..00
>>>
>>
>> I have applied to my working branch, but I cannot find this on
>> patchwork. The rest of the series is present, this not, weird..
> 
> Looks like a patchwork bug.
> We have seen some issues with patches not getting detected by
> patchwork when they are only file renames or file delete operations
> (like in this case).

Right - anyway, patch just drops a file, I did myself on my branch
adding Breno's commit message.

Regards,
Stefano

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

[U-Boot] [PATCH] MAINTAINERS: Update u-boot-marvell entry

[Stefan Roese]

This patch does the following changes to the u-boot-marvell maintainers
entry:

- Add Armada-7k/8k to the list
- Remove Prafulla and Luka since they have been silent on the list for
  a long time. Please speak up, if you would like to continue or better
  start maintaining.
- Add multiple Marvell / MVEBU related driver directories and files

Signed-off-by: Stefan Roese 
Cc: Prafulla Wadaskar 
Cc: Luka Perkov 
Cc: Tom Rini 
---
 MAINTAINERS | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 29449ffed6..7fa3e059f6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -166,16 +166,19 @@ S:Maintained
 F: arch/arm/cpu/armv8/hisilicon
 F: arch/arm/include/asm/arch-hi6220/
 
-ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX
-M: Prafulla Wadaskar 
-M: Luka Perkov 
+ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K
 M: Stefan Roese 
 S: Maintained
 T: git git://git.denx.de/u-boot-marvell.git
 F: arch/arm/mach-kirkwood/
 F: arch/arm/mach-mvebu/
 F: drivers/ata/ahci_mvebu.c
-F: drivers/phy/marvell/
+F: drivers/ddr/marvell/
+F: drivers/gpio/mvebu_gpio.c
+F: drivers/spi/kirkwood_spi.c
+F: drivers/pci/pci_mvebu.c
+F: drivers/pci/pcie_dw_mvebu.c
+F: drivers/watchdog/orion_wdt.c
 
 ARM MARVELL PXA
 M: Marek Vasut 
-- 
2.20.1

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

Re: [U-Boot] [PATCH 6/6] doc: imx: habv4: Remove secure_boot.txt guide

[Fabio Estevam]

Hi Stefano,

On Fri, Feb 15, 2019 at 9:57 AM Stefano Babic  wrote:

> > diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
> > deleted file mode 100644
> > index ae68dc8040..00
> >
>
> I have applied to my working branch, but I cannot find this on
> patchwork. The rest of the series is present, this not, weird..

Looks like a patchwork bug.
We have seen some issues with patches not getting detected by
patchwork when they are only file renames or file delete operations
(like in this case).

Regards,

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

Re: [U-Boot] [PATCH 6/6] doc: imx: habv4: Remove secure_boot.txt guide

[Breno Matheus Lima]

Hi Stefano,

Em sex, 15 de fev de 2019 às 09:57, Stefano Babic  escreveu:
>
> On 23/01/19 20:30, Breno Matheus Lima wrote:
> > The secure_boot.txt guide was replaced by mx6_mx7_secure_boot.txt and
> > mx6_mx7_spl_secure_boot.txt documents.
> >
> > Both documents covers all steps needed for SPL and non-SPL tagets,
> > so remove secure_boot.txt file to avoid duplicated content.
> >
> > Signed-off-by: Breno Lima 
> > ---
> >  doc/imx/habv4/secure_boot.txt | 100 --
> >  1 file changed, 100 deletions(-)
> >  delete mode 100644 doc/imx/habv4/secure_boot.txt
> >
> > diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
> > deleted file mode 100644
> > index ae68dc8040..00
> >
>
> I have applied to my working branch, but I cannot find this on
> patchwork. The rest of the series is present, this not, weird..

Thanks for looking this series.

Interesting, I'm also not being able to find it in patchwork.

Anyway, I have just sent again :)

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

Re: [U-Boot] [PATCH 2/4] arm: mvebu: Add Marvell's integrated CPUs

[Stefan Roese]

Hi Chis,

On 15.02.19 12:57, Chris Packham wrote:



On Fri, 15 Feb 2019, 11:06 PM Stefan Roese mailto:s...@denx.de> 
wrote:

Hi Chris,

On 15.02.19 10:41, Chris Packham wrote:
 > Marvell's switch chips with integrated CPUs (collectively referred to as
 > MSYS) share common ancestry with the Armada SoCs. Some of the IP blocks
 > (e.g. xor) are located at different addresses and DFX server exists as a
 > separate target on the MBUS (on Armada-38x it's just part of the core
 > complex registers).
 >
 > Signed-off-by: Chris Packham mailto:judge.pack...@gmail.com>>
 > ---
 >
 >   arch/arm/mach-mvebu/Kconfig               | 18 -
 >   arch/arm/mach-mvebu/Makefile              |  1 +
 >   arch/arm/mach-mvebu/cpu.c                 | 32 +--
 >   arch/arm/mach-mvebu/include/mach/config.h |  2 +-
 >   arch/arm/mach-mvebu/include/mach/cpu.h    |  3 +++
 >   arch/arm/mach-mvebu/include/mach/soc.h    | 20 ++
 >   drivers/ddr/marvell/axp/xor_regs.h        |  4 +++
 >   7 files changed, 76 insertions(+), 4 deletions(-)
 >
 > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
 > index 7dda04e0e34e..05aa2ade0499 100644
 > --- a/arch/arm/mach-mvebu/Kconfig
 > +++ b/arch/arm/mach-mvebu/Kconfig
 > @@ -46,7 +46,7 @@ config ARMADA_8K
 >   # Armada PLL frequency (used for NAND clock generation)
 >   config SYS_MVEBU_PLL_CLOCK
 >       int
 > -     default "20" if ARMADA_XP || ARMADA_3700 || ARMADA_8K
 > +     default "20" if ARMADA_XP || ARMADA_3700 || ARMADA_8K || 
MSYS

I personally find this "MSYS" abbreviation quite short and not
descriptive. How is this handled (if at all yet) in Linux?


I did briefly consider ARMADA_MSYS. But settled on MSYS because that's
how Marvell tend to refer to it. Marvells code uses MSYS, XCAT3, AC3
and BC2 depending on how specific they need to be (e.g. the ddr code
needs to distinguish AC3 and BC2).


I see. But now CONFIG_MSYS is mostly used vs CONFIG_ARMADA_38X etc.
I personally find this now clear and would prefer CONFIG_ARMADA_MSYS
over CONFIG_MSYS. You can always define CONFIG_MSYS in some DDR code
header, once this should be integrated.
 

In Linux I originally proposed MSYS but eventually we went with
MV98DX3326 as the base and used the other chip names where needed.
But that mostly works out because the arch code is generic so the
things that use these names are mostly compat strings.


I see. Isn't there any CONFIG_MACH_foo set for this SoC type (like
CONFIG_MACH_ARMADA_38X) in Linux? Or is CONFIG_MACH_ARMADA_XP selected
for this SoC as well?

Still, if we need to make this distinction in U-Boot (compared to the
more generic arch code in Linux), I would prefer CONFIG_ARMADA_MSYS
compared to CONFIG_MSYS or CONFIG_MV98DX3326.

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

[U-Boot] [PATCH RESEND 6/6] doc: imx: habv4: Remove secure_boot.txt guide

[Breno Matheus Lima]

The secure_boot.txt guide was replaced by mx6_mx7_secure_boot.txt and
mx6_mx7_spl_secure_boot.txt documents.

Both documents covers all steps needed for SPL and non-SPL tagets,
so remove secure_boot.txt file to avoid duplicated content.

Signed-off-by: Breno Lima 
---
 doc/imx/habv4/secure_boot.txt | 100 --
 1 file changed, 100 deletions(-)
 delete mode 100644 doc/imx/habv4/secure_boot.txt

diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
deleted file mode 100644
index ae68dc8040..00
-- 
2.17.1

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

Re: [U-Boot] [PATCH v1 2/3] imx: serial_mxc: disable ri and dcd irq in dte mode

[Stefano Babic]

Hi Marcel,

On 01/02/19 16:04, Marcel Ziswiler wrote:
> From: Max Krummenacher 
> 
> If the UART is used in DTE mode the RI and DCD bits in UCR3 become
> irq enable bits. Both are set to enabled after reset and both likely
> are pending.
> 
> Disable the bits to prevent an interrupt storm when Linux enables
> the UART interrupts.
> 
> Signed-off-by: Max Krummenacher 
> Signed-off-by: Marcel Ziswiler 
> 
> ---
> 

I never seen this issue, but you fix looks plausible - I applied this to
my working branch and queued for next PR.

Regards,
Stefano

>  drivers/serial/serial_mxc.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> index 7e4e6d36b8..df35ac9114 100644
> --- a/drivers/serial/serial_mxc.c
> +++ b/drivers/serial/serial_mxc.c
> @@ -138,13 +138,18 @@ struct mxc_uart {
>   u32 ts;
>  };
>  
> -static void _mxc_serial_init(struct mxc_uart *base)
> +static void _mxc_serial_init(struct mxc_uart *base, int use_dte)
>  {
>   writel(0, >cr1);
>   writel(0, >cr2);
>  
>   while (!(readl(>cr2) & UCR2_SRST));
>  
> + if (use_dte)
> + writel(0x404 | UCR3_ADNIMP, >cr3);
> + else
> + writel(0x704 | UCR3_ADNIMP, >cr3);
> +
>   writel(0x704 | UCR3_ADNIMP, >cr3);
>   writel(0x8000, >cr4);
>   writel(0x2b, >esc);
> @@ -226,7 +231,7 @@ static int mxc_serial_tstc(void)
>   */
>  static int mxc_serial_init(void)
>  {
> - _mxc_serial_init(mxc_base);
> + _mxc_serial_init(mxc_base, false);
>  
>   serial_setbrg();
>  
> @@ -271,7 +276,7 @@ static int mxc_serial_probe(struct udevice *dev)
>  {
>   struct mxc_serial_platdata *plat = dev->platdata;
>  
> - _mxc_serial_init(plat->reg);
> + _mxc_serial_init(plat->reg, plat->use_dte);
>  
>   return 0;
>  }
> @@ -367,7 +372,7 @@ static inline void _debug_uart_init(void)
>  {
>   struct mxc_uart *base = (struct mxc_uart *)CONFIG_DEBUG_UART_BASE;
>  
> - _mxc_serial_init(base);
> + _mxc_serial_init(base, false);
>   _mxc_serial_setbrg(base, CONFIG_DEBUG_UART_CLOCK,
>  CONFIG_BAUDRATE, false);
>  }
> 


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

Re: [U-Boot] [PATCH 5/7] arm: mach-k3: Add secure device build support

[Lokesh Vutla]

On 2/15/2019 4:25 AM, Andrew F. Davis wrote:
> On 2/13/19 9:46 PM, Lokesh Vutla wrote:
>>
>>
>> On 14/02/19 12:07 AM, Andrew F. Davis wrote:
>>> K3 HS devices require signed binaries for boot, use the SECDEV tools
>>> to sign the boot artifacts during build.
>>>
>>> Signed-off-by: Andrew F. Davis 
>>> ---
>>>  MAINTAINERS   |  1 +
>>>  arch/arm/mach-k3/config.mk| 25 ++
>>>  arch/arm/mach-k3/config_secure.mk | 44 +++
>>>  tools/k3_fit_atf.sh   |  8 --
>>>  4 files changed, 76 insertions(+), 2 deletions(-)
>>>  create mode 100644 arch/arm/mach-k3/config_secure.mk
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 18cdca9447..ac6bd8cfca 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -717,6 +717,7 @@ F:  arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
>>>  F: arch/arm/mach-omap2/sec-common.c
>>>  F: arch/arm/mach-omap2/config_secure.mk
>>>  F: arch/arm/mach-k3/security.c
>>> +F: arch/arm/mach-k3/config_secure.mk
>>>  F: configs/am335x_hs_evm_defconfig
>>>  F: configs/am335x_hs_evm_uart_defconfig
>>>  F: configs/am43xx_hs_evm_defconfig
>>> diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
>>> index be00d79fb0..2d8f61f9db 100644
>>> --- a/arch/arm/mach-k3/config.mk
>>> +++ b/arch/arm/mach-k3/config.mk
>>> @@ -36,6 +36,14 @@ cmd_gencert = cat $(srctree)/tools/k3_x509template.txt | 
>>> sed $(SED_OPTS) > u-boo
>>>  # If external key is not provided, generate key using openssl.
>>>  ifeq ($(CONFIG_SYS_K3_KEY), "")
>>>  KEY=u-boot-spl-eckey.pem
>>> +# On HS use real key or warn if not available
>>> +ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
>>> +ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),)
>>> +KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem
>>> +else
>>> +$(warning "WARNING: signing key not found. Random key will NOT work on HS 
>>> hardware!")
>>> +endif
>>> +endif
>>>  else
>>>  KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
>>>  endif
>>> @@ -65,6 +73,15 @@ ALL-y+= tiboot3.bin
>>>  endif
>>>  
>>>  ifdef CONFIG_ARM64
>>> +ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
>>> +SPL_ITS := u-boot-spl-k3_HS.its
>>> +$(SPL_ITS): FORCE
>>> +   IS_HS=1 \
>>> +   $(srctree)/tools/k3_fit_atf.sh \
>>> +   $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@
>>> +
>>> +ALL-y  += tispl.bin_HS
>>> +else
>>>  SPL_ITS := u-boot-spl-k3.its
>>>  $(SPL_ITS): FORCE
>>> $(srctree)/tools/k3_fit_atf.sh \
>>> @@ -72,7 +89,15 @@ $(SPL_ITS): FORCE
>>>  
>>>  ALL-y  += tispl.bin
>>>  endif
>>> +endif
>>> +
>>> +else
>>>  
>>> +ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
>>> +ALL-y  += u-boot.img_HS
>>>  else
>>>  ALL-y  += u-boot.img
>>>  endif
>>> +endif
>>> +
>>> +include $(srctree)/arch/arm/mach-k3/config_secure.mk
>>> diff --git a/arch/arm/mach-k3/config_secure.mk 
>>> b/arch/arm/mach-k3/config_secure.mk
>>> new file mode 100644
>>> index 00..6d63c57665
>>> --- /dev/null
>>> +++ b/arch/arm/mach-k3/config_secure.mk
>>> @@ -0,0 +1,44 @@
>>> +# SPDX-License-Identifier: GPL-2.0
>>> +#
>>> +# Copyright (C) 2018 Texas Instruments, Incorporated - http://www.ti.com/
>>> +#  Andrew F. Davis 
>>> +
>>> +quiet_cmd_k3secureimg = SECURE  $@
>>> +ifneq ($(TI_SECURE_DEV_PKG),)
>>> +ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),)
>>> +cmd_k3secureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \
>>> +   $< $@ \
>>> +   $(if $(KBUILD_VERBOSE:1=), >/dev/null)
>>> +else
>>> +cmd_k3secureimg = echo "WARNING:" \
>>> +   "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \
>>> +   "$@ was NOT secured!"; cp $< $@
>>> +endif
>>> +else
>>> +cmd_k3secureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \
>>> +   "variable must be defined for TI secure devices." \
>>> +   "$@ was NOT secured!"; cp $< $@
>>> +endif
>>> +
>>> +%.dtb_HS: %.dtb FORCE
>>> +   $(call if_changed,k3secureimg)
>>> +
>>> +$(obj)/u-boot-spl-nodtb.bin_HS: $(obj)/u-boot-spl-nodtb.bin FORCE
>>> +   $(call if_changed,k3secureimg)
>>> +
>>> +tispl.bin_HS: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst 
>>> %,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST))) $(SPL_ITS) FORCE
>>> +   $(call if_changed,mkfitimage)
>>> +
>>> +MKIMAGEFLAGS_u-boot.img_HS = -f auto -A $(ARCH) -T firmware -C none -O 
>>> u-boot \
>>> +   -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
>>> +   -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
>>> +   $(patsubst %,-b arch/$(ARCH)/dts/%.dtb_HS,$(subst ",,$(CONFIG_OF_LIST)))
>>
>> I guess these HS postfixed dtbs will never get cleaned. I see the same issue
>> with other TI secure devices as well. Can you update the clean rules as well?
>>
> 
> tiboot3.bin and tispl.bin also don't seem to be getting cleaned. I tried

Yeah, these should be cleaned as well.

> adding them to clean-files and CLEAN_FILES, neither worked. Outside of

looks like clean-files is relative to the current directory. You can
update arch/arm/dts/Makefile but it might be very 

[U-Boot] [PATCH 4/4] arm: mvebu: Add DB-XC3-24G4XG board

[Chris Packham]

From: Chris Packham 

The DB-XC3-24G4XG is a switch development board from Marvell. It can
either use and external CPU card such as the db-88f6820-amc or the
internal CPU that is integrated into the switch.

Add support for running U-Boot on the internal CPU and enable the USB,
SPI and NAND peripherals. For now this needs the bin_hdr from the
Marvell U-Boot for this board.

Signed-off-by: Chris Packham 
---

 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/armada-xp-98dx3236.dtsi| 343 
 arch/arm/dts/armada-xp-98dx3336.dtsi|  39 +++
 arch/arm/dts/armada-xp-98dx4251.dtsi|  54 +++
 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts| 122 +++
 arch/arm/mach-mvebu/Kconfig |   8 +
 board/Marvell/db-xc3-24g4xg/MAINTAINERS |   7 +
 board/Marvell/db-xc3-24g4xg/Makefile|   5 +
 board/Marvell/db-xc3-24g4xg/README  |   4 +
 board/Marvell/db-xc3-24g4xg/binary.0|  11 +
 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c |  71 
 board/Marvell/db-xc3-24g4xg/kwbimage.cfg|  12 +
 configs/db-xc3-24g4xg_defconfig |  55 
 include/configs/db-xc3-24g4xg.h |  45 +++
 tools/Makefile  |   4 +
 tools/kwbimage.c|   4 +
 16 files changed, 786 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/armada-xp-98dx3236.dtsi
 create mode 100644 arch/arm/dts/armada-xp-98dx3336.dtsi
 create mode 100644 arch/arm/dts/armada-xp-98dx4251.dtsi
 create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts
 create mode 100644 board/Marvell/db-xc3-24g4xg/MAINTAINERS
 create mode 100644 board/Marvell/db-xc3-24g4xg/Makefile
 create mode 100644 board/Marvell/db-xc3-24g4xg/README
 create mode 100644 board/Marvell/db-xc3-24g4xg/binary.0
 create mode 100644 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c
 create mode 100644 board/Marvell/db-xc3-24g4xg/kwbimage.cfg
 create mode 100644 configs/db-xc3-24g4xg_defconfig
 create mode 100644 include/configs/db-xc3-24g4xg.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ca5062348087..133f09d8ba63 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -113,7 +113,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-xp-theadorable.dtb   \
armada-38x-controlcenterdc.dtb  \
armada-385-atl-x530.dtb \
-   armada-385-atl-x530DP.dtb
+   armada-385-atl-x530DP.dtb   \
+   armada-xp-db-xc3-24g4xg.dtb
 
 dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \
uniphier-ld11-global.dtb \
diff --git a/arch/arm/dts/armada-xp-98dx3236.dtsi 
b/arch/arm/dts/armada-xp-98dx3236.dtsi
new file mode 100644
index ..5df1d1848dbc
--- /dev/null
+++ b/arch/arm/dts/armada-xp-98dx3236.dtsi
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree Include file for Marvell 98dx3236 family SoC
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Contains definitions specific to the 98dx3236 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+#include "armada-370-xp.dtsi"
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   model = "Marvell 98DX3236 SoC";
+   compatible = "marvell,armadaxp-98dx3236", "marvell,armada-370-xp";
+
+   aliases {
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "marvell,98dx3236-smp";
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "marvell,sheeva-v7";
+   reg = <0>;
+   clocks = < 0>;
+   clock-latency = <100>;
+   };
+   };
+
+   soc {
+   compatible = "marvell,armadaxp-mbus", "simple-bus";
+
+   ranges = ;
+
+   bootrom {
+   compatible = "marvell,bootrom";
+   reg = ;
+   };
+
+   /*
+* 98DX3236 has 1 x1 PCIe unit Gen2.0
+*/
+   pciec: pcie@8200 {
+   compatible = "marvell,armada-xp-pcie";
+   status = "disabled";
+   device_type = "pci";
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   msi-parent = <>;
+   bus-range = <0x00 0xff>;
+
+   ranges =
+  <0x8200 0 0x4 MBUS_ID(0xf0, 0x01) 
0x4 0 0x2000   /* Port 0.0 registers */
+   0x8200 0x1 0   MBUS_ID(0x04, 0xe8) 0 1 
0 /* Port 0.0 MEM */
+   0x8100 0x1 0   MBUS_ID(0x04, 0xe0) 0 1 
0 /* Port 0.0 IO  */>;
+
+   pcie1: pcie@1,0 {
+ 

[U-Boot] [PATCH 0/4] Marvell DB-XC3-24G4XG board support

[Chris Packham]

This series adds support for Marvell's Switches with integrated CPUs and
the DB-XC3-24G4XG board. The CPU side is similar to the Armada range.

For now the DDR training code needs to come from the Marvell bin_hdr.
It's one area where the integrated SoCs differ from the Armada range so
neither the Armada-XP nor Armada-38x training code will work as-is. I'm
asking Marvell about the possibility of re-licensing the code under a
Proprietary/BSD/GPL as they did with Armada-38x.

I also have access to a DB-DXBC2-MM board with a different chip. I'll
look at adding support for that as well at some point. It's harder to
work with because it has no USB, but other than that it's similar to the
DB-XC3.

Chris Packham (4):
  arm: sync armada-xp dts files from Linux 5.0
  arm: mvebu: Add Marvell's integrated CPUs
  arm: mvebu: NAND clock support for MSYS devices
  arm: mvebu: Add DB-XC3-24G4XG board

 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/armada-370-xp.dtsi | 133 
 arch/arm/dts/armada-xp-98dx3236.dtsi| 343 
 arch/arm/dts/armada-xp-98dx3336.dtsi|  39 +++
 arch/arm/dts/armada-xp-98dx4251.dtsi|  54 +++
 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts| 122 +++
 arch/arm/dts/armada-xp-gp.dts   | 167 --
 arch/arm/dts/armada-xp-maxbcm.dts   |  24 +-
 arch/arm/dts/armada-xp-mv78230.dtsi |  55 +---
 arch/arm/dts/armada-xp-mv78260.dtsi |  58 +---
 arch/arm/dts/armada-xp-mv78460.dtsi |  58 +---
 arch/arm/dts/armada-xp-synology-ds414.dts   | 199 ++--
 arch/arm/dts/armada-xp-theadorable.dts  |  69 ++--
 arch/arm/dts/armada-xp.dtsi | 214 ++--
 arch/arm/mach-mvebu/Kconfig |  26 +-
 arch/arm/mach-mvebu/Makefile|   1 +
 arch/arm/mach-mvebu/cpu.c   |  34 +-
 arch/arm/mach-mvebu/include/mach/config.h   |   2 +-
 arch/arm/mach-mvebu/include/mach/cpu.h  |   3 +
 arch/arm/mach-mvebu/include/mach/soc.h  |  31 ++
 board/Marvell/db-xc3-24g4xg/MAINTAINERS |   7 +
 board/Marvell/db-xc3-24g4xg/Makefile|   5 +
 board/Marvell/db-xc3-24g4xg/README  |   4 +
 board/Marvell/db-xc3-24g4xg/binary.0|  11 +
 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c |  71 
 board/Marvell/db-xc3-24g4xg/kwbimage.cfg|  12 +
 configs/db-xc3-24g4xg_defconfig |  55 
 drivers/ddr/marvell/axp/xor_regs.h  |   4 +
 include/configs/db-xc3-24g4xg.h |  45 +++
 tools/Makefile  |   4 +
 tools/kwbimage.c|   4 +
 31 files changed, 1310 insertions(+), 547 deletions(-)
 create mode 100644 arch/arm/dts/armada-xp-98dx3236.dtsi
 create mode 100644 arch/arm/dts/armada-xp-98dx3336.dtsi
 create mode 100644 arch/arm/dts/armada-xp-98dx4251.dtsi
 create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts
 create mode 100644 board/Marvell/db-xc3-24g4xg/MAINTAINERS
 create mode 100644 board/Marvell/db-xc3-24g4xg/Makefile
 create mode 100644 board/Marvell/db-xc3-24g4xg/README
 create mode 100644 board/Marvell/db-xc3-24g4xg/binary.0
 create mode 100644 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c
 create mode 100644 board/Marvell/db-xc3-24g4xg/kwbimage.cfg
 create mode 100644 configs/db-xc3-24g4xg_defconfig
 create mode 100644 include/configs/db-xc3-24g4xg.h

-- 
2.20.1

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

Re: [U-Boot] [PATCH 4/4] arm: mvebu: Add DB-XC3-24G4XG board

[Stefan Roese]

Hi Chris,

please find a few comments / questions below.

On 15.02.19 10:41, Chris Packham wrote:

From: Chris Packham 

The DB-XC3-24G4XG is a switch development board from Marvell. It can
either use and external CPU card such as the db-88f6820-amc or the
internal CPU that is integrated into the switch.

Add support for running U-Boot on the internal CPU and enable the USB,
SPI and NAND peripherals. For now this needs the bin_hdr from the
Marvell U-Boot for this board.

Signed-off-by: Chris Packham 
---

  arch/arm/dts/Makefile   |   3 +-
  arch/arm/dts/armada-xp-98dx3236.dtsi| 343 
  arch/arm/dts/armada-xp-98dx3336.dtsi|  39 +++
  arch/arm/dts/armada-xp-98dx4251.dtsi|  54 +++
  arch/arm/dts/armada-xp-db-xc3-24g4xg.dts| 122 +++
  arch/arm/mach-mvebu/Kconfig |   8 +
  board/Marvell/db-xc3-24g4xg/MAINTAINERS |   7 +
  board/Marvell/db-xc3-24g4xg/Makefile|   5 +
  board/Marvell/db-xc3-24g4xg/README  |   4 +
  board/Marvell/db-xc3-24g4xg/binary.0|  11 +
  board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c |  71 
  board/Marvell/db-xc3-24g4xg/kwbimage.cfg|  12 +
  configs/db-xc3-24g4xg_defconfig |  55 
  include/configs/db-xc3-24g4xg.h |  45 +++
  tools/Makefile  |   4 +
  tools/kwbimage.c|   4 +


Could you please split the kwbimage tool changes into a separate
patch?


  16 files changed, 786 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/armada-xp-98dx3236.dtsi
  create mode 100644 arch/arm/dts/armada-xp-98dx3336.dtsi
  create mode 100644 arch/arm/dts/armada-xp-98dx4251.dtsi
  create mode 100644 arch/arm/dts/armada-xp-db-xc3-24g4xg.dts
  create mode 100644 board/Marvell/db-xc3-24g4xg/MAINTAINERS
  create mode 100644 board/Marvell/db-xc3-24g4xg/Makefile
  create mode 100644 board/Marvell/db-xc3-24g4xg/README
  create mode 100644 board/Marvell/db-xc3-24g4xg/binary.0
  create mode 100644 board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c
  create mode 100644 board/Marvell/db-xc3-24g4xg/kwbimage.cfg
  create mode 100644 configs/db-xc3-24g4xg_defconfig
  create mode 100644 include/configs/db-xc3-24g4xg.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ca5062348087..133f09d8ba63 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -113,7 +113,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-xp-theadorable.dtb   \
armada-38x-controlcenterdc.dtb  \
armada-385-atl-x530.dtb \
-   armada-385-atl-x530DP.dtb
+   armada-385-atl-x530DP.dtb   \
+   armada-xp-db-xc3-24g4xg.dtb
  
  dtb-$(CONFIG_ARCH_UNIPHIER_LD11) += \

uniphier-ld11-global.dtb \
diff --git a/arch/arm/dts/armada-xp-98dx3236.dtsi 
b/arch/arm/dts/armada-xp-98dx3236.dtsi
new file mode 100644
index ..5df1d1848dbc
--- /dev/null
+++ b/arch/arm/dts/armada-xp-98dx3236.dtsi
@@ -0,0 +1,343 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree Include file for Marvell 98dx3236 family SoC
+ *
+ * Copyright (C) 2016 Allied Telesis Labs
+ *
+ * Contains definitions specific to the 98dx3236 SoC that are not
+ * common to all Armada XP SoCs.
+ */
+
+#include "armada-370-xp.dtsi"
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   model = "Marvell 98DX3236 SoC";
+   compatible = "marvell,armadaxp-98dx3236", "marvell,armada-370-xp";
+
+   aliases {
+   gpio0 = 
+   gpio1 = 
+   gpio2 = 
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "marvell,98dx3236-smp";
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "marvell,sheeva-v7";
+   reg = <0>;
+   clocks = < 0>;
+   clock-latency = <100>;
+   };
+   };
+
+   soc {
+   compatible = "marvell,armadaxp-mbus", "simple-bus";
+
+   ranges = ;
+
+   bootrom {
+   compatible = "marvell,bootrom";
+   reg = ;
+   };
+
+   /*
+* 98DX3236 has 1 x1 PCIe unit Gen2.0
+*/
+   pciec: pcie@8200 {
+   compatible = "marvell,armada-xp-pcie";
+   status = "disabled";
+   device_type = "pci";
+
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   msi-parent = <>;
+   bus-range = <0x00 0xff>;
+
+   ranges =
+  <0x8200 0 0x4 MBUS_ID(0xf0, 0x01) 
0x4 0 0x2000   /* Port 0.0 registers */
+   0x8200 0x1 0   MBUS_ID(0x04, 

Re: [U-Boot] [PATCH 2/4] arm: mvebu: Add Marvell's integrated CPUs

[Chris Packham]

On Fri, 15 Feb 2019, 11:06 PM Stefan Roese  Hi Chris,
>
> On 15.02.19 10:41, Chris Packham wrote:
> > Marvell's switch chips with integrated CPUs (collectively referred to as
> > MSYS) share common ancestry with the Armada SoCs. Some of the IP blocks
> > (e.g. xor) are located at different addresses and DFX server exists as a
> > separate target on the MBUS (on Armada-38x it's just part of the core
> > complex registers).
> >
> > Signed-off-by: Chris Packham 
> > ---
> >
> >   arch/arm/mach-mvebu/Kconfig   | 18 -
> >   arch/arm/mach-mvebu/Makefile  |  1 +
> >   arch/arm/mach-mvebu/cpu.c | 32 +--
> >   arch/arm/mach-mvebu/include/mach/config.h |  2 +-
> >   arch/arm/mach-mvebu/include/mach/cpu.h|  3 +++
> >   arch/arm/mach-mvebu/include/mach/soc.h| 20 ++
> >   drivers/ddr/marvell/axp/xor_regs.h|  4 +++
> >   7 files changed, 76 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> > index 7dda04e0e34e..05aa2ade0499 100644
> > --- a/arch/arm/mach-mvebu/Kconfig
> > +++ b/arch/arm/mach-mvebu/Kconfig
> > @@ -46,7 +46,7 @@ config ARMADA_8K
> >   # Armada PLL frequency (used for NAND clock generation)
> >   config SYS_MVEBU_PLL_CLOCK
> >   int
> > - default "20" if ARMADA_XP || ARMADA_3700 || ARMADA_8K
> > + default "20" if ARMADA_XP || ARMADA_3700 || ARMADA_8K ||
> MSYS
>
> I personally find this "MSYS" abbreviation quite short and not
> descriptive. How is this handled (if at all yet) in Linux?
>

I did briefly consider ARMADA_MSYS. But settled on MSYS because that's how
Marvell tend to refer to it. Marvells code uses MSYS, XCAT3, AC3 and BC2
depending on how specific they need to be (e.g. the ddr code needs to
distinguish AC3 and BC2).

In Linux I originally proposed MSYS but eventually we went with MV98DX3326
as the base and used the other chip names where needed. But that mostly
works out because the arch code is generic so the things that use these
names are mostly compat strings.


> >   default "10" if ARMADA_38X || ARMADA_375
> >
> >   # Armada XP/38x SoC types...
> > @@ -63,6 +63,22 @@ config MV78460
> >   bool
> >   select ARMADA_XP
> >
> > +config MSYS
> > + bool
> > + select ARMADA_32BIT
> > +
> > +config 98DX4251
> > + bool
> > + select MSYS
> > +
> > +config 98DX3336
> > + bool
> > + select MSYS
> > +
> > +config 98DX3236
> > + bool
> > + select MSYS
> > +
> >   config 88F6820
> >   bool
> >   select ARMADA_38X
> > diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
> > index ee2eca913484..e7f1c59e6351 100644
> > --- a/arch/arm/mach-mvebu/Makefile
> > +++ b/arch/arm/mach-mvebu/Makefile
> > @@ -24,6 +24,7 @@ ifndef CONFIG_SPL_BUILD
> >   obj-$(CONFIG_ARMADA_375) += ../../../drivers/ddr/marvell/axp/xor.o
> >   obj-$(CONFIG_ARMADA_38X) += ../../../drivers/ddr/marvell/a38x/xor.o
> >   obj-$(CONFIG_ARMADA_XP) += ../../../drivers/ddr/marvell/axp/xor.o
> > +obj-$(CONFIG_MSYS) += ../../../drivers/ddr/marvell/axp/xor.o
> >   obj-$(CONFIG_MVEBU_EFUSE) += efuse.o
> >
> >   extra-y += kwbimage.cfg
> > diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
> > index 919d05c88c77..e80f9a86c483 100644
> > --- a/arch/arm/mach-mvebu/cpu.c
> > +++ b/arch/arm/mach-mvebu/cpu.c
> > @@ -23,6 +23,12 @@ static struct mbus_win windows[] = {
> >   /* NOR */
> >   { MBUS_BOOTROM_BASE, MBUS_BOOTROM_SIZE,
> > CPU_TARGET_DEVICEBUS_BOOTROM_SPI, CPU_ATTR_BOOTROM },
> > +
> > +#ifdef CONFIG_MSYS
> > + /* DFX */
> > + { MBUS_DFX_BASE, MBUS_DFX_SIZE,
> > +   CPU_TARGET_DFX, 0 },
>
> Nitpicking: Doesn't this fit into one single line?
>

Will fix.


> > +#endif
> >   };
> >
> >   void lowlevel_init(void)
> > @@ -121,6 +127,14 @@ static const struct sar_freq_modes sar_freq_tab[] =
> {
> >   { 0x13,  0x0, 2000, 1000, 933 },
> >   { 0xff, 0xff,0,0,   0 } /* 0xff marks end of array */
> >   };
> > +#elif defined(CONFIG_MSYS)
> > +static const struct sar_freq_modes sar_freq_tab[] = {
> > + {  0x0, 0x0,  400,  400, 400 },
> > + {  0x2, 0x0,  667,  333, 667 },
> > + {  0x3, 0x0,  800,  400, 800 },
> > + {  0x5, 0x0,  800,  400, 800 },
> > + { 0xff, 0xff,0,   0,   0 }  /* 0xff marks end of array */
> > +};
> >   #else
> >   /* SAR frequency values for Armada XP */
> >   static const struct sar_freq_modes sar_freq_tab[] = {
> > @@ -144,7 +158,7 @@ void get_sar_freq(struct sar_freq_modes *sar_freq)
> >   u32 freq;
> >   int i;
> >
> > -#if defined(CONFIG_ARMADA_375)
> > +#if defined(CONFIG_ARMADA_375) || defined(CONFIG_MSYS)
> >   val = readl(CONFIG_SAR2_REG);   /* SAR - Sample At Reset */
> >   #else
> >   val = readl(CONFIG_SAR_REG);/* SAR - Sample At Reset */
> > @@ -160,7 +174,7 @@ void get_sar_freq(struct sar_freq_modes *sar_freq)
> >   #endif
> >   for (i = 0; 

Re: [U-Boot] [PATCH 6/6] doc: imx: habv4: Remove secure_boot.txt guide

[Stefano Babic]

On 23/01/19 20:30, Breno Matheus Lima wrote:
> The secure_boot.txt guide was replaced by mx6_mx7_secure_boot.txt and
> mx6_mx7_spl_secure_boot.txt documents.
> 
> Both documents covers all steps needed for SPL and non-SPL tagets,
> so remove secure_boot.txt file to avoid duplicated content.
> 
> Signed-off-by: Breno Lima 
> ---
>  doc/imx/habv4/secure_boot.txt | 100 --
>  1 file changed, 100 deletions(-)
>  delete mode 100644 doc/imx/habv4/secure_boot.txt
> 
> diff --git a/doc/imx/habv4/secure_boot.txt b/doc/imx/habv4/secure_boot.txt
> deleted file mode 100644
> index ae68dc8040..00
> 

I have applied to my working branch, but I cannot find this on
patchwork. The rest of the series is present, this not, weird..

Regards,
Stefano

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

[U-Boot] [PATCH 3/3] mips: fix erros on registers macros of pll-ddr-config1-nfrac for QCA956X

[Rosy Song]

Signed-off-by: Rosy Song 
---
 arch/mips/mach-ath79/include/mach/ar71xx_regs.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mach-ath79/include/mach/ar71xx_regs.h 
b/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
index 380f387a26..016679e0f8 100644
--- a/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
+++ b/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
@@ -551,7 +551,7 @@
 #define QCA956X_PLL_CPU_CONFIG1_NFRAC_L_SHIFT  0
 #define QCA956X_PLL_CPU_CONFIG1_NFRAC_L_MASK   0x1f
 #define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_SHIFT  5
-#define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK   0x3fff
+#define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK   0x1fff
 #define QCA956X_PLL_CPU_CONFIG1_NINT_SHIFT 18
 #define QCA956X_PLL_CPU_CONFIG1_NINT_MASK  0x1ff
 
@@ -563,7 +563,7 @@
 #define QCA956X_PLL_DDR_CONFIG1_NFRAC_L_SHIFT  0
 #define QCA956X_PLL_DDR_CONFIG1_NFRAC_L_MASK   0x1f
 #define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_SHIFT  5
-#define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK   0x3fff
+#define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK   0x1fff
 #define QCA956X_PLL_DDR_CONFIG1_NINT_SHIFT 18
 #define QCA956X_PLL_DDR_CONFIG1_NINT_MASK  0x1ff
 
-- 
2.17.0

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

[U-Boot] [PATCH 1/3] drivers: ag7xxx: add support for qca956x-s17

[Rosy Song]

Signed-off-by: Rosy Song 
---
 drivers/net/ag7xxx.c | 140 ++-
 1 file changed, 124 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
index 403eb64895..b3b53205fa 100644
--- a/drivers/net/ag7xxx.c
+++ b/drivers/net/ag7xxx.c
@@ -3,6 +3,7 @@
  * Atheros AR71xx / AR9xxx GMAC driver
  *
  * Copyright (C) 2016 Marek Vasut 
+ * Copyright (C) 2019 Rosy Song 
  */
 
 #include 
@@ -23,7 +24,8 @@ DECLARE_GLOBAL_DATA_PTR;
 enum ag7xxx_model {
AG7XXX_MODEL_AG933X,
AG7XXX_MODEL_AG934X,
-   AG7XXX_MODEL_AG953X
+   AG7XXX_MODEL_AG953X,
+   AG7XXX_MODEL_AG956X
 };
 
 /* MAC Configuration 1 */
@@ -219,6 +221,7 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, int 
reg, u32 *val)
u32 reg_addr;
u32 phy_temp;
u32 reg_temp;
+   u32 reg_temp_w = (reg & 0xfffc) >> 1;
u16 rv = 0;
int ret;
 
@@ -226,18 +229,25 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, 
int reg, u32 *val)
priv->model == AG7XXX_MODEL_AG953X) {
phy_addr = 0x1f;
reg_addr = 0x10;
-   } else if (priv->model == AG7XXX_MODEL_AG934X) {
+   } else if (priv->model == AG7XXX_MODEL_AG934X ||
+  priv->model == AG7XXX_MODEL_AG956X) {
phy_addr = 0x18;
reg_addr = 0x00;
} else
return -EINVAL;
 
-   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, (reg >> 9) & 
0x1ff);
+   } else
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
if (ret)
return ret;
 
phy_temp = ((reg >> 6) & 0x7) | 0x10;
-   reg_temp = (reg >> 1) & 0x1e;
+   if (priv->model == AG7XXX_MODEL_AG956X)
+   reg_temp = reg_temp_w & 0x1f;
+   else
+   reg_temp = (reg >> 1) & 0x1e;
*val = 0;
 
ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 0, );
@@ -245,7 +255,13 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, int 
reg, u32 *val)
return ret;
*val |= rv;
 
-   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 1, );
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   phy_temp = (((reg_temp_w + 1) >> 5) & 0x7) | 0x10;
+   reg_temp = (reg_temp_w + 1) & 0x1f;
+   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp, );
+   } else {
+   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 1, );
+   }
if (ret < 0)
return ret;
*val |= (rv << 16);
@@ -260,24 +276,35 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus, 
int reg, u32 val)
u32 reg_addr;
u32 phy_temp;
u32 reg_temp;
+   u32 reg_temp_w = (reg & 0xfffc) >> 1;
int ret;
 
if (priv->model == AG7XXX_MODEL_AG933X ||
priv->model == AG7XXX_MODEL_AG953X) {
phy_addr = 0x1f;
reg_addr = 0x10;
-   } else if (priv->model == AG7XXX_MODEL_AG934X) {
+   } else if (priv->model == AG7XXX_MODEL_AG934X ||
+  priv->model == AG7XXX_MODEL_AG956X) {
phy_addr = 0x18;
reg_addr = 0x00;
} else
return -EINVAL;
 
-   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
+   if (priv->model == AG7XXX_MODEL_AG956X)
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, (reg >> 9) & 
0x1ff);
+   else
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
if (ret)
return ret;
 
-   phy_temp = ((reg >> 6) & 0x7) | 0x10;
-   reg_temp = (reg >> 1) & 0x1e;
+
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   reg_temp = (reg_temp_w + 1) & 0x1f;
+   phy_temp = (((reg_temp_w + 1) >> 5) & 0x7) | 0x10;
+   } else {
+   phy_temp = ((reg >> 6) & 0x7) | 0x10;
+   reg_temp = (reg >> 1) & 0x1e;
+   }
 
/*
 * The switch on AR933x has some special register behavior, which
@@ -296,10 +323,18 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus, 
int reg, u32 val)
if (ret < 0)
return ret;
} else {
-   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp | 1, val >> 
16);
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp, val 
>> 16);
+   } else
+   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp | 1, 
val >> 16);
if (ret < 0)
return ret;
 
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   phy_temp = ((reg_temp_w >> 5) & 0x7) | 0x10;
+   reg_temp = reg_temp_w 

[U-Boot] [PATCH 2/3] mips: add initial support for qca956x referenced board

[Rosy Song]

Signed-off-by: Rosy Song 
---
 arch/mips/dts/Makefile|   1 +
 arch/mips/dts/ap152.dts   |  48 ++
 arch/mips/dts/qca956x.dtsi|  87 
 arch/mips/mach-ath79/Kconfig  |  14 +
 arch/mips/mach-ath79/Makefile |   1 +
 .../mach-ath79/include/mach/ar71xx_regs.h |  70 +++
 arch/mips/mach-ath79/include/mach/ath79.h |   3 +
 arch/mips/mach-ath79/qca956x/Makefile |   5 +
 arch/mips/mach-ath79/qca956x/clk.c| 419 ++
 arch/mips/mach-ath79/qca956x/cpu.c|   9 +
 arch/mips/mach-ath79/qca956x/ddr.c| 308 +
 arch/mips/mach-ath79/qca956x/lowlevel_init.S  |  79 
 .../mips/mach-ath79/qca956x/qca956x-ddr-tap.S | 194 
 arch/mips/mach-ath79/reset.c  | 271 +++
 board/qca/ap152/Kconfig   |  27 ++
 board/qca/ap152/MAINTAINERS   |   6 +
 board/qca/ap152/Makefile  |   3 +
 board/qca/ap152/ap152.c   |  81 
 configs/ap152_defconfig   |  55 +++
 include/configs/ap152.h   |  54 +++
 20 files changed, 1735 insertions(+)
 create mode 100644 arch/mips/dts/ap152.dts
 create mode 100644 arch/mips/dts/qca956x.dtsi
 create mode 100644 arch/mips/mach-ath79/qca956x/Makefile
 create mode 100644 arch/mips/mach-ath79/qca956x/clk.c
 create mode 100644 arch/mips/mach-ath79/qca956x/cpu.c
 create mode 100644 arch/mips/mach-ath79/qca956x/ddr.c
 create mode 100644 arch/mips/mach-ath79/qca956x/lowlevel_init.S
 create mode 100644 arch/mips/mach-ath79/qca956x/qca956x-ddr-tap.S
 create mode 100644 board/qca/ap152/Kconfig
 create mode 100644 board/qca/ap152/MAINTAINERS
 create mode 100644 board/qca/ap152/Makefile
 create mode 100644 board/qca/ap152/ap152.c
 create mode 100644 configs/ap152_defconfig
 create mode 100644 include/configs/ap152.h

diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index b94b582837..621c35f0ef 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -2,6 +2,7 @@
 
 dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
 dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
+dtb-$(CONFIG_TARGET_AP152) += ap152.dtb
 dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
 dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
 dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
diff --git a/arch/mips/dts/ap152.dts b/arch/mips/dts/ap152.dts
new file mode 100644
index 00..1722290c73
--- /dev/null
+++ b/arch/mips/dts/ap152.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Rosy Song 
+ */
+
+/dts-v1/;
+#include "qca956x.dtsi"
+
+/ {
+   model = "AP152 Reference Board";
+   compatible = "qca,ap152", "qca,qca956x";
+
+   aliases {
+   spi0 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   phy-mode = "sgmii";
+   status = "okay";
+};
+
+ {
+   clock-frequency = <2500>;
+};
+
+ {
+   clock-frequency = <2500>;
+   status = "okay";
+};
+
+ {
+   spi-max-frequency = <2500>;
+   status = "okay";
+   spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   memory-map = <0x9f00 0x0100>;
+   spi-max-frequency = <2500>;
+   reg = <0>;
+   };
+};
diff --git a/arch/mips/dts/qca956x.dtsi b/arch/mips/dts/qca956x.dtsi
new file mode 100644
index 00..6cb360b3f8
--- /dev/null
+++ b/arch/mips/dts/qca956x.dtsi
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Rosy Song 
+ */
+
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "qca,qca956x";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "mips,mips74Kc";
+   reg = <0>;
+   };
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   xtal: xtal {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-output-names = "xtal";
+   };
+   };
+
+   ahb {
+   compatible = "simple-bus";
+   ranges;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   apb {
+   compatible = "simple-bus";
+   ranges;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   uart0: uart@1802 {
+   compatible = "ns16550";
+   reg = <0x1802 0x20>;

Re: [U-Boot] [RFC 0/9] Convert Pico-Pi i.MX7D to DM

[Lukasz Majewski]

Hi Fabio,

> Hi Lukasz,
> 
> On Wed, Jan 23, 2019 at 7:01 PM Joris Offouga
>  wrote:
> 
> > Hi Lukasz,
> >  
> > > Please check if malloc pool size (in Kconfig) is large enough to
> > > handle DFU requests.  
> > The dfu request is smaller than the size of malloc pool size  
> > >
> > > Otherwise, please #define DEBUG in ./drivers/dfu.c and dfu_mmc.c
> > > and share output.  
> >
> > This is a log when dfu failed :
> >
> > blk_find_device: if_type=6, devnum=0: us...@30b4.blk, 6, 2
> > blk_find_device: if_type=6, devnum=0: us...@30b5.blk, 6, 1
> > blk_find_device: if_type=6, devnum=0: us...@30b6.blk, 6, 0
> > Request would exceed designated area!

Please carefully check the eMMC partition size (as defined in
dfu_alt_info) and the size of sent data.

This error happens when one wants to write bigger file than the
reported space on the partition.

Please look at drivers/dfu/dfu_mmc.c Line: 44

> > dfu_write_buffer_drain: Write error!
> > #Deferred dfu_flush() failed!reset_config:
> > unbind function 'dfu'/9ef6e678
> > g_dnl_unbind: calling usb_gadget_disconnect for controller
> > 'ci_udc'  
> 
> Do you have any idea on this issue, please?
> 
> This DFU bug is one of the items that is blocking the DM conversion of
> this board.
> 
> Thanks




Best regards,

Lukasz Majewski

--

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


pgpBgAKxqy7iT.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] arm: mvebu: x530: Enable watchdog in SPL and U-Boot

[Chris Packham]

On Fri, 15 Feb 2019, 9:46 PM Stefan Roese  Hi Chris,
>
> On 15.02.19 03:12, Chris Packham wrote:
> > Enable the hardware watchdog to guard against system lock ups when
> > running in the SPL or U-Boot. Stop the watchdog just before booting so
> > that the OS.
> >
> > Signed-off-by: Chris Packham 
> > ---
> >
> >   arch/arm/dts/armada-385-atl-x530-u-boot.dtsi |  4 ++
> >   board/alliedtelesis/x530/x530.c  | 48 
> >   configs/x530_defconfig   |  5 ++
> >   3 files changed, 57 insertions(+)
> >
> > diff --git a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> > index 7074a73537fa..79b694cb84bc 100644
> > --- a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> > +++ b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> > @@ -11,3 +11,7 @@
> >{
> >   u-boot,dm-pre-reloc;
> >   };
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > diff --git a/board/alliedtelesis/x530/x530.c
> b/board/alliedtelesis/x530/x530.c
> > index d7d1942fe686..1b22b6307cd2 100644
> > --- a/board/alliedtelesis/x530/x530.c
> > +++ b/board/alliedtelesis/x530/x530.c
> > @@ -7,6 +7,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -24,6 +25,10 @@ DECLARE_GLOBAL_DATA_PTR;
> >   #define CONFIG_NVS_LOCATION 0xf480
> >   #define CONFIG_NVS_SIZE (512 << 10)
> >
> > +#ifdef CONFIG_WATCHDOG
> > +static struct udevice *watchdog_dev;
> > +#endif
> > +
> >   static struct serdes_map board_serdes_map[] = {
> >   {PEX0, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
> >   {DEFAULT_SERDES, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> > @@ -75,6 +80,10 @@ struct mv_ddr_topology_map
> *mv_ddr_topology_map_get(void)
> >
> >   int board_early_init_f(void)
> >   {
> > +#ifdef CONFIG_WATCHDOG
> > + watchdog_dev = NULL;
> > +#endif
> > +
> >   /* Configure MPP */
> >   writel(0x, MVEBU_MPP_BASE + 0x00);
> >   writel(0x, MVEBU_MPP_BASE + 0x04);
> > @@ -88,6 +97,17 @@ int board_early_init_f(void)
> >   return 0;
> >   }
> >
> > +void spl_board_init(void)
> > +{
> > +#ifdef CONFIG_WATCHDOG
> > + int ret;
> > +
> > + ret = uclass_get_device(UCLASS_WDT, 0, _dev);
> > + if (!ret)
> > + wdt_start(watchdog_dev, 2500ULL * 120, 0);
>
> This is CONFIG_SYS_TCLK? Would it make sense to use this macro
> instead here?
>
> > +#endif
> > +}
> > +
> >   int board_init(void)
> >   {
> >   /* address of boot parameters */
> > @@ -100,9 +120,37 @@ int board_init(void)
> >   /* DEV_READYn is not needed for NVS, ignore it when accessing CS1
> */
> >   writel(0x4001, MVEBU_DEV_BUS_BASE + 0xc8);
> >
> > + spl_board_init();
> > +
> >   return 0;
> >   }
> >
> > +void arch_preboot_os(void)
> > +{
> > +#ifdef CONFIG_WATCHDOG
> > + wdt_stop(watchdog_dev);
> > +#endif
> > +}
>
> So you are not using the WDT in the OS (Linux)?
>

In our production systems we are. But I wanted to allow a kernel built
without the driver to boot and not have it reset on me (e.g. if I'm using a
debugger).


> > +
> > +#ifdef CONFIG_WATCHDOG
> > +void watchdog_reset(void)
> > +{
> > + static ulong next_reset = 0;
> > + ulong now;
> > +
> > + if (!watchdog_dev)
> > + return;
> > +
> > + now = timer_get_us();
> > +
> > + /* Do not reset the watchdog too often */
> > + if (now > next_reset) {
> > + wdt_reset(watchdog_dev);
> > + next_reset = now + 1000;
> > + }
> > +}
> > +#endif
>
> When I recently implemented the watchdog support the MT7688, I
> wondered why there is so much code necessary, that each board
> and platform needs to copy to get this real watchdog working.
> We should definitely rework this at some time, so make this more
> generic with less board specific code that could be shared.
>
> You don't need to change this here. I just wanted to express my
> thoughts, as I'm stumbling over this code again.
>

Yes it's no coincidence that this looks a lot like the code from one of the
turris boards. I was kind of surprised i needed to get the device and start
it but it kind of makes sense as I've decided that my board needs to do it
in the spl where as others might want to use it only to ensure that their
os boots succesfully.

Implementing watchdog_reset was a surprise but again generic code would
need to iterate over all instantiated UCLASS_WDT devices.

May be there's some middle ground with some mvebu specific code that can't
be completely generic but can avoid the repetition.


> Other than this (and your commit text change):
>
> Reviewed-by: Stefan Roese 
>
> Thanks,
> Stefan
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V2 3/3] sunxi: Fix A33 memory initialization

[Philipp Tomsich]

Dipl.-Ing. Dr.techn. Philipp Tomsich
Theobroma Systems Design und Consulting GmbH
Seestadtstrasse 27 (Aspern IQ), A-1220 Wien, Austria
Phone: +43 1 2369893-401, Fax: +43 1 2369893-9-401
Cell phone: +43 664 8346109
http://www.theobroma-systems.com 




> On 15.02.2019, at 12:31, Andre Przywara  wrote:
> 
> On Fri, 15 Feb 2019 11:18:38 +0100
> Philipp Tomsich  wrote:
> 
> Hi Philipp,
> 
>>> On 14.02.2019, at 22:24, André Przywara  wrote:
>>> 
>>> On 14/02/2019 16:36, Philipp Tomsich wrote:  
 
 
> On 14.02.2019, at 16:58, Michael Trimarchi  
> wrote:
> 
> Set two rank timing and exit self-refresh timing seems not done
> properly. We know use the same write that we are using
> on H5 silicon. Tested was done in A33 allwinner cpu, dual rank
> connection connected with two MT41K512M16HA-125:A memory model.
> Memory is configure as DDR3 1.5V
> 
> Signed-off-by: Michael Trimarchi 
> ---
> 
> V1->V2: adjust commit message
> 
> ---
> arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c 
> b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> index d73a93a132..355fe30aba 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> @@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para 
> *para)
>   writel(reg_val, _ctl->dramtmg5);
>   /* Set two rank timing and exit self-refresh timing */
>   clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0),
> - 0x33 << 8 | (0x8 << 0));
> + 0x33 << 8 | (0x10 << 0));  
 
 How exactly does the change in constants match up with the commit message?
 What is the field at “<< 0”?  
>>> 
>>> From looking at the ZynqMP register guide, which is reported to be close
>>> to the various Allwinner DRAM controllers, bits [6:0] are tXS: Self
>>> refresh exit delay. Increasing that should not hurt, and if I understand
>>> it correctly it only affects the time after the self-refresh *exit*,
>>> which happens only after (re-)initialisation(?).  
>> 
>> The “set two rank timing” comment doesn’t match our expectation that
>> this will be self-refresh timings, as on the ZynqMP or the A80.
>> Self-refresh only happens, if someone puts the DRAM into self-refresh
>> (i.e. “suspend to DRAM”) and then resumes it.  I don’t see a reference
>> to the error occurring from this.
> 
> So I was wondering about this as well. Indeed we don't seem to *explicitly* 
> enter or exit Self-Refresh anywhere, but maybe this is done implicitly as 
> part of some training phase?
> I might be wrong about this, but in some DDR3 documentation I see that 
> changing the DLL state is connected to self refresh, and enabling the DLL is 
> required as part of the initialisation? So is the DRAMC somehow triggering a 
> self refresh exit "magically"? If I understand this correctly, our ranking 
> test does reset the controller?

I’d need to reread JESD79 (a much more relaxing read than the daily news),
to figure out whether there’s any valid reason to play with self-refresh during
the training.

>> That said, if the field indeed was the exit self-refresh timing, this would
>> usually be tXSDLL, encoded as tXSDLL/32. JESD79 specifies tESXR as
>> tXSDLL (which in turn is tDLLK(min)), which is 512 nCK always: 0x10
>> would be 512 and 0x08 would only be 256… then again, this should only
>> matter when exiting self-refresh.
> 
> So I was looking at this:
> https://www.xilinx.com/html_docs/registers/ug1087/ddrc___dramtmg8.html
> and tXSDLL is bits [14:8], while the non-DLL tXS is bits [6:0].
> 
>> Note that the ‘auto-enter self-refresh’ functionality is controlled through
>> BIT(3) in PWRCTL on the A33, according to Allwinner’s basic_loader.
>> I don’t know whether that may be turned on by the driver (i.e. didn’t
>> check).
> 
> I don't see us touching pwrctl for the A33 (but for the A23).
> 
>> OTOH, when working with an underdocumented DRAM register layout
>> and once one has an educated guess at what register/setting may be
>> affected, a DRAM protocol analyzer can provide conclusive answers
>> by looking at the differences in behaviour with 0x8 and 0x10 in that
>> bitfield…
> 
> All I have is a multimeter and no A33 ;-)

You are aware that was more of a philosophical rambling and not intended
as a request to you…
However, I am way more surprised that none of the parties having money
riding on their A33 designs has gone through the required effort.

Cheers,
Philipp.

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

Re: [U-Boot] [PATCH V2 3/3] sunxi: Fix A33 memory initialization

[Andre Przywara]

On Fri, 15 Feb 2019 11:18:38 +0100
Philipp Tomsich  wrote:

Hi Philipp,

> > On 14.02.2019, at 22:24, André Przywara  wrote:
> > 
> > On 14/02/2019 16:36, Philipp Tomsich wrote:  
> >> 
> >>   
> >>> On 14.02.2019, at 16:58, Michael Trimarchi  
> >>> wrote:
> >>> 
> >>> Set two rank timing and exit self-refresh timing seems not done
> >>> properly. We know use the same write that we are using
> >>> on H5 silicon. Tested was done in A33 allwinner cpu, dual rank
> >>> connection connected with two MT41K512M16HA-125:A memory model.
> >>> Memory is configure as DDR3 1.5V
> >>> 
> >>> Signed-off-by: Michael Trimarchi 
> >>> ---
> >>> 
> >>> V1->V2: adjust commit message
> >>> 
> >>> ---
> >>> arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c 
> >>> b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> >>> index d73a93a132..355fe30aba 100644
> >>> --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
> >>> +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
> >>> @@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para 
> >>> *para)
> >>>   writel(reg_val, _ctl->dramtmg5);
> >>>   /* Set two rank timing and exit self-refresh timing */
> >>>   clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0),
> >>> - 0x33 << 8 | (0x8 << 0));
> >>> + 0x33 << 8 | (0x10 << 0));  
> >> 
> >> How exactly does the change in constants match up with the commit message?
> >> What is the field at “<< 0”?  
> > 
> > From looking at the ZynqMP register guide, which is reported to be close
> > to the various Allwinner DRAM controllers, bits [6:0] are tXS: Self
> > refresh exit delay. Increasing that should not hurt, and if I understand
> > it correctly it only affects the time after the self-refresh *exit*,
> > which happens only after (re-)initialisation(?).  
> 
> The “set two rank timing” comment doesn’t match our expectation that
> this will be self-refresh timings, as on the ZynqMP or the A80.
> Self-refresh only happens, if someone puts the DRAM into self-refresh
> (i.e. “suspend to DRAM”) and then resumes it.  I don’t see a reference
> to the error occurring from this.

So I was wondering about this as well. Indeed we don't seem to *explicitly* 
enter or exit Self-Refresh anywhere, but maybe this is done implicitly as part 
of some training phase?
I might be wrong about this, but in some DDR3 documentation I see that changing 
the DLL state is connected to self refresh, and enabling the DLL is required as 
part of the initialisation? So is the DRAMC somehow triggering a self refresh 
exit "magically"? If I understand this correctly, our ranking test does reset 
the controller?

> That said, if the field indeed was the exit self-refresh timing, this would
> usually be tXSDLL, encoded as tXSDLL/32. JESD79 specifies tESXR as
> tXSDLL (which in turn is tDLLK(min)), which is 512 nCK always: 0x10
> would be 512 and 0x08 would only be 256… then again, this should only
> matter when exiting self-refresh.

So I was looking at this:
https://www.xilinx.com/html_docs/registers/ug1087/ddrc___dramtmg8.html
and tXSDLL is bits [14:8], while the non-DLL tXS is bits [6:0].

> Note that the ‘auto-enter self-refresh’ functionality is controlled through
> BIT(3) in PWRCTL on the A33, according to Allwinner’s basic_loader.
> I don’t know whether that may be turned on by the driver (i.e. didn’t
> check).

I don't see us touching pwrctl for the A33 (but for the A23).

> OTOH, when working with an underdocumented DRAM register layout
> and once one has an educated guess at what register/setting may be
> affected, a DRAM protocol analyzer can provide conclusive answers
> by looking at the differences in behaviour with 0x8 and 0x10 in that
> bitfield…

All I have is a multimeter and no A33 ;-)

Thanks for providing some background!

Cheers,
Andre.


> Just my 2 cents.
> 
> > But it should be noted that this unconditionally affects all A33 boards.
> >   
> >> Are you configuring the IOs to 1.5V with this write (as the commit message
> >> would suggest)?  
> > 
> > I think the voltage is totally unrelated here, this is a pure timing
> > register.
> > 
> > Cheers,
> > Andre.
> > 
> >   
> >>   
> >>>   /* Set phy interface time */
> >>>   reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8)
> >>>   | (wr_latency << 0);
> >>> -- 
> >>> 2.17.1
> >>> 
> >>> ___
> >>> 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 2/2] arm: mvebu: x530: Enable watchdog in SPL and U-Boot

[Chris Packham]

On Fri, 15 Feb 2019 21:46 Stefan Roese  Hi Chris,
>
> On 15.02.19 03:12, Chris Packham wrote:
> > Enable the hardware watchdog to guard against system lock ups when
> > running in the SPL or U-Boot. Stop the watchdog just before booting so
> > that the OS.
> >
> > Signed-off-by: Chris Packham 
> > ---
> >
> >   arch/arm/dts/armada-385-atl-x530-u-boot.dtsi |  4 ++
> >   board/alliedtelesis/x530/x530.c  | 48 
> >   configs/x530_defconfig   |  5 ++
> >   3 files changed, 57 insertions(+)
> >
> > diff --git a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> > index 7074a73537fa..79b694cb84bc 100644
> > --- a/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> > +++ b/arch/arm/dts/armada-385-atl-x530-u-boot.dtsi
> > @@ -11,3 +11,7 @@
> >{
> >   u-boot,dm-pre-reloc;
> >   };
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > diff --git a/board/alliedtelesis/x530/x530.c
> b/board/alliedtelesis/x530/x530.c
> > index d7d1942fe686..1b22b6307cd2 100644
> > --- a/board/alliedtelesis/x530/x530.c
> > +++ b/board/alliedtelesis/x530/x530.c
> > @@ -7,6 +7,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -24,6 +25,10 @@ DECLARE_GLOBAL_DATA_PTR;
> >   #define CONFIG_NVS_LOCATION 0xf480
> >   #define CONFIG_NVS_SIZE (512 << 10)
> >
> > +#ifdef CONFIG_WATCHDOG
> > +static struct udevice *watchdog_dev;
> > +#endif
> > +
> >   static struct serdes_map board_serdes_map[] = {
> >   {PEX0, SERDES_SPEED_5_GBPS, PEX_ROOT_COMPLEX_X1, 0, 0},
> >   {DEFAULT_SERDES, SERDES_SPEED_5_GBPS, SERDES_DEFAULT_MODE, 0, 0},
> > @@ -75,6 +80,10 @@ struct mv_ddr_topology_map
> *mv_ddr_topology_map_get(void)
> >
> >   int board_early_init_f(void)
> >   {
> > +#ifdef CONFIG_WATCHDOG
> > + watchdog_dev = NULL;
> > +#endif
> > +
> >   /* Configure MPP */
> >   writel(0x, MVEBU_MPP_BASE + 0x00);
> >   writel(0x, MVEBU_MPP_BASE + 0x04);
> > @@ -88,6 +97,17 @@ int board_early_init_f(void)
> >   return 0;
> >   }
> >
> > +void spl_board_init(void)
> > +{
> > +#ifdef CONFIG_WATCHDOG
> > + int ret;
> > +
> > + ret = uclass_get_device(UCLASS_WDT, 0, _dev);
> > + if (!ret)
> > + wdt_start(watchdog_dev, 2500ULL * 120, 0);
>
> This is CONFIG_SYS_TCLK? Would it make sense to use this macro
> instead here?
>

Yes it would. I'll send a v2 with this change.

Ideally I'd specify the value in ms and have orion_wdt deal with the
details of SYS_TCLK.


> > +#endif
> > +}
> > +
> >   int board_init(void)
> >   {
> >   /* address of boot parameters */
> > @@ -100,9 +120,37 @@ int board_init(void)
> >   /* DEV_READYn is not needed for NVS, ignore it when accessing CS1
> */
> >   writel(0x4001, MVEBU_DEV_BUS_BASE + 0xc8);
> >
> > + spl_board_init();
> > +
> >   return 0;
> >   }
> >
> > +void arch_preboot_os(void)
> > +{
> > +#ifdef CONFIG_WATCHDOG
> > + wdt_stop(watchdog_dev);
> > +#endif
> > +}
>
> So you are not using the WDT in the OS (Linux)?
>
> > +
> > +#ifdef CONFIG_WATCHDOG
> > +void watchdog_reset(void)
> > +{
> > + static ulong next_reset = 0;
> > + ulong now;
> > +
> > + if (!watchdog_dev)
> > + return;
> > +
> > + now = timer_get_us();
> > +
> > + /* Do not reset the watchdog too often */
> > + if (now > next_reset) {
> > + wdt_reset(watchdog_dev);
> > + next_reset = now + 1000;
> > + }
> > +}
> > +#endif
>
> When I recently implemented the watchdog support the MT7688, I
> wondered why there is so much code necessary, that each board
> and platform needs to copy to get this real watchdog working.
> We should definitely rework this at some time, so make this more
> generic with less board specific code that could be shared.
>
> You don't need to change this here. I just wanted to express my
> thoughts, as I'm stumbling over this code again.
>
> Other than this (and your commit text change):
>
> Reviewed-by: Stefan Roese 
>
> Thanks,
> Stefan
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 0/9] Convert Pico-Pi i.MX7D to DM

[Fabio Estevam]

Hi Lukasz,

On Wed, Jan 23, 2019 at 7:01 PM Joris Offouga  wrote:

> Hi Lukasz,
>
> > Please check if malloc pool size (in Kconfig) is large enough to handle
> > DFU requests.
> The dfu request is smaller than the size of malloc pool size
> >
> > Otherwise, please #define DEBUG in ./drivers/dfu.c and dfu_mmc.c and
> > share output.
>
> This is a log when dfu failed :
>
> blk_find_device: if_type=6, devnum=0: us...@30b4.blk, 6, 2
> blk_find_device: if_type=6, devnum=0: us...@30b5.blk, 6, 1
> blk_find_device: if_type=6, devnum=0: us...@30b6.blk, 6, 0
> Request would exceed designated area!
> dfu_write_buffer_drain: Write error!
> #Deferred dfu_flush() failed!reset_config:
> unbind function 'dfu'/9ef6e678
> g_dnl_unbind: calling usb_gadget_disconnect for controller 'ci_udc'

Do you have any idea on this issue, please?

This DFU bug is one of the items that is blocking the DM conversion of
this board.

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

[U-Boot] [PATCH v2 2/3] sunxi: Rename Sinovoip BPI M2 Plus to Bananapi M2 Plus H3

[Chen-Yu Tsai]

The brand Sinovoip is used for Sinovoip's original VOIP products, while
the Bananapi brand is for the single board computers they produce. This
has been verified by Bananapi. Rename the board from "Sinovoip BPI M2
Plus" to "Bananapi M2 Plus". For the defconfig file, all lowercase is
used.

To support the H5 variant of this board, the "H3" suffix is added to
the defconfig name.

A symbolic link for the original defconfig, pointing to the new one, is
added to keep 3rd party distributions happy.

Also add myself as one of the board maintainers.

As the device tree files were already correctly named, they do not
require any changes.

Signed-off-by: Chen-Yu Tsai 

---

Changes in v2:
  - Drop symlink using original name, and entry for it in MAINTAINERS
  - Remove unrelated changes while renaming

 board/sunxi/MAINTAINERS   | 11 ++-
 ...2_Plus_defconfig => bananapi_m2_plus_h3_defconfig} |  0
 2 files changed, 6 insertions(+), 5 deletions(-)
 rename configs/{Sinovoip_BPI_M2_Plus_defconfig => 
bananapi_m2_plus_h3_defconfig} (100%)

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 608a86be4970..c6c6aee1810c 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -137,6 +137,12 @@ M: Jagan Teki 
 S: Maintained
 F: configs/bananapi_m2_berry_defconfig
 
+BANANAPI M2 PLUS H3 BOARD
+M: Icenowy Zheng 
+M: Chen-Yu Tsai 
+S: Maintained
+F: configs/bananapi_m2_plus_h3_defconfig
+
 BANANAPI M2 ULTRA BOARD
 M: Chen-Yu Tsai 
 S: Maintained
@@ -418,11 +424,6 @@ S: Maintained
 F: configs/Sinlinx_SinA33_defconfig
 W: http://linux-sunxi.org/Sinlinx_SinA33
 
-SINOVOIP BPI M2 PLUS H3 BOARD
-M: Icenowy Zheng 
-S: Maintained
-F: configs/Sinovoip_BPI_M2_Plus_defconfig
-
 SINOVOIP BPI M3 A83T BOARD
 M: VishnuPatekar 
 S: Maintained
diff --git a/configs/Sinovoip_BPI_M2_Plus_defconfig 
b/configs/bananapi_m2_plus_h3_defconfig
similarity index 100%
rename from configs/Sinovoip_BPI_M2_Plus_defconfig
rename to configs/bananapi_m2_plus_h3_defconfig
-- 
2.20.1

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

[U-Boot] [PATCH v2 3/3] sunxi: Add Bananapi M2+ H5 board

[Chen-Yu Tsai]

As the H5 is pin compatible with the H3, vendors tend to upgrade their
existing H3 products with an H5 SoC swap. This is the case with the
Bananapi M2+ H5.

Add the following to support it:

  - device tree file: synced from Linux v5.0-rc1,
  - defconfig: copy of bananapi_m2_plus_h3_defconfig with only SoC
   family and default device tree file name changed
  - MAINTAINERS entry

Signed-off-by: Chen-Yu Tsai 

---

Changes in v2: None

 arch/arm/dts/sun50i-h5-bananapi-m2-plus.dts   | 11 +++
 board/sunxi/MAINTAINERS   |  3 ++-
 ...lus_h3_defconfig => bananapi_m2_plus_h5_defconfig} |  6 +++---
 3 files changed, 16 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus.dts
 copy configs/{bananapi_m2_plus_h3_defconfig => bananapi_m2_plus_h5_defconfig} 
(85%)

diff --git a/arch/arm/dts/sun50i-h5-bananapi-m2-plus.dts 
b/arch/arm/dts/sun50i-h5-bananapi-m2-plus.dts
new file mode 100644
index ..350376748389
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5-bananapi-m2-plus.dts
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (C) 2018 Chen-Yu Tsai 
+
+/dts-v1/;
+#include "sun50i-h5.dtsi"
+#include 
+
+/ {
+   model = "Banana Pi BPI-M2-Plus H5";
+   compatible = "sinovoip,bpi-m2-plus", "allwinner,sun50i-h5";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index c6c6aee1810c..8e2f90fc68c3 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -137,11 +137,12 @@ M:Jagan Teki 
 S: Maintained
 F: configs/bananapi_m2_berry_defconfig
 
-BANANAPI M2 PLUS H3 BOARD
+BANANAPI M2 PLUS BOARDS
 M: Icenowy Zheng 
 M: Chen-Yu Tsai 
 S: Maintained
 F: configs/bananapi_m2_plus_h3_defconfig
+F: configs/bananapi_m2_plus_h5_defconfig
 
 BANANAPI M2 ULTRA BOARD
 M: Chen-Yu Tsai 
diff --git a/configs/bananapi_m2_plus_h3_defconfig 
b/configs/bananapi_m2_plus_h5_defconfig
similarity index 85%
copy from configs/bananapi_m2_plus_h3_defconfig
copy to configs/bananapi_m2_plus_h5_defconfig
index 597618fb900b..e7c10dbdf2d0 100644
--- a/configs/bananapi_m2_plus_h3_defconfig
+++ b/configs/bananapi_m2_plus_h5_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL=y
-CONFIG_MACH_SUN8I_H3=y
+CONFIG_MACH_SUN50I_H5=y
 CONFIG_DRAM_CLK=672
 CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
@@ -12,9 +12,9 @@ CONFIG_NR_DRAM_BANKS=1
 # CONFIG_CMD_FLASH is not set
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
-CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-bananapi-m2-plus"
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-bananapi-m2-plus"
 CONFIG_SUN8I_EMAC=y
-CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_MUSB_GADGET=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.20.1

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