Re: [U-Boot] [PATCH 2/2] mmc: rockchip: add clock init

2016-07-25 Thread Kever Yang

Hi Jaehoon Chung,

Thanks for your review comment.

On 07/25/2016 01:09 PM, Jaehoon Chung wrote:

Hi Kever,

On 07/25/2016 01:50 PM, Kever Yang wrote:

Signed-off-by: Kever Yang 
---

  drivers/mmc/rockchip_sdhci.c| 10 +-
  include/configs/rk3399_common.h |  2 +-
  2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index 023c29b..a761a86 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -7,6 +7,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -32,15 +33,22 @@ static int arasan_sdhci_probe(struct udevice *dev)
struct rockchip_sdhc_plat *plat = dev_get_platdata(dev);
struct rockchip_sdhc *prv = dev_get_priv(dev);
struct sdhci_host *host = &prv->host;
+   struct clk clk;
int ret;
u32 caps;
  
  	host->version = sdhci_readw(host, SDHCI_HOST_VERSION);

host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD;
  
+	ret = clk_get_by_index(dev, 0, &clk);

+   if (ret < 0)
+   debug("%s get clock fail\n", __func__);
+
+   ret = clk_set_rate(&clk, CONFIG_ROCKCHIP_SDHCI_MAX_FREQ);

Even if failed to get the clk, clk_set_rate() is called...right?



How about using a else branch for get clock return value?


+
caps = sdhci_readl(host, SDHCI_CAPABILITIES);
ret = sdhci_setup_cfg(&plat->cfg, dev->name, host->bus_width,
-   caps, CONFIG_ROCKCHIP_SDHCI_MAX_FREQ, EMMC_MIN_FREQ,
+   caps, ret, EMMC_MIN_FREQ,

Don't use "ret"..use the meaningful variable for maximum clock.


 OK, will use another variate like max_freq.




host->version, host->quirks, 0);
  
  	host->mmc = &plat->mmc;

diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index 6ce1aa7..eacbe4b 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -32,7 +32,7 @@
  #define CONFIG_GENERIC_MMC
  #define CONFIG_SDHCI
  #define CONFIG_BOUNCE_BUFFER
-#define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ 2
+#define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ (198*100)

Why change from 200MHz to 198MHz?


We are using a source for sdhci which clock rate is 594MHz, so we actually
get 198MHz in this sdhci driver clk_set_rate().
This change is not a must, but it may help people know the real frequency?


Thanks,
- Kever


Best Regards,
Jaehoon Chung

  
  #define CONFIG_FAT_WRITE
  








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


Re: [U-Boot] Stepping down as sunxi u-boot custodian

2016-07-25 Thread Maxime Ripard
On Fri, Jul 15, 2016 at 10:45:34AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 04-07-16 14:57, Hans de Goede wrote:
> >Hi All,
> >
> >Between my $dayjob, linux-sunxi, other foss projects and last but
> >not least spending time with my wife and children I'm way too
> >busy lately.
> >
> >So I've decided to seriously scale back my involvement in
> >linux-sunxi, as such I'm going to step down as u-boot sunxi
> >custodian.
> >
> >I've asked Ian if he wanted to pick things up, but he is too
> >busy too.
> >
> >So now the sunxi u-boot support is looking for a new custodian,
> >any takers ?
> 
> So it looks like there is no-one available to take this over from
> me, and I've have managed to successfully hand over maintenance
> form a bunch of other projects, so I'll keep doing this for now.
> 
> Still if someone wants to take over, please let me know I will
> happily step down (and I will be available afterwards to help
> out where needed).

FWIW, if anyone is interested in taking over, I'm can help with the
load if needed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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


Re: [U-Boot] [PATCH 2/5] aristainetos: Use imx_ddr_size() for calculating the DDR size

2016-07-25 Thread Heiko Schocher

Hello Fabio,

Am 23.07.2016 um 18:23 schrieb Fabio Estevam:

From: Fabio Estevam 

imx_ddr_size() can be used to calculate the DDR size in runtime.

By using this function we no longer need to define PHYS_SDRAM_SIZE.

Cc: Heiko Schocher 
Signed-off-by: Fabio Estevam 
---
  board/aristainetos/aristainetos.c | 2 +-
  include/configs/aristainetos-common.h | 1 -
  2 files changed, 1 insertion(+), 2 deletions(-)


Thanks!

Acked-by: Heiko Schocher 

bye,
Heiko


diff --git a/board/aristainetos/aristainetos.c 
b/board/aristainetos/aristainetos.c
index e95ec81..d1e6850 100644
--- a/board/aristainetos/aristainetos.c
+++ b/board/aristainetos/aristainetos.c
@@ -102,7 +102,7 @@ iomux_v3_cfg_t const usdhc1_pads[] = {

  int dram_init(void)
  {
-   gd->ram_size = get_ram_size((void *)PHYS_SDRAM, PHYS_SDRAM_SIZE);
+   gd->ram_size = imx_ddr_size();

return 0;
  }
diff --git a/include/configs/aristainetos-common.h 
b/include/configs/aristainetos-common.h
index d87d40c..640227b 100644
--- a/include/configs/aristainetos-common.h
+++ b/include/configs/aristainetos-common.h
@@ -17,7 +17,6 @@

  #define CONFIG_MACH_TYPE  4501
  #define CONFIG_MMCROOT"/dev/mmcblk0p1"
-#define PHYS_SDRAM_SIZE(1u * 1024 * 1024 * 1024)

  /* Size of malloc() pool */
  #define CONFIG_SYS_MALLOC_LEN (64 * SZ_1M)



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] tree-wide: move CONFIG_PHYS_64BIT to Kconfig

2016-07-25 Thread Stefan Roese

On 24.07.2016 15:12, Masahiro Yamada wrote:

I tried my best to use "select" where possible (for example, ARMv8
architecture) because I think this kind of option is generally user-
unconfigurable.  However, I see some of PowerPC boards have 36BIT
defconfigs as well as 32BIT ones.  I moved CONFIG_PHYS_64BIT to the
defconfigs for such boards.

Signed-off-by: Masahiro Yamada 


For the ppc4xx related stuff:

Acked-by: Stefan Roese 

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


Re: [U-Boot] [PATCH v5] dm: at91: Add driver model support for the spi driver

2016-07-25 Thread Wenyou.Yang
Hi Jagan,

> -Original Message-
> From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
> Sent: 2016年7月21日 15:10
> To: Wenyou Yang 
> Cc: U-Boot Mailing List 
> Subject: Re: [U-Boot] [PATCH v5] dm: at91: Add driver model support for the 
> spi
> driver
> 
> On 20 July 2016 at 15:05, Wenyou Yang  wrote:
> > Add driver model support while retaining the existing legacy code.
> > This allows the driver to support boards that have converted to driver
> > model as well as those that have not.
> >
> > Signed-off-by: Wenyou Yang 
> > Reviewed-by: Simon Glass 
> > ---
> >
> > Changes in v5:
> >  - Change clk_client.h -> clk.h to adapt to clk API conversion.
> >
> > Changes in v4:
> >  - Collect Reviewed-by tag.
> >  - Update the clk API based on [PATCH] clk: convert API to match
> >reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
> >  - Remove check on dev_get_parent() return.
> >  - Fixed the return value, -ENODEV->-EINVAL.
> >  - Retain #include  line.
> >
> > Changes in v3:
> >  - Remove redundant log print.
> >
> > Changes in v2:
> >  - Add clock support.
> >
> >  drivers/spi/Kconfig |   9 ++
> >  drivers/spi/atmel_spi.c | 303
> > 
> >  2 files changed, 312 insertions(+)
> >
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index
> > aca385d..e015d1d 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -32,6 +32,15 @@ config ATH79_SPI
> >   uses driver model and requires a device tree binding to operate.
> >   please refer to doc/device-tree-bindings/spi/spi-ath79.txt.
> >
> > +config ATMEL_SPI
> > +   bool "Atmel SPI driver"
> > +   depends on ARCH_AT91
> > +   select SPI_FLASH
> > +   select SPI_FLASH_ATMEL
> 
> These two configs's are flash related don't add these in spi side,  and

Accepted.

> > +   help
> > + Enable the Atmel SPI driver. This driver can be used to access
> > + the SPI Flash, such as AT25DF321.
> > +
> >  config CADENCE_QSPI
> > bool "Cadence QSPI driver"
> > help
> > diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c index
> > ed6278b..98bee35 100644
> > --- a/drivers/spi/atmel_spi.c
> > +++ b/drivers/spi/atmel_spi.c
> > @@ -4,6 +4,9 @@
> >   * SPDX-License-Identifier:GPL-2.0+
> >   */
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -11,9 +14,15 @@
> >
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >  #include "atmel_spi.h"
> >
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +#ifndef CONFIG_DM_SPI
> > +
> >  static int spi_has_wdrbt(struct atmel_spi_slave *slave)  {
> > unsigned int ver;
> > @@ -209,3 +218,297 @@ out:
> >
> > return 0;
> >  }
> > +
> > +#else
> > +
> > +#define MAX_CS_COUNT   4
> > +
> > +struct atmel_spi_platdata {
> > +   struct at91_spi *regs;
> > +};
> > +
> > +struct atmel_spi_priv {
> > +   unsigned int freq;  /* Default frequency */
> > +   unsigned int mode;
> > +   ulong bus_clk_rate;
> > +   struct gpio_desc cs_gpios[MAX_CS_COUNT]; };
> > +
> > +static int atmel_spi_claim_bus(struct udevice *dev) {
> > +   struct udevice *bus = dev_get_parent(dev);
> > +   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
> > +   struct atmel_spi_priv *priv = dev_get_priv(bus);
> > +   struct dm_spi_slave_platdata *slave_plat = 
> > dev_get_parent_platdata(dev);
> > +   struct at91_spi *reg_base = bus_plat->regs;
> > +   u32 cs = slave_plat->cs;
> > +   u32 freq = priv->freq;
> > +   u32 scbr, csrx, mode;
> > +
> > +   scbr = (priv->bus_clk_rate + freq - 1) / freq;
> > +   if (scbr > ATMEL_SPI_CSRx_SCBR_MAX)
> > +   return -EINVAL;
> > +
> > +   if (scbr < 1)
> > +   scbr = 1;
> > +
> > +   csrx = ATMEL_SPI_CSRx_SCBR(scbr);
> > +   csrx |= ATMEL_SPI_CSRx_BITS(ATMEL_SPI_BITS_8);
> > +
> > +   if (!(priv->mode & SPI_CPHA))
> > +   csrx |= ATMEL_SPI_CSRx_NCPHA;
> > +   if (priv->mode & SPI_CPOL)
> > +   csrx |= ATMEL_SPI_CSRx_CPOL;
> > +
> > +   writel(csrx, ®_base->csr[cs]);
> > +
> > +   mode = ATMEL_SPI_MR_MSTR |
> > +  ATMEL_SPI_MR_MODFDIS |
> > +  ATMEL_SPI_MR_WDRBT |
> > +  ATMEL_SPI_MR_PCS(~(1 << cs));
> > +
> > +   writel(mode, ®_base->mr);
> > +
> 
> claim_bus means have to enable spi not doing mode and freq stuff because this
> claim is calling for every transactions from flash so, doing mode and freq 
> stuff
> every time little overhead. skip these and add mode stuff in 
> atmel_spi_set_mode
> freq in atmel_spi_set_speed.

I totally agreed your opinions. 

But for Atmel SPI,  for different cs, the frequency is set by different the 
SPI_CSRx registers. 
That is to say, cs = 0, it is set by SPI_CSR0, cs =1 it is by SPI_CSR1, and so 
on.
And ops callback (*set_speed)(struct udevice *bus, uint hz) doesn't provid

[U-Boot] Passing information from SPL to next stage

2016-07-25 Thread Chris Packham
Hi,

Is there a standard way of passing information discovered by the SPL
onto the next boot stage?

I'm guessing for platforms that support the new driver model it's
possible to add/update information in the device-tree, but what about
platforms that don't currently use the new driver model.

I had a quick search of the mailing list and docs but didn't find
anything obvious. If I've missed something feel free to point me at
it.

Thanks,
Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] rockchip: rk3288: Fix pinctrl for GPIO bank 0

2016-07-25 Thread John Keeping
Bank 0 is the "PMU GPIO" bank which is controlled by the PMU registers
rather than the GRF registers.  In the GRF the top half of the register
is used as a mask so that some bits can be updated without affecting the
others, but in the PMU this feature is not provided and the top half of
the register is reserved.

Take the same approach as the Linux driver to update the value via
read-modify-write but setting the mask for only the bits that have
changed.  The PMU registers ignore the top 16 bits so this works for
both GRF and PMU iomux registers.

Signed-off-by: John Keeping 

---

Changes in v2:
- Clear mask before setting muxval
- Add comments explaining why rk_clrsetreg() can't be used

 drivers/pinctrl/rockchip/pinctrl_rk3288.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3288.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3288.c
