Re: [U-Boot] [PATCH] efi_loader: Fix partition offsets

[Heinrich Schuchardt]

On 12/01/2017 04:10 PM, Alexander Graf wrote:

Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) tried
to introduce the el torito scheme to all partition table types: Spawn
individual disk objects for each partition on a disk.

Unfortunately, that code ended up creating partitions with offset=0 which meant
that anyone accessing these objects gets data from the raw block device instead
of the partition.

Furthermore, all the el torito logic to spawn devices for partitions was
duplicated. So let's merge the two code paths and give partition disk objects
good offsets to work from, so that payloads can actually make use of them.

Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions)
Reported-by: Yousaf Kaukab 
Signed-off-by: Alexander Graf 
---
  lib/efi_loader/efi_disk.c | 60 ++-
  1 file changed, 13 insertions(+), 47 deletions(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 68ba2cf7b2..4e457a841b 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -264,21 +264,17 @@ out_of_memory:
printf("ERROR: Out of memory\n");
  }
  
-static int efi_disk_create_eltorito(struct blk_desc *desc,

-   const char *if_typename,
-   int diskid,
-   const char *pdevname)
+static int efi_disk_create_partitions(struct blk_desc *desc,
+ const char *if_typename,
+ int diskid,
+ const char *pdevname)
  {
int disks = 0;
-#if CONFIG_IS_ENABLED(ISO_PARTITION)
char devname[32] = { 0 }; /* dp->str is u16[32] long */
disk_partition_t info;
int part;
  
-	if (desc->part_type != PART_TYPE_ISO)

-   return 0;
-
-   /* and devices for each partition: */
+   /* Add devices for each partition */
for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
if (part_get_info(desc, part, ))
continue;
@@ -289,10 +285,6 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,
disks++;
}
  
-	/* ... and add block device: */

-   efi_disk_add_dev(devname, if_typename, desc, diskid, 0, 0);
-#endif
-
return disks;
  }
  
@@ -318,31 +310,18 @@ int efi_disk_register(void)

 uclass_next_device_check()) {
struct blk_desc *desc = dev_get_uclass_platdata(dev);
const char *if_typename = dev->driver->name;
-   disk_partition_t info;
-   int part;
  
  		printf("Scanning disk %s...\n", dev->name);
  
-		/* add devices for each partition: */

-   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
-   if (part_get_info(desc, part, ))
-   continue;
-   efi_disk_add_dev(dev->name, if_typename, desc,
-desc->devnum, 0, part);
-   }
-
-   /* ... and add block device: */
+   /* Add block device for the full device */
efi_disk_add_dev(dev->name, if_typename, desc,
 desc->devnum, 0, 0);
  
  		disks++;
  
-		/*

-   * El Torito images show up as block devices in an EFI world,
-   * so let's create them here
-   */
-   disks += efi_disk_create_eltorito(desc, if_typename,
- desc->devnum, dev->name);
+   /* Partitions show up as block devices in EFI */
+   disks += efi_disk_create_partitions(desc, if_typename,
+   desc->devnum, dev->name);
}
  #else >int i, if_type;
@@ -361,8 +340,6 @@ int efi_disk_register(void)
for (i = 0; i < 4; i++) {


include/configs/highbank.h allows 5 SCSI drives.
include/configs/qemu-arm.h allows 6 SCSI drives.

I guess you want to use drv->max_devs as upper limit.


struct blk_desc *desc;
char devname[32] = { 0 }; /* dp->str is u16[32] long */
-   disk_partition_t info;
-   int part;
  
  			desc = blk_get_devnum_by_type(if_type, i);

if (!desc)
@@ -373,24 +350,13 @@ int efi_disk_register(void)
snprintf(devname, sizeof(devname), "%s%d",
 if_typename, i);
  
-			/* add devices for each partition: */

-   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
-   if (part_get_info(desc, part, ))
-   continue;
-   efi_disk_add_dev(devname, if_typename, desc,
- 

Re: [U-Boot] [PATCH 4/4] ARM: imx: cm_fx6: remove esdhc init code from board file

[Simon Glass]

On 30 November 2017 at 14:38,   wrote:
> From: Christopher Spinrath 
>
> Commit 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> enabled driver model support for MMC. Remove the old mmc init code, which
> is no longer used, from the board file.
>
> Signed-off-by: Christopher Spinrath 
> ---
>  board/compulab/cm_fx6/cm_fx6.c | 29 -
>  1 file changed, 29 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] scripts: spl: fix typo

[Simon Glass]

On 29 November 2017 at 19:07, Peng Fan  wrote:
> Typo fix: CONIFG->CONFIG
>
> Signed-off-by: Peng Fan 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
>  scripts/Makefile.uncmd_spl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [RFC PATCH 09/13] arm: nexell: add UART support

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> The Nexell S5P6818 SoC uses a UART very similar to those used in the
> Samsung S5P SoCs.
> Enable the driver in the config and add the necessary glue headers
> and clock functions to make the S5P driver happy.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/Kconfig   |  3 ++
>  arch/arm/include/asm/arch-nexell/clk.h | 13 +
>  arch/arm/mach-nexell/board.c   | 50 
> ++
>  3 files changed, 66 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-nexell/clk.h

Reviewed-by: Simon Glass 

Q below

>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b0f3ee7289..9c317ddf3f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -656,6 +656,9 @@ config ARCH_NEXELL
> bool "Nexell S5P support"
> select ARM64
> select ENABLE_ARM_SOC_BOOT0_HOOK
> +   select DM
> +   select DM_SERIAL
> +   select SAMSUNG_UART
>
>  config ARCH_QEMU
> bool "QEMU Virtual Platform"
> diff --git a/arch/arm/include/asm/arch-nexell/clk.h 
> b/arch/arm/include/asm/arch-nexell/clk.h
> new file mode 100644
> index 00..bfd145f555
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-nexell/clk.h
> @@ -0,0 +1,13 @@
> +/*
> + * (C) Copyright 2017 ARM Ltd.
> + * Andre Przywara 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef __ASM_ARCH_CLK_H_
> +#define __ASM_ARCH_CLK_H_
> +
> +unsigned long get_uart_clk(int dev_index);
> +
> +#endif
> diff --git a/arch/arm/mach-nexell/board.c b/arch/arm/mach-nexell/board.c
> index f0d258b71c..54a9d8c1f5 100644
> --- a/arch/arm/mach-nexell/board.c
> +++ b/arch/arm/mach-nexell/board.c
> @@ -5,9 +5,14 @@
>   */
>
>  #include 
> +#include 
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +#define NEXELL_PLLSETREG0  0xc0010008UL

Is this not in the DT?

Do you need the UL?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] ARM: imx: cm-fx6: reinstate USB support by syncing the devicetree with Linux

[Simon Glass]

On 30 November 2017 at 14:38,   wrote:
> From: Christopher Spinrath 
>
> Commit 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> enabled driver model support for USB, thereby effectively removing USB
> support because the cm_fx6 devicetree in the U-Boot does *not* enable the
> USB nodes.
>
> Reinstate the USB support by syncing the devicetree with Linux whose
> devicetree enables the USB nodes properly.
>
> More precisely, use the devicetree found in Linux v4.15-rc1 with the
> following two changes:
>   1) Remove the audio mux; the required dt-bindings header is not
>  present in the U-Boot.
>   2) Keep the usdhc3 MMC controller node currently present in the
>  U-Boot's devicetree to retain the ability to boot from MMC.
>
> Fixes: 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> Signed-off-by: Christopher Spinrath 
> ---
>  arch/arm/dts/imx6q-cm-fx6.dts | 396 
> --
>  1 file changed, 342 insertions(+), 54 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 12/13] arm: add NanoPi M3 board support

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> The NanoPi M3 is a single board computer containing a
> Nexell S5P6818 SoC (with 8 ARMv8 Cortex-A53 cores).
> Add the respective defconfig and a (preliminary) device tree listing
> the devices that we support so far.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/Kconfig   |  6 ++
>  arch/arm/dts/s5p6818-nanopi-m3.dts | 30 ++
>  arch/arm/include/asm/arch-nexell/clk.h |  1 +
>  arch/arm/mach-nexell/board.c   | 10 ++
>  configs/nanopi_m3_defconfig| 12 
>  include/configs/s5p6818.h  |  2 ++
>  6 files changed, 61 insertions(+)
>  create mode 100644 arch/arm/dts/s5p6818-nanopi-m3.dts
>  create mode 100644 configs/nanopi_m3_defconfig

Reviewed-by: Simon Glass 

I think this needs a clock driver.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] ARM: imx: cm_fx6: defconfig: enable CONFIG_DM_KEYBOARD

[Simon Glass]

On 30 November 2017 at 14:38,   wrote:
> From: Christopher Spinrath 
>
> Commit 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> enabled driver model support for USB. But it missed to enable driver
> model support for keyboards. As a result, USB keyboards do no longer
> work.
>
> Fix this by enabling driver model support for keyboards.
>
> Fixes: 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> Signed-off-by: Christopher Spinrath 
> ---
>  configs/cm_fx6_defconfig | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [U-Boot] [RFC PATCH 07/13] arm: nexell: embed NSIH header

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> The primary boot loaders provided by the SoC vendor or derived from that
> use an image format called "NSIH" to learn the load address and size of
> the boot payload. This header occupies 512 bytes, but contains only a
> few essential words of information.
> Use the boot0 feature to prepend this header before the actual U-Boot
> proper. We automatically fill it with the required information, also
> add a branch instruction to be able to enter at the beginning of the
> header.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/Kconfig |  1 +
>  arch/arm/include/asm/arch-nexell/boot0.h | 35 
> 
>  2 files changed, 36 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-nexell/boot0.h

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

Re: [U-Boot] [RFC PATCH 11/13] arm: nexell: add preliminary S5P6818 SoC device tree

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> The Nexell S5P6818 SoC is an octa-core SoC with ARM Cortex-A53 cores.
> The chip contains the usual peripherals for an smartphone/tablet/set-top
> box SoC.
> Add the .dtsi file describing the peripherals supported so far, but
> keep them still disabled.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/Kconfig  |   1 +
>  arch/arm/dts/s5p6818.dtsi | 196 
> ++
>  2 files changed, 197 insertions(+)
>  create mode 100644 arch/arm/dts/s5p6818.dtsi

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

Re: [U-Boot] [RFC PATCH 04/13] reset: add driver for generic reset controllers

[Simon Glass]

Hi Andre,

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> From: Amit Singh Tomar 
>
> The simplest and most generic form of a reset controller just exposes
> multiple MMIO registers, where each bit toggles a separate reset line.
> Add a generic driver to describe this kind of reset controller.
>
> This is used on the Nexell S5P6818, for instance, but also by other
> SoCs.
>
> Signed-off-by: Amit Singh Tomar 
> [Andre: make more generic, let it cover multiple registers, slight rework]
> Signed-off-by: Andre Przywara 
> ---
>  drivers/reset/Kconfig |   6 +++
>  drivers/reset/Makefile|   1 +
>  drivers/reset/reset-generic.c | 111 
> ++
>  3 files changed, 118 insertions(+)
>  create mode 100644 drivers/reset/reset-generic.c

Reviewed-by: Simon Glass 

Is there a DT binding for this?

Also please see below.

>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index ce46e2752c..3032b0064c 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -12,6 +12,12 @@ config DM_RESET
>   although driving such reset isgnals using GPIOs may be more
>   appropriate in this case.
>
> +config GENERIC_RESET
> +bool "Generic Reset controller driver"
> +depends on DM_RESET
> +help
> +  Support Generic reset controller.

What is this? This help needs to be expanded with details.

> +
>  config SANDBOX_RESET
> bool "Enable the sandbox reset test driver"
> depends on DM_MAILBOX && SANDBOX
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 252cefeed5..81680837ef 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_TEGRA186_RESET) += tegra186-reset.o
>  obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
>  obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
>  obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o
> +obj-$(CONFIG_GENERIC_RESET) += reset-generic.o
> diff --git a/drivers/reset/reset-generic.c b/drivers/reset/reset-generic.c
> new file mode 100644
> index 00..0a7740202d
> --- /dev/null
> +++ b/drivers/reset/reset-generic.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (C) 2017 Amit Singh Tomar 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct generic_reset_priv {
> +   void __iomem *membase;
> +   int max_reset;

comment

> +};
> +
> +#define BITS_PER_BYTE 8

blank line here

> +static int generic_reset_toggle(struct reset_ctl *rst, bool assert)
> +{
> +   struct generic_reset_priv *priv = dev_get_priv(rst->dev);
> +   int reg_width = sizeof(u32);
> +   int bank, offset;
> +   u32 reg;
> +
> +   if (rst->id >= priv->max_reset)
> +   return -EINVAL;
> +
> +   bank = rst->id / (reg_width * BITS_PER_BYTE);
> +   offset = rst->id % (reg_width * BITS_PER_BYTE);
> +
> +   reg = readl(priv->membase + (bank * reg_width));

Can you put that expression in a local var?


> +   if (assert)
> +   writel(reg & ~BIT(offset), priv->membase + (bank * 
> reg_width));
> +   else
> +   writel(reg | BIT(offset), priv->membase + (bank * reg_width));
> +
> +   return 0;
> +}
> +
> +static int generic_reset_assert(struct reset_ctl *rst)
> +{
> +   return generic_reset_toggle(rst, true);
> +}
> +
> +static int generic_reset_deassert(struct reset_ctl *rst)
> +{
> +   return generic_reset_toggle(rst, false);
> +}
> +
> +static int generic_reset_free(struct reset_ctl *rst)
> +{
> +   return 0;
> +}
> +
> +static int generic_reset_request(struct reset_ctl *rst)
> +{
> +   struct generic_reset_priv *priv = dev_get_priv(rst->dev);
> +
> +   if (rst->id >= priv->max_reset)
> +   return -EINVAL;

OK I suppose. How about -ENOENT?

> +
> +   return generic_reset_assert(rst);
> +}
> +
> +struct reset_ops generic_reset_reset_ops = {
> +   .free = generic_reset_free,
> +   .request = generic_reset_request,
> +   .rst_assert = generic_reset_assert,
> +   .rst_deassert = generic_reset_deassert,
> +};
> +
> +static const struct udevice_id generic_reset_ids[] = {
> +   { .compatible = "generic-reset" },
> +   { .compatible = "nexell,s5p6818-reset" },
> +   { }
> +};
> +
> +static int generic_reset_probe(struct udevice *dev)
> +{
> +   struct generic_reset_priv *priv = dev_get_priv(dev);
> +   fdt_addr_t addr;
> +   fdt_size_t size;
> +
> +   addr = devfdt_get_addr_size_index(dev, 0, );

Can we use dev_read_... here?

> +   if (addr == FDT_ADDR_T_NONE)
> +   return -EINVAL;
> +
> +   priv->max_reset = dev_read_u32_default(dev, "num-resets", -1);
> +   if (priv->max_reset == -1)
> +  

Re: [U-Boot] [RFC PATCH 10/13] arm: nexell: add timer support

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> From: Amit Singh Tomar 
>
> Nexell based SoCs (S5P4414 and S5P6818) contain the same timer block as
> present on Samsungs SoCs.
>
> Add this timer code when compiling for Nexell SoC and provide the
> necessary glue functions to make the Samsung timer driver happy.
>
> Signed-off-by: Amit Singh Tomar 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/include/asm/arch-nexell/clk.h |  1 +
>  arch/arm/include/asm/arch-nexell/pwm.h | 62 
> ++
>  arch/arm/mach-nexell/Makefile  |  2 ++
>  arch/arm/mach-nexell/board.c   | 37 +---
>  4 files changed, 97 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-nexell/pwm.h

Reviewed-by: Simon Glass 

But I encourage use of setclrbits_le32()
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 05/13] mmc: add MMC (glue) driver for Nexell SoCs

[Simon Glass]

Hi Andre,

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> From: Amit Singh Tomar 
>
> The Nexell SoCs contain multiple MMC devices, which can be driven by
> U-Boot's DesignWare MMC driver, if supported by the required glue driver
> file.
> Provide that file along with the Makefile/Kconfig changes.
>
> Signed-off-by: Amit Singh Tomar 
> Signed-off-by: Andre Przywara 
> ---
>  drivers/mmc/Kconfig |   8 +++
>  drivers/mmc/Makefile|   1 +
>  drivers/mmc/nexell_dw_mmc.c | 159 
> 
>  3 files changed, 168 insertions(+)
>  create mode 100644 drivers/mmc/nexell_dw_mmc.c
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 62ce0af7d3..243878aa65 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -91,6 +91,14 @@ config MMC_DW_K3
>   Synopsys DesignWare Memory Card Interface driver. Select this option
>   for platforms based on Hisilicon K3 SoC's.
>
> +config MMC_DW_NEXELL
> +bool "NEXELL SD/MMC controller support"
> +depends on ARCH_NEXELL && DM_MMC && OF_CONTROL
> +depends on MMC_DW
> +help
> +  This enables support for the Nexell SD/MMM controller, which is
> +  based on Designware IP.
> +
>  config MMC_DW_ROCKCHIP
> bool "Rockchip SD/MMC controller support"
> depends on DM_MMC && OF_CONTROL
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index d505f37f01..0fb6eb7803 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_MMC_DAVINCI) += davinci_mmc.o
>  obj-$(CONFIG_MMC_DW)   += dw_mmc.o
>  obj-$(CONFIG_MMC_DW_EXYNOS)+= exynos_dw_mmc.o
>  obj-$(CONFIG_MMC_DW_K3)+= hi6220_dw_mmc.o
> +obj-$(CONFIG_MMC_DW_NEXELL)+= nexell_dw_mmc.o
>  obj-$(CONFIG_MMC_DW_ROCKCHIP)  += rockchip_dw_mmc.o
>  obj-$(CONFIG_MMC_DW_SOCFPGA)   += socfpga_dw_mmc.o
>  obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
> diff --git a/drivers/mmc/nexell_dw_mmc.c b/drivers/mmc/nexell_dw_mmc.c
> new file mode 100644
> index 00..e96395cdaf
> --- /dev/null
> +++ b/drivers/mmc/nexell_dw_mmc.c
> @@ -0,0 +1,159 @@
> +/*
> + * Copyright (C) 2017 Amit Singh Tomar 
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SDMMCCLKENB 0xC00C5000
> +#define SDMMCCLKGEN0L 0xC00C5004
> +#define PLL_SEL_MASK GENMASK(4, 2)
> +#define CLK_DIV_MASK GENMASK(12, 5)
> +#define PLLSEL_SHIFT 0x2
> +#define PLL0_SEL 0
> +#define PLL1_SEL 1
> +#define PLL2_SEL 2
> +#define SDMMC_CLK_ENB 0xc /* Magic bit to enable/generate SDMMC clock */
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct nexell_mmc_plat {
> +   struct mmc_config cfg;
> +   struct mmc mmc;
> +};
> +
> +struct nexell_dwmmc_priv {
> +   struct clk clk;
> +   struct dwmci_host host;
> +   struct reset_ctl reset_ctl;
> +   int fifo_depth;
> +   bool fifo_mode;

comments

> +};
> +
> +/* Should this be done from CCF ? */
> +static void nexell_dwmci_clksel(struct dwmci_host *host)
> +{
> +   u32 val;
> +
> +   /* Enable SDMMC clock */
> +   val = readl(SDMMCCLKENB);
> +   val |= SDMMC_CLK_ENB;
> +   writel(val, SDMMCCLKENB);

How about using setbits_le32() ?

> +
> +   /* Select PLL1 as clock source */
> +   val = readl(SDMMCCLKGEN0L);
> +   val = val & ~(PLL_SEL_MASK);
> +   val |= (PLL1_SEL << PLLSEL_SHIFT) & PLL_SEL_MASK;
> +   writel(val, SDMMCCLKGEN0L);

clrsetbits_le32

> +}
> +
> +static int nexell_dwmmc_ofdata_to_platdata(struct udevice *dev)
> +{
> +   struct nexell_dwmmc_priv *priv = dev_get_priv(dev);
> +   struct dwmci_host *host = >host;
> +   int fifo_depth, ret;
> +
> +   ret = reset_get_by_name(dev, "mmc", >reset_ctl);
> +   if (ret) {
> +   printf("reset_get_by_name(rst) failed: %d", ret);

debug() ? And below

> +   return ret;
> +   }
> +
> +   fifo_depth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> +   "fifo-depth", 0);

