Re: [U-Boot] [linux-sunxi] [PATCH v2] sun8i: h3: Add support for the Beelink-x2 STB

[Jagan Teki]

On Thu, Nov 15, 2018 at 2:19 PM  wrote:
>
> From: Marcus Cooper 
>
> The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
> 2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using the
> SoC's integrated PHY, Wifi via an sdio wifi chip, HDMI, an IR receiver, a
> dual colour LED and an optical S/PDIF connector.
>
> Signed-off-by: Marcus Cooper 
> ---
>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/sun8i-h3-beelink-x2.dts | 179 +++
>  board/sunxi/MAINTAINERS  |   5 +
>  configs/beelink_x2_defconfig |  19 +++
>  4 files changed, 204 insertions(+)
>  create mode 100644 arch/arm/dts/sun8i-h3-beelink-x2.dts
>  create mode 100644 configs/beelink_x2_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 1cbb45d679..cc217d4f98 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -370,6 +370,7 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
> sun8i-h2-plus-orangepi-r1.dtb \
> sun8i-h2-plus-orangepi-zero.dtb \
> sun8i-h3-bananapi-m2-plus.dtb \
> +   sun8i-h3-beelink-x2.dtb \
> sun8i-h3-libretech-all-h3-cc.dtb \
> sun8i-h3-nanopi-m1.dtb \
> sun8i-h3-nanopi-m1-plus.dtb \
> diff --git a/arch/arm/dts/sun8i-h3-beelink-x2.dts 
> b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> new file mode 100644
> index 00..683c5c31a9
> --- /dev/null
> +++ b/arch/arm/dts/sun8i-h3-beelink-x2.dts
> @@ -0,0 +1,179 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Device Tree Source for Beelink X2
> +//
> +// Copyright (C) 2018 Marcus Cooper 

need space, but this doesn't look like Linux sync. better sync it
directly w/o any changes, if you need updated license do first in
Linux.

otherwise,

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

Re: [U-Boot] [PATCH] sunxi: Fix memory 2-rank initialization for a33 cpu

[Jagan Teki]

On Thu, Nov 1, 2018 at 12:33 AM Michael Trimarchi
 wrote:
>
> When we initialize the memory we need to autodetect rank and size
> but this can happen only if we send the proper reset to both
> memory module including cke signal.
> For this reason we need initialize the physical on both channel because
> we need to presume that both are connected. This way let the CLKE to be
> activated at the right time with the memory reset coming from the cpu
>
> Signed-off-by: Michael Trimarchi 
> ---

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 v2 3/3] sunxi-mmc: use new mode on both controllers on A64

[Jagan Teki]

On Sat, Nov 10, 2018 at 10:13 AM Vasily Khoruzhick  wrote:
>
> Using new mode improves stability of eMMC and SD cards. Without
> it SPL fails to load u-boot from SD on Pinebook.
>
> Signed-off-by: Vasily Khoruzhick 
> Reviewed-by: Chen-Yu Tsai 
> ---
>  arch/arm/mach-sunxi/Kconfig |  1 +
>  drivers/mmc/sunxi_mmc.c | 10 +++---
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 66fff6c6d3..3c54f5106d 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -282,6 +282,7 @@ config MACH_SUN50I
> select SUN6I_PRCM
> select SUNXI_DE2
> select SUNXI_GEN_SUN6I
> +   select MMC_SUNXI_HAS_NEW_MODE
> select SUPPORT_SPL
> select SUNXI_DRAM_DW
> select SUNXI_DRAM_DW_32BIT
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index e50b2c3343..2b6f3c2234 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -98,12 +98,16 @@ static int mmc_resource_init(int sdc_no)
>  static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
>  {
> unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
> -   bool new_mode = false;
> +   bool new_mode = true;
> bool calibrate = false;
> u32 val = 0;
>
> -   if (IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE) && (priv->mmc_no == 2))
> -   new_mode = true;
> +   if (!IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE))
> +   new_mode = false;
> +
> +   /* A83 support new mode only on eMMC */

s/A83/A83T

Tested-by: Jagan Teki  # Amarula A64-Relic

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 v2 2/3] sunxi-mmc: don't double clock for new mode unconditionally

[Jagan Teki]

On Sat, Nov 10, 2018 at 10:13 AM Vasily Khoruzhick  wrote:
>
> Comment in Linux driver says that clock needs to be doubled only
> if we use DDR modes, moreover divider has to be set accordingly.
>
> U-boot driver doesn't declare support for any DDR modes and doesn't
> set internal clock divider in CLKCR, so it doubles clock
> unconditionally when new mode is used.
>
> Some cards can't handle that and as result SPL fails to load u-boot.
>
> Fixes: de9b1771c3b ("mmc: sunxi: Support new mode")
> Signed-off-by: Vasily Khoruzhick 
> ---

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 v3 1/3] spi: pl022: Simplify platdata code

[Quentin Schulz]

Hi Jagan,

On Thu, Nov 22, 2018 at 12:03:47PM +0530, Jagan Teki wrote:
> pl022 spi driver support both OF_CONTROL and PLATDATA, this
> patch is trying to simplify the code that differentiating
> platdata vs of_control.
> - Move OF_CONTROL code at one place
> - Handle clock setup code directly in pl022_spi_ofdata_to_platdata
> 
> Cc: Quentin Schulz 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - none 
> Changes for v2:
> - Update commit message
> - Use struct clk for clkdev
> 
>  drivers/spi/pl022_spi.c  | 48 
>  include/dm/platform_data/pl022_spi.h |  9 --
>  2 files changed, 20 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
> index 86b71d2e21..05f4f6f481 100644
> --- a/drivers/spi/pl022_spi.c
> +++ b/drivers/spi/pl022_spi.c
> @@ -72,11 +72,7 @@
>  
>  struct pl022_spi_slave {
>   void *base;
> -#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> - struct clk clk;
> -#else
>   unsigned int freq;
> -#endif
>  };
>  
>  /*
> @@ -96,30 +92,13 @@ static int pl022_is_supported(struct pl022_spi_slave *ps)
>   return 0;
>  }
>  
> -#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> -static int pl022_spi_ofdata_to_platdata(struct udevice *bus)
> -{
> - struct pl022_spi_pdata *plat = bus->platdata;
> - const void *fdt = gd->fdt_blob;
> - int node = dev_of_offset(bus);
> -
> - plat->addr = fdtdec_get_addr_size(fdt, node, "reg", &plat->size);
> -
> - return clk_get_by_index(bus, 0, &plat->clk);
> -}
> -#endif
> -
>  static int pl022_spi_probe(struct udevice *bus)
>  {
>   struct pl022_spi_pdata *plat = dev_get_platdata(bus);
>   struct pl022_spi_slave *ps = dev_get_priv(bus);
>  
>   ps->base = ioremap(plat->addr, plat->size);
> -#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> - ps->clk = plat->clk;
> -#else
>   ps->freq = plat->freq;
> -#endif
>  
>   /* Check the PL022 version */
>   if (!pl022_is_supported(ps))
> @@ -240,11 +219,7 @@ static int pl022_spi_set_speed(struct udevice *bus, uint 
> speed)
>   u16 scr = SSP_SCR_MIN, cr0 = 0, cpsr = SSP_CPSR_MIN, best_scr = scr,
>   best_cpsr = cpsr;
>   u32 min, max, best_freq = 0, tmp;
> -#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> - u32 rate = clk_get_rate(&ps->clk);
> -#else
>   u32 rate = ps->freq;
> -#endif
>   bool found = false;
>  
>   max = spi_rate(rate, SSP_CPSR_MIN, SSP_SCR_MIN);
> @@ -316,6 +291,25 @@ static const struct dm_spi_ops pl022_spi_ops = {
>  };
>  
>  #if !CONFIG_IS_ENABLED(OF_PLATDATA)
> +static int pl022_spi_ofdata_to_platdata(struct udevice *bus)
> +{
> + struct pl022_spi_pdata *plat = bus->platdata;
> + const void *fdt = gd->fdt_blob;
> + int node = dev_of_offset(bus);
> + struct clk clkdev;
> + int ret;
> +
> + plat->addr = fdtdec_get_addr_size(fdt, node, "reg", &plat->size);
> +
> + ret = clk_get_by_index(bus, 0, &clkdev);
> + if (ret)
> + return ret;
> +
> + plat->freq = clk_get_rate(&clkdev);
> +
> + return 0;
> +}
> +
>  static const struct udevice_id pl022_spi_ids[] = {
>   { .compatible = "arm,pl022-spi" },
>   { }
> @@ -327,11 +321,9 @@ U_BOOT_DRIVER(pl022_spi) = {
>   .id = UCLASS_SPI,
>  #if !CONFIG_IS_ENABLED(OF_PLATDATA)
>   .of_match = pl022_spi_ids,
> -#endif
> - .ops= &pl022_spi_ops,
> -#if !CONFIG_IS_ENABLED(OF_PLATDATA)
>   .ofdata_to_platdata = pl022_spi_ofdata_to_platdata,
>  #endif
> + .ops= &pl022_spi_ops,
>   .platdata_auto_alloc_size = sizeof(struct pl022_spi_pdata),
>   .priv_auto_alloc_size = sizeof(struct pl022_spi_slave),
>   .probe  = pl022_spi_probe,
> diff --git a/include/dm/platform_data/pl022_spi.h 
> b/include/dm/platform_data/pl022_spi.h
> index 77fe6da3cb..57d12ac912 100644
> --- a/include/dm/platform_data/pl022_spi.h
> +++ b/include/dm/platform_data/pl022_spi.h
> @@ -10,19 +10,10 @@
>  #ifndef __PL022_SPI_H__
>  #define __PL022_SPI_H__
>  
> -#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> -#include 
> -#endif
> -#include 
> -

As stated in your first version of the patch[1][2], I need fdtdec.h to
be in this header file so that I can successfuly compile.

[1] https://lists.denx.de/pipermail/u-boot/2018-November/346470.html
[2] https://lists.denx.de/pipermail/u-boot/2018-November/347371.html

Quentin


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

Re: [U-Boot] [PATCH v2 1/3] sunxi-mmc: introduce new MMC_SUNXI_HAS_MODE_SWITCH option

[Jagan Teki]

On Sat, Nov 10, 2018 at 10:12 AM Vasily Khoruzhick  wrote:
>
> A64 doesn't have a mode switch in CCM, and CCM_MMC_CTRL_MODE_SEL_NEW
> is not defined, so compilation fails if MMC_SUNXI_HAS_NEW_MODE is enabled

Simple update on commit message.

Tested-by: Jagan Teki  # Amarula A64-Relic

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] [linux-sunxi] Re: [PATCH v3 0/9] Stop AXP from crashing when enabling LDO3

[Priit Laes]

On Wed, Nov 21, 2018 at 03:58:18PM -0500, Stefan Monnier wrote:
> > When powering up an AXP209, the default value for LDO3 output is
> > enabled.  This works fine.  However if for whatever reason, LDO3 is
> > disabled, for example by OS during reboot and u-boot enables LDO3
> > again, the PMIC shuts down (without setting an interrupt) causing the
> > board to hang.  This behavior has been seen from Linux as well, u-boot
> > disables LDO3 as a default value, the kernel enables it per its DTS,
> > the kernel hangs as the PMIC gets shut down.
> 
> Hmm... I've never had any problems booting my Orange Pi mini, but it
> (almost) always hangs on reboot (right after the final message from the
> OS and before the first message from U-boot).
> Any chance this is the same problem?

Well, f you have the hardware, then there's only one way to find out:

1) Apply patchset
2) Add following into boards defconfig:
CONFIG_AXP_ALDO3_INRUSH_QUIRK=y
3) If it still fails to reboot, add following
CONFIG_AXP_ALDO3_VOLT_SLOPE_08=y
> 
> 
> Stefan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 11/11] mtd: sf: Make sf_mtd.c more robust

[Jagan Teki]

On Tue, Nov 20, 2018 at 2:33 AM Boris Brezillon
 wrote:
>
> SPI flash based MTD devs can be registered/unregistered at any time
> through the sf probe command or the spi_flash_free() function.
>
> This commit does not try to fix the root cause as it would probably
> require rewriting most of the code and have an mtd_info object
> instance per spi_flash object (not to mention that the the spi-flash
> layer is likely to be replaced by a spi-nor layer ported from Linux).
>
> Instead, we try to be as safe as can be by checking the code returned
> by del_mtd_device() and complain loudly when there's nothing we can
> do about the deregistration failure. When that happens we also reset
> sf_mtd_info.priv to NULL, and check for NULL pointer in the mtd hooks
> so that -ENODEV is returned instead of hitting a NULL pointer
> dereference exception when the MTD instance is later accessed by a user.
>
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v3:
> - New patch
> ---
>  drivers/mtd/spi/sf_mtd.c | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
> index aabbc3589435..68c36002bee2 100644
> --- a/drivers/mtd/spi/sf_mtd.c
> +++ b/drivers/mtd/spi/sf_mtd.c
> @@ -18,6 +18,9 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct 
> erase_info *instr)
> struct spi_flash *flash = mtd->priv;
> int err;
>
> +   if (!flash)
> +   return -ENODEV;
> +
> instr->state = MTD_ERASING;
>
> err = spi_flash_erase(flash, instr->addr, instr->len);
> @@ -39,6 +42,9 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t 
> from, size_t len,
> struct spi_flash *flash = mtd->priv;
> int err;
>
> +   if (!flash)
> +   return -ENODEV;
> +
> err = spi_flash_read(flash, from, len, buf);
> if (!err)
> *retlen = len;
> @@ -52,6 +58,9 @@ static int spi_flash_mtd_write(struct mtd_info *mtd, loff_t 
> to, size_t len,
> struct spi_flash *flash = mtd->priv;
> int err;
>
> +   if (!flash)
> +   return -ENODEV;
> +
> err = spi_flash_write(flash, to, len, buf);
> if (!err)
> *retlen = len;
> @@ -76,8 +85,13 @@ int spi_flash_mtd_register(struct spi_flash *flash)
>  {
> int ret;
>
> -   if (sf_mtd_registered)
> -   del_mtd_device(&sf_mtd_info);
> +   if (sf_mtd_registered) {
> +   ret = del_mtd_device(&sf_mtd_info);
> +   if (ret)
> +   return ret;
> +
> +   sf_mtd_registered = false;
> +   }
>
> sf_mtd_registered = false;
> memset(&sf_mtd_info, 0, sizeof(sf_mtd_info));
> @@ -110,5 +124,24 @@ int spi_flash_mtd_register(struct spi_flash *flash)
>
>  void spi_flash_mtd_unregister(void)
>  {
> -   del_mtd_device(&sf_mtd_info);
> +   int ret;
> +
> +   if (!sf_mtd_registered)
> +   return;
> +
> +   ret = del_mtd_device(&sf_mtd_info);
> +   if (!ret) {
> +   sf_mtd_registered = false;
> +   return;
> +   }
> +
> +   /*
> +* Setting mtd->priv to NULL is the best we can do. Thanks to that,
> +* the MTD layer can still call mtd hooks without risking a
> +* use-after-free bug. Still, things should be fixed to prevent the
> +* spi_flash object from being destroyed when del_mtd_device() fails.
> +*/
> +   sf_mtd_info.priv = NULL;
> +   printf("Failed to unregister MTD %s and the spi_flash object is going 
> away: you're in deep trouble!",
> +  sf_mtd_info.name);

Why do we need this print? can't we do the same thing in MTD core
itself, so-that it can be generic for all flash objects.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/11] mtd: sf: Unregister the MTD device prior to removing the spi_flash obj

[Jagan Teki]

On Tue, Nov 20, 2018 at 2:37 AM Boris Brezillon
 wrote:
>
> The DM implementation of spi_flash_free() does not unregister the MTD
> device before removing the spi dev object. This leads to a use-after-free
> bug when the MTD device is later accessed by a MTD user (observed when
> attaching the device to UBI after env_sf_load() has called
> spi_flash_free()).
>
> Implement ->remove() and call spi_flash_mtd_unregister() from there.
>
> Fixes: 9fe6d8716e09 ("mtd, spi: Add MTD layer driver")
> Signed-off-by: Boris Brezillon 
> ---

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

Re: [U-Boot] [PATCH v3 04/11] mtd: sf: Make sure we don't register the same device twice

[Jagan Teki]

On Tue, Nov 20, 2018 at 2:35 AM Boris Brezillon
 wrote:
>
> spi_flash_mtd_register() can be called several times and each time it
> will register the same mtd_info instance like if it was a new one.
> The MTD ID allocation gets crazy when that happens, so let's track the
> status of the sf_mtd_info object to avoid that.
>
> Fixes: 9fe6d8716e09 ("mtd, spi: Add MTD layer driver")
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v3:
> - None
>
> Changes in v2
> - None
> ---

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

Re: [U-Boot] [PATCH 2/2] enable EMAC for A64-OLinuXino

[Jagan Teki]

On Fri, Nov 16, 2018 at 9:09 PM Alexander Weidinger
 wrote:
>
> Add Ethernet nodes to OLinuXino DT to enable Gigabit Ethernet
> [ commit 21eac6f33e68ae778e9d1c910606452abf058d3d in Linux ]
>
> Set PHY TX delay of 600ps
> [ commit 679294497be31596e1c9c61507746d72b6b05f26 in Linux ]
>
> Signed-off-by: Alexander Weidinger 
> ---

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

Re: [U-Boot] [PATCH 1/2] sun8i_emac: add support for setting EMAC TX/RX delay

[Jagan Teki]

On Fri, Nov 16, 2018 at 9:08 PM Alexander Weidinger
 wrote:
>
> From: Icenowy Zheng 
>
> Some boards have the EMAC TX/RX lanes wired with a different length with
> the clock lane, which can be workarounded by setting a TX/RX delay in
> the EMAC.
>
> This kind of delays are already defined in the newest device tree
> binding of dwmac-sun8i, which has already entered linux-next.
>
> Add support for setting these delays.
>
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/net/sun8i_emac.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index 3ba3a1ff8b..230ff045d5 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -60,6 +60,10 @@
>  #define SC_ETCS_MASK   GENMASK(1, 0)
>  #define SC_ETCS_EXT_GMII   0x1
>  #define SC_ETCS_INT_GMII   0x2
> +#define SC_ETXDC_MASK  GENMASK(12, 10)
> +#define SC_ETXDC_OFFSET10
> +#define SC_ERXDC_MASK  GENMASK(9, 5)
> +#define SC_ERXDC_OFFSET5
>
>  #define CONFIG_MDIO_TIMEOUT(3 * CONFIG_SYS_HZ)
>
> @@ -140,6 +144,8 @@ struct emac_eth_dev {
>  struct sun8i_eth_pdata {
> struct eth_pdata eth_pdata;
> u32 reset_delays[3];
> +   int tx_delay_ps;
> +   int rx_delay_ps;
>  };
>
>
> @@ -273,7 +279,8 @@ static int sun8i_emac_set_syscon_ephy(struct emac_eth_dev 
> *priv, u32 *reg)
> return 0;
>  }
>
> -static int sun8i_emac_set_syscon(struct emac_eth_dev *priv)
> +static int sun8i_emac_set_syscon(struct sun8i_eth_pdata *pdata,
> +struct emac_eth_dev *priv)
>  {
> int ret;
> u32 reg;
> @@ -312,6 +319,14 @@ static int sun8i_emac_set_syscon(struct emac_eth_dev 
> *priv)
> return -EINVAL;
> }
>
> +   if (pdata->tx_delay_ps)
> +   reg |= ((pdata->tx_delay_ps / 100) << SC_ETXDC_OFFSET)
> +& SC_ETXDC_MASK;
> +
> +   if (pdata->rx_delay_ps)
> +   reg |= ((pdata->rx_delay_ps / 100) << SC_ERXDC_OFFSET)
> +& SC_ERXDC_MASK;
> +
> writel(reg, priv->sysctl_reg + 0x30);
>
> return 0;
> @@ -790,7 +805,7 @@ static int sun8i_emac_eth_probe(struct udevice *dev)
> priv->mac_reg = (void *)pdata->iobase;
>
> sun8i_emac_board_setup(priv);
> -   sun8i_emac_set_syscon(priv);
> +   sun8i_emac_set_syscon((struct sun8i_eth_pdata *)pdata, priv);

We can get the platdata using dev_get_platdata instead of this type casting.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH u-boot v3 0/3] Add Amlogic Meson SPI Flash Controller driver

[Jagan Teki]

On Wed, Nov 14, 2018 at 3:55 PM Neil Armstrong  wrote:
>
> The Amlogic Meson SoCs embeds a Flash oriented SPI Controller name SPIFC.
>
> This patchset add the driver ported from linux, but also import the regmap
> regmap_read_poll_timeout() to implify the register polling in the driver.
>
> Neil Armstrong (3):
>   regmap: add regmap_read_poll_timeout() helper
>   test: regmap: add regmap_read_poll_timeout test
>   spi: Add Amlogic Meson SPI Flash Controller driver

There are few regmap patches upstreamed recently, can you rebase and
the send the series again. take care of direct poll_timeout w/o any
function on driver.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 2/3] spi: pl022: Drop unnecessary include files

[Jagan Teki]

This patch can drop unnecessary include files in
pl022_spi driver.

Cc: Quentin Schulz 
Signed-off-by: Jagan Teki 
---
Changes for v3:
- split patch from previous

 drivers/spi/pl022_spi.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
index 05f4f6f481..f2e5367225 100644
--- a/drivers/spi/pl022_spi.c
+++ b/drivers/spi/pl022_spi.c
@@ -9,16 +9,11 @@
  * Driver for ARM PL022 SPI Controller.
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include 
 
 #define SSP_CR00x000
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH v3 3/3] dm: platform_data: spi: s/pl022_spi.h/spi_pl022.h

[Jagan Teki]

Rename platform_data include file as spi_pl022.h from pl022_spi.h,
this is generic notation used for spi platdata include files.

Cc: Quentin Schulz 
Signed-off-by: Jagan Teki 
---
Changes for v3:
- split patch from previous

 drivers/spi/pl022_spi.c   | 2 +-
 include/dm/platform_data/{pl022_spi.h => spi_pl022.h} | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)
 rename include/dm/platform_data/{pl022_spi.h => spi_pl022.h} (81%)

diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
index f2e5367225..32bb8c8d21 100644
--- a/drivers/spi/pl022_spi.c
+++ b/drivers/spi/pl022_spi.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/include/dm/platform_data/pl022_spi.h 
b/include/dm/platform_data/spi_pl022.h
similarity index 81%
rename from include/dm/platform_data/pl022_spi.h
rename to include/dm/platform_data/spi_pl022.h
index 57d12ac912..36e645c836 100644
--- a/include/dm/platform_data/pl022_spi.h
+++ b/include/dm/platform_data/spi_pl022.h
@@ -7,8 +7,8 @@
  * in ofdata_to_platdata.
  */
 
