date:20190212

On 09/02/2019 13:14, Jagan Teki wrote:
> Enable SUN4I_SPI by default for ARCH_SUNXI, so that board
> that would require to enable DM_SPI that eventually enable
> the SUN4I_SPI driver.
> 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 15207d23c1..2fb4862c4a 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -224,6 +224,7 @@ config STM32_QSPI
>  
>  config SUN4I_SPI
>   bool "Allwinner A10/A31 SoCs SPI controller"
> + default ARCH_SUNXI

I don't think that's justified, only a few boards have SPI flash,
really, also it's a new driver that nobody desperately needed so far.

What about:
default y if ARCH_SUNXI && SPI

That would mean to just define CONFIG_SPI=y in a defconfig to enable SPI
(flash) support for a board.
Similar we should add
select DM_SPI if SPI
select DM_SPI_FLASH if SPI
to the ARCH_SUNXI stanza in arch/arm/Kconfig

Cheers,
Andre.

>   help
> This enables using the SPI controller on the Allwinner A10/A31 SoCs.
>  
> 

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

Re: [U-Boot] [PATCH 10/10] board: sopine: Enable SPI/SPI-FLASH

On 09/02/2019 13:15, Jagan Teki wrote:
> Sopine has Winbond SPI flash, so enable the same to use
> flash on Sopine board.
> 
> Signed-off-by: Jagan Teki 
> ---
>  arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi | 12 
>  configs/sopine_baseboard_defconfig   |  4 
>  2 files changed, 16 insertions(+)
>  create mode 100644 arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
> 
> diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi 
> b/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
> new file mode 100644
> index 00..02b1ae046e
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
> @@ -0,0 +1,12 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Jagan Teki 
> + */
> +
> +#include "sunxi-u-boot.dtsi"
> +
> +/ {
> + aliases {
> + spi0 = 
> + };
> +};
> diff --git a/configs/sopine_baseboard_defconfig 
> b/configs/sopine_baseboard_defconfig
> index 9d7e3a2b6c..a94e3c21fd 100644
> --- a/configs/sopine_baseboard_defconfig
> +++ b/configs/sopine_baseboard_defconfig
> @@ -10,11 +10,15 @@ CONFIG_MMC0_CD_PIN=""
>  CONFIG_MMC_SUNXI_SLOT_EXTRA=2
>  CONFIG_SPL_SPI_SUNXI=y
>  CONFIG_NR_DRAM_BANKS=1
> +CONFIG_CMD_SF=y
>  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
>  # CONFIG_CMD_FLASH is not set
>  # CONFIG_SPL_DOS_PARTITION is not set
>  # CONFIG_SPL_EFI_PARTITION is not set
>  CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-sopine-baseboard"
> +CONFIG_DM_SPI=y
> +CONFIG_DM_SPI_FLASH=y
> +CONFIG_SPI_FLASH_WINBOND=y

That isn't enough, you need CONFIG_SPI=y as well, otherwise the build fails.
I'd suggest to move DM_SPI=y and DM_SPI_FLASH=y to arch/arm/Kconfig (as
mentioned in the previous mail) and keep CONFIG_SPI=y here, to enable
SPI support for a particular board. Then keep ..._WINBOND here to set
the flash chip. For which you need CONFIG_SPI_FLASH, I believe. Which
sounds somewhat weird.

Cheers,
Andre.

>  CONFIG_SUN8I_EMAC=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_OHCI_HCD=y
> 

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

Re: [U-Boot] [PATCH 08/10] spi: sun4i: Driver cleanup