dev_read_...()

and below

> +   if (fifo_depth < 0) {
> +   printf("DWMMC: Can't get FIFO depth\n");
> +   return -EINVAL;
> +   }
> +
> +   host->name = dev->name;
> +   host->ioaddr = (void *)devfdt_get_addr(dev);
> +   host->buswidth = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
> +   "bus-width", 4);
> +
> +   ret = reset_assert(>reset_ctl);
> +   if (ret)
> +   return ret;
> +
> +   host->clksel = nexell_dwmci_clksel;
> +
> +   ret = reset_deassert(>reset_ctl);
> +   if (ret)
> +   return ret;
> +
> +   

Re: [U-Boot] [RFC PATCH 13/13] arm: nexell: switch to 32-bit

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> The vendor provided SPL blob (called "secondboot") runs completely in
> AArch32, so expects U-Boot to be AArch32 as well.
> Also the lack of a working arch timer limits Linux to 32-bits, as the
> mainline arm64 kernel heavily relies on the arch timer.
>
> This commit switches the NanoPiM3 board over to generate an ARM(32) binary,
> to allow easy testing for now. Also this adds a README file to describe
> the generation of a bootable SD card image.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/Kconfig|  2 +-
>  arch/arm/mach-nexell/README | 49 
> +
>  2 files changed, 50 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-nexell/README

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

Re: [U-Boot] [RFC PATCH 06/13] arm: add basic framework for Nexell S5P6818 support

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> The Nexell S5P6818 is a typical SoC with ARM Cortex-A53 cores.
> It has many peripherals derived from Samsung SoCs (MMC, serial, I2C,
> Ethernet, ...).
> Add the required files to introduce this new SoC (family?) to U-Boot.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/Kconfig  |  6 ++
>  arch/arm/Makefile |  1 +
>  arch/arm/mach-nexell/Kconfig  |  9 +
>  arch/arm/mach-nexell/Makefile |  7 +++
>  arch/arm/mach-nexell/board.c  | 41 +
>  include/configs/s5p6818.h | 33 +
>  6 files changed, 97 insertions(+)
>  create mode 100644 arch/arm/mach-nexell/Kconfig
>  create mode 100644 arch/arm/mach-nexell/Makefile
>  create mode 100644 arch/arm/mach-nexell/board.c
>  create mode 100644 include/configs/s5p6818.h

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

Re: [U-Boot] [RFC PATCH 08/13] arm: nexell: add ARM64 MMU regions

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> From: Amit Singh Tomar 
>
> ARMv8 boards require a struct describing the memory regions for the
> mandatory MMU setup.
> Add the respective data for the Nexell S5P6818 SoC.
>
> Signed-off-by: Amit Singh Tomar 
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/mach-nexell/Makefile|  1 +
>  arch/arm/mach-nexell/mmu-arm64.c | 39 +++
>  2 files changed, 40 insertions(+)
>  create mode 100644 arch/arm/mach-nexell/mmu-arm64.c

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

Re: [U-Boot] [PATCH] cmd: i2c: Fix use sdram sub command with CONFIG_DM_I2C

[Simon Glass]

On 30 November 2017 at 22:39, Nobuhiro Iwamatsu  wrote:
> sdram sub command of i2c command does not support Drivers Model.
> This adds Drivers Model support to sdram sub command.
>
> Signed-off-by: Nobuhiro Iwamatsu 
> ---
>  cmd/i2c.c | 14 --
>  1 file changed, 12 insertions(+), 2 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 3/4] ARM: imx: cm_fx6: remove sata init code from board file

[Simon Glass]

On 30 November 2017 at 14:38,   wrote:
> From: Christopher Spinrath 
>
> Commit 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> enabled driver model support for AHCI. Remove the old, now unused, sata
> init code from the board file.
>
> Signed-off-by: Christopher Spinrath 
> ---
>  board/compulab/cm_fx6/cm_fx6.c | 42 
> --
>  1 file changed, 42 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 2/2] ARM: socfpga: remove unneeded CONFIG_SYS_NAND_USE_FLASH_BBT

[Simon Glass]

On 29 November 2017 at 03:13, Masahiro Yamada
 wrote:
> Neither denali.c nor denali_spl.c references this option.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  include/configs/socfpga_common.h | 1 -
>  1 file changed, 1 deletion(-)

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

Re: [U-Boot] [PATCH v4 02/10] dm: mmc: update mmc_of_parse()

[Simon Glass]

On 29 November 2017 at 07:29, Jean-Jacques Hiblot  wrote:
> * convert to livetree API
> * don't fail because of an invalid bus-width, instead default to 1-bit.
> * recognize 1.2v DDR and 1.2v HS200 flags
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
> no changes since v3
>
>  drivers/mmc/mmc-uclass.c | 36 
>  include/mmc.h| 11 ++-
>  2 files changed, 30 insertions(+), 17 deletions(-)

Reviewed-by: Simon Glass 

I thought I already reviewed this?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3][v3] Update MAC address in "ethernet" node of Linux device tree

[Simon Glass]

Hi York,

On 29 November 2017 at 12:33, York Sun  wrote:
> On 11/23/2017 03:22 AM, Prabhakar Kushwaha wrote:
>> The MAC addresses get fixed in the device tree for "ethernet" nodes
>> is by using trailing number behind "ethernet" found in "/aliases".
>> It may not be necessary for the "ethernet" nodes to be sequential.
>> There can be gaps in between or any ethenet node disabled.
>>
>> Reason for gaps is because the available ethernet port are based on
>> SerDes protocol chosen for the SoC. Usually Linux device tree
>> contains "ethernet" node for all possible ports supported by SoC
>> for e.g. LS1046A. Where based on SerDes protocol some "ethernet"
>> ports are unavailable hence non-sequential.
>>
>> This patch-set provide way to fetch MAC addr sequentially from env
>> variables and also create hole in "ethernet" node (disable) based
>> on SerDes protocol for LS1046ARDB.
>>
>> This patch-set provide a support to fetch MAC addr sequentially
>> from env and apply them to "ethernet" nodes in the order they appear
>> in device tree only if "ethernet" is not "disabled"
>>
>> It also disables "ethernet" nodes in device tree based ethernet port
>> availability  in the selected SerDes protocol.
>> Currently the changes are done foe LS1046A. This has been added as a
>> compile time option for now, to keep backward compatibility.
>>
>> The associated documentation is also updated in the README.
>>
>> Other platforms should also follow same approach.
>>
>> Prabhakar Kushwaha (3):
>>   common: Fix-up MAC addr in dts by fetching env variable serially
>>   arm: Add support of updating dts before fix-up
>>   boards: ls1046ardb: disable unavailable "ethernet" node in dts
>>
>>  README   |  9 +++
>>  arch/arm/lib/bootm-fdt.c | 12 ++
>>  board/freescale/ls1046ardb/eth.c | 51 
>> 
>>  common/fdt_support.c | 25 
>>  include/configs/ls1046ardb.h |  2 ++
>>  include/fdt_support.h|  3 +++
>>  6 files changed, 98 insertions(+), 4 deletions(-)
>>
>
> Simon,
>
> What do you think about this set?
>

I have not seen the patches but the idea seems OK to me.

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

Re: [U-Boot] [RFC PATCH 03/13] arm: move SYS_ARCH_TIMER to KConfig

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> SYS_ARCH_TIMER guards the usage of the ARM Generic Timer (aka arch
> timer) in U-Boot.
> At the moment it is mandatory for ARMv8 and used by two ARMv7 boards.
> Add a proper Kconfig symbol to express this dependency properly,
> allowing certain board configuration to later disable arch timer in case
> there are any problems with it.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/Kconfig | 11 +++
>  arch/arm/cpu/armv8/Makefile  |  2 +-
>  arch/arm/mach-imx/mx7ulp/Kconfig |  1 +
>  include/configs/mx7ulp_evk.h |  1 -
>  include/configs/ti_armv7_keystone2.h |  1 -
>  scripts/config_whitelist.txt |  1 -
>  6 files changed, 13 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] [RFC PATCH 01/13] serial: s5p: rework Samsung UART driver to get rid of uart.h

[Simon Glass]