-#ifndef __PL022_SPI_H__
-#define __PL022_SPI_H__
+#ifndef __spi_pl022_h
+#define __spi_pl022_h
 
 struct pl022_spi_pdata {
fdt_addr_t addr;
@@ -16,4 +16,4 @@ struct pl022_spi_pdata {
unsigned int freq;
 };
 
-#endif
+#endif /* __spi_pl022_h */
-- 
2.18.0.321.gffc6fa0e3

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

[U-Boot] [PATCH v3 1/3] spi: pl022: Simplify platdata code

[Jagan Teki]

pl022 spi driver support both OF_CONTROL and PLATDATA, this
patch is trying to simplify the code that differentiating
platdata vs of_control.
- Move OF_CONTROL code at one place
- Handle clock setup code directly in pl022_spi_ofdata_to_platdata

Cc: Quentin Schulz 
Signed-off-by: Jagan Teki 
---
Changes for v3:
- none 
Changes for v2:
- Update commit message
- Use struct clk for clkdev

 drivers/spi/pl022_spi.c  | 48 
 include/dm/platform_data/pl022_spi.h |  9 --
 2 files changed, 20 insertions(+), 37 deletions(-)

diff --git a/drivers/spi/pl022_spi.c b/drivers/spi/pl022_spi.c
index 86b71d2e21..05f4f6f481 100644
--- a/drivers/spi/pl022_spi.c
+++ b/drivers/spi/pl022_spi.c
@@ -72,11 +72,7 @@
 
 struct pl022_spi_slave {
void *base;
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
-   struct clk clk;
-#else
unsigned int freq;
-#endif
 };
 
 /*
@@ -96,30 +92,13 @@ static int pl022_is_supported(struct pl022_spi_slave *ps)
return 0;
 }
 
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
-static int pl022_spi_ofdata_to_platdata(struct udevice *bus)
-{
-   struct pl022_spi_pdata *plat = bus->platdata;
-   const void *fdt = gd->fdt_blob;
-   int node = dev_of_offset(bus);
-
-   plat->addr = fdtdec_get_addr_size(fdt, node, "reg", &plat->size);
-
-   return clk_get_by_index(bus, 0, &plat->clk);
-}
-#endif
-
 static int pl022_spi_probe(struct udevice *bus)
 {
struct pl022_spi_pdata *plat = dev_get_platdata(bus);
struct pl022_spi_slave *ps = dev_get_priv(bus);
 
ps->base = ioremap(plat->addr, plat->size);
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
-   ps->clk = plat->clk;
-#else
ps->freq = plat->freq;
-#endif
 
/* Check the PL022 version */
if (!pl022_is_supported(ps))
@@ -240,11 +219,7 @@ static int pl022_spi_set_speed(struct udevice *bus, uint 
speed)
u16 scr = SSP_SCR_MIN, cr0 = 0, cpsr = SSP_CPSR_MIN, best_scr = scr,
best_cpsr = cpsr;
u32 min, max, best_freq = 0, tmp;
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
-   u32 rate = clk_get_rate(&ps->clk);
-#else
u32 rate = ps->freq;
-#endif
bool found = false;
 
max = spi_rate(rate, SSP_CPSR_MIN, SSP_SCR_MIN);
@@ -316,6 +291,25 @@ static const struct dm_spi_ops pl022_spi_ops = {
 };
 
 #if !CONFIG_IS_ENABLED(OF_PLATDATA)
+static int pl022_spi_ofdata_to_platdata(struct udevice *bus)
+{
+   struct pl022_spi_pdata *plat = bus->platdata;
+   const void *fdt = gd->fdt_blob;
+   int node = dev_of_offset(bus);
+   struct clk clkdev;
+   int ret;
+
+   plat->addr = fdtdec_get_addr_size(fdt, node, "reg", &plat->size);
+
+   ret = clk_get_by_index(bus, 0, &clkdev);
+   if (ret)
+   return ret;
+
+   plat->freq = clk_get_rate(&clkdev);
+
+   return 0;
+}
+
 static const struct udevice_id pl022_spi_ids[] = {
{ .compatible = "arm,pl022-spi" },
{ }
@@ -327,11 +321,9 @@ U_BOOT_DRIVER(pl022_spi) = {
.id = UCLASS_SPI,
 #if !CONFIG_IS_ENABLED(OF_PLATDATA)
.of_match = pl022_spi_ids,
-#endif
-   .ops= &pl022_spi_ops,
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
.ofdata_to_platdata = pl022_spi_ofdata_to_platdata,
 #endif
+   .ops= &pl022_spi_ops,
.platdata_auto_alloc_size = sizeof(struct pl022_spi_pdata),
.priv_auto_alloc_size = sizeof(struct pl022_spi_slave),
.probe  = pl022_spi_probe,
diff --git a/include/dm/platform_data/pl022_spi.h 
b/include/dm/platform_data/pl022_spi.h
index 77fe6da3cb..57d12ac912 100644
--- a/include/dm/platform_data/pl022_spi.h
+++ b/include/dm/platform_data/pl022_spi.h
@@ -10,19 +10,10 @@
 #ifndef __PL022_SPI_H__
 #define __PL022_SPI_H__
 
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
-#include 
-#endif
-#include 
-
 struct pl022_spi_pdata {
fdt_addr_t addr;
fdt_size_t size;
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
-   struct clk clk;
-#else
unsigned int freq;
-#endif
 };
 
 #endif
-- 
2.18.0.321.gffc6fa0e3

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

Re: [U-Boot] [PATCH v2 17/18] spi: mtk_qspi: add qspi driver for MT7629 SoC

[Jagan Teki]

On Wed, Nov 21, 2018 at 5:16 PM Guochun Mao  wrote:
>
> Hi Jagan,
>
> On Wed, 2018-11-21 at 15:08 +0530, Jagan Teki wrote:
>
> > > > > +static int mtk_qspi_tx_rx(struct mtk_qspi_priv *priv)
> > > > > +{
> > > > > +   int len = 1 + priv->txlen + priv->rxlen;
> > > > > +   int i, ret, idx;
> > > > > +
> > > > > +   if (len > MTK_QSPI_MAX_SHIFT)
> > > > > +   return -ERR_INVAL;
> > > > > +
> > > > > +   writeb(len * 8, &priv->regs->cnt);
> > > > > +
> > > > > +   /* start at PRGDATA5, go down to PRGDATA0 */
> > > > > +   idx = MTK_QSPI_MAX_RX_TX_SHIFT - 1;
> > > > > +
> > > > > +   /* opcode */
> > > > > +   writeb(priv->op, &priv->regs->prgdata[idx]);
> > > > > +   idx--;
> > > > > +
> > > > > +   /* program TX data */
> > > > > +   for (i = 0; i < priv->txlen; i++, idx--)
> > > > > +   writeb(priv->tx[i], &priv->regs->prgdata[idx]);
> > > > > +
> > > > > +   /* clear out rest of TX registers */
> > > > > +   while (idx >= 0) {
> > > > > +   writeb(0, &priv->regs->prgdata[idx]);
> > > > > +   idx--;
> > > > > +   }
> > > > > +
> > > > > +   ret = mtk_qspi_execute_cmd(priv, MTK_QSPI_PRG_CMD);
> > > >
> > > > What does this execute do?
> > > It send command to flash, and latch data if need.
> > >
> > > > does it intiate the controller register
> > > > based flash command or so?
> > > No, it doesn't.
> > >
> > > >
> > > > Do you have Linux driver on the controller?
> > > Yes, it's drivers/mtd/spi-nor/mtk-quadspi.c
> >
> > This sounds more specific to flash controller rather than spi driver.
> > Can you try to write driver in mtd side itself, like Linux spi-nor.
> > use UCLASS_SPI_FLASH
>
> Sorry, I'm a little confused.
> There are many files(***qspi.c) those that used for accessing spi flash
> under folder drivers/spi/.
> However, there's no specific flash controller driver implemented under
> drives/mtd, only common spi_flash framework. It's different with kernel.
> It seems that we only need implement the spi control logic of
> spi-flash-controller(this part not based on flash, it only do
> data-xfer), and spi_flash framework will work well base on it.
> Isn't that the purpose of this architecture?

Understand your point, to be precise the driver may a fall in trouble
after sometime, if there is an additional flash specific features will
attach in future. ie reason few of flash controllers in drivers/spi
were unable to move further to add their features. and ie also reason
for your driver in Linux which resides in spi-nor.

You can directly write UCLASS_SPI_FLASH like sf_dataflash, I can help
if any issues with probing setup etc.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd: ubi: Make ubi_detach() static

[Jagan Teki]

On Wed, Oct 31, 2018 at 5:07 PM Stefan Roese  wrote:
>
> Its only called from this file, so make it static. While at it, remove
> some occurances of multiple blank lines as well.
>
> Signed-off-by: Stefan Roese 
> Cc: Boris Brezillon 
> Cc: Miquel Raynal 
> Cc: Jagan Teki 
> ---

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

Re: [U-Boot] [PATCH 0/3] Add raw read support and use it in pxa3xx NAND driver

[Jagan Teki]

On Tue, Oct 23, 2018 at 4:35 PM Jagan Teki  wrote:
>
> On Thu, Oct 11, 2018 at 9:16 PM Miquel Raynal  
> wrote:
> >
> > When using 2kiB-pages NAND chips requesting an 8-bit strength ECC, the
> > layout used is a bit particular and it happens that the ECC engine
> > tries to correct uncorrectable errors on empty pages, producing
> > bitflips.
> >
> > To avoid such situation, raw read support is added to the pxa3xx_nand
> > driver, and then used to re-read the page (in raw mode) upon
> > uncorrectable error detection to know if there is an actual ECC
> > mismatch or if the page is empty. This way we avoid seeing the
> > bitflips created by the hardware ECC engine.
> >
> > Once this done, we can revert the hack that was done in the driver to
> > enlarge the last spare area for this layout to 64B instead of 32B,
> > breaking U-Boot/Linux compatibility and preventing the BootROM to boot
> > from NAND.
> >
> > Thanks,
> > Miquèl
> >
> >
> > Miquel Raynal (3):
> >   mtd: nand: pxa3xx: add raw read support
> >   mtd: nand: pxa3xx: re-read a page in raw mode on uncorrectable error
> >   mtd: rawnand: pxa3xx: fix 2kiB pages with 8b strength chips layout
>
> Acked-by: Jagan Teki 

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

Re: [U-Boot] [PATCH v2 0/3] sunxi-mmc: enable new clock mode on A64

[Jagan Teki]

On Thu, Nov 22, 2018 at 2:01 AM Vasily Khoruzhick  wrote:
>
> On Thu, Nov 15, 2018 at 11:20 AM Vasily Khoruzhick  wrote:
> >
> > On Fri, Nov 9, 2018 at 8:41 PM Vasily Khoruzhick  wrote:
> > >
> > > A64 requires new clock mode on SD and eMMC controllers. Not using
> > > new clock mode causes stability issues of the driver - SPL may
> > > occasionally fail to load u-boot from SD for some particular SD card
> > > on some particular devices.
> > >
> > > This series depends on "sunxi: add support for automatic delay 
> > > calibration"
> > > from my Pinebook series.
> > >
> > > Tested on Pinebook and Pine64-LTS. Fixes eMMC failures on Olinuxino-A64 
> > > [1]
> >
> > Ping? I've got reports from several users that it fixes issues with
> > different SD cards on Pinebook and Sopine. It would be nice to have it
> > merged.
>
> Another gentle reminder - patches has been sitting in ML for almost 2
> weeks with no review.

Be wait for some time, I understand your concern and I'm working on
priority basic (that I mentioned in IRC). will come to this series.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 3/3] rtc: m41t62: Convert the RTC driver to support the driver model (DM)

[Stefan Roese]

On 21.11.18 23:43, Lukasz Majewski wrote:

After this change the m41t62.c can be used with RTC subsystem (i.e. date
command) which uses device model (DM).

Signed-off-by: Lukasz Majewski 

---

Changes in v1:
- New

  drivers/rtc/m41t62.c | 75 +---
  1 file changed, 72 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/m41t62.c b/drivers/rtc/m41t62.c
index cc230e2b78..2dcc1f2a63 100644
--- a/drivers/rtc/m41t62.c
+++ b/drivers/rtc/m41t62.c
@@ -1,5 +1,8 @@
  // SPDX-License-Identifier: GPL-2.0+
  /*
+ * (C) Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
+ *
   * (C) Copyright 2008
   * Stefan Roese, DENX Software Engineering, s...@denx.de.
   *
@@ -15,6 +18,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  
@@ -49,11 +53,23 @@
  
  #define M41T80_ALHOUR_HT	(1 << 6)	/* HT: Halt Update Bit */
  
+#ifdef CONFIG_DM_RTC

+static int m41t62_rtc_get(struct udevice *dev, struct rtc_time *tm)
+{
+#else
  int rtc_get(struct rtc_time *tm)
  {
+#endif /* CONFIG_DM_RTC */
u8 buf[M41T62_DATETIME_REG_SIZE];
  
+#ifdef CONFIG_DM_RTC

+   int ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
+
+   if (ret)
+   return ret;
+#else
i2c_read(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf, M41T62_DATETIME_REG_SIZE);
+#endif /* CONFIG_DM_RTC */
  
  	debug("%s: raw read data - sec=%02x, min=%02x, hr=%02x, "

  "mday=%02x, mon=%02x, year=%02x, wday=%02x, y2k=%02x\n",
@@ -81,15 +97,28 @@ int rtc_get(struct rtc_time *tm)
return 0;
  }


These #ifdef's in the function headers are a bit ugly. I personally
prefer to create a common function and call this from the "old"
(non-DM) function and the newly created DM function instead.

Perhaps you can rework this for all these functions (below as well)
and re-submit?

Thanks,
Stefan

  
+#ifdef CONFIG_DM_RTC

+static int m41t62_rtc_set(struct udevice *dev, const struct rtc_time *tm)
+{
+#else
  int rtc_set(struct rtc_time *tm)
  {
+#endif /* CONFIG_DM_RTC */
u8 buf[M41T62_DATETIME_REG_SIZE];
+   int ret;
  
  	debug("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",

  tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_wday,
  tm->tm_hour, tm->tm_min, tm->tm_sec);
  
-	i2c_read(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf, M41T62_DATETIME_REG_SIZE);

+#ifdef CONFIG_DM_RTC
+   ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
+#else
+   ret = i2c_read(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf,
+  M41T62_DATETIME_REG_SIZE);
+#endif /* CONFIG_DM_RTC */
+   if (ret)
+   return ret;
  
  	/* Merge time-data and register flags into buf[0..7] */

buf[M41T62_REG_SSEC] = 0;
@@ -108,8 +137,13 @@ int rtc_set(struct rtc_time *tm)
/* assume 20YY not 19YY */
buf[M41T62_REG_YEAR] = bin2bcd(tm->tm_year % 100);
  
-	if (i2c_write(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf,

- M41T62_DATETIME_REG_SIZE)) {
+#ifdef CONFIG_DM_RTC
+   ret = dm_i2c_write(dev, 0, buf, sizeof(buf));
+#else
+   ret = i2c_write(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf,
+   M41T62_DATETIME_REG_SIZE);
+#endif /* CONFIG_DM_RTC */
+   if (ret) {
printf("I2C write failed in %s()\n", __func__);
return -1;
}
@@ -117,15 +151,50 @@ int rtc_set(struct rtc_time *tm)
return 0;
  }
  
+#ifdef CONFIG_DM_RTC

+static int m41t62_rtc_reset(struct udevice *dev)
+{
+#else
  void rtc_reset(void)
  {
+#endif /* CONFIG_DM_RTC */
u8 val;
  
  	/*

 * M41T82: Make sure HT (Halt Update) bit is cleared.
 * This bit is 0 in M41T62 so its save to clear it always.
 */
+#ifdef CONFIG_DM_RTC
+   int ret = dm_i2c_read(dev, M41T62_REG_ALARM_HOUR, &val, sizeof(val));
+
+   val &= ~M41T80_ALHOUR_HT;
+   ret |= dm_i2c_write(dev, M41T62_REG_ALARM_HOUR, &val, sizeof(val));
+
+   return ret;
+#else
i2c_read(CONFIG_SYS_I2C_RTC_ADDR, M41T62_REG_ALARM_HOUR, 1, &val, 1);
val &= ~M41T80_ALHOUR_HT;
i2c_write(CONFIG_SYS_I2C_RTC_ADDR, M41T62_REG_ALARM_HOUR, 1, &val, 1);
+#endif /* CONFIG_DM_RTC */
  }
+
+#ifdef CONFIG_DM_RTC
+static const struct rtc_ops m41t62_rtc_ops = {
+   .get = m41t62_rtc_get,
+   .set = m41t62_rtc_set,
+   .reset = m41t62_rtc_reset,
+};
+
+static const struct udevice_id m41t62_rtc_ids[] = {
+   { .compatible = "st,m41t62" },
+   { .compatible = "microcrystal,rv4162" },
+   { }
+};
+
+U_BOOT_DRIVER(rtc_m41t62) = {
+   .name   = "rtc-m41t62",
+   .id = UCLASS_RTC,
+   .of_match = m41t62_rtc_ids,
+   .ops= &m41t62_rtc_ops,
+};
+#endif /* CONFIG_DM_RTC */



Viele Grüße,
Stefan

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

Re: [U-Boot] [PATCH v1 2/3] rtc: m41t62: Break i2c_write() arguments to fix checkpatch warning

[Stefan Roese]

On 21.11.18 23:43, Lukasz Majewski wrote:

No functional change for this commit.

Signed-off-by: Lukasz Majewski 


Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH v1 1/3] Kconfig: Migrate CONFIG_RTC_M41T62 define to Kconfig

[Stefan Roese]

On 21.11.18 23:43, Lukasz Majewski wrote:

This patch moves the RTC M41T62 config define to Kconfig.

Signed-off-by: Lukasz Majewski 


Reviewed-by: Stefan Roese 

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

Re: [U-Boot] [PATCH] arm: socfpga: crc-protect SPL on warm boot

[Simon Goldschmidt]

Am Do., 22. Nov. 2018, 03:00 hat Marek Vasut  geschrieben:

> On 11/21/2018 10:07 PM, Simon Goldschmidt wrote:
> > On 21.11.2018 15:08, Marek Vasut wrote:
> >> On 11/21/2018 06:09 AM, Simon Goldschmidt wrote:
> >>>
> >>> Am Mi., 21. Nov. 2018, 00:11 hat Marek Vasut  >>> > geschrieben:
> >>>
> >>>  On 11/20/2018 09:54 PM, Simon Goldschmidt wrote:
> >>>  > On 20.11.2018 20:33, Marek Vasut wrote:
> >>>  >> On 11/20/2018 08:22 PM, Simon Goldschmidt wrote:
> >>>  >>> From: Simon Goldschmidt  >>>  >
> >>>  >>>
> >>>  >>> On socfpga gen5, a warm reboot from Linux currently triggers
> >>> a warm
> >>>  >>> reset via reset manager ctrl register.
> >>>  >>>
> >>>  >>> This currently leads to the boot rom just jumping to onchip
> ram
> >>>  >>> executing the SPL that is supposed to still be there. This is
> >>>  >>> because we tell the boot rom to do so by writing a magin value
> >>>  >>> the warmramgrp_enable register in arch_early_init_r().
> >>>  >>>
> >>>  >>> However, this can lead to lockups on reboot if this register
> >>> still
> >>>  >>> contains its magic value but the SPL is not intact any more
> >>> (e.g.
> >>>  >>> partly overwritten onchip ram).
> >>>  >>>
> >>>  >>> To fis this, store a crc calculated over SPL in sysmgr
> >>> registers to
> >>>  >>> let the boot rom check it on next warm boot. If the crc is
> >>> still
> >>>  >>> correct, SPL can be executd from onchip ram. If the crc
> >>> fails, SPL
> >>>  >>> is loaded from original boot source.
> >>>  >>>
> >>>  >>> The crc that is written to the warmramgrp_crc register is
> >>> the crc
> >>>  >>> found in the SPL sfp image but with one addiional u32 added.
> >>> For
> >>>  >>> this, we need to add a function to calculate the updated
> >>> crc. This
> >>>  >>> is done as a bitwise calculation to keep the code increase
> >>> small.
> >>>  >>>
> >>>  >>> This whole patch added 96 bytes to .text for SPL for
> >>>  >>> socfpga_socrates_defconfig.
> >>>  >>>
> >>>  >>> Signed-off-by: Simon Goldschmidt
> >>>   >>>  >
> >>>  >>> ---
> >>>  >>>
> >>>  >>>   arch/arm/mach-socfpga/misc_gen5.c |  9 
> >>>  >>>   arch/arm/mach-socfpga/spl_gen5.c  | 73
> >>>  +++
> >>>  >>>   2 files changed, 73 insertions(+), 9 deletions(-)
> >>>  >>>
> >>>  >>> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
> >>>  >>> b/arch/arm/mach-socfpga/misc_gen5.c
> >>>  >>> index 5fa40937c4..492a3082de 100644
> >>>  >>> --- a/arch/arm/mach-socfpga/misc_gen5.c
> >>>  >>> +++ b/arch/arm/mach-socfpga/misc_gen5.c
> >>>  >>> @@ -204,15 +204,6 @@ int arch_early_init_r(void)
> >>>  >>>   {
> >>>  >>>   int i;
> >>>  >>>   -/*
> >>>  >>> - * Write magic value into magic register to unlock
> >>> support for
> >>>  >>> - * issuing warm reset. The ancient kernel code expects
> >>> this
> >>>  >>> - * value to be written into the register by the
> >>> bootloader, so
> >>>  >>> - * to support that old code, we write it here instead
> >>> of in the
> >>>  >>> - * reset_cpu() function just before resetting the CPU.
> >>>  >>> - */
> >>>  >>> -writel(0xae9efebc,
> >>> &sysmgr_regs->romcodegrp_warmramgrp_enable);
> >>>  >>> -
> >>>  >>>   for (i = 0; i < 8; i++)/* Cache initial SW setting
> >>> regs */
> >>>  >>>   iswgrp_handoff[i] =
> >>>  readl(&sysmgr_regs->iswgrp_handoff[i]);
> >>>  >>>   diff --git a/arch/arm/mach-socfpga/spl_gen5.c
> >>>  >>> b/arch/arm/mach-socfpga/spl_gen5.c
> >>>  >>> index ccdc661d05..3416e19f79 100644
> >>>  >>> --- a/arch/arm/mach-socfpga/spl_gen5.c
> >>>  >>> +++ b/arch/arm/mach-socfpga/spl_gen5.c
> >>>  >>> @@ -63,6 +63,76 @@ u32 spl_boot_mode(const u32 boot_device)
> >>>  >>>   }
> >>>  >>>   #endif
> >>>  >>>   +/* This function calculates the CRC32 used by the Cyclone
> >>> 5 SoC
> >>>  >>> Boot Rom */
> >>>  >>> +static u32 socfpga_boot_crc(u32 crc, const unsigned char
> >>> *ptr, u32
> >>>  >>> length)
> >>>  >>> +{
> >>>  >>> +uint i;
> >>>  >>> +u8 bit;
> >>>  >>> +unsigned char data;
> >>>  >>> +const u32 poly = 0x02608edb;
> >>>  >>> +
> >>>  >>> +for (; length > 0; length--, ptr++) {
> >>>  >>> +data = *ptr;
> >>>  >>> +for (i = 0; i < 8; i++) {
> >>>  >>> +if (data & 0x80)
> >>>  >>> +bit = 1;
> >>>  >>> +else
> >>>  >>> +bit = 0;
> >>>  >>> +
> >>>  >>> +data = data << 1;
> >>>  >>> +if (crc & 0x8000)
> >>>  >>> +bit = 1 - bit;
> >>>  >>> +
> >>>  >>> +if (bit) {
> >>>

[U-Boot] [PATCH v4 2/3] riscv: qemu: Use different SYS_TEXT_BASE for S-mode

[Anup Patel]

When u-boot runs in S-mode, the M-mode runtime firmware
(BBL or equivalent) uses memory range in 0x8000 to
0x8020. Due to this, we cannot use 0x8000 as
SYS_TEXT_BASE when running in S-mode. Instead for S-mode,
we use 0x8020 as SYS_TEXT_BASE.

Even Linux RISC-V kernel ignores/reserves memory range
0x8000 to 0x8020 because it runs in S-mode.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Reviewed-by: Lukas Auer 
---
 board/emulation/qemu-riscv/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/board/emulation/qemu-riscv/Kconfig 
b/board/emulation/qemu-riscv/Kconfig
index 33ca253432..56bb5337d4 100644
--- a/board/emulation/qemu-riscv/Kconfig
+++ b/board/emulation/qemu-riscv/Kconfig
@@ -13,7 +13,8 @@ config SYS_CONFIG_NAME
default "qemu-riscv"
 
 config SYS_TEXT_BASE
-   default 0x8000
+   default 0x8000 if !RISCV_SMODE
+   default 0x8020 if RISCV_SMODE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
-- 
2.17.1

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

[U-Boot] [PATCH v4 3/3] riscv: Add S-mode defconfigs for QEMU virt machine

[Anup Patel]

This patch adds S-mode defconfigs for QEMU virt machine so
that we can run u-boot in S-mode on QEMU using M-mode runtime
firmware (BBL or equivalent).

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Reviewed-by: Lukas Auer 
---
 board/emulation/qemu-riscv/MAINTAINERS |  2 ++
 configs/qemu-riscv32_smode_defconfig   | 10 ++
 configs/qemu-riscv64_smode_defconfig   | 11 +++
 3 files changed, 23 insertions(+)
 create mode 100644 configs/qemu-riscv32_smode_defconfig
 create mode 100644 configs/qemu-riscv64_smode_defconfig

diff --git a/board/emulation/qemu-riscv/MAINTAINERS 
b/board/emulation/qemu-riscv/MAINTAINERS
index 3c6eb4f844..c701c83d77 100644
--- a/board/emulation/qemu-riscv/MAINTAINERS
+++ b/board/emulation/qemu-riscv/MAINTAINERS
@@ -4,4 +4,6 @@ S:  Maintained
 F: board/emulation/qemu-riscv/
 F: include/configs/qemu-riscv.h
 F: configs/qemu-riscv32_defconfig
+F: configs/qemu-riscv32_smode_defconfig
 F: configs/qemu-riscv64_defconfig
+F: configs/qemu-riscv64_smode_defconfig
diff --git a/configs/qemu-riscv32_smode_defconfig 
b/configs/qemu-riscv32_smode_defconfig
new file mode 100644
index 00..0a84ec1874
--- /dev/null
+++ b/configs/qemu-riscv32_smode_defconfig
@@ -0,0 +1,10 @@
+CONFIG_RISCV=y
+CONFIG_TARGET_QEMU_VIRT=y
+CONFIG_RISCV_SMODE=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_FIT=y
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+# CONFIG_CMD_MII is not set
+CONFIG_OF_PRIOR_STAGE=y
diff --git a/configs/qemu-riscv64_smode_defconfig 
b/configs/qemu-riscv64_smode_defconfig
new file mode 100644
index 00..b012443370
--- /dev/null
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -0,0 +1,11 @@
+CONFIG_RISCV=y
+CONFIG_TARGET_QEMU_VIRT=y
+CONFIG_ARCH_RV64I=y
+CONFIG_RISCV_SMODE=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_FIT=y
+CONFIG_DISPLAY_CPUINFO=y
+CONFIG_DISPLAY_BOARDINFO=y
+# CONFIG_CMD_MII is not set
+CONFIG_OF_PRIOR_STAGE=y
-- 
2.17.1

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

[U-Boot] [PATCH v4 1/3] riscv: Add kconfig option to run U-Boot in S-mode

[Anup Patel]

This patch adds kconfig option RISCV_SMODE to run U-Boot in
S-mode. When this opition is enabled we use s CSRs instead
of m CSRs.

It is important to note that there is no equivalent S-mode CSR
for misa and mhartid CSRs so we expect M-mode runtime firmware
(BBL or equivalent) to emulate misa and mhartid CSR read.

In-future, we will have more patches to avoid accessing misa and
mhartid CSRs from S-mode.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
Reviewed-by: Lukas Auer 
---
 arch/riscv/Kconfig|  5 +
 arch/riscv/cpu/start.S| 33 
 arch/riscv/include/asm/encoding.h |  2 ++
 arch/riscv/lib/interrupts.c   | 36 +++
 4 files changed, 67 insertions(+), 9 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 3e0af55e71..732a357a99 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -55,6 +55,11 @@ config RISCV_ISA_C
 config RISCV_ISA_A
def_bool y
 
+config RISCV_SMODE
+   bool "Run in S-Mode"
+   help
+ Enable this option to build U-Boot for RISC-V S-Mode
+
 config 32BIT
bool
 
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 5af189b338..e4276e8e19 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -39,10 +39,18 @@ _start:
mv  s1, a1
 
la  t0, trap_entry
+#ifdef CONFIG_RISCV_SMODE
+   csrwstvec, t0
+#else
csrwmtvec, t0
+#endif
 
/* mask all interrupts */
+#ifdef CONFIG_RISCV_SMODE
+   csrwsie, zero
+#else
csrwmie, zero
+#endif
 
/* Enable cache */
jal icache_enable
@@ -164,7 +172,11 @@ fix_rela_dyn:
 */
la  t0, trap_entry
add t0, t0, t6
+#ifdef CONFIG_RISCV_SMODE
+   csrwstvec, t0
+#else
csrwmtvec, t0
+#endif
 
 clear_bss:
la  t0, __bss_start /* t0 <- rel __bss_start in FLASH */
@@ -236,17 +248,34 @@ trap_entry:
SREGx29, 29*REGBYTES(sp)
SREGx30, 30*REGBYTES(sp)
SREGx31, 31*REGBYTES(sp)
+#ifdef CONFIG_RISCV_SMODE
+   csrra0, scause
+   csrra1, sepc
+#else
csrra0, mcause
csrra1, mepc
+#endif
mv  a2, sp
jal handle_trap
+#ifdef CONFIG_RISCV_SMODE
+   csrwsepc, a0
+#else
csrwmepc, a0
+#endif
 
+#ifdef CONFIG_RISCV_SMODE
+/*
+ * Remain in S-mode after sret
+ */
+   li  t0, SSTATUS_SPP
+   csrssstatus, t0
+#else
 /*
  * Remain in M-mode after mret
  */
li  t0, MSTATUS_MPP
csrsmstatus, t0
+#endif
LREGx1, 1*REGBYTES(sp)
LREGx2, 2*REGBYTES(sp)
LREGx3, 3*REGBYTES(sp)
@@ -279,4 +308,8 @@ trap_entry:
LREGx30, 30*REGBYTES(sp)
LREGx31, 31*REGBYTES(sp)
addisp, sp, 32*REGBYTES
+#ifdef CONFIG_RISCV_SMODE
+   sret
+#else
mret
+#endif
diff --git a/arch/riscv/include/asm/encoding.h 
b/arch/riscv/include/asm/encoding.h
index 9ea50ce640..153f5af2ff 100644
--- a/arch/riscv/include/asm/encoding.h
+++ b/arch/riscv/include/asm/encoding.h
@@ -143,6 +143,8 @@
 # define MCAUSE_CAUSE MCAUSE32_CAUSE
 #endif
 
+#define SCAUSE_INT MCAUSE_INT
+
 #define RISCV_PGSHIFT 12
 #define RISCV_PGSIZE BIT(RISCV_PGSHIFT)
 
diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index 903a1c4cd5..8793f233d0 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -34,17 +34,35 @@ int disable_interrupts(void)
return 0;
 }
 
-ulong handle_trap(ulong mcause, ulong epc, struct pt_regs *regs)
+ulong handle_trap(ulong cause, ulong epc, struct pt_regs *regs)
 {
-   ulong is_int;
+   ulong is_irq, irq;
 
-   is_int = (mcause & MCAUSE_INT);
-   if ((is_int) && ((mcause & MCAUSE_CAUSE)  == IRQ_M_EXT))
-   external_interrupt(0);  /* handle_m_ext_interrupt */
-   else if ((is_int) && ((mcause & MCAUSE_CAUSE)  == IRQ_M_TIMER))
-   timer_interrupt(0); /* handle_m_timer_interrupt */
-   else
-   _exit_trap(mcause, epc, regs);
+#ifdef CONFIG_RISCV_SMODE
+   is_irq = (cause & SCAUSE_INT);
+   irq = (cause & ~SCAUSE_INT);
+#else
+   is_irq = (cause & MCAUSE_INT);
+   irq = (cause & ~MCAUSE_INT);
+#endif
+
+   if (is_irq) {
+   switch (irq) {
+   case IRQ_M_EXT:
+   case IRQ_S_EXT:
+   external_interrupt(0);  /* handle external interrupt */
+   break;
+   case IRQ_M_TIMER:
+   case IRQ_S_TIMER:
+   timer_interrupt(0); /* handle timer interrupt */
+   break;
+   default:
+   _exit_trap(cause, epc, regs);
+   break;
+   };
+   } else {
+   _exit_trap(cause, epc, regs);
+   }
 
return epc;
 }
-- 
2.17.1

__

[U-Boot] [PATCH v4 0/3] RISC-V S-mode support

[Anup Patel]

This patchset allows us runing u-boot in S-mode which is
useful on platforms where M-mode runtime firmware is an
independent firmware and u-boot is used as last stage OS
bootloader.

The patchset based upon git://git.denx.de/u-boot-riscv.git
and is tested on QEMU in both M-mode and S-mode.

For S-mode testing, we have used u-boot.bin as payload of
latest BBL (at commit 6ebd0f2a46255d0c76dad3c05b16c1d154795d26)
applied with following changes:

diff --git a/machine/emulation.c b/machine/emulation.c
index 132e977..def75e1 100644
--- a/machine/emulation.c
+++ b/machine/emulation.c
@@ -162,6 +162,12 @@ static inline int emulate_read_csr(int num, uintptr_t 
mstatus, uintptr_t* result
 
   switch (num)
   {
+case CSR_MISA:
+  *result = read_csr(misa);
+  return 0;
+case CSR_MHARTID:
+  *result = read_csr(mhartid);
+  return 0;
 case CSR_CYCLE:
   if (!((counteren >> (CSR_CYCLE - CSR_CYCLE)) & 1))
 return -1;

Changes since v3:
 - Replaced 'u-boot' with 'U-Boot' in commit message
 - Dropped 'an' in RISCV_SMODE kconfig option help message
 - Added appropriate #ifdef in arch/riscv/lib/interrupts.c

Changes since v2:
 - Dropped 'default n" from RISCV_SMODE kconfig option
 - Replaced '-smode_' in defconfig names with '_smode_'

Changes since v1:
 - Rebased upon latest git://git.denx.de/u-boot-riscv.git
 - Add details in cover letter for running u-boot in S-mode
   using BBL

Anup Patel (3):
  riscv: Add kconfig option to run U-Boot in S-mode
  riscv: qemu: Use different SYS_TEXT_BASE for S-mode
  riscv: Add S-mode defconfigs for QEMU virt machine

 arch/riscv/Kconfig |  5 
 arch/riscv/cpu/start.S | 33 +++
 arch/riscv/include/asm/encoding.h  |  2 ++
 arch/riscv/lib/interrupts.c| 36 +++---
 board/emulation/qemu-riscv/Kconfig |  3 ++-
 board/emulation/qemu-riscv/MAINTAINERS |  2 ++
 configs/qemu-riscv32_smode_defconfig   | 10 +++
 configs/qemu-riscv64_smode_defconfig   | 11 
 8 files changed, 92 insertions(+), 10 deletions(-)
 create mode 100644 configs/qemu-riscv32_smode_defconfig
 create mode 100644 configs/qemu-riscv64_smode_defconfig

-- 
2.17.1

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

Re: [U-Boot] [PATCH v3 1/3] riscv: Add kconfig option to run u-boot in S-mode

[Anup Patel]

On Thu, Nov 22, 2018 at 3:41 AM Auer, Lukas
 wrote:
>
> Hi Anup,
>
> On Wed, 2018-11-21 at 13:47 +, Auer, Lukas wrote:
> > Hi Anup,
> >
> > On Wed, 2018-11-21 at 09:11 +0530, Anup Patel wrote:
> > > This patch adds kconfig option RISCV_SMODE to run u-boot in
> >
> > nit: U-Boot (also in the first line of the commit message)
> >
> > > S-mode. When this opition is enabled we use s CSRs instead
> > > of m CSRs.
> > >
>
> Can you also modify arch/riscv/lib/interrupts.c to test for the
> supervisor instead of the machine timer and external interrupts when
> CONFIG_RISCV_SMODE is set?
>

Sure, will do.

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

Re: [U-Boot] [PATCH v3 1/3] riscv: Add kconfig option to run u-boot in S-mode

[Anup Patel]

On Wed, Nov 21, 2018 at 9:58 PM Palmer Dabbelt  wrote:
>
> On Tue, 20 Nov 2018 19:41:10 PST (-0800), a...@brainfault.org wrote:
> > This patch adds kconfig option RISCV_SMODE to run u-boot in
> > S-mode. When this opition is enabled we use s CSRs instead
> > of m CSRs.
> >
> > It is important to note that there is no equivalent S-mode CSR
> > for misa and mhartid CSRs so we expect M-mode runtime firmware
> > (BBL or equivalent) to emulate misa and mhartid CSR read.
> >
> > In-future, we will have more patches to avoid accessing misa and
> > mhartid CSRs from S-mode.
>
> Ya, I don't like this.  Our current boot protocol puts mhartid in a1 upon
> entering the supervisor, and allows the detection of misa via a device tree
> pointer provided in a0.
>
> As long as everyone agrees this isn't what we're actually looking for then I'm
> fine with the patch, I just don't want to end up requiring this "M mode
> emulates some CSRs for S mode" interface.  Since we don't have an actual
> platform spec we've got to be careful to avoid a bunch of defacto interfaces
> that we'll need to support later.

Yes, it's a temporary thingy to emulate misa and mhartid in BBL.

Eventually, U-Boot will be fixed to avoid direct access of misa and mhartid.

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

Re: [U-Boot] [PATCH] arm: socfpga: crc-protect SPL on warm boot

[Marek Vasut]

On 11/21/2018 10:07 PM, Simon Goldschmidt wrote:
> On 21.11.2018 15:08, Marek Vasut wrote:
>> On 11/21/2018 06:09 AM, Simon Goldschmidt wrote:
>>>
>>> Am Mi., 21. Nov. 2018, 00:11 hat Marek Vasut >> > geschrieben:
>>>
>>>  On 11/20/2018 09:54 PM, Simon Goldschmidt wrote:
>>>  > On 20.11.2018 20:33, Marek Vasut wrote:
>>>  >> On 11/20/2018 08:22 PM, Simon Goldschmidt wrote:
>>>  >>> From: Simon Goldschmidt >>  >
>>>  >>>
>>>  >>> On socfpga gen5, a warm reboot from Linux currently triggers
>>> a warm
>>>  >>> reset via reset manager ctrl register.
>>>  >>>
>>>  >>> This currently leads to the boot rom just jumping to onchip ram
>>>  >>> executing the SPL that is supposed to still be there. This is
>>>  >>> because we tell the boot rom to do so by writing a magin value
>>>  >>> the warmramgrp_enable register in arch_early_init_r().
>>>  >>>
>>>  >>> However, this can lead to lockups on reboot if this register
>>> still
>>>  >>> contains its magic value but the SPL is not intact any more
>>> (e.g.
>>>  >>> partly overwritten onchip ram).
>>>  >>>
>>>  >>> To fis this, store a crc calculated over SPL in sysmgr
>>> registers to
>>>  >>> let the boot rom check it on next warm boot. If the crc is
>>> still
>>>  >>> correct, SPL can be executd from onchip ram. If the crc
>>> fails, SPL
>>>  >>> is loaded from original boot source.
>>>  >>>
>>>  >>> The crc that is written to the warmramgrp_crc register is
>>> the crc
>>>  >>> found in the SPL sfp image but with one addiional u32 added.
>>> For
>>>  >>> this, we need to add a function to calculate the updated
>>> crc. This
>>>  >>> is done as a bitwise calculation to keep the code increase
>>> small.
>>>  >>>
>>>  >>> This whole patch added 96 bytes to .text for SPL for
>>>  >>> socfpga_socrates_defconfig.
>>>  >>>
>>>  >>> Signed-off-by: Simon Goldschmidt
>>>  >>  >
>>>  >>> ---
>>>  >>>
>>>  >>>   arch/arm/mach-socfpga/misc_gen5.c |  9 
>>>  >>>   arch/arm/mach-socfpga/spl_gen5.c  | 73
>>>  +++
>>>  >>>   2 files changed, 73 insertions(+), 9 deletions(-)
>>>  >>>
>>>  >>> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
>>>  >>> b/arch/arm/mach-socfpga/misc_gen5.c
>>>  >>> index 5fa40937c4..492a3082de 100644
>>>  >>> --- a/arch/arm/mach-socfpga/misc_gen5.c
>>>  >>> +++ b/arch/arm/mach-socfpga/misc_gen5.c
>>>  >>> @@ -204,15 +204,6 @@ int arch_early_init_r(void)
>>>  >>>   {
>>>  >>>   int i;
>>>  >>>   -    /*
>>>  >>> - * Write magic value into magic register to unlock
>>> support for
>>>  >>> - * issuing warm reset. The ancient kernel code expects
>>> this
>>>  >>> - * value to be written into the register by the
>>> bootloader, so
>>>  >>> - * to support that old code, we write it here instead
>>> of in the
>>>  >>> - * reset_cpu() function just before resetting the CPU.
>>>  >>> - */
>>>  >>> -    writel(0xae9efebc,
>>> &sysmgr_regs->romcodegrp_warmramgrp_enable);
>>>  >>> -
>>>  >>>   for (i = 0; i < 8; i++)    /* Cache initial SW setting
>>> regs */
>>>  >>>   iswgrp_handoff[i] =
>>>  readl(&sysmgr_regs->iswgrp_handoff[i]);
>>>  >>>   diff --git a/arch/arm/mach-socfpga/spl_gen5.c
>>>  >>> b/arch/arm/mach-socfpga/spl_gen5.c
>>>  >>> index ccdc661d05..3416e19f79 100644
>>>  >>> --- a/arch/arm/mach-socfpga/spl_gen5.c
>>>  >>> +++ b/arch/arm/mach-socfpga/spl_gen5.c
>>>  >>> @@ -63,6 +63,76 @@ u32 spl_boot_mode(const u32 boot_device)
>>>  >>>   }
>>>  >>>   #endif
>>>  >>>   +/* This function calculates the CRC32 used by the Cyclone
>>> 5 SoC
>>>  >>> Boot Rom */
>>>  >>> +static u32 socfpga_boot_crc(u32 crc, const unsigned char
>>> *ptr, u32
>>>  >>> length)
>>>  >>> +{
>>>  >>> +    uint i;
>>>  >>> +    u8 bit;
>>>  >>> +    unsigned char data;
>>>  >>> +    const u32 poly = 0x02608edb;
>>>  >>> +
>>>  >>> +    for (; length > 0; length--, ptr++) {
>>>  >>> +    data = *ptr;
>>>  >>> +    for (i = 0; i < 8; i++) {
>>>  >>> +    if (data & 0x80)
>>>  >>> +    bit = 1;
>>>  >>> +    else
>>>  >>> +    bit = 0;
>>>  >>> +
>>>  >>> +    data = data << 1;
>>>  >>> +    if (crc & 0x8000)
>>>  >>> +    bit = 1 - bit;
>>>  >>> +
>>>  >>> +    if (bit) {
>>>  >>> +    crc ^= poly;
>>>  >>> +    crc = crc << 1;
>>>  >>> +    crc |= 1;
>>>  >>> +    } else {
>>>  >>> +    crc = crc << 1;
>>>  >>> +    }
>>>  >>> +    }
>>>  >>> +    }
>>>  >>> +    r

Re: [U-Boot] [PATCH 70/93] arm: Remove ap121 board

[Tom Rini]

On Thu, Nov 22, 2018 at 01:47:24AM +0100, Daniel Schwierzeck wrote:
> Hi Simon,
> 
> Am 19.11.18 um 16:53 schrieb Simon Glass:
> > This board has not been converted to CONFIG_DM_BLK by the deadline.
> > Remove it.
> > 
> > Signed-off-by: Simon Glass 
> > ---
> > 
> >  arch/mips/mach-ath79/Kconfig |  1 -
> >  board/qca/ap121/Kconfig  | 27 
> >  board/qca/ap121/MAINTAINERS  |  6 
> >  board/qca/ap121/Makefile |  3 --
> >  board/qca/ap121/ap121.c  | 46 ---
> >  configs/ap121_defconfig  | 60 
> >  include/configs/ap121.h  | 46 ---
> >  7 files changed, 189 deletions(-)
> >  delete mode 100644 board/qca/ap121/Kconfig
> >  delete mode 100644 board/qca/ap121/MAINTAINERS
> >  delete mode 100644 board/qca/ap121/Makefile
> >  delete mode 100644 board/qca/ap121/ap121.c
> >  delete mode 100644 configs/ap121_defconfig
> >  delete mode 100644 include/configs/ap121.h
> 
> your approach with simply forcing CONFIG_BLK is flawed. This board
> doesn't use any block devices. If I enable CONFIG_BLK manually via
> menuconfig, I get this link error:
> 
>   LD  u-boot
> drivers/built-in.o: In function `blk_post_probe':
> drivers/block/blk-uclass.c:(.text.blk_post_probe+0x10): undefined
> reference to `part_init'
> make: *** [Makefile:1381: u-boot] Error 1
> 
> But part_init() is defined in disk/part.c and guarded by
> CONFIG_HAVE_BLOCK_DEVICE. If I enable that too, the board will build fine.
> 
> So the actual bug is that CONFIG_BLK doesn't do a SELECT PARTITIONS or
> that drivers/block/blk-uclass.c doesn't guard the call to part_init()
> with CONFIG_HAVE_BLOCK_DEVICE. Maybe you should fix that and then try
> again. I guess you will have much less failing boards.

There's a few different parts to the problem of switching more globally
to BLK being enabled.  And yes, you're right, we need to do something to
ensure that disk/part.o is linked in or drivers/block/blk-uclass.c only
calls part_init() in fewer cases.  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 70/93] arm: Remove ap121 board

[Daniel Schwierzeck]

Hi Simon,

Am 19.11.18 um 16:53 schrieb Simon Glass:
> This board has not been converted to CONFIG_DM_BLK by the deadline.
> Remove it.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  arch/mips/mach-ath79/Kconfig |  1 -
>  board/qca/ap121/Kconfig  | 27 
>  board/qca/ap121/MAINTAINERS  |  6 
>  board/qca/ap121/Makefile |  3 --
>  board/qca/ap121/ap121.c  | 46 ---
>  configs/ap121_defconfig  | 60 
>  include/configs/ap121.h  | 46 ---
>  7 files changed, 189 deletions(-)
>  delete mode 100644 board/qca/ap121/Kconfig
>  delete mode 100644 board/qca/ap121/MAINTAINERS
>  delete mode 100644 board/qca/ap121/Makefile
>  delete mode 100644 board/qca/ap121/ap121.c
>  delete mode 100644 configs/ap121_defconfig
>  delete mode 100644 include/configs/ap121.h

your approach with simply forcing CONFIG_BLK is flawed. This board
doesn't use any block devices. If I enable CONFIG_BLK manually via
menuconfig, I get this link error:

  LD  u-boot
drivers/built-in.o: In function `blk_post_probe':
drivers/block/blk-uclass.c:(.text.blk_post_probe+0x10): undefined
reference to `part_init'
make: *** [Makefile:1381: u-boot] Error 1

But part_init() is defined in disk/part.c and guarded by
CONFIG_HAVE_BLOCK_DEVICE. If I enable that too, the board will build fine.

So the actual bug is that CONFIG_BLK doesn't do a SELECT PARTITIONS or
that drivers/block/blk-uclass.c doesn't guard the call to part_init()
with CONFIG_HAVE_BLOCK_DEVICE. Maybe you should fix that and then try
again. I guess you will have much less failing boards.


-- 
- Daniel



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

[U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

The following changes since commit a3e1653ddeb02f39481eba572275016171e9670c:

  Merge git://git.denx.de/u-boot-marvell (2018-11-20 12:39:16 -0500)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/pull-tg18

for you to fetch changes up to a58986ca8b53d8c7a441397082f84edc7f47d19f:

  sf: Add a method to obtain the block-protect setting (2018-11-20
19:14:22 -0700)

https://travis-ci.org/sglass68/u-boot/builds/457752510


Various minor sandbox improvements
Better buildman warning handling
Misc other things


Baruch Siach (1):
  fdt: restore board_fdt_blob_setup() declaration

Heinrich Schuchardt (3):
  sandbox: remove stray DEBUG
  sandbox: README: setting environment variables
  sandbox: README: use setenv ethrotate no

Hiroyuki Yokoyama (1):
  cmd: fdt: Fix fdt address information after the movement

Hou Zhiqiang (1):
  dm/pci: Change the first CFG read to Vendor ID in enumeration

Liviu Dudau (1):
  dm: core: Widen the dump tree to show more of the driver's name.

Marek Vasut (1):
  fdt: Fix uncompress_blob() for U-Boot proper

Simon Glass (24):
  buildman: Only print toolchain probing with -v
  buildman: Detect dtc warnings
  buildman: Rename the good, better, worse variables
  buildman: Show boards with warning with w+
  cros_ec: Use uint instead of u8 for parameters
  cros_ec: Add error logging on a few commands
  cros_ec: Fail if we cannot determine the flash burst size
  cros_ec: Align uclass data to a cache boundary
  cros_ec: Add new features for events and power
  sandbox: tpm: Allow debugging of data packages
  sandbox: log: Add a category for sandbox
  sandbox: Add a function to read a host file
  sandbox: cros_ec: exynos: Drop use of cros_ec_get_error()
  sandbox: Update some drivers to work in SPL/TPL
  spl: Support bootstage, log, hash and early malloc in TPL
  spl: lz4: Allow use of lz4 compression in SPL
  binman: Add a way to enable debugging from the build
  binman: Drop an unnecessary comma in blob handling
  binman: Set the pathname correctly for ELF files
  video: Update video_set_default_colors() to support invert
  string: Include the config header
  misc: Update read() and write() methods to return bytes xfered
  test: sf: Add a simple SPI flash test
  sf: Add a method to obtain the block-protect setting

Simon Goldschmidt (1):
  dm: spi: prevent setting a speed of 0 Hz

 Makefile  |   6 +-
 arch/arm/mach-stm32mp/cpu.c   |   4 +-
 arch/sandbox/cpu/cpu.c|   8 +-
 arch/sandbox/cpu/os.c |  44 ++-
 arch/sandbox/dts/sandbox.dts  |  15 +++
 arch/sandbox/include/asm/test.h   |   8 ++
 board/samsung/common/board.c  |  10 +-
 board/sandbox/README.sandbox  |  20 +--
 board/sandbox/sandbox.c   |   9 +-
 cmd/fdt.c |   2 +-
 common/Kconfig|  35 ++
 common/Makefile   |  10 +-
 common/cros_ec.c  |  12 --
 drivers/clk/clk_vexpress_osc.c|   4 +-
 drivers/core/dump.c   |   8 +-
 drivers/misc/altera_sysid.c   |   2 +-
 drivers/misc/cros_ec.c| 370
---
 drivers/misc/cros_ec_sandbox.c|   2 +-
 drivers/misc/misc_sandbox.c   |   4 +-
 drivers/misc/rockchip-efuse.c |   2 +-
 drivers/misc/stm32mp_fuse.c   |  12 ++
 drivers/mtd/spi/sandbox.c |  10 ++
 drivers/mtd/spi/sf-uclass.c   |   9 ++
 drivers/mtd/spi/sf_internal.h |   3 +
 drivers/mtd/spi/sf_probe.c|   8 ++
 drivers/mtd/spi/spi_flash.c   |  12 ++
 drivers/pci/pci-uclass.c  |  11 +-
 drivers/spi/spi-uclass.c  |  15 ++-
 drivers/tpm/tpm_tis_sandbox.c |   6 +
 drivers/video/vidconsole-uclass.c |   2 +-
 drivers/video/video-uclass.c  |  27 ++--
 include/cros_ec.h |  89 +
 include/fdtdec.h  |   1 +
 include/log.h |   1 +
 include/misc.h|   8 +-
 include/os.h  |  14 +++
 include/spi_flash.h   |  27 
 include/video.h   |   5 +-
 lib/Kconfig   |   8 ++
 lib/Makefile  |   2 +-
 lib/fdtdec.c  |   3 +-
 lib/string.c  |   1 +
 test/dm/misc.c|   6 +-
 test/dm/sf.c  |  55 -
 test/py/tests/test_bind.py|  28 ++---
 tools/binman/README   |   6 +
 tools/binman/etype/blob.py|   2 +-
 tools/binman/etype/u_boot_elf.py  |   5 +-
 tools/buildman/builder.py |  41 +++---
 tools/buildman/cmdline.py |   2 +-
 tools/buildman/control.py |   2 +-
 tools/buildman/test.py

Re: [U-Boot] [PATCH v2] imx: hab: extend hab_auth_img to calculate ivt_offset

[Breno Matheus Lima]

Hi Parthiban,

Em qua, 21 de nov de 2018 às 18:47, Parthiban Nallathambi  
escreveu:
>
> Hi Breno,
>
> On 11/21/18 7:42 PM, Breno Matheus Lima wrote:
> > Hi Parthiban,
> >
> > Em qua, 21 de nov de 2018 às 15:52, Parthiban Nallathambi  
> > escreveu:
> >>
> >> Hi Breno,
> >>
> >> On 11/21/18 5:45 PM, Breno Matheus Lima wrote:
> >>> Hi Parthiban,
> >>>
> >>> Em qua, 21 de nov de 2018 às 11:50, Parthiban Nallathambi  
> >>> escreveu:
> 
>  Current implementation of hab_auth_img command needs ivt_offset to
>  authenticate the image. But ivt header is placed at the end of image
>  date after padding.
> 
>  This leaves the usage of hab_auth_img command to fixed size or static
>  offset for ivt header. New function "get_image_ivt_offset" is introduced
>  to find the ivt offset during runtime. The case conditional check in this
>  function is same as boot_get_kernel in common/bootm.c
> 
>  With this variable length image e.g. FIT image with any random size can
>  have IVT at the end and ivt_offset option can be left optional
> 
>  Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script
> 
>  Signed-off-by: Parthiban Nallathambi 
>  ---
> 
>  Notes:
>   Changelog in v2:
>   - Finding IVT offset doesn't need length. Removed the
>   length argument from get_image_ivt_offset
> 
>    arch/arm/mach-imx/hab.c | 29 +++--
>    1 file changed, 27 insertions(+), 2 deletions(-)
> 
>  diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
>  index b88acd13da..dbfd692fa3 100644
>  --- a/arch/arm/mach-imx/hab.c
>  +++ b/arch/arm/mach-imx/hab.c
>  @@ -6,6 +6,8 @@
>    #include 
>    #include 
>    #include 
>  +#include 
>  +#include 
>    #include 
>    #include 
>    #include 
>  @@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int 
>  flag, int argc,
>   return 0;
>    }
> 
>  +static ulong get_image_ivt_offset(ulong img_addr)
>  +{
>  +   const void *buf;
>  +
>  +   buf = map_sysmem(img_addr, 0);
>  +   switch (genimg_get_format(buf)) {
>  +#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
>  +   case IMAGE_FORMAT_LEGACY:
>  +   return (image_get_image_size((image_header_t *)img_addr)
>  +   + 0x1000 - 1)  & ~(0x1000 - 1);
>  +#endif
>  +#if IMAGE_ENABLE_FIT
>  +   case IMAGE_FORMAT_FIT:
>  +   return (fit_get_size(buf) + 0x1000 - 1)  & ~(0x1000 - 1);
>  +#endif
>  +   default:
>  +   return 0;
>  +   }
>  +}
> >>>
> >>>
> >>> Do you have more details about the image header I should use here?
> >>
> >> Is the image signed using CST or similar tool? Is so, the signature data
> >> (HAB data: CSF, Certs and signature) pads at the end of the kernel
> >> image.
> >
> > Yes, my Kernel image contains an IVT and is signed with CST. The image
> > layout looks like link below:
> > https://pastebin.com/5qEt7ETa
> >
> >>
> >>>
> >>> I'm trying to get the IVT offset for my Kernel image based on NXP
> >>> 4.9.11_2.0.0_GA Linux release loaded at 0x8080:
> >>>
> >>> => fatload mmc 0:1 0x8080 zImage
> >>> => hab_auth_img 0x8080 
> >>
> >> Length for hab_auth_img is still mandatory. Length hear means the file
> >> size or total length of the image, this is required for the HAB API to
> >> authenticate (HAB_RVT_AUTHENTICATE_IMAGE).
> >
> > Oh ok, I understood the scenario right now.
> >
> >>From my first overview I thought we would add IVT_SIZE + CSF_PAD_SIZE
> > in ivt_offset to calculate the image length, similar approach we have
> > in spl.c:
> > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-imx/spl.c;h=a20b30d154d788e4ebd4e22e9a6568a4f24c057e;hb=HEAD#l226
> >
> > In this case only load addr would be necessary.
> >
> >>
> >>>
> >>> The zImage size in Header looks correct (0x00726690), but
> >>> get_image_ivt_offset() is returning 0x0
> >>
> >> Looks like IVT offset is not found in the image.
> >>
> >>>
> >>> $ hexdump zImage | head
> >>> 000  e1a0  e1a0  e1a0  e1a0
> >>> *
> >>> 020 0003 ea00 2818 016f   6690 0072
> >>> 030 0201 0403 9000 e10f 04f8 eb00 7001 e1a0
> >>> 040 8002 e1a0 2000 e10f 0003 e312 0001 1a00
> >>>
> >>> Seems that genimg_get_format() is returning 0x0.
> >>
> >> Image is not signed?
> >
> > No, my zImage is signed.
> >
> >>
> >>>
> >>> Any ideias if I'm missing something?
> >>>
>  +
>    static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
>    char * const argv[])
>    {
>   ulong   addr, length, ivt_offset;
>   int rcode = 0;
> 
>  -   if (argc < 4)
>  +   if (argc < 3)
> >>>
> >>> I think we can also change here to argc < 2, the function
> >>> ge

Re: [U-Boot] [PATCH v3] riscv: cache: Implement i/dcache [status, enable, disable]

[Auer, Lukas]

Hi Rick,

On Wed, 2018-11-07 at 09:54 +0800, Andes wrote:
> From: Rick Chen 
> 
> AndeStar RISC-V(V5) provide mcache_ctl register which
> can configure I/D cache as enabled or disabled.
> 
> This CSR will be encapsulated by CONFIG_RISCV_NDS.
> If you want to configure cache on AndeStar V5
> AE350 platform. YOu can enable [*] AndeStar V5 ISA support
> by make menuconfig.
> 
> This approach also provide the expansion when the
> vender specific features are going to join in.
> 
> Signed-off-by: Rick Chen 
> Cc: Greentime Hu 
> ---

The commit message does not fully describe all changes of this patch.
It would be helpful to split it into separate patches.
Having only one change in each patch makes debugging later easier,
because you don't have to manually undo parts of a patch to find out
what is going on.

> 
> Changes in v3
> 
> Bin suggested:
>  1. Move RISCV_NDS to arch/riscv/cpu/ax25/Kconfig
>  
> Lukas suggested:
>  1. Add CONFIG_SYS_ICACHE_OFF in i/dcache_disable()
>  2. Remove duplicate declaration in arch/riscv/include/asm/cache.h
>  3. Add s space after "volatile" and ":::" to match the style.
>  4. Implement flush_dcache_range() and flush_cache() in
> arch/riscv/lib/cache.c
> 
>  arch/riscv/Kconfig |  6 +++
>  arch/riscv/cpu/ax25/Kconfig|  7 
>  arch/riscv/cpu/ax25/Makefile   |  1 +
>  arch/riscv/cpu/ax25/cache.c| 95
> ++
>  arch/riscv/cpu/ax25/cpu.c  |  4 ++
>  arch/riscv/cpu/qemu/cpu.c  |  2 +-
>  arch/riscv/cpu/start.S |  6 +++
>  arch/riscv/include/asm/cache.h |  3 ++
>  arch/riscv/lib/cache.c | 32 ++
>  9 files changed, 146 insertions(+), 10 deletions(-)
>  create mode 100644 arch/riscv/cpu/ax25/Kconfig
>  create mode 100644 arch/riscv/cpu/ax25/cache.c
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 371921b..6a86e9c 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -16,9 +16,15 @@ config TARGET_QEMU_VIRT
>  
>  endchoice
>  
> +# board-specific options below
>  source "board/AndesTech/ax25-ae350/Kconfig"
>  source "board/emulation/qemu-riscv/Kconfig"
>  
> +# platform-specific options below
> +source "arch/riscv/cpu/ax25/Kconfig"
> +
> +# architecture-specific options below
> +
>  choice
>   prompt "Base ISA"
>   default ARCH_RV32I
> diff --git a/arch/riscv/cpu/ax25/Kconfig
> b/arch/riscv/cpu/ax25/Kconfig
> new file mode 100644
> index 000..6c7022f
> --- /dev/null
> +++ b/arch/riscv/cpu/ax25/Kconfig
> @@ -0,0 +1,7 @@
> +config RISCV_NDS
> + bool "AndeStar V5 ISA support"
> + default n
> + help
> + Say Y here if you plan to run U-Boot on AndeStar v5
> + platforms and use some specific features which are
> + provided by Andes Technology AndeStar V5 Families.

I think it would make sense to add a "depends on TARGET_AX25_AE350" to
the RISCV_NDS config, so that it is not shown for other boards.

It would be great if we could enable cache support by default, to make
sure it is tested by Travis-CI. Some time ago, it was suggested on the
riscv-linux mailing list to use the CSR numbers instead of the names.
This way, the generic GCC compiler will not complain about the unknown
CSRs. I think, this would be a good idea. What do you think?

> diff --git a/arch/riscv/cpu/ax25/Makefile
> b/arch/riscv/cpu/ax25/Makefile
> index 2ab0342..318bacc 100644
> --- a/arch/riscv/cpu/ax25/Makefile
> +++ b/arch/riscv/cpu/ax25/Makefile
> @@ -4,3 +4,4 @@
>  # Rick Chen, Andes Technology Corporation 
>  
>  obj-y:= cpu.o
> +obj-y+= cache.o
> diff --git a/arch/riscv/cpu/ax25/cache.c
> b/arch/riscv/cpu/ax25/cache.c
> new file mode 100644
> index 000..6600ac2
> --- /dev/null
> +++ b/arch/riscv/cpu/ax25/cache.c
> @@ -0,0 +1,95 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2017 Andes Technology Corporation
> + * Rick Chen, Andes Technology Corporation 
> + */
> +
> +#include 
> +
> +void icache_enable(void)
> +{
> +#ifndef CONFIG_SYS_ICACHE_OFF
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "ori t0, t1, 0x1\n\t"
> + "csrw mcache_ctl, t0\n\t"
> + );
> +#endif
> +#endif
> +}
> +
> +void icache_disable(void)
> +{
> +#ifndef CONFIG_SYS_ICACHE_OFF
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "fence.i\n\t"
> + "csrr t1, mcache_ctl\n\t"
> + "andi t0, t1, ~0x1\n\t"
> + "csrw mcache_ctl, t0\n\t"
> + );
> +#endif
> +#endif
> +}
> +
> +void dcache_enable(void)
> +{
> +#ifndef CONFIG_SYS_DCACHE_OFF
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "csrr t1, mcache_ctl\n\t"
> + "ori t0, t1, 0x2\n\t"
> + "csrw mcache_ctl, t0\n\t"
> + );
> +#endif
> +#endif
> +}
> +
> +void dcache_disable(void)
> +{
> +#ifndef CONFIG_SYS_DCACHE_OFF
> +#ifdef CONFIG_RISCV_NDS
> + asm volatile (
> + "fence\n\t"
> + "csrr t1

[U-Boot] [PATCH v1 3/3] rtc: m41t62: Convert the RTC driver to support the driver model (DM)

[Lukasz Majewski]

After this change the m41t62.c can be used with RTC subsystem (i.e. date
command) which uses device model (DM).

Signed-off-by: Lukasz Majewski 

---

Changes in v1:
- New

 drivers/rtc/m41t62.c | 75 +---
 1 file changed, 72 insertions(+), 3 deletions(-)

diff --git a/drivers/rtc/m41t62.c b/drivers/rtc/m41t62.c
index cc230e2b78..2dcc1f2a63 100644
--- a/drivers/rtc/m41t62.c
+++ b/drivers/rtc/m41t62.c
@@ -1,5 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
+ * (C) Copyright 2018
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de.
+ *
  * (C) Copyright 2008
  * Stefan Roese, DENX Software Engineering, s...@denx.de.
  *
@@ -15,6 +18,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -49,11 +53,23 @@
 
 #define M41T80_ALHOUR_HT   (1 << 6)/* HT: Halt Update Bit */
 
+#ifdef CONFIG_DM_RTC
+static int m41t62_rtc_get(struct udevice *dev, struct rtc_time *tm)
+{
+#else
 int rtc_get(struct rtc_time *tm)
 {
+#endif /* CONFIG_DM_RTC */
u8 buf[M41T62_DATETIME_REG_SIZE];
 
+#ifdef CONFIG_DM_RTC
+   int ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
+
+   if (ret)
+   return ret;
+#else
i2c_read(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf, M41T62_DATETIME_REG_SIZE);
+#endif /* CONFIG_DM_RTC */
 
debug("%s: raw read data - sec=%02x, min=%02x, hr=%02x, "
  "mday=%02x, mon=%02x, year=%02x, wday=%02x, y2k=%02x\n",
@@ -81,15 +97,28 @@ int rtc_get(struct rtc_time *tm)
return 0;
 }
 
+#ifdef CONFIG_DM_RTC
+static int m41t62_rtc_set(struct udevice *dev, const struct rtc_time *tm)
+{
+#else
 int rtc_set(struct rtc_time *tm)
 {
+#endif /* CONFIG_DM_RTC */
u8 buf[M41T62_DATETIME_REG_SIZE];
+   int ret;
 
debug("Set DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
  tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_wday,
  tm->tm_hour, tm->tm_min, tm->tm_sec);
 
-   i2c_read(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf, M41T62_DATETIME_REG_SIZE);
+#ifdef CONFIG_DM_RTC
+   ret = dm_i2c_read(dev, 0, buf, sizeof(buf));
+#else
+   ret = i2c_read(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf,
+  M41T62_DATETIME_REG_SIZE);
+#endif /* CONFIG_DM_RTC */
+   if (ret)
+   return ret;
 
/* Merge time-data and register flags into buf[0..7] */
buf[M41T62_REG_SSEC] = 0;
@@ -108,8 +137,13 @@ int rtc_set(struct rtc_time *tm)
/* assume 20YY not 19YY */
buf[M41T62_REG_YEAR] = bin2bcd(tm->tm_year % 100);
 
-   if (i2c_write(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf,
- M41T62_DATETIME_REG_SIZE)) {
+#ifdef CONFIG_DM_RTC
+   ret = dm_i2c_write(dev, 0, buf, sizeof(buf));
+#else
+   ret = i2c_write(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf,
+   M41T62_DATETIME_REG_SIZE);
+#endif /* CONFIG_DM_RTC */
+   if (ret) {
printf("I2C write failed in %s()\n", __func__);
return -1;
}
@@ -117,15 +151,50 @@ int rtc_set(struct rtc_time *tm)
return 0;
 }
 
+#ifdef CONFIG_DM_RTC
+static int m41t62_rtc_reset(struct udevice *dev)
+{
+#else
 void rtc_reset(void)
 {
+#endif /* CONFIG_DM_RTC */
u8 val;
 
/*
 * M41T82: Make sure HT (Halt Update) bit is cleared.
 * This bit is 0 in M41T62 so its save to clear it always.
 */
+#ifdef CONFIG_DM_RTC
+   int ret = dm_i2c_read(dev, M41T62_REG_ALARM_HOUR, &val, sizeof(val));
+
+   val &= ~M41T80_ALHOUR_HT;
+   ret |= dm_i2c_write(dev, M41T62_REG_ALARM_HOUR, &val, sizeof(val));
+
+   return ret;
+#else
i2c_read(CONFIG_SYS_I2C_RTC_ADDR, M41T62_REG_ALARM_HOUR, 1, &val, 1);
val &= ~M41T80_ALHOUR_HT;
i2c_write(CONFIG_SYS_I2C_RTC_ADDR, M41T62_REG_ALARM_HOUR, 1, &val, 1);
+#endif /* CONFIG_DM_RTC */
 }
+
+#ifdef CONFIG_DM_RTC
+static const struct rtc_ops m41t62_rtc_ops = {
+   .get = m41t62_rtc_get,
+   .set = m41t62_rtc_set,
+   .reset = m41t62_rtc_reset,
+};
+
+static const struct udevice_id m41t62_rtc_ids[] = {
+   { .compatible = "st,m41t62" },
+   { .compatible = "microcrystal,rv4162" },
+   { }
+};
+
+U_BOOT_DRIVER(rtc_m41t62) = {
+   .name   = "rtc-m41t62",
+   .id = UCLASS_RTC,
+   .of_match = m41t62_rtc_ids,
+   .ops= &m41t62_rtc_ops,
+};
+#endif /* CONFIG_DM_RTC */
-- 
2.11.0

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

[U-Boot] [PATCH v1 2/3] rtc: m41t62: Break i2c_write() arguments to fix checkpatch warning

[Lukasz Majewski]

No functional change for this commit.

Signed-off-by: Lukasz Majewski 
---

Changes in v1: None

 drivers/rtc/m41t62.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/m41t62.c b/drivers/rtc/m41t62.c
index 137438389d..cc230e2b78 100644
--- a/drivers/rtc/m41t62.c
+++ b/drivers/rtc/m41t62.c
@@ -108,7 +108,8 @@ int rtc_set(struct rtc_time *tm)
/* assume 20YY not 19YY */
buf[M41T62_REG_YEAR] = bin2bcd(tm->tm_year % 100);
 
-   if (i2c_write(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf, 
M41T62_DATETIME_REG_SIZE)) {
+   if (i2c_write(CONFIG_SYS_I2C_RTC_ADDR, 0, 1, buf,
+ M41T62_DATETIME_REG_SIZE)) {
printf("I2C write failed in %s()\n", __func__);
return -1;
}
-- 
2.11.0

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

[U-Boot] [PATCH v1 1/3] Kconfig: Migrate CONFIG_RTC_M41T62 define to Kconfig

[Lukasz Majewski]

This patch moves the RTC M41T62 config define to Kconfig.

Signed-off-by: Lukasz Majewski 
---

Changes in v1: None

 configs/bk4r1_defconfig  | 1 +
 configs/m53menlo_defconfig   | 1 +
 configs/pcm052_defconfig | 1 +
 configs/x600_defconfig   | 1 +
 drivers/rtc/Kconfig  | 6 ++
 include/configs/m53menlo.h   | 1 -
 include/configs/pcm052.h | 1 -
 include/configs/x600.h   | 1 -
 scripts/config_whitelist.txt | 1 -
 9 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig
index 03592f7d2a..32d36b4f49 100644
--- a/configs/bk4r1_defconfig
+++ b/configs/bk4r1_defconfig
@@ -69,6 +69,7 @@ CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_VYBRID=y
+CONFIG_RTC_M41T62=y
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
 CONFIG_SPI=y
diff --git a/configs/m53menlo_defconfig b/configs/m53menlo_defconfig
index 795f8a3ebc..dd7aed324f 100644
--- a/configs/m53menlo_defconfig
+++ b/configs/m53menlo_defconfig
@@ -49,6 +49,7 @@ CONFIG_NAND=y
 CONFIG_NAND_MXC=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_RTC_M41T62=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_HOST_ETHER=y
diff --git a/configs/pcm052_defconfig b/configs/pcm052_defconfig
index 0c8e31a9ec..e207df51a8 100644
--- a/configs/pcm052_defconfig
+++ b/configs/pcm052_defconfig
@@ -35,5 +35,6 @@ CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
 CONFIG_MII=y
+CONFIG_RTC_M41T62=y
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
diff --git a/configs/x600_defconfig b/configs/x600_defconfig
index c8f5f66232..a96f54c737 100644
--- a/configs/x600_defconfig
+++ b/configs/x600_defconfig
@@ -52,6 +52,7 @@ CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_MII=y
+CONFIG_RTC_M41T62=y
 CONFIG_CONS_INDEX=0
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index bcc01b135e..c27730798e 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -94,4 +94,10 @@ config RTC_MC146818
  clock with a wide array of features and 50 bytes of general-purpose,
  battery-backed RAM. The driver supports access to the clock and RAM.
 
+config RTC_M41T62
+   bool "Enable M41T62 driver"
+   help
+ Enable driver for ST's M41T62 compatible RTC devices (like RV-4162).
+ It is a serial (I2C) real-time clock (RTC) with alarm.
+
 endmenu
diff --git a/include/configs/m53menlo.h b/include/configs/m53menlo.h
index 94214b135d..3fca28da6b 100644
--- a/include/configs/m53menlo.h
+++ b/include/configs/m53menlo.h
@@ -110,7 +110,6 @@
  * RTC
  */
 #ifdef CONFIG_CMD_DATE
-#define CONFIG_RTC_M41T62
 #define CONFIG_SYS_I2C_RTC_ADDR0x68
 #define CONFIG_SYS_M41T11_BASE_YEAR2000
 #endif
diff --git a/include/configs/pcm052.h b/include/configs/pcm052.h
index 2f00be6240..c553fa629e 100644
--- a/include/configs/pcm052.h
+++ b/include/configs/pcm052.h
@@ -48,7 +48,6 @@
 #endif
 
 /* RTC (actually an RV-4162 but M41T62-compatible) */
-#define CONFIG_RTC_M41T62
 #define CONFIG_SYS_I2C_RTC_ADDR 0x68
 #define CONFIG_SYS_RTC_BUS_NUM 2
 
diff --git a/include/configs/x600.h b/include/configs/x600.h
index a6835ebbd5..639da8012c 100644
--- a/include/configs/x600.h
+++ b/include/configs/x600.h
@@ -75,7 +75,6 @@
 #define CONFIG_SYS_I2C_SLAVE   0x02
 #define CONFIG_I2C_CHIPADDRESS 0x50
 
-#define CONFIG_RTC_M41T62  1
 #define CONFIG_SYS_I2C_RTC_ADDR0x68
 
 /* FPGA config options */
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 0627024e71..6d5b8c35d9 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1664,7 +1664,6 @@ CONFIG_RTC_DS3231
 CONFIG_RTC_FTRTC010
 CONFIG_RTC_IMXDI
 CONFIG_RTC_M41T11
-CONFIG_RTC_M41T62
 CONFIG_RTC_MC13XXX
 CONFIG_RTC_MCFRRTC
 CONFIG_RTC_MCP79411
-- 
2.11.0

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

[U-Boot] [PATCH v1 0/3] rtc: m41t62: Convert the m41t62 driver to use driver model (DM)

[Lukasz Majewski]

This series enables using this driver with DM aware boards

Dependency:
"ARM: pinctrl: Provide pinctrl driver for Vybrid (vf610)"
https://patchwork.ozlabs.org/project/uboot/list/?series=76877


Changes in v1:
- New

Lukasz Majewski (3):
  Kconfig: Migrate CONFIG_RTC_M41T62 define to Kconfig
  rtc: m41t62: Break i2c_write() arguments to fix checkpatch warning
  rtc: m41t62: Convert the RTC driver to support the driver model (DM)

 configs/bk4r1_defconfig  |  1 +
 configs/m53menlo_defconfig   |  1 +
 configs/pcm052_defconfig |  1 +
 configs/x600_defconfig   |  1 +
 drivers/rtc/Kconfig  |  6 
 drivers/rtc/m41t62.c | 74 ++--
 include/configs/m53menlo.h   |  1 -
 include/configs/pcm052.h |  1 -
 include/configs/x600.h   |  1 -
 scripts/config_whitelist.txt |  1 -
 10 files changed, 82 insertions(+), 6 deletions(-)

-- 
2.11.0

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

[U-Boot] [PATCH v1] eeprom: Add device model based I2C support to eeprom command

[Lukasz Majewski]

After this change the 'eeprom' command can be used with DM aware boards.

Signed-off-by: Lukasz Majewski 

---

 cmd/eeprom.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/cmd/eeprom.c b/cmd/eeprom.c
index 4052cf494a..e88cb131a1 100644
--- a/cmd/eeprom.c
+++ b/cmd/eeprom.c
@@ -137,6 +137,23 @@ static int eeprom_rw_block(unsigned offset, uchar *addr, 
unsigned alen,
spi_write(addr, alen, buffer, len);
 #else  /* I2C */
 
+#if defined(CONFIG_DM_I2C) && defined(CONFIG_SYS_I2C_EEPROM_BUS)
+   struct udevice *dev;
+
+   ret = i2c_get_chip_for_busnum(CONFIG_SYS_I2C_EEPROM_BUS, addr[0],
+ alen - 1, &dev);
+   if (ret) {
+   printf("%s: Cannot find udev for a bus %d\n", __func__,
+  CONFIG_SYS_I2C_EEPROM_BUS);
+   return CMD_RET_FAILURE;
+   }
+
+   if (read)
+   ret = dm_i2c_read(dev, offset, buffer, len);
+   else
+   ret = dm_i2c_write(dev, offset, buffer, len);
+
+#else /* Non DM I2C support - will be removed */
 #if defined(CONFIG_SYS_I2C_EEPROM_BUS)
i2c_set_bus_num(CONFIG_SYS_I2C_EEPROM_BUS);
 #endif
@@ -145,10 +162,11 @@ static int eeprom_rw_block(unsigned offset, uchar *addr, 
unsigned alen,
ret = i2c_read(addr[0], offset, alen - 1, buffer, len);
else
ret = i2c_write(addr[0], offset, alen - 1, buffer, len);
-
-   if (ret)
-   ret = 1;
 #endif
+#endif /* CONFIG_DM_I2C && CONFIG_SYS_I2C_EEPROM_BUS */
+   if (ret)
+   ret = CMD_RET_FAILURE;
+
return ret;
 }
 
-- 
2.11.0

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

Re: [U-Boot] [PATCH v3 1/3] riscv: Add kconfig option to run u-boot in S-mode

[Auer, Lukas]

Hi Anup,

On Wed, 2018-11-21 at 13:47 +, Auer, Lukas wrote:
> Hi Anup,
> 
> On Wed, 2018-11-21 at 09:11 +0530, Anup Patel wrote:
> > This patch adds kconfig option RISCV_SMODE to run u-boot in
> 
> nit: U-Boot (also in the first line of the commit message)
> 
> > S-mode. When this opition is enabled we use s CSRs instead
> > of m CSRs.
> > 

Can you also modify arch/riscv/lib/interrupts.c to test for the
supervisor instead of the machine timer and external interrupts when
CONFIG_RISCV_SMODE is set?

Thanks,
Lukas

> > It is important to note that there is no equivalent S-mode CSR
> > for misa and mhartid CSRs so we expect M-mode runtime firmware
> > (BBL or equivalent) to emulate misa and mhartid CSR read.
> > 
> > In-future, we will have more patches to avoid accessing misa and
> > mhartid CSRs from S-mode.
> > 
> > Signed-off-by: Anup Patel 
> > Reviewed-by: Bin Meng 
> > Tested-by: Bin Meng 
> > ---
> >  arch/riscv/Kconfig |  5 +
> >  arch/riscv/cpu/start.S | 33 +
> >  2 files changed, 38 insertions(+)
> > 
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 3e0af55e71..8f2139ff60 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -55,6 +55,11 @@ config RISCV_ISA_C
> >  config RISCV_ISA_A
> > def_bool y
> >  
> > +config RISCV_SMODE
> > +   bool "Run in S-Mode"
> > +   help
> > + Enable this option to build an U-Boot for RISC-V S-Mode
> 
> nit: there should be no "an" here
> 
> > +
> >  config 32BIT
> > bool
> >  
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > index 5af189b338..e4276e8e19 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -39,10 +39,18 @@ _start:
> > mv  s1, a1
> >  
> > la  t0, trap_entry
> > +#ifdef CONFIG_RISCV_SMODE
> 
> It might make the code more readable by using defines for the CSRs,
> which are set to the correct values at the start of start.S depending
> on if CONFIG_RISCV_SMODE is set (similar to what we do for the load
> and
> store instructions).
> This is just a thought, I think this way is perfectly fine as well.
> :)
> 
> Reviewed-by: Lukas Auer 
> 
> Thanks,
> Lukas
> 
> > +   csrwstvec, t0
> > +#else
> > csrwmtvec, t0
> > +#endif
> >  
> > /* mask all interrupts */
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrwsie, zero
> > +#else
> > csrwmie, zero
> > +#endif
> >  
> > /* Enable cache */
> > jal icache_enable
> > @@ -164,7 +172,11 @@ fix_rela_dyn:
> >  */
> > la  t0, trap_entry
> > add t0, t0, t6
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrwstvec, t0
> > +#else
> > csrwmtvec, t0
> > +#endif
> >  
> >  clear_bss:
> > la  t0, __bss_start /* t0 <- rel __bss_start in
> > FLASH */
> > @@ -236,17 +248,34 @@ trap_entry:
> > SREGx29, 29*REGBYTES(sp)
> > SREGx30, 30*REGBYTES(sp)
> > SREGx31, 31*REGBYTES(sp)
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrra0, scause
> > +   csrra1, sepc
> > +#else
> > csrra0, mcause
> > csrra1, mepc
> > +#endif
> > mv  a2, sp
> > jal handle_trap
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrwsepc, a0
> > +#else
> > csrwmepc, a0
> > +#endif
> >  
> > +#ifdef CONFIG_RISCV_SMODE
> > +/*
> > + * Remain in S-mode after sret
> > + */
> > +   li  t0, SSTATUS_SPP
> > +   csrssstatus, t0
> > +#else
> >  /*
> >   * Remain in M-mode after mret
> >   */
> > li  t0, MSTATUS_MPP
> > csrsmstatus, t0
> > +#endif
> > LREGx1, 1*REGBYTES(sp)
> > LREGx2, 2*REGBYTES(sp)
> > LREGx3, 3*REGBYTES(sp)
> > @@ -279,4 +308,8 @@ trap_entry:
> > LREGx30, 30*REGBYTES(sp)
> > LREGx31, 31*REGBYTES(sp)
> > addisp, sp, 32*REGBYTES
> > +#ifdef CONFIG_RISCV_SMODE
> > +   sret
> > +#else
> > mret
> > +#endif
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] riscv: Add kconfig option to run u-boot in S-mode

[Auer, Lukas]

Hi Palmer,

On Wed, 2018-11-21 at 08:28 -0800, Palmer Dabbelt wrote:
> On Tue, 20 Nov 2018 19:41:10 PST (-0800), a...@brainfault.org wrote:
> > This patch adds kconfig option RISCV_SMODE to run u-boot in
> > S-mode. When this opition is enabled we use s CSRs instead
> > of m CSRs.
> > 
> > It is important to note that there is no equivalent S-mode CSR
> > for misa and mhartid CSRs so we expect M-mode runtime firmware
> > (BBL or equivalent) to emulate misa and mhartid CSR read.
> > 
> > In-future, we will have more patches to avoid accessing misa and
> > mhartid CSRs from S-mode.
> 
> Ya, I don't like this.  Our current boot protocol puts mhartid in a1
> upon 
> entering the supervisor, and allows the detection of misa via a
> device tree 
> pointer provided in a0.  
> 
> As long as everyone agrees this isn't what we're actually looking for
> then I'm 
> fine with the patch, I just don't want to end up requiring this "M
> mode 
> emulates some CSRs for S mode" interface.  Since we don't have an
> actual 
> platform spec we've got to be careful to avoid a bunch of defacto
> interfaces 
> that we'll need to support later.
> 

I agree with you. We actually won't need the CSR emulation of misa and
mhartid for long. With Bin's recent patch series [1], the ISA string is
read from the device tree, replacing the use of misa. mhartid is only
used to pass the hart id to the kernel. I am going to replace it in a
patch series I am working on.
So the interface should just be temporary.

Thanks,
Lukas

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

> > 
> > Signed-off-by: Anup Patel 
> > Reviewed-by: Bin Meng 
> > Tested-by: Bin Meng 
> > ---
> >  arch/riscv/Kconfig |  5 +
> >  arch/riscv/cpu/start.S | 33 +
> >  2 files changed, 38 insertions(+)
> > 
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 3e0af55e71..8f2139ff60 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -55,6 +55,11 @@ config RISCV_ISA_C
> >  config RISCV_ISA_A
> > def_bool y
> > 
> > +config RISCV_SMODE
> > +   bool "Run in S-Mode"
> > +   help
> > + Enable this option to build an U-Boot for RISC-V S-Mode
> > +
> >  config 32BIT
> > bool
> > 
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > index 5af189b338..e4276e8e19 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -39,10 +39,18 @@ _start:
> > mv  s1, a1
> > 
> > la  t0, trap_entry
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrwstvec, t0
> > +#else
> > csrwmtvec, t0
> > +#endif
> > 
> > /* mask all interrupts */
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrwsie, zero
> > +#else
> > csrwmie, zero
> > +#endif
> > 
> > /* Enable cache */
> > jal icache_enable
> > @@ -164,7 +172,11 @@ fix_rela_dyn:
> >  */
> > la  t0, trap_entry
> > add t0, t0, t6
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrwstvec, t0
> > +#else
> > csrwmtvec, t0
> > +#endif
> > 
> >  clear_bss:
> > la  t0, __bss_start /* t0 <- rel __bss_start in FLASH
> > */
> > @@ -236,17 +248,34 @@ trap_entry:
> > SREGx29, 29*REGBYTES(sp)
> > SREGx30, 30*REGBYTES(sp)
> > SREGx31, 31*REGBYTES(sp)
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrra0, scause
> > +   csrra1, sepc
> > +#else
> > csrra0, mcause
> > csrra1, mepc
> > +#endif
> > mv  a2, sp
> > jal handle_trap
> > +#ifdef CONFIG_RISCV_SMODE
> > +   csrwsepc, a0
> > +#else
> > csrwmepc, a0
> > +#endif
> > 
> > +#ifdef CONFIG_RISCV_SMODE
> > +/*
> > + * Remain in S-mode after sret
> > + */
> > +   li  t0, SSTATUS_SPP
> > +   csrssstatus, t0
> > +#else
> >  /*
> >   * Remain in M-mode after mret
> >   */
> > li  t0, MSTATUS_MPP
> > csrsmstatus, t0
> > +#endif
> > LREGx1, 1*REGBYTES(sp)
> > LREGx2, 2*REGBYTES(sp)
> > LREGx3, 3*REGBYTES(sp)
> > @@ -279,4 +308,8 @@ trap_entry:
> > LREGx30, 30*REGBYTES(sp)
> > LREGx31, 31*REGBYTES(sp)
> > addisp, sp, 32*REGBYTES
> > +#ifdef CONFIG_RISCV_SMODE
> > +   sret
> > +#else
> > mret
> > +#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] use of dm_spi_flash

[C Michael Sundius]

I am a bit confused about the use of the driver model when it comes to spi
flash.

It seems from the description in the Kconfig help that both the legacy and
dm interfaces
for spi flash can coexist, thus you can use both the "sf " commands as
well as use
the driver model interface for the likes of flash..

is that correct? or is it one or the other?

2ndly, I've been trying to build u-boot for an TI am335x_evm (well our
board is designed
largely the same as that) attached to the spi flash is is25lp512 nor flash.
when I try to
configure both the CONFIG_SPI_FLASH and the CONFIG_DM_SPI +
CONFIG_DM_SPI_FLASH
i get lots of build errors.

I have a version of u-boot from 2017-09, I'll update to the newer version
next but just wondering if anyone has done this and knows which config
options to set/not set

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

Re: [U-Boot] [PATCH] arm: socfpga: crc-protect SPL on warm boot

[Simon Goldschmidt]

On 21.11.2018 15:08, Marek Vasut wrote:

On 11/21/2018 06:09 AM, Simon Goldschmidt wrote:


Am Mi., 21. Nov. 2018, 00:11 hat Marek Vasut mailto:ma...@denx.de>> geschrieben:

 On 11/20/2018 09:54 PM, Simon Goldschmidt wrote:
 > On 20.11.2018 20:33, Marek Vasut wrote:
 >> On 11/20/2018 08:22 PM, Simon Goldschmidt wrote:
 >>> From: Simon Goldschmidt mailto:sgoldschm...@de.pepperl-fuchs.com>>
 >>>
 >>> On socfpga gen5, a warm reboot from Linux currently triggers a warm
 >>> reset via reset manager ctrl register.
 >>>
 >>> This currently leads to the boot rom just jumping to onchip ram
 >>> executing the SPL that is supposed to still be there. This is
 >>> because we tell the boot rom to do so by writing a magin value
 >>> the warmramgrp_enable register in arch_early_init_r().
 >>>
 >>> However, this can lead to lockups on reboot if this register still
 >>> contains its magic value but the SPL is not intact any more (e.g.
 >>> partly overwritten onchip ram).
 >>>
 >>> To fis this, store a crc calculated over SPL in sysmgr registers to
 >>> let the boot rom check it on next warm boot. If the crc is still
 >>> correct, SPL can be executd from onchip ram. If the crc fails, SPL
 >>> is loaded from original boot source.
 >>>
 >>> The crc that is written to the warmramgrp_crc register is the crc
 >>> found in the SPL sfp image but with one addiional u32 added. For
 >>> this, we need to add a function to calculate the updated crc. This
 >>> is done as a bitwise calculation to keep the code increase small.
 >>>
 >>> This whole patch added 96 bytes to .text for SPL for
 >>> socfpga_socrates_defconfig.
 >>>
 >>> Signed-off-by: Simon Goldschmidt
 mailto:simon.k.r.goldschm...@gmail.com>>
 >>> ---
 >>>
 >>>   arch/arm/mach-socfpga/misc_gen5.c |  9 
 >>>   arch/arm/mach-socfpga/spl_gen5.c  | 73
 +++
 >>>   2 files changed, 73 insertions(+), 9 deletions(-)
 >>>
 >>> diff --git a/arch/arm/mach-socfpga/misc_gen5.c
 >>> b/arch/arm/mach-socfpga/misc_gen5.c
 >>> index 5fa40937c4..492a3082de 100644
 >>> --- a/arch/arm/mach-socfpga/misc_gen5.c
 >>> +++ b/arch/arm/mach-socfpga/misc_gen5.c
 >>> @@ -204,15 +204,6 @@ int arch_early_init_r(void)
 >>>   {
 >>>   int i;
 >>>   -    /*
 >>> - * Write magic value into magic register to unlock support for
 >>> - * issuing warm reset. The ancient kernel code expects this
 >>> - * value to be written into the register by the bootloader, so
 >>> - * to support that old code, we write it here instead of in the
 >>> - * reset_cpu() function just before resetting the CPU.
 >>> - */
 >>> -    writel(0xae9efebc, &sysmgr_regs->romcodegrp_warmramgrp_enable);
 >>> -
 >>>   for (i = 0; i < 8; i++)    /* Cache initial SW setting regs */
 >>>   iswgrp_handoff[i] =
 readl(&sysmgr_regs->iswgrp_handoff[i]);
 >>>   diff --git a/arch/arm/mach-socfpga/spl_gen5.c
 >>> b/arch/arm/mach-socfpga/spl_gen5.c
 >>> index ccdc661d05..3416e19f79 100644
 >>> --- a/arch/arm/mach-socfpga/spl_gen5.c
 >>> +++ b/arch/arm/mach-socfpga/spl_gen5.c
 >>> @@ -63,6 +63,76 @@ u32 spl_boot_mode(const u32 boot_device)
 >>>   }
 >>>   #endif
 >>>   +/* This function calculates the CRC32 used by the Cyclone 5 SoC
 >>> Boot Rom */
 >>> +static u32 socfpga_boot_crc(u32 crc, const unsigned char *ptr, u32
 >>> length)
 >>> +{
 >>> +    uint i;
 >>> +    u8 bit;
 >>> +    unsigned char data;
 >>> +    const u32 poly = 0x02608edb;
 >>> +
 >>> +    for (; length > 0; length--, ptr++) {
 >>> +    data = *ptr;
 >>> +    for (i = 0; i < 8; i++) {
 >>> +    if (data & 0x80)
 >>> +    bit = 1;
 >>> +    else
 >>> +    bit = 0;
 >>> +
 >>> +    data = data << 1;
 >>> +    if (crc & 0x8000)
 >>> +    bit = 1 - bit;
 >>> +
 >>> +    if (bit) {
 >>> +    crc ^= poly;
 >>> +    crc = crc << 1;
 >>> +    crc |= 1;
 >>> +    } else {
 >>> +    crc = crc << 1;
 >>> +    }
 >>> +    }
 >>> +    }
 >>> +    return crc;
 >>> +}
 >>> +
 >>> +/*
 >>> + * Write magic value into magic register to unlock support for the
 >>> boot rom to
 >>> + * execute spl from sram on warm reset. This may be required at
 >>> least on some
 >>> + * boards that start from qspi where the flash chip might be in a
 >>> state that
 >>> + * cannot be handled by the boot rom (e.g. 4 byte mode).
 >>> + *
 >>> + * To prevent just jumping to corrupted memory, a crc of the spl is
 >>> calculated.
 >>> + * This crc is loaded fr

Re: [U-Boot] [PATCH v2] imx: hab: extend hab_auth_img to calculate ivt_offset

[Parthiban Nallathambi]

Hi Breno,

On 11/21/18 7:42 PM, Breno Matheus Lima wrote:
> Hi Parthiban,
> 
> Em qua, 21 de nov de 2018 às 15:52, Parthiban Nallathambi  
> escreveu:
>>
>> Hi Breno,
>>
>> On 11/21/18 5:45 PM, Breno Matheus Lima wrote:
>>> Hi Parthiban,
>>>
>>> Em qua, 21 de nov de 2018 às 11:50, Parthiban Nallathambi  
>>> escreveu:

 Current implementation of hab_auth_img command needs ivt_offset to
 authenticate the image. But ivt header is placed at the end of image
 date after padding.

 This leaves the usage of hab_auth_img command to fixed size or static
 offset for ivt header. New function "get_image_ivt_offset" is introduced
 to find the ivt offset during runtime. The case conditional check in this
 function is same as boot_get_kernel in common/bootm.c

 With this variable length image e.g. FIT image with any random size can
 have IVT at the end and ivt_offset option can be left optional

 Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script

 Signed-off-by: Parthiban Nallathambi 
 ---

 Notes:
  Changelog in v2:
  - Finding IVT offset doesn't need length. Removed the
  length argument from get_image_ivt_offset

   arch/arm/mach-imx/hab.c | 29 +++--
   1 file changed, 27 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
 index b88acd13da..dbfd692fa3 100644
 --- a/arch/arm/mach-imx/hab.c
 +++ b/arch/arm/mach-imx/hab.c
 @@ -6,6 +6,8 @@
   #include 
   #include 
   #include 
 +#include 
 +#include 
   #include 
   #include 
   #include 
 @@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int flag, 
 int argc,
  return 0;
   }

 +static ulong get_image_ivt_offset(ulong img_addr)
 +{
 +   const void *buf;
 +
 +   buf = map_sysmem(img_addr, 0);
 +   switch (genimg_get_format(buf)) {
 +#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
 +   case IMAGE_FORMAT_LEGACY:
 +   return (image_get_image_size((image_header_t *)img_addr)
 +   + 0x1000 - 1)  & ~(0x1000 - 1);
 +#endif
 +#if IMAGE_ENABLE_FIT
 +   case IMAGE_FORMAT_FIT:
 +   return (fit_get_size(buf) + 0x1000 - 1)  & ~(0x1000 - 1);
 +#endif
 +   default:
 +   return 0;
 +   }
 +}
>>>
>>>
>>> Do you have more details about the image header I should use here?
>>
>> Is the image signed using CST or similar tool? Is so, the signature data
>> (HAB data: CSF, Certs and signature) pads at the end of the kernel
>> image.
> 
> Yes, my Kernel image contains an IVT and is signed with CST. The image
> layout looks like link below:
> https://pastebin.com/5qEt7ETa
> 
>>
>>>
>>> I'm trying to get the IVT offset for my Kernel image based on NXP
>>> 4.9.11_2.0.0_GA Linux release loaded at 0x8080:
>>>
>>> => fatload mmc 0:1 0x8080 zImage
>>> => hab_auth_img 0x8080 
>>
>> Length for hab_auth_img is still mandatory. Length hear means the file
>> size or total length of the image, this is required for the HAB API to
>> authenticate (HAB_RVT_AUTHENTICATE_IMAGE).
> 
> Oh ok, I understood the scenario right now.
> 
>>From my first overview I thought we would add IVT_SIZE + CSF_PAD_SIZE
> in ivt_offset to calculate the image length, similar approach we have
> in spl.c:
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-imx/spl.c;h=a20b30d154d788e4ebd4e22e9a6568a4f24c057e;hb=HEAD#l226
> 
> In this case only load addr would be necessary.
> 
>>
>>>
>>> The zImage size in Header looks correct (0x00726690), but
>>> get_image_ivt_offset() is returning 0x0
>>
>> Looks like IVT offset is not found in the image.
>>
>>>
>>> $ hexdump zImage | head
>>> 000  e1a0  e1a0  e1a0  e1a0
>>> *
>>> 020 0003 ea00 2818 016f   6690 0072
>>> 030 0201 0403 9000 e10f 04f8 eb00 7001 e1a0
>>> 040 8002 e1a0 2000 e10f 0003 e312 0001 1a00
>>>
>>> Seems that genimg_get_format() is returning 0x0.
>>
>> Image is not signed?
> 
> No, my zImage is signed.
> 
>>
>>>
>>> Any ideias if I'm missing something?
>>>
 +
   static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[])
   {
  ulong   addr, length, ivt_offset;
  int rcode = 0;

 -   if (argc < 4)
 +   if (argc < 3)
>>>
>>> I think we can also change here to argc < 2, the function
>>> get_image_ivt_offset() only requires the img addr now.
>>
>> No, length is mandatory for authentication. To brief, this patch just
>> removes the ivt_offset as argument and make it optional. This is needed
>> because, in images like FIT, the location of the ivt header varies
>> dynamically depending on the total number of images clubbed.
>>
>> In such cases, the existing h

Re: [U-Boot] [PATCH v2 0/3] sunxi-mmc: enable new clock mode on A64

[Vasily Khoruzhick]

On Thu, Nov 15, 2018 at 11:20 AM Vasily Khoruzhick  wrote:
>
> On Fri, Nov 9, 2018 at 8:41 PM Vasily Khoruzhick  wrote:
> >
> > A64 requires new clock mode on SD and eMMC controllers. Not using
> > new clock mode causes stability issues of the driver - SPL may
> > occasionally fail to load u-boot from SD for some particular SD card
> > on some particular devices.
> >
> > This series depends on "sunxi: add support for automatic delay calibration"
> > from my Pinebook series.
> >
> > Tested on Pinebook and Pine64-LTS. Fixes eMMC failures on Olinuxino-A64 [1]
>
> Ping? I've got reports from several users that it fixes issues with
> different SD cards on Pinebook and Sopine. It would be nice to have it
> merged.

Another gentle reminder - patches has been sitting in ML for almost 2
weeks with no review.

> > [1] 
> > https://github.com/armbian/build/commit/03199b3879af24c94029460b8cdf0d41048afc92#commitcomment-31028421
> >
> > Vasily Khoruzhick (3):
> >   sunxi-mmc: introduce new MMC_SUNXI_HAS_MODE_SWITCH option
> >   sunxi-mmc: don't double clock for new mode unconditionally
> >   sunxi-mmc: use new mode on both controllers on A64
> >
> >  arch/arm/mach-sunxi/Kconfig |  2 ++
> >  drivers/mmc/Kconfig |  4 
> >  drivers/mmc/sunxi_mmc.c | 19 +--
> >  3 files changed, 15 insertions(+), 10 deletions(-)
> >
> > --
> > 2.19.1
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/4] ARM: chiliboard: remove dead !CONFIG_DM_SERIAL code

[Marcin Niestroj]

DM_SERIAL is selected by TARGET_CHILIBOARD, so there is no reason to
keep code that will not be built. Remove it.

Signed-off-by: Marcin Niestroj 
---
 board/grinn/chiliboard/board.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/board/grinn/chiliboard/board.c b/board/grinn/chiliboard/board.c
index 2bb91e31b7..dc0de620fc 100644
--- a/board/grinn/chiliboard/board.c
+++ b/board/grinn/chiliboard/board.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -69,13 +68,6 @@ static void enable_board_pin_mux(void)
 }
 #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
 
-#ifndef CONFIG_DM_SERIAL
-struct serial_device *default_serial_console(void)
-{
-   return &eserial1_device;
-}
-#endif
-
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
 void set_uart_mux_conf(void)
 {
-- 
2.19.1

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

[U-Boot] [PATCH 3/4] ARM: chiliboard: move towards driver model and device-tree boot

[Marcin Niestroj]

This patch mostly enables DM drivers in board defconfig and all their
dependencies. Additionally we remove ethernet platform data, as all
details are in device-tree now.

Signed-off-by: Marcin Niestroj 
---
 board/grinn/chiliboard/board.c | 53 --
 configs/chiliboard_defconfig   | 12 ++--
 2 files changed, 10 insertions(+), 55 deletions(-)

diff --git a/board/grinn/chiliboard/board.c b/board/grinn/chiliboard/board.c
index 73a7d8281c..2bb91e31b7 100644
--- a/board/grinn/chiliboard/board.c
+++ b/board/grinn/chiliboard/board.c
@@ -150,56 +150,3 @@ int board_late_init(void)
return 0;
 }
 #endif
-
-#if !defined(CONFIG_DM_ETH) && defined(CONFIG_DRIVER_TI_CPSW) && \
-   !defined(CONFIG_SPL_BUILD)
-static void cpsw_control(int enabled)
-{
-   /* VTP can be added here */
-
-   return;
-}
-
-static struct cpsw_slave_data cpsw_slaves[] = {
-   {
-   .slave_reg_ofs  = 0x208,
-   .sliver_reg_ofs = 0xd80,
-   .phy_addr   = 0,
-   }
-};
-
-static struct cpsw_platform_data cpsw_data = {
-   .mdio_base  = CPSW_MDIO_BASE,
-   .cpsw_base  = CPSW_BASE,
-   .mdio_div   = 0xff,
-   .channels   = 8,
-   .cpdma_reg_ofs  = 0x800,
-   .slaves = 1,
-   .slave_data = cpsw_slaves,
-   .ale_reg_ofs= 0xd00,
-   .ale_entries= 1024,
-   .host_port_reg_ofs  = 0x108,
-   .hw_stats_reg_ofs   = 0x900,
-   .bd_ram_ofs = 0x2000,
-   .mac_control= (1 << 5),
-   .control= cpsw_control,
-   .host_port_num  = 0,
-   .version= CPSW_CTRL_VERSION_2,
-};
-
-int board_eth_init(bd_t *bis)
-{
-   int rv, n = 0;
-
-   writel(RMII_MODE_ENABLE | RMII_CHIPCKL_ENABLE, &cdev->miisel);
-   cpsw_slaves[0].phy_if = PHY_INTERFACE_MODE_RMII;
-
-   rv = cpsw_register(&cpsw_data);
-   if (rv < 0)
-   printf("Error %d registering CPSW switch\n", rv);
-   else
-   n += rv;
-
-   return n;
-}
-#endif
diff --git a/configs/chiliboard_defconfig b/configs/chiliboard_defconfig
index b6cde09d6f..3de0223469 100644
--- a/configs/chiliboard_defconfig
+++ b/configs/chiliboard_defconfig
@@ -29,19 +29,27 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nand0=800.nand"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=800.nand:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
+CONFIG_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="am335x-chiliboard"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_DM_GPIO=y
+CONFIG_MISC=y
+CONFIG_DM_MMC=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
-CONFIG_DRIVER_TI_CPSW=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
+CONFIG_DRIVER_TI_CPSW=y
 CONFIG_SPI=y
 CONFIG_OMAP3_SPI=y
+CONFIG_TIMER=y
+CONFIG_OMAP_TIMER=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_MUSB_HOST=y
 CONFIG_USB_MUSB_DSPS=y
+CONFIG_USB_MUSB_TI=y
 CONFIG_USB_STORAGE=y
 CONFIG_FAT_WRITE=y
 CONFIG_LZO=y
-CONFIG_OF_LIBFDT=y
-- 
2.19.1

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

[U-Boot] [PATCH 2/4] ARM: dts: am335x-chiliboard: add /chosen/stdout-path

[Marcin Niestroj]

Add that node path in u-boot overlay dtsi file for now to keep
am335x-chiliboard.dts in sync with Linux.

Signed-off-by: Marcin Niestroj 
---
 arch/arm/dts/am335x-chiliboard-u-boot.dtsi | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 arch/arm/dts/am335x-chiliboard-u-boot.dtsi

diff --git a/arch/arm/dts/am335x-chiliboard-u-boot.dtsi 
b/arch/arm/dts/am335x-chiliboard-u-boot.dtsi
new file mode 100644
index 00..4f9d308039
--- /dev/null
+++ b/arch/arm/dts/am335x-chiliboard-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+ or X11
+/*
+ * Copyright (C) 2018 Grinn Sp. z o.o. -- http://www.grinn-global.com/
+ * Author: Marcin Niestroj 
+ */
+
+/ {
+   chosen {
+   stdout-path = &uart0;
+   };
+};
-- 
2.19.1

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

[U-Boot] [PATCH 1/4] ARM: dts: am335x-chili*: add chiliSOM and chiliboard DTS files

[Marcin Niestroj]

Import chiliSOM and chiliboard dts files from Linux v4.19. They will
be used after transition to driver model and device-tree based boot.

Signed-off-by: Marcin Niestroj 
---
 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/am335x-chiliboard.dts | 200 +
 arch/arm/dts/am335x-chilisom.dtsi  | 178 +
 3 files changed, 380 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/am335x-chiliboard.dts
 create mode 100644 arch/arm/dts/am335x-chilisom.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 84b7e5335c..55f3fd1b25 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -187,7 +187,8 @@ dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb 
am335x-bone.dtb \
am335x-icev2.dtb \
am335x-pxm50.dtb \
am335x-rut.dtb \
-   am335x-pdu001.dtb
+   am335x-pdu001.dtb \
+   am335x-chiliboard.dtb
 dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb\
am43x-epos-evm.dtb \
am437x-idk-evm.dtb \
diff --git a/arch/arm/dts/am335x-chiliboard.dts 
b/arch/arm/dts/am335x-chiliboard.dts
new file mode 100644
index 00..59431b2359
--- /dev/null
+++ b/arch/arm/dts/am335x-chiliboard.dts
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2015 Jablotron s.r.o. -- http://www.jablotron.com/
+ * Author: Rostislav Lisovy 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+#include "am335x-chilisom.dtsi"
+
+/ {
+   model = "AM335x Chiliboard";
+   compatible = "grinn,am335x-chiliboard", "grinn,am335x-chilisom",
+"ti,am33xx";
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&led_gpio_pins>;
+
+   led0 {
+   label = "led0";
+   gpios = <&gpio3 7 GPIO_ACTIVE_LOW>;
+   default-state = "keep";
+   linux,default-trigger = "heartbeat";
+   };
+
+   led1 {
+   label = "led1";
+   gpios = <&gpio3 8 GPIO_ACTIVE_LOW>;
+   default-state = "keep";
+   };
+   };
+};
+
+&am33xx_pinmux {
+   uart0_pins: pinmux_uart0_pins {
+   pinctrl-single,pins = <
+   AM33XX_IOPAD(0x970, PIN_INPUT_PULLUP | MUX_MODE0)   
/* uart0_rxd.uart0_rxd */
+   AM33XX_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
/* uart0_txd.uart0_txd */
+   >;
+   };
+
+   cpsw_default: cpsw_default {
+   pinctrl-single,pins = <
+   /* Slave 1 */
+   AM33XX_IOPAD(0x90c, PIN_INPUT_PULLDOWN | MUX_MODE1)  /* 
mii1_crs.rmii1_crs */
+   AM33XX_IOPAD(0x910, PIN_INPUT_PULLUP | MUX_MODE1)   
/* mii1_rxerr.rmii1_rxerr */
+   AM33XX_IOPAD(0x914, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txen.rmii1_txen */
+   AM33XX_IOPAD(0x924, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd1.rmii1_txd1 */
+   AM33XX_IOPAD(0x928, PIN_OUTPUT_PULLDOWN | MUX_MODE1)
/* mii1_txd0.rmii1_txd0 */
+   AM33XX_IOPAD(0x93c, PIN_INPUT_PULLUP | MUX_MODE1)   
/* mii1_rxd1.rmii1_rxd1 */
+   AM33XX_IOPAD(0x940, PIN_INPUT_PULLUP | MUX_MODE1)   
/* mii1_rxd0.rmii1_rxd0 */
+   AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE0) 
/* rmii1_ref_clk.rmii_ref_clk */
+   >;
+   };
+
+   cpsw_sleep: cpsw_sleep {
+   pinctrl-single,pins = <
+   /* Slave 1 reset value */
+   AM33XX_IOPAD(0x90c, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   AM33XX_IOPAD(0x910, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   AM33XX_IOPAD(0x914, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   AM33XX_IOPAD(0x918, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   AM33XX_IOPAD(0x924, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   AM33XX_IOPAD(0x928, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   AM33XX_IOPAD(0x93c, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   AM33XX_IOPAD(0x940, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   AM33XX_IOPAD(0x944, PIN_INPUT_PULLDOWN | MUX_MODE7)
+   >;
+   };
+
+   davinci_mdio_default: davinci_mdio_default {
+   pinctrl-single,pins = <
+   /* mdio_data.mdio_data */
+   AM33XX_IOPAD(0x948, PIN_INPUT_PULLUP | SLEWCTRL_FAST | 
MUX_MODE0)
+   /* mdio_clk.mdio_clk */
+   AM33XX_IOPAD(0x94c, PIN_OUTPUT_PULLUP | MUX_MODE0)
+   >;
+   };
+
+   davinci_mdio_sleep: davinci_mdio_sleep {
+

[U-Boot] [PATCH 0/4] ARM: chiliboard: move towards driver model and device-tree boot

[Marcin Niestroj]

Hi,

Currently on master branch we are no longer able to boot Linux on
chiliboard. This is due to issue described at [1]. This series makes
the boot to Linux working once again.

This patch moves board support code to use driver model where
possible and device-tree bot. As part of that we import DTS files from
Linux v4.19.

[1] https://lists.denx.de/pipermail/u-boot/2018-November/348558.html

Marcin Niestroj (4):
  ARM: dts: am335x-chili*: add chiliSOM and chiliboard DTS files
  ARM: dts: am335x-chiliboard: add /chosen/stdout-path
  ARM: chiliboard: move towards driver model and device-tree boot
  ARM: chiliboard: remove dead !CONFIG_DM_SERIAL code

 arch/arm/dts/Makefile  |   3 +-
 arch/arm/dts/am335x-chiliboard-u-boot.dtsi |  11 ++
 arch/arm/dts/am335x-chiliboard.dts | 200 +
 arch/arm/dts/am335x-chilisom.dtsi  | 178 ++
 board/grinn/chiliboard/board.c |  61 ---
 configs/chiliboard_defconfig   |  12 +-
 6 files changed, 401 insertions(+), 64 deletions(-)
 create mode 100644 arch/arm/dts/am335x-chiliboard-u-boot.dtsi
 create mode 100644 arch/arm/dts/am335x-chiliboard.dts
 create mode 100644 arch/arm/dts/am335x-chilisom.dtsi

-- 
2.19.1

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

[U-Boot] [PATCH 3/3] ARM: liteboard: use random ethaddr

[Marcin Niestroj]

There is no ethaddr assigned to each board, so we need to use random
value in order to use network.

Signed-off-by: Marcin Niestroj 
---
 configs/liteboard_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/liteboard_defconfig b/configs/liteboard_defconfig
index 3d1b35918c..dad619e0ad 100644
--- a/configs/liteboard_defconfig
+++ b/configs/liteboard_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="imx6ul-liteboard"
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_DM_MMC=y
-- 
2.19.1

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

[U-Boot] [PATCH 2/3] ARM: liteboard: move towards driver model and device-tree boot

[Marcin Niestroj]

This patch mostly enables DM drivers in board defconfig and all their
dependencies. Additionally we remove USB code that is on longer
executed after enabling CONFIG_DM_USB. Enable CONFIG_PINCTRL, so we
can get rid of ethernet pin configuration.

Signed-off-by: Marcin Niestroj 
---
 board/grinn/liteboard/board.c | 36 ---
 configs/liteboard_defconfig   | 11 ++-
 2 files changed, 10 insertions(+), 37 deletions(-)

diff --git a/board/grinn/liteboard/board.c b/board/grinn/liteboard/board.c
index 18d152a381..80910e4713 100644
--- a/board/grinn/liteboard/board.c
+++ b/board/grinn/liteboard/board.c
@@ -24,8 +24,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -63,26 +61,6 @@ static iomux_v3_cfg_t const sd_pads[] = {
MX6_PAD_UART1_RTS_B__GPIO1_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL),
 };
 
-#ifdef CONFIG_FEC_MXC
-static iomux_v3_cfg_t const fec1_pads[] = {
-   MX6_PAD_GPIO1_IO06__ENET1_MDIO | MUX_PAD_CTRL(MDIO_PAD_CTRL),
-   MX6_PAD_GPIO1_IO07__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET1_TX_DATA0__ENET1_TDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET1_TX_DATA1__ENET1_TDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET1_TX_EN__ENET1_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 | MUX_PAD_CTRL(ENET_CLK_PAD_CTRL),
-   MX6_PAD_ENET1_RX_DATA0__ENET1_RDATA00 | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET1_RX_DATA1__ENET1_RDATA01 | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET1_RX_ER__ENET1_RX_ER | MUX_PAD_CTRL(ENET_PAD_CTRL),
-   MX6_PAD_ENET1_RX_EN__ENET1_RX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
-};
-
-static void setup_iomux_fec(void)
-{
-   imx_iomux_v3_setup_multiple_pads(fec1_pads, ARRAY_SIZE(fec1_pads));
-}
-#endif
-
 static void setup_iomux_uart(void)
 {
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
@@ -180,13 +158,6 @@ void board_late_mmc_init(void)
 #endif
 
 #ifdef CONFIG_FEC_MXC
-int board_eth_init(bd_t *bis)
-{
-   setup_iomux_fec();
-
-   return fecmxc_initialize(bis);
-}
-
 static int setup_fec(void)
 {
struct iomuxc *const iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
@@ -207,13 +178,6 @@ static int setup_fec(void)
 }
 #endif
 
-#ifdef CONFIG_USB_EHCI_MX6
-int board_usb_phy_mode(int port)
-{
-   return USB_INIT_HOST;
-}
-#endif
-
 int board_early_init_f(void)
 {
setup_iomux_uart();
diff --git a/configs/liteboard_defconfig b/configs/liteboard_defconfig
index bdc99b0e0d..3d1b35918c 100644
--- a/configs/liteboard_defconfig
+++ b/configs/liteboard_defconfig
@@ -29,10 +29,19 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="imx6ul-liteboard"
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_PHYLIB=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX6=y
+CONFIG_DM_REGULATOR=y
 CONFIG_USB=y
+CONFIG_DM_USB=y
 CONFIG_USB_STORAGE=y
-CONFIG_OF_LIBFDT=y
-- 
2.19.1

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

[U-Boot] [PATCH 1/3] ARM: dts: imx6ul-lite*: add DTS files for liteSOM and liteboard

[Marcin Niestroj]

Import liteSOM and liteboard dts files from Linux v4.19. They will
be used after transition to driver model and device-tree based boot.

Signed-off-by: Marcin Niestroj 
---
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/imx6ul-liteboard.dts | 151 ++
 arch/arm/dts/imx6ul-litesom.dtsi  |  82 
 3 files changed, 235 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6ul-liteboard.dts
 create mode 100644 arch/arm/dts/imx6ul-litesom.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 84b7e5335c..db08b949bb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -448,7 +448,8 @@ dtb-$(CONFIG_MX6UL) += \
imx6ul-isiot-nand.dtb \
imx6ul-opos6uldev.dtb \
imx6ul-14x14-evk.dtb \
-   imx6ul-9x9-evk.dtb
+   imx6ul-9x9-evk.dtb \
+   imx6ul-liteboard.dtb
 
 dtb-$(CONFIG_MX6ULL) += imx6ull-14x14-evk.dtb
 
diff --git a/arch/arm/dts/imx6ul-liteboard.dts 
b/arch/arm/dts/imx6ul-liteboard.dts
new file mode 100644
index 00..1d863a16bc
--- /dev/null
+++ b/arch/arm/dts/imx6ul-liteboard.dts
@@ -0,0 +1,151 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-litesom.dtsi"
+
+/ {
+   model = "Grinn i.MX6UL liteBoard";
+   compatible = "grinn,imx6ul-liteboard", "grinn,imx6ul-litesom",
+"fsl,imx6ul";
+
+   chosen {
+   stdout-path = &uart1;
+   };
+
+   reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usb_otg1_vbus>;
+   regulator-name = "usb_otg1_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = <&gpio2 8 GPIO_ACTIVE_LOW>;
+   };
+};
+
+&iomuxc {
+   pinctrl_enet1: enet1grp {
+   fsl,pins = <
+   MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+   MX6UL_PAD_GPIO1_IO06__ENET1_MDIO0x1b0b0
+   MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN  0x1b0b0
+   MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER  0x1b0b0
+   MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+   MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+   MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN  0x1b0b0
+   MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+   MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+   MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1  0x4001b031
+   >;
+   };
+
+   pinctrl_uart1: uart1grp {
+   fsl,pins = <
+   MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX   0x1b0b1
+   MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX   0x1b0b1
+   >;
+   };
+
+   pinctrl_usdhc1: usdhc1grp {
+   fsl,pins = <
+   MX6UL_PAD_UART1_RTS_B__GPIO1_IO19   0x17

[U-Boot] [PATCH 0/3] ARM: liteboard: move towards driver model and device-tree boot

[Marcin Niestroj]

Hi,

This patch moves board support code to use driver model where
possible and device-tree bot. As part of that we import DTS files from
Linux v4.19.

One minor patch here is to use random ethaddr in order to make network
usable on that board by default.

Marcin Niestroj (3):
  ARM: dts: imx6ul-lite*: add DTS files for liteSOM and liteboard
  ARM: liteboard: move towards driver model and device-tree boot
  ARM: liteboard: use random ethaddr

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/imx6ul-liteboard.dts | 151 ++
 arch/arm/dts/imx6ul-litesom.dtsi  |  82 
 board/grinn/liteboard/board.c |  36 ---
 configs/liteboard_defconfig   |  12 ++-
 5 files changed, 246 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm/dts/imx6ul-liteboard.dts
 create mode 100644 arch/arm/dts/imx6ul-litesom.dtsi

-- 
2.19.1

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

Re: [U-Boot] [PATCH v2] imx: hab: extend hab_auth_img to calculate ivt_offset

[Breno Matheus Lima]

Hi Parthiban,

Em qua, 21 de nov de 2018 às 15:52, Parthiban Nallathambi  
escreveu:
>
> Hi Breno,
>
> On 11/21/18 5:45 PM, Breno Matheus Lima wrote:
> > Hi Parthiban,
> >
> > Em qua, 21 de nov de 2018 às 11:50, Parthiban Nallathambi  
> > escreveu:
> >>
> >> Current implementation of hab_auth_img command needs ivt_offset to
> >> authenticate the image. But ivt header is placed at the end of image
> >> date after padding.
> >>
> >> This leaves the usage of hab_auth_img command to fixed size or static
> >> offset for ivt header. New function "get_image_ivt_offset" is introduced
> >> to find the ivt offset during runtime. The case conditional check in this
> >> function is same as boot_get_kernel in common/bootm.c
> >>
> >> With this variable length image e.g. FIT image with any random size can
> >> have IVT at the end and ivt_offset option can be left optional
> >>
> >> Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script
> >>
> >> Signed-off-by: Parthiban Nallathambi 
> >> ---
> >>
> >> Notes:
> >>  Changelog in v2:
> >>  - Finding IVT offset doesn't need length. Removed the
> >>  length argument from get_image_ivt_offset
> >>
> >>   arch/arm/mach-imx/hab.c | 29 +++--
> >>   1 file changed, 27 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> >> index b88acd13da..dbfd692fa3 100644
> >> --- a/arch/arm/mach-imx/hab.c
> >> +++ b/arch/arm/mach-imx/hab.c
> >> @@ -6,6 +6,8 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int flag, 
> >> int argc,
> >>  return 0;
> >>   }
> >>
> >> +static ulong get_image_ivt_offset(ulong img_addr)
> >> +{
> >> +   const void *buf;
> >> +
> >> +   buf = map_sysmem(img_addr, 0);
> >> +   switch (genimg_get_format(buf)) {
> >> +#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
> >> +   case IMAGE_FORMAT_LEGACY:
> >> +   return (image_get_image_size((image_header_t *)img_addr)
> >> +   + 0x1000 - 1)  & ~(0x1000 - 1);
> >> +#endif
> >> +#if IMAGE_ENABLE_FIT
> >> +   case IMAGE_FORMAT_FIT:
> >> +   return (fit_get_size(buf) + 0x1000 - 1)  & ~(0x1000 - 1);
> >> +#endif
> >> +   default:
> >> +   return 0;
> >> +   }
> >> +}
> >
> >
> > Do you have more details about the image header I should use here?
>
> Is the image signed using CST or similar tool? Is so, the signature data
> (HAB data: CSF, Certs and signature) pads at the end of the kernel
> image.

Yes, my Kernel image contains an IVT and is signed with CST. The image
layout looks like link below:
https://pastebin.com/5qEt7ETa

>
> >
> > I'm trying to get the IVT offset for my Kernel image based on NXP
> > 4.9.11_2.0.0_GA Linux release loaded at 0x8080:
> >
> > => fatload mmc 0:1 0x8080 zImage
> > => hab_auth_img 0x8080 
>
> Length for hab_auth_img is still mandatory. Length hear means the file
> size or total length of the image, this is required for the HAB API to
> authenticate (HAB_RVT_AUTHENTICATE_IMAGE).

Oh ok, I understood the scenario right now.

From my first overview I thought we would add IVT_SIZE + CSF_PAD_SIZE
in ivt_offset to calculate the image length, similar approach we have
in spl.c:
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-imx/spl.c;h=a20b30d154d788e4ebd4e22e9a6568a4f24c057e;hb=HEAD#l226

In this case only load addr would be necessary.

>
> >
> > The zImage size in Header looks correct (0x00726690), but
> > get_image_ivt_offset() is returning 0x0
>
> Looks like IVT offset is not found in the image.
>
> >
> > $ hexdump zImage | head
> > 000  e1a0  e1a0  e1a0  e1a0
> > *
> > 020 0003 ea00 2818 016f   6690 0072
> > 030 0201 0403 9000 e10f 04f8 eb00 7001 e1a0
> > 040 8002 e1a0 2000 e10f 0003 e312 0001 1a00
> >
> > Seems that genimg_get_format() is returning 0x0.
>
> Image is not signed?

No, my zImage is signed.

>
> >
> > Any ideias if I'm missing something?
> >
> >> +
> >>   static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
> >>   char * const argv[])
> >>   {
> >>  ulong   addr, length, ivt_offset;
> >>  int rcode = 0;
> >>
> >> -   if (argc < 4)
> >> +   if (argc < 3)
> >
> > I think we can also change here to argc < 2, the function
> > get_image_ivt_offset() only requires the img addr now.
>
> No, length is mandatory for authentication. To brief, this patch just
> removes the ivt_offset as argument and make it optional. This is needed
> because, in images like FIT, the location of the ivt header varies
> dynamically depending on the total number of images clubbed.
>
> In such cases, the existing hab_auth_img is hard to use as ivt header
> offset needs to be pre-calculated everytime and fed into.

Yes I understood your scena

Re: [U-Boot] [PATCH v3 0/9] Stop AXP from crashing when enabling LDO3

[Priit Laes]

On Wed, Nov 21, 2018 at 08:05:24PM +0200, Priit Laes wrote:
> This is a resend/v2 of a "Stop AXP from crashing when enabling LDO3" series,
> posted by Olliver Schinagl in March 2017. Unfortunately it never got past
> initial discussion [1], but most Olimex Lime2 boards are still running
> into this bug.

Well, this is actually v3. Missed this paragraph when pushing out v3.

> When powering up an AXP209, the default value for LDO3 output is enabled. This
> works fine. However if for whatever reason, LDO3 is disabled, for example by 
> OS
> during reboot and u-boot enables LDO3 again, the PMIC shuts down (without
> setting an interrupt) causing the board to hang. This behavior has been seen
> from Linux as well, u-boot disables LDO3 as a default value, the kernel 
> enables
> it per its DTS, the kernel hangs as the PMIC gets shut down.
> 
> The root cause is that some boards have too high capacitance on the LDO3 
> output
> port causing inrush currents exceeding the maximum of the AXP209.
> 
> The fix is to turn on the LDO3 at the lowest possible voltage and then set the
> final voltage.
> 
> If the capacitance is really big (due to a connected device for example) the
> AXP209 also features VRC, or Voltage Rate Control, allowing voltage to ramp up
> even slower.
> 
> Similar changes need to be also implemented in the operating system driver
> side when driver needs to toggle power for the ALDO3 regulator.
> 
> This patch series implements the above with a few tiny cleanups.
> 
> The initial discussion with some scope screenshots can be found in the
> linux-sunxi mailing list [0].
> 
> And the initial series were posted to u-boot mailing list [1].
> 
> Signed-off-by: Olliver Schinagl 
> Signed-off-by: Priit Laes 
> 
> [0] https://groups.google.com/forum/m/#!topic/linux-sunxi/EDvEsbHHqQI
> [1] https://lists.denx.de/pipermail/u-boot/2017-March/282789.html
> 
> --
> Changes since v2:
> - Collected Acked-by tags, patches 1,3-5 are now ripe for picking.
> - Olliver fixed wrong code in patch 2, thanks for Maxime for spotting
> - Fixed checkpatch error in patch 5
> - Expanded commit message for patch 6
> 
> Changes from initial submission:
> - Rebased on top of latest master and fixed conflicts
> - Added comments about datasheet errors for patch 6
> - Fixed some typos and checkpatch errors
> - Added patch to Olimex Lime2 eMMC board
> 
> Olliver Schinagl (8):
>   sunxi: board: Print error after power initialization fails
>   sunxi: pmic_bus: Decrease boot time by not writing duplicate data
>   power: axp209: Use BIT() macro
>   power: axp209: Define the chip version mask
>   power: axp209: Reduce magic values by adding defines for LDO[234]
>   power: axp209: Add support for voltage rate control on LDO3
>   power: axp209: Limit inrush current for broken boards
>   arm: sunxi: Reduce inrush current on Olimex OLinuXino-A20-Lime2
> 
> Priit Laes (1):
>   arm: sunxi: Reduce inrush current on Olimex OLinuXino-A20-Lime2-eMMC
> 
>  arch/arm/mach-sunxi/pmic_bus.c |  6 ++-
>  board/sunxi/board.c| 18 +++---
>  configs/A20-OLinuXino-Lime2-eMMC_defconfig |  2 +-
>  configs/A20-OLinuXino-Lime2_defconfig  |  2 +-
>  drivers/power/Kconfig  | 43 ++-
>  drivers/power/axp209.c | 66 ++
>  include/axp209.h   | 70 +--
>  7 files changed, 172 insertions(+), 35 deletions(-)
> 
> base-commit: a3e1653ddeb02f39481eba572275016171e9670c
> -- 
> git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 9/9] arm: sunxi: Reduce inrush current on Olimex OLinuXino-A20-Lime2-eMMC

[Priit Laes]

From: Priit Laes 

The lime2 features a too large capacitor on the LDO3 output, which
causes the PMIC to shutdown when enabling power. To be able to still
boot up however, we must gradually enable power on LDO3 for this board.

We do this by enabling both the inrush quirk and the maximum slope the
AXP209 supports.

Signed-off-by: Priit Laes 
---
 configs/A20-OLinuXino-Lime2-eMMC_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig 
b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
index 467ca4e..dee8d02 100644
--- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig
+++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
@@ -26,7 +26,9 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_RGMII=y
 CONFIG_MII=y
 CONFIG_SUN7I_GMAC=y
+CONFIG_AXP_ALDO3_INRUSH_QUIRK=y
 CONFIG_AXP_ALDO3_VOLT=2800
+CONFIG_AXP_ALDO3_VOLT_SLOPE_08=y
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_SCSI=y
 CONFIG_USB_EHCI_HCD=y
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 4/9] power: axp209: Define the chip version mask

[Priit Laes]

From: Olliver Schinagl 

Use a define for the chip version mask on the axp209.

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 
Acked-by: Maxime Ripard 
---
 drivers/power/axp209.c | 5 +
 include/axp209.h   | 2 ++
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index 6de5ec6..e13c762 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -153,10 +153,7 @@ int axp_init(void)
if (rc)
return rc;
 
-   /* Low 4 bits is chip version */
-   ver &= 0x0f;
-
-   if (ver != 0x1)
+   if ((ver & AXP209_CHIP_VERSION_MASK) != 0x1)
return -EINVAL;
 
/* Mask all interrupts */
diff --git a/include/axp209.h b/include/axp209.h
index 3a4fc28..43e3873 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -25,6 +25,8 @@ enum axp209_reg {
 #define AXP209_POWER_STATUS_ON_BY_DC   BIT(0)
 #define AXP209_POWER_STATUS_VBUS_USABLEBIT(4)
 
+#define AXP209_CHIP_VERSION_MASK   0x0f
+
 #define AXP209_OUTPUT_CTRL_EXTEN   BIT(0)
 #define AXP209_OUTPUT_CTRL_DCDC3   BIT(1)
 #define AXP209_OUTPUT_CTRL_LDO2BIT(2)
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 7/9] power: axp209: Limit inrush current for broken boards

[Priit Laes]

From: Olliver Schinagl 

Some boards feature a capacitance on LDO3's output that is too large,
causing inrush currents which as a result, shut down the AXP209. This
has been reported before, without knowing the actual cause.

A fix appeared to be done with
commit 0e6e34ac8dbb ("sunxi: Olimex A20 boards: Enable LDO3 and LDO4 
regulators").

The description there is a bit misleading, the kernel does not hang
during AXP209 initialization, the PMIC shuts down, causing voltages to
drop and thus the whole system freezes.

While the AXP209 does have the ability to ramp up the voltage slowly, to
reduce these inrush currents, the voltage rate control (VRC) however is
not applicable when switching on the LDO3 output. Only when going from
an enabled lower voltage setting, to a higher voltage setting is the VRC
in effect.

To work around this problem, we set LDO3 to the lowest possible setting
of 0.7 V if it was not yet enabled, and then let the VRC (if enabled) do
its thing. It should be noted, that for some undocumented reason, there
is a short delay needed between setting the LDO3 voltage register and
enabling the power. One would expect that this delay ought to be just
after enabling the output power at 0.7 V, but this did not work.

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 
---
 drivers/power/Kconfig  |  9 +
 drivers/power/axp209.c | 23 +++
 2 files changed, 32 insertions(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index e83036f..9495dca 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -231,6 +231,15 @@ config AXP_ALDO3_VOLT_SLOPE_08
 
 endchoice
 
+config AXP_ALDO3_INRUSH_QUIRK
+   bool "axp pmic (a)ldo3 inrush quirk"
+   depends on AXP209_POWER
+   default n
+   ---help---
+   The reference design denotes a value of 4.7 uF for the output capacitor
+   of LDO3. Some boards have too high capacitance causing  an inrush 
current
+   and resulting an AXP209 shutdown.
+
 config AXP_ALDO4_VOLT
int "axp pmic (a)ldo4 voltage"
depends on AXP209_POWER
diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index cf138fc..67b4209 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -122,6 +122,29 @@ int axp_set_aldo3(unsigned int mvolt)
if (rc)
return rc;
 
+#ifdef CONFIG_AXP_ALDO3_INRUSH_QUIRK
+   /*
+* On some boards, LDO3 has a too big capacitor installed. When
+* turning on LDO3, this causes the AXP209 to shutdown on
+* voltages over 1.9 volt. As a workaround, we enable LDO3
+* first with the lowest possible voltage. If this still causes
+* high inrush currents, the voltage slope should be increased.
+*/
+   rc = pmic_bus_read(AXP209_OUTPUT_CTRL, &cfg);
+   if (rc)
+   return rc;
+
+   if (!(cfg & AXP209_OUTPUT_CTRL_LDO3)) {
+   rc = pmic_bus_write(AXP209_LDO3_VOLTAGE, 0x0); /* 0.7 Volt */
+   mdelay(1);
+   rc |= pmic_bus_setbits(AXP209_OUTPUT_CTRL,
+  AXP209_OUTPUT_CTRL_LDO3);
+
+   if (rc)
+   return rc;
+   }
+#endif
+
if (mvolt == -1) {
cfg = AXP209_LDO3_VOLTAGE_FROM_LDO3IN;
} else {
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 3/9] power: axp209: Use BIT() macro

[Priit Laes]

From: Olliver Schinagl 

Use the standard BIT() macro for bitfield definitions in headers.

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 
Acked-by: Maxime Ripard 
---
 include/axp209.h | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/include/axp209.h b/include/axp209.h
index b7de6ed..3a4fc28 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -3,6 +3,8 @@
  * (C) Copyright 2012 Henrik Nordstrom 
  */
 
+#include 
+
 enum axp209_reg {
AXP209_POWER_STATUS = 0x00,
AXP209_CHIP_VERSION = 0x03,
@@ -20,29 +22,29 @@ enum axp209_reg {
AXP209_SHUTDOWN = 0x32,
 };
 
-#define AXP209_POWER_STATUS_ON_BY_DC   (1 << 0)
-#define AXP209_POWER_STATUS_VBUS_USABLE(1 << 4)
+#define AXP209_POWER_STATUS_ON_BY_DC   BIT(0)
+#define AXP209_POWER_STATUS_VBUS_USABLEBIT(4)
 
-#define AXP209_OUTPUT_CTRL_EXTEN   (1 << 0)
-#define AXP209_OUTPUT_CTRL_DCDC3   (1 << 1)
-#define AXP209_OUTPUT_CTRL_LDO2(1 << 2)
-#define AXP209_OUTPUT_CTRL_LDO4(1 << 3)
-#define AXP209_OUTPUT_CTRL_DCDC2   (1 << 4)
-#define AXP209_OUTPUT_CTRL_LDO3(1 << 6)
+#define AXP209_OUTPUT_CTRL_EXTEN   BIT(0)
+#define AXP209_OUTPUT_CTRL_DCDC3   BIT(1)
+#define AXP209_OUTPUT_CTRL_LDO2BIT(2)
+#define AXP209_OUTPUT_CTRL_LDO4BIT(3)
+#define AXP209_OUTPUT_CTRL_DCDC2   BIT(4)
+#define AXP209_OUTPUT_CTRL_LDO3BIT(6)
 
-#define AXP209_IRQ5_PEK_UP (1 << 6)
-#define AXP209_IRQ5_PEK_DOWN   (1 << 5)
+#define AXP209_IRQ5_PEK_UP BIT(6)
+#define AXP209_IRQ5_PEK_DOWN   BIT(5)
 
-#define AXP209_POWEROFF(1 << 7)
+#define AXP209_POWEROFFBIT(7)
 
 /* For axp_gpio.c */
 #define AXP_POWER_STATUS   0x00
-#define AXP_POWER_STATUS_VBUS_PRESENT  (1 << 5)
+#define AXP_POWER_STATUS_VBUS_PRESENT  BIT(5)
 #define AXP_GPIO0_CTRL 0x90
 #define AXP_GPIO1_CTRL 0x92
 #define AXP_GPIO2_CTRL 0x93
-#define AXP_GPIO_CTRL_OUTPUT_LOW   0x00 /* Drive pin low */
-#define AXP_GPIO_CTRL_OUTPUT_HIGH  0x01 /* Drive pin high */
-#define AXP_GPIO_CTRL_INPUT0x02 /* Input */
+#define AXP_GPIO_CTRL_OUTPUT_LOW   0x00 /* Drive pin low */
+#define AXP_GPIO_CTRL_OUTPUT_HIGH  0x01 /* Drive pin high */
+#define AXP_GPIO_CTRL_INPUT0x02 /* Input */
 #define AXP_GPIO_STATE 0x94
-#define AXP_GPIO_STATE_OFFSET  4
+#define AXP_GPIO_STATE_OFFSET  4
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 5/9] power: axp209: Reduce magic values by adding defines for LDO[234]

[Priit Laes]

From: Olliver Schinagl 

The AXP209 has a few 'magisc-ish' values that are better served with
clear defines.

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 
Acked-by: Maxime Ripard 
---
 drivers/power/axp209.c | 14 +++---
 include/axp209.h   | 13 +
 2 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index e13c762..819b168 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -81,8 +81,7 @@ int axp_set_aldo2(unsigned int mvolt)
if (rc)
return rc;
 
-   /* LDO2 configuration is in upper 4 bits */
-   reg = (reg & 0x0f) | (cfg << 4);
+   reg |= AXP209_LDO24_LDO2_SET(reg, cfg);
rc = pmic_bus_write(AXP209_LDO24_VOLTAGE, reg);
if (rc)
return rc;
@@ -99,10 +98,12 @@ int axp_set_aldo3(unsigned int mvolt)
return pmic_bus_clrbits(AXP209_OUTPUT_CTRL,
AXP209_OUTPUT_CTRL_LDO3);
 
-   if (mvolt == -1)
-   cfg = 0x80; /* determined by LDO3IN pin */
-   else
+   if (mvolt == -1) {
+   cfg = AXP209_LDO3_VOLTAGE_FROM_LDO3IN;
+   } else {
cfg = axp209_mvolt_to_cfg(mvolt, 700, 3500, 25);
+   cfg = AXP209_LDO3_VOLTAGE_SET(cfg);
+   }
 
rc = pmic_bus_write(AXP209_LDO3_VOLTAGE, cfg);
if (rc)
@@ -131,8 +132,7 @@ int axp_set_aldo4(unsigned int mvolt)
if (rc)
return rc;
 
-   /* LDO4 configuration is in lower 4 bits */
-   reg = (reg & 0xf0) | (cfg << 0);
+   reg |= AXP209_LDO24_LDO4_SET(reg, cfg);
rc = pmic_bus_write(AXP209_LDO24_VOLTAGE, reg);
if (rc)
return rc;
diff --git a/include/axp209.h b/include/axp209.h
index 43e3873..dc27d65 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -34,6 +34,19 @@ enum axp209_reg {
 #define AXP209_OUTPUT_CTRL_DCDC2   BIT(4)
 #define AXP209_OUTPUT_CTRL_LDO3BIT(6)
 
+#define AXP209_LDO24_LDO2_MASK 0xf0
+#define AXP209_LDO24_LDO4_MASK 0x0f
+#define AXP209_LDO24_LDO2_SET(reg, cfg)\
+   (((reg) & ~AXP209_LDO24_LDO2_MASK) | \
+   (((cfg) << 4) & AXP209_LDO24_LDO2_MASK))
+#define AXP209_LDO24_LDO4_SET(reg, cfg)\
+   (((reg) & ~AXP209_LDO24_LDO4_MASK) | \
+   (((cfg) << 0) & AXP209_LDO24_LDO4_MASK))
+
+#define AXP209_LDO3_VOLTAGE_FROM_LDO3INBIT(7)
+#define AXP209_LDO3_VOLTAGE_MASK   0x7f
+#define AXP209_LDO3_VOLTAGE_SET(x) ((x) & AXP209_LDO3_VOLTAGE_MASK)
+
 #define AXP209_IRQ5_PEK_UP BIT(6)
 #define AXP209_IRQ5_PEK_DOWN   BIT(5)
 
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 2/9] sunxi: pmic_bus: Decrease boot time by not writing duplicate data

[Priit Laes]

From: Olliver Schinagl 

When we clear a pmic_bus bit, we do a read-modify-write operation.
We waste some time however, by writing back the exact samea value
that was already set in the chip. Let us thus only do the write
in case data was changed.

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 

--
Changes since v2:
- Fix code for pmic_bus_setbits
---
 arch/arm/mach-sunxi/pmic_bus.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
index 5d91d7e..dea42de 100644
--- a/arch/arm/mach-sunxi/pmic_bus.c
+++ b/arch/arm/mach-sunxi/pmic_bus.c
@@ -101,6 +101,9 @@ int pmic_bus_setbits(u8 reg, u8 bits)
if (ret)
return ret;
 
+   if ((val & bits) == bits)
+   return 0;
+
val |= bits;
return pmic_bus_write(reg, val);
 }
@@ -114,6 +117,9 @@ int pmic_bus_clrbits(u8 reg, u8 bits)
if (ret)
return ret;
 
+   if (!(val & bits))
+   return 0;
+
val &= ~bits;
return pmic_bus_write(reg, val);
 }
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 8/9] arm: sunxi: Reduce inrush current on Olimex OLinuXino-A20-Lime2

[Priit Laes]

From: Olliver Schinagl 

The lime2 features a too large capacitor on the LDO3 output, which
causes the PMIC to shutdown when enabling power. To be able to still
boot up however, we must gradually enable power on LDO3 for this board.

We do this by enabling both the inrush quirk and the maximum slope the
AXP209 supports.

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 
---
 configs/A20-OLinuXino-Lime2_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index fa58a6d..0c04ae6 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -25,7 +25,9 @@ CONFIG_ETH_DESIGNWARE=y
 CONFIG_RGMII=y
 CONFIG_MII=y
 CONFIG_SUN7I_GMAC=y
+CONFIG_AXP_ALDO3_INRUSH_QUIRK=y
 CONFIG_AXP_ALDO3_VOLT=2800
+CONFIG_AXP_ALDO3_VOLT_SLOPE_08=y
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_SCSI=y
 CONFIG_USB_EHCI_HCD=y
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 6/9] power: axp209: Add support for voltage rate control on LDO3

[Priit Laes]

From: Olliver Schinagl 

The AXP209 LDO3 regulator supports voltage rate control, or can set a
slew rate.

This allows for the power to gradually rise up to the desired voltage,
instead of spiking up as fast as possible. Reason to have this can be
to reduce the inrush currents for example.

There are 3 slopes to choose from, the default, 'none' is a voltage rise
of 0.0167 V/uS, a 1.6 mV/uS and a 0.8 mV/uS voltage rise.

In ideal world (where vendors follow the recommended design guidelines)
this setting should not be enabled by default. Unless of course AXP209
crashes instead of reporting overcurrent condition as it normally should
do in this case.

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 
---
 drivers/power/Kconfig  | 34 ++
 drivers/power/axp209.c | 24 
 include/axp209.h   | 21 +
 3 files changed, 79 insertions(+)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 1a38524..e83036f 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -197,6 +197,40 @@ config AXP_ALDO3_VOLT
On A83T / H8 boards aldo3 is AVCC, VCC-PL, and VCC-LED, and should be
3.0V.
 
+choice
+   prompt "axp pmic (a)ldo3 voltage rate control"
+   depends on AXP209_POWER
+   default AXP_ALDO3_VOLT_SLOPE_NONE
+   ---help---
+   The AXP can slowly ramp up voltage to reduce the inrush current when
+   changing voltages.
+   Note, this does not apply when enabling/disabling LDO3. See
+   "axp pmic (a)ldo3 inrush quirk" below to enable a slew rate to limit
+   inrush current on broken board designs.
+
+config AXP_ALDO3_VOLT_SLOPE_NONE
+   bool "No voltage slope"
+   ---help---
+   Tries to reach the next voltage setting near instantaneously. 
Measurements
+   indicate that this is about 0.0167 V/uS.
+
+config AXP_ALDO3_VOLT_SLOPE_16
+   bool "1.6 mV per uS"
+   ---help---
+   Increases the voltage by 1.6 mV per uS until the final voltage has
+   been reached. Note that the scaling is in 25 mV steps and thus
+   the slew rate in reality is about 25 mV/31.250 uS.
+
+config AXP_ALDO3_VOLT_SLOPE_08
+   bool "0.8 mV per uS"
+   ---help---
+   Increases the voltage by 0.8 mV per uS until the final voltage has
+   been reached. Note that the scaling is in 25 mV steps however and thus
+   the slew rate in reality is about 25 mV/15.625 uS.
+   This is the slowest supported rate.
+
+endchoice
+
 config AXP_ALDO4_VOLT
int "axp pmic (a)ldo4 voltage"
depends on AXP209_POWER
diff --git a/drivers/power/axp209.c b/drivers/power/axp209.c
index 819b168..cf138fc 100644
--- a/drivers/power/axp209.c
+++ b/drivers/power/axp209.c
@@ -9,6 +9,16 @@
 #include 
 #include 
 
+#ifdef CONFIG_AXP_ALDO3_VOLT_SLOPE_08
+#  define AXP209_VRC_SLOPE AXP209_VRC_LDO3_800uV_uS
+#endif
+#ifdef CONFIG_AXP_ALDO3_VOLT_SLOPE_16
+#  define AXP209_VRC_SLOPE AXP209_VRC_LDO3_1600uV_uS
+#endif
+#if defined CONFIG_AXP_ALDO3_VOLT_SLOPE_NONE || !defined AXP209_VRC_SLOPE
+#  define AXP209_VRC_SLOPE 0x00
+#endif
+
 static u8 axp209_mvolt_to_cfg(int mvolt, int min, int max, int div)
 {
if (mvolt < min)
@@ -98,6 +108,20 @@ int axp_set_aldo3(unsigned int mvolt)
return pmic_bus_clrbits(AXP209_OUTPUT_CTRL,
AXP209_OUTPUT_CTRL_LDO3);
 
+   /*
+* Some boards have trouble reaching the target voltage without causing
+* great inrush currents. To prevent this, boards can enable a certain
+* slope to ramp up voltage. Note, this only works when changing an
+* already active power rail. When toggling power on, the AXP ramps up
+* steeply at 0.0167 V/uS.
+*/
+   rc = pmic_bus_read(AXP209_VRC_DCDC2_LDO3, &cfg);
+   cfg = AXP209_VRC_LDO3_SLOPE_SET(cfg, AXP209_VRC_SLOPE);
+   rc |= pmic_bus_write(AXP209_VRC_DCDC2_LDO3, cfg);
+
+   if (rc)
+   return rc;
+
if (mvolt == -1) {
cfg = AXP209_LDO3_VOLTAGE_FROM_LDO3IN;
} else {
diff --git a/include/axp209.h b/include/axp209.h
index dc27d65..f4f1b2f 100644
--- a/include/axp209.h
+++ b/include/axp209.h
@@ -10,6 +10,7 @@ enum axp209_reg {
AXP209_CHIP_VERSION = 0x03,
AXP209_OUTPUT_CTRL = 0x12,
AXP209_DCDC2_VOLTAGE = 0x23,
+   AXP209_VRC_DCDC2_LDO3 = 0x25,
AXP209_DCDC3_VOLTAGE = 0x27,
AXP209_LDO24_VOLTAGE = 0x28,
AXP209_LDO3_VOLTAGE = 0x29,
@@ -34,6 +35,26 @@ enum axp209_reg {
 #define AXP209_OUTPUT_CTRL_DCDC2   BIT(4)
 #define AXP209_OUTPUT_CTRL_LDO3BIT(6)
 
+/*
+ * AXP209 datasheet contains wrong information about LDO3 VRC:
+ * - VRC is actually enabled when BIT(1) is True
+ * - VRC is actually not enabled by default (BIT(3) = 0 after reset)
+ */
+#define AXP209_VRC_LDO3_EN BIT(3)
+#define AXP209_VRC_DCDC2_ENBIT(2)
+#define AXP209_VRC_LDO3_800uV_uS   (BIT(1) 

[U-Boot] [PATCH v3 1/9] sunxi: board: Print error after power initialization fails

[Priit Laes]

From: Olliver Schinagl 

Currently during init, we enable all power, then enable the dram and
after that check whether there was an error during power-up.

This makes little sense, we should enable power and then check if power
was brought up properly before we continue to initialize other things.

This patch moves the DRAM init after the power failure check.

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 
Acked-by: Maxime Ripard 
---
 board/sunxi/board.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 64ccbc7..26284db 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -637,13 +637,6 @@ void sunxi_board_init(void)
power_failed |= axp_set_sw(IS_ENABLED(CONFIG_AXP_SW_ON));
 #endif
 #endif
-   printf("DRAM:");
-   gd->ram_size = sunxi_dram_init();
-   printf(" %d MiB\n", (int)(gd->ram_size >> 20));
-   if (!gd->ram_size)
-   hang();
-
-   sunxi_spl_store_dram_size(gd->ram_size);
 
/*
 * Only clock up the CPU to full speed if we are reasonably
@@ -652,7 +645,16 @@ void sunxi_board_init(void)
if (!power_failed)
clock_set_pll1(CONFIG_SYS_CLK_FREQ);
else
-   printf("Failed to set core voltage! Can't set CPU frequency\n");
+   printf("Error setting up the power controller.\n"
+  "CPU frequency not set.\n");
+
+   printf("DRAM:");
+   gd->ram_size = sunxi_dram_init();
+   printf(" %d MiB\n", (int)(gd->ram_size >> 20));
+   if (!gd->ram_size)
+   hang();
+
+   sunxi_spl_store_dram_size(gd->ram_size);
 }
 #endif
 
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 0/9] Stop AXP from crashing when enabling LDO3

[Priit Laes]

This is a resend/v2 of a "Stop AXP from crashing when enabling LDO3" series,
posted by Olliver Schinagl in March 2017. Unfortunately it never got past
initial discussion [1], but most Olimex Lime2 boards are still running
into this bug.

When powering up an AXP209, the default value for LDO3 output is enabled. This
works fine. However if for whatever reason, LDO3 is disabled, for example by OS
during reboot and u-boot enables LDO3 again, the PMIC shuts down (without
setting an interrupt) causing the board to hang. This behavior has been seen
from Linux as well, u-boot disables LDO3 as a default value, the kernel enables
it per its DTS, the kernel hangs as the PMIC gets shut down.

The root cause is that some boards have too high capacitance on the LDO3 output
port causing inrush currents exceeding the maximum of the AXP209.

The fix is to turn on the LDO3 at the lowest possible voltage and then set the
final voltage.

If the capacitance is really big (due to a connected device for example) the
AXP209 also features VRC, or Voltage Rate Control, allowing voltage to ramp up
even slower.

Similar changes need to be also implemented in the operating system driver
side when driver needs to toggle power for the ALDO3 regulator.

This patch series implements the above with a few tiny cleanups.

The initial discussion with some scope screenshots can be found in the
linux-sunxi mailing list [0].

And the initial series were posted to u-boot mailing list [1].

Signed-off-by: Olliver Schinagl 
Signed-off-by: Priit Laes 

[0] https://groups.google.com/forum/m/#!topic/linux-sunxi/EDvEsbHHqQI
[1] https://lists.denx.de/pipermail/u-boot/2017-March/282789.html

--
Changes since v2:
- Collected Acked-by tags, patches 1,3-5 are now ripe for picking.
- Olliver fixed wrong code in patch 2, thanks for Maxime for spotting
- Fixed checkpatch error in patch 5
- Expanded commit message for patch 6

Changes from initial submission:
- Rebased on top of latest master and fixed conflicts
- Added comments about datasheet errors for patch 6
- Fixed some typos and checkpatch errors
- Added patch to Olimex Lime2 eMMC board

Olliver Schinagl (8):
  sunxi: board: Print error after power initialization fails
  sunxi: pmic_bus: Decrease boot time by not writing duplicate data
  power: axp209: Use BIT() macro
  power: axp209: Define the chip version mask
  power: axp209: Reduce magic values by adding defines for LDO[234]
  power: axp209: Add support for voltage rate control on LDO3
  power: axp209: Limit inrush current for broken boards
  arm: sunxi: Reduce inrush current on Olimex OLinuXino-A20-Lime2

Priit Laes (1):
  arm: sunxi: Reduce inrush current on Olimex OLinuXino-A20-Lime2-eMMC

 arch/arm/mach-sunxi/pmic_bus.c |  6 ++-
 board/sunxi/board.c| 18 +++---
 configs/A20-OLinuXino-Lime2-eMMC_defconfig |  2 +-
 configs/A20-OLinuXino-Lime2_defconfig  |  2 +-
 drivers/power/Kconfig  | 43 ++-
 drivers/power/axp209.c | 66 ++
 include/axp209.h   | 70 +--
 7 files changed, 172 insertions(+), 35 deletions(-)

base-commit: a3e1653ddeb02f39481eba572275016171e9670c
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] imx: hab: extend hab_auth_img to calculate ivt_offset

[Parthiban Nallathambi]

Hi Breno,

On 11/21/18 5:45 PM, Breno Matheus Lima wrote:

Hi Parthiban,

Em qua, 21 de nov de 2018 às 11:50, Parthiban Nallathambi  
escreveu:


Current implementation of hab_auth_img command needs ivt_offset to
authenticate the image. But ivt header is placed at the end of image
date after padding.

This leaves the usage of hab_auth_img command to fixed size or static
offset for ivt header. New function "get_image_ivt_offset" is introduced
to find the ivt offset during runtime. The case conditional check in this
function is same as boot_get_kernel in common/bootm.c

With this variable length image e.g. FIT image with any random size can
have IVT at the end and ivt_offset option can be left optional

Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script

Signed-off-by: Parthiban Nallathambi 
---

Notes:
 Changelog in v2:
 - Finding IVT offset doesn't need length. Removed the
 length argument from get_image_ivt_offset

  arch/arm/mach-imx/hab.c | 29 +++--
  1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index b88acd13da..dbfd692fa3 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -6,6 +6,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int flag, int 
argc,
 return 0;
  }

+static ulong get_image_ivt_offset(ulong img_addr)
+{
+   const void *buf;
+
+   buf = map_sysmem(img_addr, 0);
+   switch (genimg_get_format(buf)) {
+#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
+   case IMAGE_FORMAT_LEGACY:
+   return (image_get_image_size((image_header_t *)img_addr)
+   + 0x1000 - 1)  & ~(0x1000 - 1);
+#endif
+#if IMAGE_ENABLE_FIT
+   case IMAGE_FORMAT_FIT:
+   return (fit_get_size(buf) + 0x1000 - 1)  & ~(0x1000 - 1);
+#endif
+   default:
+   return 0;
+   }
+}



Do you have more details about the image header I should use here?


Is the image signed using CST or similar tool? Is so, the signature data
(HAB data: CSF, Certs and signature) pads at the end of the kernel
image.



I'm trying to get the IVT offset for my Kernel image based on NXP
4.9.11_2.0.0_GA Linux release loaded at 0x8080:

=> fatload mmc 0:1 0x8080 zImage
=> hab_auth_img 0x8080 


Length for hab_auth_img is still mandatory. Length hear means the file
size or total length of the image, this is required for the HAB API to
authenticate (HAB_RVT_AUTHENTICATE_IMAGE).



The zImage size in Header looks correct (0x00726690), but
get_image_ivt_offset() is returning 0x0


Looks like IVT offset is not found in the image.



$ hexdump zImage | head
000  e1a0  e1a0  e1a0  e1a0
*
020 0003 ea00 2818 016f   6690 0072
030 0201 0403 9000 e10f 04f8 eb00 7001 e1a0
040 8002 e1a0 2000 e10f 0003 e312 0001 1a00

Seems that genimg_get_format() is returning 0x0.


Image is not signed?



Any ideias if I'm missing something?


+
  static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
  char * const argv[])
  {
 ulong   addr, length, ivt_offset;
 int rcode = 0;

-   if (argc < 4)
+   if (argc < 3)


I think we can also change here to argc < 2, the function
get_image_ivt_offset() only requires the img addr now.


No, length is mandatory for authentication. To brief, this patch just
removes the ivt_offset as argument and make it optional. This is needed
because, in images like FIT, the location of the ivt header varies
dynamically depending on the total number of images clubbed.

In such cases, the existing hab_auth_img is hard to use as ivt header
offset needs to be pre-calculated everytime and fed into.




 return CMD_RET_USAGE;

 addr = simple_strtoul(argv[1], NULL, 16);
 length = simple_strtoul(argv[2], NULL, 16);
-   ivt_offset = simple_strtoul(argv[3], NULL, 16);
+   if (argc == 3)


argc ==2


No, length is needed as stated above.





--
Thanks,
Parthiban N

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

Re: [U-Boot] [PATCH 36/93] arm: Remove nas220 board

[Tom Rini]

On Wed, Nov 21, 2018 at 03:26:10PM +, Evgeni Dobrev wrote:

> NAK.
> 
> I was not aware of the deadline.
> Board is being maintained. I will have a look into next few days and
> provide a patch for converting if necessary.

In this case what you'll need to do is switch to using CONFIG_OF_CONTROL
(and setting a device tree to use).  You'll need to enable DM_USB for
USB_STORAGE to build.

-- 
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 36/93] arm: Remove nas220 board

[Evgeni Dobrev]

NAK.

I was not aware of the deadline.
Board is being maintained. I will have a look into next few days and provide a 
patch for converting if necessary.

Regards,
Evgeni

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

Re: [U-Boot] [PATCH v3 1/3] riscv: Add kconfig option to run u-boot in S-mode

[Palmer Dabbelt]

On Tue, 20 Nov 2018 19:41:10 PST (-0800), a...@brainfault.org wrote:

This patch adds kconfig option RISCV_SMODE to run u-boot in
S-mode. When this opition is enabled we use s CSRs instead
of m CSRs.

It is important to note that there is no equivalent S-mode CSR
for misa and mhartid CSRs so we expect M-mode runtime firmware
(BBL or equivalent) to emulate misa and mhartid CSR read.

In-future, we will have more patches to avoid accessing misa and
mhartid CSRs from S-mode.


Ya, I don't like this.  Our current boot protocol puts mhartid in a1 upon 
entering the supervisor, and allows the detection of misa via a device tree 
pointer provided in a0.  

As long as everyone agrees this isn't what we're actually looking for then I'm 
fine with the patch, I just don't want to end up requiring this "M mode 
emulates some CSRs for S mode" interface.  Since we don't have an actual 
platform spec we've got to be careful to avoid a bunch of defacto interfaces 
that we'll need to support later.




Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
---
 arch/riscv/Kconfig |  5 +
 arch/riscv/cpu/start.S | 33 +
 2 files changed, 38 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 3e0af55e71..8f2139ff60 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -55,6 +55,11 @@ config RISCV_ISA_C
 config RISCV_ISA_A
def_bool y

+config RISCV_SMODE
+   bool "Run in S-Mode"
+   help
+ Enable this option to build an U-Boot for RISC-V S-Mode
+
 config 32BIT
bool

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 5af189b338..e4276e8e19 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -39,10 +39,18 @@ _start:
mv  s1, a1

la  t0, trap_entry
+#ifdef CONFIG_RISCV_SMODE
+   csrwstvec, t0
+#else
csrwmtvec, t0
+#endif

/* mask all interrupts */
+#ifdef CONFIG_RISCV_SMODE
+   csrwsie, zero
+#else
csrwmie, zero
+#endif

/* Enable cache */
jal icache_enable
@@ -164,7 +172,11 @@ fix_rela_dyn:
 */
la  t0, trap_entry
add t0, t0, t6
+#ifdef CONFIG_RISCV_SMODE
+   csrwstvec, t0
+#else
csrwmtvec, t0
+#endif

 clear_bss:
la  t0, __bss_start /* t0 <- rel __bss_start in FLASH */
@@ -236,17 +248,34 @@ trap_entry:
SREGx29, 29*REGBYTES(sp)
SREGx30, 30*REGBYTES(sp)
SREGx31, 31*REGBYTES(sp)
+#ifdef CONFIG_RISCV_SMODE
+   csrra0, scause
+   csrra1, sepc
+#else
csrra0, mcause
csrra1, mepc
+#endif
mv  a2, sp
jal handle_trap
+#ifdef CONFIG_RISCV_SMODE
+   csrwsepc, a0
+#else
csrwmepc, a0
+#endif

+#ifdef CONFIG_RISCV_SMODE
+/*
+ * Remain in S-mode after sret
+ */
+   li  t0, SSTATUS_SPP
+   csrssstatus, t0
+#else
 /*
  * Remain in M-mode after mret
  */
li  t0, MSTATUS_MPP
csrsmstatus, t0
+#endif
LREGx1, 1*REGBYTES(sp)
LREGx2, 2*REGBYTES(sp)
LREGx3, 3*REGBYTES(sp)
@@ -279,4 +308,8 @@ trap_entry:
LREGx30, 30*REGBYTES(sp)
LREGx31, 31*REGBYTES(sp)
addisp, sp, 32*REGBYTES
+#ifdef CONFIG_RISCV_SMODE
+   sret
+#else
mret
+#endif

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

Re: [U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Simon Goldschmidt]

On 21.11.2018 16:48, Simon Goldschmidt wrote:

On 21.11.2018 16:41, Wolfgang Denk wrote:

Dear Simon,

In message  
you wrote:

Only if you use signed images.  With plain U-Boot, there is not even
a checksum for it...

When SPL loads U-Boot from a legacy image, isn't there a CRC involved over
the full image including the environment?

Yes, but when - for example - the compiled in default environment
gets corrupted while loading from the storage device or while
writing it to RAM, there will be zero check when reading it.

Hmm, on my board, SPL loads U-Boot from NOR to SDRAM, then checks the
uimage CRC. I'd say this is enough checks. That might not hold for all
boards though.


Oops, I'll have to take that back. I just checked and SPL *does* boot 
the uImage U-Boot also if I deliberately corrupt the CRC of the image. 
So you're right, it seems to be not protected at all!


Is that expected behaviour or a bug?


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

Re: [U-Boot] [PATCH] omap3: beagle: Enable DM_MMC and BLK for u-boot only, not SPL

[Tom Rini]

On Wed, Nov 21, 2018 at 04:13:20PM +0100, Guillaume GARDET wrote:

> Also disable USB_STORAGE as it is not ready for the switch.
> Tested on a Beagleboard xM rev. B.
> 
> Signed-off-by: Guillaume GARDET 
> 
> Cc: Tom Rini 
> Cc: Simon Glass 

In the case of USB_STORAGE we need to turn on DM_USB and then it works.

-- 
Tom


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

Re: [U-Boot] [PATCH v2] imx: hab: extend hab_auth_img to calculate ivt_offset

[Breno Matheus Lima]

Hi Parthiban,

Em qua, 21 de nov de 2018 às 11:50, Parthiban Nallathambi  
escreveu:
>
> Current implementation of hab_auth_img command needs ivt_offset to
> authenticate the image. But ivt header is placed at the end of image
> date after padding.
>
> This leaves the usage of hab_auth_img command to fixed size or static
> offset for ivt header. New function "get_image_ivt_offset" is introduced
> to find the ivt offset during runtime. The case conditional check in this
> function is same as boot_get_kernel in common/bootm.c
>
> With this variable length image e.g. FIT image with any random size can
> have IVT at the end and ivt_offset option can be left optional
>
> Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script
>
> Signed-off-by: Parthiban Nallathambi 
> ---
>
> Notes:
> Changelog in v2:
> - Finding IVT offset doesn't need length. Removed the
> length argument from get_image_ivt_offset
>
>  arch/arm/mach-imx/hab.c | 29 +++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
> index b88acd13da..dbfd692fa3 100644
> --- a/arch/arm/mach-imx/hab.c
> +++ b/arch/arm/mach-imx/hab.c
> @@ -6,6 +6,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -302,18 +304,41 @@ static int do_hab_status(cmd_tbl_t *cmdtp, int flag, 
> int argc,
> return 0;
>  }
>
> +static ulong get_image_ivt_offset(ulong img_addr)
> +{
> +   const void *buf;
> +
> +   buf = map_sysmem(img_addr, 0);
> +   switch (genimg_get_format(buf)) {
> +#if defined(CONFIG_IMAGE_FORMAT_LEGACY)
> +   case IMAGE_FORMAT_LEGACY:
> +   return (image_get_image_size((image_header_t *)img_addr)
> +   + 0x1000 - 1)  & ~(0x1000 - 1);
> +#endif
> +#if IMAGE_ENABLE_FIT
> +   case IMAGE_FORMAT_FIT:
> +   return (fit_get_size(buf) + 0x1000 - 1)  & ~(0x1000 - 1);
> +#endif
> +   default:
> +   return 0;
> +   }
> +}


Do you have more details about the image header I should use here?

I'm trying to get the IVT offset for my Kernel image based on NXP
4.9.11_2.0.0_GA Linux release loaded at 0x8080:

=> fatload mmc 0:1 0x8080 zImage
=> hab_auth_img 0x8080 

The zImage size in Header looks correct (0x00726690), but
get_image_ivt_offset() is returning 0x0

$ hexdump zImage | head
000  e1a0  e1a0  e1a0  e1a0
*
020 0003 ea00 2818 016f   6690 0072
030 0201 0403 9000 e10f 04f8 eb00 7001 e1a0
040 8002 e1a0 2000 e10f 0003 e312 0001 1a00

Seems that genimg_get_format() is returning 0x0.

Any ideias if I'm missing something?

> +
>  static int do_authenticate_image(cmd_tbl_t *cmdtp, int flag, int argc,
>  char * const argv[])
>  {
> ulong   addr, length, ivt_offset;
> int rcode = 0;
>
> -   if (argc < 4)
> +   if (argc < 3)

I think we can also change here to argc < 2, the function
get_image_ivt_offset() only requires the img addr now.

> return CMD_RET_USAGE;
>
> addr = simple_strtoul(argv[1], NULL, 16);
> length = simple_strtoul(argv[2], NULL, 16);
> -   ivt_offset = simple_strtoul(argv[3], NULL, 16);
> +   if (argc == 3)

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

Re: [U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Otavio Salvador]

On Wed, Nov 21, 2018 at 7:10 AM Stefano Babic  wrote:
> On 21/11/18 00:10, Marek Vasut wrote:
> > On 11/20/2018 10:11 PM, Simon Goldschmidt wrote:
> >> On 04.09.2018 12:30, Andreas Reichel wrote:
> The library is already built (tools/env/lib.a), but IMHO the best thing
> is to export it official and let that in OE we have a
> u-boot-fw-tools-dev with header and library.
>
> I would like to see the library under LGPL instead of GPL2, too, and I
> raised this issue when I started SWUpdate, but I was not very active to
> promote this. Tom, Wolfgang, is there chances to switch license ?

From OE perspective, it ought to be a different recipe as
libu-boot-env or similar, so it does allow to be used without being
connected to the BSP in use. Especially if the option to load default
env from a file or similar is added.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Wolfgang Denk]

Dear Simon,

In message  you wrote:
>
> Hmm, on my board, SPL loads U-Boot from NOR to SDRAM, then checks the 
> uimage CRC. I'd say this is enough checks. That might not hold for all 
> boards though.

If you check the image in RAM, then yes.  I've also seen
implementations where it gets checked on the fly (for boot time
reasons), so write corruption would not be covered.

> Could we put U-Boot into a fit image and put the environment in a 
> subimage? But it might increase SPL code size when a fit image has to be 
> parsed...

Yes, of course this can be done.  You would need such code anyway in
SPL if you gor for Falcon mode, where you would load a (signed) FIT
image with the Linux kernel and DTB (and maybe even a ramdisk
image).

But as mentioned - this depends on the use case and on available
resources.  It may not be possible on many more resource-constricted
boards - there, other mechanisms should be possible.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Free markets select for winning solutions."- Eric S. Raymond
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Simon Goldschmidt]

On 21.11.2018 16:41, Wolfgang Denk wrote:

Dear Simon,

In message  
you wrote:

Only if you use signed images.  With plain U-Boot, there is not even
a checksum for it...

When SPL loads U-Boot from a legacy image, isn't there a CRC involved over
the full image including the environment?

Yes, but when - for example - the compiled in default environment
gets corrupted while loading from the storage device or while
writing it to RAM, there will be zero check when reading it.


Hmm, on my board, SPL loads U-Boot from NOR to SDRAM, then checks the 
uimage CRC. I'd say this is enough checks. That might not hold for all 
boards though.


But I still think keeping the default environment in a different place 
would be good.


Could we put U-Boot into a fit image and put the environment in a 
subimage? But it might increase SPL code size when a fit image has to be 
parsed...


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

Re: [U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Wolfgang Denk]

Dear Simon,

In message  
you wrote:
>
> > Only if you use signed images.  With plain U-Boot, there is not even
> > a checksum for it...
>
> When SPL loads U-Boot from a legacy image, isn't there a CRC involved over
> the full image including the environment?

Yes, but when - for example - the compiled in default environment
gets corrupted while loading from the storage device or while
writing it to RAM, there will be zero check when reading it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Randal said it would be tough to do in sed. He didn't say  he  didn't
understand  sed.  Randal  understands sed quite well. Which is why he
uses Perl. :-) - Larry Wall in <7...@jpl-devvax.jpl.nasa.gov>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] uboot to read kernel and rootfs from a bootfs.

[Wolfgang Denk]

Dear Michael,

In message  
you wrote:
>
> as I asked in my email... since I'm using spi-flash for the fs access, it
> seems I'll need to use the DM_SPI_FLASH support.

For new code, yes.

> I'm using the 2017.09 version of u-boot with openembedded/poky and the 4.4
> kernel
>
> would it be worth me using a newer version of u-boot? would that give me
> better support of my spi-flash?

You should always go with top-of-tree from the respective mainline
repositoruy for any new developments.

> my board is basically an am335x_evm with an is25lp512 nor spi-flash instead
> of emmc.

SPI NOR is used on a zillion of boards and should work pretty well.

> when I tried to turn on the dm flash support it didn't compile. just
> wondering if that is supported more thouroughly in
> newer versions of u-boot.

sorry, I don't know.  Again, here the ML is a much better reource to
ask such things.

In any case you should not use JFFS2 any more; it is really, really
dead code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Der Dativ ist dem Genitiv sein Tod.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] SWUpdate - U-Boot environment library dependency

[Marek Vasut]

On 11/21/2018 04:31 PM, Simon Goldschmidt wrote:
> 
> 
> On Wednesday, November 21, 2018, Stefano Babic  > wrote:
> 
> Hi Marek,
> 
> On 21/11/18 15:31, Marek Vasut wrote:
> > On 11/21/2018 10:20 AM, Wolfgang Denk wrote:
> >> Dear Stefano,
> >
> > Hi,
> >
> >> In message <96836cc1-e4bb-a2a2-05ac-056053b4c...@denx.de
> > you wrote:
> >>>
> >>> I would like to see the library under LGPL instead of GPL2, too,
> and I
> >>> raised this issue when I started SWUpdate, but I was not very
> active to
> >>> promote this. Tom, Wolfgang, is there chances to switch license ?
> >>
> >> Relicensing requires permission from all who contributed to that
> >> code.
> >>
> >> Consider mine as granted.
> >>
> >> But someone hat to invest the efforts to analyze the code so we
> >> know who to ask, and then collect all the permissions...
> >>
> >>> A env library is very welcomed by many customers, because they could
> >>> integrate it in their application if license allows it.
> >>
> >> Agreed.
> >
> > Then again, U-Boot environment structure is trivial, crc, flags, data,
> > there is no complexity involved. There is probably some complexity in
> > the backing store access stuff (MTD, block devs, legacy stuff),
> but that
> > should either use some MTD utils libs, basic block access
> primitives or
> > be given a once-over and possibly be dropped.
> >
> > I think prototyping a library from scratch that's LGPL would be a few
> > days' work and the benefit would be tremendous all over.
> 
> 
> I confess I had the same idea - why not ignore the code in tools/env
> (they have also some drawbacks, see the locking mechanism in my previous
> e-mail) and start with a new library from scratch ? Then LGPL is not an
> issue anymore, it is a new development. And I already took this way for
> "grubenv" (I had to, grubenv is not license compatible).
> 
> But something in my head is telling me that this is not else as a fork
> of u-boot (ok, a partial fork, just tools/env). And if the U-Boot
> community decides to follow other ways for the environment, the "forked"
> project aka "new library" should follow. But yes, I guess it is easier,
> and I agree with you this is just a few days work.
> 
> 
> Once you had this new lgpl library, would it be a big problem to
> backport it to the U-Boot tree? Wouldn't that also ensure future
> commiters accept the lgpl license when adding their new code?

Maybe it can be part of the U-Boot tree and the old env tools can just
be migrated over, make them a husk which calls the new lib .

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

Re: [U-Boot] SWUpdate - U-Boot environment library dependency

[Simon Goldschmidt]

On Wednesday, November 21, 2018, Stefano Babic  wrote:

> Hi Marek,
>
> On 21/11/18 15:31, Marek Vasut wrote:
> > On 11/21/2018 10:20 AM, Wolfgang Denk wrote:
> >> Dear Stefano,
> >
> > Hi,
> >
> >> In message <96836cc1-e4bb-a2a2-05ac-056053b4c...@denx.de> you wrote:
> >>>
> >>> I would like to see the library under LGPL instead of GPL2, too, and I
> >>> raised this issue when I started SWUpdate, but I was not very active to
> >>> promote this. Tom, Wolfgang, is there chances to switch license ?
> >>
> >> Relicensing requires permission from all who contributed to that
> >> code.
> >>
> >> Consider mine as granted.
> >>
> >> But someone hat to invest the efforts to analyze the code so we
> >> know who to ask, and then collect all the permissions...
> >>
> >>> A env library is very welcomed by many customers, because they could
> >>> integrate it in their application if license allows it.
> >>
> >> Agreed.
> >
> > Then again, U-Boot environment structure is trivial, crc, flags, data,
> > there is no complexity involved. There is probably some complexity in
> > the backing store access stuff (MTD, block devs, legacy stuff), but that
> > should either use some MTD utils libs, basic block access primitives or
> > be given a once-over and possibly be dropped.
> >
> > I think prototyping a library from scratch that's LGPL would be a few
> > days' work and the benefit would be tremendous all over.
>
>
> I confess I had the same idea - why not ignore the code in tools/env
> (they have also some drawbacks, see the locking mechanism in my previous
> e-mail) and start with a new library from scratch ? Then LGPL is not an
> issue anymore, it is a new development. And I already took this way for
> "grubenv" (I had to, grubenv is not license compatible).
>
> But something in my head is telling me that this is not else as a fork
> of u-boot (ok, a partial fork, just tools/env). And if the U-Boot
> community decides to follow other ways for the environment, the "forked"
> project aka "new library" should follow. But yes, I guess it is easier,
> and I agree with you this is just a few days work.


Once you had this new lgpl library, would it be a big problem to backport
it to the U-Boot tree? Wouldn't that also ensure future commiters accept
the lgpl license when adding their new code?

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

[U-Boot] [PATCH] omap3: beagle: Enable DM_MMC and BLK for u-boot only, not SPL

[Guillaume GARDET]

Also disable USB_STORAGE as it is not ready for the switch.
Tested on a Beagleboard xM rev. B.

Signed-off-by: Guillaume GARDET 

Cc: Tom Rini 
Cc: Simon Glass 
---
 configs/omap3_beagle_defconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/omap3_beagle_defconfig b/configs/omap3_beagle_defconfig
index 4fb8aec57d..b4ea714aef 100644
--- a/configs/omap3_beagle_defconfig
+++ b/configs/omap3_beagle_defconfig
@@ -37,6 +37,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="omap3-beagle"
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_SPL_DM=y
+# CONFIG_SPL_BLK is not set
 CONFIG_USB_FUNCTION_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x8200
 CONFIG_LED_STATUS=y
@@ -52,6 +53,8 @@ CONFIG_LED_STATUS_GREEN_ENABLE=y
 CONFIG_LED_STATUS_GREEN=2
 CONFIG_LED_STATUS_CMD=y
 CONFIG_TWL4030_LED=y
+CONFIG_DM_MMC=y
+# CONFIG_SPL_DM_MMC is not set
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
@@ -66,7 +69,6 @@ CONFIG_USB_OMAP3=y
 CONFIG_USB_MUSB_GADGET=y
 CONFIG_USB_MUSB_OMAP2PLUS=y
 CONFIG_TWL4030_USB=y
-CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="TI"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0451
-- 
2.19.1

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

Re: [U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Simon Goldschmidt]

Am Mi., 21. Nov. 2018, 15:23 hat Wolfgang Denk  geschrieben:

> Dear Stefano,
>
> In message <151c30b1-d383-d212-a611-519150a80...@denx.de> you wrote:
> >
> > > I tend to disagree.  As mentioned, the original intent of the
> > > default environment was only (!) to make sure that a working
> > > baudrate setting for the console is available on boards where the
> > > environment has never been initialized yet (fresh our of
> > > production) or, but only as additional benefit, that have lost their
> > > environment somehow.
> >
> > Current intent is to provide a "factory reset" environment and the
> > device must be able to be functional even if with limiutation, at least
> > it should be possible to be restored.
>
> I understand the intend.  But instead of chosing an approoriate
> method (creating a separate enviornment block to be loaded with "env
> import" which has been created for exactly such purposes as user
> profiles or factory reset) they decided to to the Wong Thing.
>
> This should be fixed.
>
> > > My question is:  why do we need the default environment today?
> >
> > The "default" environemnt is the "factory reset" environment.
>
> You avoid a straight and honest answer here.
>
> It is _used_ for this purpoose, or rather _misused_.
>
> My question is: whyu do we _need_ the default environment today?
>
> I think we should get rid of it, and yes, obviously this means that
> we should put the current (mis-) users from their heads to their
> feet.
>
> > >>> - Why does building the U-Boot package not also create these
> > >>>   libraries, either directly or as a separate package?
> > >>
> > >> Issue is that there is not a u-boot-dev package
> > >
> > > Then why not create one?
> >
> > Where ? Which project ? You men OE ?
>
> You said there was no such image.  I don't know which project you
> were referring to...
>
> > > You don't have to rebuild U-Boot - building the lib should be
> > > sufficient.
> >
> > If there is a configuration file that can be imported by the lib and it
> > remains in sync with U-Boot, if U-Boot still sues linked environment.
>
> Sorry, I don't understand what you want to tell me here.
>
>
> > > And I ask again: what exactly would we lose if we drop the whole
> > > default environment?
> >
> > Board is not able to run after flashing the bootloader. This is become
> > worse in the last time due to secure boot. In fact, if this "factory
> > environment" is linked to U-Boot, it is signed together with U-Boot and
> > can be trusted (this is the original topic in the thread).
>
> This is what people made out of it.  But it's not the only possible
> way, and definitely not the best way.
>
> You ignore my arguments.
>
> Instead of using a binary blob inserted somewhere by the linker, we
> could use a more suitable data structure, probably even separate and
> with it's own signature so it could be used (and verified) by
> external tools as well.
>
> And get rid of this current implementation.
>
> > If we use in U-Boot a sort of env import, we have to be sure that we can
> > trust it.
>
> Any other form of implementation is probably better and more secure.
> At themoment the binary blob just gets loaded, without any checking,
> not even for corruption.
>
> > I see a lot of complains..
>
> I don't.
>
> > The feature we give with it is an additional redundancy because board
> > comes up even if environment in flash is damaged.
>
> If you split off the initialization, you could even have more than
> one copy of the initial / factory settings if you like.
>
> > > I would be seriously surprised if a single board in real  life uses
> > > the default environment, and only that, for normale operation.
> >
> > I guess you are really surprised !
> >
> > There are plenty of boards - "default environment" means "factory reset
> > environment".
>
> s/means/has been misused/
>
> This is not a feature, it is part of the problem that should be
> solved!
>
> > This was maybe the initial goal, but if I look in current code there is
> > just the symbol "default_environment" in the ELF. It contains the
> > default as you mind + the "real" initialization environment from
> > CONFIG_EXTRA_ENV.
>
> This has always been like that.  Yes of course it is a convenient
> way to create4 customized initial settings.  But the method how it
> is implemented does not scale, and we are running in limitations.
>
> So let's replace it with soemthing more powerful and more flexible.
>
> > > At these times, a U-Boot image would usually contaim 3 copies of the
> > > same data: two redundant copies of the normal, persistent
> > > environment, embedded somehwere at "magic offsets" in the image,
> > > plus the default environment (somehwere in the [read-only] data
> > > segment, basically at an unknown address).
> >
> > I do not see the last one in data - there are two copies (with
> > CONFIG_ENV_REDUND set, of course) in flash + one (called
> > "default_environment") in .text segment. And yes, it is linked, and
> > address cha

Re: [U-Boot] [PATCH v1 00/16] Add support for DM_USB and DM_USB_DEV to TI's am335x and am43xx_evm platforms

[Marek Vasut]

On 11/21/2018 11:51 AM, Jean-Jacques Hiblot wrote:
> 
> This series applies on top of the series "Add support for DM_USB and
> DM_USB_DEV to TI's K2G platforms" and "Add support for DM_USB and
> DM_USB_DEV for TI's DRA7 EVMs and AM57 EVMs platforms."
> 
> The am433x platforms can use the generic DWC3 driver instead of relying on
> the dwc3-xhci driver.
> The am335x platforms use the musb controller. With a bit of work it can be
> made to support DM as well. This series only enables DM_USB and DM_USB_GADGET
> on am335x_boneblack_vboot. The changes for the other am335x based platforms
> will come in a subsequent series that reworks the configs of several TI
> boards.
> 
> This is part of a work to move all TI's platforms to support DM_USB and
> DM_USB_DEV.
> As a side effect it makes it easy to support the full USB RDNIS bootflow
> (bootrom loads SPL over RNDIS, SPL loads u-boot over RNDIS, u-boot loads
> the images over RNDIS)
> 
> This series is made of 3 parts:
> - some generic changes: rename DM_USB_DEV in DM_USB_GADGET and create
> UCLASS_USB_GADGET for the USB peripheral drivers.
> - am437x support for DM_USB and DM_USB_GADGET
> - am335x support for DM_USB and DM_USB_GADGET

Real glad to see this work happening, thanks for that.
I'll let Lukasz handle the reviews since he's doing the gadget stuff.

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

Re: [U-Boot] [PATCH 00/93] dm: Move towards completing CONFIG_BLK migration

[Tom Rini]

On Tue, Nov 20, 2018 at 08:53:12AM -0500, Tom Rini wrote:
> On Tue, Nov 20, 2018 at 02:45:24PM +0100, Marek Vasut wrote:
> > On 11/20/2018 02:42 PM, Tom Rini wrote:
> > > On Tue, Nov 20, 2018 at 02:40:43PM +0100, Marek Vasut wrote:
> > >> On 11/20/2018 02:37 PM, Tom Rini wrote:
> > >>> On Tue, Nov 20, 2018 at 01:42:15PM +0100, Soeren Moch wrote:
> > 
> > 
> >  On 19.11.18 16:52, Simon Glass wrote:
> > > All boards should now be migrated to use CONFIG_BLK. This series 
> > > removes
> > > those with build problems using this option.
> > >
> > > If maintainers want to keep these boards in they should send a patch 
> > > in
> > > the next week or two. Otherwise the board will be removed in the next
> > > release, and will need to be added and re-reviewed later.
> >  Fabio, Stefano,
> > 
> >  it seems (almost?) all i.mx6 boards should be removed within two weeks.
> >  But would it not make more sense to convert the reference boards first
> >  (mx6sabresd
> >  in my case for tbs2910), and let hobbyist maintainers like me take this
> >  as example for
> >  their own modifications?
> > >>>
> > >>> So, I replied to the main thread earlier but no, we're not going to drop
> > >>> everything in 2 weeks, especially since there's a lot of false positives
> > >>> in this series.
> > >>>
> >  Simon, Tom,
> > 
> >  is this really the usual u-boot working style to remove about hundred
> >  boards within
> >  two weeks without prior warning? As hobbyist board maintainer I try to
> >  follow
> >  new developments, and more than once I fixed up regressions introduced
> >  by others
> >  in general code.
> >  But I cannot follow all development details without any heads-up. And
> >  even the
> >  NXP folks seem to be surprised about this.
> > 
> >  All problems with this transition seem to be located around usbstorage
> >  and sata.
> >  This is for sure not really very board specific. Is there any migration
> >  guide, or
> >  examples how other SoC architectures did this conversion?
> > >>>
> > >>> I'll admit this hasn't been our best notification.  But, the deadline
> > >>> was discussed about a year ago (and then no, I didn't get a build-time
> > >>> warning in).  Then around v2018.05 I said it wasn't going to be a
> > >>> removal type problem yet as we had a lot of boards to fixup still, and
> > >>> repeated that at v2018.07.  That did lead to a lot of things getting
> > >>> addressed.  But yes, we still have some large areas that after a few
> > >>> years still have not been converted, and that puts me in a hard spot
> > >>> too.
> > >>
> > >> Build time warning for a year would be good ?
> > > 
> > > A year for this?  No.  New deadlines?  That's not too far off from what
> > > we've done historically, so yes.
> > 
> > Give people some sort of breathing space to get the conversion done.
> > Stressing people out by arbitrary deadlines will lead nowhere.
> 
> Sure, agreed.  I didn't say we're going to drop all these boards, nor
> are we going to drop SATA and USB Storage (if those are still all that's
> left to convert) for this release.  But given that we proposed a
> deadline in August 2017, made email-but-not-build noise about it between
> May and July/August of this year, no, I also don't think setting a new
> deadline of November 2019 is the right call either.
> 
> So, really, lets see what the fails to build boards are with BLK being
> on when we have block devices.  Then assess what a good deadline is.
> 
> > >> Maybe we need some generic Makefile macro to set those up.
> > > 
> > > It would be nice, yes.  I think the problem here is (or, was) the
> > > complex set of options that didn't work.
> > 
> > The problem was many people didn't know about the conversion deadline or
> > simply forgot. And reminding them with a 100-patch series removing half
> > of the boards is like splashing icy water bucket in their sleeping faces.
> 
> Alright.  But we've already tried less shocking approaches to
> conversion, but in public (over the summer when Simon listed most of
> these boards in a series but I _think_ his script failed to CC the
> universe and didn't follow up with a repost that did email everyone) and
> perhaps private too (I honestly don't recall if I did, or just intended
> to, ask you about the USB side of this on IRC).

And, for the record, the USB side I had in mind here was converted, and
I just forgot, my fault.  In fact, as I go through some hack-and-slash
to see what needs a real conversion (either board updated, or drivers
updated) at least some part of this is needing to adjust dependencies to
force things on with BLK.  For example, if we have MMC we must have
DM_MMC and BLK, and if we have USB we must have DM_USB and BLK.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.d

Re: [U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Stefano Babic]

On 21/11/18 15:37, Simon Goldschmidt wrote:
> 
> 
> Am Mi., 21. Nov. 2018, 15:27 hat Wolfgang Denk  > geschrieben:
> 
> Dear Stefano,
> 
> In message <7089ef62-ed0f-87f4-e979-8c18a6ae4...@denx.de
> > you wrote:
> >
> > > Right, when we sign (and check the signatures) of all other images,
> > > then why not do the very same for some environment image?
> >
> > The weird thing is with "saveenv" - if we just read the env, it is
> fine,
> > but if we want to change it, we need to sign, and this requires a
> > private key on target.
> 
> Agreed, but this is a totaly different issue.
> 
> The separate (potentially singed0 environment image is only the
> replacement for the current "default environment", which is not
> used for "env save".  In the same way, there is no need to modfy the
> signed image.
> 
> But yes, it might be desirable to protect the working environment
> against malicious manipulation - but this should be discussed in a
> separate thread.
> 
> > > That would even be _better_ as currently there is no, absolutely no
> > > check if the builtin default environment is in any way consistent.
> >
> > This is not true. If the environment is linked to u-boot, it is signed
> > together with u-boot and its consistency is automatically verified.
> 
> Only if you use signed images.  With plain U-Boot, there is not even
> a checksum for it...
> 
> 
> When SPL loads U-Boot from a legacy image, isn't there a CRC involved
> over the full image including the environment?

I think Marek is talking about raw u-boot, not in case mkimage has put
an header at the beginning. See CONFIG_SPL_RAW_IMAGE_SUPPORT and
spl_parse_image_header(). The image is simply loaded without checks.

Best regards,
Stefano


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

[U-Boot] [PATCH] net: explicitly assign errno to return code in case of network failure

[Thomas RIENOESSL]

When dealing with two ethernet ports and having "netretry" set
to "once", it could occur that the connection (e.g. an ARP
request) failed, hence the status of the netloop was
"NETLOOP_FAIL". Due to the setting of "netretry", the network
logic would then switch to the other network interface,
assigning "ret" with the return value of "net_start_again()".
If this call succeeded we would return 0 (i.e. success) to
the caller when in reality the network action failed.

Change-Id: I58b935b0f6c7a300d1dd0058803f7d3c9455b0dc
Signed-off-by: Thomas RIENOESSL 
---
 net/net.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/net.c b/net/net.c
index 31cf306ae7..568ba74f78 100644
--- a/net/net.c
+++ b/net/net.c
@@ -657,6 +657,7 @@ restart:
/* Invalidate the last protocol */
eth_set_last_protocol(BOOTP);
debug_cond(DEBUG_INT_STATE, "--- net_loop Fail!\n");
+   ret = -ENONET;
goto done;
 
case NETLOOP_CONTINUE:
-- 
2.19.1

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

Re: [U-Boot] [swupdate] Re: SWUpdate - U-Boot environment library dependency

[Stefano Babic]

Hi Marek,

On 21/11/18 15:31, Marek Vasut wrote:
> On 11/21/2018 10:20 AM, Wolfgang Denk wrote:
>> Dear Stefano,
> 
> Hi,
> 
>> In message <96836cc1-e4bb-a2a2-05ac-056053b4c...@denx.de> you wrote:
>>>
>>> I would like to see the library under LGPL instead of GPL2, too, and I
>>> raised this issue when I started SWUpdate, but I was not very active to
>>> promote this. Tom, Wolfgang, is there chances to switch license ?
>>
>> Relicensing requires permission from all who contributed to that
>> code.
>>
>> Consider mine as granted.
>>
>> But someone hat to invest the efforts to analyze the code so we
>> know who to ask, and then collect all the permissions...
>>
>>> A env library is very welcomed by many customers, because they could
>>> integrate it in their application if license allows it.
>>
>> Agreed.
> 
> Then again, U-Boot environment structure is trivial, crc, flags, data,
> there is no complexity involved. There is probably some complexity in
> the backing store access stuff (MTD, block devs, legacy stuff), but that
> should either use some MTD utils libs, basic block access primitives or
> be given a once-over and possibly be dropped.
> 
> I think prototyping a library from scratch that's LGPL would be a few
> days' work and the benefit would be tremendous all over.


I confess I had the same idea - why not ignore the code in tools/env
(they have also some drawbacks, see the locking mechanism in my previous
e-mail) and start with a new library from scratch ? Then LGPL is not an
issue anymore, it is a new development. And I already took this way for
"grubenv" (I had to, grubenv is not license compatible).

But something in my head is telling me that this is not else as a fork
of u-boot (ok, a partial fork, just tools/env). And if the U-Boot
community decides to follow other ways for the environment, the "forked"
project aka "new library" should follow. But yes, I guess it is easier,
and I agree with you this is just a few days work.

This can solve the issue with license - the other topic regarding
"default" (or "initialization") environment is not changed by an
external library.

Best regards,
Stefano Babic

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

[U-Boot] [PATCH] arm64: zynqmp: Reflect emmc controller ID in model in DT

[Michal Simek]

Make sense to add controller ID to model name to have it visible through
the logs to know which controller is used by which configuration.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-mini-emmc0.dts | 2 +-
 arch/arm/dts/zynqmp-mini-emmc1.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/zynqmp-mini-emmc0.dts 
b/arch/arm/dts/zynqmp-mini-emmc0.dts
index 24dd1ab9df02..13d0813ed41d 100644
--- a/arch/arm/dts/zynqmp-mini-emmc0.dts
+++ b/arch/arm/dts/zynqmp-mini-emmc0.dts
@@ -10,7 +10,7 @@
 /dts-v1/;
 
 / {
-   model = "ZynqMP MINI EMMC";
+   model = "ZynqMP MINI EMMC0";
compatible = "xlnx,zynqmp";
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arm/dts/zynqmp-mini-emmc1.dts 
b/arch/arm/dts/zynqmp-mini-emmc1.dts
index 530ab3cdc22e..0538da468b3e 100644
--- a/arch/arm/dts/zynqmp-mini-emmc1.dts
+++ b/arch/arm/dts/zynqmp-mini-emmc1.dts
@@ -10,7 +10,7 @@
 /dts-v1/;
 
 / {
-   model = "ZynqMP MINI EMMC";
+   model = "ZynqMP MINI EMMC1";
compatible = "xlnx,zynqmp";
#address-cells = <2>;
#size-cells = <2>;
-- 
1.9.1

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

[U-Boot] [PATCH] arm64: zynqmp: Disable bootelf and fdt commands for mini configurations

[Michal Simek]

There is no reason to enable these commands for mini configurations.
It saves some space:
   aarch64: (for 2/2 boards) all -19076.0 bss -1048.0 data -1720.0
rodata -3840.0 text -12468.0
xilinx_zynqmp_mini_emmc1: all -19076 bss -1048 data -1720
rodata -3840 text -12468
xilinx_zynqmp_mini_emmc0: all -19076 bss -1048 data -1720
rodata -3840 text -12468

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_mini_emmc0_defconfig | 2 ++
 configs/xilinx_zynqmp_mini_emmc1_defconfig | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/configs/xilinx_zynqmp_mini_emmc0_defconfig 
b/configs/xilinx_zynqmp_mini_emmc0_defconfig
index 917637ddacd0..71c320cc3e23 100644
--- a/configs/xilinx_zynqmp_mini_emmc0_defconfig
+++ b/configs/xilinx_zynqmp_mini_emmc0_defconfig
@@ -20,6 +20,8 @@ CONFIG_SYS_PROMPT="ZynqMP> "
 # CONFIG_CMD_BOOTD is not set
 # CONFIG_CMD_BOOTM is not set
 # CONFIG_CMD_BOOTI is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_FDT is not set
 # CONFIG_CMD_GO is not set
 # CONFIG_CMD_RUN is not set
 # CONFIG_CMD_IMI is not set
diff --git a/configs/xilinx_zynqmp_mini_emmc1_defconfig 
b/configs/xilinx_zynqmp_mini_emmc1_defconfig
index 1ffa528d6d54..3298341d190d 100644
--- a/configs/xilinx_zynqmp_mini_emmc1_defconfig
+++ b/configs/xilinx_zynqmp_mini_emmc1_defconfig
@@ -20,6 +20,8 @@ CONFIG_SYS_PROMPT="ZynqMP> "
 # CONFIG_CMD_BOOTD is not set
 # CONFIG_CMD_BOOTM is not set
 # CONFIG_CMD_BOOTI is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_FDT is not set
 # CONFIG_CMD_GO is not set
 # CONFIG_CMD_RUN is not set
 # CONFIG_CMD_IMI is not set
-- 
1.9.1

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

[U-Boot] [PATCH 3/3] ARM: zynq: cse: Shrink u-boot size

[Michal Simek]

U-Boot is growing that's why not needed features can be disabled:
- CMDLINE_EDITING
- AUTO_COMPLETE
- SYS_LONGHELP

Signed-off-by: Michal Simek 
---

 configs/zynq_cse_nand_defconfig | 3 +++
 configs/zynq_cse_nor_defconfig  | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/zynq_cse_nand_defconfig b/configs/zynq_cse_nand_defconfig
index 416d91d684ef..9bb02add2d07 100644
--- a/configs/zynq_cse_nand_defconfig
+++ b/configs/zynq_cse_nand_defconfig
@@ -9,6 +9,9 @@ CONFIG_SYS_MALLOC_LEN=0x1000
 # CONFIG_BOARD_LATE_INIT is not set
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
+# CONFIG_CMDLINE_EDITING is not set
+# CONFIG_AUTO_COMPLETE is not set
+# CONFIG_SYS_LONGHELP is not set
 CONFIG_SYS_PROMPT="Zynq> "
 # CONFIG_AUTOBOOT is not set
 # CONFIG_CMD_BDI is not set
diff --git a/configs/zynq_cse_nor_defconfig b/configs/zynq_cse_nor_defconfig
index addc21fdc79e..44329971b67e 100644
--- a/configs/zynq_cse_nor_defconfig
+++ b/configs/zynq_cse_nor_defconfig
@@ -9,6 +9,9 @@ CONFIG_SYS_MALLOC_LEN=0x1000
 # CONFIG_BOARD_LATE_INIT is not set
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
+# CONFIG_CMDLINE_EDITING is not set
+# CONFIG_AUTO_COMPLETE is not set
+# CONFIG_SYS_LONGHELP is not set
 CONFIG_SYS_PROMPT="Zynq> "
 # CONFIG_AUTOBOOT is not set
 # CONFIG_CMD_BDI is not set
-- 
1.9.1

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

[U-Boot] [PATCH 2/3] ARM: zynq: cse: Disable autoboot feature

[Michal Simek]

Intention of CSE targets is not boot anything that's why also bootdelay
is not necessary

Signed-off-by: Michal Simek 
---

 configs/zynq_cse_nand_defconfig | 1 +
 configs/zynq_cse_nor_defconfig  | 2 +-
 configs/zynq_cse_qspi_defconfig | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/zynq_cse_nand_defconfig b/configs/zynq_cse_nand_defconfig
index 44ad5bd69c35..416d91d684ef 100644
--- a/configs/zynq_cse_nand_defconfig
+++ b/configs/zynq_cse_nand_defconfig
@@ -10,6 +10,7 @@ CONFIG_SYS_MALLOC_LEN=0x1000
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SYS_PROMPT="Zynq> "
+# CONFIG_AUTOBOOT is not set
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_CONSOLE is not set
 # CONFIG_CMD_BOOTD is not set
diff --git a/configs/zynq_cse_nor_defconfig b/configs/zynq_cse_nor_defconfig
index b4831f89a1a8..addc21fdc79e 100644
--- a/configs/zynq_cse_nor_defconfig
+++ b/configs/zynq_cse_nor_defconfig
@@ -6,11 +6,11 @@ CONFIG_ENV_SIZE=0x190
 CONFIG_SPL=y
 CONFIG_SPL_STACK_R_ADDR=0x20
 CONFIG_SYS_MALLOC_LEN=0x1000
-CONFIG_BOOTDELAY=-1
 # CONFIG_BOARD_LATE_INIT is not set
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SYS_PROMPT="Zynq> "
+# CONFIG_AUTOBOOT is not set
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_CONSOLE is not set
 # CONFIG_CMD_BOOTD is not set
diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index e271cca690fd..2aee069bb188 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -21,6 +21,7 @@ CONFIG_SPL_SPI_LOAD=y
 # CONFIG_AUTO_COMPLETE is not set
 # CONFIG_SYS_LONGHELP is not set
 CONFIG_SYS_PROMPT="Zynq> "
+# CONFIG_AUTOBOOT is not set
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_CONSOLE is not set
 # CONFIG_CMD_BOOTD is not set
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] ARM: zynq: cse: Disable distro bootcommands

[Michal Simek]

cse targets shouldn't never have distro default enabled because these
targets are not designed for booting images.

It was enabled by:
"configs: Re-sync with CONFIG_DISTRO_DEFAULTS"
(sha1: fa2c14676c7c6f3115dd4d9b2a4cc3b35c3ad2a2)

Signed-off-by: Michal Simek 
---

 configs/zynq_cse_qspi_defconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/zynq_cse_qspi_defconfig b/configs/zynq_cse_qspi_defconfig
index 2e1e34d0aec7..e271cca690fd 100644
--- a/configs/zynq_cse_qspi_defconfig
+++ b/configs/zynq_cse_qspi_defconfig
@@ -11,15 +11,15 @@ CONFIG_SPL_STACK_R_ADDR=0x20
 CONFIG_SYS_MALLOC_LEN=0x1000
 # CONFIG_CMD_ZYNQ is not set
 CONFIG_DEBUG_UART=y
-CONFIG_DISTRO_DEFAULTS=y
 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
-CONFIG_BOOTDELAY=-1
-# CONFIG_USE_BOOTCOMMAND is not set
 # CONFIG_BOARD_LATE_INIT is not set
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_ARCH_EARLY_INIT_R is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SPI_LOAD=y
+# CONFIG_CMDLINE_EDITING is not set
+# CONFIG_AUTO_COMPLETE is not set
+# CONFIG_SYS_LONGHELP is not set
 CONFIG_SYS_PROMPT="Zynq> "
 # CONFIG_CMD_BDI is not set
 # CONFIG_CMD_CONSOLE is not set
-- 
1.9.1

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

[U-Boot] [PATCH] ARM: zynq: Guard zynq_help_text with CONFIG_SYS_LONGHELP

[Michal Simek]

If SYS_LONGHELP is disabled the following warning is generated:
board/xilinx/zynq/cmds.c:496:13: warning: ‘zynq_help_text’ defined but
not used [-Wunused-variable]

Normal way for fixing this is to guard the whole variable.

Signed-off-by: Michal Simek 
---

 board/xilinx/zynq/cmds.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/xilinx/zynq/cmds.c b/board/xilinx/zynq/cmds.c
index 0b2a8178d62c..8b48ea3a03ab 100644
--- a/board/xilinx/zynq/cmds.c
+++ b/board/xilinx/zynq/cmds.c
@@ -493,6 +493,7 @@ static int do_zynq(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return cmd_process_error(zynq_cmd, ret);
 }
 
+#ifdef CONFIG_SYS_LONGHELP
 static char zynq_help_text[] =
""
 #ifdef CONFIG_CMD_ZYNQ_RSA
@@ -507,6 +508,7 @@ static char zynq_help_text[] =
"  destination address\n"
 #endif
;
+#endif
 
 U_BOOT_CMD(zynq,   6,  0,  do_zynq,
   "Zynq specific commands", zynq_help_text
-- 
1.9.1

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

[U-Boot] [PATCH] mtd: nand: Arasan: Add subpage configuration support

[Michal Simek]

From: Martin Lund 

Add support for disabling subpage write support via
CONFIG_SYS_NAND_NO_SUBPAGE_WRITE.

Currently the Linux Arasan driver does not support subpage writes and in
case of running UBI and accessing the same UBI volume from both U-Boot
and Linux it is required to have the same subpage write configuration
else the location of the UBI headers (EC + VID) will be misaligned
(subpage vs page) and incompatible. Hence the need for disabling
subpage write support in the U-Boot Arasan NAND driver.

Signed-off-by: Martin Lund 
Acked-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 drivers/mtd/nand/raw/arasan_nfc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/nand/raw/arasan_nfc.c 
b/drivers/mtd/nand/raw/arasan_nfc.c
index 41db9f8bb9b1..dc531ccb6822 100644
--- a/drivers/mtd/nand/raw/arasan_nfc.c
+++ b/drivers/mtd/nand/raw/arasan_nfc.c
@@ -1201,6 +1201,10 @@ static int arasan_nand_init(struct nand_chip *nand_chip, 
int devnum)
mtd = nand_to_mtd(nand_chip);
nand_set_controller_data(nand_chip, nand);
 
+#ifdef CONFIG_SYS_NAND_NO_SUBPAGE_WRITE
+   nand_chip->options |= NAND_NO_SUBPAGE_WRITE;
+#endif
+
/* Set the driver entry points for MTD */
nand_chip->cmdfunc = arasan_nand_cmd_function;
nand_chip->select_chip = arasan_nand_select_chip;
-- 
1.9.1

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

[U-Boot] [PATCH] arm: zynq: cse_qspi: Fix overwriting spi-rx-bus-width property

[Michal Simek]

From: Siva Durga Prasad Paladugu 

spi-rx-bus-width property is part of flash, so it should be moved
to flash node from qspi node. This patch fixes the incorrect read
of spi-rx-bus-width property by moving it to flash node.

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

 arch/arm/dts/zynq-cse-qspi-single.dts | 2 +-
 arch/arm/dts/zynq-cse-qspi.dtsi   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/zynq-cse-qspi-single.dts 
b/arch/arm/dts/zynq-cse-qspi-single.dts
index 3252d6a44409..0d680dfc0688 100644
--- a/arch/arm/dts/zynq-cse-qspi-single.dts
+++ b/arch/arm/dts/zynq-cse-qspi-single.dts
@@ -7,6 +7,6 @@
 
 #include "zynq-cse-qspi.dtsi"
 
-&qspi {
+&flash0 {
spi-rx-bus-width = <4>;
 };
diff --git a/arch/arm/dts/zynq-cse-qspi.dtsi b/arch/arm/dts/zynq-cse-qspi.dtsi
index 2b169468b06d..65af4081ff4f 100644
--- a/arch/arm/dts/zynq-cse-qspi.dtsi
+++ b/arch/arm/dts/zynq-cse-qspi.dtsi
@@ -59,7 +59,7 @@
#address-cells = <1>;
#size-cells = <0>;
num-cs = <1>;
-   flash@0 {
+   flash0: flash@0 {
compatible = "n25q128a11";
reg = <0x0>;
spi-tx-bus-width = <1>;
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 RESEND 0/5] usb: Introduce CONFIG_SPL_DM_USB

[Marek Vasut]

On 11/21/2018 08:43 AM, Sven Schwermer wrote:
> This solves the dependency problem I described in [1].
> 
> [1]: http://u-boot.10912.n7.nabble.com/-td347224.html

Applied, thanks

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

Re: [U-Boot] [PATCH 5/9] ARM: socfpga: Add SPL fitImage config match

[Marek Vasut]

On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Add empty SPL fitImage configuration match. This can be extended
> if there is ever need to support multiple boards with single SFP
> image.
> 
> Signed-off-by: Marek Vasut 

It's missing your SoB line, but again, why is this patch needed ?

> ---
>  arch/arm/mach-socfpga/spl_a10.c |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
> index 67a4fac..2baeba6 100644
> --- a/arch/arm/mach-socfpga/spl_a10.c
> +++ b/arch/arm/mach-socfpga/spl_a10.c
> @@ -148,3 +148,13 @@ void board_init_f(ulong dummy)
>   config_dedicated_pins(gd->fdt_blob);
>   WATCHDOG_RESET();
>  }
> +
> +#ifdef CONFIG_SPL_LOAD_FIT
> +int board_fit_config_name_match(const char *name)
> +{
> + /* Just empty function now - can't decide what to choose */
> + debug("%s: %s\n", __func__, name);
> +
> + return 0;
> +}
> +#endif
> 


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

Re: [U-Boot] [PATCH 6/9] ARM: socfpga: Set default DTB address on A10

[Marek Vasut]

On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 

Again, not your patch, please don't change authorship.

http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=eb32e568869b5f91fe34efb2642875a8da5f0ebd

> Set default DT blob address on A10 SoCDK, since this SoC uses OF
> separate configuration. The 0xf address is just below the text
> base and still leaves enough room for the DT to grow.

Why is this needed ?

> Signed-off-by: Marek Vasut 
> Signed-off-by: Tien Fong Chee 
> ---
>  arch/arm/mach-socfpga/board.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
> index 7c8c05c..436a8a8 100644
> --- a/arch/arm/mach-socfpga/board.c
> +++ b/arch/arm/mach-socfpga/board.c
> @@ -86,3 +86,11 @@ int g_dnl_board_usb_cable_connected(void)
>   return 1;
>  }
>  #endif
> +
> +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) && \
> +!defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_SEPARATE)
> +void *board_fdt_blob_setup(void)
> +{
> + return (void *)0xf0;
> +}
> +#endif
> 


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