On 09/02/2019 13:14, Jagan Teki wrote:
> - drop unused macros.
> - use base instead of base_addr, for better code readability
> - move .probe and .ofdata_to_platdata functions in required
>   places to add platdata support in future.
> - use sentinel sun4i_spi_ids.
> 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/sun4i_spi.c | 224 +---
>  1 file changed, 97 insertions(+), 127 deletions(-)
> 
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index 36f2215f7d..a32f511245 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -33,57 +33,16 @@
>  
>  #include 
>  
> -#define SUN4I_RXDATA_REG 0x00
> -
> -#define SUN4I_TXDATA_REG 0x04
> -
> -#define SUN4I_CTL_REG0x08
> -#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_LOW  BIT(4)
> -#define SUN4I_CTL_LMTF   BIT(6)
> -#define SUN4I_CTL_TF_RST BIT(8)
> -#define SUN4I_CTL_RF_RST BIT(9)
> -#define SUN4I_CTL_XCHBIT(10)
> -#define SUN4I_CTL_CS_MASK0x3000
> -#define SUN4I_CTL_CS(cs) (((cs) << 12) & SUN4I_CTL_CS_MASK)
> -#define SUN4I_CTL_DHBBIT(15)
> -#define SUN4I_CTL_CS_MANUAL  BIT(16)
> -#define SUN4I_CTL_CS_LEVEL   BIT(17)
> -#define SUN4I_CTL_TP BIT(18)
> -
> -#define SUN4I_INT_CTL_REG0x0c
> -#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_REG0x10
> -
> -#define SUN4I_DMA_CTL_REG0x14
> -
> -#define SUN4I_WAIT_REG   0x18
> -
> -#define SUN4I_CLK_CTL_REG0x1c
> -#define SUN4I_CLK_CTL_CDR2_MASK  0xff
> -#define SUN4I_CLK_CTL_CDR2(div)  ((div) & 
> SUN4I_CLK_CTL_CDR2_MASK)
> -#define SUN4I_CLK_CTL_CDR1_MASK  0xf
> -#define SUN4I_CLK_CTL_CDR1(div)  (((div) & 
> SUN4I_CLK_CTL_CDR1_MASK) << 8)
> -#define SUN4I_CLK_CTL_DRSBIT(12)
> -
> -#define SUN4I_MAX_XFER_SIZE  0xff
> -
> -#define SUN4I_BURST_CNT_REG  0x20
> -#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)
> +DECLARE_GLOBAL_DATA_PTR;
>  
> -#define SUN4I_FIFO_STA_REG   0x28
> -#define SUN4I_FIFO_STA_RF_CNT_BITS   0
> -#define SUN4I_FIFO_STA_TF_CNT_MASK   0x7f
> -#define SUN4I_FIFO_STA_TF_CNT_BITS   16
> +/* sun4i spi registers */
> +#define SUN4I_RXDATA_REG 0x00
> +#define SUN4I_TXDATA_REG 0x04
> +#define SUN4I_CTL_REG0x08
> +#define SUN4I_CLK_CTL_REG0x1c
> +#define SUN4I_BURST_CNT_REG  0x20
> +#define SUN4I_XMIT_CNT_REG   0x24
> +#define SUN4I_FIFO_STA_REG   0x28
>  
>  /* sun6i spi registers */
>  #define SUN6I_GBL_CTL_REG0x04
> @@ -97,10 +56,23 @@
>  #define SUN6I_TXDATA_REG 0x200
>  #define SUN6I_RXDATA_REG 0x300
>  
> -#define SUN4I_SPI_MAX_RATE   2400
> -#define SUN4I_SPI_MIN_RATE   3000
> -#define SUN4I_SPI_DEFAULT_RATE   100
> -#define SUN4I_SPI_TIMEOUT_US 100
> +/* sun spi bits */
> +#define SUN4I_CTL_ENABLE BIT(0)
> +#define SUN4I_CTL_MASTER BIT(1)
> +#define SUN4I_CLK_CTL_CDR2_MASK  0xff
> +#define SUN4I_CLK_CTL_CDR2(div)  ((div) & 
> SUN4I_CLK_CTL_CDR2_MASK)
> +#define SUN4I_CLK_CTL_CDR1_MASK  0xf
> +#define SUN4I_CLK_CTL_CDR1(div)  (((div) & 
> SUN4I_CLK_CTL_CDR1_MASK) << 8)
> +#define SUN4I_CLK_CTL_DRSBIT(12)
> +#define SUN4I_MAX_XFER_SIZE  0xff
> +#define SUN4I_BURST_CNT(cnt) ((cnt) & SUN4I_MAX_XFER_SIZE)
> +#define SUN4I_XMIT_CNT(cnt)  ((cnt) & SUN4I_MAX_XFER_SIZE)
> +#define SUN4I_FIFO_STA_RF_CNT_BITS   0
> +
> +#define SUN4I_SPI_MAX_RATE   2400
> +#define SUN4I_SPI_MIN_RATE   3000
> +#define SUN4I_SPI_DEFAULT_RATE   100
> +#define SUN4I_SPI_TIMEOUT_US 100
>  
>  /* sun spi register set */
>  enum sun4i_spi_regs {
> @@ -140,7 +112,7 @@ struct sun4i_spi_variant {
>  
>  struct sun4i_spi_platdata {
>   struct sun4i_spi_variant *variant;
> - u32 base_addr;
> + u32 base;
>   u32 max_hz;
>  };
>  
> @@ -148,7 +120,7 @@ struct sun4i_spi_priv {
>   struct sun4i_spi_variant *variant;
>   struct clk clk_ahb, clk_mod;
>   struct reset_ctl reset;
> - u32 base_addr;
> + u32 base;
>   u32 freq;
>   u32 mode;
>  
> @@ -156,15 +128,13 @@ struct sun4i_spi_priv {
>   u8 *rx_buf;
>  };
>  
> -DECLARE_GLOBAL_DATA_PTR;
> -
>  static inline void sun4i_spi_drain_fifo(struct sun4i_spi_priv *priv, int len)

Re: [U-Boot] [PATCH 06/10] spi: sun4i: Add CLK support

On 09/02/2019 13:14, Jagan Teki wrote:
> Add CLK support to enable AHB and MOD SPI clocks on sun4i_spi driver.
> 
> Note, that the code will enable and disable clock in claim and release
> calls to make proper clock and reset handling between claiming and
> releasing SPI bus.
> 
> Signed-off-by: Jagan Teki 

That looks alright to me, but I wonder if you should introduce the reset
support here as well. Since it's optional, it shouldn't hurt to have it
in already, even though the SUN4I generation doesn't need it.

Cheers,
Andre.

> ---
>  drivers/spi/sun4i_spi.c | 56 +++--
>  1 file changed, 48 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index d3cf25db6f..aeed68764c 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -19,6 +19,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,8 +30,6 @@
>  #include 
>  #include 
>  
> -#include 
> -
>  #include 
>  
>  #define SUN4I_RXDATA_REG 0x00
> @@ -133,6 +132,7 @@ struct sun4i_spi_platdata {
>  
>  struct sun4i_spi_priv {
>   struct sun4i_spi_variant *variant;
> + struct clk clk_ahb, clk_mod;
>   u32 base_addr;
>   u32 freq;
>   u32 mode;
> @@ -263,13 +263,34 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
>   return 0;
>  }
>  
> -static inline void sun4i_spi_enable_clock(void)
> +static inline int sun4i_spi_set_clock(struct udevice *dev, bool enable)
>  {
> - struct sunxi_ccm_reg *const ccm =
> - (struct sunxi_ccm_reg *const)SUNXI_CCM_BASE;
> + struct sun4i_spi_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + if (!enable) {
> + clk_disable(>clk_ahb);
> + clk_disable(>clk_mod);
> + return 0;
> + }
>  
> - setbits_le32(>ahb_gate0, (1 << AHB_GATE_OFFSET_SPI0));
> - writel((1 << 31), >spi0_clk_cfg);
> + ret = clk_enable(>clk_ahb);
> + if (ret) {
> + dev_err(dev, "failed to enable ahb clock (ret=%d)\n", ret);
> + return ret;
> + }
> +
> + ret = clk_enable(>clk_mod);
> + if (ret) {
> + dev_err(dev, "failed to enable mod clock (ret=%d)\n", ret);
> + goto err_ahb;
> + }
> +
> + return 0;
> +
> +err_ahb:
> + clk_disable(>clk_ahb);
> + return ret;
>  }
>  
>  static int sun4i_spi_ofdata_to_platdata(struct udevice *bus)
> @@ -293,8 +314,20 @@ static int sun4i_spi_probe(struct udevice *bus)
>  {
>   struct sun4i_spi_platdata *plat = dev_get_platdata(bus);
>   struct sun4i_spi_priv *priv = dev_get_priv(bus);
> + int ret;
> +
> + ret = clk_get_by_name(bus, "ahb", >clk_ahb);
> + if (ret) {
> + dev_err(dev, "failed to get ahb clock\n");
> + return ret;
> + }
> +
> + ret = clk_get_by_name(bus, "mod", >clk_mod);
> + if (ret) {
> + dev_err(dev, "failed to get mod clock\n");
> + return ret;
> + }
>  
> - sun4i_spi_enable_clock();
>   sun4i_spi_parse_pins(bus);
>  
>   priv->variant = plat->variant;
> @@ -308,6 +341,11 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
>  {
>   struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
>   struct sun4i_spi_variant *variant = priv->variant;
> + int ret;
> +
> + ret = sun4i_spi_set_clock(dev->parent, true);
> + if (ret)
> + return ret;
>  
>   setbits_le32(priv->base_addr + variant->regs[SPI_GCR],
>SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER |
> @@ -328,6 +366,8 @@ static int sun4i_spi_release_bus(struct udevice *dev)
>   clrbits_le32(priv->base_addr + variant->regs[SPI_GCR],
>SUN4I_CTL_ENABLE);
>  
> + sun4i_spi_set_clock(dev->parent, false);
> +
>   return 0;
>  }
>  
> 

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

Re: [U-Boot] [PATCH 07/10] spi: sun4: Add A31 spi controller support

On 09/02/2019 13:14, Jagan Teki wrote:
> Add A31 spi controller support for existing sun4i_spi driver via driver
> data, this would simply add A31 register along with proper register bits
> via enum sets.
> 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/Kconfig |  4 +-
>  drivers/spi/sun4i_spi.c | 84 -
>  2 files changed, 85 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index ac7fbab841..15207d23c1 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -223,9 +223,9 @@ config STM32_QSPI
> this ST IP core.
>  
>  config SUN4I_SPI
> - bool "Allwinner A10 SoCs SPI controller"
> + bool "Allwinner A10/A31 SoCs SPI controller"
>   help
> -   SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
> +   This enables using the SPI controller on the Allwinner A10/A31 SoCs.
>  
>  config TEGRA114_SPI
>   bool "nVidia Tegra114 SPI driver"
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index aeed68764c..36f2215f7d 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -84,6 +85,18 @@
>  #define SUN4I_FIFO_STA_TF_CNT_MASK   0x7f
>  #define SUN4I_FIFO_STA_TF_CNT_BITS   16
>  
> +/* sun6i spi registers */
> +#define SUN6I_GBL_CTL_REG0x04
> +#define SUN6I_TFR_CTL_REG0x08
> +#define SUN6I_FIFO_CTL_REG   0x18
> +#define SUN6I_FIFO_STA_REG   0x1c
> +#define SUN6I_CLK_CTL_REG0x24
> +#define SUN6I_BURST_CNT_REG  0x30
> +#define SUN6I_XMIT_CNT_REG   0x34
> +#define SUN6I_BURST_CTL_REG  0x38
> +#define SUN6I_TXDATA_REG 0x200
> +#define SUN6I_RXDATA_REG 0x300
> +
>  #define SUN4I_SPI_MAX_RATE   2400
>  #define SUN4I_SPI_MIN_RATE   3000
>  #define SUN4I_SPI_DEFAULT_RATE   100
> @@ -106,6 +119,7 @@ enum sun4i_spi_regs {
>  /* sun spi register bits */
>  enum sun4i_spi_bits {
>   SPI_GCR_TP,
> + SPI_GCR_SRST,
>   SPI_TCR_CPHA,
>   SPI_TCR_CPOL,
>   SPI_TCR_CS_ACTIVE_LOW,
> @@ -133,6 +147,7 @@ struct sun4i_spi_platdata {
>  struct sun4i_spi_priv {
>   struct sun4i_spi_variant *variant;
>   struct clk clk_ahb, clk_mod;
> + struct reset_ctl reset;
>   u32 base_addr;
>   u32 freq;
>   u32 mode;
> @@ -255,7 +270,10 @@ static int sun4i_spi_parse_pins(struct udevice *dev)
>   if (pin < 0)
>   break;
>  
> - sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SPI0);
> + if (IS_ENABLED(CONFIG_MACH_SUN50I))
> + sunxi_gpio_set_cfgpin(pin, SUN50I_GPC_SPI0);
> + else
> + sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SPI0);
>   sunxi_gpio_set_drv(pin, drive);
>   sunxi_gpio_set_pull(pin, pull);
>   }
> @@ -271,6 +289,8 @@ static inline int sun4i_spi_set_clock(struct udevice 
> *dev, bool enable)
>   if (!enable) {
>   clk_disable(>clk_ahb);
>   clk_disable(>clk_mod);
> + if (reset_valid(>reset))
> + reset_assert(>reset);
>   return 0;
>   }
>  
> @@ -286,8 +306,18 @@ static inline int sun4i_spi_set_clock(struct udevice 
> *dev, bool enable)
>   goto err_ahb;
>   }
>  
> + if (reset_valid(>reset)) {
> + ret = reset_deassert(>reset);
> + if (ret) {
> + dev_err(dev, "failed to deassert reset\n");
> + goto err_mod;
> + }
> + }
> +
>   return 0;
>  
> +err_mod:
> + clk_disable(>clk_mod);
>  err_ahb:
>   clk_disable(>clk_ahb);
>   return ret;
> @@ -328,6 +358,12 @@ static int sun4i_spi_probe(struct udevice *bus)
>   return ret;
>   }
>  
> + ret = reset_get_by_index(bus, 0, >reset);
> + if (ret && ret != -ENOENT) {
> + dev_err(dev, "failed to get reset\n");
> + return ret;
> + }
> +
>   sun4i_spi_parse_pins(bus);
>  
>   priv->variant = plat->variant;
> @@ -351,6 +387,10 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
>SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER |
>variant->bits[SPI_GCR_TP]);
>  
> + if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I))
> + setbits_le32(priv->base_addr + variant->regs[SPI_GCR],
> +  variant->bits[SPI_GCR_SRST]);
> +

Just a note: This makes the driver only support one class of device, set
at compile time. Which means we could have used an #ifdef approach from
the beginning 
Can you make this dependent on some bits in variant? That should solve it.

>   setbits_le32(priv->base_addr + variant->regs[SPI_TCR],
>variant->bits[SPI_TCR_CS_MANUAL] |
>

Re: [U-Boot] [PATCH 05/10] spi: sun4i: Support fifo_depth via drvdata

On 09/02/2019 13:14, Jagan Teki wrote:
> Support fifo_depth via drvdata instead of macro definition, this would
> eventually reduce another macro definition for new SPI controller fifo
> depth support addition.
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  drivers/spi/sun4i_spi.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index c06028890b..d3cf25db6f 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -33,8 +33,6 @@
>  
>  #include 
>  
> -#define SUN4I_FIFO_DEPTH 64
> -
>  #define SUN4I_RXDATA_REG 0x00
>  
>  #define SUN4I_TXDATA_REG 0x04
> @@ -124,6 +122,7 @@ enum sun4i_spi_bits {
>  
>  struct sun4i_spi_variant {
>   const unsigned long *regs, *bits;
> + u32 fifo_depth;
>  };
>  
>  struct sun4i_spi_platdata {
> @@ -363,7 +362,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>  
>   while (len) {
>   /* Setup the transfer now... */
> - nbytes = min(len, (u32)(SUN4I_FIFO_DEPTH - 1));
> + nbytes = min(len, (priv->variant->fifo_depth - 1));
>  
>   /* Setup the counters */
>   writel(SUN4I_BURST_CNT(nbytes),
> @@ -511,6 +510,7 @@ static const unsigned long sun4i_spi_bits[] = {
>  static const struct sun4i_spi_variant sun4i_a10_spi_variant = {
>   .regs   = sun4i_spi_regs,
>   .bits   = sun4i_spi_bits,
> + .fifo_depth = 64,
>  };
>  
>  static const struct udevice_id sun4i_spi_ids[] = {
> 

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

Re: [U-Boot] [PATCH 03/10] spi: sun4i: Simplify reg writes using set/clrbits_le32

On 09/02/2019 13:14, Jagan Teki wrote:
> Update the existing register writes using setbits_le32 and
> clrbits_le32 in required places.
> 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/sun4i_spi.c | 21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index 87b396a96e..5446cebe7c 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -283,20 +283,18 @@ static int sun4i_spi_claim_bus(struct udevice *dev)
>  {
>   struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
>  
> - writel(SUN4I_CTL_ENABLE | SUN4I_CTL_MASTER | SUN4I_CTL_TP |
> -SUN4I_CTL_CS_MANUAL | SUN4I_CTL_CS_ACTIVE_LOW,
> ->regs->ctl);
> + setbits_le32(>regs->ctl, SUN4I_CTL_ENABLE |
> +  SUN4I_CTL_MASTER | SUN4I_CTL_TP |
> +  SUN4I_CTL_CS_MANUAL | SUN4I_CTL_CS_ACTIVE_LOW);
> +

Careful, this changes semantics. The original call explicitly cleared
all the remaining bits, which is important for the setup (some bits are
default 1).
And besides I am not sure what this change would improve anyway, as it
isn't shorter. If at all, I'd use clrsetbits_le32(), to mask off the
reserved bits 31:21.

Rest is fine.

Cheers,
Andre.


>   return 0;
>  }
>  
>  static int sun4i_spi_release_bus(struct udevice *dev)
>  {
>   struct sun4i_spi_priv *priv = dev_get_priv(dev->parent);
> - u32 reg;
>  
> - reg = readl(>regs->ctl);
> - reg &= ~SUN4I_CTL_ENABLE;
> - writel(reg, >regs->ctl);
> + clrbits_le32(>regs->ctl, SUN4I_CTL_ENABLE);
>  
>   return 0;
>  }
> @@ -309,7 +307,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
>  
>   u32 len = bitlen / 8;
> - u32 reg, rx_fifocnt;
> + u32 rx_fifocnt;
>   u8 nbytes;
>   int ret;
>  
> @@ -324,10 +322,8 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>   if (flags & SPI_XFER_BEGIN)
>   sun4i_spi_set_cs(bus, slave_plat->cs, true);
>  
> - reg = readl(>regs->ctl);
> -
>   /* Reset FIFOs */
> - writel(reg | SUN4I_CTL_RF_RST | SUN4I_CTL_TF_RST, >regs->ctl);
> + setbits_le32(>regs->ctl, SUN4I_CTL_RF_RST | SUN4I_CTL_TF_RST);
>  
>   while (len) {
>   /* Setup the transfer now... */
> @@ -341,8 +337,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>   sun4i_spi_fill_fifo(priv, nbytes);
>  
>   /* Start the transfer */
> - reg = readl(>regs->ctl);
> - writel(reg | SUN4I_CTL_XCH, >regs->ctl);
> + setbits_le32(>regs->ctl, SUN4I_CTL_XCH);
>  
>   /* Wait till RX FIFO to be empty */
>   ret = readl_poll_timeout(>regs->ctl, rx_fifocnt,
> 

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

Re: [U-Boot] [PATCH 04/10] spi: sun4i: Access registers and bits via enum offsets

On 09/02/2019 13:14, Jagan Teki wrote:
> Allwinner support two different SPI controllers one for A10 and
> another for A31 with minimal changes in register offsets and
> respective register bits, but the logic for accessing the SPI
> master via SPI slave remains nearly similar.
> 
> Add enum offsets for register set and register bits, so-that
> it can access both classes of SPI controllers.
> 
> Assign same control register for global, transfer and fifo control
> registers to make the same code compatible with A31 SPI controller.
> 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/sun4i_spi.c | 162 +---
>  1 file changed, 120 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index 5446cebe7c..c06028890b 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -83,7 +83,6 @@
>  #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
> @@ -93,28 +92,49 @@
>  #define SUN4I_SPI_DEFAULT_RATE   100
>  #define SUN4I_SPI_TIMEOUT_US 100
>  
> -/* sun4i spi register set */
> -struct sun4i_spi_regs {
> - u32 rxdata;
> - u32 txdata;
> - u32 ctl;
> - u32 intctl;
> - u32 st;
> - u32 dmactl;
> - u32 wait;
> - u32 cctl;
> - u32 bc;
> - u32 tc;
> - u32 fifo_sta;
> +/* sun spi register set */
> +enum sun4i_spi_regs {
> + SPI_GCR,
> + SPI_TCR,
> + SPI_FCR,
> + SPI_FSR,
> + SPI_CCR,
> + SPI_BC,
> + SPI_TC,
> + SPI_BCTL,
> + SPI_TXD,
> + SPI_RXD,
> +};
> +
> +/* sun spi register bits */
> +enum sun4i_spi_bits {
> + SPI_GCR_TP,
> + SPI_TCR_CPHA,
> + SPI_TCR_CPOL,
> + SPI_TCR_CS_ACTIVE_LOW,
> + SPI_TCR_CS_SEL,
> + SPI_TCR_CS_MASK,
> + SPI_TCR_XCH,
> + SPI_TCR_CS_MANUAL,
> + SPI_TCR_CS_LEVEL,
> + SPI_FCR_TF_RST,
> + SPI_FCR_RF_RST,
> + SPI_FSR_RF_CNT_MASK,
> +};
> +
> +struct sun4i_spi_variant {
> + const unsigned long *regs, *bits;
>  };
>  
>  struct sun4i_spi_platdata {
> + struct sun4i_spi_variant *variant;
>   u32 base_addr;
>   u32 max_hz;
>  };
>  
>  struct sun4i_spi_priv {
> - struct sun4i_spi_regs *regs;
> + struct sun4i_spi_variant *variant;
> + u32 base_addr;
>   u32 freq;
>   u32 mode;
>  
> @@ -126,10 +146,11 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  static inline void sun4i_spi_drain_fifo(struct sun4i_spi_priv *priv, int len)
>  {
> + struct sun4i_spi_variant *variant = priv->variant;
>   u8 byte;
>  
>   while (len--) {
> - byte = readb(>regs->rxdata);
> + byte = readb(priv->base_addr + variant->regs[SPI_RXD]);

What about making this register address calculation a macro? That would
also allow you to save the variant variable everywhere.

#define SPI_REG(priv, reg) ((priv)->base_addr + \
(priv)->variant->regs[reg])

Cheers,
Andre.


>   if (priv->rx_buf)
>   *priv->rx_buf++ = byte;
>   }
> @@ -137,30 +158,33 @@ static inline void sun4i_spi_drain_fifo(struct 
> sun4i_spi_priv *priv, int len)
>  
>  static inline void sun4i_spi_fill_fifo(struct sun4i_spi_priv *priv, int len)
>  {
> + struct sun4i_spi_variant *variant = priv->variant;
>   u8 byte;
>  
>   while (len--) {
>   byte = priv->tx_buf ? *priv->tx_buf++ : 0;
> - writeb(byte, >regs->txdata);
> + writeb(byte, priv->base_addr + variant->regs[SPI_TXD]);
>   }
>  }
>  
>  static void sun4i_spi_set_cs(struct udevice *bus, u8 cs, bool enable)
>  {
>   struct sun4i_spi_priv *priv = dev_get_priv(bus);
> + struct sun4i_spi_variant *variant = priv->variant;
>   u32 reg;
>  
> - reg = readl(>regs->ctl);
> + reg = readl(priv->base_addr + variant->regs[SPI_TCR]);
>  
> - reg &= ~SUN4I_CTL_CS_MASK;
> - reg |= SUN4I_CTL_CS(cs);
> + reg &= ~variant->bits[SPI_TCR_CS_MASK];
> + reg |= ((cs << variant->bits[SPI_TCR_CS_SEL]) &
> + variant->bits[SPI_TCR_CS_MASK]);
>  
>   if (enable)
> - reg &= ~SUN4I_CTL_CS_LEVEL;
> + reg &= ~variant->bits[SPI_TCR_CS_LEVEL];
>   else
> - reg |= SUN4I_CTL_CS_LEVEL;
> + reg |= variant->bits[SPI_TCR_CS_LEVEL];
>  
> - writel(reg, >regs->ctl);
> + writel(reg, priv->base_addr + variant->regs[SPI_TCR]);
>  }
>  
>  static int sun4i_spi_parse_pins(struct udevice *dev)
> @@ -255,6 +279,7 @@ static int sun4i_spi_ofdata_to_platdata(struct udevice 
> *bus)
>   int node = dev_of_offset(bus);
>  
>   plat->base_addr = devfdt_get_addr(bus);
> + plat->variant = (struct sun4i_spi_variant *)dev_get_driver_data(bus);
>   plat->max_hz = fdtdec_get_int(gd->fdt_blob, node,
>

Re: [U-Boot] [PATCH 02/10] clk: sunxi: Implement SPI clocks, resets

On 09/02/2019 13:14, Jagan Teki wrote:
> - Implement SPI AHB, MOD clocks via ccu_clk_gate for all
>   supported Allwinner SoCs
> - Implement SPI resets via ccu_reset for all supported
>   Allwinner SoCs.
> 
> Signed-off-by: Jagan Teki 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  drivers/clk/sunxi/clk_a10.c  | 10 ++
>  drivers/clk/sunxi/clk_a10s.c |  7 +++
>  drivers/clk/sunxi/clk_a23.c  |  7 +++
>  drivers/clk/sunxi/clk_a31.c  | 13 +
>  drivers/clk/sunxi/clk_a64.c  |  7 +++
>  drivers/clk/sunxi/clk_a80.c  | 13 +
>  drivers/clk/sunxi/clk_a83t.c |  7 +++
>  drivers/clk/sunxi/clk_h3.c   |  7 +++
>  drivers/clk/sunxi/clk_h6.c   |  9 +
>  drivers/clk/sunxi/clk_r40.c  | 13 +
>  drivers/clk/sunxi/clk_v3s.c  |  4 
>  11 files changed, 97 insertions(+)
> 
> diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
> index 2aa41efe17..b8b57e2b31 100644
> --- a/drivers/clk/sunxi/clk_a10.c
> +++ b/drivers/clk/sunxi/clk_a10.c
> @@ -22,6 +22,10 @@ static struct ccu_clk_gate a10_gates[] = {
>   [CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
>   [CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
>   [CLK_AHB_MMC3]  = GATE(0x060, BIT(11)),
> + [CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
> + [CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
> + [CLK_AHB_SPI2]  = GATE(0x060, BIT(22)),
> + [CLK_AHB_SPI3]  = GATE(0x060, BIT(23)),
>  
>   [CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
>   [CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
> @@ -32,9 +36,15 @@ static struct ccu_clk_gate a10_gates[] = {
>   [CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
>   [CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
>  
> + [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
> + [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
> + [CLK_SPI2]  = GATE(0x0a8, BIT(31)),
> +
>   [CLK_USB_OHCI0] = GATE(0x0cc, BIT(6)),
>   [CLK_USB_OHCI1] = GATE(0x0cc, BIT(7)),
>   [CLK_USB_PHY]   = GATE(0x0cc, BIT(8)),
> +
> + [CLK_SPI3]  = GATE(0x0d4, BIT(31)),
>  };
>  
>  static struct ccu_reset a10_resets[] = {
> diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
> index 87b74e52dc..c6fcede822 100644
> --- a/drivers/clk/sunxi/clk_a10s.c
> +++ b/drivers/clk/sunxi/clk_a10s.c
> @@ -19,12 +19,19 @@ static struct ccu_clk_gate a10s_gates[] = {
>   [CLK_AHB_MMC0]  = GATE(0x060, BIT(8)),
>   [CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
>   [CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
> + [CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
> + [CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
> + [CLK_AHB_SPI2]  = GATE(0x060, BIT(22)),
>  
>   [CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
>   [CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
>   [CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
>   [CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
>  
> + [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
> + [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
> + [CLK_SPI2]  = GATE(0x0a8, BIT(31)),
> +
>   [CLK_USB_OHCI]  = GATE(0x0cc, BIT(6)),
>   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
>   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
> diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
> index 1ef2359286..c16019215e 100644
> --- a/drivers/clk/sunxi/clk_a23.c
> +++ b/drivers/clk/sunxi/clk_a23.c
> @@ -16,6 +16,8 @@ static struct ccu_clk_gate a23_gates[] = {
>   [CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
>   [CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
>   [CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
> + [CLK_BUS_SPI0]  = GATE(0x060, BIT(20)),
> + [CLK_BUS_SPI1]  = GATE(0x060, BIT(21)),
>   [CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
>   [CLK_BUS_EHCI]  = GATE(0x060, BIT(26)),
>   [CLK_BUS_OHCI]  = GATE(0x060, BIT(29)),
> @@ -26,6 +28,9 @@ static struct ccu_clk_gate a23_gates[] = {
>   [CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
>   [CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
>  
> + [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
> + [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
> +
>   [CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
>   [CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
>   [CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
> @@ -41,6 +46,8 @@ static struct ccu_reset a23_resets[] = {
>   [RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
>   [RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
>   [RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
> + [RST_BUS_SPI0]  = RESET(0x2c0, BIT(20)),
> + [RST_BUS_SPI1]  = RESET(0x2c0, BIT(21)),
>   [RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
>   [RST_BUS_EHCI]  = RESET(0x2c0, BIT(26)),
>

Re: [U-Boot] [PATCH 01/10] spi: sun4i: Poll for rxfifo empty

On Sat,  9 Feb 2019 18:44:51 +0530
Jagan Teki  wrote:

Hi,

> To drain rx fifo the fifo need to poll till the fifo
> count become empty.
> 
> The current code is using wait_for_bit logic on control
> register with exchange burst mode mask, which is not a
> proper way of waiting for draining fifo.
> 
> So, add code for polling fifo status register till rxfifo
> count become empty.
> 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/sun4i_spi.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> index 38cc743c61..87b396a96e 100644
> --- a/drivers/spi/sun4i_spi.c
> +++ b/drivers/spi/sun4i_spi.c
> @@ -31,6 +31,8 @@
>  
>  #include 
>  
> +#include 
> +
>  #define SUN4I_FIFO_DEPTH 64
>  
>  #define SUN4I_RXDATA_REG 0x00
> @@ -46,7 +48,6 @@
>  #define SUN4I_CTL_LMTF   BIT(6)
>  #define SUN4I_CTL_TF_RST BIT(8)
>  #define SUN4I_CTL_RF_RST BIT(9)
> -#define SUN4I_CTL_XCH_MASK   0x0400
>  #define SUN4I_CTL_XCHBIT(10)
>  #define SUN4I_CTL_CS_MASK0x3000
>  #define SUN4I_CTL_CS(cs) (((cs) << 12) & SUN4I_CTL_CS_MASK)
> @@ -308,7 +309,7 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
>  
>   u32 len = bitlen / 8;
> - u32 reg;
> + u32 reg, rx_fifocnt;
>   u8 nbytes;
>   int ret;
>  
> @@ -343,10 +344,12 @@ static int sun4i_spi_xfer(struct udevice *dev, unsigned 
> int bitlen,
>   reg = readl(>regs->ctl);
>   writel(reg | SUN4I_CTL_XCH, >regs->ctl);
>  
> - /* Wait transfer to complete */
> - ret = wait_for_bit_le32(>regs->ctl, SUN4I_CTL_XCH_MASK,
> - false, SUN4I_SPI_TIMEOUT_US, false);
> - if (ret) {
> + /* Wait till RX FIFO to be empty */
> + ret = readl_poll_timeout(>regs->ctl, rx_fifocnt,

That's not the right register, it should be regs->fifo_sta.

> +  !(((rx_fifocnt & 
> SUN4I_FIFO_STA_RF_CNT_MASK) >>
> +  SUN4I_FIFO_STA_RF_CNT_BITS) < nbytes),

I think removing the negation and using ">=" instead is less confusing.

Cheers,
Andre.


> +  SUN4I_SPI_TIMEOUT_US);
> + if (ret < 0) {
>   printf("ERROR: sun4i_spi: Timeout transferring data\n");
>   sun4i_spi_set_cs(bus, slave_plat->cs, false);
>   return ret;

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

Re: [U-Boot] [PATCH 1/1] test: let use gdbserver for all sandbox targets

On Tue, Feb 12, 2019 at 04:18:14PM +0200, Igor Opaniuk wrote:

> Enable usage of gdbserver for all sandbox targets (sandbox,
> sandbox_flattree etc.).
> 
> Signed-off-by: Igor Opaniuk 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/1] test/py: use default load address for tftp

On Sat, Jan 26, 2019 at 03:25:12PM +0100, Heinrich Schuchardt wrote:

> On x86_64 the size of the file u-boot loaded by the tftp test has grown in
> size such that when loading the file to 0x20 it overwrites a memory
> area reserved for PCI.
> 
> If no load address is specified for tftp do not use the ram base address
> (or if zero 0x20) but the default address.
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 09/13] mmc: sdhci: Make set_ios_post() return int

On Tue, Feb 12, 2019 at 02:28:15PM +0530, Faiz Abbas wrote:

> Make set_ios_post() return int to faciliate error handling in
> platform drivers.
> 
> Signed-off-by: Faiz Abbas 

Reviewed-by: Tom Rini 

-- 
Tom


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

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

On Tue, Feb 12, 2019 at 02:56:01PM +0800, Bin Meng wrote:

> Hi Tom,
> 
> This PR includes the following changes to x86:
> - edison switch to CONFIG_OF_SEPARATE
> - tangier initial ACPI support for PMIC device
> - tsc timer driver update to support native calibration
> - fixes to 64-bit U-Boot proper
> 
> The following changes since commit f94fa0e94f36c740d3c7aa314c89a750c742185b:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-i2c (2019-02-11
> 11:15:34 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-x86.git
> 
> for you to fetch changes up to 24b56e2bf369ac003ccaac37d8bb80e08b743e16:
> 
>   x86: tangier: Add initial ACPI support for PMIC device (2019-02-12
> 14:37:17 +0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v7 14/15] doc: Add a readme guide for SiFive FU540

2019-02-12 Thread Kevin Hilman

Anup Patel  writes:

> From: Atish Patra 
>
> The readme guide describes the procedure to build, flash and boot Linux
> using U-Boot on HiFive Unleashed. It also explains the current state of
> U-boot support and future action items.
>
> Signed-off-by: Atish Patra 
> Signed-off-by: Anup Patel 
> Reviewed-by: Lukas Auer 

I'm testing this with the mainline kernel (v5.0-rc6) and running into
some problems getting kernel output on the serial console.

[...]

> +=> setenv ethaddr 70:B3:D5:92:F0:C2
> +=> setenv ipaddr 10.196.157.189
> +=> setenv serverip 10.11.143.218
> +=> setenv gatewayip 10.196.156.1
> +=> setenv netmask 255.255.252.0
> +=> bdinfo
> +boot_params = 0x
> +DRAM bank   = 0x
> +-> start= 0x8000
> +-> size = 0x0002
> +relocaddr   = 0xfff9
> +reloc off   = 0x7fd9
> +ethaddr = 70:B3:D5:92:F0:C2
> +IP addr = 10.196.157.189
> +baudrate= 115200 bps
> +=> tftpboot uImage
> +ethernet@1009: PHY present at 0
> +ethernet@1009: Starting autonegotiation...
> +ethernet@1009: Autonegotiation complete
> +ethernet@1009: link up, 1000Mbps full-duplex (lpa: 0x3800)
> +Using ethernet@1009 device
> +TFTP from server 10.11.143.218; our IP address is 10.196.157.189; sending 
> through gateway 10.196.156.1
> +Filename 'uImage'.
> +Load address: 0x8020
> +Loading: #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + #
> + ##
> + 2.5 MiB/s
> +done
> +Bytes transferred = 14939132 (e3f3fc hex)
> +=> bootm 0x8020 - 0x8220

Re: [U-Boot] [PATCH] MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC

On Tue, Feb 12, 2019 at 03:44:05PM -0600, Adam Ford wrote:
> On Tue, Feb 12, 2019 at 3:41 PM Scott Wood  wrote:
> >
> > On Sun, 2019-02-10 at 07:48 -0600, Adam Ford wrote:
> > > On Sun, Feb 10, 2019 at 7:30 AM Adam Ford  wrote:
> > > >
> > > > On Mon, Feb 4, 2019 at 12:17 PM Tim Harvey  
> > > > wrote:
> > > > >
> > > > > On Wed, Jan 2, 2019 at 6:37 PM Adam Ford  wrote:
> > > > > >
> > > > > > The LogicPD board uses a Micron Flash with ECC.  To boot this from
> > > > > > SPL, the ECC needs to be correctly configured or the BCH engine
> > > > > > times out.
> > > > > >
> > > > > > Signed-off-by: Adam Ford 
> > > > > >
> > > > > > diff --git a/drivers/mtd/nand/raw/mxs_nand.c
> > > > > > b/drivers/mtd/nand/raw/mxs_nand.c
> > > > > > index e3341812a2..2d84bfffe2 100644
> > > > > > --- a/drivers/mtd/nand/raw/mxs_nand.c
> > > > > > +++ b/drivers/mtd/nand/raw/mxs_nand.c
> > > > > > @@ -1163,6 +1163,12 @@ int mxs_nand_init_spl(struct nand_chip *nand)
> > > > > >
> > > > > > nand_info->gpmi_regs = (struct mxs_gpmi_regs 
> > > > > > *)MXS_GPMI_BASE;
> > > > > > nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
> > > > > > +
> > > > > > +   if (is_mx6sx() || is_mx7())
> > > > > > +   nand_info->max_ecc_strength_supported = 62;
> > > > > > +   else
> > > > > > +   nand_info->max_ecc_strength_supported = 40;
> > > > > > +
> > > > > > err = mxs_nand_alloc_buffers(nand_info);
> > > > > > if (err)
> > > > > > return err;
> > > > > > diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > > > b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > > > index c628f3adec..ba85baac60 100644
> > > > > > --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > > > +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > > > @@ -201,6 +201,7 @@ static int mxs_nand_init(void)
> > > > > > /* setup flash layout (does not scan as we override that) */
> > > > > > mtd->size = nand_chip.chipsize;
> > > > > > nand_chip.scan_bbt(mtd);
> > > > > > +   mxs_nand_setup_ecc(mtd);
> > > > > >
> > > > > > return 0;
> > > > > >  }
> > > > > > --
> > > > > > 2.17.1
> > > > > >
> > > > >
> > > > > Thanks Adam,
> > >
> > >  Scott / Stefano,
> > >
> > > I had to use Scott's other -email.
> > >
> > >
> > >  Any chance this can get reviewed and/or applied for the next release?
> > >  We've got a few people who have their respective tested-by comments.
> >
> > I haven't been involved in U-Boot for a while now.
> 
> Tom / Stefano,
> 
> Patchwork is showing this is being delegated to Scott, but he's saying
> he isn't the right person.  Is there someone else who can review
> and/or apply a few of these patches designated to Scott?  Both of the
> patches I care about deligated to him are imx6 related

I've assigned the mxs related patches to Stefano, 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] MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC

On Tue, Feb 12, 2019 at 3:41 PM Scott Wood  wrote:
>
> On Sun, 2019-02-10 at 07:48 -0600, Adam Ford wrote:
> > On Sun, Feb 10, 2019 at 7:30 AM Adam Ford  wrote:
> > >
> > > On Mon, Feb 4, 2019 at 12:17 PM Tim Harvey  wrote:
> > > >
> > > > On Wed, Jan 2, 2019 at 6:37 PM Adam Ford  wrote:
> > > > >
> > > > > The LogicPD board uses a Micron Flash with ECC.  To boot this from
> > > > > SPL, the ECC needs to be correctly configured or the BCH engine
> > > > > times out.
> > > > >
> > > > > Signed-off-by: Adam Ford 
> > > > >
> > > > > diff --git a/drivers/mtd/nand/raw/mxs_nand.c
> > > > > b/drivers/mtd/nand/raw/mxs_nand.c
> > > > > index e3341812a2..2d84bfffe2 100644
> > > > > --- a/drivers/mtd/nand/raw/mxs_nand.c
> > > > > +++ b/drivers/mtd/nand/raw/mxs_nand.c
> > > > > @@ -1163,6 +1163,12 @@ int mxs_nand_init_spl(struct nand_chip *nand)
> > > > >
> > > > > nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
> > > > > nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
> > > > > +
> > > > > +   if (is_mx6sx() || is_mx7())
> > > > > +   nand_info->max_ecc_strength_supported = 62;
> > > > > +   else
> > > > > +   nand_info->max_ecc_strength_supported = 40;
> > > > > +
> > > > > err = mxs_nand_alloc_buffers(nand_info);
> > > > > if (err)
> > > > > return err;
> > > > > diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > > b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > > index c628f3adec..ba85baac60 100644
> > > > > --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > > +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > > @@ -201,6 +201,7 @@ static int mxs_nand_init(void)
> > > > > /* setup flash layout (does not scan as we override that) */
> > > > > mtd->size = nand_chip.chipsize;
> > > > > nand_chip.scan_bbt(mtd);
> > > > > +   mxs_nand_setup_ecc(mtd);
> > > > >
> > > > > return 0;
> > > > >  }
> > > > > --
> > > > > 2.17.1
> > > > >
> > > >
> > > > Thanks Adam,
> >
> >  Scott / Stefano,
> >
> > I had to use Scott's other -email.
> >
> >
> >  Any chance this can get reviewed and/or applied for the next release?
> >  We've got a few people who have their respective tested-by comments.
>
> I haven't been involved in U-Boot for a while now.

Tom / Stefano,

Patchwork is showing this is being delegated to Scott, but he's saying
he isn't the right person.  Is there someone else who can review
and/or apply a few of these patches designated to Scott?  Both of the
patches I care about deligated to him are imx6 related

thanks,

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

Re: [U-Boot] [PATCH] MTD: mxs_nand: Fix BCH read timeout error on boards requiring ECC

2019-02-12 Thread Scott Wood

On Sun, 2019-02-10 at 07:48 -0600, Adam Ford wrote:
> On Sun, Feb 10, 2019 at 7:30 AM Adam Ford  wrote:
> > 
> > On Mon, Feb 4, 2019 at 12:17 PM Tim Harvey  wrote:
> > > 
> > > On Wed, Jan 2, 2019 at 6:37 PM Adam Ford  wrote:
> > > > 
> > > > The LogicPD board uses a Micron Flash with ECC.  To boot this from
> > > > SPL, the ECC needs to be correctly configured or the BCH engine
> > > > times out.
> > > > 
> > > > Signed-off-by: Adam Ford 
> > > > 
> > > > diff --git a/drivers/mtd/nand/raw/mxs_nand.c
> > > > b/drivers/mtd/nand/raw/mxs_nand.c
> > > > index e3341812a2..2d84bfffe2 100644
> > > > --- a/drivers/mtd/nand/raw/mxs_nand.c
> > > > +++ b/drivers/mtd/nand/raw/mxs_nand.c
> > > > @@ -1163,6 +1163,12 @@ int mxs_nand_init_spl(struct nand_chip *nand)
> > > > 
> > > > nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
> > > > nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
> > > > +
> > > > +   if (is_mx6sx() || is_mx7())
> > > > +   nand_info->max_ecc_strength_supported = 62;
> > > > +   else
> > > > +   nand_info->max_ecc_strength_supported = 40;
> > > > +
> > > > err = mxs_nand_alloc_buffers(nand_info);
> > > > if (err)
> > > > return err;
> > > > diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > index c628f3adec..ba85baac60 100644
> > > > --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
> > > > @@ -201,6 +201,7 @@ static int mxs_nand_init(void)
> > > > /* setup flash layout (does not scan as we override that) */
> > > > mtd->size = nand_chip.chipsize;
> > > > nand_chip.scan_bbt(mtd);
> > > > +   mxs_nand_setup_ecc(mtd);
> > > > 
> > > > return 0;
> > > >  }
> > > > --
> > > > 2.17.1
> > > > 
> > > 
> > > Thanks Adam,
> 
>  Scott / Stefano,
> 
> I had to use Scott's other -email.
> 
> 
>  Any chance this can get reviewed and/or applied for the next release?
>  We've got a few people who have their respective tested-by comments.

I haven't been involved in U-Boot for a while now.

-Scott


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

Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards

2019-02-12 Thread Oleksandr



On 09.02.19 18:37, Marek Vasut wrote:

Hi


diff --git a/arch/arm/mach-rmobile/Kconfig.32
b/arch/arm/mach-rmobile/Kconfig.32
index 076a019..a2e9e3d 100644
--- a/arch/arm/mach-rmobile/Kconfig.32
+++ b/arch/arm/mach-rmobile/Kconfig.32
@@ -76,6 +76,8 @@ config TARGET_LAGER
    select SUPPORT_SPL
    select USE_TINY_PRINTF
    imply CMD_DM
+    select CPU_V7_HAS_NONSEC
+    select CPU_V7_HAS_VIRT

Shouldn't this be a H2 CPU property instead of a board property ?

Probably yes, sounds reasonable. I will move these options under
"config
R8A7790".


Does this apply to M2* too , since it has CA15 cores as well ?

I think, yes. But, without PSCI support being implemented for M2*, I
think it is not worth to select these options for it as well.

It's basically the same SoC with two CPU cores less, how would that PSCI
be any different on M2 ?

I need some time to investigate. I will come up with an answer later.

 From the first look:

1. It should be different total number of CPUs:

For R8A7790 we have the following:

#define R8A7790_PSCI_NR_CPUS    8

But for R8A7791 it seems we need to use:

#define R8A7791_PSCI_NR_CPUS    2

This information should be in the DT for each SoC, so you should extract
it from there.


2. It should be new pm-r8a7791.c file which will don't have any CA7
related stuff (CPU cores, SCU, etc).

I'd like to have a generic pm-gen2.c file , which parses the DT and
figures the configuration out that way. We are trying to get rid of all
the ad-hoc hardcoded configuration stuff in favor of DT.


Or it should be the single pm-r8a779x.c which must distinguish what SoC
is being used and do proper things.

Right



I agree to have a single generic pm-gen2.c file which covers all Gen2 SoCs.

But, unfortunately, I only have Stout boards (H2), and therefore can 
check only on them. This is why the current patch series adds support 
for H2 SoC only.


Theoretically, I could add support for M2 as well, but, I wouldn't have 
possibility to check.



I would focus on the r8a7790 for now, as the Stout board is our nearest 
target which we want to support in Xen and the PSCI feature is a 
mandatory option.


What do you think?



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

Re: [U-Boot] [PATCH v2] of-platdata: improve documentation

On Mon, Jan 21, 2019 at 12:26 PM  wrote:
>
> On Wed, 16 Jan 2019 at 12:40, Simon Goldschmidt
>  wrote:
> >
> > Improve some things in the documentation of OF_PLATDATA that I found
> > while porting socfgpa_gen5 to it.

Thanks for doing that.  I actually learned a bit.  :-)

This may be more directed at Simon, but it seems like many platforms
are limited in SPL and OF_PLATDATA might be a great feature to get
more drivers supporting device tree booting without as much overhead.

From how the documentation reads, it seems like the drivers may not
necessarily support OF_PLATDATA by default.  I've been struggling
trying to enable basic functions (like serial via 16550 driver)
because the platform data generated doesn't necessarily match the
platform data I use to start the serial device.  I would like to
migrate from using manually entered platform data to using OF_PLATDATA
to reduce the overhead.

A few things I noticed are that the generated device names correspond
to the names listed in the 'compatible' flag and there doesn't seem to
be a good way to link them to the actual driver name.

I see a few drivers that check for OF_PLATDATA, but I am not seeing
many people actually utilize this feature.  Any suggestions on how to
one might migrate a driver (like serial) which already supports
OF_CONTROL in u-boot, but the generated platdata doesn't boot in SPL?

adam
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> > Changes in v2:
> > - further fixes noted by Simon Glass
> > - added info about missing node relations
> > - moved the passage about phandles into section 'caveats'
> >
> >  doc/driver-model/of-plat.txt | 31 ---
> >  dts/Kconfig  |  6 ++
> >  2 files changed, 22 insertions(+), 15 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> Applied to u-boot-dm, thanks!
> ___
> 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

[U-Boot] [PATCH 1/1] efi_selftest: do not use efi_free_pool()

In efi_selftest we are in EFI land. We should not use U-Boot library
functions but boot time services for memory management.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_selftest/efi_selftest_block_device.c  | 2 +-
 lib/efi_selftest/efi_selftest_startimage_exit.c   | 2 +-
 lib/efi_selftest/efi_selftest_startimage_return.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/efi_selftest/efi_selftest_block_device.c 
b/lib/efi_selftest/efi_selftest_block_device.c
index 1cdd8307f4..21409aed6f 100644
--- a/lib/efi_selftest/efi_selftest_block_device.c
+++ b/lib/efi_selftest/efi_selftest_block_device.c
@@ -264,7 +264,7 @@ static int teardown(void)
}
 
if (image) {
-   r = efi_free_pool(image);
+   r = boottime->free_pool(image);
if (r != EFI_SUCCESS) {
efi_st_error("Failed to free image\n");
return EFI_ST_FAILURE;
diff --git a/lib/efi_selftest/efi_selftest_startimage_exit.c 
b/lib/efi_selftest/efi_selftest_startimage_exit.c
index 0d9e16437a..fa4b7d4a9b 100644
--- a/lib/efi_selftest/efi_selftest_startimage_exit.c
+++ b/lib/efi_selftest/efi_selftest_startimage_exit.c
@@ -103,7 +103,7 @@ static int teardown(void)
efi_status_t r = EFI_ST_SUCCESS;
 
if (image) {
-   r = efi_free_pool(image);
+   r = boottime->free_pool(image);
if (r != EFI_SUCCESS) {
efi_st_error("Failed to free image\n");
return EFI_ST_FAILURE;
diff --git a/lib/efi_selftest/efi_selftest_startimage_return.c 
b/lib/efi_selftest/efi_selftest_startimage_return.c
index 3c6249fdf1..fabf53d983 100644
--- a/lib/efi_selftest/efi_selftest_startimage_return.c
+++ b/lib/efi_selftest/efi_selftest_startimage_return.c
@@ -103,7 +103,7 @@ static int teardown(void)
efi_status_t r = EFI_ST_SUCCESS;
 
if (image) {
-   r = efi_free_pool(image);
+   r = boottime->free_pool(image);
if (r != EFI_SUCCESS) {
efi_st_error("Failed to free image\n");
return EFI_ST_FAILURE;
-- 
2.20.1

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

[U-Boot] [PATCH 1/1] efi_selftest: fix memory allocation in HII tests

In efi_selftest we are in EFI land. We cannot call U-Boot library
functions malloc() and free() but should use the boot time services
instead.

Signed-off-by: Heinrich Schuchardt 
---
There are still issues remaining in this test:
- not all allocated memory is freed
- variable ret used for efi_status_t returned by EFI services and for
  the selftest return value though both are of different type

But at least this correction is enough to allow efi_selftest() to be
called via EFI_CALL() and not crashing.
---
 lib/efi_selftest/efi_selftest_hii.c | 102 ++--
 1 file changed, 68 insertions(+), 34 deletions(-)

diff --git a/lib/efi_selftest/efi_selftest_hii.c 
b/lib/efi_selftest/efi_selftest_hii.c
index e38af7dbf8..8a0b3bc353 100644
--- a/lib/efi_selftest/efi_selftest_hii.c
+++ b/lib/efi_selftest/efi_selftest_hii.c
@@ -8,7 +8,6 @@
  */
 
 #include 
-#include 
 #include "efi_selftest_hii_data.c"
 
 #define PRINT_TESTNAME efi_st_printf("%s:\n", __func__)
@@ -192,9 +191,10 @@ static int test_hii_database_list_package_lists(void)
 (unsigned int)ret);
goto out;
}
-   handles = malloc(handles_size);
-   if (!handles) {
-   efi_st_error("malloc failed\n");
+   ret = boottime->allocate_pool(EFI_LOADER_DATA, handles_size,
+ (void **));
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("AllocatePool failed\n");
goto out;
}
ret = hii_database_protocol->list_package_lists(hii_database_protocol,
@@ -205,7 +205,11 @@ static int test_hii_database_list_package_lists(void)
 (unsigned int)ret);
goto out;
}
-   free(handles);
+   ret = boottime->free_pool(handles);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("FreePool failed\n");
+   goto out;
+   }
 
/* STRINGS */
handles = NULL;
@@ -219,9 +223,10 @@ static int test_hii_database_list_package_lists(void)
ret = EFI_ST_FAILURE;
goto out;
}
-   handles = malloc(handles_size);
-   if (!handles) {
-   efi_st_error("malloc failed\n");
+   ret = boottime->allocate_pool(EFI_LOADER_DATA, handles_size,
+ (void **));
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("AllocatePool failed\n");
ret = EFI_ST_FAILURE;
goto out;
}
@@ -234,7 +239,11 @@ static int test_hii_database_list_package_lists(void)
ret = EFI_ST_FAILURE;
goto out;
}
-   free(handles);
+   ret = boottime->free_pool(handles);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("FreePool failed\n");
+   goto out;
+   }
 
/* GUID */
handles = NULL;
@@ -248,9 +257,10 @@ static int test_hii_database_list_package_lists(void)
ret = EFI_ST_FAILURE;
goto out;
}
-   handles = malloc(handles_size);
-   if (!handles) {
-   efi_st_error("malloc failed\n");
+   ret = boottime->allocate_pool(EFI_LOADER_DATA, handles_size,
+ (void **));
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("AllocatePool failed\n");
ret = EFI_ST_FAILURE;
goto out;
}
@@ -263,7 +273,12 @@ static int test_hii_database_list_package_lists(void)
ret = EFI_ST_FAILURE;
goto out;
}
-   free(handles);
+   ret = boottime->free_pool(handles);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("FreePool failed\n");
+   ret = EFI_ST_FAILURE;
+   goto out;
+   }
 
/* KEYBOARD_LAYOUT */
handles = NULL;
@@ -277,9 +292,10 @@ static int test_hii_database_list_package_lists(void)
ret = EFI_ST_FAILURE;
goto out;
}
-   handles = malloc(handles_size);
-   if (!handles) {
-   efi_st_error("malloc failed\n");
+   ret = boottime->allocate_pool(EFI_LOADER_DATA, handles_size,
+ (void **));
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("AllocatePool failed\n");
ret = EFI_ST_FAILURE;
goto out;
}
@@ -292,7 +308,12 @@ static int test_hii_database_list_package_lists(void)
ret = EFI_ST_FAILURE;
goto out;
}
-   free(handles);
+   ret = boottime->free_pool(handles);
+   if (ret != EFI_SUCCESS) {
+   efi_st_error("FreePool failed\n");
+   ret = EFI_ST_FAILURE;
+   goto out;
+   }
 
result = EFI_ST_SUCCESS;
 
@@ -398,9 +419,10 @@ static int test_hii_database_find_keyboard_layouts(void)
 (unsigned int)ret);
goto out;
}
-

Re: [U-Boot] [PATCH v4 14/20] mtd: spi: Switch to new SPI NOR framework

On Tue, Feb 12, 2019 at 1:20 PM Adam Ford  wrote:
>
> On Sun, Feb 10, 2019 at 10:37 PM Vignesh R  wrote:
> >
> >
> >
> > On 11/02/19 9:01 AM, Adam Ford wrote:
> > > On Tue, Feb 5, 2019 at 12:00 AM Vignesh R  wrote:
> > >>
> > >> Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
> > >> layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
> > >> use new interfaces/definitions
> > >>
> > >> Signed-off-by: Vignesh R 
> > >> Tested-by: Simon Goldschmidt 
> > >> Tested-by: Stefan Roese 
> > >> Tested-by: Horatiu Vultur 
> > >> Reviewed-by: Jagan Teki 
> > >> Tested-by: Jagan Teki  #zynq-microzed
> > >
> > > This patch appears to break the da850_evm board which boots from SPI
> > > Flash and initializes the davinci driver with platdata since the
> > > device tree stuff does not quite work right in SPL.
> >
> > Oops, I did test on K2G EVM that has davinci SPI controller with micron
> > n25q flash but that was with DT. Not sure whats missing with platdata.
> >
> > >
> > > U-Boot SPL 2019.01-02923-gc4e8862308-dirty (Feb 10 2019 - 21:24:38 -0600)
> > > Trying to boot from SPI
> > > SPI probe failed.
> > > SPL: failed to boot from all boot devices
> > > ### ERROR ### Please RESET the board ###
> >
> > Could you enable debug prints at spi-mem level in drivers/spi/spi-mem.c
> > (especially debug prints at the end of spi_mem_exec_op()) and post the
> > logs here?
> >
> > >
> > > Any suggestions on how to fix the SPI initialization without needing
> > > the device tree?  I have tried to port the device tree stuff to SPL,
> > > but I haven't yet been successful so I have had to leave the platdata
> > > initialization in place.
> > >
> >
> > I haven't changed any driver names so, platdata to driver bindings
> > should still be the same. Could you verify if spi_nor_scan() is being
> > called in drivers/mtd/spi/spi-nor-tiny.c for SPL?
>
> I globally turned on DEBUG and I have two logs for you:
>
> Not working:
>
> U-Boot SPL 2019.01-02923-gc4e8862308-dirty (Feb 12 2019 - 13:04:19 -0600)
> Trying to boot from SPI
> uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 -1 'davinci_spi'
>- not found
> spi_get_bus_and_cs: Binding new device 'spi_flash', busnum=0, cs=0,
> driver=spi_flash_std
> spi_get_bus_and_cs: Error path, created=1, device 'spi_flash'
> SPI probe failed.
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> As a point of reference , I thought I'd show
> WORKING version (before this patch):
>
> U-Boot SPL 2019.01-02922-g2ee6705be0-dirty (Feb 12 2019 - 12:59:49 -0600)
> Trying to boot from SPI
> uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 -1 'davinci_spi'
>- not found
> spi_get_bus_and_cs: Binding new device 'spi_flash', busnum=0, cs=0,
> driver=spi_flash_std
> uclass_find_device_by_seq: 0 -1
> uclass_find_device_by_seq: 0 0
>- -1 -1 'spi_flash'
>- not found
> spi_flash_std_probe: slave=8001fd60, cs=0
> davinci_spi_set_speed speed 3000
> davinci_spi_set_mode mode 3
> davinci_spi_set_speed speed 3000
> davinci_spi_set_mode mode 3
> spi_get_bus_and_cs: bus=8001fbf4, slave=8001fd60
> SPL: payload image: U-Boot 2019.01-02922-g2ee6705be0   load addr:
> 0xc107ffc0 size: 405306
> Jumping to U-Boot
> loaded - jumping to U-Boot...
> image entry point: 0xc108
> ...
>
> During this process, I learned a few things.
> 1.  I am not really using the device tree during SPL like i originally
> thought and the OF_PLATDATA
> 2.  Getting SPL to support device tree with or without PLATDATA isn't
> as straightforward as I hoped
> 3.  With the knowledge I learned from item 1, I tried to disabled
> OF_CONTROL during SPL, but this patch also fails to build since it
> assumes OF_CONTROL is always enabled.
>
> If there are any suggestions you might have, I am willing to try them.
>

I beleive I have narrowed it down a bit to a chunk of code (int
device_probe(struct udevice *dev)) located in device.c:

/* Allocate private data if requested and not reentered */
if (drv->priv_auto_alloc_size && !dev->priv) {
dev->priv = alloc_priv(drv->priv_auto_alloc_size, drv->flags);
if (!dev->priv) {
printf("Allocate private data if requested and not reentered\n");
ret = -ENOMEM;
goto fail;
}
}

I am not sure how the sizes are defined and/or allocated

adam


> adam
>
> >
> > Sorry for the trouble.
> >
> > Regards
> > Vignesh
> >
> >
> > --
> > Regards
> > Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/1] efi_selftest: LoadImage from file device path

Provide a unit test that calls LoadImage() with a file device path and
executes the application via StartImage().

Signed-off-by: Heinrich Schuchardt 
---
v3
do not use library function efi_free_pool() but boot time service
v2
correct a comment
---
 lib/efi_selftest/Makefile |   3 +
 lib/efi_selftest/efi_selftest_loadimage.c | 529 ++
 2 files changed, 532 insertions(+)
 create mode 100644 lib/efi_selftest/efi_selftest_loadimage.c

diff --git a/lib/efi_selftest/Makefile b/lib/efi_selftest/Makefile
index 779f549940..2194dc7e33 100644
--- a/lib/efi_selftest/Makefile
+++ b/lib/efi_selftest/Makefile
@@ -51,6 +51,7 @@ endif
 ifeq ($(CONFIG_SANDBOX)$(CONFIG_CPU_V7M)$(CONFIG_X86_64),)
 
 obj-y += \
+efi_selftest_loadimage.o \
 efi_selftest_startimage_exit.o \
 efi_selftest_startimage_return.o
 
@@ -68,6 +69,8 @@ $(obj)/efi_miniapp_file_image_return.h: 
$(obj)/efi_selftest_miniapp_return.efi
$(obj)/../../tools/file2include $(obj)/efi_selftest_miniapp_return.efi 
> \
$(obj)/efi_miniapp_file_image_return.h
 
+$(obj)/efi_selftest_loadimage.o: $(obj)/efi_miniapp_file_image_exit.h
+
 $(obj)/efi_selftest_startimage_exit.o: $(obj)/efi_miniapp_file_image_exit.h
 
 $(obj)/efi_selftest_startimage_return.o: $(obj)/efi_miniapp_file_image_return.h
diff --git a/lib/efi_selftest/efi_selftest_loadimage.c 
b/lib/efi_selftest/efi_selftest_loadimage.c
new file mode 100644
index 00..bb7f8b5376
--- /dev/null
+++ b/lib/efi_selftest/efi_selftest_loadimage.c
@@ -0,0 +1,529 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * efi_selftest_loadimage
+ *
+ * Copyright (c) 2019 Heinrich Schuchardt 
+ *
+ * This test checks the LoadImage and StartImage boot service.
+ *
+ * The efi_selftest_miniapp_exit.efi application is loaded via a file device
+ * path and started.
+ */
+
+#include 
+/* Include containing the efi_selftest_miniapp_exit.efi application */
+#include "efi_miniapp_file_image_exit.h"
+
+/* Block size of compressed disk image */
+#define COMPRESSED_DISK_IMAGE_BLOCK_SIZE 8
+
+/* Binary logarithm of the block size */
+#define LB_BLOCK_SIZE 9
+
+#define FILE_NAME L"app.efi"
+#define VOLUME_NAME L"EfiDisk"
+
+static struct efi_boot_services *boottime;
+static efi_handle_t handle_image;
+static efi_handle_t handle_volume;
+
+static const efi_guid_t guid_device_path = DEVICE_PATH_GUID;
+static const efi_guid_t guid_simple_file_system_protocol =
+   EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID;
+static const efi_guid_t guid_file_info = EFI_FILE_INFO_GUID;
+static const efi_guid_t guid_file_system_info = EFI_FILE_SYSTEM_INFO_GUID;
+
+/* One 8 byte block of the compressed disk image */
+struct line {
+   size_t addr;
+   char *line;
+};
+
+/* Compressed file image */
+struct compressed_file_image {
+   size_t length;
+   struct line lines[];
+};
+
+/* File info including file name */
+struct file_info {
+   struct efi_file_info info;
+   u16 file_name[sizeof(FILE_NAME)];
+};
+
+/* File system info including volume name */
+struct file_system_info {
+   struct efi_file_system_info info;
+   u16 file_name[sizeof(VOLUME_NAME)];
+};
+
+/* Compressed file image */
+static struct compressed_file_image img = EFI_ST_DISK_IMG;
+
+/* Pointer to decompressed file image */
+static u8 *image;
+
+/* File info */
+static struct file_info priv_file_info = {
+   {
+   .size = sizeof(struct file_info),
+   .attribute = EFI_FILE_READ_ONLY,
+   },
+   FILE_NAME,
+};
+
+/* Pointer to file info */
+struct efi_file_info *file_info = _file_info.info;
+
+/* Volume device path */
+static struct {
+   struct efi_device_path_vendor vendor;
+   struct efi_device_path end;
+} __packed dp_volume = {
+   .vendor = {
+   .dp = {
+   .type = DEVICE_PATH_TYPE_HARDWARE_DEVICE,
+   .sub_type = DEVICE_PATH_SUB_TYPE_VENDOR,
+   .length = sizeof(struct efi_device_path_vendor),
+   },
+   .guid = EFI_GUID(0x4f9a0ebf, 0xa179, 0x88a6, 0x25, 0x68,
+0x10, 0x72, 0xb1, 0x93, 0x51, 0x71),
+   },
+   .end = {
+   .type = DEVICE_PATH_TYPE_END,
+   .sub_type = DEVICE_PATH_SUB_TYPE_END,
+   .length = sizeof(struct efi_device_path),
+   }
+};
+
+/* File device path */
+static struct {
+   struct efi_device_path_vendor vendor;
+   struct efi_device_path path;
+   u16 file[sizeof(FILE_NAME)];
+   struct efi_device_path end;
+} __packed dp_file = {
+   .vendor = {
+   .dp = {
+   .type = DEVICE_PATH_TYPE_HARDWARE_DEVICE,
+   .sub_type = DEVICE_PATH_SUB_TYPE_VENDOR,
+   .length = sizeof(struct efi_device_path_vendor),
+   },
+   .guid = EFI_GUID(0x4f9a0ebf, 0xa179, 0x88a6, 0x25, 0x68,
+0x10, 0x72, 0xb1, 0x93, 0x51, 0x71),
+

Re: [U-Boot] [PATCH 1/3] ARM: rmobile: Switch CPU to non-secure HYP mode for r8a7790 based boards

2019-02-12 Thread Oleksandr

On 09.02.19 18:35, Marek Vasut wrote:

On 2/7/19 6:19 PM, Oleksandr wrote:

[...]

+ /* Update registers with correct frequency */
+ writel(freq, TIMER_BASE + TIMER_CNTFID0);
+ asm volatile("mcr p15, 0, %0, c14, c0, 0" : : "r" (freq));
+
+ /* Make sure arch timer is started by setting bit 0 of
CNTCR */
+ writel(1, TIMER_BASE + TIMER_CNTCR);

Shouldn't this be in the timer driver instead ?

Which timer driver? Probably, I missed something, but I didn't find any
arch timer driver being used for Gen2.

I see that TMU timer (arch/sh/lib/time.c) is used as a system timer, but
it is yet another IP.

Would it be correct, if I move arch timer updating code to
arch/arm/mach-rmobile directory?

Actually, at the same location the corresponding code lives in Linux:

https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/mach-shmobile/setup-rcar-gen2.c#L61

Presumably if this is something else than TMU, it needs proper driver
that goes into drivers/ .

Did I get your point correctly that new driver (specially for Gen2 arch
timer) should be introduced in U-Boot and

the only one thing it is intended to do is to configure that timer for
the future use by Linux/Hypervisor?

If yes, the only question I have is how that new driver is going to be
populated? There is no corresponding node for arch timer in the device
tree.

https://elixir.bootlin.com/linux/v5.0-rc5/source/arch/arm/boot/dts/r8a7790.dtsi

So, do I need specially for this case add arch timer node with reg and
compatible properties?

Sorry if I ask obvious questions, not familiar enough with U-Boot.

You would need a DT entry and a bit of code to start the timer in case
the PSCI is enabled, yes. This would then fit into the DM/DT paradigm.

I understand your point, thank you.

Will create a simple driver for arch timer in V2.

+ }
+}
+
+/*
+ * In order not to break compilation if someone decides to build
with PSCI
+ * support disabled, keep these dummy functions.
+ */

That's currently the only use-case.

Shall I drop this comment and dummy functions below?

Since there is no PSCI support, yes.

Understand.

[...]

I'd like to have a cover letter go with V2, which describes what you're
trying to achieve here.

Yes, sure. Cover letter is present for the current V1 as well.

I thought that I had CC-ed all.

This is a link to it:

http://u-boot.10912.n7.nabble.com/PATCH-0-3-PSCI-support-for-r8a7790-SoC-Lager-Stout-boards-td357352.html

Thanks

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

Re: [U-Boot] [PATCH 2/3] ARM: rmobile: Add basic PSCI support for r8a7790 SoC

2019-02-12 Thread Oleksandr



On 11.02.19 22:40, Marek Vasut wrote:

Hi

On 2/11/19 9:10 PM, Oleksandr wrote:

[...]


Yes. I had to re-implement. Let me describe why.

  From my understanding (I may mistake), the PSCI backend code which
lives
in secure section should be as lightweight as possible

and shouldn't call any U-Boot routines not marked as __secure, except
simple static inline functions.

You can see PSCI implementation for any platform in U-Boot,  and only
simple "macroses/inlines" are used across all of them.

Even for realizing some delay in code, they have specially implemented
something simple. As an example __mdelay() realization here:

https://elixir.bootlin.com/u-boot/v2019.01/source/arch/arm/cpu/armv7/sunxi/psci.c#L61


Can the U-Boot code be refactored somehow to avoid the duplication ?

Sorry, what duplication you are speaking about?

It is my impression that we're reimplementing code we already have
either in drivers/ or in Linux, again, in arch/arm/ . Isn't it the case ?


All this code (for preparing, powering up/down the CPUs and related 
peripherals) which this patch introduces, is new for U-Boot.


But, yes, it is present in Linux (arch/arm/mach-shmobile/...).





I know that PMIC (for Lager) and CPLD (for Stout) assist SoC to perform
reset. But, I couldn't use that functional here in PSCI backend, as it
pulls a lot of code (i2c for PMIC, gpio manipulation for CPLD, etc),

How can the reset work properly if the CPLD/PMIC isn't even used then ?


We ask WDT to perform a CPU reset, although this is not the same reset
as an external reset from CPLD/PMIC,

but, why not use it, if we don't have alternative? This is certainly
better than nothing, I think.

Do we need to do a full board reset in this case ?


After WDT reset CPU will be brought up to bootrom code, then starts 
executing SPL, U-Boot...


So, we will get all required SoC/Board peripherals re-initialized, I think.





Actually, we ask WDT to do what it is intended to do, and it seems to
work properly as the system up and running after WDT reset in 100% cases.

What is more, this PSCI reset implementation could be common for Gen2
SoCs where WDT is present...



so for that reason (AFAIK the PSCI system reset is a mandatory option) I
chose WDT as a entity for doing a reset. This is quite simple and can be
used on both boards, what is more that it can be used on other Gen2 SoC
if required.


+}
+
+/*


+ * Functions which intended to be called from PSCI board
initialization.
+
*/


+static int sysc_power_up(int scu)
+{
+    u32 status, chan_offs, isr_bit;
+    int i, j, ret = 0;
+
+    if (scu == CA15_SCU) {
+    chan_offs = CA15_SCU_CHAN_OFFS;
+    isr_bit = CA15_SCU_ISR_BIT;
+    } else {
+    chan_offs = CA7_SCU_CHAN_OFFS;
+    isr_bit = CA7_SCU_ISR_BIT;
+    }
+
+    writel(BIT(isr_bit), SYSC_BASE + SYSCISCR);
+
+    /* Submit power resume request until it was accepted */
+    for (i = 0; i < PWRER_RETRIES; i++) {
+    /* Wait until SYSC is ready to accept a power resume
request */
+    for (j = 0; j < SYSCSR_RETRIES; j++) {
+    if (readl(SYSC_BASE + SYSCSR) & BIT(1))
+    break;
+
+    udelay(SYSCSR_DELAY_US);
+    }
+
+    if (j == SYSCSR_RETRIES)
+    return -EAGAIN;
+
+    /* Submit power resume request */
+    writel(BIT(0), SYSC_BASE + chan_offs + PWRONCR_OFFS);
+
+    /* Check if power resume request was accepted */
+    status = readl(SYSC_BASE + chan_offs + PWRER_OFFS);
+    if (!(status & BIT(0)))
+    break;
+
+    udelay(PWRER_DELAY_US);
+    }
+
+    if (i == PWRER_RETRIES)
+    return -EIO;
+
+    /* Wait until the power resume request has completed */
+    for (i = 0; i < SYSCISR_RETRIES; i++) {
+    if (readl(SYSC_BASE + SYSCISR) & BIT(isr_bit))
+    break;
+    udelay(SYSCISR_DELAY_US);
+    }
+
+    if (i == SYSCISR_RETRIES)
+    ret = -EIO;
+
+    writel(BIT(isr_bit), SYSC_BASE + SYSCISCR);
+
+    return ret;
+}
+
+static bool sysc_power_is_off(int scu)
+{
+    u32 status, chan_offs;
+
+    chan_offs = scu == CA15_SCU ? CA15_SCU_CHAN_OFFS :
CA7_SCU_CHAN_OFFS;
+
+    /* Check if SCU is in power shutoff state */
+    status = readl(SYSC_BASE + chan_offs + PWRSR_OFFS);
+    if (status & BIT(0))
+    return true;
+
+    return false;
+}
+
+static void apmu_setup_debug_mode(int cpu)
+{
+    int cluster = r8a7790_cluster_id(cpu);
+    u32 apmu_base, reg;
+
+    apmu_base = cluster == 0 ? CA15_APMU_BASE : CA7_APMU_BASE;
+
+    /*
+ * Enable reset requests derived from power shutoff to the
AP-system
+ * CPU cores in debug mode. Without taking care of, they may
fail to
+ * resume from the power shutoff state.
+ */
+    reg = readl(apmu_base + DBGRCR_OFFS);
+    reg |= DBGCPUREN | DBGCPUNREN(r8a7790_core_id(cpu)) | DBGCPUPREN;
+    writel(reg,

Re: [U-Boot] [PATCH v4 14/20] mtd: spi: Switch to new SPI NOR framework

On Sun, Feb 10, 2019 at 10:37 PM Vignesh R  wrote:
>
>
>
> On 11/02/19 9:01 AM, Adam Ford wrote:
> > On Tue, Feb 5, 2019 at 12:00 AM Vignesh R  wrote:
> >>
> >> Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
> >> layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
> >> use new interfaces/definitions
> >>
> >> Signed-off-by: Vignesh R 
> >> Tested-by: Simon Goldschmidt 
> >> Tested-by: Stefan Roese 
> >> Tested-by: Horatiu Vultur 
> >> Reviewed-by: Jagan Teki 
> >> Tested-by: Jagan Teki  #zynq-microzed
> >
> > This patch appears to break the da850_evm board which boots from SPI
> > Flash and initializes the davinci driver with platdata since the
> > device tree stuff does not quite work right in SPL.
>
> Oops, I did test on K2G EVM that has davinci SPI controller with micron
> n25q flash but that was with DT. Not sure whats missing with platdata.
>
> >
> > U-Boot SPL 2019.01-02923-gc4e8862308-dirty (Feb 10 2019 - 21:24:38 -0600)
> > Trying to boot from SPI
> > SPI probe failed.
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
>
> Could you enable debug prints at spi-mem level in drivers/spi/spi-mem.c
> (especially debug prints at the end of spi_mem_exec_op()) and post the
> logs here?
>
> >
> > Any suggestions on how to fix the SPI initialization without needing
> > the device tree?  I have tried to port the device tree stuff to SPL,
> > but I haven't yet been successful so I have had to leave the platdata
> > initialization in place.
> >
>
> I haven't changed any driver names so, platdata to driver bindings
> should still be the same. Could you verify if spi_nor_scan() is being
> called in drivers/mtd/spi/spi-nor-tiny.c for SPL?

I globally turned on DEBUG and I have two logs for you:

Not working:

U-Boot SPL 2019.01-02923-gc4e8862308-dirty (Feb 12 2019 - 13:04:19 -0600)
Trying to boot from SPI
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1 'davinci_spi'
   - not found
spi_get_bus_and_cs: Binding new device 'spi_flash', busnum=0, cs=0,
driver=spi_flash_std
spi_get_bus_and_cs: Error path, created=1, device 'spi_flash'
SPI probe failed.
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

As a point of reference , I thought I'd show
WORKING version (before this patch):

U-Boot SPL 2019.01-02922-g2ee6705be0-dirty (Feb 12 2019 - 12:59:49 -0600)
Trying to boot from SPI
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1 'davinci_spi'
   - not found
spi_get_bus_and_cs: Binding new device 'spi_flash', busnum=0, cs=0,
driver=spi_flash_std
uclass_find_device_by_seq: 0 -1
uclass_find_device_by_seq: 0 0
   - -1 -1 'spi_flash'
   - not found
spi_flash_std_probe: slave=8001fd60, cs=0
davinci_spi_set_speed speed 3000
davinci_spi_set_mode mode 3
davinci_spi_set_speed speed 3000
davinci_spi_set_mode mode 3
spi_get_bus_and_cs: bus=8001fbf4, slave=8001fd60
SPL: payload image: U-Boot 2019.01-02922-g2ee6705be0   load addr:
0xc107ffc0 size: 405306
Jumping to U-Boot
loaded - jumping to U-Boot...
image entry point: 0xc108
...

During this process, I learned a few things.
1.  I am not really using the device tree during SPL like i originally
thought and the OF_PLATDATA
2.  Getting SPL to support device tree with or without PLATDATA isn't
as straightforward as I hoped
3.  With the knowledge I learned from item 1, I tried to disabled
OF_CONTROL during SPL, but this patch also fails to build since it
assumes OF_CONTROL is always enabled.

If there are any suggestions you might have, I am willing to try them.

adam

>
> Sorry for the trouble.
>
> Regards
> Vignesh
>
>
> --
> Regards
> Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v1] dm: pinctrl: Remove obsolete function pinctrl_decode_pin_config_dm().

2019-02-12 Thread Christoph Muellner

This reverts commit 5ff776889212c080e3d1a33634ac904405ed6845.

As noted in the comment, the function pinctrl_decode_pin_config_dm()
only served as a temporary solution.

Since the function has no users anymore, we can remove it again.

Signed-off-by: Christoph Muellner 

---

 drivers/pinctrl/pinctrl-uclass.c | 22 --
 include/dm/pinctrl.h | 12 
 2 files changed, 34 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index 0e3260afd1..6db0445067 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -27,28 +27,6 @@ int pinctrl_decode_pin_config(const void *blob, int node)
return flags;
 }
 
-/*
- * TODO: this function is temporary for v2019.01.
- * It should be renamed to pinctrl_decode_pin_config(),
- * the original pinctrl_decode_pin_config() function should
- * be removed and all callers of the original function should
- * be migrated to use the new one.
- */
-int pinctrl_decode_pin_config_dm(struct udevice *dev)
-{
-   int pinconfig = 0;
-
-   if (dev->uclass->uc_drv->id != UCLASS_PINCONFIG)
-   return -EINVAL;
-
-   if (dev_read_bool(dev, "bias-pull-up"))
-   pinconfig |= 1 << PIN_CONFIG_BIAS_PULL_UP;
-   else if (dev_read_bool(dev, "bias-pull-down"))
-   pinconfig |= 1 << PIN_CONFIG_BIAS_PULL_DOWN;
-
-   return pinconfig;
-}
-
 #if CONFIG_IS_ENABLED(PINCTRL_FULL)
 /**
  * pinctrl_config_one() - apply pinctrl settings for a single node
diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h
index ff2b82e7c2..63a7d55b88 100644
--- a/include/dm/pinctrl.h
+++ b/include/dm/pinctrl.h
@@ -355,18 +355,6 @@ int pinctrl_get_periph_id(struct udevice *dev, struct 
udevice *periph);
 int pinctrl_decode_pin_config(const void *blob, int node);
 
 /**
- * pinctrl_decode_pin_config_dm() - decode pin configuration flags
- *
- * This decodes some of the PIN_CONFIG values into flags, with each value
- * being (1 << pin_cfg). This does not support things with values like the
- * slew rate.
- *
- * @pinconfig: Pinconfig udevice
- * @return decoded flag value, or -ve on error
- */
-int pinctrl_decode_pin_config_dm(struct udevice *dev);
-
-/**
  * pinctrl_get_gpio_mux() - get the mux value for a particular GPIO
  *
  * This allows the raw mux value for a GPIO to be obtained. It is
-- 
2.11.0

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

[U-Boot] [PATCH 3/5] spl: Add ability to disable SPL FAT

From: Sjoerd Simons 

spl_usb depends on FAT support, so don't try to build it if fat support
is disabled for SPL.

Signed-off-by: Sjoerd Simons 
---
 common/spl/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/spl/Makefile b/common/spl/Makefile
index e1daabf1e9c..42db0441559 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -22,7 +22,9 @@ obj-$(CONFIG_$(SPL_TPL_)NET_SUPPORT) += spl_net.o
 obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += spl_mmc.o
 obj-$(CONFIG_$(SPL_TPL_)ATF) += spl_atf.o
 obj-$(CONFIG_$(SPL_TPL_)OPTEE) += spl_optee.o
+ifdef CONFIG_SPL_FS_FAT
 obj-$(CONFIG_$(SPL_TPL_)USB_SUPPORT) += spl_usb.o
+endif
 obj-$(CONFIG_$(SPL_TPL_)FS_FAT) += spl_fat.o
 obj-$(CONFIG_$(SPL_TPL_)FS_EXT4) += spl_ext.o
 obj-$(CONFIG_$(SPL_TPL_)SATA_SUPPORT) += spl_sata.o
-- 
2.20.1

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

[U-Boot] [PATCH 4/5] spl: Add common usb support in spl if needed

From: Sjoerd Simons 

If build into the SPL at least the MUSB USB driver needs the common usb
functionality (e.g. parsing of the DR role dt property), so build this.

Signed-off-by: Sjoerd Simons 
---
 scripts/Makefile.spl | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 9d5921606e1..52afe5bca8f 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -87,6 +87,7 @@ endif
 endif
 
 libs-y += drivers/
+libs-$(CONFIG_SPL_USB_SUPPORT) += drivers/usb/common/
 libs-$(CONFIG_SPL_USB_GADGET) += drivers/usb/dwc3/
 libs-y += dts/
 libs-y += fs/
-- 
2.20.1

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

[U-Boot] [PATCH 1/5] drivers: usb: musb: Fail if the ctrl mod register is missing

From: Sjoerd Simons 

If the trcl mode register address cannot be found error out rather then
trying to continue (which cannot work)

Signed-off-by: Sjoerd Simons 
---
 drivers/usb/musb-new/ti-musb.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/musb-new/ti-musb.c b/drivers/usb/musb-new/ti-musb.c
index 20ca2731b49..725086928b3 100644
--- a/drivers/usb/musb-new/ti-musb.c
+++ b/drivers/usb/musb-new/ti-musb.c
@@ -90,6 +90,11 @@ static int ti_musb_ofdata_to_platdata(struct udevice *dev)
phys = fdtdec_lookup_phandle(fdt, node, "phys");
ctrl_mod = fdtdec_lookup_phandle(fdt, phys, "ti,ctrl_mod");
platdata->ctrl_mod_base = (void *)fdtdec_get_addr(fdt, ctrl_mod, "reg");
+   if (platdata->ctrl_mod_base == FDT_ADDR_T_NONE) {
+   pr_err("MUSB ctrl mod missing\n");
+   return -ENOENT;
+   }
+
usb_index = ti_musb_get_usb_index(node);
switch (usb_index) {
case 1:
-- 
2.20.1

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

[U-Boot] [PATCH 5/5] cmd: pxe: Increase MAX_TFTP_PATH_LEN to 256

From: Martyn Welch 

Despite the name it's also used for paths in distro configuration
files (i.e. extlinux.conf). When using OSTree, it is very easy to
reach the 127 character limit, thus increase to 256 bytes.

Signed-off-by: Martyn Welch 
---
 cmd/pxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/pxe.c b/cmd/pxe.c
index 274555319ba..14022f13c69 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -18,7 +18,7 @@
 #include "menu.h"
 #include "cli.h"
 
-#define MAX_TFTP_PATH_LEN 127
+#define MAX_TFTP_PATH_LEN 256
 
 const char *pxe_default_paths[] = {
 #ifdef CONFIG_SYS_SOC
-- 
2.20.1

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

[U-Boot] [PATCH 2/5] drivers: usb: musb: Fix comparison between pointer and integer warn

drivers/usb/musb-new/ti-musb.c: In function 'ti_musb_ofdata_to_platdata':
drivers/usb/musb-new/ti-musb.c:93:30: warning: comparison between pointer and 
integer
if (platdata->ctrl_mod_base == FDT_ADDR_T_NONE) {}

Signed-off-by: Adrian Ratiu 
---
 drivers/usb/musb-new/ti-musb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb-new/ti-musb.c b/drivers/usb/musb-new/ti-musb.c
index 725086928b3..3326c7e4702 100644
--- a/drivers/usb/musb-new/ti-musb.c
+++ b/drivers/usb/musb-new/ti-musb.c
@@ -90,7 +90,7 @@ static int ti_musb_ofdata_to_platdata(struct udevice *dev)
phys = fdtdec_lookup_phandle(fdt, node, "phys");
ctrl_mod = fdtdec_lookup_phandle(fdt, phys, "ti,ctrl_mod");
platdata->ctrl_mod_base = (void *)fdtdec_get_addr(fdt, ctrl_mod, "reg");
-   if (platdata->ctrl_mod_base == FDT_ADDR_T_NONE) {
+   if (platdata->ctrl_mod_base == (void *)FDT_ADDR_T_NONE) {
pr_err("MUSB ctrl mod missing\n");
return -ENOENT;
}
-- 
2.20.1

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

Re: [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL

On Tue, Feb 12, 2019 at 12:05:55PM -0500, Tom Rini wrote:
> On Mon, Feb 11, 2019 at 09:40:17PM -0600, Adam Ford wrote:
> > On Tue, Jan 29, 2019 at 7:36 AM Adam Ford  wrote:
> > >
> > > On Mon, Jan 28, 2019 at 2:33 PM Tom Rini  wrote:
> > > >
> > > > On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> > > > > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini  wrote:
> > > > > >
> > > > > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > > > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hello Adam,
> > > > > > > > >
> > > > > > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > > > > > By removing EXT support from SPL, it makes room for the 
> > > > > > > > > > extra
> > > > > > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > > > > > enabled, extra options need to be added to the device tree 
> > > > > > > > > > to
> > > > > > > > > > tell it which portions of the tree are needed early in boot 
> > > > > > > > > > time
> > > > > > > > > >
> > > > > > > > > > Unfortunately, with these options as-is, the system doesn't 
> > > > > > > > > > boot
> > > > > > > > > > nor does it display anything on the UART.  I don't have a 
> > > > > > > > > > debugger
> > > > > > > > > > readily available, but I have seen others with AM33x boards 
> > > > > > > > > > which
> > > > > > > > > > are similar to OMAP3 boards. This is posted as an RFC just 
> > > > > > > > > > in case
> > > > > > > > > > anyone has any suggestions on what  might be missing.
> > > > > > > > > >
> > > > > > > > > On an AM335x board I had problems when moving from embedded 
> > > > > > > > > to separate
> > > > > > > > > DTB. Even if deprecated you should probably give 
> > > > > > > > > CONFIG_OF_EMBED a try.
> > > > > > > > > If this works you could go back to CONFIG_OF_SEPARATE and 
> > > > > > > > > probably give
> > > > > > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is 
> > > > > > > > > working) did
> > > > > > > > > help me quite a lot.
> > > > > > > >
> > > > > > > > I had to turn off DM_SERIAL temporarily to get some debugging 
> > > > > > > > going.
> > > > > > > > I 'think' there is something wrong with fetching data from the 
> > > > > > > > device
> > > > > > > > tree.
> > > > > > > >
> > > > > > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  
> > > > > > > > SPL_SEPARATE_BSS is set.
> > > > > > > >
> > > > > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 
> > > > > > > > 15:22:11 -0600)
> > > > > > > > Trying to boot from MMC1
> > > > > > > > uclass_find_device_by_seq: 0 0
> > > > > > > >- not found
> > > > > > > > uclass_find_device_by_seq: 1 0
> > > > > > > >- not found
> > > > > > > > spl: could not find mmc device 0. error: -19
> > > > > > > > SPL: failed to boot from all boot devices
> > > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > > >
> > > > > > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > > > > > >
> > > > > > > > I am not sure what these values are support to be, but I was 
> > > > > > > > able to
> > > > > > > > do a dump of my spl device tree:
> > > > > > > >
> > > > > > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > > > > > >
> > > > > > > Looking at Tom's defconfig file changes for the beagle, I noticed 
> > > > > > > he
> > > > > > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was 
> > > > > > > able
> > > > > > > to get my device tree based SPL to initialize both serial and MMC.
> > > > > > > With Falcon mode enabled, it immediately stops booting and/or 
> > > > > > > showing
> > > > > > > anything.  There seems to be some correlation, because disabling 
> > > > > > > it
> > > > > > > again make it work.
> > > > > > >
> > > > > > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > > > > > debugging enabled, I can see that it is not able to locate the MMC
> > > > > > > device.  I am going to assume that if it cannot find the MMC 
> > > > > > > device,
> > > > > > > it probably cannot find the serial device which may explain why
> > > > > > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > > > > > >
> > > > > > > Might someone have any suggestions as to how to get both 
> > > > > > > SPL_OF_CONFIG
> > > > > > > with Falcon working?  I'd really like to keep that enabled by 
> > > > > > > default.
> > > > > >
> > > > > > Note that I disabled Falcon for the space savings to keep MLO small
> > > > > > enough, not that I noticed it failing to work.  Given that with my
> > > > > > patches what does work is loading an un-patched-for-DM-and-SPL 
> > > > > > u-boot
> > > > > > and doesn't work is booting the u-boot.img I just built if there's 
> > > > > > not
> > > > > > some overlap there.  Perhaps the addresses being used for

Re: [U-Boot] [RFC] ARM: omap3_logic_somlv: Enable OF_CONTROL in SPL

On Mon, Feb 11, 2019 at 09:40:17PM -0600, Adam Ford wrote:
> On Tue, Jan 29, 2019 at 7:36 AM Adam Ford  wrote:
> >
> > On Mon, Jan 28, 2019 at 2:33 PM Tom Rini  wrote:
> > >
> > > On Mon, Jan 28, 2019 at 02:23:00PM -0600, Adam Ford wrote:
> > > > On Mon, Jan 28, 2019 at 9:14 AM Tom Rini  wrote:
> > > > >
> > > > > On Mon, Jan 28, 2019 at 09:08:54AM -0600, Adam Ford wrote:
> > > > > > On Fri, Jan 25, 2019 at 3:39 PM Adam Ford  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Jan 24, 2019 at 7:19 AM Felix Brack  wrote:
> > > > > > > >
> > > > > > > > Hello Adam,
> > > > > > > >
> > > > > > > > On 23.01.2019 22:13, Adam Ford wrote:
> > > > > > > > > By removing EXT support from SPL, it makes room for the extra
> > > > > > > > > overhead of enabling OF_CONTROL in SPL.  With SPL_OF_CONTROL
> > > > > > > > > enabled, extra options need to be added to the device tree to
> > > > > > > > > tell it which portions of the tree are needed early in boot 
> > > > > > > > > time
> > > > > > > > >
> > > > > > > > > Unfortunately, with these options as-is, the system doesn't 
> > > > > > > > > boot
> > > > > > > > > nor does it display anything on the UART.  I don't have a 
> > > > > > > > > debugger
> > > > > > > > > readily available, but I have seen others with AM33x boards 
> > > > > > > > > which
> > > > > > > > > are similar to OMAP3 boards. This is posted as an RFC just in 
> > > > > > > > > case
> > > > > > > > > anyone has any suggestions on what  might be missing.
> > > > > > > > >
> > > > > > > > On an AM335x board I had problems when moving from embedded to 
> > > > > > > > separate
> > > > > > > > DTB. Even if deprecated you should probably give 
> > > > > > > > CONFIG_OF_EMBED a try.
> > > > > > > > If this works you could go back to CONFIG_OF_SEPARATE and 
> > > > > > > > probably give
> > > > > > > > CONFIG_SPL_SEPARATE_BSS a try.
> > > > > > > > Also CONFIG_DEBUG_UART (assumed the pin configuration is 
> > > > > > > > working) did
> > > > > > > > help me quite a lot.
> > > > > > >
> > > > > > > I had to turn off DM_SERIAL temporarily to get some debugging 
> > > > > > > going.
> > > > > > > I 'think' there is something wrong with fetching data from the 
> > > > > > > device
> > > > > > > tree.
> > > > > > >
> > > > > > > I tried both OF_EMBDED and OF_SEPARATE without luck.  
> > > > > > > SPL_SEPARATE_BSS is set.
> > > > > > >
> > > > > > > U-Boot SPL 2019.01-02697-gd01806a8fc-dirty (Jan 25 2019 - 
> > > > > > > 15:22:11 -0600)
> > > > > > > Trying to boot from MMC1
> > > > > > > uclass_find_device_by_seq: 0 0
> > > > > > >- not found
> > > > > > > uclass_find_device_by_seq: 1 0
> > > > > > >- not found
> > > > > > > spl: could not find mmc device 0. error: -19
> > > > > > > SPL: failed to boot from all boot devices
> > > > > > > ### ERROR ### Please RESET the board ###
> > > > > > >
> > > > > > > I can see the mmc0 device is appearing in my SPL dtb file.
> > > > > > >
> > > > > > > I am not sure what these values are support to be, but I was able 
> > > > > > > to
> > > > > > > do a dump of my spl device tree:
> > > > > > >
> > > > > > >  dtc -I dtb -O dts spl/u-boot-spl.dtb
> > > > > >
> > > > > > Looking at Tom's defconfig file changes for the beagle, I noticed he
> > > > > > disabled Falcon mode.  As soon as I disabled Falcon mode, I was able
> > > > > > to get my device tree based SPL to initialize both serial and MMC.
> > > > > > With Falcon mode enabled, it immediately stops booting and/or 
> > > > > > showing
> > > > > > anything.  There seems to be some correlation, because disabling it
> > > > > > again make it work.
> > > > > >
> > > > > > With DM_SERIAL off, I can see the dumps to the screen and with the
> > > > > > debugging enabled, I can see that it is not able to locate the MMC
> > > > > > device.  I am going to assume that if it cannot find the MMC device,
> > > > > > it probably cannot find the serial device which may explain why
> > > > > > disabling DM_SERIAL in SPL with Falcon mode on shows text.
> > > > > >
> > > > > > Might someone have any suggestions as to how to get both 
> > > > > > SPL_OF_CONFIG
> > > > > > with Falcon working?  I'd really like to keep that enabled by 
> > > > > > default.
> > > > >
> > > > > Note that I disabled Falcon for the space savings to keep MLO small
> > > > > enough, not that I noticed it failing to work.  Given that with my
> > > > > patches what does work is loading an un-patched-for-DM-and-SPL u-boot
> > > > > and doesn't work is booting the u-boot.img I just built if there's not
> > > > > some overlap there.  Perhaps the addresses being used for
> > > > > BSS/malloc/whatever are stomping on the image and that's wrecking
> > > > > things?
> > > > >
> > > >
> > > > Is there an easy way to debug memory utilization?  We're not quite
> > > > getting to the point of loading u-boot.img since it cannot find the
> > > > MMC driver.
> > > >
> > > > Interestingly enough, when I rebased my quasi-working image with the
> > > > master, it died.  I

[U-Boot] [RFC PATCH 2/3] sunxi: Don't change the rank in dram size detection in A33

2019-02-12 Thread Michael Trimarchi

Change the size create a glitch in the clke signal on second
bank. The glitch can generate problem in memory initialiazation

Signed-off-by: Michael Trimarchi 
---
 arch/arm/mach-sunxi/dram_sun8i_a33.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c 
b/arch/arm/mach-sunxi/dram_sun8i_a33.c
index 83212aaddf..d73a93a132 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
@@ -45,14 +45,12 @@ static void mctl_set_cr(struct dram_para *para)
 
 static void auto_detect_dram_size(struct dram_para *para)
 {
-   u8 orig_rank = para->rank;
int rows, columns;
 
/* Row detect */
para->page_size = 512;
para->seq = 1;
para->rows = 16;
-   para->rank = 1;
mctl_set_cr(para);
for (rows = 11 ; rows < 16 ; rows++) {
if (mctl_mem_matches(1 << (rows + 9))) /* row-column */
@@ -69,7 +67,6 @@ static void auto_detect_dram_size(struct dram_para *para)
}
 
para->seq = 0;
-   para->rank = orig_rank;
para->rows = rows;
para->page_size = 1 << columns;
mctl_set_cr(para);
-- 
2.17.1

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

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

2019-02-12 Thread Michael Trimarchi

Set two rank timing and exit self-refresh timing seems not done
properly. We know use the same write that we are using
on H5 silicon.

Signed-off-by: Michael Trimarchi 
---
 arch/arm/mach-sunxi/dram_sun8i_a33.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c 
b/arch/arm/mach-sunxi/dram_sun8i_a33.c
index d73a93a132..355fe30aba 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
@@ -146,7 +146,7 @@ static void auto_set_timing_para(struct dram_para *para)
writel(reg_val, _ctl->dramtmg5);
/* Set two rank timing and exit self-refresh timing */
clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0),
-   0x33 << 8 | (0x8 << 0));
+   0x33 << 8 | (0x10 << 0));
/* Set phy interface time */
reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8)
| (wr_latency << 0);
-- 
2.17.1

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

[U-Boot] [RFC PATCH 1/3] sunxi: Use clrsetbits_le32 instead of multiple instruction

2019-02-12 Thread Michael Trimarchi

Signed-off-by: Michael Trimarchi 
---
 arch/arm/mach-sunxi/dram_sun8i_a33.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c 
b/arch/arm/mach-sunxi/dram_sun8i_a33.c
index 1da2727f98..83212aaddf 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_a33.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c
@@ -148,12 +148,8 @@ static void auto_set_timing_para(struct dram_para *para)
reg_val = (tcksrx << 24) | (tcksre << 16) | (tckesr << 8) | (tcke << 0);
writel(reg_val, _ctl->dramtmg5);
/* Set two rank timing and exit self-refresh timing */
-   reg_val = readl(_ctl->dramtmg8);
-   reg_val &= ~(0xff << 8);
-   reg_val &= ~(0xff << 0);
-   reg_val |= (0x33 << 8);
-   reg_val |= (0x8 << 0);
-   writel(reg_val, _ctl->dramtmg8);
+   clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0),
+   0x33 << 8 | (0x8 << 0));
/* Set phy interface time */
reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8)
| (wr_latency << 0);
-- 
2.17.1

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

Re: [U-Boot] [PATCH] ARM: tegra: Reserve 32MB for the Linux kernel

2019-02-12 Thread Stephen Warren


On 2/12/19 9:03 AM, Jon Hunter wrote:

From: Jonathan Hunter 

Booting recently Linux -next kernels on 32-bit Tegra devices has been
failing when using the 'multi_v7_defconfig' kenrel configuration because
the size of has grown such that it is overwriting the FDT blob.

Current Linux -next kernels built with the 'multi_v7_defconfig' have a
total size of ~19.5MB (where .text is ~12.5MB, .data is ~6.5MB and .bss
is ~0.5MB). Therefore, increase the memory location reserved for the
Linux kernel to 32MB from 16MB for 32-bit Tegra devices.

This change has been boot tested on Tegra20 Ventana, Tegra30 Cardhu and
Tegra124 Jetson TK1 with the Linux next tree (20190212).


Reviewed-by: Stephen Warren 

Just in case anyone else puzzles over this:

It took me too long to realize/remember why the following wasn't a 
problem since the stack will overlap the initrd location:


-#define CONFIG_STACKBASE   0x8280  /* 40MB */
+#define CONFIG_STACKBASE   0x8380  /* 56MB */
...
+   "ramdisk_addr_r=0x8310\0"

... which of course is because the stackbase variable is only used 
during early boot, which is long before that location is used to store 
the initrd the U-Boot loads.

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

Re: [U-Boot] [RFC] efi_loader: EFI variables

2019-02-12 Thread Daniel Thompson

On Tue, Feb 12, 2019 at 12:34:29PM +0100, Heinrich Schuchardt wrote:
> On 2/12/19 10:49 AM, Alexander Graf wrote:
> > On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
> >> Hello Alex, hello Takahiro,
> >>
> >> this morning I met Daniel Thompson of Linaro. He thinks it would be
> >> quite valuable if U-Boot would at least offer read access to EFI
> >> variables at runtime.
> >>
> >> I think what it takes is only a RAM buffer that we put between our
> >> current storage backend (i.e. synchronization with U-Boot variables)
> >> and the API implementation.
> >>
> >> We will need such a buffer anyway for non-permanent variables once we
> >> have a SPI flash storage.
> > 
> > I think slowly we need to take a critical design decision: Do we want to
> > be in the business of managing runtime UEFI variables?
> > 
> > I don't have a fully cohesive answer to that yet. My gut feeling tells
> > me, that runtime variables would be much better off if they lived in
> > TrustZone. That way we don't have to play relocation tricks, and devices
> > that give you persistency are owned by the secure world anyway, so there
> > is no weird intersection between OS and RTS.
> > 
> > So maybe the path forward would be to implement variable services in ATF
> > (or OP-TEE rather I suppose) and just provide shim stubs to communicate
> > with them from runtime services? That would keep all the variable logic
> > platform agnostic, and we would not have to jump through weird hoops
> > with DM.
> 
> U-Boot' major asset are the many boards supported by drivers. Does ATF
> or OP-TEE have drivers for SPI?

Some ports have SPI drivers and AFAIK it is only really there to
facilitate smartcard communications. I'm not aware of any SPI flash
storage hooked up to the driver.


> Or is your idea that U-Boot would provide a module that is set up as a
> trusted driver or trusted app, cf.
> https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of-TEE%20copy.png

OP-TEE has two implementations of secure storage at present: REE (rich
OS) filesystem and eMMC RPMB.

Things will get very circular when the secure storage is the REE
filesystem because it is not available to OP-TEE until the REE has
booted and started the supplicant. That means u-boot would have to
provide a lot of supplicant infrastructure in order to read from the
variable store.


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

[U-Boot] [PATCH] ARM: tegra: Reserve 32MB for the Linux kernel

2019-02-12 Thread Jon Hunter

From: Jonathan Hunter 

Booting recently Linux -next kernels on 32-bit Tegra devices has been
failing when using the 'multi_v7_defconfig' kenrel configuration because
the size of has grown such that it is overwriting the FDT blob.

Current Linux -next kernels built with the 'multi_v7_defconfig' have a
total size of ~19.5MB (where .text is ~12.5MB, .data is ~6.5MB and .bss
is ~0.5MB). Therefore, increase the memory location reserved for the
Linux kernel to 32MB from 16MB for 32-bit Tegra devices.

This change has been boot tested on Tegra20 Ventana, Tegra30 Cardhu and
Tegra124 Jetson TK1 with the Linux next tree (20190212).

Signed-off-by: Jonathan Hunter 
---
 include/configs/tegra114-common.h | 14 +++---
 include/configs/tegra124-common.h | 14 +++---
 include/configs/tegra20-common.h  | 14 +++---
 include/configs/tegra30-common.h  | 14 +++---
 4 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/include/configs/tegra114-common.h 
b/include/configs/tegra114-common.h
index ccfc516a8256..1aa44126455a 100644
--- a/include/configs/tegra114-common.h
+++ b/include/configs/tegra114-common.h
@@ -15,7 +15,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
+#define CONFIG_STACKBASE   0x8380  /* 56MB */
 
 /*---
  * Physical Memory Map
@@ -36,13 +36,13 @@
  *   should not overlap that area, or the kernel will have to copy itself
  *   somewhere else before decompression. Similarly, the address of any other
  *   data passed to the kernel shouldn't overlap the start of RAM. Pushing
- *   this up to 16M allows for a sizable kernel to be decompressed below the
+ *   this up to 32M allows for a sizable kernel to be decompressed below the
  *   compressed load address.
  *
- * fdt_addr_r simply shouldn't overlap anything else. Choosing 32M allows for
- *   the compressed kernel to be up to 16M too.
+ * fdt_addr_r simply shouldn't overlap anything else. Choosing 48M allows for
+ *   the compressed kernel to be up to 32M too.
  *
- * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows
+ * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 49M allows
  *   for the FDT/DTB to be up to 1M, which is hopefully plenty.
  */
 #define CONFIG_LOADADDR 0x8100
@@ -50,8 +50,8 @@
"scriptaddr=0x9000\0" \
"pxefile_addr_r=0x9010\0" \
"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
-   "fdt_addr_r=0x8200\0" \
-   "ramdisk_addr_r=0x8210\0"
+   "fdt_addr_r=0x8300\0" \
+   "ramdisk_addr_r=0x8310\0"
 
 /* Defines for SPL */
 #define CONFIG_SPL_TEXT_BASE   0x80108000
diff --git a/include/configs/tegra124-common.h 
b/include/configs/tegra124-common.h
index b275f795a35e..353068416423 100644
--- a/include/configs/tegra124-common.h
+++ b/include/configs/tegra124-common.h
@@ -17,7 +17,7 @@
 /*
  * Miscellaneous configurable options
  */
-#define CONFIG_STACKBASE   0x8280  /* 40MB */
+#define CONFIG_STACKBASE   0x8380  /* 56MB */
 
 /*---
  * Physical Memory Map
@@ -38,13 +38,13 @@
  *   should not overlap that area, or the kernel will have to copy itself
  *   somewhere else before decompression. Similarly, the address of any other
  *   data passed to the kernel shouldn't overlap the start of RAM. Pushing
- *   this up to 16M allows for a sizable kernel to be decompressed below the
+ *   this up to 32M allows for a sizable kernel to be decompressed below the
  *   compressed load address.
  *
- * fdt_addr_r simply shouldn't overlap anything else. Choosing 32M allows for
- *   the compressed kernel to be up to 16M too.
+ * fdt_addr_r simply shouldn't overlap anything else. Choosing 48M allows for
+ *   the compressed kernel to be up to 32M too.
  *
- * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows
+ * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 49M allows
  *   for the FDT/DTB to be up to 1M, which is hopefully plenty.
  */
 #define CONFIG_LOADADDR 0x8100
@@ -52,8 +52,8 @@
"scriptaddr=0x9000\0" \
"pxefile_addr_r=0x9010\0" \
"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
-   "fdt_addr_r=0x8200\0" \
-   "ramdisk_addr_r=0x8210\0"
+   "fdt_addr_r=0x8300\0" \
+   "ramdisk_addr_r=0x8310\0"
 
 /* Defines for SPL */
 #define CONFIG_SPL_TEXT_BASE   0x80108000
diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h
index 7f0a5292c2e9..04d4ff4992cb 100644
--- a/include/configs/tegra20-common.h
+++ b/include/configs/tegra20-common.h
@@ -16,7 +16,7 @@
 /

[U-Boot] [PATCH 4/4] ARM: dts: stm32mp1: Add adc nodes

Add adc related nodes. These nodes are used to detect the
current supplied by USB type-C power in port on DK1 and DK2
boards.

Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/stm32mp157-pinctrl.dtsi |  7 +++
 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 21 +
 2 files changed, 28 insertions(+)

diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi 
b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 4d2bf33be7d4..c06987548612 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -148,6 +148,13 @@
gpio-ranges = < 0 160 8>;
};
 
+   adc12_usb_pwr_pins_a: adc12-usb-pwr-pins-0 {
+   pins {
+   pinmux = , /* ADC12 in18 */
+; /* ADC12 in19 */
+   };
+   };
+
cec_pins_a: cec-0 {
pins {
pinmux = ;
diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
index f6cf35648abf..54ecb3ccaa5e 100644
--- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
@@ -31,6 +31,27 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_pwr_pins_a>;
+   vdd-supply = <>;
+   vdda-supply = <>;
+   vref-supply = <>;
+   status = "okay";
+   adc1: adc@0 {
+   /*
+* Type-C USB_PWR_CC1 & USB_PWR_CC2 on in18 & in19.
+* Use at least 5 * RC time, e.g. 5 * (Rp + Rd) * C:
+* 5 * (56 + 47kOhms) * 5pF => 2.5us.
+* Use arbitrary margin here (e.g. 5µs).
+*/
+   st,min-sample-time-nsecs = <5000>;
+   /* ANA0, ANA1, USB Type-C CC1 & CC2 */
+   st,adc-channels = <0 1 18 19>;
+   status = "okay";
+   };
+};
+
 _hse {
st,digbypass;
 };
-- 
1.9.1

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

[U-Boot] [PATCH 1/4] ARM: dts: stm32: Synchronize DT with kernel one

This patch synchronizes U-boot DT with kernel one
This is based on https://patchwork.kernel.org/cover/10797115/

This patch adds initial support of STM32MP157 discovery boards:
  - Add support of stm32mp157a discovery1 board (part number: STM32MP157A-DK1).
This board embeds a STM32MP157a SOC with AC package (TFBGA361, 148 ios)
and 512MB of DDR3. Several connections are available on this boards:
4*USB2.0, 1*USB2.0 typeC, SDcard, RJ45, HDMI, Arduino connector, ...

  - Add support of stm32mp157c discovery2 board (part number: STM32MP157C-DK2).
This board is a "super-set" of stm32mp157a-dk1. A display panel (otm8009a)
and Murata wifi/BT combo is added.

Signed-off-by: Alexandre Torgue 
Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/Makefile|   2 +
 arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi | 120 ++
 arch/arm/dts/stm32mp157-pinctrl.dtsi |  74 ++
 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 175 +++
 arch/arm/dts/stm32mp157a-dk1.dts | 262 ++
 arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi |   6 +
 arch/arm/dts/stm32mp157c-dk2.dts |  67 ++
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi |  36 ++-
 arch/arm/dts/stm32mp157c-ed1.dts |  47 ++--
 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi |  19 +-
 arch/arm/dts/stm32mp157c-ev1.dts | 100 +
 arch/arm/dts/stm32mp157c.dtsi| 272 ---
 12 files changed, 1106 insertions(+), 74 deletions(-)
 create mode 100644 arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi
 create mode 100644 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157a-dk1.dts
 create mode 100644 arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157c-dk2.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 876c032d1179..89d587ae5d75 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -575,6 +575,8 @@ dtb-$(CONFIG_ARCH_ASPEED) += ast2500-evb.dtb
 dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
 
 dtb-$(CONFIG_TARGET_STM32MP1) += \
+   stm32mp157a-dk1.dtb \
+   stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb
 
diff --git a/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi 
b/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi
new file mode 100644
index ..7d9b95ccf166
--- /dev/null
+++ b/arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * STM32MP157C DK1/DK2 BOARD configuration
+ * 1x DDR3L 4Gb, 16-bit, 533MHz.
+ * Reference used NT5CC256M16DP-DI from NANYA
+ *
+ * DDR type / Platform DDR3/3L
+ * freq533MHz
+ * width   16
+ * datasheet   0  = MT41J256M16-187 / DDR3-1066 bin G
+ * DDR density 4
+ * timing mode optimized
+ * Scheduling/QoS options : type = 2
+ * address mapping : RBC
+ * Tc > + 85C : N
+ */
+#define DDR_MEM_NAME "DDR3-1066/888 bin G 1x4Gb 533MHz v1.43"
+#define DDR_MEM_SPEED 533
+#define DDR_MEM_SIZE 0x2000
+
+#define DDR_MSTR 0x00041401
+#define DDR_MRCTRL0 0x0010
+#define DDR_MRCTRL1 0x
+#define DDR_DERATEEN 0x
+#define DDR_DERATEINT 0x0080
+#define DDR_PWRCTL 0x
+#define DDR_PWRTMG 0x00400010
+#define DDR_HWLPCTL 0x
+#define DDR_RFSHCTL0 0x0021
+#define DDR_RFSHCTL3 0x
+#define DDR_RFSHTMG 0x0081008B
+#define DDR_CRCPARCTL0 0x
+#define DDR_DRAMTMG0 0x121B2414
+#define DDR_DRAMTMG1 0x000A041C
+#define DDR_DRAMTMG2 0x0608090F
+#define DDR_DRAMTMG3 0x0050400C
+#define DDR_DRAMTMG4 0x08040608
+#define DDR_DRAMTMG5 0x06060403
+#define DDR_DRAMTMG6 0x02020002
+#define DDR_DRAMTMG7 0x0202
+#define DDR_DRAMTMG8 0x1005
+#define DDR_DRAMTMG14 0x00A0
+#define DDR_ZQCTL0 0xC240
+#define DDR_DFITMG0 0x02060105
+#define DDR_DFITMG1 0x0202
+#define DDR_DFILPCFG0 0x0700
+#define DDR_DFIUPD0 0xC043
+#define DDR_DFIUPD1 0x
+#define DDR_DFIUPD2 0x
+#define DDR_DFIPHYMSTR 0x
+#define DDR_ADDRMAP1 0x00070707
+#define DDR_ADDRMAP2 0x
+#define DDR_ADDRMAP3 0x1F00
+#define DDR_ADDRMAP4 0x1F1F
+#define DDR_ADDRMAP5 0x06060606
+#define DDR_ADDRMAP6 0x0F060606
+#define DDR_ADDRMAP9 0x
+#define DDR_ADDRMAP10 0x
+#define DDR_ADDRMAP11 0x
+#define DDR_ODTCFG 0x06000600
+#define DDR_ODTMAP 0x0001
+#define DDR_SCHED 0x0C01
+#define DDR_SCHED1 0x
+#define DDR_PERFHPR1 0x0101
+#define DDR_PERFLPR1 0x08000200
+#define DDR_PERFWR1 0x08000400
+#define DDR_DBG0 0x
+#define DDR_DBG1 0x
+#define DDR_DBGCMD 0x
+#define DDR_POISONCFG 0x
+#define DDR_PCCFG 0x0010
+#define DDR_PCFGR_0 0x0001
+#define DDR_PCFGW_0 0x
+#define DDR_PCFGQOS0_0 0x02100C03
+#define DDR_PCFGQOS1_0

[U-Boot] [PATCH 0/4] Add STM32MP1 Discovery boards


This series:
 - Synchronizes DT with kernel one
 - Adds STM32MP1 Discovery boards DK1 and DK2
 - Adds power supply information at boot for DK1 and DK2 boards


Patrice Chotard (4):
  ARM: dts: stm32: Synchronize DT with kernel one
  board: stm32mp1: Update README file
  Board: stm32mp1:  Add supply current boot information
  ARM: dts: stm32mp1: Add adc nodes

 arch/arm/dts/Makefile|   2 +
 arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi | 120 ++
 arch/arm/dts/stm32mp157-pinctrl.dtsi |  81 +++
 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 196 
 arch/arm/dts/stm32mp157a-dk1.dts | 262 ++
 arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi |   6 +
 arch/arm/dts/stm32mp157c-dk2.dts |  67 ++
 arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi |  36 ++-
 arch/arm/dts/stm32mp157c-ed1.dts |  47 ++--
 arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi |  19 +-
 arch/arm/dts/stm32mp157c-ev1.dts | 100 +
 arch/arm/dts/stm32mp157c.dtsi| 272 ---
 board/st/stm32mp1/README |  23 ++
 board/st/stm32mp1/stm32mp1.c | 154 -
 14 files changed, 1310 insertions(+), 75 deletions(-)
 create mode 100644 arch/arm/dts/stm32mp15-ddr3-1x4Gb-1066-binG.dtsi
 create mode 100644 arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157a-dk1.dts
 create mode 100644 arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp157c-dk2.dts

-- 
1.9.1

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

[U-Boot] [PATCH 3/4] Board: stm32mp1: Add supply current boot information

For DK1/DK2 boards, check if power supply provides enough current
to allow the board to boot correctly.
ADC@0 channel 18 and 19 are connected to USB type-C CC1 and CC2
signals. The table below shows the behavior for different range of
CC1 or CC2:

  range   | power supply | red led |  console message
  (Volts) |   (Amps) | blinks  |
--|--|-|---
[2.10 - 1.23[ | 3|   NO|NO
[1.23 - 0.66[ | 1.5  | 3 times | WARNING 1.5A power supply detected
[0.66 - 0]| 0.5  | 2 times | WARNING 500mA power supply detected

If detected current is < 3A, red led is kept ON after blinking.

Signed-off-by: Patrice Chotard 
---

 board/st/stm32mp1/stm32mp1.c | 154 ++-
 1 file changed, 153 insertions(+), 1 deletion(-)

diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 07d1addb2a83..253094e6b418 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -2,9 +2,10 @@
 /*
  * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
  */
+#include 
+#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,10 @@ DECLARE_GLOBAL_DATA_PTR;
 #define STM32MP_GGPIO 0x38
 #define STM32MP_GGPIO_VBUS_SENSING BIT(21)
 
+#define USB_WARNING_LOW_THRESHOLD_UV   66
+#define USB_START_LOW_THRESHOLD_UV 123
+#define USB_START_HIGH_THRESHOLD_UV210
+
 int checkboard(void)
 {
int ret;
@@ -210,6 +215,145 @@ clk_err:
return ret;
 }
 
+static int get_led(struct udevice **dev, char *led_string)
+{
+   char *led_name;
+   int ret;
+
+   led_name = fdtdec_get_config_string(gd->fdt_blob, led_string);
+   if (!led_name) {
+   pr_debug("%s: could not find %s config string\n",
+__func__, led_string);
+   return -ENOENT;
+   }
+   ret = led_get_by_label(led_name, dev);
+   if (ret) {
+   debug("%s: get=%d\n", __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int setup_led(enum led_state_t cmd)
+{
+   struct udevice *dev;
+   int ret;
+
+   ret = get_led(, "u-boot,boot-led");
+   if (ret)
+   return ret;
+
+   ret = led_set_state(dev, cmd);
+   return ret;
+}
+
+static int board_check_usb_power(void)
+{
+   struct ofnode_phandle_args adc_args;
+   struct udevice *adc;
+   struct udevice *led;
+   ofnode node;
+   unsigned int raw;
+   int max_uV = 0;
+   int ret, uV, adc_count;
+   u8 i, nb_blink;
+
+   node = ofnode_path("/config");
+   if (!ofnode_valid(node)) {
+   debug("%s: no /config node?\n", __func__);
+   return -ENOENT;
+   }
+
+   /*
+* Retrieve the ADC channels devices and get measurement
+* for each of them
+*/
+   adc_count = ofnode_count_phandle_with_args(node, "st,adc_usb_pd",
+  "#io-channel-cells");
+   if (adc_count < 0) {
+   if (adc_count == -ENOENT)
+   return 0;
+
+   pr_err("%s: can't find adc channel (%d)\n", __func__,
+  adc_count);
+
+   return adc_count;
+   }
+
+   for (i = 0; i < adc_count; i++) {
+   if (ofnode_parse_phandle_with_args(node, "st,adc_usb_pd",
+  "#io-channel-cells", 0, i,
+  _args)) {
+   pr_debug("%s: can't find /config/st,adc_usb_pd\n",
+__func__);
+   return 0;
+   }
+
+   ret = uclass_get_device_by_ofnode(UCLASS_ADC, adc_args.node,
+ );
+
+   if (ret) {
+   pr_err("%s: Can't get adc device(%d)\n", __func__,
+  ret);
+   return ret;
+   }
+
+   ret = adc_channel_single_shot(adc->name, adc_args.args[0],
+ );
+   if (ret) {
+   pr_err("%s: single shot failed for %s[%d]!\n",
+  __func__, adc->name, adc_args.args[0]);
+   return ret;
+   }
+   /* Convert to uV */
+   if (!adc_raw_to_uV(adc, raw, )) {
+   if (uV > max_uV)
+   max_uV = uV;
+   pr_debug("%s: %s[%02d] = %u, %d uV\n", __func__,
+adc->name, adc_args.args[0], raw, uV);
+   } else {
+   pr_err("%s: Can't get uV value for %s[%d]\n",
+  __func__, adc->name, adc_args.args[0]);
+   }
+   }
+
+   /*
+* If

[U-Boot] [PATCH 2/4] board: stm32mp1: Update README file

Update README with DK1 and DK2 boards related informations

Signed-off-by: Patrice Chotard 
---

 board/st/stm32mp1/README | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/board/st/stm32mp1/README b/board/st/stm32mp1/README
index 72b28fabfc08..1cd3534ae4e7 100644
--- a/board/st/stm32mp1/README
+++ b/board/st/stm32mp1/README
@@ -35,6 +35,8 @@ And the necessary drivers
 Currently the following boards are supported:
 + stm32mp157c-ev1
 + stm32mp157c-ed1
++ stm32mp157a-dk1
++ stm32mp157c-dk2
 
 3. Boot Sequences
 =
@@ -76,6 +78,12 @@ the supported device trees for stm32mp157 are:
 + ed1: daughter board with pmic stpmic1
   dts: stm32mp157c-ed1
 
++ dk1: Discovery board
+  dts: stm32mp157a-dk1
+
++ dk2: Discovery board = dk1 with a BT/WiFI combo and a DSI panel
+  dts: stm32mp157c-dk2
+
 5. Build Procedure
 ==
 
@@ -127,6 +135,11 @@ the supported device trees for stm32mp157 are:
# make stm32mp15_basic_defconfig
# make DEVICE_TREE=stm32mp157c-ed1 all
 
+  d) basic boot on dk2
+   # export KBUILD_OUTPUT=stm32mp15_basic
+   # make stm32mp15_basic_defconfig
+   # make DEVICE_TREE=stm32mp157c-dk2 all
+
 6. Output files
 
   BootRom and TF-A expect binaries with STM32 image header
@@ -159,6 +172,16 @@ You can select the boot mode, on the board ed1 with the 
switch SW1
   Recovery 1   1   0
   Recovery 0   0   0
 
+- on board DK1/DK2 with the switch SW1 : BOOT0, BOOT2
+  (BOOT1 forced to 0, NOR not supported)
+
+ --
+  Boot Mode   BOOT2  BOOT0
+ --
+  Reserved 1  0
+  SD-Card  1  1
+  Recovery 0  0
+
 Recovery is a boot from serial link (UART/USB) and it is used with
 STM32CubeProgrammer tool to load executable in RAM and to update the flash
 devices available on the board (NOR/NAND/eMMC/SDCARD).
-- 
1.9.1

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

Re: [U-Boot] [PATCH 00/40] x86: Add support for booting from TPL

2019-02-12 Thread Simon Glass

Hi Bin,

On Wed, 30 Jan 2019 at 04:59, Simon Glass  wrote:
>
> At present SPL is used on 64-bit platforms, to allow SPL to be built as
> a 32-bit program and U-Boot proper to be built as 64-bit.
>
> However it is useful to be able to use SPL on any x86 platform, where
> U-Boot needs to be updated in the field. Then SPL can select which U-Boot
> to run (A or B) and most of the code can be updated. Similarly, using TPL
> allows both SPL and U-Boot to be updated. This is the best approach, since
> it means that all of U-Boot proper as well as SPL (in particular SDRAM
> init) can be updated in the field. This provides for the smallest possible
> amount of read-only (non-updateable) code: just the TPL code.
>
> This series contains a number of changes to allow x86 boards to use TPL,
> SPL and U-Boot proper. As a test, it is enabled for samus with a new
> chromebook_samus_tpl board.
>
>
> Simon Glass (40):
>   binman: Don't generate an error in 'text' entry constructor
>   binman: Don't show image-skip message by default
>   binman: Add a missing comment in Entry_vblock
>   dm: core: Fix translate condition in ofnode_get_addr_size()
>   cros_ec: Use a hyphen in the uclass name
>   spl: Allow sandbox to build a device-tree file
>   RFC: binman: Allow sections to have an offset
>   x86: start64: Fix copyright message
>   x86: mp_init: Use proper error numbers
>   x86: Add a way to reinit the cpu
>   x86: dts: Add device-tree labels for rtc and reset
>   x86: Update a stale comment about ifdtool
>   x86: Support SPL and TPL
>   x86: Support booting with TPL
>   x86: Add a handoff header file
>   x86: broadwell: Improve SDRAM debugging output
>   x86: broadwell: Allow SDRAM init from SPL
>   x86: Move init of debug UART to cpu.c
>   x86: broadwell: Split CPU init
>   x86: Add support for starting from SPL/TPL
>   x86: Allow 16-bit init to be in TPL
>   x86: broadwell: Allow booting from SPL
>   x86: broadwell: Select refcode and CPU code for SPL
>   x86: Add common Intel code for SPL
>   x86: Support saving MRC data from SPL
>   x86: Add a simple TPL implementations
>   x86: mrccache: Add more debugging
>   x86: Add a sysreset driver for the Intel PCH
>   x86: Support TPL in Intel common code
>   x86: Don't set up MTRRs in SPL
>   x86: Don't generate a bootstage report in SPL
>   x86: Support PCI VGA ROM when TPL is used
>   x86: sysreset: Implement the get_last() method
>   x86: Add documention on the samus flashmap
>   x86: samus: Update device tree for SPL
>   x86: samus: Update device tree for verified boot
>   x86: Update device tree for TPL
>   x86: Update device tree for Chromium OS verified boot
>   x86: Fix device-tree indentation
>   x86: samus: Add a target to boot through TPL

Just checking if you have any comments on this series?

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

Re: [U-Boot] [U-Boot, 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now【请注意，邮件由u-boot-boun...@lists.denx.de代发】

2019-02-12 Thread Simon Glass

HI Andy,

On Tue, 12 Feb 2019 at 04:05, Andy Yan  wrote:
>
> Hi Philipp:
>
>  Sorry for the late reply, we just come back from the Chinese Spring
> Festival.
>
> On 2019/2/1 下午6:26, Philipp Tomsich wrote:
> > Kever,
> >
> > Independent of whether we revert this for the current cycle (and also
> > independent of
> > if I ever find the other patch you had been referring to — I couldn’t
> > find it in my local
> > mailing list archive) and then deprecate it for the next release
> > (unless converted to
> > DM), we still have a number of architectural issues that need to be
> > addressed:
>
> I still doubt  is this a right  work-flow for patch apply. Before we
> apply  a patch  which will break many other boards , should we  make
> sure there is a solution patch applied for these boars first?
>
>
> > 1.This really should be a driver under DTS control.
> > 2.We need to not get away from configuring SOM-specific addresses via
> > Kconfig
> >
> > Both these issues are technical debt that we’ve accumulated over the
> > last 18 months
> > and need to address for the sake of future maintainability.
> > E.g. ‘setting an address to 0x0 via Kconfig to disable a
> > driver/feature’ really isn’t in line
> > with the architectural direction of U-Boot.
> >
> For technical side, I think CONFIG_ROCKCHIP_BOOT_MODE_REG is necessary
> here, we will read this register from save_boot_params when we get out
> from bootrom,  the dtb is not available at this point.

Yes this is happening very early, but I wonder why this is necessary?
Can it be moved to later?

The call to check_back_to_brom_dnl_flag() happens much later so there
should be no problem to convert that.

>
> On the other hand, almost rockchip based products use a recovery key to
> enter download(upgrade)mode, this is a muti-funtion key, most of them
> reuse with vol+- key,  we would like the u-boot share
>
> dtb with linux kernel. To keep the linux kernel dts as clean as possible
> ,we don't want to add another dts property to describe this key either.
> This is why I implement function rockchip_dnl_key_pressed as __weak.
>

OK, but given that it is called later, it seems to me that it could
use a driver.

Regards,
Simon


>
> > I don’t have my own house completely in order (I’ve been talking for a
> > year now about
> > finally wrapping the RGMII/GMII selection into an ioctl-call to a
> > driver) yet, but that doesn’t
> > mean that we we should delay this clean-up more than absolutely necessary.
> >
> > Thanks,
> > Philipp.
> >
> >> On 01.02.2019, at 10:34, Philipp Tomsich
> >>  >> > wrote:
> >>
> >>
> >>
> >>> On 01.02.2019, at 10:32, Kever Yang  >>> > wrote:
> >>>
> >>> Hi Philipp,
> >>>
> >>>This is not right,  this patch should not merged like this!!!
> >>>
> >>>I have give my review comment in previous mail, and this will break
> >>> many boards.
> >>>
> >>>My another patch do not break anything, but you insist NAK it
> >>> without acceptable reason;
> >>
> >> What other patch?
> >> I don’t remember seeing that one...
> >>
> >>>This patch definitely break other board and I have comment it, but
> >>> you just ignore other people's review and merge it, good job!
> >>>
> >>> Thanks,
> >>> - Kever
> >>> On 02/01/2019 05:12 AM, Philipp Tomsich wrote:
> > This function causes a 5-second delay and stops the display working on
> > minnie. This code should be in a driver and should only be enabled by
> > a device-tree property, so that it does not affect devices which
> > do not
> > have this feature.
> >
> > Signed-off-by: Simon Glass  > >
> > Reviewed-by: Philipp Tomsich
> >  > >
> > ---
> >
> > arch/arm/mach-rockchip/boot_mode.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
>  Applied to u-boot-rockchip, thanks!
>  ___
>  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
> >
> ___
> 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] [U-Boot, v4, 1/1] avb: add support for named persistent values

2019-02-12 Thread Simon Glass

Hi Igor,

On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk  wrote:
>
> Hi Tom, Simon,
>
> So I did a little investigation and found out that, the issue in that
> hcreate_r() invocation in the tee sandbox driver fails because the
> hashtable was allocated before.
> Debugging showed that the sandbox tee driver is probed twice every
> time (although remove() is never called, it's behaves like there are
> two "tee" nodes in DT), and still haven't found the root cause (I
> think Simon can help with the hint where to look).
> I was assuming that those returned udevice pointers are kept in some
> global state but seem that they are de-allocated at some point.
> Have you ever faced the same behavior?

Not really. If the driver is probed before relocation then it may be
probed again after relocation. You should be able to tell that by
check gd->flags.

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

[U-Boot] [PATCH] usb: host: Print device name when scanning

2019-02-12 Thread Ismael Luceno Cortes

Signed-off-by: Ismael Luceno 
---
 drivers/usb/host/usb-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index 611ea97a72..0575f5393b 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -255,7 +255,7 @@ int usb_init(void)
 
uclass_foreach_dev(bus, uc) {
/* init low_level USB */
-   printf("USB%d:   ", count);
+   printf("USB%d(%s):   ", count, bus->name);
count++;
 
 #ifdef CONFIG_SANDBOX
-- 
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K

2019-02-12 Thread Marcin Wojtas

Hi Patrick,

You can refer to the mainline edk2 patch:
https://github.com/tianocore/edk2-platforms/commit/bf1c4a2cf8024669d1748e78c7e417433f85707e

Best regards,
Marcin

wt., 12 lut 2019 o 10:38 Alexander Graf  napisał(a):

> On 02/04/2019 05:51 PM, Patrick Wildt wrote:
> > On Fri, Apr 06, 2018 at 12:22:03PM +0200, Alexander Graf wrote:
> >> On 31.03.18 16:13, Mark Kettenis wrote:
> >>> Currently U-Boot doesn't make any effort to reserve the memory used by
> >>> ARM Trusted Firmware on these platforms.  The result is that the
> >>> memory is listed as available in the EFI memory map.  And as soon as a
> >>> loaded kernel tries to use this memory things explode.  I've seen this
> >>> with the OpenBSD kernel.  But I totally expect a Linux kernel to
> >>> suffer the same fate.
> >>>
> >>> I'm currently using the diff below, but it is not entirely clear to me
> >>> if arch_early_init_r() is the appropriate place to do this.  I'm also
> >>> wondering whether the block should also be marked as reserved in the
> >>> FDT using fdt_add_mem_rsv().  If the latter is required this probably
> >>> needs to be done by ft_board_setup() or ft_system_setup().
> >>>
> >>> The address and size of the region have been taken from Marvell's ATF
> >>> fork at
> >>>
> >>>https://github.com/MarvellEmbeddedProcessors/atf-marvell
> >>>
> >>> The memory layout is defined in
> >>>
> >>>plat/marvell/a8k/common/include/platform_def.h
> >>>
> >>> where there are lots of defines and a diagram that attempt to describe
> >>> the memory.  It is not entirely obvious to me what part needs to be
> >>> reserved.  But 0x040-0x0420 works.
> >>>
> >>>
> >>>
> >>>
> >>> diff --git a/arch/arm/mach-mvebu/arm64-common.c
> b/arch/arm/mach-mvebu/arm64-common.c
> >>> index 3c84043a2c..895cd2852f 100644
> >>> --- a/arch/arm/mach-mvebu/arm64-common.c
> >>> +++ b/arch/arm/mach-mvebu/arm64-common.c
> >>> @@ -95,5 +95,11 @@ int arch_early_init_r(void)
> >>> pci_init();
> >>>   #endif
> >>>
> >>> +#ifdef CONFIG_EFI_LOADER
> >>> +   /* Reserve trusted SRAM section */
> >>> +   efi_add_memory_map(0x0400, 0x0020 >> EFI_PAGE_SHIFT,
> >>> +  EFI_RESERVED_MEMORY_TYPE, false);
> >> I also forgot to comment here. 2MB is probably not enough:
> >>
> >>
> >>
> https://github.com/MarvellEmbeddedProcessors/atf-marvell/blob/atf-v1.3-armada-17.10/plat/marvell/a8k/common/include/platform_def.h#L110
> >>
> >> That sounds more like it should span 65MB (PLAT_MARVELL_TRUSTED_ROM_SIZE
> >> plus 0x10).
> >>
> >> Looking at what edk2 does, it seems to use the same range as you:
> >>
> >>
> >>
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/marvell-armada-wip/Platforms/Marvell/Armada/Armada.dsc.inc#L347
> >>
> >> So let's also CC Marcin :). Maybe his range is too short!
> >>
> >>
> >> Alex
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.denx.de/listinfo/u-boot
> > The current ATF and EDK2 branch from Marvell seem to reserve a bit more.
> > I just had the same issue and am using this diff.  This then creates the
> > same map of usable memory as EDK2 does.
>
> Could you please resend as proper patch (with SoB, separate email) with
> a reference to the edk2 code in the commit message?
>
>
> Thanks,
>
> Alex
>
> >
> > Best regards,
> > Patrick
> >
> > diff --git a/arch/arm/mach-mvebu/arm64-common.c
> b/arch/arm/mach-mvebu/arm64-common.c
> > index 47bbf69944..56c0d3f6b9 100644
> > --- a/arch/arm/mach-mvebu/arm64-common.c
> > +++ b/arch/arm/mach-mvebu/arm64-common.c
> > @@ -14,6 +14,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -142,5 +143,11 @@ int arch_early_init_r(void)
> >   pci_init();
> >   #endif
> >
> > +#ifdef CONFIG_EFI_LOADER
> > + /* Reserve trusted SRAM section */
> > + efi_add_memory_map(0x0400, 0x0140 >> EFI_PAGE_SHIFT,
> > +EFI_RESERVED_MEMORY_TYPE, false);
> > +#endif
> > +
> >   return 0;
> >   }
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH v2 0/4] sunxi: SPI: Add SUN6I generation SPI support

On Tue, 12 Feb 2019 16:15:22 +0530
Jagan Teki  wrote:

> On Tue, Feb 12, 2019 at 4:11 PM Andre Przywara  wrote:
> >
> > We already have a driver for the SPI devices in older Allwinner CPUs.
> > Newer SoCs (SUN6I generation) have a similar, but improved IP block.
> > This series adds support for that, so we can access the SPI flash that
> > some newer boards come with.
> > This series gathers some patches that have appeared on the list in one
> > form or another before (hence the v2 tag), but brings them all together
> > and updates them.
> >
> > The SUN4I/SUN6I SPI devices share a very similar architecure, but differ
> > annoyingly in quite some details, to a point where a shared driver
> > would look unnecessarily complicated. So we use an #ifdef based approach,
> > which keeps the driver simple, at the cost of not being able to access
> > both types of device in one binary build. But since there are no SoCs
> > which feature both types, this is a theoretical disadvantage.
> >
> > Patch 1/4 moves the clock toggling from the probe/remove to the
> > claim/release-bus stage.
> > Patch 2/4 adds the SPI gate clocks and reset gates to the clock drivers,
> > also describes at least the enable bit for the SPI mod clock. This is used
> > in patch 3/4, which uses the new DM clock framework in the driver, helping
> > to abstract differences between the SUN4I/SUN6I types.
> > Patch 4/4 eventually adds support for the new SUN6I generation SPI device.
> > The actual device support is determined at compile time, based on the
> > CONFIG_SUNXI_GEN_SUN6I symbol.
> >
> > What's left out of this series is the config bits needed to actually
> > activate the support for a board. At the moment this is unnecessarily
> > verbose, so that Oskari is looking at simplifying this at the Kconfig
> > level, which would complement this series.
> >
> > This has been briefly tested on the Pine64-LTS and the OrangePi PC2 board.
> > Please test them if you have other devices with a SUN6I SPI generation.  
> 
> I have new series for this which I sent two days back [1]. which uses
> same sun4i driver and implement enum reg set to avoid ifdef.
> 
> [1] https://patchwork.ozlabs.org/cover/1039178/

Ah, sorry, I missed that completely. Will have a look at this later on.

Cheers,
Andre.


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

[U-Boot] [PATCH 1/1] test: let use gdbserver for all sandbox targets

2019-02-12 Thread Igor Opaniuk

Enable usage of gdbserver for all sandbox targets (sandbox,
sandbox_flattree etc.).

Signed-off-by: Igor Opaniuk 
---
 test/py/conftest.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/test/py/conftest.py b/test/py/conftest.py
index 5c658b8..e40cbf0 100644
--- a/test/py/conftest.py
+++ b/test/py/conftest.py
@@ -117,8 +117,8 @@ def pytest_configure(config):
 mkdir_p(persistent_data_dir)
 
 gdbserver = config.getoption('gdbserver')
-if gdbserver and board_type != 'sandbox':
-raise Exception('--gdbserver only supported with sandbox')
+if gdbserver and not board_type.startswith('sandbox'):
+raise Exception('--gdbserver only supported with sandbox targets')
 
 import multiplexed_log
 log = multiplexed_log.Logfile(result_dir + '/test-log.html')
-- 
2.7.4

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

Re: [U-Boot] [PATCH v7 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

2019-02-12 Thread Chee, Tien Fong

On Tue, 2019-02-12 at 05:49 -0800, Dalon L Westergreen wrote:
> On Tue, 2019-02-12 at 11:17 +0100, Marek Vasut wrote:
> > 
> > On 2/12/19 11:13 AM, Chee, Tien Fong wrote:
> > > 
> > > On Tue, 2019-02-12 at 10:43 +0100, Marek Vasut wrote:
> > > > 
> > > > On 2/12/19 10:35 AM, Chee, Tien Fong wrote:
> > > > [...]
> > > > 
> > > > > 
> > > > > > 
> > > > > > my preference for the fit image would be
> > > > > > 
> > > > > > ...
> > > > > > images {
> > > > > >   fpga@1 {
> > > > > > description = "FPGA Periph";
> > > > > > ...
> > > > > > type = "fpga_periph";
> > > > > > ...
> > > > > >   }
> > > > > >   fpga@2 {
> > > > > > description = "FPGA Core";
> > > > > > ...
> > > > > > type = "fpga" or
> > > > > > "fpga_core";
> > > > > I'm good with "fpga".
> > > > > > 
> > > > > > ...
> > > > > >   }
> > > > > > };
> > > > > > configurations {
> > > > > >   default = "config@1"
> > > > > >   config@1 {
> > > > > >   fpga = "fpga@1";  // periph only
> > > > > >   };
> > > > > >   config@2 {
> > > > > >   fpga = "fpga@1", "fpga@2";
> > > > > >   };
> > > > > > };
> > > > > > 
> > > > > > with the expectation that the order of fpga@1 and fpga@2 in
> > > > > > confi
> > > > > > g@2
> > > > > > is not relevant.  the code should find the fpga_periph type
> > > > > > and
> > > > > > program
> > > > > > it first.  just my comment, i dont like rellying on the
> > > > > > order or
> > > > > > name.
> > > > > I can add support for above implementation although this adds
> > > > > more
> > > > > complexity to the driver.
> > > > You can have fpga node and e.g. fpga-name node in the
> > > > configurations
> > > > section to discern which phandle there is the core and which is
> > > > the
> > > > peripheral RBF. Would that work ?
> > > > 
> > > So something like that?
> > > 
> > > ...
> > > 
> > > images {
> > >   fpga-periph@1 {
> > >   description = "FPGA Periph";
> > >   ...
> > >   type = "fpga_periph";
> > Do we need a new type for the periph/core distinction ?
> not really, using the node name is fine with me as is shown below.
> when i suggested that my intent was to allow the name to be
> independant of the node name still envisioning scenarios where
> the fit image has multiple fpga images.
Great, then i will work out the codes which able to identify the
bitstream type based on the node name "fpga-core" and "fpga-periph"

Thanks for finalizing the implementation.
> 
> > 
> > 
> > > 
> > >   ...
> > >   }
> > >   fpga-core@2 {
> > >   description = "FPGA Core";
> > >   ...
> > >   type = "fpga";
> > >   ...
> > >   }
> > > };
> > > configurations {
> > >   default = "config@1"
> > >   config@1 {
> > >   fpga = "fpga-periph@1";  // periph only
> > >   };
> > >   config@2 {
> > >   fpga = "fpga-periph@1", "fpga-core@2";
> > >   };
> > > };
> > > 
> > > > 
> > > > > 
> > > > > Marek, are you OK with this implementation?
> > > > Looks OK to me. Dalon ?
> > > > 
> > > > [...]
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

2019-02-12 Thread Philipp Tomsich



> On 12.02.2019, at 13:38, David Wu  wrote:
> 
> Hi Philipp,
> 
> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>> That said, I have been fighting issues from this patchset when trying to read
>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
> 
> I think you can also add the simple ops if necessary. Full pinctrl
> should only be used at the U-boot stage, or the SPL stage where the TPL is 
> available.
> 
> For most boards about 3288, there is no need to enable pinctrl at SPL
> stage, such as Tinker board.

Could you check whether TPL_MAX_SIZE and SPL_MAX_SIZE are correct for
the RK3288? If not, please submit a patch.

>> Unfortunately, in this merge I had to make a judgement call between insisting
>> on code-quality and getting the full pinctrl-driver merged.  With this 
>> release
>> cycle being longer and having 5 RCs, I figured we’ll have time to iron out 
>> any
>> wrinkles...
> 
> 

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

Re: [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values

2019-02-12 Thread Igor Opaniuk

Hi Tom, Simon,

So I did a little investigation and found out that, the issue in that
hcreate_r() invocation in the tee sandbox driver fails because the
hashtable was allocated before.
Debugging showed that the sandbox tee driver is probed twice every
time (although remove() is never called, it's behaves like there are
two "tee" nodes in DT), and still haven't found the root cause (I
think Simon can help with the hint where to look).
I was assuming that those returned udevice pointers are kept in some
global state but seem that they are de-allocated at some point.
Have you ever faced the same behavior?

I've done all testing on sandbox_flattree setup (it's not reproducing
on a simple sandbox setup):
./test/py/test.py --bd sandbox_flattree --build -s --gdbserver localhost:1234

During the first probe:
Breakpoint 1, sandbox_tee_probe (dev=0x15944610) at ../drivers/tee/sandbox.c:372
372 if (!hcreate_r(pstorage_max, _htab)) {

(gdb) info threads
 Id   Target Id   Frame
* 1Thread 13048.13048 "u-boot" sandbox_tee_probe (dev=0x15944610)
at ../drivers/tee/sandbox.c:372
(gdb) python print(gdb.selected_inferior().pid)
13048

(gdb) print pstorage_htab.table
$6 = (struct _ENTRY *) 0x0

(gdb) bt
#0  sandbox_tee_probe (dev=0x15944610) at ../drivers/tee/sandbox.c:372
#1  0x00432a7f in device_probe (dev=0x15944610) at
../drivers/core/device.c:418
#2  0x0044fe29 in tee_find_device (start=start@entry=0x0,
match=match@entry=0x0, data=data@entry=0x0, vers=vers@entry=0x0) at
../drivers/tee/tee-uclass.c:164
#3  0x0042de59 in get_open_session
(ops_data=ops_data@entry=0x1594cf60) at ../common/avb_verify.c:615
#4  0x0042e0e0 in invoke_func (ops_data=0x1594cf60, func=0,
num_param=2, param=0x7fffd520) at ../common/avb_verify.c:636
#5  0x0042e53a in read_rollback_index (ops=0x1594cf60,
rollback_index_slot=1, out_rollback_index=0x7fffd598) at
../common/avb_verify.c:703
#6  0x004188b3 in do_avb_read_rb (cmdtp=,
flag=, argc=, argv=) at
../cmd/avb.c:167
#7  0x0042cc43 in cmd_call (repeatable=0x7fffd5bc,
argv=0x1594ce40, argc=3, flag=, cmdtp=0x7782b0
<_u_boot_list_2_cmd_2_avb>) at ../common/command.c:565
#8  cmd_process (flag=, argc=3, argv=0x1594ce40,
repeatable=repeatable@entry=0x78f394 ,
ticks=ticks@entry=0x0) at ../common/command.c:606
#9  0x0041bdcb in run_pipe_real (pi=0x1594ccf0) at
../common/cli_hush.c:1677
#10 run_list_real (pi=) at ../common/cli_hush.c:1875
#11 0x0041c1dd in run_list (pi=0x1594ccf0) at ../common/cli_hush.c:2024
#12 parse_stream_outer (inp=inp@entry=0x7fffd730,
flag=flag@entry=2) at ../common/cli_hush.c:3216
#13 0x0041c54d in parse_file_outer () at ../common/cli_hush.c:3299
#14 0x0042c2ce in cli_loop () at ../common/cli.c:217
#15 0x00419f74 in main_loop () at ../common/main.c:63
#16 0x0041ccec in run_main_loop () at ../common/board_r.c:631
#17 0x0041cf41 in initcall_run_list (init_sequence=0x787740
) at ../include/initcall.h:35
#18 board_init_r (new_gd=, dest_addr=dest_addr@entry=0)
at ../common/board_r.c:856
#19 0x004025ee in main (argc=, argv=) at ../arch/sandbox/cpu/start.c:356


Then probed is invoked from a different thread:
gdb) c
Continuing.
[New Thread 13048.13074]

Thread 1 "u-boot" hit Breakpoint 1, sandbox_tee_probe (dev=0x15edf050)
at ../drivers/tee/sandbox.c:372
372 if (!hcreate_r(pstorage_max, _htab)) {
(gdb) print pstorage_htab.table
$7 = (struct _ENTRY *) 0x1594d010

(gdb) python print(gdb.selected_inferior().pid)
13048

(gdb) bt
#0  sandbox_tee_probe (dev=0x15edf050) at ../drivers/tee/sandbox.c:372
#1  0x00432a7f in device_probe (dev=0x15edf050) at
../drivers/core/device.c:418
#2  0x0044fe29 in tee_find_device (start=start@entry=0x0,
match=match@entry=0x4c31c2 , data=data@entry=0x0,
vers=vers@entry=0x7fffd42c) at ../drivers/tee/tee-uclass.c:164
#3  0x004c3203 in test_tee (vars=0x7fffd430, uts=0x7c50a0
) at ../test/dm/tee.c:66
#4  dm_test_tee (uts=0x7c50a0 ) at ../test/dm/tee.c:106
#5  0x004af11f in dm_do_test (uts=0x7c50a0
, of_live=false, test=0x77b568
<_u_boot_list_2_dm_test_2_dm_test_tee>) at ../test/dm/test-main.c:103
#6  dm_test_main (test_name=0x1594d1a0 "tee") at ../test/dm/test-main.c:180
#7  do_ut_dm (cmdtp=, flag=,
argc=, argv=) at
../test/dm/test-main.c:206
#8  0x0042cc43 in cmd_call (repeatable=0x7fffd5bc,
argv=0x15abab30, argc=3, flag=, cmdtp=0x779f90
<_u_boot_list_2_cmd_2_ut>) at ../common/command.c:565
#9  cmd_process (flag=, argc=3, argv=0x15abab30,
repeatable=repeatable@entry=0x78f394 ,
ticks=ticks@entry=0x0) at ../common/command.c:606
#10 0x0041bdcb in run_pipe_real (pi=0x15ab2380) at
../common/cli_hush.c:1677
#11 run_list_real (pi=) at ../common/cli_hush.c:1875
#12 0x0041c1dd in run_list (pi=0x15ab2380) at ../common/cli_hush.c:2024
#13 parse_stream_outer (inp=inp@entry=0x7fffd730,
flag=flag@entry=2) at ../common/cli_hush.c:3216
#14 0x0041c54d in

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

2019-02-12 Thread Philipp Tomsich



> On 12.02.2019, at 13:38, David Wu  wrote:
> 
> Hi Philipp,
> 
> 在 2019/2/10 上午2:24, Philipp Tomsich 写道:
>> That said, I have been fighting issues from this patchset when trying to read
>> from devices on the i2c0 bus on a RK3399—which had me add a “simple”
>> pinctrl device again, as pulling all the dependencies into the SPL is a pain.
> 
> I think you can also add the simple ops if necessary. Full pinctrl
> should only be used at the U-boot stage, or the SPL stage where the TPL is 
> available.

I started on this and will submit it with the follow-on changes that depend on 
this, as
I don’t want to pull in the ~10k of extra size.

There’s a number of failure modes in the SPL/TPL path from missing DTB nodes (as
one would need to add pre-reloc tags to all pinctrl and dependent nodes).

> For most boards about 3288, there is no need to enable pinctrl at SPL
> stage, such as Tinker board.
> 
> 
>> Unfortunately, in this merge I had to make a judgement call between insisting
>> on code-quality and getting the full pinctrl-driver merged.  With this 
>> release
>> cycle being longer and having 5 RCs, I figured we’ll have time to iron out 
>> any
>> wrinkles...
> 
> 

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

Re: [U-Boot] [PATCH v7 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

2019-02-12 Thread Dalon L Westergreen

On Tue, 2019-02-12 at 11:17 +0100, Marek Vasut wrote:
> On 2/12/19 11:13 AM, Chee, Tien Fong wrote:
> > On Tue, 2019-02-12 at 10:43 +0100, Marek Vasut wrote:
> > > On 2/12/19 10:35 AM, Chee, Tien Fong wrote:
> > > [...]
> > > 
> > > > > my preference for the fit image would be
> > > > > 
> > > > > ...
> > > > > images {
> > > > >   fpga@1 {
> > > > >   description = "FPGA Periph";
> > > > >   ...
> > > > >   type = "fpga_periph";
> > > > >   ...
> > > > >   }
> > > > >   fpga@2 {
> > > > >   description = "FPGA Core";
> > > > >   ...
> > > > >   type = "fpga" or
> > > > > "fpga_core";
> > > > I'm good with "fpga".
> > > > >   ...
> > > > >   }
> > > > > };
> > > > > configurations {
> > > > >   default = "config@1"
> > > > >   config@1 {
> > > > >   fpga = "fpga@1";  // periph only
> > > > >   };
> > > > >   config@2 {
> > > > >   fpga = "fpga@1", "fpga@2";
> > > > >   };
> > > > > };
> > > > > 
> > > > > with the expectation that the order of fpga@1 and fpga@2 in confi
> > > > > g@2
> > > > > is not relevant.  the code should find the fpga_periph type and
> > > > > program
> > > > > it first.  just my comment, i dont like rellying on the order or
> > > > > name.
> > > > I can add support for above implementation although this adds more
> > > > complexity to the driver.
> > > You can have fpga node and e.g. fpga-name node in the configurations
> > > section to discern which phandle there is the core and which is the
> > > peripheral RBF. Would that work ?
> > > 
> > So something like that?
> > 
> > ...
> > 
> > images {
> >   fpga-periph@1 {
> > description = "FPGA Periph";
> > ...
> > type = "fpga_periph";
> 
> Do we need a new type for the periph/core distinction ?

not really, using the node name is fine with me as is shown below.
when i suggested that my intent was to allow the name to be
independant of the node name still envisioning scenarios where
the fit image has multiple fpga images.

> 
> > ...
> >   }
> >   fpga-core@2 {
> > description = "FPGA Core";
> > ...
> > type = "fpga";
> > ...
> >   }
> > };
> > configurations {
> >   default = "config@1"
> >   config@1 {
> >   fpga = "fpga-periph@1";  // periph only
> >   };
> >   config@2 {
> >   fpga = "fpga-periph@1", "fpga-core@2";
> >   };
> > };
> > 
> > > > Marek, are you OK with this implementation?
> > > Looks OK to me. Dalon ?
> > > 
> > > [...]
> 
> 

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

Re: [U-Boot] [PATCH v3] dm: spi: Read default speed and mode values from DT

2019-02-12 Thread Patrick DELAUNAY

Hi Jagan

> From: Jagan Teki 
> Sent: samedi 9 février 2019 17:22
> Subject: Re: [PATCH v3] dm: spi: Read default speed and mode values from DT
> 
> On Mon, Jan 28, 2019 at 2:37 PM Patrick Delaunay 
> wrote:
> >
> > This patch update the behavior introduced by commit 96907c0fe50a ("dm:
> > spi: Read default speed and mode values from DT")
> >
> > In case of DT boot, don't read default speed and mode for SPI from
> > CONFIG_* but instead read from DT node. This will make sure that
> > boards with multiple SPI/QSPI controllers can be probed at different
> > bus frequencies and SPI modes.
> >
> > DT values will be always used when available (full DM support of SPI
> > slave with available DT node) even if speed and mode are requested;
> > for example in splash screen support (in splash_sf_read_raw) or in SPL
> > boot (in spl_spi_load_image).
> > The caller of spi_get_bus_and_cs() no more need to force speed=0.
> >
> > But the current behavior don't change if the SPI slave is not present
> > (device with generic driver is created automatically) or if platdata
> > is used (CONFIG_OF_PLATDATA).
> >
> >
> > Signed-off-by: Patrick Delaunay 
> > ---
> >
> > Changes in v3:
> > - complete rework of the patch-set to avoid regression
> >
> > Changes in v2:
> > - use variables to avoid duplicated code
> >
> >  README   | 3 +++
> >  cmd/sf.c | 3 +--
> >  common/spl/spl_spi.c | 2 ++
> >  drivers/spi/spi-uclass.c | 4 +++-
> >  include/spi.h| 9 +
> >  5 files changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/README b/README
> > index 17d56b8..f7fe74f 100644
> > --- a/README
> > +++ b/README
> > @@ -2184,6 +2184,9 @@ The following options need to be configured:
> > CONFIG_SF_DEFAULT_MODE  (see include/spi.h)
> > CONFIG_SF_DEFAULT_SPEED in Hz
> >
> > +   In case of DT boot, SPI don't read default speed and mode
> > +   from CONFIG_*, but from platdata values computed from 
> > available
> > +   DT node
> 
> This has to update in Kconfig help info.

Ok but witch Kconfig ? whitch config ?

drivers/mtd/spi/Kconfig
config DM_SPI_FLASH

PS: In master branch, these define are not in yet managed in  Kconfig, but they 
are still managed by defines:
   scripts/config_whitelist.txt:1713:CONFIG_SF_DEFAULT_MODE
  And so documentation is done in README not in Kconfig

some migration in Kconfig is pending (moveconfig) ?

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

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

On Tue, Feb 12, 2019 at 6:37 PM Chen-Yu Tsai  wrote:
>
> On Tue, Feb 12, 2019 at 9:02 PM Jagan Teki  wrote:
> >
> > Hi Chen-Yu,
> >
> > On Tue, Feb 12, 2019 at 5:59 PM Chen-Yu Tsai  wrote:
> > >
> > > On Tue, Feb 12, 2019 at 8:22 PM Jagan Teki  
> > > wrote:
> > > >
> > > > On Tue, Feb 12, 2019 at 5:46 PM Andre Przywara  
> > > > wrote:
> > > > >
> > > > > On Tue, 12 Feb 2019 17:39:35 +0530
> > > > > Jagan Teki  wrote:
> > > > >
> > > > > > On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, 12 Feb 2019 17:30:44 +0530
> > > > > > > Jagan Teki  wrote:
> > > > > > >
> > > > > > > > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > > > > > > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux 
> > > > > > > > > > > kernel, the
> > > > > > > > > > > device tree for the Bananapi M2+ has been split into a 
> > > > > > > > > > > common dtsi file,
> > > > > > > > > > > and an SoC-specific board device tree file that includes 
> > > > > > > > > > > both the shared
> > > > > > > > > > > dtsi file and the soc dtsi file. This was done to support 
> > > > > > > > > > > both the H3
> > > > > > > > > > > and H5 variants of the same board. This is similar to 
> > > > > > > > > > > what was doen for
> > > > > > > > > >
> > > > > > > > > > s/doen/done
> > > > > > > > >
> > > > > > > > > Good catch.
> > > > > > > > >
> > > > > > > > > > > the Libre Computer ALL-H3-CC in U-boot commit 
> > > > > > > > > > > d7b17f1c24af ("sunxi: Split
> > > > > > > > > > > out common board design for ALL-H3-CC device tree").
> > > > > > > > > > >
> > > > > > > > > > > The newly split files are directly synced from Linux tag 
> > > > > > > > > > > v5.0-rc1.
> > > > > > > > > >
> > > > > > > > > > Better sync all dts(i) files on this relevant SoC, this 
> > > > > > > > > > would help to
> > > > > > > > > > track and use for rest of SoC's are inline to the same 
> > > > > > > > > > version later.
> > > > > > > > >
> > > > > > > > > Ok. Would syncing with linux-next (5.1) work for you? FYI all 
> > > > > > > > > the PRs
> > > > > > > > > for the next release have been sent out.
> > > > > > > >
> > > > > > > > Yes, better we can pick relevant version on during next MW.
> > > > > > >
> > > > > > > I think what Chen-Yu wanted to hint at is that you can this 
> > > > > > > already, by picking the patches from the currently existing 
> > > > > > > branches of the linux-sunxi repository:
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1
> > > > > > >
> > > > > > > There should be no need to wait for the Linux MW to close.
> > > > > >
> > > > > > Not for Linux, I'm referring here about u-boot MW.
> > > > >
> > > > > Why do we have to wait for so long? The next U-Boot MW is about two 
> > > > > months away from now. And with U-Boot's usage of the DT we can surely 
> > > > > minimise the risk of breaking something, by just reviewing that the 
> > > > > DT changes do not touch or interfere with any devices that U-Boot 
> > > > > cares about.
> > > > > This way we can get up-to-date DTs now (which UEFI boot benefits 
> > > > > from), so that users don't have to provide "their own" DTs.
> > > >
> > > > I knew this degree of risk with dts changes and I have no specific
> > > > reason for this except to follow U-Boot release cycle[1] not to take
> > > > new features in 'release candidate phase' which was missed.
> > > >
> > > > [1] https://www.denx.de/wiki/U-Boot/ReleaseCycle
> > >
> > > Or you can merge these patches as is for now, and sync up all the
> > > device tree files
> >
> > Can't you wait till all get in? any urgency? idea is to grab all sync
> > changes in one commit.
>
> It's not urgent at all. It's more likely that I completely forget about
> this in two months.
>
> And it will still be two commits either way you cut it: 1 for the sync,
> the other for the defconfig and MAINTAINERS entry.

OK, will look at the rest and pick accordingly. thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2019-02-12 Thread Chen-Yu Tsai

On Tue, Feb 12, 2019 at 9:02 PM Jagan Teki  wrote:
>
> Hi Chen-Yu,
>
> On Tue, Feb 12, 2019 at 5:59 PM Chen-Yu Tsai  wrote:
> >
> > On Tue, Feb 12, 2019 at 8:22 PM Jagan Teki  
> > wrote:
> > >
> > > On Tue, Feb 12, 2019 at 5:46 PM Andre Przywara  
> > > wrote:
> > > >
> > > > On Tue, 12 Feb 2019 17:39:35 +0530
> > > > Jagan Teki  wrote:
> > > >
> > > > > On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara 
> > > > >  wrote:
> > > > > >
> > > > > > On Tue, 12 Feb 2019 17:30:44 +0530
> > > > > > Jagan Teki  wrote:
> > > > > >
> > > > > > > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > > > > > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux 
> > > > > > > > > > kernel, the
> > > > > > > > > > device tree for the Bananapi M2+ has been split into a 
> > > > > > > > > > common dtsi file,
> > > > > > > > > > and an SoC-specific board device tree file that includes 
> > > > > > > > > > both the shared
> > > > > > > > > > dtsi file and the soc dtsi file. This was done to support 
> > > > > > > > > > both the H3
> > > > > > > > > > and H5 variants of the same board. This is similar to what 
> > > > > > > > > > was doen for
> > > > > > > > >
> > > > > > > > > s/doen/done
> > > > > > > >
> > > > > > > > Good catch.
> > > > > > > >
> > > > > > > > > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af 
> > > > > > > > > > ("sunxi: Split
> > > > > > > > > > out common board design for ALL-H3-CC device tree").
> > > > > > > > > >
> > > > > > > > > > The newly split files are directly synced from Linux tag 
> > > > > > > > > > v5.0-rc1.
> > > > > > > > >
> > > > > > > > > Better sync all dts(i) files on this relevant SoC, this would 
> > > > > > > > > help to
> > > > > > > > > track and use for rest of SoC's are inline to the same 
> > > > > > > > > version later.
> > > > > > > >
> > > > > > > > Ok. Would syncing with linux-next (5.1) work for you? FYI all 
> > > > > > > > the PRs
> > > > > > > > for the next release have been sent out.
> > > > > > >
> > > > > > > Yes, better we can pick relevant version on during next MW.
> > > > > >
> > > > > > I think what Chen-Yu wanted to hint at is that you can this 
> > > > > > already, by picking the patches from the currently existing 
> > > > > > branches of the linux-sunxi repository:
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1
> > > > > >
> > > > > > There should be no need to wait for the Linux MW to close.
> > > > >
> > > > > Not for Linux, I'm referring here about u-boot MW.
> > > >
> > > > Why do we have to wait for so long? The next U-Boot MW is about two 
> > > > months away from now. And with U-Boot's usage of the DT we can surely 
> > > > minimise the risk of breaking something, by just reviewing that the DT 
> > > > changes do not touch or interfere with any devices that U-Boot cares 
> > > > about.
> > > > This way we can get up-to-date DTs now (which UEFI boot benefits from), 
> > > > so that users don't have to provide "their own" DTs.
> > >
> > > I knew this degree of risk with dts changes and I have no specific
> > > reason for this except to follow U-Boot release cycle[1] not to take
> > > new features in 'release candidate phase' which was missed.
> > >
> > > [1] https://www.denx.de/wiki/U-Boot/ReleaseCycle
> >
> > Or you can merge these patches as is for now, and sync up all the
> > device tree files
>
> Can't you wait till all get in? any urgency? idea is to grab all sync
> changes in one commit.

It's not urgent at all. It's more likely that I completely forget about
this in two months.

And it will still be two commits either way you cut it: 1 for the sync,
the other for the defconfig and MAINTAINERS entry.

> > once the next merge window opens. These patches were sent a full two
> > weeks before
> > the merge window closed. AFAIK they are eligible [1] for the pending 
> > release.
>
> To be clear I knew this and same mentioned above, I missed it during last MW.

OK.

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

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

Hi Chen-Yu,

On Tue, Feb 12, 2019 at 5:59 PM Chen-Yu Tsai  wrote:
>
> On Tue, Feb 12, 2019 at 8:22 PM Jagan Teki  wrote:
> >
> > On Tue, Feb 12, 2019 at 5:46 PM Andre Przywara  
> > wrote:
> > >
> > > On Tue, 12 Feb 2019 17:39:35 +0530
> > > Jagan Teki  wrote:
> > >
> > > > On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara  
> > > > wrote:
> > > > >
> > > > > On Tue, 12 Feb 2019 17:30:44 +0530
> > > > > Jagan Teki  wrote:
> > > > >
> > > > > > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  wrote:
> > > > > > >
> > > > > > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > > > > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux 
> > > > > > > > > kernel, the
> > > > > > > > > device tree for the Bananapi M2+ has been split into a common 
> > > > > > > > > dtsi file,
> > > > > > > > > and an SoC-specific board device tree file that includes both 
> > > > > > > > > the shared
> > > > > > > > > dtsi file and the soc dtsi file. This was done to support 
> > > > > > > > > both the H3
> > > > > > > > > and H5 variants of the same board. This is similar to what 
> > > > > > > > > was doen for
> > > > > > > >
> > > > > > > > s/doen/done
> > > > > > >
> > > > > > > Good catch.
> > > > > > >
> > > > > > > > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af 
> > > > > > > > > ("sunxi: Split
> > > > > > > > > out common board design for ALL-H3-CC device tree").
> > > > > > > > >
> > > > > > > > > The newly split files are directly synced from Linux tag 
> > > > > > > > > v5.0-rc1.
> > > > > > > >
> > > > > > > > Better sync all dts(i) files on this relevant SoC, this would 
> > > > > > > > help to
> > > > > > > > track and use for rest of SoC's are inline to the same version 
> > > > > > > > later.
> > > > > > >
> > > > > > > Ok. Would syncing with linux-next (5.1) work for you? FYI all the 
> > > > > > > PRs
> > > > > > > for the next release have been sent out.
> > > > > >
> > > > > > Yes, better we can pick relevant version on during next MW.
> > > > >
> > > > > I think what Chen-Yu wanted to hint at is that you can this already, 
> > > > > by picking the patches from the currently existing branches of the 
> > > > > linux-sunxi repository:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1
> > > > >
> > > > > There should be no need to wait for the Linux MW to close.
> > > >
> > > > Not for Linux, I'm referring here about u-boot MW.
> > >
> > > Why do we have to wait for so long? The next U-Boot MW is about two 
> > > months away from now. And with U-Boot's usage of the DT we can surely 
> > > minimise the risk of breaking something, by just reviewing that the DT 
> > > changes do not touch or interfere with any devices that U-Boot cares 
> > > about.
> > > This way we can get up-to-date DTs now (which UEFI boot benefits from), 
> > > so that users don't have to provide "their own" DTs.
> >
> > I knew this degree of risk with dts changes and I have no specific
> > reason for this except to follow U-Boot release cycle[1] not to take
> > new features in 'release candidate phase' which was missed.
> >
> > [1] https://www.denx.de/wiki/U-Boot/ReleaseCycle
>
> Or you can merge these patches as is for now, and sync up all the
> device tree files

Can't you wait till all get in? any urgency? idea is to grab all sync
changes in one commit.

> once the next merge window opens. These patches were sent a full two
> weeks before
> the merge window closed. AFAIK they are eligible [1] for the pending release.

To be clear I knew this and same mentioned above, I missed it during last MW.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] cmd: ximg.c: Add support for getting external data address and length

2019-02-12 Thread tien . fong . chee

From: Tien Fong Chee 

This function supports getting both data address and length for
existing FIT subimage and FIT external data.

Signed-off-by: Tien Fong Chee 
---
 cmd/ximg.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmd/ximg.c b/cmd/ximg.c
index 6880c74..0ca37b3 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -159,9 +159,9 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char * 
const argv[])
}
}
 
-   /* get subimage data address and length */
-   if (fit_image_get_data(fit_hdr, noffset,
-   _data, _len)) {
+   /* get subimage/external data address and length */
+   if (fit_image_get_data_and_size(fit_hdr, noffset,
+  _data, _len)) {
puts("Could not find script subimage data\n");
return 1;
}
-- 
1.7.7.4

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

[U-Boot] [PATCH] fpga: Add support for getting external data address and length

2019-02-12 Thread tien . fong . chee

From: Tien Fong Chee 

This function supports getting both data address and length for
existing FPGA subimage and FPGA external data.

Signed-off-by: Tien Fong Chee 
---
 cmd/fpga.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/cmd/fpga.c b/cmd/fpga.c
index 88a8e3f..b1f224b 100644
--- a/cmd/fpga.c
+++ b/cmd/fpga.c
@@ -343,9 +343,9 @@ static int do_fpga_loadmk(cmd_tbl_t *cmdtp, int flag, int 
argc,
return CMD_RET_FAILURE;
}
 
-   /* get fpga subimage data address and length */
-   if (fit_image_get_data(fit_hdr, noffset, _data,
-  _size)) {
+   /* get fpga subimage/external data address and length */
+   if (fit_image_get_data_and_size(fit_hdr, noffset,
+  _data, _size)) {
puts("Fpga subimage data not found\n");
return CMD_RET_FAILURE;
}
-- 
1.7.7.4

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

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

2019-02-12 Thread David Wu


Hi Philipp,

在 2019/2/10 上午2:24, Philipp Tomsich 写道:

That said, I have been fighting issues from this patchset when trying to read
from devices on the i2c0 bus on a RK3399—which had me add a “simple”
pinctrl device again, as pulling all the dependencies into the SPL is a pain.



I think you can also add the simple ops if necessary. Full pinctrl
should only be used at the U-boot stage, or the SPL stage where the TPL 
is available.


For most boards about 3288, there is no need to enable pinctrl at SPL
stage, such as Tinker board.



Unfortunately, in this merge I had to make a judgement call between insisting
on code-quality and getting the full pinctrl-driver merged.  With this release
cycle being longer and having 5 RCs, I figured we’ll have time to iron out any
wrinkles...



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

Re: [U-Boot] [PATCH v1 1/2] configs: k2g_evm: Enable CONFIG_BLK

2019-02-12 Thread Vignesh R



On 08/02/19 3:25 PM, Jean-Jacques Hiblot wrote:
> CONFIG_BLK can be safely enabled as DM_MMC and DM_USB are already enabled.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> ---
> 

Thanks for the patch!

Tested-by: Vignesh R 

Tom,

This fix is required for booting kernel from MMC/SD on K2G boards. Could
you please consider the patch for next -rc?

>  configs/k2g_evm_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig
> index c518b707a5..838b6f14b6 100644
> --- a/configs/k2g_evm_defconfig
> +++ b/configs/k2g_evm_defconfig
> @@ -34,7 +34,6 @@ CONFIG_DTB_RESELECT=y
>  CONFIG_MULTI_DTB_FIT=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_DM=y
> -# CONFIG_BLK is not set
>  CONFIG_DFU_MMC=y
>  CONFIG_SYS_I2C_DAVINCI=y
>  CONFIG_MISC=y
> 

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

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

2019-02-12 Thread Chen-Yu Tsai

On Tue, Feb 12, 2019 at 8:22 PM Jagan Teki  wrote:
>
> On Tue, Feb 12, 2019 at 5:46 PM Andre Przywara  wrote:
> >
> > On Tue, 12 Feb 2019 17:39:35 +0530
> > Jagan Teki  wrote:
> >
> > > On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara  
> > > wrote:
> > > >
> > > > On Tue, 12 Feb 2019 17:30:44 +0530
> > > > Jagan Teki  wrote:
> > > >
> > > > > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  wrote:
> > > > > >
> > > > > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > > > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux 
> > > > > > > > kernel, the
> > > > > > > > device tree for the Bananapi M2+ has been split into a common 
> > > > > > > > dtsi file,
> > > > > > > > and an SoC-specific board device tree file that includes both 
> > > > > > > > the shared
> > > > > > > > dtsi file and the soc dtsi file. This was done to support both 
> > > > > > > > the H3
> > > > > > > > and H5 variants of the same board. This is similar to what was 
> > > > > > > > doen for
> > > > > > >
> > > > > > > s/doen/done
> > > > > >
> > > > > > Good catch.
> > > > > >
> > > > > > > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af 
> > > > > > > > ("sunxi: Split
> > > > > > > > out common board design for ALL-H3-CC device tree").
> > > > > > > >
> > > > > > > > The newly split files are directly synced from Linux tag 
> > > > > > > > v5.0-rc1.
> > > > > > >
> > > > > > > Better sync all dts(i) files on this relevant SoC, this would 
> > > > > > > help to
> > > > > > > track and use for rest of SoC's are inline to the same version 
> > > > > > > later.
> > > > > >
> > > > > > Ok. Would syncing with linux-next (5.1) work for you? FYI all the 
> > > > > > PRs
> > > > > > for the next release have been sent out.
> > > > >
> > > > > Yes, better we can pick relevant version on during next MW.
> > > >
> > > > I think what Chen-Yu wanted to hint at is that you can this already, by 
> > > > picking the patches from the currently existing branches of the 
> > > > linux-sunxi repository:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1
> > > >
> > > > There should be no need to wait for the Linux MW to close.
> > >
> > > Not for Linux, I'm referring here about u-boot MW.
> >
> > Why do we have to wait for so long? The next U-Boot MW is about two months 
> > away from now. And with U-Boot's usage of the DT we can surely minimise the 
> > risk of breaking something, by just reviewing that the DT changes do not 
> > touch or interfere with any devices that U-Boot cares about.
> > This way we can get up-to-date DTs now (which UEFI boot benefits from), so 
> > that users don't have to provide "their own" DTs.
>
> I knew this degree of risk with dts changes and I have no specific
> reason for this except to follow U-Boot release cycle[1] not to take
> new features in 'release candidate phase' which was missed.
>
> [1] https://www.denx.de/wiki/U-Boot/ReleaseCycle

Or you can merge these patches as is for now, and sync up all the
device tree files
once the next merge window opens. These patches were sent a full two
weeks before
the merge window closed. AFAIK they are eligible [1] for the pending release.

[1] https://www.denx.de/wiki/U-Boot/DevelopmentProcess

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

[U-Boot] [PATCH] Convert CONFIG_IP_DEFRAG to Kconfig

2019-02-12 Thread Christian Gmeiner

This converts the following to Kconfig:
   CONFIG_IP_DEFRAG

Signed-off-by: Christian Gmeiner 
---
 net/Kconfig  | 6 ++
 scripts/config_whitelist.txt | 1 -
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/Kconfig b/net/Kconfig
index f2363e5256..5f5f632469 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -8,6 +8,12 @@ menuconfig NET
 
 if NET
 
+config IP_DEFRAG
+   bool "Support IP datagram reassembly"
+   help
+ Selecting this will enable IP datagram reassembly according
+ to the algorithm in RFC815.
+
 config NET_RANDOM_ETHADDR
bool "Random ethaddr if unset"
help
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 2b3572568b..6b746c5242 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -972,7 +972,6 @@ CONFIG_IPAM390_GPIO_BOOTMODE
 CONFIG_IPAM390_GPIO_LED_GREEN
 CONFIG_IPAM390_GPIO_LED_RED
 CONFIG_IPROC
-CONFIG_IP_DEFRAG
 CONFIG_IRAM_BASE
 CONFIG_IRAM_END
 CONFIG_IRAM_SIZE
-- 
2.20.1

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

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

On Tue, Feb 12, 2019 at 5:46 PM Andre Przywara  wrote:
>
> On Tue, 12 Feb 2019 17:39:35 +0530
> Jagan Teki  wrote:
>
> > On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara  
> > wrote:
> > >
> > > On Tue, 12 Feb 2019 17:30:44 +0530
> > > Jagan Teki  wrote:
> > >
> > > > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  wrote:
> > > > >
> > > > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki 
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai  wrote:
> > > > > > >
> > > > > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, 
> > > > > > > the
> > > > > > > device tree for the Bananapi M2+ has been split into a common 
> > > > > > > dtsi file,
> > > > > > > and an SoC-specific board device tree file that includes both the 
> > > > > > > shared
> > > > > > > dtsi file and the soc dtsi file. This was done to support both 
> > > > > > > the H3
> > > > > > > and H5 variants of the same board. This is similar to what was 
> > > > > > > doen for
> > > > > >
> > > > > > s/doen/done
> > > > >
> > > > > Good catch.
> > > > >
> > > > > > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af 
> > > > > > > ("sunxi: Split
> > > > > > > out common board design for ALL-H3-CC device tree").
> > > > > > >
> > > > > > > The newly split files are directly synced from Linux tag v5.0-rc1.
> > > > > >
> > > > > > Better sync all dts(i) files on this relevant SoC, this would help 
> > > > > > to
> > > > > > track and use for rest of SoC's are inline to the same version 
> > > > > > later.
> > > > >
> > > > > Ok. Would syncing with linux-next (5.1) work for you? FYI all the PRs
> > > > > for the next release have been sent out.
> > > >
> > > > Yes, better we can pick relevant version on during next MW.
> > >
> > > I think what Chen-Yu wanted to hint at is that you can this already, by 
> > > picking the patches from the currently existing branches of the 
> > > linux-sunxi repository:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
> > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1
> > >
> > > There should be no need to wait for the Linux MW to close.
> >
> > Not for Linux, I'm referring here about u-boot MW.
>
> Why do we have to wait for so long? The next U-Boot MW is about two months 
> away from now. And with U-Boot's usage of the DT we can surely minimise the 
> risk of breaking something, by just reviewing that the DT changes do not 
> touch or interfere with any devices that U-Boot cares about.
> This way we can get up-to-date DTs now (which UEFI boot benefits from), so 
> that users don't have to provide "their own" DTs.

I knew this degree of risk with dts changes and I have no specific
reason for this except to follow U-Boot release cycle[1] not to take
new features in 'release candidate phase' which was missed.

[1] https://www.denx.de/wiki/U-Boot/ReleaseCycle
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2019-02-12 Thread Vladimir Oltean

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

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

On Tue, 12 Feb 2019 17:39:35 +0530
Jagan Teki  wrote:

> On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara  wrote:
> >
> > On Tue, 12 Feb 2019 17:30:44 +0530
> > Jagan Teki  wrote:
> >  
> > > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  wrote:  
> > > >
> > > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki  
> > > > wrote:  
> > > > >
> > > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai  wrote:  
> > > > > >
> > > > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, 
> > > > > > the
> > > > > > device tree for the Bananapi M2+ has been split into a common dtsi 
> > > > > > file,
> > > > > > and an SoC-specific board device tree file that includes both the 
> > > > > > shared
> > > > > > dtsi file and the soc dtsi file. This was done to support both the 
> > > > > > H3
> > > > > > and H5 variants of the same board. This is similar to what was doen 
> > > > > > for  
> > > > >
> > > > > s/doen/done  
> > > >
> > > > Good catch.
> > > >  
> > > > > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af ("sunxi: 
> > > > > > Split
> > > > > > out common board design for ALL-H3-CC device tree").
> > > > > >
> > > > > > The newly split files are directly synced from Linux tag v5.0-rc1.  
> > > > >
> > > > > Better sync all dts(i) files on this relevant SoC, this would help to
> > > > > track and use for rest of SoC's are inline to the same version later. 
> > > > >  
> > > >
> > > > Ok. Would syncing with linux-next (5.1) work for you? FYI all the PRs
> > > > for the next release have been sent out.  
> > >
> > > Yes, better we can pick relevant version on during next MW.  
> >
> > I think what Chen-Yu wanted to hint at is that you can this already, by 
> > picking the patches from the currently existing branches of the linux-sunxi 
> > repository:
> > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
> > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1
> >
> > There should be no need to wait for the Linux MW to close.  
> 
> Not for Linux, I'm referring here about u-boot MW.

Why do we have to wait for so long? The next U-Boot MW is about two months away 
from now. And with U-Boot's usage of the DT we can surely minimise the risk of 
breaking something, by just reviewing that the DT changes do not touch or 
interfere with any devices that U-Boot cares about.
This way we can get up-to-date DTs now (which UEFI boot benefits from), so that 
users don't have to provide "their own" DTs.

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

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

On Tue, Feb 12, 2019 at 5:38 PM Andre Przywara  wrote:
>
> On Tue, 12 Feb 2019 17:30:44 +0530
> Jagan Teki  wrote:
>
> > On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  wrote:
> > >
> > > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki  
> > > wrote:
> > > >
> > > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai  wrote:
> > > > >
> > > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> > > > > device tree for the Bananapi M2+ has been split into a common dtsi 
> > > > > file,
> > > > > and an SoC-specific board device tree file that includes both the 
> > > > > shared
> > > > > dtsi file and the soc dtsi file. This was done to support both the H3
> > > > > and H5 variants of the same board. This is similar to what was doen 
> > > > > for
> > > >
> > > > s/doen/done
> > >
> > > Good catch.
> > >
> > > > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af ("sunxi: 
> > > > > Split
> > > > > out common board design for ALL-H3-CC device tree").
> > > > >
> > > > > The newly split files are directly synced from Linux tag v5.0-rc1.
> > > >
> > > > Better sync all dts(i) files on this relevant SoC, this would help to
> > > > track and use for rest of SoC's are inline to the same version later.
> > >
> > > Ok. Would syncing with linux-next (5.1) work for you? FYI all the PRs
> > > for the next release have been sent out.
> >
> > Yes, better we can pick relevant version on during next MW.
>
> I think what Chen-Yu wanted to hint at is that you can this already, by 
> picking the patches from the currently existing branches of the linux-sunxi 
> repository:
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1
>
> There should be no need to wait for the Linux MW to close.

Not for Linux, I'm referring here about u-boot MW.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

On Tue, 12 Feb 2019 17:30:44 +0530
Jagan Teki  wrote:

> On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  wrote:
> >
> > On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki  
> > wrote:  
> > >
> > > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai  wrote:  
> > > >
> > > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> > > > device tree for the Bananapi M2+ has been split into a common dtsi file,
> > > > and an SoC-specific board device tree file that includes both the shared
> > > > dtsi file and the soc dtsi file. This was done to support both the H3
> > > > and H5 variants of the same board. This is similar to what was doen for 
> > > >  
> > >
> > > s/doen/done  
> >
> > Good catch.
> >  
> > > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af ("sunxi: 
> > > > Split
> > > > out common board design for ALL-H3-CC device tree").
> > > >
> > > > The newly split files are directly synced from Linux tag v5.0-rc1.  
> > >
> > > Better sync all dts(i) files on this relevant SoC, this would help to
> > > track and use for rest of SoC's are inline to the same version later.  
> >
> > Ok. Would syncing with linux-next (5.1) work for you? FYI all the PRs
> > for the next release have been sent out.  
> 
> Yes, better we can pick relevant version on during next MW.

I think what Chen-Yu wanted to hint at is that you can this already, by picking 
the patches from the currently existing branches of the linux-sunxi repository:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-5.1
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt-for-5.1

There should be no need to wait for the Linux MW to close.
Given that the U-Boot release is scheduled to happen after that, we should 
start now and possibly fix things later.

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

Re: [U-Boot] [PATCH 3/3] mtd: spi: Kconfig: Select SPI_FLASH if DM_SPI_FLASH

On Tue, Feb 12, 2019 at 1:27 PM Vignesh R  wrote:
>
>
>
> On 09/02/19 5:45 PM, Jagan Teki wrote:
> > DM_SPI_FLASH should require spi flash interface code for dm
> > version, so select SPI_FLASH core by default if any board
> > enabled DM_SPI_FLASH.
> >
> > This overcome the explicit enablement of CONFIG_SPI_FLASH on
> > respective boards when DM_SPI_FLASH being used.
> > > Cc: Vignesh R 
> > Signed-off-by: Jagan Teki 
> > ---
> >  drivers/mtd/spi/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > index 605f60c713..43f597ec29 100644
> > --- a/drivers/mtd/spi/Kconfig
> > +++ b/drivers/mtd/spi/Kconfig
> > @@ -3,6 +3,7 @@ menu "SPI Flash Support"
> >  config DM_SPI_FLASH
> >   bool "Enable Driver Model for SPI flash"
> >   depends on DM && DM_SPI
> > + select SPI_FLASH
>
> How about imply instead of select since there is no compile time dependency?

Yes we can, since DM_SPI_FLASH by default require SPI_FLASH I have used select.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] efi_loader: EFI variables

2019-02-12 Thread Alexander Graf

On 02/12/2019 12:34 PM, Heinrich Schuchardt wrote:

On 2/12/19 10:49 AM, Alexander Graf wrote:

On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:

Hello Alex, hello Takahiro,

this morning I met Daniel Thompson of Linaro. He thinks it would be
quite valuable if U-Boot would at least offer read access to EFI
variables at runtime.

I think what it takes is only a RAM buffer that we put between our
current storage backend (i.e. synchronization with U-Boot variables)
and the API implementation.

We will need such a buffer anyway for non-permanent variables once we
have a SPI flash storage.

I think slowly we need to take a critical design decision: Do we want to
be in the business of managing runtime UEFI variables?

I don't have a fully cohesive answer to that yet. My gut feeling tells
me, that runtime variables would be much better off if they lived in
TrustZone. That way we don't have to play relocation tricks, and devices
that give you persistency are owned by the secure world anyway, so there
is no weird intersection between OS and RTS.

So maybe the path forward would be to implement variable services in ATF
(or OP-TEE rather I suppose) and just provide shim stubs to communicate
with them from runtime services? That would keep all the variable logic
platform agnostic, and we would not have to jump through weird hoops
with DM.

U-Boot' major asset are the many boards supported by drivers. Does ATF
or OP-TEE have drivers for SPI?

Or is your idea that U-Boot would provide a module that is set up as a
trusted driver or trusted app, cf.
https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of-TEE%20copy.png

I think it's perfectly possible to build a special OP-TEE U-Boot target
that can then reuse its drivers, similar to Simon's idea. But we should
probably not try to target RTS with that, but only secure enclaves.

Alex

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

Re: [U-Boot] [PATCH 2/3] mtd: spi: Kconfig: Update CONFIG_SPI_FLASH

On Tue, Feb 12, 2019 at 1:31 PM Vignesh R  wrote:
>
> Hi,
>
> On 09/02/19 5:45 PM, Jagan Teki wrote:
> > 1) CONFIG_SPI_FLASH is not just a legacy code, but it has common
> >core code which handle both dm and non-dm spi flash code. So
> >fix the info text to make it clear globally.
> >
> > 2) Since it's flash core it shouldn't depends on legacy SPI,
> >so remove the 'depends on SPI'
> >
> > Cc: Vignesh R 
> > Signed-off-by: Jagan Teki 
> > ---
> >  drivers/mtd/spi/Kconfig | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > index e3b40fc157..605f60c713 100644
> > --- a/drivers/mtd/spi/Kconfig
> > +++ b/drivers/mtd/spi/Kconfig
> > @@ -26,11 +26,10 @@ config SPI_FLASH_SANDBOX
> > stored in a file on the host filesystem.
> >
> >  config SPI_FLASH
> > - bool "Legacy SPI Flash Interface support"
> > - depends on SPI
> > + bool "SPI Flash Core Interface support"
>
> Nit, since we have SPI NAND flash as well, should description be updated
> to say SPI NOR Flash instead of SPI Flash?

True, I have bundle of changes even for configs to rename till those
are in lets go with as we are.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

On Mon, Feb 11, 2019 at 8:26 AM Chen-Yu Tsai  wrote:
>
> On Sun, Feb 10, 2019 at 1:38 AM Jagan Teki  wrote:
> >
> > On Fri, Jan 25, 2019 at 4:08 PM Chen-Yu Tsai  wrote:
> > >
> > > As of commit aa8fee415f46 ("ARM: dts: sun8i: h3: Split out
> > > non-SoC-specific parts of Bananapi M2 Plus") in the Linux kernel, the
> > > device tree for the Bananapi M2+ has been split into a common dtsi file,
> > > and an SoC-specific board device tree file that includes both the shared
> > > dtsi file and the soc dtsi file. This was done to support both the H3
> > > and H5 variants of the same board. This is similar to what was doen for
> >
> > s/doen/done
>
> Good catch.
>
> > > the Libre Computer ALL-H3-CC in U-boot commit d7b17f1c24af ("sunxi: Split
> > > out common board design for ALL-H3-CC device tree").
> > >
> > > The newly split files are directly synced from Linux tag v5.0-rc1.
> >
> > Better sync all dts(i) files on this relevant SoC, this would help to
> > track and use for rest of SoC's are inline to the same version later.
>
> Ok. Would syncing with linux-next (5.1) work for you? FYI all the PRs
> for the next release have been sent out.

Yes, better we can pick relevant version on during next MW.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] configs: tbs_a711: lower dram frequency

On Mon, Feb 11, 2019 at 5:39 PM Tomas Novotny  wrote:
>
> Hi Jagan,
>
> On Sat, 9 Feb 2019 21:47:12 +0530, Jagan Teki 
> wrote:
> > On Tue, Feb 5, 2019 at 7:27 PM Tomas Novotny  wrote:
> > >
> > > The dram chip on the tablet was changed. The new one requires a lower
> > > frequency, so change it.
> > >
> > > Frequency 564 was also stable in the tests, but use slightly lower one
> > > to be on a safe side.
> >
> > New rate? How does it compatible with legacy devices?
>
> The new frequency is lower and the devices from all batches work. This patch
> is used in all our devices for ~year without any problem. Yes, the
> performance suffers a bit.

OK.

>
> BTW I just noticed that I missed the 'MHz' after the frequency in the commit
> message.

Fixed it in commit message and

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

Re: [U-Boot] [PATCH] pinctrl: rockchip: Add 32bit writing function for rk3288 gpio0 pinctrl

2019-02-12 Thread Philipp Tomsich



> On 12.02.2019, at 12:51, David Wu  wrote:
> 
> There are no higher 16 writing corresponding bits for pmu_gpio0's
> iomux/drive/pull at rk3288, need to read the value from register
> firstly. Add the flag to distinguish it from normal registers.
> 
> Signed-off-by: David Wu 
> ---
> drivers/pinctrl/rockchip/pinctrl-rk3288.c | 17 ++--
> .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 39 ++-
> drivers/pinctrl/rockchip/pinctrl-rockchip.h   | 33 
> 3 files changed, 76 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c 
> b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> index 60585f3208..8b6ce11a63 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
> @@ -92,10 +92,19 @@ static void rk3288_calc_drv_reg_and_bit(struct 
> rockchip_pin_bank *bank,
> }
> 
> static struct rockchip_pin_bank rk3288_pin_banks[] = {
> - PIN_BANK_IOMUX_FLAGS(0, 24, "gpio0", IOMUX_SOURCE_PMU,
> -  IOMUX_SOURCE_PMU,
> -  IOMUX_SOURCE_PMU,
> -  IOMUX_UNROUTED
> + PIN_BANK_IOMUX_DRV_PULL_FLAGS(0, 24, "gpio0",
> +   IOMUX_SOURCE_PMU | IOMUX_WRITABLE_32BIT,
> +   IOMUX_SOURCE_PMU | IOMUX_WRITABLE_32BIT,
> +   IOMUX_SOURCE_PMU | IOMUX_WRITABLE_32BIT,
> +   IOMUX_UNROUTED,
> +   DRV_TYPE_WRITABLE_32BIT,
> +   DRV_TYPE_WRITABLE_32BIT,
> +   DRV_TYPE_WRITABLE_32BIT,
> +   0,
> +   PULL_TYPE_WRITABLE_32BIT,
> +   PULL_TYPE_WRITABLE_32BIT,
> +   PULL_TYPE_WRITABLE_32BIT,
> +   0
>   ),
>   PIN_BANK_IOMUX_FLAGS(1, 32, "gpio1", IOMUX_UNROUTED,
>IOMUX_UNROUTED,
> diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
> b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> index b84b079064..ce935656f0 100644
> --- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> +++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
> @@ -228,7 +228,13 @@ static int rockchip_set_mux(struct rockchip_pin_bank 
> *bank, int pin, int mux)
>   }
>   }
> 
> - data = (mask << (bit + 16));
> + if (mux_type & IOMUX_WRITABLE_32BIT) {
> + regmap_read(regmap, reg, );
> + data &= ~(mask << bit);
> + } else {
> + data = (mask << (bit + 16));
> + }
> +

This can not be optimised out by the compiler (for all the other platforms that 
don’t need it).
Please structure this (and the entire driver) to not pull in unneeded baggage 
that is only used
by one or a few devices.

>   data |= (mux & mask) << bit;
>   ret = regmap_write(regmap, reg, data);
> 
> @@ -252,7 +258,8 @@ static int rockchip_set_drive_perpin(struct 
> rockchip_pin_bank *bank,
>   int reg, ret, i;
>   u32 data, rmask_bits, temp;
>   u8 bit;
> - int drv_type = bank->drv[pin_num / 8].drv_type;
> + /* Where need to clean the special mask for rockchip_perpin_drv_list */
> + int drv_type = bank->drv[pin_num / 8].drv_type & (~DRV_TYPE_IO_MASK);
> 
>   debug("setting drive of GPIO%d-%d to %d\n", bank->bank_num,
> pin_num, strength);
> @@ -324,10 +331,15 @@ static int rockchip_set_drive_perpin(struct 
> rockchip_pin_bank *bank,
>   return -EINVAL;
>   }
> 
> - /* enable the write to the equivalent lower bits */
> - data = ((1 << rmask_bits) - 1) << (bit + 16);
> - data |= (ret << bit);
> + if (bank->drv[pin_num / 8].drv_type & DRV_TYPE_WRITABLE_32BIT) {
> + regmap_read(regmap, reg, );
> + data &= ~(((1 << rmask_bits) - 1) << bit);
> + } else {
> + /* enable the write to the equivalent lower bits */
> + data = ((1 << rmask_bits) - 1) << (bit + 16);
> + }
> 
> + data |= (ret << bit);
>   ret = regmap_write(regmap, reg, data);
>   return ret;
> }
> @@ -375,7 +387,11 @@ static int rockchip_set_pull(struct rockchip_pin_bank 
> *bank,
>   case RK3288:
>   case RK3368:
>   case RK3399:
> - pull_type = bank->pull_type[pin_num / 8];
> + /*
> +  * Where need to clean the special mask for
> +  * rockchip_pull_list.
> +  */
> + pull_type = bank->pull_type[pin_num / 8] & (~PULL_TYPE_IO_MASK);
>   ret = -EINVAL;
>   for (i = 0; i < ARRAY_SIZE(rockchip_pull_list[pull_type]);
>   i++) {
> @@ -390,10 +406,15 @@ static int rockchip_set_pull(struct rockchip_pin_bank 
> *bank,
>

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

2019-02-12 Thread David Wu


Hi Heinrich,

在 2019/2/10 上午12:39, Heinrich Schuchardt 写道:

On 2/9/19 4:24 PM, Philipp Tomsich wrote:




On 09.02.2019, at 16:08, Philipp Tomsich 
 wrote:

Heinrich,

My guess is that this is fallout from David Wu’s new pinctrl driver
(which has really been the bulk of changes in this cycle).  I can’t
test or debug on the rk3288 due to a lack of hardware.


If you want to start digging, that the changes in


commit 08c817c39908f9d120df1e4c90ddad4a11fc3891
Author: David Wu 
Date:   Wed Jan 2 20:51:00 2019 +0800

 ARM: rockchip: Remove the pinctrl request at rk3288-board-spl
 
 If we use the new pinctrl driver, the pinctrl setup will be done

 by device probe. Remove the pinctrl setup at rk3288-board-spl.
 
 Signed-off-by: David Wu 

 Reviewed-by: Kever Yang 
 Reviewed-by: Philipp Tomsich 



look like they have the potential to break everything, including the
UART pinctrl.

Thanks,
Philipp.,


Hello Philipp,

I would not know how to analyze the bug if there isn't even a console.


The reason i see, that is the u-boot-spl-dtb.bin is too large for 
bootrom, while supports full pinctrl at SPL stage.


Compared to the popmetal-rk3288_defconfig, CONFIG_SPL_I2C_SUPPORT is not 
enabled at PopMetal. Remove this config to reduces the spl bin size, 
makes the Tinker board to boot. As the tinker does not use the i2c to 
read the MAC address from eeprom at the SPL stage, which is at uboot.


Another thing is that I missed a patch, for the 3288 gpio0, its iomux is 
special, there is no high 16-bit write-enabled bit. For Tinker board, it 
uses I2C0, the current driver will overwrite the I2C0 iomux, while 
request the GPIO0A4. It requires a patch.




If David or you send me a git branch to compile I will test it.

Has any of the rk3288 boards been tested before merging?


Yes,
I tested the patch at RK3288 PopMetal board once, and just tested one 
board for per Soc, i didn't have a Tinker board in my hand to verify it.

The new pinctrl driver could work at PopMetal:

U-Boot SPL 2019.01-rc1-9-gdd7b9156fe (Feb 12 2019 - 09:33:17 +0800)
Returning to boot ROM...


U-Boot 2019.01-rc1-9-gdd7b9156fe (Feb 12 2019 - 09:33:17 +0800)

Model: PopMetal-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c: 1, dwmmc@ff0f: 0
Loading Environment from MMC... *** Warning - bad CRC, using default 
environment


In:serial
Out:   serial
Err:   serial
Model: PopMetal-RK3288
Net:   eth-1: ethernet@ff29
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0(part 0) is current device
** No partition table - mmc 0 **
Card did not respond to voltage select!
starting USB...
USB0:   scanning bus 0 for devices... 2 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device
No ethernet found.
=>



I think we should keep Simon in CC as he is one of the ROCKCHIP maintainers.

Best regards

Heinrich






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

[U-Boot] [PATCH] pinctrl: rockchip: Add 32bit writing function for rk3288 gpio0 pinctrl

2019-02-12 Thread David Wu

There are no higher 16 writing corresponding bits for pmu_gpio0's
iomux/drive/pull at rk3288, need to read the value from register
firstly. Add the flag to distinguish it from normal registers.

Signed-off-by: David Wu 
---
 drivers/pinctrl/rockchip/pinctrl-rk3288.c | 17 ++--
 .../pinctrl/rockchip/pinctrl-rockchip-core.c  | 39 ++-
 drivers/pinctrl/rockchip/pinctrl-rockchip.h   | 33 
 3 files changed, 76 insertions(+), 13 deletions(-)

diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3288.c 
b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
index 60585f3208..8b6ce11a63 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rk3288.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rk3288.c
@@ -92,10 +92,19 @@ static void rk3288_calc_drv_reg_and_bit(struct 
rockchip_pin_bank *bank,
 }
 
 static struct rockchip_pin_bank rk3288_pin_banks[] = {
-   PIN_BANK_IOMUX_FLAGS(0, 24, "gpio0", IOMUX_SOURCE_PMU,
-IOMUX_SOURCE_PMU,
-IOMUX_SOURCE_PMU,
-IOMUX_UNROUTED
+   PIN_BANK_IOMUX_DRV_PULL_FLAGS(0, 24, "gpio0",
+ IOMUX_SOURCE_PMU | IOMUX_WRITABLE_32BIT,
+ IOMUX_SOURCE_PMU | IOMUX_WRITABLE_32BIT,
+ IOMUX_SOURCE_PMU | IOMUX_WRITABLE_32BIT,
+ IOMUX_UNROUTED,
+ DRV_TYPE_WRITABLE_32BIT,
+ DRV_TYPE_WRITABLE_32BIT,
+ DRV_TYPE_WRITABLE_32BIT,
+ 0,
+ PULL_TYPE_WRITABLE_32BIT,
+ PULL_TYPE_WRITABLE_32BIT,
+ PULL_TYPE_WRITABLE_32BIT,
+ 0
),
PIN_BANK_IOMUX_FLAGS(1, 32, "gpio1", IOMUX_UNROUTED,
 IOMUX_UNROUTED,
diff --git a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c 
b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
index b84b079064..ce935656f0 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rockchip-core.c
@@ -228,7 +228,13 @@ static int rockchip_set_mux(struct rockchip_pin_bank 
*bank, int pin, int mux)
}
}
 
-   data = (mask << (bit + 16));
+   if (mux_type & IOMUX_WRITABLE_32BIT) {
+   regmap_read(regmap, reg, );
+   data &= ~(mask << bit);
+   } else {
+   data = (mask << (bit + 16));
+   }
+
data |= (mux & mask) << bit;
ret = regmap_write(regmap, reg, data);
 
@@ -252,7 +258,8 @@ static int rockchip_set_drive_perpin(struct 
rockchip_pin_bank *bank,
int reg, ret, i;
u32 data, rmask_bits, temp;
u8 bit;
-   int drv_type = bank->drv[pin_num / 8].drv_type;
+   /* Where need to clean the special mask for rockchip_perpin_drv_list */
+   int drv_type = bank->drv[pin_num / 8].drv_type & (~DRV_TYPE_IO_MASK);
 
debug("setting drive of GPIO%d-%d to %d\n", bank->bank_num,
  pin_num, strength);
@@ -324,10 +331,15 @@ static int rockchip_set_drive_perpin(struct 
rockchip_pin_bank *bank,
return -EINVAL;
}
 
-   /* enable the write to the equivalent lower bits */
-   data = ((1 << rmask_bits) - 1) << (bit + 16);
-   data |= (ret << bit);
+   if (bank->drv[pin_num / 8].drv_type & DRV_TYPE_WRITABLE_32BIT) {
+   regmap_read(regmap, reg, );
+   data &= ~(((1 << rmask_bits) - 1) << bit);
+   } else {
+   /* enable the write to the equivalent lower bits */
+   data = ((1 << rmask_bits) - 1) << (bit + 16);
+   }
 
+   data |= (ret << bit);
ret = regmap_write(regmap, reg, data);
return ret;
 }
@@ -375,7 +387,11 @@ static int rockchip_set_pull(struct rockchip_pin_bank 
*bank,
case RK3288:
case RK3368:
case RK3399:
-   pull_type = bank->pull_type[pin_num / 8];
+   /*
+* Where need to clean the special mask for
+* rockchip_pull_list.
+*/
+   pull_type = bank->pull_type[pin_num / 8] & (~PULL_TYPE_IO_MASK);
ret = -EINVAL;
for (i = 0; i < ARRAY_SIZE(rockchip_pull_list[pull_type]);
i++) {
@@ -390,10 +406,15 @@ static int rockchip_set_pull(struct rockchip_pin_bank 
*bank,
return ret;
}
 
-   /* enable the write to the equivalent lower bits */
-   data = ((1 << ROCKCHIP_PULL_BITS_PER_PIN) - 1) << (bit + 16);
-   data |= (ret << bit);
+   if (bank->pull_type[pin_num / 8] & PULL_TYPE_WRITABLE_32BIT) {
+   regmap_read(regmap,

Re: [U-Boot] [RFC] efi_loader: EFI variables

On 2/12/19 10:49 AM, Alexander Graf wrote:
> On 02/03/2019 07:32 PM, Heinrich Schuchardt wrote:
>> Hello Alex, hello Takahiro,
>>
>> this morning I met Daniel Thompson of Linaro. He thinks it would be
>> quite valuable if U-Boot would at least offer read access to EFI
>> variables at runtime.
>>
>> I think what it takes is only a RAM buffer that we put between our
>> current storage backend (i.e. synchronization with U-Boot variables)
>> and the API implementation.
>>
>> We will need such a buffer anyway for non-permanent variables once we
>> have a SPI flash storage.
> 
> I think slowly we need to take a critical design decision: Do we want to
> be in the business of managing runtime UEFI variables?
> 
> I don't have a fully cohesive answer to that yet. My gut feeling tells
> me, that runtime variables would be much better off if they lived in
> TrustZone. That way we don't have to play relocation tricks, and devices
> that give you persistency are owned by the secure world anyway, so there
> is no weird intersection between OS and RTS.
> 
> So maybe the path forward would be to implement variable services in ATF
> (or OP-TEE rather I suppose) and just provide shim stubs to communicate
> with them from runtime services? That would keep all the variable logic
> platform agnostic, and we would not have to jump through weird hoops
> with DM.

U-Boot' major asset are the many boards supported by drivers. Does ATF
or OP-TEE have drivers for SPI?

Or is your idea that U-Boot would provide a module that is set up as a
trusted driver or trusted app, cf.
https://developer.arm.com/-/media/developer/Block%20Diagrams/Architecture-of-TEE%20copy.png

Best regards

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

Re: [U-Boot] [linux-sunxi] [PATCH v2 0/4] sunxi: SPI: Add SUN6I generation SPI support

On Tue, Feb 12, 2019 at 4:11 PM Andre Przywara  wrote:
>
> We already have a driver for the SPI devices in older Allwinner CPUs.
> Newer SoCs (SUN6I generation) have a similar, but improved IP block.
> This series adds support for that, so we can access the SPI flash that
> some newer boards come with.
> This series gathers some patches that have appeared on the list in one
> form or another before (hence the v2 tag), but brings them all together
> and updates them.
>
> The SUN4I/SUN6I SPI devices share a very similar architecure, but differ
> annoyingly in quite some details, to a point where a shared driver
> would look unnecessarily complicated. So we use an #ifdef based approach,
> which keeps the driver simple, at the cost of not being able to access
> both types of device in one binary build. But since there are no SoCs
> which feature both types, this is a theoretical disadvantage.
>
> Patch 1/4 moves the clock toggling from the probe/remove to the
> claim/release-bus stage.
> Patch 2/4 adds the SPI gate clocks and reset gates to the clock drivers,
> also describes at least the enable bit for the SPI mod clock. This is used
> in patch 3/4, which uses the new DM clock framework in the driver, helping
> to abstract differences between the SUN4I/SUN6I types.
> Patch 4/4 eventually adds support for the new SUN6I generation SPI device.
> The actual device support is determined at compile time, based on the
> CONFIG_SUNXI_GEN_SUN6I symbol.
>
> What's left out of this series is the config bits needed to actually
> activate the support for a board. At the moment this is unnecessarily
> verbose, so that Oskari is looking at simplifying this at the Kconfig
> level, which would complement this series.
>
> This has been briefly tested on the Pine64-LTS and the OrangePi PC2 board.
> Please test them if you have other devices with a SUN6I SPI generation.

I have new series for this which I sent two days back [1]. which uses
same sun4i driver and implement enum reg set to avoid ifdef.

[1] https://patchwork.ozlabs.org/cover/1039178/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 3/3] stm32mp1: display board information

Implement checkboard() function to display
- the boot chain used: basic or trusted
- the board compatible in device tree
- the board identifier and revision, saved in OTP59 for ST boards

Signed-off-by: Patrick Delaunay 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/mach-stm32mp/include/mach/stm32.h |  4 +++
 board/st/stm32mp1/stm32mp1.c   | 44 --
 2 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index 5d0bdca..85d783c 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -98,7 +98,11 @@ enum boot_device {
 
 /* offset used for BSEC driver: misc_read and misc_write */
 #define STM32_BSEC_SHADOW_OFFSET   0x0
+#define STM32_BSEC_SHADOW(id)  (STM32_BSEC_SHADOW_OFFSET + (id) * 4)
 #define STM32_BSEC_OTP_OFFSET  0x8000
+#define STM32_BSEC_OTP(id) (STM32_BSEC_OTP_OFFSET + (id) * 4)
+
+#define BSEC_OTP_BOARD 59
 
 #endif /* __ASSEMBLY__*/
 #endif /* _MACH_STM32_H_ */
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 54feca0..07d1add 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -3,11 +3,12 @@
  * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
  */
 #include 
-#include 
-#include 
 #include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +27,45 @@ DECLARE_GLOBAL_DATA_PTR;
 #define STM32MP_GGPIO 0x38
 #define STM32MP_GGPIO_VBUS_SENSING BIT(21)
 
+int checkboard(void)
+{
+   int ret;
+   char *mode;
+   u32 otp;
+   struct udevice *dev;
+   const char *fdt_compat;
+   int fdt_compat_len;
+
+   if (IS_ENABLED(CONFIG_STM32MP1_TRUSTED))
+   mode = "trusted";
+   else
+   mode = "basic";
+
+   printf("Board: stm32mp1 in %s mode", mode);
+   fdt_compat = fdt_getprop(gd->fdt_blob, 0, "compatible",
+_compat_len);
+   if (fdt_compat && fdt_compat_len)
+   printf(" (%s)", fdt_compat);
+   puts("\n");
+
+   ret = uclass_get_device_by_driver(UCLASS_MISC,
+ DM_GET_DRIVER(stm32mp_bsec),
+ );
+
+   if (!ret)
+   ret = misc_read(dev, STM32_BSEC_SHADOW(BSEC_OTP_BOARD),
+   , sizeof(otp));
+   if (!ret && otp) {
+   printf("Board: MB%04x Var%d Rev.%c-%02d\n",
+  otp >> 16,
+  (otp >> 12) & 0xF,
+  ((otp >> 8) & 0xF) - 1 + 'A',
+  otp & 0xF);
+   }
+
+   return 0;
+}
+
 static struct dwc2_plat_otg_data stm32mp_otg_data = {
.usb_gusbcfg = STM32MP_GUSBCFG,
 };
-- 
2.7.4

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

[U-Boot] [PATCH v4 1/3] stm32mp1: add trusted boot with TF-A

Add support of trusted boot, using TF-A as first stage bootloader,
The boot sequence is
  BootRom >=> TF-A.stm32 (clock & DDR) >=> U-Boot.stm32

The TF-A monitor provides secure monitor with support of SMC
- proprietary to manage secure devices (BSEC for example)
- PSCI for power

The same device tree is used for STMicroelectronics boards with
basic boot and with trusted boot.

Signed-off-by: Patrick Delaunay 
---

Changes in v4:
- Rebase on master
- add CONFIG_CMD_CLK in trusted defconfig
  (allignment with basic defconfig)

Changes in v3:
   - Remove patch 4/4 added by error in v2 and sent by other serie
 http://patchwork.ozlabs.org/patch/1033475/

Changes in v2:
- Rebase and solve conflict on arch/arm/mach-stm32mp/config.mk

 arch/arm/Kconfig|  6 ++--
 arch/arm/mach-stm32mp/Kconfig   | 17 +--
 arch/arm/mach-stm32mp/config.mk | 15 +-
 arch/arm/mach-stm32mp/cpu.c |  9 --
 board/st/stm32mp1/MAINTAINERS   |  5 ++--
 board/st/stm32mp1/README| 56 ---
 configs/stm32mp15_trusted_defconfig | 58 +
 drivers/clk/clk_stm32mp1.c  |  2 ++
 drivers/ram/stm32mp1/stm32mp1_ram.c |  3 +-
 include/configs/stm32mp1.h  |  2 ++
 10 files changed, 145 insertions(+), 28 deletions(-)
 create mode 100644 configs/stm32mp15_trusted_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 455f06c..9e861c2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1367,8 +1367,10 @@ config ARCH_STM32MP
help
  Support for STM32MP SoC family developed by STMicroelectronics,
  MPUs based on ARM cortex A core
- U-BOOT is running in DDR and SPL support is the unsecure First Stage
- BootLoader (FSBL)
+ U-BOOT is running in DDR, loaded by the First Stage BootLoader (FSBL).
+ FSBL can be TF-A: Trusted Firmware for Cortex A, for trusted boot
+ chain.
+ SPL is the unsecure FSBL for the basic boot chain.
 
 config ARCH_ROCKCHIP
bool "Support Rockchip SoCs"
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index 8a929fa..3101d80 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -25,19 +25,30 @@ config SYS_SOC
 
 config TARGET_STM32MP1
bool "Support stm32mp1xx"
-   select ARCH_SUPPORT_PSCI
+   select ARCH_SUPPORT_PSCI if !STM32MP1_TRUSTED
select CPU_V7A
-   select CPU_V7_HAS_NONSEC
+   select CPU_V7_HAS_NONSEC if !STM32MP1_TRUSTED
select CPU_V7_HAS_VIRT
select PINCTRL_STM32
select STM32_RCC
select STM32_RESET
select SYS_ARCH_TIMER
-   select SYSRESET_SYSCON
+   imply SYSRESET_PSCI if STM32MP1_TRUSTED
+   imply SYSRESET_SYSCON if !STM32MP1_TRUSTED
help
target STMicroelectronics SOC STM32MP1 family
STMicroelectronics MPU with core ARMv7
 
+config STM32MP1_TRUSTED
+   bool "Support trusted boot with TF-A"
+   default y if !SPL
+   select ARM_SMCCC
+   help
+   Say Y here to enable boot with TF-A
+   Trusted boot chain is :
+   BootRom => TF-A.stm32 (clock & DDR) => U-Boot.stm32
+   TF-A monitor provides proprietary smc to manage secure devices
+
 config SYS_TEXT_BASE
prompt "U-Boot base address"
default 0xC010
diff --git a/arch/arm/mach-stm32mp/config.mk b/arch/arm/mach-stm32mp/config.mk
index f371aac..403af2a 100644
--- a/arch/arm/mach-stm32mp/config.mk
+++ b/arch/arm/mach-stm32mp/config.mk
@@ -3,7 +3,20 @@
 # Copyright (C) 2018, STMicroelectronics - All Rights Reserved
 #
 
-ALL-$(CONFIG_SPL_BUILD) += u-boot-spl.stm32
+ifndef CONFIG_SPL
+ALL-y += u-boot.stm32
+else
+ifdef CONFIG_SPL_BUILD
+ALL-y += u-boot-spl.stm32
+endif
+endif
+
+MKIMAGEFLAGS_u-boot.stm32 = -T stm32image -a $(CONFIG_SYS_TEXT_BASE) -e 
$(CONFIG_SYS_TEXT_BASE)
+
+u-boot.stm32: MKIMAGEOUTPUT = u-boot.stm32.log
+
+u-boot.stm32: u-boot.bin FORCE
+   $(call if_changed,mkimage)
 
 MKIMAGEFLAGS_u-boot-spl.stm32 = -T stm32image -a $(CONFIG_SPL_TEXT_BASE) -e 
$(CONFIG_SPL_TEXT_BASE)
 
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index b893358..b96720f 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -59,6 +59,7 @@
 #define BSEC_OTP_MAC   57
 
 #if !defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD)
+#ifndef CONFIG_STM32MP1_TRUSTED
 static void security_init(void)
 {
/* Disable the backup domain write protection */
@@ -114,6 +115,7 @@ static void security_init(void)
 */
writel(0x0, TAMP_CR1);
 }
+#endif /* CONFIG_STM32MP1_TRUSTED */
 
 /*
  * Debug init
@@ -130,7 +132,8 @@ static void dbgmcu_init(void)
 static u32 get_bootmode(void)
 {
u32 boot_mode;
-#if !defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD)
+#if !defined(CONFIG_STM32MP1_TRUSTED) && \
+   (!defined(CONFIG_SPL) ||

[U-Boot] [PATCH v4 2/3] stm32mp1: bsec: access with SMC for trusted boot

As BSEC is secure aware, all register access need to be done
by TF-A for TRUSTED boot chain, when U-Boot is executed in
normal world.

Signed-off-by: Patrick Delaunay 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/mach-stm32mp/bsec.c  | 28 ++
 arch/arm/mach-stm32mp/include/mach/stm32mp1_smc.h | 64 +++
 2 files changed, 92 insertions(+)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/stm32mp1_smc.h

diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c
index d087a31..920a6c9 100644
--- a/arch/arm/mach-stm32mp/bsec.c
+++ b/arch/arm/mach-stm32mp/bsec.c
@@ -8,9 +8,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define BSEC_OTP_MAX_VALUE 95
 
+#ifndef CONFIG_STM32MP1_TRUSTED
 #define BSEC_TIMEOUT_US1
 
 /* BSEC REGISTER OFFSET (base relative) */
@@ -270,6 +273,7 @@ static int bsec_program_otp(long base, u32 val, u32 otp)
 
return ret;
 }
+#endif /* CONFIG_STM32MP1_TRUSTED */
 
 /* BSEC MISC driver ***/
 struct stm32mp_bsec_platdata {
@@ -278,6 +282,11 @@ struct stm32mp_bsec_platdata {
 
 static int stm32mp_bsec_read_otp(struct udevice *dev, u32 *val, u32 otp)
 {
+#ifdef CONFIG_STM32MP1_TRUSTED
+   return stm32_smc(STM32_SMC_BSEC,
+STM32_SMC_READ_OTP,
+otp, 0, val);
+#else
struct stm32mp_bsec_platdata *plat = dev_get_platdata(dev);
u32 tmp_data = 0;
int ret;
@@ -299,27 +308,46 @@ static int stm32mp_bsec_read_otp(struct udevice *dev, u32 
*val, u32 otp)
/* restore shadow value */
ret = bsec_write_shadow(plat->base, tmp_data, otp);
return ret;
+#endif
 }
 
 static int stm32mp_bsec_read_shadow(struct udevice *dev, u32 *val, u32 otp)
 {
+#ifdef CONFIG_STM32MP1_TRUSTED
+   return stm32_smc(STM32_SMC_BSEC,
+STM32_SMC_READ_SHADOW,
+otp, 0, val);
+#else
struct stm32mp_bsec_platdata *plat = dev_get_platdata(dev);
 
return bsec_read_shadow(plat->base, val, otp);
+#endif
 }
 
 static int stm32mp_bsec_write_otp(struct udevice *dev, u32 val, u32 otp)
 {
+#ifdef CONFIG_STM32MP1_TRUSTED
+   return stm32_smc_exec(STM32_SMC_BSEC,
+ STM32_SMC_PROG_OTP,
+ otp, val);
+#else
struct stm32mp_bsec_platdata *plat = dev_get_platdata(dev);
 
return bsec_program_otp(plat->base, val, otp);
+#endif
 }
 
 static int stm32mp_bsec_write_shadow(struct udevice *dev, u32 val, u32 otp)
 {
+#ifdef CONFIG_STM32MP1_TRUSTED
+   return stm32_smc_exec(STM32_SMC_BSEC,
+ STM32_SMC_WRITE_SHADOW,
+ otp, val);
+#else
struct stm32mp_bsec_platdata *plat = dev_get_platdata(dev);
 
return bsec_write_shadow(plat->base, val, otp);
+#endif
 }
 
 static int stm32mp_bsec_read(struct udevice *dev, int offset,
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32mp1_smc.h 
b/arch/arm/mach-stm32mp/include/mach/stm32mp1_smc.h
new file mode 100644
index 000..8130546
--- /dev/null
+++ b/arch/arm/mach-stm32mp/include/mach/stm32mp1_smc.h
@@ -0,0 +1,64 @@
+/* SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause */
+/*
+ * Copyright (C) 2019, STMicroelectronics - All Rights Reserved
+ */
+
+#ifndef __STM32MP1_SMC_H__
+#define __STM32MP1_SMC_H__
+
+#include 
+
+/*
+ * SMC function IDs for STM32 Service queries
+ * STM32 SMC services use the space between 0x8200 and 0x8200
+ * like this is defined in SMC calling Convention by ARM
+ * for SiP (silicon Partner)
+ * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+ */
+#define STM32_SMC_VERSION  0x8200
+
+/* Secure Service access from Non-secure */
+#define STM32_SMC_BSEC 0x82001003
+
+/* Service for BSEC */
+#define STM32_SMC_READ_SHADOW  0x01
+#define STM32_SMC_PROG_OTP 0x02
+#define STM32_SMC_WRITE_SHADOW 0x03
+#define STM32_SMC_READ_OTP 0x04
+#define STM32_SMC_READ_ALL 0x05
+#define STM32_SMC_WRITE_ALL0x06
+
+/* SMC error codes */
+#define STM32_SMC_OK   0x0
+#define STM32_SMC_NOT_SUPPORTED-1
+#define STM32_SMC_FAILED   -2
+#define STM32_SMC_INVALID_PARAMS   -3
+
+#define stm32_smc_exec(svc, op, data1, data2) \
+   stm32_smc(svc, op, data1, data2, NULL)
+
+#ifdef CONFIG_ARM_SMCCC
+static inline u32 stm32_smc(u32 svc, u8 op, u32 data1, u32 data2, u32 *result)
+{
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(svc, op, data1, data2, 0, 0, 0, 0, );
+
+   if (res.a0) {
+   pr_err("%s: Failed to exec in secure mode (err = %ld)\n",
+  __func__, res.a0);
+   return -EINVAL;
+   }
+   if (result)
+   *result = (u32)res.a1;
+
+   return 0;
+}
+#else

[U-Boot] [PATCH v4 0/3] stm32mp1: add trusted boot with TF-A


This patch serie add a new configuration
stm32mp15_trusted_defconfig to handle STM32MP157 boards
with TF-A as secure first stage bootloader.

TF-A code is available in GitHub
https://github.com/ARM-software/arm-trusted-firmware

With platform stm32mp1 platform
https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/st/stm32mp1

For details, see documentation
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/stm32mp1.rst

PS: upstream of trusted boot for TF-A is still in progress.


Changes in v4:
- Rebase on master
- add CONFIG_CMD_CLK in trusted defconfig
  (allignment with basic defconfig)

Changes in v3:
   - Remove patch 4/4 added by error in v2 and sent by other serie
 http://patchwork.ozlabs.org/patch/1033475/

Changes in v2:
- Rebase and solve conflict on arch/arm/mach-stm32mp/config.mk

Patrick Delaunay (3):
  stm32mp1: add trusted boot with TF-A
  stm32mp1: bsec: access with SMC for trusted boot
  stm32mp1: display board information

 arch/arm/Kconfig  |  6 ++-
 arch/arm/mach-stm32mp/Kconfig | 17 --
 arch/arm/mach-stm32mp/bsec.c  | 28 ++
 arch/arm/mach-stm32mp/config.mk   | 15 +-
 arch/arm/mach-stm32mp/cpu.c   |  9 +++-
 arch/arm/mach-stm32mp/include/mach/stm32.h|  4 ++
 arch/arm/mach-stm32mp/include/mach/stm32mp1_smc.h | 64 +++
 board/st/stm32mp1/MAINTAINERS |  5 +-
 board/st/stm32mp1/README  | 56 ++--
 board/st/stm32mp1/stm32mp1.c  | 44 +++-
 configs/stm32mp15_trusted_defconfig   | 58 
 drivers/clk/clk_stm32mp1.c|  2 +
 drivers/ram/stm32mp1/stm32mp1_ram.c   |  3 +-
 include/configs/stm32mp1.h|  2 +
 14 files changed, 283 insertions(+), 30 deletions(-)
 create mode 100644 arch/arm/mach-stm32mp/include/mach/stm32mp1_smc.h
 create mode 100644 configs/stm32mp15_trusted_defconfig

-- 
2.7.4

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

[U-Boot] [PATCH v2 2/4] clk: sunxi: Implement SPI gates clocks and reset

From: Jagan Teki 

In every SoC the SPI device requires an AHB clock, also the MOD clock
needs to be toggled. Provide those as gate clocks for all SoCs as per
the manual.
The driver doesn't tinker with the actual SPI frequency, so we get away
without a proper MOD clock implementation.

Newer SoCs also provide a reset gate per SPI device. Add them as well.

Signed-off-by: Jagan Teki 
Signed-off-by: Andre Przywara 
[Andre: Add A23, A31, A80, A83T, H3, H6, R40, V3s]
---
 drivers/clk/sunxi/clk_a10.c  |  9 +
 drivers/clk/sunxi/clk_a10s.c |  7 +++
 drivers/clk/sunxi/clk_a23.c  |  7 +++
 drivers/clk/sunxi/clk_a31.c  | 13 +
 drivers/clk/sunxi/clk_a64.c  |  7 +++
 drivers/clk/sunxi/clk_a80.c  | 15 +++
 drivers/clk/sunxi/clk_a83t.c |  7 +++
 drivers/clk/sunxi/clk_h3.c   |  7 +++
 drivers/clk/sunxi/clk_h6.c   |  6 ++
 drivers/clk/sunxi/clk_r40.c  | 13 +
 drivers/clk/sunxi/clk_v3s.c  |  4 
 11 files changed, 95 insertions(+)

diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
index 2aa41efe17..654b954203 100644
--- a/drivers/clk/sunxi/clk_a10.c
+++ b/drivers/clk/sunxi/clk_a10.c
@@ -22,6 +22,10 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
[CLK_AHB_MMC3]  = GATE(0x060, BIT(11)),
+   [CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
+   [CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
+   [CLK_AHB_SPI2]  = GATE(0x060, BIT(22)),
+   [CLK_AHB_SPI3]  = GATE(0x060, BIT(23)),
 
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
@@ -32,6 +36,11 @@ static struct ccu_clk_gate a10_gates[] = {
[CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
[CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
 
+   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
+   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
+   [CLK_SPI2]  = GATE(0x0a8, BIT(31)),
+   [CLK_SPI3]  = GATE(0x0d4, BIT(31)), /* SPI3 is separate */
+
[CLK_USB_OHCI0] = GATE(0x0cc, BIT(6)),
[CLK_USB_OHCI1] = GATE(0x0cc, BIT(7)),
[CLK_USB_PHY]   = GATE(0x0cc, BIT(8)),
diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
index 87b74e52dc..0a417d0b9f 100644
--- a/drivers/clk/sunxi/clk_a10s.c
+++ b/drivers/clk/sunxi/clk_a10s.c
@@ -19,6 +19,13 @@ static struct ccu_clk_gate a10s_gates[] = {
[CLK_AHB_MMC0]  = GATE(0x060, BIT(8)),
[CLK_AHB_MMC1]  = GATE(0x060, BIT(9)),
[CLK_AHB_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_AHB_SPI0]  = GATE(0x060, BIT(20)),
+   [CLK_AHB_SPI1]  = GATE(0x060, BIT(21)),
+   [CLK_AHB_SPI2]  = GATE(0x060, BIT(22)),
+
+   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
+   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
+   [CLK_SPI2]  = GATE(0x0a8, BIT(31)),
 
[CLK_APB1_UART0]= GATE(0x06c, BIT(16)),
[CLK_APB1_UART1]= GATE(0x06c, BIT(17)),
diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
index 1ef2359286..c16019215e 100644
--- a/drivers/clk/sunxi/clk_a23.c
+++ b/drivers/clk/sunxi/clk_a23.c
@@ -16,6 +16,8 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_MMC0]  = GATE(0x060, BIT(8)),
[CLK_BUS_MMC1]  = GATE(0x060, BIT(9)),
[CLK_BUS_MMC2]  = GATE(0x060, BIT(10)),
+   [CLK_BUS_SPI0]  = GATE(0x060, BIT(20)),
+   [CLK_BUS_SPI1]  = GATE(0x060, BIT(21)),
[CLK_BUS_OTG]   = GATE(0x060, BIT(24)),
[CLK_BUS_EHCI]  = GATE(0x060, BIT(26)),
[CLK_BUS_OHCI]  = GATE(0x060, BIT(29)),
@@ -26,6 +28,9 @@ static struct ccu_clk_gate a23_gates[] = {
[CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
[CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
 
+   [CLK_SPI0]  = GATE(0x0a0, BIT(31)),
+   [CLK_SPI1]  = GATE(0x0a4, BIT(31)),
+
[CLK_USB_PHY0]  = GATE(0x0cc, BIT(8)),
[CLK_USB_PHY1]  = GATE(0x0cc, BIT(9)),
[CLK_USB_HSIC]  = GATE(0x0cc, BIT(10)),
@@ -41,6 +46,8 @@ static struct ccu_reset a23_resets[] = {
[RST_BUS_MMC0]  = RESET(0x2c0, BIT(8)),
[RST_BUS_MMC1]  = RESET(0x2c0, BIT(9)),
[RST_BUS_MMC2]  = RESET(0x2c0, BIT(10)),
+   [RST_BUS_SPI0]  = RESET(0x2c0, BIT(20)),
+   [RST_BUS_SPI1]  = RESET(0x2c0, BIT(21)),
[RST_BUS_OTG]   = RESET(0x2c0, BIT(24)),
[RST_BUS_EHCI]  = RESET(0x2c0, BIT(26)),
[RST_BUS_OHCI]  = RESET(0x2c0, BIT(29)),
diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
index 5bd8b7dccc..fa6e3eeef0 100644
--- a/drivers/clk/sunxi/clk_a31.c
+++

[U-Boot] [PATCH v2 3/4] spi: sunxi: Add CLK support to Allwinner SPI driver