On 29 November 2017 at 18:24, Andre Przywara  wrote:
> At the moment the serial_s5p driver takes care of both Exynos UARTs
> as well as those from older Samsung SoCs (s3c/s5p series).
> Looking more closely the only difference between those two groups is
> how the fractional baud rate is programmed: via a "divslot" (s3c) or as
> a proper fractional value (Exynos).
> Instead of intricately expressing this via a special header file (which
> is otherwise identical), let's use the blessings of DT to tackle this:
> The S5P series of SoCs use their own compatible string, in line with
> what the official DTs from the Linux kernel do. We then switch between
> divslot and fractional value based on the compatible string used.
> This allows us to get rid of the uart.h header files and make the
> driver more flexible.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/dts/s5pc1xx-goni.dts |  2 +-
>  arch/arm/dts/s5pc1xx-smdkc100.dts |  2 +-
>  arch/arm/mach-exynos/include/mach/uart.h  | 44 --
>  arch/arm/mach-s5pc1xx/include/mach/uart.h | 44 --
>  drivers/serial/serial_s5p.c   | 45 
> +++
>  5 files changed, 42 insertions(+), 95 deletions(-)
>  delete mode 100644 arch/arm/mach-exynos/include/mach/uart.h
>  delete mode 100644 arch/arm/mach-s5pc1xx/include/mach/uart.h
>
> diff --git a/arch/arm/dts/s5pc1xx-goni.dts b/arch/arm/dts/s5pc1xx-goni.dts
> index 182325a091..964c7a6b67 100644
> --- a/arch/arm/dts/s5pc1xx-goni.dts
> +++ b/arch/arm/dts/s5pc1xx-goni.dts
> @@ -28,7 +28,7 @@
> };
>
> serial@e2900800 {
> -   compatible = "samsung,exynos4210-uart";
> +   compatible = "samsung,s5pv210-uart";

Does this match linux?

Apart from that:

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

Re: [U-Boot] U-Boot proper(not SPL) relocate option

[Simon Glass]

Hi Joakim,

On 29 November 2017 at 03:48, Joakim Tjernlund
 wrote:
> On Wed, 2017-11-29 at 19:11 +0900, Masahiro Yamada wrote:
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you recognize the sender and know the 
>> content is safe.
>>
>>
>> Hi Simon,
>>
>>
>> 2017-11-28 2:13 GMT+09:00 Simon Glass :
>> > (Tom - any thoughts about a more expansive cc list on this?)
>> >
>> > Hi Masahiro,
>> >
>> > On 26 November 2017 at 07:16, Masahiro Yamada
>> >  wrote:
>> > > 2017-11-26 20:38 GMT+09:00 Simon Glass :
>> > > > Hi Philipp,
>> > > >
>> > > > On 25 November 2017 at 16:31, Dr. Philipp Tomsich
>> > > >  wrote:
>> > > > > Hi,
>> > > > >
>> > > > > > On 25 Nov 2017, at 23:34, Simon Glass  wrote:
>> > > > > >
>> > > > > > +Tom, Masahiro, Philipp
>> > > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > On 22 November 2017 at 03:27, Wolfgang Denk  wrote:
>> > > > > > > Dear Kever Yang,
>> > > > > > >
>> > > > > > > In message  
>> > > > > > > you wrote:
>> > > > > > > >
>> > > > > > > > I can understand this feature, we always do dram_init_banks() 
>> > > > > > > > first,
>> > > > > > > > then we relocate to 'known' area, then will be no risk to 
>> > > > > > > > access memory.
>> > > > > > > > I believe there must be some historical reason for some kind 
>> > > > > > > > of device,
>> > > > > > > > the relocate feature is a wonderful idea for it.
>> > > > > > >
>> > > > > > > This is actuallyu not so much a feature needed to support some
>> > > > > > > specific device (in this case much simpler approahces would be
>> > > > > > > possible), but to support a whole set of features.  Unfortunately
>> > > > > > > these appear to get forgotten / ignored over time.
>> > > > > > >
>> > > > > > > > many other SoCs should be similar.
>> > > > > > > > - Without relocate we can save many step, some of our customer 
>> > > > > > > > really
>> > > > > > > > care much about the boot time duration.
>> > > > > > > > * no need to relocate everything
>> > > > > > > > * no need to copy all the code
>> > > > > > > > * no need init the driver more than once
>> > > > > > >
>> > > > > > > Please have a look at the README, section "Memory Management".
>> > > > > > > The reloaction is not done to any _fixed_ address, but the 
>> > > > > > > address
>> > > > > > > is actually computed at runtime, depending on a number features
>> > > > > > > enabled (at least this is how it used to be - appearently little 
>> > > > > > > of
>> > > > > > > this is tested on a regular base, so I would not be surprised if
>> > > > > > > things are broken today).
>> > > > > > >
>> > > > > > > The basic idea was to reserve areas of memory at the top of RAM,
>> > > > > > > that would not be initialized / modified by U-Boot and Linux, not
>> > > > > > > even across a reset / warm boot.
>> > > > > > >
>> > > > > > > This was used for exaple for:
>> > > > > > >
>> > > > > > > - pRAM (Protected RAM) which could be used to store all kind of 
>> > > > > > > data
>> > > > > > >  (for example, using a pramfs [Protected and Persistent RAM
>> > > > > > >  Filesystem]) that could be kept across reboots of the OS.
>> > > > > > >
>> > > > > > > - shared frame buffer / video memory. U-Boot and Linux would be 
>> > > > > > > able
>> > > > > > >  to initialize the video memory just once (in U-Boot) and then
>> > > > > > >  share it, maybe even across reboots.  especially, this would 
>> > > > > > > allow
>> > > > > > >  for a very early splash screen that gets passed (flicker free) 
>> > > > > > > to
>> > > > > > >  Linux until some Linux GUI takes over (much more difficult 
>> > > > > > > today).
>> > > > > > >
>> > > > > > > - shared log buffer: U-Boot and Linux used to use the same syslog
>> > > > > > >  buffer mechanism, so you could share it between U-Boot and 
>> > > > > > > Linux.
>> > > > > > >  this allows for example to
>> > > > > > >  * read the Linux kernel panic messages after reset in U-Boot; 
>> > > > > > > this
>> > > > > > >is very useful when you bring up a new system and Linux 
>> > > > > > > crashes
>> > > > > > >before it can display the log buffer on the console
>> > > > > > >  * pass U-Boot POST results on to Linux, so the application code
>> > > > > > >can read and process these
>> > > > > > >  * process the system log of the previous run (especially after a
>> > > > > > >panic) in Lunux after it rebootet.
>> > > > > > >
>> > > > > > > etc.
>> > > > > > >
>> > > > > > > There are a number of such features which require to reserve 
>> > > > > > > room at
>> > > > > > > the top of RAM, the size of which is calculatedat runtime, often
>> > > > > > > depending on user settable environment data.
>> > > > > > >
>> > > > > > > All this 

Re: [U-Boot] [U-Boot, 1/3] rockchip: boot mode: parse adc channel from dts

[Simon Glass]

Hi Philipp,

On 29 November 2017 at 02:53, Dr. Philipp Tomsich
 wrote:
> [Getting Simon's email-address right, helps…]
>
> Simon,
>
> could you comment on this one from a general U-Boot architecture and
> DM-maintainer perspective?
>
> Thanks,
> Philipp.
>
> On 29 Nov 2017, at 10:50, Dr. Philipp Tomsich
>  wrote:
>
>
> On 29 Nov 2017, at 07:34, Andy Yan  > wrote:
>
> Hi Philipp:
>
>
> On 2017年11月28日 21:59, Philipp Tomsich wrote:
>
> +sjg
>
> On Tue, 28 Nov 2017, Andy Yan wrote:
>
> Most the current rockchip based boards use adc channel
> 1 detect the download key, but there are also some
> boards like rv1108 based plaform use adc channel 0.
> So we parse the adc channel from dts if we can get
> it, otherwise we use the channel 1 as default.
>
> Signed-off-by: Andy Yan  >
> Acked-by: Philipp Tomsich  >
>
> ---
>
> arch/arm/mach-rockchip/boot_mode.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/boot_mode.c
> b/arch/arm/mach-rockchip/boot_mode.c
> index 942849f..49dfd39 100644
> --- a/arch/arm/mach-rockchip/boot_mode.c
> +++ b/arch/arm/mach-rockchip/boot_mode.c
> @@ -8,6 +8,9 @@
> #include 
> #include 
> #include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
>
> void set_back_to_bootrom_dnl_flag(void)
> {
> @@ -26,9 +29,19 @@ void set_back_to_bootrom_dnl_flag(void)
>
> __weak int rockchip_dnl_key_pressed(void)
> {
> +const void *blob = gd->fdt_blob;
>unsigned int val;
> +int channel = 1;
> +int node;
> +u32 chns[2];
> +
> +node = fdt_node_offset_by_compatible(blob, 0, "adc-keys");
> +if (node >= 0) {
> +if (!fdtdec_get_int_array(blob, node, "io-channels", chns, 2))
> +channel = chns[1];
> +}
>
>
> The driver for 'adc-keys' should be a driver in drivers/input that can then
> be retrieved via DM and queried using keyboard_getc().
>
>
>Yes, if there is an exiting adc-keys driver, we will use it here with no
> doubts, but there is not now. I just need  to check the button
> down event once, no up or other things needed, so I call the adc api
> directly. I grep all the u-boot project, and found all other boards
> handle this kind of button status check by call device specific api
> directly, rather than use the api from input subsystem. So I think
> this is a acceptable way.
>
>
> Which other boards did you find that used the “adc-keys” node this way?
> My grep shows only a few sunxi DTS referring to it:
> ptomsich@android:~/u-boot-rockchip$ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
> ptomsich@android:~/u-boot-rockchip$ git grep adc-keys
> arch/arm/dts/sun4i-a10.dtsi:compatible =
> "allwinner,sun4i-a10-lradc-keys";
> arch/arm/dts/sun5i-gr8.dtsi:compatible =
> "allwinner,sun4i-a10-lradc-keys";
> arch/arm/dts/sun5i.dtsi:compatible =
> "allwinner,sun4i-a10-lradc-keys";
> arch/arm/dts/sun6i-a31.dtsi:compatible =
> "allwinner,sun4i-a10-lradc-keys";
> arch/arm/dts/sun7i-a20.dtsi:compatible =
> "allwinner,sun4i-a10-lradc-keys";
> arch/arm/dts/sun8i-a23-a33.dtsi:compatible =
> "allwinner,sun4i-a10-lradc-keys";
>
>
>  Would you please consider taking this patch if there is no other
> problems. And when there is a adc-keys driver in the future, I can move
> it to input based api, or I will write a adc-keys driver when my workloads
> is not so heavy as now.
>
>
> The problem is that if we go ahead with this as-is, there never be a driver
> for the "adc-keys” created ...
> Let’s see what for Simon’s input is, before we make a final decision.

I agree that we should do this with a generic driver if that is what
Linux does. We should try to avoid creating migration work for the
next person.

It does not seem that hard to do?

>
>
>
> -if (adc_channel_single_shot("saradc", 1, )) {
> +if (adc_channel_single_shot("saradc", channel, )) {
>pr_err("%s: adc_channel_single_shot fail!\n", __func__);
>return false;
>}


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

Re: [U-Boot] [RFC PATCH 02/13] serial: S5P/Samsung: refactor and Kconfig-ize UART selection

[Simon Glass]

On 29 November 2017 at 18:25, Andre Przywara  wrote:
> Currently the UART used by some Samsung SoCs is selected by the
> generic CONFIG_S5P define. This makes it hard to re-use that UART
> without pulling in the whole of the S5P code. Also the Exynos SoCs
> use this driver, which is in fact a generic Samsung UART driver.
>
> So create a new Kconfig symbol CONFIG_SAMSUNG_UART to reflect this and
> change the existing boards to use this symbol.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/Kconfig  | 1 +
>  arch/arm/mach-s5pc1xx/Kconfig | 2 ++
>  drivers/serial/Kconfig| 6 ++
>  drivers/serial/Makefile   | 2 +-
>  4 files changed, 10 insertions(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH] dm: blk: Use uclass_find_first/next_device() in blk_first/next_device()

[Simon Glass]

On 29 November 2017 at 08:46, Stefan Roese  wrote:
> This patch changes the calls to uclass_first/next_device() in blk_first/
> next_device() to use uclass_find_first/next_device() instead. These functions
> don't prepare the devices, which is correct in this case.
>
> With this patch applied, the "usb storage" command now works again as
> expected:
>
> => usb storage
>   Device 0: Vendor: SanDisk Rev: 1.00 Prod: Ultra
>   Type: Removable Hard Disk
>   Capacity: 58656.0 MB = 57.2 GB (120127488 x 512)
>
> Without this patch, it used to generate this buggy output:
>
> => usb storage
> Card did not respond to voltage select!
> mmc_init: -95, time 26
> No storage devices, perhaps not 'usb start'ed..?
>
> Signed-off-by: Stefan Roese 
> Suggested-by: Simon Glass 
> Cc: Simon Glass 
> Cc: Bin Meng 
> ---
>  drivers/block/blk-uclass.c | 7 ---
>  1 file changed, 4 insertions(+), 3 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 4/5] treewide: convert assert() to BUG_ON()

[Simon Glass]

On 29 November 2017 at 07:17, Masahiro Yamada
 wrote:
> Hi Simon,
>
>
> 2017-11-29 22:08 GMT+09:00 Simon Glass :
>> Hi Masahiro,
>>
>> On 28 November 2017 at 05:23, Masahiro Yamada
>>  wrote:
>>> We do not need multiple ways to do the same thing.  Instead of
>>> assert(), use BUG_ON() from Linux.  The logic is opposite, but
>>> Coccinelle is of great help for such a conversion.  We could
>>> simply convert assert(x) to BUG_ON(!x) for all expressions "x",
>>> but I did a bit better job by converting assert(a == b) to
>>> BUG_ON(a != b), etc.
>>
>> My reading of BUG_ON() is that it does not compile to nothing when
>> DEBUG is not set, unlike assert(). So they do not seem to be
>> equivalent.
>>
>
>
> Tom suggested to add an option to make BUG_ON() to nothing by default:
> https://patchwork.ozlabs.org/cover/842165/
>
> With the option, they will be equivalent.

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

Re: [U-Boot] [PATCH v4 06/10] mmc: don't use malloc_cache_aligned()

[Simon Glass]

On 29 November 2017 at 07:29, Jean-Jacques Hiblot  wrote:
> Not using this function reduces the size of the binary. It's replaces by
> a standard malloc() and the alignment requirement is handled by an
> intermediate buffer on the stack.
>
> Also make sure that the allocated buffer is freed in case of error.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)

Somewhat unsure of this one but it looks right to me.

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

Re: [U-Boot] [PATCH v4 08/10] mmc: make UHS and HS200 optional

[Simon Glass]

Hi Jean-Jacques,

On 29 November 2017 at 07:29, Jean-Jacques Hiblot  wrote:
> Supporting USH and HS200 increases the code size as it brings in IO voltage
> control, tuning and fatter data structures.
> Use Kconfig configuration to select which of those features should be
> built in.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/Kconfig  | 46 +++
>  drivers/mmc/mmc-uclass.c |  4 +++
>  drivers/mmc/mmc.c| 63 
> +++-
>  include/mmc.h| 27 ++---
>  4 files changed, 135 insertions(+), 5 deletions(-)

A few things:

- Can these default to on? I think going fast is best, and reducing
functionality can be an option
- Can you use if (IS_ENABLED) instead of #if within functions?

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

Re: [U-Boot] [PATCH v4 01/10] mmc: dump card and host capabilities if debug is enabled

[Simon Glass]

On 29 November 2017 at 07:29, Jean-Jacques Hiblot  wrote:
> This is a useful information while debugging the initialization process or
> performance issues.
> Also dump this information with the other mmc info if the verbose option
> is selected
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>
> no changes since v3
>
>  cmd/mmc.c | 4 
>  drivers/mmc/mmc.c | 9 +
>  2 files changed, 13 insertions(+)

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

Re: [U-Boot] [PATCH v4 05/10] mmc: fix for old MMCs (below version 4)

[Simon Glass]

On 29 November 2017 at 07:29, Jean-Jacques Hiblot  wrote:
> The ext_csd is allocated only for MMC above version 4. The compare will
> crash or fail for older MMCs.
>
> Signed-off-by: Jean-Jacques Hiblot 
> ---
>  drivers/mmc/mmc.c | 3 +++
>  1 file changed, 3 insertions(+)

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

Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

[Simon Glass]

Hi Michal,

On 29 November 2017 at 03:00, Michal Simek  wrote:
> On 29.11.2017 06:20, Goldschmidt Simon wrote:
>> On 28.11.2017 14:46, Michal Simek wrote:
>>> On 28.11.2017 10:08, Goldschmidt Simon wrote:
 Simon Goldschmidt wrote:
> Hi Simon,
>
> Simon Glass wrote:
>> I see that, although it is adding to the fpga header so presumably
>> making it harder for someone to move this over.
>
> Yes, I'm not happy with changing the header and even xilinx C file to
> add functionality for altera. However, this is due to the fact that a
> core file still depends on an dogs implementation, which I removed.

 This should have meant "on an fpga implementation". No dogs or offences 
 here.
 My mobile phone does not know the word "fpga", obviously.

>
>> Does anyone on cc know the plan fr conversion of FPGA to driver model?
>> It does not look too tricky from a quick look at the header file.
>
> It does not look tricky, indeed. However, we should try to match this
> to the Linux implementation regarding what's needed in the device
> tree. And I just don't know that part, yet ;-)
>>>
>>> I have not a problem to enable others fpgas to use this functionality.
>>> And transition should be done for all these drivers when someone has a time 
>>> to do
>>> it.
>>
>> Great, thanks! So via which tree would this be included?
>
> Origin code was applied via my tree. It means it shouldn't be an issue
> to do that again.
> Anyway I have tested it on zynqmp and this feature is still working
> without any issue when this patch is applied.
>
> sjg: Do you see any other issue with this patch?

No other issues.

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

Re: [U-Boot] [RESEND PATCH 2/2] net: designware: add clock support

[Simon Glass]

On 29 November 2017 at 01:06,   wrote:
> From: Patrice Chotard 
>
> This implementation manages several clocks, disable and
> free all of them in case of error during probe and in remove
> callback.
>
> Signed-off-by: Patrice Chotard 
> ---
>  drivers/net/designware.c | 43 +++
>  drivers/net/designware.h |  4 
>  2 files changed, 47 insertions(+)

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

Re: [U-Boot] [RESEND PATCH 1/2] dm: core: add missing dev_count_phandle_with_args()

[Simon Glass]

Hi Patrice,

On 29 November 2017 at 01:06,   wrote:
> From: Patrice Chotard 
>
> Add missing dev_count_phandle_with_args() to avoid
> compilation issue.
>
> Signed-off-by: Patrice Chotard 
> ---
>  drivers/core/read.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/core/read.c b/drivers/core/read.c
> index 5d440ce..f346cc1 100644
> --- a/drivers/core/read.c
> +++ b/drivers/core/read.c
> @@ -103,6 +103,13 @@ int dev_read_phandle_with_args(struct udevice *dev, 
> const char *list_name,
>   out_args);
>  }
>
> +int dev_count_phandle_with_args(struct udevice *dev, const char *list_name,
> +   const char *cells_name)

Is there a declaration of this in the header file?

> +{
> +   return ofnode_count_phandle_with_args(dev_ofnode(dev), list_name,
> + cells_name);
> +}
> +
>  int dev_read_addr_cells(struct udevice *dev)
>  {
> return ofnode_read_addr_cells(dev_ofnode(dev));
> --
> 1.9.1
>

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

Re: [U-Boot] [PATCH] drivers: firmware: psci: use pr_* log functions instead of printf()

[Simon Glass]

On 28 November 2017 at 23:04, Masahiro Yamada
 wrote:
> In Linux, the warning messages are printed out by pr_warn().
>
> We can use Linux-like log functions in tree-wide.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/firmware/psci.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

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

Re: [U-Boot] [PULL] Please pull u-boot-rockchip/master

[Tom Rini]

On Sat, Dec 02, 2017 at 12:32:00AM +0100, Dr. Philipp Tomsich wrote:

> Here’s v2 of the pull-request with the issues fixed.
> 
> Looks like I’ll need to become even more restrictive on the quality of vendor 
> patches.
> Sorry for causing extra work.
> 
> Regards,
> Philipp.
> 
> 
> The following changes since commit 9804d88630cdb22f5f0ace05ac05942928410fd9:
> 
>   Merge branch 'rmobile-mx' of git://git.denx.de/u-boot-sh (2017-11-30 
> 10:39:04 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to 4fc495e9e2e497afee383294a6ee9212e9a8bd73:
> 
>   rockchip: clk: rk3128: fix DCLK_VOP_DIV_CON_MASK (2017-12-02 00:27:42 +0100)
> 

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] [PULL] Please pull u-boot-rockchip/master

[Dr. Philipp Tomsich]

Here’s v2 of the pull-request with the issues fixed.

Looks like I’ll need to become even more restrictive on the quality of vendor 
patches.
Sorry for causing extra work.

Regards,
Philipp.


The following changes since commit 9804d88630cdb22f5f0ace05ac05942928410fd9:

  Merge branch 'rmobile-mx' of git://git.denx.de/u-boot-sh (2017-11-30 10:39:04 
-0500)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git master

for you to fetch changes up to 4fc495e9e2e497afee383294a6ee9212e9a8bd73:

  rockchip: clk: rk3128: fix DCLK_VOP_DIV_CON_MASK (2017-12-02 00:27:42 +0100)


Andy Yan (1):
  rockchip: board: evb_rv1108: update README

Kever Yang (10):
  rockchip: rk3128: add device tree file
  rockchip: rk3128: add soc basic support
  rockchip: rk3128: add clock driver
  rockchip: rk3128: add pinctrl driver
  rockchip: rk3128: add evb-rk3128 support
  rockchip: rk3128: add defconfig for evb-rk3128
  rockchip: rk3128: add sdram driver
  rockchip: rk3036: fix pll config for correct frequency
  rockchip: rk3036: update clock driver for ddr
  rockchip: rk3036: sdram: correct setting for pll integer mode

Philipp Tomsich (8):
  MAINTAINERS: update maintained files for Rockchip
  rockchip: board: evb-rk3128: add empty Makefile
  rockchip: rk3399-puma: implement usb_hub_reset_devices for puma-rk3399
  rockchip: dts: rk3399-puma: add a 'tsd, usb-port-power' stringlist for 
USB1
  rockchip: rk3399-puma: add code to allow forcing a power-on reset
  rockchip: dts: rk3399-puma: add /config/sysreset-gpio property
  rockchip: clk: rk3128: fix NANDC_PLL_SEL_MASK
  rockchip: clk: rk3128: fix DCLK_VOP_DIV_CON_MASK

 MAINTAINERS   |  12 ++
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/rk3128-evb.dts   |  95 +
 arch/arm/dts/rk3128.dtsi  | 804 
+
 arch/arm/dts/rk3399-puma.dtsi |   6 +
 arch/arm/include/asm/arch-rockchip/cru_rk3128.h   | 212 

 arch/arm/include/asm/arch-rockchip/grf_rk3128.h   | 551 

 arch/arm/mach-rockchip/Kconfig|  10 ++
 arch/arm/mach-rockchip/Makefile   |   2 +
 arch/arm/mach-rockchip/rk3036/sdram_rk3036.c  |  22 ++-
 arch/arm/mach-rockchip/rk3128-board.c | 127 +
 arch/arm/mach-rockchip/rk3128/Kconfig |  24 
 arch/arm/mach-rockchip/rk3128/Makefile|   9 ++
 arch/arm/mach-rockchip/rk3128/clk_rk3128.c|  32 +
 arch/arm/mach-rockchip/rk3128/rk3128.c|  12 ++
 arch/arm/mach-rockchip/rk3128/syscon_rk3128.c |  21 +++
 board/rockchip/evb_rk3128/Kconfig |  15 ++
 board/rockchip/evb_rk3128/MAINTAINERS |   6 +
 board/rockchip/evb_rk3128/Makefile|   5 +
 board/rockchip/evb_rk3128/evk-rk3128.c|   0
 board/rockchip/evb_rv1108/README  |   5 +-
 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 114 ++-
 configs/evb-rk3128_defconfig  |  56 
 doc/device-tree-bindings/config.txt   |   6 +
 drivers/clk/rockchip/Makefile |   3 +-
 drivers/clk/rockchip/clk_rk3128.c | 596 
++
 drivers/pinctrl/Kconfig   |  10 ++
 drivers/pinctrl/rockchip/Makefile |   4 +-
 drivers/pinctrl/rockchip/pinctrl_rk3128.c | 187 
+
 drivers/ram/rockchip/Makefile |   1 +
 drivers/ram/rockchip/sdram_rk3128.c   |  59 
 include/configs/evb_rk3128.h  |  15 ++
 include/configs/rk3128_common.h   |  70 ++
 include/dt-bindings/clock/rk3128-cru.h| 190 
+
 34 files changed, 3263 insertions(+), 19 deletions(-)
 create mode 100644 arch/arm/dts/rk3128-evb.dts
 create mode 100644 arch/arm/dts/rk3128.dtsi
 create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3128.h
 create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3128.h
 create mode 100644 arch/arm/mach-rockchip/rk3128-board.c
 create mode 100644 arch/arm/mach-rockchip/rk3128/Kconfig
 create mode 100644 arch/arm/mach-rockchip/rk3128/Makefile
 create mode 100644 arch/arm/mach-rockchip/rk3128/clk_rk3128.c
 create mode 100644 arch/arm/mach-rockchip/rk3128/rk3128.c
 create mode 100644 arch/arm/mach-rockchip/rk3128/syscon_rk3128.c
 create mode 100644 board/rockchip/evb_rk3128/Kconfig
 create mode 100644 board/rockchip/evb_rk3128/MAINTAINERS
 create mode 100644 

Re: [U-Boot] [PATCH v4] power: pmic/regulator: Add basic support for TPS65910

[Simon Glass]

On 30 November 2017 at 05:52, Felix Brack  wrote:
> Texas Instrument's TPS65910 PMIC contains 3 buck DC-DC converts, one
> boost DC-DC converter and 8 LDOs. This patch implements driver model
> support for the TPS65910 PMIC and its regulators making the get/set
> API for regulator value/enable available.
> This patch depends on the patch "am33xx: Add a function to query MPU
> voltage in uV" to build correctly. For boards relying on the DT
> include file tps65910.dtsi the v3 patch "power: extend prefix match
> to regulator-name property" and an appropriate regulator naming is
> also required.
>
> Signed-off-by: Felix Brack 
> ---
>
> Changes in v4:
> - remove unnecessary test of unit number since it can't be negative
>
> Changes in v3:
> - use dev_get_driver_data() instead of dev->driver_data
> - use dev_get_platdata() instead of dev->platdata
> - store unit address in platdata during ofdata_to_platdata() instead
>   of queering it multiple times by dev_get_driver_data()
> - use pmic_reg_read() instead of pmic_read() wherever possible
> - eliminate the use small data types like u8 if not required
>
> Changes in v2:
> - move information about regulator supply power from the PMIC to the
>   regulator driver which greatly simplifies and streamlines the code
>   of both drivers (thanks Simon!)
> - use dev_get_uclass_platdata() to get the regulator constraints
>   instead of reinventing the wheel and reading them from the DT
> - make pmic_tps65910_write() and pmic_tps65910_read() return the
>   results of the i2c operation instead of obscuring it
> - generally review and eventually fix return values
> - modify regulator description in Kconfig
> - get_ctrl_reg_from_unit_addr() uses a lookup array instead of a
>   switch statement
> - rename some local functions to prevent confusion with generic
>   functions
> - reformatting code for better readability
>
>  drivers/power/pmic/Kconfig   |   8 +
>  drivers/power/pmic/Makefile  |   1 +
>  drivers/power/pmic/pmic_tps65910_dm.c|  98 ++
>  drivers/power/regulator/Kconfig  |   8 +
>  drivers/power/regulator/Makefile |   1 +
>  drivers/power/regulator/tps65910_regulator.c | 459 
> +++
>  include/power/tps65910_pmic.h| 130 
>  7 files changed, 705 insertions(+)
>  create mode 100644 drivers/power/pmic/pmic_tps65910_dm.c
>  create mode 100644 drivers/power/regulator/tps65910_regulator.c
>  create mode 100644 include/power/tps65910_pmic.h

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

Re: [U-Boot] [PATCH] binman: do not add binary files to git

[Simon Glass]

Hi Masahiro,

On 29 November 2017 at 07:14, Masahiro Yamada
 wrote:
>
> Hi Simon,
>
> 2017-11-29 22:08 GMT+09:00 Simon Glass :
> > Hi Masahiro,
> >
> > On 26 November 2017 at 18:11, Masahiro Yamada
> >  wrote:
> >>
> >> Signed-off-by: Masahiro Yamada 
> >
> > Commit message?
> >
> > This breaks the binman tests.
> >
> > With the Makefile that is now present in tools/binman/test we could
> > perhaps generate these files on the fly?
>
>
> I saw the Makefile.
> I thought it was invoked somewhere.

Unfortunately not yet, but it is a start. Originally I was worried
that we might not be able to generate a suitable ELF file reliably on
all platforms, but perhaps I am being too paranoid.

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

Re: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

[Tom Rini]

On Fri, Dec 01, 2017 at 10:07:54AM -0700, Stephen Warren wrote:
> On 12/01/2017 08:19 AM, Michal Simek wrote:
> >Hi,
> >
> >On 1.12.2017 16:06, Heinrich Schuchardt wrote:
> >>
> >>
> >>On 12/01/2017 03:46 PM, Michal Simek wrote:
> >>>Qemu for arm32/arm64 has a problem with time setup.
> >>
> >>Wouldn't it be preferable to fix the root cause?
> >
> >Definitely that would be the best and IIRC I have tried to convince our
> >qemu guy to do that but they have never done that.
> 
> What is the exact failure condition? Is it simply that the test is still
> slightly too strict about which delays it accepts, or is sleep outright
> broken?
> 
> You can use command-line option -k to avoid some tests. For example "-k not
> sleep". That way, we don't have to hard-code the dependency into the test
> source. Depending on the root cause (issue in U-Boot, or issue in just your
> local version of qemu, or something that will never work) this might be
> better?

Even with the most recent relaxing of the sleep test requirements, I can
still (depending on overall system load) have 'sleep' take too long, on
QEMU.  I think it might have been half a second slow, but I don't have
the log handy anymore.  Both locally and in travis we -k not sleep all
of the qemu instances.

-- 
Tom


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

Re: [U-Boot] [PULL] Please pull u-boot-rockchip/master

[Tom Rini]

On Fri, Dec 01, 2017 at 07:00:36PM +0100, Dr. Philipp Tomsich wrote:

> Tom,
> 
> Another set of changes on u-boot-rockchip is ready for your tree.
> This includes support for the RK3128, documentation updates and convenience 
> changes for some of our boards.
> 
> Thanks,
> Philipp.
> 
> 
> The following changes since commit 9804d88630cdb22f5f0ace05ac05942928410fd9:
> 
>   Merge branch 'rmobile-mx' of git://git.denx.de/u-boot-sh (2017-11-30 
> 10:39:04 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-rockchip.git master
> 
> for you to fetch changes up to 5f104178bf713615dc404fdfcf0fb53d89c66a07:
> 
>   rockchip: dts: rk3399-puma: add /config/sysreset-gpio property (2017-11-30 
> 22:59:54 +0100)
> 

NAK:
+(evb-rk3128)  writel(((clr) | (set)) << 16 | (set), addr)
+(evb-rk3128) ^
+(evb-rk3128) ../drivers/clk/rockchip/clk_rk3128.c:234:2: note: in expansion of 
macro ?rk_clrsetreg?
+(evb-rk3128)   rk_clrsetreg(>cru_clksel_con[2],
+(evb-rk3128)   ^~~~
+(evb-rk3128) ../drivers/clk/rockchip/clk_rk3128.c:445:3: note: in expansion of 
macro ?rk_clrsetreg?
+(evb-rk3128)rk_clrsetreg(>cru_clksel_con[27],
+(evb-rk3128)^~~~
w+(evb-rk3128) ../drivers/clk/rockchip/clk_rk3128.c: In function ?rkclk_init?:
w+(evb-rk3128) include/asm/arch/hardware.h:17:28: warning: result of ?122624 << 
16? requires 34 bits to represent, but ?int? only has 32 bits 
[-Wshift-overflow=]
w+(evb-rk3128) ../drivers/clk/rockchip/clk_rk3128.c: In function 
?rk3128_vop_set_clk?:
w+(evb-rk3128) include/asm/arch/hardware.h:17:28: warning: result of ?1048321 
<< 16? requires 37 bits to represent, but ?int? only has 32 bits 
[-Wshift-overflow=]

Please fix, 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] arm: arm64: only use general regs

[Alexander Graf]

On 28.11.17 03:09, Peng Fan wrote:
> When compiling with android toolchain, there is an instruction
> "str q0, [x8],#16", but x8 is not 16bytes aligned,
> this instruction will trigger sync abort.
> 
> So, following Linux kernel, only use general regs for arm64.
> If not, compiler may use simd registers Q[x]. We need to avoid
> using simd registers in U-Boot, because load/store Q[x] has
> restriction that 128bits aligned when str/ldr.
> 
> Signed-off-by: Peng Fan 

The compiler should only output 16-byte-alignemnt-requiring instructions
when it can safely assume that the variable in question is 16 byte aligned.

Where did x8 come from? That was probably just an unsafe cast?

For reference, I ran into something similar recently on 32bit ARM:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82445

And this indeed turned out to be a compiler bug.

FWIW the main reason Linux doesn't want to use FPU registers in kernel
space is simply that it doesn't want to bother saving/restoring them on
syscalls or interrupts. But I don't quite see why we would care in U-Boot.


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

Re: [U-Boot] [PATCH] efi_loader: add missing breaks

[Alexander Graf]

On 30.11.17 15:21, Heinrich Schuchardt wrote:
> 
> 
> On 11/30/2017 03:02 PM, Rob Clark wrote:
>> Otherwise with GUID partition types you would end up with things like:
>>
>>   
>> .../HD(Part0,Sig6252c819-4624-4995-8d16-abc9cd5d4130)/HD(Part0,MBRType=02,SigType=02)
>>
>>
>> Signed-off-by: Rob Clark 
>> ---
>> Reported by 'ykaukab' on IRC.
>>
>> Not sure if someone already sent a similar patch.
>>
>>   lib/efi_loader/efi_device_path_to_text.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/lib/efi_loader/efi_device_path_to_text.c
>> b/lib/efi_loader/efi_device_path_to_text.c
>> index 62771338f0..3b703301ff 100644
>> --- a/lib/efi_loader/efi_device_path_to_text.c
>> +++ b/lib/efi_loader/efi_device_path_to_text.c
>> @@ -135,10 +135,12 @@ static char *dp_media(char *s, struct
>> efi_device_path *dp)
>>   case SIG_TYPE_GUID:
>>   s += sprintf(s, "/HD(Part%d,Sig%pUl)",
> 
> This is not the format defined in UEFI Spec 2.7:
> 
> HD(Partition, Type, Signature, Start, Size)
> HD(Partition, Type, Signature) (Display only)
> 
> We should output something like:
> /HD(1,MBR,0xA0021243,0x800,0x2EE00)
> 
>>    hddp->partition_number, sig);
>> +    break;
>>   default:
>>   s += sprintf(s, "/HD(Part%d,MBRType=%02x,SigType=%02x)",
>>    hddp->partition_number, hddp->partmap_type,
>>    hddp->signature_type);
> 
> See above.
> 
>> +    break;
> 
> This line is superfluous at the end of a switch block.

I actually like the symmetry of a break at the end of default (or
whatever the last switch case is).

> 
> Could you, please, rebase your patch on
> [PATCH v3 04/18] efi_loader: fix efi_convert_device_node_to_text
> https://lists.denx.de/pipermail/u-boot/2017-November/312523.html

I've just manually fixed it up and applied it now.


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

[U-Boot] [PATCH] efi_loader helloworld.efi: Fix building with -Os

[Alexander Graf]

Depending on your compiler, when compiling the hello world efi binary
with -Os, gcc might think it's a smart idea to replace common patterns
such as memory copies with explicit calls to memcpy().

While that sounds great at first, we don't have any memcpy() available
in our helloworld build target. So let's indicate to gcc that we really
do want to have the code be built as freestanding.

Fixes: bbf75dd9 ("efi_loader: output load options in helloworld")
Signed-off-by: Alexander Graf 
---
 lib/efi_loader/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 83d879b686..2722265ee3 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -7,8 +7,8 @@
 # This file only gets included with CONFIG_EFI_LOADER set, so all
 # object inclusion implicitly depends on it
 
-CFLAGS_helloworld.o := $(CFLAGS_EFI)
-CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI)
+CFLAGS_helloworld.o := $(CFLAGS_EFI) -Os -ffreestanding
+CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI) -Os
 
 ifneq ($(CONFIG_CMD_BOOTEFI_HELLO_COMPILE),)
 always += helloworld.efi