index 8cb3b82..0cdaac0 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3288.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3288.c
@@ -589,6 +589,7 @@ static int rk3288_pinctrl_set_pins(struct udevice *dev, int 
banknum, int index,
struct rk3288_pinctrl_priv *priv = dev_get_priv(dev);
uint shift, ind = index;
uint mask;
+   uint value;
u32 *addr;
int ret;
 
@@ -597,7 +598,18 @@ static int rk3288_pinctrl_set_pins(struct udevice *dev, 
int banknum, int index,
  &mask);
if (ret)
return ret;
-   rk_clrsetreg(addr, mask << shift, muxval << shift);
+
+   /*
+* PMU_GPIO0 registers cannot be selectively written so we cannot use
+* rk_clrsetreg() here.  However, the upper 16 bits are reserved and
+* are ignored when written, so we can use the same code as for the
+* other GPIO banks providing that we preserve the value of the other
+* bits.
+*/
+   value = readl(addr);
+   value &= ~(mask << shift);
+   value |= (mask << (shift + 16)) | (muxval << shift);
+   writel(value, addr);
 
/* Handle pullup/pulldown */
if (flags) {
@@ -615,7 +627,12 @@ static int rk3288_pinctrl_set_pins(struct udevice *dev, 
int banknum, int index,
addr = &priv->grf->gpio1_p[banknum - 1][ind];
debug("%s: addr=%p, val=%x, shift=%x\n", __func__, addr, val,
  shift);
-   rk_clrsetreg(addr, 3 << shift, val << shift);
+
+   /* As above, rk_clrsetreg() cannot be used here. */
+   value = readl(addr);
+   value &= ~(mask << shift);
+   value |= (3 << (shift + 16)) | (val << shift);
+   writel(value, addr);
}
 
return 0;
-- 
2.9.0.465.g8850cbc.dirty

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


Re: [U-Boot] [PATCH v2] rockchip: rk3288: Fix pinctrl for GPIO bank 0

2016-07-25 Thread Kever Yang

Hi John,

On 07/25/2016 05:02 PM, John Keeping wrote:

Bank 0 is the "PMU GPIO" bank which is controlled by the PMU registers
rather than the GRF registers.  In the GRF the top half of the register
is used as a mask so that some bits can be updated without affecting the
others, but in the PMU this feature is not provided and the top half of
the register is reserved.

Take the same approach as the Linux driver to update the value via
read-modify-write but setting the mask for only the bits that have
changed.  The PMU registers ignore the top 16 bits so this works for
both GRF and PMU iomux registers.

Signed-off-by: John Keeping 

---

Changes in v2:
- Clear mask before setting muxval
- Add comments explaining why rk_clrsetreg() can't be used

  drivers/pinctrl/rockchip/pinctrl_rk3288.c | 21 +++--
  1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/rockchip/pinctrl_rk3288.c 
b/drivers/pinctrl/rockchip/pinctrl_rk3288.c
index 8cb3b82..0cdaac0 100644
--- a/drivers/pinctrl/rockchip/pinctrl_rk3288.c
+++ b/drivers/pinctrl/rockchip/pinctrl_rk3288.c
@@ -589,6 +589,7 @@ static int rk3288_pinctrl_set_pins(struct udevice *dev, int 
banknum, int index,
struct rk3288_pinctrl_priv *priv = dev_get_priv(dev);
uint shift, ind = index;
uint mask;
+   uint value;
u32 *addr;
int ret;
  
@@ -597,7 +598,18 @@ static int rk3288_pinctrl_set_pins(struct udevice *dev, int banknum, int index,

  &mask);
if (ret)
return ret;
-   rk_clrsetreg(addr, mask << shift, muxval << shift);
+
+   /*
+* PMU_GPIO0 registers cannot be selectively written so we cannot use
+* rk_clrsetreg() here.  However, the upper 16 bits are reserved and
+* are ignored when written, so we can use the same code as for the
+* other GPIO banks providing that we preserve the value of the other
+* bits.
+*/
+   value = readl(addr);
+   value &= ~(mask << shift);
+   value |= (mask << (shift + 16)) | (muxval << shift);
+   writel(value, addr);
  
  	/* Handle pullup/pulldown */

if (flags) {
@@ -615,7 +627,12 @@ static int rk3288_pinctrl_set_pins(struct udevice *dev, 
int banknum, int index,
addr = &priv->grf->gpio1_p[banknum - 1][ind];
debug("%s: addr=%p, val=%x, shift=%x\n", __func__, addr, val,
  shift);
-   rk_clrsetreg(addr, 3 << shift, val << shift);
+
+   /* As above, rk_clrsetreg() cannot be used here. */
+   value = readl(addr);
+   value &= ~(mask << shift);
+   value |= (3 << (shift + 16)) | (val << shift);
+   writel(value, addr);
}
  
  	return 0;

Reviewed-by: Kever Yang 

Thanks,
- Kever

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


Re: [U-Boot] cmd, nand: add an option to disable the verification when writing in raw mode

2016-07-25 Thread Boris Brezillon
On Sun, 24 Jul 2016 20:41:30 -0500
Scott Wood  wrote:

> On Wed, Jun 15, 2016 at 10:42:18AM +0200, Boris Brezillon wrote:
> > diff --git a/cmd/nand.c b/cmd/nand.c
> > index 583a18f..3a5e3a0 100644
> > --- a/cmd/nand.c
> > +++ b/cmd/nand.c
> > @@ -306,7 +306,7 @@ static void nand_print_and_set_info(int idx)
> >  }
> >  
> >  static int raw_access(struct mtd_info *mtd, ulong addr, loff_t off,
> > - ulong count, int read)
> > + ulong count, int read, int noverify)
> >  {
> > int ret = 0;
> >  
> > @@ -324,7 +324,7 @@ static int raw_access(struct mtd_info *mtd, ulong addr, 
> > loff_t off,
> > ret = mtd_read_oob(mtd, off, &ops);
> > } else {
> > ret = mtd_write_oob(mtd, off, &ops);
> > -   if (!ret)
> > +   if (!ret && !no_verify)
> > ret = nand_verify_page_oob(mtd, &ops, off);  
> 
> "noverify" versus "no_verify"...  I've fixed it while applying.

Oops, sorry about that.

> 
> I assume/hope that you just sent an old version by mistake, and that this
> was actually tested?

Yes, it was tested, just forgot to amend my commit :-(.
Thanks for fixing the problem.

Regards,

Boris


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


[U-Boot] [PATCH] ARM: at91/dt: Add device tree for SAMA5D2 Xplained

2016-07-25 Thread Wenyou Yang
Add device tree for SAMA5D2 Xplained board.

Signed-off-by: Wenyou Yang 
---

 arch/arm/dts/Makefile  |   3 +
 arch/arm/dts/at91-sama5d2_xplained.dts | 200 ++
 arch/arm/dts/sama5d2.dtsi  | 671 +
 3 files changed, 874 insertions(+)
 create mode 100644 arch/arm/dts/at91-sama5d2_xplained.dts
 create mode 100644 arch/arm/dts/sama5d2.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ef573ec..725e5de 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -262,6 +262,9 @@ dtb-$(CONFIG_SOC_KEYSTONE) += k2hk-evm.dtb \
k2e-evm.dtb \
k2g-evm.dtb
 
+dtb-$(CONFIG_TARGET_SAMA5D2_XPLAINED) += \
+   at91-sama5d2_xplained.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/at91-sama5d2_xplained.dts 
b/arch/arm/dts/at91-sama5d2_xplained.dts
new file mode 100644
index 000..3709437
--- /dev/null
+++ b/arch/arm/dts/at91-sama5d2_xplained.dts
@@ -0,0 +1,200 @@
+/dts-v1/;
+#include "sama5d2.dtsi"
+#include "sama5d2-pinfunc.h"
+
+/ {
+   model = "Atmel SAMA5D2 Xplained";
+   compatible = "atmel,sama5d2-xplained", "atmel,sama5d2", "atmel,sama5";
+
+   chosen {
+   stdout-path = &uart1;
+   };
+
+   ahb {
+   usb1: ohci@0040 {
+   num-ports = <3>;
+   atmel,vbus-gpio = <&pioA 42 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usb_default>;
+   status = "okay";
+   };
+
+   usb2: ehci@0050 {
+   status = "okay";
+   };
+
+   sdmmc0: sdio-host@a000 {
+   bus-width = <8>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_sdmmc0_cmd_dat_default 
&pinctrl_sdmmc0_ck_cd_default>;
+   status = "okay";
+   };
+
+   sdmmc1: sdio-host@b000 {
+   bus-width = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_sdmmc1_cmd_dat_default 
&pinctrl_sdmmc1_ck_cd_default>;
+   status = "okay"; /* conflict with qspi0 */
+   };
+
+   apb {
+   qspi0: spi@f002 {
+   status = "okay";
+
+   flash@0 {
+   compatible = "atmel,sama5d2-qspi-flash";
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_qspi0_default>;
+   spi-max-frequency = <8300>;
+
+   partition@ {
+   label = "boot";
+   reg = <0x 0x00c0>;
+   };
+
+   partition@00c0 {
+   label = "rootfs";
+   reg = <0x00c0 0x>;
+   };
+   };
+   };
+
+   spi0: spi@f800 {
+   cs-gpios = <&pioA 17 0>, <0>, <0>, <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_spi0_default>;
+   status = "okay";
+
+   spi_flash@0 {
+   compatible = "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <5000>;
+   };
+   };
+
+   macb0: ethernet@f8008000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_macb0_rmii 
&pinctrl_macb0_phy_irq>;
+   phy-mode = "rmii";
+   status = "okay";
+
+   ethernet-phy@1 {
+   reg = <0x1>;
+   };
+   };
+
+   uart1: serial@f802 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_uart1_default>;
+   status = "okay";
+   };
+
+   i2c1: i2c@fc028000 {
+   pinctrl-names = "default";
+   pinct

Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h

2016-07-25 Thread Robert P. J. Day
On Mon, 25 Jul 2016, Wolfgang Denk wrote:

> Dear Robert,
>
> In message  you 
> wrote:
>
> >3094 CONFIG_AT91SAM9XE
> >3095 enable special bootcounter support on at91sam9xe 
> > based boards.
> >3096 CONFIG_BLACKFIN
> >3097 enable special bootcounter support on blackfin 
> > based boards.
> >3098 CONFIG_SOC_DA8XX
> >3099 enable special bootcounter support on da850 based 
> > boards.
>
> This is name space pollution t best, and has potential to cause
> unwanted side effects.  This needs thorough checking and cleanup, if
> it should turn out thatthese macros are used only to select specific
> bootcount implementations - in that case, they should be renamed
> into something like CONFIG_BOOTCOUNT_* or such.
>
> Heiko, maybe you could have a look at that, please?

  i'm not sure it's as bad as it looks, since those macros are used
specifically in drivers/bootcount/Makefile:

  obj-y   += bootcount.o
  obj-$(CONFIG_AT91SAM9XE)+= bootcount_at91.o
  obj-$(CONFIG_BLACKFIN)  += bootcount_blackfin.o
  obj-$(CONFIG_SOC_DA8XX) += bootcount_davinci.o
  obj-$(CONFIG_BOOTCOUNT_AM33XX)  += bootcount_davinci.o
  obj-$(CONFIG_BOOTCOUNT_RAM) += bootcount_ram.o
  obj-$(CONFIG_BOOTCOUNT_ENV) += bootcount_env.o
  obj-$(CONFIG_BOOTCOUNT_I2C) += bootcount_i2c.o

and drivers/bootcount/ is processed only if:

  obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/

but i do see the single, more precise example of
CONFIG_BOOTCOUNT_AM33XX, so someone else can decide if anything
should be renamed here.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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


Re: [U-Boot] [RFC PATCH v2 3/5] spl: dfu: adding dfu support functions for SPL-DFU

2016-07-25 Thread Lukasz Majewski
Hi Ravi,

> Adding support functions to run dfu spl commands.
> 
> Signed-off-by: Ravi Babu 
> ---
>  common/spl/Makefile  |1 +
>  common/spl/spl_dfu.c |   57
> ++
> include/spl.h|8 +++ 3 files changed, 66 insertions(+)
>  create mode 100644 common/spl/spl_dfu.c
> 
> diff --git a/common/spl/Makefile b/common/spl/Makefile
> index 2e0f695..0850da0 100644
> --- a/common/spl/Makefile
> +++ b/common/spl/Makefile
> @@ -21,4 +21,5 @@ obj-$(CONFIG_SPL_USB_SUPPORT) += spl_usb.o
>  obj-$(CONFIG_SPL_FAT_SUPPORT) += spl_fat.o
>  obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
>  obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
> +obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o
>  endif
> diff --git a/common/spl/spl_dfu.c b/common/spl/spl_dfu.c
> new file mode 100644
> index 000..e8d0ba1
> --- /dev/null
> +++ b/common/spl/spl_dfu.c
> @@ -0,0 +1,57 @@
> +/*
> + * (C) Copyright 2016
> + * Texas Instruments, 
> + *
> + * Ravi B 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int run_dfu(int usb_index, char *interface, char *devstring)
> +{
> + int ret;
> +
> + ret = dfu_init_env_entities(interface, devstring);
> + if (ret) {
> + dfu_free_entities();
> + goto exit;
> + }
> +
> + run_usb_dnl_gadget(usb_index, "usb_dnl_dfu");
> +exit:
> + dfu_free_entities();
> + return ret;
> +}
> +
> +int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface,
 ^^ this is a bit
 misleading.
 I would rename it to "alt_info_str"

> char *devstr) +{
> + char *str_env;
> + int ret;
> +
> + /* set default environment */
> + set_default_env(0);

set_default_env() accepts const char *s as the argument. Please replace
0 -> NULL

> + str_env = getenv(dfu_alt_info);
> + if (!str_env) {
> + error("\"dfu_alt_info\" env variable not
> defined!\n");
> + return -EINVAL;
> + }
> +
> + ret = setenv("dfu_alt_info", str_env);
> + if (ret) {
> + error("unable to set env variable
> \"dfu_alt_info\"!\n");
> + return -EINVAL;
> + }

I'm a bit confused with this env flow.

Is it required on your platform to:

1. set_default_env(NULL) - which sets default envs (one which are
mostly defined at ./include/ file) in RAM

2. call getenv with "dfu_alt_info_ram", which reads this value from RAM

3. call setenv() to store already in ram available env variable to some
medium?

If you want to store default envs in the medium (e.g. eMMC), I think
that it would be easier to call "saveenv".

Otherwise, I would stay with default envs, since we only use this
u-boot for flashing other binaries.

> +
> + /* invoke dfu command */
> + return run_dfu(usbctrl, interface, devstr);
> +}
> diff --git a/include/spl.h b/include/spl.h
> index 2360466..1524e26 100644
> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -140,4 +140,12 @@ void spl_board_init(void);
>   */
>  bool spl_was_boot_source(void);
>  
> +/**
> + * spl_dfu_cmd- run dfu command with chosen mmc device interface
> + * @param usb_index - usb controller number
> + * @param mmc_dev -  mmc device nubmer
> + *
> + * @return 0 on success, otherwise error code
> + */
> +int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface,
> char *devstr); #endif



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v8] mmc: atmel_sdhci: Convert to the driver model support

2016-07-25 Thread Wenyou Yang
Convert the driver to the driver model while retaining the existing
legacy code. This allows the driver to support boards that have
converted to driver model as well as those that have not.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v8:
 - Make atmel_sdhci_get_clk() to get clock device.
 - Use ulong type for gck_rate.
 - Remove meaningless type casting before dev->name.

Changes in v7:
 - Add support for using driver model for block devices and MMC operations.
 - Change clk_client.h -> clk.h to adapt to clk API conversion.

Changes in v6:
 - Remove unnecessary white space.
 - Use sdhci_read(), instead of readl().
 - Remove the local variables min_clk.

Changes in v5:
 - Add Reviewed-by tag.

Changes in v4:
 - Update the clk API based on [PATCH] clk: convert API to match
   reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
 - Remove check on dev_get_parent() return.
 - Fixed the return value, such as -ENODEV->-EINVAL.

Changes in v3:
 - Remove the redundant log print.

Changes in v2:
 - Add clock support, include enabling peripheral clock
   and generated clock.
 - Retain the existing legacy code to support boards which have not
   converted to driver model.

 drivers/mmc/Kconfig   |  10 
 drivers/mmc/atmel_sdhci.c | 127 ++
 include/sdhci.h   |   2 +
 3 files changed, 139 insertions(+)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 79cf18f..49b325e 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -34,6 +34,16 @@ config MSM_SDHCI
   SD 3.0 specifications. Both SD and eMMC devices are supported.
  Card-detect gpios are not supported.
 
+config ATMEL_SDHCI
+   bool "Atmel SDHCI controller support"
+   depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
+   help
+ This enables support for the Atmel SDHCI controller, which supports
+ the embedded MultiMedia Card (e.MMC) Specification V4.51, the SD
+ Memory Card Specification V3.0, and the SDIO V3.0 specification.
+ It is compliant with the SD Host Controller Standard V3.0
+ specification.
+
 config ROCKCHIP_DWMMC
bool "Rockchip SD/MMC controller support"
depends on DM_MMC && OF_CONTROL
diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index 24b68b6..8a4f347 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -6,12 +6,15 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
 #define ATMEL_SDHC_MIN_FREQ40
 
+#ifndef CONFIG_DM_MMC
 int atmel_sdhci_init(void *regbase, u32 id)
 {
struct sdhci_host *host;
@@ -38,3 +41,127 @@ int atmel_sdhci_init(void *regbase, u32 id)
 
return 0;
 }
+
+#else
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct atmel_sdhci_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
+static int atmel_sdhci_get_clk(struct udevice *dev, int index, struct clk *clk)
+{
+   struct udevice *dev_clk;
+   int periph, ret;
+
+   ret = clk_get_by_index(dev, index, clk);
+   if (ret)
+   return ret;
+
+   periph = fdtdec_get_uint(gd->fdt_blob, clk->dev->of_offset, "reg", -1);
+   if (periph < 0)
+   return -EINVAL;
+
+   dev_clk = dev_get_parent(clk->dev);
+   ret = clk_request(dev_clk, clk);
+   if (ret)
+   return ret;
+
+   clk->id = periph;
+
+   return 0;
+}
+
+static int atmel_sdhci_probe(struct udevice *dev)
+{
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
+   struct sdhci_host *host = dev_get_priv(dev);
+   u32 max_clk;
+   u32 caps, caps_1;
+   u32 clk_base, clk_mul;
+   ulong gck_rate;
+   struct clk clk;
+   int ret;
+
+   ret = atmel_sdhci_get_clk(dev, 0, &clk);
+   if (ret)
+   return ret;
+
+   ret = clk_enable(&clk);
+   if (ret)
+   return ret;
+
+   host->name = dev->name;
+   host->ioaddr = (void *)dev_get_addr(dev);
+
+   host->quirks = 0;
+   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
+
+   host->bus_width = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"bus-width", 4);
+
+   caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+   clk_base = (caps & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
+   caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+   clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
+   gck_rate = clk_base * 100 * (clk_mul + 1);
+
+   ret = atmel_sdhci_get_clk(dev, 1, &clk);
+   if (ret)
+   return ret;
+
+   ret = clk_set_rate(&clk, gck_rate);
+   if (ret)
+   return ret;
+
+   max_clk = clk_get_rate(&clk);
+   if (!max_clk)
+   return -EINVAL;
+
+   ret = sdhci_setup_cfg(&plat->cfg, dev->name, host->bus_width,
+

Re: [U-Boot] [RFC PATCH v2 2/5] common: dfu: saperate the dfu common functionality

2016-07-25 Thread Lukasz Majewski
Hi Ravi,

> The cmd_dfu functionality is been used by both SPL and
> u-boot, saperating the core dfu functionality moving
> it to common/dfu.c.
> 
> Signed-off-by: Ravi Babu 
> ---
>  cmd/dfu.c   |   61 ++
>  common/Makefile |2 ++
>  common/dfu.c|   88
> +++
> include/g_dnl.h |1 + 4 files changed, 93 insertions(+), 59
> deletions(-) create mode 100644 common/dfu.c
> 
> diff --git a/cmd/dfu.c b/cmd/dfu.c
> index d8aae26..04291f6 100644
> --- a/cmd/dfu.c
> +++ b/cmd/dfu.c
> @@ -21,7 +21,6 @@
>  
>  static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[]) {
> - bool dfu_reset = false;
>  
>   if (argc < 4)
>   return CMD_RET_USAGE;
> @@ -30,7 +29,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) char *interface = argv[2];
>   char *devstring = argv[3];
>  
> - int ret, i = 0;
> + int ret;
>  #ifdef CONFIG_DFU_TFTP
>   unsigned long addr = 0;
>   if (!strcmp(argv[1], "tftp")) {
> @@ -52,67 +51,11 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) }
>  
>   int controller_index = simple_strtoul(usb_controller, NULL,
> 0);
> - board_usb_init(controller_index, USB_INIT_DEVICE);
> - g_dnl_clear_detach();
> - g_dnl_register("usb_dnl_dfu");
> - while (1) {
> - if (g_dnl_detach()) {
> - /*
> -  * Check if USB bus reset is performed after
> detach,
> -  * which indicates that -R switch has been
> passed to
> -  * dfu-util. In this case reboot the device
> -  */
> - if (dfu_usb_get_reset()) {
> - dfu_reset = true;
> - goto exit;
> - }
>  
> - /*
> -  * This extra number of
> usb_gadget_handle_interrupts()
> -  * calls is necessary to assure correct
> transmission
> -  * completion with dfu-util
> -  */
> - if (++i == 1)
> - goto exit;
> - }
> + run_usb_dnl_gadget(controller_index, "usb_dnl_dfu");
>  
> - if (ctrlc())
> - goto exit;
> -
> - if (dfu_get_defer_flush()) {
> - /*
> -  * Call to usb_gadget_handle_interrupts() is
> necessary
> -  * to act on ZLP OUT transaction from HOST
> PC after
> -  * transmitting the whole file.
> -  *
> -  * If this ZLP OUT packet is NAK'ed, the
> HOST libusb
> -  * function fails after timeout (by default
> it is set to
> -  * 5 seconds). In such situation the
> dfu-util program
> -  * exits with error message.
> -  */
> -
> usb_gadget_handle_interrupts(controller_index);
> - ret = dfu_flush(dfu_get_defer_flush(), NULL,
> 0, 0);
> - dfu_set_defer_flush(NULL);
> - if (ret) {
> - error("Deferred dfu_flush()
> failed!");
> - goto exit;
> - }
> - }
> -
> - WATCHDOG_RESET();
> - usb_gadget_handle_interrupts(controller_index);
> - }
> -exit:
> - g_dnl_unregister();
> - board_usb_cleanup(controller_index, USB_INIT_DEVICE);
>  done:
>   dfu_free_entities();
> -
> - if (dfu_reset)
> - run_command("reset", 0);
> -
> - g_dnl_clear_detach();
> -
>   return ret;
>  }
>  
> diff --git a/common/Makefile b/common/Makefile
> index 7a7a1b4..83bd3f4 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -87,6 +87,7 @@ obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
>  endif # !CONFIG_SPL_BUILD
>  
>  ifdef CONFIG_SPL_BUILD
> +obj-$(CONFIG_SPL_DFU_SUPPORT) += dfu.o
>  obj-$(CONFIG_SPL_DFU_SUPPORT) += cli_hush.o
>  obj-$(CONFIG_SPL_HASH_SUPPORT) += hash.o
>  obj-$(CONFIG_ENV_IS_IN_FLASH) += env_flash.o
> @@ -160,6 +161,7 @@ obj-$(CONFIG_CMDLINE) += cli_simple.o
>  
>  obj-y += cli.o
>  obj-$(CONFIG_CMDLINE) += cli_readline.o
> +obj-$(CONFIG_CMD_DFU) += dfu.o
>  obj-y += command.o
>  obj-y += s_record.o
>  obj-y += xyzModem.o
> diff --git a/common/dfu.c b/common/dfu.c
> new file mode 100644
> index 000..c6a7a58
> --- /dev/null
> +++ b/common/dfu.c
> @@ -0,0 +1,88 @@
> +/*
> + * dfu.c -- dfu command

Please write:

dfu.c -- common dfu command code

> + *
> + * Copyright (C) 2015
> + * Lukasz Majewski 
> + *
> + * Copyright (C) 2012 Samsung Electronics
> + * authors: Andrzej Pietrasiewicz 
> + *   Lukasz Majewski 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#inc

[U-Boot] [PATCH v6] dm: at91: Add driver model support for the spi driver

2016-07-25 Thread Wenyou Yang
Add driver model support while retaining the existing legacy code.
This allows the driver to support boards that have converted to
driver model as well as those that have not.

Signed-off-by: Wenyou Yang 
Reviewed-by: Simon Glass 
---

Changes in v6:
 - Remove the two flash related options.

Changes in v5:
 - Change clk_client.h -> clk.h to adapt to clk API conversion.

Changes in v4:
 - Collect Reviewed-by tag.
 - Update the clk API based on [PATCH] clk: convert API to match
   reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
 - Remove check on dev_get_parent() return.
 - Fixed the return value, -ENODEV->-EINVAL.
 - Retain #include  line.

Changes in v3:
 - Remove redundant log print.

Changes in v2:
 - Add clock support.

 drivers/spi/Kconfig |   7 ++
 drivers/spi/atmel_spi.c | 303 
 2 files changed, 310 insertions(+)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aca385d..16ed231 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -32,6 +32,13 @@ config ATH79_SPI
  uses driver model and requires a device tree binding to operate.
  please refer to doc/device-tree-bindings/spi/spi-ath79.txt.
 
+config ATMEL_SPI
+   bool "Atmel SPI driver"
+   depends on ARCH_AT91
+   help
+ Enable the Atmel SPI driver. This driver can be used to access
+ the SPI Flash, such as AT25DF321.
+
 config CADENCE_QSPI
bool "Cadence QSPI driver"
help
diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
index ed6278b..98bee35 100644
--- a/drivers/spi/atmel_spi.c
+++ b/drivers/spi/atmel_spi.c
@@ -4,6 +4,9 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
@@ -11,9 +14,15 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include "atmel_spi.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifndef CONFIG_DM_SPI
+
 static int spi_has_wdrbt(struct atmel_spi_slave *slave)
 {
unsigned int ver;
@@ -209,3 +218,297 @@ out:
 
return 0;
 }
+
+#else
+
+#define MAX_CS_COUNT   4
+
+struct atmel_spi_platdata {
+   struct at91_spi *regs;
+};
+
+struct atmel_spi_priv {
+   unsigned int freq;  /* Default frequency */
+   unsigned int mode;
+   ulong bus_clk_rate;
+   struct gpio_desc cs_gpios[MAX_CS_COUNT];
+};
+
+static int atmel_spi_claim_bus(struct udevice *dev)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
+   struct atmel_spi_priv *priv = dev_get_priv(bus);
+   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
+   struct at91_spi *reg_base = bus_plat->regs;
+   u32 cs = slave_plat->cs;
+   u32 freq = priv->freq;
+   u32 scbr, csrx, mode;
+
+   scbr = (priv->bus_clk_rate + freq - 1) / freq;
+   if (scbr > ATMEL_SPI_CSRx_SCBR_MAX)
+   return -EINVAL;
+
+   if (scbr < 1)
+   scbr = 1;
+
+   csrx = ATMEL_SPI_CSRx_SCBR(scbr);
+   csrx |= ATMEL_SPI_CSRx_BITS(ATMEL_SPI_BITS_8);
+
+   if (!(priv->mode & SPI_CPHA))
+   csrx |= ATMEL_SPI_CSRx_NCPHA;
+   if (priv->mode & SPI_CPOL)
+   csrx |= ATMEL_SPI_CSRx_CPOL;
+
+   writel(csrx, ®_base->csr[cs]);
+
+   mode = ATMEL_SPI_MR_MSTR |
+  ATMEL_SPI_MR_MODFDIS |
+  ATMEL_SPI_MR_WDRBT |
+  ATMEL_SPI_MR_PCS(~(1 << cs));
+
+   writel(mode, ®_base->mr);
+
+   writel(ATMEL_SPI_CR_SPIEN, ®_base->cr);
+
+   return 0;
+}
+
+static int atmel_spi_release_bus(struct udevice *dev)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
+
+   writel(ATMEL_SPI_CR_SPIDIS, &bus_plat->regs->cr);
+
+   return 0;
+}
+
+static void atmel_spi_cs_activate(struct udevice *dev)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_priv *priv = dev_get_priv(bus);
+   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
+   u32 cs = slave_plat->cs;
+
+   dm_gpio_set_value(&priv->cs_gpios[cs], 0);
+}
+
+static void atmel_spi_cs_deactivate(struct udevice *dev)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_priv *priv = dev_get_priv(bus);
+   struct dm_spi_slave_platdata *slave_plat = dev_get_parent_platdata(dev);
+   u32 cs = slave_plat->cs;
+
+   dm_gpio_set_value(&priv->cs_gpios[cs], 1);
+}
+
+static int atmel_spi_xfer(struct udevice *dev, unsigned int bitlen,
+ const void *dout, void *din, unsigned long flags)
+{
+   struct udevice *bus = dev_get_parent(dev);
+   struct atmel_spi_platdata *bus_plat = dev_get_platdata(bus);
+   struct at91_spi *reg_base = bus_plat->regs;
+
+   u32 len_tx, len_rx, len;
+   u32 status;
+   const u8 *txp = dout;
+   u8 *rxp = din;
+   u8 value;
+
+   if (bitlen ==

Re: [U-Boot] [PATCH 1/2] mmc: sdhci: set to INT_DATA_END when there are data

2016-07-25 Thread Minkyu Kang
Hi,

On 25/07/16 13:55, Jaehoon Chung wrote:
> Hi All,
> 
> On 07/12/2016 09:55 PM, Lukasz Majewski wrote:
>> Hi Jaehoon,
>>
>>> There is no data, it doesn't needs to wait for completing data
>>> transfer. (It seems that it can be removed.)
>>> Almost all timeout error is occured from stop command without data.
>>> After applied this patch, I hope that we don't need to increase
>>> timeout value anymore.
>>
>> This patch fixes issue (in a better way) for Odroid U3 write
>> performance (http://patchwork.ozlabs.org/patch/646932/) and hence
>> should be used.
>>
> 
> Is there any other opinion for this patch?

looks reasonable.

Acked-by: Minkyu Kang 

> Who is maintaining u-boot-mmc? Is Pantelis still maintaining u-boot-mmc?
> 
> Who can apply this patch and patch relevant to mmc?
> 

Pantelis seems to away from mailing list.
If so, I think we need discuss about new custodian for mmc.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v8] mmc: atmel_sdhci: Convert to the driver model support

2016-07-25 Thread Jaehoon Chung
On 07/25/2016 06:56 PM, Wenyou Yang wrote:
> Convert the driver to the driver model while retaining the existing
> legacy code. This allows the driver to support boards that have
> converted to driver model as well as those that have not.
> 
> Signed-off-by: Wenyou Yang 
> Reviewed-by: Simon Glass 


Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> 
> Changes in v8:
>  - Make atmel_sdhci_get_clk() to get clock device.
>  - Use ulong type for gck_rate.
>  - Remove meaningless type casting before dev->name.
> 
> Changes in v7:
>  - Add support for using driver model for block devices and MMC operations.
>  - Change clk_client.h -> clk.h to adapt to clk API conversion.
> 
> Changes in v6:
>  - Remove unnecessary white space.
>  - Use sdhci_read(), instead of readl().
>  - Remove the local variables min_clk.
> 
> Changes in v5:
>  - Add Reviewed-by tag.
> 
> Changes in v4:
>  - Update the clk API based on [PATCH] clk: convert API to match
>reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
>  - Remove check on dev_get_parent() return.
>  - Fixed the return value, such as -ENODEV->-EINVAL.
> 
> Changes in v3:
>  - Remove the redundant log print.
> 
> Changes in v2:
>  - Add clock support, include enabling peripheral clock
>and generated clock.
>  - Retain the existing legacy code to support boards which have not
>converted to driver model.
> 
>  drivers/mmc/Kconfig   |  10 
>  drivers/mmc/atmel_sdhci.c | 127 
> ++
>  include/sdhci.h   |   2 +
>  3 files changed, 139 insertions(+)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 79cf18f..49b325e 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -34,6 +34,16 @@ config MSM_SDHCI
>SD 3.0 specifications. Both SD and eMMC devices are supported.
> Card-detect gpios are not supported.
>  
> +config ATMEL_SDHCI
> + bool "Atmel SDHCI controller support"
> + depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
> + help
> +   This enables support for the Atmel SDHCI controller, which supports
> +   the embedded MultiMedia Card (e.MMC) Specification V4.51, the SD
> +   Memory Card Specification V3.0, and the SDIO V3.0 specification.
> +   It is compliant with the SD Host Controller Standard V3.0
> +   specification.
> +
>  config ROCKCHIP_DWMMC
>   bool "Rockchip SD/MMC controller support"
>   depends on DM_MMC && OF_CONTROL
> diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
> index 24b68b6..8a4f347 100644
> --- a/drivers/mmc/atmel_sdhci.c
> +++ b/drivers/mmc/atmel_sdhci.c
> @@ -6,12 +6,15 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  
>  #define ATMEL_SDHC_MIN_FREQ  40
>  
> +#ifndef CONFIG_DM_MMC
>  int atmel_sdhci_init(void *regbase, u32 id)
>  {
>   struct sdhci_host *host;
> @@ -38,3 +41,127 @@ int atmel_sdhci_init(void *regbase, u32 id)
>  
>   return 0;
>  }
> +
> +#else
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct atmel_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> +static int atmel_sdhci_get_clk(struct udevice *dev, int index, struct clk 
> *clk)
> +{
> + struct udevice *dev_clk;
> + int periph, ret;
> +
> + ret = clk_get_by_index(dev, index, clk);
> + if (ret)
> + return ret;
> +
> + periph = fdtdec_get_uint(gd->fdt_blob, clk->dev->of_offset, "reg", -1);
> + if (periph < 0)
> + return -EINVAL;
> +
> + dev_clk = dev_get_parent(clk->dev);
> + ret = clk_request(dev_clk, clk);
> + if (ret)
> + return ret;
> +
> + clk->id = periph;
> +
> + return 0;
> +}
> +
> +static int atmel_sdhci_probe(struct udevice *dev)
> +{
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
> + struct sdhci_host *host = dev_get_priv(dev);
> + u32 max_clk;
> + u32 caps, caps_1;
> + u32 clk_base, clk_mul;
> + ulong gck_rate;
> + struct clk clk;
> + int ret;
> +
> + ret = atmel_sdhci_get_clk(dev, 0, &clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_enable(&clk);
> + if (ret)
> + return ret;
> +
> + host->name = dev->name;
> + host->ioaddr = (void *)dev_get_addr(dev);
> +
> + host->quirks = 0;
> + host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
> +
> + host->bus_width = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
> +  "bus-width", 4);
> +
> + caps = sdhci_readl(host, SDHCI_CAPABILITIES);
> + clk_base = (caps & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
> + caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
> + clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
> + gck_rate = clk_base * 100 * (clk_mul + 1);
> +
> + ret = atmel_sdhci_get_clk(dev, 1, &

[U-Boot] [PATCH v2 2/8] tools: moveconfig: do not check clean tree and compilers for -H option

2016-07-25 Thread Masahiro Yamada
The clean tree (make mrproper) and compilers are required when moving
config options, but not needed when we only cleanup headers.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 tools/moveconfig.py | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index b1190e2..05a581f 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -1042,11 +1042,9 @@ def main():
 
 check_top_directory()
 
-check_clean_directory()
-
-update_cross_compile(options.color)
-
 if not options.cleanup_headers_only:
+check_clean_directory()
+update_cross_compile(options.color)
 move_config(configs, options)
 
 if configs:
-- 
1.9.1

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


[U-Boot] [PATCH v2 0/8] tools: moveconfig: a collection of improvement of garbage cleaning

2016-07-25 Thread Masahiro Yamada

Masahiro Yamada (8):
  tools: moveconfig: do not cleanup headers in include/generated
  tools: moveconfig: do not check clean tree and compilers for -H option
  tools: moveconfig: trim garbage lines after header cleanups
  tools: moveconfig: show result of header cleaning in unified diff
  tools: moveconfig: show diffs of cleaned headers in color
  tools: moveconfig: fix cleanup of defines across multiple lines
  tools: moveconfig: make getting all defconfigs into helper function
  tools: moveconfig: support CONFIG_SYS_EXTRA_OPTIONS cleaning

 tools/moveconfig.py | 231 ++--
 1 file changed, 208 insertions(+), 23 deletions(-)

-- 
1.9.1

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


[U-Boot] [PATCH v2 3/8] tools: moveconfig: trim garbage lines after header cleanups

2016-07-25 Thread Masahiro Yamada
The tools/moveconfig.py has a feature to cleanup #define/#undef's
of moved config options, but I want this tool to do a better job.

For example, when we are moving CONFIG_FOO and its define is
surrounded by #ifdef ... #endif, like follows:

  #ifdef CONFIG_BAR
  #  define CONFIG_FOO
  #endif

The header cleanup will leave empty #ifdef ... #endif:

  #ifdef CONFIG_BAR
  #endif

Likewise, if a define line between two blank lines

  
  #define CONFIG_FOO
  
---

Changes in v2:
  - cleanup between #elif ... #endif,
#elif ... #elif

 tools/moveconfig.py | 85 ++---
 1 file changed, 81 insertions(+), 4 deletions(-)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 05a581f..03e4953 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -160,6 +160,7 @@ To see the complete list of supported options, run
 
 """
 
+import copy
 import filecmp
 import fnmatch
 import multiprocessing
@@ -319,6 +320,57 @@ def update_cross_compile(color_enabled):
 
 CROSS_COMPILE[arch] = cross_compile
 
+def extend_matched_lines(lines, matched, pre_patterns, post_patterns, 
extend_pre,
+ extend_post):
+"""Extend matched lines if desired patterns are found before/after already
+matched lines.
+
+Arguments:
+  lines: A list of lines handled.
+  matched: A list of line numbers that have been already matched.
+   (will be updated by this function)
+  pre_patterns: A list of regular expression that should be matched as
+preamble.
+  post_patterns: A list of regular expression that should be matched as
+ postamble.
+  extend_pre: Add the line number of matched preamble to the matched list.
+  extend_post: Add the line number of matched postamble to the matched 
list.
+"""
+extended_matched = []
+
+j = matched[0]
+
+for i in matched:
+if i == 0 or i < j:
+continue
+j = i
+while j in matched:
+j += 1
+if j >= len(lines):
+break
+
+for p in pre_patterns:
+if p.search(lines[i - 1]):
+break
+else:
+# not matched
+continue
+
+for p in post_patterns:
+if p.search(lines[j]):
+break
+else:
+# not matched
+continue
+
+if extend_pre:
+extended_matched.append(i - 1)
+if extend_post:
+extended_matched.append(j)
+
+matched += extended_matched
+matched.sort()
+
 def cleanup_one_header(header_path, patterns, dry_run):
 """Clean regex-matched lines away from a file.
 
@@ -334,13 +386,38 @@ def cleanup_one_header(header_path, patterns, dry_run):
 matched = []
 for i, line in enumerate(lines):
 for pattern in patterns:
-m = pattern.search(line)
-if m:
-print '%s: %s: %s' % (header_path, i + 1, line),
+if pattern.search(line):
 matched.append(i)
 break
 
-if dry_run or not matched:
+if not matched:
+return
+
+# remove empty #ifdef ... #endif, successive blank lines
+pattern_if = re.compile(r'#\s*if(def|ndef)?\W') #  #if, #ifdef, #ifndef
+pattern_elif = re.compile(r'#\s*el(if|se)\W')   #  #elif, #else
+pattern_endif = re.compile(r'#\s*endif\W')  #  #endif
+pattern_blank = re.compile(r'^\s*$')#  empty line
+
+while True:
+old_matched = copy.copy(matched)
+extend_matched_lines(lines, matched, [pattern_if],
+ [pattern_endif], True, True)
+extend_matched_lines(lines, matched, [pattern_elif],
+ [pattern_elif, pattern_endif], True, False)
+extend_matched_lines(lines, matched, [pattern_if, pattern_elif],
+ [pattern_blank], False, True)
+extend_matched_lines(lines, matched, [pattern_blank],
+ [pattern_elif, pattern_endif], True, False)
+extend_matched_lines(lines, matched, [pattern_blank],
+ [pattern_blank], True, False)
+if matched == old_matched:
+break
+
+for i in matched:
+print '%s: %s: %s' % (header_path, i + 1, lines[i]),
+
+if dry_run:
 return
 
 with open(header_path, 'w') as f:
-- 
1.9.1

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


[U-Boot] [PATCH v2 1/8] tools: moveconfig: do not cleanup headers in include/generated

2016-07-25 Thread Masahiro Yamada
The files in include/generated are generated during build and removed
by "make mrproper", so it has no point to touch them by this tool.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 tools/moveconfig.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index bf60dbc..b1190e2 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -371,6 +371,8 @@ def cleanup_headers(configs, dry_run):
 
 for dir in 'include', 'arch', 'board':
 for (dirpath, dirnames, filenames) in os.walk(dir):
+if dirpath == os.path.join('include', 'generated'):
+continue
 for filename in filenames:
 if not fnmatch.fnmatch(filename, '*~'):
 cleanup_one_header(os.path.join(dirpath, filename),
-- 
1.9.1

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


[U-Boot] [PATCH v2 8/8] tools: moveconfig: support CONFIG_SYS_EXTRA_OPTIONS cleaning

2016-07-25 Thread Masahiro Yamada
We mostly move config options from board header files to Kconfig,
but sometimes config defines come from CONFIG_SYS_EXTRA_OPTIONS.

Historically, CONFIG_SYS_EXTRA_OPTIONS originates in boards.cfg,
which was used as a central database of configuration prior to the
Kconfig conversion.

Now, we want to migrate to primary entries in Kconfig rather than
option list in CONFIG_SYS_EXTRA_OPTIONS, so it should be helpful to
have the tool to cleanup CONFIG_SYS_EXTRA_OPTIONS automatically.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Make diffing into a helper function

 tools/moveconfig.py | 74 +
 1 file changed, 74 insertions(+)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 3b7499b..e7b245c 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -494,6 +494,79 @@ def cleanup_headers(configs, options):
 cleanup_one_header(os.path.join(dirpath, filename),
patterns, options)
 
+def cleanup_one_extra_option(defconfig_path, configs, options):
+"""Delete config defines in CONFIG_SYS_EXTRA_OPTIONS in one defconfig file.
+
+Arguments:
+  defconfig_path: path to the cleaned defconfig file.
+  configs: A list of CONFIGs to remove.
+  options: option flags.
+"""
+
+start = 'CONFIG_SYS_EXTRA_OPTIONS="'
+end = '"\n'
+
+with open(defconfig_path) as f:
+lines = f.readlines()
+
+for i, line in enumerate(lines):
+if line.startswith(start) and line.endswith(end):
+break
+else:
+# CONFIG_SYS_EXTRA_OPTIONS was not found in this defconfig
+return
+
+old_tokens = line[len(start):-len(end)].split(',')
+new_tokens = []
+
+for token in old_tokens:
+pos = token.find('=')
+if not (token[:pos] if pos >= 0 else token) in configs:
+new_tokens.append(token)
+
+if new_tokens == old_tokens:
+return
+
+tolines = copy.copy(lines)
+
+if new_tokens:
+tolines[i] = start + ','.join(new_tokens) + end
+else:
+tolines.pop(i)
+
+show_diff(lines, tolines, defconfig_path, options.color)
+
+if options.dry_run:
+return
+
+with open(defconfig_path, 'w') as f:
+for line in tolines:
+f.write(line)
+
+def cleanup_extra_options(configs, options):
+"""Delete config defines in CONFIG_SYS_EXTRA_OPTIONS in defconfig files.
+
+Arguments:
+  configs: A list of CONFIGs to remove.
+  options: option flags.
+"""
+while True:
+choice = raw_input('Clean up CONFIG_SYS_EXTRA_OPTIONS? [y/n]: 
').lower()
+print choice
+if choice == 'y' or choice == 'n':
+break
+
+if choice == 'n':
+return
+
+configs = [ config[len('CONFIG_'):] for config in configs ]
+
+defconfigs = get_all_defconfigs()
+
+for defconfig in defconfigs:
+cleanup_one_extra_option(os.path.join('configs', defconfig), configs,
+ options)
+
 ### classes ###
 class Progress:
 
@@ -1160,6 +1233,7 @@ def main():
 
 if configs:
 cleanup_headers(configs, options)
+cleanup_extra_options(configs, options)
 
 if __name__ == '__main__':
 main()
-- 
1.9.1

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


[U-Boot] [PATCH v2 5/8] tools: moveconfig: show diffs of cleaned headers in color

2016-07-25 Thread Masahiro Yamada
Show code diff in color if --color option is given.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Make diffing into a helper function

 tools/moveconfig.py | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 4f07782..4edcb6c 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -276,13 +276,14 @@ def color_text(color_enabled, color, string):
 else:
 return string
 
-def show_diff(a, b, file_path):
+def show_diff(a, b, file_path, color_enabled):
 """Show unidified diff.
 
 Arguments:
   a: A list of lines (before)
   b: A list of lines (after)
   file_path: Path to the file
+  color_enabled: Display the diff in color
 """
 
 diff = difflib.unified_diff(a, b,
@@ -290,7 +291,12 @@ def show_diff(a, b, file_path):
 tofile=os.path.join('b', file_path))
 
 for line in diff:
-print line,
+if line[0] == '-' and line[1] != '-':
+print color_text(color_enabled, COLOR_RED, line),
+elif line[0] == '+' and line[1] != '+':
+print color_text(color_enabled, COLOR_GREEN, line),
+else:
+print line,
 
 def update_cross_compile(color_enabled):
 """Update per-arch CROSS_COMPILE via environment variables
@@ -388,14 +394,14 @@ def extend_matched_lines(lines, matched, pre_patterns, 
post_patterns, extend_pre
 matched += extended_matched
 matched.sort()
 
-def cleanup_one_header(header_path, patterns, dry_run):
+def cleanup_one_header(header_path, patterns, options):
 """Clean regex-matched lines away from a file.
 
 Arguments:
   header_path: path to the cleaned file.
   patterns: list of regex patterns.  Any lines matching to these
 patterns are deleted.
-  dry_run: make no changes, but still display log.
+  options: option flags.
 """
 with open(header_path) as f:
 lines = f.readlines()
@@ -436,21 +442,21 @@ def cleanup_one_header(header_path, patterns, dry_run):
 for i in reversed(matched):
 tolines.pop(i)
 
-show_diff(lines, tolines, header_path)
+show_diff(lines, tolines, header_path, options.color)
 
-if dry_run:
+if options.dry_run:
 return
 
 with open(header_path, 'w') as f:
 for line in tolines:
 f.write(line)
 
-def cleanup_headers(configs, dry_run):
+def cleanup_headers(configs, options):
 """Delete config defines from board headers.
 
 Arguments:
   configs: A list of CONFIGs to remove.
-  dry_run: make no changes, but still display log.
+  options: option flags.
 """
 while True:
 choice = raw_input('Clean up headers? [y/n]: ').lower()
@@ -473,7 +479,7 @@ def cleanup_headers(configs, dry_run):
 for filename in filenames:
 if not fnmatch.fnmatch(filename, '*~'):
 cleanup_one_header(os.path.join(dirpath, filename),
-   patterns, dry_run)
+   patterns, options)
 
 ### classes ###
 class Progress:
@@ -1145,7 +1151,7 @@ def main():
 move_config(configs, options)
 
 if configs:
-cleanup_headers(configs, options.dry_run)
+cleanup_headers(configs, options)
 
 if __name__ == '__main__':
 main()
-- 
1.9.1

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


[U-Boot] [PATCH v2 4/8] tools: moveconfig: show result of header cleaning in unified diff

2016-07-25 Thread Masahiro Yamada
The header cleanup feature of this tool now removes empty ifdef's,
successive blank lines as well as moved option defines.  So, we
want to see a little more context to check which lines were deleted.

It is true that we can see it by "git diff", but it would not work
in the --dry-run mode.  So, here, this commit.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Make diffing into a helper function

 tools/moveconfig.py | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 03e4953..4f07782 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -161,6 +161,7 @@ To see the complete list of supported options, run
 """
 
 import copy
+import difflib
 import filecmp
 import fnmatch
 import multiprocessing
@@ -275,6 +276,22 @@ def color_text(color_enabled, color, string):
 else:
 return string
 
+def show_diff(a, b, file_path):
+"""Show unidified diff.
+
+Arguments:
+  a: A list of lines (before)
+  b: A list of lines (after)
+  file_path: Path to the file
+"""
+
+diff = difflib.unified_diff(a, b,
+fromfile=os.path.join('a', file_path),
+tofile=os.path.join('b', file_path))
+
+for line in diff:
+print line,
+
 def update_cross_compile(color_enabled):
 """Update per-arch CROSS_COMPILE via environment variables
 
@@ -414,16 +431,19 @@ def cleanup_one_header(header_path, patterns, dry_run):
 if matched == old_matched:
 break
 
-for i in matched:
-print '%s: %s: %s' % (header_path, i + 1, lines[i]),
+tolines = copy.copy(lines)
+
+for i in reversed(matched):
+tolines.pop(i)
+
+show_diff(lines, tolines, header_path)
 
 if dry_run:
 return
 
 with open(header_path, 'w') as f:
-for i, line in enumerate(lines):
-if not i in matched:
-f.write(line)
+for line in tolines:
+f.write(line)
 
 def cleanup_headers(configs, dry_run):
 """Delete config defines from board headers.
-- 
1.9.1

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


[U-Boot] [PATCH v2 6/8] tools: moveconfig: fix cleanup of defines across multiple lines

2016-07-25 Thread Masahiro Yamada
Correct the clean-up of such defines that continue across multiple
lines, like follows:

  #define CONFIG_FOO "this continues to the next line " \
  "this line should be removed too" \
  "this line should be removed as well"

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 tools/moveconfig.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 4edcb6c..5b1fa92 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -408,6 +408,9 @@ def cleanup_one_header(header_path, patterns, options):
 
 matched = []
 for i, line in enumerate(lines):
+if i - 1 in matched and lines[i - 1][-2:] == '\\\n':
+matched.append(i)
+continue
 for pattern in patterns:
 if pattern.search(line):
 matched.append(i)
-- 
1.9.1

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


[U-Boot] [PATCH v2 7/8] tools: moveconfig: make getting all defconfigs into helper function

2016-07-25 Thread Masahiro Yamada
I want to reuse this routine in the next commit.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 tools/moveconfig.py | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 5b1fa92..3b7499b 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -266,6 +266,16 @@ def get_make_cmd():
 sys.exit('GNU Make not found')
 return ret[0].rstrip()
 
+def get_all_defconfigs():
+"""Get all the defconfig files under the configs/ directory."""
+defconfigs = []
+for (dirpath, dirnames, filenames) in os.walk('configs'):
+dirpath = dirpath[len('configs') + 1:]
+for filename in fnmatch.filter(filenames, '*_defconfig'):
+defconfigs.append(os.path.join(dirpath, filename))
+
+return defconfigs
+
 def color_text(color_enabled, color, string):
 """Return colored string."""
 if color_enabled:
@@ -1079,12 +1089,7 @@ def move_config(configs, options):
 sys.exit('%s - defconfig does not exist. Stopping.' %
  defconfigs[i])
 else:
-# All the defconfig files to be processed
-defconfigs = []
-for (dirpath, dirnames, filenames) in os.walk('configs'):
-dirpath = dirpath[len('configs') + 1:]
-for filename in fnmatch.filter(filenames, '*_defconfig'):
-defconfigs.append(os.path.join(dirpath, filename))
+defconfigs = get_all_defconfigs()
 
 progress = Progress(len(defconfigs))
 slots = Slots(configs, options, progress, reference_src_dir)
-- 
1.9.1

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


[U-Boot] [PATCH 0/4] dra7xx: QSPI: Increase SPI bus speed.

2016-07-25 Thread Vignesh R
By configuring DPLL_PER_HS13 divider value to provide 76.8MHz clock as
QSPI fclk on dra7xx, it is possible to operate SPI slave clock at
768.MHz which is the maximum supported frequency as per AM572x DM
SPRS953A. This helps to increase flash read speed by ~2MB/s.

Tested  on DRA74 Rev G & H, DRA72 Rev B & C EVMs.


Lokesh Vutla (1):
  ARM: dra7xx: Change DPLL_PER_HS13 divider value

Vignesh R (3):
  spi: ti_qspi: dra7xx: Add support to use 76.8MHz clock
  configs: dra7xx: Update QSPI speed to 76.8MHz
  ARM: dts: dra7xx: Update spi-max-frequency for QSPI

 arch/arm/cpu/armv7/omap5/hw_data.c |  2 +-
 arch/arm/dts/dra7-evm.dts  |  2 +-
 arch/arm/dts/dra72-evm.dts |  2 +-
 drivers/spi/ti_qspi.c  | 17 -
 include/configs/dra7xx_evm.h   |  2 +-
 5 files changed, 16 insertions(+), 9 deletions(-)

-- 
2.9.2

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


[U-Boot] [PATCH 2/4] spi: ti_qspi: dra7xx: Add support to use 76.8MHz clock

2016-07-25 Thread Vignesh R
According to AM572x DM SPRS953A, QSPI bus speed can be 76.8MHz, update
the driver to use the same.

Signed-off-by: Vignesh R 
---
 drivers/spi/ti_qspi.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/ti_qspi.c b/drivers/spi/ti_qspi.c
index fa7ee229878a..bb72cb03ec24 100644
--- a/drivers/spi/ti_qspi.c
+++ b/drivers/spi/ti_qspi.c
@@ -21,7 +21,8 @@ DECLARE_GLOBAL_DATA_PTR;
 
 /* ti qpsi register bit masks */
 #define QSPI_TIMEOUT200
-#define QSPI_FCLK   19200
+#define QSPI_FCLK  19200
+#define QSPI_DRA7XX_FCLK7680
 /* clock control */
 #define QSPI_CLK_EN BIT(31)
 #define QSPI_CLK_DIV_MAX0x
@@ -101,6 +102,7 @@ struct ti_qspi_priv {
 #endif
struct ti_qspi_regs *base;
void *ctrl_mod_mmap;
+   ulong fclk;
unsigned int mode;
u32 cmd;
u32 dc;
@@ -113,7 +115,7 @@ static void ti_spi_set_speed(struct ti_qspi_priv *priv, 
uint hz)
if (!hz)
clk_div = 0;
else
-   clk_div = (QSPI_FCLK / hz) - 1;
+   clk_div = (priv->fclk / hz) - 1;
 
debug("ti_spi_set_speed: hz: %d, clock divider %d\n", hz, clk_div);
 
@@ -366,8 +368,10 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
 #if defined(CONFIG_DRA7XX) || defined(CONFIG_AM57XX)
priv->ctrl_mod_mmap = (void *)CORE_CTRL_IO;
priv->slave.memory_map = (void *)MMAP_START_ADDR_DRA;
+   priv->fclk = QSPI_DRA7XX_FCLK;
 #else
priv->slave.memory_map = (void *)MMAP_START_ADDR_AM43x;
+   priv->fclk = QSPI_FCLK;
 #endif
 
ti_spi_set_speed(priv, max_hz);
@@ -520,7 +524,10 @@ static int ti_qspi_xfer(struct udevice *dev, unsigned int 
bitlen,
 
 static int ti_qspi_probe(struct udevice *bus)
 {
-   /* Nothing to do in probe */
+   struct ti_qspi_priv *priv = dev_get_priv(bus);
+
+   priv->fclk = dev_get_driver_data(bus);
+
return 0;
 }
 
@@ -572,8 +579,8 @@ static const struct dm_spi_ops ti_qspi_ops = {
 };
 
 static const struct udevice_id ti_qspi_ids[] = {
-   { .compatible = "ti,dra7xxx-qspi" },
-   { .compatible = "ti,am4372-qspi" },
+   { .compatible = "ti,dra7xxx-qspi",  .data = QSPI_DRA7XX_FCLK},
+   { .compatible = "ti,am4372-qspi",   .data = QSPI_FCLK},
{ }
 };
 
-- 
2.9.2

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


[U-Boot] [PATCH 1/4] ARM: dra7xx: Change DPLL_PER_HS13 divider value

2016-07-25 Thread Vignesh R
From: Lokesh Vutla 

According to AM572x DM SPRS953A, QSPI bus speed can be 76.8MHz, hence
update QSPI input clock divider value (DPLL_PER_HS13) to provide 76.8MHz
clock, so that driver can use the same.

Signed-off-by: Vignesh R 
---
 arch/arm/cpu/armv7/omap5/hw_data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c 
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 62dd275f7ee8..a83f68c366a0 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -160,7 +160,7 @@ static const struct dpll_params 
per_dpll_params_768mhz_es2[NUM_SYS_CLKS] = {
 
 static const struct dpll_params per_dpll_params_768mhz_dra7xx[NUM_SYS_CLKS] = {
{32, 0, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 12 MHz   */
-   {96, 4, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 20 MHz   */
+   {96, 4, 4, 1, 3, 4, 10, 2, -1, -1, -1, -1}, /* 20 MHz   */
{160, 6, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1}, /* 16.8 MHz */
{20, 0, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},  /* 19.2 MHz */
{192, 12, 4, 1, 3, 4, 4, 2, -1, -1, -1, -1},/* 26 MHz   */
-- 
2.9.2

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


[U-Boot] [PATCH 3/4] configs: dra7xx: Update QSPI speed to 76.8MHz

2016-07-25 Thread Vignesh R
Now that QSPI driver can support 76.8MHz, update the
CONFIG_SF_DEFAULT_SPEED to the same value.

Signed-off-by: Vignesh R 
---
 include/configs/dra7xx_evm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 0d51aeb86909..0b78ada4143c 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -157,7 +157,7 @@
 /* SPI */
 #undef CONFIG_OMAP3_SPI
 #define CONFIG_TI_SPI_MMAP
-#define CONFIG_SF_DEFAULT_SPEED6400
+#define CONFIG_SF_DEFAULT_SPEED7680
 #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0
 #define CONFIG_QSPI_QUAD_SUPPORT
 
-- 
2.9.2

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


Re: [U-Boot] [RFC PATCH v2 0/5] SPL: DFU Support in SPL

2016-07-25 Thread Lukasz Majewski
Hi Ravi,

> Traditionally the DFU support is available only
> as part 2nd stage boot loader(u-boot) and DFU
> is not supported in SPL.
> 
> The SPL-DFU feature is useful for boards which
> does not have MMC/SD, ethernet boot mechanism
> to boot the board and only has USB inteface.
> 
> This patch add DFU support in SPL with RAM
> memory device support to load and execute u-boot 
> from PC over USB interface. And then leverage
> full functional feature of DFU in u-boot to
> flash boot inital binary images to factory or
> bare-metal boards to memory devices like SPI,
> eMMC, MMC/SD card using USB interface.
> 
> As a reference, refer to application note [3]
> on SPL-DFU support based on 2014.07 u-boot.
> 
> Steps to build SPL-DFU/RAM:
> This SPL-DFU support can be enabled through
> Menuconfig->Boot Images->Enable SPL-DFU support
> 1) Soc ROMcode loads the u-boot-spl.bin(+DFU) to IRAM 
> from PC host via usb interface and execute DFU.
> 2) Then load u-boot.img to RAM using dfu-util from PC-host
> with -R switch to boot u-boot.
> #sudo dfu-util -c 1 -i 0 -a 0 -D u-boot.img -R
> 


I wanted to add this patch series for testing. Unfortunately, I cannot
apply this code to the newest u-boot-usb/master (SHA1:
eb364c3dc28d59d33e823470d07746b22a8e6fee)

Please rebase your code on top of this branch.

Thanks in advance,

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 5/5] cgtqmx6eval: Remove uneeded PHYS_SDRAM_SIZE

2016-07-25 Thread Otavio Salvador
On Sat, Jul 23, 2016 at 1:23 PM, Fabio Estevam  wrote:
> From: Fabio Estevam 
>
> cgtqmx6eval uses the imx_ddr_size() function to calculate the DDR size in
> runtime, so there is no need to define PHYS_SDRAM_SIZE.
>
> Remove the unneeded definition.
>
> Cc: Otavio Salvador 
> Signed-off-by: Fabio Estevam 

Acked-by: Otavio Salvador 



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


[U-Boot] [PATCH 4/4] ARM: dts: dra7xx: Update spi-max-frequency for QSPI

2016-07-25 Thread Vignesh R
According to AM572x DM SPRS953A, QSPI max bus speed is 76.8MHz.
Therefore update the spi-max-frequency value of QSPI node for DRA74 and
DRA72 evm. This increase flash read speed by ~2MB/s.

Signed-off-by: Vignesh R 
---
 arch/arm/dts/dra7-evm.dts  | 2 +-
 arch/arm/dts/dra72-evm.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/dra7-evm.dts b/arch/arm/dts/dra7-evm.dts
index 429b9edc1b2b..8b77a761d211 100644
--- a/arch/arm/dts/dra7-evm.dts
+++ b/arch/arm/dts/dra7-evm.dts
@@ -491,7 +491,7 @@
pinctrl-names = "default";
pinctrl-0 = <&qspi1_pins>;
 
-   spi-max-frequency = <6400>;
+   spi-max-frequency = <7680>;
m25p80@0 {
compatible = "s25fl256s1","spi-flash";
spi-max-frequency = <6400>;
diff --git a/arch/arm/dts/dra72-evm.dts b/arch/arm/dts/dra72-evm.dts
index ced2f1166d8c..c7c5d40adac7 100644
--- a/arch/arm/dts/dra72-evm.dts
+++ b/arch/arm/dts/dra72-evm.dts
@@ -603,7 +603,7 @@
pinctrl-names = "default";
pinctrl-0 = <&qspi1_pins>;
 
-   spi-max-frequency = <6400>;
+   spi-max-frequency = <7680>;
m25p80@0 {
compatible = "s25fl256s1","spi-flash";
spi-max-frequency = <6400>;
-- 
2.9.2

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


Re: [U-Boot] [PATCH 1/4] tools: moveconfig: trim garbage lines after header cleanups

2016-07-25 Thread Masahiro Yamada
Hi Tom,


2016-07-25 0:19 GMT+09:00 Tom Rini :
> On Sun, Jul 24, 2016 at 11:17:36PM +0900, Masahiro Yamada wrote:
>
>> The tools/moveconfig.py has a feature to cleanup #define/#undef's
>> of moved config options, but I want this tool to do a better job.
>>
>> For example, when we are moving CONFIG_FOO and its define is
>> surrounded by #ifdef ... #endif, like follows:
>>
>>   #ifdef CONFIG_BAR
>>   #  define CONFIG_FOO
>>   #endif
>>
>> The header cleanup will leave empty #ifdef ... #endif:
>>
>>   #ifdef CONFIG_BAR
>>   #endif
>>
>> Likewise, if a define line between two blank lines
>>
>>   
>>   #define CONFIG_FOO
>>   >
>> ... is deleted, the result of the clean-up will be successive empty
>> lines, which is a coding-style violation.
>
> Thanks!  This is mildly annoying to find/fixup with regex, which is how
> I usually do it.  A few comments / questions:
>
> [snip]
>> +# remove empty #ifdef ... #endif, successive blank lines
>> +pattern_ifdef = re.compile(r'#\s*if(def|ndef)?\s')
>
> It starts to get complex to catch if defined/elif defined cases, so
> we should just leave that to manual review, yes?

It was missing from my thought.

It is difficult to invert the logic, like changing ifdef to ifndef,
but just removing can be done easily.

In v2,

"tools/moveconfig -H -c FOO" can clean more!


ex1)

   #if CONFIG_BAR
 /* ... */
  -#elif CONFIG_BAZ
  -# define CONFIG_FOO
   #endif


ex2)
   #if CONFIG_BAR
 /* ... */
  -#elif CONFIG_BAZ
  -# define CONFIG_FOO
   #elif CONFIG_BAZ2
 /* ... */
   #endif





>> +pattern_endif = re.compile(r'#\s*endif\s')
>> +pattern_blank = re.compile(r'^\s*$')
>
> The last pattern will catch multiple blank lines, right?

Yes.


-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] mmc: sdhci: set to INT_DATA_END when there are data

2016-07-25 Thread Lukasz Majewski
Hi Jaehoon,

> Hi All,
> 
> On 07/12/2016 09:55 PM, Lukasz Majewski wrote:
> > Hi Jaehoon,
> > 
> >> There is no data, it doesn't needs to wait for completing data
> >> transfer. (It seems that it can be removed.)
> >> Almost all timeout error is occured from stop command without data.
> >> After applied this patch, I hope that we don't need to increase
> >> timeout value anymore.
> > 
> > This patch fixes issue (in a better way) for Odroid U3 write
> > performance (http://patchwork.ozlabs.org/patch/646932/) and hence
> > should be used.
> > 
> 
> Is there any other opinion for this patch?
> Who is maintaining u-boot-mmc? Is Pantelis still maintaining
> u-boot-mmc?
> 
> Who can apply this patch and patch relevant to mmc?

To be honest, I do look forward to see this patch included to u-boot
master branch.

Addition of some extra Odroid U3 tests hinge on it.

> 
> Best Regards,
> Jaehoon Chung
> 
> > 
> >>
> >> Signed-off-by: Jaehoon Chung 
> >> ---
> >>  drivers/mmc/sdhci.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> >> index 604f18d..0a38a56 100644
> >> --- a/drivers/mmc/sdhci.c
> >> +++ b/drivers/mmc/sdhci.c
> >> @@ -175,7 +175,8 @@ static int sdhci_send_command(struct mmc *mmc,
> >> struct mmc_cmd *cmd, flags = SDHCI_CMD_RESP_LONG;
> >>else if (cmd->resp_type & MMC_RSP_BUSY) {
> >>flags = SDHCI_CMD_RESP_SHORT_BUSY;
> >> -  mask |= SDHCI_INT_DATA_END;
> >> +  if (data)
> >> +  mask |= SDHCI_INT_DATA_END;
> >>} else
> >>flags = SDHCI_CMD_RESP_SHORT;
> >>  
> > 
> > Acked-by: Lukasz Majewski 
> > Tested-by: Lukasz Majewski 
> > 
> > Test HW: Odroid U3 (Exynos4):
> > 
> > Odroid # ext4load mmc 0:2 0x4100 dat_31M.img
> > 32505856 bytes read in 1471 ms (21.1 MiB/s)
> > Odroid # ext4write mmc 0:2 0x4100 /dat_w55.img 0x1f0
> > File System is consistent
> > update journal finished
> > 32505856 bytes written in 3528 ms (8.8 MiB/s)
> > 
> > Performance improvement is even better than with previously proposed
> > patches.
> > 
> > Test HW: Odroid XU3 (Exynos5):
> > 
> > ODROID-XU3 # ext4load mmc 0:2 0x4100 dat_31M.img
> > 32505856 bytes read in 6309 ms (4.9 MiB/s)
> > ODROID-XU3 # ext4write mmc 0:2 0x4100 /dat_w1.img 0x1f0
> > File System is consistent
> > update journal finished
> > 32505856 bytes written in 4884 ms (6.3 MiB/s)
> > 
> > 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] suggested/stealable setups for robustness with switchable partitions?

2016-07-25 Thread Robert P. J. Day
On Fri, 22 Jul 2016, Wolfgang Denk wrote:

> Dear Robert,
>
> In message  you 
> wrote:
> >
> >   followup to my earlier post, i'll keep this short as i want to
> > do some research first, but i'm looking for setups where target
> > boards have dual partitions that switch between active and
> > inactive for reliability.
>
> Switching partitions is usually not some isolated feature, but part
> of a software update and reliable fall back configuration.  In
> U-Boot, it is usually found in combination with the boot counter
> feature; in Linux, it usually requires support of a (hardware)
> watchdog.
>
> Once you reached that point, you probably want to look at the
> swupdate [1] project and read it's documentation...
>
> [1] http://git.denx.de/?p=swupdate.git;a=summary

  ironically, i was already digging into swupdate when you mentioned
it, since i saw it was one of stefano's projects so i assumed it would
play nicely with u-boot.

rday

p.s. i also noticed a few boards in u-boot that explicitly work with
"partition sets":

$ grep -r partitionset *
board/siemens/taurus/taurus.c:  char *partitionset_active = NULL;
board/siemens/taurus/taurus.c:  partitionset_active = 
getenv("partitionset_active");
board/siemens/taurus/taurus.c:  if (partitionset_active) {
board/siemens/taurus/taurus.c:  if (partitionset_active[0] == 'A')
board/siemens/taurus/taurus.c:  setenv("partitionset_active", 
"B");
board/siemens/taurus/taurus.c:  setenv("partitionset_active", 
"A");
board/siemens/taurus/taurus.c:  printf("partitionset_active 
missing.\n");
include/configs/etamin.h:   "setenv ${partitionset_active} true;" \
include/configs/siemens-am33x-common.h: "setenv 
${partitionset_active} true;" \
include/configs/siemens-am33x-common.h: "setenv 
partitionset_active B; " \
include/configs/siemens-am33x-common.h: "setenv 
partitionset_active A; " \
include/configs/siemens-am33x-common.h: "echo set 
${partitionset_active}...;" \
include/configs/siemens-am33x-common.h: "partitionset_active=A\0" \
include/configs/siemens-am33x-common.h: "echo Set partitionset_active 
variable to 'A' " \
include/configs/siemens-am33x-common.h: "setenv ${partitionset_active} 
true;" \
include/configs/siemens-am33x-common.h: "setenv ${partitionset_active} 
true;" \
include/configs/taurus.h:   "partitionset_active=A\0"
$

so i'm trying to collect all of this and write it up in one (public)
place, so i can use it for an upcoming embedded linux class.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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


Re: [U-Boot] suggested/stealable setups for robustness with switchable partitions?

2016-07-25 Thread Stefano Babic
Hi Robert,

On 25/07/2016 12:42, Robert P. J. Day wrote:
> On Fri, 22 Jul 2016, Wolfgang Denk wrote:
> 
>> Dear Robert,
>>
>> In message  you 
>> wrote:
>>>
>>>   followup to my earlier post, i'll keep this short as i want to
>>> do some research first, but i'm looking for setups where target
>>> boards have dual partitions that switch between active and
>>> inactive for reliability.
>>
>> Switching partitions is usually not some isolated feature, but part
>> of a software update and reliable fall back configuration.  In
>> U-Boot, it is usually found in combination with the boot counter
>> feature; in Linux, it usually requires support of a (hardware)
>> watchdog.
>>
>> Once you reached that point, you probably want to look at the
>> swupdate [1] project and read it's documentation...
>>
>> [1] http://git.denx.de/?p=swupdate.git;a=summary
> 
>   ironically, i was already digging into swupdate when you mentioned
> it, since i saw it was one of stefano's projects so i assumed it would
> play nicely with u-boot.
> 

Yes, of course :-)

> rday
> 
> p.s. i also noticed a few boards in u-boot that explicitly work with
> "partition sets":

Do not let be confused by digging the environment into U-Boot. There are
much more boards as you can discover. In fact, you can see the "default"
environment, but on many boards the right environment is loaded in
factory as part of device tests. The default environment, linked with
u-boot, is not so important for many products.

It is also possible that what you are seeing here is not used at all
later, and replaced with some other scripts.

Best regards,
Stefano Babic

> 
> $ grep -r partitionset *
> board/siemens/taurus/taurus.c:char *partitionset_active = NULL;
> board/siemens/taurus/taurus.c:partitionset_active = 
> getenv("partitionset_active");
> board/siemens/taurus/taurus.c:if (partitionset_active) {
> board/siemens/taurus/taurus.c:if (partitionset_active[0] == 
> 'A')
> board/siemens/taurus/taurus.c:
> setenv("partitionset_active", "B");
> board/siemens/taurus/taurus.c:
> setenv("partitionset_active", "A");
> board/siemens/taurus/taurus.c:printf("partitionset_active 
> missing.\n");
> include/configs/etamin.h: "setenv ${partitionset_active} true;" \
> include/configs/siemens-am33x-common.h:   "setenv 
> ${partitionset_active} true;" \
> include/configs/siemens-am33x-common.h:   
> "setenv partitionset_active B; " \
> include/configs/siemens-am33x-common.h:   
> "setenv partitionset_active A; " \
> include/configs/siemens-am33x-common.h:   "echo set 
> ${partitionset_active}...;" \
> include/configs/siemens-am33x-common.h:   "partitionset_active=A\0" \
> include/configs/siemens-am33x-common.h:   "echo Set 
> partitionset_active variable to 'A' " \
> include/configs/siemens-am33x-common.h:   "setenv 
> ${partitionset_active} true;" \
> include/configs/siemens-am33x-common.h:   "setenv 
> ${partitionset_active} true;" \
> include/configs/taurus.h: "partitionset_active=A\0"
> $
> 
> so i'm trying to collect all of this and write it up in one (public)
> place, so i can use it for an upcoming embedded linux class.
> 


-- 
=
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
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [RFC PATCH] i2c: i2c-uclass-compat: avoid any BSS usage

2016-07-25 Thread Vignesh R
As I2C can be used before DRAM initialization for reading EEPROM,
avoid using static variables stored in BSS, since BSS is in DRAM, which
may not have been initialised yet. Explicitly mark "static global"
variables as belonging to the .data section.

Signed-off-by: Vignesh R 
---
 drivers/i2c/i2c-uclass-compat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/i2c-uclass-compat.c b/drivers/i2c/i2c-uclass-compat.c
index 5606d1f807f6..de78db6a887f 100644
--- a/drivers/i2c/i2c-uclass-compat.c
+++ b/drivers/i2c/i2c-uclass-compat.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 
-static int cur_busnum;
+static int cur_busnum __attribute__((section(".data")));
 
 static int i2c_compat_get_device(uint chip_addr, int alen,
 struct udevice **devp)
-- 
2.9.2

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


Re: [U-Boot] [PATCH] tree-wide: move CONFIG_PHYS_64BIT to Kconfig

2016-07-25 Thread Masahiro Yamada
Hi Tom,


2016-07-25 1:55 GMT+09:00 Tom Rini :
> On Sun, Jul 24, 2016 at 10:12:50PM +0900, Masahiro Yamada wrote:
>
>> I tried my best to use "select" where possible (for example, ARMv8
>> architecture) because I think this kind of option is generally user-
>> unconfigurable.  However, I see some of PowerPC boards have 36BIT
>> defconfigs as well as 32BIT ones.  I moved CONFIG_PHYS_64BIT to the
>> defconfigs for such boards.
>>
>> Signed-off-by: Masahiro Yamada 
>
> Thanks for doing this, I'm sure it's going to fix a few other "hidden"
> bugs, aside from the USB one that we've already found.  Can you please
> add in, roughtly:
>
> We need to ensure that CONFIG_PHYS_64BIT is configured via Kconfig so
> that it is always available to the build system.  Otherwise we can run
> into cases where we have inconsistent sizes of certain attributes.
> Fixes: 95ebc25 (types.h: move and redefine resource_size_t)
> Reported-by:  Ravi Babu 


I did so in v2.

> Also:
>
>> diff --git a/Kconfig b/Kconfig
>> index ef12f9f..d7eda49 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -124,6 +124,12 @@ config TOOLS_DEBUG
>> debug through the source code, etc.
>>
>>  endif
>> +
>> +config PHYS_64BIT
>> +   bool "64bit physical address support"
>> +   help
>> + Say Y here to support 64bit physical memory address.
>
> Aside from the case of a 64bit CPU this is also needed on 32bit systems
> that offer a larger than 32bit address space.

Right.  Like ARM LPAE.

I noted this in the Kconfig help.




>> diff --git a/configs/MPC8536DS_36BIT_defconfig 
>> b/configs/MPC8536DS_36BIT_defconfig
>> index 2ffc647..02cd9c7 100644
>> --- a/configs/MPC8536DS_36BIT_defconfig
>> +++ b/configs/MPC8536DS_36BIT_defconfig
>> @@ -1,6 +1,7 @@
>>  CONFIG_PPC=y
>>  CONFIG_MPC85xx=y
>>  CONFIG_TARGET_MPC8536DS=y
>> +CONFIG_PHYS_64BIT=y
>>  CONFIG_OF_BOARD_SETUP=y
>>  CONFIG_OF_STDOUT_VIA_ALIAS=y
>>  CONFIG_SYS_EXTRA_OPTIONS="36BIT"
>
> Then on these 32bit CPU + 36bit address space boards we can now remove
> 36BIT from CONFIG_SYS_EXTRA_OPTIONS as this is all that's triggered by
> CONFIG_36BIT now.  Thanks!


Good catch.

I do not like fiddling with sed again and again,
I wrote this patch:
http://patchwork.ozlabs.org/patch/652215/

I hope you will like it.



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] suggested/stealable setups for robustness with switchable partitions?

2016-07-25 Thread Robert P. J. Day
On Mon, 25 Jul 2016, Stefano Babic wrote:

> Hi Robert,
>
> On 25/07/2016 12:42, Robert P. J. Day wrote:

> > p.s. i also noticed a few boards in u-boot that explicitly work with
> > "partition sets":
>
> Do not let be confused by digging the environment into U-Boot. There are
> much more boards as you can discover. In fact, you can see the "default"
> environment, but on many boards the right environment is loaded in
> factory as part of device tests. The default environment, linked with
> u-boot, is not so important for many products.
>
> It is also possible that what you are seeing here is not used at all
> later, and replaced with some other scripts.
>
> Best regards,
> Stefano Babic
>
> >
> > $ grep -r partitionset *
> > board/siemens/taurus/taurus.c:  char *partitionset_active = NULL;
> > board/siemens/taurus/taurus.c:  partitionset_active = 
> > getenv("partitionset_active");
> > board/siemens/taurus/taurus.c:  if (partitionset_active) {
> > board/siemens/taurus/taurus.c:  if (partitionset_active[0] == 
> > 'A')
> > board/siemens/taurus/taurus.c:  
> > setenv("partitionset_active", "B");
> > board/siemens/taurus/taurus.c:  
> > setenv("partitionset_active", "A");
> > board/siemens/taurus/taurus.c:  printf("partitionset_active 
> > missing.\n");
> > include/configs/etamin.h:   "setenv ${partitionset_active} true;" \
> > include/configs/siemens-am33x-common.h: "setenv 
> > ${partitionset_active} true;" \
> > include/configs/siemens-am33x-common.h: 
> > "setenv partitionset_active B; " \
> > include/configs/siemens-am33x-common.h: 
> > "setenv partitionset_active A; " \
> > include/configs/siemens-am33x-common.h: "echo set 
> > ${partitionset_active}...;" \
> > include/configs/siemens-am33x-common.h: "partitionset_active=A\0" \
> > include/configs/siemens-am33x-common.h: "echo Set 
> > partitionset_active variable to 'A' " \
> > include/configs/siemens-am33x-common.h: "setenv 
> > ${partitionset_active} true;" \
> > include/configs/siemens-am33x-common.h: "setenv 
> > ${partitionset_active} true;" \
> > include/configs/taurus.h:   "partitionset_active=A\0"
> > $

  oh, i understand that, i was just noting another component that can
come into play if someone *wants* to do it as is being done above,
unless it's overridden at the factory.

  a couple more bootlimit/autoboot questions coming later as i try to
pull all this together and finish writing it up, so others don't have
to do as much reading as me. :-)

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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


[U-Boot] [PATCH v2] treewide: move CONFIG_PHYS_64BIT to Kconfig

2016-07-25 Thread Masahiro Yamada
We need to ensure that CONFIG_PHYS_64BIT is configured via Kconfig so
that it is always available to the build system.  Otherwise we can run
into cases where we have inconsistent sizes of certain attributes.

Ravi Babu reported offset mismatch of struct dwc3 across files since
commit 95ebc253e6d4 ("types.h: move and redefine resource_size_t").
Since the commit, resource_addr_t points to phys_addr_t, whose size
is dependent on CONFIG_PHYS_64BIT for ARM architecture.

I tried my best to use "select" where possible (for example, ARMv8
architecture) because I think this kind of option is generally user-
unconfigurable.  However, I see some of PowerPC boards have 36BIT
defconfigs as well as 32BIT ones.  I moved CONFIG_PHYS_64BIT to the
defconfigs for such boards.

CONFIG_36BIT is no longer referenced, so all of the defines were
removed from CONFIG_SYS_EXTRA_OPTIONS.

Fixes: 95ebc253e6d4 ("types.h: move and redefine resource_size_t")
Signed-off-by: Masahiro Yamada 
Reported-by: Ravi Babu 
Acked-by: Stefan Roese 
---

Changes in v2:
  - Clean 36BIT, PHYS_64BIT from CONFIG_SYS_EXTRA_OPTIONS
(generated by  http://patchwork.ozlabs.org/patch/652215/)

 Kconfig   |  8 
 arch/arm/Kconfig  |  1 +
 arch/arm/cpu/armv7/omap5/Kconfig  |  1 +
 arch/arm/include/asm/config.h |  1 -
 arch/powerpc/cpu/mpc85xx/Kconfig  | 18 ++
 arch/powerpc/cpu/ppc4xx/Kconfig   |  1 +
 configs/C29XPCIE_NAND_defconfig   |  2 +-
 configs/C29XPCIE_NOR_SECBOOT_defconfig|  2 +-
 configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig   |  2 +-
 configs/C29XPCIE_SPIFLASH_defconfig   |  2 +-
 configs/C29XPCIE_defconfig|  2 +-
 configs/MPC8536DS_36BIT_defconfig |  2 +-
 configs/MPC8548CDS_36BIT_defconfig|  2 +-
 configs/MPC8572DS_36BIT_defconfig |  2 +-
 configs/MPC8641HPCN_36BIT_defconfig   |  2 +-
 configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig  |  5 +++--
 configs/P1010RDB-PA_36BIT_NAND_defconfig  |  3 ++-
 configs/P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig   |  5 +++--
 configs/P1010RDB-PA_36BIT_NOR_defconfig   |  3 ++-
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig|  3 ++-
 configs/P1010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig  |  5 +++--
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig  |  3 ++-
 configs/P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig  |  5 +++--
 configs/P1010RDB-PB_36BIT_NAND_defconfig  |  3 ++-
 configs/P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig   |  5 +++--
 configs/P1010RDB-PB_36BIT_NOR_defconfig   |  3 ++-
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig|  3 ++-
 configs/P1010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig  |  5 +++--
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig  |  3 ++-
 configs/P1020MBG-PC_36BIT_SDCARD_defconfig|  3 ++-
 configs/P1020MBG-PC_36BIT_defconfig   |  3 ++-
 configs/P1020RDB-PC_36BIT_NAND_defconfig  |  3 ++-
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig|  3 ++-
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig  |  3 ++-
 configs/P1020RDB-PC_36BIT_defconfig   |  3 ++-
 configs/P1020UTM-PC_36BIT_SDCARD_defconfig|  3 ++-
 configs/P1020UTM-PC_36BIT_defconfig   |  3 ++-
 configs/P1021RDB-PC_36BIT_NAND_defconfig  |  3 ++-
 configs/P1021RDB-PC_36BIT_SDCARD_defconfig|  3 ++-
 configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig  |  3 ++-
 configs/P1021RDB-PC_36BIT_defconfig   |  3 ++-
 configs/P1022DS_36BIT_NAND_defconfig  |  3 ++-
 configs/P1022DS_36BIT_SDCARD_defconfig|  3 ++-
 configs/P1022DS_36BIT_SPIFLASH_defconfig  |  3 ++-
 configs/P1022DS_36BIT_defconfig   |  2 +-
 configs/P1024RDB_36BIT_defconfig  |  3 ++-
 configs/P1025RDB_36BIT_defconfig  |  3 ++-
 configs/P2020RDB-PC_36BIT_NAND_defconfig  |  3 ++-
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig|  3 ++-
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig  |  3 ++-
 configs/P2020RDB-PC_36BIT_defconfig   |  3 ++-
 configs/controlcenterd_36BIT_SDCARD_DEVELOP_defconfig |  3 ++-
 configs/controlcenterd_36BIT_SDCARD_defconfig |  3 ++-
 include/configs/B4860QDS.h|  1 -
 include/configs/C29XPCIE.h|  1 -
 include/configs/MPC8536DS.h   |  4 
 include/configs/MPC8548CDS.h  |  4 
 include/configs/MPC8572DS.h   |  4 
 include/configs/MPC8641HPCN.h |  1 -
 include/configs/P1010RDB.h  

Re: [U-Boot] [PATCH v7] mmc: atmel_sdhci: Convert to the driver model support

2016-07-25 Thread Wenyou.Yang
Hi Jaehoon,

> -Original Message-
> From: Jaehoon Chung [mailto:jh80.ch...@samsung.com]
> Sent: 2016年7月21日 12:17
> To: Wenyou Yang ; U-Boot Mailing List  b...@lists.denx.de>
> Cc: Pantelis Antoniou ; Andreas Bießmann
> ; Simon Glass 
> Subject: Re: [PATCH v7] mmc: atmel_sdhci: Convert to the driver model support
> 
> Hi Wenyuo,
> 
> On 07/20/2016 07:04 PM, Wenyou Yang wrote:
> > Convert the driver to the driver model while retaining the existing
> > legacy code. This allows the driver to support boards that have
> > converted to driver model as well as those that have not.
> >
> > Signed-off-by: Wenyou Yang 
> > Reviewed-by: Simon Glass 
> > ---
> >
> > Changes in v7:
> >  - Add support for using driver model for block devices and MMC operations.
> >  - Change clk_client.h -> clk.h to adapt to clk API conversion.
> >
> > Changes in v6:
> >  - Remove unnecessary white space.
> >  - Use sdhci_read(), instead of readl().
> >  - Remove the local variables min_clk.
> >
> > Changes in v5:
> >  - Add Reviewed-by tag.
> >
> > Changes in v4:
> >  - Update the clk API based on [PATCH] clk: convert API to match
> >reset/mailbox fstyle (http://patchwork.ozlabs.org/patch/625342/).
> >  - Remove check on dev_get_parent() return.
> >  - Fixed the return value, such as -ENODEV->-EINVAL.
> >
> > Changes in v3:
> >  - Remove the redundant log print.
> >
> > Changes in v2:
> >  - Add clock support, include enabling peripheral clock and
> >generated clock.
> >  - Retain the existing legacy code to support boards which have not
> >converted to driver model.
> >
> >  drivers/mmc/Kconfig   |  10 
> >  drivers/mmc/atmel_sdhci.c | 125
> ++
> >  include/sdhci.h   |   2 +
> >  3 files changed, 137 insertions(+)
> >
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
> > 79cf18f..49b325e 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -34,6 +34,16 @@ config MSM_SDHCI
> >SD 3.0 specifications. Both SD and eMMC devices are supported.
> >   Card-detect gpios are not supported.
> >
> > +config ATMEL_SDHCI
> > +   bool "Atmel SDHCI controller support"
> > +   depends on DM_MMC && BLK && DM_MMC_OPS && ARCH_AT91
> > +   help
> > + This enables support for the Atmel SDHCI controller, which supports
> > + the embedded MultiMedia Card (e.MMC) Specification V4.51, the SD
> > + Memory Card Specification V3.0, and the SDIO V3.0 specification.
> > + It is compliant with the SD Host Controller Standard V3.0
> > + specification.
> > +
> >  config ROCKCHIP_DWMMC
> > bool "Rockchip SD/MMC controller support"
> > depends on DM_MMC && OF_CONTROL
> > diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
> > index 24b68b6..977f6ef 100644
> > --- a/drivers/mmc/atmel_sdhci.c
> > +++ b/drivers/mmc/atmel_sdhci.c
> > @@ -6,12 +6,15 @@
> >   */
> >
> >  #include 
> > +#include 
> > +#include 
> 
> If it doesn't use DM_MMC, then doesn't it need to include dm.h?
> 
> >  #include 
> >  #include 
> >  #include 
> >
> >  #define ATMEL_SDHC_MIN_FREQ40
> >
> > +#ifndef CONFIG_DM_MMC
> >  int atmel_sdhci_init(void *regbase, u32 id)  {
> > struct sdhci_host *host;
> > @@ -38,3 +41,125 @@ int atmel_sdhci_init(void *regbase, u32 id)
> >
> > return 0;
> >  }
> > +
> > +#else
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +struct atmel_sdhci_plat {
> > +   struct mmc_config cfg;
> > +   struct mmc mmc;
> > +};
> > +
> > +static int atmel_sdhci_probe(struct udevice *dev) {
> > +   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> > +   struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
> > +   struct sdhci_host *host = dev_get_priv(dev);
> > +   u32 max_clk;
> > +   u32 caps, caps_1;
> > +   u32 clk_base, clk_mul;
> > +   u32 gck_rate;
> > +   struct udevice *dev_clk;
> > +   struct clk clk;
> > +   int periph, ret;
> > +
> > +   ret = clk_get_by_index(dev, 0, &clk);
> > +   if (ret)
> > +   return ret;
> > +
> > +   periph = fdtdec_get_uint(gd->fdt_blob, clk.dev->of_offset, "reg", -1);
> > +   if (periph < 0)
> > +   return -EINVAL;
> 
> periph is just used to pass to clk.id. it looks meaningless.
> As i already mentioned, you can make more cleaner than now.

There is a litter difference from usual clock structure for Atmel clock driver.

The periph value is got from a child node, then is assigned to its parent clock 
node. 

> 
> > +
> > +   dev_clk = dev_get_parent(clk.dev);
> > +   ret = clk_request(dev_clk, &clk);
> > +   if (ret)
> > +   return ret;
> > +
> > +   clk.id = periph;
> > +   ret = clk_enable(&clk);
> > +   if (ret)
> > +   return ret;
> > +
> > +   host->name = (char *)dev->name;
> 
> Needs the type casting?

Accepted.

> 
> > +   host->ioaddr = (void *)dev_get_addr(dev);
> > +
> > +   host->quirks = 0;
> > +   host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
> > +
> > +   host->bus_width = fdtdec_get_int(gd->fdt_

Re: [U-Boot] [PATCH] i2c: intel_i2c: SMBus driver PCI addition (e.g. BayTrail)

2016-07-25 Thread Stefan Roese

Hi Simon,

On 25.07.2016 04:07, Simon Glass wrote:

On 28 June 2016 at 07:44, Stefan Roese  wrote:

This patch adds support for the SMBus block read/write functionality.
Other protocols like the SMBus quick command need to get added
if this is needed.

This patch also removed the SMBus related defines from the Ivybridge
pch.h header. As they are integrated in this driver and should be
used from here. This change is added in this patch to avoid compile
breakage to keep the source git bisectable.

Tested on a congatec BayTrail board to configure the SMSC2513 USB
hub.

Signed-off-by: Stefan Roese 
Cc: Bin Meng 
Cc: Simon Glass 
Cc: Heiko Schocher 
---
Simon, I'm not sure if this change breaks your Ivybridge targets
using the probe part of this driver. Could you please let me
know if this works? Or let me know what needs changes here?


Yes this breaks booting on link. Something odd is going on because the
call to set up I2C in ivybridge's print_cpuinfo() returns a very
strange error -726376.

But I then enabled CONFIG_CMD_I2C and it boots. However 'i2c probe'
produces a lot of errors like this:

ERROR: len=0 on read
smbus_block_read (107): dev=0x3b offs=0x0 len=0x1
smbus_block_read (136): count=0 (len=1)


Thanks for checking. I'll try to find some time this week to look into
this.

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


Re: [U-Boot] [PATCH v2] ARM: socfpga: use the default CONFIG_BOOTDELAY=2

2016-07-25 Thread Marek Vasut
On 07/24/2016 06:38 PM, Masahiro Yamada wrote:
> This option controls how long it should be paused before entering
> the auto-boot mode.  The default value from Kconfig should be fine
> except socfpga_vining_fpga_defconfig.
> 
> Signed-off-by: Masahiro Yamada 

Applied, thanks

> ---
> 
> Changes in v2:
>   - Keep socfpga_vining_fpga_defconfig untouched
> 
>  configs/socfpga_arria5_defconfig   | 1 -
>  configs/socfpga_cyclone5_defconfig | 1 -
>  configs/socfpga_de0_nano_soc_defconfig | 1 -
>  configs/socfpga_is1_defconfig  | 1 -
>  configs/socfpga_mcvevk_defconfig   | 1 -
>  configs/socfpga_sockit_defconfig   | 1 -
>  configs/socfpga_socrates_defconfig | 1 -
>  configs/socfpga_sr1500_defconfig   | 1 -
>  8 files changed, 8 deletions(-)
> 
> diff --git a/configs/socfpga_arria5_defconfig 
> b/configs/socfpga_arria5_defconfig
> index 2478ae5..1bec969 100644
> --- a/configs/socfpga_arria5_defconfig
> +++ b/configs/socfpga_arria5_defconfig
> @@ -10,7 +10,6 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria5_socdk"
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_FIT=y
> -CONFIG_BOOTDELAY=3
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
> diff --git a/configs/socfpga_cyclone5_defconfig 
> b/configs/socfpga_cyclone5_defconfig
> index 1619b86..0437cbe 100644
> --- a/configs/socfpga_cyclone5_defconfig
> +++ b/configs/socfpga_cyclone5_defconfig
> @@ -10,7 +10,6 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_socdk"
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_FIT=y
> -CONFIG_BOOTDELAY=3
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
> diff --git a/configs/socfpga_de0_nano_soc_defconfig 
> b/configs/socfpga_de0_nano_soc_defconfig
> index 43d939b..7c05e6a 100644
> --- a/configs/socfpga_de0_nano_soc_defconfig
> +++ b/configs/socfpga_de0_nano_soc_defconfig
> @@ -10,7 +10,6 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_de0_nano_soc"
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_FIT=y
> -CONFIG_BOOTDELAY=3
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
> diff --git a/configs/socfpga_is1_defconfig b/configs/socfpga_is1_defconfig
> index 658770b..58661c0 100644
> --- a/configs/socfpga_is1_defconfig
> +++ b/configs/socfpga_is1_defconfig
> @@ -9,7 +9,6 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_is1"
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_FIT=y
> -CONFIG_BOOTDELAY=3
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
> diff --git a/configs/socfpga_mcvevk_defconfig 
> b/configs/socfpga_mcvevk_defconfig
> index c5c662b..517a6de 100644
> --- a/configs/socfpga_mcvevk_defconfig
> +++ b/configs/socfpga_mcvevk_defconfig
> @@ -10,7 +10,6 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_mcvevk"
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_FIT=y
> -CONFIG_BOOTDELAY=3
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
> diff --git a/configs/socfpga_sockit_defconfig 
> b/configs/socfpga_sockit_defconfig
> index 1c4a40d..9bd3331 100644
> --- a/configs/socfpga_sockit_defconfig
> +++ b/configs/socfpga_sockit_defconfig
> @@ -10,7 +10,6 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_sockit"
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_FIT=y
> -CONFIG_BOOTDELAY=3
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
> diff --git a/configs/socfpga_socrates_defconfig 
> b/configs/socfpga_socrates_defconfig
> index e34d13e..5347032 100644
> --- a/configs/socfpga_socrates_defconfig
> +++ b/configs/socfpga_socrates_defconfig
> @@ -10,7 +10,6 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_socrates"
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_FIT=y
> -CONFIG_BOOTDELAY=3
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
> diff --git a/configs/socfpga_sr1500_defconfig 
> b/configs/socfpga_sr1500_defconfig
> index d1cfbcd..81a3fc1 100644
> --- a/configs/socfpga_sr1500_defconfig
> +++ b/configs/socfpga_sr1500_defconfig
> @@ -10,7 +10,6 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_sr1500"
>  CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_FIT=y
> -CONFIG_BOOTDELAY=3
>  CONFIG_HUSH_PARSER=y
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
> 


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


[U-Boot] [PATCH 3/3] arm64: thunderx_88xx_defconfig: remove unneeded CONFIG_SYS_EXTRA_OPTIONS

2016-07-25 Thread Masahiro Yamada
ARM64 is correctly select'ed in arch/arm/Kconfig, so this line in
the defconfig is unneeded.

Signed-off-by: Masahiro Yamada 
---

 configs/thunderx_88xx_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/thunderx_88xx_defconfig b/configs/thunderx_88xx_defconfig
index 4a8655f..28797f9 100644
--- a/configs/thunderx_88xx_defconfig
+++ b/configs/thunderx_88xx_defconfig
@@ -2,7 +2,6 @@ CONFIG_ARM=y
 CONFIG_TARGET_THUNDERX_88XX=y
 CONFIG_DM_SERIAL=y
 CONFIG_DEFAULT_DEVICE_TREE="thunderx-88xx"
-CONFIG_SYS_EXTRA_OPTIONS="ARM64"
 CONFIG_BOOTDELAY=5
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="ThunderX_88XX> "
-- 
1.9.1

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


[U-Boot] [PATCH 1/3] cmd: bootz: make CMD_BOOTZ depend on CMD_BOOTM

2016-07-25 Thread Masahiro Yamada
The "bootz" command is implemented in the "bootm", so the dependency
should be reflected in Kconfig.

Signed-off-by: Masahiro Yamada 
---

 Kconfig | 1 +
 cmd/Kconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Kconfig b/Kconfig
index ef12f9f..0d6afd2 100644
--- a/Kconfig
+++ b/Kconfig
@@ -57,6 +57,7 @@ config DISTRO_DEFAULTS
bool "Select defaults suitable for booting general purpose Linux 
distributions"
default y if ARCH_SUNXI
default n
+   select CMD_BOOTM
select CMD_BOOTZ
select CMD_DHCP
select CMD_EXT2
diff --git a/cmd/Kconfig b/cmd/Kconfig
index d69b817..171114d 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -162,6 +162,7 @@ config CMD_BOOTM
 
 config CMD_BOOTZ
bool "bootz"
+   depends on CMD_BOOTM
help
  Boot the Linux zImage
 
-- 
1.9.1

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


Re: [U-Boot] [RFC PATCH v2 3/5] spl: dfu: adding dfu support functions for SPL-DFU

2016-07-25 Thread B, Ravi
Hi Lukasz

>> Adding support functions to run dfu spl commands.
>> 
>> Signed-off-by: Ravi Babu 
>> ---
>>  common/spl/Makefile  |1 +
>>  common/spl/spl_dfu.c |   57
>> ++
>> include/spl.h|8 +++ 3 files changed, 66 insertions(+)
>>  create mode 100644 common/spl/spl_dfu.c
>> 
>> diff --git a/common/spl/Makefile b/common/spl/Makefile index 
>> 2e0f695..0850da0 100644
>> --- a/common/spl/Makefile
>> +++ b/common/spl/Makefile
>> @@ -21,4 +21,5 @@ obj-$(CONFIG_SPL_USB_SUPPORT) += spl_usb.o
>>  obj-$(CONFIG_SPL_FAT_SUPPORT) += spl_fat.o
>>  obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
>>  obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
>> +obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o
>>  endif
>> diff --git a/common/spl/spl_dfu.c b/common/spl/spl_dfu.c new file mode 
>> 100644 index 000..e8d0ba1
>> --- /dev/null
>> +++ b/common/spl/spl_dfu.c
>> @@ -0,0 +1,57 @@
>> +/*
>> + * (C) Copyright 2016
>> + * Texas Instruments, 
>> + *
>> + * Ravi B 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static int run_dfu(int usb_index, char *interface, char *devstring) {
>> +int ret;
>> +
>> +ret = dfu_init_env_entities(interface, devstring);
>> +if (ret) {
>> +dfu_free_entities();
>> +goto exit;
>> +}
>> +
>> +run_usb_dnl_gadget(usb_index, "usb_dnl_dfu");
>> +exit:
>> +dfu_free_entities();
>> +return ret;
>> +}
>> +
>> +int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface, 
>^^ this is a bit
>misleading.
>I would rename it to "alt_info_str"

Ok. Will change to alt_info_str.

>
>> char *devstr) +{
>> +char *str_env;
>> +int ret;
>> +
>> +/* set default environment */
>> +set_default_env(0);

>set_default_env() accepts const char *s as the argument. Please replace
>0 -> NULL

Fine.

>
>> +str_env = getenv(dfu_alt_info);
>> +if (!str_env) {
>> +error("\"dfu_alt_info\" env variable not
>> defined!\n");
>> +return -EINVAL;
>> +}
>> +
>> +ret = setenv("dfu_alt_info", str_env);
>> +if (ret) {
>> +error("unable to set env variable
>> \"dfu_alt_info\"!\n");
>> +return -EINVAL;
>> +}

>I'm a bit confused with this env flow.
>
>Is it required on your platform to:
>
>1. set_default_env(NULL) - which sets default envs (one which are mostly 
>defined at ./include/ file) in RAM

Actually not required, I felt it is better to use default environment inorder 
to get the latest 
environment from SPL which is being loaded. I will check once without 
set_default_env().

>
>2. call getenv with "dfu_alt_info_ram", which reads this value from RAM
>
>3. call setenv() to store already in ram available env variable to some medium?

This step is required, "dfu_alt_info" is one referred by dfu driver.

>
>If you want to store default envs in the medium (e.g. eMMC), I think that it 
>would be easier to call "saveenv".

Ok. 

>Otherwise, I would stay with default envs, since we only use this u-boot for 
>flashing other binaries.

Right.

Regards
Ravi 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 0/4] Add support for TI PCF8575 I2C GPIO expander

2016-07-25 Thread Vignesh R
This series adds support for TI's PCF8575 I2C GPIO expander[1] based on
Linux Kernel driver for the same.  Also adds support for ethernet to use
new PCF8575 driver to select appropriate cpsw slaves on dra72.

Depends on I2C DM support [2]

Tested on DRA72 EVM.

[1]http://www.ti.com/lit/ds/symlink/pcf8575.pdf
[2]https://www.mail-archive.com/u-boot@lists.denx.de/msg218923.html

Vignesh R (4):
  gpio: Add driver for TI PCF8575 I2C GPIO expander
  ARM: dra7xx_evm: Enable support for TI PCF8575
  net: cpsw: Add support to drive gpios for ethernet to be functional
  ARM: dts: dra72-evm: Add mode-gpios entry for mac node

 arch/arm/dts/dra72-evm.dts |   2 +-
 doc/device-tree-bindings/gpio/gpio-pcf857x.txt |  71 +
 drivers/gpio/Kconfig   |   7 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/pcf8575_gpio.c| 199 +
 drivers/net/cpsw.c |  13 ++
 include/configs/dra7xx_evm.h   |   5 +
 7 files changed, 297 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/gpio/gpio-pcf857x.txt
 create mode 100644 drivers/gpio/pcf8575_gpio.c

-- 
2.9.2

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


[U-Boot] [PATCH 3/4] net: cpsw: Add support to drive gpios for ethernet to be functional

2016-07-25 Thread Vignesh R
On DRA72 EVM, cpsw slaves may be muxed with other modules. This
selection is controlled by a pcf gpio line. Add support for cpsw driver
to acquire mode-gpios and select the appropriate slave using gpio APIs.

Signed-off-by: Vignesh R 
---
 drivers/net/cpsw.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 2ce4ec69f1df..83be336cf39c 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1152,12 +1153,14 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
struct cpsw_priv *priv = dev_get_priv(dev);
+   struct gpio_desc *mode_gpios;
const char *phy_mode;
const void *fdt = gd->fdt_blob;
int node = dev->of_offset;
int subnode;
int slave_index = 0;
int active_slave;
+   int num_mode_gpios;
int ret;
 
pdata->iobase = dev_get_addr(dev);
@@ -1203,6 +1206,16 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
*dev)
return -ENOENT;
}
 
+
+   num_mode_gpios = gpio_get_list_count(dev, "mode-gpios");
+   if (num_mode_gpios > 0) {
+   mode_gpios = malloc(sizeof(struct gpio_desc) *
+   num_mode_gpios);
+   gpio_request_list_by_name(dev, "mode-gpios", mode_gpios,
+ num_mode_gpios, GPIOD_IS_OUT);
+   free(mode_gpios);
+   }
+
active_slave = fdtdec_get_int(fdt, node, "active_slave", 0);
priv->data.active_slave = active_slave;
 
-- 
2.9.2

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


[U-Boot] [PATCH 1/4] gpio: Add driver for TI PCF8575 I2C GPIO expander

2016-07-25 Thread Vignesh R
TI's PCF8575 is a 16-bit I2C GPIO expander.The device features a
16-bit quasi-bidirectional I/O ports. Each quasi-bidirectional I/O can
be used as an input or output without the use of a data-direction
control signal. The I/Os should be high before being used as inputs.
Read the device documentation for more details[1].

This driver is based on pcf857x driver available in Linux v4.7 kernel.
It supports basic reading and writing of gpio pins.

[1] http://www.ti.com/lit/ds/symlink/pcf8575.pdf

Signed-off-by: Vignesh R 
---
 doc/device-tree-bindings/gpio/gpio-pcf857x.txt |  71 +
 drivers/gpio/Kconfig   |   7 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/pcf8575_gpio.c| 199 +
 4 files changed, 278 insertions(+)
 create mode 100644 doc/device-tree-bindings/gpio/gpio-pcf857x.txt
 create mode 100644 drivers/gpio/pcf8575_gpio.c

diff --git a/doc/device-tree-bindings/gpio/gpio-pcf857x.txt 
b/doc/device-tree-bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index ..ada4e2973323
--- /dev/null
+++ b/doc/device-tree-bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,71 @@
+* PCF857x-compatible I/O expanders
+
+The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be
+driven high by a pull-up current source or driven low to ground. This combines
+the direction and output level into a single bit per line, which can't be read
+back. We can't actually know at initialization time whether a line is 
configured
+(a) as output and driving the signal low/high, or (b) as input and reporting a
+low/high value, without knowing the last value written since the chip came out
+of reset (if any). The only reliable solution for setting up line direction is
+thus to do it explicitly.
+
+Required Properties:
+
+  - compatible: should be one of the following.
+- "maxim,max7328": For the Maxim MAX7378
+- "maxim,max7329": For the Maxim MAX7329
+- "nxp,pca8574": For the NXP PCA8574
+- "nxp,pca8575": For the NXP PCA8575
+- "nxp,pca9670": For the NXP PCA9670
+- "nxp,pca9671": For the NXP PCA9671
+- "nxp,pca9672": For the NXP PCA9672
+- "nxp,pca9673": For the NXP PCA9673
+- "nxp,pca9674": For the NXP PCA9674
+- "nxp,pca9675": For the NXP PCA9675
+- "nxp,pcf8574": For the NXP PCF8574
+- "nxp,pcf8574a": For the NXP PCF8574A
+- "nxp,pcf8575": For the NXP PCF8575
+- "ti,tca9554": For the TI TCA9554
+
+  - reg: I2C slave address.
+
+  - gpio-controller: Marks the device node as a gpio controller.
+  - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+cell specifies GPIO flags, as defined in . Only 
the
+GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+
+Optional Properties:
+
+  - lines-initial-states: Bitmask that specifies the initial state of each
+  line. When a bit is set to zero, the corresponding line will be initialized 
to
+  the input (pulled-up) state. When the  bit is set to one, the line will be
+  initialized the low-level output state. If the property is not specified
+  all lines will be initialized to the input state.
+
+  The I/O expander can detect input state changes, and thus optionally act as
+  an interrupt controller. When the expander interrupt line is connected all 
the
+  following properties must be set. For more information please see the
+  interrupt controller device tree bindings documentation available at
+  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
+
+  - interrupt-controller: Identifies the node as an interrupt controller.
+  - #interrupt-cells: Number of cells to encode an interrupt source, shall be 
2.
+  - interrupt-parent: phandle of the parent interrupt controller.
+  - interrupts: Interrupt specifier for the controllers interrupt.
+
+
+Please refer to gpio.txt in this directory for details of the common GPIO
+bindings used by client devices.
+
+Example: PCF8575 I/O expander node
+
+   pcf8575: gpio@20 {
+   compatible = "nxp,pcf8575";
+   reg = <0x20>;
+   interrupt-parent = <&irqpin2>;
+   interrupts = <3 0>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 73b862dc0b21..1af05358ec76 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -79,6 +79,13 @@ config PM8916_GPIO
  Power and reset buttons are placed in "pm8916_key" bank and
   have gpio numbers 0 and 1 respectively.
 
+config PCF8575_GPIO
+   bool "PCF8575 I2C GPIO Expander driver"
+   depends on DM_GPIO && DM_I2C
+   help
+Support for PCF8575 I2C 16 bit GPIO expander. Most of these
+chips are from NXP and TI.
+
 config ROCKCHIP_GPIO
bool "Rockchip GPIO driver"
depends on DM_GPIO
diff --git a/drivers/gpio/Makef

[U-Boot] [PATCH 2/4] ARM: dra7xx_evm: Enable support for TI PCF8575

2016-07-25 Thread Vignesh R
On DRA7, pcf chip present at address 0x21 on i2c1, is used to
switch between cpsw slave0 and slave1. Hence, enable PCF
driver for the same.

Signed-off-by: Vignesh R 
---
 include/configs/dra7xx_evm.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index 0d51aeb86909..4ad8beaf2f75 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -328,4 +328,9 @@
 #define CONFIG_EEPROM_CHIP_ADDRESS 0x50
 #define CONFIG_EEPROM_BUS_ADDRESS 0
 
+/* PCF Support */
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_PCF8575_GPIO
+#endif
+
 #endif /* __CONFIG_DRA7XX_EVM_H */
-- 
2.9.2

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


[U-Boot] [PATCH 4/4] ARM: dts: dra72-evm: Add mode-gpios entry for mac node

2016-07-25 Thread Vignesh R
On DRA72 EVM, cpsw slave1 is muxed with VIN2A, hence switch to cpsw
slave0 for ethernet. This is controlled by pcf gpio line. Add
appropriate mode-gpios DT entry so that driver can select the required
slave.

Signed-off-by: Vignesh R 
---
 arch/arm/dts/dra72-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/dra72-evm.dts b/arch/arm/dts/dra72-evm.dts
index ced2f1166d8c..aee570520aa6 100644
--- a/arch/arm/dts/dra72-evm.dts
+++ b/arch/arm/dts/dra72-evm.dts
@@ -576,6 +576,7 @@
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
pinctrl-1 = <&cpsw_sleep>;
+   mode-gpios = <&pcf_gpio_21 4 GPIO_ACTIVE_HIGH>;
 };
 
 &cpsw_emac1 {
@@ -587,7 +588,6 @@
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
-   active_slave = <1>;
 };
 
 &dcan1 {
-- 
2.9.2

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


Re: [U-Boot] [RFC PATCH v2 2/5] common: dfu: saperate the dfu common functionality

2016-07-25 Thread B, Ravi
Hi Lukasz

>> +++ b/common/dfu.c
>> @@ -0,0 +1,88 @@
>> +/*
>> + * dfu.c -- dfu command

>Please write:

>dfu.c -- common dfu command code

Ok. 

>> + *
>> + * Copyright (C) 2015
>> + * Lukasz Majewski 
>> + *
>> + * Copyright (C) 2012 Samsung Electronics
>> + * authors: Andrzej Pietrasiewicz 
>> + *  Lukasz Majewski 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +int run_usb_dnl_gadget(int usbctrl_index, char *usb_dnl_gadget) {
>> +bool dfu_reset = false;
>> +int ret, i = 0;
>> +
>> +board_usb_init(usbctrl_index, USB_INIT_DEVICE);
>> +g_dnl_clear_detach();
>> +g_dnl_register(usb_dnl_gadget);
>> +while (1) {
>> +if (g_dnl_detach()) {
>> +/*
>> + * Check if USB bus reset is performed after
>> detach,
>> + * which indicates that -R switch has been
>> passed to
>> + * dfu-util. In this case reboot the device
>> + */
>> +if (dfu_usb_get_reset()) {
>> +dfu_reset = true;
>> +goto exit;
>> +}
>> +
>> +/*
>> + * This extra number of
>> usb_gadget_handle_interrupts()
>> + * calls is necessary to assure correct
>> transmission
>> + * completion with dfu-util
>> + */
>> +if (++i == 1)
>> +goto exit;
>> +}
>> +
>> +if (ctrlc())
>> +goto exit;
>> +
>> +if (dfu_get_defer_flush()) {
>> +/*
>> + * Call to usb_gadget_handle_interrupts() is
>> necessary
>> + * to act on ZLP OUT transaction from HOST
>> PC after
>> + * transmitting the whole file.
>> + *
>> + * If this ZLP OUT packet is NAK'ed, the
>> HOST libusb
>> + * function fails after timeout (by default
>> it is set to
>> + * 5 seconds). In such situation the
>> dfu-util program
>> + * exits with error message.
>> + */
>> +usb_gadget_handle_interrupts(usbctrl_index);
>> +ret = dfu_flush(dfu_get_defer_flush(), NULL,
>> 0, 0);
>> +dfu_set_defer_flush(NULL);
>> +if (ret) {
>> +error("Deferred dfu_flush()
>> failed!");
>> +goto exit;
>> +}
>> +}
>> +
>> +WATCHDOG_RESET();
>> +usb_gadget_handle_interrupts(usbctrl_index);
>> +}
>> +exit:
>> +g_dnl_unregister();
>> +board_usb_cleanup(usbctrl_index, USB_INIT_DEVICE);
>> +
>> +if (dfu_reset)
>> +run_command("reset", 0);
>> +
>> +g_dnl_clear_detach();
>> +
>> +return ret;
>> +}
>> +
>> diff --git a/include/g_dnl.h b/include/g_dnl.h index ba49f1f..bd29a9f 
>> 100644
>> --- a/include/g_dnl.h
>> +++ b/include/g_dnl.h
>> @@ -43,5 +43,6 @@ void g_dnl_set_serialnumber(char *);  bool 
>> g_dnl_detach(void);  void g_dnl_trigger_detach(void);  void 
>> g_dnl_clear_detach(void);
>> +int run_usb_dnl_gadget(int usbctrl_index, char *usb_dnl_gadget);
>>  
>>  #endif /* __G_DOWNLOAD_H_ */


Regards
Ravi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] spl_nor.c: Support devicetree sizes different from 16k

2016-07-25 Thread Mike Looijmans
The devicetrees for various platforms already exceed 16k. Add a define
CONFIG_SYS_FDT_SIZE to specify the FDT size, and default to 16k. This
allows platforms with larger devicetree blobs to boot from NOR.

Signed-off-by: Mike Looijmans 
---
 common/spl/spl_nor.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
index da2422f..b37a023 100644
--- a/common/spl/spl_nor.c
+++ b/common/spl/spl_nor.c
@@ -7,6 +7,11 @@
 #include 
 #include 
 
+/* 16 KiB default size for DT */
+#ifndef CONFIG_SYS_FDT_SIZE
+# define CONFIG_SYS_FDT_SIZE (16<<10)
+#endif
+
 int spl_nor_load_image(void)
 {
int ret;
@@ -40,11 +45,11 @@ int spl_nor_load_image(void)
 
/*
 * Copy DT blob (fdt) to SDRAM. Passing pointer to
-* flash doesn't work (16 KiB should be enough for DT)
+* flash doesn't work
 */
memcpy((void *)CONFIG_SYS_SPL_ARGS_ADDR,
   (void *)(CONFIG_SYS_FDT_BASE),
-  (16 << 10));
+  CONFIG_SYS_FDT_SIZE);
 
return 0;
} else {
-- 
1.9.1

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


[U-Boot] [PATCH 0/3] Some Kconfig move/fixups

2016-07-25 Thread Masahiro Yamada

Masahiro Yamada (3):
  cmd: bootz: make CMD_BOOTZ depend on CMD_BOOTM
  cmd: booti: move CONFIG_CMD_BOOTI to Kconfig
  arm64: thunderx_88xx_defconfig: remove unneeded
CONFIG_SYS_EXTRA_OPTIONS

 Kconfig  | 2 ++
 cmd/Kconfig  | 7 +++
 configs/dragonboard410c_defconfig| 1 +
 configs/e2220-1170_defconfig | 1 +
 configs/hikey_defconfig  | 1 +
 configs/odroid-c2_defconfig  | 1 +
 configs/p2371-_defconfig | 1 +
 configs/p2371-2180_defconfig | 1 +
 configs/p2571_defconfig  | 1 +
 configs/p2771--a02_defconfig | 1 +
 configs/p2771--b00_defconfig | 1 +
 configs/rpi_3_defconfig  | 1 +
 configs/s32v234evb_defconfig | 1 +
 configs/thunderx_88xx_defconfig  | 1 -
 configs/uniphier_ld11_defconfig  | 1 +
 configs/uniphier_ld20_defconfig  | 1 +
 configs/vexpress_aemv8a_dram_defconfig   | 1 +
 configs/vexpress_aemv8a_juno_defconfig   | 1 +
 configs/vexpress_aemv8a_semi_defconfig   | 1 +
 configs/xilinx_zynqmp_ep_defconfig   | 1 +
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
 configs/xilinx_zynqmp_zcu102_defconfig   | 1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
 include/config_distro_defaults.h | 3 ---
 include/configs/uniphier.h   | 1 -
 include/configs/vexpress_aemv8a.h| 1 -
 include/configs/xilinx_zynqmp.h  | 1 -
 30 files changed, 32 insertions(+), 7 deletions(-)

-- 
1.9.1

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


[U-Boot] [PATCH 2/3] cmd: booti: move CONFIG_CMD_BOOTI to Kconfig

2016-07-25 Thread Masahiro Yamada
This command is used to boot ARM64 Linux.

I made DISTRO_DEFAULTS select this option for ARM64 to respect
include/config_distro_defaults.h.

Signed-off-by: Masahiro Yamada 
---

 Kconfig  | 1 +
 cmd/Kconfig  | 6 ++
 configs/dragonboard410c_defconfig| 1 +
 configs/e2220-1170_defconfig | 1 +
 configs/hikey_defconfig  | 1 +
 configs/odroid-c2_defconfig  | 1 +
 configs/p2371-_defconfig | 1 +
 configs/p2371-2180_defconfig | 1 +
 configs/p2571_defconfig  | 1 +
 configs/p2771--a02_defconfig | 1 +
 configs/p2771--b00_defconfig | 1 +
 configs/rpi_3_defconfig  | 1 +
 configs/s32v234evb_defconfig | 1 +
 configs/uniphier_ld11_defconfig  | 1 +
 configs/uniphier_ld20_defconfig  | 1 +
 configs/vexpress_aemv8a_dram_defconfig   | 1 +
 configs/vexpress_aemv8a_juno_defconfig   | 1 +
 configs/vexpress_aemv8a_semi_defconfig   | 1 +
 configs/xilinx_zynqmp_ep_defconfig   | 1 +
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
 configs/xilinx_zynqmp_zcu102_defconfig   | 1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
 include/config_distro_defaults.h | 3 ---
 include/configs/uniphier.h   | 1 -
 include/configs/vexpress_aemv8a.h| 1 -
 include/configs/xilinx_zynqmp.h  | 1 -
 29 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/Kconfig b/Kconfig
index 0d6afd2..335efcd 100644
--- a/Kconfig
+++ b/Kconfig
@@ -59,6 +59,7 @@ config DISTRO_DEFAULTS
default n
select CMD_BOOTM
select CMD_BOOTZ
+   select CMD_BOOTI if ARM64
select CMD_DHCP
select CMD_EXT2
select CMD_EXT4
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 171114d..f7c609d 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -166,6 +166,12 @@ config CMD_BOOTZ
help
  Boot the Linux zImage
 
+config CMD_BOOTI
+   bool "booti"
+   depends on CMD_BOOTM && ARM64
+   help
+ Boot the Linux Image for ARM64
+
 config CMD_BOOTEFI
bool "bootefi"
depends on EFI_LOADER
diff --git a/configs/dragonboard410c_defconfig 
b/configs/dragonboard410c_defconfig
index ad2e8b8..4aa21eb 100644
--- a/configs/dragonboard410c_defconfig
+++ b/configs/dragonboard410c_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_SNAPDRAGON=y
 CONFIG_DEFAULT_DEVICE_TREE="dragonboard410c"
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="dragonboard410c => "
+CONFIG_CMD_BOOTI=y
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_MEMINFO=y
diff --git a/configs/e2220-1170_defconfig b/configs/e2220-1170_defconfig
index eb01dec..c2fb6e6 100644
--- a/configs/e2220-1170_defconfig
+++ b/configs/e2220-1170_defconfig
@@ -5,6 +5,7 @@ CONFIG_DEFAULT_DEVICE_TREE="tegra210-e2220-1170"
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Tegra210 (E2220-1170) # "
+CONFIG_CMD_BOOTI=y
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/hikey_defconfig b/configs/hikey_defconfig
index d150dd3..343ec87 100644
--- a/configs/hikey_defconfig
+++ b/configs/hikey_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BOOTI=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
index 808bbc2..8805b43 100644
--- a/configs/odroid-c2_defconfig
+++ b/configs/odroid-c2_defconfig
@@ -5,6 +5,7 @@ CONFIG_TARGET_ODROID_C2=y
 CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_BDI is not set
+CONFIG_CMD_BOOTI=y
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_LOADS is not set
diff --git a/configs/p2371-_defconfig b/configs/p2371-_defconfig
index d27fd6d..0f47283 100644
--- a/configs/p2371-_defconfig
+++ b/configs/p2371-_defconfig
@@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="tegra210-p2371-"
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Tegra210 (P2371-) # "
+CONFIG_CMD_BOOTI=y
 # CONFIG_CMD_IMI is not set
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/p2371-2180_defconfig b/configs/p2371-2180_defconfig
index 4e365b5..f398988 100644
--- a/configs/p2371-2180_defconfig
+++ b/configs/p2371-2180_defconfig
@@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="tegra210-p2371-2180"
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Tegra210 (P2371-2180) # "
+CONFIG_CMD_BOOTI=y
 # CONFIG_C

Re: [U-Boot] [PATCH 1/3] cmd: bootz: make CMD_BOOTZ depend on CMD_BOOTM

2016-07-25 Thread Robert P. J. Day
On Mon, 25 Jul 2016, Masahiro Yamada wrote:

> The "bootz" command is implemented in the "bootm", so the dependency
> should be reflected in Kconfig.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  Kconfig | 1 +
>  cmd/Kconfig | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/Kconfig b/Kconfig
> index ef12f9f..0d6afd2 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -57,6 +57,7 @@ config DISTRO_DEFAULTS
>   bool "Select defaults suitable for booting general purpose Linux 
> distributions"
>   default y if ARCH_SUNXI
>   default n
> + select CMD_BOOTM
>   select CMD_BOOTZ
>   select CMD_DHCP
>   select CMD_EXT2
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index d69b817..171114d 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -162,6 +162,7 @@ config CMD_BOOTM
>
>  config CMD_BOOTZ
>   bool "bootz"
> + depends on CMD_BOOTM
>   help
> Boot the Linux zImage

  if bootz already depends on bootm, why then do you need to select
both?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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


Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h

2016-07-25 Thread Wolfgang Denk
Dear Robert,

In message  you 
wrote:
>
>   i'm not sure it's as bad as it looks, since those macros are used
> specifically in drivers/bootcount/Makefile:

You are right, and apparently it is working fine so far.  But it is
confusing, and...

>   obj-$(CONFIG_SOC_DA8XX) += bootcount_davinci.o
>   obj-$(CONFIG_BOOTCOUNT_AM33XX)  += bootcount_davinci.o

..this would make more sense to me if it was called

CONFIG_BOOTCOUNT_DAVINCI

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
Do not simplify the design of a program if a way can be found to make
it complex and wonderful.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/4] configs: dra7xx: Update QSPI speed to 76.8MHz

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 03:45:46PM +0530, Vignesh R wrote:

> Now that QSPI driver can support 76.8MHz, update the
> CONFIG_SF_DEFAULT_SPEED to the same value.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/4] net: cpsw: Add support to drive gpios for ethernet to be functional

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 06:40:22PM +0530, Vignesh R wrote:

> On DRA72 EVM, cpsw slaves may be muxed with other modules. This
> selection is controlled by a pcf gpio line. Add support for cpsw driver
> to acquire mode-gpios and select the appropriate slave using gpio APIs.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

Minor nit below:

> @@ -1203,6 +1206,16 @@ static int cpsw_eth_ofdata_to_platdata(struct udevice 
> *dev)
>   return -ENOENT;
>   }
>  
> +
> + num_mode_gpios = gpio_get_list_count(dev, "mode-gpios");

Extra blank line added.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] gpio: Add driver for TI PCF8575 I2C GPIO expander

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 06:40:20PM +0530, Vignesh R wrote:

> TI's PCF8575 is a 16-bit I2C GPIO expander.The device features a
> 16-bit quasi-bidirectional I/O ports. Each quasi-bidirectional I/O can
> be used as an input or output without the use of a data-direction
> control signal. The I/Os should be high before being used as inputs.
> Read the device documentation for more details[1].
> 
> This driver is based on pcf857x driver available in Linux v4.7 kernel.
> It supports basic reading and writing of gpio pins.
> 
> [1] http://www.ti.com/lit/ds/symlink/pcf8575.pdf
> 
> Signed-off-by: Vignesh R 
[snip]
> @@ -0,0 +1,199 @@
> +/*
> + * PCF8575 I2C GPIO EXPANDER DRIVER
> + *
> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * Vignesh R 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * SPDX-License-Identifier:  GPL-2.0

With the SPDX tag we don't need the rest of the GPL boilerplate.

> + *
> + *
> + * Driver for TI PCF-8575 16 bit I2C gpio expander. Based on
> + * gpio-pcf857x Linux Kernel(v4.7) driver.
> + *
> + * Copyright (C) 2007 David Brownell

But of course do keep the above.

Otherwise:
Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] ARM: dra7xx_evm: Enable support for TI PCF8575

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 06:40:21PM +0530, Vignesh R wrote:

> On DRA7, pcf chip present at address 0x21 on i2c1, is used to
> switch between cpsw slave0 and slave1. Hence, enable PCF
> driver for the same.
> 
> Signed-off-by: Vignesh R 
> ---
>  include/configs/dra7xx_evm.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
> index 0d51aeb86909..4ad8beaf2f75 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -328,4 +328,9 @@
>  #define CONFIG_EEPROM_CHIP_ADDRESS 0x50
>  #define CONFIG_EEPROM_BUS_ADDRESS 0
>  
> +/* PCF Support */
> +#ifndef CONFIG_SPL_BUILD
> +#define CONFIG_PCF8575_GPIO
> +#endif

We need to invert the logic and undef on SPL, and pick this up normally
via Kconfig.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] ARM: dts: dra72-evm: Add mode-gpios entry for mac node

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 06:40:23PM +0530, Vignesh R wrote:

> On DRA72 EVM, cpsw slave1 is muxed with VIN2A, hence switch to cpsw
> slave0 for ethernet. This is controlled by pcf gpio line. Add
> appropriate mode-gpios DT entry so that driver can select the required
> slave.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 8/8] tools: moveconfig: support CONFIG_SYS_EXTRA_OPTIONS cleaning

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 07:15:29PM +0900, Masahiro Yamada wrote:

> We mostly move config options from board header files to Kconfig,
> but sometimes config defines come from CONFIG_SYS_EXTRA_OPTIONS.
> 
> Historically, CONFIG_SYS_EXTRA_OPTIONS originates in boards.cfg,
> which was used as a central database of configuration prior to the
> Kconfig conversion.
> 
> Now, we want to migrate to primary entries in Kconfig rather than
> option list in CONFIG_SYS_EXTRA_OPTIONS, so it should be helpful to
> have the tool to cleanup CONFIG_SYS_EXTRA_OPTIONS automatically.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] ARM: dra7xx: Change DPLL_PER_HS13 divider value

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 03:45:44PM +0530, Vignesh R wrote:

> From: Lokesh Vutla 
> 
> According to AM572x DM SPRS953A, QSPI bus speed can be 76.8MHz, hence
> update QSPI input clock divider value (DPLL_PER_HS13) to provide 76.8MHz
> clock, so that driver can use the same.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] spi: ti_qspi: dra7xx: Add support to use 76.8MHz clock

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 03:45:45PM +0530, Vignesh R wrote:

> According to AM572x DM SPRS953A, QSPI bus speed can be 76.8MHz, update
> the driver to use the same.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 5/8] tools: moveconfig: show diffs of cleaned headers in color

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 07:15:26PM +0900, Masahiro Yamada wrote:

> Show code diff in color if --color option is given.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 7/8] tools: moveconfig: make getting all defconfigs into helper function

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 07:15:28PM +0900, Masahiro Yamada wrote:

> I want to reuse this routine in the next commit.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] ARM: dts: dra7xx: Update spi-max-frequency for QSPI

2016-07-25 Thread Vignesh R


On Monday 25 July 2016 07:08 PM, Tom Rini wrote:
> On Mon, Jul 25, 2016 at 03:45:47PM +0530, Vignesh R wrote:
> 
>> According to AM572x DM SPRS953A, QSPI max bus speed is 76.8MHz.
>> Therefore update the spi-max-frequency value of QSPI node for DRA74 and
>> DRA72 evm. This increase flash read speed by ~2MB/s.
>>
>> Signed-off-by: Vignesh R 
> 
> Reviewed-by: Tom Rini 
> 
> And similar changes are taking place in Linux-land and the DTS will be
> updated there too, right?  Thanks!

Yes, I will be updating Kernel DTS too...


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


Re: [U-Boot] [PATCH] spl_nor.c: Support devicetree sizes different from 16k

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 01:20:39PM +0200, Mike Looijmans wrote:

> The devicetrees for various platforms already exceed 16k. Add a define
> CONFIG_SYS_FDT_SIZE to specify the FDT size, and default to 16k. This
> allows platforms with larger devicetree blobs to boot from NOR.

Ug, yes, that is too small.

> Signed-off-by: Mike Looijmans 
> ---
>  common/spl/spl_nor.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
> index da2422f..b37a023 100644
> --- a/common/spl/spl_nor.c
> +++ b/common/spl/spl_nor.c
> @@ -7,6 +7,11 @@
>  #include 
>  #include 
>  
> +/* 16 KiB default size for DT */
> +#ifndef CONFIG_SYS_FDT_SIZE
> +# define CONFIG_SYS_FDT_SIZE (16<<10)
> +#endif

There's not a lot of CONFIG_SPL_NOR_SUPPORT boards today, so can we
please move this into the config.h file for all, rather than "hide" this
here?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] ARM: dts: dra7xx: Update spi-max-frequency for QSPI

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 03:45:47PM +0530, Vignesh R wrote:

> According to AM572x DM SPRS953A, QSPI max bus speed is 76.8MHz.
> Therefore update the spi-max-frequency value of QSPI node for DRA74 and
> DRA72 evm. This increase flash read speed by ~2MB/s.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

And similar changes are taking place in Linux-land and the DTS will be
updated there too, right?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/4] dra7xx: QSPI: Increase SPI bus speed.

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 03:45:43PM +0530, Vignesh R wrote:

> By configuring DPLL_PER_HS13 divider value to provide 76.8MHz clock as
> QSPI fclk on dra7xx, it is possible to operate SPI slave clock at
> 768.MHz which is the maximum supported frequency as per AM572x DM
> SPRS953A. This helps to increase flash read speed by ~2MB/s.
> 
> Tested  on DRA74 Rev G & H, DRA72 Rev B & C EVMs.

And for the record, there is no HW that exists "in the wild" that would
not support these options, yes?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] treewide: move CONFIG_PHYS_64BIT to Kconfig

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 07:56:03PM +0900, Masahiro Yamada wrote:

> We need to ensure that CONFIG_PHYS_64BIT is configured via Kconfig so
> that it is always available to the build system.  Otherwise we can run
> into cases where we have inconsistent sizes of certain attributes.
> 
> Ravi Babu reported offset mismatch of struct dwc3 across files since
> commit 95ebc253e6d4 ("types.h: move and redefine resource_size_t").
> Since the commit, resource_addr_t points to phys_addr_t, whose size
> is dependent on CONFIG_PHYS_64BIT for ARM architecture.
> 
> I tried my best to use "select" where possible (for example, ARMv8
> architecture) because I think this kind of option is generally user-
> unconfigurable.  However, I see some of PowerPC boards have 36BIT
> defconfigs as well as 32BIT ones.  I moved CONFIG_PHYS_64BIT to the
> defconfigs for such boards.
> 
> CONFIG_36BIT is no longer referenced, so all of the defines were
> removed from CONFIG_SYS_EXTRA_OPTIONS.
> 
> Fixes: 95ebc253e6d4 ("types.h: move and redefine resource_size_t")
> Signed-off-by: Masahiro Yamada 
> Reported-by: Ravi Babu 
> Acked-by: Stefan Roese 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] a few questions about saving bootcount in the environment

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 06:57:21AM +0200, Wolfgang Denk wrote:
> Dear Robert,
> 
> In message  you 
> wrote:
> > 
> > so this tells me that there's not a whole lot of that feature being
> > used, so i won't spend much time on it.
> 
> Right, it is only a last resort when you cannot find any better place
> to storeit (in a hardware register that survives resets).