-- 
2.12.3

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

Re: [U-Boot] [PATCH 00/23] imx: add i.MX8M support and i.MX8MQ EVK

[Fabio Estevam]

Hi Peng,

On Thu, Nov 30, 2017 at 12:53 AM, Peng Fan  wrote:

>> I don't see a README in here, I'm wondering what the details/requirements
>> are around ARM Trusted Firmware and the build process, for this platform does
>> it use the open ARM ATF, or is it similar to other platforms that early boot 
>> is
>> proprietary and u-boot is just chain loaded? Something like the sunxi 64 bit
>> readme [1] would be useful.
>
> We are using ATF and use a dedicated package tool to generate the final image.
>
> Then the boot flow is SPL->ATF/TEE->U-Boot->Kernel. I do not have much time
> to write that down now. You may get a very good user guide from NXP sw 
> release,
> if you want to boot your board or else.

I agree with Peter that a README file is really important for this series.

Without it we can't really test it on the real hardware.

My colleague Diego tried to test it and was not able to boot it, so
please add a README file on your v2.

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

Re: [U-Boot] [PATCH 02/23] imx: mx8m: add register definition header file

[Fabio Estevam]

Forgot to add Tom.

On Fri, Dec 1, 2017 at 6:45 PM, Fabio Estevam  wrote:
> Hi Stefano,
>
> +Tom
>
> On Wed, Nov 29, 2017 at 8:06 AM, Stefano Babic  wrote:
>
>> Right. There were long discussions in the ML and it was decided to
>> diverge from kernel and use structures in U-Boot. I do not want to
>> restart that painly discussion...:-)
>
> In this thread I got the impression that Tom was open to change such
> requirement:
>
> https://marc.info/?l=u-boot=142609602127309=2
>
> I agree it can be painful for submitters to convert code which uses
> base + offset accesses into structs.
>
> Regards,
>
> Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 02/23] imx: mx8m: add register definition header file

[Fabio Estevam]

Hi Stefano,

+Tom

On Wed, Nov 29, 2017 at 8:06 AM, Stefano Babic  wrote:

> Right. There were long discussions in the ML and it was decided to
> diverge from kernel and use structures in U-Boot. I do not want to
> restart that painly discussion...:-)

In this thread I got the impression that Tom was open to change such
requirement:

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

I agree it can be painful for submitters to convert code which uses
base + offset accesses into structs.

Regards,

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

Re: [U-Boot] [PATCH] imx: Unify CONFIG_BOOTDELAY

[Fabio Estevam]

Hi Stefano,

On Mon, Nov 20, 2017 at 11:54 AM, Fabio Estevam  wrote:
> In order to provide a consistent user experience for imx board users,
> remove the custom CONFIG_BOOTDELAY values from defconfig files, so that
> all boards can use the default two second delay.
>
> Signed-off-by: Fabio Estevam 

Are you happy with this one?

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

Re: [U-Boot] Should we reorganise arch/arm/dts into arch/arm/dts/?

[Tom Rini]

On Fri, Dec 01, 2017 at 09:00:05PM +0100, Dr. Philipp Tomsich wrote:
> Tom,
> 
> As one of my colleagues noticed, the list of files in arch/arm/dts
> grows with every release.
> 
> How about splitting this into subdirectories for each SOC vendor (e.g.
> arch/arm/dts//) to reduce the clutter?
> If this sounds like a good idea, let me know and I’ll start
> rearranging the rockchip-related files.

I'm OK with a re-org to match how arch/arm64/boot/dts is today and how
arch/arm/boot/dts is moving to, but I want to keep them location-wise
in-sync.

-- 
Tom


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

Re: [U-Boot] [PATCH 4/4] ARM: imx: cm_fx6: remove esdhc init code from board file

[Fabio Estevam]

On Thu, Nov 30, 2017 at 7:38 PM,   wrote:
> From: Christopher Spinrath 
>
> Commit 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> enabled driver model support for MMC. Remove the old mmc init code, which
> is no longer used, from the board file.
>
> Signed-off-by: Christopher Spinrath 

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

Re: [U-Boot] [PATCH 3/4] ARM: imx: cm_fx6: remove sata init code from board file

[Fabio Estevam]

On Thu, Nov 30, 2017 at 7:38 PM,   wrote:
> From: Christopher Spinrath 
>
> Commit 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> enabled driver model support for AHCI. Remove the old, now unused, sata
> init code from the board file.
>
> Signed-off-by: Christopher Spinrath 

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

Re: [U-Boot] [PATCH 2/4] ARM: imx: cm_fx6: defconfig: enable CONFIG_DM_KEYBOARD

[Fabio Estevam]

On Thu, Nov 30, 2017 at 7:38 PM,   wrote:
> From: Christopher Spinrath 
>
> Commit 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> enabled driver model support for USB. But it missed to enable driver
> model support for keyboards. As a result, USB keyboards do no longer
> work.
>
> Fix this by enabling driver model support for keyboards.
>
> Fixes: 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> Signed-off-by: Christopher Spinrath 

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

Re: [U-Boot] [PATCH 1/4] ARM: imx: cm-fx6: reinstate USB support by syncing the devicetree with Linux

[Fabio Estevam]

On Thu, Nov 30, 2017 at 7:38 PM,   wrote:
> From: Christopher Spinrath 
>
> Commit 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> enabled driver model support for USB, thereby effectively removing USB
> support because the cm_fx6 devicetree in the U-Boot does *not* enable the
> USB nodes.
>
> Reinstate the USB support by syncing the devicetree with Linux whose
> devicetree enables the USB nodes properly.
>
> More precisely, use the devicetree found in Linux v4.15-rc1 with the
> following two changes:
>   1) Remove the audio mux; the required dt-bindings header is not
>  present in the U-Boot.
>   2) Keep the usdhc3 MMC controller node currently present in the
>  U-Boot's devicetree to retain the ability to boot from MMC.
>
> Fixes: 5248930ebf48 ("dm: imx: cm_fx6: Enable more driver model support")
> Signed-off-by: Christopher Spinrath 

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

[U-Boot] Should we reorganise arch/arm/dts into arch/arm/dts/?

[Dr. Philipp Tomsich]

Tom,

As one of my colleagues noticed, the list of files in arch/arm/dts grows with 
every release.

How about splitting this into subdirectories for each SOC vendor (e.g. 
arch/arm/dts//) to reduce the clutter?
If this sounds like a good idea, let me know and I’ll start rearranging the 
rockchip-related files.

Regards,
Philipp.

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

Re: [U-Boot] Fwd: Errored: agraf/u-boot#91 (efi-next - c457420)

[Heinrich Schuchardt]

Hello Alex,

bisection shows this is the problematic patch:

efi_loader: output load options in helloworld
https://github.com/agraf/u-boot/commit/bbf75dd9345d0b1a7ec7a50016547eb7c759b7af
https://travis-ci.org/xypron2/u-boot/builds/310193906

The preceding patch does not have an error on vexpress_ca15_tc2
efi_selftest: add missing line feed
https://github.com/agraf/u-boot/commit/c51e7df941c9d4a75d25505a9b0435f543edcf34
https://travis-ci.org/xypron2/u-boot/builds/310188175


Best regards

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

[U-Boot] [PULL] Please pull u-boot-rockchip/master

[Dr. Philipp Tomsich]

Tom,

Another set of changes on u-boot-rockchip is ready for your tree.
This includes support for the RK3128, documentation updates and convenience 
changes for some of our boards.

Thanks,
Philipp.


The following changes since commit 9804d88630cdb22f5f0ace05ac05942928410fd9:

  Merge branch 'rmobile-mx' of git://git.denx.de/u-boot-sh (2017-11-30 10:39:04 
-0500)

are available in the git repository at:

  git://git.denx.de/u-boot-rockchip.git master

for you to fetch changes up to 5f104178bf713615dc404fdfcf0fb53d89c66a07:

  rockchip: dts: rk3399-puma: add /config/sysreset-gpio property (2017-11-30 
22:59:54 +0100)


Andy Yan (1):
  rockchip: board: evb_rv1108: update README

Kever Yang (10):
  rockchip: rk3128: add device tree file
  rockchip: rk3128: add soc basic support
  rockchip: rk3128: add clock driver
  rockchip: rk3128: add pinctrl driver
  rockchip: rk3128: add evb-rk3128 support
  rockchip: rk3128: add defconfig for evb-rk3128
  rockchip: rk3128: add sdram driver
  rockchip: rk3036: fix pll config for correct frequency
  rockchip: rk3036: update clock driver for ddr
  rockchip: rk3036: sdram: correct setting for pll integer mode

Philipp Tomsich (6):
  MAINTAINERS: update maintained files for Rockchip
  rockchip: board: evb-rk3128: add empty Makefile
  rockchip: rk3399-puma: implement usb_hub_reset_devices for puma-rk3399
  rockchip: dts: rk3399-puma: add a 'tsd, usb-port-power' stringlist for 
USB1
  rockchip: rk3399-puma: add code to allow forcing a power-on reset
  rockchip: dts: rk3399-puma: add /config/sysreset-gpio property

 MAINTAINERS   |  12 ++
 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/rk3128-evb.dts   |  95 +
 arch/arm/dts/rk3128.dtsi  | 804 
+
 arch/arm/dts/rk3399-puma.dtsi |   6 +
 arch/arm/include/asm/arch-rockchip/cru_rk3128.h   | 212 

 arch/arm/include/asm/arch-rockchip/grf_rk3128.h   | 551 

 arch/arm/mach-rockchip/Kconfig|  10 ++
 arch/arm/mach-rockchip/Makefile   |   2 +
 arch/arm/mach-rockchip/rk3036/sdram_rk3036.c  |  22 ++-
 arch/arm/mach-rockchip/rk3128-board.c | 127 +
 arch/arm/mach-rockchip/rk3128/Kconfig |  24 
 arch/arm/mach-rockchip/rk3128/Makefile|   9 ++
 arch/arm/mach-rockchip/rk3128/clk_rk3128.c|  32 +
 arch/arm/mach-rockchip/rk3128/rk3128.c|  12 ++
 arch/arm/mach-rockchip/rk3128/syscon_rk3128.c |  21 +++
 board/rockchip/evb_rk3128/Kconfig |  15 ++
 board/rockchip/evb_rk3128/MAINTAINERS |   6 +
 board/rockchip/evb_rk3128/Makefile|   5 +
 board/rockchip/evb_rk3128/evk-rk3128.c|   0
 board/rockchip/evb_rv1108/README  |   5 +-
 board/theobroma-systems/puma_rk3399/puma-rk3399.c | 114 ++-
 configs/evb-rk3128_defconfig  |  56 
 doc/device-tree-bindings/config.txt   |   6 +
 drivers/clk/rockchip/Makefile |   3 +-
 drivers/clk/rockchip/clk_rk3128.c | 596 
++
 drivers/pinctrl/Kconfig   |  10 ++
 drivers/pinctrl/rockchip/Makefile |   4 +-
 drivers/pinctrl/rockchip/pinctrl_rk3128.c | 187 
+
 drivers/ram/rockchip/Makefile |   1 +
 drivers/ram/rockchip/sdram_rk3128.c   |  59 
 include/configs/evb_rk3128.h  |  15 ++
 include/configs/rk3128_common.h   |  70 ++
 include/dt-bindings/clock/rk3128-cru.h| 190 
+
 34 files changed, 3263 insertions(+), 19 deletions(-)
 create mode 100644 arch/arm/dts/rk3128-evb.dts
 create mode 100644 arch/arm/dts/rk3128.dtsi
 create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3128.h
 create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3128.h
 create mode 100644 arch/arm/mach-rockchip/rk3128-board.c
 create mode 100644 arch/arm/mach-rockchip/rk3128/Kconfig
 create mode 100644 arch/arm/mach-rockchip/rk3128/Makefile
 create mode 100644 arch/arm/mach-rockchip/rk3128/clk_rk3128.c
 create mode 100644 arch/arm/mach-rockchip/rk3128/rk3128.c
 create mode 100644 arch/arm/mach-rockchip/rk3128/syscon_rk3128.c
 create mode 100644 board/rockchip/evb_rk3128/Kconfig
 create mode 100644 board/rockchip/evb_rk3128/MAINTAINERS
 create mode 100644 board/rockchip/evb_rk3128/Makefile
 create mode 100644 board/rockchip/evb_rk3128/evk-rk3128.c

Re: [U-Boot] [PATCH] ARM: zynq: Fix SPL SD boot mode

[Gerald Van Baren]

Hi Michal,

On Fri, Dec 1, 2017 at 8:13 AM, Michal Simek 
wrote:

> This patch is fixing two issues:
> 1. Insufficient stack size for fat fs buffers
> 2. Insufficient space in malloc area
>
> Tested on zc702 and zc706.
>
> Signed-off-by: Michal Simek 
>

What are the symptoms of this bug?

I am running on a custom board and have been bedeviled by the behavior
where I can boot off a SD Card with the SPL loading U-Boot also off the SD
Card for many new build / copy to SD Card / boot iterations and then it
stops with an error message that the SD Card did not respond to the voltage
select command. Adding debugging printouts indicate the SD Card does not
respond to commands right at the start of the capabilities read operations
for no apparent reason.

Once it fails for a given image, it always fails for that SD Card until I
load a new image... then it might work or might not. Sometimes if I
reformat the SD Card it works again (presumably due to shifting where the
images are on the SD Card), sometimes not.

This has been driving me CRAZY.

I've applied your changes and will see if my problem goes away, but it is a
"halting problem" in that I don't know how many time it has to succeed
before I'm sure it will never fail. :-/

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

Re: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

[Stephen Warren]

On 12/01/2017 08:19 AM, Michal Simek wrote:

Hi,

On 1.12.2017 16:06, Heinrich Schuchardt wrote:



On 12/01/2017 03:46 PM, Michal Simek wrote:

Qemu for arm32/arm64 has a problem with time setup.


Wouldn't it be preferable to fix the root cause?


Definitely that would be the best and IIRC I have tried to convince our
qemu guy to do that but they have never done that.


What is the exact failure condition? Is it simply that the test is still 
slightly too strict about which delays it accepts, or is sleep outright 
broken?


You can use command-line option -k to avoid some tests. For example "-k 
not sleep". That way, we don't have to hard-code the dependency into the 
test source. Depending on the root cause (issue in U-Boot, or issue in 
just your local version of qemu, or something that will never work) this 
might be better?

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

Re: [U-Boot] [V2 1/2] armv8: ls1043a: modify the detecting way to cover all variants

[York Sun]

The subject can be change to

armv8: ls1043a: check SoC by device ID

On 11/30/2017 10:55 PM, Wenbin song wrote:
> There are many variants for ls1043a. Modify the detecting way to
> make that the below fixup apply to all variants of ls1043a.
>   - Fix GIC offset for rev1.1
>   - Fix msi node for rev1.1
>   - erratum_a010151

Maybe the commit message can be

Check LS1043A by device ID without using personality ID to determine
revision number. This check applies to all various personalities of the
same SoC family.