That's not strictly true.  One of the things I noticed recently is that
Mender uses bootcount, in environment, as a least common denominator.
And thrown in a file in a filesystem, in so far as you trust the
underlying black box to be good about reads/writes and wear levelling,
it's robust enough (for certain values of robust and enough).  We're
dipping into one of those areas where experts have varying opinions on
what's good enough, hence all the qualifiers.  But it is a useful
option.  And neatly circumvents the need for a "driver" to clear the
count too.

[snip]
> > now, i can see where one wants to reset "bootcount" to zero once you
> > boot successfully, but why would you also set "upgrade_available" to
> > zero? don't you want to keep using that feature when you boot in the
> > future?
> 
> --> Heiko ?

Heiko wrote a kernel driver, for the non-env side of things at least at
one point, and the DT bindings didn't get approved.  I picked it up
years ago, tried, and had different DT binding approval problems and
never cycled back to it while I was at TI playing with that kind of
stuff.  Which is why the bootcount in env side of things is so
attractive, it's just fw_setenv/printenv once you're happy with your
system boot.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/8] tools: moveconfig: do not cleanup headers in include/generated

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 07:15:22PM +0900, Masahiro Yamada wrote:

> The files in include/generated are generated during build and removed
> by "make mrproper", so it has no point to touch them by this tool.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [issue report] mainline u-boot was stuck before booting kernel

2016-07-25 Thread Ziyuan Xu

Hi All,

I'm sorry to tell you that I failed to boot linux kernel with the 
mainline u-boot on rk3288 board(both evb-rk3288 & fennec-rk3288). It was 
stuck in cleanup_before_linux() before jumping to linux, and the 
boot_stage_flag is BOOTSTAGE_ID_BOOTM_HANDOFF.


## Current stack ends at 0x7df638b0 *  kernel: cmdline image address = 
0x0200

## No init Ramdisk
   ramdisk start = 0x, ramdisk end = 0x
## No Flattened Device Tree
Continuing to boot without FDT
Initial value for argc=3
Final value for argc=3
using: ATAGS
## Transferring control to Linux (at address 0200)...

Starting kernel ...

With the further investigation, it never returnned back from 
invalidate_dcache_all(). I mean that I can't reach stage 4 as below.


cleanup_before_linux
==>cleanup_before_linux_select
==>1.disable_interrupts
==>2.dcache_disable
==>3.invalidate_dcache_all
==>4.icache_disable

Debug further, invalidate_dcache_all  invalidate all cache one-by-one 
which cache type is DATA_ONLY, INSTRUCTION_DATA or UNIFIED. And 
invalidate way from one set to another set in order. The problem is that 
the PC ran away in invalidate way loop  [cache level L1!!!].


I add some serial output code in __v7_flush_dcache_all to figure out the 
bog.

I expect:
Print the value of r9 in sequence, e.g 0x7f, 0x7e, 0x7d. 0x01, 0x00 
(hex)
In fact, print the value of r9 in sequence at first, but print 
unexpected value afterwards.   e.g 0x7f, 0x7e, 0x7d, ..,0x73, 0x40, 
0x85,


ENTRY(__v7_flush_dcache_all)
[snip]
loop1:
movr9, r7@ create working copy of max index
loop2:
+  stmfdsp!, {r0}
+  ldr r0, =0xff69
+  str r9, [r0]
+  ldmfdsp!, {r0}
 ARM(orrr11, r10, r4, lsl r5)@ factor way and cache 
number into r11

 THUMB(lslr6, r4, r5)
 THUMB(orrr11, r10, r6)@ factor way and cache 
number into r11

 ARM(orrr11, r11, r9, lsl r2)@ factor index number into r11
 THUMB(lslr6, r9, r2)
 THUMB(orrr11, r11, r6)@ factor index number into r11
mcrp15, 0, r11, c7, c14, 2@ clean & invalidate by set/way
subsr9, r9, #1@ decrement the index
bgeloop2
subsr4, r4, #1@ decrement the way
bgeloop1
skip:
ENDPROC(__v7_flush_dcache_all)

I don't have the jtag, hence I can't address the current pc. I have no 
doubt that if any glitches in __v7_flush_dcache_all, I reviewed several 
times, also copy kernel's implement to here. :-( No effect.
A more interesting thing is that Sandy had report it.  He and I have 
similar problem. Everything work fine after I applied his patches, or 
disable dcache(active CONFIG_SYS_DCACHE_OFF).

@Stany, I'm sorry that I disable dcache during hack.. That was a mistake:-(

@Simon & hieko,
Can you boot linux with the mainline u-boot? have a try?


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


Re: [U-Boot] [RFC PATCH v2 3/5] spl: dfu: adding dfu support functions for SPL-DFU

2016-07-25 Thread Lukasz Majewski
Hi Ravi,

> Hi Lukasz
> 
> >> Adding support functions to run dfu spl commands.
> >> 
> >> Signed-off-by: Ravi Babu 
> >> ---
> >>  common/spl/Makefile  |1 +
> >>  common/spl/spl_dfu.c |   57
> >> ++
> >> include/spl.h|8 +++ 3 files changed, 66
> >> insertions(+) create mode 100644 common/spl/spl_dfu.c
> >> 
> >> diff --git a/common/spl/Makefile b/common/spl/Makefile index 
> >> 2e0f695..0850da0 100644
> >> --- a/common/spl/Makefile
> >> +++ b/common/spl/Makefile
> >> @@ -21,4 +21,5 @@ obj-$(CONFIG_SPL_USB_SUPPORT) += spl_usb.o
> >>  obj-$(CONFIG_SPL_FAT_SUPPORT) += spl_fat.o
> >>  obj-$(CONFIG_SPL_EXT_SUPPORT) += spl_ext.o
> >>  obj-$(CONFIG_SPL_SATA_SUPPORT) += spl_sata.o
> >> +obj-$(CONFIG_SPL_DFU_SUPPORT) += spl_dfu.o
> >>  endif
> >> diff --git a/common/spl/spl_dfu.c b/common/spl/spl_dfu.c new file
> >> mode 100644 index 000..e8d0ba1
> >> --- /dev/null
> >> +++ b/common/spl/spl_dfu.c
> >> @@ -0,0 +1,57 @@
> >> +/*
> >> + * (C) Copyright 2016
> >> + * Texas Instruments, 
> >> + *
> >> + * Ravi B 
> >> + *
> >> + * SPDX-License-Identifier:   GPL-2.0+
> >> + */
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +static int run_dfu(int usb_index, char *interface, char
> >> *devstring) {
> >> +  int ret;
> >> +
> >> +  ret = dfu_init_env_entities(interface, devstring);
> >> +  if (ret) {
> >> +  dfu_free_entities();
> >> +  goto exit;
> >> +  }
> >> +
> >> +  run_usb_dnl_gadget(usb_index, "usb_dnl_dfu");
> >> +exit:
> >> +  dfu_free_entities();
> >> +  return ret;
> >> +}
> >> +
> >> +int spl_dfu_cmd(int usbctrl, char *dfu_alt_info, char *interface, 
> >  ^^ this is a bit
> >  misleading.
> >  I would rename it to
> > "alt_info_str"
> 
> Ok. Will change to alt_info_str.
> 
> >
> >> char *devstr) +{
> >> +  char *str_env;
> >> +  int ret;
> >> +
> >> +  /* set default environment */
> >> +  set_default_env(0);
> 
> >set_default_env() accepts const char *s as the argument. Please
> >replace 0 -> NULL
> 
> Fine.
> 
> >
> >> +  str_env = getenv(dfu_alt_info);
> >> +  if (!str_env) {
> >> +  error("\"dfu_alt_info\" env variable not
> >> defined!\n");
> >> +  return -EINVAL;
> >> +  }
> >> +
> >> +  ret = setenv("dfu_alt_info", str_env);
> >> +  if (ret) {
> >> +  error("unable to set env variable
> >> \"dfu_alt_info\"!\n");
> >> +  return -EINVAL;
> >> +  }
> 
> >I'm a bit confused with this env flow.
> >
> >Is it required on your platform to:
> >
> >1. set_default_env(NULL) - which sets default envs (one which are
> >mostly defined at ./include/ file) in RAM
> 
> Actually not required, I felt it is better to use default environment
> inorder to get the latest environment from SPL which is being loaded.
> I will check once without set_default_env().
> 
> >
> >2. call getenv with "dfu_alt_info_ram", which reads this value from
> >RAM
> >
> >3. call setenv() to store already in ram available env variable to
> >some medium?
> 
> This step is required, "dfu_alt_info" is one referred by dfu driver.

But is it necessary to store "dfu_alt_info" env variable to memory
medium (e.g. eMMC) or is it enough to use the default value stored in
RAM?

> 
> >
> >If you want to store default envs in the medium (e.g. eMMC), I think
> >that it would be easier to call "saveenv".
> 
> Ok. 
> 
> >Otherwise, I would stay with default envs, since we only use this
> >u-boot for flashing other binaries.
> 
> Right.
> 
> Regards
> Ravi 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 4/5] dra7x: boot: add dfu bootmode support

2016-07-25 Thread B, Ravi
Hi Tom

>> +++ b/arch/arm/include/asm/arch-omap5/spl.h
>> @@ -20,7 +20,7 @@
>>  #define BOOT_DEVICE_QSPI_1  0x0A
>>  #define BOOT_DEVICE_QSPI_4  0x0B
>>  #define BOOT_DEVICE_UART0x43
>> -#define BOOT_DEVICE_USB 0x45
>> +#define BOOT_DEVICE_DFU 0x45

>So you're breaking regular USB gadget support with this change, on these 
>platforms, yes?

You are correct. This platform does not support BOOT_DEVICE_USB support.
The BOOT_DEVICE_USB is basically the USBHOST-MSC support 
(CONFIG_SPL_USB_SUPPORT), i.e, boot from mass storage device.
Yes, this platform don't have USBHOST-MSC support, hence BOOT_DEVICE_USB is not 
valid for this device and removed, and also does not support BOOT_DEVICE_USBETH 
as well.
Instead BOOT_DEVICE_DFU  is defined for USB-Gadget-DFU support, i.e, boot from 
USB-DFU.

Regards
Ravi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 03/14] drivers: i2c: uclass: parse dt parameters only when CONFIG_OF_CONTROL is enable

2016-07-25 Thread Mugunthan V N
On Friday 22 July 2016 07:46 PM, Simon Glass wrote:
> Hi Muganthan,
> 
> On 22 July 2016 at 01:35, Mugunthan V N  wrote:
>> On Friday 22 July 2016 08:51 AM, Simon Glass wrote:
>>> Hi Mugunthan,
>>>
>>> On 18 July 2016 at 03:40, Mugunthan V N  wrote:
 parse dt parameter of i2c devices only when CONFIG_OF_CONTROL
 is enabled.

 Signed-off-by: Mugunthan V N 
 ---
  drivers/i2c/i2c-uclass.c | 14 ++
  1 file changed, 14 insertions(+)
>>>
>>> Reviewed-by: Simon Glass 
>>>
>>> Please see below.
>>>

 diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
 index 50b99ea..20b30ff 100644
 --- a/drivers/i2c/i2c-uclass.c
 +++ b/drivers/i2c/i2c-uclass.c
 @@ -467,6 +467,7 @@ int i2c_deblock(struct udevice *bus)
 return ops->deblock(bus);
  }

 +#if CONFIG_IS_ENABLED(OF_CONTROL)
  int i2c_chip_ofdata_to_platdata(const void *blob, int node,
 struct dm_i2c_chip *chip)
  {
 @@ -482,31 +483,44 @@ int i2c_chip_ofdata_to_platdata(const void *blob, 
 int node,

 return 0;
  }
 +#endif

  static int i2c_post_probe(struct udevice *dev)
  {
 +#if CONFIG_IS_ENABLED(OF_CONTROL)
 struct dm_i2c_bus *i2c = dev_get_uclass_priv(dev);

 i2c->speed_hz = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
  "clock-frequency", 10);
>>>
>>> The above should be moved into i2c_chip_ofdata_to_platdata(), which
>>> will only be called if there is a device tree.
>>
>> This cannot be moved to i2c_chip_ofdata_to_platdata() as it is called
>> from post_bind where uclass_priv will not be allocated. uclass_priv will
>> be allocated in device probe.
> 
> OK I see. Then why do we need to support i2c without OF_CONTROL? Would
> it not be better to enable OF_CONTROL?
> 

Due to the memory size issue in OMAP SoCs, enabling OF_CONTROL for spl
is not possible. So having an option of enabling i2c uclass without
OF_CONTROL will be a good option.

Regards
Mugunthan V N

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


Re: [U-Boot] a few questions about saving bootcount in the environment

2016-07-25 Thread Wolfgang Denk
Dear Tom,

In message <20160725135754.GN14698@bill-the-cat> you wrote:
> 
> > Right, it is only a last resort when you cannot find any better place
> > to storeit (in a hardware register that survives resets).
> 
> That's not strictly true.  One of the things I noticed recently is that
> Mender uses bootcount, in environment, as a least common denominator.
> And thrown in a file in a filesystem, in so far as you trust the
> underlying black box to be good about reads/writes and wear levelling,
> it's robust enough (for certain values of robust and enough).  We're
> dipping into one of those areas where experts have varying opinions on
> what's good enough, hence all the qualifiers.  But it is a useful
> option.  And neatly circumvents the need for a "driver" to clear the
> count too.

Agreed.  Let me rephrase the warning, then: it is always a good idea
to minimize the number of writes to the environment, especially when
done automagically.  One should at least avoid to re-write it on every
boot, especially when storage is some (flash based) storage device
with a limited number of erase/write cycles.  And even on other stoage
each write access includes the risk of errors.

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
People don't like to be lectured to, but if you can make them  laugh,
their  defenses  come  down,  and for the time being they've accepted
whatever truth is embedded in your humor. - Paul Krassner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/8] tools: moveconfig: do not check clean tree and compilers for -H option

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 07:15:23PM +0900, Masahiro Yamada wrote:

> The clean tree (make mrproper) and compilers are required when moving
> config options, but not needed when we only cleanup headers.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 6/8] tools: moveconfig: fix cleanup of defines across multiple lines

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 07:15:27PM +0900, Masahiro Yamada wrote:

> Correct the clean-up of such defines that continue across multiple
> lines, like follows:
> 
>   #define CONFIG_FOO "this continues to the next line " \
>   "this line should be removed too" \
>   "this line should be removed as well"
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] a few questions about saving bootcount in the environment

2016-07-25 Thread Wolfgang Denk
Dear Tom,

I wrote:

> Agreed.  Let me rephrase the warning, then: it is always a good idea
> to minimize the number of writes to the environment, especially when
> done automagically.  One should at least avoid to re-write it on every
> boot, especially when storage is some (flash based) storage device
> with a limited number of erase/write cycles.  And even on other stoage
> each write access includes the risk of errors.

And of course access to the environment in inherently much slower than
a register write. This may not matter in many cases, but when
optimizing boot time it may be important, too.

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
Some people march to the beat of a different drummer. And some people
tango!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 4/5] dra7x: boot: add dfu bootmode support

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 02:17:35PM +, B, Ravi wrote:
> Hi Tom
> 
> >> +++ b/arch/arm/include/asm/arch-omap5/spl.h
> >> @@ -20,7 +20,7 @@
> >>  #define BOOT_DEVICE_QSPI_10x0A
> >>  #define BOOT_DEVICE_QSPI_40x0B
> >>  #define BOOT_DEVICE_UART  0x43
> >> -#define BOOT_DEVICE_USB   0x45
> >> +#define BOOT_DEVICE_DFU   0x45
> 
> >So you're breaking regular USB gadget support with this change, on these 
> >platforms, yes?
> 
> You are correct. This platform does not support BOOT_DEVICE_USB support.
> The BOOT_DEVICE_USB is basically the USBHOST-MSC support 
> (CONFIG_SPL_USB_SUPPORT), i.e, boot from mass storage device.

So, we have 3 SoCs that share these values here, and we need to be
correct for all of them.  What does 0x45 mean, on OMAP5, DRA7xx and
AM57xx, in terms of what, and how, the ROM loaded something in?

> Yes, this platform don't have USBHOST-MSC support, hence BOOT_DEVICE_USB is 
> not valid for this device and removed, and also does not support 
> BOOT_DEVICE_USBETH as well.

When you say platform and device, do you mean SoC, or the specific EVM
you're working with?

> Instead BOOT_DEVICE_DFU  is defined for USB-Gadget-DFU support, i.e, boot 
> from USB-DFU.

It sounds like you're saying here that 0x45, for DRA7xx/AM57xx means
"ROM enumerated a USB gadget (of type what?) and was given a payload".
This is what, on TI platforms, usually happens with 0x45.  Sometimes
it's a USB RNDIS device and bootp (am33xx, am43xx), sometimes it's a
something else (I honestly forget what OMAP4 did, I think it was just a
vendor class self-defined and spec-allowed thing).  What is happening in
this case, and how do we get this first part in?

Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 0/5] SPL: DFU Support in SPL

2016-07-25 Thread B, Ravi
Tom

>> Traditionally the DFU support is available only as part 2nd stage boot 
>> loader(u-boot) and DFU is not supported in SPL.
>> 
>> The SPL-DFU feature is useful for boards which does not have MMC/SD, 
>> ethernet boot mechanism to boot the board and only has USB inteface.

>How well did you test DFU on other platforms after these changes?
>Thanks

Actually earlier platforms did not had this support,  support for either RNDIS 
boot mode (CONFIG_SPL_USBETH_SUPPORT) or
CONFIG_SPL_USB_SUPPORT (boot from mass-storage device) were only supported.

But ideally, this should work on any other platform, as functional flow of 
SPL-DFU is same as DFU functionality in u-boot and
reuse of common dfu driver, also DFU has been verified in multiple platforms in 
u-boot mainline.
The same DFU support is now brought to SPL to facilitate booting EVM using USB 
interface.

Regards
Ravi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] ARM64: rockchip: Add initial support for RK3368 based GeekBox

2016-07-25 Thread Andreas Färber
Hi Simon,

Am 23.07.2016 um 04:31 schrieb Simon Glass:
> On 18 July 2016 at 06:13, Heiko Stübner  wrote:
>> Am Montag, 18. Juli 2016, 03:06:07 schrieb Andreas Färber:
>>> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
>>> index 86b77f8..597f043 100644
>>> --- a/arch/arm/mach-rockchip/Kconfig
>>> +++ b/arch/arm/mach-rockchip/Kconfig
>>> @@ -3,6 +3,10 @@ if ARCH_ROCKCHIP
>>>  config ROCKCHIP_RK3288
>>>   bool "Support Rockchip RK3288"
>>>   select CPU_V7
>>> + select SUPPORT_SPL
>>> + select SPL
>>> + select SPL_DM
>>> + select SPL_SYS_MALLOC_SIMPLE
>>>   help
>>> The Rockchip RK3288 is a ARM-based SoC with a quad-core Cortex-A17
>>> including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
>>> @@ -13,12 +17,21 @@ config ROCKCHIP_RK3288
>>>  config ROCKCHIP_RK3036
>>>   bool "Support Rockchip RK3036"
>>>   select CPU_V7
>>> + select SUPPORT_SPL
>>> + select SPL
>>> + select SPL_DM
>>> + select SPL_SYS_MALLOC_SIMPLE
>>>   help
>>> The Rockchip RK3036 is a ARM-based SoC with a dual-core Cortex-A7
>>> including NEON and GPU, Mali-400 graphics, several DDR3 options
>>> and video codec support. Peripherals include Gigabit Ethernet,
>>> USB2 host and OTG, SDIO, I2S, UART, SPI, I2C and PWMs.
>>
>> looks like both you and Kever need that separation of the SPL symbols (me as
>> well for the rk3188 for the time being), so it might make sense to split that
>> out into a separate patch, all could use.
>>
>> I guess it might also make it easier for Simon to find an order to apply the
>> patches?
> 
> Yes. Andreas, can you please resent your patches against 
> u-boot-rockchip/master?

I had done that and thereby ran into the mismerges I pointed out. ;)
Didn't send that blown-up version out since you suggested an rk3399
resend, which came once I was unavailable over the extended weekend...

> Also it needs a MAINTAINERS file I think.

True.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 4/5] dra7x: boot: add dfu bootmode support

2016-07-25 Thread B, Ravi
Hi Tom

>> 
>> You are correct. This platform does not support BOOT_DEVICE_USB support.
>> The BOOT_DEVICE_USB is basically the USBHOST-MSC support 
>> (CONFIG_SPL_USB_SUPPORT), i.e, boot from mass storage device.

>So, we have 3 SoCs that share these values here, and we need to be correct for 
>all of them.  What does 0x45 mean, on OMAP5, DRA7xx and AM57xx, in terms of 
>what, and how, the ROM loaded something in?

For all  OMAP5/DRA7X/AM57X  devices, 0x45 means ROM-USB peripheral boot mode. 
You are correct, as pointed out, the "ROM enumerated as USB gadget (type : 
vendor specific download gadget)".

>> Yes, this platform don't have USBHOST-MSC support, hence BOOT_DEVICE_USB is 
>> not valid for this device and removed, and also does not support 
>> BOOT_DEVICE_USBETH as well.

>When you say platform and device, do you mean SoC, or the specific EVM you're 
>working with?

>> Instead BOOT_DEVICE_DFU  is defined for USB-Gadget-DFU support, i.e, boot 
>> from USB-DFU.

>It sounds like you're saying here that 0x45, for DRA7xx/AM57xx means "ROM 
>enumerated a USB gadget (of type what?) and was given a payload".

Correct. ROM implements custom download gadget.

>This is what, on TI platforms, usually happens with 0x45.  Sometimes it's a 
>USB RNDIS device and bootp (am33xx, am43xx), sometimes it's a something else 

Yes you are correct, there is only one USB mode implemented in ROM (either host 
boot  or peripheral boot mode).

 >(I honestly forget what OMAP4 did, I think it was just a vendor class 
 >self-defined and spec-allowed thing).  What is happening in this case, and 
 >how do we get this first part in?

I am not sure on OMAP4, it must be similar to OMAP5 which is vendor class 
specific download gadget.

Regards
Ravi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] arm64: thunderx_88xx_defconfig: remove unneeded CONFIG_SYS_EXTRA_OPTIONS

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 10:06:08PM +0900, Masahiro Yamada wrote:

> ARM64 is correctly select'ed in arch/arm/Kconfig, so this line in
> the defconfig is unneeded.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/3] Some Kconfig move/fixups

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 10:06:05PM +0900, Masahiro Yamada wrote:

> 
> Masahiro Yamada (3):
>   cmd: bootz: make CMD_BOOTZ depend on CMD_BOOTM
>   cmd: booti: move CONFIG_CMD_BOOTI to Kconfig

After a quick skim of the code, I think we could split bootz/booti into
cmd/boot[zi].c and this I think might have been why I didn't make sure
that CMD_BOOT[ZI] depended on CMD_BOOTM in the first place.  Can you
re-work them that way?  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 0/5] SPL: DFU Support in SPL

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 02:40:21PM +, B, Ravi wrote:
> Tom
> 
> >> Traditionally the DFU support is available only as part 2nd stage boot 
> >> loader(u-boot) and DFU is not supported in SPL.
> >> 
> >> The SPL-DFU feature is useful for boards which does not have MMC/SD, 
> >> ethernet boot mechanism to boot the board and only has USB inteface.
> 
> >How well did you test DFU on other platforms after these changes?
> >Thanks
> 
> Actually earlier platforms did not had this support,  support for either 
> RNDIS boot mode (CONFIG_SPL_USBETH_SUPPORT) or
> CONFIG_SPL_USB_SUPPORT (boot from mass-storage device) were only supported.

Yes, sorry, I mean you're making generic DFU code changes too, did you
test them on other TI platforms which support DFU in other cases to make
sure nothing slipped in and broke them with these changes?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/3] cmd: booti: move CONFIG_CMD_BOOTI to Kconfig

2016-07-25 Thread Ryan Harkin
On 25 July 2016 at 14:42, Michal Simek  wrote:
> On 25.7.2016 15:06, Masahiro Yamada wrote:
>> This command is used to boot ARM64 Linux.
>>
>> I made DISTRO_DEFAULTS select this option for ARM64 to respect
>> include/config_distro_defaults.h.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  Kconfig  | 1 +
>>  cmd/Kconfig  | 6 ++
>>  configs/dragonboard410c_defconfig| 1 +
>>  configs/e2220-1170_defconfig | 1 +
>>  configs/hikey_defconfig  | 1 +
>>  configs/odroid-c2_defconfig  | 1 +
>>  configs/p2371-_defconfig | 1 +
>>  configs/p2371-2180_defconfig | 1 +
>>  configs/p2571_defconfig  | 1 +
>>  configs/p2771--a02_defconfig | 1 +
>>  configs/p2771--b00_defconfig | 1 +
>>  configs/rpi_3_defconfig  | 1 +
>>  configs/s32v234evb_defconfig | 1 +
>>  configs/uniphier_ld11_defconfig  | 1 +
>>  configs/uniphier_ld20_defconfig  | 1 +
>>  configs/vexpress_aemv8a_dram_defconfig   | 1 +
>>  configs/vexpress_aemv8a_juno_defconfig   | 1 +
>>  configs/vexpress_aemv8a_semi_defconfig   | 1 +
>>  configs/xilinx_zynqmp_ep_defconfig   | 1 +
>>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
>>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
>>  configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 +
>>  configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
>>  configs/xilinx_zynqmp_zcu102_defconfig   | 1 +
>>  configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
>>  include/config_distro_defaults.h | 3 ---
>>  include/configs/uniphier.h   | 1 -
>>  include/configs/vexpress_aemv8a.h| 1 -
>>  include/configs/xilinx_zynqmp.h  | 1 -
>>  29 files changed, 30 insertions(+), 6 deletions(-)
>>
>> diff --git a/Kconfig b/Kconfig
>> index 0d6afd2..335efcd 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -59,6 +59,7 @@ config DISTRO_DEFAULTS
>>   default n
>>   select CMD_BOOTM
>>   select CMD_BOOTZ
>> + select CMD_BOOTI if ARM64
>>   select CMD_DHCP
>>   select CMD_EXT2
>>   select CMD_EXT4
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index 171114d..f7c609d 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -166,6 +166,12 @@ config CMD_BOOTZ
>>   help
>> Boot the Linux zImage
>>
>> +config CMD_BOOTI
>> + bool "booti"
>> + depends on CMD_BOOTM && ARM64
>> + help
>> +   Boot the Linux Image for ARM64
>
> I would even add here default y which can shorten defconfigs and you can
> disable it if you don't want it.
> What do you think?
>

That sounds like a good idea to me.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [issue report] mainline u-boot was stuck before booting kernel

2016-07-25 Thread Ziyuan Xu

hi Stany,

The difference is that you print out assertion log.

Reset not supported on this platform
### ERROR ### Please RESET the board ###

You can add show_boot_progress() function in your bsp file to find out 
something.

#define CONFIG_SHOW_BOOT_PROGRESS
void show_boot_progress(int progress)
{
printf("Boot reached stage %d\n", progress);
}


On 2016年07月25日 22:12, Ziyuan Xu wrote:

Hi All,

I'm sorry to tell you that I failed to boot linux kernel with the 
mainline u-boot on rk3288 board(both evb-rk3288 & fennec-rk3288). It 
was stuck in cleanup_before_linux() before jumping to linux, and the 
boot_stage_flag is BOOTSTAGE_ID_BOOTM_HANDOFF.


## Current stack ends at 0x7df638b0 *  kernel: cmdline image address = 
0x0200

## No init Ramdisk
   ramdisk start = 0x, ramdisk end = 0x
## No Flattened Device Tree
Continuing to boot without FDT
Initial value for argc=3
Final value for argc=3
using: ATAGS
## Transferring control to Linux (at address 0200)...

Starting kernel ...

With the further investigation, it never returnned back from 
invalidate_dcache_all(). I mean that I can't reach stage 4 as below.


cleanup_before_linux
==>cleanup_before_linux_select
==>1.disable_interrupts
==>2.dcache_disable
==>3.invalidate_dcache_all
==>4.icache_disable

Debug further, invalidate_dcache_all  invalidate all cache one-by-one 
which cache type is DATA_ONLY, INSTRUCTION_DATA or UNIFIED. And 
invalidate way from one set to another set in order. The problem is 
that the PC ran away in invalidate way loop  [cache level L1!!!].


I add some serial output code in __v7_flush_dcache_all to figure out 
the bog.

I expect:
Print the value of r9 in sequence, e.g 0x7f, 0x7e, 0x7d. 0x01, 
0x00 (hex)
In fact, print the value of r9 in sequence at first, but print 
unexpected value afterwards.   e.g 0x7f, 0x7e, 0x7d, ..,0x73, 0x40, 
0x85,


ENTRY(__v7_flush_dcache_all)
[snip]
loop1:
movr9, r7@ create working copy of max index
loop2:
+  stmfdsp!, {r0}
+  ldr r0, =0xff69
+  str r9, [r0]
+  ldmfdsp!, {r0}
 ARM(orrr11, r10, r4, lsl r5)@ factor way and cache 
number into r11

 THUMB(lslr6, r4, r5)
 THUMB(orrr11, r10, r6)@ factor way and cache 
number into r11
 ARM(orrr11, r11, r9, lsl r2)@ factor index number 
into r11

 THUMB(lslr6, r9, r2)
 THUMB(orrr11, r11, r6)@ factor index number into r11
mcrp15, 0, r11, c7, c14, 2@ clean & invalidate by set/way
subsr9, r9, #1@ decrement the index
bgeloop2
subsr4, r4, #1@ decrement the way
bgeloop1
skip:
ENDPROC(__v7_flush_dcache_all)

I don't have the jtag, hence I can't address the current pc. I have no 
doubt that if any glitches in __v7_flush_dcache_all, I reviewed 
several times, also copy kernel's implement to here. :-( No effect.
A more interesting thing is that Sandy had report it.  He and I have 
similar problem. Everything work fine after I applied his patches, or 
disable dcache(active CONFIG_SYS_DCACHE_OFF).
@Stany, I'm sorry that I disable dcache during hack.. That was a 
mistake:-(


@Simon & hieko,
Can you boot linux with the mainline u-boot? have a try?


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







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


Re: [U-Boot] [PATCH 2/3] cmd: booti: move CONFIG_CMD_BOOTI to Kconfig

2016-07-25 Thread Michal Simek
On 25.7.2016 15:06, Masahiro Yamada wrote:
> This command is used to boot ARM64 Linux.
> 
> I made DISTRO_DEFAULTS select this option for ARM64 to respect
> include/config_distro_defaults.h.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  Kconfig  | 1 +
>  cmd/Kconfig  | 6 ++
>  configs/dragonboard410c_defconfig| 1 +
>  configs/e2220-1170_defconfig | 1 +
>  configs/hikey_defconfig  | 1 +
>  configs/odroid-c2_defconfig  | 1 +
>  configs/p2371-_defconfig | 1 +
>  configs/p2371-2180_defconfig | 1 +
>  configs/p2571_defconfig  | 1 +
>  configs/p2771--a02_defconfig | 1 +
>  configs/p2771--b00_defconfig | 1 +
>  configs/rpi_3_defconfig  | 1 +
>  configs/s32v234evb_defconfig | 1 +
>  configs/uniphier_ld11_defconfig  | 1 +
>  configs/uniphier_ld20_defconfig  | 1 +
>  configs/vexpress_aemv8a_dram_defconfig   | 1 +
>  configs/vexpress_aemv8a_juno_defconfig   | 1 +
>  configs/vexpress_aemv8a_semi_defconfig   | 1 +
>  configs/xilinx_zynqmp_ep_defconfig   | 1 +
>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
>  configs/xilinx_zynqmp_zcu102_defconfig   | 1 +
>  configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
>  include/config_distro_defaults.h | 3 ---
>  include/configs/uniphier.h   | 1 -
>  include/configs/vexpress_aemv8a.h| 1 -
>  include/configs/xilinx_zynqmp.h  | 1 -
>  29 files changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/Kconfig b/Kconfig
> index 0d6afd2..335efcd 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -59,6 +59,7 @@ config DISTRO_DEFAULTS
>   default n
>   select CMD_BOOTM
>   select CMD_BOOTZ
> + select CMD_BOOTI if ARM64
>   select CMD_DHCP
>   select CMD_EXT2
>   select CMD_EXT4
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 171114d..f7c609d 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -166,6 +166,12 @@ config CMD_BOOTZ
>   help
> Boot the Linux zImage
>  
> +config CMD_BOOTI
> + bool "booti"
> + depends on CMD_BOOTM && ARM64
> + help
> +   Boot the Linux Image for ARM64

I would even add here default y which can shorten defconfigs and you can
disable it if you don't want it.
What do you think?

Thanks,
Michal


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


Re: [U-Boot] Passing information from SPL to next stage

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 08:54:27PM +1200, Chris Packham wrote:

> Hi,
> 
> Is there a standard way of passing information discovered by the SPL
> onto the next boot stage?
> 
> I'm guessing for platforms that support the new driver model it's
> possible to add/update information in the device-tree, but what about
> platforms that don't currently use the new driver model.
> 
> I had a quick search of the mailing list and docs but didn't find
> anything obvious. If I've missed something feel free to point me at
> it.

Just how much information is it?  The answer is somewhere between
'save_boot_params' (shove a tiny bit of data in a magic location) and
"switch to driver model, whack the DT prior to kicking off U-Boot",
depending also on size constraints.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [issue report] mainline u-boot was stuck before booting kernel

2016-07-25 Thread Sandy Patterson
Ah, thanks. Your debugging looks the same as what I've seen from printf
debugging. I'll try to verify though.

On Mon, Jul 25, 2016 at 10:58 AM, Ziyuan Xu  wrote:

> hi Stany,
>
> The difference is that you print out assertion log.
>
> Reset not supported on this platform
> ### ERROR ### Please RESET the board ###
>
> You can add show_boot_progress() function in your bsp file to find out
> something.
> #define CONFIG_SHOW_BOOT_PROGRESS
> void show_boot_progress(int progress)
> {
> printf("Boot reached stage %d\n", progress);
>
> }
>
>
> On 2016年07月25日 22:12, Ziyuan Xu wrote:
>
>> Hi All,
>>
>> I'm sorry to tell you that I failed to boot linux kernel with the
>> mainline u-boot on rk3288 board(both evb-rk3288 & fennec-rk3288). It was
>> stuck in cleanup_before_linux() before jumping to linux, and the
>> boot_stage_flag is BOOTSTAGE_ID_BOOTM_HANDOFF.
>>
>> ## Current stack ends at 0x7df638b0 *  kernel: cmdline image address =
>> 0x0200
>> ## No init Ramdisk
>>ramdisk start = 0x, ramdisk end = 0x
>> ## No Flattened Device Tree
>> Continuing to boot without FDT
>> Initial value for argc=3
>> Final value for argc=3
>> using: ATAGS
>> ## Transferring control to Linux (at address 0200)...
>>
>> Starting kernel ...
>>
>> With the further investigation, it never returnned back from
>> invalidate_dcache_all(). I mean that I can't reach stage 4 as below.
>>
>> cleanup_before_linux
>> ==>cleanup_before_linux_select
>> ==>1.disable_interrupts
>> ==>2.dcache_disable
>> ==>3.invalidate_dcache_all
>> ==>4.icache_disable
>>
>> Debug further, invalidate_dcache_all  invalidate all cache one-by-one
>> which cache type is DATA_ONLY, INSTRUCTION_DATA or UNIFIED. And invalidate
>> way from one set to another set in order. The problem is that the PC ran
>> away in invalidate way loop  [cache level L1!!!].
>>
>> I add some serial output code in __v7_flush_dcache_all to figure out the
>> bog.
>> I expect:
>> Print the value of r9 in sequence, e.g 0x7f, 0x7e, 0x7d. 0x01, 0x00
>> (hex)
>> In fact, print the value of r9 in sequence at first, but print unexpected
>> value afterwards.   e.g 0x7f, 0x7e, 0x7d, ..,0x73, 0x40, 0x85,
>>
>> ENTRY(__v7_flush_dcache_all)
>> [snip]
>> loop1:
>> movr9, r7@ create working copy of max index
>> loop2:
>> +  stmfdsp!, {r0}
>> +  ldr r0, =0xff69
>> +  str r9, [r0]
>> +  ldmfdsp!, {r0}
>>  ARM(orrr11, r10, r4, lsl r5)@ factor way and cache
>> number into r11
>>  THUMB(lslr6, r4, r5)
>>  THUMB(orrr11, r10, r6)@ factor way and cache number
>> into r11
>>  ARM(orrr11, r11, r9, lsl r2)@ factor index number into
>> r11
>>  THUMB(lslr6, r9, r2)
>>  THUMB(orrr11, r11, r6)@ factor index number into r11
>> mcrp15, 0, r11, c7, c14, 2@ clean & invalidate by set/way
>> subsr9, r9, #1@ decrement the index
>> bgeloop2
>> subsr4, r4, #1@ decrement the way
>> bgeloop1
>> skip:
>> ENDPROC(__v7_flush_dcache_all)
>>
>> I don't have the jtag, hence I can't address the current pc. I have no
>> doubt that if any glitches in __v7_flush_dcache_all, I reviewed several
>> times, also copy kernel's implement to here. :-( No effect.
>> A more interesting thing is that Sandy had report it.  He and I have
>> similar problem. Everything work fine after I applied his patches, or
>> disable dcache(active CONFIG_SYS_DCACHE_OFF).
>> @Stany, I'm sorry that I disable dcache during hack.. That was a
>> mistake:-(
>>
>> @Simon & hieko,
>> Can you boot linux with the mainline u-boot? have a try?
>>
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>>
>>
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 0/5] SPL: DFU Support in SPL

2016-07-25 Thread B, Ravi
Tom

>> >How well did you test DFU on other platforms after these changes?
>> >Thanks
>> 
>> Actually earlier platforms did not had this support,  support for 
>> either RNDIS boot mode (CONFIG_SPL_USBETH_SUPPORT) or CONFIG_SPL_USB_SUPPORT 
>> (boot from mass-storage device) were only supported.

>Yes, sorry, I mean you're making generic DFU code changes too, did you test 
>them on other TI platforms which support DFU in other cases to make sure 
>nothing slipped in and broke them with these changes?

I got your point, You are referring to generic dfu code changes, that is moving 
common dfu code to  common/dfu.c , 
so that both u-boot and SPL can leverage common code. But this change is 
generic cleanup code.
Yes, I did test DFU functionality on other platforms (say AM335X).  I can check 
other platform as well. 

But SPL-DFU is tied with ROM-USB peripheral boot mode, I cannot test other than 
DRA7X/AM57X.
But in order to verify the SPL-DFU boot on other platform,  I have tested 
SPL-DFU on AM335x,  hacking common/spl/spl.c to
execute SPL-DFU code by default and could able to load u-boot.img into RAM and 
boot to u-boot. (using dfu-utils from PC host).

Let me know I have clarified.

Regards
Ravi 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 0/5] SPL: DFU Support in SPL

2016-07-25 Thread Tom Rini
On Mon, Jul 25, 2016 at 03:25:52PM +, B, Ravi wrote:
> Tom
> 
> >> >How well did you test DFU on other platforms after these changes?
> >> >Thanks
> >> 
> >> Actually earlier platforms did not had this support,  support for 
> >> either RNDIS boot mode (CONFIG_SPL_USBETH_SUPPORT) or 
> >> CONFIG_SPL_USB_SUPPORT (boot from mass-storage device) were only supported.
> 
> >Yes, sorry, I mean you're making generic DFU code changes too, did you test 
> >them on other TI platforms which support DFU in other cases to make sure 
> >nothing slipped in and broke them with these changes?
> 
> I got your point, You are referring to generic dfu code changes, that is 
> moving common dfu code to  common/dfu.c , 
> so that both u-boot and SPL can leverage common code. But this change is 
> generic cleanup code.
> Yes, I did test DFU functionality on other platforms (say AM335X).  I can 
> check other platform as well. 
> 
> But SPL-DFU is tied with ROM-USB peripheral boot mode, I cannot test other 
> than DRA7X/AM57X.
> But in order to verify the SPL-DFU boot on other platform,  I have tested 
> SPL-DFU on AM335x,  hacking common/spl/spl.c to
> execute SPL-DFU code by default and could able to load u-boot.img into RAM 
> and boot to u-boot. (using dfu-utils from PC host).
> 
> Let me know I have clarified.

OK.  Please note in the next round (and in general) when you also test
that generic changes have been confirmed on other platforms, thanks.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 0/5] SPL: DFU Support in SPL

2016-07-25 Thread B, Ravi
Hi Tom

>> I got your point, You are referring to generic dfu code changes, that 
>> is moving common dfu code to  common/dfu.c , so that both u-boot and SPL can 
>> leverage common code. But this change is generic cleanup code.
>> Yes, I did test DFU functionality on other platforms (say AM335X).  I can 
>> check other platform as well. 
>> 
>> But SPL-DFU is tied with ROM-USB peripheral boot mode, I cannot test other 
>> than DRA7X/AM57X.
>> But in order to verify the SPL-DFU boot on other platform,  I have 
>> tested SPL-DFU on AM335x,  hacking common/spl/spl.c to execute SPL-DFU code 
>> by default and could able to load u-boot.img into RAM and boot to u-boot. 
>> (using dfu-utils from PC host).
>> 
>> Let me know I have clarified.

>OK.  Please note in the next round (and in general) when you also test that 
>generic changes have been confirmed on other platforms, thanks.

Yes, I will do. Thanks.

Regards
Ravi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Add a power domain framework/uclass

2016-07-25 Thread Stephen Warren

On 07/24/2016 08:07 PM, Simon Glass wrote:

Hi Stephen,

On 14 July 2016 at 22:17, Simon Glass  wrote:

Hi Stephen,

On 13 July 2016 at 13:45, Stephen Warren  wrote:

From: Stephen Warren 

Many SoCs allow power to be applied to or removed from portions of the SoC
(power domains). This may be used to save power. This API provides the
means to control such power management hardware.

Signed-off-by: Stephen Warren 
---
I'll soon(?) send a Tegra186 power domain driver that implements this
new subsystem. I'm waiting for all the relevant DT bindings to be
reviewed as kernel patches first though.

...

Acked-by: Simon Glass 

Could you add a command (with list/on/off subcommands) to control this also?


Any thoughts on this?

Applied to u-boot-dm, thanks!


Such a command sounds like a good idea. I'm a bit too swamped to do this 
immediately though.


One issue to consider: How would the user specify which power domain to 
control? There's no global namespace. Only individual drivers can parse 
their own namespace, and there's no requirement that drivers identify 
each powerdomain with e.g. a single integer or name, just like DT 
specificiers can use multiple cells. I can think of two ways to handle this:


a) Add a new "op" function to the driver to allow converting the cmdline 
arguments the user passed to the shell command into whatever value(s) 
the driver uses to identify the power domain, e.g. "cmdline_xlate()". 
This has the disadvantage of requiring extra code (although we could 
provide a default implementation for the common code), but has the 
advantage of allowing control over any powerdomain that any driver 
implements.


b) Make the command take a DT property node name and index, and have the 
command look the powerdomain ID up from DT. This has the disadvantage of 
limiting control to powerdomains that are already added to the DT, but 
does have the advantage of not requiring any driver code.

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


Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h

2016-07-25 Thread Heiko Schocher

Hello Robert,

sorry for replying late, but I was on vacation ... and as I got
while I was on vacation!, a new Internetconnection my current
Internetaccess state is unstable, incl. loosing EMails, because
my provider disabled my EMail address (seems currently already
re-enabled ... so sorry, if I not respond to EMails here on this
list)

Am 25.07.2016 um 12:03 schrieb Robert P. J. Day:

On Mon, 25 Jul 2016, Wolfgang Denk wrote:


Dear Robert,

In message  you 
wrote:


3094 CONFIG_AT91SAM9XE
3095 enable special bootcounter support on at91sam9xe based 
boards.
3096 CONFIG_BLACKFIN
3097 enable special bootcounter support on blackfin based 
boards.
3098 CONFIG_SOC_DA8XX
3099 enable special bootcounter support on da850 based 
boards.


This is name space pollution t best, and has potential to cause
unwanted side effects.  This needs thorough checking and cleanup, if
it should turn out thatthese macros are used only to select specific
bootcount implementations - in that case, they should be renamed
into something like CONFIG_BOOTCOUNT_* or such.

Heiko, maybe you could have a look at that, please?


   i'm not sure it's as bad as it looks, since those macros are used
specifically in drivers/bootcount/Makefile:

   obj-y   += bootcount.o
   obj-$(CONFIG_AT91SAM9XE)+= bootcount_at91.o
   obj-$(CONFIG_BLACKFIN)  += bootcount_blackfin.o
   obj-$(CONFIG_SOC_DA8XX) += bootcount_davinci.o
   obj-$(CONFIG_BOOTCOUNT_AM33XX)  += bootcount_davinci.o
   obj-$(CONFIG_BOOTCOUNT_RAM) += bootcount_ram.o
   obj-$(CONFIG_BOOTCOUNT_ENV) += bootcount_env.o
   obj-$(CONFIG_BOOTCOUNT_I2C) += bootcount_i2c.o

and drivers/bootcount/ is processed only if:

   obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/


Yes, excatly.



but i do see the single, more precise example of
CONFIG_BOOTCOUNT_AM33XX, so someone else can decide if anything
should be renamed here.


I think the

>obj-$(CONFIG_SOC_DA8XX) += bootcount_davinci.o
>obj-$(CONFIG_BOOTCOUNT_AM33XX)  += bootcount_davinci.o

part, should be renamed into "CONFIG_BOOTCOUNT_DAVINCI" ... and
may all symbols should start with "CONFIG_BOOTCOUNT_*" ...

Can you proide a patch for this?

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


  1   2   3   >