> 
> Signed-off-by: Wenbin Song 
> ---
> Changes for V1:
>   None.
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/fdt.c| 4 ++--
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   | 5 ++---
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h | 3 +++
>  drivers/usb/common/fsl-errata.c| 7 +--
>  4 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> index cae59da803..3c32c0f860 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
> @@ -145,7 +145,7 @@ static void fdt_fixup_gic(void *blob)
>  
>   val = gur_in32(>svr);
>  
> - if (SVR_SOC_VER(val) != SVR_LS1043A) {
> + if (!IS_SVR_DEV(val, SVR_DEV_LS1043A)) {
>   align_64k = 1;
>   } else if (SVR_REV(val) != REV1_0) {
>   val = scfg_in32(>gic_align) & (0x01 << GIC_ADDR_BIT);
> @@ -327,7 +327,7 @@ static void fdt_fixup_msi(void *blob)
>  
>   rev = gur_in32(>svr);
>  
> - if (SVR_SOC_VER(rev) != SVR_LS1043A)
> + if (!IS_SVR_DEV(rev, SVR_DEV_LS1043A))
>   return;
>  
>   rev = SVR_REV(rev);
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
> b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> index fa93096c68..54b825a626 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> @@ -37,9 +37,8 @@ ENTRY(get_gic_offset)
>   ldr x2, =DCFG_CCSR_SVR
>   ldr w2, [x2]
>   rev w2, w2
> - mov w3, w2
> - andsw3, w3, #SVR_WO_E << 8
> - mov w4, #SVR_LS1043A << 8
> + lsr w3, w2, #16
> + ldr w4, =SVR_DEV_LS1043A
>   cmp w3, w4
>   b.ne1f
>   andsw2, w2, #0xff
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> index 247f09e0f5..a2a039ec53 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
> @@ -77,6 +77,7 @@ struct cpu_type {
>  #define SVR_LS2041A  0x870914
>  
>  #define SVR_DEV_LS2080A  0x8701
> +#define SVR_DEV_LS1043A  0x8792

My suggestion is to get rid of these SVR_DEV_* macros and define this

#define SVR_DEV(svr) (svr >> 8)

Then you can reuse all SVR macros.

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

[U-Boot] [PATCH 8/9] arm64: zynqmp: Enable phys for zcu102

[Michal Simek]

Enable USB3.0 and SATA phy for zcu102 boards.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-zcu102-revA.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/dts/zynqmp-zcu102-revA.dts 
b/arch/arm/dts/zynqmp-zcu102-revA.dts
index a2128ebfd8c8..2e382562c496 100644
--- a/arch/arm/dts/zynqmp-zcu102-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu102-revA.dts
@@ -14,6 +14,7 @@
 #include "zynqmp-clk.dtsi"
 #include 
 #include 
+#include 
 
 / {
model = "ZynqMP ZCU102 RevA";
@@ -884,6 +885,8 @@ 
drivers/hwmon/pmbus/Makefile:11:obj-$(CONFIG_SENSORS_MAX20751)  += max20751.o
ceva,p1-comwake-params = /bits/ 8 <0x06 0x14 0x08 0x0E>;
ceva,p1-burst-params = /bits/ 8 <0x13 0x08 0x4A 0x06>;
ceva,p1-retry-params = /bits/ 16 <0x96A4 0x3FFC>;
+   phy-names = "sata-phy";
+   phys = < PHY_TYPE_SATA 1 1 12500>;
 };
 
 /* SD1 with level shifter */
@@ -895,6 +898,10 @@ 
drivers/hwmon/pmbus/Makefile:11:obj-$(CONFIG_SENSORS_MAX20751)  += max20751.o
xlnx,mio_bank = <1>;
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
pinctrl-names = "default";
@@ -917,6 +924,10 @@ 
drivers/hwmon/pmbus/Makefile:11:obj-$(CONFIG_SENSORS_MAX20751)  += max20751.o
 _0 {
status = "okay";
dr_mode = "host";
+   snps,usb3_lpm_capable;
+   phy-names = "usb3-phy";
+   phys = < PHY_TYPE_USB3 0 2 2600>;
+   maximum-speed = "super-speed";
 };
 
  {
-- 
1.9.1

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

[U-Boot] [PATCH 3/9] arm64: zynqmp: Add reference to pmu firmware node

[Michal Simek]

This reference is needed for pinctrl driver where some signals can be
routed directly to platform management unit (PMU).

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 247344fcbb86..1cf535b964b5 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -261,7 +261,7 @@
method = "smc";
};
 
-   firmware {
+   pmufw: firmware {
compatible = "xlnx,zynqmp-pm";
method = "smc";
interrupt-parent = <>;
-- 
1.9.1

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

[U-Boot] [PATCH 6/9] arm64: zynqmp: Read boot mode register using zynqmp_mmio_read

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Dont read boot mode register directly read it using
zynqmp_mmio_read().

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f769db7e81b9..8c859ed8ff8b 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -343,13 +343,17 @@ int board_late_init(void)
u8 bootmode;
const char *mode;
char *new_targets;
+   int ret;
 
if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
debug("Saved variables - Skipping\n");
return 0;
}
 
-   reg = readl(_base->boot_mode);
+   ret = zynqmp_mmio_read((ulong)_base->boot_mode, );
+   if (ret)
+   return -EINVAL;
+
if (reg >> BOOT_MODE_ALT_SHIFT)
reg >>= BOOT_MODE_ALT_SHIFT;
 
-- 
1.9.1

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

[U-Boot] [PATCH 5/9] arm64: zynqmp: Enable SPL_CLK when SPL is enabled

[Michal Simek]

Setup proper dependency in Kconfig for SPL_CLK.

Signed-off-by: Michal Simek 
---

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

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e50ba930a17c..16be179c8ba5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -773,7 +773,7 @@ config ARCH_ZYNQMP
select SUPPORT_SPL
select CLK
select SPL_BOARD_INIT if SPL
-   select SPL_CLK
+   select SPL_CLK if SPL
select DM_USB if USB
imply FAT_WRITE
 
-- 
1.9.1

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

[U-Boot] [PATCH 7/9] arm64: zynqmp: Setup modeboot variable based on bootmode

[Michal Simek]

Setup bootmode variable based on bootmode selection.
This is helping with setting up boot method.
Also setup sdbootdevice.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 8c859ed8ff8b..7aa9628414fe 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -364,23 +364,28 @@ int board_late_init(void)
case USB_MODE:
puts("USB_MODE\n");
mode = "usb";
+   env_set("modeboot", "usb_dfu_spl");
break;
case JTAG_MODE:
puts("JTAG_MODE\n");
mode = "pxe dhcp";
+   env_set("modeboot", "jtagboot");
break;
case QSPI_MODE_24BIT:
case QSPI_MODE_32BIT:
mode = "qspi0";
puts("QSPI_MODE\n");
+   env_set("modeboot", "qspiboot");
break;
case EMMC_MODE:
puts("EMMC_MODE\n");
mode = "mmc0";
+   env_set("modeboot", "emmcboot");
break;
case SD_MODE:
puts("SD_MODE\n");
mode = "mmc0";
+   env_set("modeboot", "sdboot");
break;
case SD1_LSHFT_MODE:
puts("LVL_SHFT_");
@@ -389,13 +394,16 @@ int board_late_init(void)
puts("SD_MODE1\n");
 #if defined(CONFIG_ZYNQ_SDHCI0) && defined(CONFIG_ZYNQ_SDHCI1)
mode = "mmc1";
+   env_set("sdbootdev", "1");
 #else
mode = "mmc0";
 #endif
+   env_set("modeboot", "sdboot");
break;
case NAND_MODE:
puts("NAND_MODE\n");
mode = "nand0";
+   env_set("modeboot", "nandboot");
break;
default:
mode = "";
-- 
1.9.1

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

[U-Boot] [PATCH 4/9] arm64: zynqmp: Add support for generic QSPI boot

[Michal Simek]

This patch is enabling support for SPL QSPI boot.

First of all it is necessary to generate atf-spi.ub which is different
format than atf-uboot.ub (this can be made as legacy image too)

ADDR=`arm-xilinx-linux-gnueabi-readelf -a bl31.elf | grep "Entry point
address" | cut -d ':' -f 2 | sed -e 's/^[ \t]*//'`
aarch64-linux-gnu-objcopy -O binary bl31.elf bl31.bin
./tools/mkimage -f auto -A arm64 -T firmware -C none -O u-boot -a $ADDR
-e $ADDR -n "atf1" -E -b arch/arm/dts/zynqmp-zcu102.dtb -d bl31.bin
atf-uboot.ub
./tools/mkimage -A arm64 -T firmware -C none -O u-boot -a $ADDR -e $ADDR
-n "atf-for-qspi" -E -d bl31.bin atf-spi.ub

This patch is using this QSPI layout with offsets:
0 boot.bin
512k atf-ub
640k u-boot.bin
1280k u-boot.img

Which corresponding by writing these images(read from MMC)
mmcinfo
sf probe
load mmc 0 1000 boot.bin
sf erase 0 +$filesize
sf write 1000 0 $filesize
load mmc 0 1000 atf-spi.ub
sf erase 0x8 +$filesize
sf write 1000 0x8 $filesize
load mmc 0 1000 u-boot.bin
sf erase 0xa +$filesize
sf write 1000 0xa $filesize
load mmc 0 1000 u-boot.img
sf erase 0x14 +$filesize
sf write 1000 0x14 $filesize

For testing u-boot running in EL3 you can break atf-spi.ub like this:
sf probe
sf erase 0x8 +4

Then u-boot.img is executed.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp.dtsi| 1 +
 include/configs/xilinx_zynqmp.h | 9 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 1cf535b964b5..5bdab6116451 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -804,6 +804,7 @@
};
 
qspi: spi@ff0f {
+   u-boot,dm-pre-reloc;
compatible = "xlnx,zynqmp-qspi-1.0";
status = "disabled";
clock-names = "ref_clk", "pclk";
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index df03d6700672..c2350f523f2d 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -236,6 +236,15 @@
 
 #define CONFIG_SPL_FRAMEWORK
 
+#if defined(CONFIG_SPL_SPI_FLASH_SUPPORT)
+# define CONFIG_SPL_SPI_LOAD
+# define CONFIG_SYS_SPI_KERNEL_OFFS0x8
+# define CONFIG_SYS_SPI_ARGS_OFFS  0xa
+# define CONFIG_SYS_SPI_ARGS_SIZE  0xa
+
+# define CONFIG_SYS_SPI_U_BOOT_OFFS0x17
+#endif
+
 /* u-boot is like dtb */
 #define CONFIG_SPL_FS_LOAD_ARGS_NAME   "u-boot.bin"
 #define CONFIG_SYS_SPL_ARGS_ADDR   0x800
-- 
1.9.1

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

[U-Boot] [PATCH 9/9] arm64: zynqmp: Enable clock command for all boards

[Michal Simek]

clk command provides an option to see actual clock setting.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_ep_defconfig   | 1 +
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig| 1 +
 configs/xilinx_zynqmp_zcu102_revA_defconfig  | 1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
 8 files changed, 8 insertions(+)

diff --git a/configs/xilinx_zynqmp_ep_defconfig 
b/configs/xilinx_zynqmp_ep_defconfig
index c9e01b19f165..4e29cc782032 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -24,6 +24,7 @@ CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_CMD_THOR_DOWNLOAD=y
 # CONFIG_CMD_EDITENV is not set
 # CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
 # CONFIG_CMD_FPGA is not set
 CONFIG_CMD_GPIO=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index 6067ab48e81d..c2805ac08125 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -22,6 +22,7 @@ CONFIG_FASTBOOT_FLASH=y
 CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_CMD_THOR_DOWNLOAD=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
index 2acc1eba295b..3a5fe1331cf1 100644
--- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
@@ -22,6 +22,7 @@ CONFIG_FASTBOOT=y
 CONFIG_FASTBOOT_FLASH=y
 CONFIG_CMD_THOR_DOWNLOAD=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
index 35dce719b19b..18f2eed7f0aa 100644
--- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
@@ -15,6 +15,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_CLK=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
index 2124d6b23c45..75ebd223cdf4 100644
--- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
@@ -16,6 +16,7 @@ CONFIG_SPL=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_CLK=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
diff --git a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig 
b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
index 225bd8a5d309..a72781000c1e 100644
--- a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
@@ -23,6 +23,7 @@ CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_CMD_THOR_DOWNLOAD=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
diff --git a/configs/xilinx_zynqmp_zcu102_revA_defconfig 
b/configs/xilinx_zynqmp_zcu102_revA_defconfig
index bf8fdc2bf674..94116ec61b59 100644
--- a/configs/xilinx_zynqmp_zcu102_revA_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revA_defconfig
@@ -23,6 +23,7 @@ CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_CMD_THOR_DOWNLOAD=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index 6dfa11a90f75..d6c49cdfad5b 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -23,6 +23,7 @@ CONFIG_FASTBOOT_FLASH_MMC_DEV=0
 CONFIG_CMD_THOR_DOWNLOAD=y
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
-- 
1.9.1

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

[U-Boot] [PATCH 2/9] arm64: zynqmp: Do not use SPL_SYS_MALLOC_SIMPLE allocator

[Michal Simek]

This was caused by: "fs/fat: Reduce stack usage"
 (sha1:2460098cffacd18729262e3ed36656e6943783ed) which converted
fat code to use malloc. But simple malloc is not freeing space
that's why full malloc implementation is needed.
Malloc space is added to RAM.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_ep_defconfig   | 1 -
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 -
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 -
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 -
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 -
 configs/xilinx_zynqmp_zcu102_rev1_0_defconfig| 1 -
 configs/xilinx_zynqmp_zcu102_revA_defconfig  | 1 -
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 -
 include/configs/xilinx_zynqmp.h  | 6 +++---
 9 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/configs/xilinx_zynqmp_ep_defconfig 
b/configs/xilinx_zynqmp_ep_defconfig
index ff865f1bdcd0..c9e01b19f165 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -14,7 +14,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_FASTBOOT=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index beb24346baa9..6067ab48e81d 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -15,7 +15,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_FASTBOOT=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
index 8c8201dfbb5c..2acc1eba295b 100644
--- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
@@ -16,7 +16,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_FASTBOOT=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
index 34365c8cfe82..35dce719b19b 100644
--- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
@@ -12,7 +12,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_CMD_MEMTEST=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
index a9e7a879de42..2124d6b23c45 100644
--- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
@@ -13,7 +13,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_CMD_MEMTEST=y
diff --git a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig 
b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
index bf27ca48db93..225bd8a5d309 100644
--- a/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_rev1_0_defconfig
@@ -15,7 +15,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_FASTBOOT=y
diff --git a/configs/xilinx_zynqmp_zcu102_revA_defconfig 
b/configs/xilinx_zynqmp_zcu102_revA_defconfig
index 80c5e4934844..bf8fdc2bf674 100644
--- a/configs/xilinx_zynqmp_zcu102_revA_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revA_defconfig
@@ -15,7 +15,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_FASTBOOT=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index 232532c99597..6dfa11a90f75 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -15,7 +15,6 @@ CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
-CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="ZynqMP> "
 CONFIG_FASTBOOT=y
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index cc1a53654591..df03d6700672 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -260,14 +260,14 @@
 # define 

[U-Boot] [PATCH 1/9] arm64: zynqmp: Do not perform reset in case of panic

[Michal Simek]

Do not perform reset when panic happens because in the next reset
panic happens again and logs are overflood by the same errors.
This can be enabled by default and reset can be performed via watchdog.

Signed-off-by: Michal Simek 
---

 include/configs/xilinx_zynqmp.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index 14604eb4e801..cc1a53654591 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -126,6 +126,7 @@
 #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
 #define CONFIG_SYS_LONGHELP
 #define CONFIG_CMDLINE_EDITING
+#define CONFIG_PANIC_HANG
 #define CONFIG_SYS_MAXARGS 64
 
 /* Ethernet driver */
-- 
1.9.1

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

Re: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

[Michal Simek]

Hi,

On 1.12.2017 16:06, Heinrich Schuchardt wrote:
> 
> 
> On 12/01/2017 03:46 PM, Michal Simek wrote:
>> Qemu for arm32/arm64 has a problem with time setup.
> 
> Wouldn't it be preferable to fix the root cause?

Definitely that would be the best and IIRC I have tried to convince our
qemu guy to do that but they have never done that.

> 
>> That's why sleep test is failing. Add boardidentity marker to remove
>> specific boards from running that test.
> 
> Isn't this what 'boardspec' is used for?

There are two things here.

./test/py/test.py --bd zynq_zc706 --build  --board-identity zc706  -s

boardspec is zynq_z706 -> u-boot config
and I use board identity (zc706) as actual HW I have here

And I use this
./test/py/test.py --bd zynq_zc706 --build  --board-identity qemu -s
which means run the same config for zc706 but on qemu

etc.

> 
> test/py/pytest.ini:
> boardspec: U-Boot: Describes the set of boards a test can/can't run on.

as above. This file should be also update if this "feature" is fine.


>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>> If you want to add this checking in one patch and then put it to one
>> test then it is fine for me.
>>
>> ---
>>   test/py/conftest.py | 28 
>>   test/py/pytest.ini  |  1 +
>>   test/py/tests/test_sleep.py |  1 +
>>   3 files changed, 30 insertions(+)
>>
>> diff --git a/test/py/conftest.py b/test/py/conftest.py
>> index 6e66a48c15fd..1812ff340e6a 100644
>> --- a/test/py/conftest.py
>> +++ b/test/py/conftest.py
>> @@ -436,6 +436,33 @@ def setup_boardspec(item):
>>   if required_boards and ubconfig.board_type not in required_boards:
>>   pytest.skip('board "%s" not supported' % ubconfig.board_type)
>>   +def setup_boardidentity(item):
>> +    """Process any 'boardidentity' marker for a test.
>> +
>> +    Such a marker lists the set of board identity that a test
>> does/doesn't
>> +    support. If tests are being executed on an unsupported board, the
>> test is
>> +    marked to be skipped.
>> +
>> +    Args:
>> +    item: The pytest test item.
>> +
>> +    Returns:
>> +    Nothing.
>> +    """
>> +    mark = item.get_marker('boardidentity')
>> +    if not mark:
>> +    return
>> +    required_boards = []
>> +    for board in mark.args:
>> +    if board.startswith('!'):
>> +    if ubconfig.board_identity == board[1:]:
>> +    pytest.skip('board identity not supported')
>> +    return
>> +    else:
>> +    required_boards.append(board)
>> +    if required_boards and ubconfig.board_identity not in
>> required_boards:
>> +    pytest.skip('board identity not supported')
>> +
>>   def setup_buildconfigspec(item):
>>   """Process any 'buildconfigspec' marker for a test.
>>   @@ -503,6 +530,7 @@ def pytest_runtest_setup(item):
>>     start_test_section(item)
>>   setup_boardspec(item)
>> +    setup_boardidentity(item)
>>   setup_buildconfigspec(item)
>>   setup_requiredtool(item)
>>   diff --git a/test/py/pytest.ini b/test/py/pytest.ini
>> index 67e514f42058..9d64671814de 100644
>> --- a/test/py/pytest.ini
>> +++ b/test/py/pytest.ini
>> @@ -8,4 +8,5 @@
>>   [pytest]
>>   markers =
>>   boardspec: U-Boot: Describes the set of boards a test can/can't
>> run on.
>> +    boardidentity: U-Boot: Describes the board identity a test
>> can/can't run on.
>>   buildconfigspec: U-Boot: Describes Kconfig/config-header
>> constraints.
>> diff --git a/test/py/tests/test_sleep.py b/test/py/tests/test_sleep.py
>> index 64e057132622..02a8a85b0e22 100644
>> --- a/test/py/tests/test_sleep.py
>> +++ b/test/py/tests/test_sleep.py
>> @@ -5,6 +5,7 @@
>>   import pytest
>>   import time
>>   +@pytest.mark.boardidentity("!qemu")
> 
> According to your commit message you don't want to exclude qemu-x86 here.

It is really just qemu board identity not qemu target.

The issue with this patch is that everybody can select whatever they
want to for board identification.

Maybe it would be much simpler to create variable and check it in that
test and skip that test.

Anyway this is what I have in the tree and it is time to find proper
solution that's why RFC.

Thanks,
Michal


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

[U-Boot] [PATCH] efi_loader: Fix partition offsets

[Alexander Graf]

Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) tried
to introduce the el torito scheme to all partition table types: Spawn
individual disk objects for each partition on a disk.

Unfortunately, that code ended up creating partitions with offset=0 which meant
that anyone accessing these objects gets data from the raw block device instead
of the partition.

Furthermore, all the el torito logic to spawn devices for partitions was
duplicated. So let's merge the two code paths and give partition disk objects
good offsets to work from, so that payloads can actually make use of them.

Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions)
Reported-by: Yousaf Kaukab 
Signed-off-by: Alexander Graf 
---
 lib/efi_loader/efi_disk.c | 60 ++-
 1 file changed, 13 insertions(+), 47 deletions(-)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 68ba2cf7b2..4e457a841b 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -264,21 +264,17 @@ out_of_memory:
printf("ERROR: Out of memory\n");
 }
 
-static int efi_disk_create_eltorito(struct blk_desc *desc,
-   const char *if_typename,
-   int diskid,
-   const char *pdevname)
+static int efi_disk_create_partitions(struct blk_desc *desc,
+ const char *if_typename,
+ int diskid,
+ const char *pdevname)
 {
int disks = 0;
-#if CONFIG_IS_ENABLED(ISO_PARTITION)
char devname[32] = { 0 }; /* dp->str is u16[32] long */
disk_partition_t info;
int part;
 
-   if (desc->part_type != PART_TYPE_ISO)
-   return 0;
-
-   /* and devices for each partition: */
+   /* Add devices for each partition */
for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
if (part_get_info(desc, part, ))
continue;
@@ -289,10 +285,6 @@ static int efi_disk_create_eltorito(struct blk_desc *desc,
disks++;
}
 
-   /* ... and add block device: */
-   efi_disk_add_dev(devname, if_typename, desc, diskid, 0, 0);
-#endif
-
return disks;
 }
 
@@ -318,31 +310,18 @@ int efi_disk_register(void)
 uclass_next_device_check()) {
struct blk_desc *desc = dev_get_uclass_platdata(dev);
const char *if_typename = dev->driver->name;
-   disk_partition_t info;
-   int part;
 
printf("Scanning disk %s...\n", dev->name);
 
-   /* add devices for each partition: */
-   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
-   if (part_get_info(desc, part, ))
-   continue;
-   efi_disk_add_dev(dev->name, if_typename, desc,
-desc->devnum, 0, part);
-   }
-
-   /* ... and add block device: */
+   /* Add block device for the full device */
efi_disk_add_dev(dev->name, if_typename, desc,
 desc->devnum, 0, 0);
 
disks++;
 
-   /*
-   * El Torito images show up as block devices in an EFI world,
-   * so let's create them here
-   */
-   disks += efi_disk_create_eltorito(desc, if_typename,
- desc->devnum, dev->name);
+   /* Partitions show up as block devices in EFI */
+   disks += efi_disk_create_partitions(desc, if_typename,
+   desc->devnum, dev->name);
}
 #else
int i, if_type;
@@ -361,8 +340,6 @@ int efi_disk_register(void)
for (i = 0; i < 4; i++) {
struct blk_desc *desc;
char devname[32] = { 0 }; /* dp->str is u16[32] long */
-   disk_partition_t info;
-   int part;
 
desc = blk_get_devnum_by_type(if_type, i);
if (!desc)
@@ -373,24 +350,13 @@ int efi_disk_register(void)
snprintf(devname, sizeof(devname), "%s%d",
 if_typename, i);
 
-   /* add devices for each partition: */
-   for (part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
-   if (part_get_info(desc, part, ))
-   continue;
-   efi_disk_add_dev(devname, if_typename, desc,
-i, 0, part);
-   }
-
-   /* ... and add block device: */
+  

Re: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

[Heinrich Schuchardt]

On 12/01/2017 03:46 PM, Michal Simek wrote:

Qemu for arm32/arm64 has a problem with time setup.


Wouldn't it be preferable to fix the root cause?


That's why sleep test is failing. Add boardidentity marker to remove
specific boards from running that test.


Isn't this what 'boardspec' is used for?

test/py/pytest.ini:
boardspec: U-Boot: Describes the set of boards a test can/can't run on.



Signed-off-by: Michal Simek 
---

If you want to add this checking in one patch and then put it to one
test then it is fine for me.

---
  test/py/conftest.py | 28 
  test/py/pytest.ini  |  1 +
  test/py/tests/test_sleep.py |  1 +
  3 files changed, 30 insertions(+)

diff --git a/test/py/conftest.py b/test/py/conftest.py
index 6e66a48c15fd..1812ff340e6a 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -436,6 +436,33 @@ def setup_boardspec(item):
  if required_boards and ubconfig.board_type not in required_boards:
  pytest.skip('board "%s" not supported' % ubconfig.board_type)
  
+def setup_boardidentity(item):

+"""Process any 'boardidentity' marker for a test.
+
+Such a marker lists the set of board identity that a test does/doesn't
+support. If tests are being executed on an unsupported board, the test is
+marked to be skipped.
+
+Args:
+item: The pytest test item.
+
+Returns:
+Nothing.
+"""
+mark = item.get_marker('boardidentity')
+if not mark:
+return
+required_boards = []
+for board in mark.args:
+if board.startswith('!'):
+if ubconfig.board_identity == board[1:]:
+pytest.skip('board identity not supported')
+return
+else:
+required_boards.append(board)
+if required_boards and ubconfig.board_identity not in required_boards:
+pytest.skip('board identity not supported')
+
  def setup_buildconfigspec(item):
  """Process any 'buildconfigspec' marker for a test.
  
@@ -503,6 +530,7 @@ def pytest_runtest_setup(item):
  
  start_test_section(item)

  setup_boardspec(item)
+setup_boardidentity(item)
  setup_buildconfigspec(item)
  setup_requiredtool(item)
  
diff --git a/test/py/pytest.ini b/test/py/pytest.ini

index 67e514f42058..9d64671814de 100644
--- a/test/py/pytest.ini
+++ b/test/py/pytest.ini
@@ -8,4 +8,5 @@
  [pytest]
  markers =
  boardspec: U-Boot: Describes the set of boards a test can/can't run on.
+boardidentity: U-Boot: Describes the board identity a test can/can't run 
on.
  buildconfigspec: U-Boot: Describes Kconfig/config-header constraints.
diff --git a/test/py/tests/test_sleep.py b/test/py/tests/test_sleep.py
index 64e057132622..02a8a85b0e22 100644
--- a/test/py/tests/test_sleep.py
+++ b/test/py/tests/test_sleep.py
@@ -5,6 +5,7 @@
  import pytest
  import time
  
+@pytest.mark.boardidentity("!qemu")


According to your commit message you don't want to exclude qemu-x86 here.

Best regards

Heinrich Schuchardt


  def test_sleep(u_boot_console):
  """Test the sleep command, and validate that it sleeps for approximately
  the correct amount of time."""


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

[U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

[Michal Simek]

Qemu for arm32/arm64 has a problem with time setup.
That's why sleep test is failing. Add boardidentity marker to remove
specific boards from running that test.

Signed-off-by: Michal Simek 
---

If you want to add this checking in one patch and then put it to one
test then it is fine for me.

---
 test/py/conftest.py | 28 
 test/py/pytest.ini  |  1 +
 test/py/tests/test_sleep.py |  1 +
 3 files changed, 30 insertions(+)

diff --git a/test/py/conftest.py b/test/py/conftest.py
index 6e66a48c15fd..1812ff340e6a 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -436,6 +436,33 @@ def setup_boardspec(item):
 if required_boards and ubconfig.board_type not in required_boards:
 pytest.skip('board "%s" not supported' % ubconfig.board_type)
 
+def setup_boardidentity(item):
+"""Process any 'boardidentity' marker for a test.
+
+Such a marker lists the set of board identity that a test does/doesn't
+support. If tests are being executed on an unsupported board, the test is
+marked to be skipped.
+
+Args:
+item: The pytest test item.
+
+Returns:
+Nothing.
+"""
+mark = item.get_marker('boardidentity')
+if not mark:
+return
+required_boards = []
+for board in mark.args:
+if board.startswith('!'):
+if ubconfig.board_identity == board[1:]:
+pytest.skip('board identity not supported')
+return
+else:
+required_boards.append(board)
+if required_boards and ubconfig.board_identity not in required_boards:
+pytest.skip('board identity not supported')
+
 def setup_buildconfigspec(item):
 """Process any 'buildconfigspec' marker for a test.
 
@@ -503,6 +530,7 @@ def pytest_runtest_setup(item):
 
 start_test_section(item)
 setup_boardspec(item)
+setup_boardidentity(item)
 setup_buildconfigspec(item)
 setup_requiredtool(item)
 
diff --git a/test/py/pytest.ini b/test/py/pytest.ini
index 67e514f42058..9d64671814de 100644
--- a/test/py/pytest.ini
+++ b/test/py/pytest.ini
@@ -8,4 +8,5 @@
 [pytest]
 markers =
 boardspec: U-Boot: Describes the set of boards a test can/can't run on.
+boardidentity: U-Boot: Describes the board identity a test can/can't run 
on.
 buildconfigspec: U-Boot: Describes Kconfig/config-header constraints.
diff --git a/test/py/tests/test_sleep.py b/test/py/tests/test_sleep.py
index 64e057132622..02a8a85b0e22 100644
--- a/test/py/tests/test_sleep.py
+++ b/test/py/tests/test_sleep.py
@@ -5,6 +5,7 @@
 import pytest
 import time
 
+@pytest.mark.boardidentity("!qemu")
 def test_sleep(u_boot_console):
 """Test the sleep command, and validate that it sleeps for approximately
 the correct amount of time."""
-- 
1.9.1

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

[U-Boot] [PATCH] arm: zynq: Add support to store environment in EEPROM

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Added support to store environment in EEPROM.
Set the mux to select EEPROM during board init so
that the env can be read from EEPROM later.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 board/xilinx/zynq/board.c | 8 +++-
 include/configs/zynq-common.h | 2 ++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index e59038106aa6..28394bef0567 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -34,6 +34,9 @@ static xilinx_desc fpga100 = XILINX_XC7Z100_DESC(0x100);
 
 int board_init(void)
 {
+#if defined(CONFIG_ENV_IS_IN_EEPROM) && !defined(CONFIG_SPL_BUILD)
+   unsigned char eepromsel = CONFIG_SYS_I2C_MUX_EEPROM_SEL;
+#endif
 #if (defined(CONFIG_FPGA) && !defined(CONFIG_SPL_BUILD)) || \
 (defined(CONFIG_SPL_FPGA_SUPPORT) && defined(CONFIG_SPL_BUILD))
u32 idcode;
@@ -79,7 +82,10 @@ int board_init(void)
fpga_init();
fpga_add(fpga_xilinx, );
 #endif
-
+#if defined(CONFIG_ENV_IS_IN_EEPROM) && !defined(CONFIG_SPL_BUILD)
+   if (eeprom_write(CONFIG_SYS_I2C_MUX_ADDR, 0, , 1))
+   puts("I2C:EEPROM selection failed\n");
+#endif
return 0;
 }
 
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index b10cb3f57220..547f447a46fd 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -146,6 +146,8 @@
 # define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 4
 # define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 5
 # define CONFIG_SYS_EEPROM_SIZE1024 /* Bytes */
+# define CONFIG_SYS_I2C_MUX_ADDR   0x74
+# define CONFIG_SYS_I2C_MUX_EEPROM_SEL 0x4
 #endif
 
 /* Total Size of Environment Sector */
-- 
1.9.1

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

[U-Boot] [RFC PATCH] cmd: aes: Extend aes command to use hw engine if available.

[Michal Simek]

From: Siva Durga Prasad Paladugu 

Extend aes command to use hw engine for decryption if available
in hardware.

Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 cmd/aes.c   | 55 +++--
 include/uboot_aes.h | 10 ++
 2 files changed, 47 insertions(+), 18 deletions(-)

diff --git a/cmd/aes.c b/cmd/aes.c
index ee1ae13c06ec..48835129658e 100644
--- a/cmd/aes.c
+++ b/cmd/aes.c
@@ -16,6 +16,11 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+__weak int aes_decrypt_hw(u8 *key_ptr, u8 *src_ptr, u8 *dst_ptr, u32 len)
+{
+   return 0;
+}
+
 /**
  * do_aes() - Handle the "aes" command-line command
  * @cmdtp: Command data struct pointer
@@ -33,8 +38,9 @@ static int do_aes(cmd_tbl_t *cmdtp, int flag, int argc, char 
*const argv[])
uint8_t key_exp[AES_EXPAND_KEY_LENGTH];
uint32_t aes_blocks;
int enc;
+   bool use_hw = false;
 
-   if (argc != 6)
+   if (argc < 6 || argc > 7)
return CMD_RET_USAGE;
 
if (!strncmp(argv[1], "enc", 3))
@@ -49,21 +55,31 @@ static int do_aes(cmd_tbl_t *cmdtp, int flag, int argc, 
char *const argv[])
dst_addr = simple_strtoul(argv[4], NULL, 16);
len = simple_strtoul(argv[5], NULL, 16);
 
-   key_ptr = (uint8_t *)key_addr;
-   src_ptr = (uint8_t *)src_addr;
-   dst_ptr = (uint8_t *)dst_addr;
+   if (argc == 7)
+   if (!strncmp(argv[6], "hw", 2))
+   use_hw = true;
 
-   /* First we expand the key. */
-   aes_expand_key(key_ptr, key_exp);
+   key_ptr = (uint8_t *)(uintptr_t)key_addr;
+   src_ptr = (uint8_t *)(uintptr_t)src_addr;
+   dst_ptr = (uint8_t *)(uintptr_t)dst_addr;
 
-   /* Calculate the number of AES blocks to encrypt. */
-   aes_blocks = DIV_ROUND_UP(len, AES_KEY_LENGTH);
+   if (use_hw) {
+   if (!enc)
+   aes_decrypt_hw(key_ptr, src_ptr, dst_ptr, len);
+   } else {
+   /* First we expand the key. */
+   aes_expand_key(key_ptr, key_exp);
 
-   if (enc)
-   aes_cbc_encrypt_blocks(key_exp, src_ptr, dst_ptr, aes_blocks);
-   else
-   aes_cbc_decrypt_blocks(key_exp, src_ptr, dst_ptr, aes_blocks);
+   /* Calculate the number of AES blocks to encrypt. */
+   aes_blocks = DIV_ROUND_UP(len, AES_KEY_LENGTH);
 
+   if (enc)
+   aes_cbc_encrypt_blocks(key_exp, src_ptr, dst_ptr,
+  aes_blocks);
+   else
+   aes_cbc_decrypt_blocks(key_exp, src_ptr, dst_ptr,
+  aes_blocks);
+   }
return 0;
 }
 
@@ -75,15 +91,18 @@ static char aes_help_text[] =
"  $key and store the result at address\n"
"  $dst. The $len size must be multiple of\n"
"  16 bytes and $key must be 16 bytes long.\n"
-   "aes dec key src dst len - Decrypt block of data $len bytes long\n"
-   "  at address $src using a key at address\n"
-   "  $key and store the result at address\n"
-   "  $dst. The $len size must be multiple of\n"
-   "  16 bytes and $key must be 16 bytes long.";
+   "aes dec key src dst len [hw] - Decrypt block of data $len bytes\n"
+   "   long at address $src using a key at\n"
+   "   address $key and store the result at\n"
+   "   address $dst. The $len size must be\n"
+   "   multiple of 16 bytes and $key must be\n"
+   "   16 bytes long. The optional hw flag\n"
+   "   specifies to used hardware engine if\n"
+   "   supports\n";
 #endif
 
 U_BOOT_CMD(
-   aes, 6, 1, do_aes,
+   aes, 7, 1, do_aes,
"AES 128 CBC encryption",
aes_help_text
 );
diff --git a/include/uboot_aes.h b/include/uboot_aes.h
index 6315c02aa93d..5198bb98d076 100644
--- a/include/uboot_aes.h
+++ b/include/uboot_aes.h
@@ -91,4 +91,14 @@ void aes_cbc_encrypt_blocks(u8 *key_exp, u8 *src, u8 *dst, 
u32 num_aes_blocks);
  */
 void aes_cbc_decrypt_blocks(u8 *key_exp, u8 *src, u8 *dst, u32 num_aes_blocks);
 
+/**
+ * Decrypt the image using hw engine.
+ *
+ * @key_ptrKey to use
+ * @src_ptrSource data to decrypt
+ * @dst_ptrDestination buffer
+ * @lenLength of encrypted image
+ */
+int aes_decrypt_hw(u8 *key_ptr, u8 *src_ptr, u8 *dst_ptr, u32 len);
+
 #endif /* _AES_REF_H_ */
-- 
1.9.1

___
U-Boot mailing list

[U-Boot] [PATCH] ARM: zynq: Fix SPL SD boot mode

[Michal Simek]

This patch is fixing two issues:
1. Insufficient stack size for fat fs buffers
2. Insufficient space in malloc area

Tested on zc702 and zc706.

Signed-off-by: Michal Simek 
---

 configs/syzygy_hub_defconfig   | 2 ++
 configs/topic_miami_defconfig  | 2 ++
 configs/topic_miamilite_defconfig  | 2 ++
 configs/topic_miamiplus_defconfig  | 2 ++
 configs/zynq_cc108_defconfig   | 2 ++
 configs/zynq_microzed_defconfig| 2 ++
 configs/zynq_picozed_defconfig | 2 ++
 configs/zynq_z_turn_defconfig  | 2 ++
 configs/zynq_zc702_defconfig   | 2 ++
 configs/zynq_zc706_defconfig   | 2 ++
 configs/zynq_zc770_xm010_defconfig | 2 ++
 configs/zynq_zc770_xm011_defconfig | 2 ++
 configs/zynq_zc770_xm012_defconfig | 2 ++
 configs/zynq_zc770_xm013_defconfig | 2 ++
 configs/zynq_zed_defconfig | 2 ++
 configs/zynq_zybo_defconfig| 2 ++
 include/configs/zynq-common.h  | 7 ++-
 17 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/configs/syzygy_hub_defconfig b/configs/syzygy_hub_defconfig
index 1cc86b862c4a..8bdc4be67d70 100644
--- a/configs/syzygy_hub_defconfig
+++ b/configs/syzygy_hub_defconfig
@@ -3,6 +3,7 @@ CONFIG_SYS_VENDOR="opalkelly"
 CONFIG_SYS_CONFIG_NAME="syzygy_hub"
 CONFIG_ARCH_ZYNQ=y
 CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_SPL_STACK_R_ADDR=0x20
 CONFIG_DEFAULT_DEVICE_TREE="zynq-syzygy-hub"
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
@@ -10,6 +11,7 @@ CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
diff --git a/configs/topic_miami_defconfig b/configs/topic_miami_defconfig
index 38f2e4e5ccfd..aabd705da0fb 100644
--- a/configs/topic_miami_defconfig
+++ b/configs/topic_miami_defconfig
@@ -3,12 +3,14 @@ CONFIG_SYS_VENDOR="topic"
 CONFIG_SYS_CONFIG_NAME="topic_miami"
 CONFIG_ARCH_ZYNQ=y
 CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_SPL_STACK_R_ADDR=0x20
 CONFIG_BOOT_INIT_FILE="board/topic/zynq/zynq-topic-miami/ps7_regs.txt"
 CONFIG_DEFAULT_DEVICE_TREE="zynq-topic-miami"
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=0
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="zynq-uboot> "
 CONFIG_CMD_THOR_DOWNLOAD=y
diff --git a/configs/topic_miamilite_defconfig 
b/configs/topic_miamilite_defconfig
index a1e98b7bc3f6..7228283b3c6b 100644
--- a/configs/topic_miamilite_defconfig
+++ b/configs/topic_miamilite_defconfig
@@ -3,12 +3,14 @@ CONFIG_SYS_VENDOR="topic"
 CONFIG_SYS_CONFIG_NAME="topic_miami"
 CONFIG_ARCH_ZYNQ=y
 CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_SPL_STACK_R_ADDR=0x20
 CONFIG_BOOT_INIT_FILE="board/topic/zynq/zynq-topic-miamilite/ps7_regs.txt"
 CONFIG_DEFAULT_DEVICE_TREE="zynq-topic-miamilite"
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=0
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="zynq-uboot> "
 CONFIG_CMD_THOR_DOWNLOAD=y
diff --git a/configs/topic_miamiplus_defconfig 
b/configs/topic_miamiplus_defconfig
index b51107725a0c..d511a942838b 100644
--- a/configs/topic_miamiplus_defconfig
+++ b/configs/topic_miamiplus_defconfig
@@ -3,12 +3,14 @@ CONFIG_SYS_VENDOR="topic"
 CONFIG_SYS_CONFIG_NAME="topic_miami"
 CONFIG_ARCH_ZYNQ=y
 CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_SPL_STACK_R_ADDR=0x20
 CONFIG_BOOT_INIT_FILE="board/topic/zynq/zynq-topic-miamiplus/ps7_regs.txt"
 CONFIG_DEFAULT_DEVICE_TREE="zynq-topic-miamiplus"
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=0
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="zynq-uboot> "
 CONFIG_CMD_THOR_DOWNLOAD=y
diff --git a/configs/zynq_cc108_defconfig b/configs/zynq_cc108_defconfig
index fcf4635e3d17..bdba0d1cc9ba 100644
--- a/configs/zynq_cc108_defconfig
+++ b/configs/zynq_cc108_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
 CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_SPL_STACK_R_ADDR=0x20
 CONFIG_DEFAULT_DEVICE_TREE="zynq-cc108"
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
@@ -8,6 +9,7 @@ CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig
index a713314343d8..fc21eb8f67a3 100644
--- a/configs/zynq_microzed_defconfig
+++ b/configs/zynq_microzed_defconfig
@@ -1,12 +1,14 @@
 CONFIG_ARM=y
 CONFIG_ARCH_ZYNQ=y
 CONFIG_SYS_TEXT_BASE=0x400
+CONFIG_SPL_STACK_R_ADDR=0x20
 CONFIG_DEFAULT_DEVICE_TREE="zynq-microzed"
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL=y
+CONFIG_SPL_STACK_R=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Zynq> "
diff --git a/configs/zynq_picozed_defconfig b/configs/zynq_picozed_defconfig
index bbccfa5dcecf..f36e7bd849f4 100644
--- a/configs/zynq_picozed_defconfig
+++ 

Re: [U-Boot] [PATCH] tools: env: Add support for direct read/write UBI volumes

[Lothar Waßmann]

Hi,

On Tue, 14 Nov 2017 23:01:26 -0800 S. Lockwood-Childs wrote:
> Up to now we were able to read/write environment data from/to UBI
> volumes only indirectly by gluebi driver. This driver creates NAND MTD
> on top of UBI volumes, which is quite a workaroung for this use case.
> 
> Add support for direct read/write UBI volumes in order to not use
> obsolete gluebi driver.
> 
> Forward-ported from this patch:
> http://patchwork.ozlabs.org/patch/619305/
> 
> Original patch:
> Signed-off-by: Marcin Niestroj 
> 
> Forward port:
> Signed-off-by: S. Lockwood-Childs 
> ---
>  tools/env/fw_env.c  | 255 
> +++-
>  tools/env/fw_env.config |   8 ++
>  2 files changed, 261 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
> index ab06415..867fba5 100644
> --- a/tools/env/fw_env.c
> +++ b/tools/env/fw_env.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef MTD_OLD
>  # include 
> @@ -34,6 +35,8 @@
>  # include 
>  #endif
>  
> +#include 
> +
>  #include "fw_env_private.h"
>  #include "fw_env.h"
>  
> @@ -58,6 +61,7 @@ struct envdev_s {
>   ulong erase_size;   /* device erase size */
>   ulong env_sectors;  /* number of environment sectors */
>   uint8_t mtd_type;   /* type of the MTD device */
> + int is_ubi; /* set if we use UBI volume */
>  };
>  
>  static struct envdev_s envdevices[2] =
> @@ -76,6 +80,7 @@ static int dev_current;
>  #define DEVESIZE(i)   envdevices[(i)].erase_size
>  #define ENVSECTORS(i) envdevices[(i)].env_sectors
>  #define DEVTYPE(i)envdevices[(i)].mtd_type
> +#define IS_UBI(i) envdevices[(i)].is_ubi
>  
>  #define CUR_ENVSIZE ENVSIZE(dev_current)
>  
> @@ -122,6 +127,228 @@ static unsigned char obsolete_flag = 0;
>  #define DEFAULT_ENV_INSTANCE_STATIC
>  #include 
>  
> +#define UBI_DEV_START "/dev/ubi"
> +#define UBI_SYSFS "/sys/class/ubi"
> +#define UBI_VOL_NAME_PATT "ubi%d_%d"
> +
> +static int is_ubi_devname(const char *devname)
> +{
> + return !strncmp(devname, UBI_DEV_START, sizeof(UBI_DEV_START) - 1);
> +}
> +
> +static int ubi_check_volume_sysfs_name(const char *volume_sysfs_name,
> +const char *volname)
> +{
> + char path[256];
>
/usr/include/linux/limits.h specifies the constant 'PATH_MAX' which
should be used here.

> + FILE *file;
> + char *name;
> + int ret;
> +
> + strcpy(path, UBI_SYSFS "/");
> + strcat(path, volume_sysfs_name);
> + strcat(path, "/name");
> +
> + file = fopen(path, "r");
> + if (!file)
> + return -1;
> +
> + ret = fscanf(file, "%ms", );
> + fclose(file);
> + if (ret <= 0 || !name) {
> + fprintf(stderr,
> + "Failed to read from file %s, ret = %d, name = %s\n",
> + path, ret, name);
> + return -1;
> + }
> +
> + if (!strcmp(name, volname)) {
> + free(name);
> + return 0;
> + }
> + free(name);
> +
> + return -1;
> +}
> +
> +static int ubi_get_volnum_by_name(int devnum, const char *volname)
> +{
> + DIR *sysfs_ubi;
> + struct dirent *dirent;
> + int ret;
> + int tmp_devnum;
> + int volnum;
> +
> + sysfs_ubi = opendir(UBI_SYSFS);
> + if (!sysfs_ubi)
> + return -1;
> +
> +#ifdef DEBUG
> + fprintf(stderr, "Looking for volume name \"%s\"\n", volname);
> +#endif
> +
> + while (1) {
> + dirent = readdir(sysfs_ubi);
> + if (!dirent)
> + return -1;
> +
> + ret = sscanf(dirent->d_name, UBI_VOL_NAME_PATT,
> +  _devnum, );
> + if (ret == 2 && devnum == tmp_devnum) {
> + if (ubi_check_volume_sysfs_name(dirent->d_name,
> + volname) == 0)
> + return volnum;
> + }
> + }
> +
> + return -1;
>
This can never be reached.

> +}
> +
> +static int ubi_get_devnum_by_devname(const char *devname)
> +{
> + int devnum;
> + int ret;
> +
> + ret = sscanf(devname + sizeof(UBI_DEV_START) - 1, "%d", );
> + if (ret != 1)
> + return -1;
> +
> + return devnum;
> +}
> +
> +static const char *ubi_get_volume_devname(const char *devname,
> +   const char *volname)
> +{
> + char *volume_devname;
> + int volnum;
> + int devnum;
> + int ret;
> +
> + devnum = ubi_get_devnum_by_devname(devname);
> + if (devnum < 0)
> + return NULL;
> +
> + volnum = ubi_get_volnum_by_name(devnum, volname);
> + if (volnum < 0)
> + return NULL;
> +
> + ret = asprintf(_devname, "%s_%d", devname, volnum);
> + if (ret < 0)
> + return NULL;
> +
> +#ifdef DEBUG
> + fprintf(stderr, 

Re: [U-Boot] mmc1 not working on Samsung snow chromebook

[Guillaume Gardet]

Le 18/11/2017 à 17:33, Guillaume Gardet a écrit :



Le 17/11/2017 à 17:06, Jaehoon Chung a écrit :


On 2017년 11월 17일 18:38, Guillaume Gardet wrote:


Le 17/11/2017 à 10:36, Lukasz Majewski a écrit :

On Thu, 16 Nov 2017 13:29:56 +0100
Guillaume Gardet  wrote:


I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is
working fine.

I guess there is a better way to implement the following patch ?

**
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980b..a6a0934eef 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg,
struct dwmci_host *host, cfg->host_caps |= MMC_MODE_4BIT;
       cfg->host_caps &= ~MMC_MODE_8BIT;
       }
-   cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+   /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so
disbale it for now */
+   cfg->host_caps |= MMC_MODE_HS;

This seems like a workaround. The root cause of the problem is the
regression with HS 52MHz

Not sure it ever worked on this target.

Could you give me the debug log after enabled DEBUG?


WIth debug in mmc.c and dw_mmc.c on the broken system, I have:
Buswidth = 1, clock: 0
Buswidth = 1, clock: 40
Sending CMD0
Sending CMD8
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD55
Sending CMD51
Sending CMD6
Sending CMD6
Sending CMD55
dwmci_send_cmd: Response Error.
mmc_init: -5, time 78


WIth debug in mmc.c and dw_mmc.c with my workaround, I have:
Buswidth = 1, clock: 0
Buswidth = 1, clock: 40
Sending CMD0
Sending CMD8
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD55
Sending CMD41
Sending CMD2
Sending CMD3
Sending CMD9
Sending CMD7
Sending CMD55
Sending CMD51
Sending CMD6
Sending CMD55
Sending CMD6
Buswidth = 4, clock: 40
Sending CMD55
Sending CMD13
Buswidth = 4, clock: 2500
Sending CMD16
Sending CMD17
switch to partitions #0, OK
mmc1 is current device

The problem occurs in 'sd_change_freq' function when if we try to set high 
speed with the 2nd call to  'sd_switch' (1st call is just a check).


Any progress on this problem?

Guillaume





Guillaume




Best Regards,
Jaehoon Chung


Guillaume


       cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
    }
**


Guillaume



Le 15/11/2017 à 11:27, Guillaume Gardet a écrit :

Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and
while mmc0 (internal eMMC) is working fine, mmc1 (external SD
slot) does not work. I get the following error for 'mmc dev 1'
command: mmc_init: -110, time 30

Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop
auto-boot), I firstly get: mmc_init: -5, time 39

Then, all next attempts retruns:
  mmc_init: -110, time 30


Guillaume


Any idea what could be wrong?

Guillaume


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


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-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de

___
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 v3 00/18] efi_loader: manage protocols in a linked list (v3)

[Alexander Graf]

On 11/27/2017 06:09 PM, Simon Glass wrote:

Hi,

On 26 November 2017 at 06:05, Heinrich Schuchardt  wrote:

Up to now the protocols of an EFI handle where contained in an
array of fixed size. With the patch series the protocols are
managed in a linked list. This both saves memory and gives
more flexibility.

The LocateDevicePath boot service is implemented according
to the UEFI specification.

A unit test for the LocateDevicePath boot service and the
device path to text protocol are added.

Some bug fixes are provided.

v3
 Remove patch
 efi_loader: efi_bootmgr: do not make hidden assignments
 (A patch to add device path printing in printf() is
 pending.)
 Resubmit
 efi_loader: helloworld.c: remove superfluous include
v2
 Enhance the helloworld example to check if the image
 handle is passed corectly. Adjust the related py
 test.

 Use a helper function to initialize EFI objects.

 Further minor bug fixes.

Heinrich Schuchardt (18):
   efi_loader: helloworld.c: remove superfluous include
   efi_loader: size of media device path node represenation
   efi_loader: efi_dp_str should print path not node
   efi_loader: fix efi_convert_device_node_to_text
   efi_loader: reimplement LocateDevicePath
   efi_selftest: test EFI_DEVICE_PATH_TO_TEXT_PROTOCOL
   efi_loader: efi_disk: use efi_add_protocol
   efi_loader: efi_net: use efi_add_protocol
   efi_loader: efi_gop: use efi_add_protocol
   efi_loader: simplify efi_open_protocol
   efi_loader: simplify find_obj
   efi_loader: manage protocols in a linked list
   efi_selftest: compile without special compiler flags
   efi_selftest: add missing line feed
   efi_loader: output load options in helloworld
   test/py: check return code of helloworld
   efi_loader: pass handle of loaded image
   efi_loader: helper function to add EFI object to list


This series seems to have been hanging around for a while. Is it going
to be applied soon?



Well, v3 was only one day old by the time you wrote :). But yes, on it.


Alex

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

Re: [U-Boot] [PATCH 00/23] imx: add i.MX8M support and i.MX8MQ EVK

[Diego Dorta]

Hi Peng,

2017-11-29 0:42 GMT-02:00 Peng Fan :
> Hi Diego,
>
> On Tue, Nov 28, 2017 at 02:42:20PM -0200, Diego Dorta wrote:
>>Hi Peng Fan,
>>
>>2017-11-28 10:31 GMT-02:00 Peng Fan :
>>> This patchset is to add i.MX8M and i.MX8MQ-EVK support
>>>
>>> patch: "power: pmic.h: include dm/ofnode.h" and
>>> "power: pmic/regulator allow dm be omited by SPL" is previously reviewed
>>> in mailist to not merged. Pick it up.
>>>
>>> The board support is a large patch because of the ddr related code.
>>> If it is not good, please first review/pick-up other patches if they
>>> are ok.
>>>
>>
>>I applied your patches and I am facing the following errors:
>
> I missed to add this after I cleanup patches.
>
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index efa2056e09..5ad17cb7fb 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -135,3 +135,4 @@ obj-$(CONFIG_MX6) += mx6/
>  obj-$(CONFIG_MX7) += mx7/
>  obj-$(CONFIG_ARCH_MX7ULP) += mx7ulp/
>
> +obj-$(CONFIG_MX8M) += mx8m/
>
> I'll add this in V2.
>
> Thanks,
> Peng.
>

I've followed the instructions for compiling and generating the
flash.bin file image.
However, when I try to boot I got this error and the U-Boot does not fully load:

�
U-Boot SPL 2017.11-38298-g2c1aa10-dirty (Nov 30 2017 - 10:49:38)
PMIC:  PFUZE100 ID=0x10
check ddr4_pmu_train_imem code
check ddr4_pmu_train_imem code pass
check ddr4_pmu_train_dmem code
check ddr4_pmu_train_dmem code pass
PLL bypass to 100MTS setting done
Training PASS
PLL bypass to 400MTS setting done
Training PASS
Training PASS
check ddr4_pmu_train_imem code
check ddr4_pmu_train_imem code pass
check ddr4_pmu_train_dmem code
check ddr4_pmu_train_dmem code pass

Have you ever faced this error or am I doing something wrong?

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

Re: [U-Boot] [PATCH] Convert CONFIG_NAND_OMAP_GPMC et al to Kconfig

[Enric Balletbo Serra]

2017-08-26 15:37 GMT+02:00 Simon Glass :
> On 11 August 2017 at 07:03, Adam Ford  wrote:
>> This converts the following to Kconfig:
>>CONFIG_NAND_OMAP_GPMC
>>CONFIG_NAND_OMAP_GPMC_PREFETCH
>>CONFIG_NAND_OMAP_ELM
>>CONFIG_SYS_NAND_BUSWIDTH_16BIT
>>CONFIG_SPL_NAND_AM33XX_BCH
>>CONFIG_SPL_NAND_SIMPLE
>>
>> Signed-off-by: Adam Ford 
>> ---
>>  README |  4 ---
>>  arch/arm/mach-omap2/Kconfig| 18 +
>>  configs/am335x_baltos_defconfig|  2 +-
>>  configs/am335x_evm_defconfig   |  1 +
>>  configs/am335x_evm_nor_defconfig   |  1 +
>>  configs/am335x_evm_usbspl_defconfig|  1 +
>>  configs/am335x_hs_evm_defconfig|  1 +
>>  configs/am3517_crane_defconfig |  1 +
>>  configs/am3517_evm_defconfig   |  2 ++
>>  configs/chiliboard_defconfig   |  2 +-
>>  configs/devkit8000_defconfig   |  1 +
>>  configs/eco5pk_defconfig   |  2 ++
>>  configs/igep0020_defconfig |  1 +
>>  configs/igep0030_defconfig |  1 +
>>  configs/igep0032_defconfig |  1 +

Tested by: Enric Balletbo i Serra 

>>  configs/ipam390_defconfig  |  1 +
>>  configs/mcx_defconfig  |  2 ++
>>  configs/mt_ventoux_defconfig   |  2 ++
>>  configs/omap3_beagle_defconfig |  1 +
>>  configs/omap3_evm_defconfig|  1 +
>>  configs/omap3_ha_defconfig |  1 +
>>  configs/omap3_logic_defconfig  |  1 +
>>  configs/omap3_overo_defconfig  |  1 +
>>  configs/omap3_pandora_defconfig|  1 +
>>  configs/omap3_zoom1_defconfig  |  1 +
>>  configs/omapl138_lcdk_defconfig|  1 +
>>  configs/tao3530_defconfig  |  1 +
>>  configs/ti816x_evm_defconfig   |  2 ++
>>  configs/twister_defconfig  |  2 ++
>>  drivers/mtd/nand/Kconfig   | 47 
>> +-
>>  include/configs/am335x_evm.h   |  6 -
>>  include/configs/am335x_igep003x.h  |  1 -
>>  include/configs/am3517_crane.h |  3 ---
>>  include/configs/am3517_evm.h   |  4 ---
>>  include/configs/am43xx_evm.h   |  5 
>>  include/configs/apf27.h|  1 -
>>  include/configs/baltos.h   |  3 ---
>>  include/configs/bav335x.h  |  5 
>>  include/configs/brppt1.h   |  3 ---
>>  include/configs/chiliboard.h   |  6 -
>>  include/configs/cm_t35.h   |  2 --
>>  include/configs/cm_t3517.h |  1 -
>>  include/configs/cm_t43.h   |  1 -
>>  include/configs/da850evm.h |  1 -
>>  include/configs/devkit3250.h   |  1 -
>>  include/configs/devkit8000.h   |  1 -
>>  include/configs/dra7xx_evm.h   |  6 -
>>  include/configs/ipam390.h  |  1 -
>>  include/configs/mcx.h  |  4 ---
>>  include/configs/omap3_beagle.h |  2 --
>>  include/configs/omap3_cairo.h  |  1 -
>>  include/configs/omap3_evm.h|  3 ---
>>  include/configs/omap3_igep00x0.h   |  2 --
>>  include/configs/omap3_logic.h  |  3 ---
>>  include/configs/omap3_overo.h  |  1 -
>>  include/configs/omap3_pandora.h|  1 -
>>  include/configs/omap3_zoom1.h  |  1 -
>>  include/configs/omapl138_lcdk.h|  2 --
>>  include/configs/pengwyn.h  |  2 --
>>  include/configs/siemens-am33x-common.h |  3 ---
>>  include/configs/tam3517-common.h   |  4 ---
>>  include/configs/tao3530.h  |  3 ---
>>  include/configs/tegra-common.h |  1 -
>>  include/configs/ti816x_evm.h   |  5 
>>  include/configs/ti_am335x_common.h |  4 ---
>>  include/configs/ti_armv7_omap.h|  1 -
>>  include/configs/ti_omap3_common.h  |  1 -
>>  include/configs/ti_omap4_common.h  |  4 ---
>>  include/configs/ti_omap5_common.h  |  4 ---
>>  include/configs/tricorder.h|  2 --
>>  scripts/config_whitelist.txt   |  5 
>>  71 files changed, 97 insertions(+), 117 deletions(-)
>>
>
> Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/1] arm: sunxi: Allwinner A10 SPI driver

[Stefan Mavrodiev]

Add spi driver for sun4i, sun5i and sun7i SoCs. The driver is
adapted from mailine kernel (currently 4.15.0-rc1).

Signed-off-by: Stefan Mavrodiev 
---
 Tested with A20-OLinuXino-Lime2 with W25Q128 chip. The output is:
 => sspi

 => sf probe
 SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 Mib

 => sf test 0 100
 SPI flash test:
 0 erase: 188398 ticks, 86 KiB/s 0.688 Mbps
 1 check: 141504 ticks, 115 KiB/s 0.920 Mbps
 2 write: 174697 ticks, 93 KiB/s 0.744 Mbps
 3 read: 141312 ticks, 115 KiB/s 0.920 Mbps
 Test passed
 0 erase: 188398 ticks, 86 KiB/s 0.688 Mbps
 1 check: 141504 ticks, 115 KiB/s 0.920 Mbps
 2 write: 174697 ticks, 93 KiB/s 0.744 Mbps
 3 read: 141312 ticks, 115 KiB/s 0.920 Mbps

 drivers/spi/Kconfig |   5 +
 drivers/spi/Makefile|   1 +
 drivers/spi/sun4i_spi.c | 423 
 3 files changed, 429 insertions(+)
 create mode 100644 drivers/spi/sun4i_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 88da9a4..d78253a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -132,6 +132,11 @@ config STM32_QSPI
  used to access the SPI NOR flash chips on platforms embedding
  this ST IP core.
 
+config SUN4I_SPI
+   bool "Allwinner A10 SoCs SPI controller"
+   help
+ SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
+
 config TEGRA114_SPI
bool "nVidia Tegra114 SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ad56203..04ba305 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
 obj-$(CONFIG_SH_SPI) += sh_spi.o
 obj-$(CONFIG_SH_QSPI) += sh_qspi.o
 obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o
+obj-$(CONFIG_SUN4I_SPI) += sun4i_spi.o
 obj-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
 obj-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
 obj-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
new file mode 100644
index 000..3ef1c68
--- /dev/null
+++ b/drivers/spi/sun4i_spi.c
@@ -0,0 +1,423 @@
+/*
+ * (C) Copyright 2017 Whitebox Systems / Northend Systems B.V.
+ * S.J.R. van Schaik 
+ * M.B.W. Wajer 
+ *
+ * (C) Copyright 2017 Olimex Ltd..
+ * Stefan Mavrodiev 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define SUN4I_FIFO_DEPTH   64
+
+#define SUN4I_RXDATA_REG   0x00
+
+#define SUN4I_TXDATA_REG   0x04
+
+#define SUN4I_CTL_REG  0x08
+#define SUN4I_CTL_ENABLE   BIT(0)
+#define SUN4I_CTL_MASTER   BIT(1)
+#define SUN4I_CTL_CPHA BIT(2)
+#define SUN4I_CTL_CPOL BIT(3)
+#define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
+#define SUN4I_CTL_LMTF BIT(6)
+#define SUN4I_CTL_TF_RST   BIT(8)
+#define SUN4I_CTL_RF_RST   BIT(9)
+#define SUN4I_CTL_XCH  BIT(10)
+#define SUN4I_CTL_CS_MASK  0x3000
+#define SUN4I_CTL_CS(cs)   (((cs) << 12) & SUN4I_CTL_CS_MASK)
+#define SUN4I_CTL_DHB  BIT(15)
+#define SUN4I_CTL_CS_MANUALBIT(16)
+#define SUN4I_CTL_CS_LEVEL BIT(17)
+#define SUN4I_CTL_TP   BIT(18)
+
+#define SUN4I_INT_CTL_REG  0x0c
+#define SUN4I_INT_CTL_RF_F34   BIT(4)
+#define SUN4I_INT_CTL_TF_E34   BIT(12)
+#define SUN4I_INT_CTL_TC   BIT(16)
+
+#define SUN4I_INT_STA_REG  0x10
+
+#define SUN4I_DMA_CTL_REG  0x14
+
+#define SUN4I_WAIT_REG 0x18
+
+#define SUN4I_CLK_CTL_REG  0x1c
+#define SUN4I_CLK_CTL_CDR2_MASK0xff
+#define SUN4I_CLK_CTL_CDR2(div)((div) & 
SUN4I_CLK_CTL_CDR2_MASK)
+#define SUN4I_CLK_CTL_CDR1_MASK0xf
+#define SUN4I_CLK_CTL_CDR1(div)(((div) & 
SUN4I_CLK_CTL_CDR1_MASK) << 8)
+#define SUN4I_CLK_CTL_DRS  BIT(12)
+
+#define SUN4I_MAX_XFER_SIZE0xff
+
+#define SUN4I_BURST_CNT_REG0x20
+#define SUN4I_BURST_CNT(cnt)   ((cnt) & SUN4I_MAX_XFER_SIZE)
+
+#define SUN4I_XMIT_CNT_REG 0x24
+#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
+
+#define SUN4I_FIFO_STA_REG 0x28
+#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
+#define SUN4I_FIFO_STA_RF_CNT_BITS 0
+#define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
+#define SUN4I_FIFO_STA_TF_CNT_BITS 16
+
+#define SUN4I_SPI_MAX_RATE 2400
+#define SUN4I_SPI_MIN_RATE 3000
+#define SUN4I_SPI_DEFAULT_RATE 100
+#define SUN4I_SPI_TIMEOUT_US   100
+
+struct sun4i_spi_platdata {
+   u32 base_addr;
+   u32 freq;
+};
+
+struct sun4i_spi_priv {
+   u32 base_addr;
+   u32 freq;
+   u32 mode;
+
+   const u8   

Re: [U-Boot] [PATCH V11 1/4] usb: rockchip: add the rockusb gadget

[Marek Vasut]

On 12/01/2017 08:20 AM, Eddie Cai wrote:
> this patch implement rockusb protocol on the device side. this is based on
> USB download gadget infrastructure. the rockusb function implements the rd,
> wl, rid commands. it can work with rkdeveloptool
> 
> Signed-off-by: Eddie Cai 
> Reviewed-by: Simon Glass 
> ---
> Changes in v11:
> -fix checkpatch error
> -add maintainer
> 
> Changes in v10:
> -fix build error
> 
> Changes in v9:
> -fix compile error
> 
> Changes in v8:
> -none
> 
> Changes in v7:
> -none
> 
> Changes in v6:
> -move some data to f_rockusb structure
> 
> Changes in v5:
> -fix build error when build non-rockchip board
> -fix checkpatch error
> 
> Changes in v4:
> -use enum instead of macro define
> -move some structure define and macro to f_rockusb.h
> -add some function comment as Simon required
> -address other comment from Simon
> -fix build error as Lukasz point out
> 
> ---
>  MAINTAINERS|   5 +
>  arch/arm/include/asm/arch-rockchip/f_rockusb.h | 132 +
>  drivers/usb/gadget/Kconfig |   8 +
>  drivers/usb/gadget/Makefile|   1 +
>  drivers/usb/gadget/f_rockusb.c | 697 
> +
>  5 files changed, 843 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/f_rockusb.h
>  create mode 100644 drivers/usb/gadget/f_rockusb.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2a20b94..e92a15d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -452,6 +452,11 @@ S:   Maintained
>  T:   git git://git.denx.de/u-boot-usb.git
>  F:   drivers/usb/
>  
> +ROCKUSB
> +M:   Eddie Cai 
> +S:  Maintained
> +F:   drivers/usb/gadget/f_rockusb.c
> +
>  VIDEO
>  M:   Anatolij Gustschin 
>  S:   Maintained
> diff --git a/arch/arm/include/asm/arch-rockchip/f_rockusb.h 
> b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
> new file mode 100644
> index 000..c207a78
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-rockchip/f_rockusb.h
> @@ -0,0 +1,132 @@
> +/*
> + * (C) Copyright 2017
> + *
> + * Eddie Cai 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#ifndef _F_ROCKUSB_H_
> +#define _F_ROCKUSB_H_
> +#include 
> +
> +#define ROCKUSB_VERSION  "0.1"
> +
> +#define ROCKUSB_INTERFACE_CLASS  0xff
> +#define ROCKUSB_INTERFACE_SUB_CLASS  0x06
> +#define ROCKUSB_INTERFACE_PROTOCOL   0x05
> +
> +#define RX_ENDPOINT_MAXIMUM_PACKET_SIZE_2_0  (0x0200)
> +#define RX_ENDPOINT_MAXIMUM_PACKET_SIZE_1_1  (0x0040)
> +#define TX_ENDPOINT_MAXIMUM_PACKET_SIZE  (0x0040)

My V10 comments were not addressed, NAK.

Also, I'm not sure why you have 20 people on To: list , Cc would be
preferred and trimming the list down to only relevant people would also
be preferred.
-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot